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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WRHZl-0006hF-5s
for bitcoin-development@lists.sourceforge.net;
Sat, 22 Mar 2014 08:46:45 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.100 as permitted sender)
client-ip=62.13.148.100; envelope-from=pete@petertodd.org;
helo=outmail148100.authsmtp.co.uk;
Received: from outmail148100.authsmtp.co.uk ([62.13.148.100])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WRHZj-00064U-Mr for bitcoin-development@lists.sourceforge.net;
Sat, 22 Mar 2014 08:46:45 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2M8kbuo005581
for <bitcoin-development@lists.sourceforge.net>;
Sat, 22 Mar 2014 08:46:37 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2M8kYl1027429
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Sat, 22 Mar 2014 08:46:36 GMT
Date: Sat, 22 Mar 2014 04:47:02 -0400
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20140322084702.GA13436@savin>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 7a735fa9-b19e-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQd1
LRkLXVBSFQF4ARQL AhgUUR88cANYeX5u ZEFqQHFbVVt/fUFi
QwAXFxAOPg48aWAd V0Rafk1VcQRLflFC O1d8USVcaHhVZ3M1
WlZqMmt0N2UHcmEN GltQfAobGBsHF2Eq ZxkEETEuG0JNQiQ1
IgZuI1IbBFoQNUN6 PkEoUl8WLhsWG0VQ GFsFDSpTKlUNSiZj
BgRcRkMYCyBGCTxN GQElJwQqSiJTU2JU A1ZPTxxKEDtIViVJ
TjkaSCA1CFEiKgcg I2ERPAxZ
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/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
X-Headers-End: 1WRHZj-00064U-Mr
Subject: [Bitcoin-development] Handling miner adoption gracefully for
embedded consensus systems via double-spending/replace-by-fee
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: Sat, 22 Mar 2014 08:46:45 -0000
--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
There's been a lot of recent hoopla over proof-of-publication, with the
OP_RETURN <data> length getting reduced to a rather useless 40 bytes at
the last minute prior to the 0.9 release. Secondly I noticed a
overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken
into account, making it possible to broadcast unminable transactions and
bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG
outputs given that the sigops limit and the way they use up a fixed 20
sigops per op makes them hard to do fee calculations for. They also make
it easy to bloat the UTXO set, potentially a bad thing. This would of
course require things using them to change. Currently that's just
Counterparty, so I gave them the heads up in my email.
To make a long story short, it was soon suggested that Bitcoin Core be
forked - the software, not the protocol - and miners encouraged to
support it. This isn't actually as trivial as it sounds, as you need to
add some anti-DoS stuff to deal with the fact that the hashing power
mining the transations you are relaying may be quite small. The second
issue is you need to add preferential peering, so the nodes in the
network with a broader idea of what is a "allowed" transaction can find
each other. (likely with a new service flag) It'd be a good time to
implement replace-by-fee, partly for its anti-DoS properties.
Which leaves us with a practical question: How do you gracefully handle
a switchover? First of all I suggest that proof-of-publication
applications adopt format flexibility, similar to how Mastercoin can
encode its data in pay-to-pubkeyhash, bare multisig, or op_return
outputs. Given the possibility of bare multisig going away, I'd suggest
that P2SH multisig scriptSig encoding be added as well. Note that a
really good implementation of all this is actually format agnostic, and
will let PUSHDATA's used for encoding data be specified arbitrarily. I
wrote up some code to do so awhile back as an experiment. It used the
LSB's of the nValue field in the txouts to specify what was and wasn't
data, along with some stenographic encryption of data and nValue. I'd be
happy to dig that up if anyone is interested.
All these methods have some overhead compared to just using OP_RETURN
and thus cost more. So I suggest you have your software simultaneously
double-spend the inputs to any proof-of-publication transaction with a
second transaction that just makes use of efficient OP_RETURN. That
second one can go to more enlightened miners. Only one or the other will
get mined of course and the cost to publish data will be proportional to
the relative % of hashing power in the two camps.
Finally I'll be writing something more detailed soon about why
proof-of-publication is essential and miners would be smart to support
it. But the tl;dr: of it is if you need proof-of-publication for what
your system does you're much more secure if you're embedded within
Bitcoin rather than alongside of it. There's a lot of very bad advise
getting thrown around lately for things like Mastercoin, Counterparty,
and for that matter, Colored Coins, to use a separate PoW blockchain or
a merge-mined one. The fact is if you go with pure PoW, you risk getting
attacked while your still growing, and if you go for merge-mined PoW,
the attacker can do so for free. We've got a real-world example of the
former with Twister, among many others, usually resulting in a switch to
a centralized checkpointing scheme. For the latter we have Coiledcoin,
an alt that made the mistake of using SHA256 merge-mining and got killed
off early at birth with a zero-cost 51% attack. There is of course a
censorship risk to going the embedded route, but at least we know that
for the forseeable future doing so will require explicit blacklists,
something most people here are against.
To MSC, XCP and others: Now I'm not going to say you shouldn't take
advice from people who call your finance 2.0 systems scams, or maybe if
they're nice, indistinguishable from a scam. But when you do, you should
think for yourself before just trusting that some authority figure has
your best interests in mind.
1) Yes, this was responsibly disclosed to the security mailing list. It
was revealed to the public a few hours later on the -dev IRC channel
without a fix.
--=20
'peter'[:-1]@petertodd.org
00000000000000009065ab15f4a036e9ec13d2e788e0ede69472e0ec396b097f
--Qxx1br4bt0+wmkIi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTLU3/XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA4MTJjNzU2ZGJhNmJkYmYyODQwMTU0NjNhNzYzMGFiNWU0
ODA1NmQ0MmFlZTAyNjkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuO3AgAnM7TALoodJuOPh4x1Xm8hYYS
fjak1he1YQTahPnxJEO/Pt2ol0kr6nP6qFsDi2Ty+tQg+C7vj7HMvgj7nkOC/oas
+3eCCrFi/bXGbiPs6o+8nFXWJpCqj8WUc//PjsH/zRYkp2OGHP1/DStjHCqFnVO8
lozIC18bNgspGLkBFoPEYmqPrQ+GwCF7mK+JsjA9KBJcuwTySX/RtEyxE1YXVcGb
5H0nftMznw74UxZiy7+B5HGWmrbmBLpgmn05W3fzG1QU45LLEMLeq8p9TJ39qZYv
BKyirOrxHzyrHrXNnZgfgQibrc+0CQR4euVyCvStXLbuiCNdbkq4fuL+W1WREA==
=dONs
-----END PGP SIGNATURE-----
--Qxx1br4bt0+wmkIi--
|
