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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1AAD6C004D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2020 00:14:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 09B4886031
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2020 00:14:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ntyS0PBa8Dfu
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2020 00:14:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 7CF7386008
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2020 00:14:33 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with ESMTPSA id CD5F02D4A4C;
Tue, 11 Aug 2020 00:14:30 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
s=1597102863; t=1597104871;
bh=4NagTHYJdmc5gTSNFnNWetJVIg180+jMLPcElkC6YCA=;
h=Subject:To:Cc:References:From:Date:In-Reply-To:From;
b=GT2iWoGGxiN/GMfomIsijO9aquHgBV33jzmeGTmWND1fZGOz1aZm4oiVyX/AqT/Yx
U+LOSJ9Y7y8SBuBvE7hdu4x91Bpxj3m+x5BkYopY7YW49V1hLHrEHaS4L+JSgGMOhb
TQ5Z5D1goRhQmTcpEoz/UZOgSTbj4O6hzNtj11YattdqVssAjGiA6gDIL5KVBHbogV
KkvnXe5X9H8MI6ayEe0jdwcCw7Uw9YU10T1vl7CtwOHBV3iaGVLKZoTp+jlwF6jlV2
hFna1e5gpOhSSkIDPqy6UOF32uT0gnFZGTBOq8M5gtUCp2QPczSli/ml0insQ8lk5O
Ix0YOOtosg3fA==
To: Richard Myers <rich@gotenna.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com>
<735E5B6A-785E-408B-8658-FA36200923C7@mattcorallo.com>
<KSfad5I1vkw0QoInOkoVtxk9Sw6ypolsQu6TwMd_Y9CzaQsLTElk14434R3Rc2gwC88oAfiH3cITp4do0gtSKknUUBfrmbRKGeYW0ldeevU=@protonmail.com>
<94bb2092-6d53-0e46-45ac-a1f8e04dafba@mattcorallo.com>
<CACJVCgLtt=SBLeA=JWPhzU7EdbJUy2AfPTGbs-pRn0fuwGmZsQ@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <e3b1d9a0-df1d-38e0-02cb-306020ab7240@mattcorallo.com>
Date: Mon, 10 Aug 2020 20:14:29 -0400
MIME-Version: 1.0
In-Reply-To: <CACJVCgLtt=SBLeA=JWPhzU7EdbJUy2AfPTGbs-pRn0fuwGmZsQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 11 Aug 2020 00:14:35 -0000
I was assuming, largely, that Bitcoin Core will eventually get what you describe here (which is generally termed
"package relay", implying we relay, and process, groups of transactions as one).
What we'd need for SIGHASH_ANYPREVOUT is a relay network that isn't just smart about fee calculation, but can actually
rewrite the transactions themselves before passing them on to a local bitcoind.
eg such a network would need to be able to relay
"I have transaction A, with one input, which is valid for any output-idx-0 in a transaction spending output B".
and then have the receiver go look up which transaction in its mempool/chain spends output B, then fill in the input
with that outpoint and hand the now-fully-formed transaction to their local bitcoind for processing.
Matt
On 8/7/20 11:34 AM, Richard Myers wrote:
> When you say that a special relay network might be more "smart about replacement" in the context of ANYPREVOUT*, do you
> mean these nodes could RBF parts of a package like this:
>
>
> Given:
> - Package A = UpdateTx_A(n=1): txin: AnchorTx, txout: SettlementTx_A(n=1) -> HtlcTxs(n=1)_A -> .chain of transactions
> that pin UpdateTx_A(n=1) with high total fee, etc.
>
>
> And a new package with higher fee rate versions of ANYPREVOUT* transactions in the package, but otherwise lower total fee:
>
> - Package B = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1) -> HtlcTxs(n=1)_B -> low total fee package
>
>
> Relay just the higher up-front fee-rate transactions from package B which get spent by the high absolute fee child
> transactions from package A:
>
> - Package A' = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1) -> HtlcTxs(n=1)_A -> ...chain of up to 25
> txs that pin UpdateTx(n=1) with high total fee, etc.
>
> On Thu, Aug 6, 2020 at 5:59 PM Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> In general, SIGHASH_NOINPUT makes these issues much, much simpler to address, but only if we assume that nodes can
> somehow be "smart" about replacement when they see a SIGHASH_NOINPUT spend which can spend an output that something else
> in the mempool already spends (potentially a different input than the relaying node thinks the transaction should
> spend). While ideally we'd be able to shove that (significant) complexity into the Bitcoin P2P network, that may not be
> feasible, but we could imagine a relay network of lightning nodes doing that calculation and then passing the
> transactions to their local full nodes.
>
>
|
