Quote from: led_lcd on February 20, 2014, 06:07:13 AM

Quote from: Alias on February 19, 2014, 02:27:03 PM

Quote from: led_lcd on February 19, 2014, 01:32:31 PM

Quote from: Alias on February 19, 2014, 01:12:03 PM

Quote from: uma97081 on February 19, 2014, 12:55:37 PM

Quote from: led_lcd on February 19, 2014, 12:40:20 PM

Here's an option to reduce the risk of a single entity controlling all of XBTC causing systemic risk. How about I transfer XBTC to the developers and they by enrolment allocate portions of the XBTC to entities who wish to underwrite the value of XBTC to BTC. The more the better. That way, if any single entitty was to do a 'runner' it would have a reduced impact to the value of XBTC.

In such case, we need 100+ underwriters, I think.

In a situation like this each underwriter/backer can accept and exchange each others XBTC and BTC. There could still be room for Poloniex or another one or two larger more liquid underwriters to act as clearing houses for all the smaller underwriters.

I think there is only 1 way to perfectly implement this pegged value idea. Create a DAC (Distributed Autonomous Community) whose sole function is to take an amount of BTC as an input and return the same amount of XBTC to you in return. This DAC will run on at least all the underwriters computers. This keeps it as simple as possible. The DAC is trust-less and starts with the 21 Million XBTC. To get the XBTC you have to feed it with BTC. All the accounts would be transparent and really simple - only 1 address is needed for both the BTC and XCP.

This would work for any other crypto-currency too. The only caveat being that the members of the DAC community would have to run the blockchains of each cryptocurrency involved.

It certainly would be possible to code up a simple function as you described. The question I have though is how would the DAC essentially 'advertise' the directory of the addresses that serve up this function vs rogue nodes which would just eat up BTC?

If I'm understanding your question correctly then the answer looks to be quite simple - the blockchain. Anyone can send BTC to the DAC and the DAC sends the XBTC back in return. Once you know the DAC's public key you can see all of these transactions and individuals can sign messages with their private keys to prove they were involved in transactions.

Warning - Wall of text ahead

I'd be happy to take this to the official forum...

I headed off to bed and found I came to a similar conclusion. I think it's completely do-able and awesome. I've expanded what you have said into greater detail and some implementation details. There are some limitations that I can think of. I'd be happy to hear comments and how to get around the limitations.

Let's say that each node will be sent a small amount of XBTC by the issuer of XBTC when they start up. Lets say 10 XBTC to begin with (and 0 BTC). Maybe more if the person running the node is well known. The reason to not distribute all 21M XBTC immediately is that the DAC would start with a smaller number of nodes. It would be rather difficult to redistribute the XBTC in an easy way.

For simplicity, the node should run with a new Bitcoin wallet and a single receive address. This address is the payment address for XBTC to receive BTC. It is the same address to send BTC to receive XBTC. The node will listen simultaneously on the Counterpartyd API and Bitcoin API.

The exchange rate is not precisely 1:1 to incentivize operators of nodes to continue to operate or at least recover operating costs.

A customer of the node who wishes to exchange 1.0001 XBTC to 1 BTC:
* Sends 1 XBTC to the receive address of the node. The node will respond by sending 1 BTC to the source address of the Counterparty send.

A customer of the node who wishes to exchange 1.0001 BTC to XBTC:
* Sends 1 BTC to the receive address of the node. The node will wait for a defined number of confirmations and and respond by sending 1 XBTC to the source address of the send. Here's where the some restrictions like as with the Counterparty white paper must be enforced. ie the Bitcoin transaction must have 1 input to ensure no ambiguity of who should be credited with the XBTC.

"Every Counterparty transaction must, moreover, have a unique and unambiguous source address: all of the inputs to a Bitcoin transaction which contains a Counterparty transaction must be the samethe unique source of the funds in the Bitcoin transaction is the source of the Counterparty transaction within."

BTC sent to a node which does not fit within this requirement would be considered ambigious and returned to one of the input addresses of the transaction. Such malformed requests can be limited by having an interface like Counterpartyd which ensures transactions are crafted in the correct manner.

when a node first starts up with a balance of 10 XBTC and 0 BTC, it cannot 'dispense' any BTC. A similar situation may occur during a 'bank run' if many customers are sending XBTC to the same node. The node may fill as much as the order as possible. All unfilled portions of XBTC or BTC are returned to the source address.

Nodes can be uniquely identified by their address. The node can be completely audited by comparison to XCP database and the Bitcoin blockchain. In fact, it would be possible for an independent web site like blockscan or the web wallet to display the 'health' of the DAC and each node. ie perform an audit of each node and ensure that balances and prices are not tampered with.

There is still the risk that an operator of a node could run with the balances. Since BTC is a separate block chain and payments irrevokable, we'd have to live with that.

I think the above is deterministic and possible to implement.

Also, I've been thinking of something that might be nice. Say we could use the Counterparty 'broadcast' for a moment:

Nodes advertise their balances over the Counterparty protocol via 'broadcasts'

Based upon the node's parameters, the node may wish to seek to replenish its balances of XBTC or BTC from other nodes in the DAC. It can use the broadcasts to locate other nodes in the DAC. They can then send an order to purchase the asset they wish to replenish. The thing to be careful is that one node attempting to buy from another node may cause a knock on effect of causing other nodes to be depleted of resources. The broadcasts could also be used by the aforementioned audit page of the health of the DAC.

I think this is very much doable and fairly quickly. Given yesterday's security scare, the only problem implementing this at an early stage is if there are any exploits where a node loses some of the XBTC it holds then its a much bigger trouble than yesterday. I can imagine Poloniex trouble would have been of a much higher magnitude if it was not the only exchange in town. If the hacker had deposited XCP in another exchange the problem would have been 10 times bigger. In this scenario the XBTC can be encashed for BTC in any of the nodes. This is not to say that there are more security exploits, merely to suggest that perhaps we must wait for the system to mature and move out of alpha before we implement something like this.

If implemented correctly there would be no single point of failure. Trades wouldn't be as instant as a central exchange but that's the only downside.