MIME-Version: 1.0
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
Subject: [bitcoin-dev] Idea: Efficient bitcoin block propagation
Precedence: list

--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--