6 ms·

Seems like whoever writes financial code in the future should treat it more like NASA code than startup technical-debt code.

by cordite 12y ago

ryan-allen 12y ago
This is true if you intend on running an exchange properly and not being a highway robber posing as a travelling dentist.
- panhandlr 12y ago
  Exactly... From my perspective, their plan worked perfectly. 1. Open an exchange. 2. Collect real money in exchange for fake money. 3. "Get hacked" losing all the fake money and keeping all the real money.
  - im2w1l 12y ago
    Yeah, "We noticed the hot wallets dwindling but assuming it was members moving their funds off site during the DDOS, we loaded all the cold balances onto the site" sounds extremely suspicious.
    - Mtinie 12y ago
      Possiblely, but in light of the protracted duration of the DDoS, it makes sense that people would be moving their holdings off-exchange when they could connect. If the withdrawal addresses were all different -- and from what Excoin posted on their site it looks like the party responsible used multiple BTC and NBT addresses to move the funds -- multiples of small to moderate amounts of coins being requested doesn't sound out of the question. In retrospect, it was a horrible decision not to research these transactions in depth as they happened, but the Excoin team was fighting a "bigger" fire at the time with the DDoS.
  - brighton36 12y ago
    Which one is the fake money, USD or btc?
- rodgerd 12y ago
  Sufficiently advanced criminality is indistinguishable from gross stupidity, apparently.
trupedo 12y ago
But are the customers willing to pay a significant premium price for the development effort of NASA-ized exhange? If the answer is no (and I suspect it is), then incentives are aligned so that putting extra effort into security is something an exchange operator should definitely not do. All of this is also assuming (on faith) that the business model is actually running an exchange, as opposed to a hack-blaming racket.
- Johnie 12y ago
  If you believe this, you shouldn't be handling people's money. It's not just about losing the bitcoin, people running these exchanges may be personally liable.
  - trupedo 12y ago
    > It's not just about losing the bitcoin, people running these exchanges may be personally liable. The law is still very murky here, and there are plenty of ways to deflect responsibility. I'm not saying any of this is right, I'm suggesting that the way our culture and infrastructure is laid out, running a shoddy (perhaps conspiratorial) business might actually be the optimal path -- and that's where we need a solution.
    - Johnie 12y ago
      If you lose my money that I trusted in your startup, I would file a lawsuit. Whether or not the law is murky, you'll be tied up in legal issues for a long time. Even if the law says you're not legally liable (unlikely), your legal fees would put you in a world of hurt for a long time. When you're transacting in something of value (whether that be money, digital currency, or pokemon cards) for your users, you better be sure to take it seriously.
      - dogecoinbase 12y ago
        So, if providers were responding correctly to incentives in the Bitcoin exchange marketplace, they'd be both ignoring security, and making themselves difficult to find or identify. Got it.
panarky 12y ago
When you build something that stores or transfers money, you will attract adversaries. These adversaries will have more skill, more time, and more tenacity than you do. Knowing this threat environment, what will you do differently from the dozens exchanges that have come before you and failed?
stcredzero 12y ago
NASA code than startup technical-debt code I have a friend who ported then maintained critical software at NASA about almost decade ago. He said that introducing source control was viewed as "a radical idea" at the time. Also, management seemed to go with superstition and "truthiness" as far as making decisions. "If it ain't broke, don't fix it" was the management mantra. (I would reveal the piece of software he was working on, but that would easily reveal his identity.)
- cordite 12y ago
  I refer to modern but rigorous NASA development practices, from design to verification.
- EpicEng 12y ago
  "If it ain't broke, don't fix it" is probably a good mantra to have when your code can kill people.
  - stcredzero 12y ago
    But when you have discovered that your code is logically or mathematically inconsistent, you really need a better justification for leaving it than, "Well, it's worked so far." That's exactly the kind of thinking that resulted in both shuttle disasters, and that's exactly the kind of thing my friend faced from management. Now hardware: The NASA hardware guys who showed up to the Houston hackerspace always really impressed me. (But what do I know? I'm a software guy.)
    - EpicEng 12y ago
      Sure; I suppose it comes down to your definition of "broken". I would consider inconsistent results broken and, as you say, a thorough analysis should be performed to assess the impact. I was thinking more along the lines of "I don't like this code, let's refactor". That can be dangerous.
      - stcredzero 12y ago

Seems like whoever writes financial code in the future should treat it more like NASA code than startup technical-debt code.

by cordite 12y ago

Seems like whoever writes financial code in the future should treat it more like NASA code than startup technical-debt code.

ryan-allen 12y ago

This is true if you intend on running an exchange properly and not being a highway robber posing as a travelling dentist.

panhandlr 12y ago
Exactly... From my perspective, their plan worked perfectly. 1. Open an exchange. 2. Collect real money in exchange for fake money. 3. "Get hacked" losing all the fake money and keeping all the real money.
- im2w1l 12y ago
  Yeah, "We noticed the hot wallets dwindling but assuming it was members moving their funds off site during the DDOS, we loaded all the cold balances onto the site" sounds extremely suspicious.
  - Mtinie 12y ago
    Possiblely, but in light of the protracted duration of the DDoS, it makes sense that people would be moving their holdings off-exchange when they could connect. If the withdrawal addresses were all different -- and from what Excoin posted on their site it looks like the party responsible used multiple BTC and NBT addresses to move the funds -- multiples of small to moderate amounts of coins being requested doesn't sound out of the question. In retrospect, it was a horrible decision not to research these transactions in depth as they happened, but the Excoin team was fighting a "bigger" fire at the time with the DDoS.
- brighton36 12y ago
  Which one is the fake money, USD or btc?
rodgerd 12y ago
Sufficiently advanced criminality is indistinguishable from gross stupidity, apparently.

trupedo 12y ago

But are the customers willing to pay a significant premium price for the development effort of NASA-ized exhange? If the answer is no (and I suspect it is), then incentives are aligned so that putting extra effort into security is something an exchange operator should definitely not do. All of this is also assuming (on faith) that the business model is actually running an exchange, as opposed to a hack-blaming racket.

Johnie 12y ago
If you believe this, you shouldn't be handling people's money. It's not just about losing the bitcoin, people running these exchanges may be personally liable.
- trupedo 12y ago
  > It's not just about losing the bitcoin, people running these exchanges may be personally liable. The law is still very murky here, and there are plenty of ways to deflect responsibility. I'm not saying any of this is right, I'm suggesting that the way our culture and infrastructure is laid out, running a shoddy (perhaps conspiratorial) business might actually be the optimal path -- and that's where we need a solution.
  - Johnie 12y ago
    If you lose my money that I trusted in your startup, I would file a lawsuit. Whether or not the law is murky, you'll be tied up in legal issues for a long time. Even if the law says you're not legally liable (unlikely), your legal fees would put you in a world of hurt for a long time. When you're transacting in something of value (whether that be money, digital currency, or pokemon cards) for your users, you better be sure to take it seriously.
    - dogecoinbase 12y ago
      So, if providers were responding correctly to incentives in the Bitcoin exchange marketplace, they'd be both ignoring security, and making themselves difficult to find or identify. Got it.

panarky 12y ago

When you build something that stores or transfers money, you will attract adversaries. These adversaries will have more skill, more time, and more tenacity than you do. Knowing this threat environment, what will you do differently from the dozens exchanges that have come before you and failed?

stcredzero 12y ago

NASA code than startup technical-debt code I have a friend who ported then maintained critical software at NASA about almost decade ago. He said that introducing source control was viewed as "a radical idea" at the time. Also, management seemed to go with superstition and "truthiness" as far as making decisions. "If it ain't broke, don't fix it" was the management mantra. (I would reveal the piece of software he was working on, but that would easily reveal his identity.)

cordite 12y ago
I refer to modern but rigorous NASA development practices, from design to verification.
EpicEng 12y ago
"If it ain't broke, don't fix it" is probably a good mantra to have when your code can kill people.
- stcredzero 12y ago
  But when you have discovered that your code is logically or mathematically inconsistent, you really need a better justification for leaving it than, "Well, it's worked so far." That's exactly the kind of thinking that resulted in both shuttle disasters, and that's exactly the kind of thing my friend faced from management. Now hardware: The NASA hardware guys who showed up to the Houston hackerspace always really impressed me. (But what do I know? I'm a software guy.)
  - EpicEng 12y ago
    Sure; I suppose it comes down to your definition of "broken". I would consider inconsistent results broken and, as you say, a thorough analysis should be performed to assess the impact. I was thinking more along the lines of "I don't like this code, let's refactor". That can be dangerous.
    - stcredzero 12y ago