Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-03 🗒️ Summary of this message: A potential ...
📅 Original date posted:2023-06-03
🗒️ Summary of this message: A potential issue with transaction replacement in Bitcoin could mislead developers into thinking their transactions are immune to replacement. This occurs when a counter-party submits a strictly worse transaction for miners by bloating its weight, not adding fees. Mitigation methods are available.
📝 Original message:
>
> > Depending on policy to mitigate this annex malleability vector could
> mislead developers into believing their transactions are immune to
> replacement, when in fact they might not be.
>
> The issue I'm talking about is where someone's transaction is denied entry
> into the mempool entirely because a counter-party decided to put in a
> strictly worse transaction for miners by bloating the weight of it, not
> adding fees. A strictly worse "API" for paying miners for no gain seems
> like a bad trade to me, especially when there are reasonable methods for
> mitigating this.
>
Just to expand this, an example would be a transaction with inputs A' and
B' signed by two parties A and B. A has a fully signed transaction in
hands, but can't publish it because B created and published an alternative
version of it with a large annex for input B'. Wouldn't miners just accept
A's version because it's fee rate is higher? I am looking at this case
assuming the user has a direct connection to a miner, ignoring any
potential concerns related to p2p transport.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/08c8c4df/attachment-0001.html>;
🗒️ Summary of this message: A potential issue with transaction replacement in Bitcoin could mislead developers into thinking their transactions are immune to replacement. This occurs when a counter-party submits a strictly worse transaction for miners by bloating its weight, not adding fees. Mitigation methods are available.
📝 Original message:
>
> > Depending on policy to mitigate this annex malleability vector could
> mislead developers into believing their transactions are immune to
> replacement, when in fact they might not be.
>
> The issue I'm talking about is where someone's transaction is denied entry
> into the mempool entirely because a counter-party decided to put in a
> strictly worse transaction for miners by bloating the weight of it, not
> adding fees. A strictly worse "API" for paying miners for no gain seems
> like a bad trade to me, especially when there are reasonable methods for
> mitigating this.
>
Just to expand this, an example would be a transaction with inputs A' and
B' signed by two parties A and B. A has a fully signed transaction in
hands, but can't publish it because B created and published an alternative
version of it with a large annex for input B'. Wouldn't miners just accept
A's version because it's fee rate is higher? I am looking at this case
assuming the user has a direct connection to a miner, ignoring any
potential concerns related to p2p transport.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/08c8c4df/attachment-0001.html>;