1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
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 <gmaxwell@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CANEZrP0wtyagZeSe7kRwk08Td-O5RGz_vwbTNm_v69VdfUuorw@mail.gmail.com>
References: <CAOXABZohe93SSRm1FN5ai2H97eBJV2j+LAjA-39YAaNmX=ep0Q@mail.gmail.com>
<CAAS2fgSJh83YEZjRfL81sKjC=nSKHtWT1qzS0evLJ9Gy6qdA1w@mail.gmail.com>
<CANEZrP0wtyagZeSe7kRwk08Td-O5RGz_vwbTNm_v69VdfUuorw@mail.gmail.com>
Date: Sun, 25 May 2014 02:51:06 -0700
Message-ID: <CAAS2fgRrDR5nHpuyDg7tdu-kYjYc6XnyPcjquodYjsMWiTJRaQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 25 May 2014 09:51:14 -0000
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 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.
|
