William Swanson [ARCHIVE] on Nostr: 📅 Original date posted:2015-04-24 📝 Original message:On Thu, Apr 16, 2015 at ...
📅 Original date posted:2015-04-24
📝 Original message:On Thu, Apr 16, 2015 at 9:12 AM, s7r <s7r at sky-ip.org> wrote:
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
The BIP 62 approach to malleability isn't the only option. Another
approach is to sign the transaction in such a way that the input
txid's are allowed to change without invalidating the signatures. That
way, if malleability happens, you just adjust you transaction to match
and re-broadcast. That proposal is here:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
The "Build your own nHashType" thread on this mailing list contains
the discussion.
I personally prefer this solution, since it nails the problem
completely with one simple and obvious change. The BIP 62 approach is
more like a game of wac-a-mole.
-William
📝 Original message:On Thu, Apr 16, 2015 at 9:12 AM, s7r <s7r at sky-ip.org> wrote:
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
The BIP 62 approach to malleability isn't the only option. Another
approach is to sign the transaction in such a way that the input
txid's are allowed to change without invalidating the signatures. That
way, if malleability happens, you just adjust you transaction to match
and re-broadcast. That proposal is here:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
The "Build your own nHashType" thread on this mailing list contains
the discussion.
I personally prefer this solution, since it nails the problem
completely with one simple and obvious change. The BIP 62 approach is
more like a game of wac-a-mole.
-William