Gold is almost entirely propped up by central banks who control the majority of the world's supply. They never had to pay for that gold themselves, since it was obtained via the taxing powers of the respective governments.

How vaulable would gold be if all the central banks auctioned off their supplies to the highest bidder and then refused to buy any more?

In terms of ensuring Bitcoin's survival in the face of hostile and well-resourced interests, I think a better model to look at is the Tor project. Why are they able to survive in spite of a lot of powerful interests who'd like to see otherwise?

There is no way to achieve the goal you want through the methods you're proposing.

If you want a currency that can store value, then it needs to be used by other people. That means it has to support the kind of usage levels that you're afraid of.

If remains too small to be effectively attacked, then it will also be too small to retain any kind of monetary value.

Safety through smallness is a dead end, which leaves safety through growth.

That might not work, but staying small for certain won't work.

A lot of those 'sensible counter arguments' take the form of:

"There's a tradeoff between scaling and decentralization."

"Can you explain what exactly you mean by 'decentralization' and how to measure it?"

"...no."

The fundemental error here is failing to recognize the voluntary nature of currency adoption.

Gavin proposed a change to Bitcoin that users are free to accept or decline.

That some developers interpreted this as a threat and turned it into a battle only shows the weakness of their position.

The proper response would have been to convince people to not choose the change by explaning why they would be better of by doing so.

Instead, they acted with outrage over the idea that somebody proposed something without their permission and was doing a better job of convincing people that they'd benefit from his proposal instead of theirs.

This is not a sustainable position for them. Money is only as valuable as there are other people willing to accept it, and nobody is in a position to force anybody to accept Bitcoin.

People who act on the expectation that their opinions are right by default because they were there first and so aren't subject to continual validation in the marketplace of ideas are going to end up losing everything.

if 75% of the network wants to go with large blocks and 25% want to force smaller blocks, which fork is the hostile one?

It's out of necessity. I have a home server whose routine maintenance is consuming too much of my time. I need to put an automation system in place so that I have more time available to do things other than keep my server running.

Also a sufficiently-complete automation system is close enough to Linux distro that I might as well make it publicly available as one.

To save time.

Random coincidence: You post about this today, while I've spent all day writing rules for an automation system (cfengine) that will generate the configuration files for tool for automating the creation of iptables rules (shorewall).

If I thought it was worth going through the argument, I'd be in favor of a protocol change to make the block reward shrink a little bit each block instead of suddenly dropping by half every four years.

Really though it's only the first 3-4 block reward halvings that we need to worry about. After that it should be small enough to not matter any more.

My position is that it would be great if we could have started Bitcoin up without a block subsidy, but since the currency has to be issued via some method, and since the only way to produce a truly optimal initial distribution would require an entity that was both omnipotent and omniscient, issuing the currency via block subsidy spread out over time is the least terrible way to do it.

It's in my queue of articles that need to be written.

The block subsidy really does distort mining, just like every other subsidy does in its respective market. The economics of Bitcoin mining are going to make a lot more sense once the block reward shrinks to negligable levels, or once the transaction volume grows large enough to render the reward negligable and thus the distortion insignifigant.

The first criteria is something over which we have no control - we just have to wait.

The second is something we can do something about.

Somebody made a video describing the effect of a block size limit back in 2011: https://www.youtube.com/watch?v=gVq5oh3-JXc

A payment code is an address that each sender can use to derive up to 4 billion deposit addresses unique to them.

If a charity advertises a payment code for donations, each individual donation transaction would send funds to a unique address.

https://github.com/bitcoin/bips/pull/159

Payment codes are a technique for creating permanent Bitcoin addresses that can be reused and publicly associated with a real-life identity without creating a loss of financial privacy.

They are similar to stealth addresses, but involve a different set of trade-offs and features that may make them more practical.

You can publicize your payment code in the same way that you can publicize your email address. Even if everyone knows your payment code, nobody can monitor the blockchain to see how many payments you have received or which transactions are yours.

If you receive an incoming transaction to your payment code, the act of learning that you received funds tells you the payment code of the person who sent the transaction. This means transactions sent to payment codes do have the "from address" that's missing from Bitcoin wallets and that many users would like to have.

Since transactions involving payment codes have a from address, the recipient of a payment can send a refund to the sender without requiring additional information.

Unlike stealth addresses, detecting incoming payments does not require scanning the entire blockchain and all transactions. Any method used by light clients to obtain their balance normally also works with payment codes. This means a light client can use payment codes without outsourcing their privacy to a trusted full node.

Payment codes have different privacy features than stealth addresses:

• Payments sent to a stealth address are obviously identifiable to network and blockchain observers as sends to a stealth address and could conceivably be censored. Payments sent to a payment code are not distinguishable from traditional Bitcoin transactions
• Payment codes leak an upper bound on the number of incoming notification transactions a known payment code has received. The senders of those payment codes, whether not a particular notification transaction is a valid payment code or not is not leaked. Notification transactions are identifiable by a network or blockchain observer and could conceivably be censored.
• Stealth address transactions put the information that's contained inside a payment code notification in every transaction. Payment code notification transactions include an extended public key that only needs to be sent once to each recipient and is which is valid for 2³² subsequent payments.

The payment code standard does not currently support multisig payment codes, and there's no obvious way to add support for them without either losing desirable features or failing to provide the additional security that multisig addresses are supposed to provide. It might be possible to use threshold signature techniques to accomplish the goal of allowing multiple parties to share control over a payment code without requiring OP_CHECKMULTISIG scripts. This will be a subject for future investigation.

The full description of the protocol with illustrations is available here:

https://github.com/OpenBitcoinPrivacyProject/bips/blob/master/bip-0047.mediawiki

That particular benefit is not attributable to IBLT.

You can stop sending transactions twice by putting transaction hashes, rather than full transactions, in the block message.

IBLT allows miners to broadcast (information that can be used to construct) those hashes while they mine rather than waiting after they found the block to send everything.

IBLT takes a large spike in needed bandwidth that occurs at the time a block is found and spreads it out over the entire time the block is being mined.

If you're already talking about bandwidth requirements in terms of 10 minutes averages, then introducing IBLT doesn't appreciably change anything.

It would be great if you'd be specific that the proposal is about increasing the block size limit, which is only indirectly and occasionally related to the actual size of mined blocks.

Of course the protocol is not going to break. Does anyone thing it will?

It's not about the protocol or the network.

The SatoshiDice stress tess was a lot better than this plan.

At least the capacity problems they caused were from actual customers receving a service for which they were willing to pay rather than admitted spam.

What actually happened is that when F2Pool realized they had been mislead about the effects of the change, they promptly reverted it.

Because, unlike the spherical cow models the game theorists are always using, they value the long term value of their investment rather than the short term benefit of gaining a few extra pennies on each block.

Incentives do work after all.

I deleted my last post in this thread because after some reflection I thought there was a chance I was being unfair to Peter Todd and the post was unhelpfully inflammitory.

Then, not ten minutes later, he and his supporters confirm exactly what I said on the mailing list.

They want to intentionally break native Bitcoin transactions to punish anyone who doesn't adopt Proofchains.

Users are not to be allowed to make their own risk assessments and adopt Proofchains if and only if they think it's the best solution for their particular problem based on their own judgement - they need to be forced into a better solution because Peter Todd knows best for them.