Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WoV5F-0001LL-UO for bitcoin-development@lists.sourceforge.net; Sun, 25 May 2014 09:51:14 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.41 as permitted sender) client-ip=209.85.215.41; envelope-from=gmaxwell@gmail.com; helo=mail-la0-f41.google.com; Received: from mail-la0-f41.google.com ([209.85.215.41]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WoV5E-0005nY-Ts for bitcoin-development@lists.sourceforge.net; Sun, 25 May 2014 09:51:13 +0000 Received: by mail-la0-f41.google.com with SMTP id e16so5162589lan.14 for ; Sun, 25 May 2014 02:51:06 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.45.37 with SMTP id j5mr960036lam.58.1401011466216; Sun, 25 May 2014 02:51:06 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Sun, 25 May 2014 02:51:06 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 May 2014 02:51:06 -0700 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WoV5E-0005nY-Ts Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Cut-through propagation of blocks X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 09:51:14 -0000 On Sun, May 25, 2014 at 2:36 AM, Mike Hearn wrote: > Although this is a somewhat appealing notion, would it really improve > feature velocity? I don't think the current p2p protocol is holding anyth= ing > 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=E2=80=94 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.