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

[halfcab123]

we should trustlessly vote on a few predetermined scenarios, with a minimum amount of voters required for the vote to stand. If not enough voters participate we will have to have PhantomPhreak and Xnova talk with us on the forum and come to a decision based on whats best for the majority, and which plan of action does the least damage to the notoriety and fairness of the protocol. We have to really think longterm here guys. For instance if you gain back 100% and people lose faith then your 100% might not be worth much, but if you gain back 60% and the rep stays the same.. well.. ? then you just might have a pot of gold, like we all will inevitably have anyways.

Chaotic logic!  Shut up please. You have given too much noise in this forum! We all know you have burned 15BTC. ok!

Oh.. Man that was pretty rude. Was that really necessary ? I've already been told I have good points. I didn't even say anything about how much I burned. I guess its time to pull out the chairs again, please have one of these _/ kind sir, and for you a special treat here is your lovely dunce cap /\ ... Thanks.

[flayway]

Maybe we can now wait and look how every party from butoni to hacker and us devs make.. Someone of us maybe get little damage after all, for that we cant do anything, but we need to trust the future. Coin is not dead or worthless. That only come more strong after this attack. We get serious security bug fixed really fast and also idea for bug bounty. With last one we maybe can pass same situations in future. We can build so fucking hard total bounty that most biggest security bug finder turn black hat hacker to white when hope to get full bounty if security bug is enough big..

[lonsharim]

I definitely support raising some sort of fund for Busoni, and would happily contribute to it.

I disagree that the person who spotted this wasn’t acting benevolently. It’s true that they weren’t as white hat as they possibly could have been, but at the same time they could have damaged the whole project much more than they did. I think they should still receive a bounty for pointing out and helping to fix a flaw.

Apart from the 80 BTC that they are yet to return? Now that's called benevolent.

[halfcab123]

If anyone has a problem with me, which I've already seen a few really do, I definitely apologize. Please don't hesitate to hit the ignore button in the margin.

[520Bit]

If some other talents could join the project, maybe better. The Counterparty team have to focus on code right now. Give them time, OK? Counterparty protocol, client and coin were announced just for less than two months. Do you see any other project make this kind of progress in just less than two months announcement?

[qtgwith]

If some other talents could join the project, maybe better. The Counterparty team have to focus on code right now. Give them time, OK? Counterparty protocol, client and coin were announced just for less than two months. Do you see any other project make this kind of progress in just less than two months announcement?

Support! Great work.We need more patience.

[puipamchi21]

There's no decision to be made. If you change the protocol after-the-fact, you lose all credibility. It's the same discussion the bitcoin community recently had about the DPR coins. It would be advantageous to fork out all the captured DPR/FBI coins...but the damage to the protocol would be HUGE.

Also, for what it's worth, I'm definitely rethinking my assessment of the "white hat" hacker here. It now sounds less like a white hat and more like a really conflicted grey hat. A benevolent hacker would have withdrawn and redeposited the 35k XCP, then done a couple of small transactions to prove it was possible, then notified Busoni. A white hat would NOT have executed 80 BTC worth of trades and completely disrupted the exchange, if not the entire XCP marketplace.

FACT: Busoni is going to spend days, maybe weeks, sorting through the result of this debacle and trying to figure out how to disperse the "damage."

I call on all the community members who pledged bounties to the "white hat" hacker to rescind those pledges, and instead forward any donations to Busoni, to help him resolve the damage that this hacker caused to Poloniex, and possibly to the entire ecosystem.

I agree with you. Protocol shouldn't be changed. Busoni, did a great help by listing XCP in his exchange Poloniex and helped us to find a big bug. As with any risky business, Busoni might be knowing there is a possibility of this kind of loss. We can help him to recover his losses as much as we can. But protocol shouldn't be changed.

[jaybny]

Can someone please explain what happens when two people try to sell at the bid price at the same time? Who gets the fill?
This is fundamental issue with Decentralized Distributed Exchanges.

There's no such thing as 'at the same time' in the blockchain: two transactions in the same block are handled in order of appearance within the block.

but the order of the transactions can be different per miner... so its dependent on which miner solves the block?

Yes.

PhantomPhreak, thanks for responding.
 
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  

[qtgwith]

There's no decision to be made. If you change the protocol after-the-fact, you lose all credibility. It's the same discussion the bitcoin community recently had about the DPR coins. It would be advantageous to fork out all the captured DPR/FBI coins...but the damage to the protocol would be HUGE.

Also, for what it's worth, I'm definitely rethinking my assessment of the "white hat" hacker here. It now sounds less like a white hat and more like a really conflicted grey hat. A benevolent hacker would have withdrawn and redeposited the 35k XCP, then done a couple of small transactions to prove it was possible, then notified Busoni. A white hat would NOT have executed 80 BTC worth of trades and completely disrupted the exchange, if not the entire XCP marketplace.

FACT: Busoni is going to spend days, maybe weeks, sorting through the result of this debacle and trying to figure out how to disperse the "damage."

I call on all the community members who pledged bounties to the "white hat" hacker to rescind those pledges, and instead forward any donations to Busoni, to help him resolve the damage that this hacker caused to Poloniex, and possibly to the entire ecosystem.

I agree with you. Protocol shouldn't be changed. Busoni, did a great help by listing XCP in his exchange Poloniex and helped us to find a big bug. As with any risky business, Busoni might be knowing there is a possibility of this kind of loss. We can help him to recover his losses as much as we can. But protocol shouldn't be changed.

Absolutely agree with you!

[IamNotSure]

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 !

[halfcab123]

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.

[puipamchi21]

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 !

For your info, High Frequency Trade means use of automated systems to execute billions of trade in seconds by splitting into smaller orders

[ddink7]

Is the DEX working? I'm not seeing any newly matched orders on blockscan.

[wizzardTim]

Is the DEX working? I'm not seeing any newly matched orders on blockscan.

exactly. what is happening on the DEX and POLONIEX?

[jaybny]

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.

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

Not Going to Happen.

Busoni is still working a solution, wait for a proposal and then we'll start discussing for a compensation if someone is in the red.

It's in alpha, it is written in red in the first post, these kind of things were going to happen, and might happen again (with a lower probability now)

Personally I've traded a tiny part of my XCP on poloniex, because trading more than 2-3% of your holdings at this stage is foolish. If I lose them because of a bug in the alpha, a hack on an exchange, of whatever, I wouldn't complain.

Yeah, it is an alpha and written in red in the first post. One of the things that would happen is you might lose value in your holdings. So why are you complaining about it happening to you when it is an easy fix that would prove the quality of the community? You said yourself, it is OK to lose them due to a bug in the alpha.


 

[ddink7]

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

[chinnuperiya]

Any plans to add XCP to any other centralised exchange than poloniex. What is the status with DGEX? I want to liquidate my holdings

[IamNotSure]

Any plans to add XCP to any other centralised exchange than poloniex. What is the status with DGEX? I want to liquidate my holdings

Sell in bulk in the buy/sell thread

https://bitcointalk.org/index.php?topic=445740.0

You'll find a buyer in no time

PS: alternatively you can PM me the price and quantity you want to sell and I'll see if I'm intrested

[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 "quirk" 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.