Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Bob McElrath <bob@mcelrath•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)
Date: Mon, 03 Dec 2018 04:16:10 +0000	[thread overview]
Message-ID: <8-tJwX51A0xFHoEsKchKREO5i8YxqM48JWspLRiAV3TBHWrRUkUmcZqbAJH6Z6KBQAppPHwuClmzzoaLxtOQqWoHyQG8nzVJAuzAFFGl-s8=@protonmail.com> (raw)
In-Reply-To: <20181202150839.GE22873@mcelrath.org>

Good morning Bob,

Would `SIGHASH_SINGLE` work?
Commitment transactions have a single input but multiple outputs.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, December 2, 2018 11:08 PM, Bob McElrath <bob@mcelrath•org> wrote:

> I've long thought about using SIGHASH_SINGLE, then either party can add inputs
> to cover whatever fee they want on channel close and it doesn't have to be
> pre-planned at setup.
>
> For Lightning I think you'd want to cross-sign, e.g. Alice signs her input
> and Bob's output, while Bob signs his input and Alice's output. This would
> demotivate the two parties from picking apart the transaction and broadcasting
> one of the two SIGHASH_SINGLE's in a Lightning transaction.
>
> Matt Corallo via bitcoin-dev [bitcoin-dev@lists•linuxfoundation.org] wrote:
>
> > (cross-posted to both lists to make lightning-dev folks aware, please take
> > lightning-dev off CC when responding).
> > As I'm sure everyone is aware, Lightning (and other similar systems) work by
> > exchanging pre-signed transactions for future broadcast. Of course in many
> > cases this requires either (a) predicting what the feerate required for
> > timely confirmation will be at some (or, really, any) point in the future,
> > or (b) utilizing CPFP and dependent transaction relay to allow parties to
> > broadcast low-feerate transactions with children created at broadcast-time
> > to increase the effective feerate. Ideally transactions could be constructed
> > 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 complexity
> > has led to channel failures in lightning in practice (as both sides must
> > agree on a reasonable-in-the-future feerate). Option (b) is a much more
> > natural choice (assuming some form of as-yet-unimplemented package relay on
> > the P2P network) but is made difficult due to complexity around RBF/CPFP
> > 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 available
> > 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-spend
> > output. This transaction, B, will have a large absolute fee while making 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 memory
> > 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 size
> > 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 least
> > until/unless the prevailing feerates decline and some of the mempool backlog
> > 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') security
> >     model assumes the ability to get such commitment transactions confirmed in a
> >     timely manner, as otherwise HTLCs may time out and counterparties can claim
> >     the timeout-refund before we can claim the HTLC using the hash-preimage.
> >
> >
> > To partially-address the CPFP security model considerations, a next step
> > might involve tweaking Lightning's commitment transaction to have two
> > small-value outputs which are immediately spendable, one by each channel
> > participant, allowing them to chain children off without allowng unrelated
> > 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 transactions
> > 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 mempool
> >     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 criteria).
> >
> >
> > 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 transaction
> >     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 always
> >     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 discussions
> > around solving the "RBF-pinning" problem by allowing transactors to mark
> > 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 consistently,
> > as any "transaction-delaying" channel participant will have to place the
> > package containing A at an effective feerate which makes confirmation to
> > occur soon with some likelihood. It is, however, possible to pull off this
> > attack with low probability in case of feerate spikes right after broadcast.
> > Note that this clearly relies on some form of package relay, which comes
> > with its own challenges, but I'll start a separate thread on that.
> > See-also: lightning-dev thread about the changes to lightning spec required
> > to incorporate this: https://lists.linuxfoundation.org/pipermail/lightning-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