lonsharim
|
|
February 20, 2014, 04:04:26 AM |
|
Blockscan is back up and it looks like Poloniex balance was restored.
So now it's really up to busoni to figure out what he wants to do. IMO the best policy is to throw out all trades made by the attacker and credit back the buyers' BTC. Those trades wouldn't have happened without the attack so I don't understand people complaining about not getting to keep the XCP they bought for 0.002.
That's assuming busoni wants to continue to serve as punching bag for any future XCP exploits though. Completely understandable if he does not. If we no longer have a centralized exchange it would really shift focus to fixing the DEX. This thread was full of good discussion about that until it got derailed by price speculation.
This creates a bit of a mess for busoni to clean up. No matter which way we approach this, someone is going to be unhappy. Original Depositors of XCP are safe because it is not their trades that got executed and the reparse has restored their balances in the central wallet. The best way forward is for 0.002 transactions to be rolled back and hacker return bitcoins because the deposit of 35k XCP has an invalided input. I don't understand how the hacker is considered benevolent. A white hat would have exposed the vulnerability without causing such a mess to clean up. Even if he withdrew 35k to prove a point, depositing it back and dumping it does not show good intentions IMO To me it seems like he knew a patch release will invalidate his XCP holdings and therefore he made away with as many bitcoins as he could take and until he returns them back to busoni my opinion will not change. The discussion regarding XBTC/BTC/DAC/Escrow was evolving nicely until this came along, maybe we should pursue that discussion in a separate thread in the counterparty forums.
|
|
|
|
|
xnova
Sr. Member
Offline
Activity: 390
Merit: 254
Counterparty Developer
|
|
February 20, 2014, 04:17:54 AM |
|
The Counterparty team would like to thank the community with being patient as we collectively work through this issue. We really appreciate it.
As others have mentioned, these kinds of issues are not unique to XCP. However, that does not lessen the severity of security issues in our eyes. One of our main focuses throughout the protocol and reference client design was, and very much still is, to make things as simple and straightforward as possible for exactly these kinds of reasons (i.e reduced attack vectors, less chance for bugs).
At this point, Counterparty has started to gain the success and market value that has begin to attract many people to it. This is good, but -- like Bitcoin or any other innovative digital currency -- it also increases the stakes of any potential security issues found. Therefore, in short order we will be announcing a generous security bug bounty program which will be driven by donations from all of us in the community. Hopefully this should help bring extra eyes on the code to chase out any flaws, and compensate the talented individuals that do assist on this front.
We remain committed to making the distributed exchange as useful and straightforward as possible. The newest clients include updates to the DEx functionality that should hopefully take care of the troll order issue. Our plan is to see how these changes play out in the market, and do further tweaking as is necessary.
Regarding Poloniex, I know we are all awaiting busoni's assessment of the situation, and we can collectively decide on the best course of action based on that.
Thanks again to everyone for working through XCP's maturation process with us.
|
|
|
|
xnova
Sr. Member
Offline
Activity: 390
Merit: 254
Counterparty Developer
|
|
February 20, 2014, 04:23:10 AM |
|
Due to the present rapid speed of development, it's definitely better at this time to build from source over using the windows installers (as they may lag behind the newest source updates...generally I try to update at every new version number but sometimes it may take a bit of time to get to this). As Counterparty continues to mature, these version updates will become less frequent, and using the windows binaries (or any binary-based counterpartyd install) will make more sense.
|
|
|
|
Spekulatius
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
February 20, 2014, 04:27:20 AM |
|
The Counterparty team would like to thank the community with being patient as we collectively work through this issue. We really appreciate it.
As others have mentioned, these kinds of issues are not unique to XCP. However, that does not lessen the severity of security issues in our eyes. One of our main focuses throughout the protocol and reference client design was, and very much still is, to make things as simple and straightforward as possible for exactly these kinds of reasons (i.e reduced attack vectors, less chance for bugs).
At this point, Counterparty has started to gain the success and market value that has begin to attract many people to it. This is good, but -- like Bitcoin or any other innovative digital currency -- it also increases the stakes of any potential security issues found. Therefore, in short order we will be announcing a generous security bug bounty program which will be driven by donations from all of us in the community. Hopefully this should help bring extra eyes on the code to chase out any flaws, and compensate the talented individuals that do assist on this front.
We remain committed to making the distributed exchange as useful and straightforward as possible. The newest clients include updates to the DEx functionality that should hopefully take care of the troll order issue. Our plan is to see how these changes play out in the market, and do further tweaking as is necessary.
Regarding Poloniex, I know we are all awaiting busoni's assessment of the situation, and we can collectively decide on the best course of action based on that.
Thanks again to everyone for working through XCP's maturation process with us.
Thx, I think you are doing a good job. What is your mood towards taking on more developers for providing a more stable foundation for the growing project and working on finding bugs like the last one earlier? (I dont blame you guys, just saying 6 eyes see more then 4. Or 8, or 10..)
|
|
|
|
halfcab123
Full Member
Offline
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
|
|
February 20, 2014, 04:40:40 AM |
|
Is there really any hard evidence that Mastercoin and NXT are not indeed ahead of us at this point ?
|
DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
|
|
|
xnova
Sr. Member
Offline
Activity: 390
Merit: 254
Counterparty Developer
|
|
February 20, 2014, 04:47:28 AM Last edit: February 20, 2014, 06:16:08 AM by xnova |
|
The Counterparty team would like to thank the community with being patient as we collectively work through this issue. We really appreciate it.
As others have mentioned, these kinds of issues are not unique to XCP. However, that does not lessen the severity of security issues in our eyes. One of our main focuses throughout the protocol and reference client design was, and very much still is, to make things as simple and straightforward as possible for exactly these kinds of reasons (i.e reduced attack vectors, less chance for bugs).
At this point, Counterparty has started to gain the success and market value that has begin to attract many people to it. This is good, but -- like Bitcoin or any other innovative digital currency -- it also increases the stakes of any potential security issues found. Therefore, in short order we will be announcing a generous security bug bounty program which will be driven by donations from all of us in the community. Hopefully this should help bring extra eyes on the code to chase out any flaws, and compensate the talented individuals that do assist on this front.
We remain committed to making the distributed exchange as useful and straightforward as possible. The newest clients include updates to the DEx functionality that should hopefully take care of the troll order issue. Our plan is to see how these changes play out in the market, and do further tweaking as is necessary.
Regarding Poloniex, I know we are all awaiting busoni's assessment of the situation, and we can collectively decide on the best course of action based on that.
Thanks again to everyone for working through XCP's maturation process with us.
Thx, I think you are doing a good job. What is your mood towards taking on more developers for providing a more stable foundation for the growing project and working on finding bugs like the last one earlier? (I dont blame you guys, just saying 6 eyes see more then 4. Or 8, or 10..) As we don't operate a foundation with millions of dollars in funding, our ability (and desire) to hire and retain a large team is limited, and moreover is against the ethos of the project. As the core team, our mandate (i.e. https://counterparty.co/wiki/counterparty-project-principles) is purposefully restricted, and we intend to stay within that. However, especially as the value of XCP increases we will likely add some dedicated development strength in a way that is controlled and reasonable, while at the same time being very effective. We are currently exploring some possibilities along these lines. That all being said, ultimately XCP's success will lie in the growth and participation of the social network around it. Counterparty is all about the opportunities that it enables for entrepreneurs, developers, financial professionals, and more. For instance, in the long term, we would love to see additional client implementations (like libbitcoin/sx is vs bitcoind, for instance) and much more diversity, in order to even further increase the security of the network and reduce any remaining potential points of failure, human or otherwise. We would also love to see Counterparty itself become so successful that it essentially takes backstage to the inventions and creations running on it. This project was never about its creators -- the focus has to remain on the creation itself, and the groundbreaking things that it enables for both Bitcoin and finance in general.
|
|
|
|
Chang Hum
|
|
February 20, 2014, 04:48:38 AM |
|
[/quote]
Thx, I think you are doing a good job. What is your mood towards taking on more developers for providing a more stable foundation for the growing project and working on finding bugs like the last one earlier? (I dont blame you guys, just saying 6 eyes see more then 4. Or 8, or 10..) [/quote]
Could someone please confirm this statement is correct?
|
|
|
|
busoni
Sr. Member
Offline
Activity: 364
Merit: 250
Owner of Poloniex
|
|
February 20, 2014, 04:48:50 AM |
|
Okay, so if I were to roll back the dump, Poloniex would be short about 80 BTC. I have messaged the hacker again, and hopefully he will stick to his word. His actions don't really seem consistent with someone who just wanted to steal BTC--as I said, he left about 35 BTC in his account. Why he decided to make a mess, though, I don't know.
As I don't think he has the XCP to cover the dump, I'm probably going to end up trying to roll back the trades. This might get a little complicated, though, as I didn't see it happen right away and people withdrew XCP after the dump. I'm going to wait until tomorrow (about 12 hours from now) to hear back from him, and then I will most likely start rolling back the trades.
|
Poloniex.com - Fast crypto exchange with margin trading, advanced charts, and stop-limit orders
|
|
|
DaFockBro
Newbie
Offline
Activity: 126
Merit: 0
|
|
February 20, 2014, 05:00:19 AM |
|
The Counterparty sub-reddit only has 52 subscribers. Please create a reddit account and subscribe, it takes less than 5 minutes: http://www.reddit.com/r/counterparty_xcp
|
|
|
|
relm9
|
|
February 20, 2014, 05:11:33 AM |
|
I imagine there will be a drop in price ones trades begin functioning again. In the long term, I don't see any problems. Devs are clear that this is alpha level code and problems may arise. Personally, I think we've seen that a) the devs had a fix within hours (very, very impressive), b) we have a good and responsive community, including Busoni and the white hat. So I think there is some positive takeaway here. nxt had a similar critical bug just a week ago, but without the pumping (also white hat), nothing happened to the development or even short term price There was a blockchain rollback with NXT a few months ago too, I remember as one of my trades went missing and had to ask the seller to resend at the time. I don't remember it impacting the price. I think most people realize these things can happen, better when it's early on than later.
|
|
|
|
ginko-B
Member
Offline
Activity: 82
Merit: 10
|
|
February 20, 2014, 05:20:15 AM |
|
Okay, so if I were to roll back the dump, Poloniex would be short about 80 BTC. I have messaged the hacker again, and hopefully he will stick to his word. His actions don't really seem consistent with someone who just wanted to steal BTC--as I said, he left about 35 BTC in his account. Why he decided to make a mess, though, I don't know.
As I don't think he has the XCP to cover the dump, I'm probably going to end up trying to roll back the trades. This might get a little complicated, though, as I didn't see it happen right away and people withdrew XCP after the dump. I'm going to wait until tomorrow (about 12 hours from now) to hear back from him, and then I will most likely start rolling back the trades.
Busoni, Were all of the withdrawals by the hacker in BTC? Or were some of the hacker withdrawals in XCP too?
|
|
|
|
jaybny
|
|
February 20, 2014, 05:28:38 AM |
|
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.
|
|
|
|
broken_pixel
|
|
February 20, 2014, 05:29:45 AM |
|
Trade Volume: 65.979 BTC
|
GA-990FXA-UD5, 1x 7970L, 2x S1, AX1200i, RIVBE, 2x R290x, NEX1500, BTC: 1G9cQix8bMgh35MQ9wY3Rb9yNSSCtnoRmK, DGC: DFo9FcKYsutv9Vx5c5xUzkrt7VJdECZWTM, LTC: LaAN33aktPGaimN5ALL9kjHjuJekfmKfTh
|
|
|
PhantomPhreak (OP)
Sr. Member
Offline
Activity: 476
Merit: 300
Counterparty Chief Scientist and Co-Founder
|
|
February 20, 2014, 05:40:47 AM |
|
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.
|
|
|
|
halfcab123
Full Member
Offline
Activity: 224
Merit: 100
CabTrader v2 | crypto-folio.com
|
|
February 20, 2014, 05:44:39 AM |
|
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 ?
|
DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
|
|
|
jaybny
|
|
February 20, 2014, 05:49:39 AM |
|
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?
|
|
|
|
qwertyqwerty
|
|
February 20, 2014, 05:59:08 AM |
|
Can Someone not Host The Block Chain So I can Download It Maybe Or Something .... Would That Work ?
halfcab123: I Don't Know What The Rush Is To Consolidate The Addresses. Especially With The Amount You Had Burned.. Or IDK. The Counterwallet Should Maybe Have Ability To Sweep The Balance Or Something Xnova Mentioned This On The Counterparty Forum
|
|
|
|
led_lcd
|
|
February 20, 2014, 06:07:13 AM |
|
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 aheadI'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.
|
|
|
|
lonsharim
|
|
February 20, 2014, 06:12:02 AM |
|
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.
|
|
|
|
|