[SUCCESS] Double Spend against a satoshidice loss

[Vitalik Buterin]

One idea I had to help mitigate this is that SatoshiDice could immediately re-send the output of any transaction that they receive to themselves with a fee, encouraging miners to quickly confirm both the new transaction and its parent over any conflicting transactions.

Two questions:

1. Can a transaction reference an unconfirmed transaction as an input? If so, can the two appear in the same block? I'm pretty sure the answer is yes to the first, but I'm not sure about the second.

2. Do miners actually work that way? Does a fee on a transaction also encourage miners to include its (possibly feeless and even non-standard/bloated) parent? If not, are there any obstacles / reasons not to implement such a strategy (with appropriate rules so you can't use one transaction to force miners to include 1000 bad ones, obviously)?

[1714163081]

1714163081

[1714163081]

1714163081

[1714163081]

1714163081

[1714163081]

1714163081

[1714163081]

1714163081

[1714163081]

1714163081

[Yuhfhrh]

One idea I had to help mitigate this is that SatoshiDice could immediately re-send the output of any transaction that they receive to themselves with a fee, encouraging miners to quickly confirm both the new transaction and its parent over any conflicting transactions.

Two questions:

1. Can a transaction reference an unconfirmed transaction as an input? If so, can the two appear in the same block? I'm pretty sure the answer is yes to the first, but I'm not sure about the second.

2. Do miners actually work that way? Does a fee on a transaction also encourage miners to include its (possibly feeless and even non-standard/bloated) parent? If not, are there any obstacles / reasons not to implement such a strategy (with appropriate rules so you can't use one transaction to force miners to include 1000 bad ones, obviously)?

First off, thanks for writing an article on this! I appreciate it!
Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.   If I receive more than 1.5BTC, further funds will be used for more double spending attempts.

1. The answer is yes to both.
2. I don't believe it works that way. As long as miners are following the standard rules, sending a transaction 999 times with no fee and then sending the last with a 1BTC fee will not affect the previous 999 transactions. Each transaction is based on it's own fees.

[Mike Hearn]

1. Can a transaction reference an unconfirmed transaction as an input? If so, can the two appear in the same block? I'm pretty sure the answer is yes to the first, but I'm not sure about the second.

Yes and yes.

2. Do miners actually work that way? Does a fee on a transaction also encourage miners to include its (possibly feeless and even non-standard/bloated) parent? If not, are there any obstacles / reasons not to implement such a strategy (with appropriate rules so you can't use one transaction to force miners to include 1000 bad ones, obviously)?

Fees are not considered recursively at the moment. They should be and there are patches open to do that. I think Gavin is planning to merge some of that work soon (i hope?)

[nibor]

Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.   If I receive more than 1.5BTC, further funds will be used for more double spending attempts.

I think Satoshidice owe you a reward. I am surprised that they do not offer a standard 10 BTC reward to anyone who posts a proven double spend on this forum.

[Yuhfhrh]

Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.   If I receive more than 1.5BTC, further funds will be used for more double spending attempts.

I think Satoshidice owe you a reward. I am surprised that they do not offer a standard 10 BTC reward to anyone who posts a proven double spend on this forum.

Well they don't owe me a reward. Also I could have won BTC instead of losing during these tests.

[paybitcoin]

Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.   If I receive more than 1.5BTC, further funds will be used for more double spending attempts.

I think Satoshidice owe you a reward. I am surprised that they do not offer a standard 10 BTC reward to anyone who posts a proven double spend on this forum.

Well they don't owe me a reward. Also I could have won BTC instead of losing during these tests.

Funny that you mention that, since in the process of testing your method I ended up 5 BTC ahead... I think I'm obligated now to cover your loss, so I'll share the winnings.

I couldn't pull off the double spend, but I only got 1 or 2 reasonable tests in. They do take quite a long time to execute.

[Yuhfhrh]

Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.   If I receive more than 1.5BTC, further funds will be used for more double spending attempts.

I think Satoshidice owe you a reward. I am surprised that they do not offer a standard 10 BTC reward to anyone who posts a proven double spend on this forum.

Well they don't owe me a reward. Also I could have won BTC instead of losing during these tests.

Funny that you mention that, since in the process of testing your method I ended up 5 BTC ahead... I think I'm obligated now to cover your loss, so I'll share the winnings.

I couldn't pull off the double spend, but I only got 1 or 2 reasonable tests in. They do take quite a long time to execute.

Thanks, I really appreciate it! 

[Gyrsur]

Anyone who wants to test double spends is free to try it on the test site:

http://1209k.com/testdice/

I'll be doing some of my own testing.

this testdice is located in prodnet?? what it the sense of that?

a testdice should be located in testnet with exactly the same parameters as in prodnet.

[etotheipi]

Anyone who wants to test double spends is free to try it on the test site:

http://1209k.com/testdice/

I'll be doing some of my own testing.

this testdice is located in prodnet?? what it the sense of that?

a testdice should be located in testnet with exactly the same parameters as in prodnet.

I agreed with this statement at first, but I think it will be difficult to trigger on testnet -- the makeup of the network and the miners is significantly different.  You probably don't have the same density and diversity of peers needed to do it -- you need significant propagation of each tx in the subnetworks of nodes that are willing to accept it and mine it.

Not to say it can't be done, I just think the attack will manifest differently on testnet.  

On the upside, anyone succeeding on the test site might make a few tenths of a BTC for their effort.

[usagi]

DISCLAIMER: The following post shows the risk with accepting bitcoin transactions with no confirmations. This could not have been done if the transaction had a confirmation.

This was pure genius. Thank you for your contribution to science.

[Yuhfhrh]

I still haven't confirmed if sending a spammy transaction with the standard 0.0005 BTC fee where a normal fee of ~0.01 would be required and double spending it would work or not. I haven't had the time to try, but this should theoretically work under their new rules unless satoshidice checks to make sure the standard fee is paid, and not just the 0.0005.

[etotheipi]

I can't believe I posted in the wrong thread!  

A couple days ago, I observed a pretty large, successful, double spend against SD (25 BTC).  Please see my post in the statistics thread.  I have raw data if anyone wants to analyze it.  

It is not related to the vulnerability retep posted.  But it does look like a miner may have helped them.

tl;dr:  

The original bet, B, was made using an input from transaction A.  A was 7 kB and had 43 inputs.  I don't know what the transaction fee was (but I all zero-conf tx I received that entire day with timestamps, so all this information could be reconstructed... I can make it available to anyone who wants to dig into it).

Transaction A never made it past zero-conf, and was replaced by a block with transaction A'.  Thus, bet B was invalidated.  The curious part is that A' was 14 kB, with 83 inputs, and paid zero fee!.  14kB is clearly over the allowFree limit, thus it would only be accepted (even without a conflicting tx in the memory pool) by a miner with non-standard rules.  Now given that there was a public, conflicting transaction... hmmm

[mskwik]

The original bet, B, was made using an input from transaction A.  A was 7 kB and had 43 inputs.  I don't know what the transaction fee was (but I all zero-conf tx I received that entire day with timestamps, so all this information could be reconstructed... I can make it available to anyone who wants to dig into it).

Transaction A never made it past zero-conf, and was replaced by a block with transaction A'.  Thus, bet B was invalidated.  The curious part is that A' was 14 kB, with 83 inputs, and paid zero fee!.  14kB is clearly over the allowFree limit, thus it would only be accepted (even without a conflicting tx in the memory pool) by a miner with non-standard rules.  Now given that there was a public, conflicting transaction... hmmm

It seems possible that A' was submitted first (directly to any miner that would accept it) and didn't propagate over the rest of the network because of the lack of fee.  Then A and B could be submitted normally and make it to the rest of the network (except for any miners that already had the conflicting transaction).  The tricky part would be trying to affect who found the next block after seeing the bet outcome.  With enough hashing power you could point at one pool or another you could push the odds around somewhat but it would seem to be far from a sure thing, it wouldn't however necessarily require collusion from any mining pools directly.

[Mike Hearn]

OK, a Finney attack against SD, nice.

BTW does anyone know if Eclipse publishes the list of blocks they solved anywhere? I couldn't find such a list on their site. If Eclipse did solve it, then I guess Inaba needs to examine how A' got into his memory pool.

Miners that are accepting direct submissions of transactions that would normally fail to relay really should be ensuring those transactions don't conflict with any in the memory pool, and if they see a broadcast transaction that would double spend a direct submission, should take the broadcast transaction as having priority.

Is it possible to send a tx that wouldn't normally relay to a node, but still get it accepted into the nodes memory pool? I thought the code did not allow that, but maybe I'm wrong.

It seems worth investigating this in more detail.

[mskwik]

Is it possible to send a tx that wouldn't normally relay to a node, but still get it accepted into the nodes memory pool? I thought the code did not allow that, but maybe I'm wrong.

Well if the tx was accepted by the pool in the first place it would have to be running some custom software.  I assume it would try and relay it normally but it would only be accepted by peers that were following the same relaxed rules as itself.  I have played with nonstandard transactions in the past sending them through Eligius to get mined and it does seem that though they are accepted and eventually end up in a block that I do not see them get propagated very far elsewhere on the network before being mined.  I assume that it would work fairly similarly for transactions with fees below minimum.

[Mike Hearn]

I turns out the issue is that Inaba excluded 1dice transactions from the memorypool on his node due to some crashing issue. I'm not sure if he realized this opens SD to double spends or not, but at any rate, it's not deliberate collusion so actually exploiting it is difficult.

Edit: the issue was apparently fixed and it was actually a deadlock, not a crash.

This is one aspect of using fixed addresses I suspect fireduck did not consider. Using static addresses like that not only makes his books entirely open, but allows people to selectively exclude his traffic. I'm not sure what the crash issue was, but if it wasn't possible to isolate his transactions there may have been more motivation to find a real fix.

[World]

something is wrong to many double spend addresses
https://blockchain.info/double-spends

[etotheipi]

I was doing some Armory testing last night and shutdown Bitcoin-Qt ... meaning my double-spend detection script was disconnected... What timing!  <facepalm>

However, I turned it on this morning and was able to catch some excitement at 2:44pm EST -- a bunch of bets total 613 BTC was invalidated (at least from where I'm sitting in the network).

This invalidation was a straight zero-conf replacement (no replacing tx on which it was depending).  This is all the information I have... the first one is the transaction that was invalidated (containing 613 BTC to SD), and the second one is the one that replaced it, looks to be similar... probably just a "re-roll":

Code:

Transaction:
   TxHash:    54825a1963a0fc4b566cd415690986c835a84974ceb00ae3649ed311a39d2a2e (BE)
   Version:   1
   nInputs:   15
   nOutputs:  9
   LockTime:  0
   Inputs: 
      PyTxIn:
         PrevTxHash: e7b58ff78217d9c2dbf1241caf5fe4fcd92e0d2513377a172fd045549fcdc98f (BE)
         TxOutIndex: 0
         Script:     (493046022100c9f4ebda0ef6a9cdfbec47395f6f9003db03fa6a1e988f6cf6c6)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 73ed5c2ebb46b065ce60e8032dbb302ca35844a422efe97c4e51a899b0f7b5d4 (BE)
         TxOutIndex: 0
         Script:     (483045022100eed323557e4c64468bbc6ea29127d7cc32174040abb1fad80e6f)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 7b22d93449f68c77e983e3293a9f7e2ff1d168cd38fe583e59fcb9f48920c2ee (BE)
         TxOutIndex: 0
         Script:     (47304402200b219204a17742c08b33f010273d8587d92e4250b785c20c202ada)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 3b3d950b16804433a6c51ee20b7f2cbf960c29d4f4f807d4401cf7ecbd129b5d (BE)
         TxOutIndex: 0
         Script:     (483045022100fb3c5b09df5f7ee08fd67a48f100bab72b98caca0627d38f27c5)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 0f2e75cd762a29e99833cd74cfb0146e8e0c9da154c28e3fe3f93b4ae07fb6ff (BE)
         TxOutIndex: 0
         Script:     (493046022100ef1b39f1c8e9a9cfea3078a9b84b14aa28e767f8d68e4f0350e1)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: d4bb36bc35374261d09fa9f1b32c30be42eeb7a1b6e065ad49f69ca90f82c9e3 (BE)
         TxOutIndex: 0
         Script:     (483045022048cdb8f317f34cd1ed2aa0f70233ed900ba09b530b7c45fb1756bd)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 673523e82a5522e43495806675fd55827551d19967717de7614a7cb1604ae11c (BE)
         TxOutIndex: 0
         Script:     (483045022100aac3d77c8aea7226d4ce907f3545d1c45dfa3b0e0218679a52df)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: d28f2ab759e302242c3364e2b3942b4f8726db582305df80deb5933ede6cb3ec (BE)
         TxOutIndex: 0
         Script:     (47304402201d26918c38b1200b3b8e3902fdc91ad0adc578b6d5cda1f30c94a7)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: b43aed06284a97a1977bc6f5f523e175dae220a7e3ea2bae79350279df2e396d (BE)
         TxOutIndex: 0
         Script:     (493046022100d461c1df9eb08a237f7fac396ed5ff4497ed2a6019b00a10b282)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: b593b0e4f026f0fa384dc821ffe4a70f567f55696ff509f4b0fa7e148b354815 (BE)
         TxOutIndex: 0
         Script:     (493046022100f35d2b1e7a695df93402d3dcdce356bc0e6d510d2fc437726508)
         Sender:     1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 747969dcc31ea6c3ed01bf7a1c970d50d7dacb885068f8e03b464a5abdfa5e44 (BE)
         TxOutIndex: 0
         Script:     (4730440220704b975e73a8ceb2cff37580ea867a7a792b61b3762bae34092237)
         Sender:     1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: e15cddae2f36bbf27045bba9aa0eede24e30e733a83bb4a2214d31a74731cdbd (BE)
         TxOutIndex: 0
         Script:     (47304402205be446e867d43b884756217bc6e1bd414354ad7d1ffbb6ae0b9f51)
         Sender:     1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 3865e1176077e06eca8089bcc49691d22c285a7499564723041104baff1de558 (BE)
         TxOutIndex: 8
         Script:     (48304502206cedfbaf681a98c827445ef33851154dc16dda797a906cd2732e3e)
         Sender:     1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 204f7599883588e752578988bc43cb7572010ecd25fe8a34dba7ffdaadf592db (BE)
         TxOutIndex: 8
         Script:     (493046022100d2e46f587078fd6de62172908b5eb2962ea64dae3b6eb96e0a3e)
         Sender:     1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 30a8ed895212e2f7f18e67526ae37fbbdf9562017892f79ff8459226be627994 (BE)
         TxOutIndex: 8
         Script:     (493046022100bc7b0681e2ba82ad4f89e83fd21e1a94c6fb402de13cea22fb55)
         Sender:     1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV
         Seq:        4294967295
   Outputs: 
      TxOut:
         Value:    10000000000 ( 100.0 )
         Script:   OP_DUP OP_HASH (1dice97ECuByXAvqXpaYzSaQuPVvrtmz6) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    10000000000 ( 100.0 )
         Script:   OP_DUP OP_HASH (1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    25000000000 ( 250.0 )
         Script:   OP_DUP OP_HASH (1dice7W2AicHosf5EL3GFDUVga7TgtPFn) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    10000000000 ( 100.0 )
         Script:   OP_DUP OP_HASH (1dice7fUkz5h4z2wPc1wLMPWgB5mDwKDx) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    5000000000 ( 50.0 )
         Script:   OP_DUP OP_HASH (1dice7EYzJag7SxkdKXLr8Jn14WUb3Cf1) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    1000000000 ( 10.0 )
         Script:   OP_DUP OP_HASH (1dice6YgEVBf88erBFra9BHf6ZMoyvG88) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    200000000 ( 2.0 )
         Script:   OP_DUP OP_HASH (1dice6DPtUMBpWgv8i4pG8HMjXv9qDJWN) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    100000000 ( 1.0 )
         Script:   OP_DUP OP_HASH (1dice5wwEZT2u6ESAdUGG6MHgCpbQqZiy) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    15215213996 ( 152.15213996 )
         Script:   OP_DUP OP_HASH (1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ) OP_EQUAL OP_CHECKSIG

Code:

Transaction:
   TxHash:    47bfb18624d0f1ed09e895fe427dcd9a3cef709d92ccedd48528b7774e8f7e23 (BE)
   Version:   1
   nInputs:   15
   nOutputs:  9
   LockTime:  0
   Inputs: 
      PyTxIn:
         PrevTxHash: e7b58ff78217d9c2dbf1241caf5fe4fcd92e0d2513377a172fd045549fcdc98f (BE)
         TxOutIndex: 0
         Script:     (00493046022100c9f4ebda0ef6a9cdfbec47395f6f9003db03fa6a1e988f6cf6)
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 73ed5c2ebb46b065ce60e8032dbb302ca35844a422efe97c4e51a899b0f7b5d4 (BE)
         TxOutIndex: 0
         Script:     (483045022100eed323557e4c64468bbc6ea29127d7cc32174040abb1fad80e6f)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 7b22d93449f68c77e983e3293a9f7e2ff1d168cd38fe583e59fcb9f48920c2ee (BE)
         TxOutIndex: 0
         Script:     (47304402200b219204a17742c08b33f010273d8587d92e4250b785c20c202ada)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 3b3d950b16804433a6c51ee20b7f2cbf960c29d4f4f807d4401cf7ecbd129b5d (BE)
         TxOutIndex: 0
         Script:     (483045022100fb3c5b09df5f7ee08fd67a48f100bab72b98caca0627d38f27c5)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 0f2e75cd762a29e99833cd74cfb0146e8e0c9da154c28e3fe3f93b4ae07fb6ff (BE)
         TxOutIndex: 0
         Script:     (493046022100ef1b39f1c8e9a9cfea3078a9b84b14aa28e767f8d68e4f0350e1)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: d4bb36bc35374261d09fa9f1b32c30be42eeb7a1b6e065ad49f69ca90f82c9e3 (BE)
         TxOutIndex: 0
         Script:     (483045022048cdb8f317f34cd1ed2aa0f70233ed900ba09b530b7c45fb1756bd)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 673523e82a5522e43495806675fd55827551d19967717de7614a7cb1604ae11c (BE)
         TxOutIndex: 0
         Script:     (483045022100aac3d77c8aea7226d4ce907f3545d1c45dfa3b0e0218679a52df)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: d28f2ab759e302242c3364e2b3942b4f8726db582305df80deb5933ede6cb3ec (BE)
         TxOutIndex: 0
         Script:     (47304402201d26918c38b1200b3b8e3902fdc91ad0adc578b6d5cda1f30c94a7)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: b43aed06284a97a1977bc6f5f523e175dae220a7e3ea2bae79350279df2e396d (BE)
         TxOutIndex: 0
         Script:     (493046022100d461c1df9eb08a237f7fac396ed5ff4497ed2a6019b00a10b282)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: b593b0e4f026f0fa384dc821ffe4a70f567f55696ff509f4b0fa7e148b354815 (BE)
         TxOutIndex: 0
         Script:     (493046022100f35d2b1e7a695df93402d3dcdce356bc0e6d510d2fc437726508)
         Sender:     1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 747969dcc31ea6c3ed01bf7a1c970d50d7dacb885068f8e03b464a5abdfa5e44 (BE)
         TxOutIndex: 0
         Script:     (4730440220704b975e73a8ceb2cff37580ea867a7a792b61b3762bae34092237)
         Sender:     1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: e15cddae2f36bbf27045bba9aa0eede24e30e733a83bb4a2214d31a74731cdbd (BE)
         TxOutIndex: 0
         Script:     (47304402205be446e867d43b884756217bc6e1bd414354ad7d1ffbb6ae0b9f51)
         Sender:     1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 3865e1176077e06eca8089bcc49691d22c285a7499564723041104baff1de558 (BE)
         TxOutIndex: 8
         Script:     (48304502206cedfbaf681a98c827445ef33851154dc16dda797a906cd2732e3e)
         Sender:     1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 204f7599883588e752578988bc43cb7572010ecd25fe8a34dba7ffdaadf592db (BE)
         TxOutIndex: 8
         Script:     (493046022100d2e46f587078fd6de62172908b5eb2962ea64dae3b6eb96e0a3e)
         Sender:     1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
         Seq:        4294967295
      PyTxIn:
         PrevTxHash: 30a8ed895212e2f7f18e67526ae37fbbdf9562017892f79ff8459226be627994 (BE)
         TxOutIndex: 8
         Script:     (493046022100bc7b0681e2ba82ad4f89e83fd21e1a94c6fb402de13cea22fb55)
         Sender:     1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV
         Seq:        4294967295
   Outputs: 
      TxOut:
         Value:    10000000000 ( 100.0 )
         Script:   OP_DUP OP_HASH (1dice97ECuByXAvqXpaYzSaQuPVvrtmz6) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    10000000000 ( 100.0 )
         Script:   OP_DUP OP_HASH (1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    25000000000 ( 250.0 )
         Script:   OP_DUP OP_HASH (1dice7W2AicHosf5EL3GFDUVga7TgtPFn) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    10000000000 ( 100.0 )
         Script:   OP_DUP OP_HASH (1dice7fUkz5h4z2wPc1wLMPWgB5mDwKDx) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    5000000000 ( 50.0 )
         Script:   OP_DUP OP_HASH (1dice7EYzJag7SxkdKXLr8Jn14WUb3Cf1) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    1000000000 ( 10.0 )
         Script:   OP_DUP OP_HASH (1dice6YgEVBf88erBFra9BHf6ZMoyvG88) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    200000000 ( 2.0 )
         Script:   OP_DUP OP_HASH (1dice6DPtUMBpWgv8i4pG8HMjXv9qDJWN) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    100000000 ( 1.0 )
         Script:   OP_DUP OP_HASH (1dice5wwEZT2u6ESAdUGG6MHgCpbQqZiy) OP_EQUAL OP_CHECKSIG
      TxOut:
         Value:    15215213996 ( 152.15213996 )
         Script:   OP_DUP OP_HASH (1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ) OP_EQUAL OP_CHECKSIG

[dooglus]

I mentioned these apparently double spends here.  The guy owing these transactions had a pretty unlikely winning streak overnight.

the first one is the transaction that was invalidated (containing 613 BTC to SD), and the second one is the one that replaced it, looks to be similar... probably just a "re-roll":

The two transactions are apparently almost identical.  All the inputs and outputs are the same (except for the first input script, which starts with an extra 0 byte in the 2nd transaction).  It looks like the same transaction was just slightly modified, re-signed and re-sent.

As a result, your formatting of the transactions shows no 'sender' for the 1st input of the 2nd transaction:

Code:

Transaction:
   TxHash:    54825a1963a0fc4b566cd415690986c835a84974ceb00ae3649ed311a39d2a2e (BE)
[...]
   Inputs: 
      PyTxIn:
         PrevTxHash: e7b58ff78217d9c2dbf1241caf5fe4fcd92e0d2513377a172fd045549fcdc98f (BE)
         TxOutIndex: 0
         Script:     (493046022100c9f4ebda0ef6a9cdfbec47395f6f9003db03fa6a1e988f6cf6c6)
         Sender:     1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
         Seq:        4294967295
[...]

Code:

Transaction:
   TxHash:    47bfb18624d0f1ed09e895fe427dcd9a3cef709d92ccedd48528b7774e8f7e23 (BE)
[...]
   Inputs: 
      PyTxIn:
         PrevTxHash: e7b58ff78217d9c2dbf1241caf5fe4fcd92e0d2513377a172fd045549fcdc98f (BE)
         TxOutIndex: 0
         Script:     (00493046022100c9f4ebda0ef6a9cdfbec47395f6f9003db03fa6a1e988f6cf6)
         Seq:        4294967295
[...]

Edit: http://blockchain.info/tx-index/47564468 confirms that the first input script starts with an OP_FALSE, but of course that doesn't matter because the rest of the script is pushed on top of it on the stack.  The OP_FALSE will still be on the stack when the script finishes executing, but, according to the wiki, "A transaction is valid if nothing in the combined script triggers failure and the top stack item is true", so the buried OP_FALSE doesn't matter.

[dooglus]

I see three more pairs of double-spends from the same wallet:

75c39711ab8dee9fd6c6b166c17b6a12209d472990b230c0bb2ce0d8bd0fb248 and c651661bbe39c1dabe52892fce8eeef8932ba349392b64b5848167e683128cd4,

87d222fcee789576195fd524b22f84e1562d241e67bbc3e971b4d6659da0be91 and c97a74b8ba7edacc72f2be39a05a0ff2b8821ec87e16fb400458d8d6ff8086d4

28be43a55c9a88e11254094be7486e6c6db9d6c73bd352bbfea0f9abc5e33170 and 5a9c49c118e1655b511b76a0cb2978f4b5ebe7773a938664ecf304b5c35a9ee7.

In each pair, the two transactions are identical except that the first input script is one byte longer in the 2nd of the pair.  For instance, in the first pair we see input scripts:

30 46 02 21    00da2f0d0925960b1c8cb87fc04e02ddfd8cb6cfa947c656e652d1fb315ef66db5022100a494956 71a1f6f86520a126780f980a6fee0e22943143527cca38b3f489704f401 04090871c9bb80ebcd923d8e8b76194085afc9d417831545b4380cacc02dc2214966eea799a3d04 a2098c12d76aab3bbd95d94ec985094a71830e2bb739a255788

and

30 47 02 22 00 00da2f0d0925960b1c8cb87fc04e02ddfd8cb6cfa947c656e652d1fb315ef66db5022100a494956 71a1f6f86520a126780f980a6fee0e22943143527cca38b3f489704f401 04090871c9bb80ebcd923d8e8b76194085afc9d417831545b4380cacc02dc2214966eea799a3d04 a2098c12d76aab3bbd95d94ec985094a71830e2bb739a255788

So the input wasn't even re-signed.  The old signature was simply left-padded with an extra zero byte, changing the txid.