From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C1A1FC0175 for ; 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 ; 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 ; 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 ; 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" From: ZmnSCPxj Reply-To: ZmnSCPxj 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 , lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 . 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