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
|
Return-Path: <freedom@reardencode.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 44FAB1205
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Sep 2018 20:42:31 +0000 (UTC)
X-Greylist: delayed 00:09:45 by SQLgrey-1.7.6
Received: from hank.reardencode.com (hank.reardencode.com [206.125.169.162])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id C4B668B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Sep 2018 20:42:30 +0000 (UTC)
Received: by hank.reardencode.com (Postfix, from userid 1001)
id 593E22E003; Thu, 6 Sep 2018 13:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=reardencode.com;
s=default; t=1536265964;
bh=LoDtMCrPAfMD+HGEtBCVYptOImmUt38LKurs2gwBQfc=;
h=Date:From:To:Cc:Subject:References:In-Reply-To;
b=lq9xBtMTiZ3qOJdr9v3udF6cA2BSpRlU6PIQJIM6FZtyo92FZGXML+qiKKCWtHByR
0nOgKAojxUm0i+9WUTqCswH7WWY1h8Y0EOEscF6t+S/VX83QrgwH3XfgrxUi8Hyozo
ePNfDOEnqK3oy4CAzxTl93rS8ocz4JQXxFA3MhrI=
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>
X-Operating-System: FreeBSD 10.4-RELEASE-p8 amd64
User-Agent: Mutt/1.9.5 (2018-04-13)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 06 Sep 2018 23:33:40 +0000
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'
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: Thu, 06 Sep 2018 20:42:31 -0000
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
|
