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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 581A5407
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 03:07:55 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail5.protonmail.ch (mail5.protonmail.ch [185.70.40.28])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7541CB0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 03:07:54 +0000 (UTC)
Date: Wed, 09 May 2018 23:07:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1525921671;
bh=QcZdSXGJccZmWJ0y655nCiw4n3w4RBh4Rok1yMfshTU=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=GKEjsoaKdWbGCIIgrrdHkGdJr31Cb4K8v/Oh1ZN+fMnVTQBF5DKopUGD03Q1gFbUJ
V98Wc9qRqAxAI4Jw/FjpFs1e2ZcOPb3MOQGH3h1S5UMV8BhDmAN+levVX2RKmFzZQ+
OJzmsq7SYwD5mCBGfw/QCOuBUCnch6523Kalku9c=
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <YOfgzjDA6blassXxfjPMCeNNE77y-Cuyp8rtc2eOdjj6NVPSOrZfa4a6clTE96-Val-IBHKlQteiVrI9vObgFh9SphENQwLRbf2-AKqUXeM=@protonmail.com>
In-Reply-To: <201805100227.42217.luke@dashjr.org>
References: <87po25lmzs.fsf@rustcorp.com.au>
<201805100227.42217.luke@dashjr.org>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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, 10 May 2018 03:08:15 +0000
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, 10 May 2018 03:07:55 -0000
Good morning Luke and list,
> An OP_TRUE-only script with a low value seems like a good example of wher=
e the
>=20
> weight doesn't reflect the true cost: it uses a UTXO forever, while only
>=20
> costing a weight of 4.
>=20
> I like Johnson's idea to have some template (perhaps OP_2-only, to preser=
ve
>=20
> expected behaviour of OP_TRUE-only) that when combined with a 0-value is
>=20
> always valid only if spent in the same block.
I understand the issue. On Lightning side, if this rule is used, we would =
have the two options below:
1. Commitment transactions always use the minimum feerate, but always have=
the above OP_TRUE output. Then to confirm the commitment transaction we w=
ould have to always spend the OP_TRUE output in CPFP transaction that pays =
for actual fee at unilateral close. This consumes more blockchain space fo=
r unilateral closes, as the second transaction is always mandatory.
2. We store two commitment transactions and associated paraphernalia (furt=
her transactions to claim the HTLCs). One version has a negotiated feerate=
without the OP_TRUE output. The other version has a slightly increased fe=
erate and an OP_TRUE output as above. At unilateral close, we see if the n=
egotiated feerate is enough and use that version if possible, but if not we=
RBF it with other version and in addition also CPFP on top. As mentioned =
before, we do not have transaction packages, so we need to RBF with higher =
feerate the commitment transaction, then submit the CPFP transaction which =
makes the first transaction valid to include in a block as per the rule. T=
his requires that the fallback always have both an RBF bump and a CPFP bump=
.
>=20
>(Maybe it should be the first output
>=20
> instead of the last... Is there any legitimate reason one would have mult=
iple
>=20
> such dummy outputs?)
It seems there are indeed none.
Regards,
ZmnSCPxj
|
