I see multiple issues with the scenario in the OP.

1. You say that $100B will be spent on mining by retailers, and assume this must take the form of owning mining hardware themselves to the exclusion of freelance miners. But it seems they can just as easily sponsor it in other ways, such as assurance contracts payable to miners or paying PPS pools directly. The people actually doing the hashing could still be freelancers, some of them at least.

2. "They want their customers' transactions processed quickly" - I don't find this likely. Walmart isn't going to wait 10 minutes (actually much more, see below) to accept payment from a customer. They'll accept 0-confirm txs, and rightfully so - 99.99% of their customers won't double-spend. So the confirmations really only affect their ability to use these funds further. The idea that they will pay 5% of their revenue to get the funds maybe an hour earlier is ludicrous - that's a 188-digit APR (better than Pirate!)

Also, I don't think most Bitcoin payments will take the form of transactions. There will be intermediary services with various trust requirements (Bitcoin's powerful scripting allows for some options with little trust). So the customers should be able to do instant irreversible payments without needing confirmations for the payment.

3. There will be people sending transactions which the retailers don't care about, and they will pay fees to get them included. Depending on the retailer's policy on accepting transactions for their fee, this could leave some revenue to sponsor freelance mining.

4. You speak of this as a scenario in which Bitcoin is successful. I don't. If mining is dominated by big retailers who only care about their own transactions then Bitcoin can hardly be thought of as decentralized, which defeats the purpose. (The incentive structure which makes it feasible to do freelance mining if one so chooses is more important than how many different groups end up actually doing it. Which is also important, of course.)

5. You present a false dichotomy between "not use Bitcoin" and "pay as much as Bitcoin saves them on mining". Even as a "first order estimate" it fails to take into account that the retailer will only spend money on this if the situation with the spending is sufficiently better than the situation without the spending. If the Bitcoin network functions properly transactions will be included eventually even with a modest fee. The retailer doesn't have that much to gain by adding its own hashpower to the mix. How this plays out exactly depends on the details of the scenario. In a scenario where so few miners would include the transactions to Walmart that it has something to gain by hashing for it, it means that even with its hashing it will be included only in a fraction of the blocks, so the confirmations would still take much more than 10 minutes.

6. Bitcoin would need to be extremely "widespread and ubiquitous" for Walmart to even consider mining or sponsoring it. Maybe it will happen but it will be a long, long time in the future.



Anyway, I guess I agree with the main point - mining is currently a speculative investment, and as Bitcoin catches on it will become less speculative, and correspondingly less potentially profitable.

As planned, the bondholder list has now been finalized.

A test payment has been sent to new bondholders (d9dc20e0ead0aa68cf6fcf3497fe278adc2566aea3140d85b93ce475ece41794), which includes 186 unclaimed bonds which have been donated evenly between The Bitcoin Foundation, Bitcoin100 and SIAI (62 bonds each).

This was followed by a back payment of 0.0198961645 BTC per bond for blocks 201935 to 211343 (60f081b5bf75550bc3a9fce20b6daffa80975504dc96d14b24de3306eb8966d8).

Then a full list of 15566 bonds have been assembled. It was sent a test payment (94b1539b909b1af3c8b22e9c3293d45099e821b2ee47fa83b95c904cd3212e49). The number of satoshis paid to each address is equal to the number of bonds credited to it, so this is a good opportunity for all bondholders to make sure there isn't any problem.

Then I sent coupon payments for recent blocks:

211679 - 212687: 0.0016092739 BTC per bond - 237bed462683b6b49a7d59b9010bc92e3285a3a8373fced4e16d74e282ed2491

213023 - 213359: 0.0007286389 BC per bond - 3a8f68d0993288213d566bd23ae1a36f420763186b4e172065aa2bbc6a135e90

Coupon payments should be more regular from now on. Also, since the list won't change much, there should be no need for more of the annoying test payments.

The Tel Aviv Bitcoin Meetup January 2013 has been scheduled for January 21, 17:30, in eToro, Habarzel 32, Building B, Floor 5, Tel Aviv. See http://www.meetup.com/bitcoin-il/events/97068362/.

It's soft cementing (wet cement?). It probably has some advantages over hard cementing, but essentially it has the same tradeoffs.

It was an intended pun.

I'm not convinced. Even if some of the demand is latent, there's still a lot of depth. Selling 500 BTC would cause about 0.4% slippage, which is not as bad as the trouble of finding OTC buyers.

Exchanges exist for a reason and that reason isn't going away any time soon.

About that - I think it might be worth it to do the talks in English, precisely for the recording to be more broadly usable.

30 minutes.

If you run Bitcoin with this command (as opposed to running it without this parameter), it will look for the database in the E:\Data\Bitcoin directory, and as necessary download it to that directory.

How you use it exactly depends on your exact setup, but assuming you have a Windows machine and a shortcut that points to "C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe", and you want the database to reside in E:\Data\Bitcoin (or any other directory), you should:

1. Move your already existing database to E:\Data\Bitcoin.
2. Change the shortcut to point to "C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" -datadir="E:\Data\Bitcoin".

The blockchain is stored in the data directory, which can be configured with the datadir parameter. For example:
Note that the wallet file is also stored in the data directory.

Symlinks may also be of use to you.

Not yet.

Cool.

Maybe. I think the ability to recover is important, both practically and for the theoretical "correctness" of the system.

I used "Pure PoW" in the narrower sense of sticking to the longest branch (which depends only on the current observed data and not the history of receiving it).

Thank you for this. I would however like to emphasize that table 2 is probably the least reliable item in the paper, it assumes a specific model for an attack which is likely to diverge significantly from reality. (And doesn't even follow the math of that model to the end because of the complexity of the calculations.)

I see what you're saying. When you say it's only slightly higher than breaking ECDSA, you mean that THIS PROBLEM IS SO EXTREME AND URGENT THAT WE NEED TO FREAK OUT ABOUT IT RIGHT NOW!  No? Ok.

Without cementing, new nodes use the longest branch, as do all other nodes. In case there's a majority attacker, he can make attacks but at least the nodes are consistent with each other.

With cementing, if a certain attack is executed, new nodes will be detached from the rest of the network (e.g., the veteran network is cemented on a shorter branch, but the new node will join the attacker's longer branch). At the very least it shows that cementing doesn't make the network (where "the network" includes the ability of nodes to join it) immune to such attacks.

Yes, but checkpoints are much more infrequent, and require upgrading the client.

If the IP vote overrides the longer chain, it is not clear you still need majority hashrate. You can use your IPs to vote on your minority branch. How this works exactly will depend on the specific implementation and attack.

Also, the cost is additive. You'll need the cost of multiple IPs + cost of hashpower + cost of bitcoins. Tripling the resource cost isn't so impressive if the attacker might have a thousand-to-one resource advantage.

Suppose you're a new node joining the network. Of course you are not cemented on anything. You see some nodes broadcasting a short chain and some an incompatible, longer chain. Who do you believe? If you default to the longer chain, you could fall right into the majority attacker's net. If you use something else you make it easier to carry out an attack without majority hashrate.

In this way the attacker can prevent new nodes from joining reliably. Not "some poor victim somewhere will be attacked". Nobody can join the network. Unless, of course, we spend some time thinking about a framework for higher-level overriding.

And I will repeat myself and say there are two primary attacks with majority hashrate - double-spending and rejection. Cementing helps with one. What about the other?

I agree, when we do start seriously thinking about this, we will need more knowledgeable people to take part.

By running multiple nodes spanned over various IP addresses, of course.

Maybe. Let's put it this way - cementing is simple and obvious, if it was that great Satoshi would have implemented it from the start. So we shouldn't do any "quick fix" without a solid understanding of the reasons for the decision and a thorough analysis of the dynamics of the new system.

AFAIK no, and depends on the definition of "naturally" but essentially no.

A network fork is when one client thinks some block is valid and another client thinks it is invalid. Short-term forks are normal but longer-term ones are effectively splitting the original network into two (or more) separate networks.

Yes, then 75% of the clients will be on one network and the other 25% will be in a separate, incompatible network (assuming there was in fact a reorg that required making a choice). In fact those that chose cementing may be further divided between them based on what they observed during various reorgs.

However, if the 75% is by hashrate, then those clients will eventually build a longer chain, which the non-cementers will switch to, with a massive disruptive reorg. Which will happen again every time there is such a fork.

If the user makes a choice then the clients will fork based on what their users choose (unless, of course, for some reason all users' choices lead to the same results).

Not sure if serious.

It's not very robust. Even with the IP range restriction it should be easy for an attacker to game this.

Proof of Stake is exactly an attempt to do a majority vote based on the harder-to-fake ownership of coins. It may or may not have a place in the hierarchy.

I can see the marketing copy - "With Bitcoin, you are in full control of your money, and payments cannot be reversed! Unless you're one of the 1% whom we don't care about, and then payments to you could be completely bogus."

Seriously though, I don't disagree but moving away from pure PoW is a fundamental design change and we need to consider it carefully to keep disruption and unwanted side-effects at an absolute minimum. If nodes aren't safe when participating in the network then the network is meaningless.

And as mentioned, if we consider majority attack to be plausible we need to protect against rejection attacks, not just double-spending.

See my post above for various motivations. They are all "economic" with sufficiently broad usage of the term, but not in the most direct sense.

This isn't a client-level choice, it's a network fork.

The incentives to carry out the attack are well documented.
1. Someone could take a large short position on Bitcoin, carry out the attack, and profit from the panic selling.
2. Banks and similar organizations can do it to maintain their monopoly.
3. Governments could do it for fear of illegitimate uses of Bitcoin.

This is just a form of cementing. The obvious hurdle is that different nodes see things at different times and thus this is not a signal that will converge to universal agreement (unlike vanilla longest-branch). More concretely, a node could be stuck on the wrong version. This can be used only if there is a higher-level signal that can override the cementing. (Currently it's hardcoded checkpoints, but they're too infrequent to be practical).

Also, in itself it is useless against attacking by rejecting all other blocks and excluding all transactions.

Since we're talking about governments and such, they can surely fund the development of ASICs more efficient than those available on the market, followed by mass production, in a quantity that takes into account from the start how the market will look like 1-2 years in the future.

It is well known that if someone has sustained majority hashrate and wishes to use it to damage Bitcoin, it is bad.

So the options are:
1. Hope no entity wishing to destroy Bitcoin will obtain majority hashrate.
2. Adopt a more comprehensive branch selection solution which is harder to attack.

#2 would probably take the form of a hierarchy of various levels of synchronization signals, each of which can be cemented but overridden by the next, slower level. I imagine one of the top levels will be broadcasting a "block hash of the week" all over the internet and via TV, radio, newspaper, billboards etc. This way, if someone gets stuck on the wrong version, he will notice.

To protect against excluding all transactions, a DAG structure may have to be adopted.

The incentive to attack them is correspondingly small, however. This of course does not apply to MM alts; also, even with Litecoin it did not have a serious attack yet (that I know of), and hypothetically it could one day surpass Bitcoin in total compute power.

Depends on the kind of pruning. Also, even with pruning implemented there are still expected to be archive nodes.

All these transactions will become invalid and will remain so forever (assuming everyone now builds on the attacker's branch and nobody replaces it with yet another one). It's actually worse than what you described because transactions can have multiple inputs. The attacker will get his 1M back, and also all coins which trace back to the original double-spent transaction (which can be much more than 1M, even all coins in existence) will be shuffled around.

However, AFAIK the transactions aren't literally erased. The current client version at least keeps blocks which are not part of the main chain, it just doesn't do anything with them.

I think that if a block is invalidated, all transactions in it which are not double-spent go back to the memory pool and can be included in the next block. Even if not, the client that originally sent the transaction still has it and can rebroadcast it, it is still just as valid.

See a, the client keeps forks, however this might change when pruning enters the picture.

The number of unclaimed bonds is down to 186.

Some bondholders haven't responded with a payment address despite two email messages sent starting a week ago. I will wait until the beginning of next week before I split these bonds between SIAI, Bitcoin100 and the Bitcoin foundation, and proceed with regular coupon payments.

Since these bondholders have filed a claim with neither me nor GLBSE in almost 3 months, there is no other data about them other than the email addresses I received, and it is unlikely they will respond after not having done so for a week and a half, I think that's the most reasonable option.

Why do you think an attacker is more likely to make multiple spends from the same address than a legitimate customer?

An attacker trying to double-spend 0-confirm will likely use a Finney attack. He may do it with several merchants at once but it will likely be from a different sending address per merchant.

The traditional method (which I think is not yet completely implemented) is to wait a few seconds and check that none of your peers knows of a conflicting transaction, and hope the attacker won't do Finney. This is more than fine for buying coffee; for buying a car, not so much.