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
202
203
204
205
206
207
208
209
210
211
212
213
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Yqj3X-0004jU-V4
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 14:15:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.41 as permitted sender)
client-ip=209.85.192.41; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f41.google.com;
Received: from mail-qg0-f41.google.com ([209.85.192.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yqj3W-0006OO-TE
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 14:15:11 +0000
Received: by qgdy78 with SMTP id y78so36946900qgd.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 07:15:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.217.17 with SMTP id n17mr5372233qhb.69.1431094505515;
Fri, 08 May 2015 07:15:05 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Fri, 8 May 2015 07:15:05 -0700 (PDT)
In-Reply-To: <CAOoPuRZG4CVxcgExKHjDQd+F-w6xr6cJZD7pShbgPJd9CnqTwg@mail.gmail.com>
References: <CAE-z3OUiK_s-gJtnPquUZbG5aJkJjfo+VYKHgX+Bfcgem+6i9A@mail.gmail.com>
<CANEZrP2OXSmhLsfvpsQdr0QGbGyJWaAp1F0itu4V_C-E+0gO6A@mail.gmail.com>
<CAOoPuRZG4CVxcgExKHjDQd+F-w6xr6cJZD7pShbgPJd9CnqTwg@mail.gmail.com>
Date: Fri, 8 May 2015 15:15:05 +0100
Message-ID: <CAE-z3OV30-ds5=5Tm55n+B26sPz3P+iC2TNHTBUidbX=qu08nQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Benjamin <benjamin.l.cordes@gmail.com>
Content-Type: multipart/alternative; boundary=001a1139b816a43a33051592a7c1
X-Spam-Score: 0.2 (/)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.0 AC_DIV_BONANZA RAW: Too many divs in a row... spammy template
-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
0.8 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Yqj3W-0006OO-TE
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Assurance contracts to fund the network
with OP_CHECKLOCKTIMEVERIFY
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, 08 May 2015 14:15:12 -0000
--001a1139b816a43a33051592a7c1
Content-Type: text/plain; charset=UTF-8
Just to clarify the process.
Pledgers create transactions using the following template and broadcast
them. The p2p protocol could be modified to allow this, or it could be a
separate system.
*Input: 0.01 BTC*
*Signed with SIGHASH_ANYONE_CAN_PAY*
*Output 50BTC*
*Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE*
*Output 0.01BTC*
*Paid to OP_TRUE*
This transaction is invalid, since the inputs don't pay for the output.
The advantage of the sighash "anyone can pay" field is that other people
can add additional inputs without making the signature invalid. Normally,
any change to the transaction would make a signature invalid.
Eventually, enough other users have added pledges and a valid transaction
can be broadcast.
*Input: 0.01 BTC*
*Signed with SIGHASH_ANYONE_CAN_PAY*
*Input: 1.2 BTCSigned with SIGHASH_ANYONE_CAN_PAY*
*Input: 5 BTCSigned with SIGHASH_ANYONE_CAN_PAY*
*<etc>*
*Input: 1.3 BTCSigned with SIGHASH_ANYONE_CAN_PAYOutput 50BTC*
*Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY OP_TRUE*
*Output 0.01BTC**Paid to OP_TRUE*
This transaction can be submitted to the main network. Once it is included
into the blockchain, it is locked in.
In this example, it might be included in block 999,500. The 0.01BTC output
(and any excess over 50BTC) can be collected by the block 999,500 miner.
The OP_CHECKLOCKTIMEVERIFY opcode means that the 50BTC output cannot be
spent until block 1 million. Once block 1 million arrives, the output is
completely unprotected. This means that the miner who mines block 1
million can simply take it, by including his own transaction that sends it
to an address he controls. It would be irrational to include somebody
else's transaction which spent it.
If by block 999,900, the transaction hasn't been completed (due to not
enough pledgers), the pledgers can spend the coin(s) that they were going
to use for their pledge. This invalidates those inputs and effectively
withdraws from the pledge.
On Fri, May 8, 2015 at 11:01 AM, Benjamin <benjamin.l.cordes@gmail.com>
wrote:
> 2. "A merchant wants to cause block number 1 million to effectively
> have a minting fee of 50BTC." - why should he do that? That's the
> entire tragedy of the commons problem, no?
>
No, the pledger is saying that he will only pay 0.01BTC if the miner gets a
reward of 50BTC.
Imagine a group of 1000 people who want to make a donation of 50BTC to
something. They all way that they will donate 0.05BTC, but only if
everyone else donates.
It still isn't perfect. Everyone has an incentive to wait until the last
minute to pledge.
--001a1139b816a43a33051592a7c1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div><div>Just to clarify th=
e process.<br><br></div>Pledgers create transactions using the following te=
mplate and broadcast them.=C2=A0 The p2p protocol could be modified to allo=
w this, or it could be a separate system.<br><br></div><i>Input: 0.01 BTC<b=
r></i></div><i>Signed with SIGHASH_ANYONE_CAN_PAY<br><br></i></div><i>Outpu=
t 50BTC<br></i></div><i>Paid to: <1 million> OP_CHECKLOCKTIMEVERIFY O=
P_TRUE<br></i></div><i><br>Output 0.01BTC<br></i></div><i>Paid to OP_TRUE<b=
r></i><br></div><div>This transaction is invalid, since the inputs don'=
t pay for the output.=C2=A0 The advantage of the sighash "anyone can p=
ay" field is that other people can add additional inputs without makin=
g the signature invalid.=C2=A0 Normally, any change to the transaction woul=
d make a signature invalid.<br><br></div><div>Eventually, enough other user=
s have added pledges and a valid transaction can be broadcast.<br><br><i>In=
put: 0.01 BTC<br></i><i>Signed with SIGHASH_ANYONE_CAN_PAY<br><br></i><i><i=
>Input: 1.2 BTC<br></i><i>Signed with SIGHASH_ANYONE_CAN_PAY</i><br></i><i>=
<br><i>Input: 5 BTC<br></i><i>Signed with SIGHASH_ANYONE_CAN_PAY<br></i></i=
><i><i><br></i></i></div><div><i><i><etc><br></i></i></div><div><i><i=
><i><br><i>Input: 1.3 BTC<br></i><i>Signed with SIGHASH_ANYONE_CAN_PAY<br><=
br></i></i></i>Output 50BTC<br></i><i>Paid to: <1 million> OP_CHECKLO=
CKTIMEVERIFY OP_TRUE<br></i><i><br>Output 0.01BTC<br></i><i>Paid to OP_TRUE=
</i><br></div><div><div><div><div><div><div><div><div><div><div><div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This transaction =
can be submitted to the main network.=C2=A0 Once it is included into the bl=
ockchain, it is locked in.<br><br></div><div class=3D"gmail_extra">In this =
example, it might be included in block 999,500.=C2=A0 The 0.01BTC output (a=
nd any excess over 50BTC) can be collected by the block 999,500 miner.<br><=
br></div><div class=3D"gmail_extra">The OP_CHECKLOCKTIMEVERIFY opcode means=
that the 50BTC output cannot be spent until block 1 million.=C2=A0 Once bl=
ock 1 million arrives, the output is completely unprotected.=C2=A0 This mea=
ns that the miner who mines block 1 million can simply take it, by includin=
g his own transaction that sends it to an address he controls.=C2=A0 It wou=
ld be irrational to include somebody else's transaction which spent it.=
<br><br></div><div class=3D"gmail_extra">If by block 999,900, the transacti=
on hasn't been completed (due to not enough pledgers), the pledgers can=
spend the coin(s) that they were going to use for their pledge.=C2=A0 This=
invalidates those inputs and effectively withdraws from the pledge.</div><=
br><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri, May 8, 201=
5 at 11:01 AM, Benjamin <span dir=3D"ltr"><<a href=3D"mailto:benjamin.l.=
cordes@gmail.com" target=3D"_blank">benjamin.l.cordes@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. "A merchant wants to cause block number 1 million to effectively<br=
>
have a minting fee of 50BTC." - why should he do that? That's the<=
br>
entire tragedy of the commons problem, no?<br></blockquote><div><br></div><=
div>No, the pledger is saying that he will only pay 0.01BTC if the miner ge=
ts a reward of 50BTC.<br></div><div><br></div><div>Imagine a group of 1000 =
people who want to make a donation of 50BTC to something.=C2=A0 They all wa=
y that they will donate 0.05BTC, but only if everyone else donates.<br><br>=
</div><div>It still isn't perfect.=C2=A0 Everyone has an incentive to w=
ait until the last minute to pledge.<br></div></div></div></div></div></div=
></div></div></div></div></div></div></div></div></div>
--001a1139b816a43a33051592a7c1--
|
