10 ms·

So, did bitstamp also implement incorrectly despite warnings?

patio11 13y ago
It appears that Bitstamp did indeed use the creation transaction API in bitcoind which returns a transaction ID and they made the incorrect decision that the transaction ID returned had properties many programmers associate with IDs, like "meaning anything at all." What they should have done was waited an hour then done an O(n) scan of all transactions globally in history to find the transaction by inspecting for parameters which exactly matched the ones they provided. That is, the Bitcoin developers now say, the correct use of the create transaction API. Let me use an example programmers may be familiar with. Twilio lets you do SMS messages with three parameters: from_number, to_number, message. You are given back an SMS ID, which you can query to see the results of the SMS message (like, say, was it delivered successfully or did it fail with an error like "that telephone number did not exist"). Here's a discussion with Twilio in the bizarro world where it's like Bitcoin. Me: "Hey Twilio I created an SMS message but when I try to query it for the results it 404s." Them: "Are you sure you created the message?" Me: "Yep pretty sure." Them: "Are you sure you are looking for the right message ID in /messages/:id?" Me: "Yep, I'm using the one that I got back when I created it." Them: "Maybe it changed." Me: "... What?" Them: "Message IDs can change." Me: "They don't usually change." Them: "Of course, they don't usually change. Why have an ID if they usually changed? They only change some of the time." Me: "What determines if a message ID changes?" Them: "Oh, anyone globally can change your message IDs." Me: "That sounds a bit insecure for a system which is, by its nature, deployed in a hostile environment." Them: "Don't worry, they can't change after about an hour. Well, probably. It would be pretty expensive for an attacker to change them after an hour. Don't worry though, you'll never need an ID." Me: "I find IDs useful for querying things. Like, say, messages. Which I have to do. To see whether the message was successful or not." Them: "Well you're already downloading every message ever. Just scan through for one which matches the same from number, to number, and message contents." Me: "... You're serious." Them: "Don't worry though: they can't touch the from number, to number, or the message contents." Me: "... Does this sound a little problematic to anyone else?" Them: "It's on our wiki, noob!" [Edit: Maybe somebody thinks I'm joking. Let me point you to one of the dangerous functions. https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls... Name: sendtoaddress Parameters: <bitcoinaddress> <amount> [comment] [comment-to] Comments: <amount> is a real and is rounded to 8 decimal places. Returns the transaction ID <txid> if successful. You should naturally, upon reading this documentation, figure "I should immediately discard that transaction ID, because it could be changed instantaneously after this message call. If I instead rely on that transaction ID, I will allow malicious users to break the software I am building."]
- latchkey 13y ago
  Comment of the year award. Seriously.
- eterm 13y ago
  Funnily enough, I've had a similar situation to that in my line of work. It wasn't twilio, but it turned out that when we submitted a SMS message of over 160 characters, the provider split it into 160 chunks and sent out as multiple SMS. So far, so normal. But what happened when the first chunk sent successfully and the second chunk failed? We got back a notification to say "MessageID: 4ACB-etc Result: OK" but the customer never got the message, and scanning the report on the provider's site showed the customer number, time and message as having failed. But then the representative agreed it was a problem and set out to fix it rather than blaming our dependence on the ID!
- carlio 13y ago
  I normally enjoy reading your posts here but this one I have to say I find a bit gleefully FUD-tastic. Given that you describe BitCoin as "magic Internet money" [0] I can't help but feel you simply rejoice in BitCoin failures as vindication of your belief that crytocurrency will never work. There seem to be two prevailing extremes of opinion which appear a lot on Hacker News and many other places, as extremes are wont to do while those in the middle don't feel strongly enough to contribute. Those are 1) BitCoin will replace government control of money and fix freedom, dude! and 2) What fucking morons, can't wait until you crash and burn. I love this whole thing. It's fascinating, it's an interesting solution to a problem, and watching DogeCoin take off is fun to watch. In my opinion, BitCoin is kind of like when a naïve programmer decides to rewrite an existing library themselves, and comes up against the brutal reality that led the original developers to the compromises and apparently necessary hacks to get the thing working. The analogy here being regulation, insurance, all that jazz. It's educational, and I haven't been this interested in a technology for a while. I'm picking on your reply here because it is one of many that exemplifies a "haha told you so" rather than really digging into the interesting technical and sociological aspects. * Message IDs from one API do not equate to IDs from the other, so your example is a bit flawed; there's no way to check with Twilio except the ID. * Is "ID" even the term used? I don't know for sure, but "Tx Hash" seems to be more widely spread. [Edit: patio11 edited his comment while I was typing mine; I withdraw this point!] * "It's on our wiki noob" - someone running the 3rd largest exchange should hardly be a "noob" * "O(n) scan of all transactions globally" - that's not particularly hard, nor is it necessary (why scan all transactions from all time?), nor is it unexpected (the entire thing requires everyone to have the complete ledger, so you have the data anyway) There are valid points to be made that the BitCoin protocol needs improvements, and these are even acknowledged by the core devs. This whole situation is a bit ludicrous. But I wish we were talking about "what have we learned", not "told you so". When it comes to BitCoin, the conversation seems to be full of radicals and optimists when success happens, and gloaters when it doesn't. I don't feel either add to the conversation, we could be talking about how to improve this as a currency or (as I believe the long term actual application to be) how this can influence distributed trust, especially important in the current climate. [0] https://twitter.com/patio11/status/431347845031940096 https://twitter.com/patio11/status/431347845031940096
yetfeo 13y ago
It depends. There's a small issue with the reference client that is also causing chains of double spent transactions in merchant wallets: http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_active_malleable_transaction_relayers_it/ http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_activ... I would be more inclined to believe that the majority of sites use the reference client and this is why issues are appearing.

It appears that Bitstamp did indeed use the creation transaction API in bitcoind which returns a transaction ID and they made the incorrect decision that the transaction ID returned had properties many programmers associate with IDs, like "meaning anything at all." What they should have done was waited an hour then done an O(n) scan of all transactions globally in history to find the transaction by inspecting for parameters which exactly matched the ones they provided. That is, the Bitcoin developers now say, the correct use of the create transaction API. Let me use an example programmers may be familiar with. Twilio lets you do SMS messages with three parameters: from_number, to_number, message. You are given back an SMS ID, which you can query to see the results of the SMS message (like, say, was it delivered successfully or did it fail with an error like "that telephone number did not exist"). Here's a discussion with Twilio in the bizarro world where it's like Bitcoin. Me: "Hey Twilio I created an SMS message but when I try to query it for the results it 404s." Them: "Are you sure you created the message?" Me: "Yep pretty sure." Them: "Are you sure you are looking for the right message ID in /messages/:id?" Me: "Yep, I'm using the one that I got back when I created it." Them: "Maybe it changed." Me: "... What?" Them: "Message IDs can change." Me: "They don't usually change." Them: "Of course, they don't usually change. Why have an ID if they usually changed? They only change some of the time." Me: "What determines if a message ID changes?" Them: "Oh, anyone globally can change your message IDs." Me: "That sounds a bit insecure for a system which is, by its nature, deployed in a hostile environment." Them: "Don't worry, they can't change after about an hour. Well, probably. It would be pretty expensive for an attacker to change them after an hour. Don't worry though, you'll never need an ID." Me: "I find IDs useful for querying things. Like, say, messages. Which I have to do. To see whether the message was successful or not." Them: "Well you're already downloading every message ever. Just scan through for one which matches the same from number, to number, and message contents." Me: "... You're serious." Them: "Don't worry though: they can't touch the from number, to number, or the message contents." Me: "... Does this sound a little problematic to anyone else?" Them: "It's on our wiki, noob!" [Edit: Maybe somebody thinks I'm joking. Let me point you to one of the dangerous functions. https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls... Name: sendtoaddress Parameters: <bitcoinaddress> <amount> [comment] [comment-to] Comments: <amount> is a real and is rounded to 8 decimal places. Returns the transaction ID <txid> if successful. You should naturally, upon reading this documentation, figure "I should immediately discard that transaction ID, because it could be changed instantaneously after this message call. If I instead rely on that transaction ID, I will allow malicious users to break the software I am building."]

latchkey 13y ago
Comment of the year award. Seriously.
eterm 13y ago
Funnily enough, I've had a similar situation to that in my line of work. It wasn't twilio, but it turned out that when we submitted a SMS message of over 160 characters, the provider split it into 160 chunks and sent out as multiple SMS. So far, so normal. But what happened when the first chunk sent successfully and the second chunk failed? We got back a notification to say "MessageID: 4ACB-etc Result: OK" but the customer never got the message, and scanning the report on the provider's site showed the customer number, time and message as having failed. But then the representative agreed it was a problem and set out to fix it rather than blaming our dependence on the ID!
carlio 13y ago
I normally enjoy reading your posts here but this one I have to say I find a bit gleefully FUD-tastic. Given that you describe BitCoin as "magic Internet money" [0] I can't help but feel you simply rejoice in BitCoin failures as vindication of your belief that crytocurrency will never work. There seem to be two prevailing extremes of opinion which appear a lot on Hacker News and many other places, as extremes are wont to do while those in the middle don't feel strongly enough to contribute. Those are 1) BitCoin will replace government control of money and fix freedom, dude! and 2) What fucking morons, can't wait until you crash and burn. I love this whole thing. It's fascinating, it's an interesting solution to a problem, and watching DogeCoin take off is fun to watch. In my opinion, BitCoin is kind of like when a naïve programmer decides to rewrite an existing library themselves, and comes up against the brutal reality that led the original developers to the compromises and apparently necessary hacks to get the thing working. The analogy here being regulation, insurance, all that jazz. It's educational, and I haven't been this interested in a technology for a while. I'm picking on your reply here because it is one of many that exemplifies a "haha told you so" rather than really digging into the interesting technical and sociological aspects. * Message IDs from one API do not equate to IDs from the other, so your example is a bit flawed; there's no way to check with Twilio except the ID. * Is "ID" even the term used? I don't know for sure, but "Tx Hash" seems to be more widely spread. [Edit: patio11 edited his comment while I was typing mine; I withdraw this point!] * "It's on our wiki noob" - someone running the 3rd largest exchange should hardly be a "noob" * "O(n) scan of all transactions globally" - that's not particularly hard, nor is it necessary (why scan all transactions from all time?), nor is it unexpected (the entire thing requires everyone to have the complete ledger, so you have the data anyway) There are valid points to be made that the BitCoin protocol needs improvements, and these are even acknowledged by the core devs. This whole situation is a bit ludicrous. But I wish we were talking about "what have we learned", not "told you so". When it comes to BitCoin, the conversation seems to be full of radicals and optimists when success happens, and gloaters when it doesn't. I don't feel either add to the conversation, we could be talking about how to improve this as a currency or (as I believe the long term actual application to be) how this can influence distributed trust, especially important in the current climate. [0] https://twitter.com/patio11/status/431347845031940096 https://twitter.com/patio11/status/431347845031940096

yetfeo 13y ago

It depends. There's a small issue with the reference client that is also causing chains of double spent transactions in merchant wallets: http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_active_malleable_transaction_relayers_it/ http://www.reddit.com/r/Bitcoin/comments/1xm49o/due_to_activ... I would be more inclined to believe that the majority of sites use the reference client and this is why issues are appearing.