
Bitcoin's $137k Jackpot - cynthiar
http://hackingdistributed.com/2016/04/29/bitcoins-137k-jackpot/
======
ryan-c
> Remember that time when you tried to transfer your life savings from one
> bank account to another for a small fee, but swapped the fee field with the
> total transfer amount field, and ended up losing all your life savings? Of
> course you don't. There are safeguards to catch and prevent these kinds of
> errors. > > But this is a common occurrence in Bitcoin-land.

This mistake is difficult, if not impossible, to make with standard Bitcoin
software. The fee field is usually pre-filled and somewhat tricky to change,
and newer versions of bitcoin-core will block transactions like this as
obviously wrong. It should also be noted the bitcoin fees are implicit in
transactions - a transaction will have some amount of funds going in, and some
amount going out, and anything left over is the fee. Usually these types of
mistakes actually happen when someone manually crafts a transaction and
forgets that they need to make a change output for themselves.

It is obviously still _possible_ to create transactions like this, but it
currently requires using advanced interfaces and deliberately bypassing safety
measures.

~~~
wimagguc
All types of costly mistakes happen in non-bitcoin land too: _Deutsche Bank
accidentally transfers $6bn to hedge fund client_
([http://www.theguardian.com/business/2015/oct/20/deutsche-
ban...](http://www.theguardian.com/business/2015/oct/20/deutsche-bank-
accidentally-transfers-6bn-to-a-single-customer))

...as long as humans are involved in transactions (by writing software if
anything), human errors seem to be bound to happen.

~~~
felipeerias
The diference with Bitcoin-land is right there in the article: "and recovered
one day later".

~~~
drcross
Miners will typically return obviously erroneous transactions to keep bitcoin
users in good faith. It's happened numerous times, including this week.

~~~
ssharp
But they don't have to and they aren't going to be held accountable if they
don't.

------
hughes
This reminds me of a similar error from 2005[1] where a trader mistook the
"price" and "quantity" fields of the trading software. Instead of selling 1
share for 610,000 yen, 610,000 shares were sold for 1 yen.

The mistake cost around $225 million.

[1] [http://www.foxnews.com/story/2005/12/09/typing-error-
causes-...](http://www.foxnews.com/story/2005/12/09/typing-error-
causes-225m-loss-at-tokyo-stock-exchange.html)

~~~
Cyph0n
Damn that's huge. You'd assume that the software checks the dollar amount and
asks for a confirmation, or better yet permission from a higher up, if it
exceeds some value.

~~~
joering2
it does ask for confirmation. As OP wrote - it was an error, NOT a mistake.

~~~
randyrand
What a silly semantic argument to make.

It was an error _and_ a mistake.

In fact, error is a synonym for mistake:
[https://www.google.com/search?q=mistake&oq=mistake&aqs=chrom...](https://www.google.com/search?q=mistake&oq=mistake&aqs=chrome..69i57j69i60l2&sourceid=chrome&ie=UTF-8)

------
drostie
Can someone else confirm to me that I'm not crazy and the central distinction
of this article is totally bogus?

Reasoning: BitCoin isn't, to my knowledge, a scheme where some private
identifier is stored inside each "coin" whose ownership is revealed with a
zero-knowledge proof; it's simply one where you have public and private keys
and use those private keys to sign transactions saying "Take X1 out of my
public key K1 and put X2 in public key K2, with X1 - X2 going to the miner."
That is, BitCoins themselves, as I understand them, are just points in a big
distributed videogame: they do not represent actual packets of data which are
individually 'minted' in mining and stored on your computer until you spend
them.

If that's correct, then there's no distinction if you tumble-via-miners versus
tumble-via-tumblers -- either way the coins are 'freshly minted'; there's
simply no other sort of coin.

The only real thing that you seem to be able to do here is to tumble via
_both_ the tumblers and the miners, which might create some binary tree of
complexity if someone tries to "follow the money" \-- but that doesn't seem to
be what the author is saying.

Is there legitimately something in each coin which makes it easier to follow a
given bitcoin via tumbling than through miner-money-laundering, or are they
really just the same thing performed through different channels, with a much
slower rate of success for the MML tumbling?

~~~
CydeWeys
In traditional tumbling, let's say you have ten people who all want to
intermingle their funds. So you have ten inputs and ten outputs, and now
there's some plausible deniability added because you don't know which
particular one of the ten any given output corresponds to. But you do know it
belongs to one of the ten, which is still significant information. And, most
importantly, the vast majority of Bitcoiners do not use tumbling services.

With mining, however, you are intermingling with the activities of an entire
mining pool. It is WAAAY harder to trace. Let's say I want to launder 1,000
BTC, and I have a sympathetic mining pool that will launder it for me. So I
sign a 1,000 BTC transaction that gives it all away as a transaction fee, and
they include it in their next mined block, eating the full bonus.

Then, separately, either before or after, and possibly far separated in time
chronologically, they issue a series of transactions to a set of separate
virgin receiving addresses I have created that total up to, say, 999 BTC (they
keep 1 BTC as their mixing fee). As a key point, these transactions do NOT
spend the output of the 1,000 BTC reward block, but rather, block generation
rewards from previous blocks they've mined. They are indistinguishable from
standard mining reward payouts, which any pool goes through a huge number of
every day.

Those 999 BTC I now have spread across my addresses are way more anonymized
than anything I could get with a traditional mixing pool.

~~~
joshuak
This does not serve as a tumbling mechanism because the participants aren't
peers. The coins went all one direction from source to many destinations. If
those many destinations don't, in turn, pay the source back in some way you've
just lost the money not laundered it.

~~~
CydeWeys
I don't understand your objection. The mechanism I explained works to launder
and obscure the auditable trail of Bitcoin. All I figure is that you're
pointing out some there is some risk inherent in the mining pool simply
walking away with the money. OK, sure. There's lots of trust involved in the
Bitcoin ecosystem. Every time I buy something on the Internet with Bitcoin I'm
trusting the retailer to send me what I ordered rather than walking away with
my money. Every time I transfer BTC to an exchange in order to sell it I'm
similarly trusting that they won't instead simply screw me over.

~~~
joshuak
No, you're not describing something like A (typical tumbling) is risky, and B
(paid back by miners) is better but with somewhat more risk.

A is I give you a million dollars, you give me the deed on your house. There
is risk, there is trust involved, but we both are peers and bare equivalent
risk.

B is I give a small portion of a million dollars to hundreds or thousands of
people and ask that they pay a new account some large portion of it.

B is 100% risk. It is in fact guaranteed not to work in the aggregate. The
problem is that none of the individual miners have a stake, as I said they are
not peers. In fact it's worse then that, they would incur unnecessary risk of
their own to payback the money rather than just keep it because of the danger
of being implicated in a money laundering scheme.

With tumbling every participant shares risk equally since every participant
puts funds into the system. In your scenario weather it's 10 miners or 10000
miners NONE of them are putting up any money at the same time, AND you must
trust every single individual.

It simply doesn't work. It is not a lauding scheme of any kind.

~~~
CydeWeys
I think you are misunderstanding how mining pools work. It's only the pool
operator that needs to know the valuable fee transaction in order to launder
Bitcoin via block rewards. The individual miners that are in the pool are just
hashing over a hash of the merkle root of all of the transactions that the
pool has selected, along with several other fields. More details here:
[https://en.bitcoin.it/wiki/Block_hashing_algorithm](https://en.bitcoin.it/wiki/Block_hashing_algorithm)

The individual miners don't know, and have no control over, the transactions
in the tree that they are hashing. The only person you need to trust is the
person in charge of the pool. So this part is wrong:

> In fact it's worse then that, they would incur unnecessary risk of their own
> to payback the money rather than just keep it because of the danger of being
> implicated in a money laundering scheme.

The miners have no option to pay back or keep the money. They just submit
valid hashes of what is essentially nonsense to them (other hashes), and get
paid out for doing so. They have no control over the mining pool operator, no
control over what they're hashing, and no way of defecting other than by
withholding valid hashes, which is disincentivized because it costs them
money.

To use an example, AntPool is currently sitting at ~30% of the network hash
rate. That works out to about 50 blocks per day, more than enough to do lots
of laundering if they were so inclined. If I had, say, 1,000 BTC I wanted to
launder, all I would have to trust is the main technical person at AntPool.
I'd give them fifty different transactions, each with a block fee of 20 BTC,
and they could launder it over a day, then give me back most of that 1,000 BTC
in transactions to unrelated addresses from unrelated sources at their
leisure. I literally only have to trust a single person at AntPool to do this
-- I don't understand where you think these thousands of other people come in.
It's certainly not doomed to fail.

The only real risk I can see is that a lot of mining pools (but not all)
include transaction fees in the block reward bonus to be distributed to
miners, after the mining pool rake is taken anyway. You'd simply have to
calculate the fees differently. Currently miners might be paid out for, say,
95% of the value of a total block transaction fee summing up to around
~0.25-0.5 BTC. You'd continue paying that out for normal transaction fees, but
then also add in, say, 1% of non-P2P transaction fees (the money-laundering
ones), with another 1% being taken by the pool and the other 98% ultimately
going back to the source in untraceable transactions. This would actually
create a lot of incentive to use the pool that is doing the money laundering,
because they'd be paying out more per found block since they have a second
income stream!

~~~
joshuak
I do know how mining pools work. One could indeed do what you are saying.

What I am saying, however, is that one wouldn't.

It does not make any sense economically or in terms of risk of arrest.

Either you have pissed off miners ("Hey! What happen to all the money from
that fee?"), or they are all collaborating which means "grand conspiracy".

Without the miners participation you have an easy to trace transaction chain
that goes like this: bad guys, suspicions fee transaction, pool operator, new
address. Trivial to trace.

In point of fact the fees in this case went to every participating miner. All
conceivable cases that lead to any definition of tumbling requires that the
actual funds are sent to all the miners. The event horizon argument which is
the basis of the article is simply wrong. You seem to agree since you don't
make a case for that.

Simply put: __the fee is just as traceable as any transaction __.

The best that could be done to balance the economic motivations and risk in
your scenario is to generate pre-signed multi party transactions in advance of
the initial fee payment for every minor, perhaps they only become valid once
the fee is paid (one of the inputs to the transaction), and only at some point
in the future (to obscure the direct relationship). In this case you'd have at
least one new transaction from every participating miner creating a large
number of outputs that become difficult to trace. Though it is still only one
round of tumbling, and so compromising even a single participant would be
enough to trace at least the value of that one participants laundering
contribution directly to the source.

Even that solution requires a set of completely traceable colluding
participants namely the entire set of miners who should have been paid the
fees but aren't. And each of them would have to express there intent to
collude via the pre-signed transaction _in advance_ of receiving any benefit.

So at absolute best you have a poor quality, high risk, error prone, tumbling
/ mining service.

------
mrpopo
You can see a half-dozen of "mega-fees" on this graph[0]. The public nature of
bitcoin transactions is very interesting.

[0] [https://blockchain.info/charts/transaction-
fees?timespan=all...](https://blockchain.info/charts/transaction-
fees?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=)

------
xigency
Sort of unrelated but,

"According to my calculation, a single Bitcoin transaction uses roughly enough
electricity to power 1.57 American households for a day."

[http://motherboard.vice.com/read/bitcoin-is-
unsustainable](http://motherboard.vice.com/read/bitcoin-is-unsustainable)

I find this interesting thinking about Bitcoin as a currency. The first
cryptographic currency example that I had read, from a cryptography book,
didn't involve active power. I'm really surprised that Bitcoin has been able
to gain this much popularity with its design. Does this explain how you might
be able to lose a household-sized amount of money in a transaction on this
network? I don't know, but I think that the blockchain idea might not be the
ideal for digital currencies.

~~~
thescriptkiddie
Each bitcoin block takes 25 BTC (11000 USD at time of writing) worth of
electricity to mine, because that is the maximum that the sum total of miners
can afford to spend and still break even. Currently it's only possible to fit
somewhere around 2000 transactions in each block, because there is a hard-
coded limit on the size of a block (1 MiB). So each transaction costs
11000/2000=5.5 USD, which is indeed the approximate value of 1.57 days worth
of average per household energy consumption in the US. This is a big reason
why it is important that the 1 MiB limit is lifted soon, the artificial
restriction on transaction volume pushes the cost per transaction far too
high. As a side note, when the block reward halves to 12.5 BTC in a few
months, we will either see the value of bitcoin double or the hashrate (and
energy consumption) halve - probably a little of both.

~~~
aianus
> So each transaction costs 11000/2000=5.5 USD

No, each transaction costs _at most_ $5.50 USD. You haven't established any
lower bound in your calculations. A better approach would be to calculate the
average number of hashes required to mine a block and the power efficiency of
the latest generation ASIC miners.

Also, for what it's worth, $5 is much cheaper than a Western Union or SWIFT
wire transfer so even this upper bound doesn't mean Bitcoin is uneconomical
compared to modern banking.

~~~
xigency
Except environmentally, you need to look at the energy footprint of Western
Union compared to the network of Bitcoin miners, not the price of electricity
or amount of coins awarded.

~~~
Mtinie
Western Union's energy footprint is no doubt large. Is it larger than the
Bitcoin networks? I don't know, but WU has extensive infrastructure in place
all over the World, so it's not a simple case of Bitcoin being the only
ecologically unsound option of the two.

------
Bedon292
Obviously I am missing something on this. How do you direct the transaction
fee to a specific miner? I thought it just went out there for anyone to
process. If you can, why don't people just direct all their transaction fees
at their own mining operation or a friend they trust?

~~~
vilhelm_s
Ordinarily transactions are broadcasted to the entire network for anyone to
process. The miner who first finds a solution will get the fee for that
transaction.

I think the idea here is that you instead privately give the transaction to
only your favoured miner. He will then try to hash it, and if and when he
finishes it, he will broadcast the transaction and the solution to the network
at the same time.

Ordinarily there would be no advantage to give your transactions privately to
just one miner; if you broadcast it publicly there will be many more miners
working on it, so it will commit faster. So unless you are deliberately trying
to overpay (like here) it would be a waste of money.

~~~
CydeWeys
> I think the idea here is that you instead privately give the transaction to
> only your favoured miner. He will then try to hash it, and if and when he
> finishes it, he will broadcast the transaction and the solution to the
> network at the same time.

That's not really a good description of how this will work. Each miner
maintains a transaction pool of transactions that have been broadcasted across
the network. Think of it as a priority queue. Transactions are of different
sizes and fees, and the miner is trying to maximize their total fee up to the
1 MB block size limit. These transaction pools are largely the same across all
miners, with of course some differences owing to time delays and network
propagation issues.

So all that would happen in miner tumbling is that the miner maintains its
transaction pool as normal, but then additionally adds in the special
transaction that it does _not_ rebroadcast. The end result is you end up
mining a block that has almost the same transactions in it as any other miner
would, except with that one extra special transaction, and a low priority one
being bumped.

~~~
nandemo
I might be wrong, but I feel you gave a lower-level (more detailed)
description of "the idea here is that you instead privately give the
transaction to only your favoured miner".

~~~
CydeWeys
The comment I replied to said several things that are wrong. I understand that
it was attempting to give a higher-level overview, but it did so in a way that
made things inaccurate. Let me break it down.

> Ordinarily transactions are broadcasted to the entire network for anyone to
> process.

Process is sort of inaccurate here (it implies mining). Transactions are
broadcast across the network in a P2P manner amongst all full Bitcoin nodes,
so long as they validate anyway. Miners themselves are running full nodes, and
find out about transactions because they come across the P2P network.

> The miner who first finds a solution will get the fee for that transaction.

Miners aren't trying to "find a solution" to transactions. That description
isn't accurate. What miners are trying to do is figure out what nonce to
insert into a block (which includes a _lot_ of transactions, along with
metadata) such that the hash of the entire block is less than some very small
target number. Understandably, this takes a large amount of tries, to the
point where you have mining pools that distribute ranges of nonces across a
large number of workers to pool their effort (i.e. distributed computing).

> I think the idea here is that you instead privately give the transaction to
> only your favoured miner.

This part is correct.

> He will then try to hash it

Nope. Transactions are static. They always hash to the same value. What the
miner is doing is trying to find a valid block. The miner isn't doing anything
to specific transactions other than validating them, which any full node does.

> and if and when he finishes it, he will broadcast the transaction and the
> solution to the network at the same time.

Nope. All valid transactions are broadcast by all full nodes as part of the
normal P2P operation. What the comment was trying to talk about was
broadcasting a valid block. There is no "solution" per se -- there's no
guarantee that a nonce even exists that yields a hash below the target for any
given set of transactions and block metadata. However, the transaction pool is
constantly changing as more transactions are received, so constant churn in
the transaction set as well as being able to run through the entire range of
nonces each time guarantees that, with enough hashing, you will eventually
find a combination that yields a hash that is sufficiently low enough. And
then the block is broadcast.

Hope that clears things up.

~~~
mannykannot
Thank you for this clear explanation, but it leads me to another question
(which, I realize, is probably based on a misunderstanding): first the miner
finds a valid block that includes the high-reward transaction before the
latter is broadcast, then the conspirators broadcast the transaction, followed
closely by the valid block including it. But is it not possible that at about
the same time, another miner finds a valid block containing one or more of the
same transactions used in the special block (though obviously not the so-far
private high-reward one) and broadcasts that? If so, then it is my
understanding that there will be a race to see which block becomes accepted,
and if the block containing the special transaction falls by the wayside, that
transaction could be included in another valid block by any miner?

~~~
CydeWeys
> first the miner finds a valid block that includes the high-reward
> transaction before the latter is broadcast, then the conspirators broadcast
> the transaction, followed closely by the valid block including it.

Negative on the second part. The only reason that the P2P network exists is to
(a) get blocks (which all nodes do), and (b) share transactions so that they
can be included in blocks. Once a transaction is in a block, that's it, it's
on the chain. It isn't transmitted separately. Once a node gets a new block
over the P2P network, it validates it, and removes all of the transactions
included in it from its transaction pool.

> But is it not possible that at about the same time, another miner finds a
> valid block containing one or more of the same transactions used in the
> special block (though obviously not the so-far private high-reward one) and
> broadcasts that

Yes, conflicts can and do happen (this is called a fork). It's actually quite
likely, when you think about it; if blocks are found an average of once every
ten minutes, and say it takes a few seconds for the P2P network to transfer
the latest 1 MB block to all nodes, then you can have a situation were two
mining pools find blocks simultaneously that conflict. The longest chain
always wins out, otherwise it's whatever block you mined first. Absent an
adversarial situation, the odds of having a fork that lasts even two blocks is
so low that it should happen on average well less than once a month.

I want to point out an incorrect understanding in this one particular
statement though:

> another miner finds a valid block containing one or more of the same
> transactions

Blocks don't conflict because they have the same transactions, they conflict
because each block has a parent, and multiple blocks with the same parent is a
conflict. Even if two blocks had no duplicate transactions between them at
all, if they topologically form anything other than a straight line on the
blockchain (i.e. sharing a parent) then they conflict, and only one will win
out.

> if the block containing the special transaction falls by the wayside, that
> transaction could be included in another valid block by any miner?

Yes, it could be, but I do not believe that the Bitcoin software by default
adds transactions to its transaction pool from orphaned blocks. That might be
an optimization you could make if you wanted to take advantage of high-fee
transactions that end up being orphaned that aren't broadcast to the network
before inclusion into a block.

------
ChuckMcM
_" exogeneous enforcement mechanisms."_ \-- Chortle, I really need one of
those :-). I had not been aware of how the miners could launder bitcoin, that
seems like a pretty big hole you can drive a lot of bitcoin through.

~~~
maxerickson
The award is recorded and they owe taxes on it. Which probably still leaves
room for laundering. But it doesn't really obscure the flow of value all that
much, unless they are all doing it and doing it for about the same price.

------
vonklaus
Is MML(miner money laundering) a viable concept? I thought that the
transaction blocks were randomly distributed so it would be hard for a
launderer to "target" a miner they trust. If someone has a bit more technical
insight about whether this makes sense, or is viable I would be interested.

I would also contend that even if it was trivially easy to do, it would
probably make more sense to just route transactions to various wallets and
then to some exchanges and into other currencies, ect. I don't know if the
miner thing makes sense

~~~
maxerickson
Presumably the high fee transaction could be withheld from the network until
the block was mined.

I don't know if that is possible, but if it is it would ensure that a given
miner was getting those fees.

~~~
wcoenen
It is indeed possible to withold a transaction while trying to mine it into a
block

But this still doesn't provide 100% certainty that you will collect the
transaction fee. You risk that other miners try to orphan the block once it is
published (i.e. ignore it and build on the previous one instead) in order to
put the transaction in their own block.

~~~
URSpider94
This is an excellent point. If a block with unusually high fees comes up,
you'd be well served to try to re-mine it as long as P(win)^(n+1) * fee >
P(win) * mining reward, where n equals the number of blocks after the few was
published. If you have a 10% chance of earning a block, you could push on for
quite a while.

------
placeybordeaux
Pretty bad article, but I couldn't find any better. Looks like a solid chunk
of the money traces pretty cleanly back to tradeBTC.

I'd really like to find a good tool for exploring the graph of transactions.
Most of the funding of the account that lost all the money have a similar
pattern where a couple BTC is peeled off at each step and the majority goes
forward in the chain till it all pools at 1QgTYzMYqStzZBQx8gguYaJQMjFRbagbh
and gets spent. I wonder if thats just what TradeBTC transactions look like.

------
thevibesman
Thanks for the post, I enjoyed the read (haven't read much about bitcoin
laundering).

One small nitpick:

> My payment is going to be with newly mined coins, the Bitcoin equivalent of
> fresh, crisp dollar bills straight from the Mint.

Coins are minted, bills are printed, so only coins come from the U.S. Mint.
Paper bank notes and stamps come straight from the Bureau of Engraving and
Printing (way less fun to say though!).

~~~
andirk
Also, you wouldn't want money coming straight from the Bureau because I'm sure
the serial numbers would be so incredibly easy to track. For example, your
bills have sequential serial numbers, or are clearly from the same batch.
Better to have them straight from the Panama Papers.

~~~
thevibesman
> Better to have them straight from the Panama Papers.

Haha, great point!

------
seanalltogether
Wouldn't sending a transaction directly to the miner be more reliable then
trying to hide it in the fee? If the goal is to hide your money in the high
volume of BTC that a big name miner processes per day, why not just send it
straight to their wallet?

From an investigators perspective there is no difference between the two
scenarios.

1\. Miner A has received 500 BTC from Suspect B over the past year and may be
laundering it.

2\. Miner A has processed 500 BTC in transaction fees from Suspect B over the
past year and may be laundering it.

------
tdebroc
Intersting explanation: [http://bitcoin.stackexchange.com/questions/35986/are-
the-hug...](http://bitcoin.stackexchange.com/questions/35986/are-the-huge-
transaction-fees-mostly-mistakes-or-some-other-market-indicator)

------
LAMike
Some people say it was an act of money laundering by the pool that mined it.

------
known
Is Bitcoin suffering from
[https://en.wikipedia.org/wiki/Pareto_principle](https://en.wikipedia.org/wiki/Pareto_principle)

------
theandrewbailey
> Remember that time when you tried to transfer your life savings from one
> bank account to another for a small fee, but swapped the fee field with the
> total transfer amount field, and ended up losing all your life savings? Of
> course you don't.

Of course I don't. I know banks can have terrible design, but I've never seen
a 'fee' field on any transfer form. (maybe because I use credit unions?) That
bank might as well tell everyone 'please let us eat even more of your money on
top of the bogus fees we already charge you'. And don't real banks have
regulations preventing mess ups like these?

------
maxerickson
Wouldn't the MML leave lots of traces in the blockchain, a miner collecting
unusually high fees over time?

~~~
MichaelGG
I don't think it'd even be that hard. Unless new mined blocks are untraceable
(as in, it's impossible to see which fees went to which new coins), then it
provides no covering at all. It's the same as sending small amounts from one
address to another.

~~~
maxerickson
There aren't coins as such. The address the fee goes to is given in the block.

~~~
MichaelGG
Exactly. So this accomplishes absolutely nothing. Your identity from address A
flows right through to the "fee address".

~~~
eternauta3k
The person with dirty money is paid with the reward of _other_ blocks, not the
one with his transaction.

------
taesu
I'd definitely keep that amount if I won it through mining. It's really hard
swapping `amount` to `fee`, in coding, so I bet that this was a human mistake
on sending btc, not coding mistake...

~~~
cjbprime
I heard that the web interface on the exchange they used has fee and amount
fields next to each other and with identical widgets (but different labels),
so it's extremely easy to see how a human would make that mistake there.

