summaryrefslogtreecommitdiff
path: root/ea/6c15489bf6a02de86787554d27aa6759f86a0d
blob: 6f4f6fd4d5b211ca18cd1230de5fc108667a6197 (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
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CAA917F9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 May 2018 17:36:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com
	[209.85.220.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3EAA5A3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 May 2018 17:36:09 +0000 (UTC)
Received: by mail-qk0-f174.google.com with SMTP id d125-v6so4262860qkb.8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 May 2018 10:36:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:to:subject:in-reply-to:references:date:message-id:mime-version; 
	bh=uCk+3+1WI2RoD1FFfOx2Ri6qiMKshCHTds+m8+vXC4s=;
	b=tHytSiZ31epwECunUaKuB+Nr4f1XxQ1g40+wMBCazzBhdN6RCH9jM/0m/z7UaCx7YQ
	gB2MQI3C6x2gMg/ilfsKHyHL7oFLG+sI4dU6wEEC8xPTeCWI8buZakkaVBB3FxINdpb/
	p9O8R9ixdL56r4psIUQhXyVx/grPWfB53P5rvWOKUAPSD3JrLNzdwrBrgrcq4LisEH1r
	2gQXmUJrsHKgWO2JBQL0FAkrWWQq+2xqFjlGX7bZn3Yl45U51yADA3tksQa0kDDSlNOC
	JTn3/Fl6h6i7t7cgq4DFjiz8T7k+cibZeAqXAGist0YINWH/xoaOv1gZWb3gkui2vJWM
	n44g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:to:subject:in-reply-to:references:date
	:message-id:mime-version;
	bh=uCk+3+1WI2RoD1FFfOx2Ri6qiMKshCHTds+m8+vXC4s=;
	b=aDipdrTkNxFs3hT6gwIcoUzQauQWZHqlvTGUjEe0V4iZk4+MHSzmOSTA7JcmzLQpNd
	scbQLYWMaPe955ABbtiMuyH/IbN2jdWC2kfzIJK7FoNMa+bfIc8QbryoUKueA9Wxn0hU
	FchFMhrr5k51l6mSDKeF1VwsKPDHz72jpSFAN0iMZEJKVMSHoSY/8NlAdufkKE0aNQY9
	2yN55nsaY72LzIM9jnXVfPUKyJPLofztnx/KQIw9W9IvsZLXz7hG5SCmZ9OcBw4Bg/hV
	LomrUOl7HESbxFnRVOTNtOAvxwH2rDu+YWzneR69rv/2ITUSFu95F0j0VsUD3jGCqfu2
	F/nQ==
X-Gm-Message-State: ALKqPwcdM9V/9t/CNQR3yUK60rbOrLYvjj1L9NTAsezhN8eQoRqo8AZ2
	mGM4r06mXgD+vvWNvO8/8/I=
X-Google-Smtp-Source: AB8JxZr+sKZRzHNN4Z6ap5zvgQ82d/AZwQqFpOXpS9/8bhn7zwaGu2FLoSCnRF+FugBQAFV5ZfHQUw==
X-Received: by 2002:a37:1f14:: with SMTP id
	f20-v6mr5728919qkf.391.1526578568329; 
	Thu, 17 May 2018 10:36:08 -0700 (PDT)
Received: from localhost (parkc133.p.subnet.rcn.com. [206.71.234.160])
	by smtp.gmail.com with ESMTPSA id
	u21-v6sm4296021qki.63.2018.05.17.10.36.06
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 17 May 2018 10:36:07 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <bGnScyqXi6LMbsqtc8l3DDTfibYhKd30y-Urd28iImu-gK2hBKYPLpkkbit18RkYlmakzoJAVqKyqL5bw_By_AdXJJd1r3QrLjH1W6igKPM=@protonmail.com>
References: <87po25lmzs.fsf@rustcorp.com.au>
	<201805100227.42217.luke@dashjr.org>
	<87vabnq9ui.fsf@rustcorp.com.au>
	<bGnScyqXi6LMbsqtc8l3DDTfibYhKd30y-Urd28iImu-gK2hBKYPLpkkbit18RkYlmakzoJAVqKyqL5bw_By_AdXJJd1r3QrLjH1W6igKPM=@protonmail.com>
Date: Thu, 17 May 2018 13:35:53 -0400
Message-ID: <87h8n6i3ra.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, 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
Subject: Re: [bitcoin-dev] Making OP_TRUE standard?
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, 17 May 2018 17:36:09 -0000

ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:

> Good morning Rusty and list,
>
>> Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is
>> interesting,
>> 
>> but if we want a SF just give us SIGHASH_NOINPUT and we'll not need
>> this
>> 
>> at all (though others still might).
>
> We might still want this in general in Lightning; for instance we
> could make every funding transaction include such an output.  If it
> turns out, our initial feerate estimate for the funding transaction is
> low, we can use the `OP_TRUE` for fee-bumping.  This is a win for
> Lightning since the funding transaction ID remains the same (even in
> Decker-Russell-Osuntokun, the trigger transaction is signed with
> `SIGHASH_ALL`, and refers to a fixed funding transaction ID).
>
> Without the `OP_TRUE`-for-fee-bump, we would have to pretend to open a
> new different channel and RBF the old funding transaction with a new
> higher-feerate funding transaction, then keep track of which one gets
> confirmed deeply (there is a race where a miner discovers a block
> using the older funding transaction before our broadcast of the new
> funding transaction reaches it).
>
> (we could also feebump using the change output of the funding
> transaction, but such a change output might not exist for all funding
> transactions.)

This would only really help in the case of the funding tx not having a
change output, which I believe will be very rare. In the case of a
change output we can simply do a CPFP which includes the change output.