📅 Original date posted:2014-07-19
📝 Original message:> Most things I've seen working in this space are attempting to minimize
> the data transfered. At least for the miner-interested case the round
> complexity is much more important because a single RTT is enough to
> basically send the whole block on a lot of very relevant paths.
Agreed. Yaron's scheme is magical because it is non-interactive. I send you
a packet of O(expected-delta) and you immediately figure out the delta
without further back and forth communication, each requiring an RTT.
> I know much better is possible (see up-thread where I linked to an old
> proposal to use forward error correction to transfer with low data
> transfer (but not optimal) and negligible probability of needing a
> round-trip, with a tradeoff for more overhead for lower roundtrip
> probability).
FEC schemes are both fairly complex, because the set is constantly
changing, and (if i understand your suggestion correctly) they add
additional metadata overhead (albeit mostly during tx propagation). Set
reconciliation is near optimal.
In any case, I have no horse here (I think changing the client so it's
multithreaded is the best way to go), but Yaron's work is pretty cool and
may be applicable.
- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140718/d7cb8d29/attachment.html>;
Emin Gün Sirer [ARCHIVE] /
npub1k6…xvja6
2023-06-07 15:24:10
in reply to nevent1q…0a0a
Author Public Key
npub1k6906yrdzekdkn23mrskcf6up8s2fypqldhnz9gfc44kwsan02zq5xvja6Published at
2023-06-07 15:24:10Event JSON
{
"id": "b69102ccd152ad200d34cbc9eed64586a9c8178397e55743efd575d076fc3f0a",
"pubkey": "b68afd106d166cdb4d51d8e16c275c09e0a49020fb6f311509c56b6743b37a84",
"created_at": 1686151450,
"kind": 1,
"tags": [
[
"e",
"3507527acf6651445fc18e718512a320c7c5edde322b321b00914bf719d85722",
"",
"root"
],
[
"e",
"bcd9fcc984e53fb42cce5c73dae1d8baf42d8be032f6f73e2238c641623b7a60",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-07-19\n📝 Original message:\u003e Most things I've seen working in this space are attempting to minimize\n\u003e the data transfered. At least for the miner-interested case the round\n\u003e complexity is much more important because a single RTT is enough to\n\u003e basically send the whole block on a lot of very relevant paths.\n\nAgreed. Yaron's scheme is magical because it is non-interactive. I send you\na packet of O(expected-delta) and you immediately figure out the delta\nwithout further back and forth communication, each requiring an RTT.\n\n\u003e I know much better is possible (see up-thread where I linked to an old\n\u003e proposal to use forward error correction to transfer with low data\n\u003e transfer (but not optimal) and negligible probability of needing a\n\u003e round-trip, with a tradeoff for more overhead for lower roundtrip\n\u003e probability).\n\nFEC schemes are both fairly complex, because the set is constantly\nchanging, and (if i understand your suggestion correctly) they add\nadditional metadata overhead (albeit mostly during tx propagation). Set\nreconciliation is near optimal.\n\nIn any case, I have no horse here (I think changing the client so it's\nmultithreaded is the best way to go), but Yaron's work is pretty cool and\nmay be applicable.\n\n- egs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140718/d7cb8d29/attachment.html\u003e",
"sig": "dec522fac28fd09a66a6c61b75e000bfb3998b7b97561d49840cc862e56f58b5437a9d0e4247bfc2a0ca1e9b664e35bb6479e54ab9a69338510c4ba3c44cddc8"
}