I know that output 0 of transaction cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35 was already claimed, but this post triggered me to experiment with manually constructing transactions.

Here is a piece of code that uses bitlib and bccapi to build the exact same transaction:
http://code.google.com/p/bccapi/source/browse/trunk/bccapi/src/com/bccapi/ng/example/CustomBuiltTransaction.java

Here is the gist:
   public static void main(String[] args) throws ScriptParsingException, MalformedURLException, ApiException {
      // Build transaction input
      Sha256Hash txHash = new Sha256Hash(
            HexUtils.toBytes("cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35"));
      OutPoint outPoint = new OutPoint(txHash, 0);
      ScriptInput si = ScriptInput.fromScriptBytes(new byte[] { 1, Script.OP_FALSE, Script.OP_DROP });
      TransactionInput ti = new TransactionInput(outPoint, si);

      // Build transaction output
      Address receiver = Address.fromString("1LqTjBzMRdXQqXpRQo1zDYRiUobAVS55Lo", NetworkParameters.productionNetwork);
      ScriptOutput so = new ScriptOutputStandard(receiver.getTypeSpecificBytes());
      TransactionOutput to = new TransactionOutput(99950000, so);

      // Build transaction
      Transaction tx = new Transaction(1, new TransactionInput[] { ti }, new TransactionOutput[] { to }, 0);
      System.out.println("Our transaction hash: " + tx.getHash().toString());

      // Broadcast transaction (here we depend on the BCCAPI server, you can use
      // whatever API you like for this)
      URL url = new URL("http://bqs1.bccapi.com:80");
      BitcoinClientApi api = new BitcoinClientApiImpl(url, NetworkParameters.productionNetwork);
      BroadcastTransactionResponse response = api.broadcastTransaction(new BroadcastTransactionRequest(tx));
      System.out.println("Broadcasted transaction with hash: " + response.hash.toString());
   }


Hope you find it useful.

I saw this post yesterday just before going to bed and was going to claim it first thing in the morning (was dead tired), now it is taken. You snooze you loose 

From the BitcoinSpinner announcement thread:
For those of you who are using the raw BCCAPI there will be a little integration work to get to the next generation. The good news is that:
1. The new API is simpler and more powerful, as it allows you query on any Bitcoin address
2. The old API will continue to work for a month or so.

Look for bitlib and bccapi here: http://code.google.com/p/bitcoinspinner/source/browse/#svn%2Ftrunk
bitlib is a self-contained Java library for dealing with transactions (creating, parsing wire-format, signing, ...)
bccapi builds on top of that and connects to a server etc, so if you don't like that you can still use bitlib

There is a brand new version of the ASCII based SimpleClient showing how to use it here: http://code.google.com/p/bitcoinspinner/source/browse/trunk/bccapi/src/com/bccapi/ng/example/SimpleClient.java

I haven't updated the official BCCAPI page yet, but I am working on it.

BitcoinSpinner v0.8.0b is out. You can download/upgrade it from the Google Android market (god know why, but they call it Google Play these days), or fetch it directly from the project site. The differences may seem subtle, but it is backed by 1 1/2 months of hard full time work where most of the time has been spent on the backend system.
User visible changes:
 - Even faster: The next generation BCCAPI is simpler, has fewer lines og code, requires fewer server roundtrips during startup, while being as secure as before.
 - In addition to displaying "coins on the way to you" on the main screen it also displays how many coins you are currently sending.
 - Transaction history color coded to make it easier to distinguish receives and sends
 - Transaction history now displays the address you received coins from instead of displaying which address you received the coins with.
 - Better error messages when trying to spend your last coins while you cannot afford the miner fee.

BitcoinSpinner is now backed by another version of the BCCAPI, which makes it much easier to manage multiple redundant servers as they no longer need to share anything but the block chain.  I will maintain backwards compatibility with version 0.7.3b for about a month, leaving people time to upgrade, whereafter I'll scrap the old server. This allows me to manage multiple redundant copies of the new backend, which has been requested by several.
 
Enjoy

Thanks for the link, I'll give it a spin.

Yes, absolutely, there is a lot of time and effort in producing a sound paper. I think some people (Tony, Steve, vink vink) have a lot at stake on accepting zero-confirmation transactions. I am merely trying to get something rolling 

Thank you for the producing and publishing this paper (sent you a donation). We need much more of this kind of work. I would really like to see more academic papers on Bitcoin.

A couple of questions/thoughts:

Are you considering to publish this elsewhere, submitting it as a conference paper?
Are you associated with a university or an old graduate like myself?

The paper describes probabilities of doing double-spending attacks where the attacker has some amount of hashing power. To have a significant probability of a successful attack he would need quite a bit of hashing power as todays hash rate is quite high. I believe that such an attack would be costly, and only feasible for high value transactions.
However, there are many merchants today who accept zero-confirmation transactions using merchant solutions such as BitPay (Tony, Steve, correct me if I am wrong).

So assuming that the attacker has no hashing power at all, how easy would it be to mount a double-spending attack against a zero-confirmation accepting merchant? And what can you do to detect a zero-confirmation double spend attack or avoid to accept the transaction if a double-spend is happening?

So basically the attacker broadcasts two conflicting transactions (T1 and T2) and hopes that T1 reaches the merchant while T2 reaches as many miners as possible.

I see two ways of protecting against this attack with some probability of success:

1. Listen to the network for a few seconds and see how well T1 propagates: Since nodes will not relay T2 if they have seen T1 you should receive fewer transaction inventory broadcasts containing the hash of T1 than what you would normally receive. The better you are connected to the network the more material you have to base your decision on.

2. When you receive T1 you listen for a conflicting transaction for a few seconds. If you find one there was a double-spend attempt. This sounds simple, but since nodes do not relay T2 if they have seen T1 you only receive T2 if you have connections to nodes that received T2 before T1. The more connections you have the higher probability there is of you getting T1 and T2.

There may be other smarter ways of detecting/preventing zero-confirmation double-spends, but this is what I came up with. However, the above raises some questions:

• On a network of N nodes, how many nodes should you be connected to in order to have probability P of getting both T1 and T2?
• How long time should I listen to the network for approach 1 and 2?
• Within what margin should the "propagation-level" be for me to have probability P that the transaction is not a double-spend?

So here is my suggestion: If you write a paper of the same quality on this topic and answer some of the above questions I'll donate 5 BTC to you for your effort. I could imagine that BitPay and others would be interested in your analysis as well.

X=Wallet Y=reorganize()

Details and fix sugestion  posted here: http://code.google.com/p/bitcoinj/issues/detail?id=257

Sorry couldn't help it 

I applaud Grau for doing all this work. I don't get the logic of withholding known bugs. If you don't want to help this is fine, but claiming that you found a bug, you just don't want to tell about it, is silly at best. We had a similar situation a year back or so where an alt-coin developer claimed to have found a bug in the satoshi-code, he just didn't want to tell Gavin (sorry can't find the reference).

Grau, maybe you should see if you can find a bug in BitcoinJ so you have something to trade with  
(Jan tries to dodge the flames)

Congratulations. Sounds amazing.
To use the services mentioned, debit card etc, do I have to live in the EU, or France, or is it available to everyone?

Being an offline client like the one I outlined does not require much memory. 32 bytes for a private key and roughly 100 bytes for each unspent transaction output and 500 bytes for each full transaction, or something along those lines. You can go far with 1Mb flash memory which is nothing these days. I think we will see them within the next year or so if the market demands it. The tricky part is to make it sufficiently tamper resistant (not android phones) and cheap.

To be honest, if there is an internet blackout I believe there are more pressing problems than spending coins. At least for me.

However, let's assume that you have a secure hardware device with built-in radio, that allows you to communicate securely (short distance, authenticated communication) with another device of the same kind, and that device does not allow you to export/import private keys. Then you could do multiple secure transactions from device to device for days or months before finally syncing up with the network.

This could be useful in areas without mobile coverage, such as most of rural US

Rural Area United States

I would rather see export private key functionality.
I believe that the needle is pointing in a direction where users migrate to alternative clients. Let's make the transition easier. I know that they can just move the funds elsewhere, but many users have sent the corresponding addresses to other users/web-sites and/or use vanity addresses.
Also, exporting a key is much much easier, no need to have Bitcoin-QT rescan the block chain.

Centralization.

I believe that Charlie and Erik are in Macau or travelling back to the US.

Grats to Slush

At least... behind one of those 700 monitors sit 3 people

You should display the address as a QR-code as well, this makes it much easier to pay by phone. You can make the QR-code contain both the address and amount to pay. This makes it super easy for the end user.
Extra credit if you make both the address and QR-code a clickable bitcoin URL. This allows you to launch your favorite wallet by just clicking the QR-code/URL.

I don't have a down-time percentage, but it has been low. There have however been two giltches the last two days. This should be fixed now.

Block tracking stalled for some reason. It is currently catching up, I'll look into the reason why.

Erik, great article. You convinced me.
I think the culprit is that they are afraid of endorsing Bitcoin. They are depending too much on donations from people that believe that Bitcoin is drug money. The Wordpress news will hopefully steer the needle in the right direction for us.
Keep up the good work.