Quote from: Bitalo_Maciej on March 13, 2014, 09:18:43 AM

Quote from: Phil Dann Ward on March 12, 2014, 12:43:44 AM

But what I'd picked up in my reading (perhaps wrongly but please feel free to correct me) was that the bitcoin protocol had been changed (I assume, after the Contracts.Providing a Deposit algorithm had been expounded) to effectively deprecate the use of nLockTime greater than zero in a transaction since such a transaction will be immediately marked as invalid and deleted from the transaction queue.

That's correct, transactions with lock time set in the future are considered non-standard and won't be relayed. This is to prevent possible DOS attacks where you could spam the network with such transactions.

Quote from: Phil Dann Ward on March 12, 2014, 12:43:44 AM

I have an additional query about how Alice can know that ExpiryTx is otherwise valid apart from having not yet reached its nLockTime, i.e. that it has two valid signatures, without submitting it to the bitcoin network? And if the only way for Alice to check that ExpiryTx as two valid signatures is to submit it then does the bitcoin network give a nuanced report of the transaction's validity, e.g. indicating that the signatures are valid even if the nLockTime is invalid

You can check that the transaction is valid yourself:
- you can decode it to see if all parameters are ok - all outputs are pointing where they should be, and the nLockTime is properly set
- you can pick signatures from inputs and check them yourself using the same algorithms that Bitcoin software uses

That said, I have a feeling that we misunderstood ourselves regarding the use of some terminology. When I'm referring to "transaction malleability", I'm not talking about ability for the author of the transaction to submit a new version of it based on lock time parameter. I'm talking about someone else (let's call her Eve) being able to tweak certain tx parameters in a way that the signature is still valid, but the TXID is different. This can happen without Eve knowing Bob or Alice - she can set up a node that will catch transactions as they propagate in the network and re-submit them with tweaked parameters. She won't gain anything by doing this, but she can mess up with software and protocols that expect that TXID's don't change, effectively pulling of a DOS attack on those.

Ah, OK, yes, I get your point re: a malicious (or even just mischievous), unknown third party having the chance to usurp a transaction that's has just been legitimately submitted.

My take away from this is that currently, *any*(?) algorithm that relies on tying together consecutive bitcoin transactions without being able to wait for each transaction to be confirmed is susceptible to failure due to malleability...unless an alternative version of the algorithm can be conceived that is able to detect that *a* 'suitable' transaction has taken place, identify the transaction in question and then create the next transaction in the sequence.

So in the case of my proposed algorithm, if IntermediateTx is usurped by malleability then if Bob is unwilling or unable to create new ExpiryTx and PaymentTx transactions for Alice then her Collateral+Payment bitcoins will be stuck in AliceBobAddr and therefore lost to her forever.

That sounds like quite a serious flaw in my proposed algorithm so I don't think that it's a practical proposition until bitcoin transactions are made non-malleable. :-(

Thanks for the info; I really appreciate it.

Phil Dann Ward

Posts

Merits