Bitcoind : not quite ready for prime time

Friday, 01 March, Year 5 d.Tr. | Author: Mircea Popescu

The large "BFL will fail" bet closed earlier today on BitBet. Leaving aside the various historical implications and such considerations, let us focus on the technical side of things for a moment.

The 135 bets made produced a total of 79 winners. Since some people made multiple bets with the same beneficiary address this all condenses to a total of 70 addresses that need to be paid their winnings. This can be easily enough arranged into a sendmany commandi to be fed to bitcoind.

The response ?

error: {"code":-4,"message":"Transaction creation failed"}

That is possibly the least helpful error message in the history of unhelpful error messages. Not because it's much worse than Windows' patented "An unspeficied error has occurred", but because Bitcoin is so very much more important than Windows ever was or could ever aspire to be.

So what's one to do ?

I'll spare you the googling, since all that'll net is people having the exact same problem with no solution whatsoever forthcoming, and skip directly to the whats and wherefores.

Bitcoind is poorly written, in two respects. One is that it fails to correctly pick the most adequate inputs to feed into a given list of outputs. The process it uses could perhaps be best described as "randomly selects some inputs". Since that "random" approach uses a fixed seed this works no better overall than any possible alternative. Literally, any alternative. If you're lucky your tx goes through, if not you get a -4, as if it were your fault.

The other is that it contains some unspecified limits which appear to be hardcoded. I haven't spent the time and resources to go hunt for the exact limits, but it appears quite plainly that bitcoind would not allow me to create a 1 Mb transaction. Inasmuch this is true it is also The Wrong Thing. As long as the block limit is 1 Mb the ability to create 1 Mb transactions belongs to me and strictly to me, as the end user. If I can afford to pay enough in fees - which I can - then it's nobody's business but mine.

The practical way this problem was eventually resolved was by excluding the largest two transactions from the sendmany. The remainder 68 payments were made without a problem, as part of a 3436 byte txii which took 0.0005 in fees. The smallest of the two large payments, for 517.24339527 BTC also was made without a problem, through a 2777 byte txiii that actually took no fees at all. Somehow strangely enough it's okay to send two transactions, one of 2777 bytes and the other of 3436 bytes paying an aggregate 0.0005 fee, but it's NOT okay to send a single 6k tx paying the same. This doesn't make any sense whatsoever, and if we consider the fact that a large section of the bitcoin dev hangers-on periodically bitch and whine about how "Satoshi Dice is breaking Bitcoin" things suddenly become very amusing.

What's your ideal world, ye wise men, a place where people don't divide txs to atomic size and don't aggregate them to actual size but simply do what ? What you yourselves do ? How about "Satoshi Dice couldn't merge tx's anyway because bitcoind is written by monkeys" ? I dunno, I'm no miner, I'm no coder, I'm just sayin'. And seeing how what I happen to be sayin' happens to be backed by the only thing that matters, and the only thing that gives Bitcoin its substance and its purpose (ie moneyiv) a pretty sensible thing would be to sit down, shut up and get crackin'.

And in that state of mind, we move on to the largest of the excluded transactions. It couldn't be made unless split up into two transactions, one for 310 and change and the other for 400. The 310 and change part went fine, the 400 part didn't, so it had to be further split into two 200 halves. This sort of shit does not wash.

Fix the motherfucking code before you have to be fired. To recap : a. If I want to make 1 Mb txs I make 1 Mb txs ; b. correct inputs are selected to feed the outputs as if a human or better was doing the selecting.

  1. Next time you're about to say "Bitcoin is anonymous" think about the circumstance that I've just published for the entire world to see the Bitcoin payment details of an entire slate of people. Strangely enough this creates no problem for them. Do you wonder why that is ? []
  2. fead082c83a0625eb8cc22452b7f213d7be041e29a7d2c203e704b01ec6bb04b []
  3. c6258eff0639d758015ed5dcdd8a1f1dcf7580ac833d52336b6ec4469f9281b5 []
  4. No, it's not minds. We have plenty of those, and they're rarely worth more than a bullet. No, it's not ideas, the world is awash in ideas. No, it's not code, nor people nor immortal souls or any of that bullshit. Money. Only and strictly money. []
Category: S.BBET
Comments feed : RSS 2.0. Leave your own comment below, or send a trackback.

8 Responses

  1. Old story is old.

  2. Mircea Popescu`s avatar
    Mircea Popescu 
    Friday, 1 March 2013

  1. [...] Bitcoind : not quite ready for prime time [...]

  2. [...] Bitcoind : not quite ready for prime time [...]

  3. [...] in mind that Bitcoin always was and to this day remains not ready for prime time, which specifically means that it is not a mature or even reliably usable (or even extant, because [...]

  4. [...] option then requires that most of the work involved transaction creation (importantly - the coinbase selection!) will be done by the node, which is definitionally a low security environmentiv. What's worse, the [...]

  5. [...] ACTUALLY WAS A WAY for "bitcoin community" on tardstalk to impress me. just as there was a way, years ago, for "bitcoin developer community" to impress me. that these doors successively close doth not mean [...]

  6. [...] option then requires that most of the work involved in transaction creation (importantly - the coinbase selection!) will be done by the node, which is definitionally a low security environmentiv. What's worse, the [...]

Add your cents! »
    If this is your first comment, it will wait to be approved. This usually takes a few hours. Subsequent comments are not delayed.