instagibbs

Given the general resistance of people to concept ACK a specific
transaction topology like V3, I was thinking it would be useful
to think ahead and see what policy relaxations or restrictions
we could enact in the future to make things more flexible,
incentive compatible, and overall more useful.

TL;DR: V3 is useful and likely upgradeable to something
we can be more proud of.

Here are some ideas on what path we could take. Here's a set

instagibbs

LN-Symmetry Project

ln-symmetry started with a simple idea: Someone should take the eltoo idea and take it as far as possible to prove out the concept, without requiring community consensus required actions like softforks before proving it out.

The end result is research-level quality software, with basic functional tests of the common cases:

1. channel opens
2. payments (revamped + simplified channel state machine)
3. payments with hops

instagibbs

diff --git a/src/test/fuzz/package_eval.cpp b/src/test/fuzz/package_eval.cpp
index 9c64c39699..989373b044 100644
--- a/src/test/fuzz/package_eval.cpp
+++ b/src/test/fuzz/package_eval.cpp
@@ -98,51 +98,52 @@ struct TransactionsDelta final : public CValidationInterface {
          m_added.erase(tx);
     }
 };
 
 void MockTime(FuzzedDataProvider& fuzzed_data_provider, const Chainstate& chainstate)

instagibbs

Bitcoin has a KYC problem. We don't know any customers. One man's spammer is another man's marketing genius.

This plays into how Bitcoin software handles transactions that are gossiped to it on the network. Your local node does a list of anti-DoS checks, as well as miner compatibility checks, caches the transaction, and forwards it to any nodes connected to yours.

For miner incentives, this is not exactly straight forward, but easy enough to inuit. If you can "make the mempool better", you accept a new transaction, and kick out whatever it replaced.

This isn't the whole story. What it it makes the mempool contents better for miners, but is worse

instagibbs

"Free Relay"

In transaction relay we are trying to avoid "free relay" which is roughly defined as:

total_bytes_relayed / (total_sats_in_mempool + total_sats_mined) ?< minrelay

Did the sum total of bytes we've been accepting to our mempool and propagating across the network pay for the "bandwidth" to do so, dubbed minrelay which is a static value

instagibbs

Messaging Changes

I am assuming minimal changes to commitment transaction structure, essentially swapping out HTLC for PTLC, so no fast-forward schemes here.

Here are output labels because I get confused so often what things in BOLTs mean:

• (a) a_o_atx_* Alice-offered "offered PTLC" in Alice's tx
• (b) a_o_btx_* Alice-offered "received PTLC" in Bob's tx
• (c) b_o_atx_* Bob-offered "received PTLC" in Alice's tx
• (d) b_o_btx_* Bob-offered "offered PTLC" in Bob's tx

instagibbs

This was written in response to bitcoin/bitcoin#27578 and any other number of occurrences of the topic.

“Standardness policy” is a term for a transaction that would be consensus-legal, but our node doesn’t want to relay for various reasons. Clearly if it’s consensus valid we want to accept it to not split the network if a miner chooses a “weird” transaction to mine.

There are N motivations for policy that I know of:

1. Anti-DoS: Only “cheap” things to validate get flooded to the network
2. Security: Certain types of transactions may mess up certain systems for no good reason
3. Upgrade hooks: We leave some things “forbidden” such that if we find a use for them later we don’t “confiscate” funds by refusing to relay e.g., a spend or pre-signed transaction
4. Pro-decentralization: Make it simple/cheap for miners to build blocks that pay well

instagibbs

<instagibbs> _aj_, thinking I should have two variants of my work, one which is easier to get into signet(but also more pinnable), as well as one that's more "ideal" and can be switched on once features are in. So for MVP for standardness, I think I just need some form of annex relay support
<instagibbs> would be easy to remove EAs, could at least prioritise txns if nothing else as a demo. (or I could hack settlement txns to just dump value to fee)
<instagibbs> Shouldn't be a ton of work on my end to support both variants, and having live demo > not
* Disconnected ()
* Now talking on ##eltoo
<_aj_> instagibbs_: EAs seem fine to keep -- doesn't really matter if there's dust anyone-can-spend utxos on signet due to mempool evictions; all utxos on signet are equally worthless anyway
<instagibbs_> ok, so 1) annexcarrier option which can be arbitrarily restricted later via Bright Side PR 2) Make OP_TRUE output standard 3) allow dusty OP_TRUE. These would be quite low drag and allow me to get txns in the mempool/blo

instagibbs

# -*- coding: utf-8 -*-

################################################################################
## Form generated from reading UI file 'getxpubdialog.ui'
##
## Created by: Qt User Interface Compiler version 5.14.0
##
## WARNING! All changes made in this file will be lost when recompiling UI file!
################################################################################

instagibbs

diff --git a/src/wallet/rpcdump.cpp b/src/wallet/rpcdump.cpp
index c93c297..bf5655a 100644
--- a/src/wallet/rpcdump.cpp
+++ b/src/wallet/rpcdump.cpp
@@ -811,11 +811,12 @@ struct ImportData
     std::unique_ptr<CScript> redeemscript; //! Provided redeemScript; will be mvoed to `import_scripts` if relevant.
     std::unique_ptr<CScript> witnessscript; //! Provided witnessScript; will be moved to `import_scripts` if relevant.
     std::map<CKeyID, CPubKey> pubkeys;
+    std::vector<CPubKey> ordered_pubkeys; //! Used to track ordering of insertion of pubkeys
     std::map<CKeyID, CKey> privkeys;