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
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1UjePX-0007ZA-Ad
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Jun 2013 23:43:35 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.172 as permitted sender)
client-ip=209.85.217.172; envelope-from=melvincarvalho@gmail.com;
helo=mail-lb0-f172.google.com;
Received: from mail-lb0-f172.google.com ([209.85.217.172])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UjePV-0000Pd-V6
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Jun 2013 23:43:35 +0000
Received: by mail-lb0-f172.google.com with SMTP id p10so29288lbi.31
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Jun 2013 16:43:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.202.35 with SMTP id kf3mr11866530lbc.122.1370303007219;
Mon, 03 Jun 2013 16:43:27 -0700 (PDT)
Received: by 10.112.20.231 with HTTP; Mon, 3 Jun 2013 16:43:27 -0700 (PDT)
In-Reply-To: <20130601193036.GA13873@savin>
References: <20130601193036.GA13873@savin>
Date: Tue, 4 Jun 2013 01:43:27 +0200
Message-ID: <CAKaEYh+9BZ5WdoyzFSRp+k3_R5TW2qBy+aihK2g_22DWYWgnTQ@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c377a2fae4a804de4887cf
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(melvincarvalho[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UjePV-0000Pd-V6
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: soft-fork to make
anyone-can-spend outputs unspendable for 100 blocks
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, 03 Jun 2013 23:43:35 -0000
--001a11c377a2fae4a804de4887cf
Content-Type: text/plain; charset=ISO-8859-1
On 1 June 2013 21:30, Peter Todd <pete@petertodd.org> wrote:
> Currently the most compact way (proof-size) to sacrifice Bitcoins that
> does not involve making them unspendable is to create a anyone-can-spend
> output as the last txout in the coinbase of a block:
>
> scriptPubKey: <data> OP_TRUE
>
> The proof is then the SHA256 midstate, the txout, and the merkle path to
> the block header. However this mechanism needs miner support, and it is
> not possible to pay for such a sacrifice securely, or create an
> assurance contract to create one.
>
Sorry if this is a stupid question, but why would someone want to sacrifice
their bitcoins?
>
> A anyone-can-spend in a regular txout is another option, but there is no
> way to prevent a miner from including a transaction spending that txout
> in the same block. Once that happens, there is no way to prove the miner
> didn't create both, thus invalidating the sacrifice. The announce-commit
> protocol solves that problem, but at the cost of a much larger proof,
> especially if multiple parties want to get together to pay the cost of
> the sacrifice. (the proof must include the entire tx used to make the
> sacrifice)
>
> However if we add a rule where txouts ending in OP_TRUE are unspendable
> for 100 blocks, similar to coinbases, we fix these problems. The rule
> can be done as a soft-fork with 95% support in the same way the
> blockheight rule was implemented. Along with that change
> anyone-can-spend outputs should be make IsStandard() so they will be
> relayed.
>
> The alternative is sacrifices to unspendable outputs, which is very
> undesirable compared to sending the money to miners to further
> strengthen the security of the network.
>
> We should always make it easy for people to write code that does what is
> best for Bitcoin.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a11c377a2fae4a804de4887cf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 1 June 2013 21:30, Peter Todd <span dir=3D"ltr"><<a href=3D"m=
ailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Currently the most compact way (proof-size) =
to sacrifice Bitcoins that<br>
does not involve making them unspendable is to create a anyone-can-spend<br=
>
output as the last txout in the coinbase of a block:<br>
<br>
scriptPubKey: <data> OP_TRUE<br>
<br>
The proof is then the SHA256 midstate, the txout, and the merkle path to<br=
>
the block header. However this mechanism needs miner support, and it is<br>
not possible to pay for such a sacrifice securely, or create an<br>
assurance contract to create one.<br></blockquote><div><br></div><div>Sorry=
if this is a stupid question, but why would someone want to sacrifice thei=
r bitcoins?<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A anyone-can-spend in a regular txout is another option, but there is no<br=
>
way to prevent a miner from including a transaction spending that txout<br>
in the same block. Once that happens, there is no way to prove the miner<br=
>
didn't create both, thus invalidating the sacrifice. The announce-commi=
t<br>
protocol solves that problem, but at the cost of a much larger proof,<br>
especially if multiple parties want to get together to pay the cost of<br>
the sacrifice. (the proof must include the entire tx used to make the<br>
sacrifice)<br>
<br>
However if we add a rule where txouts ending in OP_TRUE are unspendable<br>
for 100 blocks, similar to coinbases, we fix these problems. The rule<br>
can be done as a soft-fork with 95% support in the same way the<br>
blockheight rule was implemented. Along with that change<br>
anyone-can-spend outputs should be make IsStandard() so they will be<br>
relayed.<br>
<br>
The alternative is sacrifices to unspendable outputs, which is very<br>
undesirable compared to sending the money to miners to further<br>
strengthen the security of the network.<br>
<br>
We should always make it easy for people to write code that does what is<br=
>
best for Bitcoin.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293<br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite<br>
It's a free troubleshooting tool designed for production<br>
Get down to code-level detail for bottlenecks, with <2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href=3D"http://p.sf.net/sfu/appdyn_d2d_ap2" target=3D"_blank">http://p.s=
f.net/sfu/appdyn_d2d_ap2</a><br>___________________________________________=
____<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>
--001a11c377a2fae4a804de4887cf--
|
