this is what LN is about. but with one extra feature the OP has missed. multisigs
Bob and Alice both transmit an public key to each other of both a bitcoin and litecoin format.(empty address contains no funds)
1bobsbitcoinaddress
1alicesbitcoinaddress
these are both combined to create the bitcoin multisig
3bobaliceBTCmultisigaddress
Lbobsbitcoinaddress
Lalicesbitcoinaddress
these are both combined to create the litecoin multisig
3LbobaliceLTCmultisigaddress
alice puts the altcoin into 3LbobaliceLTCmultisigaddress
bob puts the bitcoin into 3bobaliceBTCmultisigaddress
now the funds are inside locked. the funds need both sides to sign each multisig. meaning not one person can move the funds alone
because both the multisigs have CLTV and CSV both parties have a mutually agreed destruction penalty if they dont agree to sign
Topic: Cryptocurrency Exchange without a trusted third party (Read 528 times)
why are you making things extremely complicated for no reason and with a big ass wall of text?!!!
first of all the notion of exchanging private keys is ridiculous. because as long as the on chain sending is available there is no need to exchange private keys. it is like giving someone your bank account instead of writing him a check (cheque?)!!
there is a simple solution instead of this strange method that nobody understands or at least not easily, and the solution is using a multi signature address.
Alice and Bob make a multi sig bitcoin address (2 signatures) each holding one key and Bob sends the amount to that address. Alice sends him the altcoin he wants and a transaction for him to sign that spends the bitcoins in that multi sig address. when Bob received the altcoins he signs the transaction which is half signed by Alice and broadcasts it completing the exchange.
easy and understandable while using the protocols already available to everyone!
first of all the notion of exchanging private keys is ridiculous. because as long as the on chain sending is available there is no need to exchange private keys. it is like giving someone your bank account instead of writing him a check (cheque?)!!
there is a simple solution instead of this strange method that nobody understands or at least not easily, and the solution is using a multi signature address.
Alice and Bob make a multi sig bitcoin address (2 signatures) each holding one key and Bob sends the amount to that address. Alice sends him the altcoin he wants and a transaction for him to sign that spends the bitcoins in that multi sig address. when Bob received the altcoins he signs the transaction which is half signed by Alice and broadcasts it completing the exchange.
easy and understandable while using the protocols already available to everyone!
hero member
Activity: 2912
Merit: 541
Leading Crypto Sports Betting & Casino Platform
i think its like exchanges between bitcoin into fiat like what i am do, for example, i sell my bitcoin into my friends, which is local exchanger, he send me the money into my account, but i don't think its good with altcoin, because i think we still need third party to make selling or buying.
I've tried to think of a way to make an exchange or sale without a third party, and the only method I can see as viable is a face to face exchange.
The best alternative in my opinion is the use of multi-sigs in Bitcoin, That involves 3 parties - a buyer, a seller, and an arbitrator. You submit the transaction with a retriction that it needs at least two of the three sigs to be spent.
The best alternative in my opinion is the use of multi-sigs in Bitcoin, That involves 3 parties - a buyer, a seller, and an arbitrator. You submit the transaction with a retriction that it needs at least two of the three sigs to be spent.
Yes that can be done but we still want a trusted third party since many scammers keep popping out like mushrooms in the internet. I even been a victim for five times already. But your tip can be done if our client is a trusted friend with high trust ratings but if applied to someone we just knew it is very risky and so a trusted third party is still recommended.
There can be an automated triggered escrow which requires some cross blockchain activity and monitoring and some serious coding skills, or just pay at least %0.2 fee to avoid all the hassle and save yourself going through different steps.
.
. 
I did not completely get your protocol 5 but all the 5 protocols aren't safe for either parties (neither Alice nor Bob).
There is always a need of a third party when two unknown users are exchanging cryptocurrencies. Even in protocol 5, one party can lose a part of the ransom. Why can't the protocol refund the ransom to the sender if the other party doesn't send the coins in time?
There is always a need of a third party when two unknown users are exchanging cryptocurrencies. Even in protocol 5, one party can lose a part of the ransom. Why can't the protocol refund the ransom to the sender if the other party doesn't send the coins in time?
I didn't have the patience to read all that long post, sorry about that, but I've already seen some problems.
1. Many people prefer off-chain trading, since they will not pay the tx fee for every tiny bit they exchange. And this way they can exchange in both directions when the market allows it.
2. Your methods take significant time (again, because they are on-chain), time when the prices can change significantly, time the trader is wasting...
3. You seem to want to rely on a feature the (most) coins don't have and most will not bother implementing.
1. Many people prefer off-chain trading, since they will not pay the tx fee for every tiny bit they exchange. And this way they can exchange in both directions when the market allows it.
2. Your methods take significant time (again, because they are on-chain), time when the prices can change significantly, time the trader is wasting...
3. You seem to want to rely on a feature the (most) coins don't have and most will not bother implementing.
Cross posting from Metzdowd...
Just wondering if I could have comments on the following. Flames welcome!
1. Alice has Altcoin, but wants Bitcoin.
2. Bob has Bitcoin, but wants Altcoin.
How can they exchange cryptocurrencies without a trusted third party?
Protocol #1
-----------
1. Alice moves Altcoin to a new Altcoin address
2. Bob moves Bitcoin to a new Bitcoin address
3. They exchange private keys
4. Alice now has Bitcoin, Bob now has Altcoin.
There are many problems here, but let's concern ourselves with this one - as
they both know each other's private keys, stealing can occur.
Protocol #2
-----------
To solve the stealing problem, they should keep their private keys to
themselves:
1. Alice tells Bob her Bitcoin address
2. Bob tells Alice his Altcoin address
3. Alice moves Altcoin into Bob's Altcoin address
4. Bob moves Bitcoin into Alice's Bitcoin address
5. Alice now has Bitcoin, Bob now has Altcoin.
The problem now is that if Alice skips step 3, she gets to keep her Altcoin
and her newly aquired Bitcoin (this is essentially stealing from Bob).
Protocol #3
-----------
What we have here (and in the above protocols) is a trust issue - Alice doesn't
trust Bob, and Bob can't trust Alice. I don't blame either of them.
Here's a way for them to build some trust between them:
1. Alice tells Bob her Bitcoin address
2. Bob tells Alice his Altcoin address
3. Loop until we have exchanged the required amount
3.1 Alice moves a little bit of Altcoin into Bob's Altcoin address
3.2 Bob moves a little of Bitcoin into Alice's Bitcoin address
4. Alice now has Bitcoin, Bob now has Altcoin.
At each step, they could move the same as the last iteration, or they could
increase by some function with faster growth.
The cool thing about this protocol is it can be used today between most
cryptocurrencies without modification.
The problem here is that Alice can still skip step 3. If she does this between
a big increase of the iteration function, it could lead to a significant
steal.
Protocol #4
-----------
An alternative to building trust could be used if only there was a way of
punishing cheaters rather than rewarding them...
"Guys, it’s time for some game theory":
1. Alice creates an Altcoin ransom transaction with a refund timeout
2. Bob creates a Bitcoin ransom transaction with a refund timeout
3. They exchange ransom unlock keys
4. Proceed to Protocol #2.
If cheating is detected during stage 3 or 4, the player spends the other
player's ransom (e.g output disappears to an invalid address forever).
Protocol #4 can be considered a game with stages, having the following rules:
1. We progress to Coin Exchange if and only if Co-op/Co-op was played within
Ransom Setup. Otherwise the game exits early
2. The Co-op/Co-op selection within Ransom Refund can only be played if and
only if Co-op/Co-op was played within Coin Exchange.
Here's the payoff matricies:
1. Ransom Setup
2. Coin Exchange
3. Ransom Refund
If we progress to completion, the total payoff matrix follows Stag Hunt:
However unlike a usual Stag Hunt, players choose the Co-op/Co-op payoff
dominant strategy because of the credible commitment via Ransom Setup.
tl;dr: a ransom made high enough (i.e at least r > 2x) makes a strong case for
players to play cooperatively.
Caveat: This assumes ideal conditions. As two cryptocurrenices move at
different speeds, there could be moments where it is too late for one player to
spend the ransom while the other player still can, thus leaving risk on the
table for one player.
Protocol #5
-----------
The problem with Protocol #4 is that if Alice skips step 1, Bob loses the
ransom (luckily enough though, Alice can't steal anything). Let's fix that:
1. Alice and Bob exchange ransom unlock keys
2. Loop until ransoms are at least twice the size of the required funds
2.1. Alice moves a little bit of Altcoin into an Altcoin ransom transaction with timeout
2.2. Bob moves a little bit of Bitcoin into a Bitcoin ransom transaction with timeout
3. Proceed to Protocol #2.
Like Protocol #4, we again have a game with stages, only this time Ransom Setup
is now split into a finitely repeated game. Luckily, our total payoff matrix is
the same.
Anti-caveat: As the ratcheting up of ransom transactions was done over time, so
too do the ransom transactions expirations. This effectively leaves an ever
decreasing total ransom that can be spent by only one player.
Implementation
--------------
All that's needed to perform Protocol #4 and #5, is the ability to create
transactions that allow refund timeouts. Peter Todd's OP_CHECKLOCKTIMEVERIFY
(BIP 65) for Bitcoin does exactly this.
As for Protocol #3, we can already do that today. Anyone want to trade
Alfie
Just wondering if I could have comments on the following. Flames welcome!
1. Alice has Altcoin, but wants Bitcoin.
2. Bob has Bitcoin, but wants Altcoin.
How can they exchange cryptocurrencies without a trusted third party?
Protocol #1
-----------
1. Alice moves Altcoin to a new Altcoin address
2. Bob moves Bitcoin to a new Bitcoin address
3. They exchange private keys
4. Alice now has Bitcoin, Bob now has Altcoin.
There are many problems here, but let's concern ourselves with this one - as
they both know each other's private keys, stealing can occur.
Protocol #2
-----------
To solve the stealing problem, they should keep their private keys to
themselves:
1. Alice tells Bob her Bitcoin address
2. Bob tells Alice his Altcoin address
3. Alice moves Altcoin into Bob's Altcoin address
4. Bob moves Bitcoin into Alice's Bitcoin address
5. Alice now has Bitcoin, Bob now has Altcoin.
The problem now is that if Alice skips step 3, she gets to keep her Altcoin
and her newly aquired Bitcoin (this is essentially stealing from Bob).
Protocol #3
-----------
What we have here (and in the above protocols) is a trust issue - Alice doesn't
trust Bob, and Bob can't trust Alice. I don't blame either of them.
Here's a way for them to build some trust between them:
1. Alice tells Bob her Bitcoin address
2. Bob tells Alice his Altcoin address
3. Loop until we have exchanged the required amount
3.1 Alice moves a little bit of Altcoin into Bob's Altcoin address
3.2 Bob moves a little of Bitcoin into Alice's Bitcoin address
4. Alice now has Bitcoin, Bob now has Altcoin.
At each step, they could move the same as the last iteration, or they could
increase by some function with faster growth.
The cool thing about this protocol is it can be used today between most
cryptocurrencies without modification.
The problem here is that Alice can still skip step 3. If she does this between
a big increase of the iteration function, it could lead to a significant
steal.
Protocol #4
-----------
An alternative to building trust could be used if only there was a way of
punishing cheaters rather than rewarding them...
"Guys, it’s time for some game theory":
1. Alice creates an Altcoin ransom transaction with a refund timeout
2. Bob creates a Bitcoin ransom transaction with a refund timeout
3. They exchange ransom unlock keys
4. Proceed to Protocol #2.
If cheating is detected during stage 3 or 4, the player spends the other
player's ransom (e.g output disappears to an invalid address forever).
Protocol #4 can be considered a game with stages, having the following rules:
1. We progress to Coin Exchange if and only if Co-op/Co-op was played within
Ransom Setup. Otherwise the game exits early
2. The Co-op/Co-op selection within Ransom Refund can only be played if and
only if Co-op/Co-op was played within Coin Exchange.
Here's the payoff matricies:
1. Ransom Setup
Code:
+-------+--------+-------+
| | | |
| | Co-op | Cheat |
| | | |
+-------+--------+-------+
| | | |
| Co-op | -r, -r | -r, r |
| | | |
+-------+--------+-------+
| | | |
| Cheat | r, -r | r, r |
| | | |
+-------+--------+-------+
| | | |
| | Co-op | Cheat |
| | | |
+-------+--------+-------+
| | | |
| Co-op | -r, -r | -r, r |
| | | |
+-------+--------+-------+
| | | |
| Cheat | r, -r | r, r |
| | | |
+-------+--------+-------+
2. Coin Exchange
Code:
+-------+------------+------------+
| | | |
| | Co-op | Cheat |
| | | |
+-------+------------+------------+
| | | |
| Co-op | x, x | -x, 2x |
| | | |
+-------+------------+------------+
| | | |
| Cheat | 2x, -x | x, x |
| | | |
+-------+------------+------------+
| | | |
| | Co-op | Cheat |
| | | |
+-------+------------+------------+
| | | |
| Co-op | x, x | -x, 2x |
| | | |
+-------+------------+------------+
| | | |
| Cheat | 2x, -x | x, x |
| | | |
+-------+------------+------------+
3. Ransom Refund
Code:
+-------+--------+-------+
| | | |
| | Co-op | Cheat |
| | | |
+-------+--------+-------+
| | | |
| Co-op | r, r | 0, 0 |
| | | |
+-------+--------+-------+
| | | |
| Cheat | 0, 0 | 0, 0 |
| | | |
+-------+--------+-------+
| | | |
| | Co-op | Cheat |
| | | |
+-------+--------+-------+
| | | |
| Co-op | r, r | 0, 0 |
| | | |
+-------+--------+-------+
| | | |
| Cheat | 0, 0 | 0, 0 |
| | | |
+-------+--------+-------+
If we progress to completion, the total payoff matrix follows Stag Hunt:
Code:
+-------+------------+------------+
| | | |
| | Co-op | Cheat |
| | | |
+-------+------------+------------+
| | | |
| Co-op | x, x | -x-r, 2x-r |
| | | |
+-------+------------+------------+
| | | |
| Cheat | 2x-r, -x-r | x-r, x-r |
| | | |
+-------+------------+------------+
| | | |
| | Co-op | Cheat |
| | | |
+-------+------------+------------+
| | | |
| Co-op | x, x | -x-r, 2x-r |
| | | |
+-------+------------+------------+
| | | |
| Cheat | 2x-r, -x-r | x-r, x-r |
| | | |
+-------+------------+------------+
However unlike a usual Stag Hunt, players choose the Co-op/Co-op payoff
dominant strategy because of the credible commitment via Ransom Setup.
tl;dr: a ransom made high enough (i.e at least r > 2x) makes a strong case for
players to play cooperatively.
Caveat: This assumes ideal conditions. As two cryptocurrenices move at
different speeds, there could be moments where it is too late for one player to
spend the ransom while the other player still can, thus leaving risk on the
table for one player.
Protocol #5
-----------
The problem with Protocol #4 is that if Alice skips step 1, Bob loses the
ransom (luckily enough though, Alice can't steal anything). Let's fix that:
1. Alice and Bob exchange ransom unlock keys
2. Loop until ransoms are at least twice the size of the required funds
2.1. Alice moves a little bit of Altcoin into an Altcoin ransom transaction with timeout
2.2. Bob moves a little bit of Bitcoin into a Bitcoin ransom transaction with timeout
3. Proceed to Protocol #2.
Like Protocol #4, we again have a game with stages, only this time Ransom Setup
is now split into a finitely repeated game. Luckily, our total payoff matrix is
the same.
Anti-caveat: As the ratcheting up of ransom transactions was done over time, so
too do the ransom transactions expirations. This effectively leaves an ever
decreasing total ransom that can be spent by only one player.
Implementation
--------------
All that's needed to perform Protocol #4 and #5, is the ability to create
transactions that allow refund timeouts. Peter Todd's OP_CHECKLOCKTIMEVERIFY
(BIP 65) for Bitcoin does exactly this.
As for Protocol #3, we can already do that today. Anyone want to trade
Alfie
Jump to: