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

[BrBoy]

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?

[Revalin]

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.

[BrBoy]

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.

[Revalin]

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.

[koin]

 * only a node who faster solve a predetermined problem will be able to make a valid transaction

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.

[BrBoy]

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
}

[Revalin]

Yes:

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

[BrBoy]

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

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.

[BrBoy]

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

[koin]

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.

[jtimon]

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

I don't think I've understood it.
What are X and Y for?
What's wrong with this 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

[cunicula]

You might also be interested with this thread:

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.

[BrBoy]

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.

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.

[BrBoy]

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

I don't think I've understood it.
What are X and Y for?
What's wrong with this 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

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

[cunicula]

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.

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.

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.

[BrBoy]

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

[jtimon]

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.

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.

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

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?

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

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

[BrBoy]

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.

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.

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

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?

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

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

[jtimon]

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?

[BrBoy]

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)