> 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.
I'm surprised that this even happens. It's so involved to make a transaction yourself. It's not like leaving your keys on the kitchen counter. It's more like building a house and forgetting to add a door
Basically, any client which can speak the protocol can send transactions. Normal human consumers use it via clients like multbit-hd (on Desktop) or any of the online wallets, which of course don't allow this mistake to happen, as they calculate the fee for you (online wallets add their commission as well).
But as the article says, likely it happened via a script. But its a very costly mistake. I hope we know the real cause of it.
Overall, I like the depth the article has gone into. But I don't agree with this sentence:
the kind of script that swaps arguments by mistake may be the kind of script that does not write its keys out to a database, so the private keys may be long gone
I think the article got it wrong. How can the private key be lost (and also logged to DB!)? The 291+ btc would have come from some public key. If that that public key has got more btc attached to it, then the owner surely still has the private key. Also even if its zero value now. The wallet (public-key) from which the money came, would still exist, and private key still there somewhere.
So the miner can return the extra BTC to the same public key. Am I missing something?
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.
> Worse still, the number of shares in Mizuho's order was 41 times the number of J-Com's outstanding shares, but the Tokyo Stock Exchange processed the order anyway.
There are a lot of simultaneous errors going on here...
Stock exchanges really cannot be expected to track numbers of outstanding shares. One puts in a bid or an ask, indicating that one is willing to purchase or sell the given number at the given price, and an order type, indicating the manner to fulfil (fill-or-kill, limit to a certain price, take whatever outstanding offers are necessary...). This is more than enough nuance for a professional product like a stock exchange that needs to operate at microsecond cadence.
If you want to validate whether an order makes sense or is a "good idea", the place to do it on the client.
Coming from a perspective of competitive multiplayer game networking, that seems insane. You can't trust the client. An ideal stock exchange, I'd think, would include the same sort of logic as a payment processor: blocking any orders that seem to be "not the sort of order this client would make", to prevent e.g. orders being executed by people who have illegitimately gained access to the account.
Of course, these type of algorithms typically take far more than microseconds to run—but that's fine, as long as they take the same time for everyone.
Multiplayer games are a completely different genre than a professional-level API like a stock exchange. You absolutely must trust that a client's business logic is sound; as long as their credentials validate it's simply out of scope for you to do anything other than explicitly execute their instructions, because that's how the traders make money. "Trust the client" doesn't mean state, it means actions - the equivalent reasoning in a game would be disallowing the player from "playing badly", which is nonsensical.
> the equivalent reasoning in a game would be disallowing the player from "playing badly", which is nonsensical //
Self and team damage is often turned off (on games I've played, I'm not really a big gamer). That would seem to correspond to blocking a sell order that represents more shares than you could possibly have?
A stock exchange isn't responsible for tracking how much outstanding stock there is. The purpose of an exchange is just to match orders, not to determine if they are insane.
Expecting otherwise would be like expecting eBay to determine that your buy it now price is too low or that you don't have enough inventory on hand to fulfill your listings.
Not at all. If your exchange takes five milliseconds, you're gonna lose the volume of high frequency trading algorithms because they cannot front run as effectively. For an exchange volume (hence fees) is key, so you really have to work for HFTers.
You can validate this stuff before doing matchmaking. Sure, it might add less than 1 ten millionth of a second latency. But, nobody is going to drop an exchange because one of there network cables is a few inches longer than necessary and that's the cost of sanity checks.
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.
It got flagged multiple times and, each time, someone at the Tokyo Stock Exchange came to the conclusion that they didn't have the authority to countermand the order. The regulator was livid about this in the report.
The problem with confirmation is it trains the human to always press "yes". You need a system that only activates if something really unusual or wrong.
So instead of a yes/no confirmation, you force the user to explicitly type what they are doing, i.e. "Sell 610,000 shares of stock X for 1 yen each."
This is similar to how Github forces you to type the name of a repository when you try to delete it.
You can also configure a threshold such that the "hardcore" prompt kicks in only if the system detects that the user is trying to do something unusual, i.e. sell a stock for much cheaper than it is.
I like what mycelium does. You type the amount, and there's a button that will change state on every press, and cycles though "generous", "normal", "economical" and "stingy" or something like that.
That way, a user doesn't have to know what value to use. You can also set this once in settings and never see it again, except as a report.
These sorts of mistakes happened when I was trading options more than a decade ago. In most transactions, such a confirmation would have cost money on every transaction since speed matters.
Back in the old days, I feel the broker would have gone to the market makers, said there was an error, and gotten out of the trade.
>>In most transactions, such a confirmation would have cost money on every transaction since speed matters.
Which is why I said you would enable it based on a threshold and/or only on unusual threads. These systems are capable of extremely complex decision-making at very high frequency. Surely something like "sell 610,000 shares for 1 yen" would have stood out as strange.
A billion times over market price, funny; who in their right mind would even pay 20x over market price in any meaningful amount without requiring some sort of control?
Yes of course. I'm just saying that usually these systems are badly designed, and recognizing errors correctly is a surprisingly hard problem.
In the medical world, many people have been killed by mistakes in prescriptions, despite everything going through computers and multiple humans checking it.
The problem was that the machines were too sensitive to mistakes and trained the humans to ignore warnings. They also didn't distinguish mild warnings from extreme warnings. E.g. a prescription being 2x larger than recommended, or 100x larger than recommended, which are very different situations. A well designed interface might have different shades of red for different levels of severity. To give an indication if something is really wrong.
My mother use computers all day, and also hates them and think they are illogical.
In a way she is correct, I saw her many times freaking out at a dialog box and calling me to "fix it", and it was just some absolutely useless "warning", but I also saw her many times clicking "ok" on a important message without reading and then wondering why things broke.
2005 was ages ago in terms of financial markets. It was before the housing crash and other financial crises (notably in Greece). It was before the flash crash and other notable electronic trading incidents.
Many world equity markets now have daily up/daily down limits a certain percentage above and below the previous day's closing price. Others will pause trading for a short period of time if short-term price moves are abnormally large.
Many equities markets only allow direct connections to the market from brokerages licensed by the country's financial regulators. These days, brokerages often implement their own sanity checks on many order flows. Joe's Live Bait and Stock Trading generally isn't connecting directly to any equity trading venue.
I'm curious what the effect would be of a market switching to second-price blind auctions every 5 minutes if a stock moves up or down 5% on the day. There are academic papers showing theoretical stability advantages of second-price auctions. Trading at the second-highest bid when the market is down more than 5% and at the second-lowest ask when the market is up should help to attract one-sided liquidity in the direction of market stability.
It's more nuanced than that though isn't it - you can sell shares at a loss to push the market so you can buy and profit off the rebound (ie go short)? Kinda like losing your queen in chess in order to check-mate your opponent.
I don't see what you're getting at. The trader switched price with quantity - it was a human mistake.
If the software had brought up a warning with something like "you are selling each share for less than 610000 +- 10000, please confirm", this could have been avoided.
I think fat finger is more like adding too many zeros, or hitting the wrong numbers on the keyboard. This incident was a UI confusion; entering correct values in the wrong inputs.
That reminds me of the time when, in 1989, I was playing trade wars, on a bbs out of San Jose; I was attempting to corner the market on wheat in the galaxy as I had pretty much all of it... I smoked pot and instead of buying all the available wheat, I sold all I had. Ruined my monopoly on wheat....
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?
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.
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.
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.
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.
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
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!
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.
Well you are laundering money (which is likely illegal depending on your reason for doing so), so it'd be unreasonable not to expect there to be some risk. You're just trading off risk from government for risk from mining pool. But if you do the laundering over a series of transactions spread out in time, you are limiting your potential losses. Say you do it in fifty blocks over a week -- if the miner betrays you your maximum loss is 2%. If you don't tell the miner how much you're laundering through them (they'll just know when you are finished), and you give them an acceptable cut (say, 3%), it would be in their vested interest not to betray you because the expected value of more laundering from you is greater than what they could make by eating any one given attempt.
Also, if they are doing laundering as a service, then trust in them is very important, and screwing over one customer at the cost of potentially losing all future customers is not worth it. For instance, let's say I'm selling $5K of Bitcoin. I'm not worried too much that any given exchange is going to screw me over and eat it, because the big exchanges are doing many millions of dollars in business a day, and stand to lose a lot more from a hit to their reputation from stealing from me than they do to gain from eating my money. The only worry is if an entire exchange goes down (a la MtGox), but you can minimize that risk by not keeping money in an exchange.
You are correct in that tracing a transaction fee is equivalent to tracing any kind of transaction. There is no event horizon for transaction fees as implied by the article. New coins have no history because they are new, the coins for the fee are not new, they are simply added to the reward total for successfully mining them.
---
That being said the bitcoin metaphor is misleading in the details as metaphors always are. There are no bitcoins, in that there are no IDs that are kept in an inventory that represent every individual bitcoin. Instead bitcoins are represented as ledger entries only. The traceability, or lack thereof, comes from the ability to trace the ledger entries. It goes something like this:
Miner: "Everyone agrees I now have 25 bitcoins in account M1. Because I'm a winner!"
Miner: Tx :: Send 25 bitcoins from M1 account, to P2 (Person 2's public key)
Person 2: Tx :: Send 5 bitcoins from P2, to P3.
Balances
M1: 0
P2: 20
P3: 5
P3's bitcoins can be traced to P2, and then M1. Now P2 sends a transaction with a high fee (up to now no fees were paid).
Person 2: Tx :: Send 1 bitcoin from P2, to P4, with a tx fee of 19.
Miner 2: "Everyone agrees I now have 44 bitcoins in my M2 account. Because I'm a winner!"
Balances
M1: 0
P2: 0
P3: 5
P4: 1
M2: 44
M2's bitcoins can be traced to 25 new coins, 19 fee coins given by P2, who go them form m1. P3 is not involved in the transaction history, and every transaction is traceable.
Yes tumbling is much more secure if your goal is to anonymise your money. MML is much more easily traceable as you just look at the guy who mined the block and send the authorities to go and speak with him. Especially if the large mining operations are well known.
The usefulness to a launderer seems more the simplicity of exchanging a large amount of coins for fiat currency in a single transaction, rather than going through an exchange or sending lots of complex small transactions through a mixer and figuring out how to exchange all of that back without going through an exchange w/ KYC
> MML is much more easily traceable as you just look at the guy who mined the block and send the authorities to go and speak with him.
Well that's easier said than done. There are a large number of blocks for which the miner is not known. The only reason the miner is known for as many blocks as it is is because several of the largest mining pools tag every block that they mine as a form of accountability to their miners (and of course bragging rights).
OK but you know the account that got the "laundered" money. So whatever you were going to do with the BTC before laundering (like cash them in), you still can't do. The previous identity flows.
No you don't know where the laundered money ends up. See my other longer comment in this thread, but the gist of it is that the pool will use the transaction fee to pay their mining rewards out of, and pay out rewards from previous blocks to a series of separate virgin addresses controlled by the original party in a way that looks indistinguishable from mining reward payouts.
I will grant you that the article didn't fully explain the process, and elided important details.
Most of the "important details" aren't, as far as I can see. The only big thing that the pool adds is plausible deniability: everything else can be simulated by sufficiently complex tumblers; it's just that the vast majority of mining payouts are untainted that gives this a mixing effect. (You can delay payments and pay back in installments to multiple addresses that are not the source address but are owned by that person, via either mechanism.)
Running some numbers, it looks like about 98% of Bitcoin's hashrate seems to be held in the top 10 mining pools; assuming this isn't a common service provided by those top pools then a mining pool which launders too will have, say, 1% of the network hashrate at most. That's actually a nice place to be in; it means you get a payout roughly every 1000 minutes of 25 BTC (~$400) plus what looks like typically 1500 transactions or so paying you about a nickel apiece -- so let's optimistically say you get a payout of $600 total every 16 hours, or $900/day. Maybe you can keep plausible deniability going even when 25% of your revenues come from laundering transactions, so that means they can launder about $300/day. That's not too bad, about $100k/year, but it's not a massive chunk of the money laundering happening worldwide either, which usually is quoted in at least terms of billions of dollars -- so 4-5 orders of magnitude larger. Even considering how much the network as a whole could maybe launder if they were crazy about it (100x more participation in laundering, 10x more revenues from laundering transactions) you're still only 1-10% of total global money laundering by this mechanism before you have no presumption of "most of this money is clean so the laundered money is properly hidden."
So e.g. if you wanted to launder $1m within a year using our example pool then you'd have to pay in $2700/day and the legitimate transactions of the pool would only be 900/3600 = 25%; I'm not claiming that this is insecure -- but rather that a normal tumbling system could do this too, purchasing 25% of the money-to-be-laundered from a BitCoin exchange, gradually paying out over a year, and reselling the surplus 25% back on the exchange, for no real difference in security (but potential gains in speed and volume). If you charge a 10% laundering fee then this is an investment of $250k to gain $350k over the course of 550 installments in the year, so if I'm doing the math right that's a return rate of 0.13094%/installment or a nominal rate of 72%/year -- plenty enough to cover whatever risks there are in the currency, inflation, opportunity cost, etc. So it wouldn't be prohibitively much to ask the laundering network to invest, if I'm doing these numbers right.
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.
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.
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.
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.
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.
and in a country where Western Union is actually the preferred payment option, the transaction fee allows a recipient that may not even own a computer to go to a shop in their village and collect local currency they can actually spend on the things they need
>much cheaper than a Western Union or SWIFT wire transfer
But in practice, even when a user moves bitcoins between their own wallets its results in that transaction getting registered in the block chain. Which is very unnecessary, costly, inefficient and also may compromise the user's privacy. That's why IMHO some kind of solution whether it is lightning network[1] or sidechains is needed.
This is a dramatic oversimplification of the Bitcoin network.
First, the hashrate's primary purpose is not mining transactions, it's securing the network. That includes transactions that have already been mined, and includes all of the bitcoins that everyone is sitting on. For me personally, Bitcoin's primary purpose is not moving money around but rather parking my money safely in an asset that is not subject to the whims of politicians. Giant price swings are inconvenient, but I am willing to accept the variance because I know my money cannot be seized, my transactions cannot be censored, and the money will not lose value because my government decides to print a ton of cash. It is important to me that the network have a high hashrate whether or not I am actively moving my money around, and in fact most of that $11,000 is charged in the form of inflation, not in the form of transaction fees. Inflation penalizes the people holding onto their bitcoins, where fees penalize the people moving money around.
Secondly, the cost of a transaction is a relatively minor concern when it comes to the blocksize. What is most important is that the network is secure, and cheap transactions come as a secondary concern. If you want cheap transactions, you can use a centralized system which does not need to worry about all the problems that accompany decentralized money. If you want decentralized transactions, you're going to need to pay the minimum price necessary to make sure that the network remains both secure and decentralized, and (unfortunately) 1MB (soon to be ~1.75MB, thanks to segwit) per 10 minutes is about all we can do safely.
Explaining why 1MB is approx the best throughput the network can get is a much longer conversation, but there are signficant safety concerns related to hardforking the network, related to slowing down block propagation (larger blocks propagate slower, and if blocks are taking more than ~6 seconds to propagate the network you get mining centralization pressures), related to the cost of running a full node, related to the fact that a fee market is going to be what secures the network in the future, and related to a handful of other smaller issues as well. It turns out that a number as simple as 1MB has a large number of broad effects on the system as a whole, and changing it even slightly can have pretty dramatic effects in unintuitive places.
Finally, in practice there is not a linear correlation between hashpower and block subsidy. Lots of miners have been preparing for the halving for months, and therefore have only expanded their operations to what they will be able to sustain after the halving. There are at least a few large mining companies out there that are actually spending less than half the price of a bitcoin in electricity and maintenance for each bitcoin they mine, meaning they will not lose any hashrate at all when the halving arrives. There was some concern about this at the Scaling Bitcoin conferences, so me and a few others probed deeper into the probable outcomes of the reward halving, and we found that most miners had a plan which did not involve them turning off their rigs even if the price did not rise. Some of them are actually already locked into power agreements that will penalize them heavily if they don't consume the electricity.
It's difficult to predict what the halving will do to the price. We know that when the halving occurs, ~1800btc per day of sell pressure will disappear. That most likely means that the price will rise, but there is absolutely no reason to believe that this will cause the price to double.
I personally am predicting that, regardless of price movement, we will see the hashrate drop less than 15% in the month following the halving. I have done a moderate amount of research in arriving at this conclusion, at least more than your typical armchair speculator.
You're right, I've left a lot out here for simplicity. I've ignored that miners have costs other than electricity, that miners buy their electricity for cheaper than the average american, that most miners make a profit, that currency exchange markets have friction, that miners provide a more valuable service to the network than creating coins, that the average block has less than 2000 transactions, that it is possible to fit more than 2000 transactions into a 1 MiB block, that the current price reflects expectations of the post-halvening future, and so on. My estimate could be half or double the real number, though I think it is in the right ballpark. I really wanted people to take away two things from that comment which I'm not sure I got across:
1) The cost (in money and energy) of each transaction will increase as the value of each coin increases, and decrease as the number of transactions per block increases. If we assume that the number of transactions will increase faster than the value (which I think is a reasonable assumption), then the cost per transaction will fall over time.
2) When all 21 million coins have been mined, the block reward has tapered off to zero, and miners are dependent on transaction fees, the cost (in money and energy) of each transaction will be much lower than today. You can think of the energy currently being burned on mining new coins as being the tangible asset which backs those coins.
This is off topic, but... when the blocksize changes, the blockchain will fork, right? What happens to bitcoins 'in' wallets that are represented in the 'old' blockchain? Do they have to be coverted/sent to the new blockchain at some point?
A wallet is really just a private key. All coin ever sent to that private key is recorded on the blockchain forever. Your client looks in the blockchain to determine your wallet's value, it isn't really storing anything.
When the blockchain forks, anything before the fork is in both chains, so nothing is lost.
To see why, think about this at a much coarser granularity: just people who operate miners. Suppose a new version of the BitCoin software comes out which makes you lose all of your money. Will you switch over to that software? No, you'll just keep the old version that lets you keep your money. What about the peer pressure to switch over? Well, if all of the peers stand to lose by switching over, your peers are likely going to band with you, precisely to not switch over.
Therefore any change needs to be backwards-compatible. Software changes come in the form of updates, "Before block #123456, block sizes will be X; for that block and after, block sizes will be Y," issued some months before block #123456 is likely to show up.
It's actually a parallel to something where I saw an agnostic philosopher debating some Christian fundamentalists who were totally out-of-their-league. They were supporting a divine-command-theory of morality. He was saying something like, "That's stupid: your morality could change tomorrow; God could tell you something different, like that you have to kill babies, and then that would become the Right Thing to Do -- but that's in the face of every moral intuition we have."
They were saying something like, "of course, God can't change his mind because he's eternal, so that's a non-issue. The laws of morality are therefore eternal and your example is impossible."
He replied, "No, I'm saying that God's eternal rule could be, 'Before 6AM on May 15th, 2016, GMT, killing babies shall be bad, and afterwards, it shall be everyone's duty.' It's a perfectly eternal rule that does not require God to ever change His mind. And you're saying that you're totally comfortable if that turns out to be the way that God's moral laws work, right?"
To a temporal agent, an agreement about the structure of eternity can always be renegotiated among those agreements which amongst themselves agree on the past and nearby future.
Those older examples suffered from the "double spend problem" where you could spend the digital currency twice (or more). Kind of like cheque fraud.
The Proof of Work part of bitcoin (the part that consumes all that electricity) creates a consensus record so that if double spends are performed, only one of them will stick. Now double spends are a "feature" called "replace by fee."
Preventing double spends is worth millions to investors, so that's why it continues.
Yes, and maybe that was the main obstacle to implementation.
Reading some of the original literature, and glossing over the textbook, it seems like many of the issues involved with double spending and counterfeiters are _eventually_ resolved with someone going to jail, rather than being able to resolve the financial payments in order. A naïve solution - which might save some energy - what about using signed timestamps from an adequate authority?
No, I'm saying the authority would provide resources to enable transactions, not an authority that controls transactions, which is actually what the distributed network of miners does in the case of Bitcoin.
In this case, the authority would provide stamps for transactions.
Well, ideally there would be a scheme where the authority facilitating transactions (with timestamps in this case) wouldn't be provided identifying information.
Some are working on a consensus system called proof of stake which does not use energy. It is not clear whether it will be fully secure, etc., but if you read about this stuff decades ago you might want to google and research primarily Bitcoin and Ethereum.
I've been using central ledger currency systems (i.e. logging into my bank's website and issuing payments) for longer than Bitcoin has existed. Decentralization is the entire point of Bitcoin. Take that away and you aren't left with anything that wasn't already done long ago. What you're proposing is something that banks have already been doing widely for decades.
> Take that away and you aren't left with anything that wasn't already done long ago
And that is exactly my point. There are very interesting ideas in digital currencies/digital cash that have no representation in Bitcoin or at all.
By using Bitcoin, like using your bank's website, you still need an Internet connection to use your currency digitally.
However, it's possible to create a digital currency that doesn't have to be plugged-in to a network to operate. Being able to send an e-mail with a cash value integrated in its data is something that hasn't been done long ago, or even yet today.
Even better, some digital currencies could (conceptually) be sent in a paper letter as cash.
Whether the value is created algorithmically or by bankers is a separate, economic debate, and really less interesting, in my opinion, than the technology itself.
> By using Bitcoin, like using your bank's website, you still need an Internet connection to use your currency digitally.
You can do all sorts of things with Bitcoin without needing to be attached to a network. You can have an address that has value associated with it and then print a private key as physical Bitcoin -- variants that have been done include coins, bills, paper wallets, and OCR-able backups of regular wallets. In a high security situation you can have Bitcoin running on an offline computer and sneakernet signed transactions from it to avoid ever exposing it to the Internet.
> However, it's possible to create a digital currency that doesn't have to be plugged-in to a network to operate.
Yes, like all of the above.
> Being able to send an e-mail with a cash value integrated in its data is something that hasn't been done long ago, or even yet today.
You lost me. How does email work without being attached to a network?! If you're giving us access to a network, why not just use Bitcoin? If you meant something like snail mail, well then, again, see above.
> Even better, some digital currencies could (conceptually) be sent in a paper letter as cash.
Yes. Like Bitcoin.
Or are you truly trying to propose some kind of digital currency that never requires network access? How could that possibly work? If network access isn't allowed, how do I know that you haven't already sent the same "digital coin" that you're sending me to ten other people? The double spend problem is real. Bitcoin solves it. I don't see how a solution is possible that doesn't involve some kind of communication.
Digital implies something that is based in information, which doesn't imply a computer network. I won't pretend to be an expert, and I might have been living under a rock concerning Bitcoin, as it is not something I use.
The article link I posted (for a research paper, second level post), plus the original sources and works that cite it specifically discuss digital or cryptographic cash which follow six properties, including anonymity and some measures of usefulness.
Bitcoin achieves this, but it's also possible to achieve with a central authority or coalition of authorities. Interestingly, the consequence of double payment or false payments is to have one's identity revealed or to effectively assume debt. The fraudulent charges are exposed as IOUs.
The proof of work portion of Bitcoin, which I think is bothersome and wasteful, is related to the money supply. If a currency were tied to real funds or precious metals some of the burden would be lifted, but a large database would still be required.
Using a blockchain to implement a trustless distributed ledger is such a fundamentally important revolution in digital currencies that you can compare it to what Einstein's theory of relativity did for physics. They both caused complete sea changes in their fields. Citing a paper from the early 1990s on digital currency is like citing a paper on physics from the 1800s in a technical discussion about GPS.
I am not being hyperbolic. I realize what it may sound like, but solving the double-spend problem without a central authority was the tricky issue in digital currencies that vexed computer scientists for decades. Bitcoin solved it. The double spend problem falls under the category of (b) from the paper that you cited, and note that said paper does not solve it.
If you are at all interested in digital currencies, and it sounds like you definitely are, then you owe it to yourself to read up on Bitcoin, to understand how it works, and to understand the problems that it solves. There has been a huge explosion in the field since the release of Satoshi Nakamoto's original whitepaper.
To answer some minor points:
> Bitcoin achieves this, but it's also possible to achieve with a central authority or coalition of authorities.
This has been possible for thousands of years. You just have a central ledger that is locked up and inaccessible somewhere. That's how all existing banking systems work. I'm not sure why you keep bringing this up; it's not relevant because it doesn't solve the problem that Bitcoin does. Saying that it can be done with a central authority is like telling Gugliemo Marconi that he can make contact with the other receiver if he just lays a wire between the two. Yes, it's true, but it misses the point entirely; he was trying to invent wireless communication, not create yet another telegraph system (which had already been around for decades).
> Interestingly, the consequence of double payment or false payments is to have one's identity revealed or to effectively assume debt.
Bitcoin allows strong pseudonymity while maintaining protection against double spends, while subsequent iterations of it building on the blockchain idea allow for strong anonymity (see Darksend).
> The proof of work portion of Bitcoin, which I think is bothersome and wasteful, is related to the money supply.
The proof of work portion is required to implement a system that has the properties that Bitcoin has. Relativity is tricky and hurts my brain, but if I want to make a GPS satellite that works, I have to use it.
> Citing a paper from the early 1990s on digital currency is like citing a paper on physics from the 1800s in a technical discussion about GPS.
Like Maxwell's equations?
Anyway, for (b) security it claims to be secure by providing a way for the bank A to reveal the identity P of the double-spender mathematically from the duplicate spent coins.
I agree that these ideas solve different issues.
Bitcoin is set up for making payments to individuals far away and anonymously (or pseudo anonymously). This makes it possible to say, order a pizza with Bitcoin. By the time the pizza is done being made it's possible for the merchant to verify the transaction. Completing a transaction on the sneakernet would be akin to carbon-copying a credit card when the network is down.
These other digital currency ideas are different and seem easier to implement for making a purchase at 7 Eleven and leaving within 10 seconds or making purchases without a network and knowing that the value is there.
Yes, it requires banks, like checkbooks require banks, but a digital currency can offer some benefits that paper checks don't, and it shows that Bitcoin has limitations. The drawback would be negotiating an agreement with a financial institution.
In terms of the article, Bitcoin makes it very easy to lose money, especially if someone loses their private key.
Maxwell's equations don't yield workable GPS. You need general relativity. Similarly, you need a blockchain (or some similar solution for the double-spend problem) for a workable digital currency.
> Anyway, for (b) security it claims to be secure by providing a way for the bank A to reveal the identity P of the double-spender mathematically from the duplicate spent coins.
Yes, exactly, it needs a centralized authority (the bank). You're citing a digital currency scheme that was never workable enough to be implemented and that was state of the art 25 years ago, which is an eternity in the world of digital currencies. Can we please talk about what's state of the art today?
> These other digital currency ideas are different and seem easier to implement for making a purchase at 7 Eleven and leaving within 10 seconds or making purchases without a network and knowing that the value is there.
... umm, like a credit card? That solves your use case of being able to pay for it quickly. It's also been around for decades. Or for something that works when the network is down, how about a simple smart card, like that can be used to pay for bus rides? Again, decades-old technology. Not revolutionary now. Still requires a centralized authority. You're talking about long-solved problems.
If you want to do it with no central authority, which is the key thing, then now we need to use blockchain technology. If you're willing to accept the low risk inherent in 0-conf transactions, you can use Bitcoin for your theoretical "buy something cheap at 7-11 in 10 seconds" use case. If you want to reduce risk further, you can use Lightning Network or similar, which is a further evolution on Bitcoin that does allow ironclad sub-second confirmations. I highly suggest that you look into it. It sounds like what you are most interested in.
I don't know how else to make this important fact clear to you: If you have a centralized authority, then there's nothing new under the Sun, and it's all possible with decades-old technology. It's not really a digital currency though, it's just a method for moving entries around in a centralized digital ledger. It requires trust in banks and governments. Decentralized digital currencies like Bitcoin require only trust in math. This is a huge difference in kind, not degree, but you keep suggesting schemes that don't even have this important property. I get that you don't think it's important, but at least maybe try to understand it?
Well, whether or not you agree, there is some newness.
The Okamoto-Ohta scheme might seem like handing out gift card codes to people as payment to you, but there are interesting mathematical properties to it that move responsibility further up the ladder than simply saying you're SOL if you've been handed a spent card number.
If you hold BTC you might not want to hear that Bitcoin has faults, but it does.
Outside of practical problems, it's labeled as a cryptocurrency but the design of it, besides wallet keys, uses little cryptography. The scheme of signing cash values to anonymize spenders' identities unless counterfeiting occurs involves much more cryptographic math. If you try to research this field on Wikipedia for instance, only 'decentralized' cryptocurrencies are explained in the cryptocurrencies article, which involve little cryptographic math. Even if you think what I'm describing is ancient history, it is not well known to everyone.
Proof of work itself is not very much based in cryptography, even if it's implemented with hash functions, so the real breakthrough (on the crypto side) is signing accounts with public/private keys which isn't revolutionary to anyone who has used RSA before.
Bitcoin is revolutionary like bittorrent is, and in this case I'm not interested in the P2P implementation. I do understand its value to users of Bitcoin, however. But in some ways, beyond its implementation which is quite complicated, the block chain itself is completely centralized, while the miners are decentralized.
A scheme with issuing banks might be centralized but I'd rather call it ad hoc.
Credit cards and smart cards place trust in a different position than electronic cash. It provides identity information to the merchant, and can allow the merchant to set the price of the transaction. It's also possible to reverse charges or overdraw accounts. The case of double-spending in the Ot-Oh is an instance of fraud and the perpetrator is then identified. This is a completely unique mathematical argument, and yes it is new, if it hasn't been implemented in the 25 years since it was discovered.
The two sides of this argument are what is more important: the mathematical basis or the software implementation.
It also might be the case that what you are entertaining is the discussion of a currency and what I want to discuss is the implementation of a digital form of exchange.
So, if Bitcoin Bank A issues Bank A digital cash, backed by Bitcoin, then merchants or friends that accept bank A's digital cash can make offline transactions with digital currency in the way explained above with specific programs or devices. Starting accounts would require more than using Bitcoin, ie. providing identifying information like SSN, but the commonplace use of the digital cash would be secure and convenient while being arguably more reliable/convenient than either cash or credit cards and faster than accepting Bitcoin transactions directly.
It might be hard to see because of how many uphill battles Bitcoin has had to fight, now that some sellers are willing to accept it, but there are many details to the hand-to-hand transactions that aren't convenient, like messing up fees or needing to wait for blocks to be accepted. Waiting 10 minutes for a charge to pass before getting something out of a vending machine, for example, or having your card information stolen by a faulty vending machine card reader for your run-of-the-mill credit card.
The truth is both BTC and other digital cash forms have the same problem - there are no chargebacks. So if you purchase something at a distance with either, there's no way for a refund if someone runs off with your money.
So to summarize - yes, there are trade-offs between any implementation and there are differences between currencies and forms of currency, which are not totally exclusive, and I'm still learning about Bitcoin, so thanks for the information.
> but there are interesting mathematical properties to it that move responsibility further up the ladder
That's the thing, with decentralized digital currencies, there is no "further up the ladder", nor can there be, so this property isn't appreciated. And decentralized digital currencies are the only ones that are finding any traction.
> Outside of practical problems, it's labeled as a cryptocurrency but the design of it, besides wallet keys, uses little cryptography.
You should read up on the latest developments. Bitcoin is essentially a platform now that has hundreds of different technical innovations (most of them involving cryptography, which you seem fond of) built either on top of or with modifications to. Everything from segwit to Lightning Network to n-of-m escrow transactions to Darksend to sidechains to blind transactions to Ethereum to Namecoin etc. etc. etc. You could spend months reading up on all of this. It's all made possible thanks to Bitcoin. Also, did you know that Bitcoin has a built-in scripting language (from the very beginning) that allows all sorts of nifty transactions that are way more complicated than "Send N BTC from A to B"? You should look into it.
> the block chain itself is completely centralized, while the miners are decentralized.
Huh? Every full node has its own copy of the blockchain. It's way more decentralized than mining, which is limited to a smallish number of pools. That everyone has the same copy of Bitcoin just means that everyone is living in the same objective reality; it has to be the same, otherwise you could never agree on anything. Absent a currency that has intrinsic value such as gold (and there are big problems inherent in that too), and which is impossible for virtual currencies, the value comes from everyone agreeing on where the value is.
> Waiting 10 minutes for a charge to pass before getting something out of a vending machine
Well realistically a vending machine would just do a 0-conf transaction, because pulling off a double spend would be way more effort than it's worth just to steal a soda. But also, you do realize that ten minutes is just a tuning parameter, right? There's no fundamental reason it has to be that value. There are altcoins with faster blocks, and Lightning Network does side-chain transactions that confirm near instantly. It's not an intractable problem, in other words; you just tune some parameters or use something built on top of Bitcoin. People are much more willing to use modifications on top of Bitcoin to solve these problems than they are to give up on the decentralized nature of it entirely and just go with something else. It's no accident that decentralization is the killer feature, and anything lacking it is a non-starter.
There are plenty of centralized financial payment services that are good enough. That ideas in that article you linked to never caught on because they don't add value of the kind that people care about. It's no accident that it was never actually implemented. Bitcoin, meanwhile, just did that one thing, decentralization, but because of that it has been used by millions of people worldwide, and is sitting at a total market cap right now of ~$7 billion. You can't really argue with results. You can keep arguing until you're blue in the face that decentralization doesn't really matter, that all these other things are actually more important, but that's not borne out by results.
> or having your card information stolen by a faulty vending machine card reader for your run-of-the-mill credit card.
This is an unrelated issue related to push vs pull transactions (push is better). Credit cards are pull transactions. Bitcoin is push. Chip and PIN as implemented by credit cards in most of the rest of the world are also push transactions, and also handily solve the problem.
> The truth is both BTC and other digital cash forms have the same problem - there are no chargebacks. So if you purchase something at a distance with either, there's no way for a refund if someone runs off with your money.
Yes, sending Bitcoin using a raw transaction is like sending cash or a money order. No argument there. People are used to those risks however. Also, using the aforementioned Bitcoin Script language, you can write multisig escrow transactions that do allow what are effectively chargebacks. I suggest you look into it. You are arguing many things as being faults of Bitcoin and the related ecosystem which do in fact have solutions.
I've been fairly heavily involved in Bitcoin for about five years now and this is just scratching the surface. I do recommend learning more -- most of your concerns are already addressed in ways that do not compromise decentralization.
It's not centralized though. Each node is independently building and verifying the entire record, based on no criteria other than (a) prefer the longest chain and (b) use blocks you get over the P2P network from other nodes. You are using the word "centralized" incorrectly, or at the very least, in a way that is inconsistent with the way that everyone else in the space uses it. A semantic argument over a word doesn't change the way that things work.
The only centralized thing about Bitcoin is that the logic (i.e. the software rules) that all nodes are using is the same. If this weren't true then there could be no consensus blockchain. But there's a huge difference between thousands of different actors, all who merely happen to be running the same software that determines things by consensus, and then a single authoritative actor who controls everything by fiat.
Problem is that if it was centralized it may be shut down. Moreover, the central entity would have to issue money and comply with aml etc and register accounts, thus turning it into a bank.
Almost all currencies are digital today. Bank notes are just a physical transaction mechanism. You could use Bitcoin notes if you want with the private key under a scratch layer. The big difference is exactly that Bitcoin has no central authority. If that doesn't matter to someone he'd be perfectly happy to use state endorsed currencies.
Digital cash doesn't have a scratch-off layer. It has information associated with its minting and mechanisms to be used in spending and transactions.
> ... perfectly happy to use state endorsed currencies.
Unless what you are looking for is a digital currency.
Being able to send $5,000 cash in the form of information is a separate issue from who controls the money supply. If someone wants to exchange that amount without having access to a distributed network of computers, is that more centralized?
What I'm saying is, I would be happy to use an information based currency, even if it means holding a key with a central authority, if it means being able to make free, anonymous transactions easily with a completely digital, offline currency.
That is not what Bitcoin provides. And it isn't possible to e-mail paper bills, either.
That's true. I really wanted to talk about alternate digital currencies so I started by attacking Bitcoin's big blockchain and huge power burden.
I recognize each 'transaction' holds several payments. I find the growing size of the block chain pretty astonishing as well, in an alarming way for users.
This same article gets brought up continually by people who either want to discourage bitcoin use or just don't understand how it works. Disregarding for a moment that their calculations are ridiculous and that the article is over a year old when there was less volume, bitcoin transactions and the energy used for mining are uncorrelated.
The electricity used is the level of security, the number of transactions supported are completely separate and could easily be orders of magnitude larger if the block size gets expanded (which is a whole other issue, but unique to bitcoin at this moment).
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?
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.
> 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.
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".
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.
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?
> 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.
Well, if the entity issuing the TX was colluding with a miner, they'd craft the TX and the miner would add it to their mempool without announcing it to the rest of the network. Then when and if this miner finds a block, it would include this transaction.
Instead of sending the transaction out on the p2p network for any miner to include, you just send it privately to the specific miner you want to mine it. Nobody else knows about it, so they can't include it in their blocks.
The problem (and the reason this really isn't a useful money-laundering method) is that people watch incoming transactions and blocks, and if a block is mined including a transaction that was not seen previously, it's a strong indication that there's collusion going on.
Usually transactions are published on the network and anyone can choose to include them. But a miner can add transactions that no other miner knows about. Usually you don't want to do it because it takes a long and random amount of time for the transaction to go through (you have to wait for that specific miner to win a block). But if you're mining it yourself or in collusion with a specific miner, that's a tradeoff you can make.
Hand the signed transaction to that miner instead of broadcasting it to the network. It'll only get mined whenever that miner successfully mines a block.
"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.
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.
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
There is no reason why you need to transmit any transactions. In fact your best chance of executing a double spend is similar, these kind of attacks are called finney attacks.
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.
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.
Any miner that would want to steal a block fee would have to mine two blocks in succession before the rest of the network gets another one. It's possible, but quite unlikely, and if you don't pull it off you've thrown away a lot of hashing cycles. The only way to make it probable is to control a majority of the network hashrate, but in that case, there are much larger problems afoot (i.e. a 51% attack).
It does place an upper bound on the total amount of BTC that can be laundered through transaction fees on a single block, though. I won't do the math right now but it's some multiple of the block reward fee that depends on what percentage of the network hash rate you control.
Fortunately (?) for the would-be launderer, the average pool is mining a good deal more than one block per day, so you just spread your laundering across a series of blocks.
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.
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!).
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.
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.
> 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?
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.
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...
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.
I'm sure we all understand the feeling you describe and how irritating it is. I certainly do. But the essence of civility (or at least the hardest part of it) is containing that irritation and not letting it determine one's reaction. This is a work in progress for all of us, work that is necessary to make HN the kind of place we want it to be.
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.