[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[lonsharim]

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 same—the 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.

[xnova]

Can anyone help me understand the reindex thing ? No matter who I ask or what I read it's not working and I burned 15 bitcoin so I'm trying to figure out how to consolidate this and get in a position where I can send and receive as needed ... why is this so difficult for me ? I'm even a developer. Have tried re indexing 5 times over a period of 2 weeks. Counterparty commands throw all kinds of errors idk man I've tried everything and ... now I'm even more discouraged than before because I hear that the Web wallet will not have the ability to import private key -_____- is there really no one willing to help for a donation ? :/

Can I maybe get someone to do a remote session to help me set up all the prereq and then that way all I have to do is import my keys and I'm good to go. I'm desperate at this point. -___-

Can Someone not Host The Block Chain So I can Download It Maybe Or Something .... Would That Work ?

1. The web wallet may not have an import but xnova talked about adding a sweeping functionality. This means with your existing private keys XCP can be transferred to an address created by your web wallet. From there on you can consolidate if you like.
2. I had an unusual problem reindexing too, I did it twice and each time after closing and opening qt wallet it prompted that an reindex is required. I deleted my blockchain and restored an older copy, made double sure my bitcoin.conf was correct, reindexed again and everything was fine. Since then I have decided to backup my blockchain at least once a month.
3. I wouln't remote session with anyone I didn't actually know, especially if I had 15 addresses with 1000+ XCP each in them.

Sweep functionality is implemented within Counterwallet. Currently it is untested, but it's there (will be doing basic testing of it later this week). With the feature you can sweep BTC, XCP, or any Counterparty asset type. The only hiccup is that for instance to sweep 8 different kinds of assets, the address you are sweeping from will need 8 unspent txouts existing for it (each with at least 1 confirmation... the wallet will detect if you don't have this at the time and will show an error, however). That, or if you only have 1 unspent txout for instance, you can always sweep one asset at a time, and just wait for the txn to confirm before sweeping the next.

Message signing was implemented today as well.

[Chuck]

Okay, so if I were to roll back the dump, Poloniex would be short about 80 BTC...

As I don't think he has the XCP to cover the dump, ...

Since this was a bug in the protocol that could have affected anyone, it does not seem fair that Poloniex or its users should take the hit.

Since we are still in "Alpha", why not release a new version of the protocol, that issues another 35K XCP as the solution?

It would essentially be a 1% tax on everyone who holds XCP, through inflation. It seems like a small price to pay for finding out about this huge, show stopping bug (that could have gone unnoticed & exploited for months!)

[halfcab123]

Give me an example of both the bitcoin.conf and counterpartyd.conf

This process would be so much easier with a super clear for dummies step by step explanation,  one I'd love to do when this finally all clicks. I figured by now someone would have helped for a donation.

[broken_pixel]

Last Price:
0.00000006
 
24 Hour High:
0.00000007
 
24 Hour Low:
0.00000003
 
Trade Volume:
81.675 BTC

[wwdz99]

Okay, so if I were to roll back the dump, Poloniex would be short about 80 BTC...

As I don't think he has the XCP to cover the dump, ...

Since this was a bug in the protocol that could have affected anyone, it does not seem fair that Poloniex or its users should take the hit.

Since we are still in "Alpha", why not release a new version of the protocol, that issues another 35K XCP as the solution?

It would essentially be a 1% tax on everyone who holds XCP, through inflation. It seems like a small price to pay for finding out about this huge, show stopping bug (that could have gone unnoticed & exploited for months!)

may be it look like a good choice.

[lonsharim]

Give me an example of both the bitcoin.conf and counterpartyd.conf

This process would be so much easier with a super clear for dummies step by step explanation,  one I'd love to do when this finally all clicks. I figured by now someone would have helped for a donation.

Both are sufficiently well explained here

http://counterpartyd-build.readthedocs.org/en/latest/SettingUpBitcoind.html

http://counterpartyd-build.readthedocs.org/en/latest/AdditionalTopics.html#editing-the-config

[porqupine]

Can anyone help me understand the reindex thing ? No matter who I ask or what I read it's not working and I burned 15 bitcoin so I'm trying to figure out how to consolidate this and get in a position where I can send and receive as needed ... why is this so difficult for me ? I'm even a developer. Have tried re indexing 5 times over a period of 2 weeks. Counterparty commands throw all kinds of errors idk man I've tried everything and ... now I'm even more discouraged than before because I hear that the Web wallet will not have the ability to import private key -_____- is there really no one willing to help for a donation ? :/

Can I maybe get someone to do a remote session to help me set up all the prereq and then that way all I have to do is import my keys and I'm good to go. I'm desperate at this point. -___-

Can Someone not Host The Block Chain So I can Download It Maybe Or Something .... Would That Work ?

1. The web wallet may not have an import but xnova talked about adding a sweeping functionality. This means with your existing private keys XCP can be transferred to an address created by your web wallet. From there on you can consolidate if you like.
2. I had an unusual problem reindexing too, I did it twice and each time after closing and opening qt wallet it prompted that an reindex is required. I deleted my blockchain and restored an older copy, made double sure my bitcoin.conf was correct, reindexed again and everything was fine. Since then I have decided to backup my blockchain at least once a month.
3. I wouln't remote session with anyone I didn't actually know, especially if I had 15 addresses with 1000+ XCP each in them.

Sweep functionality is implemented within Counterwallet. Currently it is untested, but it's there (will be doing basic testing of it later this week). With the feature you can sweep BTC, XCP, or any Counterparty asset type. The only hiccup is that for instance to sweep 8 different kinds of assets, the address you are sweeping from will need 8 unspent txouts existing for it (each with at least 1 confirmation... the wallet will detect if you don't have this at the time and will show an error, however). That, or if you only have 1 unspent txout for instance, you can always sweep one asset at a time, and just wait for the txn to confirm before sweeping the next.

Message signing was implemented today as well.

You also need the unspent txouts to be in the appropriate addresses to match the XCP don't you?
The way to go would be a shuffle function, or a configurable min. dust amount that the wallet will keep in each address containing an Counterparty asset.

[halfcab123]

Give me an example of both the bitcoin.conf and counterpartyd.conf

This process would be so much easier with a super clear for dummies step by step explanation,  one I'd love to do when this finally all clicks. I figured by now someone would have helped for a donation.

Both are sufficiently well explained here

http://counterpartyd-build.readthedocs.org/en/latest/SettingUpBitcoind.html

http://counterpartyd-build.readthedocs.org/en/latest/AdditionalTopics.html#editing-the-config

How willi know re index done

[halfcab123]

Last Price:
0.00000006
 
24 Hour High:
0.00000007
 
24 Hour Low:
0.00000003
 
Trade Volume:
81.675 BTC

Hi wtf is this please?

[lonsharim]

Okay, so if I were to roll back the dump, Poloniex would be short about 80 BTC...

As I don't think he has the XCP to cover the dump, ...

Since this was a bug in the protocol that could have affected anyone, it does not seem fair that Poloniex or its users should take the hit.

Since we are still in "Alpha", why not release a new version of the protocol, that issues another 35K XCP as the solution?

It would essentially be a 1% tax on everyone who holds XCP, through inflation. It seems like a small price to pay for finding out about this huge, show stopping bug (that could have gone unnoticed & exploited for months!)

I think its a terrible idea. Two wrongs don't make a right.

This will also encourage hackers to loot what they want knowing that the breach will be filled from thin air by the protocol. It diminishes the value of the protocol and undermines consumer confidence.

We must also wait for the busoni to report back what the hacker has in mind before we formulate the best way forward. If he does not return the BTC, short of raising funds for the Poloniex loss there is nothing else we can do. The bounty people planned for the "benevolent" hacker must go to Poloniex even though it may not fully mitigate Busoni's loss.

[lonsharim]

Last Price:
0.00000006
 
24 Hour High:
0.00000007
 
24 Hour Low:
0.00000003
 
Trade Volume:
81.675 BTC

Hi wtf is this please?

Think he lost his way

[lonsharim]

Give me an example of both the bitcoin.conf and counterpartyd.conf

This process would be so much easier with a super clear for dummies step by step explanation,  one I'd love to do when this finally all clicks. I figured by now someone would have helped for a donation.

Both are sufficiently well explained here

http://counterpartyd-build.readthedocs.org/en/latest/SettingUpBitcoind.html

http://counterpartyd-build.readthedocs.org/en/latest/AdditionalTopics.html#editing-the-config

How willi know re index done

I reindexed using the qt wallet and not the daemon, the reindex and sync information can be seen at all times on the status bar.

[qtgwith]

Okay, so if I were to roll back the dump, Poloniex would be short about 80 BTC...

As I don't think he has the XCP to cover the dump, ...

Since this was a bug in the protocol that could have affected anyone, it does not seem fair that Poloniex or its users should take the hit.

Since we are still in "Alpha", why not release a new version of the protocol, that issues another 35K XCP as the solution?

It would essentially be a 1% tax on everyone who holds XCP, through inflation. It seems like a small price to pay for finding out about this huge, show stopping bug (that could have gone unnoticed & exploited for months!)

Really a terrible idea! It will kill Counterparty XCP!

[Chuck]

I think its a terrible idea. Two wrongs don't make a right.

This will also encourage hackers to loot what they want knowing that the breach will be filled from thin air by the protocol. It diminishes the value of the protocol and undermines consumer confidence.

We must also wait for the busoni to report back what the hacker has in mind before we formulate the best way forward. If he does not return the BTC, short of raising funds for the Poloniex loss there is nothing else we can do. The bounty people planned for the "benevolent" hacker must go to Poloniex even though it may not fully mitigate his loss.

My idea would not encourage hackers any more then the current situation. Hackers will hack, either way.

And besides, that is not a bad thing, we WANT bugs in the protocol to be found as soon as possible.

It is just a matter of deciding who takes the loss now, how to minimize the bad feelings.

Why punish the very first exchange that was brave enough to carry Counterparty? By letting busoni or his users take the loss, we send a message, "Lesson: don't use counterparty, you could lose your money".

The current situation rewards those who hoarded XCP and did not trade (share) it with new users. My idea spreads the damage so thinly that nobody really notices.

Also, this would not be the response in the future. This could be limited to "Alpha" stage only, and once the developers declare we are out of Alpha, it would never be done again.

You are right, it would undermine consumer confidence if this were done a year from now. But it is so early now that my idea would actually create consumer confidence, I think!

Inflation is less scary then having your money stolen on an exchange. Almost all altcoins have inflation and nobody notices. I would rather put my money and time in a software that deals with protocol bugs with inflation then thinking I could lose 100% of my money at any time with no recourse.

[lonsharim]

I think its a terrible idea. Two wrongs don't make a right.

This will also encourage hackers to loot what they want knowing that the breach will be filled from thin air by the protocol. It diminishes the value of the protocol and undermines consumer confidence.

We must also wait for the busoni to report back what the hacker has in mind before we formulate the best way forward. If he does not return the BTC, short of raising funds for the Poloniex loss there is nothing else we can do. The bounty people planned for the "benevolent" hacker must go to Poloniex even though it may not fully mitigate his loss.

My idea would not encourage hackers any more then the current situation. Hackers will hack, either way.

And besides, that is not a bad thing, we WANT bugs in the protocol to be found as soon as possible.

It is just a matter of deciding who takes the loss now, how to minimize the bad feelings.

Why punish the very first exchange that was brave enough to carry Counterparty? By letting busoni or his users take the loss, we send a message, "Lesson: don't use counterparty, you could lose your money".

The current situation rewards those who hoarded XCP and did not trade (share) it with new users. My idea spreads the damage so thinly that nobody really notices.

Also, this would not be the response in the future. This could be limited to "Alpha" stage only, and once the developers declare we are out of Alpha, it would never be done again.

You are right, it would undermine consumer confidence if this were done a year from now. But it is so early now that my idea would actually create consumer confidence, I think!

Inflation is less scary then having your money stolen on an exchange. Almost all altcoins have inflation and nobody notices. I would rather put my money and time in a software that deals with protocol bugs with inflation then thinking I could lose 100% of my money at any time with no recourse.

None of your statements are wrong, except for the recourse you have in mind, I agree with everything else.

You are right, hackers will hack, however, the hacker in touch with busoni explains the exploit and talks about returning back everything he took and then does not respond for the next few hours. What message do we sent when we are ready to fill the breach in this fashion.

Secondly as you yourself point out, its alpha stage, you use your xcp at your own risk. It has been stated in no uncertain terms by the OP. The current situation does not warrant a wide spread use of the coin, I would like to trade my coins too but I would rather wait for the whole system to mature before I do anything. This is not to say early adopters and the curious minded shouldn't do anything, just that you need to be aware of the risks involved.

I am all for a community consensus to fill the loss borne but it think at this stage its premature to talk about and it needs to be filled from our pockets rather than just generate an extra 35k. 

[halfcab123]

Ok so I'm reindexing with Bitcoin-Qt.exe --reindex

Is this ok for my bitcoin.conf

Code:

rpcuser=bettyboop
rpcpassword=Inottellingteehee
txindex=1
server=1
daemon=1

Is it ok that daemon=1 is set ?


ALSO! One other question.

I have tried importprivkey command via the bitcoin-qt console
and I've only managed to get 5 of the 15 addresses to show.
How on earth could this be so difficult ? lol.

[ginko-B]

I think its a terrible idea. Two wrongs don't make a right.

This will also encourage hackers to loot what they want knowing that the breach will be filled from thin air by the protocol. It diminishes the value of the protocol and undermines consumer confidence.

We must also wait for the busoni to report back what the hacker has in mind before we formulate the best way forward. If he does not return the BTC, short of raising funds for the Poloniex loss there is nothing else we can do. The bounty people planned for the "benevolent" hacker must go to Poloniex even though it may not fully mitigate his loss.

My idea would not encourage hackers any more then the current situation. Hackers will hack, either way.

And besides, that is not a bad thing, we WANT bugs in the protocol to be found as soon as possible.

It is just a matter of deciding who takes the loss now, how to minimize the bad feelings.

Why punish the very first exchange that was brave enough to carry Counterparty? By letting busoni or his users take the loss, we send a message, "Lesson: don't use counterparty, you could lose your money".

The current situation rewards those who hoarded XCP and did not trade (share) it with new users. My idea spreads the damage so thinly that nobody really notices.

Also, this would not be the response in the future. This could be limited to "Alpha" stage only, and once the developers declare we are out of Alpha, it would never be done again.

You are right, it would undermine consumer confidence if this were done a year from now. But it is so early now that my idea would actually create consumer confidence, I think!

Inflation is less scary then having your money stolen on an exchange. Almost all altcoins have inflation and nobody notices. I would rather put my money and time in a software that deals with protocol bugs with inflation then thinking I could lose 100% of my money at any time with no recourse.

The very best solution is for the hacker to quickly agree to send the BTC back.

If he does not send the BTC back, then the hacker will endure the pain and psychological suffering that comes with being a thief. And under this circumstance, the latest proposal to spread the loss equally over every XCP holder as a form of quantitative easing may have merit from a distributional standpoint, however, I wonder if it is technically realistic?  How would this solution actually be implemented?  

[halfcab123]

Does anyone know what happened to Bitshares/PTS ? Why the huge jump in volume ? $5 million + ? Was there a breakthrough of some sort ? They are nearing the $30million market cap which they have only reached briefly before during the Chinese pump in early December. I find this situation very curious considering they are a direct competitor with Counterparty along with Mastercoin and NXT.

[halfcab123]

I know I sure am talking alot lol. I'm very excited that this counterpartyd thing is starting to sink in. 

I'm not running my bitcoin-qt in a virtual machine as I've seen so many advise doing. Is that a must for top-security of the private keys?
Is wallet encryption not enough ? Can you encrypt the wallet and still allow counterpartyd seamless communication with bitcoind/bitcoin-qt ?

Are there any other precautions security wise I should be taking ?

Is it imperative that I switch to using a virtual machine for this ?