Quote from: Bitalo_Maciej on March 10, 2014, 05:10:55 PM

Phil Dann Ward: There is one flaw in your protocol regarding lately discussed transaction malleability issue. You cannot be sure about a TXID of transaction until it is included in the blockchain (and even then, there could be a reorg later, but let's assume that's highly unlikely). And yet, this protocol relies on an assumption that a lock time transaction will be able to spend the funds using a specific TXID as an input. If in the mean time the TXID gets changed (someone manages to insert a modified version of the transaction in the blockchain), this will fail.

This problem (which is a problem for many Contract-style protocols) will gradually fade away as Bitcoin devs address the malleability issue somehow.

Bitalo_Maciej: I'm glad that you picked up on transaction malleability since it was one thing that I wasn't entirely sure that I'd adequately covered but I didn't think I'd got it so badly wrong that I bothered to explicitly raise it as one of my outstanding questions/requests; perhaps I should have.

I used bitcoin Contracts.Providing a Deposit (https://en.bitcoin.it/wiki/Contracts#Example_1:_Providing_a_deposit) algorithm as the basis of my algorithm where my IntermediateTx is equivalent to the 'Deposit' Tx1 and my ExpiryTx is equivalent to the 'Deposit' Tx2.

In 'Deposit', Tx2 spends Tx1 with reference to Tx1's transaction id and Tx2 will fail if Tx1 is changed. But Tx1 is controlled by the user and the user is the one who's keen to have Tx2 succeed in order for them to get their money back from Tx1. Therefore it's in the interest of the user not to invalidate Tx2 by changing Tx1. In 'Deposit', the website isn't so interested in the Tx1 transaction id itself but only in knowing that the deposit has been lodged in the dual signature (user+website) bitcoin account.

The interesting thing about 'Deposit' is that Tx1 and Tx2 are submitted together (by the user!) early in the algorithm and then, because Tx2 has two correct signatures, sequence number set to less than UINT_MAX and nLockTime greater than zero, Tx2 remains valid but outstanding (until nLockTime is reached) and malleable. In fact, the rest of the algorithm *relies* on the fact that Tx2 is malleable since it means that a new version of Tx2 can be mutually created by the user and the website to either return the deposit back to the user early or to extend the term of the deposit.

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.

The (assumed) latter deprecation is why, in my proposed algorithm, although Alice transmits IntermediateTx (which is under her control) she doesn't transmit ExpiryTx (which, with sequence number set UINT_MAX, isn't malleable) until after nLockTime has been reached and which, therefore, (assuming that it has two valid signatures - see below) is processed immediately thereafter.

Since ExpiryTx can't be left outstanding in the transaction queue (even if Alice submits it, possibly multiple times), it doesn't need to be malleable because a suitable, dual-signature PaymentTx (or a mutually agreed, different ExprityTx) can be submitted at any time to spend IntermediateTx...although only so long as the IntermediateTx transaction id is the same as referenced from PaymentTx (or ExpiryTx).

Bob makes sure that the IntermediateTx transaction id is referred to in both the ExpiryTx and PaymentTx (Step 0.10 and Step 0.11).

Alice wants to make sure that the IntermediateTx transaction id remains the same as that referred to in ExpiryTx (otherwise she'll never get her bitcoins back) and therefore, as far as Bob is concerned, Alice has an implicit incentive to ensure that the IntermediateTx transaction id remains the same as that referred to in PaymentTx.

Bob has an incentive to check that IntermediateTx (to the dual signature AliceBobAddr) is confirmed in the bitcoin network with the transaction id that he expects, matching that referred to in PaymentTx (Step 1.3), and that AliceBobAddr contains the right amount of Collateral+Payment (Step 1.4); that way he knows that he has some chance of getting the Payment amount from the PaymentTx so long as Alice eventually signs her part of PaymentTx and submits it once she's got the real world goods from Bob.

Beyond checking that the use of nLockTime greater than zero has effectively been deprecated, 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...and perhaps also indicating that IntermediateTx does not exist yet since Alice wouldn't want to submit IntermediateTx until after she's made a test submission of ExpiryTx to avoid forever locking up her bitcoins in AlicceBobAddr because, without an (eventually) valid ExpiryTx, she has no way of getting them back again?

The answers to my additional queries may change the validity of it but the algorithm is based around the parties who could make the transactions malleable not actually making them malleable because they have mutually dependent incentives not to make them malleable and have various opportunities to confirm that the transactions aren't malleable.

Anyway, thanks for your interest Bitalo_Maciej; I hope you can answer my questions and check if the algorithm still makes sense thereafter (and hopefully MPOE-PR won't mind that I've probably written too much again :-) ).