Topic: P2P Exchange - "1X" and "NX", a new concept in the block (Read 4939 times)

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://bitcointalksearch.org/topic/a-decentralized-anonymous-exchange-between-chains-31643
https://bitcointalksearch.org/topic/a-fee-only-chain-before-the-miners-reward-halves-32258

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

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

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!

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'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

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)

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.

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?
It also could be this way but I really prefer to stay as simple as possible using only existing infrastructure - if possible.
+1
+1

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.


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...

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.

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.

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)".

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

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

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

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.

I have made some drafts to try to better explain it. No protocol change as it will use existing protocol and 2 commands (signmessage and verifymessage).

The advantage: Alice is free to make possible trade even if her do not have any offer or contact. She only needs to wait n blocks. This method is similar to Mtgox Ask/Bid exchange. Where you read Alice and Bob replace them with Ask and Bid. Now you have a decentralized MtGox for block chain based cryptocurrencies.

p.s.: I have renamed "X" to "1X" (btc exchange address) and "Y" to "NX" (nmc exchange address)
Legends:


#1 - Alice exchange transaction


#2 - Scam attempt


#3 - Bob attempt


#4 - No trade (refund)

I still don't get it. I still don't get the purpose of X and Y. I'm not convinced you don't need to modify the protocol neither.
Do you have a post describing it in Portuguese?

Also...
What are the advantages of this system over the exchange across chains with secrets and nLockTime described in the wiki?

No need to change the protocol. Only needed to change:
- client version
- set the command version service to non Zero
- implement the exchange feature

>>>Wait, wait, all nodes sign with the same key? That doesn't makes much sense to me.
My bad. All nodes CAN sign it but only someone who made the Y transaction can legitimate claim this payment 'cause only WHO made the payment CAN proper use the command "signmessage". All others attempts will be rejected (rejected by the network using "verifymessage", etc).

Bob makes the payment to "Y" and only Bob legitimate are allowed to claim "X". How? Why?

How
Remember, every node knows "X" private key. Also Bob knows it. So:
a) Bob creates a new tx sending "X" funds to "B1" [B1 is a public key owned by Bob] and then sign it with "X" private key.
b) Y payment is used as proof of work.
c) The network VERIFY Bob Tx. If it is a legitimate transaction, it will be added to block chain if no it is rejected.
d) Alice also gets her coins from "Y" to "A2" as already described.

Why
Bob are allowed to claim it 'cause:
e) Bob owns the address that has made the Y payment [stored in his wallet]
f) Bob proofs it using: signmessage .
g) Network listen: verifymessage .

done

I mean my design is broken. I just have to thought it again. the design for the messages in there is wrong. But I'm pretty sure it's completely feasible. My proposal allows not only chain coins to be traded, also centrally issued crypto-currencies that would work in a very similar way to open transactions.


So you need to change the bitcoin protocol. I ask again, What's wrong with what's described in the wiki for trading across chains?


Wait, wait, all nodes sign with the same key? That doesn't makes much sense to me.