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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1XZRXm-0004l6-4X
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Oct 2014 21:34:42 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.170 as permitted sender)
client-ip=209.85.160.170; envelope-from=gavinandresen@gmail.com;
helo=mail-yk0-f170.google.com;
Received: from mail-yk0-f170.google.com ([209.85.160.170])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XZRXk-0006Za-88
for bitcoin-development@lists.sourceforge.net;
Wed, 01 Oct 2014 21:34:42 +0000
Received: by mail-yk0-f170.google.com with SMTP id 20so419705yks.29
for <bitcoin-development@lists.sourceforge.net>;
Wed, 01 Oct 2014 14:34:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.101.138 with SMTP id b10mr75013524yhg.91.1412199273681;
Wed, 01 Oct 2014 14:34:33 -0700 (PDT)
Received: by 10.170.188.23 with HTTP; Wed, 1 Oct 2014 14:34:33 -0700 (PDT)
In-Reply-To: <542C6C61.30301@gmail.com>
References: <20141001130826.GM28710@savin.petertodd.org>
<201410011823.56441.luke@dashjr.org>
<CABsx9T1xC_1GzquEKBH3TQscZoo3EjXyQFR3FF6BXufjduL_JA@mail.gmail.com>
<542C6C61.30301@gmail.com>
Date: Wed, 1 Oct 2014 17:34:33 -0400
Message-ID: <CABsx9T1Wh1ypQ-RCkAh+1qEw7QvBnuPja1teJ6xq9F_gQHAGOA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: multipart/alternative; boundary=20cf301b606f0f586e050463449a
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
(gavinandresen[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: 1XZRXk-0006Za-88
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent
a txout from being spent until an expiration time
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: Wed, 01 Oct 2014 21:34:42 -0000
--20cf301b606f0f586e050463449a
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> On 10/01/2014 04:58 PM, Gavin Andresen wrote:
> > If the first transaction is P2SH, then the miner won't know there is
> > an advantage to holding it until it is too late (the scriptPubKey is
> > an opaque hash until the second transaction is final and
> > relayed/broadcast).
>
> If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH
> defeat the purpose of it?
>
No, the burner would supply the funding transaction plus the redeeming
script as the proof-of-burn to whoever needed the proof.
Only after at least one confirmation, if there was some risk that revealing
the redeeming script would make miners refuse to mine that first
transaction because they want to get it plus the CHECKTIMELOCKVERIFY "burn"
transaction.
--
--
Gavin Andresen
--20cf301b606f0f586e050463449a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Oct 1, 2014 at 5:04 PM, Alan Reiner <span dir=3D"ltr"><<a href=3D"ma=
ilto:etotheipi@gmail.com" target=3D"_blank">etotheipi@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 10/01/2014=
04:58 PM, Gavin Andresen wrote:<br>
> If the first transaction is P2SH, then the miner won't know there =
is<br>
> an advantage to holding it until it is too late (the scriptPubKey is<b=
r>
> an opaque hash until the second transaction is final and<br>
> relayed/broadcast).<br>
<br>
</span>If you're doing some kind of proof-of-burn scheme, wouldn't =
using P2SH<br>
defeat the purpose of it?<br>
<div class=3D"HOEnZb"><div class=3D"h5"></div></div></blockquote></div><div=
><br></div><div>No, the burner would supply the funding transaction plus th=
e redeeming script as the proof-of-burn to whoever needed the proof.</div><=
div><br></div><div>Only after at least one confirmation, if there was some =
risk that revealing the redeeming script would make miners refuse to mine t=
hat first transaction because they want to get it plus the CHECKTIMELOCKVER=
IFY "burn" transaction.</div><div><br></div>-- <br>--<br>Gavin An=
dresen<br>
</div><div class=3D"gmail_extra"><br></div></div>
--20cf301b606f0f586e050463449a--
|
