Pages:
Author

Topic: Alt chains and atomic transfers - page 2. (Read 27375 times)

legendary
Activity: 1232
Merit: 1094
February 13, 2014, 04:29:02 AM
#31
The system in this thread doesn't work at the moment due to transaction malleability.
newbie
Activity: 14
Merit: 0
February 12, 2014, 11:01:03 PM
#30
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.
newbie
Activity: 45
Merit: 0
January 11, 2014, 03:41:11 PM
#29
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
newbie
Activity: 52
Merit: 0
December 31, 2013, 02:34:04 AM
#28
@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.
sr. member
Activity: 280
Merit: 257
bluemeanie
December 30, 2013, 12:14:26 PM
#27

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
newbie
Activity: 52
Merit: 0
December 30, 2013, 05:05:06 AM
#26
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
sr. member
Activity: 280
Merit: 257
bluemeanie
December 29, 2013, 03:49:54 PM
#25
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?
legendary
Activity: 1232
Merit: 1094
December 29, 2013, 03:44:41 PM
#24
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.
sr. member
Activity: 280
Merit: 257
bluemeanie
December 29, 2013, 03:14:54 PM
#23
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.
newbie
Activity: 52
Merit: 0
December 29, 2013, 04:36:07 AM
#22
@socrates1024
I cannot spent bail-in in current form with BitcoinJ library
Executing with signing script
Code:
x(btc bug) 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!
legendary
Activity: 1120
Merit: 1152
November 25, 2013, 02:33:29 AM
#21
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>
newbie
Activity: 45
Merit: 0
November 24, 2013, 07:48:05 PM
#20
Socrates1024, I have never written any forth code, but I am pretty sure that how you are using "op_if" is incorrect.
See links for details: http://bitcoin.stackexchange.com/questions/2317/script-op-if-etc-clarifications
This also talks about if statments in forth: http://theforthsource.com/guide10.html

This is my attempt to re-write it.

//I am assuming that if is known, that it is already on the stack.
//The first "2" is because of bitcoin's bug. The second "2" is an input for op_checkmultisig
2 2 OP_CHECKMULTISIG OP_DUP //OP_DUP (duplicate top of stack) is here
                                                                                               //because OP_NOTIF pops an item off the stack.
//If checkmultisig worked, then we want to skip to the end and verify. if checkmultisig did not work,
//then we still have another chance
OP_NOTIF
        OP_DROP //This gets rid of the 0 that OP_checkmultisig gave us. Now should be on top.
        OP_HASH160 OP_EQUAL //If the hash of x is , then this will leave a 1 on top. otherwise, it leaves a 0.
         OP_CHECKSIG  //If B has signed, put a 1 on top
        1 OP_EQUAL OP_EQUAL //If the top 2 items were (1, 1) then, delete them and put a 1 on top. Otherwise delete them
                                                // and put a 0 on top. T
OP_ENDIF
        OP_VERIFY

Now I understand what you were doing Socrates1024
legendary
Activity: 2618
Merit: 1007
October 11, 2013, 02:36:19 AM
#19
Well, then there's still the issue with altcoins being (far) less secure than Bitcoin:

Alice reveals X, Bob 51% attacks Altcoin to undo/prevent Alice's transaction for the remaining n hours, Bob redeems Bitcoin. Are Altcoins just viewed as "secure" in this scenario and is this a reasonable assumption in reality? This again might be seen as not relevant, as not the protocol but the chain is attacked.

Still it would be nice to allow Alice to trade with anyone, not just a certain Bob.
full member
Activity: 126
Merit: 110
Andrew Miller
October 10, 2013, 05:19:34 PM
#18
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?
Alice can only harm herself by waiting so close to the deadline. This is OK.
legendary
Activity: 2618
Merit: 1007
October 10, 2013, 05:14:24 PM
#17
As far as I understand, Alice cannot put out a general offer though, she can only trade with Bob and vice versa. This might be a potential drawback. On the other hand this is about atomic transfers, not cross chain trade offers...

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? Also might it be the case that this leads to some issues in the altcoin network, if half of the nodes see her revealing X thus granting her the altcoin and the other half believe that the time is over and the altcoin should return to Bob?
hero member
Activity: 555
Merit: 654
October 10, 2013, 03:36:59 PM
#16
This socrates1024 protocol seems to be much better than some others I saw. I can't find any drawback.

full member
Activity: 126
Merit: 110
Andrew Miller
October 10, 2013, 02:31:03 PM
#15
I've been skeptical of atomic cross-chain trades for a while now. In particular I edited the Contracts wiki page to explain that the proposed technique (the "luxgladius" protocol) has a fatal race condition. But now I'm convinced that solution proposed here works and has no race condition. And it's simpler than P2PTradeX, which is good (although P2PTradeX may still be useful for other things). So, here's my writeup of how this works. Unless I realize I missed something, I want to revise the Contracts wiki page to point to TierNolan's description by default one, and remove the disclaimer that cross-trades don't work! https://en.bitcoin.it/wiki/Contracts

Quote
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:
Code:
OP_IF
// Refund for A
2 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
// Ordinary claim for B
OP_HASH160 OP_EQUAL OP_CHECKSIGVERIFY
OP_ENDIF

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
Code:
  1
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:
Code:
OP_IF
// Refund for B
2 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
// Ordinary claim for A
OP_HASH160 OP_EQUAL OP_CHECKSIGVERIFY
OP_ENDIF

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
Code:
  1
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:
Code:
  0
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:
Code:
  0
.


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.
legendary
Activity: 1232
Merit: 1094
August 03, 2013, 03:15:41 AM
#14
Maybe do it on testnet

Does litecoin have a testnet, I guess that would work?

Anyway, I was thinking that the feature could be achieved using channels.  Both traders would open a channel to handle the trade.

This can be done with standard multi-sig transactions.

LTC fees are 0.1 LTC which is pretty high.

If nodes created channels to 8 other nodes, then you could get a distributed exchange.  Each node would act as market maker between the peers it was connected to.

It would tell the other nodes what its bid/ask price was.  Persistent nodes could potentially generate profit for their operators.
legendary
Activity: 1792
Merit: 1111
August 02, 2013, 11:19:56 PM
#13
I was thinking of trying this out.

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

Maybe do it on testnet
legendary
Activity: 1232
Merit: 1094
August 02, 2013, 03:25:13 PM
#12
I was thinking of trying this out.

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