{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-21\n📝 Original message:Hm, that is true as long as the signer is the only signer of the\ntransaction, otherwise he'd be invalidating the signatures of the other\nsigners. That can however be fixed by having a canonical ordering of Inputs\nand Outputs, which has been discussed before in order to decrease\ninformation that can be gained about the spender. Maybe we can defer to\nthat effort?\n\nOn Wed, Oct 21, 2015 at 10:41 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote:\n\u003e \u003e On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e \u003e On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:\n\u003e \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 \u003e This doesn't completely close malleability (which should be\n\u003e \u003e \u003e \u003e \u003e documented\n\u003e \u003e \u003e\n\u003e \u003e \u003e in\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e the BIP), so I'm not sure it's worth the cost, especially if\n\u003e closing\n\u003e \u003e \u003e \u003e \u003e malleability later on would need more. How about specifying flags\n\u003e \u003e \u003e\n\u003e \u003e \u003e upfront\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e in the UTXO-creating transaction specifying which parts the\n\u003e signature\n\u003e \u003e \u003e \u003e \u003e will cover? This would allow implementation of fully\n\u003e \u003e \u003e \u003e \u003e malleability-proof wallets.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e As far as I see it the only remaining venues for malleability are the\n\u003e \u003e \u003e \u003e use of sighash flags that are not SIGHASH_ALL, as mentioned in the\n\u003e \u003e \u003e \u003e BIP. Any\n\u003e \u003e \u003e\n\u003e \u003e \u003e use\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e of non-sighash_all flags is already an explicit permission to modify\n\u003e \u003e \u003e \u003e the transactions, by adding and removing inputs and outputs, so I\n\u003e \u003e \u003e \u003e don't see\n\u003e \u003e \u003e\n\u003e \u003e \u003e how\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e these can be made non-malleable. Am I missing something?\n\u003e \u003e \u003e\n\u003e \u003e \u003e Signer malleability is still a notable concern needing consideration.\n\u003e \u003e \u003e Ideally,\n\u003e \u003e \u003e wallets should be trying to actively CoinJoin, bump fees on, etc any\n\u003e \u003e \u003e pending\n\u003e \u003e \u003e transactions in the background. These forms of malleability affect\n\u003e nearly\n\u003e \u003e \u003e as\n\u003e \u003e \u003e many real use cases as third-party malleability.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Luke\n\u003e \u003e\n\u003e \u003e How is signer malleability still a problem if we remove the signatures\n\u003e from\n\u003e \u003e the transaction ID of the transaction and all preceding transactions? The\n\u003e \u003e signer can re-sign a transaction but it won't change the transaction ID.\n\u003e\n\u003e The signer can also change the order of the inputs, the inputs themselves,\n\u003e add/remove outputs, etc... all which should be possible without becoming a\n\u003e different logical transaction. The only unique property of the logical\n\u003e transaction is the scriptPubKey/address.\n\u003e\n\u003e Luke\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/c06fc8ff/attachment.html\u003e"}