path: root/ce/d319fdcbab59504a532b494d814000864aa670

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 29872C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Feb 2023 00:56:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id EC90C40B61
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Feb 2023 00:56:43 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EC90C40B61
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=ImiNbYZE
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wBQPltXsJq9V
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Feb 2023 00:56:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 79505404B3
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com
 [IPv6:2607:f8b0:4864:20::12b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 79505404B3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Feb 2023 00:56:42 +0000 (UTC)
Received: by mail-il1-x12b.google.com with SMTP id l7so6832554ilf.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 07 Feb 2023 16:56:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=Rv356yVXCn9c6w8kH0VDy2Clvbno/em0it6yXfsQa5o=;
 b=ImiNbYZEI8yjlamu6u7Co15IM9JFgHTFdJYV46dzF0B9N2WbI45rqLeGTPAwxbr68X
 qMxfMRpYq+n9Xo2Lf3NdmuUGkRypqoihNa+PlbJmlVsm3guDZJasADFIbp7itTyEreNb
 2twTsmNMDqFGGjIgKt4bmGmajj3Vh390Eh8eYZVsH+/gW5aLWrR0d7V1RL28RmssdkKV
 itG/p4WJ5IS7MQA+Krmd1zeMGj9JnyeoJKsLR7rXjsAR484BhXTRxzZTWIq8YuFOp/Lc
 x0djmjzTpyjDcCKSgoJ4HFiiLBBjs+oPwKvP6Phe0Svas8IB+dRSW6XKZTdMFkVGPsmH
 UrSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=Rv356yVXCn9c6w8kH0VDy2Clvbno/em0it6yXfsQa5o=;
 b=HH9tcRZRQZRSFYTKNllrp0JGKihryw4cFElK0QRK06ABPji1gCJdusYVuQDNf/Zv8E
 P9oGl5NMtd4BeMYPt5fMc/WQ7NSIEZrtcimtF8SPxgc5tP7MimdKop7HkIbnX5SEhaW6
 1ohmHuK2YLL1EFAS5q/jhXqNP9//xxsTKHY5zsRH/C7bmL4dN0rbYNgjR/xnwvpfQLsK
 i4OheN9trFAJcBwxrW9vLKwAK5a2pCvxaUgrwBB/GzO8Pn8gptRTlyhCjgxOncK9Cj1M
 gLGGiSMxKegLDLQCA3Quj1in5JHJS8WyjF5/Z3aSeFS99mZYw7n6DwqpVfI7pYVFx9fW
 v7wQ==
X-Gm-Message-State: AO0yUKU0netMpzumvcvYIRlOXjyL8ovXOBXfX1E2wKkL0zU38dZSZ7j+
 mWHd5GSghDtyDUBPC5MoFykN1fCS3TIPH4udLi0YlR9gg843Tg==
X-Google-Smtp-Source: AK7set/j/NesTyCUARNRZNp3A3ex9ujzhe/0NBrlWNja4uuA49RIIo3BBrb9xCdi5/39TBiBd9nKN8w2bZvYvmKY2Vc=
X-Received: by 2002:a92:5413:0:b0:30e:f98e:126c with SMTP id
 i19-20020a925413000000b0030ef98e126cmr3348053ilb.43.1675817801374; Tue, 07
 Feb 2023 16:56:41 -0800 (PST)
MIME-Version: 1.0
References: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
In-Reply-To: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 8 Feb 2023 00:56:30 +0000
Message-ID: <CALZpt+E2XKmqAELcedN8-5JkCOwmEH-CN8nwmpwW74xGUZPtbA@mail.gmail.com>
To: Yuval Kogman <nothingmuch@woobling.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c263af05f425bcbd"
X-Mailman-Approved-At: Wed, 08 Feb 2023 02:06:56 +0000
Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty
 protocols with Taproot inputs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Feb 2023 00:56:44 -0000

--000000000000c263af05f425bcbd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Yuval,


> Since the absolute fee amount is already committed to by the provided

> (`SIGHASH_ALL`) signatures but the total transaction weight is not,
Mallory can

> broadcast any valid signatures up to the maximum standard weight and
minimum

> relay fees, or in collusion with a miner, up to consensus limits.

>

> This effectively steals a fee from Alice et al, as their signatures do no=
t

> commit to a feerate directly or indirectly.


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. 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].


To mitigate, among the peer-to-peer style of mitigations, one is of course =
a
reputation strategy or monetary strategy, where the asymmetries in
counterparties reputation are compensated with out-of-band
fees/credentials. 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). Signature ordering supposes also a reputation basis, and it
doesn't exclude giving a transaction construction edge to the reputational
counterparty (e.g a LSP "promising" a dual-funding UTXO to X distinct
participant, picking up the first to yield back a signature).


Best,

Antoine


[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/00=
2796.html

[1] https://github.com/bitcoin/bitcoin/pull/19645

[2]
https://gist.github.com/ariard/7e509bf2c81ea8049fd0c67978c521af#witness-mal=
leability

Le mar. 7 f=C3=A9vr. 2023 =C3=A0 02:59, Yuval Kogman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> ## Summary
>
> Since Taproot (more generally any kind of MAST) spends have variable size
> which
> depends on the path being used, the last such input to be signed in a
> multiparty
> transaction can always use a larger than estimated signature to unfairly
> extract
> a fee contribution from the other parties to the transaction (keeping the
> absolute fees the same and reducing the feerate for the transaction).
>
> ## Attack Scenario
>
> Alice et al wish to perform a multiparty transaction, such as a CoinJoin =
or
> lightning dual funding at a relatively high feerate.
>
> Mallory has a P2TR output with a large script spend path, e.g. an ordinal
> inscription commitment transaction output.
>
> Mallory registers this coin as an input into the multiparty transaction
> with a
> fee obligation calculated on the basis of a key spend. When all other
> participants have provided signatures, the script spend path can be used.
>
> Since the absolute fee amount is already committed to by the provided
> (`SIGHASH_ALL`) signatures but the total transaction weight is not,
> Mallory can
> broadcast any valid signatures up to the maximum standard weight and
> minimum
> relay fees, or in collusion with a miner, up to consensus limits.
>
> This effectively steals a fee from Alice et al, as their signatures do no=
t
> commit to a feerate directly or indirectly.
>
> ## Mitigations
>
> ### RBF
>
> All parties could negotiate a (series of) transaction(s) ahead of time at=
 a
> lower feerate, giving a lower bound minimum feerate that Mallory can forc=
e.
>
> ### Minimum Weight Before Signing
>
> Enforcing a minimal weight for all non-witness data in the transaction
> before
> the transaction is considered fully constructed can limit the
> effectiveness of
> this attack, since the difference between the predicted weight and the
> maximum
> weight decreases.
>
> ### Trusted Coordinator
>
> In the centralized setting if BIP-322 ownership proofs are required for
> participation and assuming the server can be trusted not to collude with
> Mallory, the server can reject signatures that do not exercise the same
> spend
> path as the ownership proof, which makes the ownership proof a commitment
> to the
> spend weight of the input.
>
> ### Reputation
>
> Multiparty protocols with publicly verifiable protocol transcripts can be
> provided as weak evidence of a history of honest participation in
> multiparty
> transactions.
>
> A ring signature from keys used in the transaction or its transcript
> committing
> to the new proposed transaction can provide weak evidence for the honesty
> of the
> peer.
>
> Such proofs are more compelling to an entity which has participated in
> (one of)
> the transcripts, or proximal transactions. Incentives are theoretically
> aligned
> if public coordinators publish these transcripts as a kind of server
> reputation.
>
> ### Increasing Costliness
>
> A minimum feerate for the previous transaction or a minimum confirmation
> age
> (coindays destroyed implies time value, analogous to fidelity bonds) can =
be
> required for inputs to be added, in order to make such attacks less
> lucrative
> (but there is still a positive payoff for the attacker).
>
> ### Signature Ordering
>
> Signatures from potentially exploitative inputs can be required ahead of
> legacy
> or SegWit v0 ones. The prescribed order can be determined based on
> reputation or
> costliness as described in the previous paragraphs.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000c263af05f425bcbd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p style=3D"margin:0px;font-stretch:normal;line-height:nor=
mal;color:rgb(0,0,0)"><span style=3D"font-variant-ligatures:no-common-ligat=
ures"><font face=3D"arial, sans-serif">Hi Yuval,</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; Since the absolute fee amount is already commit=
ted to by the provided</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; (`SIGHASH_ALL`) signatures but the total transa=
ction weight is not, Mallory can</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; broadcast any valid signatures up to the maximu=
m standard weight and minimum</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; relay fees, or in collusion with a miner, up to=
 consensus limits.</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt;<span class=3D"gmail-Apple-converted-space">=C2=
=A0</span></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; This effectively steals a fee from Alice et al,=
 as their signatures do not</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; commit to a feerate directly or indirectly.</fo=
nt></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">From what I understand, there are many inputs=C2=A0<=
/font></span><span style=3D"font-family:arial,sans-serif">for the coinjoin =
transaction, the latest signer provides an inflated witness=C2=A0</span><sp=
an style=3D"font-family:arial,sans-serif">downgrading the multi-party trans=
action feerate. It doesn&#39;t sound to me a=C2=A0</span><span style=3D"fon=
t-family:arial,sans-serif">fee siphoning as </span>occurring<span style=3D"=
font-family:arial,sans-serif"> with loose malleability [0], rather another =
case=C2=A0</span><span style=3D"font-family:arial,sans-serif">of transactio=
n-relay jamming where the adversary&#39;s goal is to slow down the=C2=A0</s=
pan><span style=3D"font-family:arial,sans-serif">confirmation of the transa=
ction to waste everyone timevalue.</span></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0);min-height:13px"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><font face=3D"arial, sans-serif"><span style=3D"font-variant-ligatures=
:no-common-ligatures">I think the issue has already been mentioned to advoc=
ate updating Core&#39;s mempool acceptance=C2=A0</span>policy, and allows w=
txid-replacement [1]. There is also a description available here [2].</font=
></p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0);min-height:13px"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><font face=3D"arial, sans-serif"><span style=3D"font-variant-ligatures=
:no-common-ligatures">To mitigate, among the peer-to-peer style of mitigati=
ons, one is of course=C2=A0</span>a reputation strategy or monetary strateg=
y, where the asymmetries in counterparties reputation are compensated with =
out-of-band fees/credentials. I don&#39;t think increasing adversary costli=
ness 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 attac=
k contexts). Signature ordering supposes also a reputation basis, and it do=
esn&#39;t exclude giving a transaction construction edge to the reputationa=
l counterparty (e.g a LSP &quot;promising&quot; a dual-funding UTXO to X di=
stinct participant, picking up the first to yield back a signature).</font>=
</p>
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0);min-height:13px"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Best,</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Antoine</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[0] <a href=3D"https://lists.linuxfoundation.org/pip=
ermail/lightning-dev/2020-September/002796.html">https://lists.linuxfoundat=
ion.org/pipermail/lightning-dev/2020-September/002796.html</a></font></span=
></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[1] <a href=3D"https://github.com/bitcoin/bitcoin/pu=
ll/19645">https://github.com/bitcoin/bitcoin/pull/19645</a></font></span></=
p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[2] <a href=3D"https://gist.github.com/ariard/7e509b=
f2c81ea8049fd0c67978c521af#witness-malleability">https://gist.github.com/ar=
iard/7e509bf2c81ea8049fd0c67978c521af#witness-malleability</a></font></span=
></p></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">Le=C2=A0mar. 7 f=C3=A9vr. 2023 =C3=A0=C2=A002:59, Yuval Kogman via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddin=
g-left:1ex">## Summary<br>
<br>
Since Taproot (more generally any kind of MAST) spends have variable size w=
hich<br>
depends on the path being used, the last such input to be signed in a multi=
party<br>
transaction can always use a larger than estimated signature to unfairly ex=
tract<br>
a fee contribution from the other parties to the transaction (keeping the<b=
r>
absolute fees the same and reducing the feerate for the transaction).<br>
<br>
## Attack Scenario<br>
<br>
Alice et al wish to perform a multiparty transaction, such as a CoinJoin or=
<br>
lightning dual funding at a relatively high feerate.<br>
<br>
Mallory has a P2TR output with a large script spend path, e.g. an ordinal<b=
r>
inscription commitment transaction output.<br>
<br>
Mallory registers this coin as an input into the multiparty transaction wit=
h a<br>
fee obligation calculated on the basis of a key spend. When all other<br>
participants have provided signatures, the script spend path can be used.<b=
r>
<br>
Since the absolute fee amount is already committed to by the provided<br>
(`SIGHASH_ALL`) signatures but the total transaction weight is not, Mallory=
 can<br>
broadcast any valid signatures up to the maximum standard weight and minimu=
m<br>
relay fees, or in collusion with a miner, up to consensus limits.<br>
<br>
This effectively steals a fee from Alice et al, as their signatures do not<=
br>
commit to a feerate directly or indirectly.<br>
<br>
## Mitigations<br>
<br>
### RBF<br>
<br>
All parties could negotiate a (series of) transaction(s) ahead of time at a=
<br>
lower feerate, giving a lower bound minimum feerate that Mallory can force.=
<br>
<br>
### Minimum Weight Before Signing<br>
<br>
Enforcing a minimal weight for all non-witness data in the transaction befo=
re<br>
the transaction is considered fully constructed can limit the effectiveness=
 of<br>
this attack, since the difference between the predicted weight and the maxi=
mum<br>
weight decreases.<br>
<br>
### Trusted Coordinator<br>
<br>
In the centralized setting if BIP-322 ownership proofs are required for<br>
participation and assuming the server can be trusted not to collude with<br=
>
Mallory, the server can reject signatures that do not exercise the same spe=
nd<br>
path as the ownership proof, which makes the ownership proof a commitment t=
o the<br>
spend weight of the input.<br>
<br>
### Reputation<br>
<br>
Multiparty protocols with publicly verifiable protocol transcripts can be<b=
r>
provided as weak evidence of a history of honest participation in multipart=
y<br>
transactions.<br>
<br>
A ring signature from keys used in the transaction or its transcript commit=
ting<br>
to the new proposed transaction can provide weak evidence for the honesty o=
f the<br>
peer.<br>
<br>
Such proofs are more compelling to an entity which has participated in (one=
 of)<br>
the transcripts, or proximal transactions. Incentives are theoretically ali=
gned<br>
if public coordinators publish these transcripts as a kind of server reputa=
tion.<br>
<br>
### Increasing Costliness<br>
<br>
A minimum feerate for the previous transaction or a minimum confirmation ag=
e<br>
(coindays destroyed implies time value, analogous to fidelity bonds) can be=
<br>
required for inputs to be added, in order to make such attacks less lucrati=
ve<br>
(but there is still a positive payoff for the attacker).<br>
<br>
### Signature Ordering<br>
<br>
Signatures from potentially exploitative inputs can be required ahead of le=
gacy<br>
or SegWit v0 ones. The prescribed order can be determined based on reputati=
on or<br>
costliness as described in the previous paragraphs.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c263af05f425bcbd--