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

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

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.

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

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.

You might also be interested with this thread:

https://bitcointalksearch.org/topic/the-realcoin-idea-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.

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://bitcointalksearch.org/topic/a-generic-protocol-for-cryptographic-assets-60591

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

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

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.

Yes:

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

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
}

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.

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.

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.

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.

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?