{"type":"rich","version":"1.0","author_name":"npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","author_url":"https://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-21\n📝 Original message:On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:\n\u003e On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:\n\u003e \u003e \u003e On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e \u003e \u003e This doesn't completely close malleability (which should be\n\u003e \u003e \u003e \u003e documented\n\u003e \u003e \n\u003e \u003e in\n\u003e \u003e \n\u003e \u003e \u003e \u003e the BIP), so I'm not sure it's worth the cost, especially if closing\n\u003e \u003e \u003e \u003e malleability later on would need more. How about specifying flags\n\u003e \u003e \n\u003e \u003e upfront\n\u003e \u003e \n\u003e \u003e \u003e \u003e in the UTXO-creating transaction specifying which parts the signature\n\u003e \u003e \u003e \u003e will cover? This would allow implementation of fully\n\u003e \u003e \u003e \u003e malleability-proof wallets.\n\u003e \u003e \u003e \n\u003e \u003e \u003e As far as I see it the only remaining venues for malleability are the\n\u003e \u003e \u003e use of sighash flags that are not SIGHASH_ALL, as mentioned in the\n\u003e \u003e \u003e BIP. Any\n\u003e \u003e \n\u003e \u003e use\n\u003e \u003e \n\u003e \u003e \u003e of non-sighash_all flags is already an explicit permission to modify\n\u003e \u003e \u003e the transactions, by adding and removing inputs and outputs, so I\n\u003e \u003e \u003e don't see\n\u003e \u003e \n\u003e \u003e how\n\u003e \u003e \n\u003e \u003e \u003e these can be made non-malleable. Am I missing something?\n\u003e \u003e \n\u003e \u003e Signer malleability is still a notable concern needing consideration.\n\u003e \u003e Ideally,\n\u003e \u003e wallets should be trying to actively CoinJoin, bump fees on, etc any\n\u003e \u003e pending\n\u003e \u003e transactions in the background. These forms of malleability affect nearly\n\u003e \u003e as\n\u003e \u003e many real use cases as third-party malleability.\n\u003e \u003e \n\u003e \u003e Luke\n\u003e \n\u003e How is signer malleability still a problem if we remove the signatures from\n\u003e the transaction ID of the transaction and all preceding transactions? The\n\u003e signer can re-sign a transaction but it won't change the transaction ID.\n\nThe signer can also change the order of the inputs, the inputs themselves, \nadd/remove outputs, etc... all which should be possible without becoming a \ndifferent logical transaction. The only unique property of the logical \ntransaction is the scriptPubKey/address.\n\nLuke"}