summaryrefslogtreecommitdiff
path: root/39/4400d65c668025b2fe8f0ff8d9474c3f2ef8ad
blob: e944d8a60108510f071bbd3e523a58c6f5409e52 (plain)
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
134
135
136
137
138
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C25119C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Aug 2015 19:27:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF9D612A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Aug 2015 19:27:28 +0000 (UTC)
Received: from [100.174.56.104] (unknown [172.56.6.127])
	by mail.bluematt.me (Postfix) with ESMTPSA id AA7654002D;
	Wed,  5 Aug 2015 19:27:26 +0000 (UTC)
In-Reply-To: <CALwsPgnnkbfUBhL=Qyspz13pnZ-6RHdaZOGvfLG34JjJRgt2Dw@mail.gmail.com>
References: <CALwsPgnnkbfUBhL=Qyspz13pnZ-6RHdaZOGvfLG34JjJRgt2Dw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----YAFYG2SPCM894MDK1IP4P60M9EBJKW"
Content-Transfer-Encoding: 8bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Date: Wed, 05 Aug 2015 19:27:22 +0000
To: Arnoud Kouwenhoven - Pukaki Corp <arnoud@pukaki.bz>,
	Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev
	<bitcoin-dev@lists.linuxfoundation.org>,
	bitcoin-dev@lists.linuxfoundation.org
Message-ID: <B3546CB9-6A24-474C-8B56-9B1E2D33B470@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Re: [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:27:29 -0000

------YAFYG2SPCM894MDK1IP4P60M9EBJKW
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

See-also: Bitcoinrelaynetwork.org. It's already in use my the majority of large miners, is publicly available to anyone, and the protocol is rather simple and the client could be tweaked easily to keep exactly it's block ready to quickly relay to the nearest server (ie only have to relay the header, the coinbase transaction, and only small other data... Experience shows this is really easy to fit into one packet on the wire). It's not nearly as complicated as your suggestion, but may still marginally favor well-connected miners, but hopefully not much (when you're taking about single packets, it should all be latency, and the servers are well distributed). If you feel so inclined, there are some todos to make it really meet is efficiency limits filled on github.com/TheBlueMatt/RelayNode, feel free to rewrite the protocol if you really want :).

Matt

On August 5, 2015 9:07:44 PM GMT+02:00, Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Hello all.
>
>We’d like to share an idea we have to dramatically increase the bitcoin
>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
>(“Guarantee Messages”) between miners. This would allow miners 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 ‘hidden devils in the details’
>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 ‘official’ 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
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

------YAFYG2SPCM894MDK1IP4P60M9EBJKW
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

<html><head></head><body>See-also: <a href="http://Bitcoinrelaynetwork.org">Bitcoinrelaynetwork.org</a>. It&#39;s already in use my the majority of large miners, is publicly available to anyone, and the protocol is rather simple and the client could be tweaked easily to keep exactly it&#39;s block ready to quickly relay to the nearest server (ie only have to relay the header, the coinbase transaction, and only small other data... Experience shows this is really easy to fit into one packet on the wire). It&#39;s not nearly as complicated as your suggestion, but may still marginally favor well-connected miners, but hopefully not much (when you&#39;re taking about single packets, it should all be latency, and the servers are well distributed). If you feel so inclined, there are some todos to make it really meet is efficiency limits filled on <a href="http://github.com/TheBlueMatt/RelayNode">github.com/TheBlueMatt/RelayNode</a>, feel free to rewrite the protocol if you really wan
 t
:).<br>
<br>
Matt<br><br><div class="gmail_quote">On August 5, 2015 9:07:44 PM GMT+02:00, Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr">Hello all.<br /><br />We’d like to share an idea we have to dramatically increase the bitcoin block propagation speed after a new block has been mined for the first time.<br /><br />Efficient bitcoin block propagation<br />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.<br /><br />Short summary: we propose to introduce bitcoin-backed guarantees (“Guarantee Messages”) between miners. This would allow miners 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 currentl
 y
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).<br /><br />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.<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 guarantee that there are no ‘hidden devils in the details’ and we invite you to be critical in a friendly and constructive manner. We will do our best to answer all questions 
 that
arise.<br /><br />The ‘official’ proposal is at:<br />PDF: <a href="http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.pdf">http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.pdf</a><br />HTML: <a href="http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.html">http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.html</a><br /><div><br /></div><div>-- Arnoud Kouwenhoven</div></div>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /></pre></blockquote></div></body></html>
------YAFYG2SPCM894MDK1IP4P60M9EBJKW--