Bitcoin Forum

Feb/27/2012 EDIT 2:
* Post #20 has a draft.
* It works only for block chain based currencies.
* I have renamed "X" and "Y" address to "1X" (Bitcoin eXchange address) and "NX" (Namecoin eXchange address) address.
* Let me know if you have found any pitfall.
------

EDIT:
* Post #8 has an explanation how to make p2p exchange using cryptocurrency network miners to validate exchange transactions.
* It works only for bitcoin, namecoin, litecoin, etc. Won't work for fiat money.
* Make sure you understand "X" and "Y" system address structure.
* Let me know if you have found any pitfall
------

Is there a way to create a bitcoin Public Key that has the Private Key controlled by a pool of nodes?
or
Is there a way to spend bitcoin to a non standard public key address?

Sure, just copy the private key onto all the nodes.  Note that the Satoshi client will display balances weird if you do this, but there's no technical reason that multiple nodes can't share the key.

I understand that this way the first node who spend the funds will make a valid transaction. Others nodes wont be able to try after it happens.

I mean the pool controls when it is a valid transaction. Lets say:
- Every node in the pool has the same key pair
- Every node in the pool are free to "try" to spend the funds however:
  * only a node who faster solve a predetermined problem will be able to make a valid transaction
  * any other who try to spend the funds without solving the problem [before/after] will make invalid transaction

So a valid transaction is a collective pool decision.

That's almost how it actually works.

The first valid transaction transmitted is the one that the miners will consider valid.  Every transaction after that one will be dropped.

the bitcoin protocol itself doesn't support anything like that.  

but you can create something on top that does.

what you could do is encrypt the key using an algorithm that can be brute-forced and give that encrypted key to each node.  the first node to decrypt the key can spend using that key.

Is there a way to implement another set of rules where miners have to validate additional conditions for the transaction?

Lets say miners verify if this transaction satisfy certain conditions:
IF (additional_condition == true)
{
   block.add(tx)
}
else
{
  refuse tx
}

Yes:

https://en.bitcoin.it/wiki/Script
https://en.bitcoin.it/wiki/Contracts

hum...

So a distributed public/private keys + conditional script could be a solution to create a decentralized cryptocurrency exchanger.

Trust-free crypto-currency exchange with time-conditional scripts (https://bitcointalk.org/index.php?topic=22581.0)

Lets say there are:
X = Unique system bitcoin public key that all nodes is also aware of its private key (no secret!)
Y = Unique system namecoin public key that all nodes is also aware of its private key (no secret!)
A1 = Alice bitcoin address
A2 = Alice namecoin address
B1 = Bob bitcoin address
B2 = Bob namecoin address

A = Alice has 1 bitcoin (A1) and wants 200 namecoins (A2) in her address- she accepts to wait for 300 blocks (2 days?).
B = Bob is interested in this trade and will spend 200 namecoins (B2) to get 1 btc (B1) in his address.

To create a valid exchange, lets say Alice has sent 1 btc from her address (A1) to X and want to receive 100 nmc from Y into her namecoin address (A2).

option 1 - no trade:
- no one was interested in this transaction and 300 blocks was reached. The network "sign" Alice transaction with her bitcoin public key (A1). She gets her btc back.

option 2 - fraud attempt:
- Scammer used the system private key X to try to spend the coins without sending the namecoins to Y. Network refuses this transaction. Scammer gets nothing.

option 3 - valid trade:
- Bob is interested in the trade and send 200 namecoins from B2 to Y. The network "transfer/sign" Alice A2 with Y private key and also "transfer/sign" Bob B1 with X private key. The trade is completed.

Do let me know if you have found any pitfall int the post #8 idea.

the bitcoin protocol has no concept of namecoin, and thus cannot verify that the namecoins were sent.

I don't think I've understood it.
What are X and Y for?
What's wrong with this (https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains) in the first place?

I would want to also be able to exchange non chain based crypto-currencies (you could call them crypto-IOUs, since you need to trust the issuer) and other assets. The design is broken, I have to try again. But the following thread summarizes (the specification of) what I have in mind:

https://bitcointalk.org/index.php?topic=60591

You might also be interested with this thread:

https://bitcointalk.org/index.php?topic=66327 (https://bitcointalk.org/index.php?topic=66327)

It is concerned with a slightly different issue, but the same problem you are facing comes up:
(Bitcoin isn't aware of what goes on in other blockchains)

The most relevant part discusses two parallel m-of-n txn accounts in two block chains. The purpose of this is to create an exchange managed democratically by n predetermined trustees in which txns are authorized by democratic vote.

This is a stop gap solution to deal with the fact that Bitcoin isn't aware of other blockchains.

This is easily solved by:
- performing a query in another blockchain transaction that could be done by a new implementation to perform interblockchain queries. Lets say bitcoin client could:
 * ask local namecoin client to provide information about a transaction and vice-versa
 * or direct connect to namecoin nodes to ask for a specific transaction [no need to download namecoin block chain] and vice-versa.

p.s.: When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version. There are a "service" field that could be used as a flag to inform others nodes about additional features. In this case, this node is able to perform inter block chain exchanges.

Why the design is broke? This model works only for block chain based crypto currencies. New cryptos USD, EUR work perfectly however... paypal alike doesn't.

"X"=bitcoin address and "Y"=namecoin address that the network is aware of its private key. Why?

You could ask "if I'm aware of this private key, I can import this private key to my wallet and spend it". Yes, but stop here.

When this address is involved, things will work a little different. Nodes have to validate this transaction with additional work. What will be the additional work? They have to verify the internal script that ask for inter block chain work [check if the trade was completed as described].

If the trade is valid, all nodes sign the transaction with X private key [that all nodes are aware of].

Could you explain this in more detail.  Your language is a little awkward and I'm having difficulty understanding what you are saying. I have a very similar idea and I like where you are going, but I don't understand you completely.

In particular, how is the fact that bitcoind received true information about namecoin txns verified? How are these verifications incorporated into a blockchain? Please respond with a step by step explanation.

I can better do it in Portuguese. English is not my language.

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.

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 <Bob_address_used_to_make_Y_payment> <proper_transaction_message>.
g) Network listen: verifymessage <Bob_address_used_to_make_Y_payment> <Bob_signature> <proper_transaction_message>.

done :)

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?

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:
http://i40.tinypic.com/eppr14.png

#1 - Alice exchange transaction
http://i40.tinypic.com/1628c28.png

#2 - Scam attempt
http://i42.tinypic.com/debbl0.png

#3 - Bob attempt
http://i39.tinypic.com/4jexk.png

#4 - No trade (refund)
http://i44.tinypic.com/snm6c8.png

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.

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 :D

http://i40.tinypic.com/10eeul2.png

http://i41.tinypic.com/rj2q6e.png

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

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

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


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

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.

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

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!

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