📅 Original date posted:2012-06-15
📝 Original message:On Fri, 2012-06-15 at 15:43 +0200, Mike Hearn wrote:
> > Yes, the format is something that must be hashed out (no pun
> > intended). Need input from potential users about what information
> > they might need.
>
> Matts point that a branch-per-transaction may duplicate data is well
> made, that said, I suspect a format that tries to fix this would be
> much more complicated.
>
> How about see this project as a three part change?
>
> First step - add the mempool command and make nodes sync up their
> mempools on startup.
ACK
>
> Second step - if protocol version >= X, the "block" message consists
> of a header + num transactions + vector<hash> instead of the full
> transactions themselves.
If vector<hash> is sorted in the order of the merkle tree, you dont need
to forward the merkle tree to non-filtered nodes, further saving some
small amount of bandwidth. For filtered nodes, you would still need to
forward merkle branches anyway.
>
> On receiving such a block, we go look to see which transactions we're
> missing from the mempool and request them with getdata. Each time we
> receive a tx message we check to see if it was one we were missing
> from a block. Once all transactions in the block message are in
> memory, we go ahead and assemble the block, then verify as per normal.
> This should speed up block propagation. Miners have an incentive to
> upgrade because it should reduce wasted work.
ACK
>
> Third step - new message, getmerkletx takes a vector<hash> and returns
> a merkletx message: "merkle branch missing the root + transaction data
> itself" for each requested transaction. The filtering commands are
> added, so the block message now only lists transaction hashes that
> match the filter which can then be requested with getmerkletx.
I really dont think it would be /that/ difficult to make it getmerkletxs
vector<hashes>. And then respond with a partial merkle tree to those
transactions.
Matt
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 10:12:58
in reply to nevent1q…nf2g
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 10:12:58Event JSON
{
"id": "beb2ef9ad28bf45595514bfaf9ad593cd13996c64b7dca54b221fbfb0e94b58d",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686132778,
"kind": 1,
"tags": [
[
"e",
"4ab728f783516dec9c5c5541517c3c7b576e19472778304e55db6fb52442f9a4",
"",
"root"
],
[
"e",
"b6e037efab786e242dadce378a30aa6ccadc6dfbb57f812d80a46ced230e0069",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2012-06-15\n📝 Original message:On Fri, 2012-06-15 at 15:43 +0200, Mike Hearn wrote:\n\u003e \u003e Yes, the format is something that must be hashed out (no pun\n\u003e \u003e intended). Need input from potential users about what information\n\u003e \u003e they might need.\n\u003e \n\u003e Matts point that a branch-per-transaction may duplicate data is well\n\u003e made, that said, I suspect a format that tries to fix this would be\n\u003e much more complicated.\n\u003e \n\u003e How about see this project as a three part change?\n\u003e \n\u003e First step - add the mempool command and make nodes sync up their\n\u003e mempools on startup.\nACK\n\u003e \n\u003e Second step - if protocol version \u003e= X, the \"block\" message consists\n\u003e of a header + num transactions + vector\u003chash\u003e instead of the full\n\u003e transactions themselves.\nIf vector\u003chash\u003e is sorted in the order of the merkle tree, you dont need\nto forward the merkle tree to non-filtered nodes, further saving some\nsmall amount of bandwidth. For filtered nodes, you would still need to\nforward merkle branches anyway.\n\u003e \n\u003e On receiving such a block, we go look to see which transactions we're\n\u003e missing from the mempool and request them with getdata. Each time we\n\u003e receive a tx message we check to see if it was one we were missing\n\u003e from a block. Once all transactions in the block message are in\n\u003e memory, we go ahead and assemble the block, then verify as per normal.\n\u003e This should speed up block propagation. Miners have an incentive to\n\u003e upgrade because it should reduce wasted work.\nACK\n\u003e \n\u003e Third step - new message, getmerkletx takes a vector\u003chash\u003e and returns\n\u003e a merkletx message: \"merkle branch missing the root + transaction data\n\u003e itself\" for each requested transaction. The filtering commands are\n\u003e added, so the block message now only lists transaction hashes that\n\u003e match the filter which can then be requested with getmerkletx.\nI really dont think it would be /that/ difficult to make it getmerkletxs\nvector\u003chashes\u003e. And then respond with a partial merkle tree to those\ntransactions.\n\nMatt",
"sig": "dcdd7260564b27aae114dc6dd3c5d00b9e840a92036039c4c46f91993228f3917da1e2eea9f96ad0e0c6164d531f5799b25cc74128f8ac807cd164348ee7cfbd"
}