I'm not sure you are fully aware what a >50% attacker can or cannot do.
He cannot add blocks which don't comply with the protocol, these will simply be rejected.
He cannot add transactions which send coins from addresses he hasn't the key for.
He can add blocks that exclude any or all floating transactions. By putting such blocks in a long enough branch, he can reverse blocks which do include these transactions.

So, whatever he does, eventually 100 blocks will be reached. It doesn't matter if some of these are useless blocks created by the attacker.

A possible problem is that he will cause the difficulty to increase and thus transactions will take more time to enter a block (since some of the blocks are the attacker's and don't include useful transactions), but that is a minor problem.


Having signatures for every block requires a lot of data to be passed around, and doesn't help much.

This is interesting, but 10% of all coins owned by miners is way too high - especially since we are seeking to keep the network secure while reducing the overhead of mining. And with less than that, I don't think the disincentive to attackers is high enough.

In the current system, it is not known what the next block will be before it is found. Every miner know a certain set of transactions and tries to find a block including them. When a block is found, which is a relatively rare event, it is broadcast and any remaining floating transactions will remain and can be included in the next block.

If you want several miners to verify a block before it is accepted, it means that they have to agree on the transactions to include before starting to verify it. This is a synchronization nightmare.


My own system is along the following lines.

Hash-based mining will continue more or less as usual. However, branch choice will depend not only on length, but on two additional factors: Signatures, to prevent double spending; and circulation, to prevent interfering with transaction confirmation.

Every 100th block (or 64th, or some other number) will be a signature block. It is mined normally, but once it is found and confirmed with 10 additional blocks, stakeholders (people who have coins as of the signature block) are invited to sign the block's hash with their private key (which can be separate from their transaction private key). Choosing between two branches will be very heavily influenced by the weight of the signatures on the last signature block.

An attacker with high hashrate who tries to build an alternative long branch will be rejected because it conflicts with a signed branch. Thus, someone who makes a large transfer can guarantee its security if he waits for a signature block.

To prevent the results from being skewed by coins whose owners are not interested in signing, the voting weight of an address will decrease for every block it doesn't sign. It will increase back to the normal weight for every block it signs. If coins are moved to a new address, the weight will reset to 0. Also, if an address signs two conflicting blocks, its weight will reset to 0.

If keeping the network secure, and thus maintaining the value of their stake, is not incentive enough, there will be a system to have a part of the transaction fees reserved for stakeholders, or maybe a separate signature fee (paid by those who wish to incentivize stakeholders to sign the next signature block).

This leaves the problem of an attacker trying to disrupt the network by reversing blocks and thus stopping transactions from being confirmed. For this, two more terms can be considered in evaluating a branch:

1. Circulation - how many different coins have circulated in the last 10 blocks. An attacker can try to displace all blocks, except for his own blocks which only include transactions sending money to himself (to make them appear like legitimate block). Unless he has lots of bitcoins, he will need to send the same coins back and forth. Branches where this is detected - that is, the total number of different coins circulated is low - will be penalized. This may be hard to compute, but some sort of useful approximation may be tractable.
2. Inclusivity - A block will be penalized for every transaction it excludes which has a high enough fee and has been floating for a while. A few transactions occasionally missing is ok, but when it becomes systematic it indicates someone trying to block a specific transaction.

Try https://en.bitcoin.it/wiki/Protocol_specification and https://en.bitcoin.it/wiki/Protocol_rules. Though it's possible that for some things the code is the de facto documentation.

What does "Pseudonymous socializing" mean?

You don't need to go to a booth, you can do it via the internet with encryption and digital signatures. And you don't need to hope the papers won't be lost, because the information required to prove to you that your vote was counted is published (without anyone else being able to tell what you voted). That's the whole point.

Being "public" is not what the block chain solves, you have the internet for that. What it solves is creating a timeline, which you don't need for voting.

I agree, assuming that the total amount given per unit time is the same. What I'm arguing is that fees will be very low (unless a solution is found), so the reward per block will decrease until it is unacceptably low.

It doesn't matter regarding the incentives of miners, so the hashrate will be the same in both scenarios. But it does matter regarding the incentives of attackers - in the second scenario, Bitcoin is worth thrice as much so the incentive to attack, for whatever reason, is tripled. So the hashrate the attacker is expected to amass will also triple, and the hashrate that is the same in both scenarios will not be enough to secure the network in the second scenario.

Hence, the number of bitcoins awarded per block is a good measure of the security of the network (because the other two variables are the worth of a bitcoin and the incentive to attack, which are more or less proportional).

The problem is that people won't pay enough transaction fees if they'll be included in a block anyway. As above, by default security is proportional to total fees paid. Of course, the lower the fees can be while keeping the network secure, the better.

On the last two blocks there were 0.4 BTC fees on average. Will this number be higher in the future? Lower? Will the amount be enough to secure the network? I don't know, and I've seen no evidence the answer must be yes.

I believe a solution will be found one way or another if a problem should arise. But I think we need to be prepared in advance. And I don't think we should consider Bitcoin as having proven its technical integrity when the real test is still ahead of us.

It's roughly 4 years, but when difficulty is increasing it will be less. I think the current estimate is September 2012.

There's some network effect, but the utility still scales much slower than quadratic.

We know there's no problem as long as generation is high enough... But what happens afterwards?

... Except if you shorted bitcoins, and making them go down in price was your plan all along.

This is a real problem, please don't try to sweep it under the rug. We don't know how to make people pay transaction fees, we don't know how to prevent miners from including low-fee transactions (a prerequisite to having people pay fees), we don't know what % fee will be considered acceptable by merchants and we don't know what % fee is required to keep the network secure (against all kinds of attack, not just vanilla double-spending).

It's easy to think the network secure now when mining is funded by 37% yearly inflation.

That makes some sense, except that if you read deepceleron's post you'll see it's correct too and is basically the same as what I wrote. You draw the percentile uniformly in [0,1], and translate it to a value using the inverse of the cumulative distribution function (log in our case).

You need to clarify exactly what is the problem you are trying to solve before analyzing solutions. Heck, I understand the problem and the solution approach and could barely follow you.

I'll assume the problem is this:

We need some rule to determine which branch of the block chain to consider valid. The current rule (using the branch representing the highest total difficulty) is vulnerable to attacks by an entity with high hashrate. Proof-of-stake systems seek to modify the decision rule so that attacking the network can only be done by those who have many bitcoins, and thus, have the least incentive to do so.

So, if this is the goal, we cannot assess how close your suggestion is to achieving it, because you haven't specified what would be the rule to choose between branches.

For just the technical part of actually signing a block, my preferred approach is this: Every address is associated with two key pairs. The address itself is a hash of the concatenation of the two public keys. Doing normal bitcoin transactions involve revealing both public keys, as well as signing the transaction with private key A. Signing a block involves revealing both public keys and signing the block hash with private key B. The weight of the signature depends on the number of coins belonging to the address up to the signed block (or alternatively, X blocks back). Key B doesn't need to be as well-protected as key A - if it's compromised, the owner just sends the coins to a different address. So he can maintain voting rights with bitcoins safely stored in a time capsule.

I'll add my thoughts about how to incorporate it in a system later.

Yes, this is a problem that has been discussed (for example here) and deserves more discussion. Basically the solution will boil down to:

1. Making the transaction fees high enough to have significant network power
2. Modifying the protocol to allow more security for a given level of processing power

If you want the voting power to be directly related to the amount of money offered, this is good but not new.

For "normal" voting where the voting power of each person is determined by his status (this includes equal power to every one in some group, as in elections), the block chain doesn't bring much to the table. You can, however, use plain old cryptography. Here is an example cryptographic voting system with some good properties.

I won't post in the bitHopper thread because it's too busy, so with your permission I'll reply here to a comment there:

I don't know where you heard the term "poisson time-distributed random", but you should use standard terminology:

A process of independent random events happening at a given rate is called a Poisson process.

The distribution of the number of events in a given time interval in a Poisson process is called the Poisson distribution.

The distribution of the time between any point and the next event in a Poisson process is called the Exponential distribution.

The discrete version of the exponential distribution, which gives the number of shares in a round, is called the Geometric distribution.

Now, the procedure I outline is the correct way to obtain an exponentially distributed random variable (the active ingredient is taking a logarithm). I don't know how bb did his simulation so can't comment whether this is what he needs.

The motivation of your post - the fact that fallback is not necessary with many proportional pools - is not new. I've said this already here (Table B.1) and before that.

The reason it's unnecessary because when there are many pools, you never get to 43.5% - there will virtually always be a pool with less than that. So you don't need any of the "random threshold selection from the range [0.5, 1.5]" nonsense.

Except of course for the cost of the solar device, and the mining equipment (which depreciates with Moore's law), and maintenance, and a location for the rig where the heat/noise won't be a nuisance...

... Or you could start a thread in Off-topic about evolutionary advances in solar power extraction.

Hashing/Integer ASICs will do to GPU mining what GPUs did to CPU mining.

The difficulty will increase to keep the cost of mining bitcoins more or less the same.

People will no longer be able to mine on existing hardware, but if dedicated PCIe cards are mass-produced it may be viable to add mining cards to an existing computer.

The incentive to attack the network is proportional to the total worth of the Bitcoin economy, and hence to the number of transactions. Therefore, The need for security, and by extension, the cost of mining, also increases with the number of transactions.

So eventually we will reach a point where cost/transaction is more or less constant... But that will be only after the need for security will have relevance to the total mining done.

Both the post and the comments on reddit ignore the critical distinction between the inflation era and the tx fees era.

Right now, the total cost of mining has nothing to do, quantitatively, with the value of security, and everything to do with the implementation choice of 7200 BTC minted per day. The network has more hashing capacity than is due for protecting the network with its current value. The electricity costs are basically paid for by those wishing to get their hands on the new coins.

In the future, there will be no issuing of new coins, only transaction fees. The total hashrate, hence the network security, will be proportional to the total fees paid. An optimal balance should be sought between the need for security and the cost of transactions (how to reach such an optimum is an open problem). The electricity costs will be paid for by those who wish their transactions to be quickly confirmed against double-spending. And the cost per transaction will be much less than $4.

I think you're mixing two different things:
1. Full nodes will prune old transactions that were already spent. They will keep unspent transactions.
2. Lightweight clients will only keep block headers and relevant Merkle branches. They will not at any point keep transactions that do not concern them.