Wait, WHAT??! Are my btc gone?  ? c:\counterpartyd_build>counterpartyd btcpay --order-match-id 4cf58e136cc46c8fca50ca9a095559e1fe607f8693737973018c3046e30d08b2ca0c75e8478c7ff ac0ca7ddf9a390bfb88b 1bf1356db28d5465d7f5a36cfddeb http://blockscan.com/btcpay.aspx#Tx Block Source TimeStamp Order MatchID Remark 3321 284510 1EEwWVYaSF2QUsv3nMz8h5uGifHiuza485 2014-02-06 20:10:21 4cf58e136cc46c8fca50ca9a095559... Invalid: no such order match ID *sigh* Please read the over a dozen posts I've made in this thread, as well as on the forums, warning people about this issue. Please update your version of counterparty to the latest. PhantomPhreak will, of course, reimburse you for the BTC loss that you've accrued. Devs: If the version requirement thing will take a while, can you please edit the first post in LARGE RED LETTERS LIKE THIS warning people about the issue? Also, put up stickies in the forums. Also blockscan, if that helps. That's very kind for PhantomPhreak to reimburse me. @PhantomPhreak: Please send 0.0800667 BTC to 1337SBVs6V5Ty8xA2GiRroRDFCWMDTpXv2 Tx Block BlockTime Source Destination BTCAmount Fee 3321 284510 2014-02-06 20:10:21 1EEwWVYaSF2QUsv3nMz8h5uGifHiuza485 BtcPay Paid to 1PBmybpJ9DXFCMqGdcMHd7FdbVYLajH5nU 0.08006667 0.0001 Many thanks in advance! @jimhsu: I update my version daily, I was not expecting conditions that could lead me to sending btc into a black hole. Sorry for not reading through the past 100 messages on the board each time before touching counterpartyd..... wow! Yes, this is a very rare, irreversible bug in the order matching (normally bugs like this are reversible, but not BTCpay, so why I got on top of this so quickly). That's why I wanted the devs to get out version requirement code and make announcements about this so urgently. Also, I think reimbursements are handled according to the value of XCP for that order. |
|
|
|
Wait, WHAT??! Are my btc gone? ? c:\counterpartyd_build>counterpartyd btcpay --order-match-id 4cf58e136cc46c8fca50ca9a095559e1fe607f8693737973018c3046e30d08b2ca0c75e8478c7ff ac0ca7ddf9a390bfb88b 1bf1356db28d5465d7f5a36cfddeb http://blockscan.com/btcpay.aspx#Tx Block Source TimeStamp Order MatchID Remark 3321 284510 1EEwWVYaSF2QUsv3nMz8h5uGifHiuza485 2014-02-06 20:10:21 4cf58e136cc46c8fca50ca9a095559... Invalid: no such order match ID *sigh* Please read the over a dozen posts I've made in this thread, as well as on the forums, warning people about this issue. Please update your version of counterparty to the latest. PhantomPhreak will, of course, reimburse you for the BTC loss that you've accrued. Devs: If the version requirement thing will take a while, can you please edit the first post in LARGE RED LETTERS LIKE THIS warning people about the issue? Also, put up stickies in the forums. Also blockscan, if that helps. |
|
|
|
Devs, would it be possible to push out that version requirement patch any time soon? Don't want to see more BTC go to waste. If it produces some sort of cryptic error message, all the better because it'll make people hit the forums to find out what's going on. |
|
|
|
|
Heads up, I see some more invalid order matches:
3288 284402 1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb 2014-02-06 05:29:18 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f...
3286 284391 1JUXwDjh21yLkUhKNdggenexZK8XpeXTRx 2014-02-06 04:26:13 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f...
3285 284390 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN 2014-02-06 04:14:45 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f...
3282 284386 1CJTDpHBvcQw4e7FCKzkT9j62PuXegWdYN 2014-02-06 04:26:07 023d390307488909fc6b05a37a3335... Invalid: invalid order match ID, 023d390307488909f...
Someone needs to update their client?
|
|
|
|
|
I see that you've implemented the order book -- props for an absolutely essential feature.
Can you sort the Sell orders in ascending order though (cheapest sell on top)? Optionally also put last trade/volume info on top.
A chart would also be nice, but I don't think we have enough volume yet.
|
|
|
|
Is there a way to reconcile the situation? Or are my bitcoins irrecoverable due to the bug?
I would hope that the sellers who benefitted from this bug will send the XCP to their buyers, realizing that in order for the rest of their XCP to appreciate in value early buyers shouldn't feel scammed. I'll try to make a list of all affected accounts: BTCPay out: 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb 1EEwWVYaSF2QUsv3nMz8h5uGifHiuza485 BTCPay mistakenly received: 1GbkV2QgQ2jqHk8yjgcdwEMfLC1Y6oGSMF - 0.4 - 250 XCP not delivered to 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1JBp8tdzwzo5VKcKpg1QHKbYP2sKDNWGnk - 0.11 - no XCP orders 17PgVzRSSSjc2aN8Lyp1x9QayKzPzY2pKj - 0.65 - no XCP orders If you lost BTC due to this bug, PM me and the Counterparty team will reimburse you the XCP you were supposed to have purchased (if the seller will not do this himself). This does not mean that we will reimburse everyone who loses money due to bugs in this software in the future. This is a very specific kind of bug that appeared because of the interaction of some rounding issues with Bitcoin transactions, which of course are irreversible in the Counterparty protocol. Also, we let the master branch fall too far behind the develop branch, so the problem was not fixed as quickly as it might have been. The rounding errors have been fixed permanently and properly, so the likelihood of a similar bug causing loss of funds is unlikely. Of course, this is still alpha software, so use your discretion. Very noble of the devs for such a move. This is the type of project that gets my support. Later I'll be donating the trade that was supposed to be made to the bounty fund. |
|
|
|
Great, that's the kind of honest feedback we need.
Note to self: You're fired! lol.
Alright, you've asked for my honest opinion. I'll divide it into several categories: Usability: I think this is some sort of title page, from the appearance. However, I'm not sure what sort of content is being presented on this page. Features? Power of the network? Etc. Also, what is a good place for a menu? Aesthetics: Full color backgrounds may seem like a good idea, but only if done properly. Something like this could work if there is a fadeout to white at the bottom, followed by the key features. The text, in addition, is not very readable on top of the background. Furthermore, the design trends recently have been away from photorealistic backgrounds, unless you're in charge of managing a photo gallery or something similar. Bitcoin: I'm mixed on using bitcoin's logo on top of that page. We've had this discussion before with other coins, and I don't think presenting another coin's logo on your coin's page is that good of an idea, no matter how it's presented. The transition makes sense, but I don't think the image itself does. Just my two cents. |
|
|
|
I created an order then sent bitcoins after seeing an order-match ID, however the order seems to have expired anyway. I received no XCP from this trade according to Blockscan. http://blockscan.com/order.aspx?q=3251The expiration was set to 15, however the bitcoins were sent within 4 blocks. Can anyone assist? What branch are you using? I used git to clone what I believe is the master branch. Prior to this trade yesterday I updated due to the bug with block 284193. There are a few btcpays to invalid order match ids according to blockscan: http://blockscan.com/btcpay.aspxThe bitcoins were definitely transacted...confirmed by blockchain.info. Bump to this. I sold the XCP for that order, and did not get the BTC intended for the BTCpay. I don't know what account that BTC was sent to. Another BTC sell order from that same order successfully processed though, so my order does work. Problem seems to be in the BTCpay matching. The issue seems to be that order matches that existed in master didn't exist in develop, due to the recent changes in the rounding algorithms. I've updated master now. Thanks. Since this (I believe) resulted in actual BTC lost by one or more parties, would it be advisable for all parties to manually reconcile these transactions? Of course this being bitcoin I can't force anyone to do anything. Is there a way to reconcile the situation? Or are my bitcoins irrecoverable due to the bug? I would hope that the sellers who benefitted from this bug will send the XCP to their buyers, realizing that in order for the rest of their XCP to appreciate in value early buyers shouldn't feel scammed. According to jimhsu, he was the counterparty of the trade, but didn't receive my bitcoins. (Jimhsu, did you lose your XCP also?) So are my bitcoins irrecoverable due to the bug? No, I got my XCP back after order expiration matched, but your BTCPay was not sent to me. I was not harmed nor the beneficiary of any of these transactions. For those new to this discussion: This bug has been fixed in latest versions of develop and master. |
|
|
|
Is there a way to reconcile the situation? Or are my bitcoins irrecoverable due to the bug?
I would hope that the sellers who benefitted from this bug will send the XCP to their buyers, realizing that in order for the rest of their XCP to appreciate in value early buyers shouldn't feel scammed. I'll try to make a list of all affected accounts: BTCPay out: 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1AQPf7f3y37NN9XsYkfGGALHQiW1ig3MXb 1EEwWVYaSF2QUsv3nMz8h5uGifHiuza485 BTCPay mistakenly received: 1GbkV2QgQ2jqHk8yjgcdwEMfLC1Y6oGSMF - 0.4 - 250 XCP not delivered to 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1JBp8tdzwzo5VKcKpg1QHKbYP2sKDNWGnk - 0.11 - no XCP orders 17PgVzRSSSjc2aN8Lyp1x9QayKzPzY2pKj - 0.65 - no XCP orders |
|
|
|
I created an order then sent bitcoins after seeing an order-match ID, however the order seems to have expired anyway. I received no XCP from this trade according to Blockscan. http://blockscan.com/order.aspx?q=3251The expiration was set to 15, however the bitcoins were sent within 4 blocks. Can anyone assist? What branch are you using? I used git to clone what I believe is the master branch. Prior to this trade yesterday I updated due to the bug with block 284193. There are a few btcpays to invalid order match ids according to blockscan: http://blockscan.com/btcpay.aspxThe bitcoins were definitely transacted...confirmed by blockchain.info. Bump to this. I sold the XCP for that order, and did not get the BTC intended for the BTCpay. I don't know what account that BTC was sent to. Another BTC sell order from that same order successfully processed though, so my order does work. Problem seems to be in the BTCpay matching. The issue seems to be that order matches that existed in master didn't exist in develop, due to the recent changes in the rounding algorithms. I've updated master now. Thanks. Since this (I believe) resulted in actual BTC lost by one or more parties, would it be advisable for all parties to manually reconcile these transactions? Of course this being bitcoin I can't force anyone to do anything. |
|
|
|
I created an order then sent bitcoins after seeing an order-match ID, however the order seems to have expired anyway. I received no XCP from this trade according to Blockscan. http://blockscan.com/order.aspx?q=3251The expiration was set to 15, however the bitcoins were sent within 4 blocks. Can anyone assist? What branch are you using? I used git to clone what I believe is the master branch. Prior to this trade yesterday I updated due to the bug with block 284193. There are a few btcpays to invalid order match ids according to blockscan: http://blockscan.com/btcpay.aspxThe bitcoins were definitely transacted...confirmed by blockchain.info. Bump to this. I sold the XCP for that order, and did not get the BTC intended for the BTCpay. I don't know what account that BTC was sent to. Another BTC sell order from that same order successfully processed though, so my order does work. Problem seems to be in the BTCpay matching. |
|
|
|
Watch out: there's a fatal bug in develop triggered in block 284193 with the error message: 'assert asset != 'BTC' # Never BTC.'. I just pushed a hotfix to GitHub.
I got the error on the master branch. It still doesn't work for me with the latest github. Yeah, mine does the same as well. When I do a "git pull origin master" I get an update saying 'Already upto date'. Maybe that is probably why. Switch to develop or manually apply this fix to cancel.py: https://forums.counterparty.co/index.php/topic,22.msg163.html#msg163If not technically inclined, just wait it out a few days. |
|
|
|
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. Thanks for your input Vitalik. Speaking from the Wall Street perspective, not all exchanges out there are even suitable for high frequency trading (witness the recent rise of electronic exchanges - ARCA, BATS, etc). Not all participants are interested in "low-quality" liquidity so to speak, as provided by most high-frequency exchanges (which was one of the indirect causes of the infamous 2010 Flash Crash). Not all assets need to be traded on a real-time basis (real estate [which has many analogies with BTC], bonds, and mutual funds for instance). It's not also widely appreciated that official settlement for stock trades occurs not instantaneously, but 3 days ( the T+3 rule). In contrast, 1 hour (6 confirmations) is widely acknowledged to be a reasonable settlement time for even the largest BTC trades. The blockchain more closely resembles, say, the housing market or the contracts/swaps derivatives markets, which don't operate in any way similar to HFT even though they handle trillions of dollars in notional value. So the notion that non-highly liquid markets can't be valuable is absurd. |
|
|
|
FYI, I've contacted Bitcoin Magazine to let them know about the project. They seem to be interested in looking into it! Ruben Alexander 4:09 PM (13 minutes ago) to me I kinda missed the boat on this and I normally like to be involved early on. I see that your gui will be released on valentines day. Is there an early build (even cli is fine) I can play with? David [email address redacted] 4:22 PM (0 minutes ago) to Ruben Sure! Link included below. FYI I'm just an enthusiast and not "in charge" in any way. Here is a link to the thread on Bitcointalk. The first post is very informative with instructions etc. Thanks for your response!! Counterparty is a protocol for the creation and use of decentralised financial instruments using Bitcoin as a transport layer. It has an open-source and MIT-licensed reference implementation, counterpartyd, which is available for download/perusal at https://github.com/PhantomPhreak/counterpartyd/. The protocol specification is hosted athttps://github.com/PhantomPhreak/Counterparty. Pull requests are welcome! Great, mention that the (CLI) client is fully functional, blockscan.com (a truly invaluable resource), and forums are available for installation/troubleshooting. |
|
|
|
Can someone point me to the details on the Superbowl bet?
How did the bet work out? Did two people send BTC or XCP to an address, and the Counterparty protocol settled the bet and did the payout automatically?
If that's what happened, where did the protocol get the result of the game from?
I'm curious if this was really a "trustless" superbowl bet, or if there is a trusted party somewhere in there.
Thanks!
The two parties in that bet were BiggestFish and me. Every part of the bet, except for the feed, was completely trustless. I explained that in this particular case, we didn't place any stringent rules on the feed operator. In a professional setting, a feed operator wouldn't be participating in the actual betting to avoid conflict of interest, and could vet himself by a) being a trusted member of the forum, and b) signing messages related to the bet with his key. There had been discussions to turn even the feed into something trustless; however that is complicated, both theoretically and practically (someone could, for example, launch a man in the middle attack against cryptsy's API if using that for a bet). Ultimately a trusted party has to provide the data somewhere (do you trust CNN? ESPN? NIST?). The important innovation is that there is no escrow requirement -- given the inherent nature of XCP, you don't need someone to hold the pot. And any deviation (from the part of the feed operator reporting an incorrect score, for instance) is instantly detectable. BiggestFish could have reported, for instance, that Broncos won, but that deviation is instantly detectable to all parties of the bet (who would therefore not use his services in the future). But there is no theoretical possibility for him to run off with the pot. |
|
|
|
Contract Settled: NotEqual won the pot of 2.0 XCP; 0.0 XCP credited to the feed
address (c1cfe0315493ac2c...3fbd9e4e76bff67d)
Woot, first real XCP bet completed. (This could go into the press release, also).
Broncos lost, but oh well. Congrats Seahawks.
I feel proud to be part of this historic event. This could be XCP's "bitcoin pizza". Can't think of a more fitting first XCP transaction than a decentralized bet on the Super Bowl. Obviously a friendly bet of course. I'd imagine for truly professional-style betting: 1. Trusted member of community / verified ID / DD 2. Announces betting by signing post with BTC/XCP address 3. Collects the bets (with fees) 4. Announces result of bet, signed again 5. Broadcast result of feed 6. (the best part) winnings are distributed automatically, and are completely trustless The only "trust" in this system is the feed operator, no one else (no middlemen). |
|
|
|
|
Show Posts
