I (instagibbs) was asked to draft a statement, I feel this is a fair summation of the project's direction. I might be wrong
Bitcoin Core’s next release will, by default, relay and mine transactions whose
OP_RETURN outputs exceed 80 bytes and allow any number of these outputs.
The long-standing cap, originally a gentle signal that block space should be used
sparingly for non-consensus data has outlived its utility.
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,
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:
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?
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.
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.
| 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): |
| 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: