Trading across chains

[lophie]

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains

Hi, I am looking forward to work on this. I just need the community help to brainstorm little more, and mpowering myself of more knowledge on the block chain.

So my question is what if the coins from the second block-chain are sent elsewhere while the coins on the first chain are being sent?

[1715288854]

1715288854

[1715288854]

1715288854

[1715288854]

1715288854

[1715288854]

1715288854

[Akka]

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains

Hi, I am looking forward to work on this. I just need the community help to brainstorm little more, and mpowering myself of more knowledge on the block chain.

So my question is what if the coins from the second block-chain are sent elsewhere while the coins on the first chain are being sent?

Not possible, if I understand it right, A dosn't have the coins anymore at this point. But B needs to send as well to be able to claim the coins send by A.

[lophie]

Just read it once more throughrolly...

ah so you mean both coins on both chains are sent to addresses of multi-sig that's why party "A" cannot take the coins while party "B" is releasing the other coins on the alternate chain, did I get it right?

[Akka]

Just read it once more throughrolly...

ah so you mean both coins on both chains are sent to addresses of multi-sig that's wht party "A" cannot take the coins while party "B" is releasing the other coins on the alternate chain, did I get it right?

Yes, that's IMO the only way that could safely work.

It still leaves all the loosing risk on A though (If B doesn't send, A coins are lost for everyone). But someone has to send first, I don't see a way to solve this without involving a third party.

[Fjordbit]

My feeling on this is that this problem is better suited to Open Transactions and not blockchain manipulation.

[lophie]

My feeling on this is that this problem is better suited to Open Transactions and not blockchain manipulation.

Open transaction is really awesome project but "FellowTraveller" lost me on the "centeralized" part.

[lophie]

If B doesn't send, A coins are lost for everyone

How about if we added future transactions?
Bear with my confused retarded mind for a second here.

say we want to exchange 0.1 BTC for 1 NMC... Party A got the bitcoins, B got the namecoins.
 
- so we have a multisig address on bitcoin chain, another multisig address on namecoin chain.
- Before sending anything we create two "future" transactions and both signs them. One to return the 0.1 BTC to its rightful owner and one to return the 1 NMC to the righful owner
- Now we procceed as suggested in the example

if B doesn't send, A coins will go back after the period, and vice versa.

The future transactions are just guarentees and they will be worthless since the temp multisig addresses are empty!

Penny (or a satoshi   ) for your thoughts?

[Akka]

If B doesn't send, A coins are lost for everyone

How about if we added future transactions?
Bear with my confused retarded mind for a second here.

say we want to exchange 0.1 BTC for 1 NMC... Party A got the bitcoins, B got the namecoins.
 
- so we have a multisig address on bitcoin chain, another multisig address on namecoin chain.
- Before sending anything we create two "future" transactions and both signs them. One to return the 0.1 BTC to its rightful owner and one to return the 1 NMC to the righful owner
- Now we procceed as suggested in the example

if B doesn't send, A coins will go back after the period, and vice versa.

The future transactions are just guarentees and they will be worthless since the temp multisig addresses are empty!

Penny (or a satoshi   ) for your thoughts?

That could work, A sending the coins cancels Bs future transaction and vice versa. This would require to add cancel-able future transactions to the protocol, though.

[lophie]

That could work, A sending the coins cancels Bs future transaction and vice versa. This would require to add cancel-able future transactions to the protocol, though.

Yes I got stuck at the same point. The future transaction cannot be canceled but can be invalidated due to lack of enough balance. In this scenario the latter party have to send the coins to themselves before the time is up and the coins are back to the original owner.

But the exchange is pretty solid and trust-free so far. Now to the even more important questions:

- How did they meet and agreed on a price in first place without a centeralized server?

- How to minimize the communication steps between parties?

- What measures can we use to reduce flooders? because flooding cost money in this case, the transactions fees. you still getting your money back from a flooder but losing the transactions fees. And time you will lose time waiting your transaction to be finalized and money back to you!.

The idea of this whole post is to brainstorm and think of a peer to peer exchange of "cryptocurrencies" (No fiat). This is a part of a bigger idea of a peer to peer stock market. Since the block-chains are not necessarily currencies. But that is another part which needs it is own thread.

So let's think this together, since appearently in p2p cryptocurrencies scene we are on our own, no gov or "Big guys" are looking after us.

[Akka]

Since you are no noob anymore and are able to post everywhere, why don't you PM a mod if he can move this thread to development. There you will probably get more feedback than just my opinion.

It's a interesting concept and deserves more notice.

[lophie]

Sent a pm to psy. Thank you for the replies I have been brainstorming this for a couple of months now but I am a bit shy... (afraid of knowledgeable and aggressive ppl to just shoot me down and make fun of my lack of understanding  ). But I spent some time around and I noticed how understanding and supporting this community is. Thank you all for that <3

[marcus_of_augustus]

My feeling on this is that this problem is better suited to Open Transactions and not blockchain manipulation.

Open transaction is really awesome project but "FellowTraveller" lost me on the "centeralized" part.

The OT servers doing the exchange do not have to be trusted, in fact they shouldn't be. You do not deal with a
single centralised server rather you are dealing with a federation of untrusted servers that are kept honest by a
web-of-trust model via an audit protocol based on voting pools (federations) of untrusted servers.

[lophie]

I understand the trustworthyness of OT servers. What I don't like is we have problems with the current exchanges like mtgox, like the "possibility" that they rip you off (having to trust them) and more importantly them being "Centeralized".

The second problem shows how much harm this can cause Bitcoin if exchanges went down for a reason or another. (Big brother sick of seeing us getting even bigger?) Now when you want to come up with a solution, we can -like you suggested- be happy with a solution like OT which solves only one problem. But ultimately we have to create a solution which is fully p2p.

OT is 99% ready. It just needs implementation to link a bitcoin address to an issued currency and voila... a GLBSE alternative!

Maybe having a network of OT servers running as tor hidden services is the ultimate solution? I don't know....

[Sergio_Demian_Lerner]

Check the thread: P2PTradeX: P2P Trading between cryptocurrencies (https://bitcointalk.org/index.php?topic=91843.0)

For a method of trading between block-chains that works fine in practice and has no known drawback.

Best regards,
  Sergio.

[Mike Hearn]

So my question is what if the coins from the second block-chain are sent elsewhere while the coins on the first chain are being sent?

You can't do that, it's the whole point of the protocol. By the time you reached step 6, the coins on both chains are in a suspended state in which, lacking any other action, they will eventually return to their original owners (they cannot move anywhere else). The act of moving to step 7 and claiming the coins on one chain makes the coins on the other chain claimable as well, but only by the other side.

If you want to implement this technique you have a lot of difficult work ahead of you. For one, the chain trade protocol requires transaction replacement to operate, which is currently disabled. Re-enabling it requires convincing Gavin there are no DoS risks, probably by rewriting how transactions are verified in the Satoshi client to be priority queue based.

[markm]

My feeling on this is that this problem is better suited to Open Transactions and not blockchain manipulation.

Open transaction is really awesome project but "FellowTraveller" lost me on the "centeralized" part.

Bitcoin is also "centralised", since what you seem to mean is that some people will only run clients not a full "server" setup.

It is much like bitcoin in that way: it is not expected that all users of bitcoin will bother to real a real full node just as it is not expected that all users of Open Transactions will bother to run the server side, they will just use clients.

Not bothering to become a server yourself does not really give you good grounds for complaining that there are fewer servers than clients (aka that it is "centralised".

Open Transactions is "centralised" in the sense that if you are the only person in your social circle who runs the server side, people in your social circle who choose not to use servers that are outside of that social circle could spread FUD about you trying to "centralise" by your evil tendency to fail to force everyone else to also run servers.

It is FUD: if they want to decentralise more, it is free open source code they are free to run themselves.

If everyone ran a server as well as a client, any two who want to execute a trade via a server can execute it on either of their own servers or split it into smaller transactions some executed on one party's server some executed on the other party's server, or they could even spread it out into many transactions across every server of whose existence they are aware...

-MarkM-

[lophie]

Thank you for joining the conversation Mike. Saw your talk in the confrence on youtube. Things lead to another and thats how I came across trading between chains in first place . So thanks.

Just read the explaination of tx versioning. Isn't that helping the channel of micro transactions idea? I am really new to bitcoin and just started learning about the protocol can you tell me why do you think this is related to an implementation for trading across chains? Thanks.

[Mike Hearn]

Yes, it's needed for both protocols. If you read the chain trade protocol it needs transaction replacement to work, as does the concept of micropayment channels.