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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephencalebmorse@gmail.com>) id 1Yzmtp-0003Vf-1X
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Jun 2015 14:10:37 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.50 as permitted sender)
client-ip=209.85.213.50;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-yh0-f50.google.com;
Received: from mail-yh0-f50.google.com ([209.85.213.50])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yzmto-0000N9-BM
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Jun 2015 14:10:37 +0000
Received: by yhom41 with SMTP id m41so41555801yho.1
for <bitcoin-development@lists.sourceforge.net>;
Tue, 02 Jun 2015 07:10:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.170.128.139 with SMTP id u133mr32833271ykb.49.1433254230469;
Tue, 02 Jun 2015 07:10:30 -0700 (PDT)
Received: by 10.13.245.70 with HTTP; Tue, 2 Jun 2015 07:10:30 -0700 (PDT)
In-Reply-To: <CALqxMTFkWOfWXOnVAnZESkVWHtbZLc=T_sQDoTofr66mcb6_gQ@mail.gmail.com>
References: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com>
<CABHVRKQD4YPt0NA8VnXW4VYx0fmCgSHUYq-73F2esHZqX-FUxw@mail.gmail.com>
<CAOG=w-tDdJTkkqGaEEpDZ6pX0kXT7f2wvoN_cEpd6+MVnu1CdQ@mail.gmail.com>
<E67A3D18-EFB0-4156-98B7-082793D2D871@gmail.com>
<CALqxMTFkWOfWXOnVAnZESkVWHtbZLc=T_sQDoTofr66mcb6_gQ@mail.gmail.com>
Date: Tue, 2 Jun 2015 10:10:30 -0400
Message-ID: <CABHVRKRympU4LAeD7xG9bX3PvWMNcJaa1RMff+fukn0wSRr81A@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a11395ece47b21005178981c0
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
(stephencalebmorse[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: 1Yzmto-0000N9-BM
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP draft] Consensus-enforced
transaction replacement signalled via sequence numbers
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: Tue, 02 Jun 2015 14:10:37 -0000
--001a11395ece47b21005178981c0
Content-Type: text/plain; charset=UTF-8
>
> That would also introduce the anomaly of a script that was once valid
> becoming later invalid, when nothing varies other than time. That is
> not super compatible with the current model of reprocessing
> transactions in later blocks if the block they were first in gets
> reorged.
>
Very good point.
>
> (Not a huge flexibility loss as you can implement "not after" by
> making it the previous holders responsibility to spend a "not before"
> back to themselves.)
>
Do you mean something like the below?
scriptPubKey:
IF
{A's pub} CHECKSIGVERIFY
ELSE
{curr_height + 100} CLTV {B's pub} CHECKSIGVERIFY
This ensures that Alice has to spend the output in the next 100 blocks or
risk it being taken from her (she just has to put an OP_TRUE on the end of
her scriptSig). So, it seems we can forget about an inverted CLTV/CSV,
great!
Best,
Stephen
--001a11395ece47b21005178981c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">That would also introduce the anomaly of a script that was onc=
e valid<br>
becoming later invalid, when nothing varies other than time.=C2=A0 That is<=
br>
not super compatible with the current model of reprocessing<br>
transactions in later blocks if the block they were first in gets<br>
reorged.<br></blockquote><div><br></div><div>Very good point.=C2=A0</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
<br>
(Not a huge flexibility loss as you can implement "not after" by<=
br>
making it the previous holders responsibility to spend a "not before&q=
uot;<br>
back to themselves.)<br></blockquote><div><br></div><div>Do you mean someth=
ing like the below?</div><div><br></div><div><font face=3D"monospace, monos=
pace">scriptPubKey:</font><span style=3D"font-family:monospace,monospace">=
=C2=A0</span></div><div><font face=3D"monospace, monospace">=C2=A0 IF=C2=A0=
</font></div><div><span style=3D"font-family:monospace,monospace">=C2=A0 =
=C2=A0 {A's pub} CHECKSIGVERIFY</span></div><div><font face=3D"monospac=
e, monospace">=C2=A0 ELSE</font></div><div><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 {curr_height + 100} CLTV {B's pub} CHECKSIGVERIFY</fo=
nt></div><div><br></div><div>This ensures that Alice has to spend the outpu=
t in the next 100 blocks or risk it being taken from her (she just has to p=
ut an OP_TRUE on the end of her scriptSig). So, it seems we can forget abou=
t an inverted CLTV/CSV, great!</div><div><br></div><div>Best,<br>Stephen</d=
iv><div><br></div><div><br></div></div></div></div>
--001a11395ece47b21005178981c0--
|
