Topic: Alt chains and atomic transfers (Read 27420 times)

Looking to implement this.

Is there an agreed hash function for different alts to use?

Looking to implement this.

Is there an agreed hash function for different alts to use?

This is very valueable thread and I'm glad of all the work TierNolan and others have done! To contribute to it a little bit, I worked out both proposed protocols. The first one with a formalisation, proof and demo implementation. However, the second protocol isn't atomic so my post isn't as elaborated as the first one (on the other hand, the derived one in TierNolan's BIP has the issue fixed, but I didn't study it in much detail).

BTW, I'm implementing this as a part of a bigger project---decentralised cryptocurrency exchange (Coincer, for short ). And I already have a working atomic protocol that uses only standard transaction scripts. So after years this stuff is definitely moving forwards!

Shortage of free time.  Getting all the encryption right isn't that easy , but I have the transactions working, as long as no cheating is required.

I still need to add checking for fraud and the refund transactions.

One point of good news from the dev list is that they are relaxing some of the restrictions on standard transactions.

See this post.  As long as the transaction uses P2SH, non-standard transactions will be accepted by the network.

At the cost of some extra complexity in creating transactions, almost all non-standard transactions will be possible.  The remaining limit is 520 bytes and 15 signature operations, but that is not a major restriction (and is just to protect against DOS attacks).

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).

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.

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  
else clause: 2x BTC to Bobs address and redeemer needs to solve H(x)



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

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).

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

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

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?

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

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?

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

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.

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.

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

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

What if Alice (because she likes to do arbitrage and is speculating on shifting values) reveals her x very late (after 23:59h and 59 seconds)? This would lead to the case that she doesn't get her altcoin but bob can still claim the Bitcoin, right?

This is an explanation of TierNolan's atomic cross transaction technique. It's similar to one by luxgladius, except this protocol avoids a race condition by using asymmetry - only Alice has a secret, and the timeout on one chain is much longer than the other. https://bitcointalksearch.org/topic/m.2224949

Alice has 1btc (Bitcoin) and Bob has 1atc (Altcoin). They would like to conduct an atomic exchange, so that after a finite time, either Alice has 1atc and Bob has 1btc, or the transaction was aborted and their positions are both unchanged. We assume that both the Bitcoin and Altcoin chains are loosely synchronized to eachother, such that neither chain gets more than 12 hours ahead of the other.

Phase 1: Alice bails in

Alice draws a random secret x. Alice constructs TX1 to bail in a bitcoin. TX1 has a single txout with 1 btc, containing the following scriptPubkey:

Alice signs TX1 but does not yet publish it. She creates TX2, her refund transaction, which has a locktime of +48 hours. It contains TX1[0] as a txin, and the txout is a standard spend to A. The scriptSig for this txin looks like
which proceeds through the main branch of the IF. Alice signs TX2, obtaining sigA2.

Alice transmits TX2 to Bob, and requests that Bob signs and returns it. Once Alice receives Bob’s signature sigB2, then Alice publishes TX1, knowing that she will be able to claim her refund after 48 hours, as long as she does not reveal x. Alice is now bailed in.


Phase 2: Bob bails in

Bob received TX2 in the first phase, and therefore knows H(x). Bob also signed Alice’s refund transaction, but that will not be active until after 48 hours. If Bob is honest, he’ll get what he wants within 24 hours in any case. Bob has also seen that TX1 has been published.

Bob creates TX3, which bails in an Altcoin. TX3 is symmetric with TX1, and has a single txout with 1atc, containing the following scriptPubkey:

Bob also creates TX4, which is his own Altcoin refund. TX4 is timelocked for only 24 hours, uses TX3[0] as a txin, and the scriptSig looks like
which proceeds through the main branch of the if. Bob signs TX4, obtaining sigB, and transmits TX4 to Alice, asking her to sign it. When Bob receives sigA4, he can safely publish TX3, knowing that he will be able to abort and reclaim his coin after 24 hours. Bob is now bailed in.


Phase 3: Alice reveals x and triggers both transactions.

Alice has 24 hours to claim the Altcoin, using the following scriptSig:
which triggers the ELSE branch of the conditional. However in doing so, she must necessarily reveal x. If Alice reveals x within 24 hours, then Bob can also claim his Bitcoin before 48 hours:
.


This is atomic because:
   a) each party *bails in* their coins only after receiving a *refund signature* from the other party.
   b) the refund delay is significantly larger on the Bitcoin chain than on the Altcoin chain, and Alice, who initially knows x, bails in her coin first.

Maybe do it on testnet

I was thinking of trying this out.

Does anyone know if there is a pool like Eligius for Litecoin that accepts non-standard transactions?

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.

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 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.

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

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.

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.