summaryrefslogtreecommitdiff
path: root/67/1020c0f33ff2dd4159e49c0afee0fdff94f182
blob: f74ea3e09080dd251574a726634104ada1729674 (plain)
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
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B47E3D30
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Sep 2018 15:16:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com
	[209.85.222.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3E947F9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Sep 2018 15:16:55 +0000 (UTC)
Received: by mail-ua1-f46.google.com with SMTP id f4-v6so9034006uao.10
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Sep 2018 08:16:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=dhEJ/pVrk8sPbg8UmQN9o3FAN6FmNQcIi+SWzO70O04=;
	b=Zlod6wUFHGpe1kYdDhqJxAa9L33kSKhPHa7dimO5RtHTE3qHfrD5z9EsBDafLUdWdO
	g3ajOc/9y2RjniYYi799BxnrUoiZhXH5hHQ34J77Np5YoClS5tCXDcaC7MMyFtlXddCJ
	D9fuTiqy8NPQBTeXQ0Ngrw79p+zMHyKUgmz+qlFNUoCQvEjlpBKeNjQ+qwBzusESF2wC
	V2nHSETNFnjeESBiOWyBq8toH39R0QptOtw+eKdQA1ru7izApVrfEdikE+2EIf6L/NCh
	+WYc2zbV5kXVxWIOaTKNSMYFFJc/das14BStP6RM0zBe4RQjmsWLq6x0KCYcV7hQfe9T
	MT0Q==
X-Gm-Message-State: APzg51DlLn3BIOSX/XivURYzsIDvTQlkb+e3Zd1XRuAsvZWfF0rfUWi2
	bQKCgwQdWRAn9onRVlFIVKXbffkLwOHqdoVLD9I=
X-Google-Smtp-Source: ANB0Vdar3MTTVTuOQcvyF3lxeT4BS8BoBrFTebLWVZJXBKubmzYLRS9jZySASifaJl1xigwoPATIUFZ01rE6Pi9zK/Y=
X-Received: by 2002:ab0:5594:: with SMTP id
	v20-v6mr1194597uaa.146.1536247014746; 
	Thu, 06 Sep 2018 08:16:54 -0700 (PDT)
MIME-Version: 1.0
References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com>
In-Reply-To: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Thu, 6 Sep 2018 15:16:34 +0000
Message-ID: <CAAS2fgQqer6nMXXdcuoXE8UyJokuLTTLBwT+w0tH2+BA2gDu0w@mail.gmail.com>
To: a.ranchalpedrosa@gmail.com, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_NONE 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 16:20:26 +0000
Cc: sara.tucci@cea.fr, Onder.GURCAN@cea.fr
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 15:16:57 -0000

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).