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
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
Return-Path: <arnoud@pukaki.bz>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 18DE89B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 19:14:28 +0000 (UTC)
X-Greylist: delayed 00:06:41 by SQLgrey-1.7.6
Received: from mail.affil.co (mail.affil.co [75.101.133.5])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3268D14E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 19:14:27 +0000 (UTC)
Received: (qmail 29338 invoked by uid 1008); 5 Aug 2015 19:06:35 +0000
Received: from mail-oi0-f45.google.com (arnoud@pop.affil.co@209.85.218.45)
by mail.affil.co with RC4-SHA encrypted SMTP; 5 Aug 2015 19:06:35 +0000
Received: by oip136 with SMTP id 136so25501281oip.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Aug 2015 12:07:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.90.5 with SMTP id o5mr9128753oib.79.1438801664497; Wed,
05 Aug 2015 12:07:44 -0700 (PDT)
Received: by 10.76.83.136 with HTTP; Wed, 5 Aug 2015 12:07:44 -0700 (PDT)
Date: Wed, 5 Aug 2015 13:07:44 -0600
Message-ID: <CALwsPgnnkbfUBhL=Qyspz13pnZ-6RHdaZOGvfLG34JjJRgt2Dw@mail.gmail.com>
From: Arnoud Kouwenhoven - Pukaki Corp <arnoud@pukaki.bz>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113d468e1d5e86051c951e90
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,HTML_MESSAGE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Idea: Efficient bitcoin block propagation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2015 19:14:28 -0000
--001a113d468e1d5e86051c951e90
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello all.
We=E2=80=99d like to share an idea we have to dramatically increase the bit=
coin
block propagation speed after a new block has been mined for the first time=
.
Efficient bitcoin block propagation
A proposed solution to provide near-instantaneous block propagation on the
bitcoin network, even with slow network connections or large block sizes.
Increasing mining efficiency for everyone while decreasing transaction
confirmation times and strengthening the distributed nature of bitcoin.
Short summary: we propose to introduce bitcoin-backed guarantees
(=E2=80=9CGuarantee Messages=E2=80=9D) between miners. This would allow min=
ers to mine on
blocks that are not yet fully transmitted. This reduces the effect of slow
internet connections, leveling the playing field between the 1st world
fiberoptic datacenter miners and the rest of the world. We also believe it
strengthens the bitcoin network by using existing processing power that is
currently wasted into further securing the blockchain, and it reduces the
likelihood of transactions becoming confirmed, then unconfirmed and then
-hopefully- confirmed again (due to different miners finding competing
blocks with different transactions at approx the same time).
It is possible to implement our idea as a fork of bitcoind, or as layer
between the standard bitcoind and the mining equipment. In the future it
could be incorporated in the bitcoin core if and when that becomes a
priority, but that step would not make sense until it becomes a priority.
There are a lot of nuances in this idea, and the first reaction is quite
probably that this is a crazy idea. We have attempted to address the most
important nuances in our proposal, which is currently at v.0.2.
We cannot guarantee that there are no =E2=80=98hidden devils in the details=
=E2=80=99 and we
invite you to be critical in a friendly and constructive manner. We will do
our best to answer all questions that arise.
The =E2=80=98official=E2=80=99 proposal is at:
PDF: http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.pdf
HTML: http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.html
-- Arnoud Kouwenhoven
--001a113d468e1d5e86051c951e90
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello all.<br><br>We=E2=80=99d like to share an idea we ha=
ve to dramatically increase the bitcoin block propagation speed after a new=
block has been mined for the first time.<br><br>Efficient bitcoin block pr=
opagation<br>A proposed solution to provide near-instantaneous block propag=
ation on the bitcoin network, even with slow network connections or large b=
lock sizes. Increasing mining efficiency for everyone while decreasing tran=
saction confirmation times and strengthening the distributed nature of bitc=
oin.<br><br>Short summary: we propose to introduce bitcoin-backed guarantee=
s (=E2=80=9CGuarantee Messages=E2=80=9D) between miners. This would allow m=
iners to mine on blocks that are not yet fully transmitted. This reduces th=
e effect of slow internet connections, leveling the playing field between t=
he 1st world fiberoptic datacenter miners and the rest of the world. We als=
o believe it strengthens the bitcoin network by using existing processing p=
ower that is currently wasted into further securing the blockchain, and it =
reduces the likelihood of transactions becoming confirmed, then unconfirmed=
and then -hopefully- confirmed again (due to different miners finding comp=
eting blocks with different transactions at approx the same time).<br><br>I=
t is possible to implement our idea as a fork of bitcoind, or as layer betw=
een the standard bitcoind and the mining equipment. In the future it could =
be incorporated in the bitcoin core if and when that becomes a priority, bu=
t that step would not make sense until it becomes a priority.<br><br>There =
are a lot of nuances in this idea, and the first reaction is quite probably=
that this is a crazy idea. We have attempted to address the most important=
nuances in our proposal, which is currently at v.0.2.<br><br>We cannot gua=
rantee that there are no =E2=80=98hidden devils in the details=E2=80=99 and=
we invite you to be critical in a friendly and constructive manner. We wil=
l do our best to answer all questions that arise.<br><br>The =E2=80=98offic=
ial=E2=80=99 proposal is at:<br>PDF: <a href=3D"http://pukaki.bz/efficient-=
bitcoin-block-propagation-v.0.2.pdf">http://pukaki.bz/efficient-bitcoin-blo=
ck-propagation-v.0.2.pdf</a><br>HTML: <a href=3D"http://pukaki.bz/efficient=
-bitcoin-block-propagation-v.0.2.html">http://pukaki.bz/efficient-bitcoin-b=
lock-propagation-v.0.2.html</a><br><div><br></div><div>-- Arnoud Kouwenhove=
n</div></div>
--001a113d468e1d5e86051c951e90--
|
