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

[ddink7]

A quick update: We are currently working through things with busoni and the anonymous hacker regarding the security incident. We have essentially extended a reward as well as a security developer-type position to this individual contingent upon us fully settling this issue and the funds being fully returned.

Phantom is currently implementing even more strict transaction validity checking rules as we speak (to among other things, guard against a specific potential security issue in bitcoind itself that the hacker has identified). We are also working on an intermediate transaction database (to lessen the need to do a full rebuild off of bitcoind for all but the most major updates). That all being said, there will most likely be another update out shortly that requires a rebuild, but we hope that this will be the last for awhile.

We have also created two donation addresses:

Bug bounty program: 14Tf35AovvRVURzd623q5i9kry2EW8WzyL
General donations: 19U6MmLLumsqxXSBMB5FgYXbezgXYC6Gpe

We will be announcing the terms of a bug bounty program later today. If you are interested in helping pay for bounties for bugs found, please donate BTC or XCP to the bounty address above.

General donations (to be used with the project at the Counterparty team's discretion) can be sent to the General donations address.

Again, thank you all for your patience on this matter as we drive it to resolution.

Have the bitcoin devs been notified of the security issue in bitcoind?

[xnova]

A quick update: We are currently working through things with busoni and the anonymous hacker regarding the security incident. We have essentially extended a reward as well as a security developer-type position to this individual contingent upon us fully settling this issue and the funds being fully returned.

Phantom is currently implementing even more strict transaction validity checking rules as we speak (to among other things, guard against a specific potential security issue in bitcoind itself that the hacker has identified). We are also working on an intermediate transaction database (to lessen the need to do a full rebuild off of bitcoind for all but the most major updates). That all being said, there will most likely be another update out shortly that requires a rebuild, but we hope that this will be the last for awhile.

We have also created two donation addresses:

Bug bounty program: 14Tf35AovvRVURzd623q5i9kry2EW8WzyL
General donations: 19U6MmLLumsqxXSBMB5FgYXbezgXYC6Gpe

We will be announcing the terms of a bug bounty program later today. If you are interested in helping pay for bounties for bugs found, please donate BTC or XCP to the bounty address above.

General donations (to be used with the project at the Counterparty team's discretion) can be sent to the General donations address.

Again, thank you all for your patience on this matter as we drive it to resolution.

Have the bitcoin devs been notified of the security issue in bitcoind?

We are not saying it is a genuine security issue to bitcoind itself. However, it is a less-than-ideal design consideration with a specific aspect of the protocol that has possible security implications for Counterparty and other Bitcoin-based metacoins. We will soon have a full release out that addresses any potential or theoretical attack vectors that this design choice may expose. Due to the nature of the problem, that's all I can say at the moment regarding this issue.

[kdrop22]

There is an order on the DEX to buy at 0.009 and two order to sell at the same price. Any idea why these haven't been matched? Thanks!

Check the fee required, for the sell order.

[NewDeal]

Hi everybody!

I bought 402 XCP two days ago on poloniex... for 4BTC... Do you think I will see them again? 

[Spratan]

Congrats Devs for all your outstanding work

[Probably]

... I wonder if it is technically realistic?  How would this solution actually be implemented?  

Hard code into the next version, recognizing an address that PhantomPhreak controls as having a balance of 35,000 XCP on the first block. Then, PhantomPhreak sends this to busoni.  I would think it could be a 1 liner, not too hard?

I would hope that, if this is done, we can also set a date for when this type of fix is permanently "off limits". Maybe 6-12 months from now. In other words, a date where we all agree it is no longer Alpha software, but Beta.

And secondly, raise a pool of funds (controlled by PhantomPhreak?) to have a security audit done by an outside party, before we declare the transition from Alpha to Beta.  I would donate to this and I think many others would too.

this is the most retarded thing i have read today, another bailout ... call Obama and Bernanke

What a coincidence, your post is the most retarded thing I have read today! It clearly isn't a bailout, it is more aligned with FDIC when after a bank gets robbed the accounts are replenished.

Bottomline is that without it being that worthy of a target the vulnerability would likely remain so until that lucrative. You're also setting a pattern (I've read a lot of negative precedent setting issues in this thread) that it's fine to just wait until something catastrophic occurs and fuck you to the people who were required to invest / interact collectively to squeak out the issue.


Finally, it is rather convenient that this "benevolent hacker" proved their issue in such an amazingly robust manner. why not benevolently doublespend the minimum amount?

The unbelievable aspect - and why many doubted the initial reports - were 100% due to the scope and scale of the issue and how non-publicized it was. You're going to not directly contact the public / the devs to reveal the issue? But someone running an exchange when their involvement is rather tangential? LOL.

The idea that most people don't give a shit and shouldn't be "punished" for equality due to early adopters building the interest to the point that it is a worthy target deserves the slowest clap from the smallest animated gif

Who cares because everything's working as intended, and disclaimer text means tough shit, right?

[Probably]

... I wonder if it is technically realistic?  How would this solution actually be implemented?  

Hard code into the next version, recognizing an address that PhantomPhreak controls as having a balance of 35,000 XCP on the first block. Then, PhantomPhreak sends this to busoni.  I would think it could be a 1 liner, not too hard?

I would hope that, if this is done, we can also set a date for when this type of fix is permanently "off limits". Maybe 6-12 months from now. In other words, a date where we all agree it is no longer Alpha software, but Beta.

And secondly, raise a pool of funds (controlled by PhantomPhreak?) to have a security audit done by an outside party, before we declare the transition from Alpha to Beta.  I would donate to this and I think many others would too.

That's completely defeating the purpose of PoB.

No it doesn't. Burning again doesn't defeat the purpose of burning, it just reestablishes value.

 

Burning again undermines the entire protocol, because it creates the possibility of unlimited inflation. We could just reinitiate a burn whenever people feel like it.

What's this we shit?

First of all, that already could happen. It doesn't undermine anything regarding the protocol past the point that the protocol is ALPHA and changes / reestablishing the burn amount is part of CHANGING THE PROTOCOL TO MAKE IT BETTER.

Pretty simple. So no, it doesn't "create" any more or less possibility of unlimited inflation than there already is. Stating "the burn is final" is as rigid a rule as saying "we will only burn in alpha when doublespend vulnerabilities are found to have been implemented" or as stating "haha we'll burn whenever we feel like it."



It creates minor inflation up front in response to a critical bug that was only revealed by people having enough invested in it to make it worthwhile to abuse.

Congrats. Hope the grey hat hacker gets enough bounty to make giving up more coin worthwhile. Laff.

How about just consider the plunder the bounty? Oh that would be too obvious, eh

[ddink7]

What's this we shit?

This "we shit" refers to "we" as in "the Counterparty community." Or did you think you were the only one who mattered?

[PhantomPhreak]

EBIT: I think you're right, that you enter the fee in % when placing the order, but it looks like blockscan converts it to a BTC amount.

The command-line interface takes a fraction (.01 = 1%), and the protocol uses a fixed quantity of BTC.

[0.oJoker]

Looking forward to more people participating in project of XCP  XCP will be better

[chinnuperiya]

Any word for Poloniex whether they will continue to trade BTC/XCP?

[ddink7]

Any word for Poloniex whether they will continue to trade BTC/XCP?

xnova said earlier they are all working together to sort things out. I'm sure we'll here from Busoni as soon as possible.

[wizzardTim]

EBIT: I think you're right, that you enter the fee in % when placing the order, but it looks like blockscan converts it to a BTC amount.

The command-line interface takes a fraction (.01 = 1%), and the protocol uses a fixed quantity of BTC.

Apologies if this is obvious, but why aren’t the orders previously discussed being matched on the DEX? Sellers’ fee required is lower than the buyer’s fee provided.

@devs: is something malfunctioning?

[ginko-B]

... I wonder if it is technically realistic?  How would this solution actually be implemented?  

Hard code into the next version, recognizing an address that PhantomPhreak controls as having a balance of 35,000 XCP on the first block. Then, PhantomPhreak sends this to busoni.  I would think it could be a 1 liner, not too hard?

I would hope that, if this is done, we can also set a date for when this type of fix is permanently "off limits". Maybe 6-12 months from now. In other words, a date where we all agree it is no longer Alpha software, but Beta.

And secondly, raise a pool of funds (controlled by PhantomPhreak?) to have a security audit done by an outside party, before we declare the transition from Alpha to Beta.  I would donate to this and I think many others would too.

this is the most retarded thing i have read today, another bailout ... call Obama and Bernanke

Hi prophetx, just like you I am extremely skeptical of central bankers, inflation, and bailouts.  And for the record I also believe strongly in the concept of "sanctity of protocol", i.e., the idea that the protocol should be sacred and for all intents and purposes untouchable or off limits to devs and community.

Nevertheless, there is an important distinction here.

The world's central banks operate in a totally non-transparent fashion and they make decisions to inflate our currency without our knowledge or consent.  Over the past 50 years since we left the gold standard (which had previously been in existence for more than 1000 years) this pattern of central bank corruption has become pervasive and systemic, with centralized governments accruing massive fiscal deficits,  then running the printing presses to fund the bailout, at the same time constantly "cooking" the methodologies for calculating inflation to fix the optics.  I have traveled to more than 100 countries over the past decade and I would say that more than, say, 25% of the 206 countries in the world are in total economic shambles as a consequence of this (and other associated and interrelated) macro-economic mismanagement.  It is absolutely disgusting, it is immoral, and it leads to massive poverty, inequality, violence, etc.  

I personally believe that it is a basic human right that we should have a "non-corruptible currency" for use in our everyday lives, kind of like our right to water and oxygen.  =)

Notwithstanding, at this stage in the Counterparty project, where the project is still in alpha and we have encountered a technical glitch that has damaged many members of this community, and the community still being relatively small, I can also justify in my mind the situation of holding a community vote.  If we were to hold a community vote and if there was a majority or supermajority consensus that every XCP holder should give-up a tiny fraction of ownership in order to cover the costs of this unintended technical glitch, then, I think this would be possibly the fairest outcome, and it would add credibility to the community.  This would not be an non-transparent and centrally imposed inflation like we are faced with every day by the evil central bankers.  It would be community driven!  See the difference?

In summary, while I deeply and fundamentally agree with everyone arguing for "sanctity of protocol", and while I believe it is a very fine line and potentially a dangerous and slippery slope to introduce any inflation at all, I also see the possibility for an educated and intelligent community rallying together under the  exceptional circumstances of a "force majeur" event such as the security breech that has just occurred to hold a vote and make a collective decision to self-tax ourselves in the spirit of helping Busoni cover the loss.

Finally, my apologies for the long and passionate message, and I will refrain from any further posts on this topic until after we hear the result of Busoni and xnova's earnest efforts to reach a resolution with the greyhat.

[led_lcd]

So you cant really be sure of your position until the standard 6 confirmations.

Also a miner can game the system by front-running trades after solving a block.

Also there are many "latency arbitrage" "alpha" strategies that can be used to game the system, since it is possible to to make a trade in the past based on "future" information.

This is why Decentralized Distributed Exchanges for liquid assets is nearly impossible to implement.

I've read this whole thread and everything about XCP and still have not found details technical info on how the matching works, does it use "atomic transactions" ?

I have some ideas on solutions, PM if interested.. im a 15 year high frequency trading C++ coders.  cheers 

Hello, not sure if I can help but I've made some trades on the DEX.

Actually I've encountered a simultaneous trade with someone else (within the same block) he was first and since he took the whole order I end up with an unfilled buy order. I think that your are sure of your position as soon as the block is mined (and as long as there is no fork in BTC, which is quite rare)

About the latency arbitrages you're talking about, I have no clue but I'm really interested about this possibility and how to avoid it.

I've also red that DEXes are not (and will probably never be) suited for HFT (I remember Vitalik saying that somewhere in this thread) I have no trading vocabulary but I see the DEX as a low frequency (10m) trading engine. Which is already quite a nice innovation !

Trust me if

So you cant really be sure of your position until the standard 6 confirmations.

Also a miner can game the system by front-running trades after solving a block.

Also there are many "latency arbitrage" "alpha" strategies that can be used to game the system, since it is possible to to make a trade in the past based on "future" information.

This is why Decentralized Distributed Exchanges for liquid assets is nearly impossible to implement.

I've read this whole thread and everything about XCP and still have not found details technical info on how the matching works, does it use "atomic transactions" ?

I have some ideas on solutions, PM if interested.. im a 15 year high frequency trading C++ coders.  cheers 

Hello, not sure if I can help but I've made some trades on the DEX.

Actually I've encountered a simultaneous trade with someone else (within the same block) he was first and since he took the whole order I end up with an unfilled buy order. I think that your are sure of your position as soon as the block is mined (and as long as there is no fork in BTC, which is quite rare)

About the latency arbitrages you're talking about, I have no clue but I'm really interested about this possibility and how to avoid it.

I've also red that DEXes are not (and will probably never be) suited for HFT (I remember Vitalik saying that somewhere in this thread) I have no trading vocabulary but I see the DEX as a low frequency (10m) trading engine. Which is already quite a nice innovation !

This is an interesting concept but I don't expect widespread adoption of XCP.

First of all, its use is very limited. I don't think it will win over a single professional trader ever. In this time and age of HFT (high frequency trading) in most markets, especially the very liquid ones, where latencies are counted by the microseconds, the pace of 1 block per 10 minutes is not really going to cut it. This alone already rules out liquid markets like FX, MM, rates equities and commodities, where 99.999% of the trades are. Low Lack liquidity in XCP will translate to huge spreads and slippage from hell, making it unprofitable to trade through XCP, which in turn hurts liquidity. You can't break that vicious circle unless you can compete with the lightning speed and market depth at the exchanges. Unfortunately I don't see that ever happening. And oh, the exchange fees in these very liquid markets are negligible, especially for high volumes, so no advantage for XCP there either.

Mind you I'm not dismissing XCP, it's fantastic technology and it will have many novel applications. But I just don't think it's going to have the same level of impact as bitcoin, which was truly a paradigm shift.

I hope I'm proven wrong though! 

Blockchain-based technologies in general, whether BTC, MSC, XCP or Ethereum, will not be used for HFT. The scalability is simply not there for that. OpenTransactions servers, on the other hand, are excellent for HFT. Blockchains are for higher-value transactions and settlement.

Forget about HFT. Its all about latency arbitrage. If I have the fastest quotes feeds and the fastest access to exchanges, then there are specific techniques that enable trading with nearly 100% profitability. Goldman Sacks and JPMorgan, are on a streak of hundreds of days in a row with no losses in their "prop program trading book".

In this case, its much worse, because you can decide to take the trade or give it to the original trader, depending on what happened after the trade. So you can rewrite history, it doesn't matter how frequent the trades are.

Also, if this DEX get big and there is a huge trade during a bitcoin "flash crash", I can guarantee that some group of miners/traders will front run and create a fork.

DEX can only work if you only allow trading on confirmed blocks. So basically orders can only be matched against orders that have 6 confirmations, and then you need to wait another 6 confirmations to "clear" the trade.

One idea (off the top of my head)  is to have a 6 confirmation pause between "trading sessions", no trading allowed during the pause.

I think you have good points.

Taking latency arbitrage by itself: The granularity of transactions on Counterparty means that the opportunity to arbitrage is limited to gaming the Counterparty order book once every 10 minutes appropriately. That's interesting but whilst you can get your order in faster than anyone else on the DEX, everyone else in the world will be piling in orders too during that time.

The order in which orders are formed in the block is dependent on the miner. Therefore, for the low latency arbitrager it isn't deterministic so not as interesting.

However, what you then go on to describe is latency arbitrage on top of a 51% attack. This is entirely possible. Indeed there are already instances where ghash.io  has been accused of gaming satoshis dice.

In fact, a miner with 51% power could deny others from accessing the DEX completely by not including Counterparty orders or cherry pick orders that it likes.

Depending on the attacker's hash rate, waiting for 6 confirmations may be insufficient. Please see section 11 calculations https://bitcoin.org/bitcoin.pdf

I'd love to hear what ideas you have to limit the ability of a large miner to game the Counterparty order book. Keep in mind though we aren't going to be able to solve a problem that is inherent in Bitcoin. That needs to be solved by the Bitcoin community. Unless of course, the utility value of Counterparty starts to outweigh the utility value of Bitcoin...

[delulo]

did anyone try to install the new 0.6 client? all that happens when I open it (after installing https://github.com/xnova/counterpartyd_binaries) is a comand line window opening and closing again after a few seconds...?

[wizzardTim]

did anyone try to install the new 0.6 client? all that happens when I open it (after installing https://github.com/xnova/counterpartyd_binaries) is a comand line window opening and closing again after a few seconds...?

The same happened to me. Just build it from source.

[delulo]

did anyone try to install the new 0.6 client? all that happens when I open it (after installing https://github.com/xnova/counterpartyd_binaries) is a comand line window opening and closing again after a few seconds...?

The same happened to me. Just build it from source.

i have no clue how to do that

also, are other clients like https://github.com/JahPowerBit/BoottleXCP not recommended anymore since the new 0.6 version with the fix came out?

[wizzardTim]

did anyone try to install the new 0.6 client? all that happens when I open it (after installing https://github.com/xnova/counterpartyd_binaries) is a comand line window opening and closing again after a few seconds...?

The same happened to me. Just build it from source.

i have no clue how to do that

also, are other clients like https://github.com/JahPowerBit/BoottleXCP not recommended anymore since the new 0.6 version with the fix came out?

Follow the instructions here http://counterpartyd-build.readthedocs.org/en/latest/BuildingFromSource.html#on-windows

[prophetx]

... I wonder if it is technically realistic?  How would this solution actually be implemented?  

Hard code into the next version, recognizing an address that PhantomPhreak controls as having a balance of 35,000 XCP on the first block. Then, PhantomPhreak sends this to busoni.  I would think it could be a 1 liner, not too hard?

I would hope that, if this is done, we can also set a date for when this type of fix is permanently "off limits". Maybe 6-12 months from now. In other words, a date where we all agree it is no longer Alpha software, but Beta.

And secondly, raise a pool of funds (controlled by PhantomPhreak?) to have a security audit done by an outside party, before we declare the transition from Alpha to Beta.  I would donate to this and I think many others would too.

this is the most retarded thing i have read today, another bailout ... call Obama and Bernanke

Hi prophetx, just like you I am extremely skeptical of central bankers, inflation, and bailouts.  And for the record I also believe strongly in the concept of "sanctity of protocol", i.e., the idea that the protocol should be sacred and for all intents and purposes untouchable or off limits to devs and community.

Nevertheless, there is an important distinction here.

The world's central banks operate in a totally non-transparent fashion and they make decisions to inflate our currency without our knowledge or consent.  Over the past 50 years since we left the gold standard (which had previously been in existence for more than 1000 years) this pattern of central bank corruption has become pervasive and systemic, with centralized governments accruing massive fiscal deficits,  then running the printing presses to fund the bailout, at the same time constantly "cooking" the methodologies for calculating inflation to fix the optics.  I have traveled to more than 100 countries over the past decade and I would say that more than, say, 25% of the 206 countries in the world are in total economic shambles as a consequence of this (and other associated and interrelated) macro-economic mismanagement.  It is absolutely disgusting, it is immoral, and it leads to massive poverty, inequality, violence, etc.  

I personally believe that it is a basic human right that we should have a "non-corruptible currency" for use in our everyday lives, kind of like our right to water and oxygen.  =)

Notwithstanding, at this stage in the Counterparty project, where the project is still in alpha and we have encountered a technical glitch that has damaged many members of this community, and the community still being relatively small, I can also justify in my mind the situation of holding a community vote.  If we were to hold a community vote and if there was a majority or supermajority consensus that every XCP holder should give-up a tiny fraction of ownership in order to cover the costs of this unintended technical glitch, then, I think this would be possibly the fairest outcome, and it would add credibility to the community.  This would not be an non-transparent and centrally imposed inflation like we are faced with every day by the evil central bankers.  It would be community driven!  See the difference?

In summary, while I deeply and fundamentally agree with everyone arguing for "sanctity of protocol", and while I believe it is a very fine line and potentially a dangerous and slippery slope to introduce any inflation at all, I also see the possibility for an educated and intelligent community rallying together under the  exceptional circumstances of a "force majeur" event such as the security breech that has just occurred to hold a vote and make a collective decision to self-tax ourselves in the spirit of helping Busoni cover the loss.

Finally, my apologies for the long and passionate message, and I will refrain from any further posts on this topic until after we hear the result of Busoni and xnova's earnest efforts to reach a resolution with the greyhat.

I see your point on transparency and voting mechanisms.  In general I think that is a great idea. Implementation might be a challenge.

However I would point out that in this particular case it is the fault of the exchange operator not having adequate controls when on-ramping a new protocol; specifically I am referring to allowing withdrawals without manual intervention by operator staff.

But be that as it may...

Would any entity have the same chance to ask the XCP community to insure them?  Basically insure the counterparty risk because he is unable to meet his obligations? Even 50 years from now?

That is the way to be fair about this over time, not some arbitrary fork in the road with a one liner that can easily be commented out. i actually laughed when i read that one...