{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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"}