When I feel like it.  Probably early tomorrow.  Lets say I won't decide until 2012.06.16 11:00 GMT.

Not quite what I was looking for, but thanks.  I'm looking for something simple that shows decently at 32x32 which I think will require the subjects to be redrawn in cartoon style.

f59a644a49b0a1d91d243dfeedb1973dc10a211cd1ec3289efe9b274d3302d25

I need 16 small graphics created. I have example images of each of what I am looking for roughly.

Here is how I'd like to work this. The first image is a llama. I want it in a simple cartoonish style. It needs to be png with a transparent background and 32x32.

Here is a model image, showing the pose I want. I just want the llama, no background.

http://img.1209k.com/e996d81bb03a4b9a29e6405e8a424ad2.jpg

Send me your submissions. If I like it, I hire you and give you the rest of the list of items. If it is a solid entry but I don't like it I'll send you 0.5 BTC and thank you for your time. If it is not a solid entry, I'll thank you for your time. (Entirely my decision). Please sent bitcoin address with submissions and post submissions on thread for everyone to enjoy.

I'll of course want to do a little back and forth revising the images but I'm not very picky and will do my best to not waste anyone's time.

Looks like it was processed fine with the payment in the next block.  However, it wan't processed until it was confirmed because the software ignores unconfirmed transactions with a fee less than 0.0005.

It looks like the software saw that TX but there was some bug relating to it being included in an orphan chain as well as the main chain.  I'll look into that.  In the mean time, it is processing now.

It is actually max(0.0005, (ins + outs) * 0.000075) so is fairly stupid but is higher for larger transactions.

Code is here: http://code.google.com/r/fireduck-magicpony/source/browse/core/src/main/java/com/google/bitcoin/core/FeeFinderCounting.java

Thank you for your careful and considered estimation of the time it will take to implement a feature in my code, which I am almost certain you have never seen.  I will treasure it always.  

Hi, I am the programmer working on SatoshiDice.

We are absolutely interested in being good bitcoin citizens and doing things in a good and efficient way.  However, changing to handling many bets with a single transaction is a complicated change for us.  It is certainly doable but has to be done carefully because making sure people get paid properly and accountably is our business.  It will also make it confusing for our users.  Right now seeing that they payment was correct is simple.  They see one output to their address of the correct amount and one output to one of our change addresses.  If we combine transactions, they will see a ton of outputs to various addresses.  It gets even more confusing is the same address is getting payments from multiple bets in the same transaction (which will be a common use case, people bet a bunch at once often).

Of course none of that is a deal breaker.  We can do it, but it will likely be a little while before I can get the code in and tested.  I'll also have to think about making improvements to our UI to help users make sense of what they will see in these big transactions.

I suspect there has been some confusing between cloudfront and cloudflare.  I've never heard of cloudflare.  Cloudfront is Amazon's CDN product which SatoshiDice website is hosted on.

And we have set a new record for us today.  We have had over 30,000 bets today and still a good chunk of an hour left in the day (GMT days).

Previous high was 19,000 on June 4th.

The problem you are having is that Satoshidice ignores any transaction with a fee of less than 0.0005 until it is confirmed.  Based on my experience that many of these never confirm and we would rather not tie up outputs on them if they are doomed.

For example, blockchain.info shows that last one as "Estimated: Never": http://blockchain.info/tx-index/8969893/ff6a2dedc9fd31194806ba8aec7236d32cd4666a5b77fcdc7e01d38bb3cb3b72

Right now we have about 4500 unconfirmed.  I have yet to figure out any coherent way of predicting when the miners will pick these up.

Agreed.  I'll work on that. 

Over 21,000 bets already today.  Everything seems to be flowing fine now except for about 600 unknowns which I am working on clearing up now.  They should be gone in the next 4 hours or so.

Sorry, that was a database change I made.  I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets.  It should be much better now.  I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us.

Ok, so do to some bad transactions that never confirmed a bunch of downstream transactions chained off those got hosed.  Then some things I did made it worse.

Today I've completed rebuilding our transaction database and gotten things to a clean state.  Right now the system is offline while we wait to see which of our payment transactions actually confirm.  Then I'll restart processing and any payments that haven't been confirmed will be recreated and everything will return to some semblance of proper.

Sorry about all the trouble.  I've been working on this part time so some of my solutions haven't had the full rigor I'd like to give things.

However, I think we are making solid progress on being more stable and available.  The last week prior to this weekend were pretty good.

Anyone with unpayed bets of transactions that never showed up, please be patient.  Everything will get paid as it should.

Note: I expect processing to be restarted around 15:00 GMT.

Yeah, a few bets that never confirmed came in last night.  That is fine until we run out of confirmed funds and start paying with pendings that never confirm.

Anyways, everything will get paid eventually.  I'm invalidating payments that aren't going anywhere and recreating them with different inputs.

Sorry for the delays.

Ok, returning from a dive into whatever this insanity is.

http://blockchain.info/tx-index/4611323/5d34b39c5e531e939801ff573553189d9f6ee417b1ce053dbb29d6474c263619

Take a look at this, a normal transaction.
In the script inputs section there are two elements:
3045022100a22956219bfb38b6f89eeaecd7c1bf3626efbd13fb53a4bf694f613cfcb493c202206 dbe153a64cc05f017a0e4e3070780ae1ce00ca22c45699c1f825a1da0e7cbbc01 04550138da91fd693ac9865af4d3412d5f03f776a50e852f348b270402946e5079ce3a8a6b5cb40 2a181439151e1453da6d75b515c86ddf9f34206dffeff32a46e

The second one, that starts with 0455 is the public key.  It is pretty important.

Now take a look at our favorite transaction:
http://blockchain.info/tx-index/6712457/a96a3cc6284df89c4d670722e6c2705b7d3709673be8e7207c53e02f35220d45

It just has one element:
30450220239628fbc434ac378f1f0f52d02ec0004e8d0ae930467eee649daabaf210e409022100b 3d836a99f48b9bec9136c77efc4dd9721924ab291df4fca33006095ad2d04a101

Now this is probably valid.  Blockexplorer and Blockchain.info seem to understand it but my BitcoinJ implementation does not.  In fact, it misunderstands is so hard that it isn't know it is misunderstanding it and hashes the entire input script as if it is the public key.  So that produces an address so my software goes on fine and pays that address, which no one has the key to.

I have my software now ignoring any such transactions that it sees.  This isn't optimal but at least it prevents them from being paid to the wrong address.

I hope in the next few days some people in the BitcoinJ development circle can shed some light and I can put in a real solution.

In the mean time I will pay out nelisky separately to make that right and run a program to see if there were any more of these.

I think this was caused because the output in question was fresh from a mined block and had the output in the older OP_CHECKSIG style.

http://blockchain.info/tx-index/6313254/55eacb8699a780561ca42012a3ea47e2eab100d01f89a18749666a94bc88938e

However, I could easily be misunderstanding what is going on there.

Transaction: a96a3cc6284df89c4d670722e6c2705b7d3709673be8e7207c53e02f35220d45
  UpdateTime: Thu May 24 14:56:48 PDT 2012
  Inputs:
    in:0 <- 55eacb8699a780561ca42012a3ea47e2eab100d01f89a18749666a94bc88938e:1
      1K6UuRxtomeyGhYsTCXq9HdRDQVMDPQeEe
      [72]30450220239628fbc434ac378f1f0f52d02ec0004e8d0ae930467eee649daabaf210e409022100b 3d836a99f48b9bec9136c77efc4dd9721924ab291df4fca33006095ad2d04a101

So Blockexplorer and blockchain.info say 1MgH8iNkdZrDW8rsfzifDzsqJnCjBVyRBV
My software says 1K6UuRxtomeyGhYsTCXq9HdRDQVMDPQeEe

The input script is identical. Very strange.