I think you are greatly overestimating the marginal cost of turning on mining hardware. Hardware depreciation is a much more significant cost than electricity.

Also, you're mistakenly assuming that attacker blocks have an "evil bit" set. When a node is facing a massive reorg, in general he doesn't know if the new branch is one built in secret by an attacker, or if so far he has been isolated by an attacker and finally he gets a glimpse of the real chain.

And, if the node does have some way to determine that a branch belongs to an attacker, there's no need at all to fire up the hardware to work to orphan this branch - the network can just agree to reject this obviously malicious branch.

The practice of rejecting a new branch if it conflicts with a known branch X blocks deeps is what I call "cementing". This has its uses but it carries the risk that a node will be stuck on the wrong branch. Which is why proof of stake is needed to have the final say - the cemented branch will be given up once proof-of-stake favors a different branch.

Can you explain how a monopolized Bitcoin is better than a central currency issuer? The entire point of Bitcoin is decentralization, if we don't have that, what do we have left? And why do we need the whole proof of work/stake thing, instead of the monopolist just synchronizing transactions in its internal database?

You could take pretty much any argument in favor of Bitcoin and use it against a monopoly. What if it charges exorbitant fees of $0.3 + 3%? What if its servers are down and nobody can process transactions? What if it is attacked by some government agency? What if it goes bankrupt due to bad management? What if it starts posing restrictions on how one can use their bitcoins?

I intend to issue 300 new bonds later this week, at a price that is to be determined.

Current bidders should be advised that if the issue price is lower than their bid, they will pay the full price they bid.

"Bitcoinica Buy Apy" is what you'd get per year for an idle deposit. Currently this is 0% for BTC and 7.41% for USD.
"Daily Pip" is in units of 0.01% per day.
"Bitcoinica sell" is what you pay for a "negative balance". Eg, if you buy bitcoins on margin, you have to pay the USD Bitcoinica sell Apy.

You can include signature fees in transactions and in assurance contracts. Since the cost of signing is low, the token incentives that can be obtained from assurance contracts, quid-pro-quo, direct interest and so on should be sufficient.

For the purpose of preventing double-spending, stakeholders aren't supposed to make any judgment about which block is better. As long as enough of them sign, and they never sign more than one block in a given height, the system should work. Preventing other attacks may require a more sophisticated system.

I wonder if this can already be done with the right script.

It's similar but the proposed use case is different. Here the focus is not on merchant payments, but on personal wallet security. I think there are security schemes that are possible with this but not without it, and some people might want to use them.

Also, in this proposal, you don't reverse just the offending transaction from the address, you reverse both this transaction and the previous transaction to this address (and have the funds return to a different, presumably uncompromised address). This is what allows it to have security implications. (If you reverse just one transaction, a hacker could just make the transaction again).

Sounds good.

Exactly, that's my point. You can't argue "the current level of security requires spending $10M / year, and that's a small price to pay for a global financial system". By the time Bitcoin is a ubiquitous global financial system, securing it will cost $1T / year, and nobody will cough that up without personal incentives. Which is precisely the "tragedy of the commons" problem we've been talking about.

Then this reduces to waiting to see if there is any conflicting transaction, which is a service which can be provided by any node, it needn't be a miner. In fact waiting a few seconds and querying nodes gives superior security to contracts with miners, so this fails as an extra revenue source for miners.

If the price of a bitcoin increases, so does the incentive to attack the network (political parties and banks see it as more of a threat, more potential profit from double-spending and short-selling), hence the resources attackers are expected to muster, hence the hashrate required to secure the network. Because of this, BTC/block is a good measure for the level of security.

Stakeholders will only validate a block if it currently enjoys acceptance among miners. But once they do, their validation overrides anything miners have to say on the matter.

Can you link to the 0.8 & 0.2 proposal? My current design is described here, I think it's not complicated at all.

I assumed the participating pools would reject conflicting blocks, because if not, the weakness is even clearer. Joe makes a double-spend, one to Walmart and one to himself. Walmart pays 51% of the pools to commit to the transaction to Walmart. Meanwhile Joes pays the other 49% (or 20%, or whatever) to commit to the send-back. Walmart thinks the transaction is safe and gives the product to Joe, when in fact there's a 49% chance that the next block found will have the payment to Joe, and Walmart will lose the money.


I am a critic of the majority of existing alt coins. Alts have their place but they really need to be thought out and have a reason to exist, I'm not eager to rush an alt of my own.

There's still some work to be done with the design. The design I currently have should work against double-spending, but not necessarily against denial of service.

I can work on the design from a high-level perspective, but I don't think I'll be able to lead the development and promotion efforts in the near future. Someone would have to volunteer for that (and to create a new thread for further discussion).

Possibly, but that's not strictly necessary, test attacks should work well for testing resilience.

I can certainly imagine a scenario where Bitcoin fails due to this problem, and an alt proof-of-stake coin will be there to pick up the pieces. But I fear that people will attribute the failure to the concept of cryptocurrency itself, rather than to solvable problems that were foreseen in advance.

I don't expect an alt to rise to prominence before Bitcoin failing, so by the time people will be convinced to make the change, it will arguably be too late.

Which is why I hope people will give more weight to theoretical considerations. Empirical testing is great but it's not always feasible.

This needn't be an immediate all-or-nothing change. You could start by collecting people's signatures and ignoring them. Then you could try reasoning what would happen if we used these signatures in branch selection.

I'm not going to be writing code to implement this anytime soon, if that's what you mean. But I'm putting a lot of personal resources into Bitcoin on the hope that its challenges will eventually be overcome, so it's not "purely theoretical" to me.

Anyway, this problem probably won't manifest for a long time. Discussion of the problem and solutions should be out there, but as long as uncertainty of the future prospects isn't holding back adoption, there's no rush to implement anything.

Thanks, but I'd much rather see this change implemented while keeping the Bitcoin name and the current blockchain.

PS. AFAIK, the first mention of using proof-of-stake in Bitcoin was by QuantumMechanic, in this appropriately named post.

As I said it's just a problem with the label. It's not pretty or anything, but you can still get the data about number of shares traded, even if they're labeled as "BTC". And I'm pretty sure it is solvable in the bitcoincharts platform if properly configured.

IMO fractions of a share should be tradeable on GLBSE.

The protocol doesn't say that if there are two conflicting transactions (whether a fraudulent double-spend attempt or something else) you have to reject both and reject any block that contains either. It says you go with the one you encountered first, unless a block is found that contains the other and then you go with that. In your scenario (especially if there is a dedicated denial-of-service attack), every block will be rejected by every miner because it contains some transaction the miner committed to reject.

In December the block reward will be 25 BTC. The problem is when block reward is close to 0. We're no going to have any empirical evidence for a long time.

I'm not saying the problem isn't solvable; I'm saying it's silly to think of it as "not a problem" when it was never tested, and when the proposed ideas of how the ecosystem will work depart completely from how Bitcoin works now and from its design principles.


Yes, people will contribute more than what the immediate incentives can account for, due to altruism, fear of a snowball effect, superrationality, etc. But they will only do so by a small amount, not enough to sustain the expenditure that will be required. If you really want to be future-proof, you need to align the immediate incentives properly.


A big unless. You'd want to attack the network either for profiting from double-spending, or for harming Bitcoin (political agenda, destroying competition, short-selling bitcoins). There's a tradeoff, some things you can do to protect against the former makes you more vulnerable to the latter.


They are (arguably) too high now for the current value of Bitcoin. As the impact of Bitcoin rises, so will the incentives to attack it. Since the attack incentive is more or less proportional to the purchase power of a bitcoin, it is safe to assume that the BTC reward per block is the invariant security factor. 50 BTC is high, but 1 BTC - which may very well be the future equlibrium - is not.

This will certainly help. Decoupling compensation from individual transactions is a positive direction. But I think the fundamental problem remains. Someone would want to pledge his own funds only if he thinks there's a good chance he will tip the scale to passing the threshold. Which means the network will always walk on the edge in which there's a chance for everything to crumble.


Game theory isn't a model of what people do. It's a model of what people should do. Even if 99% of people do "better" than what game theory prescribes, there can still be 1% who are selfish and rational and exploit the system. Having a system that is secure in theory can go a long way to preventing unpleasant surprises in practice.

By the way, "failures of game theory predictions" are commonly not problems with the theory, but with the game that was chosen to model the specific real-world situation.


I am still of the opinion that all the ideas proposed could account for some level of hashing, but not enough for proof-of-work to completely secure the network. Which is why proof-of-stake will need to augment it to pick up the slack.

As I said it looks like there's no bug, it displays either shares or BTCs according to your choice, what am I missing?

There was a bug in retrieving difficulty for new blocks. Because of it, coupons paid for the last 3 blocks were about 9% higher than should have been. Since the mistake was in favor of bondholders, no further action is needed; and hopefully the bug is fixed now.

For reference, the amounts that were actually paid were:


The amounts which should have been paid, and are now reflected on the website:

I doubt this will work. I assume you mean that the confirming pools will also reject any blocks that contain a conflicting transaction. Which means that for every block and any pool, it's likely that at least one of its transactions will be rejected. Which means most blocks will be rejected, which is a vulnerability.

If it's the same 51% hashrate used by everyone this won't happen, but then it's just a mining cartel, which is only one step removed from a central mint.

Reduction in block reward is arguably the second biggest challenge Bitcoin is facing (the first is legal attacks).