Topic: Instant TX for established business relationships (need replacements/nLockTime) - page 2. (Read 6081 times)

I think you must be misunderstanding something or my post was not clear because there is no security risk in this scheme.  This is not "slightly less risky instant transactions".  This is indeed "zero-risk" instant transactions, where "zero risk" means the same level of risk as non-instant transactions.  The catch is that the money can only be spent to one person.  Intuitively, double-spending is trivial to prevent if each piece of money is tagged so that it can only go to one person!
Please describe exactly how one could cheat the other if they both follow this scheme.

Here are two subtle points incase you are not understanding why they are crucial:
1) You must get a sig from the other party on txB before you sign txA.   Otherwise, the money could be stuck.
2) The other party should not sign any TxB replacements he receives until he is ready to broadcast the final one.  That is, the TxB replacements are signed by one person (the person paying more money), and then held by the other party.  The other party keeps them to himself until they are ready to settle the balance, at which point he signs that replacement.  Since any update requires BOTH signatures, the first party cannot single-handedly make ANY update without approval from the second party.

I think (2) is what you are missing.  TxA was written so it requires 2 sigs to spend.  So the payer can't just broadcast an earlier version of TxB.
Note the TxB replacements are not increasing in sequence number -- they are FINAL, and not time-locked.

In other words, there will only EVER be TWO valid TX spending TxA:
- The very first one, giving it back to the first person.  This is replaceable and uses nLockTime at say, 30 days in the future.
- The very last replacement sent by the first person to the second.  This is not replacable and is locked immediately.  The second person does not sign any of the others, thus they are never actually valid replacements.

So the second person just keeps a bunch of half-transactions in his pocket, until it gets to say, 5 days before the first TX will expire.  Then he decides to settle the balance, by signing and broadcasting the last half-signed TX he received (the one giving him the most money).  At this point, should they decide to continue the business relationship, they repeat.

Actually, I thought about this for a long time and I now think it might have some uses.

At first I thought that tx A could be broadcast without signing tx B, which would allow the withdrawer to burn coins. But the site just needs to count BTC as temporarily withdrawn until tx B is signed.

Then I thought that the side sending tx A would have a long time to generate a block and choose any version of tx B they want, ignoring sequence. But they'll actually have only tens of minutes to do this.

The risk still seems unacceptable for most sites. The attacker can't easily use network-based attacks as with regular 0-confirmation transactions, but they still only need to solve one block, and they can try the attack many times without cost until it works. Maybe the method could be used if other security measures were taken, such as delaying USD withdrawals out of exchanges.

I don't understand.  Once you have signed a TX and sent it to mtgox, he has the money.  He just chooses not to broadcast it until later, so that rather than paying a TX fee/waiting for every small deposit/withdraw, you only do this when you want to.  You cannot cheat mtgox out of money...

I wouldn't really consider MtGox full-reserve if they did that, since someone could "burn" their deposits.

Yet more reason for replacements/nLockTime to be turned on, you would never need an "account" on mtgox that you had to deposit more than you were going to immediately use into.

In general long-term business relationships can agree to just "settle it in the blockchain later", but still do it in a way that neither can screw the other.
 
1) Do the "standard escrow setup":
    a) Write Tx A w/ output spendable by sig from you AND mtgox, don't sign it yet.
    b) Write Tx B spending Tx A back to you with nLockTime some time in the future and seq number 0.
    c) Hand mtgox both these *unsigned* (don't sign TxA until he has signed TxB), demand he sign them, get them back and sign them, broadcast them.

2) For quick withdraw, mtgox can do the same thing in reverse with you.

3) To start off, Tx B has seq 0 and gives all coins in TxA back to you.  When you need to give mtgox money, you send him a signed replacement of
TxB that is final, and sends some of TxA to him and the rest back to you.  These are all offline, not sent to network.

4) As you need to give more money, you send new replacements for TxB giving more to mtgox and less to yourself.  Again these are all offline.

5) Finally, sometime before the original TxB expires, mtgox should broadcast the last signed replacement you gave him (the one that gives him the most money).
 

In this scheme, money is tied up, but still cannot be spent by the other party without authorization from you.  On the other hand, you can provide that authorization to them instantly offline of the blockchain.