<bitcoin-git>
[bitcoin] hebasto opened pull request #32856: Update `minisketch` subtree and switch to its build script (master...250702-minisketch) https://github.com/bitcoin/bitcoin/pull/32856
<bitcoin-git>
[bitcoin] hebasto closed pull request #32289: doc: Add note for building on macOS (Intel) with CMake ≥ 4.0 (master...250416-macos-intel) https://github.com/bitcoin/bitcoin/pull/32289
<ghost43>
are there known vulnerabilities for the witness commitment wtxid merkle tree? it uses the same construction as the block header txid merkle tree, so e.g. it would also be vulnerable against 64 byte txs, right? except 64 bytes is *just* barely not enough to serialize a tx with a witness, meaning none of the 64-byte tx concerns apply?
<ghost43>
version: 4, marker+flag: 2, n_ins(0x01): 1, prevout_txid: 32, prevout_idx: 4, scriptSig_len(0x00): 1, nSequence: 4, n_outs(0x01): 1, out_amt: 8, spk_len: 1, spk: 1 (OP_RETURN <>), n_wit_elems: 1 byte (must be 0x00 ?, no space left), locktime: 4. that's already 64 B. but as the witness is empty, 0x00, the tx would have to be serialized without marker+flag and witness, using the old format.
<ghost43>
so seems I cannot construct a 64 byte witness-serialized tx. is there any public writeup/discussion about this topic?
<_aj_>
ghost43: there are the same number of entries in the witness merkle tree as in the tx merkle tree, so i don't think there's an additional ambiguity there
<ghost43>
_aj_: right. what I am asking is which ambiguities are still present and apply
<ghost43>
for example, the bip54 consensus cleanup mentions banning txs that serialize as 64 bytes using the old format. why is it not banning txs that serialize as 64 bytes using the new format?
<ghost43>
(is it because there aren't any?)
<_aj_>
ghost43: if they don't serialize to 64 bytes in the old format, you know exactly how many txs there are, and thus there's no ambiguity checking the witness merkle root
<ghost43>
_aj_: but as a light client, if you want to witness-spv a tx, does that mean you also have to do the satoshi-spv using the block header merkle tree, and compare that the proof lengths are the same?
<_aj_>
(if they don't --> if they aren't permitted to)
<ghost43>
or how would you know if the two merkle trees contain the same number of txs
sbddesign has quit [Ping timeout: 248 seconds]
<bitcoin-git>
[bitcoin] fanquake closed pull request #32397: doc: Add hint about avoiding spaces in paths when building on Windows (master...HintNoSpace) https://github.com/bitcoin/bitcoin/pull/32397
<_aj_>
oh i see. witness-spv seems like a pain since you have to get and parse the coinbase as well
<ghost43>
well, I guess the light client would need to satoshi-spv the coinbase tx anyway, so could just compare the length of the coinbase tx's merkle branch with the length of the witness merkle-branch proving the interesting tx
<sipa>
right, is it possible to exploit the 64-byte (non-witness) txid merkle root if you know the correct number of *levels* in the tree, but not the exact number of leaves?
jespada has quit [Ping timeout: 248 seconds]
jespada has joined #bitcoin-core-dev
<_aj_>
i think 020000000001017e44cfd662a5b224d0ffd016f6ae3903aa3d03ea35c1d864adb24b897f1c512513000000003b0000000102a12500000000000100010001000000 is the smallest possible tx with a witness at 65 bytes? i think a witness flag with an empty witness is invalid, no?
<sipa>
_aj_: indeed
<sipa>
and even if one would accept that in a deserializer (which i wouldn't recommend, but some software has accepted in the past), you should always use a canonically serialized form for computing wtxids
<_aj_>
ah my bad, 020000000001017e44cfd662a5b224d0ffd016f6ae3903aa3d03ea35c1d864adb24b897f1c512513000000003b0000000102a125000000000000010001000000 gets to exactly 64 bytes
<eugenesiegel>
I want to measure leveldb usage in some specific scenarios, is there any way to simulate this? I basically want to use a mainnet-size leveldb to measure things I cannot really measure on mainnet.
<bitcoin-git>
[bitcoin] hebasto opened pull request #32858: doc: Add workaround for vcpkg issue with paths with embedded spaces (master...250702-vcpkg-spaces) https://github.com/bitcoin/bitcoin/pull/32858
sbddesign has quit [Remote host closed the connection]
<phantomcircuit>
i want to separate activatebestchain running from downloading blocks during ibd, so that means a thread running activatebestchain, what should own that new thread?
jonatack has joined #bitcoin-core-dev
sbddesign has quit [Ping timeout: 248 seconds]
jon_atack has quit [Ping timeout: 252 seconds]
<phantomcircuit>
i was thinking owned by ChainStateManager ?