Right, I wouldn't be surprised if Grue's ADSL connection was hurting the ability to mine profitably even with the current block sizes. If you have to pay the same as your competitors for hardware and electricity, a competitive market should punish even a fairly small persistent disadvantage that your urban competitors don't have. In the same way, there will be large parts of the world (including here in Tokyo) where you can't mine profitably long-term in a seriously competitive market because electricity costs too much.

If we're thinking about system-level attacks, the relevant people to think about are the people who actually will be doing the mining, and we should assume that in a competitive market, everything about their setup will be reasonably well optimized. That makes high-end connections the relevant factor here, and they may even be growing _faster_ than Moore' Law.
http://www.sqw.co.uk/sqw-commentary/the-urban-rural-digital-dividewider-and-wider

(Overall bandwidth seems to be growing a bit slower than Moore's Law, presumably because the connections of unlucky people like tvbcof and grue in rural areas of countries with disfunctional telecom markets pull down the average...)

Nielsen reckons network growth is a bit slower, but still exponential. He has network speed increasing at 50% per year, while Moore's Law works out at about 60% per year.
http://www.nngroup.com/articles/law-of-bandwidth/

That's not a change, that's the whole point of banks.

The model is:
1) You lend your money to the band, ie you trade your money for a debt.
2) They then lend the money to someone else. At that point its no longer the bank's money either.
3) Hopefully the someone else pays the debt back with money, and the bank can pay your debt back with money.
4) Failing that maybe some kind taxpayer will pay to make up the difference.
5) Failing that the people who lost your money hope you'll blame the whole thing on the European Commission.

Out of interest, what's the specific cost per transaction, in USD, that you think will price out Satoshi Dice while keeping things that are "legitimately" on the block-chain viable?

If nearly all the actual commerce was happening in Litecoins, and Litecoins had solved the scaling problems that Bitcoin hadn't, it's not really clear that people would still want to hold Bitcoins.

The normal thing to do when you run into serious scaling problems is to shard. Sharding is always a big PITA, so you don't do it until you absolutely have to. (Half the payment has confirmed, but the other half hasn't yet, because you're spending coins from two different shards...)

But right now Bitcoin is scaling fine. It's not radically decentralized, and hasn't been for a long time, but that ship sailed when people started mining on expensive, dedicated hardware rather than using the spare CPU cycles on boxes they were running anyway. Capital-intensive commodity businesses have huge economies of scale. They are never cottage industries. You can't run a profitable steelworks in your garage. We may not like these economic facts, but tinkering with irrelevant things like the block size isn't going to change them.

I think most people would agree with that, but it's worth saying here that keeping the ceiling where it is as we get ever closer to it isn't necessarily the cautious move.

To stick with the aircraft analogy, we're flying at 1000 meters towards a 1500-meter-high mountain. If we do nothing, we hit the mountain. There may be some legitimate concerns about whether the plane will be OK at higher altitude, but there are also serious concerns about what happens when the plane hits the mountain. The fact that we've been flying along happily at this altitude over open sea for quite a while before we actually got to the mountain doesn't mean that everything will be OK at the same altitude when we do hit it.

Specifically, we've always had reasonably low transaction fees. We have no idea what would happen to the economy with high transaction fees, and there are some very plausible worst-cases, like Bitcoin losing in the marketplace to an alt-coin or another technology, and most of that $1B+ going up in smoke. The people advocating keeping the limit low are generally optimistic on how great it might be to hit it (we'll land softly in a blossoming forest of off-chain solutions!), and also of the opinion that we're going to hit a mountain sooner or later anyway so it may as well be sooner. They may even turn out to be right. But they're bold, not cautious. The cautious move is not to hit the mountain.

If you were also prepared to take coins out of circulation by buying them if the price dropped too low, this might work. You'd effectively be the central bank. The hitch is that people would have to trust you to be honest and not get hacked.

The p2p way to do this is for the network to get information about the value of your coin (this is the hard part) and allow people to create new money when the coins were too weak, and destroy it when coins were too strong. You could incentivize people to destroy coins when they were too weak by giving them a voucher to create coins next time they were too strong. Miners could enforce this: They at wouldn't recognize coin creation operations unless they agreed the currency was too strong, or coin destruction operations unless they agreed the currency was too weak.

The markets should know that this will happen, so they should price it in and move the change in spending power from the future to the present.

Put another way, if the average Bitcoin trader thought the Bitcoin would be at $260 this time next year, why is some chump on MtGox willing to hand over his Bitcoin to you for $130? And who are all the other morons who are standing by and letting you take $260 of money off the said chump for $130, rather than offering to take it off his hands for $140?

This is what I don't get about the hoarding theory. If it's rational to hoard, it's also rational to buy, and if it's rational to buy the price should rise. And it should keep moving - fast - until it gets to the point - there must be one somewhere - where it's not rational to buy any more, even bearing in mind the future money supply. And at that point, it's not rational to hoard any more either.

I suppose it would be possible that some services would actually ask people to use particular shards, but it's not really clear they'd have much advantage from making their users jump through the extra hoop. I suppose it's possible that people would somehow decide that some shards were worth less than others, and that would become a self-fulfilling prophecy; I remember in Central Asia in the mid-90s people had somehow decided that older US dollars were worth less than new ones, so they were.

But to fend that kind of thing off I think you'd have to design it with the goal of making distribution of coins among the shards as arbitrary as possible. If you were starting with Bitcoin, you'd split the chain when it got too big and assign outputs to one or the other at random, rather than doing what people on this thread suggested and having different shards for different purposes.

If I've got this right, since addresses are basically just key pairs, you wouldn't need to send your coins to an _address_ on Shard 9971. All addresses would work on all the shards. That reduces the risk that different shards will have different values, because the vendor asks you to pay X coins to address xyz, they wouldn't know which shard the money would be coming in on. If all the coins on all the shards buy the same amount of stuff, they all have the same value.

So if you had 100 coins on Shard 17, you could just send them to a vendor's address on Shard 17. When the vendor wanted to spend them, they would also send those coins on Shard 17. Most of the time you wouldn't need to make atomic transactions across chains or anything difficult like that. Obviously everybody's client would need access to enough data to do SPV on all the shards it had coins on.

The fact that the money was split into different Shards could mostly be hidden from the end-user, in the same way that it currently hides the fact that your coins are made up of different amounts in different outputs. The only time you'd have a problem would be when you wanted to send 100 coins at once, but you had 40 coins on Shard 17 and 60 coins on Shard 9971. In that case you'd have two options:
1) Send two transactions, one on Shard 17 and the other on Shard 9971. The vendor will give you your stuff when they get both. (Again the client could take care of this without bothering you about it.)
2) If you need the whole payment in one transaction for some reason (maybe it's a fancy escrow contract or something), _then_ you have to swap with somebody on one of the other shards.

(2) may not turn out to be too important if (1) works well, but trading between shards wouldn't _necessarily_ have to be a clever atomic p2p thing. It could just be the equivalent of the current mixing operations - you send someone with a good reputation some coins on Shard 9971, and they send you some back on Shard 17. You might also have the client set to do these operations in the background to defragment itself and consolidate your coins among a smaller number of shards. Obviously having lots of people routinely taking part in mixing operations for routine, non-illegal purposes has some anonymity benefits, too...

Clearly there's a bit of inconvenience there compared to the current arrangement, but the advantage is that it would allow Bitcoin (or ShardCoin, if Bitcoin didn't want to do this) to scale unto infinity. Whereas right now everyone seems to think there's a point _somewhere_  where you can't scale because blocks get too big to transmit fast enough, or you run into some other limitation and fees go up to choke off demand. (People disagree about where this point is, and whether the community should decide by fiat or just let the miners figure it out.)

PS Scuse the thread necromancy.

I was thinking we'd have to make a thing like Bitcoin but with a way to find out its own exchange rate and print or destroy money, but maybe Liberty Reserve would be good enough for practical purposes. I guess the minimum you'd need would be:
1) An API allowing transactions to be made in real time, and confirmed by third-parties. (Not sure if they have the latter, but if not maybe they could be persuaded.)
2) Non-reversible payments.

It's one of two things that would help mitigate the problems. The other is an alt-coin that controls its own money supply to keep its value pegged to a fiat currency - a kind of parallel crypto-dollar.

That wouldn't solve the problem, but it would help because:
- You'd have functioning price discovery even when the non-p2p exchanges were borked.
- You'd be able to speculate and hedge against exchange rate risk between Bitcoins and the equivalent of dollars, in a censorship-resistant, frictionless environment.
- People could sell stable crypto-dollars for cash in a lot of environments where they can't sell volatile Bitcoins. For example, a lot of shops near me sell online gaming tokens, but it's hard to see them selling Bitcoins because they'd have to keep changing the prices. These could then be traded for Bitcoins on a p2p exchange.

Yes, it's technically feasible. The thought is that the attacker (presumably a large government, or group of governments) would make laws forcing miners in their jurisdiction to follow their rules, not Satoshi's. The idea is then that if miners are able to operate anonymously we'd have a defence, because they'd all just hide behind Tor and the government couldn't get them because it wouldn't know who they were.

The problems with the defence are:

1) It's not enough for the miners to be _able_ to duck behind Tor and hide under the radar rather than comply they also need to be _incentivized_ to go off the radar. There would still be a chance that they'd get found out. ("With an electricity bill like that you're either mining bitcoins or growing weed, let's search your house and find out which...") Better to comply rather than risk going to prison.

2) Small-scale anonymous miners still have to out-compete miners who are working out in the open, which they can't do any more because Bitcoin mining is too capital-intensive, regardless of what you do with the block size. (See my previous post.)

3) The attacker wouldn't have to use coercion. They could use bribery instead. Anonymity doesn't help with that, because thanks to Bitcoin, you can bribe people anonymously. Decentralization doesn't really help either; If anything it makes it worse, because smaller miners have less to lose if their actions reduce the value of Bitcoin compared to the amount they stand to gain.

4) If all that failed, the attacker could just set up the mining infrastructure themselves. It's expensive to set up, but you make up for it in mining revenue. They have access to cheaper capital than the private sector, so they could probably just out-compete the non-compliant miners and drive them out of business. If they weren't able to operate as efficiently they'd need a subsidy, but only enough to cover the difference between their inefficient operation and the efficient private-sector operations, plus a little bit extra to make sure they wiped out their competitors' profit margins.

All this makes me think that the chances of the Tor defence being both necessary and sufficient are pretty minimal. On the other side of the equation, throttling the network and forcing transaction costs up takes away one really effective defence Bitcoin has against hostile government activity, which is the ability to take the world's payment systems hostage so that the government can't shoot it without hitting something it cares about. This is done by getting loads of businesses and non-profits using Bitcoin, right on the block-chain, so that everybody depends on Bitcoin and will stop their donations to any politician who messes with it.

In fact, if you were a representative of a hostile government or somebody trying to protect the legacy banking system, I think the most effective move you could make right now would be to make a video trying to persuade the Bitcoin community to cripple their own currency by throttling it at 7 transactions per second...

That "small markup" has to cover delivery, support, returns and the cost and risk of holding stock, because sales won't be predictable, plus the distributor's profit margin. Someone paying wholesale prices has a huge competitive advantage over someone paying retail.


What proportion of people currently running ASICs do you think are running on somebody else's "free" electricity? Realistically, Bitcoin mining is now becoming capital-intensive, so the network isn't going to be mainly powered by people using it as a roundabout way to steal money from their parents.


There are some datacenter designs that trap the heat and use it for something useful - the classic one is colocating a datacenter and a swimming pool. In practice these have tended to have the same problem as doing this at home, namely that the logistics of putting everything in the right place and getting it running at the right time tend to outweigh the saving. This is particularly true if, like most of the places where humans live, your house is sometimes too hot instead of too cold, because you have to either idle your (expensive, fast-depreciating) hardware or eat the opposite cost of cooling, which will be much worse than a datacenter because your house was designed for living in, not getting rid of server heat.

Before we had GPU mining, then ASICs, this was sort-of feasible: You just need to run software on hardware that you already have, and since there's no capital cost it doesn't matter if you only run it some of the time. But once the hardware started becoming specialized and capital-intensive, as it inevitably did, mining was always going to move out of people's bedrooms and move towards getting done by professionals.

Edit to add:

Some people have made alt-coins that try to come up with proof-of-work schemes that are more resistant to capital-intensive, specialized hardware, and therefore resist the economic tendency to industrialization -> centralization (oligopolization?). IMHO if the OP's that worried about centralization he'd be better off working on one of those, and making clear from the start that _that_ will have a limited block size, probably smaller than 1MB. But it needs doing from the ground up, starting with the proof-of-work scheme - if it still uses proof-of-work.

Right now he's trying to stop people putting petrol in the car for fear of making it too heavy to fly, but his efforts are wrongly directed because there are much more serious problems in getting this particular car to fly, starting with the fact that it doesn't have any wings.

I'm a bit puzzled why the people behind this video think that the _blocksize_ of all things is going to be the thing that pushes small miners out of business. Bitcoin mining is a simple, commodity business with serious economies of scale. Specifically:

* Buying 10,000 ASICs will cost you substantially less than 10,000x the price of buying 1 ASIC.
* A commercial customer buying a lot of electricity in volume will pay substantially less per kWh than a domestic customer buying a little bit.
* Setting up, monitoring and maintaining 10,000 identically-configured boxes will cost you orders of magnitude less than 10,000x the cost of setting up and running 1 box.

Bitcoin is designed to make mining a competitive market, so as more efficient miners show up, less efficient miners will constantly be finding that they can't operate at a profit and forced to close. The network connection for transmitting the blocks is a completely trivial factor compared to the raw economics involved in buying hardware and operating it to turn electricity into hash power more cheaply than anyone else.

Centralization of mining power may turn out to be a serious problem, but if it is, it's a fundamental problem with the Bitcoin design, not something that you can prevent by throttling the network to 7 transactions per second. The only way throttling the network might help would be if it kills Bitcoin's growth and makes mining so unprofitable that only hobbyists bother with it.

OK, so it's regular human-run escrow with some trusted people who have access to the money? (Possibly mitigated by useful Bitcoin features like multi-sig, so the people running the escrow can't steal the money without cooperating with each other.)

That makes sense now, I was confused because for some reason I was expecting something a bit more cyber... And that also answers the riddle of how the exchange rate information gets into the system: The humans in charge of the escrow check it, using publicly available data and common sense.

How do the consensus witnesses get access to the data about what's going in and out of other people's accounts? I don't know Sofort - do they publish that information? Even if they do, you're now relying on them to publish accurate data.

The problem doesn't end there, because if they don't have a way of filtering where their users live then they'll potentially be doing business in all kinds of other countries, and breaking their laws as well.

The ideal solution would be to get the necessary permits for every jurisdiction in the world, but this may not be practical - for example, there are a lot of countries where PayPal can't do business, presumably not for lack of trying.

I think the upshot is that (above-the-radar) exchanges will need some way of filtering their customers by jurisdiction. IANAL, but it may be enough just to geolocate their IPs and ask them to promise that they're in one of the places where the exchange is licensed. Once they've done that, there's no particular need to operate everywhere in the US either. It may actually be less risky to have a lot of little exchanges in different states rather than one big national one, so you don't risk getting everyone's service disrupted because you messed up the paperwork for North Dakota or whatever.

They're not an exchange so they're probably OK.

Here's their take on it:
http://blog.bitpay.com/2013/03/how-fincen-guidelines-affect-bitpay.html?m=1

You want them to come up with a way to publish a transaction on a public network, while keeping it secret from the recipient?