Date: Thu, 6 Sep 2018 13:32:44 -0700
From: Brandon Smith <freedom@reardencode.com>
To: Gregory Maxwell <greg@xiph.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180906203244.GQ62902@hank.reardencode.com>
References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com>
	<CAAS2fgQqer6nMXXdcuoXE8UyJokuLTTLBwT+w0tH2+BA2gDu0w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAS2fgQqer6nMXXdcuoXE8UyJokuLTTLBwT+w0tH2+BA2gDu0w@mail.gmail.com>
User-Agent: Mutt/1.9.5 (2018-04-13)
Cc: sara.tucci@cea.fr, Onder.GURCAN@cea.fr, a.ranchalpedrosa@gmail.com
Subject: Re: [bitcoin-dev] A BIP proposal for transactions that are
 'cancellable'
Precedence: list

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