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
|
Return-Path: <papawnana4541@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 272F5BBD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Sep 2018 05:02:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com
[209.85.221.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 853EB8B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Sep 2018 05:02:31 +0000 (UTC)
Received: by mail-wr1-f49.google.com with SMTP id n2-v6so13571584wrw.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Sep 2018 22:02:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=FIZb8Y5LvraqH/38viDIKqGgEXBKBpSoxDMearZitWY=;
b=TtzrkIxWj9jydKbU0MUa1p5adDMWxpELKIxCwe14ACtAFcsoXVg2LXg3kA6pSZzwZ2
FGGPPSGRvWNsc3zZqiEKPRaw3WuP06gOdPCVJagBRhyeXXtM5bbk38z1/c0NYcnCMrX1
nbTfOkovnQhBvrE88e8xP1gYW4JNh0xEPqXgGwpG17HholErFpR7f7DYOG8ViXX/1pbM
6RFKpafNCLd/6KndS6+W5C4Vfybv5QoXmFGf/22+ksQyqjMZLPduVKlUBFPkd6rzn2p+
k/gC6aZ6rBZM6zl7ZprFYhVuyb6muXWw/eO2/C90mQmxjejDMCELheZ4pSc0GbR4Cmqb
/4iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=FIZb8Y5LvraqH/38viDIKqGgEXBKBpSoxDMearZitWY=;
b=BCeMqAK0DTvnOQWKoNETuEeyUTEj32dnzI/lK8T+/bCXSQAORox80Cs0034m8foNRv
cDr0ZOMp4XKUGJFBavgLpghsRz26FVfJf0fCwEU6XI1UdwfLPdBl4OJvobYK9hupig/k
f+2DEBTzl5kDEFEUamqA1SOkLasCQRlodc4p323sDK8rTqVcHyMnF2AAef2Nyd7Bx5r+
qQO9LSALi/1MooN1kZfrVvHd9dZ3qcsogyxvHWU0g4swYrbNUiGEEfQNjux6r8Btmrty
NU4vS363P8Gyw8w+LE0cVrrNYWkrPDSWKRnx/Dt8E664f+4wV9jGVY1szjRZs4veRdGu
cdow==
X-Gm-Message-State: APzg51BHnkT3W79nx3/BBuCV0uTxYX+iTGeNu/yCc0hbP4tbkH14l5Lm
tWHBB8c0HRj2hEvNdTKzBR9iVS19ITkxxuppaCTLSQ==
X-Google-Smtp-Source: ANB0Vdb8GTXTYh7/2gcASXu5CGIZS1ZuT8KZ1XKJht+wh2i/pRQvHc2EhE0JRCNzxv2xIJ5QLAKEmXVy4nMLN8vWU/E=
X-Received: by 2002:adf:8205:: with SMTP id 5-v6mr4625860wrb.160.1536296549918;
Thu, 06 Sep 2018 22:02:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a1c:c703:0:0:0:0:0 with HTTP;
Thu, 6 Sep 2018 22:02:29 -0700 (PDT)
In-Reply-To: <20180906203244.GQ62902@hank.reardencode.com>
References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com>
<CAAS2fgQqer6nMXXdcuoXE8UyJokuLTTLBwT+w0tH2+BA2gDu0w@mail.gmail.com>
<20180906203244.GQ62902@hank.reardencode.com>
From: Terry McLaughlin <papawnana4541@gmail.com>
Date: Fri, 7 Sep 2018 00:02:29 -0500
Message-ID: <CAHDfhJpt2Uust5LFX5GyGHDqP_NR9u7a=PUDTgN74zUxZK-A-g@mail.gmail.com>
To: Brandon Smith <freedom@reardencode.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000020ac28057540ea6c"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 07 Sep 2018 13:43:16 +0000
Subject: Re: [bitcoin-dev] A BIP proposal for transactions that are
'cancellable'
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Sep 2018 05:02:32 -0000
--00000000000020ac28057540ea6c
Content-Type: text/plain; charset="UTF-8"
Please help me guide me in the direction I need to go
On Thursday, September 6, 2018, Brandon Smith via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I made a similar proposal about 7 months ago, and documented some of the
> discussion points here:
>
> https://github.com/reardencode/bips/blob/reverselocktime/bip-0zzz.
> mediawiki
>
> On 2018-09-06 (Thu) at 15:16:34 +0000, Gregory Maxwell via bitcoin-dev
> wrote:
> > Functionality such as this does not currently exist not because no one
> > thought of it before, but because it has been proposed many times
> > before and determined to be harmful. The existing design of CLTV/CSV
> > were carefully constructed to make it impossible for a transaction to
> > go from valid to invalid based on the time. The most naive
> > construction-- e.g. push the current time/height on the stack-- would
> > have that property and was specifically avoided.
> >
> > When a spend goes from valid to invalid it means that a reorganization
> > will destroy coins even completely absent any dishonest actions of the
> > coins prior owner in the coins recent casual history. Effectively a
> > coin with any kind of non-monotone validity event in its recent
> > history functions like a recently generated coin: a coin that reorgs
> > destroy. Bitcoin addresses the issue for recently generated coins by
> > not permitting their use for 100 blocks. I've yet to see an argument
> > for a use case for non-monotone validity that still sounds useful once
> > the negative effects are addressed (e.g. by subjecting coins that have
> > gone through them to a maturity limitation).
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000020ac28057540ea6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Please help me guide me in the direction I need to go=C2=A0<br><br>On Thurs=
day, September 6, 2018, Brandon Smith via bitcoin-dev <<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.o=
rg</a>> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I made a similar propos=
al about 7 months ago, and documented some of the<br>
discussion points here:<br>
<br>
<a href=3D"https://github.com/reardencode/bips/blob/reverselocktime/bip-0zz=
z.mediawiki" target=3D"_blank">https://github.com/<wbr>reardencode/bips/blo=
b/<wbr>reverselocktime/bip-0zzz.<wbr>mediawiki</a><br>
<br>
On 2018-09-06 (Thu) at 15:16:34 +0000, Gregory Maxwell via bitcoin-dev wrot=
e:<br>
> Functionality such as this does not currently exist not because no one=
<br>
> thought of it before, but because it has been proposed many times<br>
> before and determined to be harmful.=C2=A0 The existing design of CLTV=
/CSV<br>
> were carefully constructed to make it impossible for a transaction to<=
br>
> go from valid to invalid based on the time. The most naive<br>
> construction-- e.g. push the current time/height on the stack-- would<=
br>
> have that property and was specifically avoided.<br>
> <br>
> When a spend goes from valid to invalid it means that a reorganization=
<br>
> will destroy coins even completely absent any dishonest actions of the=
<br>
> coins prior owner in the coins recent casual history. Effectively a<br=
>
> coin with any kind of non-monotone validity event in its recent<br>
> history functions like a recently generated coin: a coin that reorgs<b=
r>
> destroy. Bitcoin addresses the issue for recently generated coins by<b=
r>
> not permitting their use for 100 blocks.=C2=A0 I've yet to see an =
argument<br>
> for a use case for non-monotone validity that still sounds useful once=
<br>
> the negative effects are addressed (e.g. by subjecting coins that have=
<br>
> gone through them to a maturity limitation).<br>
> ______________________________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/mailman/listi=
nfo/bitcoin-<wbr>dev</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/b=
itcoin-<wbr>dev</a><br>
</blockquote>
--00000000000020ac28057540ea6c--
|
