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