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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C8ADBE19
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 22:27:16 +0000 (UTC)
X-Greylist: delayed 00:10:56 by SQLgrey-1.7.6
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4962822D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 22:27:16 +0000 (UTC)
Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197]
(may be forged)) (authenticated bits=0)
by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t8NMGGmu027616
(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Sep 2015 15:16:16 -0700
Content-Type: multipart/signed;
boundary="Apple-Mail=_8F7E48FB-76B5-4E3A-8393-005C0D45FB90";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Pgp-Agent: GPGMail 2.5.1
From: "Jonathan Toomim (Toomim Bros)" <j@toom.im>
In-Reply-To: <CABsx9T3NFRO5nw3z=jrs0Hu3caVNkkTTTb1ibqR7LMWsoou9RQ@mail.gmail.com>
Date: Wed, 23 Sep 2015 15:16:14 -0700
Message-Id: <03FF5567-DF6E-4242-B63F-D71D1E7E393F@toom.im>
References: <CABsx9T2+dG0AE+MgKRAU97KhkHTU1MuxXuwHKv3BgpJswZ5vVg@mail.gmail.com>
<CABaSBaxcDRzw0X7-fAfxPJyLcWxTHigpHuAPb4aNQ5zk5NoDCQ@mail.gmail.com>
<CAAS2fgTr-OuL3T6mXX-4xFC_LHnAiogTTcPMbcjsM7WtRisQEQ@mail.gmail.com>
<CABsx9T3NFRO5nw3z=jrs0Hu3caVNkkTTTb1ibqR7LMWsoou9RQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVZ0lR1oumHexThjCg19hXE0gCsZeQZ/6WFlqI57mmx6OImkRXg+AAP5HneNLaf/afT75flxh9fFExMkelZkHViW
X-Sonic-ID: C;GpAqtUBi5RGrleK7sH9FTg== M;GH+XtUBi5RGrleK7sH9FTg==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW 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] Weak block thoughts...
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, 23 Sep 2015 22:27:16 -0000
--Apple-Mail=_8F7E48FB-76B5-4E3A-8393-005C0D45FB90
Content-Type: multipart/alternative;
boundary="Apple-Mail=_3D6BF2E3-F3DA-415E-9F9D-DD8A3D151B0C"
--Apple-Mail=_3D6BF2E3-F3DA-415E-9F9D-DD8A3D151B0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Sep 23, 2015, at 2:37 PM, Gavin Andresen via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Take care, here-- if a scheme is used where e.g. the full solution had
> to be exactly identical to a prior weak block then the result would be
> making mining not progress free because bigger miners would have
> disproportionately more access to the weak/strong one/two punch. I
> think what you're thinking here is okay, but it wasn't clear to me if
> you'd caught that particular potential issue.
>=20
> I'm assuming the optimized protocol would be forward-error-coded (e.g. =
using IBLTs) and NOT require the full solution (or follow-on weak =
blocks) to be exactly the same.
>=20
One possible improvement on this is to cache Merkle nodes/subtrees. When =
a weak block is created, nodes could cache the hashes for the Merkle =
nodes along with each node's children. A miner could then describe their =
block in terms of Merkle nodes (describing groups of 2^n transactions), =
which would give them the ability to copy e.g. 87.5% or 96.875% or =
whatever of their new block from someone else's weak block but with a =
few modifications (e.g. new transactions) in the remaining =
non-prespecified portion. This gives small miners the ability to trade =
off versatility (do I specify all of the transactions with my own Merkle =
structure?) versus propagation speed (do I copy all of my Merkle tree =
from another miner's weak block?) with all steps in between.
I've got a proposal for a block propagation protocol inspired by =
bittorrent applied to the Merkle tree instead of chunks of a file. Weak =
blocks would fit in with this blocktorrent protocol quite nicely by =
caching and pre-transmitting Merkle nodes. I don't want to hijack this =
thread, so I'll post it under a separate subject in an hour or so.
--Apple-Mail=_3D6BF2E3-F3DA-415E-9F9D-DD8A3D151B0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div><br></div><div><div>On Sep 23, 2015, at 2:37 =
PM, Gavin Andresen via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><blockquote =
class=3D"gmail_quote" style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: =
0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex; position: =
static; z-index: auto;">Take care, here-- if a scheme is used where e.g. =
the full solution had<br>to be exactly identical to a prior weak block =
then the result would be<br>making mining not progress free because =
bigger miners would have<br>disproportionately more access to the =
weak/strong one/two punch. I<br>think what you're thinking here is okay, =
but it wasn't clear to me if<br>you'd caught that particular potential =
issue.<br></blockquote><div style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><br></div><div style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I'm =
assuming the optimized protocol would be forward-error-coded (e.g. using =
IBLTs) and NOT require the full solution (or follow-on weak =
blocks) to be exactly the same.</div><br =
class=3D"Apple-interchange-newline"></blockquote></div><br><div>One =
possible improvement on this is to cache Merkle nodes/subtrees. When a =
weak block is created, nodes could cache the hashes for the Merkle nodes =
along with each node's children. A miner could then describe their block =
in terms of Merkle nodes (describing groups of 2^n transactions), which =
would give them the ability to copy e.g. 87.5% or 96.875% or whatever of =
their new block from someone else's weak block but with a few =
modifications (e.g. new transactions) in the remaining non-prespecified =
portion. This gives small miners the ability to trade off versatility =
(do I specify all of the transactions with my own Merkle structure?) =
versus propagation speed (do I copy all of my Merkle tree from another =
miner's weak block?) with all steps in =
between.</div><div><br></div><div>I've got a proposal for a block =
propagation protocol inspired by bittorrent applied to the Merkle tree =
instead of chunks of a file. Weak blocks would fit in with this =
blocktorrent protocol quite nicely by caching and pre-transmitting =
Merkle nodes. I don't want to hijack this thread, so I'll post it under =
a separate subject in an hour or so.</div></body></html>=
--Apple-Mail=_3D6BF2E3-F3DA-415E-9F9D-DD8A3D151B0C--
--Apple-Mail=_8F7E48FB-76B5-4E3A-8393-005C0D45FB90
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWAySvAAoJEIEuMk4MG0P1i+oH/0+AFg6wc3vDcWz9DM1s8KOD
yUWb7YKd7taNe8jDB8Va4MXrrfRUk9ZDqnlAaeP94wd/nfETBVn2ZoMDS9NAXtPD
qjYwy3YTVoUfPK5yes4hztzk8i+mVPuuQ4jOjyhs+VMaoGws7nDscUQOkyogXdYr
FZZbfQM/AzTE7bCsk4dsGHxlifMbUYSzedThtzn1vZcoiqK0riV9w1UkHSN9Vw5f
Ix1kLE9iYHKuoe/XkpOFBZCpurE0raFjxmeoFQbODHMDlQ7W44+MBzoMDc8f3xz+
4UxSSb6zAgg3BMf2y0tK9Wwky74pLd+zgTLfnGkVi9bIS5N+eqGMbb98LCScXdI=
=ZVHr
-----END PGP SIGNATURE-----
--Apple-Mail=_8F7E48FB-76B5-4E3A-8393-005C0D45FB90--
|
