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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VhRXY-0006V4-U2
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 22:07:00 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.113 as permitted sender)
client-ip=62.13.149.113; envelope-from=pete@petertodd.org;
helo=outmail149113.authsmtp.com;
Received: from outmail149113.authsmtp.com ([62.13.149.113])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VhRXX-0000uV-2Z for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 22:07:00 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt5.authsmtp.com (8.14.2/8.14.2) with ESMTP id rAFM6qam061346;
Fri, 15 Nov 2013 22:06:52 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 rAFM6nrE074900
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 15 Nov 2013 22:06:51 GMT
Date: Fri, 15 Nov 2013 17:06:48 -0500
From: Peter Todd <pete@petertodd.org>
To: Mark Friedenbach <mark@monetize.io>
Message-ID: <20131115220648.GA30456@petertodd.org>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
<20131104115314.GA1013@savin>
<CANEZrP1uqee1UO=zb+50t9BNtv2voTHoCKQCTQExNyoL=Y0=PA@mail.gmail.com>
<20131104181649.GA3847@petertodd.org>
<5277F166.9090606@monetize.io>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7"
Content-Disposition: inline
In-Reply-To: <5277F166.9090606@monetize.io>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 3b65e55a-4e42-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwcUFloCAgsB AmUbWVZeUFt7XGE7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQ213 exhAEGxycAFPeH4+ ZEdjVncVXxZ8cBN4
Rx9JETgCZ3phaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNTk5 QhEeATQpEgUZQG0+
PwA8IxYWGEEaMQ0+ OEcoHltQORIOFgBE fQlIDTVWKhwERiwm
RRhGVEgSGSdRKQAA
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.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
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]
X-Headers-End: 1VhRXX-0000uV-2Z
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [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: Fri, 15 Nov 2013 22:07:01 -0000
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 04, 2013 at 11:11:34AM -0800, Mark Friedenbach wrote:
> > 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.
>=20
> You mean... an authenticated prefix tree? Composable/commutative
> properties are not needed as far as I can see, so you could make the
> path validation, traversal, and proof size smaller by using level
> compression.
You don't need level compression if you adopt my per-block randomization
idea. I think we'd be better off keeping the proofs as simple as
possible, just dumb merkle paths.
> I had previously proposed to this list a hash256-to-UUID mechanism
> explicitly for this purpose. Recap: use 122 of the low 128 bits of the
> aux-chain's genesis block to form a version=3D4 (random) or version=3D6
> (previously unused) UUID. However since making that proposal I am now
> leaning towards simply using the hash of the genesis block directly to
> identify aux chains since level compression will allow longer keys
> with the same path length.
I mentioned UUID more in spirit than in terms of the official UUID
standard; any large randomly picked integer is fine.
> If there is general interest, I can make finishing this a higher priority.
Wouldn't hurt to run the idea past forrestv, given p2pool will be
affected as it'd need to adopt the standard. He's run into some oddness
with mining hardware and nonces that would be good to understand. (note
how p2pool blocks don't commit to a fully random hash - there's some
extra bytes in there due to stratum or something IIRC)
--=20
'peter'[:-1]@petertodd.org
000000000000000601a5b2f2b4a597851fdf00f6fc3572bbc03f26857c170032
--1yeeQ81UyVL57Vl7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJShpr4AAoJEBmcgzuo5/CF28AIAJgCYIqmvnPTDkkzhEJnIeSP
5uB7vrLYYW26TUV5BBh0J6ssbVy4vcmQ2Weyyzil6pA1WeIajulNHipD1QDjQpCd
1mdfKwP56uWxllkfo9+EH4U+Z3GD+a9HGEF8QyLPIW5L1DqjzF1t0m5EbJRfqp4E
NQeXhPSjnjgVTiWSWxCCOOS4gwU/JpX3e7PfQhnq7BZbLz6dxz0CWC4IIbFS9wSM
FVGrvcO/u8arws46403y/mM+Nxg/kDe3Iw0ZD2eTadjUX2z7tqHHJcy1SNMUs/D4
opcBN2k0Q//ZsETlYynIFF9HDHUitP1aiQGSvawFEDOUNtowpSxhHnN1f7PHqi0=
=RXaS
-----END PGP SIGNATURE-----
--1yeeQ81UyVL57Vl7--
|
