[bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
## 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 not 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 force. ### 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
Re: [bitcoin-dev] Ordinal Inscription Size Limits
there are already images encoded in the chain using multisig. when we eliminated the max-witness size in 2017, that made it a bit cheaper, that's all (one tx instead of many) https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html my favorite one is the javascript exploit for people that like to render untrusted blockchain data in their browser the script to interpret these is trivial, and it's not much harder to add a mime type On Mon, Feb 6, 2023 at 12:34 PM Claus Ehrenberg via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The inscriptions are designed to be easy to use, they even specify that > mime types should be used. I'd say, the way the data is stored is anything > but 'obscure'. UIs will be popping up to make this really easy. The main > chain can't be censored, what's in a block is in a block. I'm predicting a > huge success. > > So, are we ready to accept that we'll likely see the first pictures with > insults or worse in the Bitcoin chain? I really like the idea, but the risk > is pretty obvious. I think it would be prudent to have at least an opt-out > feature for the data. So that it's possible to use the chain without the > potentially malicious content. That means the content shouldn't live in the > essential data of the main chain. Better would be something like the > extension blocks in Litecoin. > > Best Regards > Claus > > On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I'm curious what opinions exist and what actions might be taken by core >> developers regarding storing unlimited amounts of NFT (or other?) content >> as witness data (https://docs.ordinals.com/inscriptions.html). The >> ordinal scheme is elegant and genius IMHO, but when I think about the >> future disk use of all unpruned nodes, I question whether unlimited storage >> is wise to allow for such use cases. Wouldn't it be better to find a way to >> impose a size limit similar to OP_RETURN for such inscriptions? >> >> I think it would be useful to link a sat to a deed or other legal >> construct for proof of ownership in the real world, so that real property >> can be transferred on the blockchain using ordinals, but storing the >> property itself on the blockchain seems nonsensical to me. >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
The inscriptions are designed to be easy to use, they even specify that mime types should be used. I'd say, the way the data is stored is anything but 'obscure'. UIs will be popping up to make this really easy. The main chain can't be censored, what's in a block is in a block. I'm predicting a huge success. So, are we ready to accept that we'll likely see the first pictures with insults or worse in the Bitcoin chain? I really like the idea, but the risk is pretty obvious. I think it would be prudent to have at least an opt-out feature for the data. So that it's possible to use the chain without the potentially malicious content. That means the content shouldn't live in the essential data of the main chain. Better would be something like the extension blocks in Litecoin. Best Regards Claus On Fri, Jan 27, 2023 at 1:47 PM Robert Dickinson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'm curious what opinions exist and what actions might be taken by core > developers regarding storing unlimited amounts of NFT (or other?) content > as witness data (https://docs.ordinals.com/inscriptions.html). The > ordinal scheme is elegant and genius IMHO, but when I think about the > future disk use of all unpruned nodes, I question whether unlimited storage > is wise to allow for such use cases. Wouldn't it be better to find a way to > impose a size limit similar to OP_RETURN for such inscriptions? > > I think it would be useful to link a sat to a deed or other legal > construct for proof of ownership in the real world, so that real property > can be transferred on the blockchain using ordinals, but storing the > property itself on the blockchain seems nonsensical to me. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Ordinal Inscription Size Limits
its trivial to store images in such a way that they look like legit transactions. this was done, in the past, using large numbers of multisig output addresses that encode the images. given the goals of the project, introducing this sort of censorship into bitcoin seems fundamentally undesirable ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case
On Sat, Feb 4, 2023 at 6:28 PM Peter Todd wrote: > On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote: > > We have standard commercial information about the payment processors, non > > custodial liquidity providers and merchants which become our clients - we > > do not have any kyc/aml information or telephone number on who is sending > > our clients the bitcoin for deposit. For us these are just bitcoin Trx > > which our clients choose to benefit from 0-conf deposit recognition. Our > > service is provided via API with the only information our clients share > > with us, regarding a specific bitcoin transaction, being public bitcoin > > information like trx hash and output address. > > You know who your clients are, and thus every request for information on a > transaction is reasonably likely to be a deposit associated with the > client who > requested it. Learning what addresses are associated with what entity is a > significant benefit to Chainalysis operations, and there's every reason to > expect that the data you learn will either be sold or leaked to Chainalysis > companies. > I would estimate based on general discussions with clients and open research more than 90% of our clients use different AML trx analysis service providers for trx deposited on their platforms - completely irrelevant to us or 0-conf. So if these clients were to stop recognising 0-conf this would have no impact on these AML service providers access to the data. We service payment processors and liquidity providers and have little or no insight into which wallets or merchants our clients service. Further to this many of the cluster addresses of our clients and just like other service providers in the bitcoin space are publicly known - just as Max had no issue sharing the cluster of his deposit address in his email which I posted to the list. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
