Bitcoin Forum
May 19, 2019, 03:48:18 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: [SUCCESS] Double Spend against a satoshidice loss  (Read 18829 times)
Vitalik Buterin
Sr. Member
****
Offline Offline

Activity: 331
Merit: 337


View Profile
December 18, 2012, 11:11:18 AM
 #41

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)?

Argumentum ad lunam: the fallacy that because Bitcoin's price is rising really fast the currency must be a speculative bubble and/or Ponzi scheme.
1558280898
Hero Member
*
Offline Offline

Posts: 1558280898

View Profile Personal Message (Offline)

Ignore
1558280898
Reply with quote  #2

1558280898
Report to moderator
The Man Behind
Pokémon
&
Yu-Gi-Oh
brands
Collect!
Trade!
Play!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558280898
Hero Member
*
Offline Offline

Posts: 1558280898

View Profile Personal Message (Offline)

Ignore
1558280898
Reply with quote  #2

1558280898
Report to moderator
1558280898
Hero Member
*
Offline Offline

Posts: 1558280898

View Profile Personal Message (Offline)

Ignore
1558280898
Reply with quote  #2

1558280898
Report to moderator
Yuhfhrh
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
December 18, 2012, 11:38:49 AM
 #42

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.  Cheesy 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
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1008


View Profile
December 18, 2012, 01:33:22 PM
 #43

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.

Quote
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
Sr. Member
****
Offline Offline

Activity: 396
Merit: 259


View Profile
December 19, 2012, 06:02:32 PM
 #44

Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.  Cheesy 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
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
December 19, 2012, 09:33:55 PM
Last edit: December 19, 2012, 10:10:25 PM by Yuhfhrh
 #45

Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.  Cheesy 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. Tongue
paybitcoin
Member
**
Offline Offline

Activity: 85
Merit: 10


1h79nc


View Profile WWW
December 20, 2012, 05:19:46 AM
 #46

Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.  Cheesy 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. Tongue

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. Smiley

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
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
December 20, 2012, 06:55:01 AM
 #47

Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.  Cheesy 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. Tongue

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. Smiley

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!  Smiley
Gyrsur
Legendary
*
Offline Offline

Activity: 2198
Merit: 1140


#BEL+++


View Profile WWW
December 22, 2012, 09:39:25 AM
 #48

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.

███████████
██
██
██
██
██
██
██
██
██
██
██
███████████
#1
███████████
██
██
██
██
██
██
██
██
██
██
██
███████████
BTC 
  ●
   BTC
  BTC  
.
    ▄▄▄▀▀▀▀
 ▄██▀
███        ▄▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄▄▄
▀███▄▄▄▄▀▀▀                 ▀▀▄▄
  ▀▀▀██████████████████████████▀
   ▄█▄     ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
    ▀▀██▄▄█▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀▀
      ▄  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
      ▀██▄  ▄▀▀▀▀▀▀▀▀▀▀▀▀▄
        ▀█▀██████████████▀▀
         ▀█▄▄ ▄▄▄▄▄▄▄▄▄▄
            █▀▄▄▄▄▄▄▄▄▄▄▀
             ▀▀▄▄▄▄▄▄▄
.
     BTC
  BTC   
  ●
  BTC  
███████████
██
██
██
██
██
██
██
██
██
██
██
███████████
███████████
██
██
██
██
██
██
██
██
██
██
██
███████████
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
December 24, 2012, 05:00:22 AM
Last edit: December 26, 2012, 02:42:15 AM by etotheipi
 #49

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
usagi
VIP
Hero Member
*
Offline Offline

Activity: 812
Merit: 1000


13


View Profile
December 31, 2012, 07:43:42 AM
 #50

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
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
January 05, 2013, 08:10:54 AM
 #51

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
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
January 17, 2013, 05:34:05 PM
Last edit: January 17, 2013, 05:54:49 PM by etotheipi
 #52

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

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
mskwik
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
January 17, 2013, 06:12:02 PM
 #53

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
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1008


View Profile
January 18, 2013, 10:20:46 AM
 #54

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
Full Member
***
Offline Offline

Activity: 125
Merit: 100


View Profile
January 18, 2013, 02:29:02 PM
 #55

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
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1008


View Profile
January 20, 2013, 07:16:47 PM
Last edit: January 24, 2013, 05:10:49 PM by Mike Hearn
 #56

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
Hero Member
*****
Offline Offline

Activity: 743
Merit: 500



View Profile
January 29, 2013, 02:33:27 PM
 #57

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

Supporting people with beautiful creative ideas. Bitcoin is because of the developers,exchanges,merchants,miners,investors,users,machines and blockchain technologies work together.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428
Merit: 1005


Core Armory Developer


View Profile WWW
January 30, 2013, 01:38:50 AM
 #58

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


Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
dooglus
Legendary
*
Offline Offline

Activity: 2590
Merit: 1126



View Profile
January 30, 2013, 03:12:01 AM
Last edit: January 30, 2013, 03:34:50 AM by dooglus
 #59

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:

Quote
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.


Just-Dice                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   Play or Invest                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   1% House Edge
dooglus
Legendary
*
Offline Offline

Activity: 2590
Merit: 1126



View Profile
January 30, 2013, 04:07:45 AM
 #60

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:

Quote
30 46 02 21    00da2f0d0925960b1c8cb87fc04e02ddfd8cb6cfa947c656e652d1fb315ef66db5022100a494956 71a1f6f86520a126780f980a6fee0e22943143527cca38b3f489704f401 04090871c9bb80ebcd923d8e8b76194085afc9d417831545b4380cacc02dc2214966eea799a3d04 a2098c12d76aab3bbd95d94ec985094a71830e2bb739a255788
and
Quote
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.

Just-Dice                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   Play or Invest                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   1% House Edge
Pages: « 1 2 [3] 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!