š
Original date posted:2014-07-18
š Original message:Two more half-baked thoughts:
We should be able to assume that the majority of transaction data (except
for coinbase) has already been propagated. As Jeff said, incentivizing
nodes to propagate transactions is a very good thing (the signature cache
already gives a small incentive to miners to propagate and not 'hoard'
transactions).
So the only information that theoretically needs to be propagated is which
transactions a miner is including in their block, and in what order they
are included.
But if there was some agreed-upon canonical ordering, then it should
theoretically be possible to take shortcuts in the "what order".
You'd start with setof(transactions I think everybody knows about)
Select some subset, based on miner's policy
Sort that subset with the canonical ordering algorithm
Very efficiently broadcast, taking all sorts of shortcuts assuming most of
your peers already know the set you started with and expect the same
canonical ordering (see gmaxwell's thoughts on block encoding).
Second half-baked thought:
I wonder if broadcasting your transaction selection policy ("11KB of free
transactions, sorted by priority, then 111K of fee-paying transactions,
sorted by fee") might make it possible to save even more bandwidth by
letting your peers create a very good approximation of your block with just
that information....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140718/f2b10a38/attachment.html>;
Gavin Andresen [ARCHIVE] /
npub1s4ā¦d44kw
2023-06-07 15:24:07
in reply to nevent1qā¦c7na
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwPublished at
2023-06-07 15:24:07Event JSON
{
"id": "c15fb6d0e3b62aa4c340eadb14a172a9199e1cc33fbe6bde36f12a6b3485625b",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686151447,
"kind": 1,
"tags": [
[
"e",
"3507527acf6651445fc18e718512a320c7c5edde322b321b00914bf719d85722",
"",
"root"
],
[
"e",
"01450126e157780fd8ecefc61173dbf6b56b42ff0eec28e5710a41b737343abe",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "š
Original date posted:2014-07-18\nš Original message:Two more half-baked thoughts:\n\nWe should be able to assume that the majority of transaction data (except\nfor coinbase) has already been propagated. As Jeff said, incentivizing\nnodes to propagate transactions is a very good thing (the signature cache\nalready gives a small incentive to miners to propagate and not 'hoard'\ntransactions).\n\nSo the only information that theoretically needs to be propagated is which\ntransactions a miner is including in their block, and in what order they\nare included.\n\nBut if there was some agreed-upon canonical ordering, then it should\ntheoretically be possible to take shortcuts in the \"what order\".\n\nYou'd start with setof(transactions I think everybody knows about)\nSelect some subset, based on miner's policy\nSort that subset with the canonical ordering algorithm\nVery efficiently broadcast, taking all sorts of shortcuts assuming most of\nyour peers already know the set you started with and expect the same\ncanonical ordering (see gmaxwell's thoughts on block encoding).\n\nSecond half-baked thought:\nI wonder if broadcasting your transaction selection policy (\"11KB of free\ntransactions, sorted by priority, then 111K of fee-paying transactions,\nsorted by fee\") might make it possible to save even more bandwidth by\nletting your peers create a very good approximation of your block with just\nthat information....\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140718/f2b10a38/attachment.html\u003e",
"sig": "61fe626aa64bec11bd38fa9a4ca05feb3200e3bfbf58a563a02f6aa8db76a033985c2a8dd953d62769923f0ac13aaa8e0ecb1992f792d06e7c701cd80a43ed4e"
}