summaryrefslogtreecommitdiff
path: root/0a/e672a1ab271d57ac51ced08d20b44f99d9f351
blob: bf5da3bbe7b5fa594819b08195edc9644f0bfbc1 (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
82
83
84
85
86
87
88
89
90
91
92
93
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gmaxwell@gmail.com>) id 1Xc7PO-0005h1-Il
	for bitcoin-development@lists.sourceforge.net;
	Thu, 09 Oct 2014 06:41:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.173 as permitted sender)
	client-ip=209.85.213.173; envelope-from=gmaxwell@gmail.com;
	helo=mail-ig0-f173.google.com; 
Received: from mail-ig0-f173.google.com ([209.85.213.173])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Xc7PM-0002aY-Uu
	for bitcoin-development@lists.sourceforge.net;
	Thu, 09 Oct 2014 06:41:06 +0000
Received: by mail-ig0-f173.google.com with SMTP id h18so11065640igc.0
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 08 Oct 2014 23:40:59 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.42.20.84 with SMTP id f20mr4793188icb.48.1412836859536; Wed,
	08 Oct 2014 23:40:59 -0700 (PDT)
Received: by 10.107.168.5 with HTTP; Wed, 8 Oct 2014 23:40:59 -0700 (PDT)
In-Reply-To: <20141009063331.GA16898@muck>
References: <CANEZrP1eGi-AHgciQiKUuUB7WwqKsMOyTjCQAAO=RWEkPC2Uiw@mail.gmail.com>
	<CAJHLa0NRNEQLqA2E=ysXsKw6hWS-H9X_AFYK4ckC4-_Bk=qbSA@mail.gmail.com>
	<20141004003850.GA23202@muck>
	<CANEZrP0_jDouDCLn9BvxUd7UYiZLbVsaGGkkxwjcOYxZryBDPQ@mail.gmail.com>
	<CABsx9T0Q8g9KYRbAvCV=35x5Rb5HFnrNkrwwMZ=Mv-namMEPpg@mail.gmail.com>
	<CANEZrP2Xp7ene+KDw_L_YnNW=hDt9K-UigvZ6PLb3oUviOr_Tw@mail.gmail.com>
	<CA+s+GJC2v+g-SWvqdaD2Fb7bb4DkWTtp+e4QNRGvCo1QtraFnQ@mail.gmail.com>
	<5435FD3D.40409@gmail.com>
	<CALqxMTHN4G1HO-7_0Fot943KK-GGOfK9gXDBqaKyyRngiXbuFQ@mail.gmail.com>
	<CAAS2fgRmuyK_k4UU+3Lufaq7=j7wR_MXV1PKeb2HqRRa7VX=pQ@mail.gmail.com>
	<20141009063331.GA16898@muck>
Date: Thu, 9 Oct 2014 06:40:59 +0000
Message-ID: <CAAS2fgSfv4NoJtT=eEN7cSM=f2syeggt7fFLJd=GBcjP53RAHQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gmaxwell[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Xc7PM-0002aY-Uu
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent
 a txout from being spent until an expiration time
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 09 Oct 2014 06:41:06 -0000

On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd <pete@petertodd.org> wrote:
> Speaking of, can anyone think of an example of a complex transaction
> use-case that is affected by malleability which can't be fixed by
> CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
> trying to think of a good example.

Yea, no problem since we lack covenants.

Or a least no problem making an example, maybe you'll find it too
contrived since I'm not sure what would motivate it:

You and I put 5 btc each into a kickstarter-escrow to pay Alice+some
oracle that decides if alice did her job.  But if a timeout expires
before alice manages to get the sign off the funds must be returned
completely to their original payers.

Returning them to in two outputs, one to me, one to you is trivial
with a pre-signed refund.

You could make there be multiple alice outputs or refund, but then you
can't guarantee an atomic reversal (e.g. maybe Alice gets half if we
race).