MIME-Version: 1.0
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"
Subject: Re: [bitcoin-dev] A BIP proposal for transactions that are
	'cancellable'
Precedence: list

--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 &lt;<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt; 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>
&gt; Functionality such as this does not currently exist not because no one=
<br>
&gt; thought of it before, but because it has been proposed many times<br>
&gt; before and determined to be harmful.=C2=A0 The existing design of CLTV=
/CSV<br>
&gt; were carefully constructed to make it impossible for a transaction to<=
br>
&gt; go from valid to invalid based on the time. The most naive<br>
&gt; construction-- e.g. push the current time/height on the stack-- would<=
br>
&gt; have that property and was specifically avoided.<br>
&gt; <br>
&gt; When a spend goes from valid to invalid it means that a reorganization=
<br>
&gt; will destroy coins even completely absent any dishonest actions of the=
<br>
&gt; coins prior owner in the coins recent casual history. Effectively a<br=
>
&gt; coin with any kind of non-monotone validity event in its recent<br>
&gt; history functions like a recently generated coin: a coin that reorgs<b=
r>
&gt; destroy. Bitcoin addresses the issue for recently generated coins by<b=
r>
&gt; not permitting their use for 100 blocks.=C2=A0 I&#39;ve yet to see an =
argument<br>
&gt; for a use case for non-monotone validity that still sounds useful once=
<br>
&gt; the negative effects are addressed (e.g. by subjecting coins that have=
<br>
&gt; gone through them to a maturity limitation).<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <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--