This lists what remains open in opportunistic one-parent-one-child (1p1c) package relay and orphan handling after the fixes in , and a follow-up PR adding an end-to-end liveness fuzz target (). All items are low severity. Each can delay one 1p1c attempt from one peer; none lets a peer poison a txid for future attempts, and none puts funds at risk.
| | Commit | Problem fixed |
| #!/usr/bin/env python3 | |
| """ | |
| Craft a BDB wallet file that triggers excessive memory allocation. | |
| The BDB read-only parser (src/wallet/migrate.cpp) trusts the page | |
| header's `entries` field without validating it against the page size. | |
| This script creates a file where a leaf page claims thousands of | |
| entries, all pointing to the same record with a large `len` field. | |
| Each entry allocates a separate copy of the record data, causing | |
| memory consumption vastly disproportionate to the file size. |
| #!/usr/bin/env python3 | |
| """ | |
| Craft a malicious BDB wallet file with circular overflow page references. | |
| The Bitcoin Core BDB read-only parser (src/wallet/migrate.cpp) follows | |
| overflow page chains without cycle detection. This script creates a | |
| minimal valid BDB file where an overflow page's next_page field points | |
| back to itself, causing an infinite loop with unbounded memory growth | |
| when the file is opened via migratewallet or bitcoin-wallet tool. |
| fn not(bit: bool) -> bool { | |
| <u1>::into(jet::complement_1(<bool>::into(bit))) | |
| } | |
| // ECDSA verify over secp256k1. | |
| // Returns by asserting validity (panics on failure). | |
| fn ecdsa_verify_raw(msg32: u256, pk_x: u256, pk_y_is_odd: u1, r: u256, s: u256) { | |
| // 1) Range checks: r,s in [1, n-1] | |
| let r_s: Scalar = r; |
Sorry, this got very long at least for my standards.
I'd like to start off by saying I believe that Bitcoin is in good technical hands regardless of how this shakes out. Good things take time and we've learned a lot; let's continue doing so.
Before I dive into what I think needs to be answered for this proposal to move forward, I'd like to respond to language in the letter to make sure we're on a common understanding of the asks being given here.
We respectfully ask Bitcoin Core contributors to prioritize the review and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or similar) within the next six months. We believe this timeline allows for rigorous final review and activation planning.
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-payment proof of publication 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.