instagibbs

L2/Covenants Coredev Study Group

Who is (potentially) leading: Somsen, instagibbs, ???

Who attends: Anyone invited to Coredev

Time/Location: FIXME Adam Jonas

Before we meet again at Coredev in late February, a few of us thought it would be helpful to organize a study club, aimed at you, Bitcoin Core contributors,

instagibbs

Assume for simplicity contract id == txid of kickoff tx.

"register" == where we store committed state, can be CCV, caboose, whatever

kickoff tx has two outputs. These outputs, or the descendant of the first output and the second output MUST be spent together on the second spending path.

output 1 has a spk HISTORY_SPK which:

1. self-replicates spk in new output (for simplicity)

instagibbs

Contract-level Relative Timelock (CLRT) UTXO for Eltoo

Eltoo constructs such as ln-symmetry suffer from an issue where every time an update transaction is confirmed on the blockchain, the relative timelock is reset. This causes further funds lockup, and further extends HTLC expiry in the LN use-case, potentially reducing network utility.

How can we have a "contract" level relative timelock?

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)