Conversation
fjahr
force-pushed
the
2026_utxo_set_share
branch
from
802cfce to
4bc39c8
Compare
| | `merkle_root` | `uint256` | 32 | Root of the Merkle tree computed over chunk hashes. | | ||
|
|
||
| A requesting node MUST ignore entries whose `serialized_hash` does not match a known | ||
| utxo set hash for the corresponding height. |
There was a problem hiding this comment.
I think it would be better for a client that supports this mechanism to hardcode the merkle root instead of the straight serialized hash, and to drop serialized_hash from this message.
There was a problem hiding this comment.
Hm, yeah, I think that makes sense, I was struggling with finding the right path between building on top of the existing assumeutxo data we already have and extending it. I am adding the merkle root to the assumeutxo data in my PR, so checking the serialized_hash is a belts and suspenders there, so it makes sense to make this explicit here as well.
There was a problem hiding this comment.
If you wanted to change the contents of the utxo dump as well, it would be nice to include the header chain for the block where the snapshot was taken. Then you could do an import without needing to connect to the network at all, I think.
| | `block_hash` | `uint256` | 32 | Block hash this data corresponds to. | | ||
| | `chunk_index` | `uint32_t` | 4 | Zero-based index of this chunk. | | ||
| | `proof_length` | `compact_size` | 1–9 | Number of hashes in the Merkle proof. | | ||
| | `proof_hashes` | `uint256[]` | 32 × `proof_length` | Sibling hashes from leaf to root. | |
There was a problem hiding this comment.
Rather than a proof, it might be better to just request getutxoset <height> <hash> 0xFFFFFFFF once to get the full list of chunk hashes -- that should be about 74kB for a 9GB utxo set, and should stay under 4MB until the utxo set is >450GB. Then each chunk is just <height> <hash> <number> <data>.
There was a problem hiding this comment.
Huh, interesting idea to get all the chunk hashes first, I didn't think of that. It might make sense to do this with a separate message type even instead of hacking getutxoset as you described. I will have to think about it a little more.
|
I was going to complain that I haven’t seen a discussion about this proposal on the mailing list… but you did that already for me. If you already know that you should send it to the mailing list first, I don’t know why you opened the PR first, though. 😛 |
It wasn't clear to me that a ML post was a prerequisit to open the PR. I just thought it was necessary to do this at some point before the bip could get merged/assigned a number. I think that having a place for more detail oriented commentary makes sense to have in addition to the high level discussion happening on the ML, if ML readers have such feedback but would rather use the more convenient inline commenting/suggestion features in GitHub. I was also looking for feedback on my assumeutxo related question, e.g. can I assume knowledge of a feature that is only implemented in Bitcoin Core or should I define this in the BIP. The ML doesn't seem like the right place to ask about this. I will close this for now and re-open when I have made the ML post and given it some reasonable time for discussion. |
3 participants
This BIP draft describes the sharing of a full UTXO set via the p2p network.
Design summary:
The one part I am not so sure about yet: This references Bitcoin Core and it’s features or RPCs in a few places now. I am aware that this is not ideal for specification that targets a wider audience but the reality is that assumeutxo seems to be only implemented in Bitcoin Core and mentioning RPCs from the workflow there seems the most clear way to describe this. But I am happy to generalize this further, I would be very happy to receive some guidance what level of referencing assumutxo is acceptable here since it is obviously the main current motivation. One concrete example: The Bitcoin Core PR that I will use as a reference implementation will rely on assumeutxo params rather than comparing multiple peer values of the merkle root. Is this discrepancy an issue?
Mailing List post
and reference implementationwill follow shortly and I will add the links here asap.