From: Antoine Riard <antoine.riard@gmail•com>
To: Yuval Kogman <nothingmuch@woobling•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
Date: Wed, 15 Feb 2023 03:33:24 +0000 [thread overview]
Message-ID: <CALZpt+HYinkSWvy56ky4KJrmLGaN1OxBy+6MOX6VkRgQu-7Y6g@mail.gmail.com> (raw)
In-Reply-To: <CAAQdECCDfmAmxvSWfTsiTz_0TecpA8zoryZzHT==mXDU0p-xoA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7669 bytes --]
> Apologies for not citing, I think I must have seen that before but
> only remembered the pinning variants, and so did not recall it at the
> time that I wrote this up, which I did rather hastily.
> However, I do think the adversary model should be broadened, as there
> is a potential positive externality to a party which simply wishes to
> get some witness data confirmed in a block while paying less than the
> market rate, without needing to assume time sensitive contracts in the
> threat model.
Please no apologies - Message matters more than the messenger in
open-source. Yes, on the adversary model I would like to note there is a
potential negative externality in the context of time-sensitive contract,
e.g
for a DLC with short-term maturity you can delay confirmation of the funding
transaction in function of the event outcome progression (e.g a basketball
quarters),
and if the outcome turns in your defavor, you just double-spend a funding
input.
> What I had in mind was the estimated witness size messages in the dual
> funding proposal and felt they would create a false sense of
> validation, specifically in the context of an adversary interested in
> having their ordinal inscriptions being paid for by someone else by
> subverting the a priori agreed upon feerate. From my point of view
> this is primarily an argument for RBF by default (ideally full RBF, as
> rule 3 of BIP 125 imposes difficult constraints on multiparty
> transaction construction) in such protocols.
We could have miniscript embedded in the backend of a Lightning
implementation, to reject any malleable witness (maybe with some tolerance
bounds ?),
to restrain a counterparty downgrading a posteriori its feerate
contribution.
Full rbf effectively would prevent timevalue DoS inflicted to the
most-utxo-value
contributor in dual-funding, however in the present flow, I don't know if it
changes something, the witness downgrading counterparty benefits from
a feerate discount, not lack of confirmation.
> Yes, that doesn't make things incentive compatible but allows the
> potential victims to have clearer bounds on the potential positive
> payoff to the adversary. I think that's mainly useful in conjunction
> constraining the order of signature submission, going from smallest to
> largest input seems intuitively compelling but it seems to me like
> ordering by feerate of creating transaction or perhaps some
> combination of the two might provide a stronger deterrent.
I think some combination of the two can makes sense, as if the feerate
is what you paid, the input value is your "economically subjective"
liquidity
risk, and as such you might pay a better signature submission place for
a feerate contribution increase. Quite sophisticated for the basic
dual-funding flow.
> Either way the main takeaway in my opinion is not that this is a
> serious attack, as it's hard to exploit in theory and as far as I know
> none of the currently deployed protocols are in any way vulnerable:
> 1. dual funding supports RBF and quite amenable to reputation based
mitigations
> 2. in JoinMarket the taker can protect themselves
> 3. centralized coinjoins, despite misleading claims to the contrary by
> both vendors, currently strongly rely on a trusted server for many
> other aspects of the protocol and all three protocols are not
> currently exploitable as described (the attacker can't broadcast the
> transaction with a witness that would otherwise be rejected by the
> server)
> ... but rather that (full) RBF is required for incentive compatible
> multiparty transactions (or the closest approximation of incentive
> compatibility possible barring future soft forks).
Yep yep, all types of DoS are less concerning than "loss of funds"
severity pinning attacks, and doesn't sounds to affect currently
deployed protocols. Still concerned all those DoS once accumulated
might be a "practical" show-stopper, like we have with channel jamming.
Le ven. 10 févr. 2023 à 19:35, Yuval Kogman <nothingmuch@woobling•org> a
écrit :
> On Wed, 8 Feb 2023 at 02:56, Antoine Riard <antoine.riard@gmail•com>
> wrote:
> > From what I understand, there are many inputs for the coinjoin
> transaction, the latest signer provides an inflated witness downgrading the
> multi-party transaction feerate.
>
> Yep!
>
> > It doesn't sound to me a fee siphoning as occurring with loose
> malleability [0], rather another case of transaction-relay jamming where
> the adversary's goal is to slow down the confirmation of the transaction to
> waste everyone timevalue.
> >
> > I think the issue has already been mentioned to advocate updating Core's
> mempool acceptance policy, and allows wtxid-replacement [1]. There is also
> a description available here [2].
>
> Yep, the mechanism is basically the same as witness malleability based
> jamming.
>
> Apologies for not citing, I think I must have seen that before but
> only remembered the pinning variants, and so did not recall it at the
> time that I wrote this up, which I did rather hastily.
>
> However, I do think the adversary model should be broadened, as there
> is a potential positive externality to a party which simply wishes to
> get some witness data confirmed in a block while paying less than the
> market rate, without needing to assume time sensitive contracts in the
> threat model.
>
> What I had in mind was the estimated witness size messages in the dual
> funding proposal and felt they would create a false sense of
> validation, specifically in the context of an adversary interested in
> having their ordinal inscriptions being paid for by someone else by
> subverting the a priori agreed upon feerate. From my point of view
> this is primarily an argument for RBF by default (ideally full RBF, as
> rule 3 of BIP 125 imposes difficult constraints on multiparty
> transaction construction) in such protocols.
>
> > I don't think increasing adversary costliness is that efficient as there
> is a scaling effect (e.g the feerate of the previous transaction can be
> used to feed N outputs for N dissociated attack contexts).
>
> Yes, that doesn't make things incentive compatible but allows the
> potential victims to have clearer bounds on the potential positive
> payoff to the adversary. I think that's mainly useful in conjunction
> constraining the order of signature submission, going from smallest to
> largest input seems intuitively compelling but it seems to me like
> ordering by feerate of creating transaction or perhaps some
> combination of the two might provide a stronger deterrent.
>
> Either way the main takeaway in my opinion is not that this is a
> serious attack, as it's hard to exploit in theory and as far as I know
> none of the currently deployed protocols are in any way vulnerable:
>
> 1. dual funding supports RBF and quite amenable to reputation based
> mitigations
> 2. in JoinMarket the taker can protect themselves
> 3. centralized coinjoins, despite misleading claims to the contrary by
> both vendors, currently strongly rely on a trusted server for many
> other aspects of the protocol and all three protocols are not
> currently exploitable as described (the attacker can't broadcast the
> transaction with a witness that would otherwise be rejected by the
> server)
>
> ... but rather that (full) RBF is required for incentive compatible
> multiparty transactions (or the closest approximation of incentive
> compatibility possible barring future soft forks).
>
[-- Attachment #2: Type: text/html, Size: 21674 bytes --]
prev parent reply other threads:[~2023-02-15 3:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 2:49 Yuval Kogman
2023-02-07 4:38 ` Lloyd Fournier
2023-02-07 9:36 ` Nadav Ivgi
2023-02-07 12:50 ` Peter Todd
2023-02-07 13:46 ` Andrew Poelstra
2023-02-07 18:10 ` Andrew Poelstra
2023-02-07 18:35 ` Russell O'Connor
2023-02-07 19:04 ` Peter Todd
2023-02-08 9:34 ` Michael Folkson
2023-02-08 14:00 ` Andrew Poelstra
2023-02-08 14:04 ` Russell O'Connor
2023-02-11 5:14 ` Anthony Towns
2023-02-11 14:40 ` Russell O'Connor
2023-02-12 6:47 ` Anthony Towns
2023-02-07 18:12 ` Peter Todd
2023-02-08 0:56 ` Antoine Riard
2023-02-10 19:35 ` Yuval Kogman
2023-02-15 3:33 ` Antoine Riard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZpt+HYinkSWvy56ky4KJrmLGaN1OxBy+6MOX6VkRgQu-7Y6g@mail.gmail.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=nothingmuch@woobling$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox