From: Gregory Maxwell <gmaxwell@gmail•com>
To: "Emin Gün Sirer" <el33th4x0r@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire
Date: Fri, 18 Jul 2014 23:48:18 -0700 [thread overview]
Message-ID: <CAAS2fgRRfBtwRuANEvU7VEe2oS3dJ2aZQYU57Brmc6F-uYxePA@mail.gmail.com> (raw)
In-Reply-To: <CAPkFh0thLcaAPaa7Xswu2vSxossRDziMCoStzTDWw+e0c3WqTw@mail.gmail.com>
On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer <el33th4x0r@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.
next prev parent reply other threads:[~2014-07-19 6:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-17 21:35 Kaz Wesley
2014-07-17 22:46 ` Gavin Andresen
2014-07-17 23:26 ` Kaz Wesley
2014-07-18 13:53 ` Jeff Garzik
2014-07-18 14:53 ` Gavin Andresen
2014-07-18 15:06 ` Jeff Garzik
2014-07-18 17:39 ` Kaz Wesley
2014-07-18 17:48 ` Jeff Garzik
2014-07-18 17:53 ` Kaz Wesley
2014-07-18 19:51 ` Kaz Wesley
2014-07-18 19:55 ` Jeff Garzik
2014-07-19 0:54 ` Emin Gün Sirer
2014-07-19 1:25 ` Gregory Maxwell
2014-07-19 3:06 ` Emin Gün Sirer
2014-07-19 6:48 ` Gregory Maxwell [this message]
2014-07-19 8:06 ` Wladimir
2014-07-17 23:34 ` Gregory Maxwell
[not found] ` <CABsx9T2PSa3MpfMMDCb8ACVF5vDOZOFLEK9zfP9PakgHA4U16w@mail.gmail.com>
[not found] ` <CAPkFh0vKFnKRE-sd-Z9t1zB73VLPsiaQ3o=OYgBqqtUE4_rTaw@mail.gmail.com>
2014-07-31 20:47 ` Kaz Wesley
2014-07-31 21:29 ` Gregory Maxwell
2014-07-31 21:41 ` Kaz Wesley
2014-07-31 21:51 ` Gregory Maxwell
2014-07-31 22:27 ` Kaz Wesley
2014-07-31 23:18 ` Gregory Maxwell
2014-08-01 1:00 ` Kaz Wesley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgRRfBtwRuANEvU7VEe2oS3dJ2aZQYU57Brmc6F-uYxePA@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=el33th4x0r@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox