📅 Original date posted:2012-06-15
📝 Original message:> 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.
Second step - if protocol version >= X, the "block" message consists
of a header + num transactions + vector<hash> instead of the full
transactions themselves.
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.
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.
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 10:12:55
in reply to nevent1q…zhxu
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 10:12:55Event JSON
{
"id": "b6e037efab786e242dadce378a30aa6ccadc6dfbb57f812d80a46ced230e0069",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686132775,
"kind": 1,
"tags": [
[
"e",
"4ab728f783516dec9c5c5541517c3c7b576e19472778304e55db6fb52442f9a4",
"",
"root"
],
[
"e",
"bd667ace1991c5428aa47f46064b8f01e16864201199bb7b57214f9192d023b3",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2012-06-15\n📝 Original message:\u003e Yes, the format is something that must be hashed out (no pun\n\u003e intended). Need input from potential users about what information\n\u003e they might need.\n\nMatts point that a branch-per-transaction may duplicate data is well\nmade, that said, I suspect a format that tries to fix this would be\nmuch more complicated.\n\nHow about see this project as a three part change?\n\nFirst step - add the mempool command and make nodes sync up their\nmempools on startup.\n\nSecond step - if protocol version \u003e= X, the \"block\" message consists\nof a header + num transactions + vector\u003chash\u003e instead of the full\ntransactions themselves.\n\nOn receiving such a block, we go look to see which transactions we're\nmissing from the mempool and request them with getdata. Each time we\nreceive a tx message we check to see if it was one we were missing\nfrom a block. Once all transactions in the block message are in\nmemory, we go ahead and assemble the block, then verify as per normal.\nThis should speed up block propagation. Miners have an incentive to\nupgrade because it should reduce wasted work.\n\nThird step - new message, getmerkletx takes a vector\u003chash\u003e and returns\na merkletx message: \"merkle branch missing the root + transaction data\nitself\" for each requested transaction. The filtering commands are\nadded, so the block message now only lists transaction hashes that\nmatch the filter which can then be requested with getmerkletx.",
"sig": "213017a2ae04a27754848880db6c8b398820776f55840c9d63d81aebe26a7d656ee8f52512b6632389f7540dbd73c4f4546b0f0ba74193d665fc768854ad5c8d"
}