{"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:On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:\n\u003e \u003e On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e \u003e This doesn't completely close malleability (which should be documented\n\u003e in\n\u003e \u003e \u003e the BIP), so I'm not sure it's worth the cost, especially if closing\n\u003e \u003e \u003e malleability later on would need more. How about specifying flags\n\u003e upfront\n\u003e \u003e \u003e in the UTXO-creating transaction specifying which parts the signature\n\u003e \u003e \u003e will cover? This would allow implementation of fully malleability-proof\n\u003e \u003e \u003e wallets.\n\u003e \u003e\n\u003e \u003e As far as I see it the only remaining venues for malleability are the use\n\u003e \u003e of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any\n\u003e use\n\u003e \u003e of non-sighash_all flags is already an explicit permission to modify the\n\u003e \u003e transactions, by adding and removing inputs and outputs, so I don't see\n\u003e how\n\u003e \u003e these can be made non-malleable. Am I missing something?\n\u003e\n\u003e Signer malleability is still a notable concern needing consideration.\n\u003e Ideally,\n\u003e wallets should be trying to actively CoinJoin, bump fees on, etc any\n\u003e pending\n\u003e transactions in the background. These forms of malleability affect nearly\n\u003e as\n\u003e many real use cases as third-party malleability.\n\u003e\n\u003e Luke\n\u003e\n\nHow is signer malleability still a problem if we remove the signatures from\nthe transaction ID of the transaction and all preceding transactions? The\nsigner can re-sign a transaction but it won't change the transaction ID.\n\nIt is still possible to double-spend transactions that do not have enough\nfees, so just starting a new round of CoinJoin is sufficient to bump fees\nfor all parties that participate, and that would also result in the\ndouble-spent low fee transaction to be discarded, resolving the state of\nall coins in the first CoinJoin tx.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151021/87444434/attachment.html\u003e"}