P2P Exchange - "1X" and "NX", a new concept in the block

[cunicula]

There is a bit of a problem in that the counterparty can wait 300 blocks before deciding to do the txn. The exchange rate may move in the meantime and counterparties will take advantage of this by completing only favorable txns. Can the wait time be reduced to say 3 blocks without issue?

Otherwise the system will not support speculative trades. You will only end up successfully making trades that you regret having initiated.

[BrBoy]

No. The block count is the max limit of time to Alice. Not for Bob.

A match occur when Bob pay what Alice ask.

If the exchange rate changes and Alice thinks she will lose money... she does:
"I'm Alice. I have signed this message using 1X private key for transaction #123 to get my money back. The proof of work is #AliceCancel that I sign using 1Alice private key."

The network checks... if Bob has not paid, Alice get her money back.

......

I have made some draft screens

[cunicula]

I like it. If Alice can cancel her order prior to fulfillment, then exchange rate movements are not an issue. Make it happen.

[BrBoy]

I like it. If Alice can cancel her order prior to fulfillment, then exchange rate movements are not an issue. Make it happen.

Hehe thanks. I hope I have made things clear with drafts.

[BrBoy]

I was stressing this model trying to find pitfalls. Today I have some considerations.

Homogeneous scenery:
a) 100% bitcoin/namecoin clients ARE NOT patched with the proper implementation. They DO NOT recognizes and ALSO DO NOT complies the set of rules for "1X" and "NX" address.
b) 100% bitcoin/namecoin clients ARE patched with the proper implementation. They recognizes and also complies the set of rules for "1X" and "NX" address.

Heterogeneous scenery:
c) a small fraction of bitcoin/namecoin clients ARE patched with the proper implementation. They recognizes and ALSO complies the set of rules for "1X" and "NX" address.
d) a small fraction of bitcoin/namecoin clients ARE patched with a malicious implementation. They recognizes but DON'T properly complies with the set of rules for "1X" and "NX" address.

My research results is still inconclusive for each scenery (hey... I need some help here!):
a) The network have NO ability to comply with p2p exchange specification.
b) The best of the worlds. Here is where the network complies with p2p exchange specification. I have not found yet any flaw.
c) The probably scenery. Here some nodes are complying with p2p exchange specification but others nodes do not collaborate with the work. My research is... inconclusive. I need to better understand this point. Maybe a core developer could help here.
d) Pending. I need to better understand "c)".

[Sukrim]

What do you really need to know from other blockchains/Bitcoin?

As far as I understood you only need to know if a transaction has been validated into a block and you need to know either or both the block number and the block timestamp (300 blocks in Bitcoin might not be 300 blocks in namecoin at the same time).

I'm not sure where the proof of work comes into play - wouldn't it be enough if you instead send "My transaction was 200 NMC to NX using NAny Address - included as transaction 12345 in NMC block 54321"? Clients then would ask either some Namecoin clients that support some kind of protocol or (in the beginning/alternatively) some trusted public service or a local namecoind for: Is transaction 12345 really (as the buyer claimed) in block 54321of the longest NMC chain? What's the current NMC block height (is it high enough to make sure the claimed transaction is really confirmed? It might even be nice for Alice to specify when she accepts this - selling 10000 BTC might require higher confirmation counts than just buying 1-2 NMC.)

Maybe you meant something like this already? This then wouldn't be a "proof of work" though.

[BrBoy]

I need to better understand what happen when, lets say, 10% of the nodes [btc/nmc] are complying with the specification when there are 90% that doesn't?

A response for that mix of "patched" and "not patched" clients comportment in the same network is what is needed.

[Prayer]

I need to better understand what happen when, lets say, 10% of the nodes [btc/nmc] are complying with the specification when there are 90% that doesn't?

A response for that mix of "patched" and "not patched" clients comportment in the same network is what is needed.

More importantly, what about other coins?  Are you really thinking that you can get every single coin to implement code to make them be able to do this sort of thing with every other coin?

How about building a new P2P network that's purpose designed to handle exchanges and other types of complex transactions.  Let's call it the Multi-Block Exchange, or MBX.  It might make for some good synergy to include the Stratum project, which is aimed at facilitating transactions with slim/selfish clients.  Having a network of nodes already charged with maintaining the blockchains for every known coin would allow servers to pull double duty.

The client/wallet software would be separate from the server, and capable of initiating any sort of transaction for any of the coins supported by the server network.

There is a bit of a problem in that the counterparty can wait 300 blocks before deciding to do the txn. The exchange rate may move in the meantime and counterparties will take advantage of this by completing only favorable txns. Can the wait time be reduced to say 3 blocks without issue?

Otherwise the system will not support speculative trades. You will only end up successfully making trades that you regret having initiated.

On the trading side, implement it as a bid-ask matrix, just like traditional exchanges.  Issue a buy or sell order, and it's included in the next appropriate transaction, which in turn is mined into a block.

As blocks are mined, the exchange rates are updated and republished.  All automatic like, but without centralized control.

A single transaction might include dozens of exchanges between multiple parties....  this would be a pretty complex algorithm, but completely doable.  A block might include hundreds of exchanges, but only a few transactions, as all transactions of a certain size would be pooled together, with the change falling through to the next transaction in line.  The final transaction would be change back to the originators refunding whatever couldn't be exchanged in that round.

In the simplest example... I put a buy on 1000NMC for 1BTC, but only 500 is available, so 5BTC would be refunded at the end of the transaction.


There are a number of things that would need to be worked out... but off the top of my head, it would probably be best if the client and server were separate packages, and support for the various block chains be built in modules to allow new chains to be easily added, removed, or modified without affecting the core or other modules.

Yeah, we need to get a development team together for this...

[BrBoy]

More importantly, what about other coins?  Are you really thinking that you can get every single coin to implement code to make them be able to do this sort of thing with every other coin?

I believe once we have a patch for at least 2 coins... it could be adapted to any other. No problem, it also could be a new application.

The heterogeneous scenery question remains:
- Older versions of bitcoin clients will respect the decision of the applications with the new Exchange rules implementation?
- What happens when, lets say, 10% of the network follow the exchange rules but 90% are not aware of these rules?
- The validation script inside the transaction made by new applications will be respected by old clients?

How about building a new P2P network that's purpose designed to handle exchanges and other types of complex transactions.  Let's call it the Multi-Block Exchange, or MBX.  It might make for some good synergy to include the Stratum project, which is aimed at facilitating transactions with slim/selfish clients.  Having a network of nodes already charged with maintaining the blockchains for every known coin would allow servers to pull double duty.

It also could be this way but I really prefer to stay as simple as possible using only existing infrastructure - if possible.

There are a number of things that would need to be worked out... but off the top of my head, it would probably be best if the client and server were separate packages, and support for the various block chains be built in modules to allow new chains to be easily added, removed, or modified without affecting the core or other modules.

+1

Yeah, we need to get a development team together for this...

+1

[Prayer]

More importantly, what about other coins?  Are you really thinking that you can get every single coin to implement code to make them be able to do this sort of thing with every other coin?

I believe once we have a patch for at least 2 coins... it could be adapted to any other. No problem, it also could be a new application.

The heterogeneous scenery question remains:
- Older versions of bitcoin clients will respect the decision of the applications with the new Exchange rules implementation?
- What happens when, lets say, 10% of the network follow the exchange rules but 90% are not aware of these rules?
- The validation script inside the transaction made by new applications will be respected by old clients?

If separate chains exist and you want a P2P exchange, that exchange either has to be implemented within each and every chain, or you have to have a trusted 3rd party system to handle transactions between each of those other chains.

The problem I see with getting every client to support every chain (C), is that the relationships (R) will quickly get out of hand: R=C(C/2)-C/2.  It might actually be +C/2, but I'm too lazy to do the math right now.  Either way, that means that 10 chains will have either 45 or 50 relationships to maintain.  I think you would have better luck trying to herd cats than coders.  Even at 1 update per year per client, that's still 10 updates per year that have to be applied to every project.

The problem with a super-client that can handle cross-chain transactions, is that will potentially supersede the stand-alone chains, rendering one or more of them obsolete.

[cunicula]

The super chain is definitely the way to go it just needs to:
1) hold a private key to accounts in both bitcoin and each secondary coin (not sure how this would work, keys must be.secret.from everyone)
2) keep a database of all bids and asks for each coin with the moneys escrowed in its account
3) distribute coins from its accounts when bids and asks cross
4) only initiate sends and distributions once txns have enough confirmations to be effectively.irreversible (a reorg of the database is okay, a reorg of txns that.have been executed destroys the.system)

[Prayer]

The super chain is definitely the way to go it just needs to:
1) hold a private key to accounts in both bitcoin and each secondary coin (not sure how this would work, keys must be.secret.from everyone)
2) keep a database of all bids and asks for each coin with the moneys escrowed in its account
3) distribute coins from its accounts when bids and asks cross
4) only initiate sends and distributions once txns have enough confirmations to be effectively.irreversible (a reorg of the database is okay, a reorg of txns that.have been executed destroys the.system)

I've been struggling with these same questions myself, but didn't want to get into the meat of it until it was time.  There are definitely some challenges that need to be overcome, but I think a P2P Exchange system is an interesting problem that can be solved and potentially expanded to include real-world currencies and commodities (topics for later discussion).

1) Keys... I don't think they would be needed.  At first I did, but then as my thoughts developed into the process I describe below, I don't think so...

2) database... this is easy.  It would be built right into the blockchain... as traders trade, the ask/bid spread is automatically updated and you have your prices automatically transmitted to every client in the network.

3) My original thought, was to accept inputs from any given coin at a given value, then distribute the pot to the recipients in their desired currency.  However, this process got very complicated very quickly, requiring all kinds of keys to be tossed around in the open.  I think I came up with a workable solution... read on if you dare.

4) Agreed.  This was a major stumbling block as I think about how to make the whole P2P process work.  Your questions triggered some more thoughts in my screwed up mind, and I think I actually managed to figure out a solution to the whole problem.

Now, I'm not sure if what I describe here is purely a business process (which is how I'm describing it), or if it would require mathematical proof, but I'm leaning towards the former...

First, some values: BTC/NMC @ 0.005; BTC/MBX @ 0.125 (1BTC = 200NMC = 8MBX)

Second, assume a transaction value of 0.3%, divided by 3 for each type of coin.

Bob advertises NMC for sale, Alice sees that advertisement and issues a buy against it for 200NMC.  Both clients exchange the necessary information to construct the transactions as follows:

Bob sends an MBX transaction
 * 8 MBX deposit
 * 0.008 MBX tx fee
 * properly signed transaction to send 200 NMC to Alice (including tx fees)

Alice sends a similar transaction with deposit, fees, and BTC payload

The MBX network, seeing a valid exchange transaction, would broadcast the NMC and BTC transactions to their respective networks.

Once a mutually agreed upon confirmation period expires, MBX would then process the deposits, refunding each or awarding both to one party or the other if one of the 3rd party transactions failed.

There is one specific challenge I'm not ready to think about yet, and that's determining if a transaction has been rejected or is still waiting to get into a block.

-Prayer

[cunicula]

The MBX network, seeing a valid exchange transaction, would broadcast the NMC and BTC transactions to their respective networks.

How does the MBX network broadcast txns unless it has private keys to a NMC and BTC account?
Money needs to be escrowed in the MBX accounts in NMC and BTC first and then sent to Alice and Bob when their bid and ask orders cross.

[Prayer]

The MBX network, seeing a valid exchange transaction, would broadcast the NMC and BTC transactions to their respective networks.

How does the MBX network broadcast txns unless it has private keys to a NMC and BTC account?
Money needs to be escrowed in the MBX accounts in NMC and BTC first and then sent to Alice and Bob when their bid and ask orders cross.

I might be off my rocker, but you create a new class, CMBXTransaction that extends CTransaction and adds a new member of CTransaction.  Basically embedding a transaction within a transaction.

The whole thing would be mined into the MBX chain, but only after sending the BTC transaction out for confirmation on the BTC chain.

-Prayer

PS: I'm still getting my feet wet in the code & protocol, so forgive me if I'm referencing the wrong object!

[Prayer]

BrBoy,

I really didn't intend to hijack your thread... it's just that it really got me thinking in overdrive.  I still don't see how this could ever be effectively included in every individual blockchain, it would make a huge mess of dependencies that would be a nightmare to maintain... but a 3rd party P2P system should be completely doable (like what I describe or maybe something completely different).

-Prayer

[jtimon]

I haven't look into Prayer's proposal, but BrBoy proposal seems to require changing the protocol.
Changing the rules miners need to check is changing the protocol.
I proposed something similar, but with a middlecoin/exchangeChain. Doesn't require the other chains to change (but they can if there's a consensus):

https://bitcointalk.org/index.php?topic=31643.0
https://bitcointalk.org/index.php?topic=32258.0

Maybe you're interested. I now think that contracts are a superior solution.