Bitcoin's $137k Jackpot
hackingdistributed.com
hackingdistributed.com
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.
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?
...as long as humans are involved in transactions (by writing software if anything), human errors seem to be bound to happen.
The mistake cost around $225 million.
[1] http://www.foxnews.com/story/2005/12/09/typing-error-causes-...
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.
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...
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.
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.
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.
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.
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.
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.
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.
There are a lot of simultaneous errors going on here...
If you want to validate whether an order makes sense or is a "good idea", the place to do it on the client.
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.
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?
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.
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?
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
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).
I think the article is simply wrong.
I will grant you that the article didn't fully explain the process, and elided important details.
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.
---
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.
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.
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.
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.
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!
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.
[0] https://blockchain.info/charts/transaction-fees?timespan=all...
"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
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.
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.
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?
Here is the article from 1991 for those interested in the original idea: http://link.springer.com/chapter/10.1007%2F3-540-46766-1_27
> ... 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.
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.
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.
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.
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?
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.
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.
A digital cash system with 20 independent banks and offline transactions could arguably be more decentralized.
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.
The whole point of bitcoin is permissionless transactions. It is to make transactions even if the authorities don't want them to happen.
In this case, the authority would provide stamps for transactions.
That's why bitcoin is decentralized. To prevent something like that.
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.
I believe this is because the average block size is less than 1 MB: https://blockchain.info/charts/avg-block-size
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.
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.
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.
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.
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).
The e-currency example you read probably wasn't decentralized.
Totally unrelated and an old argument talked about in depth.
Plus you are conflating the word transaction. It is not how the article used that word.
The person tried to spend 5 cents on the transaction. This is not one days worth of electricity.
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.
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.
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.
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.
> 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.
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.
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
I don't know if that is possible, but if it is it would ensure that a given miner was getting those fees.
http://bitcoin.stackexchange.com/questions/4942/what-is-a-fi...
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.
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.
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.
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!).
Haha, great point!
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.
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?