Alt chains and atomic transfers

[Peter Todd]

Socrates1024, I have never written any forth code, but I am pretty sure that how you are using "op_if" is incorrect.

I just glanced at it, so take this with a grain of salt, but he's using a standard trick in Bitcoin scripting of using an op_if op_else op_endif to select which condition the script is testing directly rather than test and re-test on failure. You spend such a scriptPubKey with something like this:

scriptSig: {values that satisfy the script} <1 or 0 depending on which version you want to use>

[kactech]

@socrates1024
I cannot spent bail-in in current form with BitcoinJ library
Executing with signing script

Code:

 x(btc bug) <sigA> <sigB> 1

results in empty non-true stack "Stack empty at end of script execution". Works fine when I change CHECKMULTISIGVERIFY to CHECKMULTISIG and CHECKSIGVERIFY to CHECKSIG but I'm not sure if it's safe.
Could it be a BitcoinJ bug or something is missing in your script?
I think it could work with "CHECKMULTISIGVERIFY OP_TRUE" as OP_VERIFY returns Nothing/Invalid
Thanks!

[bluemeanie1]

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

I think you need to do a lot more work to prove this fully.  A lot of the publications surrounding this project have been flimsy as of late.

Seems this area is overrun by amateurism, but you need to show in specific concrete terms how this works and publish it with a NAME and DATE.

[TierNolan]

I think you need to do a lot more work to prove this fully.  A lot of the publications surrounding this project have been flimsy as of late.

The point I meant was that it you exchange BTC for coloured coins, then it is inherently atomic.

Handling more than 1 chain is more complex.

However, ignoring large scale chain reversals, the atomic transfer system in this thread would be atomic too.

[bluemeanie1]

I think you need to do a lot more work to prove this fully.  A lot of the publications surrounding this project have been flimsy as of late.

The point I meant was that it you exchange BTC for coloured coins, then it is inherently atomic.

Handling more than 1 chain is more complex.

However, ignoring large scale chain reversals, the atomic transfer system in this thread would be atomic too.

some of the recent proposals [1] suggest doing Color Coins in an altchain, thus according to your claims here you lose this 'atomic' exchange quality with BTC.

btw- using Confidence Chains you have 100% reliable exchanges because we support them directly in the TX formats.  http://www.altchain.org/?q=whitepapers/paper2.html


[1] not sure if proposal is the right term, more like CRG: collaborative rumor generation?

[kactech]

Here is working sketch of trade flow:
https://github.com/kactech/atomictc/blob/pub/src/test/java/com/kactech/atomictc/AtomicTests.java
ASCII armored messages from test run:
https://github.com/kactech/atomictc/wiki/Five-Steps-Trade-communication
To simplify things there are only 2 pubKeys(and related addresses) used, traders exchange only things needed to recreate transactions at their side(instead of sending full refund transactions they send bailInHash and amount), trade state is POJO saved to JSON.
It would be nice to hear your thoughts
Sorry for spelling
Cheers
###
TODOS:
* UTXOs locking
* spam prevention: if Bob doesn't know Alice(or chains have significantly different transaction costs) he can f.e. require her refund to be partitioned (refund amount split over more outputs) to make Alice's refund more expensive than his

[bluemeanie1]

my thoughts are Im not going to take this seriously until someone at least spends the time writing out an explanation of it with their name on it.  A 'rough sketch' or 'code is the spec' isn't an asset, it's a sign that no one thought anything through and they just wanted to produce some code to look like work has been done.

the last interesting thing I saw come out of Color Coins was Meni Rosenfeld's whitepaper.

I might be a bit more generous with my attention span but unfortunately a number of obnoxious people have moved into that neighborhood.

I don't know you so Im not judging you personally.

-bm

Here is working sketch of trade flow:
https://github.com/kactech/atomictc/blob/pub/src/test/java/com/kactech/atomictc/AtomicTests.java
ASCII armored messages from test run:
https://github.com/kactech/atomictc/wiki/Five-Steps-Trade-communication
To simplify things there are only 2 pubKeys(and related addresses) used, traders exchange only things needed to recreate transactions at their side(instead of sending full refund transactions they send bailInHash and amount), trade state is POJO saved to JSON.
It would be nice to hear your thoughts
Sorry for spelling
Cheers
###
TODOS:
* UTXOs locking
* spam prevention: if Bob doesn't know Alice(or chains have significantly different transaction costs) he can f.e. require her refund to be partitioned (refund amount split over more outputs) to make Alice's refund more expensive than his

[kactech]

@bluemeanie1
I don't know what kind of description you want here, it's socrates1024's script, rest is in bitcoin spec. I want to use BitcoinJ, blockchain.info and RPC client to trade BTC/ALT and asking for opinion, that's all. Thank you for not judging me, I'll also refrain from doing so.

[agorism]

Thank you very much for building the example code kactech. Stuff like this is really helpful.

Perhaps I could get advice on how to experiment with scripting?
I have been using bitcoind and pybitcointools. I have been having trouble getting the transactions to Eligius, which is the only mining pool that accepts custom transactions?

Since broadcasting custom transactions is such a pain, maybe we can come up with a way to do all the custom transactions off-chain?
And then we broadcast the final standard transaction normally?

Once a transaction has been signed, it is easy for either of them to verify that the transaction is valid.
Instead of broadcasting it, they can make an standard transaction that does the same thing, and broadcast that instead.

Only in the case where one person disappears do you have to broadcast the custom transaction?

I am currently trying to write code to implement cross-chain transactions, as well as trustless distributed gambling. I use bitmessage so that users can talk to one another. bitmessage is a proof-of-work based communication system where you can't even tell which addresses are talking to each other.

The code is a big mess right now. https://github.com/zack-bitcoin/python-bitcoin-library

[cryptotechguy]

Since broadcasting custom transactions is such a pain, maybe we can come up with a way to do all the custom transactions off-chain?
And then we broadcast the final standard transaction normally?

How can we be sure that funds haven't been spend? The way I see it, both Alice and Bob need to verify that transactions are buried under several blocks thus considered valid, and then Alice can proceed with revealing secret x and triggering both transactions.

[TierNolan]

The system in this thread doesn't work at the moment due to transaction malleability.

[cryptotechguy]

The system in this thread doesn't work at the moment due to transaction malleability.

Yeah, but the idea presented later (and here: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains) is not compromised and is a great one.

Has anyone tried implementing it in any fashion?

[kactech]

The system in this thread doesn't work at the moment due to transaction malleability.

Yeah, but the idea presented later (and here: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains) is not compromised and is a great one.

Has anyone tried implementing it in any fashion?

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
Tx2(the contract) can be invalidated by Tx1(the payment) mutant, if 'B' won't cooperate with 'A' to resolve this issue 'A' will loose his coins.

[kactech]

Thank you very much for building the example code kactech. Stuff like this is really helpful.

Perhaps I could get advice on how to experiment with scripting?
I have been using bitcoind and pybitcointools. I have been having trouble getting the transactions to Eligius, which is the only mining pool that accepts custom transactions?

Since broadcasting custom transactions is such a pain, maybe we can come up with a way to do all the custom transactions off-chain?
And then we broadcast the final standard transaction normally?

Once a transaction has been signed, it is easy for either of them to verify that the transaction is valid.
Instead of broadcasting it, they can make an standard transaction that does the same thing, and broadcast that instead.

Only in the case where one person disappears do you have to broadcast the custom transaction?

I am currently trying to write code to implement cross-chain transactions, as well as trustless distributed gambling. I use bitmessage so that users can talk to one another. bitmessage is a proof-of-work based communication system where you can't even tell which addresses are talking to each other.

The code is a big mess right now. https://github.com/zack-bitcoin/python-bitcoin-library

Hi, bail-in on the blockchain is fundamental here, now way to make it offline.
Have you tried https://blockchain.info/pushtx for custom transactions?

[k99]

The system in this thread doesn't work at the moment due to transaction malleability.

I think the extortion problem due malleability could be solved in the way that Bob pays in a deposit so there is a balanced risk situation.
So both pay in the same amount, Alice payment move over to Bob and he gets his deposit back after the trade:

Tx1:
input 1: x BTC from Alice
input 2: x BTC from Bob
output:
if clause: MultiSig <Alice, Bob> 
else clause: 2x BTC to Bobs address and redeemer needs to solve H(x)

Tx2_Refund:
input: 2x BTC from Tx1 (MultiSig <Alice, Bob> )
output 1: x BTC to Alice
output 2: x BTC to Bob
timelock: 24 h

Same happens on the altcoin side.

Tx1 is first signed by Bob then sent to Alice and then she signs her input.

Malleability could also happen without bad intention, but the refund tx is only needed if the normal trade does not get completed.
In that case both have an incentive to agree to a new refund tx with the changed TxID from the now published Tx1 to get back their payments.
At least Bob has no extortion advantage compared to Alice.

One other open problem is that when the price changes to the disadvantage of Alice, she might consider to not redeem the Altcoin and therefore cancel the trade.
So both trades will be refunded, but Alice has the advantage to decide to cancel the trade if the price moves against her interests.
That form of scam seems to be quite a problem on localbitcoin or bitcoin.de. With shorter time-windows that could be mitigated.

The fact that Alice is the redeemer who reveals the secret and therefore control if the trade will executed or be canceled (refund), might need additional protection (offer fees, reputation system?).
Automated trades with micropayments might be another option (break down a bigger volume to smaller chunks).

[TierNolan]

I created a thread about a similar method.  You method is simpler.

I think the extortion problem due malleability could be solved in the way that Bob pays in a deposit so there is a balanced risk situation.
So both pay in the same amount, Alice payment move over to Bob and he gets his deposit back after the trade:

Tx1:
input 1: x BTC from Alice
input 2: x BTC from Bob
output:
if clause: MultiSig <Alice, Bob> 
else clause: 2x BTC to Bobs address and redeemer needs to solve H(x)

<snip>

Tx1 is first signed by Bob then sent to Alice and then she signs her input.

Alice selects a transaction output of value x that she owns as input 1 and sends it to Bob.

Bob creates the transaction, as above, signs it and sends it back to Alice.

Alice signs the transaction and gets it hash.

Alice creates the refund transaction.

Input
2x from TX1 signed by Alice, locked 24 hours in the future

Output
x to Bob
x to Alice

Bob signs and sends it back to Alice.

Alice now has a refund transaction.

She is then supposed to publish TX1.

If Alice stops here, then she can hold Bob's money to ransom.

Worst case, she gets her money back after 24 hours.

OTOH, her hand is weakened, since her x BTC is tied up in the process.

The fact that Alice is the redeemer who reveals the secret and therefore control if the trade will executed or be canceled (refund), might need additional protection (offer fees, reputation system?).
Automated trades with micropayments might be another option (break down a bigger volume to smaller chunks).

This might be a general solution, especially with malleability.  If you have traded with someone before, you are willing to trust them for up to 1% of the trade or 1% of the total trades that you have done with that person before.

[gigq]

Malleability could also happen without bad intention, but the refund tx is only needed if the normal trade does not get completed.
In that case both have an incentive to agree to a new refund tx with the changed TxID from the now published Tx1 to get back their payments.
At least Bob has no extortion advantage compared to Alice.

There is still the issue of mutual destruction though.  You may ask why that would happen but I can imagine if a decentralized exchange like this really took off it might be worth it for the existing exchanges to mess with users of the decentralized exchange by locking up their funds at random.

But I agree with transaction malleability out there this seems like the only possible solution.

[TierNolan]

[edit]
Doesn't work

Bob can broadcast TX4 and then wait for the timeout before spending it.  By broadcasting TX4, TX3 is spend, so Alice can't get a refund.
[/edit]

[edit2]
Works after all, TX3 can be tweaked.
[/edit2]

I am trying to get the standard transactions adjusted and ideally, the change should be minimal.

One suggestion is to add the following

OP_HASH160 OP_EQUAL_VERIFY [Standard Transaction]

This means that you can protect a standard transaction with a hash password.

I think that this is enough to make things work.

Bob selects x

TX0: Bob sends w BTC to [2 of Alice-pub-key1 and Bob-pub-key1]

TX1: from TX0 to [x for Hash(x) & Alice-pub-key2]
TX2: from TX0 to [Bob-pub-key2], timelocked 48 hours

Bob signs TX1 and sends TX1-half-signed and TX2 (unsigned) to Alice.

Alice signs both and returns the signed version of TX2 to Bob.

Bob has TX2 signed and Alice has TX1 signed.

Alice extracts Hash(x) from TX1

TX3: Alice sends v ATC to [2 of Alice-pub-key3 and Bob-pub-key3] and <delta> to [x for hash(x) & 2 of Bob-pub-key3 and Alice-pub-key3]
Note: TX3 has 2 outputs

TX4: from TX3/0 and TX3/1 to [Bob-pub-key4]
TX5: from TX3/0 to [Alice-pub-key4], timelocked 24 hours

Alice signs TX4 and sends TX4-half-signed and TX5 (unsigned) to Bob.

Bob signs both and returns the signed version of TX5 to Alice.

Alice has TX5 signed and Bob has TX4 signed.

Knowledge of each party

Nothing is broadcast until the above is completed.

Bob has fully signed versions of
TX0 - initial bail-in
TX2 - timelocked refund of TX0 (48 hours)
TX4 - Bob cashes in altcoin

Alice has fully signed versions of
TX1: Alice cashes in bitcoin
TX3: Alice bail in
TX5: timelocked refund (24 hours)

Release protocol

Note:

1) Bob broadcasts TX0 (Bob bails-in)

If the protocol ends here, Bob can use TX2 to get his money back after 48 hours

2) Alice broadcast TX3 (Alice bails-in)

If the protocol ends here, Bob can use TX2 to get his money back after 48 hours and Alice can use TX5 to get her money back after 24 hours

3) Bob broadcasts TX4 (Bob commits transaction)

He spends v ATC to another of his addresses.

He can only do this by providing x, since TX3/1 requires x for hash(x).

This commits the transaction.

Bob has Alice's money, so she might as well perform step 4.  She can't get her original money back anyway.

4) Alice completes the transaction

Alice broadcasts TX1.  She spends w BTC to another of her addresses.

[TierNolan]

I created a new BIP draft relating to this.

https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki

The latest version allows transfers between chains as long as 1 of them supports non-standard transactions.

This means that fast testnet <-> mainnet transfers would be possible. 

Testnet would have to have the longer timeout, since it is the network that supports non-standard transactions.  Everything on Bitcoin would standard.

I am going to look into creating a simple client/server this week-end to verify that the scheme actually works.

What is cool about this is that it means that a BTC <-> altcoin trading system would only require that the altcoin accepts the non-standard transactions template. 

It should be much easier to convince an altcoin dev to make the change than updating the Bitcoin reference client's rules (though hopefully, they will too).

[elroy69]

TierNolan,

Really great work on this.  Any luck with the simple client/server?  Did it work as expected.  Have you discussed this with the people like Adam Back pushing the SideChain changes, so that they can include this?

I created a new BIP draft relating to this.

https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki

The latest version allows transfers between chains as long as 1 of them supports non-standard transactions.

This means that fast testnet <-> mainnet transfers would be possible. 

Testnet would have to have the longer timeout, since it is the network that supports non-standard transactions.  Everything on Bitcoin would standard.

I am going to look into creating a simple client/server this week-end to verify that the scheme actually works.

What is cool about this is that it means that a BTC <-> altcoin trading system would only require that the altcoin accepts the non-standard transactions template. 

It should be much easier to convince an altcoin dev to make the change than updating the Bitcoin reference client's rules (though hopefully, they will too).