SERIOUS VULNERABILITY related to accepting zero-confirmation transactions

[piuk]

You know, I actually performed this attack, and quite successfully steal a few Bitcoins worth of a service from a site. I don't know what safeguards the site happened to have, but it's not implausible that I could have made off with thousands. (the site has been fixed)

The limit for a single unconfirmed transaction is ~10 BTC and ~25 BTC simultaneous unconfirmed paid out at any one time. There have been two double spends in 6 months, both using methods mentioned in this thread.

[1713852328]

1713852328

[1713852328]

1713852328

[1713852328]

1713852328

[1713852328]

1713852328

[1713852328]

1713852328

[Peter Todd]

From a site that swaps unconfirmed coins for confirmed coins. That is not at all the majority of merchants.

The limit for a single unconfirmed transaction is ~10 BTC and ~25 BTC simultaneous unconfirmed paid out at any one time. There have been two double spends in 6 months, both using methods mentioned in this thread.

sigh... I didn't want to mention what exactly who I exploited precisely because the network is public.

I don't understand why you assert that the attacker doesn't need a bunch of machines. They still need to mine.

You sure you understand the attack? You don't need to mine at all to pull it off. Email me if you want further clarification.

Only confirmation is persuasive evidence of eventual confirmation.

This is circular.

No it's not. Because clients validate all transactions in blocks against the same rules whether the tx is in the most recent block, or how ever many blocks back, the rules for confirmation are the rules for subsequent confirmation. The rules for every single node on the network are exactly the same; if they aren't you get a network split.

On the other hand there is no single set of rules that decides if a transaction will get into a block in the first place; that's up to miners and the relay-rules of the network itself and every miner and every node can, and does, have somewhat different rules they operate by. Some miners ignore satoshidice tx's, other miners ignore zero fee tx's; it's all over the place.

What we have with the Bitcoin community today is people using APIs that don't make it easy to do accurate risk analysis. Of all transactions, not just unconfirmed. For instance the current best practice is to wait some number of blocks before considering a transaction "done" but the actual hardware cost of mounting an attack doesn't depend on the number of blocks, it depends on how difficult those blocks were to create (yes, I'm oversimplifying a bit). So really sites should think about confidence in terms of gigahashes of work done, but in practice no sites actually do. I've tried to support this kind of approach in bitcoinj, where you can query any wallet transaction to find out how much work has been done on top of it, but I never had time to really push this idea.

I'm not one of the core dev's, so maybe they think otherwise, but I'm pretty sure they'd agree that building API's to allow zero-conf transactions to be accepted "safely" sounds like a world of hurt. It's a moving target for one thing as attacks are discovered, and in addition the best ways of detecting them can't be done unless you have access to many different nodes to do network propagation measurement.

If you want to allow zero-conf tx's to be accepted safely, start a service to do so. Have staff that maintain this service, do constant risk analysis and continual threat detection, and if you have good reason to believe your counter-measures are adequate, offer insurance on transactions using the service. It's not a new idea, but there isn't anyway doing it right now as far as I know, so maybe you can make it work?

Putting this functionality in the satoshi client just leads people to believe the functionality works properly. It'll just lead to more examples of people getting defrauded, and we don't need that.

So it's up to us, the community, to build APIs that ensure users can use Bitcoin safely.

The API's already let you use Bitcoin safely: just don't accept unconfirmed transactions.

Like I said, I'll post the full details in a week or two. As you note yourself, not every site can be contacted manually. Besides anyone who wants to can figure out what you're talking about just by looking at recent changes to various client apps anyway.

It'd be nice of you to ask the core-devs and other members of the community about when is right to release the full details. In addition, when that time comes, I think it'd also be nice to let me do it.

[MatthewLM]

No they do not remove the risk of fraud, Steve just clarified that they do not. And bitcoin does not have chargebacks. BitPay hasn't removed that, bitcoin has. The problem is with 0-conf transactions.

You're cute and all but I was talking about CC chargeback. I'm saying the promise of BitPay to merchants is to eliminate CC chargeback risks (by using an alternative payment system obviously).
Of course you can accept BTC without BitPay, but not every internet merchant wants to know about Bitcoin, or understands it enough to feel comfortable accepting them themselves.

Well, for sure BitPay might be useful for transfers to a bank account but I'm talking about merchants that want payment in bitcoin. Why use a middle-man when you can directly use bitcoin? Bit-Pay offers bitcoin transfers for 0.99%.

BitPay has misrepresentation in their promotional material: "With Bitpay you can eliminate the risk of Fraud" This is false.

You could say BitPay offers software solutions that do not exist elsewhere, but that is completely redundant as soon as anyone creates a open-source merchant software that suports bitcoin.

[Kris]

No they do not remove the risk of fraud, Steve just clarified that they do not. And bitcoin does not have chargebacks. BitPay hasn't removed that, bitcoin has. The problem is with 0-conf transactions.

You're cute and all but I was talking about CC chargeback. I'm saying the promise of BitPay to merchants is to eliminate CC chargeback risks (by using an alternative payment system obviously).
Of course you can accept BTC without BitPay, but not every internet merchant wants to know about Bitcoin, or understands it enough to feel comfortable accepting them themselves.

You could say BitPay offers software solutions that do not exist elsewhere, but that is completely redundant as soon as anyone creates a open-source merchant software that suports bitcoin.

Not really no.

I feel obligated to inform that many places use zero-confirmation in one way or another. BitPay and WalletBit is no exception.

But imagine this from a customers point of view, they do not want to stand in the store waiting 1 minute or more for a confirmation, so therefore we have to let the mobile checkout (point of sale) use 0 confirmation to display payment done notification to the customer as soon as we register the payment, even if this poses a risk for the merchant.

At the same time from the merchants point of view they will still have to wait 6 confirmations for the payment to arrive in their account and be transferred as bitcoin payment to their own wallet or as bank transfer to their local bank account. We do have issuance if a finney attack or other takes place by a "customer" out in a store using Mobile Checkout (See it here), but then again this is very unlikely to happen unless they got remote access to a setup at "home" able to do the attack.

As far as eCommerce or online shops, there really is no risk in accepting bitcoin via WalletBit or BitPay, since both system sends out a Instant Payment Notification when a defined bitcoin confirmation number have been reached.

Here it is up to the merchant if he wants quick notification of payment or very safe with no risk at all = 6 confirmations. It is as simple as setting your Notification in your account to High, Medium or Low in your WalletBit business tools, I think the same goes for BitPay in one's account.

In the end if we could iron out every attack involving zero-confirmation that would of cause be the way to go, but I can say right away that this won't happen, there will always be a loophole to find if you search enough.

[paybitcoin]

Yes, I'd think it is similar to the process of paying with a check at the grocery store. The store takes the signed piece of paper that promises that the bank will deliver them the money. You can still drive home really fast and withdraw all of your money from your account, rendering your earlier check useless to the store.

The same way banks deal with this kind of fraud (with verifying proof of identity when presenting the check, check-scanning machines that can talk to the bank to verify the check, and of course real legal liability for bounced checks) will definitely come to Bitcoin as well at some point. I can definitely see the case where merchants may only accept co-signed transactions from big payment providers, so they can have someone to sue when the funds don't come in.

[zvs]

can anyone tell me where all these 0 fee blocks spamming my logs are coming from?

i already got rid of the 2 IPs it's showing as relaying on blockchain

i guess i need to add IPs to transactions in source too =/

2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees ee1a7973ffe7f2515f6c12526b90f6255ca13bbe776e082bf0178d65663eeba9
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f0b511b75aa9aa442434a59765b98b4fd2756524fd8f9c2b11f5c888bde9958f
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f0d0a79791b5b78a022331a6389297e3eee9b9f3034c878d8c6cee2412691571
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees efb77fc35a8a6bc33e5c58b284e81be2b353874cb13838ff4c74ca51b5ba793c
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees efbdc9e1a1bf3a3c7fd3132cb777431ffa73d6fc836e1d1b70489cdccdfeac6c
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f0543537bb137ae02c5eefb93dc5d362623ba8480e1563b4937aca5013da5854
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f1c34730e5a0940c65e4a0b37cc2d1fce9ce0f1c730d3de0b5e005d0f0b4db7f
2013-01-15T10:56:09 ERROR: CTxMemPool::accept() : not enough fees f74b022b82f9a3e1d0f0515b05e85564bfa07ad0c9e6ace89b2ce7f2752011b6
2013-01-15T10:56:14 ERROR: CTxMemPool::accept() : not enough fees cf540360acbdcdf6afa58ee2adec991301d4ba992e2be242071087b45f05be93
2013-01-15T10:56:14 ERROR: CTxMemPool::accept() : not enough fees d3c90dbdde9eec6063571cd0236d6bfd142a373d65e25f4fa3e975ace446e524
2013-01-15T10:56:15 ERROR: CTxMemPool::accept() : not enough fees d8543699b679c45cd36705f025c54d3039a1ed2dfb63466c193b320dec5e400f
2013-01-15T10:56:15 ERROR: CTxMemPool::accept() : not enough fees d9286580caabcfecaa67904cd217207e92885ed71c37ec4377336bda0c23e207
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees ee399a5e806540e0fd1bc1d46f37a34ce74a6811550dc5f5683c2bf5028443b2
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f0115ef694c04dcbc48068755498a6d5158d316380459f096bae8f7724227176
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f026656b07abc5708d06e763583f56e3cc9124dde85e2ddad1ee724d5645c1db
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f39996eb7d6a45f9193daf58ca5f20d378c81eb0598746fd5e1cd692658709fb
2013-01-15T10:56:16 ERROR: CTxMemPool::accept() : not enough fees f6b3421a3b01240ed9d7744350ebf00bfd0b966e991b98d02da7b83d5596ea69
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cddf3a1683d1429b6e85da4f96039041fb42bd12e36766720db95eafd0235b7a
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ce7c0dbfa5d2a89787a62d9d1473fe60662622fa6d14d93dcfdb460e7f92b15d
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cfe8b131f8d24bcb97a32367724991667ddc077c2ae0f84b6f4b3c37a04e37b4
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d744f1bb7049f720f7913b2bc43e763aeabb069bce156262463f436e7daca37d
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dbfd6af1f0a106d3abbf110f445031e1988fe810088bcf110d2a865983d5b928
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ccebe83aa809a3f5446398f0e5449803f71b55e635143e83edcf451e25e84b20
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cd6d323d755e65efa638bc6157c89bc88b6cacc8b5181d438e36ec28bb7426a3
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ce1f54c78b8f3e0ebe04fafbd5c6d5c46aab92e4e4d13ef1a6832a223154fe18
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees ce32ad556d883d3df90ac3463f94e854fe9d3e016bfcf603d1c0e00fddac2043
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cf233c426e941967014cd118cbf70c38186e3da5f17629b37863e97d676d8f8d
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cf5c391b229c6d0d59580bd894ccfcd42811ee4a5a456a6648c9bcdd7b34e9ac
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees cf91339258163883e1747cf48c54590542f7acbe7f8a2aba527752398c360baa
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d0d2edd026073b8e548623be491ffd5acf57d4db454a9c041a4cb56a726308de
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d0ea334244eca1dc51ed875959a126434ec70368dd62059961a8fb704449dfe3
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d1ef53d215ce4620790af274e8374410121837db59d099b311829dd51fb21070
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d2878c33afaa8023e2695bff2c83586068cc447ddaf684705ce10bb07cf193b7
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d2d21775d847bf1f8b0819c30f4acdaa24e4b1067012de6f2109f93e1d0daac7
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d302d1a7354fdddd120c5582a14d86b5a04ca678ddb730eae665a6bc90872a32
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d56cdda9a4d2006814affe057bc4edb2d7adec39bb62faf54b8f557e93ea7870
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d5d02daa5e19f5f7c4d037d60949bc6cbd0cc52e49f80cbd1409f7973269f07e
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d71fa20523418f39c6908545401c6a85c95bf254cb00c955887bcdeabfaeaa56
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees d83b16d1400497a17ed1d1a9fe1c2cce4a5f9bf55dae1832d3755b39ee7f2a77
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees db009790fe3f7416dc97b43212aaa847b151c81c24c972610aa3d36951ab47a1
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dbd43f0addf1a654ac8965a49f99f7e013dd78294a3fc66848738e8b0b90f1d9
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dc3f7b3515416ec6fec66b6c47fac7d822a03abadc0794c6de58afe21f561b2b
2013-01-15T10:56:17 ERROR: CTxMemPool::accept() : not enough fees dc5b696042870930d58b4351f7e088bd51a2ae3863d86946d2e7bf3f17e8571a

and so on

[Jan]

They are not related to the vulnerability discussed in this thread.
Your bitcoin node is complaining about transactions that do not meet the minimum relay fee. So basically what it tells you is that it will not forward the transactions to other nodes in the network. These transactions may however still reach a miner and get included in a block as some nodes have other relay policies and/or are connected directly to a miner who includes any transaction regardless of fees. This is for instance the case with the first one on your list: ee1a7973ffe7f2515f6c12526b90f6255ca13bbe776e082bf0178d65663eeba9

[zvs]

They are not related to the vulnerability discussed in this thread.
Your bitcoin node is complaining about transactions that do not meet the minimum relay fee. So basically what it tells you is that it will not forward the transactions to other nodes in the network. These transactions may however still reach a miner and get included in a block as some nodes have other relay policies and/or are connected directly to a miner who includes any transaction regardless of fees. This is for instance the case with the first one on your list: ee1a7973ffe7f2515f6c12526b90f6255ca13bbe776e082bf0178d65663eeba9

I think they are related, in that someone was trying to exploit (or test) it.  I mean, why else would you throw around 20 .000082 transactions at once?

I know how the relay works.  I'd like to designate these transactions as 'misbehaving', but not with a huge 24hr ban, more like 1hr.  I'll probably change it in my client later.

http://blockchain.info/ip-address/78.47.187.253

They start at 2013-01-15 10:40:03 and end at 10:58, about 400 in total, on that IP.  There was one other German node that was getting some first and also a UK node.

http://blockchain.info/address/1Ct8vwFzpWGzUyNagYUyV6NFP5cjBNkgoW       or      http://blockchain.info/address/18dzWGn9wMHA46GmBFRNgwrT3yJneKaKkA


entirely unrelated

[libertaad]

We had temporarily disabled zero-confirmation deposits at bitZino, but we have now re-enabled them thanks to Mike Hearn's help. We've also added a series of additional anti-fraud checks in order to ensure our risk from a double-spend attack is minimal. As always, we only allow withdrawals back out of our site after a deposit has received multiple confirmations.

I'd really like to thank retep and Mike for their responsible disclosure and help in getting this issues resolved. We've tipped each of you 5 BTC as a way to say thanks from bitZino for helping us operate our business in a secure manner.

[Peter Todd]

I'd really like to thank retep and Mike for their responsible disclosure and help in getting this issues resolved. We've tipped each of you 5 BTC as a way to say thanks from bitZino for helping us operate our business in a secure manner.

Thanks! Glad to help.

[phelix]

still no details? you got me curious...

[meebs]

well... duh?

Who would have thought it was a good idea to consider a transaction complete if a guy claims to have sent you funds but they haven't actually been verified as legit by ANYONE yet?

[ErebusBat]

still no details? you got me curious...

Take a look at bitcoin magazines website.

[Luke-Jr]

still no details? you got me curious...

Take a look at bitcoin magazines website.

The article does not cover the vulnerability this thread is about.

I'm sure disclosure will come in time.

[Mike Hearn]

For what it's worth, I'm working on changes to bitcoinj so that apps built on that library are protected from this and related issues. It's not done yet but making progress. I'm not sure if anything is being done to the main C++ client.

[Gavin Andresen]

The reference implementation patch is scheduled for the (real soon now!) 0.8 release:
  https://github.com/bitcoin/bitcoin/pull/2223

[nelisky]

And diceoncrack fell on to this attack, it seems... https://bitcointalk.org/index.php?topic=138988.0

I have a requirement that isn't satisfied on the 0.8 series, an effect of the leveldb implementation. I need to be able to read raw tx for non wallet transactions, and these are no longer kept, so for now I can't update. I think that there are only two things I can do at this point; don't accept 0 confirmation wagers without fee and make sure the coins used on the wager tx are already on a block. Had I these measures in place the attack would have failed.

That or simply not take 0 confirmation wagers, of course.

If anyone need details about this attack let me know, I can dig the transactions that got rolled back.

[Luke-Jr]

I have a requirement that isn't satisfied on the 0.8 series, an effect of the leveldb implementation. I need to be able to read raw tx for non wallet transactions, and these are no longer kept, so for now I can't update.

This will be fixed in 0.8 (though require you to use a new option the first time you start it).

[Peter Todd]

And diceoncrack fell on to this attack, it seems... https://bitcointalk.org/index.php?topic=138988.0

I have a requirement that isn't satisfied on the 0.8 series, an effect of the leveldb implementation. I need to be able to read raw tx for non wallet transactions, and these are no longer kept, so for now I can't update. I think that there are only two things I can do at this point; don't accept 0 confirmation wagers without fee and make sure the coins used on the wager tx are already on a block. Had I these measures in place the attack would have failed.

Luke is correct above, and you can also simply apply the patch Gavin posted to your 0.7 bitcoind src. I've tested this before - I wrote a slightly different version of the patch a few weeks ago - and it worked fine.

If anyone need details about this attack let me know, I can dig the transactions that got rolled back.

I'd be very interested to know; there are many variations of this attack.

[nelisky]

This particular attack we endured doesn't seem to be related to lockntime, as far as I can tell. The coins are originally sent back and forth across a few addresses a few times in small values and finally they get aggregated in one address like A (http://blockchain.info/tx-index/46601326/e586b0cfa885c5fc8960205a9bfec228dc0dfa496c04b20172c66d1f9760076d) and B (http://blockchain.info/tx-index/46646986/2076b8e5be0fcaed6e6652ea2a89a45d755462764f852e3e3b9fcda3bb035e3e).

One vout from each of A and B (18 and 1 is one particular example) are then aggregated into C, which is then bet on Martingale at DoC with tx D. The long chain of tx without any fees takes a long time to get confirmed by the network and somewhere along the line C is replaced by another Tx, completing the double spend.

The now rolled back transactions C and D were:

Code:

{
"hex" : "0100000001f677169e7a5739be1e4c462e88fb1cc394a4ea061e4a1defc1f4d0e4e4aca9cf000000008b483045022100a086c038850b5f683abec9f04a43b2408b698cbd31d24e716f92737c114a9ee7022043b1f928c7f57d905260a0faf0b8f307e111f5f6566ccbc9f15961abcb8c9a4d014104e168f0402da84fafc564594cb18abf720567cbc58b118caf6698298d0f34404cfd784c30cf49dc18e0eabf58301791170e8db56ff792ca78470f15045a501bdcffffffff016a48c323000000001976a9142ddfe9616ddf358d81546a3a18034fc88b34965688ac00000000",
"txid" : "2b1cecb3046e1f951dfb0237b6318ce3685585e14d1541938d08b1c56e2ae6c0",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "cfa9ace4e4d0f4c1ef1d4a1e06eaa494c31cfb882e464c1ebe39577a9e1677f6",
"vout" : 0,
"scriptSig" : {
"asm" : "3045022100a086c038850b5f683abec9f04a43b2408b698cbd31d24e716f92737c114a9ee7022043b1f928c7f57d905260a0faf0b8f307e111f5f6566ccbc9f15961abcb8c9a4d01 04e168f0402da84fafc564594cb18abf720567cbc58b118caf6698298d0f34404cfd784c30cf49dc18e0eabf58301791170e8db56ff792ca78470f15045a501bdc",
"hex" : "483045022100a086c038850b5f683abec9f04a43b2408b698cbd31d24e716f92737c114a9ee7022043b1f928c7f57d905260a0faf0b8f307e111f5f6566ccbc9f15961abcb8c9a4d014104e168f0402da84fafc564594cb18abf720567cbc58b118caf6698298d0f34404cfd784c30cf49dc18e0eabf58301791170e8db56ff792ca78470f15045a501bdc"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 6.00000618,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 2ddfe9616ddf358d81546a3a18034fc88b349656 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9142ddfe9616ddf358d81546a3a18034fc88b34965688ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"15BZeHbK4gX8YugqBsHwyTnUAqF5GJjgBW"
]
}
}
]
}

Code:

{
"hex" : "0100000001c0e62a6ec5b1088d9341154de1855568e38c31b63702fb1d951f6e04b3ec1c2b000000008b4830450220310e5c39ac668739c8938180a10fc304615fda593c99216a1b3691cf4887d835022100c2bd43eb443013b7e1c1543c37d2e0c491b48bae165964a34a8b9583349493e5014104696b060ed1de0bac92d72cf4afbb3ac6627464b90466eff282f3ff01c0b19a2da261f2bbad9c501332ebd87b82ad4e64b86f7248f7eaf7040b02d44fbbbc415fffffffff016a48c323000000001976a9147d3b0ada4990415ac12b968174371c8e67dc691b88ac00000000",
"txid" : "acaebd04202864eef6af5b9df8ca70b88875bc4cf540a6d0f8b010a87f00145c",
"version" : 1,
"locktime" : 0,
"vin" : [
{
"txid" : "2b1cecb3046e1f951dfb0237b6318ce3685585e14d1541938d08b1c56e2ae6c0",
"vout" : 0,
"scriptSig" : {
"asm" : "30450220310e5c39ac668739c8938180a10fc304615fda593c99216a1b3691cf4887d835022100c2bd43eb443013b7e1c1543c37d2e0c491b48bae165964a34a8b9583349493e501 04696b060ed1de0bac92d72cf4afbb3ac6627464b90466eff282f3ff01c0b19a2da261f2bbad9c501332ebd87b82ad4e64b86f7248f7eaf7040b02d44fbbbc415f",
"hex" : "4830450220310e5c39ac668739c8938180a10fc304615fda593c99216a1b3691cf4887d835022100c2bd43eb443013b7e1c1543c37d2e0c491b48bae165964a34a8b9583349493e5014104696b060ed1de0bac92d72cf4afbb3ac6627464b90466eff282f3ff01c0b19a2da261f2bbad9c501332ebd87b82ad4e64b86f7248f7eaf7040b02d44fbbbc415f"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 6.00000618,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 7d3b0ada4990415ac12b968174371c8e67dc691b OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9147d3b0ada4990415ac12b968174371c8e67dc691b88ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"1CRACKLiwFrZbAQz1yb9w22onHCMLbiMTY"
]
}
}
]
}