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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A8DD6A80
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 02:28:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 21FF867F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 May 2018 02:28:29 +0000 (UTC)
Received: from [2001:470:5:265:a45d:823b:2d27:961c] (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 058BA38B5CF4;
Thu, 10 May 2018 02:27:44 +0000 (UTC)
X-Hashcash: 1:25:180510:bitcoin-dev@lists.linuxfoundation.org::RMblWeWdFgKU7W0R:deELB
X-Hashcash: 1:25:180510:rusty@rustcorp.com.au::0lFIdDubtvDWZ5E0:7zYk
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Rusty Russell <rusty@rustcorp.com.au>
Date: Thu, 10 May 2018 02:27:41 +0000
User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748)
References: <87po25lmzs.fsf@rustcorp.com.au>
In-Reply-To: <87po25lmzs.fsf@rustcorp.com.au>
X-KMail-QuotePrefix: >
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201805100227.42217.luke@dashjr.org>
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED
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, 10 May 2018 02:28:29 -0000
An OP_TRUE-only script with a low value seems like a good example of where the
weight doesn't reflect the true cost: it uses a UTXO forever, while only
costing a weight of 4.
I like Johnson's idea to have some template (perhaps OP_2-only, to preserve
expected behaviour of OP_TRUE-only) that when combined with a 0-value is
always valid only if spent in the same block.
I wonder if it would make sense to actually tie it to a transaction version
bit, such that when the bit is set, the transaction is serialised with +1 on
the output count and 00000000000000000181 is simply injected into the
transaction hashing... But for now, simply having a consensus rule that a bit
MUST be set for the expected behaviour, and the bit may ONLY be set when the
last output is exactly 00000000000000000181, would allow us to code the
transaction serialisation up later. (Maybe it should be the first output
instead of the last... Is there any legitimate reason one would have multiple
such dummy outputs?)
Luke
On Tuesday 08 May 2018 23:57:11 Rusty Russell via bitcoin-dev wrote:
> Hi all,
>
> The largest problem we are having today with the lightning
> protocol is trying to predict future fees. Eltoo solves this elegantly,
> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> commitment transactions so that we use minimal fees and then use CPFP
> (which can't be done at the moment due to CSV delays on outputs).
>
> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> non-standard. Are there any reasons not to suggest such a policy
> change?
>
> Thanks!
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
