| 28.0 | |
| ---- | |
| a) Do nothing | |
| - 1P1C things propagate better | |
| - package rbf can often happen in non-adversial settings | |
| b) disable update_fee | |
| - 1 sat/vbyte static commit tx fee | |
| - no commit tx format changes |
| | ns/op | op/s | err% | total | benchmark | |
| |--------------------:|--------------------:|--------:|----------:|:---------- | |
| | 93,062,810.00 | 10.75 | 0.3% | 1.02 | `LinearizeOptimallyExample00` | |
| | 97,757,782.00 | 10.23 | 10.0% | 1.03 | :wavy_dash: `LinearizeOptimallyExample01` (Unstable with ~1.0 iters. Increase `minEpochIterations` to e.g. 10) | |
| | 72,062,906.00 | 13.88 | 18.7% | 1.39 | :wavy_dash: `LinearizeOptimallyExample02` (Unstable with ~1.9 iters. Increase `minEpochIterations` to e.g. 19) | |
| | 70,236,537.00 | 14.24 | 8.2% | 0.96 | :wavy_dash: `LinearizeOptimallyExample03` (Unstable with ~1.3 iters. Increase `minEpochIterations` to e.g. 13) | |
| | 24,690,481.40 | 40.50 | 13.4% | 1.07 | :wavy_dash: `LinearizeOptimallyExample04` (Unstable with ~4.2 iters. Increase `minEpochIterations` to e.g. 42) | |
| | 31,282,472.67 | 31.97 | 16.3 |
| 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 |
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:
| 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) |
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
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
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_o_atx_* Alice-offered "offered PTLC" in Alice's txa_o_btx_* Alice-offered "received PTLC" in Bob's txb_o_atx_* Bob-offered "received PTLC" in Alice's txb_o_btx_* Bob-offered "offered PTLC" in Bob's tx
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:
| <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 |