Date: Mon, 03 Dec 2018 04:16:10 +0000
To: Bob McElrath <bob@mcelrath.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <8-tJwX51A0xFHoEsKchKREO5i8YxqM48JWspLRiAV3TBHWrRUkUmcZqbAJH6Z6KBQAppPHwuClmzzoaLxtOQqWoHyQG8nzVJAuzAFFGl-s8=@protonmail.com>
In-Reply-To: <20181202150839.GE22873@mcelrath.org>
References: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>
	<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
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)
Precedence: list

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 <bob@mcelrath.org> 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