Cofresí
Member
So Cofresi spend half his weekend with a bottle of aged dominican rum, the voices in my head speaking of nothing but a decentralised drk exchange...
Mind having a very close look and tell me exactly what flaws you see and what could be wrong with this:
Cofresi's simple in-wallet btc/drk p2p exchange that leverages masternodes
Let me introduce the usual suspects....
Brokers
Server daemons, entirely separate from the darkcoind binary, running on those Masternodes whose owners are ready to take the risk and the opportunity to be a currency exchange broker for btc/drk. Some flags in the config file of this daemon could be the exact same as in darkcoind to identify the masternode and tie it to its hot or cold wallet's public key, e.g. the masternodeprivkey and whatever else is necessary, for the commission payments. The deamon runs on a separate port, e.g. 8888. China very lucky number. As a matter of fact, the brokers are nothing more than a simple bid/ask matching engine. They serve their trading clients and should be able to handle multiple clients at once. They are just here to bring the traders together very quickly. Apart from their commission they never get any money from their clients. The trades happen without them. As a masternode and just like the darkcoind deamon, the brokers will have an identifying token on the token based multi-path routing system. This token is used for inter broker communication. It should only be possible to run the broker daemon on an active masternode that fulfills the requirements of 1000 drk.
Traders (Alice & Bob)
Say Alice wants to buy 100 drk for 0.01 drk/btc with btc (BID)
Say Bob wants to sell 100 drk for 0.01 drk/btc for btc (ASK)
Distributed Order Book
I'm not be a big fan of using the drk or btc blockchain because of privacy issues and bloat.
For the sake of simplicty, I propose to make use of an already existing technology like bitmessage and adapt it to our needs. Let's call it Bidmessage. Like Bitmessage, Bidmessage doesn't have a blockchain but each client sends its messages to all users. The nodes store all those messages for two days and then delete them. I think that's perfect for our exchange wallets and masternode brokers. This message storage time could obviously be changed if needed. It's just our currency exchange internal order message storing system, so there shouldn't be any scalability problem. To prevent spam, bitmessage uses POW for each message which takes around 4 min. on an average computer. That would be impossibly long and we don't really need POW to prevent order spam, because the traders will have to pay a collateral into a deposit account in advance which later will serve as the commission for the broker. So every order message on Bidmessage needs to include the txid of the collateral transaction in order for the system to verify that the collateral has been paid. Also every message needs to include the token of the client's broker, so the broker of a matched trader can connect to with them.
https://bitmessage.org/bitmessage.pdf
Order protocol
https://bitmessage.org/wiki/Protocol_specification
Some simple and easy parseable order message which is packed into Bidmessage protocol. Like a json string with the all necessary variables
action (buy or sell)
currency to buy (drk or btc)
currency to sell (drk or btc)
order type (market or limit)
limit (limit price)
order amount
order expiration (day, gtc)
payout address (the drk or btc address where the bought coins should be sent)
txid of collateral multisig
broker token
Trades
Alice's trade order process
In order to place a market order for 100 drk at the price of 0.01 btc/drk the following steps are necessary
- Alice puts in the order info in the exchange wallet's GUI and hits SUBMIT
- Alice's exchange wallet connects to a free broker in the exchange network
- The exchange wallet sets up a collateral multisig account with the broker (2-of-2 in the btc blockchain)
- Alice's exchange wallet sends a percentage of the trading value of 1 btc (0.01 btc) into the collateral account
- Alice's exchange wallet can now broadcast the order message to the exchange network
Bob's trade order process
In order to place a market order for 1 btc at the price of 0.01 btc/drk the following steps are necessary
- Bob puts in the order info in the exchange wallet's GUI and hits SUBMIT
- Bob's exchange wallet connects to a free broker in the exchange network
- The exchange wallet sets up a collateral multisig account with the broker (2-of-2 in the drk blockchain)
- Bob's exchange wallet sends a percentage of the trading value of 100 drk (1 drk) into the collateral account
- Bob's exchange wallet can now broadcast the order message to the exchange network
Bid/Ask order matching and atomic cross chain transfer
The brokers constantly scan existing or new Bidmessage messages for new Bid/Ask orders that match the orders of their clients (Alice & Bob).
Once a broker found one or more matching order where BID >= ASK or ASK <= BID, even only partial fills, they take the oldest by timestamp matching order and try to connect
to the broker of the matched client. If they are the first to connect, they lock the order, fix a settlement price and broadcast to the network that
the order was fully filled or, in case of a partial fill, broadcast the same order again with the order amount accordingly reduced.
Alice and Bob have now been matched. The atomic cross chain transfer algorithm according to TierNolan can now be initiated. A = Alice's wallet. B = Bob's wallet. This exchange between the wallets happens almost instantaneous. The long refund times are just here in case something goes wrong (like if Bob would have changed the behaviour of his wallet and not pay A after receiving TX3).
A picks a random number x
A creates TX1: "Pay w BTC to <B's public key> if (x for H(x) known and signed by B) or (signed by A & B)"
A creates TX2: "Pay w BTC from TX1 to <A's public key>, locked 48 hours in the future, signed by A"
A sends TX2 to B
B signs TX2 and returns to A
1) A submits TX1 to the network
B creates TX3: "Pay v alt-coins to <A-public-key> if (x for H(x) known and signed by A) or (signed by A & B)"
B creates TX4: "Pay v alt-coins from TX3 to <B's public key>, locked 24 hours in the future, signed by B"
B sends TX4 to A
A signs TX4 and sends back to B
2) B submits TX3 to the network
3) A spends TX3 giving x
4) B spends TX1 using x
This is atomic (with timeout). If the process is halted, it can be reversed no matter when it is stopped.
Before 1: Nothing public has been broadcast, so nothing happens
Between 1 & 2: A can use refund transaction after 48 hours to get his money back
Between 2 & 3: B can get refund after 24 hours. A has 24 more hours to get his refund
After 3: Transaction is completed by 2
- A must spend his new coin within 24 hours or B can claim the refund and keep his coins
- B must spend his new coin within 48 hours or A can claim the refund and keep his coins
For safety, both should complete the process with lots of time until the deadlines.
https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
Again: this exchange between A and B is instantaneous and the deadlines will never be used as long as nobody tampered with the code in their wallets. I think this could be misunderstood because the quoted algorithm works just the same for two people doing everything manually. Since our wallets A and B are doing the same automatically, the process is fast as hell.
Since ultimately the traded amounts are transfered without the interference of the brokers, we shouldn't worry about the brokers being hacked or abused to steal funds. Except for the commission/collateral, it is really a peer to peer transfer.
Once the newly bought coins hit the payout address in Alice's and Bob's wallets, the collateral is released and goes to the broker masternodes public address as a commission.
Distributing broker work evenly amongst masternodes
All broker masternodes are constantly accepting new clients and scanning the Bidmessage messages for matching orders. Those with more network capacity and faster hardware can broker more trades and earn more commissions.
Multi-currency wallet
A little inconvenient shock to finish off my thoughts: in order for everything to happen in-wallet, inside the DarkcoinQT or whatever other client solution, we need to somehow merge a drk wallet with a btc wallet. Sounds like a perversion. Do we really need to do this? Well, I just don't think we should forfeit the chance of really taking control and leaving the btc side of the trading outside of the Exchange-GUI and the whole thing split across different wallets.
To keep it more light, maybe we could merge the btc/drk electrum wallets and fork a ultra-light multi-currency electrum exchange wallet instead of needing to import the btc blockchain into the DarkcoinQT. That would also facilitate a later merge with other electrum ready cryptos. On the other hand, most people that do btc/drk trading probably have the btc blockchain already on their computer, so in order to import the btc wallet into the DarkcoinQT, on the GUI-side of things it would require only a simple import wizard that asks for the wallet.dat, the privatekey and the encryption password. And a extra tab for the btc wallet.
That's it. So who's gonna code it up already? I can't. No good C++.
The system I discribed doesn't include different exchanges living in the masternode servers. It would be just one darkcoin network wide exchange. I couldn't really grasp how TT imagined this. Tungfa, maybe you or TT can clarify?
Mind having a very close look and tell me exactly what flaws you see and what could be wrong with this:
Cofresi's simple in-wallet btc/drk p2p exchange that leverages masternodes
Let me introduce the usual suspects....
Brokers
Server daemons, entirely separate from the darkcoind binary, running on those Masternodes whose owners are ready to take the risk and the opportunity to be a currency exchange broker for btc/drk. Some flags in the config file of this daemon could be the exact same as in darkcoind to identify the masternode and tie it to its hot or cold wallet's public key, e.g. the masternodeprivkey and whatever else is necessary, for the commission payments. The deamon runs on a separate port, e.g. 8888. China very lucky number. As a matter of fact, the brokers are nothing more than a simple bid/ask matching engine. They serve their trading clients and should be able to handle multiple clients at once. They are just here to bring the traders together very quickly. Apart from their commission they never get any money from their clients. The trades happen without them. As a masternode and just like the darkcoind deamon, the brokers will have an identifying token on the token based multi-path routing system. This token is used for inter broker communication. It should only be possible to run the broker daemon on an active masternode that fulfills the requirements of 1000 drk.
Traders (Alice & Bob)
Say Alice wants to buy 100 drk for 0.01 drk/btc with btc (BID)
Say Bob wants to sell 100 drk for 0.01 drk/btc for btc (ASK)
Distributed Order Book
I'm not be a big fan of using the drk or btc blockchain because of privacy issues and bloat.
For the sake of simplicty, I propose to make use of an already existing technology like bitmessage and adapt it to our needs. Let's call it Bidmessage. Like Bitmessage, Bidmessage doesn't have a blockchain but each client sends its messages to all users. The nodes store all those messages for two days and then delete them. I think that's perfect for our exchange wallets and masternode brokers. This message storage time could obviously be changed if needed. It's just our currency exchange internal order message storing system, so there shouldn't be any scalability problem. To prevent spam, bitmessage uses POW for each message which takes around 4 min. on an average computer. That would be impossibly long and we don't really need POW to prevent order spam, because the traders will have to pay a collateral into a deposit account in advance which later will serve as the commission for the broker. So every order message on Bidmessage needs to include the txid of the collateral transaction in order for the system to verify that the collateral has been paid. Also every message needs to include the token of the client's broker, so the broker of a matched trader can connect to with them.
https://bitmessage.org/bitmessage.pdf
Order protocol
https://bitmessage.org/wiki/Protocol_specification
Some simple and easy parseable order message which is packed into Bidmessage protocol. Like a json string with the all necessary variables
action (buy or sell)
currency to buy (drk or btc)
currency to sell (drk or btc)
order type (market or limit)
limit (limit price)
order amount
order expiration (day, gtc)
payout address (the drk or btc address where the bought coins should be sent)
txid of collateral multisig
broker token
Trades
Alice's trade order process
In order to place a market order for 100 drk at the price of 0.01 btc/drk the following steps are necessary
- Alice puts in the order info in the exchange wallet's GUI and hits SUBMIT
- Alice's exchange wallet connects to a free broker in the exchange network
- The exchange wallet sets up a collateral multisig account with the broker (2-of-2 in the btc blockchain)
- Alice's exchange wallet sends a percentage of the trading value of 1 btc (0.01 btc) into the collateral account
- Alice's exchange wallet can now broadcast the order message to the exchange network
Bob's trade order process
In order to place a market order for 1 btc at the price of 0.01 btc/drk the following steps are necessary
- Bob puts in the order info in the exchange wallet's GUI and hits SUBMIT
- Bob's exchange wallet connects to a free broker in the exchange network
- The exchange wallet sets up a collateral multisig account with the broker (2-of-2 in the drk blockchain)
- Bob's exchange wallet sends a percentage of the trading value of 100 drk (1 drk) into the collateral account
- Bob's exchange wallet can now broadcast the order message to the exchange network
Bid/Ask order matching and atomic cross chain transfer
The brokers constantly scan existing or new Bidmessage messages for new Bid/Ask orders that match the orders of their clients (Alice & Bob).
Once a broker found one or more matching order where BID >= ASK or ASK <= BID, even only partial fills, they take the oldest by timestamp matching order and try to connect
to the broker of the matched client. If they are the first to connect, they lock the order, fix a settlement price and broadcast to the network that
the order was fully filled or, in case of a partial fill, broadcast the same order again with the order amount accordingly reduced.
Alice and Bob have now been matched. The atomic cross chain transfer algorithm according to TierNolan can now be initiated. A = Alice's wallet. B = Bob's wallet. This exchange between the wallets happens almost instantaneous. The long refund times are just here in case something goes wrong (like if Bob would have changed the behaviour of his wallet and not pay A after receiving TX3).
A picks a random number x
A creates TX1: "Pay w BTC to <B's public key> if (x for H(x) known and signed by B) or (signed by A & B)"
A creates TX2: "Pay w BTC from TX1 to <A's public key>, locked 48 hours in the future, signed by A"
A sends TX2 to B
B signs TX2 and returns to A
1) A submits TX1 to the network
B creates TX3: "Pay v alt-coins to <A-public-key> if (x for H(x) known and signed by A) or (signed by A & B)"
B creates TX4: "Pay v alt-coins from TX3 to <B's public key>, locked 24 hours in the future, signed by B"
B sends TX4 to A
A signs TX4 and sends back to B
2) B submits TX3 to the network
3) A spends TX3 giving x
4) B spends TX1 using x
This is atomic (with timeout). If the process is halted, it can be reversed no matter when it is stopped.
Before 1: Nothing public has been broadcast, so nothing happens
Between 1 & 2: A can use refund transaction after 48 hours to get his money back
Between 2 & 3: B can get refund after 24 hours. A has 24 more hours to get his refund
After 3: Transaction is completed by 2
- A must spend his new coin within 24 hours or B can claim the refund and keep his coins
- B must spend his new coin within 48 hours or A can claim the refund and keep his coins
For safety, both should complete the process with lots of time until the deadlines.
https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
Again: this exchange between A and B is instantaneous and the deadlines will never be used as long as nobody tampered with the code in their wallets. I think this could be misunderstood because the quoted algorithm works just the same for two people doing everything manually. Since our wallets A and B are doing the same automatically, the process is fast as hell.
Since ultimately the traded amounts are transfered without the interference of the brokers, we shouldn't worry about the brokers being hacked or abused to steal funds. Except for the commission/collateral, it is really a peer to peer transfer.
Once the newly bought coins hit the payout address in Alice's and Bob's wallets, the collateral is released and goes to the broker masternodes public address as a commission.
Distributing broker work evenly amongst masternodes
All broker masternodes are constantly accepting new clients and scanning the Bidmessage messages for matching orders. Those with more network capacity and faster hardware can broker more trades and earn more commissions.
Multi-currency wallet
A little inconvenient shock to finish off my thoughts: in order for everything to happen in-wallet, inside the DarkcoinQT or whatever other client solution, we need to somehow merge a drk wallet with a btc wallet. Sounds like a perversion. Do we really need to do this? Well, I just don't think we should forfeit the chance of really taking control and leaving the btc side of the trading outside of the Exchange-GUI and the whole thing split across different wallets.
To keep it more light, maybe we could merge the btc/drk electrum wallets and fork a ultra-light multi-currency electrum exchange wallet instead of needing to import the btc blockchain into the DarkcoinQT. That would also facilitate a later merge with other electrum ready cryptos. On the other hand, most people that do btc/drk trading probably have the btc blockchain already on their computer, so in order to import the btc wallet into the DarkcoinQT, on the GUI-side of things it would require only a simple import wizard that asks for the wallet.dat, the privatekey and the encryption password. And a extra tab for the btc wallet.
That's it. So who's gonna code it up already? I can't. No good C++.
- Different Exchanges can compete for customers (voting system, who is best and trusted...
let the exchanges compete on quality of service and user experience)
Tx TT for the input
The system I discribed doesn't include different exchanges living in the masternode servers. It would be just one darkcoin network wide exchange. I couldn't really grasp how TT imagined this. Tungfa, maybe you or TT can clarify?
Last edited by a moderator: