From: Gregory Maxwell <gmaxwell@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cut-through propagation of blocks
Date: Sun, 25 May 2014 02:51:06 -0700 [thread overview]
Message-ID: <CAAS2fgRrDR5nHpuyDg7tdu-kYjYc6XnyPcjquodYjsMWiTJRaQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0wtyagZeSe7kRwk08Td-O5RGz_vwbTNm_v69VdfUuorw@mail.gmail.com>
On Sun, May 25, 2014 at 2:36 AM, Mike Hearn <mike@plan99•net> wrote:
> Although this is a somewhat appealing notion, would it really improve
> feature velocity? I don't think the current p2p protocol is holding anything
> back, and having to implement features twice in two protocols would slow
> things down quite a bit.
If someone wanted to implement swanky UDP non-blocking transports or
complex network coding schemes I'd probably want to see the proven in
actual use before sticking them in the reference code, so yes.
It's also the case that the ~last addition we made to the P2P code
added a remotely exploitable crash bug.
There are some pretty distinct use cases out there— fast block
relaying, supporting thin clients, minimizing bandwidth (e.g. via
compression and tx/block redundancy elimination), etc. Some of them
may not be well handled by an external gateway, some of them (e.g.
block relaying) very much could be.
The nice thing with alternative protocols and gatewaying is that it
can proceed completely asynchronously with implementation development,
e.g. revving versions as fast as the users of the protocol care, and
could potentially be used immediately with other bitcoin
implementations... and if its buggy it doesn't break the nodes using
it: I'd be much more likely to run an experimental gateway in another
process on a node than experimental p2p code inside my production
bitcoinds themselves.
next prev parent reply other threads:[~2014-05-25 9:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-24 3:57 Ashley Holman
2014-05-24 5:11 ` Ashley Holman
2014-05-24 22:59 ` Bernd Jendrissek
2014-05-24 23:16 ` Gregory Maxwell
2014-05-24 23:41 ` Ashley Holman
2014-05-25 0:04 ` Alan Reiner
2014-05-25 0:14 ` Gregory Maxwell
2014-05-25 0:38 ` Alan Reiner
2014-05-25 9:36 ` Mike Hearn
2014-05-25 9:51 ` Gregory Maxwell [this message]
2014-05-26 15:08 ` Mike Hearn
[not found] <mailman.177181.1400974908.2207.bitcoin-development@lists.sourceforge.net>
2014-05-24 23:57 ` Jonathan Levin
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=CAAS2fgRrDR5nHpuyDg7tdu-kYjYc6XnyPcjquodYjsMWiTJRaQ@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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