Code:
/----------------------------------------\
| Alice 50.00 BTC -> 49.99 BTC Bob |
| Bob 0.00 BTC 0.00 BTC Alice |
\----------------------------------------/
Topic: CPUchain decentralized exchange proposal (Read 146 times)
It can be solved by using zero satoshis:
Then, "0.00 BTC" can be interpreted as "150.00 CPU", when you hide that information in tapscript and when altcoin will be represented as zero satoshi outputs on BTC. Currently, this solution is nonstandard in the main network, but you can do that in testnet. That means swapping tBTC and tCPU is now possible, so you can check how it works on test coins. To move that to the mainnet, you would need some support from the miners.
This system is still unsafe. Assume Bob would be a cheater. He could create fake transaction sending his CPU to himself. Then, he could silently create transaction sending BTC to another address and broadcast it as soon as Alice release her honest transaction. Then, Alice will lose both coins, because her reverse transaction would be treated as "double-spending attempt" by the BTC network.
Even creating another type of transaction is still not sufficient. For example you can safely create a message that lists all inputs and all outputs for both coins. But even if such message would be a valid transaction in both networks (if signed by all parties), it is still vulnerable to "race attack" when honest party releases its coins and dishonest party creates another transaction moving funds to its own address and broadcasts it (making any next transactions as "double spend attempts").
Even creating another type of transaction is still not sufficient. For example you can safely create a message that lists all inputs and all outputs for both coins. But even if such message would be a valid transaction in both networks (if signed by all parties), it is still vulnerable to "race attack" when honest party releases its coins and dishonest party creates another transaction moving funds to its own address and broadcasts it (making any next transactions as "double spend attempts").
Note: This proposal may be useful also for other coins, but I chose BTC and CPU as an example of what is possible.
We assume Alice has some BTC she wants to turn into some CPU, and Bob has some CPU he wants to turn into some BTC. At first, Alice publishes her BTC inputs, her CPU outputs and both BTC and CPU best blocks' hashes and heights. She also chooses some "key for exchange" that she signs by all her BTC keys to prove that she owns these coins and to allow using another key for transmitted "exchange messages" instead of repeating all those keys in each message. She also includes all "reverse transaction" outputs, because in this way she can later revert her transaction if Bob will cheat her.
/------------------------------------------------------\
| * all zeroes previous message's hash |
| * Alice's BTC inputs |
| * best BTC block height |
| * best BTC block hash |
| * Alice's CPU outputs |
| * best CPU block height |
| * best CPU block hash |
| * Alice's key for exchange (signed by all BTC keys) |
| * Alice's BTC reverse transaction outputs |
|------------------------------------------------------|
| * this message is signed by Alice's key for exchange |
\------------------------------------------------------/
Now, Bob knows all addresses and all amounts, so he can create his transaction transferring his CPU to Alice's outputs. He signs it, calculates transaction hash and keeps this transaction private. He can include Alice message's hash and her reverse transaction without any signatures. He can also add transaction transferring Alice's BTC to his outputs (without signatures). Finally, he also includes his key for exchange, signed by all her CPU keys to prove he owns his coins. Then, he signs the whole message by this key.
/------------------------------------------------------------\
| * Bob CPU -> Alice CPU transaction (signed by Bob) |
|------------------------------------------------------------|
| * this message's hash is enough to create next transaction |
| * Bob keeps this transaction private (for now) |
\------------------------------------------------------------/
/------------------------------------------------------------\
| * Alice message's hash |
| * Alice CPU -> Bob CPU reverse transaction (no signatures) |
| * Alice BTC -> Bob BTC transaction (no signatures) |
| * Bob's key for exchange (signed by all CPU keys) |
|------------------------------------------------------------|
| * this message is signed by Bob's key for exchange |
\------------------------------------------------------------/
Next, Alice can now safely sign Bob's reverse transaction and include it in her next message. She also signs her transaction transferring her BTC to Bob, but she keeps this transaction private. She takes hash from this transaction to create her reverse transaction and adds it without any signatures.
/------------------------------------------------------------\
| * Alice BTC -> Bob BTC transaction (signed by Alice) |
|------------------------------------------------------------|
| * this message's hash is enough to create next transaction |
| * Alice keeps this transaction private (for now) |
\------------------------------------------------------------/
/--------------------------------------------------------------\
| * Bob message's hash |
| * Alice CPU -> Bob CPU reverse transaction (signed by Alice) |
| * Bob BTC -> Alice BTC reverse transaction (no signatures) |
|--------------------------------------------------------------|
| * this message is signed by Alice's key for exchange |
\--------------------------------------------------------------/
Finally, Bob can now sign Alice's reverse transaction and send it to her.
/--------------------------------------------------------------\
| * Alice message's hash |
| * Bob BTC -> Alice BTC reverse transaction (signed by Bob) |
|--------------------------------------------------------------|
| * this message is signed by Bob's key for exchange |
\--------------------------------------------------------------/
Now, both parties have all transactions and all reverse transactions they need and they can release their transactions to the network. No party will release reverse transaction, because in this case another party will do the same and both parties will just lose some coins on transaction fees. Blocks heights and hashes are needed as a timestamp and a hint what exchange rate they can use (but of course they can exchange coins using any amounts if both parties agree).
We assume Alice has some BTC she wants to turn into some CPU, and Bob has some CPU he wants to turn into some BTC. At first, Alice publishes her BTC inputs, her CPU outputs and both BTC and CPU best blocks' hashes and heights. She also chooses some "key for exchange" that she signs by all her BTC keys to prove that she owns these coins and to allow using another key for transmitted "exchange messages" instead of repeating all those keys in each message. She also includes all "reverse transaction" outputs, because in this way she can later revert her transaction if Bob will cheat her.
/------------------------------------------------------\
| * all zeroes previous message's hash |
| * Alice's BTC inputs |
| * best BTC block height |
| * best BTC block hash |
| * Alice's CPU outputs |
| * best CPU block height |
| * best CPU block hash |
| * Alice's key for exchange (signed by all BTC keys) |
| * Alice's BTC reverse transaction outputs |
|------------------------------------------------------|
| * this message is signed by Alice's key for exchange |
\------------------------------------------------------/
Now, Bob knows all addresses and all amounts, so he can create his transaction transferring his CPU to Alice's outputs. He signs it, calculates transaction hash and keeps this transaction private. He can include Alice message's hash and her reverse transaction without any signatures. He can also add transaction transferring Alice's BTC to his outputs (without signatures). Finally, he also includes his key for exchange, signed by all her CPU keys to prove he owns his coins. Then, he signs the whole message by this key.
/------------------------------------------------------------\
| * Bob CPU -> Alice CPU transaction (signed by Bob) |
|------------------------------------------------------------|
| * this message's hash is enough to create next transaction |
| * Bob keeps this transaction private (for now) |
\------------------------------------------------------------/
/------------------------------------------------------------\
| * Alice message's hash |
| * Alice CPU -> Bob CPU reverse transaction (no signatures) |
| * Alice BTC -> Bob BTC transaction (no signatures) |
| * Bob's key for exchange (signed by all CPU keys) |
|------------------------------------------------------------|
| * this message is signed by Bob's key for exchange |
\------------------------------------------------------------/
Next, Alice can now safely sign Bob's reverse transaction and include it in her next message. She also signs her transaction transferring her BTC to Bob, but she keeps this transaction private. She takes hash from this transaction to create her reverse transaction and adds it without any signatures.
/------------------------------------------------------------\
| * Alice BTC -> Bob BTC transaction (signed by Alice) |
|------------------------------------------------------------|
| * this message's hash is enough to create next transaction |
| * Alice keeps this transaction private (for now) |
\------------------------------------------------------------/
/--------------------------------------------------------------\
| * Bob message's hash |
| * Alice CPU -> Bob CPU reverse transaction (signed by Alice) |
| * Bob BTC -> Alice BTC reverse transaction (no signatures) |
|--------------------------------------------------------------|
| * this message is signed by Alice's key for exchange |
\--------------------------------------------------------------/
Finally, Bob can now sign Alice's reverse transaction and send it to her.
/--------------------------------------------------------------\
| * Alice message's hash |
| * Bob BTC -> Alice BTC reverse transaction (signed by Bob) |
|--------------------------------------------------------------|
| * this message is signed by Bob's key for exchange |
\--------------------------------------------------------------/
Now, both parties have all transactions and all reverse transactions they need and they can release their transactions to the network. No party will release reverse transaction, because in this case another party will do the same and both parties will just lose some coins on transaction fees. Blocks heights and hashes are needed as a timestamp and a hint what exchange rate they can use (but of course they can exchange coins using any amounts if both parties agree).
Jump to: