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
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 85657DE5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Apr 2018 23:46:55 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [103.22.144.67])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D860CA9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Apr 2018 23:46:54 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 40FTQh5l8fz9s1w; Tue, 3 Apr 2018 09:46:52 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Tue, 03 Apr 2018 09:16:45 +0930
Message-ID: <874lktdvdm.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_05,RCVD_IN_DNSWL_MED,
T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Signature bundles
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: Mon, 02 Apr 2018 23:46:55 -0000
Hi all!
Since there's activity on new signature types, I think it's
worth considering a more flexible alternative to
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. See Usefulness for why.
Proposal: Two bits: SIGHASH_BUNDLESTART/SIGHASH_INBUNDLE
--------
A signature needs to indicate that signs only part of a transaction's
inputs and outputs (a.k.a. a "bundle"). Bundles can be combined
together into larger transactions, and non-bundled signature inputs /
outputs appended.
Two per-tx counters are kept: bundle_inputs_used and
bundle_outputs_used, both starting at 0.
SIGHASH_BUNDLESTART indicates two var_int sit between the sighash flags
and the signature itself: the first is the number of inputs in this
bundle starting at bundle_inputs_used, the second is the number of
outputs starting at bundle_outputs_used. bundle_inputs_used and
bundle_outputs_used have these values added, for next time.
SIGHASH_INBUNDLE indicates that this signature applies to the current
bundle. The txCopy is reduced to cover only the inputs and
outputs in the current bundle, and the signature commits to the two
var_ints from SIGHASH_BUNDLESTART along with the sighash flags.
(A proper BIP would detail how any weird stuff makes the tx invalid:
take that as read).
Usage
-----
You can use this to sign a transaction just like now, with only two
extra bytes and these SIGHASH flags. But this transaction can now be
aggregated by pasting on another bundle, or attaching other normal
inputs and/or outputs. You can aggregate as many transactions as you
want this way.
Usefulness
----------
One of the issues we've struck with lightning is trying to guess future
fees for commitment transactions: we can't rely on getting another
signature from our counterparty to increase fees. Nor can we use
parent-pays-for-child since the outputs we can spend are timelocked.
This "holding a valid tx but I want to add fees later without
re-signing" seems like a general problem. The only current method would
be to engineer transactions as a single-input-single-output tx and use
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY; this is very limiting.
The other obvious application would be to run public aggregators, which
would provide throughput promises ("if you send me a tx with feerate X,
I will make sure it goes onchain within a week"). This service would
sometimes profit, if it can do so cheaper than it quoted, and sometimes
have to add additional fees. The existence of such services should
smooth the current fee cliff by allowing users and services to offer
"slow mode" payment options without requiring interaction.
Feedback welcome!
Rusty.
|
