From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A4A3749D for ; Mon, 3 Dec 2018 04:16:27 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7344614D for ; Mon, 3 Dec 2018 04:16:26 +0000 (UTC) Date: Mon, 03 Dec 2018 04:16:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1543810577; bh=/+ryZ0Zz9hcZL+ZuzSc8z0CoQf3Tx6vfpCuWzb2KmG0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=XQzCh/hgZ2KcC8l21bcUaRpNnISi7eu6L+KXDlf16sBSqPJYebgCFZPayfR7vBXzI 2bRcRCJvIRD6Kjj8Npkp3Ot66AjUXp5wyzRSa9QQRR3Uuku1ewTLfG3YqQEWRpPIA6 7ujesqi2iBSNeTE4EVHb1RYM58J7C8bb4iPCQucc= To: Bob McElrath From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <8-tJwX51A0xFHoEsKchKREO5i8YxqM48JWspLRiAV3TBHWrRUkUmcZqbAJH6Z6KBQAppPHwuClmzzoaLxtOQqWoHyQG8nzVJAuzAFFGl-s8=@protonmail.com> In-Reply-To: <20181202150839.GE22873@mcelrath.org> References: <20181202150839.GE22873@mcelrath.org> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 03 Dec 2018 04:23:01 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 04:16:27 -0000 Good morning Bob, Would `SIGHASH_SINGLE` work? Commitment transactions have a single input but multiple outputs. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Sunday, December 2, 2018 11:08 PM, Bob McElrath wrote= : > I've long thought about using SIGHASH_SINGLE, then either party can add i= nputs > to cover whatever fee they want on channel close and it doesn't have to b= e > pre-planned at setup. > > For Lightning I think you'd want to cross-sign, e.g. Alice signs her inpu= t > and Bob's output, while Bob signs his input and Alice's output. This woul= d > demotivate the two parties from picking apart the transaction and broadca= sting > one of the two SIGHASH_SINGLE's in a Lightning transaction. > > Matt Corallo via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrot= e: > > > (cross-posted to both lists to make lightning-dev folks aware, please t= ake > > lightning-dev off CC when responding). > > As I'm sure everyone is aware, Lightning (and other similar systems) wo= rk by > > exchanging pre-signed transactions for future broadcast. Of course in m= any > > cases this requires either (a) predicting what the feerate required for > > timely confirmation will be at some (or, really, any) point in the futu= re, > > or (b) utilizing CPFP and dependent transaction relay to allow parties = to > > broadcast low-feerate transactions with children created at broadcast-t= ime > > to increase the effective feerate. Ideally transactions could be constr= ucted > > to allow for after-the-fact addition of inputs to increase fee without = CPFP > > but it is not always possible to do so. > > Option (a) is rather obviously intractible, and implementation complexi= ty > > has led to channel failures in lightning in practice (as both sides mus= t > > agree on a reasonable-in-the-future feerate). Option (b) is a much more > > natural choice (assuming some form of as-yet-unimplemented package rela= y on > > the P2P network) but is made difficult due to complexity around RBF/CPF= P > > anti-DoS rules. > > For example, if we take a simplified lightning design with pre-signed > > commitment transaction A with one 0-value anyone-can-spend output avail= able > > for use as a CPFP output, a counterparty can prevent confirmation > > of/significantly increase the fee cost of confirming A by chaining a > > large-but-only-moderate-feerate transaction off of this anyone-can-spen= d > > output. This transaction, B, will have a large absolute fee while makin= g the > > package (A, B) have a low-ish feerate, placing it solidly at the bottom= of > > the mempool but without significant risk of it getting evicted during m= emory > > limiting. This large absolute fee forces a counterparty which wishes to= have > > the commitment transaction confirm to increase on this absolute fee in = order > > to meet RBF rules. > > For this reason (and many other similar attacks utilizing the package s= ize > > limits), in discussing the security model around CPFP, we've generally > > considered it too-difficulty-to-prevent third parties which are able to > > spend an output of a transaction from delaying its confirmation, at lea= st > > until/unless the prevailing feerates decline and some of the mempool ba= cklog > > gets confirmed. > > You'll note, however, that this attack doesn't have to be permanent to = work > > > > - Lightning's (and other contracting/payment channel systems') securi= ty > > model assumes the ability to get such commitment transactions confi= rmed in a > > timely manner, as otherwise HTLCs may time out and counterparties c= an claim > > the timeout-refund before we can claim the HTLC using the hash-prei= mage. > > > > > > To partially-address the CPFP security model considerations, a next ste= p > > might involve tweaking Lightning's commitment transaction to have two > > small-value outputs which are immediately spendable, one by each channe= l > > participant, allowing them to chain children off without allowng unrela= ted > > third-parties to chain children. Obviously this does not address the > > specific attack so we need a small tweak to the anti-DoS CPFP rules in > > Bitcoin Core/BIP 125: > > The last transaction which is added to a package of dependent transacti= ons > > in the mempool must: > > > > - Have no more than one unconfirmed parent, > > - Be of size no greater than 1K in virtual size. > > (for implementation sanity, this would effectively reduce all mempo= ol > > package size limits by 1 1K-virtual-size transaction, and the last = would be > > "allowed to violate the limits" as long as it meets the above crite= ria). > > > > > > For contracting applications like lightning, this means that as long as= the > > transaction we wish to confirm (in this case the commitment transaction= ) > > > > - Has only two immediately-spendable (ie non-CSV) outputs, > > - where each immediately-spendable output is only spendable by one > > counterparty, > > > > - and is no larger than MAX_PACKAGE_VIRTUAL_SIZE - 1001 Vsize, > > each counterparty will always be able to independantly CPFP the tra= nsaction > > in question. ie because if the "malicious" (ie transaction-delaying= ) party > > bradcasts A with a child, it can never meet the "last transaction" = carve-out > > as its transaction cannot both meet the package limit and have only= one > > unconfirmed ancestor. Thus, the non-delaying counterparty can alway= s > > independently add its own CPFP transaction, increasing the (A, Tx2)= package > > feerate and confirming A without having to concern themselves with = the (A, > > Tx1) package. > > > > > > As an alternative proposal, at various points there have been discussio= ns > > around solving the "RBF-pinning" problem by allowing transactors to mar= k > > their transactions as "likely-to-be-RBF'ed", which could enable a relay > > policy where children of such transactions would be rejected unless the > > resulting package would be "near the top of the mempool". This would > > theoretically imply such attacks are not possible to pull off consisten= tly, > > as any "transaction-delaying" channel participant will have to place th= e > > package containing A at an effective feerate which makes confirmation t= o > > occur soon with some likelihood. It is, however, possible to pull off t= his > > attack with low probability in case of feerate spikes right after broad= cast. > > Note that this clearly relies on some form of package relay, which come= s > > with its own challenges, but I'll start a separate thread on that. > > See-also: lightning-dev thread about the changes to lightning spec requ= ired > > to incorporate this: https://lists.linuxfoundation.org/pipermail/lightn= ing-dev/2018-November/001643.html > > Matt > > > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > !DSPAM:5c014daf168271726154759! > > -- > Cheers, Bob McElrath > > "For every complex problem, there is a solution that is simple, neat, and= wrong." > -- H. L. Mencken > > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev