Would love to hear PP chime in on this, as related to XCP. Changing a bit or two, or hiding BTC transaction, sounds like something that could be serious problems for XCP.
It’s not a bug in bitcoin, it’s a bug in mt gox
[quote author=blackbeard link=topic=81.msg393#msg393 date=1392066514]
It’s not a bug in bitcoin, it’s a bug in mt gox
[/quote]
Actually, it is a bug in the bitcoin protocol, an old and well documented one that MtGox “ignored”
I wouldn’t call not being able to trust unconfirmed transactions a bug.
[quote author=blackbeard link=topic=81.msg397#msg397 date=1392075091]
I wouldn’t call not being able to trust unconfirmed transactions a bug.
[/quote]
Yeah, but being able to replace the txid and relaying it instead of the original one is definitely a bug, even if the only known application was abusing MtGox.
I’m wondering like OP is this might have an impact over XCP protocol.
Bug or not, that’s semantics. We should be able to agree that it’s definitely not a feature. Let’s call it a concession. A compromise. An outstanding issue.
I just want PP or xnova to chime in and say something akin to “Look, aQuant, you’re worrying over nothing. XCP isn’t affected by this because we don’t use the txid for anything in our code, nor do we have any plans on ever needing to.”
Well, I’ll chime in. Because malleability only affects the txid and not pubkeys (which we use for multisig) nor OP-RETURN (which hasn’t even been implemented yet), I don’t see how that affectx XCP. You might say it could affect BTCpay, but then again no unconfirmed transactions appear in the DEX anyways, so I don’t see that as an issue.
Like I said, not being able to to trust unconfirmed transactions is not a bug, it is a feature
Sometimes it’s not about how nice your blender is, no matter the re-engineering it’ll never make a good airplane and its operating staff probably wouldn’t know how to fly a blender anyhow.