Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-03 🗒️ Summary of this message: The issue ...
📅 Original date posted:2023-06-03
🗒️ Summary of this message: The issue discussed is the malleability of the wtxid, which can mislead developers into thinking their transactions are immune to replacement.
📝 Original message:No in this case the txid is identical. Only the wtxid is malleated, with
annex data stuffed to max transaction size.
Cheers,
Greg
On Sat, Jun 3, 2023, 8:36 AM Joost Jager <joost.jager at gmail.com> wrote:
> > 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/49e83857/attachment.html>;
🗒️ Summary of this message: The issue discussed is the malleability of the wtxid, which can mislead developers into thinking their transactions are immune to replacement.
📝 Original message:No in this case the txid is identical. Only the wtxid is malleated, with
annex data stuffed to max transaction size.
Cheers,
Greg
On Sat, Jun 3, 2023, 8:36 AM Joost Jager <joost.jager at gmail.com> wrote:
> > 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/49e83857/attachment.html>;