📅 Original date posted:2014-07-19
📝 Original message:On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer <el33th4x0r at gmail.com> wrote:
>
>> 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.
Oh that does sound interesting— its the property I was trying to
approximate with the FEC.. It achieves the one-shot, but there is
overhead. One plus we have is that we can do some tricks to make some
computational soundness arguments that we'd actually get average
performance on average (e.g. that someone can't author transactions in
such a way as to jam the process).
> 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.
Thank you, I've certantly queued the paper for reading.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:24:11
in reply to nevent1q…4dk9
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:24:11Event JSON
{
"id": "d56a9f852515b41770615d9904b21cd59499be311047bdd39b9f7dee7b42c9ff",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151451,
"kind": 1,
"tags": [
[
"e",
"3507527acf6651445fc18e718512a320c7c5edde322b321b00914bf719d85722",
"",
"root"
],
[
"e",
"b69102ccd152ad200d34cbc9eed64586a9c8178397e55743efd575d076fc3f0a",
"",
"reply"
],
[
"p",
"b68afd106d166cdb4d51d8e16c275c09e0a49020fb6f311509c56b6743b37a84"
]
],
"content": "📅 Original date posted:2014-07-19\n📝 Original message:On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer \u003cel33th4x0r at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Most things I've seen working in this space are attempting to minimize\n\u003e\u003e the data transfered. At least for the miner-interested case the round\n\u003e\u003e complexity is much more important because a single RTT is enough to\n\u003e\u003e basically send the whole block on a lot of very relevant paths.\n\u003e\n\u003e Agreed. Yaron's scheme is magical because it is non-interactive. I send you\n\u003e a packet of O(expected-delta) and you immediately figure out the delta\n\u003e without further back and forth communication, each requiring an RTT.\n\nOh that does sound interesting— its the property I was trying to\napproximate with the FEC.. It achieves the one-shot, but there is\noverhead. One plus we have is that we can do some tricks to make some\ncomputational soundness arguments that we'd actually get average\nperformance on average (e.g. that someone can't author transactions in\nsuch a way as to jam the process).\n\n\u003e In any case, I have no horse here (I think changing the client so it's\n\u003e multithreaded is the best way to go), but Yaron's work is pretty cool and\n\u003e may be applicable.\n\n\nThank you, I've certantly queued the paper for reading.",
"sig": "d279e93e768833cb623591deb7445e0a0652efc9be8e4d3199cb75c86cebfee7747e428d154de9513e4585a4d8b87f7fec5b498fbe287a0307d563c510d3fb35"
}