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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 19F2F1124
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2015 15:41:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149080.authsmtp.com (outmail149080.authsmtp.com
[62.13.149.80])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 363FA10D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2015 15:41:52 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBNFfpPr081267
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2015 15:41:51 GMT
Received: from muck ([72.143.224.85]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBNFficL004100
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2015 15:41:48 GMT
Date: Wed, 23 Dec 2015 07:41:43 -0800
From: Peter Todd <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20151223154143.GA2295@muck>
References: <20151223013119.GA31113@muck>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
In-Reply-To: <20151223013119.GA31113@muck>
X-Server-Quench: adf6c0ef-a98b-11e5-bcde-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktfYVU6ClZ1
UkhIR0JTEQ9sABYF DlAZUAdzcwZYenx0 e05nQXVTW1t7OwIP
PDgCTD56ZWdkaWAf HkNfcAoaIVcceExF PwZiBXoFM3gGZy9l
WgU4Mz10ZW0GdX0K HAoEdANCV3wGTHYP TREeFjIuGwgJSjsG
ZycrJUQRE08NP0l6 Llo9X18DKBIJQgRY EwlTCStYK1AdRi0t
CQ5BRgYbETtcRyg0
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 72.143.224.85/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] Segregated witnesses and validationless mining
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 Dec 2015 15:41:54 -0000
--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 22, 2015 at 05:31:19PM -0800, Peter Todd via bitcoin-dev wrote:
> # Easy solution: previous witness data proof
>=20
> To return segregated witnesses to the status quo, we need to at least
> make having the previous block's witness data be a precondition to
> creating a block with transactions; ideally we would make it a
> precondition to making any valid block, although going this far may
> receive pushback from miners who are currently using validationless
> mining techniques.
>=20
> We can require blocks to include the previous witness data, hashed with
> a different hash function that the commitment in the previous block.
> With witness data W, and H(W) the witness commitment in the previous
> block, require the current block to include H'(W)
>=20
> A possible concrete implementation would be to compute the hash of the
> current block's coinbase txouts (unique per miner for obvious reasons!)
> as well as the previous block hash. Then recompute the previous block's
> witness data merkle tree (and optionally, transaction data merkle tree)
> with that hash prepended to the serialized data for each witness.
>=20
> This calculation can only be done by a trusted entity with access to all
> witness data from the previous block, forcing miners to both publish
> their witness data promptly, as well as at least obtain witness data
> from other miners. (if not actually validate it!) This returns us to at
> least the status quo, if not slightly better.
>=20
> This solution is a soft-fork. As the calculation is only done once per
> block, it is *not* a change to the PoW algorithm and is thus compatible
> with existing miner/hasher setups. (modulo validationless mining
> optimizations, which are no longer possible)
Note that this fix can be designed to retain the possibility of
validationless mining, by allowing empty blocks to be created if the
previous witness data proof is omitted. This would achieve the same goal
as Gregory Maxwell's blockchain verification flag(1) but with
significantly less ability/reason to lie about the status of that flag.
1) [bitcoin-dev] Blockchain verification flag (BIP draft),
Gregory Maxwell, Dec 4th 2015,
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011=
853.html
--=20
'peter'[:-1]@petertodd.org
000000000000000002c7cfc8455339de54444ac9798cad32cbfbcda77e0f2b09
--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWesC0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMmM3Y2ZjODQ1NTMzOWRlNTQ0NDRhYzk3OThjYWQzMmNi
ZmJjZGE3N2UwZjJiMDkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwLDwf/QjiP+rqg5bW4XU924RHUt7sU
vl3REP5K6rVbwD07/XTPnTAZIrnGisRSsobqkVXDoeG8xchhO7pdQCsetrHNATv8
7tBV2UUncMfT3FjZwdvlYkLcuSYXIg5Sx8wVTqf2PQq5u4U11lHa9GLGGPE36ubw
ZsRz2YLVmeaWDCgCE/O40dAJrajmGjhWFx+U9kOkUkZq6s21LFhmdNCcjVr5ThzU
8GPJOReX5Q0wz1lgdJ5F4Ld5nbpXIiGlkQhFRWWCuwcSLeCfMfxo4lftpvSY5qk+
53eEB23cxPxhXEt89S6/uMaHT3I70LWYa3iRTG050N2/jy7JXGuhoXDwDq0Ulg==
=ijy+
-----END PGP SIGNATURE-----
--C7zPtVaVf+AK4Oqc--
|
