Topic: Alt chains and atomic transfers - page 3. (Read 27381 times)

Thanks for the great explanation, now it's all clear.

Sounds reasonable.

A picks a random number x

A creates TX1: "Pay w BTC to if (x for H(x) known and signed by B) or (signed by A & B)"

A creates TX2: "Pay w BTC from TX1 to , locked 48 hours in the future, signed by A"

A sends TX2 to B

B signs TX2 and returns to A

1) A submits TX1 to the network

B creates TX3: "Pay v alt-coins to if (x for H(x) known and signed by A) or (signed by A & B)"

B creates TX4: "Pay v alt-coins from TX3 to , locked 24 hours in the future, signed by B"

B sends TX4 to A

A signs TX4 and sends back to B

2) B submits TX3 to the network

3) A spends TX3 giving x

4) B spends TX1 using x

This is atomic (with timeout).  If the process is halted, it can be reversed no matter when it is stopped.

Before 1: Nothing public has been broadcast, so nothing happens
Between 1 & 2: A can use refund transaction after 48 hours to get his money back
Between 2 & 3: B can get refund after 24 hours.  A has 24 more hours to get his refund
After 3: Transaction is completed by 2
- A must spend his new coin within 24 hours or B can claim the refund and keep his coins
- B must spend his new coin within 48 hours or A can claim the refund and keep his coins

For safety, both should complete the process with lots of time until the deadlines.

No it's not. I assume that you mean that the problem is that B's coins will remain locked until A agrees to unlock, but this is solved with locktime as described by gmaxwell, see also here.

This basically works by sending the 2 coins to a script that can only be spent if you have the recipient's public key and the x for a matching H(x).

Step 1
A generates H(x)
A sends coins to and x for H(x)

Step 2
B knows that A has sent his coins, so
B sends coins to and x for H(x)

Step 3
A sends x to B.

The can now both spend the coins they received.

If A refuses to perform step 3, when A spends the coins B sent, he has to provide x to the chain.  At that point B can spend his coins.

The worst A can do is defect and refuse to unlock the coins he sent B, until he wants to spend the coins he received.

This is potentially a problem.

I had some difficulty Googling for a clear explanation of atomic cross-chain trading, so I gathered my findings into this wiki page.

I must admit I do not fully understand Mike Hearns' explanation as presented, I suggest we use the wiki page to develop and clarify the solution as needed.

I meant something similar to what gmaxwell described here:
"You first create the ZKP payment transaction which requires (Password+Their_signature) OR (Their signature plus Your signature). You keep this transaction private. You then write a new transaction, the refund transaction, which spends the payment back to you but has an nlocktime set in the future (e.g. 1000 blocks from now). You sign it, and give it to the other party to sign. He is able to sign it without actually seeing the payment transaction (he only sees its hash). When he returns it, you then release the payment transaction. If he does not redeem the payment transaction before the locktime expires you transmit the refund and recover it yourself. Because of the locktime you are unable to steal the payment back right after sending it to him."

Do you agree that the simple protocol that I described gives atomic trade across chains with no possibilities for extortion?

Yeah.  In fact, having the alt-chain support the system is better than trying for BTC script.

Basically, it is a script that verifies that a hash has been included in an alt chain's merkle tree to a certain depth.


That isn't how locktime works.  Locktime means that the transaction can't be included into the chain until the given time.

Ideally, for an atomic system, it must be possible for it to be cancelled at any stage.  This is what the block chain does, in order to establish ordering of transactions.

Step 1: Bob sends coin unlocked by Alice's public key and X for sha(X)

If the transaction ends here, Bob loses his money

Step 2: Alice sends coins unlocked by Bob's public key and X for sha(X)

If the transaction ends here, Alice loses her money.  Bob can spend his at some later time.

Step 3: Bob sends X for sha(X) to Alice or to block chain

Transaction is completed.

What is needed is something like

Step 1: Bob sends coin unlocked by [Alice's public key and Proof step 3 happened] or [Proof step 3 didn't happen]

If the transaction ends here, Bob loses his money

Step 2: Alice sends coins unlocked by [Bob's public key and Proof step 3 happened] or [Proof step 3 didn't happen]

If the transaction ends here, Alice loses her money.  Bob can spend his at some later time.

Step 3: Bob sends X for sha(X) to Alice or to block chain

Transaction completed.

What you want is an alt chain that gives the proof.

You could have a time-stamping chain.  You can submit X to the chain and then it blocks sha(X) being added and vice versa.

The script in the OP was a way to say that the proof must be buried deep in some alt chain.

Check this thread. I think is similar to what you say.

P2PTradeX: P2P Trading between cryptocurrencies (https://bitcointalksearch.org/topic/p2ptradex-p2p-trading-between-cryptocurrencies-91843)

I'm not completely sure whether I understood your objective here, and I also didn't I understand some of the specifics.

If the objective is to trade (colored) coins between two chains (e.g. Bitcoin and Litecoin) where the trade is atomic, in the sense that either both parties received the coins that they wanted, or neither party did, then I think that we can use this simple protocol:

1) Alice has n1 bitcoins, Bob has n2 litecoins, and they want to trade them.

2) Bob selects a random password X and broadcasts to the Litecoin network a transaction that spends his n2 litecoins to a script that requires the usual OP_CHECKSIG for Alice's Litecoin address as well as "OP_SHA256 Y OP_EQUAL" where Y=SHA256(X), meaning that Alice (and only Alice) can spend those n2 litecoins, but only if she knew an X that satisfies Y==SHA256(X). This transaction is public, so Alice and everyone else see it on the Litecoin blockchain.

3) Alice now broadcasts to the Bitcoin network a similar transaction that allows Bob to spend her n1 bitcoins only if he reveals an X that gives Y==SHA256(X), i.e. a transaction with OP_CHECKSIG for Bob's Bitcoin address and "OP_SHA256 Y OP_EQUAL".

4) If Bob spends the n1 bitcoins (e.g. by sending them to another Bitcoin address of his) then he necessarily reveals X, so now Alice can do the same and spend the n2 litecoins.

5) To avoid extortion, we can use nlocktime (similarly to how it's used in the Contracts wiki page), so for example the transaction on the Litecoin network in step (2) expires after 2 days (meaning that Bob could spend the coins back to himself after 2 days), and the transaction on the Bitcoin network in step (3) expires after 1 day. This implies that if Bob spends the n1 bitcoins then we can be sure that Alice will be able to spend the n2 litecoins, and if either Alice or Bob abort at any stage then no harm is done.

One of the big benefits of colored coins is that the transactions are atomic.

You can buy 10 shares in a company for 20 BTC and either the transaction happens or it doesn't.  You don't get into a situation where you pay (or give the shares) and then the other transaction is reversed for some reason.

One way of doing it would be to verify that the other transaction was buried in a second chain.

This could involve checking that a token was in a merkle tree.

Step 1: verify that the token matches the desired token

OP_DUP [target-token] OP_EQUALVERIFY

Step 2: build up merkle tree (fixed depth)
[3] OP_ROLL OP_IF OP_SWAP OP_ENDIF OP_CAT OP_HASH256

It is assumed the input is  [true/false] [child1] [child2]

If true, then child1 and child2 are swapped and then the hash is computed.  OP_CAT is currently disabled.

The output is [parent]

The spend would be

[true/false] [merkle-node] [true/false] [merkle-node] .... [true/false] [merkle-node] [token]

When this step is finished, then the merkle root would be on the stack.

Step 3: scan the alt-chain headers

OP_SWAP would be needed before starting to move the merkle root back one.  The alt-chain is assumed to have only 3 fields in its header.

The input is
[nonce] [merkle-root] [previous-hash]

OP_CAT OP_CAT OP_HASH256 OP_DUP OP_LESS_THAN [target] OP_VERIFY [2] OP_PICK OP_EQUALVERIFY

This computes the hash and checks that it meets difficulty.  It then checks that the "previous-hash" for the next header matches the hash of this header.

This would be repeated for as many blocks as required.

The effect of all of these steps is that it is a script that is released if the token is buried in another chain at least a certain number of blocks deep.

To spend, you have to provide the merkle path to the root and then the nonce and merkle root for the headers which build on this one.

Depending on the value of the transactions more confirming blocks would be required.

The OP_CAT opcode is currently disabled.  It isn't really clear what a disabled opcode means.  If it isn't accepted, then it effectively doesn't exist.