instagibbs

Non-exhaustive thoughts but better to have something written than nothing at all:

WANTING: There's no developer or larger community consensus on anything, so I marked anything I'm happy with as "Wanting" instead.

MEVil: The below discussion is predicated on the fact we as a community are no longer overly concerned with script enhancements creating mining centralization risk via MEVil.

OP_CTV

SIGHASH_ALL emulation. Pretty understandable how to use, also not very exciting on its own unless you believe it's the step function in usability for Arg, Timeout Trees, and also believe those are game changers. It does show up in a lot of places are cleanups removing interactivity in protocols, especially when combined with OP_CSFS.

instagibbs

diff --git a/test/functional/mining_basic.py b/test/functional/mining_basic.py
index fb649c1a6b..fe0cc5fa42 100755
--- a/test/functional/mining_basic.py
+++ b/test/functional/mining_basic.py
@@ -54,11 +54,16 @@ def assert_template(node, block, expect, rehash=True):
     assert_equal(rsp, expect)
 
 
 class MiningTest(BitcoinTestFramework):
     def set_test_params(self):

instagibbs

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

instagibbs

|               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

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