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
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id C1A1FC0175
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Apr 2020 12:53:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id AF35487723
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Apr 2020 12:53:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id CCQ5m+mO+VON
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Apr 2020 12:53:09 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by whitealder.osuosl.org (Postfix) with ESMTPS id 87EAC877A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Apr 2020 12:53:09 +0000 (UTC)
Date: Thu, 23 Apr 2020 12:52:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1587646387;
bh=yTEFEObdMasDl69Pluk/cKchsT507XM9HtD8Y9KY0/c=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=Bgw/gMckaNmS9y3aPdmpATi1tgjPpdHwCtYYBxS4anStMilkt7YY3y22SsGTWGixu
fbF4fPB5XEcuXwFrvIHm8bhd7eDozMOsgmAHrtded38K8+Rp7sARo+gTlaHSK+7a1h
PzTBNOhEok3tDX0uNXrAfMDSq7Jjtqkk4dZpqq0I=
To: "David A. Harding" <dave@dtrt.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <94JJOtjVVtDkVWhb42Wy-bSCathj7nZJc9uJCKz0XVK5hYF2kwbZQ9ZN9LHhe5mPNrbSENW6F0sLe5tM-mVG7-oM493B4HKyVQJceTsdmHI=@protonmail.com>
In-Reply-To: <20200423095957.ocetcjhevwlonwya@ganymede>
References: <52DA8104-3E4E-450F-92A4-3970D1A31281@mattcorallo.com>
<20200423095957.ocetcjhevwlonwya@ganymede>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
and Competing Interest
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: Thu, 23 Apr 2020 12:53:10 -0000
Good morning David,
Unfortunately this technique does not look like it is compatible to payment=
points rather than hashes, and we would really like to upgrade to payment =
points sooner rather than later.
Nobody but B can recognize the signature as revealing the scalar behind a p=
articular point (the main privacy advantage of using points).
Even variations on this are not useable with payment points.
Regards,
ZmnSCPxj
> On Wed, Apr 22, 2020 at 03:53:37PM -0700, Matt Corallo wrote:
>
> > if you focus on sending the pinning transaction to miner nodes
> > directly (which isn't trivial, but also not nearly as hard as it
> > sounds), you could still pull off the attack.
>
> If the problem is that miners might have information not available to
> the network in general, you could just bribe them for that knowledge.
> E.g. as Bob's refund deadline approaches and he begins to suspect that
> mempool shenanigans are preventing his refund transaction from
> confirming, he takes a confirmed P2WPKH UTXO he's been saving for use in
> CPFP fee bumps and spends part of its value (say 1 mBTC) to the
> following scriptPubKey[1],
>
> OP_SHA256 <hash_whose_preimage_bob_wants> OP_EQUAL
>
> Assuming the feerate and the bribe amount are reasonable, any miner who
> knows the preimage is incentivized to include Bob's transaction and a
> child transation spending from it in their next block. That child
> transaction will include the preimage, which Bob will see when he
> processes the block.
>
> If any non-miner knows the preimage, they can also create that child
> transaction. The non-miner probably can't profit from this---miners can
> just rewrite the child transaction to pay themselves since there's no
> key-based security---but the non-miner can at least pat themselves on
> the back for being a good Summaritan. Again Bob will learn the preimage
> once the child transaction is included in a block, or earlier if his
> wallet is monitoring for relays of spends from his parent transaction.
>
> Moreover, Bob can first create a bribe via LN and, in that case, things
> are even better. As Bob's deadline approaches, he uses one of his
> still-working channels to send a bunch of max-length (20 hops?) probes
> that reuse the earlier HTLC's <hash>. If any hop along the path knows
> the preimage, they can immediately claim the probe amount (and any
> routing fees that were allocated to subsequent hops). This not only
> gives smaller miners with LN nodes an equal chance of claiming the
> probe-bribe as larger miners, but it also allows non-miners to profit
> from learning the preimage from miners.
>
> That last part is useful because even if, as in your example, the
> adversary is able to send one version of the transaction just to miners
> (with the preimage) and another conflicting version to all relay nodes
> (without the preimage), miners will naturally attempt to relay the
> preimage version of the transaction to other users; if some of those
> users run modified nodes that write all 32-byte witness data blobs to a
> database---even if the transaction is ultimately rejected as a
> conflict---then targetted relay to miners may not be effective at
> preventing Bob from learning the preimage.
>
> Obviously all of the above requires people run additional software to
> keep track of potential preimages[2] and then compare them to hash
> candidates, plus it requires additional complexity in LN clients, so I
> can easily understand why it might be less desirable than the protocol
> changes under discussion in other parts of this thread. Still, with
> lots of effort already being put into watchtowers and other
> enforcement-assistance services, I wonder if this problem can be largely
> addressed in the same general way.
>
> -Dave
>
> [1] Requires a change to standard relay and mining policy.
> [2] Pretty easy, e.g.
>
> bitcoin-cli getrawmempool \
> | jq -r .[] \
> | while read txid ; do
> bitcoin-cli getrawtransaction $txid true | jq .vout[].scriptPubKey.asm
> done \
> | grep -o '\<[0-9a-f]\{64\}\>'
>
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
|
