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
|
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 <pete@petertodd.org>) id 1VdOi1-0006S3-OI
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 18:17:05 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.109 as permitted sender)
client-ip=62.13.148.109; envelope-from=pete@petertodd.org;
helo=outmail148109.authsmtp.co.uk;
Received: from outmail148109.authsmtp.co.uk ([62.13.148.109])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VdOi0-0007Bm-GP for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 18:17:05 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt12.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4IGwME098692;
Mon, 4 Nov 2013 18:16:58 GMT
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA4IGnDi050404
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 4 Nov 2013 18:16:52 GMT
Date: Mon, 4 Nov 2013 13:16:49 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20131104181649.GA3847@petertodd.org>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
<20131104115314.GA1013@savin>
<CANEZrP1uqee1UO=zb+50t9BNtv2voTHoCKQCTQExNyoL=Y0=PA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q"
Content-Disposition: inline
In-Reply-To: <CANEZrP1uqee1UO=zb+50t9BNtv2voTHoCKQCTQExNyoL=Y0=PA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 47bc4754-457d-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgYUFloCAgsB AmUbWlxeUVt7XGE7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQ20F f2lAJkBycgVCeHo+ ZEVgXXAVWEMoJkJ6
R0pJEWgBMXphaTUc TRJQdwFJcANIexZF O1F6ACIKLw51Pz4z
GA41ejw8IzhbLzxQ TwcRGBo5RkMOHyIg RhYNVSkoVUAVWz86
ZxYiLVUfVEoYLkx1 OBMrVE4EPgVwQghT BU5ARSpYIVRJXDYi Cw9TR0J2
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: petertodd.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1VdOi0-0007Bm-GP
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Committing to extra block data/a better
merge-mine standard
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: Mon, 04 Nov 2013 18:17:05 -0000
--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 04, 2013 at 01:00:16PM +0100, Mike Hearn wrote:
> Given that IP address data is inherently transient, perhaps a better
> solution is to define a short hash in the coinbase that commits to extra
> data that is relayed along with block data (e.g. appended to the block
> message). It can then be stored temporarily in the block db and erased
> after some time, like a few months. It would therefore not really be a pa=
rt
> of the chain, but could be extended as we see fit with any other
> semi-transient data required. A new "getextra" message would let nodes
> query for it.
>=20
> The hash can be short because it doesn't have to survive brute forcing
> attacks longer than the expected validity period of the transient data
> anyway. 80 bits would probably be overkill.
No sense in compromising - you need a whole merkle path to prove the
extra data is valid so you might as well make this a full 256 bits;
another 22 bytes is insignificant compared to the size of the path.
Again, the right way to do this is define the standard to use the last
txout so that midstate compression can be applied in the future. We can
re-use this for merge-mining and other commitments easily by defining a
simple standard based on defined path directions. Essentially for each
thing you might want to commit, perhaps a merge-mined coin, a p2pool
share, a UTXO commitment, whatever, generate a random 128-bit UUID.
Now interpret the bits of that UUID as an allowed path: 0 =3D left, 1 =3D
right, from the top of the tree. When you build the tree, make sure
everything that is going to be committed to uses it's allowed path; the
tree will look a bit jagged. If everyone picks their per-purpose UUIDs
randomly the paths won't collide for very many levels on average, and
path lengths will remain short. Validating that some given data was
committed properly is simple and easy: just check the path, and check
that the directions from the top of the tree followed the spec.
For timestamping, just pick any empty spot in the tree.
You'll want to put some "reasonable" limit on actual path lengths, just
pick something like 32 levels; if applications pick their UUIDs honestly
a collision will be very unlikely. You can also make the allowed paths
block specific by defining them as H(uuid | nonce), with nonce as an
optional PUSHDATA just prior to the commitment pushdata, allowing overly
long paths to be eliminated entirely by simply incrmenting the nonce.
Unlike the original, broken, merge-mining standard alt-coins have used
this actually works, extends indefinitely, and is simple and easy to
validate given a single merkle-path for each purpose. Generating the
trees of commitments is a bit convoluted, but at least that code only
needs to be written once.
--=20
'peter'[:-1]@petertodd.org
0000000000000002c43b3c05c0ed0842317747f0d1e3982489d0a51e7c8a05a3
--ikeVEW9yuYc//A+q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSd+SRAAoJEBmcgzuo5/CFSscH+wc9zHQuD6ni4GHwsZ4XSaO7
LgTengnQsHdAdQjqpPYGuI3bu7c+psjhAl5PVAGZiq36ygq93iu/gYhEvZCv97uA
YSyi5W3OHyjFZCGATivhNoKY09Wsx2+wK2BXc5XZ7fsBsOkpl0xUFnH4w+ui/yAQ
5j95oUASWXcrWYBe16FDztzfRt4MVbrp0tCo4yh84HQpmEpGEHyVj22j1z1cx02j
gdUENZ2lEdkZ3kIEgawN5jtbnqkYyq7tdw97NGiHQtIWxU3cEjNQbrqxidOsaBV6
/KwET/Idu2ka2ViEuj5DRAIsmnTg4IwZgfNkcCs6Bmkji9JM3QQtvYpAlzgQSIA=
=clfn
-----END PGP SIGNATURE-----
--ikeVEW9yuYc//A+q--
|
