Oleg Andreev [ARCHIVE] on Nostr: 📅 Original date posted:2015-04-28 📝 Original message:> On 27 Apr 2015, at ...
📅 Original date posted:2015-04-28
📝 Original message:> On 27 Apr 2015, at 21:21, Peter Todd <pete at petertodd.org> wrote:
>
> Even right now there are edge cases without
> good solutions, like how in a multisig environment any of the key
> holders can mutate transactions.
Can't we add requirement for RFC6979 signatures to mitigate this? Of course, multiple signers can still mutate transaction by choosing a different set (but not the order, thankfully) of signatures. Or when a single signer has multiple participating keys.
In some interesting to me scenarios mutation by signer is not critical: it is mutation by non-signers that creates a problem. Do you know of any edge cases when non-signers can mutate transactions which are not covered by BIP62? What would be a more robust approach than "whack-a-mole" to work around mutability? (Normalized tx ids?)
📝 Original message:> On 27 Apr 2015, at 21:21, Peter Todd <pete at petertodd.org> wrote:
>
> Even right now there are edge cases without
> good solutions, like how in a multisig environment any of the key
> holders can mutate transactions.
Can't we add requirement for RFC6979 signatures to mitigate this? Of course, multiple signers can still mutate transaction by choosing a different set (but not the order, thankfully) of signatures. Or when a single signer has multiple participating keys.
In some interesting to me scenarios mutation by signer is not critical: it is mutation by non-signers that creates a problem. Do you know of any edge cases when non-signers can mutate transactions which are not covered by BIP62? What would be a more robust approach than "whack-a-mole" to work around mutability? (Normalized tx ids?)