Proof of Activity Proposal

[coblee]

Proof of Activity Proposal

I'd like to put out a alternative Proof of Stake proposal that I'm calling Proof of Activity or PoA for short. The problem with the few PoS proposals floating out there right now is that there's a lot of extra network traffic and block chain bloat to propagate and store all those signatures. With PoA, there's no need for stakeholders to sign all the signature blocks. Instead, one stakeholder is randomly chosen (and evenly distributed by coins held) to be the lucky representative of that block. And only he gets a chance to "sign" the block. If he signs the block, he will get a reward for it. And in the case of a "51%" attack, the fork that has a more aggregate difficulty and signature blocks wins out. That's the general idea. I will explain the details below.

Random Evenly Distributed Stakeholder

The reason why using random evenly distributed stakeholders works is because if the attacker does not have a huge stake, chances are he will not be selected in the blocks he generates. So his blocks will be unsigned. It would be harder for him to mount an attack against the real network with signed blocks. So in order for the attack to succeed, the attacker must have a huge hash rate and a huge stake.

The hash of the previous block is a random enough value that every node knows and can be used to select the "lucky" stakeholder for the next block. But in order to make this work, we need to be able to pick the random stakeholders with an even distribution and every node must be able to verify which is the correct stakeholder for the next block.  If person A has 200 coins spread out in multiple addresses and person B has 100 coins spread out in multiple address, person A should be exactly twice as likely to be selected as person B to be the stakeholder for the next block. One way to do is to figure out all unspent outputs and randomly pick one with an even distribution. You can mod the previous block hash by total satoshis ever produced up to this point,  and have the remaining value deterministically pinpoint an address from a ordered list of all unspent outputs.

Another way (not sure if easier are harder to calculate) is to have the mod of the previous block hash deterministically pinpoint a single satoshi from a coinbase transaction. Then follow that satoshi as it travels from transaction to transaction until it reaches an unspent output. Then that output address will be selected as the next stakeholder. You can do this deterministically. Since the initial satoshi picked from a coinbase output is evenly distributed, the eventual selection will be evenly distributed also. I can explain more if people are interested in how this will work.

Note that when nodes get a new block, they can start calculating the next stakeholder right away. And when the next block is announced, they just need to check to make sure that the block contains the right stakeholder. So even if calculating the next stakeholder may be a cpu intensive calculation, it won't affect node performance much because it can be done asynchronously. And it's not a new vector for a DoS attack. Though initial block download will be slower when it verifies each stakeholder of a block.

Rewarding Proof of Activity

The easiest way to reward PoA stakeholders is to send them coins in the coinbase. Stakeholders and miners will split the 50 generated coins in the coinbase transaction. I think giving stakeholders 10% (5 coins) is a good enough amount to entice stakeholders to sign the block yet not take away too much from the miners. This number is up for debate.

We could dynamically increase/decrease this ratio based on how many stakeholders have signed previous blocks. For example, we can do it during the diff retarget and try to reach of target of 50% signed blocks. If there are less than 50% signed blocks in the previous 2016 blocks, then pay the stakeholders more in the next 2016 blocks. And vice versa.

Block Signing

Block signing is achieved by spending the PoA coinbase output. When the selected stakeholder spends that coinbase output, he is effectively "signing" that block. He is telling the network that he agrees that this chain is the true chain.

In order for this to work, stakeholders must sign the block within a certain window. Because signing a block from a month ago really does nothing to protect the network. So we want to make these coinbase transactions expire after a certain period. Let's say 120 blocks for now, but that's adjustable. So if the stakeholder broadcasts a transaction to spend the coinbase output after 120 blocks has passed, this transaction will be deemed invalid and will be rejected by other nodes.

Unclaimed PoA coinbase outputs can be reclaimed or just left as is and considered part of natural coin destruction that happens. Note that due to coin destruction, there will be blocks that are unsignable. This happens when we randomly select a stakeholder address that is lost.

Best Chain

Signed blocks should have a weighted value that is more than unsigned blocks when trying to figure out the best chain. Currently we are doing sum(diff) and the chain with the larger sum(diff) wins. With PoA, signed blocks would be counted X times the normal diff value. If we choose X=2, then signed blocks would be worth twice as much as unsigned blocks with respect to calculating the best chain. So a chain with 6 signed blocks is "longer" than a chain with 11 unsigned blocks of the same difficulty.

I'm proposing we use X=5. The reason why I chose 5 is because if we assume that on the real network we have half the blocks signed, then an attacker with no stake would need 75% of total network hash rate in order to perform the "51%" attack. The way to calculate this is if the network hashrate hashes 10 blocks and half of those blocks are signed, then the strength of chain is 5 (unsigned) + 5*5 (signed) = 30 effective blocks. The attacker needs to match that hashrate with unsigned blocks, so he needs a hashrate that can produce 30 blocks in the same time when the main network is producing 10 blocks. 30 / (30 + 10) = 75%.

There's an attack vector where lucky stakeholders might withhold their signatures in order for them to try to perform a double spend. They could hash in secret and find a block with their signature. When they do, they send a transaction to the real network that they plan to double spend and then release their fork which will be "longer" due to their signed block. The solution to this is to allow a signature (only found in one fork) to also be used to sign the signature block on the other fork if applicable. For example, if both forks have the same signature block (i.e. the fork happened after it) and the signature is only found on one fork, then both fork gets 5xdiff for that signature block.

Another attack vector is the attacker can mine blocks until they find a block that hashes to something that will select themselves as the next stakeholder. When they find that block, they keep it a secret and then start building their fork on top of that block and include their signature transaction. This way, they can launch a double spend with a large stake and only ~15% of the network hash rate. A solution to this is to increase the weight of the signed block based on how deep the signature transaction is in the block chain. So the attacker is forced to build more blocks on top and needs to outpace the main network's blocks, which would likely have more signatures.

Conclusion

Proof of Activity provides the benefit of Proof of Stake without the added network traffic and block chain bloat. It makes it harder for an attacker to perform a "51%" attack. In order to perform a successful attack, he would need a huge hashrate and a huge stake.

The nice thing about this proposal is that you would only need to change 5 things:
- Nodes need to calculate and verify next stakeholder
- New coinbase output for PoA
- PoA coinbase spends will mark blocks signed
- Invalidate transactions that are trying to spend expired PoA coinbase
- New best chain calculation

It would of course be a chain forking change that needs to be scheduled for sometime in the future.

Thoughts?

EDIT: Thanks a lot to iddo for helping me flesh out this proposal.

[1715543795]

1715543795

[1715543795]

1715543795

[1715543795]

1715543795

[gmaxwell]

So, one point thats a minor engineering thing but important is that you should _not_  be using the same key for currency transactions and mining, because it's reasonable and prudent to keep large volumes of coins offline or at least encrypted. There are a bunch of ways to do this (persistent delegations, one time delegations, ECC math related keys) which have different consequences; I think it's just important to do one.

As far as the overall design goes, it seems to me that it has a weakness I'd call "unavailability of the preferable alternative" or a hobson's-choice-attack that I think exists in all the stochastic PoS schemes I've looked at.

Lets say there exists a pair of short competing forks.  There is an earlier fork, the one you heard first and a competing later one. Network convergence demands you sign the earlier one, but you're not the chosen miner for the blocks there. You are, however, a chosen node in the weaker fork.  You (like almost all users) have no transactions that would be reversed by mining in one over the other.... so you confirm the weaker one because _doing so cost you nothing, and in the event that it does win, you get more coin that way, so doing so is the rational action_. Your choice isn't "Fork A" or "Fork B", it's "sign" or "do nothing"  _independently_ on each fork you're permitted to sign, and signing costs you nothing and has a non-zero expected return.   With PoW you're burning a finite resource on your preferred choice, and you can't simultaneously mine multiple forks without diluting your resources.

This happens is because your stochastic PoS has the property that the existence of a fork expands the network wide pool of stake producing capacity. At least, opposed to some other schemes, creating that fork still requires a POW investment so at least thats good.

I'd have to think harder and see more concrete details to do a real analysis, but I think if you think of this under the Byzantine Altruistic Rational model (BAR; Byzantine participants want to burn the earth, Altruistic help out at their own expense, Rational make fairly short term greedy self-interested decisions), I think your scheme defends against byzantine faults better than Bitcoin if and only if your population is very altruist heavy instead of rational. It requires participants to sign the single convergence optimal chain and only that chain, even though doing something else would make them more coin. I think altruistic-heavy is unlikely: just holding a lot of currency for the sake of being able to mine it has a real cost associated with it, so its demanding a lot of expenditure from altruists in the form of stationary funds.

If instead the population is rational heavy I would expect your scheme to _increase_ the amount of time required to become confident that a reorg will not happen_ even absent a byzantine attacker_ because a shorter fork may, by luck of which users are on or offline, gather signatures faster and become the rational target for the pow workers to extend, then it's competitor could catch up when some signers wake back up, and so on.   While this instability wouldn't extend beyond your signing horizon, you'd likely lose stability within it, and it also potentially presents interesting attacks against newly bootstrapping nodes.  (e.g. a late created fork with lying timestamps with 1/3rd the POW difficulty but every single block signed because they're all held by an attacker)

[coblee]

Lets say there exists a pair of short competing forks.  There is an earlier fork, the one you heard first and a competing later one. Network convergence demands you sign the earlier one, but you're not the chosen miner for the blocks there. You are, however, a chosen node in the weaker fork.  You (like almost all users) have no transactions that would be reversed by mining in one over the other.... so you confirm the weaker one because _doing so cost you nothing, and in the event that it does win, you get more coin that way, so doing so is the rational action_. Your choice isn't "Fork A" or "Fork B", it's "sign" or "do nothing"  _independently_ on each fork you're permitted to sign, and signing costs you nothing and has a non-zero expected return.   With PoW you're burning a finite resource on your preferred choice, and you can't simultaneously mine multiple forks without diluting your resources.

There's nothing inherently wrong for someone to sign a weaker fork because he was selected as a stakeholder in that fork. If his signature helps that fork become the best chain, then that is the best chain. The point is we are trying to make it harder for a fork held in secret to outpace the main chain. For your scenario where 2 blocks were found at the same time and one of them has you as the stakeholder, then by all means, sign that block. Since you'd want that fork to win. And let fate decide which fork wins. In the end you still need PoW to build on the chain.

While this instability wouldn't extend beyond your signing horizon, you'd likely lose stability within it, and it also potentially presents interesting attacks against newly bootstrapping nodes.  (e.g. a late created fork with lying timestamps with 1/3rd the POW difficulty but every single block signed because they're all held by an attacker)

It would take a lot of hashpower and stake for an attacker to create 3 blocks that all select the attacker as the stakeholder. I don't think that's going to be a problem.
EDIT: I just reread what you wrote. It is possible for an attacker to spend the time and energy to generate tons of blocks to try to build 3 consecutive blocks with him as stakeholder and use those blocks to trick newly bootstrapping nodes. Not sure how big of an problem this is though.

[killerstorm]

even absent a byzantine attacker

Well I guess it's aimed primarily at byzantine attackers, at expense of higher small-scale reorgs. Also, doing calculated double-spends might be harder due to chaotic environment, but opportunistic double-spends might be easier.

[Meni Rosenfeld]

I like the idea of probabilistic PoS. I think the motivating problem is exaggerated but this could have other advantages too.

Another way (not sure if easier are harder to calculate) is to have the mod of the previous block hash deterministically pinpoint a single satoshi from a coinbase transaction. Then follow that satoshi as it travels from transaction to transaction until it reaches an unspent output. Then that output address will be selected as the next stakeholder. You can do this deterministically. Since the initial satoshi picked from a coinbase output is evenly distributed, the eventual selection will be evenly distributed also. I can explain more if people are interested in how this will work.

I don't think satoshis are tracked the way you think they do. If there's a 50 BTC coinbase which is split to two addresses you can't say "this satoshi went to output A and this satoshi went to output B". Not a major problem though, if you agree on a randomness seed (deterministically from the blockchain) you can simply trace the chain forward, in each step choosing a random output weighted by number of coins.

[iddo]

Hello gmaxwell,

So, one point thats a minor engineering thing but important is that you should _not_  be using the same key for currency transactions and mining, because it's reasonable and prudent to keep large volumes of coins offline or at least encrypted. There are a bunch of ways to do this (persistent delegations, one time delegations, ECC math related keys) which have different consequences; I think it's just important to do one.

With delegations, it has to involve linkage of the two pubkeys at some block on the chain, and all nodes would continuously have to look at the old block where the linkage was established to verify it. With ECC math related keys, did you mean something similar to type-2 deterministic wallet? Meaning that the seed is blank or known to all, everyone can derive pubkey2 from pubkey1, but only the person who holds privkey1 can derive privkey2 and then use privkey2 (stored unencrypted) to create PoS signatures? This idea is actually quite neat, like deterministic wallet it's secure as long as the PRF is pesudorandom, and there's no need to bloat the blockchain with linkages.

Edit: Hmm, I was wrong. If the seed is known to all, privkey2 is stored unencrypted, and some hacker steals wallet.dat and obtains privkey2, then he can simply do privkey2-hash(seed,...) to get privkey1 and spend the coins. gmaxwell, what did you mean by ECC math related keys?

Lets say there exists a pair of short competing forks.  There is an earlier fork, the one you heard first and a competing later one. Network convergence demands you sign the earlier one, but you're not the chosen miner for the blocks there. You are, however, a chosen node in the weaker fork.  You (like almost all users) have no transactions that would be reversed by mining in one over the other.... so you confirm the weaker one because _doing so cost you nothing, and in the event that it does win, you get more coin that way, so doing so is the rational action_. Your choice isn't "Fork A" or "Fork B", it's "sign" or "do nothing"  _independently_ on each fork you're permitted to sign, and signing costs you nothing and has a non-zero expected return.   With PoW you're burning a finite resource on your preferred choice, and you can't simultaneously mine multiple forks without diluting your resources.

This happens is because your stochastic PoS has the property that the existence of a fork expands the network wide pool of stake producing capacity. At least, opposed to some other schemes, creating that fork still requires a POW investment so at least thats good.

But isn't it true that in coblee's proposal you would see both "Fork A" and "Fork B", because the protocol allows for a time period (120 blocks in his example) in which you may do your PoS? Perhaps it might be a good idea for the protocol to enforce that you also wait at least N<120 blocks before you are allowed do your PoS (i.e. spend your reward in this proposal), to avoid the default behavior of stakeholders who'd sign too quickly the first fork that they see, which might not be the best fork because of network propagation/isolation issues ?
This idea is supposed to provide security from an attacker who only has large hashpower, so his fork would lose because he doesn't control the privkeys that should do the PoS by spending the rewards. If I understand correctly, you agree that this protocol gives better security from attackers who only have large hashpower, but claim that there are new risks that involve malicious stakeholders who could try to attack?

Edit: what I wrote here is nonsense, it applies to Meni's protocol, not to lottery-based protocols. The correct answer is in post #82 etc.

[coblee]

I like the idea of probabilistic PoS. I think the motivating problem is exaggerated but this could have other advantages too.

Another way (not sure if easier are harder to calculate) is to have the mod of the previous block hash deterministically pinpoint a single satoshi from a coinbase transaction. Then follow that satoshi as it travels from transaction to transaction until it reaches an unspent output. Then that output address will be selected as the next stakeholder. You can do this deterministically. Since the initial satoshi picked from a coinbase output is evenly distributed, the eventual selection will be evenly distributed also. I can explain more if people are interested in how this will work.

I don't think satoshis are tracked the way you think they do. If there's a 50 BTC coinbase which is split to two addresses you can't say "this satoshi went to output A and this satoshi went to output B". Not a major problem though, if you agree on a randomness seed (deterministically from the blockchain) you can simply trace the chain forward, in each step choosing a random output weighted by number of coins.

Satoshis are not tracked that way, but you could track it that way. You just need a deterministic way to do it. So just map every satoshi in the input to a satoshi in the output using an ordered 1 to 1 mapping. So for example, if you are looking at a transaction with an input of 50 BTC and 2 outputs of 25 BTC each and you are tracking the a satoshi that is located at 26.11111111 of 50 BTC, then you would follow the 1.11111111 satoshi in the 2nd output. Does that make sense?

[Meni Rosenfeld]

I like the idea of probabilistic PoS. I think the motivating problem is exaggerated but this could have other advantages too.

Another way (not sure if easier are harder to calculate) is to have the mod of the previous block hash deterministically pinpoint a single satoshi from a coinbase transaction. Then follow that satoshi as it travels from transaction to transaction until it reaches an unspent output. Then that output address will be selected as the next stakeholder. You can do this deterministically. Since the initial satoshi picked from a coinbase output is evenly distributed, the eventual selection will be evenly distributed also. I can explain more if people are interested in how this will work.

I don't think satoshis are tracked the way you think they do. If there's a 50 BTC coinbase which is split to two addresses you can't say "this satoshi went to output A and this satoshi went to output B". Not a major problem though, if you agree on a randomness seed (deterministically from the blockchain) you can simply trace the chain forward, in each step choosing a random output weighted by number of coins.

Satoshis are not tracked that way, but you could track it that way. You just need a deterministic way to do it. So just map every satoshi in the input to a satoshi in the output using an ordered 1 to 1 mapping. So for example, if you are looking at a transaction with an input of 50 BTC and 2 outputs of 25 BTC each and you are tracking the a satoshi that is located at 26.11111111 of 50 BTC, then you would follow the 1.11111111 satoshi in the 2nd output. Does that make sense?

Yes, you could do that. You need to be very careful though not only with the order of inputs and outputs, but also with the order of transactions in a block since the satoshi can end up as a tx fee.

Essentially this is equivalent to how I suggested to look at it.

[coblee]

I like the idea of probabilistic PoS. I think the motivating problem is exaggerated but this could have other advantages too.

Another way (not sure if easier are harder to calculate) is to have the mod of the previous block hash deterministically pinpoint a single satoshi from a coinbase transaction. Then follow that satoshi as it travels from transaction to transaction until it reaches an unspent output. Then that output address will be selected as the next stakeholder. You can do this deterministically. Since the initial satoshi picked from a coinbase output is evenly distributed, the eventual selection will be evenly distributed also. I can explain more if people are interested in how this will work.

I don't think satoshis are tracked the way you think they do. If there's a 50 BTC coinbase which is split to two addresses you can't say "this satoshi went to output A and this satoshi went to output B". Not a major problem though, if you agree on a randomness seed (deterministically from the blockchain) you can simply trace the chain forward, in each step choosing a random output weighted by number of coins.

Satoshis are not tracked that way, but you could track it that way. You just need a deterministic way to do it. So just map every satoshi in the input to a satoshi in the output using an ordered 1 to 1 mapping. So for example, if you are looking at a transaction with an input of 50 BTC and 2 outputs of 25 BTC each and you are tracking the a satoshi that is located at 26.11111111 of 50 BTC, then you would follow the 1.11111111 satoshi in the 2nd output. Does that make sense?

Yes, you could do that. You need to be very careful though not only with the order of inputs and outputs, but also with the order of transactions in a block since the satoshi can end up as a tx fee.

Essentially this is equivalent to how I suggested to look at it.

There is a standard ordering of transactions in blocks, right? If not, having it alphabetized by address is fine. As long as all the nodes use the same deterministic way, we are good. Satoshi ending up as a fee is fully supported. Since those will just be sent to the miner's block reward and it can continue follow the path.

The only catch is it's possible for a miner to destroy coins by not redeeming the full 50 btc in the coinbase. When that happens to our tracked satoshi, maybe we decide that there's no stakeholder for the next block.

[killerstorm]

But isn't it true that in coblee's proposal you would see both "Fork A" and "Fork B", because the protocol allows for a time period (120 blocks in his example) in which you may do your PoS? Perhaps it might be a good idea for the protocol to enforce that you also wait at least N<120 blocks before you are allowed do your PoS (i.e. spend your reward in this proposal), to avoid the default behavior of stakeholders who'd sign too quickly the first fork that they see, which might not be the best fork because of network propagation/isolation issues ?
This idea is supposed to provide security from an attacker who only has large hashpower, so his fork would lose because he doesn't control the privkeys that should do the PoS by spending the rewards. If I understand correctly, you agree that this protocol gives better security from attackers who only have large hashpower, but claim that there are new risks that involve malicious stakeholders who could try to attack?

I think it would help to clarify about what kinds of attacks it is designed to protect against. 51% attack does not say me anything, what is motive?

I guess it's obvious that this scheme simply cannot help against double-spends induced by small-scale (e.g. ~10 blocks) reorgs. In fact, coblee's proposal makes them much simpler. To a larger degree than he thinks.

He thinks that large stake is necessary to help yourself to do a double-spend. But this misses the fact that attacker can simply bribe people to make signatures for his double-spending fork.

For example, I would announce that if someone adds a signing txn to my chain instead of main chain, I would double his reward. Reward is will be paid in a fork, so if forking is not successful, reward isn't paid. (It's essentially a kickback from double-spend.)

Rational entities would prefer 2x reward to 1x reward, so my work will statistically get more signatures if we assume rationality, so double-spending is trivial if you have some fraction of hashpower to mine blocks from time to time (20% of hashpower is enough for 10-block reorg) and you can pay an interesting reward.

If you introduce lag, signatures won't help against small-scale reorgs at all. They might help against malicious history rewrites which aim to discredit currency as a whole. (Or a variant of this: an attacker who mines empty blocks.)

If this is true, it should be tuned towards this goal: introduce a big enough lag, low X value would be better.

[coblee]

He thinks that large stake is necessary to help yourself to do a double-spend. But this misses the fact that attacker can simply bribe people to make signatures for his double-spending fork.

A double spend kind of needs to be done in secret. If it's out in the open, then the entity (like an exchange) that you are trying to double spend against will see that you are trying to perform a double spend attack and they won't let you withdraw. And since stakeholders are chosen at random, you would not be able to tell who to bribe unless you announce your fork and your bribe to everyone.

[killerstorm]

OK, here's a full description of attacks which, I think, prove that PoA is not useful for anything, and is, in fact, harmful.

A. For-profit double-spending.

So I want to do for-profit double-spending. If I don't have all resources myself, I'll announce it as a double-spending service. It is a legitimate business in the cryptocurrency world. I need three things:

1. A steady source of double-spend transactions. I announce that I'll include double-spends into my chain for a kickback. I've outline process in details here: https://bitcointalk.org/index.php?topic=101820.msg1119119#msg1119119 (ppcoin thread) I assume that double-spend txns are submitted to me secretly so mechants do not know about them.

2. A source of PoA block signatures. Note that it is not necessary to have a full block to make a signature. I'll just announce hashes of my blocks as well as whatever is necessary for a signature, but not transactions in those blocks. It's possible to implement it as an add-on for a client software which submits these signatures in hope to get reward.

3. A source of hashing power. This is more complex, but one thing is that less than 50% is necessary, and another thing is that if there is certainty that my service works miners would be eager to use my mining pool because their rewards in main chain will be wiped with a reorg. Again, no full knowledge of blocks is necessary, miners only see hashes. I can temporary buy hashing power to bootstrap the thing.

So here's how I'll overpower the network: rational entities would submit their signatures both for main chain and into my fork-chain. But they are interested into waiting as long as possible to submit signature into main chain because my chain pays higher reward (from double-spend kickbacks).

In any cases, people do not lose their money: if fork works, they get twice the reward. If it fails, they still get reward in the main chain.

So, statistically, I'll get somewhat more signatures because main chain would be starved of signatures for some time. (It depends on people getting rewards in both chains within a certain window. This happens from time to time, especially for people with a lot of money.)

Thus, I need less than 50% of hashing power to perform a commercial double-spend.

B. Malicious 51% attack aimed to destroy a chain.

A malicious entity would pay for PoA block signatures for his alternative chain. He needs to pay in a different currency, obviously.

Essentially, it would be like a self-fulfilling prophecy: if people know that attacker has enough hashing power, they will trade their Litecoin savings for reward denominated in Bitcoin.

----

So what we get is that this PoA can make it cheaper to perform both for-profit and destructive attacks on a chain due to profit motives. It can only work if majority of nodes are altruistic.

[iddo]

Hello killerstorm,

What do you mean by "it is not necessary to have a full block to make a signature" ? In coblee's protocol, the winning address (that should provide the PoA signature by spending the reward) is derived from the block hash, so how could you provide the PoA signature before you solved the block?

Are your concerns also apply to canicula and Meni's protocols? So far it seems to me that the only relevant distinction in Meni's protocol is that he proposed voting weights for PoS signatures, which have the property that we can penalize an address that attempted to sign more than one fork, by zeroing its weight. Implementing voting weights is complex and probably involves computationally intensive calculations by all the network nodes. But it might be possible just to penalize an address that attempted to provide PoA signatures in more than one fork, by including the evidence that it signed another fork in the blockchain (same issue arises with Meni's voting weights idea). This idea should be investigated if there plausible attack scenarios (perhaps your scenario). We shouldn't assume that the majority of stakeholders is malicious, but we should assume that the majority is rational.

[iddo]

I'd like to raise two additional issues that weren't mentioned in coblee's OP, mainly because we missed gmaxwell's suggestion to use the key homomorphism feature of ECDSA to delegate signing keys.

In terms of economics/philosophy, maybe it's preferable that stakeholders are taxed instead of rewarded, meaning that (say) 0.5 coins of the block reward is taken from the address of the stakeholder, unless he provides the PoA signature. Technically this can be implemented by creating the coinbase txn (e.g. after 120 blocks) that spends those 0.5 coins, simply as a rule that the distributed network follows, without requiring the stakeholder's privkey. We might wish to require that the PoA txn of the stakeholder references the block that he signs, otherwise an attacker could include txn by this stakeholder in his competing fork (if the attacker was lucky enough to derive this stakeholder address in his fork). If the stakeholders participate and provide their PoA signatures, then they aren't taxed.

If we delegate signing keys, there's a security risk (that coblee raised) where people would give their signing key to some central entity that would do the signing for them, either because they don't run a node on their computer 24/7, or because the central entity offers them financial benefits. The central entity could then use its signing power for double-spending attacks. Opinions?

[killerstorm]

What do you mean by "it is not necessary to have a full block to make a signature" ? In coblee's protocol, the winning address (that should provide the PoA signature by spending the reward) is derived from the block hash, so how could you provide the PoA signature before you solved the block?

I meant that attacker will reveal only block hashes or block headers, but not transactions in blocks.

Are your concerns also apply to canicula and Meni's protocols?

I don't quite understand cunicula's protocol, but it seems to be vulnerable.

So far it seems to me that the only relevant distinction in Meni's protocol is that he proposed voting weights for PoS signatures, which have the property that we can penalize an address that attempted to sign more than one fork, by zeroing its weight.

I think this fixes this problem. In general, I think proof-of-stake can work only if there is some form of punishment for malicious activity.

If there is no punishment then one can experiment with malicious activity without repercussions.

(It's also worth noting that Meni's protocol does not help against Denial of Service. But it makes bribery for DoS harder, I think.)

Implementing voting weights is complex and probably involves computationally intensive calculations by all the network nodes. But it might be possible just to penalize an address that attempted to provide PoA signatures in more than one fork, by including the evidence that it signed another fork in the blockchain (same issue arises with Meni's voting weights idea). This idea should be investigated if there plausible attack scenarios (perhaps your scenario). We shouldn't assume that the majority of stakeholders is malicious, but we should assume that the majority is rational.

Well, instead of using weights we can just ban whole address so he won't be able to spend his coins, is that what you've meant?

I also considered use of distinct type of addresses for transactions and for stake signing (i.e. you can have your money either on transactions, or on interest-earning account and moving between them takes some time), it might make banning easier. (i.e. we can ban money which is sitting on time deposit account.)

[coblee]

killerstorm, I don't think your attack scenario is feasible. If he can pull of the double spends, the value of the currency will drop significantly. The attacker has to entice more than 50% of all stakeholders (in terms of coins held) to agree to sign his blocks in addition to the main chain. Why would the largest shareholders be interested in helping with a double spend attack. Also remember that the largest stakeholders will be the exchanges and if they are acting rationally, they would sign all the blocks on the main chain and would not sign any of the attacker's chain. I think your attack is theoretically possible but not practical.

[hashman]

Nice idea Coblee! 
My first thought was Democritus.  Sign your block, it's like jury duty  

I suppose when a block comes up for signature and is not signed by the designated block chain citizen, the block doesn't pass.  So there would be incentive for folks to keep their coins online in citizen groups to make sure to get that reward for when their time is called.  The ecosystem would be very different.  What gmaxwell said.   

My reservations here are similar to those with PoX (X!=W) ideas in general:  I'm not sure what the problem is for this solution.

Are we going for:

1) a more energy efficient mining process  OR
2) a way to eliminate double spending attacks entirely  OR
3) a way to make double spending attacks more expensive OR
4) something else I'm missing? 

There will always be a way for an attacker to spend Z units to get Y in return, when Z>>Y.  That is really hard to stop!  
The problem in the system arises when these attacks become feasible for Z~Y or even Z<Y.  One way to prevent this and secure the system is to make sure Z is very big.  Another way is to make sure Y is small. 

If the problem in need of solution is double spending, a simple solution exists:  minimize Y.  Don't accept transactions in such a way that the costs of a double spend attack can be regained.  Wait for more blocks if more money is changing hands, don't automate large transactions, keep track of pool percentages, cap your overall outputs, etc. etc.  I guess I just haven't been convinced that this 51% threat is such a huge one, but I suppose eventually we will see some big ones go down. 

That being said, I like the idea.  Another alt-coin please  

[killerstorm]

If he can pull of the double spends, the value of the currency will drop significantly.

If we assume efficient markets, it will drop significantly once you announce that you want to include a feature which worsens protection against double-spends

Also, I don't think you should depend on the fact that stake holders will be reluctant to participate in attacks which decrease exchange rate: "intuitively optimal" solutions can be very different from Nash equilibrium produced by independent rational players. I believe that double-spending with proof-of-stake can be quite like prisoner's dilemma where Nash equilibrium is the worst option. (Which, basically, means that one shouldn't include this feature.)

The attacker has to entice more than 50% of all stakeholders (in terms of coins held) to agree to sign his blocks in addition to the main chain.

No. You forget that this is a stochastic process: number of signatures available in different forks is a random variable with large variance.

Attacker does not need to win all the time, he doesn't need to win most of the time. He needs to win from time to time.

Since variance is high from time to time his chain would win in a number of signatures and double-spend would be successful.

For example, if attacker has access to 25% of stake he'll get three signatures for three blocks in 1.5% of cases. So at least one double-spend per day.

Also note that legitimate stake holders do not always sign blocks immediately, they don't really have an incentive for it. Delayed signing will further shift probability towards attacker (stakeholders who work for attacker have higher motivation to sign ASAP).

I think your attack is theoretically possible but not practical.

Maybe. Its feasibility depends on particular economic conditions and altruism/laziness among stakeholders.

But why would you make your blockchain theoretically weaker? I really see no reason for it, it doesn't really prevent any kind of attack...

[coblee]

We could have the reward decay the longer it takes users to sign blocks. But that only alleviates the issue.

But why would you make your blockchain theoretically weaker? I really see no reason for it, it doesn't really prevent any kind of attack...

Point taken. Do you see a way to fix up this proposal so that it's not theoretically weaker?

[socrates1024]

My reservations here are similar to those with PoX (X!=W) ideas in general:  I'm not sure what the problem is for this solution.

Are we going for:

1) a more energy efficient mining process  OR
2) a way to eliminate double spending attacks entirely  OR
3) a way to make double spending attacks more expensive OR
4) something else I'm missing?  

If you want a really good challenge to work on, I suggest:
4) eliminate the need for hard-coded timing parameters, such as 10 minutes in between blocks, or the 2 hour window for rejecting timestamps, or the 2 weeks in between difficulty adjustments.

The reason why this problem is worth solving is that you cannot evaluate the soundness of the protocol just by looking at the code itself. You must also make quantitative assessments about the current state of the world's technology and the latency of the internet. There is no objective way to determine if the parameters are configured appropriately.

This is an extremely difficult and subtle problem. A sign that you're working on the right problem is if you're considering a 33% attack rather than a 49% attack (in other words, the attacker must be weaker than half the network you know about, but network delays may cause you to underestimate the actual size of the network). This is what it would take to make a theoretically stronger block-chain.

[iddo]

If you want a really good challenge to work on, I suggest:
4) eliminate the need for hard-coded timing parameters, such as 10 minutes in between blocks

See https://bitcointalk.org/index.php?topic=79837.0
However, you're in the wrong thread, please visit https://bitcointalk.org/index.php?topic=102357.0 and keep the discussion in this thread focused on the PoA protocol.

[iddo]

Implementing voting weights is complex and probably involves computationally intensive calculations by all the network nodes. But it might be possible just to penalize an address that attempted to provide PoA signatures in more than one fork, by including the evidence that it signed another fork in the blockchain (same issue arises with Meni's voting weights idea). This idea should be investigated if there plausible attack scenarios (perhaps your scenario). We shouldn't assume that the majority of stakeholders is malicious, but we should assume that the majority is rational.

Well, instead of using weights we can just ban whole address so he won't be able to spend his coins, is that what you've meant?

Yes, that's the kind of thing that I meant.
However, there's a crypto issue with this suggestion: we would include a signature of random data (edited: hash of a block in an orphaned branch in Meni's protocol, txn of some coinbase output in coblee's protocol) as evidence that an address should be banned from providing proof-of-stake. This means that the crypto security assumption that we're relying on is somewhat weaker, because we don't have a reduction from chosen-plaintext attacks to random-plaintext attacks. If you only know the pubkey and can sign random data, it obviously means that ECDSA is broken, but still it's a weaker assumption. If ECDSA wasn't resistant to RPA but still resistant to CPA, then the worst thing that an attacker could do is ban other addresses from providing proof-of-stake.
Another issue is that under this suggestion the signatures would probably also need to sign the height of the block, instead of just the hash of the block, otherwise an attacker could take an old block that you signed and claim that it's evidence that you're attempting to sign several forks now.

As a more general note, if we decide to implement PoA in Litecoin (maybe as a sandbox for Bitcoin) then I guess that we'd be biased towards simplicity, so handling far-fetched attack scenarios could be sacrificed for the sake of simplicity. This discussion is worthwhile, as we consider which attacks are plausible and which attacks are far-fetched.

[killerstorm]

However, there's a crypto issue with this suggestion: we would include a signature of random data (hash of a block in an orphaned branch) as evidence that an address should be banned from providing proof-of-stake.

I'm not sure I follow you, coblee wrote:

Block signing is achieved by spending the PoA coinbase output. When the selected stakeholder spends that coinbase output, he is effectively "signing" that block.

So apparently evidence of banning should include that spending and corresponding block header with coinbase.

Another issue is that under this suggestion the signatures would probably also need to sign the height of the block, instead of just the hash of the block, otherwise an attacker could take an old block that you signed and claim that it's evidence that you're attempting to sign several forks now.

Well, if you want block signature to work this way, evidence of wrongdoing should include at least a whole block header.

As a more general note, if we decide to implement PoA in Litecoin (maybe as a sandbox for Bitcoin) then I guess that we'd be biased towards simplicity, so handling far-fetched attack scenarios could be sacrificed for the sake of simplicity. This discussion is worthwhile, as we consider which attacks are plausible and which attacks are far-fetched.

I still don't get what kind of problem PoA is trying to fix.

[killerstorm]

Point taken. Do you see a way to fix up this proposal so that it's not theoretically weaker?

I still don't get what kind of attack are you trying to defend against with PoA. What problem is it trying to fix?

If it is about small-scale reorgs, I doubt anything can be done at all since ultimately weight modification from signing increases variance and thus likelihood of attacks "from time to time".

If you focus on large reorgs, i.e. it is a defense against attacks which aim to discredit currency as a whole, I'd say introducing lag should help. I.e. you can sign block only once it has like 50 confirmations.

This way block signing for double-spends will become largely impractical. One can try to use PoA vector in that large attack, but (arguably) that's harder than simply borrowing hashing power. Additionally you can implement punishment to make it even better, but it's not necessary to have punishment from start. I.e. it is required only against really sophisticated attack.

And in general I would advice to follow Meni's PoS design, PoA with lag will be similar to it. If you want extra double-spend protection you can add cementing. Also, stuff that iddo have written, i largely agree with him.

(Note that Meni pretty much confirms that you cannot prevent small-scale reorgs with PoS, but you can prevent them with cementing, and you can fix problems which arise from use of cementing with PoS (or PoA)).

[iddo]

However, there's a crypto issue with this suggestion: we would include a signature of random data (hash of a block in an orphaned branch) as evidence that an address should be banned from providing proof-of-stake.

I'm not sure I follow you, coblee wrote:

Block signing is achieved by spending the PoA coinbase output. When the selected stakeholder spends that coinbase output, he is effectively "signing" that block.

So apparently evidence of banning should include that spending and corresponding block header with coinbase.

That spending is a signature of random data, because that data exists on an orphaned branch, and some of the network nodes have never seen and will never see this orphaned branch.

I still don't get what kind of problem PoA is trying to fix.

At the most basic level, PoA tries to fix the scenario where an attacker with large hashpower could do double-spending. It's infeasible to fake ECDSA signatures with large computation power, so this kind of attacker will fail if the protocol incorporates proof-of-stake. The question is whether we open the door to other kinds of attacks, and how to minimize these risks.
There might be other indirect benefits, for example if PoA would be useful in providing security from double-spending attacks, then maybe less hashpower would be needed to secure the network, so it could be more energy-efficient.

[killerstorm]

That spending is a signature of random data, because that data exists on an orphaned branch, and some of the network nodes have never seen and will never see this orphaned branch.

Err, let's start from beginning. WHAT is included into a block chain as an evidence of wrongdoing? I see two options:

1. block-signing transaction itself as self-evident thing
2. a special message with a special format which includes both that txn and all require information

Apparently if we choose second approach we can include as much information as needed (i.e. block header, coinbase) so cheating would be not possible.

If you're concerned about 'signature of random data' then you probably assuming approach number 1 as it requires less coding. But I guess in that case a block-signing txn must have a certain format to distinguish it from normal txns... Otherwise block will be considered invalid as it contains invalid transaction.

(We cannot assume that all invalid transactions are evidence of wrong-doing because they might be traces of double-spends performed ON that user, not BY that user.)

Thus we can assume that a coinbase output for block-signing has some special scriptPubKey and block-signing txn includes scriptSig which matches that scriptPubKey.

For example: scriptSig might include 1) magic number which distinguishes it from normal txns. 2) signature for coinbase txn spend. 3) block metadata like timestamp, height; 4) signature for that metadata.

As metadata is not random, we no longer have random-key attack, do we? If we demand meta-data to be plausible, this would significantly limit attacker.

(While we are here, what if we just request two signatures: for block's hash and for block's hash hash? Attacker can choose any block's hash, but then he cannot choose block's hash hash, is it still RPA? I really don't know much about ECDSA.)

At the most basic level, PoA tries to fix the scenario where an attacker with large hashpower could do double-spending.

Double-spending, sure, but we should probably differentiate small-scale double spending caused by reorg of ~10 blocks (6 blocks is a standard for Bitcoin, I think) from large-scale double-spending, like 100+ blocks.

I believe that neither PoA nor PoS can directly help with small-scale double-spending as they more like increase fork/main chain weight variance.

For this reason Meni's scheme aims to prevent this small-scale double-spending with cementing, and PoS just fixes split issue which arises from double-spending.

PoS and PoA can, in theory, help against large-scale reorgs.

But I'm not convinced that automatic resolution is really needed here. A low tech solution is to bring client into a panic mode if it sees large reorg. Then a human operator can analyze what happened and either checkpoint an older (pre-attack) chain which would invalidate all of attacker's blocks, or he will follow longer chain if he sees that it was probably a network split.

So you just need to add:

1. Panic mode.
2. An RPC call for user to checkpoint older (cemented?) chain.
3. An RPC call for user to continue reorg.

It's much simpler than PoA/PoS and likely more reliable. And this would completely remove profit motive from such reorgs.

Attacker can still try to do that as a form of DoS, but then it is not really a double-spend attack, it is a DoS attack you're preventing.

And, again, I believe that there is an easy, low-tech solution to frequent DoS attacks: give user an option to do auto-cementing. Then watch how idiot burns his money trying to DoS you. (Alternative: an option to temporarily enable centralized checkpointing like in PPCoin.)

(Just to give due credit, I largely designed this solution for an alt-chain I intended to do myself, but then I talked to Lolcust and it turned out that he had similar solution in mind. So it might be possible that some ideas expressed here are Lolcust's (or somebody else's). So if somebody finds it new and wants to include somewhere, mention Lolcust in credits.)

[iddo]

Yes, if you store more data than just the signature, then it's no longer RPA (but it still might be data that an attacker can attempt to generate, rather than data that the attacker doesn't have control over). So it bloats the blockchain a little more, but if attacks are plausible then it could be worthwhile to add it to the protocol. I think that the basic idea behind such attacks involves a majority (at a particular time) of stakeholders who tries to double-spend.

This PoA protocol is a form of PoS, that's more simple and more efficient because it doesn't require nodes to propagate proof-of-stake signatures and attach those signatures to the blockchain.

To help with small reorgs, maybe we can do cementing in PoA too: as coblee mentioned, PoA signatures should have little/no weight at start, until their block gets older, so maybe the node can cement i.e. refuse to switch to another branch that reverses at least (say) 6 of its last blocks, and will un-cement only if the signatures weight of the other fork passes some threshold.

It sounds risky to have panic mode with each user manually selecting which branch to use, instead of automatic rules that all nodes follow. If enough clueless users make a mistake, then the blockchain forks and the situation might escalate, because people in different forks begin to have financial interest to stay in their fork?

[cunicula]

I'm kind of confused by the debate here. Isn't my proposal already good enough? As described in the wiki, it simultaneously uses coin-age as in PPCoin and work as in bitcoin. In the proof-of-stake wiki, I call "coin-age" "coin-confirmations".

Voting power is determined by a weighted average of hashing power and coin-age (coin-confirmations), rather than coin-age alone. [for details see wiki]

There is no requirement for multiple signatures to be recorded in the blockchain. (there would have to be one additional txn per block, recording the block miner's use of coin-confirmations)
 
The system is stochastic because the hashing power element of voting power is stochastic.

Like bitcoin, validity is assesed based on comparison of the block to a periodically-revised difficulty target. (a stochastic system prevents the possibility of establishing an irreversible, infeasible target.)

The primary criticism of PPCoin is that it is vulnerable to purposeful accumulation of coin-age for double-spending purposes. I think that some minimal level of additional security is sufficient to prevent this, and it can be provided by the proof-of-work element in a mixed proof-of-work/proof-of-stake scheme.

For an example of a robust system that prevents periodic double spends, consider an equal geometric weighting of coin-confirmations and work. Say you want to temporarily acquire 51% control here for double-spends. To do this, you wait an extremely long time until you have a stockpile of 99% of all outstanding coin-confirmations. Hold that stockpile fixed during the short interval you attempt double-spends. How much hashing power would you need to acquire to double spend? About 25% of the total outstanding supply. The hashing power requirement seems like a very large barrier to double-spending. It should remain adequate even after the aggregate hash rate drops to a low level. The potential gains from periodic double-spends are likely small.

Symmetrically, say you have 99% of hashing power and want to establish lasting control over the network (not just temporary control). The potential gains from lasting control are larger, so a much bigger obstacle is needed here. To achieve lasting control, you would need 25% of the total coin supply. Acquiring that would be prohibitively expensive. Both the short-term and long-term security issues appear well-addressed. Is there another security issue that I am missing here?

What about energy efficiency? Does mixed proof-of-work/proof-of-stake sacrifice energy efficiency goals? Energy efficiency is determined by the overall hashrate which is a function of block reward. As long block reward drops, future energy efficiency is assured. The problem is ensuring that security persists after energy efficiency is obtained.

Anyways, I apologize for cluttering up discussion here by rehashing my own old idea. However, because I am often flamed, I do not feel that starting my own thread is a good idea. I am not aware of a critical flaw with my idea. Perhaps there is one. If so, point it out, so we can discuss (feel free to start a new thread for this).

[iddo]

Hello cunicula,

Your protocol may be the most secure in terms of double-spending, I haven't looked carefully enough at the security analysis yet.

But I'm not sure why you're confused that we're brainstorming other ideas too, it seems to me that there are at least a couple of fundamental differences between your protocol and PoA:

(1) if someone buys let's say 100,000 coins with fiat money at an exchange, and now as a stakeholder he wants to contribute his services to the security of the distributed network, but he's not the kind of person who would mess with GPUs/ASICs hardware and become a miner, then under your protocol this stakeholder wouldn't participate?

(2) it appears that your protocol incentivizes stakeholders to keep their coins in a single address, in order to increase their coin-confirmation when they sign the block that they solved. This raises security concerns, and with PoA we don't have this problem because coblee's idea of follow-the-satoshi to determine the lucky stakeholder works even if that stakeholder splits his coins among many addresses. Have you thought of ways to discourage people from storing all their coins in a single address with your protocol? Maybe they'd have to add multiple signatures to the block that they solved?

[cunicula]

Hello cunicula,

Your protocol may be the most secure in terms of double-spending, I haven't looked carefully enough at the security analysis yet.

But I'm not sure why you're confused that we're brainstorming other ideas too, it seems to me that there are at least a couple of fundamental differences between your protocol and PoA:

(1) if someone buys let's say 100,000 coins with fiat money at an exchange, and now as a stakeholder he wants to contribute his services to the security of the distributed network, but he's not the kind of person who would mess with GPUs/ASICs hardware and become a miner, then under your protocol this stakeholder wouldn't participate?

(2) it appears that your protocol incentivizes stakeholders to keep their coins in a single address, in order to increase their coin-confirmation when they sign the block that they solved. This raises security concerns, and with PoA we don't have this problem because coblee's idea of follow-the-satoshi to determine the lucky stakeholder works even if that stakeholder splits his coins among many addresses. Have you thought of ways to discourage people from storing all their coins in a single address with your protocol? Maybe they'd have to add multiple signatures to the block that they solved?

I support the brainstorming of other ideas. Sorry if I came across badly. I just feel that my idea is not so popular and I want to understand why.

(1) Stake and work do not have to be co-located. The GPU-starved stakeholder could rent hashing power online. Provided the stakeholder's computer is on and connected to the net, I'm sure this could be worked out. [Its also possible to allow stake to be rented to people with hashing power, but I'm not as comfortable with this]

(2) It kind of depends on how confirmations are measured and reset across multiple addresses. I don't really understand this well enough. However, its worth remarking though that there is no advantage to combining your coins in one single account. Average mining output per unit time is the same regardless of whether all coins are held in one account or divided arbitrarily across multiple accounts. This is based on simulations.

To see this heuristically, suppose that you solve a block whenever you hit 100 coin-confirmations (deterministic case). If you have 100 coins in one account, then you have just enough coins to mine every single block into the indefinite future. Suppose instead that you have 1 coin in each of 100 separate accounts and that each of these coins starts with 100-confirmations. Again, you have just enough coins to mine every single block into the indefinite future.

[iddo]

I support the brainstorming of other ideas. Sorry if I came across badly. I just feel that my idea is not so popular and I want to understand why.

(1) Stake and work do not have to be co-located. The GPU-starved stakeholder could rent hashing power online. Provided the stakeholder's computer is on and connected to the net, I'm sure this could be worked out. [Its also possible to allow stake to be rented to people with hashing power, but I'm not as comfortable with this]

(2) Over a long time-span, there is no advantage to combining your coins in one single address. Average mining output per unit time is the same regardless of whether all coins are held in one mining address or divided arbitrarily across multiple mining addresses. This is based on simulations (I suspect it can be proven, but I'm not that skilled in this regard and don't want to spend a lot of time on it.)

Maybe your protocol is less popular because it's more complex to comprehend all of its security implications. If we had a comparison between the properties of each proof-of-stake proposal then it'd be easier for people to follow.

(1) Well, you wouldn't want to send your privkey in the clear to the hashpower entity that you're renting. Even if we could do signing-key delegation (still waiting for a reply from gmaxwell regarding ECC related keys, I thought about it and I don't think it's possible), you'd probably want to have the miner who solved the block send it to you for signing, before broadcasting it to the rest of the network. So I suppose that you'd be losing some precious seconds compared to the other miners. It should also be verified that the stakeholder isn't faking to attack honest miners, which he could do by spending his coins even after he provided an initial signature evidence to the miner. I bet there are all sorts of interesting scenarios that could arise, that we haven't thought of yet. I still conjecture that the scenario where the stakeholder simply wouldn't want to bother by delegating or investing in his own hashpower is a plausible scenario.

(2) Right, I was confused and missed the fact that your coins lose their weight after you use them when you solved the block. So I suppose that it's a question of variance, e.g. if you solve a block once in a blue moon then you'd probably prefer to have a single address that controls many coins. Also, maybe if one or a few malicious miners+stakeholders keep a large amount of coins in a single address then they could use it for double-spending attacks, under the assumption that the rest of the distributed network splits their coins among many addresses?

[killerstorm]

For an example of a robust system that prevents periodic double spends, consider an equal geometric weighting of coin-confirmations and work. Say you want to temporarily acquire 51% control here for double-spends. To do this, you wait an extremely long time until you have a stockpile of 99% of all outstanding coin-confirmations. Hold that stockpile fixed during the short interval you attempt double-spends. How much hashing power would you need to acquire to double spend? About 25% of the total outstanding supply.

This is intriguing, but I don't understand where do you get these numbers from. Is there a more detailed example?

On wiki page I see  

Code:

target/coin-confirmations^4

formula. This means that twice more confirmations equals 16 more hash power, right?

So if I have 6 accounts with twice the average coin-confirmations I'll be able to do a 6-block reorg with just 51/16 = 3% of hashing power.

[killerstorm]

Imagine our whole world consists of 100 identical hashing units which consist of 1 unit of hashing power and 1 coin which is used to get coin-confirmations.

One averaged, out of 100 solved blocks one block belongs to each hashing unit.

Now let's say I own 6 hashing units and I want to do a 6-block reorg. I stop hashing on my units for some time. Difficulty stays the same or decreases.

After I waited enough (say, for 100 blocks) I start hashing. I have twice the average coin-confirmations in my hashing units. Besides that, I have 6 units. So chances that next block would be solved by one of my units are something like

Code:

6*16/100 = 0.96

(I'm probably very wrong here, but it doesn't matter much -- I just need to wait enough for chances to be close to 1.)

OK, one of my hashing units is out of coin-confirmations, but I have 5 more. And, again, chances that one of them will solve the block are high. Thus I have high chances of solving 6 blocks in a row, achieving desired reorg.

If I'm not mistaken, achieving a reorg with this wonderful system is as simple as waiting a bit, neither large hashing power nor high stake are required.

Your mistake, cunicula, is that you consider only output averaged over a large interval of time. It is true that you cannot increase your output by splitting/merging your coins/hashing power. But you can affect temporal clustering of your blocks via splitting and waiting, and it makes a reorg of arbitrary size possible with little resources.

[cunicula]

For an example of a robust system that prevents periodic double spends, consider an equal geometric weighting of coin-confirmations and work. Say you want to temporarily acquire 51% control here for double-spends. To do this, you wait an extremely long time until you have a stockpile of 99% of all outstanding coin-confirmations. Hold that stockpile fixed during the short interval you attempt double-spends. How much hashing power would you need to acquire to double spend? About 25% of the total outstanding supply.

This is intriguing, but I don't understand where do you get these numbers from. Is there a more detailed example?

On wiki page I see  

Code:

target/coin-confirmations^4

formula. This means that twice more confirmations equals 16 more hash power, right?

So if I have 6 accounts with twice the average coin-confirmations I'll be able to do a 6-block reorg with just 51/16 = 3% of hashing power.

Your mistake, cunicula, is that you consider only output averaged over a large interval of time.

As you note, I messed up the calculation. However, my broader point still holds. The system is quite robust to double spends. Thanks for questioning me so I can offer the correct argument.

The formula in the wiki weights PoS heavily. I think that protection even with the high PoS weighting is likely adequate. For this formula, your statement would be correct if you replaced "twice the average" with two-thirds of all the current coin confirmations engaged in mining. This seems difficult enough to me (though probably not to you).

For equal weighting, the formula becomes [target/coin-confirmations]. Equal weighting makes double-spends much more difficult. Let's look at the equal weighting formula.

Suppose, you have 99% of the outstanding coin-confirmations. The rest of the mining world has the other 1% of outstanding coin-confirmations and is combining them with work to try to mine the current block. If you just want to mine the current block, then all of your coins will need to be concentrated in one account. Due to this concentration, your PoW difficulty target will be 99 times easier (let's round to 100) than the average PoW difficulty faced by other miners. In order to mine just the next block with >50% prob you need 1% of hashing power.

Mining several blocks in a row is much more difficult. In order to mine 6 blocks in a row, then you will need to divide your 99% across six separate accounts. Because of this division, your difficulty target will only be 99/6=16.5 times easier than the average for rest of the mining world [importantly you aren't competing with another individual miners, but all other miners collectively]. In order to mine six blocks in a row with >50% prob, you will then need about 6% of hashing power.

That is really pretty difficult to acquire. 99% of all outstanding coin-confirmations and 6% of hashing power is a high bar.

However, if this isn't good enough for you, why not just wait for more confirmations. Suppose you want to do a 50 block reorg, you will need to divide your coins across 50 separate accounts. To mine a longer chain over 50 consecutive blocks with non-negligible probability, you would need about 25% of hashing power.

You are correct that any double-spend is achievable if you wait long enough, but, unless you hold a very large stockpile of coins, the waiting period could be decades for just one measly double-spend. I'm not really worried about people planning a double spend decades in advance.

[killerstorm]

Mining several blocks in a row is much more difficult. In order to mine 6 blocks in a row, then you will need to divide your 99% across six separate accounts. Because of this division, your difficulty target will only be 99/6=16.5 times easier than the average for rest of the mining world. In order to mine six blocks in a row with >50% prob, you will then need about 6% of hashing power.

Seems to be about right except number 99%.

Let's re-purpose my previous example: there are 94 hashing units which have 100 coin-confirmations on average each, thus their cumulative hashing power is 94*100 = 9400.
I have 6 hashing units with 1600 coin-confirmations each, my hashing power is 6*1600 = 9600. So I can perform 51% attack and mine next 6 blocks with ~50% probability.

Thus I need only about 50% of total coin-confirmations and 6% of hashing power to run this attack.

I guess we get different numbers (50% vs 99%) because you consider only momentary hash power parity to mine next block, while you should consider hash power parity to mine _any_ block. I.e. you assume that 1% of coin-confirmations sits in one account and so 99 hashing units can compete with 1 hashing unit and 99% coin-confirmations. It is true that they have 50% chance of mining next block, but note that if rest-of-the-world actually wins, it now has 0% of confirmations and attacker has 100%. So you need to consider a scenario where that 1% of coin-confirmation is spread over many accounts, and each such account gives only a minuscule bonus to hashing power.

That is really pretty difficult to acquire. 99% of all outstanding coin-confirmations is a very high stake threshold to meet. Waiting a little while won't do it. I need to work harder to figure out exactly how long you'd need to wait.

Well, in my example if you have 6% of coins you need to wait 1600 confirmations = ~11 days. Which isn't good, IMO: it means that a mid-sized miner can mount double-spends from time to time, and he doesn't even need to spend much on electricity.

However, if this isn't good enough for you, why not just wait for more confirmations. Suppose you want to do a 50 block reorg, you will need to divide your coins across 50 separate accounts. To mine a longer chain over 50 consecutive blocks with non-negligible probability, you would need about 25% of hashing power.

I agree that getting 50+ blocks in a row is not a small feat. But still, this design is weaker than pure PoW for relatively short reorgs. I.e. if we adopt it, we would have to wait for more confirmations for each payment. (Same is true for PPCoin and PoA.)

[cunicula]

Mining several blocks in a row is much more difficult. In order to mine 6 blocks in a row, then you will need to divide your 99% across six separate accounts. Because of this division, your difficulty target will only be 99/6=16.5 times easier than the average for rest of the mining world. In order to mine six blocks in a row with >50% prob, you will then need about 6% of hashing power.

Seems to be about right except number 99%.

Let's re-purpose my previous example: there are 94 hashing units which have 100 coin-confirmations on average each, thus their cumulative hashing power is 94*100 = 9400.
I have 6 hashing units with 1600 coin-confirmations each, my hashing power is 6*1600 = 9600. So I can perform 51% attack and mine next 6 blocks with ~50% probability.

[Edit: I am actually confused here. ]

No, you are confused. You really do need something like 99% of the outstanding stock of coin-confirmations and 6% of hashing power to double-spend. The problem has to be analyzed block by block. There is an important asymmetry between the attacker's problem and the legit miner's problem that you are ignoring.

As an attacker, you have 1600 coin confirmations to spend for block 1. The other 8000 have to wait in reserve for blocks 2,3,4,5, and 6 (1600 per block). If you spend all of your stock on block 1, you will have no hope of continuing the chain to blocks 2,3,...

As a legit miner, you do not need (or want) to horde coin confirmations. Hording causes you to lose mining revenue. Hording is only useful for attack purposes.  Therefore, you would attempt to mine with all 9400 coin confirmations for every individual block. (or rather 94 different miners will want to mine will all of their 100 coin-confirmations, it doesn't matter at all whether they are coordinated or not)

The attacker is at a gross disadvantage with only 14.5% of the stock of outstanding coin confirmations to spend on each block. Given his low share in the outstanding coin-confirmation stock, he would require much more hashing power than the defenders to succeed. The sufficient number is not 6 units of hashing power, it is (85.5/14.5)*94=554 units of hashing power.

Contrary to what you are trying to say, double-spending is very hard in this system, even for a short interval such as 6 blocks.

[cunicula]

It is true that they have 50% chance of mining next block, but note that if rest-of-the-world actually wins, it now has 0% of confirmations and attacker has 100%. So you need to consider a scenario where that 1% of coin-confirmation is spread over many accounts, and each such account gives only a minuscule bonus to hashing power.

[Edit: This is wrong, please ignore. It does matter if the money is divided across many people when analysing short reorgs. It matters less and less as reorgs become longer and longer and doesn't matter at all for permanent control]

No, the rest-of-the-world is divided among many miners. Say there are 1000 identical people in the rest-of-the-world. Every one of them is contributing to defense against the attacker. Ex-post only of them actually suffers a loss in coin-confirmations when each block is found. The others accumulate coin confirmations. For the rest-of-the-world, it is completely irrelevant for security purposes if the money is concentrated in a few accounts or divided across many. There is no need to analyze the two situations separately.


I'm going to get frustrated here soon. Anyone understand me and want to help explain?

[killerstorm]

As an attacker, you have 1600 coin confirmations to spend for block 1. The other 8000 have to wait in reserve for blocks 2,3,4,5, and 6 (1600 per block). If you spend all of your stock on block 1, you will have no hope of continuing the chain to blocks 2,3,...

Yes. I have 6 accounts with 1 coin in each account. I wait for 1600 confirmations (~11 days), now I have 1600 coin-confirmations in each account, 9600 coin-confirmations.

At the same time rest of hashing units (which act independently) each have about 100 confirmations on average, 94*100 = 9400 total.

I have a hashing power of 9600 and rest of network has hashing power of 9400 if each hashing unit is hashing on its own. Thus, I win having just ~50% of total coin-confirmations stock and 6% of hashing power.

So, again, a person owning 6% of coins and 6% of hashing power (which he can buy temporarily from Amazon, so only ownership of coins is required) can do 6-block deep reorg in 11 days.

Likewise a person having 5% of coins and 5% of hashing power can do a 50 block deep reorg in 138 days.

As a legit miner, you do not need (or want) to horde coin confirmations. Hording causes you to lose mining revenue. Hording is only useful for attack purposes.  Therefore, you would attempt to mine with all 9400 coin confirmations for every individual block. (or rather 94 different miners will want to mine will all of their 100 coin-confirmations, it doesn't matter at all whether they are coordinated or not)

If a miner has 9400 coin-confirmations in one account and he has 94 units of hashing power, he has an apparent 883600 hashing power.

If there are 94 miners which have 100 coin-confirmations each on average, and each one uses 1 unit of hashing power, apparent hashing power of a system is 94*100 = 9400.

A model where there are 94 miners is correct because on the next block they have an apparent hash power of 9400 again, i.e. hashing power is stable.

But a single miner will have 0 coin-confirmations for the second block, so winning a string of blocks afterwards would be trivial.

Say there are 1000 identical people in the rest-of-the-world. Every one of them is contributing to defense

Then when you say that rest of the network has 1% of coin-confirmations it means that each person has 0.001% of coin-confirmations. You need to plug this value into hash-target calculation, not the sum of coin-confirmations they have.

I'm going to get frustrated here soon. Anyone understand me and want to help explain

I find it rather strange that I have to explain that in a system where build-up of coin-confirmations compensates for lack of hashing power attacker can perform a double-spend if he waits enough. It is absolutely obvious.

I have no interest in further discussion. I've already demonstrated that your system if faulty with numbers. There is no need to explain me anything.

If you still don't get it please re-read my message enough times.

[cunicula]

Then when you say that rest of the network has 1% of coin-confirmations it means that each person has 0.001% of coin-confirmations. You need to plug this value into hash-target calculation, not the sum of coin-confirmations they have.

Sorry, you are right and I screwed up again. Not much sleep recently, I apologize.  

As you point out, my numbers applied to a single legit miner and the short-term reorg situation is different when miners are numerous. For short-term reorgs, the correct reference is to a representative, average miner like you say. However, when the number of miners increases, the average number of coin-confirmations in a successfully mined block tends would tend to increase in a similar proportion. Thus, it is not obvious that it actually becomes progressively easier to do reorgs as mining becomes more atomistic. We need to analyze the entire system to get an answer here.


Take the 50-50 weighting. For simplicity normalize total coins and hashing power to 1.

Suppose there is one legit miner who owns c 0<c<1 coins and x, 0<x<1, hashing power.  The legit miner maximizes block output per unit time.
There is also one attacker who controls 1-c of the coins and 1-x of the hashing power. The attacker maximizes 6 block reorgs. How often can the attacker double spend?

Excluding periodic reorgs, the legit miner will consecutively mine every single block with c coin-confirmations. The legit miner's voting power is xc. The attacker will need to exceed this for 6 consecutive blocks to do a reorg. Let w be the number of blocks the attacker waits between attacks. The attacker's coin-confirmations are w(1-c). The attacker is tied with the legit miner if w*(1-c)*(1-x)= 6xc. Solving for w indicates how long the attacker need to wait between attacks. w=6xc/[(1-c)(1-x)]

Thus, if the attacker has 5% of coins (c=0.95) and 5% of hashing power (x=0.95), he can attack every 2166 blocks. That is about once every 15 days. Attacking generates 6 blocks. Legit mining would generate 0.05*2166=108 blocks. There is a sacrifice of 102 blocks to facilitate attacks. Each attack pays off if it facilitates a theft equivalent in value to 102 block rewards.

What if mining is more atomized than this. Suppose there are n identical legit miners, who own nc coins in total, 0<nc<1, and nx hashing power in total, 0<nx<1. The legit miners maximize block output per unit time.
There is also one attacker who controls 1-nc of the coins and 1-nx of the hashing power. The attacker maximizes 6 block reorgs. How often can the attacker double spend?

Excluding periodic reorgs, each legit miner will mine once every n blocks with nc coin coin-confirmations. An individual legit miner's mining power will be nxc. Collectively, the n individual miners have mining power of n^2xc. The attacker will need to exceed this collective mining power for 6 consecutive blocks to do a reorg. Let w be the number of blocks the attacker waits between attacks. The attacker's coin-confirmations are w(1-nc). The attacker is tied with the legit miners if w*(1-nc)*(1-nx)= 6n^2xc. Solving for w indicates how long the attacker need to wait between attacks. w=6(nx)(xc))/[(1-nc)(1-nx)].

Thus, if the attacker has 5% of coins (nc=0.95) and 5% of hashing power (nx=0.95), again he can attack every 2166 blocks. Atomizing mining doesn't change anything.


Suppose we decide that this is to frequent and want to enforce a threshold of once a year (every 52560 blocks) in this scenario (nc=0.95) (nx=0.95). This would mean that each 6 block reorg would need to pay off 2622 blocks rewards in theft value to payoff. Remember the attacker is forgoing 2622 mined blocks in order to prepare each double spend. Seems like a lot.

To achieve this, the stake weighting needs to be lowered.  We started out with 50-50, we would achieve this target if we reduce stake to 41 and raise work to 59. Perhaps 40 stake-60 work is a good split.

Notes:

We must find g such that 52560=2166^g
g=ln 52560/ln2166
g=1.41520944787
(1-p)/p=g (where p is the stake weighting and 1-p is the work weighting)
p=1/2.41520944787=0.41

[cunicula]

The relevant question is how long an attacker would need to wait to perform one 6 block reorg. Is it hours, days, months, years, decades, or centuries? Say the answer is 1 day. Surely, there is no way an attacks could occur that frequently with the 50-50 weighting. However, for the purpose of argument, let's assume they could. The problem is simple to fix. Tweak the weighting to offer stronger protection against double spends and weaker protection against permanent control. Let's go through the numbers for an 80 work 20 stake weighting and see how waiting time compares to the 50-50 case. Remember, with 50-50, we assumed  attacks were possible once a day.

Formula Becomes [target/(coin-confirmations)^0.25]


Temporary Double-Spends

Coin-confirmations in n prepared accounts are 1000 times that of an average miners' coin confirmations -> attacker needs at least 15% of total hashing power for reorg of length n
      
Waiting time has increased by about 200-fold relative to the 50 work 50 stake scenario, where you just needed about a 5-fold coin confirmation edge to succeed with 15% of hashing power.
1 day of waiting becomes 0.5 years.

Coin-confirmations in n prepared accounts are 1,000,000 times that of an average miners' coin confirmations, attacker needs at least 3% of total hashing power for reorg of length n

Waiting time has increased by about 30,000-fold relative to the 50 work 50 stake scenario, where you just needed about a 30-fold coin confirmation edge to succeed with 3% of hashing power.
1 day of waiting now becomes 82 years.

Coin-confirmations in n prepared accounts are 1,000,000,000 times that of an average miners' coin confirmations, attacker needs at least 0.6% of total hashing power for reorg of length n

Waiting time has increased by about 6-million fold relative to the 50 work 50 stake scenario, where you just needed a 200-fold coin confirmation edge to succeed with 0.5% of hashing power.
1 day becomes 16,000 years.


Permanent Control

Hashing Power is close to 100% of network total -> need ownership of 0.5^(80/20)=3.125% of total coins in circulation to exert permanent 51% control

That's not as good as before. With 50-50, you needed 25% of the money supply and 100% of hashing power. With 20-80. you need 3.125% of the money supply and 100% of hashing power. This is still a tall order. Even if the total hashrate becomes very small and trivial to acquire, the 3.25% remains a very costly barrier to permanent control. That is the point of proof of stake. My guess is that there is a happy medium somewhere. I'm not sure if it is 20-80, 50-50, or 80-20, though.

sorry for posting all this crap everyone, just wanted to make the arithmetic as transparent as possible; best way to catch errors

[cunicula]

(Also it's worth noting that with your system top hash-rate equivalent is achieved when all money is in hands of one miner, as he will spend all his hasing power on account which highest coin-confirmations, while many independent miners would also waste their hashes on accounts with low coin-confirmations.)

I'm answering here because I don't want to clutter's Sunny's thread with irrelevant material. It encourages him to ignore our criticisms.

I don't understand what you are saying here. The amount of hashing you spend on hashing to maximize profits is subtle in my system. If you have an explicit formula, it could be really useful.

I only have results based on simulation. see https://bitcointalk.org/index.php?topic=68213.msg801253#msg801253 The simulation suggests that output per unit time is constant-returns-to-scale Cobb-Douglas. This implies that you optimally spend a fraction p of your mining investment on stake (where p is the proof-of-stake weighting) and 1-p on hashing power. Provided that perfect competition holds, this division is invariant to the scale of investment. I'm ignoring electricity use here and thinking about mining as powered by electricity efficient but capital-intensive ASICs.

I don't think scale matters at all unless someone is big enough to affect the aggregate hash rate. As in bitcon, domination big players affecting the aggregate hash rate decreases aggregate investment. You seem to be suggesting the opposite.

[killerstorm]

Apparently cluttering coblee's thread is OK

No, it's a different thing.

Here's an example with concrete numbers. Suppose there are 100 identical hashing units each having one coin.

If they all belong to one guy and he uses one account, then he will produce all blocks and his account always has 100 coin-confirmations (100 coins * 1 confirmation each). Thus apparent hashpower is 100*100 = 10000.

Suppose that guy wants to have 100 accounts for some reason. OK, no problem: he will put all of his hash-power into account which has most coin-confirmations, and usually that would be one with 100 coin-confirmations (1 coin which waited for 100 confirmations). So apparent hash-power is 100*100 again.

Now suppose all these accounts belong to different miners who do not cooperate: i.e. they won't work on each other's shares. Suppose that number of confirmations in each account is uniform 1..100 (it is not true, see below). In this case there are some miners who work on 100 coin-confirmation account, but also there are miners who work on 1 coin-confirmation accounts. On average there are 50 coin-confirmations, so apparent hashpower is 50*100.

But is assumption about uniform 1..100 true? Not really. There might be accounts with more than 100 coin-confirmations. But also note that to get to 100 confirmations account needs to get through 100 rounds, and it is likely to be reset to 1 confirmation somewhere in the middle. So distribution would be biases towards smaller accounts.

I've done a simulation, and it appears that mean confirmations for 100 independent miners is 66, while median is around 50. Moreover, these numbers scale linearly on the number of miners, i.e. 10 miners have around 6.6 confirmations mean.

So configuration with many independent miners is about 33% less efficient than one miner. This matches the general idea that cooperating miners will be better at resource allocation.

Now we can reduce double-spend analysis to a situation with one miner.

Suppose miner has h hashpower and c coins. His apparent hashpower is h*c.

I want to match this with h', c' and bonus b: h*c = h' * c' * b. Morover, to do n-deep double-spend, I need to do this with just c'/n coins, so:

Code:

b = (h/h')*(c/c')/n

So I have have 5% of coins and 5% of hashpower and want to do 50-deep reorg, I need a bonus of 20*20*50 = 20000 which matches previous results. (Which I obtained somewhat incorrectly). With 144 confirmations per day and equal weighting it is 139 days.

But in reality if there are many independent miners I get something like 33% bonus.

Now of course if you have c^0.25 bonus formula it is 20000^4, totally unfeasible. But smaller reorg is doable.

[cunicula]

Anyone have thoughts on the following mixed proof-of-work proof-of-stake system that incorporates a variant of Colbee's idea for a lottery. I personally prefer that
all blocks follow a symmetric system because it avoids unnecessary communication of blocks that don't provide useful security.

1) Lucky number

There is a lucky number each round. Lucky number should be a public random number that cannot be controlled without vast resources. Say it is a hash of the proof-of-work submitted in the last 100 blocks.

2) One lottery draw per coin confirmation

Each public address containing one or more coin confirmations provides lottery draw(s) which can be compared against the lucky number. Say an address k has c coin confirmations. This address k can then be used for c different lottery draws.

e.g. {lottery draw} = {hash (public key of address k,j)} where j = 1,2, ... ,  c if c>=1 and null set otherwise

Thus you get one lottery draw per coin confirmation. You only care about the best one in each round. Note that these draws are invariant over time. A set of possible draws can be computed once and for all time when the address is generated. They are public info, but only the address owner needs to care about them.

3) Each miner has a unique best lottery draw in the current round

In each round, a good lottery draw is close to the lucky number. Say we measure closeness as simple distance.

V(lottery draw, lucky number)= |(lucky number - lottery draw)|

A miner searches over his set of lottery draws and finds the one closest to the lucky lottery number. This determines his stake value, V', in the current round.

V*(lucky number) = min [V(lottery draw, lucky number)] in the set {lottery draw}

He only cares about the best possible lottery draw he has out of all of his addresses. Given that the draws are all pre-generated, finding his best draw should not be time-consuming.

4)  The miner faces a proof-of-work target. Most likely he can just connect to a pool and pay for access to their hashes.

target =  difficulty*V'^(p) where p >= 0

If p=0, then it is just like bitcoin. As p increases getting a good draw decreases the target more and more and proof-of-work becomes less and less important.

5) Block submission.

Miner submits proof-of-work that meets target and signs the block using the private key to his winning address. Anyone can verify that his proof-of-work, public key combination meets the target. As usual, difficulty is revised periodically to keep the block spacing to an average of 10 minutes.

I think the point of work here is to
a) manage the timing of block generation
b) ensure that the system cannot stop permanently because of an "unlucky" lucky number
c) generate lucky numbers


[edit: in the above, you could also replace one draw per coin-confirmations with one draw per coin and it wouldn't change much. One draw per coin-confirmation makes it easier for people with small balances to participate.]

[ripper234]

Can someone provide a tl;dr of what is the key problem in PoS that PoA is trying to solve, and how does it solve it?

[ripper234]

Please take a look at ThePiachu's answer and my comments. I think I now understand the difference between PoA and PoS, but I'm not sure what's the benefit of PoA.

[killerstorm]

I think iddo provided a good summary:

This PoA protocol is a form of PoS, that's more simple and more efficient because it doesn't require nodes to propagate proof-of-stake signatures and attach those signatures to the blockchain.

So PoA is essentially one of possible implementations of PoS, presumably the advantage is that it is easier to implement. However, it depends on what we are comparing it to...

For example, PPCoin's PoS isn't particularly complex (it is already implemented) and it can be made about as secure as PoA. (Particularly, it should be PoW+PoS, not pure PoS.)

One can say that PoA can be a drop-in upgrade, but I think PPCoin demonstrate that PoS can be a drop-in upgrade too.

So this is largely a matter of aesthetics.

[iddo]

I've looked again at this thread and at the discussion between killerstorm and cunicula at the other threads.
Few of the earlier posts are somewhat unclear to me:
Where does killerstorm's 1/q number come from, at https://bitcointalk.org/index.php?topic=102342.msg1139483#msg1139483 ?
At the wiki (link), the terminology that cunicula uses seems a bit loose, when he writes that you double your hashpower and it increases your chance from 50% to 100%, it appears to mean that you take the other 50% of hashpower that the other miners had (so they now have 0% of the hashpower), unlike what we'd normally think that "double your haspower" means (you'd have 2x hashpower and rest of the network would have x hashpower). The calculation there is fine for the stylized example, but to avoid confusions it might be better to clarify similar terminology of some posts like post #40 here, or rewrite in wiki .

Maybe when you analysed double-spending attacks and fell-back to coinconfirms^(1/4) to allow better protection, you should also provide analysis of attacker with a lot of hashpower but without stake, who tries to do 6-block reorg, obviously coinconfirms^(1/t) for bigger t will make it easier for an attacker who has little or no stake.

About the last post #43 of cunicula, it seems similar to coblee's first idea (link) that we abandoned in favor of his 2nd (better) idea. Though it seems wasteful to do {hash (public key of address k,j)} where j=1,2,...,c because c might be large, instead simply do V'=c*hash(lucky-num,pubkey-address), the important observation is that PoW-only attacker cannot try to generate new (privkey,pubkey) pair which is close to the lucky-num using just hashpower, because this fresh pair will have 0-coinconfirms for the current block.

Regarding stakeholders who try to sign competing forks, and whether the protocol should punish them, some of my comments were confused and are relevant for Meni's scheme, but not really for the PoA scheme. In coblee's OP, the first attack vector (3rd paragraph of "Best Chain" subsection) describes a scenario where the signed block exists before the fork began, but the signature for this signed block exists in only one of the competing branches after the fork began. The idea is that the miners will use the signature txn also for the branch in which it is missing (when they calculate which branch is the winning branch), and then include this signature txn in the next block of that branch. Hopefully this idea is technically feasible, because non-miner nodes also need to calculate the winning branch, so this idea might be susceptible to DOS attacks? If this protocol behavior can be implemented without significant problems, then part of my response to gmaxwell in post #6 is meaningless: we don't need to wait N blocks before allowing the stakeholder to provide his signature.

If we conclude that short re-orgs are a problem with PoA (I'm not convinced yet, see next paragraph), then as mentioned in OP we can give weight to the signatures only after say N=100 blocks. So an attacker with 50% hashpower who can obtain more signatures than the honest network would need to prepare a secret branch of e.g. 106 blocks to have 6 valid signatures, while the branch of length 106 that the honest network generated during that time would have 3 valid signatures, assuming that the protocol re-targets the stakeholder reward so that about half of the blocks get signed. The disadvantage of N=100 before signatures become valid is that you cannot rely of the service that the stakeholders provide if you only wait for e.g. 6 confirmations. I'd also like to mention that cementing (mentioned in post #27) is an extra feature, it isn't required. The advantage of cementing (at e.g. 6 blocks) is that if you wait for more than 6 blocks then you can be confident that an attacker couldn't release a secret fork that would reverse your txn, and the disadvantage is that an attack who releases his fork at exactly 6 blocks can create havoc and split the hashpower of the honest network due to propagation lag (until it re-unites at the un-cement depth of e.g. 100 blocks).

About killerstorm's double-spending-bribes service scenario, let's use the following (standard) terminology:
* "honest" participant follows the protocol, so he runs only the official client code (or another client that implements exactly the same protocol), therefore he doesn't participate in the double-spending-bribes service because that involves running different code that connects to the attacker's branch instead of the honest network.
* "greedy" participant is rational/self-interested, he cares about earning more money for himself, and doesn't try to hurt the network on purpose.
* "malicious" participant tries to destroy the network.
If we assume that the majority is honest and isn't more lazy than the greedy+malicious participants, then PoA is more secure than pure-PoW (lazy means that honest participants provide less PoA signatures than greedy+malicious participants).
It isn't all that clear whether those who participate in the double-spending-bribes service are greedy or malicious, because if this service is successful then it obviously hurts the network. There's also an issue regarding your self-interest, because when the honest participants see that you provide signatures for the double-spending-bribes service they might blacklist your stake, etc. Therefore, it can make sense to assume that the majority of stakeholders are honest, as we assume with Bitcoin that the majority of miners are honest.
If this double-spending-bribes service was such a great idea, then it raises the question of whether such service is plausible with the pure-PoW Bitcoin network. As mentioned in earlier posts, the technical difference is that with PoA the greedy participants can provide their signatures both to the honest network and to the attacker (who pays them more), and if the attacker's fork fails then they still earn their regular reward with the honest network. With pure-PoW, the greedy participants contribute their hashpower to the attacker's fork, and if his attack fails then they earn nothing. So for pure-PoW, if this double-spending-bribes service is so great then maybe the (malicious, not greedy) attacker could incentivize greedy participants to contribute their hashpower to his attack by giving them significantly higher rewards, so it becomes worthwhile for them even after taking into account that when the double-spending attack fails they earn nothing.
One way to overcome this issue is to allow the PoA signature to be provided only in the next (say) 6 blocks, so now a greedy participant cannot withhold his signature from the honest network, as it'd be invalid if they try to provide it after 6 blocks. This idea doesn't necessarily interfere with the earlier issue that I mentioned here regarding the first attack vector (3rd paragraph of "Best Chain" subsection in the OP), for example if the protocol specifies that honest miners should include the PoA txn even after 6 blocks (but before 100 blocks) if they saw and verified a competing branch in which this PoA txn was included at depth 6 blocks or less, but the honest miners shouldn't include the PoA txn if if they just receive it for the first time after more than 6 blocks, and when calculating the blockchain-difficulty the relevant number for PoA txn to be valid is 100 rather than 6. However, the attacker could just release his losing branch anyway, to get the signatures included in the honest branch. I'm not sure if 6 blocks window for including the PoA signature is a good idea anyway, if it is then maybe there could be better ways to do it that I didn't think of.

Overall I still think that the PoA protocol as outlined by coblee is the best proof-of-stake scheme that we should implement in Litecoin. The option to have signing-key delegation is probably risky+problematic, so striving for e.g. 10% of the reward for stakeholders (who take the extra risk of using unencrypted wallet) seems like a good idea.

[killerstorm]

Where does killerstorm's 1/q number come from, at https://bitcointalk.org/index.php?topic=102342.msg1139483#msg1139483 ?

It just means that attack is probabilistic, i.e. I do not need to attack at certain time with 100% certainty, but chances of success of 1/q are OK for my goals. q is something like "time I can spend on doing one attack on PPCoin, measured in blocks". (Suppose number of successful attacks has binomial distribution, n = q, p = 1/q. Then mean number of successful attacks in q blocks is q * (1/q) = 1.)

If you want 1 successful attack per week, choose q = 144*7=1008.

[iddo]

OK I wrongly assumed that you wait q blocks and then do q attempts to build your k-blocks secret branch, to have q*1/q=1 successful attempt as the expectation, so overall you attack once every 2q blocks (where you sit idle for the first q blocks, but now I see that you meant that the time you sit idle is unrelated to q). Actually a crude upper bound would be q+k*q instead of 2q because of failed attempts that started but didn't reach length k.
Obviously it makes sense that p can be smaller when q is bigger, but this p^k * C(n, k)*k! > 1/q calculation doesn't take into account coin-confirmations at all? (i.e. that you have better probabilities at the later attempts because you have more coin-confirmations). So I suppose that a more precise calculation will show that you can have a (significantly?) smaller p to do double-spending attacks?

[cunicula]

We need to make a list of objectives and then identify a proposal which best satisfies them. It would be better to agree on objectives first and then try to find a framework which realizes them. Otherwise people will talk past one another. Everyone is biased towards their own ideas.

Here are my own objectives:

1) Very expensive to perform a persistent 51% attack even with low aggregate hash rate.
2) Selling voting power to a third party is costly/personally risky.
3) 6 conf txns can be trusted even if an attacker controls 51% of work but no stake.
4) Attacker cannot perform 6-block reorgs with monthly frequency without controlling at least 10% of work and 10% of stake.
5) Constant returns to scale. i.e. Returns you get from 2% of stake and 2% of hashing power are approximately double those of 1% of stake and 1% of hashing power.
6) Voting for a fork which is not the main chain is costly.
7) Protocol rules are simple and transparent.

Do these seem reasonable to everyone else? Is there something which should be added to the list?

[iddo]

We need to make a list of objectives and then identify a proposal which best satisfies them. It would be better to agree on objectives first and then try to find a framework which realizes them. Otherwise people will talk past one another. Everyone is biased towards their own ideas.

Here are my own objectives:

1) Very expensive to perform a persistent 51% attack even with low aggregate hash rate.
2) Selling voting power to a third party is costly/personally risky.
3) 6 conf txns can be trusted even if an attacker controls 51% of work but no stake.
4) Attacker cannot perform 6-block reorgs with monthly frequency without controlling at least 10% of work and 10% of stake.
5) Constant returns to scale. i.e. Returns you get from 2% of stake and 2% of hashing power are approximately double those of 1% of stake and 1% of hashing power.
6) Voting for a fork which is not the main chain is costly.
7) Protocol rules are simple and transparent.

Do these seem reasonable to everyone else? Is there something which should be added to the list?

I wish that we could come up with a protocol that is at least as secure as pure-PoW, with extra proof-of-stake properties that may enhance the security, but don't introduce new security risks when compared to pure-PoW.
If the proof-of-stake signatures become valid only after many more blocks compared to the default 6-conf double-spending safety length, then the proof-of-stake can be thought of just as replacing the need for hardcoded developers checkpoints.
With Litecoin we could have the luxury of switching from default 6-conf to default 24-conf, so there's room to play with the numbers.

If we agree that (2) is risky then signing-key delegation is probably a bad idea (mentioned in post #14 here). It also probably requires linkages on the blockchain (though one linkage per deterministic wallet can be done), so miners might reasonably expect fees for the extra work. I doubt it's possible without linkages, I tried to ask gmaxwell about his comments (link), but he hasn't replied.
So it'd mean that stakeholders should either use an unencrypted wallet, or maybe they could register their email address on some blockexplorer website and receive notification when they should provide their proof-of-stake signature (for lucky-num proof-of-stake schemes such as PoA).

There's a contradiction between allowing stakeholders who aren't running their client 24/7 with unencrypted wallet to participate (by having a long time/blocks limit to provide the proof-of-stake signature), and attack scenarios like killerstorm's double-spending bribes service (where we'd rather allow only a short time/blocks limit to provide the proof-of-stake signature).

In (6) I suppose you mean that it should be costly for attackers to vote in competing forks, because we shouldn't punish honest miners who saw the losing branch first and signed it. But with lucky-num schemes this scenario doesn't occur anyway (discussed in post #47).

Regarding (4), with PoA an attacker with 10% of hashpower and 10% of stake cannot do anything, he's actually in worse shape compared to an attacker on pure-PoW network with 10% hashpower. But killerstorm conjectures that the attacker can get >50% stake using bribes service because stakeholders aren't honest, so maybe we should brainstorm about external remedies to handle such non-honest stakeholders, like blacklisting their stake, because the bribes service cannot be anonymous.

I would like to add one very important property to your list (though it might be considered orthogonal to proof-of-stake), which is security against attackers with large hashpower who try to deny txns (link). Security from this kind of attack is arguably even more important than security from double-spending attacks. Any thoughts on the best ways to implement this?

[cunicula]

If we agree that (2) is risky then signing-key delegation is probably a bad idea (mentioned in post #14 here).

A middle-of-the-road approach is appropriate here. Signers should have some skin in the game, but not too much.

Here is what I mean:
Two keys controlling the coins: 1) Full Spend Key 2) Sign/Withdrawal Limit Key
The withdrawal limit key can only include 1/k of the private key balance in any one txn (txns with this key must send k coins to the input address(es) for every 1 coin sent to an external address). That means it would take k blocks to deplete the full balance using the limited spend key. k could be user specified, but would have to be lower than a maximum value (say 10,000). Selling your withdrawal limit key to someone else would be very risky. Exposing your withdrawal limit key to the internet would be slightly risky too, but it is a limited risk because you can always invalidate key 2 using key 1. Withdrawal limits are a useful feature anyways.

In (6) I suppose you mean that it should be costly for attackers to vote in competing forks, because we shouldn't punish honest miners who saw the losing branch first and signed it. But with lucky-num schemes this scenario doesn't occur anyway (discussed in post #47).

PoA fails on point 6. As does every other PoS proposal except for my own. I'm an economist. Economists always assume profit-maximization. If you tell them that honest miners exist, they will say you're full of shit. Everyone is greedy according to economists. If you accept that (and I think the system should operate on that premise), proof-of-stake signing needs to involve opportunity cost in order for it to function as a branch selection mechanism. It needs to be more costly to sign two forks than it is to sign one fork. Otherwise, signing every fork you see is the strictly dominant strategy for miners. If all forks are signed, proof-of-stake will be completely useless as a security mechanism. To solve this, stake signatures need to be jointly submitted with proof-of-work.

This problem applies to Meni's proposal, PPCcoin, POA, etc. Killerstorm's suggested improvements. None of those ideas involve joint submission of work and stake. That is not good. Submission should be joint. Otherwise proof-of-stake has no theoretical purpose.

I'm not the only person who is hung up on this issue:
https://en.bitcoin.it/wiki/Talk:Proof_of_Stake   - look at the first comment by Ian Stewart (you can ignore the rest)
Luke-Jr puts it well here:

Proof-of-stake (at least all existing attempts I know of) also allows miners to use it for attacks in parallel to the legitimate blockchain. That is, there is no cost to attempt to fork the blockchain. Incentively speaking, this means rational miners should mine every chain that does not hurt them personally.

Also in this thread:

As far as the overall design goes, it seems to me that it has a weakness I'd call "unavailability of the preferable alternative" or a hobson's-choice-attack that I think exists in all the stochastic PoS schemes I've looked at.

I would like to add one very important property to your list (though it might be considered orthogonal to proof-of-stake), which is security against attackers with large hashpower who try to deny txns (link). Security from this kind of attack is arguably even more important than security from double-spending attacks. Any thoughts on the best ways to implement this?

Yes, I agree completely. In fact this is what I mean by persistent 51% attack, that is point (1). In my view, solving this is the whole point of proof-of-stake. Double spends are a side issue (albeit an important one).

[cunicula]

Any thoughts on the best ways to implement this?

I have a very simple proposal which an elaboration of the one in the proof-of-stake wiki. The proposal in the wiki is weak to short reorgs if the proof-of-stake weighting is high (see criticism by killerstorm). This is simple to fix, but requires introducing higher weighting on proof-of-work. However, it is possible to have the best of both worlds. To do this, include two types of blocks with type-specific weightings and difficulty settings. Block A can have a 0.1 stake weighting and a 0.9 work weighting. Block B can have a 0.9 stake weighting and a 0.1 work weighting. To be valid, blocks must be added in an ABABABAB pattern. Block A difficulty targets an average waiting time for each A block of x minutes.  Block B difficulty targets an average waiting time for each B block of x minutes. Users trust a txn once it receives 6 confirmations (i.e. 3 of type A and 3 of type B).

[yaffare]

In my opinion the only thing you all do is increase the difficulty of performing an attack.

This does not solve anything.

We must find a general way to completely eliminate attacks. If [richguy/country] wants to takeover bitcoin, they dont care if its
1 or 100 billion to spend for hardware.

I made a proposal by myself, but this is another topic.

[iddo]

If we agree that (2) is risky then signing-key delegation is probably a bad idea (mentioned in post #14 here).

A middle-of-the-road approach is appropriate here. Signers should have some skin in the game, but not too much.

Here is what I mean:
Two keys controlling the coins: 1) Full Spend Key 2) Sign/Withdrawal Limit Key
The withdrawal limit key can only include 1/k of the private key balance in any one txn (txns with this key must send k coins to the input address(es) for every 1 coin sent to an external address). That means it would take k blocks to deplete the full balance using the limited spend key. k could be user specified, but would have to be lower than a maximum value (say 10,000). Selling your withdrawal limit key to someone else would be very risky. Exposing your withdrawal limit key to the internet would be slightly risky too, but it is a limited risk because you can always invalidate key 2 using key 1. Withdrawal limits are a useful feature anyways.

Very interesting idea, delegating withdrawal-limited keys could answer coblee's concern. The exact behavior of the withdrawal limit can be debated, but the minimal limit has to be high enough to avoid delegating to that central signing entity from post #14. I agree that withdrawal-limited keys could be useful independently of proof-of-stake.
As for the implementation, I still think that the most straightforward option is that the proof-of-stake signature will sign an extra field with the delegated pubkey (i.e. this is where the linkage is established), and when using the corresponding delegated privkey you also specify the linkage block number, so the miners have to look at that older block to verify your (withdrawal-limited) signature. (earlier post on this).

In (6) I suppose you mean that it should be costly for attackers to vote in competing forks, because we shouldn't punish honest miners who saw the losing branch first and signed it. But with lucky-num schemes this scenario doesn't occur anyway (discussed in post #47).

PoA fails on point 6. As does every other PoS proposal except for my own. I'm an economist. Economists always assume profit-maximization. If you tell them that honest miners exist, they will say you're full of shit. Everyone is greedy according to economists. If you accept that (and I think the system should operate on that premise), proof-of-stake signing needs to involve opportunity cost in order for it to function as a branch selection mechanism. It needs to be more costly to sign two forks than it is to sign one fork. Otherwise, signing every fork you see is the strictly dominant strategy for miners. If all forks are signed, proof-of-stake will be completely useless as a security mechanism. To solve this, stake signatures need to be jointly submitted with proof-of-work.

I agreed earlier that we should assume that the majority is greedy rather than honest, but I'm less inclined to agree that stakeholders who participate in double-spending-bribes service are greedy rather than malicious. Also it might be risky because others could retaliate and blacklist your stake.
I agree that if stakeholders could provide their signatures to competing chains with impunity then the proof-of-stake scheme is worthless.
Any comments of my technical suggestion in post #47 for protocol behavior to deal with this issue? If the recommended safety length for double-spending protection is 6 confirms, and the protocol enforces that you cannot provide your proof-of-stake signature after 6 blocks, then you would select and sign only one branch (because signing multiple branches would be useless for the attacker).

I would like to add one very important property to your list (though it might be considered orthogonal to proof-of-stake), which is security against attackers with large hashpower who try to deny txns (link). Security from this kind of attack is arguably even more important than security from double-spending attacks. Any thoughts on the best ways to implement this?

Yes, I agree completely. In fact this is what I mean by persistent 51% attack, that is point (1). In my view, solving this is the whole point of proof-of-stake. Double spends are a side issue (albeit an important one).

Right, I now see that your point (1) meant to deal with this issue, apologies.
I also see that your next post #53 shows that this issue isn't necessarily unrelated to proof-of-stake, though it's still plausible that incorporating BDD could help too.
What would be the disadvantage of simply using pure-PoW for type A blocks?

[iddo]

We must find a general way to completely eliminate attacks.

This statement doesn't make sense. You can do brute-force attack on ECDSA with 2^128 iterations, to steal coins.

I made a proposal by myself, but this is another topic.

IMHO that proposal also doesn't make sense, allowing human discretion instead of using hardcoded protocol rules whenever a long re-org occurs is a terrible idea. See post #27 (and #26) here.

[cunicula]

[ If the recommended safety length for double-spending protection is 6 confirms, and the protocol enforces that you cannot provide your proof-of-stake signature after 6 blocks, then you would select and sign only one branch (because signing multiple branches would be useless for the attacker).

This doesn't help at all.

Assume you get a reward b for signing a branch and that the good branch ends up as the main chain with probability p. One of the bad branches will end up as the main chain with probability 1-p.

Suppose the official software allows you to sign only one branch. The expected payoff from signing the good branch is pb.

Now suppose unofficial software allows you to sign multiple branches. The expected reward payoff from signing multiple branches is b. Provided reorgs occur with positive probability, p > bp.
The unofficial client has strictly superior payoffs to the official client. Greedy people like it. Why should they care if they are signing a double-spend? It not going to be their coin at risk.

If everyone uses the unofficial client, proof-of-stake has absolutely no security functionality whatsoever. Use of the official client cannot be forced. Essentially you are relying on laziness and irrationality to secure the blockchain.

How do you prevent this? Stake signatures must be accompanied by proof-of-work. The proof-of-work costs w to create.

Say p(i) is the probability that branch i emerges as the main chain. The expected payoff from signing a branch i is p(i)b-w. You sign if p(i)b>=w and you do not sign otherwise. In other words, you only sign the main chain. You do not sign attackers chains. Attackers have to deal with the fact that you only sign their crap if you expect their attack to succeed with high probability. This makes it quite difficult to get a successful attack going.

Proof-of-stake works as intended. My proposals have always incorporated this essential feature. None of the other proposals have bothered to include it. PPCoin does not have it either.
 

[iddo]

uses the unofficial client, proof-of-stake has absolutely no security functionality whatsoever.

The official client behavior is that after you've signed one branch, you'll sign a competing branch only if you discover that this competing branch is winning (excluding the signature that you'd provide is probably the better rule).
If the unofficial client signs all the branches that it sees, then using the unofficial client is either greedy or malicious (let's not differentiate for the two for the moment), and if everyone uses the unofficial client then the network is equivalent to pure-PoW. This is the objective that I'm trying to achieve, i.e. that if the stakeholders are honest then the network is more secure than pure-PoW, and if the stakeholders are greedy/malicious then the network is at least as secure as pure-PoW.

Your comments appear to refer to the scenario where greedy stakeholders sign shorter public branches, to maximize their reward probability. Note that the double-spending attack scenario is different, there the attacker prepares 6-blocks branch in secret, bribes stakeholders to sign his secret branch, and then broadcasts his branch after it's at least 6-blocks deep and is the winning branch. If stakeholders refuse the bribe then they earn their regular reward on the honest network, if they accept the bribe then the attacker supposedly offers them a higher reward, but (unlike what killerstorm described) they cannot participate in the attack and then expect to collect the regular reward on the honest network in case the attack failed, because the attacker wouldn't want to pay stakeholders who also sign the honest branch in less than 6-blocks and therefore don't contribute to his attack. In other words, this kind of double-spending-bribes service is exactly the same as what can be achieved with pure-PoW network, as described in post #47.

If we could really agree that we have a protocol that is always at least as secure as pure-PoW, and more secure if stakeholders are honest, then IMHO it'd be major progress. Edit: Of course I don't rule out the possibility that your protocol would be even better, I'm just saying that if we could establish a protocol that is at least as secure as pure-PoW, then we would have a clear milestone that we could try to improve upon.
The problem is that even if you agreed with everything I said here, technically it's still unclear whether we could have a protocol that achieves these properties. Did you also consider my comments on how the protocol could enforce 6-blocks window for signing?

[cunicula]

The idea that the double-spend will need to be secret is silly. Profitable double-spends are likely to involve trading in financial assets. Other kinds of double-spends probably won't generate a large enough payoff to be worthwhile. All you will want to do is reverse an unfavorable trade. You don't need to steal the asset you traded. These double spends can be completely public. The public double spend problem could be made more severe by PoA.

Say for example you buy a large amount of USD and the BTC price goes up. You now regret your USD purchase and want execute a double spend.

90% of miners use my unofficial client and thus play no role in branch selection. The remaining 10% participate in the txn reversal service. The attacker pays them to withhold signatures from the good chain and only add them to his branch. The good branch will have 90% of possible signatures. The bad branch will have 100% of possible signatures. Voila double spend. The double spend is made easier by proof-of-stake.

To fix this, you need to introduce incentives which make use of the unofficial client unprofitable. i.e. submitting a stake signature must require an investment in work.

In game theory, signals (read stake signatures) which have no opportunity cost are called "cheap talk". In many kinds of games, "cheap talk" does not help players achieve good outcomes. By contrast, costly signals are more effective. That is the basic principle involved here.

[cunicula]

What would be the disadvantage of simply using pure-PoW for type A blocks?

It would work. This choice is not a big deal. I would need to simulate different scenarios before I could advocate for a specific weighting.

Main point:
Block A mostly or all proof-of-work
Block B mostly, but not all proof-of-stake

I can't be more precise about 'mostly' without some simulations.

[iddo]

Say for example you buy a large amount of USD and the BTC price goes up. You now regret your USD purchase and want execute a double spend.

90% of miners use my unofficial client and thus play no role in branch selection. The remaining 10% participate in the txn reversal service. The attacker pays them to withhold signatures from the good chain and only add them to his branch. The good branch will have 90% of possible signatures. The bad branch will have 100% of possible signatures. Voila double spend. The double spend is made easier by proof-of-stake.

Attacker A sends coins to merchant B, so that B waits and sees the branch where he received the coins with 6-confirms, and then B sends the merchandise (e.g. USD) to A, and then A reverses the branch so that the new winning branch doesn't have the txn that transferred the coins from A to B.
If 90% of stakeholders don't participate in the attack, the we expect that 90% (or say 90/2=45%) of the blocks in the branch that B saw were signed, while at most 10% of the attacker's secret branch were signed.
If the attacker doesn't build his branch in secret, and instead tries to build it by broadcasting his competing branch to the entire network in order to collect signatures from all the greedy stakeholders, then B can scan the network and discover the double-spend attempt, and refuse to send the merchandise to A.

[cunicula]

Say for example you buy a large amount of USD and the BTC price goes up. You now regret your USD purchase and want execute a double spend.

90% of miners use my unofficial client and thus play no role in branch selection. The remaining 10% participate in the txn reversal service. The attacker pays them to withhold signatures from the good chain and only add them to his branch. The good branch will have 90% of possible signatures. The bad branch will have 100% of possible signatures. Voila double spend. The double spend is made easier by proof-of-stake.

Attacker A sends coins to merchant B, so that B waits and sees the branch where he received the coins with 6-confirms, and then B sends the merchandise (e.g. USD) to A, and then A reverses the branch so that the new winning branch doesn't have the txn that transferred the coins from A to B.
If 90% of stakeholders don't participate in the attack, the we expect that 90% (or say 90/2=45%) of the blocks in the branch that B saw were signed, while at most 10% of the attacker's secret branch were signed.
If the attacker doesn't build his branch in secret, and instead tries to build it by broadcasting his competing branch to the entire network in order to collect signatures from all the greedy stakeholders, then B can scan the network and discover the double-spend attempt, and refuse to send the merchandise to A.

?

There is no secret branch. It is a public attack. It can begin after the seller releases the goods. The problem I'm pointing out is that the 90% may participate in the attack passively by signing all branches they see. The remaining 10% are active attackers. They only sign the attacker's branch. Causing the attacker to win.

To reiterate, the issue is that if the majority of people sign all forks in order to maximize their block reward, the resulting system is worse than proof-of-work. The majority may cast multiple contradictory votes out of greed. A small minority could then cast decisive votes for attacking forks in exchange for a bribe. This never occurs in proof-of-work because you can't vote twice without paying double.

[iddo]

There is no secret branch. It is a public attack. It can begin after the seller releases the goods. The problem I'm pointing out is that the 90% may participate in the attack passively by signing all branches they see. The remaining 10% are active attackers. They only sign the attacker's branch. Causing the attacker to win.

If it's a public attack that starts after the seller released the goods, then the branch that the seller sees has a 6-confirms head start, or even 24-confirms with Litecoin (see here). This means that the attacker will need much more than 50% hashpower, assuming for example 2x weight for signed blocks and 10% advantage in proof-of-stake signatures for the attacker's branch.

However, this entire scenario that we discussed in the last few posts doesn't jibe with PoA, because each individual stakeholder address gets the opportunity to sign only one of the competing branches (when it wins the follow-the-satoshi lottery, probability for an address to win in two concurrent branches is negligible). This means that the attacker cannot tell whether a stakeholder who accepts the bribe also participates in the honest network. Therefore, the rational behavior for all the greedy stakeholders is to accept the bribe and sign the attacker's branch when they win the lottery in his branch, and simultaneously also sign the honest branch when they win the lottery there. So the attacker won't have 10% advantage, all the stakeholders will simply snatch his bribe payments and sign both his branch and the honest branch, so the attack will fail and the attacker just loses money.

[cunicula]

There is no secret branch. It is a public attack. It can begin after the seller releases the goods. The problem I'm pointing out is that the 90% may participate in the attack passively by signing all branches they see. The remaining 10% are active attackers. They only sign the attacker's branch. Causing the attacker to win.

If it's a public attack that starts after the seller released the goods, then the branch that the seller sees has a 6-confirms head start, or even 24-confirms with Litecoin (see here). This means that the attacker will need much more than 50% hashpower, assuming for example 2x weight for signed blocks and 10% advantage in proof-of-stake signatures for the attacker's branch.

However, this entire scenario that we discussed in the last few posts doesn't jibe with PoA, because each individual stakeholder address gets the opportunity to sign only one of the competing branches (when it wins the follow-the-satoshi lottery, probability for an address to win in two concurrent branches is negligible). This means that the attacker cannot tell whether a stakeholder who accepts the bribe also participates in the honest network. Therefore, the rational behavior for all the greedy stakeholders is to accept the bribe and sign the attacker's branch when they win the lottery in his branch, and simultaneously also sign the honest branch when they win the lottery there. So the attacker won't have 10% advantage, all the stakeholders will simply snatch his bribe payments and sign both his branch and the honest branch, so the attack will fail and the attacker just loses money.

?

The bribe is paid to people who could have signed the valid chain, but chose not to. The fact that potential signatories are selected at random is irrelevant. These people can either be publicly identifiable (i.e. lottery is public) or they can announce themsevles in a verifiable way to the bribery service (i.e. lottery is private). The bribery service can wait for these people to perform the attack before paying them.

Bribery of a small minority is sufficient to obtain a majority of stake signatures. With pure PoW or joint submission PoS/PoW you can still bribe people, but you would need to bribe a majority.

The whole problem is due to the greedy stakeholders signing everything instead of being selective. Lack of selectivity is due to costless signatures. Fix is simple. Make signing stuff costly.

Sigh, why continue discussion of this proposal when I have already
a) explained why PoA, Meni's system, killerstorm's suggestions, PPCoin, etc. are critically flawed
b) suggested a solution to the problem (which is not at all new and has always been part of my proposal. The ABAB thing is a response to killerstorm's criticisms. I don't think the issue he raises is nearly as important, but it is significant enough to merit a fix.)
                                                

[iddo]

The bribe is paid to people who could have signed the valid chain, but chose not to. The fact that potential signatories are selected at random is irrelevant. These people can either be publicly identifiable (i.e. lottery is public) or they can announce themsevles in a verifiable way to the bribery service (i.e. lottery is private). The bribery service can wait for these people to perform the attack before paying them.

So some stakeholder with say 10,000 BTC will identify himself to the attacker's bribe service by signing with the privkeys that control the 10,000 BTC and promising that he won't sign the honest chain whenever the attacker declares that a double-spending attack begins. The attacker verifies that this stakeholder doesn't sign in the honest chain whenever an attack is in progress. If the attacker tries to double-spend all the time, then this stakeholder shouldn't sign on the honest chain at all. In your scenario there are many stakeholders such as this one, who provided verifiable evidence that proves that they participate in the double-spending bribe service, so the total stake used by the bribes service is e.g. 10%. Furthermore, the honest chain will have a head start of 6-confirms or 24-confirms, because the attacker also needs signatures from all the other stakeholders to get 10% advantage over the honest chain.
What incentive does the attacker have to pay these 10% of stakeholders after the attack succeeds?
Wouldn't these 10% of stakeholders earn more coins by signing the honest chain?
Shouldn't stakeholders be worried of retaliation if there's verifiable evidence that they participate in double-spending-bribes service, e.g. the other 90% of stakeholders could decide that those 10% of stakeholders diminish the value of the cryptocurrency and therefore their stake should be blacklisted ?
Wouldn't the attacker need to sustain more than 50% hashpower for a long period of time until his chain wins? The honest miners won't help the attackers while his chain is small, even if it's public, so if it's 2x weight for a signed block and there's e.g. 12 blocks gap to close, the attacker has 10% advantage in signing and an advantageous signed block closes 2 blocks in the gap instead of 1 block, so overall we'd say that the attacker needs to close a gap of about 10 blocks as if he didn't have any advantage in signing?

Sigh, why continue discussion of this proposal when I have already
a) explained why PoA, Meni's system, killerstorm's suggestions, PPCoin, etc. are critically flawed
b) suggested a solution to the problem (which is not at all new and has always been part of my proposal. The ABAB thing is a response to killerstorm's criticisms. I don't think the issue he raises is nearly as important, but it is significant enough to merit a fix.)

You explanation of why PoA is (critically) flawed isn't convincing yet.
I think that we should also discuss your system, the ABAB idea looks promising.
Maybe we should also discuss a hybrid of your system and PoA, similar to what you suggested in post #43. We can also look at from the perspective of extending PoA, i.e. the signed block should be supplement with PoW hash of certain difficult, to make it costly for stakeholders to sign blocks. It's still unclear to me whether that'd be a good idea. I hope that as a result of these discussions we will converge to one proof-of-stake system in the end. For actually implementing some system in Litecoin, there should be bias towards simplicity, which is point (7) in your list of objectives.

[cunicula]

What incentive does the attacker have to pay these 10% of stakeholders after the attack succeeds?
Wouldn't these 10% of stakeholders earn more coins by signing the honest chain?

The same reason that a silk road vendor sends the product after he receives coins. He needs repeat business. If you hire miners and don't pay them, then you won't be able to hire them again.

Think about the following attack scenario. Suppose that normally all blocks receive signatures. This happens on every fork because miners are rational/

He wants to double-spend a txn located in block 1. His fork will always be 100% fully signed. He won't be able to create as much work as the main chain, but he's going to compensate by weaking the stake signatures in the main chain so that he can double-spend. His fork will have 100% singed blocks. The main chain will have a sequence of unsigned blocks.

The attacker can ask his 10% of signers to carry out the following orders.

1) Please do not sign at block 1.
2) Please do not sign at block 2. However, if block 2 is signed, then give up and sign at block 1.
3) Please do not sign at block 3. However, if block 1 or block 2 are signed, then give up and sign at blocks 1,2, and/or 3.

If 10% of miners are participating in the attack service, then you get three participants in a row once ever 1000 blocks. If you don't get three participants in a row, then the attack is called off ex-post. There is no attack, but the malicious miners don't pay any penalty either. They still get their full reward for stake signatures. If the attacker links three blocks in a row with no stake signature, then the attack is in motion. We assume that the attacker is completely sure that with 3 unsigned blocks in a row on the main chain, then he can execute a successful attack. If the attacker is not certain, then just increase his advantage to 4 unsigned blocks in a row (once every 10k blocks). Then, the attackers employees lose nothing from conducting the attack relative to just mining the main chain.

In this scenario, the malicious stakeholders lose absolutely nothing as a consequence of the attack. If the attacker pays them 0.01 BTC each as a bribe, then they have a net gain of 0.01 BTC each.

[cunicula]

Maybe we should also discuss a hybrid of your system and PoA, similar to what you suggested in post #43.

The problem with the hybrid scenario in post #43 is that it does not satisfy constant returns to scale. Under the hybrid, 2% stake and 2% work yields more than twice as many blocks as 1% stake and 1% work.

I haven't yet figured out how to achieve the following three objectives simultaneously:
a) use a lottery to determine the the stake signatory
b) require work to accompany all stake signatures
c) maintain constant returns to scale (i.e. so that simultaneously doubling stake and hashing power just doubles output [at least to a close approximation])

I'd be happy with the hybrid if it satisfied constant returns to scale.

Of (a), (b), and (c), I would say that (b) and (c) are important whereas (a) is not necessary.

[iddo]

Hello cunicula,

Regarding ABAB:
I'm not so sure whether ABAB gives better protection from attacker with 50% hashpower who tries to double-spend by doing 6-block reorg, compared to the Bitcoin pure-PoW protocol.
Let's assume type-A is pure-PoW and type-B is heavily weighted towards proof-of-stake (for example as you said 0.9 stake weighting and a 0.1 work weighting).
Without going into the exact calculations, let's just say that if the attacker has 1% of the active network stake which he divides equally among 3 addresses, and he waits for about one week, then with his hashpower he can generate 3 consecutive type-B blocks ahead of the distributed network. Since he has 50% of the entire network hashpower, he can also generate the 3 interleaved type-A blocks, and thereby create 6-block reorg and double-spend.
So the only difference between the pure-PoW protocol and ABAB with respect to attacker with 50% hashpower is that the attacker has to sit idle for a while (one week or some different time frame, depending on the other parameters) before launching his double-spending attack? Am I missing something here?

Interestingly, I think that the type-B blocks (or simply your original protocol) offer good protection from attacker who wishes denies txns and destroy the network, because he couldn't generate all the type-B blocks once he runs out of coin-confirms.

I mentioned in post #31 another advantage that the double-spending attacker has: if the honest participants divide their stake among e.g. 10 addresses on average, and the attacker divides his stake among 3 addresses, then it's advantageous for the attacker in order to achieve 3 consecutive type-B blocks, because his coin-confirms will be concentrated in 3 addresses instead of 10 addresses and therefore carry more weight in the difficulty calculation, compared to the average miner. An honest miner who divides his stake among 10 address (so not to put all his eggs in one basket) would do hash attempts with only one of his 10 addresses while trying to solve the current block, it's pointless for him to do 10 different attempt concurrently because that's the same as having 10x less hashpower. So for double-spend attacks the optimal number of addresses should be the same as the length of the reorg, which doesn't necessarily coincide with the number of addresses that an honest miner would choose to have.

The issue of waiting e.g. one week before launching the double-spending attack occurs because of the coin-confirms property of the difficulty calculation. The PoA scheme doesn't use coin-confirms, so this wait-one-week-to-double-spend issue doesn't occur there. On the other hand, the PoA scheme as it is doesn't handle the attacker-who-denies-txns issue at all. I'm still hoping that we could refine all the ideas and converge to some superior scheme.

[cunicula]

Hello cunicula,

Regarding ABAB:
I'm not so sure whether ABAB gives better protection from attacker with 50% hashpower who tries to double-spend by doing 6-block reorg, compared to the Bitcoin pure-PoW protocol.
Let's assume type-A is pure-PoW and type-B is heavily weighted towards proof-of-stake (for example as you said 0.9 stake weighting and a 0.1 work weighting).
Without going into the exact calculations, let's just say that if the attacker has 1% of the active network stake which he divides equally among 3 addresses, and he waits for about one week, then with his hashpower he can generate 3 consecutive type-B blocks ahead of the distributed network. Since he has 50% of the entire network hashpower, he can also generate the 3 interleaved type-A blocks, and thereby create 6-block reorg and double-spend.
So the only difference between the pure-PoW protocol and ABAB with respect to attacker with 50% hashpower is that the attacker has to sit idle for a while (one week or some different time frame, depending on the other parameters) before launching his double-spending attack? Am I missing something here?

Interestingly, I think that the type-B blocks (or simply your original protocol) offer good protection from attacker who wishes denies txns and destroy the network, because he couldn't generate all the type-B blocks once he runs out of coin-confirms.

No you aren't missing anything. The idea is just to preserve the 50% work requirement for an attack, but also protect the network from denial of txns. I guess you could say the goal is to make something strictly better than proof-of-work. In the sense that it offers complete proof-of-work protection + additional protection.

I'll think about an ABAB pattern, where the stake block is Colbee's proof-of-activity lottery. I think the proof-of-stake reward should be as in PPCoin. PPCoin is also a lottery BTW. It should be like interest, so that you get more reward if you have to wait longer to find a block. The proof-of-stake lottery guys would always be indifferent to rewriting history, which I see as a big problem. However, you could fix this by giving a larger reward to people who wait longer to find blocks (i.e. interest accumulates as a superexponential function instead of an exponential one)

superexponential means where t and T are two time points both greater than 0.
f(t)f(T)<F(t+T) [you get more finding one block at time T+t than you would finding one block at time t and one block at time T]
where with normal exponential growth rate of interest accumulation
f(t)f(T)=f(t+T) [this means you get just as much finding one block at time t and one block at time T as you would finding one block at time t+T]

This would mean that you get a larger reward if you find a later block. Finding a block is a lottery. You could write an alternate history at an earlier date where you also win the lottery.
However, since you earn less by winning the earlier lottery you will never want to write this alternate history. You don't want to wait forever either. Because it is a lottery and you might die before you ever win. I think you could just give all the txn fees to the work miners and pay out stake miners using inflation (say 1% year as in PPCoin; though it would be variable if interest is superexponential [more inflation when there is more hoarding])

It is a bit confusing however so I need to think about it more.

[sorry this is disjointed; ask a question and I'll clarify when I have more time]

[cunicula]

On the other hand, the PoA scheme as it is doesn't handle the attacker-who-denies-txns issue at all.

Could you elaborate on this issue? I don't understand what you mean.

[iddo]

On the other hand, the PoA scheme as it is doesn't handle the attacker-who-denies-txns issue at all.

Could you elaborate on this issue? I don't understand what you mean.

I meant that with PoA (or Meni's scheme etc.) where the miners first generate the blocks and only later the stakeholders add their signatures (that correspond to blocks that were already generated), an attacker with huge hashpower and without any stake could paralyze the network by excluding all txns in the blocks that he generates. Because stakeholders would only see the attacker's winning branch, no other branches will ever be generated, so they could only sign the attacker's branch. With PoA the attacker might wish to include the signature txns in his branch (depending on the rule for competing branches with same signed/unsigned prefix, post #47), but it doesn't matter because if signature txns are the only txns that are included then the network will be destroyed anyway.

Your idea about larger rewards for later blocks sounds interesting, but it's still vague. Does it involve the blocks timestamps, or just branch length is enough?

[cunicula]

Okay here is a proposal which mixes my ideas with colbees ideas. You can think of this as proof-of-public broadcast. Miners search for the seed to a number sequence that indexes the coins of several connected network peers. If they are not connected to the network it is impossible to successfully mine. The stake component in the initial block is just there to prevent denial of service by mining empty blocks.

The proposal aims to achieve 3 things [in my perceived order of importance]:
1) To make sustained denial of service by mining empty blocks exceptionally difficult (i.e. at least 20% stake and 90% work is required for example)
2) Make hidden extension of a chain to double spend almost impossible, i.e. for it to require something like 99.99% of work rather than just 51%, even for people who hold 10% stake.
3) To provide an incentive for stake providers to vote only once rather than multiple times.

The rules work as follows.

1) Mixed Stake/Work miner finds a tentative block. The work target is difficulty/coin-age.
2) The work submitted in this tentative block produces a sequence of lottery draws, randomly drawing an ordered sequence of 10 satoshis that are lottery winners.
3) The tentative block is transmitted in the network soliciting signatures from the lottery winners. The lottery winners must sign the block in sequence.
4) If a tentative block acquires a sequence of five consecutive signatures, it becomes a full block and can be extended. If not, then go to (1).
5) If a tentative block acquires five signatures, then a new tentative block can be mined. Mining this block requires hashing together the past proof of work block and the 5th, 6th, 7th, 8th, 9th, or 10th stake signature. Accordingly, you cannot begin looking for this block until the fifth signature is found. [Edited: to reflect iddo's comment]
6) Before the next block is found, signatures 6-10 can be added. These signatures increase block stability and miners will want to incorporate them if they become aware of them before finding a new block.
7) The chain with the highest total number of lottery-selected signatures is the valid chain. Highest difficulty can be used as a tie breaker.
Only the block itself includes txns. The blocks are timed for once every 10 minutes.

Notes:
a) It is almost impossible to get five randomly selected signatures in secret and hope to win. Thus objective 2 is achieved.

b) Objective 1 is achieved by the use of stake in step 1. You will run out of coin-age and no longer be able to deny service.

c) We still have the remain problem of stake-holders participating in multiple lotteries. Step (6) is combined with a reward scheme to address this.

Rewards:
1) The mixed stake/work miner is rewarded with txn fees. Double-spenders need a work advantage of many orders of magnitude. Difficulty can be extremely low without posing a security risk. Therefore energy efficiency can be very high and txn fees can stay very low forever (ignoring bandwidth and storage problems).

2) The signatories are rewarded with inflation. Their rewards are delayed until 500 blocks in the future. These operate like rewards in PPC coin. The signatories are allowed to submit coin-age in exchange for interest.  Submission is done at least 500+x blocks after the signature occurs. Submitted coins must have sat still for more than 500+x blocks to be eligible for interest. Perhaps, Age on coins is capped at one year (not sure if this is necessary).

3) The annual interest rate varies from 0 and 1.5%. Thus the annual money supply growth rate is between 0 and 1.5%. The interest rate increases with the number of signatures in the block that the lottery winner signed and also in the subsequent 9 blocks. Say there are a total of s sigs on these 10 blocks. S can vary between 50 and 100. The interest rate will be r=0.015*(s/50-1). You cannot know your interest rate in advance because it depends on future outcomes. You get high interest by signing chains which you expect to be widely signed. You get low or no interest by signing chains that have suspiciously few signatures (e.g. the bare minimum). Such low signature chains are nearly certain to be attack chains.

Note:
This reward system encourages signatories to bet on a single chain which they expect has the widest consensus support.  If you provide a marginal vote that helps an attack chain, then you get punished with forgone interest. This accomplishes point (3).

Final Note:
There is a lot of message relaying going on here. If a fraction p of stake is connected to the network, then the number of blocks you need to relay before finding a valid block is 1/p^5. If p is 0.5, then this is about 32 blocks. It is probably easier to have nodes keep track of which stakes are connected to the network, rather than have them send out every block attempt they see. The system maintains a list of nodes that were recently connected to the network (signatures in past blocks). It would be simple to take the list of 5,000-10,000 signatories from the last 1000 blocks and only relay blocks that matched say 3 out of 5 these signatories. Thus network traffic could be limited to blocks that were highly likely to obtain signatures. More generally, success probability can be predicted based on blockchain history using linear regression and only block attempts above a certain minimum success probability are worth transmitting.

The cap on age for interest purposes provides an incentive to participate and thus keep p high. If you don't participate at least once a year, you forfeit rewards. Even if you participated receently,
you still have some incentive to participate because this extends your interest exipration. It is like airline miles that expire. The participation incentive strengthens as the network grows in size. It is almost certainly nonlinear in coin-holdings. Very large holdings lead to positive, but weak incentives to participate [i.e. the age cap will rarely bind, so you can participate infrequently and be fine]. Moderate holdings lead to positive, strong incentives to participate [the age cap is likely to bind without frequent participation]. Very low holdings should not participate at all [the age cap is likely to bind even with frequent participation]. People with very low holdings should deposit their holdings in an online wallet, which would participate for them and offer them interest on savings. Even without the cap, there are weak incentives for participation. I think the cap is a good idea, however.

[iddo]

I think that there's a mixup between (a) and (b), objective 2 is achieved by (a) and objective 1 is achieved by (b) ?

I think that the core of your new idea is very intriguing. Instead of PoA where miners generate PoW blocks and stakeholders (derived deterministically from block hash with follow-the-satoshi) may or may not sign those blocks later (so signature for an earlier block appears in a later block), I think that a simplified version of your new idea can be described as follows: the miner who solved a block according to the current difficulty doesn't win yet, he has to broadcast the block that he solved to the network, and then the deterministically chosen stakeholder according to the hash of this solved block has to sign it, then announce to the network that the block is now valid, and now the blockchain can be extended from this block, by incorporating the hash of that stakeholder's signature in the next block.
This core idea might be cleaner than PoA, because now all the blocks are always signed, so we don't need to have questionable rules to decide the winning branch.

Regarding your particular suggestion of deriving 10 stakeholders deterministically via follow-the-satoshi instead of just 1 stakeholder, with the threshold of having the 5 first-derived stakeholders provide signatures before the block becomes valid (BTW it isn't so clear where these signatures should reside, they aren't inside the current block and won't be in subsequent blocks, so I guess they should be wrapped together with the current block as an extended data structure), if I understand correctly the purpose here is (supposedly) that stakeholders wouldn't want to sign the attacker's branch because we expect that the attacker's branch will get only 5 signatures or so, while we expect that the branch of the honest network will get 10 signatures, and stakeholders receive larger rewards if there are more signatures. But isn't there a problem with your suggestion because a particular stakeholder who got chosen in the attacker's branch doesn't also get chosen in the honest branch (except for with negligible probability), so it would be rational for this particular stakeholder to sign that attacker's branch in order to have a chance to get his individual reward (in the honest branch he wasn't chosen and wouldn't get any reward). Maybe the way to fix this issue is that the individual stakeholders never get any reward for the signature that they provide, and instead just have the rule that if more signatures are provided (closer to 10 instead of 5) then all the stakeholders are rewarded collectively, via lower rate of inflation or some other kind of reward?

I wonder if adjusting for 10 minutes block time is possible with this scheme, because of the dependency on the currently active stakeholders. There might also be new kinds of attacks by stakeholders, for examples stakeholders who collude by withholding the 5th signature, then releasing it at the same time in order to split the chain and create chaos?

I don't understand how trading coin-age for interest is supposed to work, could you elaborate?

From an economic perspective, I hope that objectives (1)+(2)+(3) can be achieved without a protocol that requires infinite monetary inflation. Maybe we could attempt to design two different protocols, one with infinite inflation, and one without, so that later the better protocol could be decided by also taking economic considerations into account. What do you think?

Regarding the complexity issues, indeed those might be a huge problem. Even just attaching 10 ECDSA signatures to each block is quite huge (extra 640 bytes per block). Having a good solution for delegating signing-keys might also be highly significant, and possibly add even more complexities. One major advantage of PoA is simplicity. We should try to simplify and minimize complexities wherever possible...

[cunicula]

I think that there's a mixup between (a) and (b), objective 2 is achieved by (a) and objective 1 is achieved by (b) ?

Yes. Fixed that. Good eye.

I think that the core of your new idea is very intriguing. Instead of PoA where miners generate PoW blocks and stakeholders (derived deterministically from block hash with follow-the-satoshi) may or may not sign those blocks later (so signature for an earlier block appears in a later block), I think that a simplified version of your new idea can be described as follows: the miner who solved a block according to the current difficulty doesn't win yet, he has to broadcast the block that he solved to the network, and then the deterministically chosen stakeholder according to the hash of this solved block has to sign it, then announce to the network that the block is now valid, and now the blockchain can be extended from this block, by incorporating the hash of that stakeholder's signature in the next block.
This core idea might be cleaner than PoA, because now all the blocks are always signed, so we don't need to have questionable rules to decide the winning branch.

Yes. It can be simplified. In fact it could look just like PoA except that you must find one signer before beginning the next block. The simple system would probably work pretty well. However, the complexity incorporates added security features. There is a trade-off. If you want simple, I prefer the ABAB system discussed earlier. I could understand why someone would prefer the ABAB system to this. The ABAB system seems inferior, but it is very simple to implement and understand.

Regarding your particular suggestion of deriving 10 stakeholders deterministically via follow-the-satoshi instead of just 1 stakeholder, with the threshold of having the 5 first-derived stakeholders provide signatures before the block becomes valid

The five stakeholder threshold just makes overwhelming work majorities almost useless for competition with the main chain. It might be overkill (i.e. large signature requirements pose communication problems). I'm not sure. Clearly 100 sigs is not feasible. 1 may be too few (double-spends will be too easy). 3 is probably enough.

(BTW it isn't so clear where these signatures should reside, they aren't inside the current block and won't be in subsequent blocks, so I guess they should be wrapped together with the current block as an extended data structure),

I think you have pointed out a significant problem here. The solution is simple though. Just allow the next block to be built off the signature in any block from 5-10. Thus all signatures go in to blocks and you will have to add them before the next block is found. Block miners will extend the chain using the highest signature number. High sig numbers decrease the probability that the block will be orphaned. You could add dangling signatures to old blocks, but signers wouldn't want to do this because signing minority chains exposes them to risk of forgone interest.

I don't understand how trading coin-age for interest is supposed to work, could you elaborate?

As far as trading coin-age for interest. It should be really simple. The public key you sign with has a balance and the coins associated with this key have not been spent or won the lottery for a known time period (call this age). Age is measured in years (units of 52560 blocks). Call age a, the balance b, and the interest rate r, 0<r<0.015. 500 blocks after you sign, the miner includes a generation txn which sends b*(exp(a*r)-1) to this public key.  

Winning the lottery frequently does not directly affect the amount of coins you earn. The lottery win allows you to withdraw early without facing an early withdrawal penalty (foregone interest). Winning frequently increases liquidity of your savings, but does not give you a bigger monetary reward. It is a very very small advantage. If you expect to win only extremely rarely, you will probably keep your coins in an online wallet. The online wallet can manage the mining for you. If you hold a large balance, then you will win frequently and can manage the coins yourself. Most of the wealth will be in large balances (wealth distributions are always highly unequal, e.g. in the US it is something like the top 1% has 40% of the wealth. The top 1% can handle their own mining. Everyone else could delegate.)

if I understand correctly the purpose here is (supposedly) that stakeholders wouldn't want to sign the attacker's branch because we expect that the attacker's branch will get only 5 signatures or so, while we expect that the branch of the honest network will get 10 signatures, and stakeholders receive larger rewards if there are more signatures. But isn't there a problem with your suggestion because a particular stakeholder who got chosen in the attacker's branch doesn't also get chosen in the honest branch (except for with negligible probability), so it would be rational for this particular stakeholder to sign that attacker's branch in order to have a chance to get his individual reward (in the honest branch he wasn't chosen and wouldn't get any reward). Maybe the way to fix this issue is that the individual stakeholders never get any reward for the signature that they provide, and instead just have the rule that if more signatures are provided (closer to 10 instead of 5) then all the stakeholders are rewarded collectively, via lower rate of inflation or some other kind of reward?

You are not getting a direct reward from signing. You can claim your interest in any case, just at a later date. You expect well-signed chains to remain well-signed. If you sign a well-signed chain, your expected interest rate is higher. If you sign a poorly-signed chain, your expected interest rate is lower. Therefore you are forgoing a benefit if you sign a poorly-signed chain (attack chain).  It only makes sense to do this if you need to move your coins very soon and prefer no interest to a penalized amount of interest. In this case you sign everything you see. I assume that a substantial number of stake holders (it does not even have to be the majority) will prefer to wait in order to earn a higher rate of interest. These only sign well-signed chains. They will rationally reject a lottery win in an attack chain. It is fine if 90% of people sign everything and 10% sign selectively. I think it will be the other way around though.

Why are attack chains weakly signed? Attack chains are mined privately using an overwhelming amount of work. An attacker will only want to generate 5 signature long sequence because (for an attacker) this is orders of magnitude easier than generating 6 7 8 9 or 10 signature long sequences. If you try to help him out by signing his chain, then you will get penalized.

The idea is that people begin in default behavior, signing one chain only. If you deviate from default behavior, but some strictly positive fraction of people remain in default mode, then you will get penalized for the deviation. Thus default behavior is a nash equilibrium. This differs from PoA where default behavior is not a nash equilibrium.

I wonder if adjusting for 10 minutes block time is possible with this scheme, because of the dependency on the currently active stakeholders. There might also be new kinds of attacks by stakeholders, for examples stakeholders who collude by withholding the 5th signature, then releasing it at the same time in order to split the chain and create chaos?

Yes, you can withhold the fifth signature, but then some other block will be found and built upon. You will need to add the fifth signature and then secretly find a new block. Secretly finding a new block is nearly impossible.

From an economic perspective, I hope that objectives (1)+(2)+(3) can be achieved without a protocol that requires infinite monetary inflation. Maybe we could attempt to design two different protocols, one with infinite inflation, and one without, so that later the better protocol could be decided by also taking economic considerations into account. What do you think?

This is not really inflation at all. A small amount of new money is printed, but it is distributed proportionally evenly among people who already have money. Say productivity grows by 1% a year.
In this case, prices will remain close to constant in the long-run, but your $1.00 will slowly turn into $1.01 each year. [productivity growth shows up as an increase in your balance instead of falling prices]
With bitcoin, prices fall by 1% each year, and your $1.00 balance remains as $1.00. [productivity growth shows up as falling prices]
The two situations are almost equivalent.

The difference is that there is an implicit tax on txns. You are penalized via loss of interest if you move your coins. The penalty is very small. Think of buying a television for US$400.
You have a choice. Do I buy it now, or do I wait 6 months to earn interest and then buy it? At most, 6 months of waiting could decrease the price by US$6. In practice, however effects will be much smaller than this. You could hold your money in an online wallet. They would store 90% of their holdings to earn interest and handle liquidity needs with the remaining 10% (just like a normal bank, except with a 100% reserve).
The loss of interest would then be reduced to $0.60. I don't think you will delay your television purchase for 6 months to save 0.15% off the purchase price. The implict txn tax will be really really tiny.

Regarding the complexity issues, indeed those might be a huge problem. Even just attaching 10 ECDSA signatures to each block is quite huge (extra 640 bytes per block).

640 bytes per block is very little in additional storage. The main issue is how much extra info has to be transmitted. The bandwidth requirement is more worrying because you need to transmit more than you store.

It sounds really difficult and taxing on the network, but I think that it could actually be much easier than it sounds. The miners don't actually need to transmit a large number of tentative blocks. They just need to search for blocks that match keys that have recently signed the blockchain. i.e. they search for historically active keys. They discard potentially valid blocks with keys that are rarely seen in signatures. They then transmit blocks that historically active keys can sign. These tentative blocks are likely to become valid. The final signatures in the sequence allow the blockchain to constantly update the record of historical activity. [These final signatures are increasingly random rather than miner selected, particularly sigs 6-10.] Thus, by referring to the blockchain, the miners always know approximately what type of sequence they are looking for.

This search might sound hard, but really it isn't. You are most likely searching for the public keys of Mt. Gox, Bitinstant, Bill Gates, blockchain.info, etc. A small number of people will hold a huge amount of stake. Searching for a small number of keys is not that difficult. Searching for the key to an average person's wallet is probably not worth the time.

Have a good solution for delegating signing-keys might also be highly significant, and possibly add even more complexities. One major advantage of PoA is simplicity. We should try to simplify and minimize complexities wherever possible...

Yes delegation is essential and limited functionality singing-keys are also essential. You want blockchain.info to be able to participate using its users' money. We've discussed before that bitcoin could really benefit from limited-spend keys. The inability to make low-risk spend keys is a security risk. Atm cards have withdrawal limits for a reason. You shouldn't have to expose your entire bank account to the internet in order to send $10. It is silly.

[iddo]

I haven't read carefully the last post yet (I will a bit later), but I would like to ask again regarding PoA:

Let's consider this simple PoA protocol:
*) stakeholder who won the follow-the-satoshi lottery is allowed to provide his signature txn only in the next 6 blocks to win his reward (the rule is that his signature txn is invalid from the 7th block onwards, so it wouldn't be included in the 7th block by miners who follow the protocol).
**) the recommended safe length to protect yourself from doubles-spending attacks is between 6 signed blocks and 12 unsigned blocks.
***) the weight of each signed block is for example 2x or 5x the weight of an unsigned block, and this weight goes into effect immediately.
****) there aren't any other special rules to determine the winning branch, simply the branch with highest difficulty (adjusted by PoA weights) wins.

This protocol doesn't attempt (yet) to help with an attacker who generates empty blocks to destroy the network.

I claim that w.r.t. double-spending attacks, this protocol is more secure than pure-PoW, assuming that the majority of stakeholders isn't malicious.

Suppose merchant A receives the coins payment of the buyer B at block n, and listens on the network for double-spending attempts until reaching block n+6 (or up to n+12 if all blocked were unsigned), and only then sends the merchandise to B. The double-spending attacker cannot prepare a secret fork of 6 blocks and then announce it to stakeholders to get their signatures, because their signatures will be invalid after 6 blocks. If the attacker makes his fork public from the start, then the merchant's client will detect the double-spending attempt. So waiting for 6 signed blocks is enough, and e.g. if 2nd block wasn't signed by the honest network and the attacker released his secret fork after 6 blocks then this 2nd block can still be signed by the lucky stakeholder in the 7th block and thereby give more weight to the attacker's branch, so waiting up to 12 blocks (depending on how many were signed) is safe.

Let's consider the attack vector raised by coblee where the attacker waits until he's the lucky winner of a block that he mined and lets the honest network extend this block without providing his signature txn, while preparing a secret fork in which he includes his signature txn. Note that the txn that he plans to double-spend doesn't need to be in the initial block that he mined, he can put this txn in the 2nd block of the honest network that extends his initial block. So he has an advantage of one signed block in his secret fork (i.e. the block that he mined initially), and the honest network won't be able to include the signature of that block if he releases his fork after at least 6 blocks. Still, if the reward for the stakeholders is big enough so that at least half of the blocks get signed on average, then the attacker's branch will have only one signed block in the first 6 blocks, and the honest branch will have about 3 signed blocks. So I don't think that this attack vector is a problem, unless less than 1/6 of all blocks get signed on average.

The double-spending-bribes service cannot operate with this protocol, this service had to keep the fork secret for 6 blocks before soliciting signatures from stakeholders, so that the merchant won't detect it, but now those signatures would be invalid.

The reward for stakeholders should probably be big (for example 10% of the block reward), because they must provide their signature in the next 6 blocks. This is also related to signing-key delegation, i.e. whether stakeholders can use encrypted wallets.

So when comparing with pure-PoW, the only disadvantage is that the merchant might have to wait for more than 6 blocks (but less than 12), depending on how many blocks were signed? The advantage is of course that PoW-only attacker will fail against the honest network.

Assuming the the incentives for stakeholders would work (maybe by adjusting their reward with the difficulty retarget window), do you think that this protocol is good, and we could try to extend it to handle attackers who generate empty blocks? Or am I missing possible attacks on this protocol?

[cunicula]

I haven't read carefully the last post yet (I will a bit later), but I would like to ask again regarding PoA:

Let's consider this simple PoA protocol:
*) stakeholder who won the follow-the-satoshi lottery is allowed to provide his signature txn only in the next 6 blocks to win his reward (the rule is that his signature txn is invalid from the 7th block onwards, so it wouldn't be included in the 7th block by miners who follow the protocol).
**) the recommended safe length to protect yourself from doubles-spending attacks is between 6 signed blocks and 12 unsigned blocks.
***) the weight of each signed block is for example 2x or 5x the weight of an unsigned block, and this weight goes into effect immediately.
****) there aren't any other special rules to determine the winning branch, simply the branch with highest difficulty (adjusted by PoA weights) wins.

Issues:
1) A modest Proof-of-work advantage (2-fold or 5-fold with 100% participation; less with partial participation) still allows you to double-spend or deny service. This is not adequate for a world with just pure fees and no block subsidy. If someone could perform a 51% attack, I can't see why they couldn't also perform a 76% attack. Get into the 99%+ range and I'll be satisfied.

Possible Resolutions:
a) The best way of preventing denial of service is to make the source block depend on the miner's personal proof of stake. You can use multiple block types if you want to preserve pure proof-of-work blocks.
b) Require all blocks to be signed before they can be added to. (i.e. you need a signature for a valid block and you have to get that before the process can move on) Just one signature per block would help a lot. Miners could no longer mine in secret without stake. Even with 10% of stake and just 1 signature, attackers would need 10 times as much hashing power in order to compete with the main chain.

2) There is no clear plan for rewarding signatories in the long-term. If you use simple txn fees to reward stakeholders, then txn fees become a bribery vector. Simply including a txn with large fees on an attack chain induces rational stakeholders to join the attack.

Possible Resolutions:
a) Use permanent inflation to reward stakeholders. [See for example PPCoin]
b) Use a long-run average of historical txn fees to reward stakeholders. Whenever a block is mined, give 10% of txn fees directly to the miner. Send the other 90% of txn fees to a fund that rewards signatories. Distribute 0.001% of this fund to stakeholders in each block. With this, system current miners could not influence signature payouts to any meaningful degree (i.e. including 100,000 times the regular fee in a block increases stakeholder rewards by just 1%). [This is conceptually similar to PPCoin; a txn tax rewards stakeholders; the miner has no influence over the tax; here, the txn tax does not operate through inflation] An added bonus is that this method incentivizes the transmission of txn data.

3) For atomistic stakeholders, the unique nash equilibirum is to sign every single fork you see.

Possible Resolutions:
a) Include a mechanism to penalize signatures on blocks with low consensus. There are at least two things you could do:
       i) Make signature rewards increase with the degree of stakeholder consensus. You can adapt this to a txn fee system with no inflation. Alternatively you can use inflation. Ask if you are curious.
       ii) use inflation to reward stake holders and make their holdings grow at a hyperexponential rate. You can ask about this if you are curious. I think both (i) and (ii) are much better ideas though.
b) Do not use a lottery at all and go with a protocol like ABAB coin as described above.

[iddo]

As far as trading coin-age for interest. It should be really simple. The public key you sign with has a balance and the coins associated with this key have not been spent or won the lottery for a known time period (call this age). Age is measured in years (units of 52560 blocks). Call age a, the balance b, and the interest rate r, 0<r<0.015. 500 blocks after you sign, the miner includes a generation txn which sends b*(exp(a*r)-1) to this public key.  

How would the miner include that generation txn? The stakeholder has to send this txn request to the miner, otherwise the miner wouldn't know about it? But the incentive of the miner is not to include that txn, because he then gets less reward?

Could you please explain what is the reasoning behind trading coin-age for interest? I mean, what are the particular benefits of using this reward scheme over other reward schemes.

The idea is that people begin in default behavior, signing one chain only. If you deviate from default behavior, but some strictly positive fraction of people remain in default mode, then you will get penalized for the deviation. Thus default behavior is a nash equilibrium. This differs from PoA where default behavior is not a nash equilibrium.

I'm attempting to convince you (see next post) that simple-PoA is a Nash equilibrium for the PoW miners, meaning that it's better for miners to generate blocks in the honest network than it is to generate a competing branch. I agree that it's better for stakeholders to sign all the branches that they see, but if the PoW attacker wouldn't generate his branch in the first place then we're good.

I wonder if adjusting for 10 minutes block time is possible with this scheme, because of the dependency on the currently active stakeholders. There might also be new kinds of attacks by stakeholders, for examples stakeholders who collude by withholding the 5th signature, then releasing it at the same time in order to split the chain and create chaos?

Yes, you can withhold the fifth signature, but then some other block will be found and built upon. You will need to add the fifth signature and then secretly find a new block. Secretly finding a new block is nearly impossible.

I'm still not so sure. Maybe some small fraction of the stakeholders could increase the number of splits, say by synchronizing to provide their 5th signature only at round minutes (if they see that they're the lottery winner of 5th signature at 11:00:05 PM then they'll broadcast their signature at 11:01:00 PM). BTW my concerns here would be the same if it was the simplified core idea with a single signature instead of 5-10 signatures.

I think that the core idea of requiring PoW+lottery_PoA_signature before the block becomes valid raises interesting issues.
As a miner, if you solved the block and you're waiting for the stakeholder to broadcast his signature (and so far he doesn't), do you sit idle, or do you attempt to re-solve the block while waiting? Since if you manage to re-solve then maybe the 2nd stakeholder will provide his signature, while the 1st stakeholder wouldn't.

BTW there are also interesting issues with protocols like your ABAB where the miner must use his privkey to generate the block. Specifically, you couldn't use mining pools, so maybe a variation of p2pool has to be an integral part of the protocol. This is actually a great feature rather than a drawback, because centralized mining pools are a security risk (can be DoS attacked, unlike p2pool, etc.) I don't remember whether I discussed it with you before, but I did raise this issue at #bitcoin-dev about one year ago (link).

From an economic perspective, I hope that objectives (1)+(2)+(3) can be achieved without a protocol that requires infinite monetary inflation. Maybe we could attempt to design two different protocols, one with infinite inflation, and one without, so that later the better protocol could be decided by also taking economic considerations into account. What do you think?

This is not really inflation at all. A small amount of new money is printed, but it is distributed proportionally evenly among people who already have money. Say productivity grows by 1% a year.
In this case, prices will remain close to constant in the long-run, but your $1.00 will slowly turn into $1.01 each year. [productivity growth shows up as an increase in your balance instead of falling prices]
With bitcoin, prices fall by 1% each year, and your $1.00 balance remains as $1.00. [productivity growth shows up as falling prices]
The two situations are almost equivalent.

The difference is that there is an implicit tax on txns. You are penalized via loss of interest if you move your coins. The penalty is very small. Think of buying a television for US$400.
You have a choice. Do I buy it now, or do I wait 6 months to earn interest and then buy it? At most, 6 months of waiting could decrease the price by US$6. In practice, however effects will be much smaller than this. You could hold your money in an online wallet. They would store 90% of their holdings to earn interest and handle liquidity needs with the remaining 10% (just like a normal bank, except with a 100% reserve).
The loss of interest would then be reduced to $0.60. I don't think you will delay your television purchase for 6 months to save 0.15% off the purchase price. The implict txn tax will be really really tiny.

I don't dispute (nor approve) any of that, I always use the phrase "monetary inflation" to be clear. Not sure how the 90%,10% online wallet example works, you don't really need to allocate 10% that sits idle because you can always transfer coins and forfeit some interest reward? But I guess that you would still want to tell your customers that their withdrawals cannot bypass the 10% limit unless they meet some requirements?

It sounds really difficult and taxing on the network, but I think that it could actually be much easier than it sounds. The miners don't actually need to transmit a large number of tentative blocks. They just need to search for blocks that match keys that have recently signed the blockchain. i.e. they search for historically active keys. They discard potentially valid blocks with keys that are rarely seen in signatures. They then transmit blocks that historically active keys can sign. These tentative blocks are likely to become valid. The final signatures in the sequence allow the blockchain to constantly update the record of historical activity. [These final signatures are increasingly random rather than miner selected, particularly sigs 6-10.] Thus, by referring to the blockchain, the miners always know approximately what type of sequence they are looking for.

This search might sound hard, but really it isn't. You are most likely searching for the public keys of Mt. Gox, Bitinstant, Bill Gates, blockchain.info, etc. A small number of people will hold a huge amount of stake. Searching for a small number of keys is not that difficult. Searching for the key to an average person's wallet is probably not worth the time.

At first glance this doesn't sound good at all to me. Why would we want to encourage wealth concentration by having the miners behave in the way that you describe? Don't you agree that having only a few stakeholders is a major security risk? I suppose that we agree that the network is more secure when the PoW hashpower is more distributed, so why wouldn't you agree that the same is true for distributed stake?

[iddo]

1) A modest Proof-of-work advantage (2-fold or 5-fold with 100% participation; less with partial participation) still allows you to double-spend or deny service. This is not adequate for a world with just pure fees and no block subsidy. If someone could perform a 51% attack, I can't see why they couldn't also perform a 76% attack. Get into the 99%+ range and I'll be satisfied.

I'm gonna use 3-fold in my example (see next), which means that pure-PoW attacker would need 75% of the total hashpower if all the blocks get signed (edit: 66% of the total hashpower assuming that on average half of the blocks get signed). That ain't 99%, but if we use a higher multiplier than 3x (say 100x) then the attacker would always need just one more block than half of the double-spending safety length (see next).

2) There is no clear plan for rewarding signatories in the long-term. If you use simple txn fees to reward stakeholders, then txn fees become a bribery vector. Simply including a txn with large fees on an attack chain induces rational stakeholders to join the attack.

I don't see how a large txn fees bribe is a problem with simple-PoA: if the attacker's branch is public then stakeholders would just grab the extra coins that he offers them and make his branch the winning branch (double-spending wouldn't occur, so the attacker loses his coins), and if the attacker's branch is secret then neither the stakeholders nor the attacker can benefit from the large txn fees bribe that he attempted to offer them, because when he reveals his secret branch after 6 blocks the stakeholders can no longer participate because their signatures would already be invalid.

b) Use a long-run average of historical txn fees to reward stakeholders. Whenever a block is mined, give 10% of txn fees directly to the miner. Send the other 90% of txn fees to a fund that rewards signatories. Distribute 0.001% of this fund to stakeholders in each block. With this, system current miners could not influence signature payouts to any meaningful degree (i.e. including 100,000 times the regular fee in a block increases stakeholder rewards by just 1%). [This is conceptually similar to PPCoin; a txn tax rewards stakeholders; the miner has no influence over the tax; here, the txn tax does not operate through inflation] An added bonus is that this method incentivizes the transmission of txn data.

Interesting idea, I'll keep that in mind.


I was looking for concrete attacks on simple-PoA, after thinking about it a bit more I'll describe now what seems to me to be the general framework of how an attack looks like, though I'll use specific parameters for simplicity:
Let's assume 3-fold PoA weight (meaning that a signed block is worth the same as 3 unsigned blocks), and let's assume that the attacker controls 20% of the total stake. This 20% is either the attacker himself, or malicious stakeholders that help the attacker, or rational stakeholders that were recruited by the attacker in secret and their actions must be hidden from the rest of the network.
Let's assume that half of the blocks get signed by the honest network, and those 20% of stakeholders who collude with the attacker still also participate in the honest network (edit: if they don't contribute to the honest network during the attack then on average 40% of the honest branch gets signed, so the merchant's client might wait longer for approval and it'd make the attack even more difficult).
For the attacker to succeed in double-spending via 6-block reorg, he repeatedly attempts to mine his secret branch from the current block. Assuming that the next 6 blocks of the honest network will have 3 signed blocks out of the 6, the attacker needs (at least) 4 consecutive signed block in order to win, so with 20% stake this happens with probability (1/5)^4, meaning that he has to wait 625 blocks (4.3 days, assuming 10min blocks) on average until this event occurs. Note that the attacker wastes some of his hashpower while waiting (whenever he starts extending his secret branch), and that he has to broadcast the double-spending txn to the honest network each time (I was wrong in post #75 about including his txn in the 2nd block of the honest network), so an example scenario would be that the attacker does many purchases of dollars with his BTC, and once every 625 purchases his double-spending could succeed. Therefore, such an attacker needs to generate 4 PoW blocks to compete with 6 PoW blocks of the honest network, i.e. he needs 40% of the total network hashpower. The merchant can decrease the attacker's probability of success by waiting for more than 3-out-of-6 signed blocks, e.g. 5-out-of-10 implies that the attacker needs 7 consecutive signed blocks, which means one double-spending attempt once every 542 days while having 7/17=41% of the total hashpower. If we look at the current state of Bitcoin, I doubt that a single entity could have 20% of all the bitcoins under its control (about 2 million BTC). So I like these odds.

I'm still very interested to hear about other concrete attacks, maybe there are better ways to attack simple-PoA ?

[cunicula]

I don't see how a large txn fees bribe is a problem with simple-PoA: if the attacker's branch is public then stakeholders would just grab the extra coins that he offers them and make his branch the winning branch (double-spending wouldn't occur, so the attacker loses his coins), and if the attacker's branch is secret then neither the stakeholders nor the attacker can benefit from the large txn fees bribe that he attempted to offer them, because when he reveals his secret branch after 6 blocks the stakeholders can no longer participate because their signatures would already be invalid.

Since txn fee bribes are feasible in bitcoin as well I posted a new topic on it here:  https://bitcointalk.org/index.php?topic=122291.msg1315784#msg1315784

The bribe would work the same way with PoA. i.e. you make a one block long secret fork (secretly loading your bribes in this fork), send a real txn and put the bribe elsewhere on the main chain, wait for the txn to go through, and then bribe people to extend the fork you started. The bribes are only valid if the attack chain becomes valid, otherwise they are rejected as double spends.

You need to be much more cautious about bribery when you use PoS. With PoW there are significant costs for dishonest miners in the event that the attack fails.
The attacker needs to pay compensation for that. With PoS, there are no costs for the dishonest miners if the attack fails. Thus you don't need to pay any compensation.
As I noted though you can build some costs in with a funky reward structure. This should help some.

To the degree that you incorporate PoS in any mechanism, bribing people becomes easier.  

The limiting feature on bribery though is that you need to personally make at least one secret block to get the bribery process started. Without the secret block, the bribe can get stolen (like you mention).
The signature sequence mechanism that I described makes secret mining extremely costly. Even mining just one secret block is infeasible without significant ownership (say 10% of all active stake minumum).
Ownership of 10% of stake removes attack incentives to begin with. So secret mining and associated double spends become solved problems.

[cunicula]

How would the miner include that generation txn? The stakeholder has to send this txn request to the miner, otherwise the miner wouldn't know about it? But the incentive of the miner is not to include that txn, because he then gets less reward?

The interest would be a block validity rule. The stake signature indicates the public key that is owed interest. The miner has to include generation sent to this address for the block to be valid. (i.e. the miner looks up 500 blocks back in the blockchain to see who is owed money). People checking block validity make sure this debt was paid, and reject the block if it was not paid.

Could you please explain what is the reasoning behind trading coin-age for interest? I mean, what are the particular benefits of using this reward scheme over other reward schemes.

If you have a fixed reward in a PoA style scheme (e.g. txn fees or block reward), then stakeholders should sign all chains to maximize their expected return. The coin-age scheme with fixed interest means that your expected reward does not increase when you sign additional chains. Signing additional chains might allow you to access the reward earlier, but it does not increase your expected reward. The coin-age scheme with variable interest causes your expected reward to decrease if you sign minority chains. Under this scheme, stakeholders (at least most of them) will strictly prefer to sign only one chain, the chain with the strongest consensus.

This issue of signing every chain you see only comes up when stake submission is not accompanied by work submission. It is not relevant to my ABAB style chain.

I'm attempting to convince you (see next post) that simple-PoA is a Nash equilibrium for the PoW miners, meaning that it's better for miners to generate blocks in the honest network than it is to generate a competing branch. I agree that it's better for stakeholders to sign all the branches that they see, but if the PoW attacker wouldn't generate his branch in the first place then we're good.

I understand what you are saying. The PoW guys will sign one chain only. I agree with that, but the problems don't end there. If the PoA guys are truly willing to sign everything, then the resulting scheme becomes less secure than pure PoW. The PoA guys can now influence chain selection through corrupt signature behavior. An attacker can send the PoA guys small bribes to influence their signing behavior (i.e. to deny signatures to the main chain). The attacker can then use his own work to attack the main chain. He requires much less work than before because the PoA guys are helping him.

I'm still not so sure. Maybe some small fraction of the stakeholders could increase the number of splits, say by synchronizing to provide their 5th signature only at round minutes (if they see that they're the lottery winner of 5th signature at 11:00:05 PM then they'll broadcast their signature at 11:01:00 PM). BTW my concerns here would be the same if it was the simplified core idea with a single signature instead of 5-10 signatures.

Yes, the 5th signatory can withhold his signature, then split off the chain, and building a one block fork. The fork cannot be extended past one block, however. This is only dangerous if you accept one confirmation txns. There is no danger at all if you require two confirmations. I didn't promise that I could make one confirm txns secure.

I think that the core idea of requiring PoW+lottery_PoA_signature before the block becomes valid raises interesting issues.
As a miner, if you solved the block and you're waiting for the stakeholder to broadcast his signature (and so far he doesn't), do you sit idle, or do you attempt to re-solve the block while waiting? Since if you manage to re-solve then maybe the 2nd stakeholder will provide his signature, while the 1st stakeholder wouldn't.

You re-solve the block while waiting. Recall that blocks with less than 5 sigs can never be recorded. You can't predict which blocks will succeed ahead of time. Meeting the difficulty target is just the first hurdle. Even with 50% participation, only about 1 in 30 blocks that meet the difficulty target will actually get 5 signatures. Many of these blocks will be obvious failures even before you transmit them (the signatories are obviously not participating based on the blockchain record). You would want to discard these without even bothering to transmit them. Other blocks will have a good chance. You want to transmit all blocks that have a good chance.

In the event of a contentious fork, you may also choose not to sign anything at all to avoid risk of loss, alternatively you may pick a chain which you strongly expect to win. This is good. It means that the choice between two public chains of equal length will fall upon the PoW miner. He will only be able to extend one chain. There won't be any ambiguity any more. Perhaps ask more questions about this because it is somewhat complex and may still be unclear.

BTW there are also interesting issues with protocols like your ABAB where the miner must use his privkey to generate the block. Specifically, you couldn't use mining pools, so maybe a variation of p2pool has to be an integral part of the protocol. This is actually a great feature rather than a drawback, because centralized mining pools are a security risk (can be DoS attacked, unlike p2pool, etc.) I don't remember whether I discussed it with you before, but I did raise this issue at #bitcoin-dev about one year ago (link).

Yes, I think it should be a limited spend privkey to allow for a more acceptable risk level. Yes, you can't use mining pools. Besides this there is no motivation to use a pool, rewards have low variance even though you don't use a pool. You just mine occasionally once you have accumulated enough coin-age to mine successfully, and then shut down once you succeed. If you have a very large stake, you can mine continuously. P2Pool could be used to allocate hashing power intelligently across stakes and divide the rewards among all participants.

I don't dispute (nor approve) any of that, I always use the phrase "monetary inflation" to be clear. Not sure how the 90%,10% online wallet example works, you don't really need to allocate 10% that sits idle because you can always transfer coins and forfeit some interest reward? But I guess that you would still want to tell your customers that their withdrawals cannot bypass the 10% limit unless they meet some requirements?

Yes, something like that. Recall that PPCoin uses coin-age based interest to reward proof of stake. There is talk of doublec's exchange collecting interest for people with balances there and distributing it to users. I don't think the details of how this will work are that important at this point.

At first glance this doesn't sound good at all to me. Why would we want to encourage wealth concentration by having the miners behave in the way that you describe? Don't you agree that having only a few stakeholders is a major security risk? I suppose that we agree that the network is more secure when the PoW hashpower is more distributed, so why wouldn't you agree that the same is true for distributed stake?

It does not encourage wealth concentration except to a negligible degree. For me wealth concentration is a fairness issue, not a security issue. I see wealth concentration as improving security.

I don't think it will be 'a few major stakeholders'. It will be more like there are 10 huge stakeholders holding (2.5% stake each), 100 large stakeholders holding (0.25% stake each), 1000 medium stakeholders (0.025% stake each), and 10,000 small stakeholders (0.0025% stake each). Wealth distributions always look like this (pareto). I'm sure bitcoin's does to. I don't see this as a security risk. In fact, I think security gets much stronger as wealth gets more concentrated. The huge stakeholders have major holdings and will be completely fucked if the network gets exploited. They will work hard to protect the network. The 10,000 small  don't have any incentive to protect the network proactively. It will be to much trouble for them.

[cunicula]

I was looking for concrete attacks on simple-PoA, after thinking about it a bit more I'll describe now what seems to me to be the general framework of how an attack looks like, though I'll use specific parameters for simplicity:
Let's assume 3-fold PoA weight (meaning that a signed block is worth the same as 3 unsigned blocks), and let's assume that the attacker controls 20% of the total stake. This 20% is either the attacker himself, or malicious stakeholders that help the attacker, or rational stakeholders that were recruited by the attacker in secret and their actions must be hidden from the rest of the network.
Let's assume that half of the blocks get signed by the honest network, and those 20% of stakeholders who collude with the attacker still also participate in the honest network (edit: if they don't contribute to the honest network during the attack then on average 40% of the honest branch gets signed, so the merchant's client might wait longer for approval and it'd make the attack even more difficult).
For the attacker to succeed in double-spending via 6-block reorg, he repeatedly attempts to mine his secret branch from the current block. Assuming that the next 6 blocks of the honest network will have 3 signed blocks out of the 6, the attacker needs (at least) 4 consecutive signed block in order to win, so with 20% stake this happens with probability (1/5)^4, meaning that he has to wait 625 blocks (4.3 days, assuming 10min blocks) on average until this event occurs. Note that the attacker wastes some of his hashpower while waiting (whenever he starts extending his secret branch), and that he has to broadcast the double-spending txn to the honest network each time (I was wrong in post #75 about including his txn in the 2nd block of the honest network), so an example scenario would be that the attacker does many purchases of dollars with his BTC, and once every 625 purchases his double-spending could succeed. Therefore, such an attacker needs to generate 4 PoW blocks to compete with 6 PoW blocks of the honest network, i.e. he needs 40% of the total network hashpower. The merchant decrease the attacker's probability of success by waiting for more than 3-out-of-6 signed blocks, e.g. 5-out-of-10 implies that the attacker needs 7 consecutive blocks, which means one double-spending attempt once every 542 days while having 7/17=41% of the total hashpower. If we look at the current state of Bitcoin, I doubt that a single entity could have 20% of all the bitcoins under its control (about 2 million BTC). So I like these odds.

I'm still very interested to hear about other concrete attacks, maybe there are better ways to attack simple-PoA ?

I think you need to prepare for an environment where the total network has only 30 Gigahashes and contains $100 million USD. That is what the network will look like without block reward. The numbers might not be quite good enough for this situation.

I wouldn't worry about double spends coming from someone with USD$20 million of bitcoin. He will be scrambling to keep the network secure and his fortune safe. Only an idiot would try to double spend from this position.

Worry about someone who owns 300 Gigahashes double-spending. 300 gigahashes costs less than $0.5 million USD to acquire. This is far less than the $20 million necessary for stake.

Moreover, the GPUs might retain significant resale value in the event of a devastating successful attack. The bitcoin would not.

[iddo]

How would the miner include that generation txn? The stakeholder has to send this txn request to the miner, otherwise the miner wouldn't know about it? But the incentive of the miner is not to include that txn, because he then gets less reward?

The interest would be a block validity rule. The stake signature indicates the public key that is owed interest. The miner has to include generation sent to this address for the block to be valid. (i.e. the miner looks up 500 blocks back in the blockchain to see who is owed money). People checking block validity make sure this debt was paid, and reject the block if it was not paid.

This sounds like a computationally infeasible task, though maybe I misunderstand what the task is. Could you describe the algorithm that the miners use to decide which interest-payment txns should be included in the blocks?

I was looking for concrete attacks on simple-PoA, after thinking about it a bit more I'll describe now what seems to me to be the general framework of how an attack looks like, though I'll use specific parameters for simplicity:
Let's assume 3-fold PoA weight (meaning that a signed block is worth the same as 3 unsigned blocks), and let's assume that the attacker controls 20% of the total stake. This 20% is either the attacker himself, or malicious stakeholders that help the attacker, or rational stakeholders that were recruited by the attacker in secret and their actions must be hidden from the rest of the network.
Let's assume that half of the blocks get signed by the honest network, and those 20% of stakeholders who collude with the attacker still also participate in the honest network (edit: if they don't contribute to the honest network during the attack then on average 40% of the honest branch gets signed, so the merchant's client might wait longer for approval and it'd make the attack even more difficult).
For the attacker to succeed in double-spending via 6-block reorg, he repeatedly attempts to mine his secret branch from the current block. Assuming that the next 6 blocks of the honest network will have 3 signed blocks out of the 6, the attacker needs (at least) 4 consecutive signed block in order to win, so with 20% stake this happens with probability (1/5)^4, meaning that he has to wait 625 blocks (4.3 days, assuming 10min blocks) on average until this event occurs. Note that the attacker wastes some of his hashpower while waiting (whenever he starts extending his secret branch), and that he has to broadcast the double-spending txn to the honest network each time (I was wrong in post #75 about including his txn in the 2nd block of the honest network), so an example scenario would be that the attacker does many purchases of dollars with his BTC, and once every 625 purchases his double-spending could succeed. Therefore, such an attacker needs to generate 4 PoW blocks to compete with 6 PoW blocks of the honest network, i.e. he needs 40% of the total network hashpower. The merchant decrease the attacker's probability of success by waiting for more than 3-out-of-6 signed blocks, e.g. 5-out-of-10 implies that the attacker needs 7 consecutive blocks, which means one double-spending attempt once every 542 days while having 7/17=41% of the total hashpower. If we look at the current state of Bitcoin, I doubt that a single entity could have 20% of all the bitcoins under its control (about 2 million BTC). So I like these odds.

I'm still very interested to hear about other concrete attacks, maybe there are better ways to attack simple-PoA ?

I think you need to prepare for an environment where the total network has only 30 Gigahashes and contains $100 million USD. That is what the network will look like without block reward. The numbers might not be quite good enough for this situation.

I wouldn't worry about double spends coming from someone with USD$20 million of bitcoin. He will be scrambling to keep the network secure and his fortune safe. Only an idiot would try to double spend from this position.

Worry about someone who owns 300 Gigahashes double-spending. 300 gigahashes costs less than $0.5 million USD to acquire. This is far less than the $20 million necessary for stake.

Moreover, the GPUs might retain significant resale value in the event of a devastating successful attack. The bitcoin would not.

This may all be true, but it's an argument why PoA isn't good enough, rather than an argument why PoA is worse than pure-PoW Bitcoin. The PoW attacker will need (say) 66% of the total hashpower with PoA, instead of 50% with pure-PoW. I agree that it'd be much better if PoA could be improved upon, for example combining PoA with ABAB seems to be a straightforward way to get protection from both double-spending attackers and denial-of-service attackers, I've been thinking about these kinds of ideas. However, I'm still trying to figure out whether there are certain kinds of attacks where PoA is more vulnerable than pure-PoW.

I'm attempting to convince you (see next post) that simple-PoA is a Nash equilibrium for the PoW miners, meaning that it's better for miners to generate blocks in the honest network than it is to generate a competing branch. I agree that it's better for stakeholders to sign all the branches that they see, but if the PoW attacker wouldn't generate his branch in the first place then we're good.

I understand what you are saying. The PoW guys will sign one chain only. I agree with that, but the problems don't end there. If the PoA guys are truly willing to sign everything, then the resulting scheme becomes less secure than pure PoW. The PoA guys can now influence chain selection through corrupt signature behavior. An attacker can send the PoA guys small bribes to influence their signing behavior (i.e. to deny signatures to the main chain). The attacker can then use his own work to attack the main chain. He requires much less work than before because the PoA guys are helping him.

With simple-PoA (post #75), the PoW miners don't sign any blocks. Basically what I'm claiming is that if the competing branches are public then that's fine (everyone should contribute his PoW effort and/or his PoA signature to whichever branch he wishes, and may the best branch win), and if one competing branch is secret then it's useless for double-spending attacks because it couldn't get anywhere near enough PoA signatures while it was secret, and by the time it goes public the needed PoA signatures would be invalid in this branch. Therefore, PoA is gives better security against double-spending by an attacker with large hashpower, because the nature of double-spending attacks is that they need to stay secret at the first stage, and they couldn't get enough PoA signatures at the first stage.

I'd still like to solicit concrete attacks on simple-PoA (attacks that couldn't be carried out just as easily with pure-PoW, I didn't look into your "double double spend" thread closely enough yet).

[cunicula]

This sounds like a computationally infeasible task, though maybe I misunderstand what the task is. Could you describe the algorithm that the miners use to decide which interest-payment txns should be included in the blocks?

No it is not a computational task at all. It operates just like regular old block reward.

The miner looks up in the block chain who signed the block 500 blocks past, block t-500. There is a record of public keys there. At the time of signing, each public key had a certain amount of coins. This indicates the principal owned by each signatory, P_i, indexing the 5-10 signatories by i. The coins also had a certain amount of age (i.e. blocks since they had last been spent or received an interest payment). This indicates the # of blocks for which the coins are owed interest, T_i. T_i is in units of 52560 blocks (i.e. years). Finally, blocks t-491, t-492, ..., t-500 have a total number of signatures on them. The total # of signatures (between 50 and 100) determines the interest rate to be used, r=0.015*(S/100)-0.0075. Now the amount due to each signatory is P_i*(exp(r*T_i)-1); round down to the nearest satoshi. The block simply prints money and sends it to the signatories keys. If it fails to do this, then it is not a valid block and all the clients, miners, will reject it. You could still seek out signatories for it, but no one can build on it, so it drops out of the chain.

With simple-PoA (post #75), the PoW miners don't sign any blocks. Basically what I'm claiming is that if the competing branches are public then that's fine (everyone should contribute his PoW effort and/or his PoA signature to whichever branch he wishes, and may the best branch win),

Here is how it works. Assume people sign everything they can by default. I have 50% of hashing power.

I spend at time t in the main branch and I want to revoke this spend. I wait for 6 confirmations in the main branch. The guy I am ripping off delivers the goods. Meanwhile I build a 6 block long secret branch from t-1, eg. t* t+1* t+2* t+3* t+4* t+5* t+6*. The block at t* contains my double spend.

Now I announce my secret chain which has 6 unsigned blocks. According to your rules, every block on my secret chain is currently eligible for a signature. By assumption, the regular PoA guys immediately give me their signatures. Once that happens I can continue extending my attack chain.

There is also the main chain. I should be even with it because I have 50% of hashing power. By assumption, the main chain also has full signatures up to this point.

Now normally, I would have a 50-50 chance of winning vs. the PoW miners. I still do. However, I can tip this 50% into my favor. I announce publicly that I will send bribes to whoever refuses to sign the main chain. I am assuming the identity of the public keys who should sign the main chain is public knowledge (i.e. the lottery winners are public knowledge even before they claim their prize). In the attack fork, I send the keys that should be signing the main chain small amounts of money. The owners of these keys now have a good reason to withhold their signatures from the main chain.

Of course, I could bribe people via PoW too, but that is much less efficent. To execute a PoW bribe, I include a big txn fee in blocks within the attack chain. In expectation, this bribe is divided evenly among all possible miners. By comparison, the PoA bribe is targeted at exactly the key I need to bribe. Thus, the PoW bribe will need to be many times larger than the PoA bribe. The cheaper bribe makes double-spends easier. More generally I can use these targeted bribes to win with just a minority of hashing power.

You can avoid this by requiring the signatures to come before the block enters the chain. In this case, you won't know who to bribe until it is too late to bribe them.



 

[iddo]

I spend at time t in the main branch and I want to revoke this spend. I wait for 6 confirmations in the main branch. The guy I am ripping off delivers the goods. Meanwhile I build a 6 block long secret branch from t-1, eg. t* t+1* t+2* t+3* t+4* t+5* t+6*. The block at t* contains my double spend.

Now I announce my secret chain which has 6 unsigned blocks. According to your rules, every block on my secret chain is currently eligible for a signature.

No, according to simple-PoA rules, your block t* isn't eligible because the PoA for it cannot be put inside block t+7*, only your blocks t+1* t+2* t+3* t+4* t+5* t+6* are eligible. Therefore, if the merchant saw your txn at block t was signed and then saw that the next 6 blocks t+1 t+2 t+3 t+4 t+5 t+6 were all signed, he would then send you the merchandise, and now you make your secret branch public, but you can get signatures for only 6 out of the first 7 blocks that you generated, while the honest network has 7-out-of-7 signed block there. Assuming 3-fold PoA weight, it means that the honest network is effectively ahead of by 2 blocks (your t* is has weight=1, the honest t has weight=3).
If the merchant didn't see 6 consecutive signed blocks, then he waits the safety length of up to 12 blocks so that half of them are signed (assuming the incentives for stakeholders are in place so that at least half the blocks get signed on average). When you release your secret branch after 12 blocks, only the last 6 blocks in your branch are eligible for PoA signature, so the honest branch of 12 blocks where half are signed wins again.
Edit: a better way to describe it without getting into indexing troubles is simply to say that the merchant waits for 7 signed blocks (starting from the block where the relevant txn resides), so when the attacker releases his secret branch (of whichever length) only the last 6 blocks of it would be eligible for PoA signature, so the honest chain wins, unless the attacker has huge hashpower and he generated significantly more (unsigned) blocks than the honest network. And the only other thing that's left to say is that waiting for 7 signed blocks would take less than 14 block on average.

[cunicula]

No, according to simple-PoA rules, your block t* isn't eligible because the PoA for it cannot be put inside block t+7*, only your blocks t+1* t+2* t+3* t+4* t+5* t+6* are eligible. Therefore, if the merchant saw your txn at block t was signed and then saw that the next 6 blocks t+1 t+2 t+3 t+4 t+5 t+6 were all signed, he would then send you the merchandise, and now you make your secret branch public, but you can get signatures for only 6 out of the first 7 blocks that you generated, while the honest network has 7-out-of-7 signed block there. Assuming 3-fold PoA weight, it means that the honest network is effectively ahead of by 2 blocks (your t* is has weight=1, the honest t has weight=3).
If the merchant didn't see 6 consecutive signed blocks, then he waits the safety length of up to 12 blocks so that half of them are signed (assuming the incentives for stakeholders are in place so that at least half the blocks get signed on average). When you release your secret branch after 12 blocks, only the last 6 blocks in your branch are eligible for PoA signature, so the honest branch of 12 blocks where half are signed wins again.
Edit: a better way to describe it without getting into indexing troubles is simply to say that the merchant waits for 7 signed blocks (starting from the block where the relevant txn resides), so when the attacker releases his secret branch (of whichever length) only the last 6 blocks of it would be eligible for PoA signature, so the honest chain wins, unless the attacker has huge hashpower and he generated significantly more (unsigned) blocks than the honest network. And the only other thing that's left to say is that waiting for 7 signed blocks would take less than 14 block on average.

Sorry about the indexing problem.

It doesn't matter which branch wins after 6 or 7 or 12 confirms. It matters which branch wins in the end. Simple PoA is delaying resolution of voting into the future. This opens up a time window when we know the exact identity of the signatories and can bribe these individuals to vote for one branch or another. This means the attacker can win easily even if he is behind when the secret branch is announced.

If you require PoA signature(s) to be submitted in conjunction with each mined block, then you eliminate the time window. This solves the bribery problem. You won't know the identity of the person you need to bribe until it is too late to bribe them.

[cunicula]

A very simple, radically different, and secure PoS algorithm is to appoint an elected committee that controls all txns.

Say there are 9 public keys that belong to committee members. These can start out as some founding fathers of the coin.
Any valid txn block must be signed by 5 out of committee 9 keys. This solves the consensus problem.

The committee could be corrupt. Thus they need to be voted in and out of office.

Any coin holder can destroy 100 coins in order to mine a voting block, i.e. he sends them to a destruction address. The voting block does not include txns, just votes.
The coin holder proposes the removal of one committee member (public key) and the addition of another committee member (public key). Normally, I think you would nominate yourself.

He then draws and announces a random number (he can control the random number seed, it won't really matter). The random number is then hashed 10,000 times to draw a random electorate.
The electorate is drawn randomly from satoshis that have moved within the last year (thus avoiding the problem of dead voters). Major stakeholders would get to vote more than once.

The voters then either vote yes, no, or fail to vote. People who fail to vote are assumed to vote no.
If a block eventually gets 5,001 yes votes, then it enters the blockchain and a committee member is replaced. His signing key no longer affects block validity.

The voting blocks are valid even if they are not signed by any committee members. Voting blocks only enter the block chain if they pass.

There is no single point of failure here. If a committee member gets compromised or fails to perform his duties, he gets replaced.
The committee can also perform useful functions such as levying txn fees to fund development work or any other public good.
If someone don't like this they can vote the bastards out.

[iddo]

If you require PoA signature(s) to be submitted in conjunction with each mined block, then you eliminate the time window. This solves the bribery problem. You won't know the identity of the person you need to bribe until it is too late to bribe them.

Not so clear even for PoA submitted in conjunction with each mined block: the miners have to broadcast the blocks that they solved so that the stakeholders would attach their signature to those blocks, therefore the attack can listen and bribe these stakeholders too, no? If the attacker puts the bribe in his branch only after the stakeholder already forfeited his opportunity in the honest chain (to make sure that stakeholders don't cheat on him), then stakeholders have to trust that the attacker will deliver the bribe, both here and with PoA, so I don't see much of a difference. If the attacker puts the bribe in his branch immediately (so the stakeholders can cheat on him), then I also don't see much of a difference here versus PoA.

It doesn't matter which branch wins after 6 or 7 or 12 confirms. It matters which branch wins in the end. Simple PoA is delaying resolution of voting into the future. This opens up a time window when we know the exact identity of the signatories and can bribe these individuals to vote for one branch or another. This means the attacker can win easily even if he is behind when the secret branch is announced.

So basically we have reduced the problem from the scenario where there was a secret branch being generated, to the more straightforward scenario where the attacker simply has a shorter branch than the honest branch, and he's trying to use bribes in order to get his branch to win. This public branch of the attacker can even be of length 0 (if he's trying to bribe miners), or length 1 (if he's trying to bribe stakeholders). The first question that springs to mind: do you claim that PoA is less secure than Bitcoin because of this scenario? I'm curious to know what's your answer to this question. It seems to me that the answer is "no", with pure-PoW bitcoin the attacker can simply put high txn-fees in his branch, to encourage the miners to switch to him. The earlier advantage of pure-PoW over PoA that we discussed doesn't apply here, namely the advantage where PoW miners would lose if the attack fails, while PoA stakeholders wouldn't lose because they signed both branches (here the stakeholder who colludes with the attacker would lose the follow-the-satoshi lottery reward that he would have received in the honest chain, if the attacker fails).

Anyway, either with pure-PoW or with PoA, I'm not so sure that we should consider this public bribes scenario to be an "attack" that demonstrates a weakness of the protocol. Wouldn't you agree that this is simply a free-market issue, meaning that if the txn-fees on the honest chain are large enough then the miners or stakeholders (recall that in PoA the lucky stakeholder gets e.g. 10% of the total txn-fees) will prefer the honest chain over the attacker's shorter chain, and if the txn-fees are too low then double-spending attacks could be carried out because it might be rational for miners/stakeholders to help the attack? I'm not even sure if we should call this "double-spending", maybe we can use "public-double-spending" to differentiate, and I'm also not so sure if the entity who tries to carry out public-double-spending should be called an "attacker", it seems to me that all the participants in this scenario are acting legitimately rather than fraudulently (it's arguable, even for regular double-spending). But anyway this is just semantics, we agree that we should assume that the (majority of the) participants are acting rationally, and that's all that matters.

BTW from the point of view of the atomistic miner/stakeholder, it's not so clear why it's rational to help the attacker, given that the honest chain is longer and therefore if he's the only one who helps the attack then he would lose.

If you insist that this public bribes scenario is likely to be a problem, then which protocol to you propose to overcome this (perceived) problem? I'm not sure whether you'll manage to convince me that the likelihood of this problem is high, but if there's a good protocol that defeats this kind of attackers who offer public bribes then it'd be worthwhile to consider.

In any case, the main issue that concerns me is still whether some aspect of simple-PoA is weaker than pure-PoW, concrete attacks please? If it becomes more clear that simple-PoA is sound, then I'll move on to consider what's the best way to extend simple-PoA to handle attackers who generate empty blocks. But I'm happy to also discuss other protocols at the same time.

[cunicula]

Simple Attack where PoA is worse then PoW (no bribery):

All chains are signed by default if stakeholder participates. A fraction p of stakeholders participate. Attacker owns positive stake share, 0<s<1  and 0<p+s<1.  Attacker has workshare 0<w<1 of aggregate hash rate and the extra weight on signed blocks T. Attacker uses his stake to swing things in his favor.  Attacker wins if (1+pT+sT) w > (1+pT)(1-w) or if w/(1-w) > (1+pT)/(1+pT+sT). If T=0 (i.e. pure PoW) then the right hand side is equal to 1. If T>0, then the right hand side is less than 1, indicating that the attack becomes easier. In practice, however, the difference is really small unless p is small and s is large. Just provide incentives to keep p high and you should be fine. I'm much more worried about bribery than this.

Stuff you can do about bribery (in order of perceptive importance):
1) The reward system should discourage people from signing multiple chains (i.e. the coin-age scheme and/or ABAB scheme). Bribes would still work, but you could never get away with bribing a very small minority. You would need to bribe the majority. This is potentially difficult (I don't really think everyone is going to accept a bribe).

2) Remember that the feasibility of bribery depended on the attacker mining a one-block long secret fork. Without the secret fork, all the bribes can be stolen and then ignored. A simple defense is to make secret blocks computationally infeasible.

Consider the scheme with 5 sequential signatures. If the attacker has 1% of stake, he needs to mine 10 billion blocks just to construct a one-block long secret fork. It is reasonable to assume that the reward from mining 100,000 blocks on the main chain exceeds the reward from theft (I can't really say 10 billion because the attacker dies first). If you just do 1 signature, then the attacker with 1% stake needs to mine 100 blocks to get the one-block long secret fork. That still would help to discourage him, but I think you need at least 2 signatures -> 10,000 blocks for this to become really effective.

[You could put double-spends in a public fork and then issue bribes to extend the public fork. Thus, it makes sense to prevent double-spends in public forks. I think you can do this by requiring the miner to announce his tentative block to any signatory who requests it. The peers can just pass around the block header and the miner's IP address. The signatories can check if they are designated signers based on the block header. If they are, they can request full txn information from the miner's IP address. Once they have verified the txns are valid, they can sign the txn information and the block header, and submit this back to the miner. The miner can then send the updated data to the next signatory. After the fifth signature, the miner and the fifth signatory can announce the full block on the P2P network.]

[cunicula]

In any case, the main issue that concerns me is still whether some aspect of simple-PoA is weaker than pure-PoW, concrete attacks please? If it becomes more clear that simple-PoA is sound, then I'll move on to consider what's the best way to extend simple-PoA to handle attackers who generate empty blocks. But I'm happy to also discuss other protocols at the same time.

If you want to suggest the ABAB system with PoA added on top, that is fine with me. If you want to do just PoA alone, then I don't understand. PoA is not very strong against someone with a lot of work, i.e. it is not strong without substantial block reward.

[iddo]

Simple Attack where PoA is worse then PoW (no bribery):

All chains are signed by default if stakeholder participates. A fraction p of stakeholders participate. Attacker owns positive stake share, 0<s<1  and 0<p+s<1.  Attacker has workshare 0<w<1 of aggregate hash rate and the extra weight on signed blocks T. Attacker uses his stake to swing things in his favor.  Attacker wins if (1+pT+sT) w > (1+pT)(1-w)

But what is the nature of the attack here? If the attacker is mining in secret then the LHS is (1+sT)w instead of (1+pT+sT)w, and if the attacker is mining in public then he's simply helping to generate the honest branch.

[iddo]

This sounds like a computationally infeasible task, though maybe I misunderstand what the task is. Could you describe the algorithm that the miners use to decide which interest-payment txns should be included in the blocks?

No it is not a computational task at all. It operates just like regular old block reward.

The miner looks up in the block chain who signed the block 500 blocks past, block t-500. There is a record of public keys there. At the time of signing, each public key had a certain amount of coins. This indicates the principal owned by each signatory, P_i, indexing the 5-10 signatories by i. The coins also had a certain amount of age (i.e. blocks since they had last been spent or received an interest payment). This indicates the # of blocks for which the coins are owed interest, T_i. T_i is in units of 52560 blocks (i.e. years). Finally, blocks t-491, t-492, ..., t-500 have a total number of signatures on them. The total # of signatures (between 50 and 100) determines the interest rate to be used, r=0.015*(S/100)-0.0075. Now the amount due to each signatory is P_i*(exp(r*T_i)-1); round down to the nearest satoshi. The block simply prints money and sends it to the signatories keys. If it fails to do this, then it is not a valid block and all the clients, miners, will reject it. You could still seek out signatories for it, but no one can build on it, so it drops out of the chain.

Ahh, sorry, I was under the impression that all stakeholders are entitled to receive interest-payments, not just stakeholders who sign blocks. I've look at your previous posts and indeed when you were consistent when describing the interest-payment system, so I was just confused. I think that the post that got me confused is this:

if I understand correctly the purpose here is (supposedly) that stakeholders wouldn't want to sign the attacker's branch because we expect that the attacker's branch will get only 5 signatures or so, while we expect that the branch of the honest network will get 10 signatures, and stakeholders receive larger rewards if there are more signatures. But isn't there a problem with your suggestion because a particular stakeholder who got chosen in the attacker's branch doesn't also get chosen in the honest branch (except for with negligible probability), so it would be rational for this particular stakeholder to sign that attacker's branch in order to have a chance to get his individual reward (in the honest branch he wasn't chosen and wouldn't get any reward). Maybe the way to fix this issue is that the individual stakeholders never get any reward for the signature that they provide, and instead just have the rule that if more signatures are provided (closer to 10 instead of 5) then all the stakeholders are rewarded collectively, via lower rate of inflation or some other kind of reward?

You are not getting a direct reward from signing. You can claim your interest in any case, just at a later date.

Could you explain what you meant here? It seems that this interest-payments system is giving a direct reward to the stakeholder who signed, it's just that the reward is delayed by 500 blocks instead of being given immediately. How could you claim your interest if you haven't won the follow-the-satoshi lottery?

Edit: looking at your other comment:

Winning the lottery frequently does not directly affect the amount of coins you earn. The lottery win allows you to withdraw early without facing an early withdrawal penalty (foregone interest). Winning frequently increases liquidity of your savings, but does not give you a bigger monetary reward. It is a very very small advantage.

I think that maybe you meant that you can move some of your old coins and therefore still continue to earn interest on the coins that you haven't moved, but still to actually receive the interest-payment you have to win the lottery?

[cunicula]

Simple Attack where PoA is worse then PoW (no bribery):

All chains are signed by default if stakeholder participates. A fraction p of stakeholders participate. Attacker owns positive stake share, 0<s<1  and 0<p+s<1.  Attacker has workshare 0<w<1 of aggregate hash rate and the extra weight on signed blocks T. Attacker uses his stake to swing things in his favor.  Attacker wins if (1+pT+sT) w > (1+pT)(1-w)

But what is the nature of the attack here? If the attacker is mining in secret then the LHS is (1+sT)w instead of (1+pT+sT)w, and if the attacker is mining in public then he's simply helping to generate the honest branch.

I'm assuming that he was mining in secret, but then he revealed his secret chain to the world. Due to promiscuous signing (if I can call it that), the secret chain can catch up with less than 50% work.

[cunicula]

Could you explain what you meant here? It seems that this interest-payments system is giving a direct reward to the stakeholder who signed, it's just that the reward is delayed by 500 blocks instead of being given immediately. How could you claim your interest if you haven't won the follow-the-satoshi lottery?

You can't claim interest until you win the lottery. But you get to claim more interest if win the lottery later. The purpose of this is to provide an incentive to sign only the most plausible winning chain.

You can think of it like this. 1) You always have some potential interest reward in the chain. 2) You are trying to claim this interest reward by signing. 3) When you sign it is a speculative bet on which chain other people will sign. 4) If you bet on a chain that is unlikely to win, but this chain wins anyway, then you only get a portion of your interest reward and forfeit the rest. 5) If you wait to sign until later when your number comes up in a chain that is likely to win, then you get to receive your full interest reward + any additional interest you have accumulated in the interim.


Perhaps an extended example will help:

Suppose I have principal A and I earn a fraction f(F) of A per block in interest. The fraction f is an increasing functoin of the # of signatures, F, in the current and subsequent 9 blocks. I start out with 99 blocks in accumulated interest and the next block will give me 100 block of accumulated interest.

Now the chain forks into two valid blocks at history H as shown below. I've indicated places where I could sign are marked with "*", and other people's signatures with "b"

H-b-b-b-b-*

H-b-b-b-b-b-b-b

Suppose that 90% of people obey the rule and do not sign a block that is behind. Should I also obey this rule?

Obey Case:

Suppose I obey the rule just like the good 90% of stakeholders. Then the top sequence cannot be extended and will orphan.

The bottom sequence will be extended. Say that I win the lottery 300 blocks later.

H-b-b-b-b-b-b-b-(300 blocks)-b-b-b-b-*1

By now I have accumulated 400 blocks of interest. This is the only chain and I sign it. If I do so, then I earn 400AE[f_*1] in interest where E[f_*1] is the expected value of f_*1 when I sign at *1.

Disobey Case:

Suppose that I sign the top fork and this fork wins (if it fails to win, then the outcome is the same as before). When this occurs the top fork will win with low signatures.
Remember that 90% of stakeholders would refuse to sign the top fork as long as it is behind. Until it catches up it will have the bare minimum of signatures. The only plausible catchup process
is a lucky mining draw as shown below. (It is not clear why a miner would extend the top fork instead of working on the bottom one, but suppose they he does so out of ignorance)

H-b-b-b-b-*2-H-b-b-b-b-b

H-b-b-b-b-b-b-b

Now the top fork is ahead and everyone will sign it exclusively. I will get a reward of 100AE[f_*2] where E[f_*2] is the expected value of f_*2 when I sign at *2. Note that the block I signed has the minimum number of signatures, so E[f_2*]<E[f_1*]

Now extend this another 299 blocks and suppose I win the lottery again at *3. (I might win at another time, but this case is the easiest to explain)

H-b-b-b-b-*2-H-b-b-b-b-b-(299 blocks)-b-b-b-b-*3

This is the only chain and I sign it. If I do so, then I earn 300AE[f_*3] in interest where E[f_*3] is the expected value of f_*3 when I sign at *3. This case is identical to the obey case, so we can assume that E[f_*3]=E[f_1*].

What is my total payoff if I disobey? 100AE[f_2*]+300AE[f_*3]

Since [f_2*]<[f_3*]=[f_1*], the payoff I get if I disobey is smaller than the payoff I get if I obey. Compare,

100AE[f_2*]+300AE[f_*3] <  400AE[f_*1]

Therefore, if a positive fraction of other stakeholders obey, it is a nash equilibrium for me to obey also.

[iddo]

Simple Attack where PoA is worse then PoW (no bribery):

All chains are signed by default if stakeholder participates. A fraction p of stakeholders participate. Attacker owns positive stake share, 0<s<1  and 0<p+s<1.  Attacker has workshare 0<w<1 of aggregate hash rate and the extra weight on signed blocks T. Attacker uses his stake to swing things in his favor.  Attacker wins if (1+pT+sT) w > (1+pT)(1-w)

But what is the nature of the attack here? If the attacker is mining in secret then the LHS is (1+sT)w instead of (1+pT+sT)w, and if the attacker is mining in public then he's simply helping to generate the honest branch.

I'm assuming that he was mining in secret, but then he revealed his secret chain to the world. Due to promiscuous signing (if I can call it that), the secret chain can catch up with less than 50% work.

Yes, interesting.
So basically what happens here is that attacker has to wait the safe double-spend length before making his branch public, and simple-PoA guarantees that when the attacker's branch goes public it will be shorter (with less signatures) than the honest branch, but if your equation holds then eventually the attacker's branch will win.
Let's consider this attack with particular parameters. Since wer're interested in the case where pure-PoW is safe and simple-PoA is vulnerable, and since an attacker with 51% hashpower can defeat pure-PoW, the interesting case is when the attacker has less than 50% hashpower, so let's say he has 40%, and that the PoA weight is 3-fold (so T=2) and half of the rational stakeholders paricipate (so p=1/2).
We get (1+1+2s)4/10>(1+1)6/10, meaning that we need s=1/2
Therefore the attacker needs half of activate stake under his malicious control in order to carry out this attack. In Bitcoin terms, if the total stake is about 10 million BTC, then the active stake would be 5 million BTC, so the attacker would need 2.5 million BTC and 40% of the total hashpower. So as with the previous attack, I like these odds.

Also, I still take issue with your initial assumtion:

All chains are signed by default if stakeholder participates.

Using the terminology from post #47, we could say that h of the stakeholders are honest which means that they'll use a client that follows the protocol so they'll only sign the longest branch, r of the stakeholders are rational so they'll use a modified client and sign all branches, m of the stakeholders are malicious stakeholders that are under the control of the attacker and they'll only sign his shorter branch, and h+r+m <= 1
Now the equation is (1+mT+rT)w > (1+hT+rT)(1-w)
Wouldn't you agree that h>0 ? Simply because some stakeholders care about the health of the cryptocurrency network and wouldn't want to see double-spending attacks take place. Actually I know that h>0 because I personally would prefer to use a client that follows the protocol rather than the "rational" client. Also, we can have non-protocol methods to deal with rational stakeholders who care about their own reputation rather than the health of the network, for example some website could listen on the network and record addresses of stakeholder who sign short branches, so if some stakeholder does it repeatedly he would gain a bad reputation.

BTW just to make it clear why the m fraction of stakeholders aren't behaving rationally, note that if they win the follow-the-satoshi lottery on the honest branch then they refuse to sign and thereby forfeit their reward, even though the honest branch is longer.

Regarding my dream objective, it's probably just wishful thinking to hope that we could have a proof-of-stake protocol that is always at least as safe as pure-PoW. In reality it'd always be a game of trade-offs that depend on variables that describe the underlying assumptions. I hoped that the assumption that 50% of the stakeholders aren't malicious would be enough, but if we look again at your attack with say w=45% hashpower, h=0, r=1/2, T=2, then we'd get m<1/2 and therefore to guarantee m>=1/2 we'd need for example T=1 (i.e. 2-fold PoA weight). But anyway the attack described in post #78 works with m<1/2 and T=1  (for example).

So we now have two concrete attacks (your attack at post #88 and my attack at post #78) that demonstrate the trade-offs. When setting particular parameters, it seems to me that simple-PoA is advantageous (by far) over pure-PoW.

Regarding bribe attacks, I haven't fully thought it through yet. Could you please reply to the previous question that I was curious about, namely whether you think that simple-PoA is less secure than pure-PoW because of the bribes attack? I explained why I think that the answer is "no" in post #87.

Edit: I'm also curious to hear your answer regarding the game-theory aspect of the bribes attack:

BTW from the point of view of the atomistic miner/stakeholder, it's not so clear why it's rational to help the attacker, given that the honest chain is longer and therefore if he's the only one who helps the attack then he would lose.

To elaborate a bit: when the attacker sees that a stakeholder won the follow-the-satoshi lottery on the honest branch, he puts a txn in his public shorter branch that gives this stakeholder even more coins (either the attacker puts the txn immediately so he has to trust the stakeholder not to sign the honest branch, or promises to put the txn after the 6-block validity length so that the stakeholder has to trust the attacker). So if this particular stakeholder is the only one who colludes with the attacker, then the attack would most probably fail and this stakeholder would lose the lottery reward that he would have received on the honest branch. Can you please explain why it's rational for the atomistic stakeholder to collude with the attacker by accepting the bribe? I suppose that the bribes will have to be very large in order to provide an incentive for stakeholders to collude with the attack, which implies that the double-spending txn is even larger.

[iddo]

Regarding whether protection from attackers who deny service (by generating empty blocks) can be incorporated into PoA:

I think that the objective that we should aspire to achieve is something like: an attacker couldn't deny "too many" txns unless he controls at least 50% of the active stake and a huge amount (say 90%) of the total hashpower.
Let's take some simple example that shows why ABAB (posts #53, #68) achieves this objective. Suppose there're 20 honest stakeholders with 5 BTC each, they can do round-robin to generate the type-B blocks, i.e. each stakeholder waits 20 turns so he'd have 20*5=100 coin-confirms and then try to generate type-B block, or they could all try to generate the type-B block simultaneously i.e. each stakeholder with 5 coin-confirms trying to meet the difficulty/5 threshold, and their combined difficulty will still be (1/20)*(difficulty/5) for each type-B block. So effectively the distributed honest network always has 100 coin-confirms. Now if the attacker has 50% of the total stake, i.e. 100 coins, then with his huge hashpower he will defeat the honest network by generating all (or more than 90%) the blocks. If for example the attacker had only 50 coins, then he would only generate every 2nd type-B block, and therefore at least 1/4 of all the blocks will be generated by the honest network, and we're good.

However, ABAB has highly significant implications, in particular: no mining pools are possible for type-B blocks (post #80).

We could instead try to incorporate BDD into the winning branch calculation (given the rationale in post #71), meaning that we look at the coin-confirms of the txns inside the block, instead of the coin-confirms of the stakeholder who signed the block. However, it's unlikely that we could meet the objective of requiring the attacker to have 50% of the total stake, because it's unreasonable to expect that anything near 50% of the total stake will be used in the txns inside the blocks that the honest network generates, and therefore the attacker could defeat the honest network with much less than 50% stake.

How about using something like AAAAAAAAABAAAAAAAAAB (abbrev A9BA9B) ? The rule would be: at every type-B block increment by 1 the coin-confirms of every coin, and when some coins are used to sign type-B block we reset the coin-confirms of those coins back to 1. As mentioned in the example, if the attacker has 25% of the total stake then he'll only be able to generate every 2nd type-B block, so we are guaranteed that 1/20 of all the blocks are generated by the honest network. Is that good enough? Here mining pool could still generate 90% of all the blocks.

simple-PoA can be used together with A9BA9B to provide much better protection from double-spending attacks.

Though I guess that we could come up with better ideas than A9BA9B, any suggestions?

[cunicula]

However, ABAB has highly significant implications, in particular: no mining pools are possible for type-B blocks (post #80).

...

How about using something like AAAAAAAAABAAAAAAAAAB (abbrev A9BA9B) ?
...


simple-PoA can be used together with A9BA9B to provide much better protection from double-spending attacks.

Though I guess that we could come up with better ideas than A9BA9B, any suggestions?

Do you like A9BA9B because of reduced variance of A block arrival times?
Or is it about distributing a larger share of rewards to A block miners?

If it is the former, that then A9BA9B is fine with me. Reduced variance (a la litecoin) has some advantages. If it is the latter, I don't agree. I think rewards should be split 50-50 between A and B blocks. Increasing rewards for A blocks will increase PoW participation. PoW miners need to compensated for electricity and hardware and will drop out without this compensation. Likewise, increasing rewards for B blocks will increase PoS participation. PoS miners need to be compensated for keeping their computers on and exposed to the network. They are facing a significant risk of theft. There is a trade off here. A 50-50 split seems reasonable to me. I think you can reward the miners of A and B blocks with an evenly divided long-run average of txn fees.


I think double-spend protection is completely fine with either ABAB or A9BA9B. I agree that adding simple PoA could improve things from say "completely fine" to "excellent." There is also a small chance it could make things worse. PoA's effectiveness depends on how it is used. The best case scenario is that everyone participates in PoA and everyone signs one chain only. Then PoA will make the network very secure. The middle case is that everyone participates in PoA, but everyone signs every chain they see. Then PoA will be neither beneficial nor harmful. The worst case scenario is that hardly anyone participates in PoA. Then PoA opens up a weak point for attack.

In simple PoA, the "promiscuous signing" troubles me somewhat, but it's not be a make it or break it issue. Likewise bribery is a little troubling, but not a make it or break it issue. I'd be more worried about these if there were no ABAB system in place. The most serious danger  is non-participation. There needs to be some reward offered to encourage people to participate. I could accept the 'fancy' variable interest reward that discourages "promiscuous signing" or a simple share of the long-run average txn fee which encourages "promiscuous signing". I'm willing to believe that many people will sign honestly out of altruism. It doesn't need to be everyone. Due to bribery concerns, I don't think a highly variable txn fee reward is a good idea.

For both B blocks and PoA, it is important to mitigate risks for signatories. This is almost as important for participation as the reward. Signatories need to store unecrypted private keys online. For a large balance, this is much too risky. There needs to be some redesign of the protocol to mitigate (but not remove) the theft risk. I proposed an idea for a hard fork modification for PPCoin here:
https://bitcointalk.org/index.php?topic=115608.msg1319290#msg1319290
https://bitcointalk.org/index.php?topic=115608.msg1319612#msg1319612 (I suggested something else too, but the linked proposal is much better)
My gut feeling is that mitigation of theft risk will be well-received. Users worry a lot more about personal theft risk than they do about collective network security.

[iddo]

Hello cunicula,

I'll respond to your other posts soon, but I've come up with a new idea that deals with attackers who generate empty blocks, different than ABAB, so I'd like to throw it out there.

This idea is more in the spirit of PoA and it doesn't interfere with mining pools. Suppose the attacker who wishes to generate empty blocks has 99% of the total hashpower. Our objective is to let the honest network generate every (say) 7th block, instead of every 100th block that the 99% malicious hashpower implies. The protocol rule is that at every 5th block we xor the hashes of the last 5 blocks, then derive from the xor'd result an address of a uniform-random stakeholder via follow-the-satoshi technique, and this lucky stakeholder is allowed to create the 7th block (i.e. two blocks after the current 5th block) just by collecting the txns that he wishes to put inside the block and signing it with his privkey, without doing any PoW, The protocol still allows this 7th block to be generated in the regular fashion by anyone else via PoW according to the current difficulty, in case the lucky stakeholder isn't active.
Comments please?

Edit: I'll mention why I think that security against an attacker who generates empty blocks to destroy the network is important. It's possible to say that if the attacker has 99% hashpower then still every 100th block on average will be generated by the honest network, and since the attacker wastes his resources while generating empty blocks the network can survive with 1/100 of the blocks until the attacker gives up. However, the attack could quite plausibly have a snowball effect, meaning that more and more honest miners will quit as confidence in the network is being lost. With the idea above, the stakeholders would control one block at predictable short intervals (every 7th block in the example), so the network could continue to function, which might discourage the attacker from wasting his resources on this kind of attack.

Let me mention that in general I'm trying to come up with the most simple (to implement, as well as to analyze) protocol change so that we could hardfork Litecoin. If it'd be successful then maybe Bitcoin could incorporate or refine these ideas next. However, if you'd like to design an even better protocol (that wouldn't have mining pools), maybe with the intention of starting a new alternate cryptocurrency and try it out, then I'll be happy to participate in that effort too (initially the most interesting aspect for me would be to analyze the advantages of this protocol over simple-PoA etc.)

[cunicula]

Hello cunicula,

I'll respond to your other posts soon, but I've come up with a new idea that deals with attackers who generate empty blocks, different than ABAB, so I'd like to throw it out there.

This idea is more in the spirit of PoA and it doesn't interfere with mining pools. Suppose the attacker who wishes to generate empty blocks has 99% of the total hashpower. Our objective is to let the honest network generate every (say) 7th block, instead of every 100th block that the 99% malicious hashpower implies. The protocol rule is that at every 5th block we xor the hashes of the last 5 blocks, then derive from the xor'd result an address of a uniform-random stakeholder via follow-the-satoshi technique, and this lucky stakeholder is allowed to create the 7th block (i.e. two blocks after the current 5th block) just by collecting the txns that he wishes to put inside the block and signing it with his privkey, without doing any PoW, The protocol still allows this 7th block to be generated in the regular fashion by anyone else via PoW according to the current difficulty, in case the lucky stakeholder isn't active.
Comments please?

Let me mention that in general I'm trying to come up with the most simple (to imlpement, as well as to analyze) protocol change so that we could hardfork Litecoin. If it'd be successful then maybe Bitcoin could incorporate or refine these ideas next. However, if you'd like to design an even better protocol (that wouldn't have mining pools), maybe with the intention of starting a new alternate cryptocurrency and try it out, then I'll be happy to participate in that effort too (initially the most interesting aspect for me would be to analyze the advantages of this protocol over simple-PoA etc.)

In terms of analytical simplicty
ABAB much simpler than PoA.  [promiscuous signing is very complicated to deal with analytically.]

In terms of implementation (my strong expectation)
ABAB much simpler than PoA.

In terms of alienating mining pools (apparently a concern for you [I could care less])
Miners/pools just care about getting their coins. Just give the A block guys 100% of block reward and 50% fees. Give the B block guys 0% of block reward and 50% of fees.
The miners/pools don't care about fees, so they will go along with it.
You should also alter the fee structure to make txn fee-based bribes less feasible. (i.e. pay a long-run average of txn fees)

[iddo]

In terms of analytical simplicty
ABAB much simpler than PoA.  [promiscuous signing is very complicated to deal with analytically.]

So far I'm quite happy with the analysis of simple-PoA, though I'm still waiting for your answers to the two questions that I asked in post #94 regarding bribe attacks (at the end). Any other comments are also welcome, of course.

In terms of alienating mining pools (apparently a concern for you [I could care less])
Miners/pools just care about getting their coins. Just give the A block guys 100% of block reward and 50% fees. Give the B block guys 0% of block reward and 50% of fees.

I thought that our focus should be on the environment after the block reward ended (post #81).
How can you give the miner+stakeholder who solved some type-B block anything other than all then txn-fees of that block? Who will get the rest of the txn-fees in this case? Or maybe there wouldn't be any txn-fees and instead you recommend using a reward system of one of the other kinds that you mentioned?


BTW, instead of ABAB, we could also have just one single block type that combines both, for example the miner+stakeholder first uses his privkey to sign and solve for a block hash according to coin-confirms difficulty, and then he concatenates the hash he found to the block, and hashes the result to solve according to pure-PoW difficulty. It means having a shorter safe double-spending interval, but adjusting the two difficulties independently might be problematic, and there'd be other security implications that should be considered (and mining pools will be impossible).

Are you sure that ABAB is what you consider to be the best protocol? Nothing is left to refine?
What about security against double-spending attacks? ABAB doesn't offer better double-spending security than pure-PoW, and users have to wait twice longer than pure-PoW in order to get the same level of security that pure-PoW provides.

Any comments regarding my new idea in post #97 ?

[cunicula]

Edit: I'll mention why I think that security against an attacker who generates empty blocks to destroy the network is important. It's possible to say that if the attacker has 99% hashpower then still every 100th block on average will be generated by the honest network, and since the attacker wastes his resources while generating empty blocks the network can survive with 1/100 of the blocks until the attacker gives up. However, the attack could quite plausibly have a snowball effect, meaning that more and more honest miners will quit as confidence in the network is being lost. With the idea above, the stakeholders would control one block at predictable short intervals (every 7th block in the example), so the network could continue to function, which might discourage the attacker from wasting his resources on this kind of attack.

Yes, I completely agree with this. This was my motivation for interest in proof-of-stake in the first place. I had no initial interest in preventing double spends. I was mostly concerned with empty blocks and the snowball effect. Combined these suggest that you only have to apply 51% of hashing power for a brief interval to permanently destroy the network.

Recall that the attacker can refuse to build on other chains. Therefore with 51% he can generate 100% of blocks. Acquiring 99% does not offer any additional advantage.

As far as generating a random minter every seventh block. I need to know what the rule to evaluate the winning chain is. If it is simply longest chain, then 1 out of every 7 blocks is a trivial obstacle for the attacker. His chain could simply never make use of these blocks. This would mean that instead of 50.1%, he needs 54%. That doesn't raise the bar much at all.

Is the rule that the chain with the most random minters wins? This raises the bar substantially. To minimize ambiguity, I feel that the rules should map directly to chain length.
To do this you should not allow the chain to be extended unless the random block is constructed.

[cunicula]

and that the PoA weight is 3-fold (so T=2) and half of the rational stakeholders paricipate (so p=1/2).
We get (1+1+2s)4/10>(1+1)6/10, meaning that we need s=1/2
Therefore the attacker needs half of activate stake under his malicious control in order to carry out this attack. In Bitcoin terms, if the total stake is about 10 million BTC, then the active stake would be 5 million BTC, so the attacker would need 2.5 million BTC and 40% of the total hashpower. So as with the previous attack, I like these odds.

I think T needs to be much higher, or the system won't have much to distinguish itself from PoW.

1) Attacker wins if (1+pT+sT) w > (1+pT)(1-w) [this describes the worst case scenario.]

Say p=1/10 and s=1/10. I think this reasonably describes an absolute worst case scenario. I am hoping that signing can be made safe and rewarding enough that we can guarantee p>=0.1. I'm sure that we can guarantee s<0.1. It does not make any sense whatsoever to attack with high s. The attacker would face huge personal losses. The attacker wins if w>0.46. That is fine.

2) If T=2, p=1, s=0, and all stakeholders are honest (absolute best case scenario), then the attacker wins if w > (1+2T)(1-w). That is if w>0.75. Thus, absolute ideal performance with these parameters improves the work requirements for attack from 50.1% to 75.1%. I do not like these odds at all. My demand for the best case scenario was 99.9%.

3) We can increase T to meet my best case scenario demand that w=0.999. Then, T=499. Now consider the first scenario again. p=1/10 and s=1/10. Then the attacker needs w>0.34. That is not that much worse than w>0.46.  Say we take it a step further increase my best case scenario demand to w=1. w = (T+10)/(3T+20). lim T->∞ w =0.33. Thus if you are going in this direction, and you can p>=0.1, you might as well make T=∞. That isn't much worse, so why not increase T to ∞?

What does it mean if T is ∞? The only sensible interpretation is that blocks require PoA signatures in order to be extended.

Can this work with mining pools? Sure, why not?

1) Mining pool generates block and adds it to blockchain.
2) If block gets signature, then it can be extended. Mining pool gets reward.
3) If block does not get signature, then it cannot be extended. Go to step 1.

This means that there will be multiple blocks stored in memory while they are waiting for signatures, e.g. at any point in time nodes will have info like this.
Let's suppose we start from a highly confused situation with a lot of these blocks and no signatures. Wi is a block waiting for a signature and the memory pool stores up to n blocks.


H-W1
H-W2
...
H-Wi
...
H-Wn


Suppose that several of the blocks get signed, but others don't.

H-W1
H-W2-s
...
H-Wi-s
...
H-Wn

After a time interval (say 1 minute after discovery), the unsigned chains can be removed from memory. If we hear about them again later, we can add them back in.

[]
H-W2-s
[]
H-Wi-s
[]
[]

Then miners can pick from the signed chains to work on extensions.

Suppose a new block is found, for one of the two extensions. Then the memory pool looks like this.

[]
H-W2-s
[]
H-Wi-s-Wi2
[]
[]

Now block Wi2 will either get a signature, or it won't. Say it doesn't get a sig. In the meantime, miners may have been finding other blocks that extend W2-s and Wi-s.
They found H-Wi-s-Wi3 and H-W2-s-W23
Pools will want to wait a bit before spending work on this (say a minute) because the blocks will likely be orphaned if Wi2 gets a signature.
[]
H-Wi-s-Wi2
H-Wi-s-Wi3
H-W2-s-W23
[]
H-W2-s-W2n

One of these blocks gets signed, say H-W2-s-W23, and the other blocks are cleared from memory after a time interval, so we are left with.

[]
[]
[]
H-W2-s-W23-s
[]
[]

We can see that the system has achieved consensus about H-W2. There is no point in revisiting this history, it would clearly be a waste of work.

I think a good system is to make an ABAB chain where all of the blocks have PoA signatures. So the chain can look like AsBsAsBs.

Double-spending is extremely difficult because the s signatures make secret chain extensions very hard. You could publicly flood the chain with empty blocks. However, because of the B blocks, you will
quickly run out of coin-confirmations when you try to do this unless you have s>0.5. PoW miners and Pools are still happy because they can still generate A blocks and capture block reward. Both A and B blocks share some of the txn fees with the block signers. The txn fees are distributed from a long-run average fund, so it is not feasible to offer bribes to fork the chain.

The only weakness occurs if p falls to a very low level. Stake signing needs to be made safe in order to prevent this. This means their needs to be a specialized signing private key with limited spending functionality. I discussed how to do this in the previously linked thread: https://bitcointalk.org/index.php?topic=115608.msg1319612#msg1319612

To compare two chains of the same difficulty, just use length (ignoring unsigned blocks at the end)
To compare two chains of varying difficulty:
Total Chain Difficulty = (0.5 * Total A Chain Difficulty^r + 0.5*Total B Chain Difficulty^r)^(1/r) where r is some negative number. Say -5.
The function ensures that you can't get very far at all in replacing one chain with another unless you can simultaneously increase both difficulty levels. Increasing just one will not cut it.

[iddo]

As far as generating a random minter every seventh block. I need to know what the rule to evaluate the winning chain is. If it is simply longest chain, then 1 out of every 7 blocks is a trivial obstacle for the attacker. His chain could simply never make use of these blocks. This would mean that instead of 50.1%, he needs 54%. That doesn't raise the bar much at all.

I don't understand why you're talking about 54% hashpower, given that I assumed that the attacker even hash 99% hashpower.
Suppose that the attacker generates blocks in public, and it takes the attacker 10 minutes to generate each block. When the 5th block is generated, the lucky stakeholder is derived from that hashes of the last 5 blocks, so this stakeholder's client could notify him, and now this stakeholder can create the 7th block (2 blocks after this 5th block) without any PoW effort. If this lucky stakeholder creates the 7th block and broadcasts it in less than 10 minutes, then the distributed network will accept it as a valid extension of the chain, and the attacker will be forced to continue to extend the chain from the 8th block.

Actually, xor'ing the last 5 blocks was a bad idea, because the attacker could generate 4 blocks in public and then re-solve the 5th block repeatedly until he derives himself as the chosen stakeholder. One better way to do it would be something like this: suppose that the total number of satoshis minted so far is bounded by 2^x (say x=30), then each of the 5 block hashes derives x/5 bits (independently of the other 4 blocks), and the xor'd hash of all the 5 blocks derives a permutation out of the 5! or possible permutations. This should make it nearly impossible for the attacker to derive a satoshi that belongs to him by re-solving only the 5th block.
I still suspect that I'm missing more elegant (crypto oriented) ways to rely on all of the last 5 blocks in order to derive a uniform-random number. Suggestions?

Anyway, in practice we can easily overcome this issue by using scrypt with many iteration and a large memory buffer to derive the chosen stakeholder. Then the attacker couldn't afford repeated attempts to re-derive the stakeholder even if he has 99% hashpower, because the honest network with 1% hashpower only needs to derive the stakeholder once.

[cunicula]

If this lucky stakeholders creates the 7th block and broadcasts it in less than 10 minutes, then the distributed network will accept it as a valid extension of the chain, and the attacker will be forced to continue to extend the chain from the 8th block.

You need a rule to compare two chains. If the longest chain wins for example, then the attacker does not need to include any of the PoA generated blocks provided that he has 54% of hashing power.

[cunicula]

Suggestions?

As suggested before, for each block,

1) Require the selection of multiple winners who sign in sequence. Thus the attacker chances of selecting himself become (s)^n, where n is the length of the sequence and 0<s<1 is the attackers share of stake.

2) Do not make these XOR'd blocks or whatever optional. Make them mandatory.

[iddo]

If this lucky stakeholders creates the 7th block and broadcasts it in less than 10 minutes, then the distributed network will accept it as a valid extension of the chain, and the attacker will be forced to continue to extend the chain from the 8th block.

You need a rule to compare two chains. If the longest chain wins for example, then the attacker does not need to include any of the PoA generated blocks provided that he has 54% of hashing power.

Yes, longest chain wins. This new idea that I described in posts #97 and #102 is independent of PoA, you can apply it to pure-PoW in order to get protection from an attacker who generates empty blocks.
I still don't understand why you're talking about 54% hashpower instead of 99% hashpower. Because of the difficulty adjustments, even with 99% hashpower the attacker needs 10mins to generate each block, while the chosen stakeholder can generate the (say) 7th block instantly, just by signing it. Am I missing something here? Please take another look at posts #97 and #102 to make sure that you understand this protocol?

[cunicula]

If this lucky stakeholders creates the 7th block and broadcasts it in less than 10 minutes, then the distributed network will accept it as a valid extension of the chain, and the attacker will be forced to continue to extend the chain from the 8th block.

You need a rule to compare two chains. If the longest chain wins for example, then the attacker does not need to include any of the PoA generated blocks provided that he has 54% of hashing power.

Yes, longest chain wins. This new idea that I described in posts #97 and #102 is independent of PoA, you can apply it to pure-PoW in order to get protection from an attacker who generates empty blocks.
I still don't understand why you're talking about 54% hashpower instead of 99% hashpower. Because of the difficulty adjustments, even with 99% hashpower the attacker needs 10mins to generate each block, while the chosen stakeholder can generate the (say) 7th block instantly, just by signing it. Am I missing something here? Please take another look at posts #97 and #102 to make sure that you understand this protocol?

In bitcoin, an attacker with 51% of hashing power can refuse to build on other people's chains. His chain will always be the longest.

In your case, there is an optional PoA block after every 6th block. Since this block is optional (not a good idea), the attacker can also refuse to build on top of it. He can construct a long chain which does not include any PoA blocks. This is the key point. The attacker is not required to pay any attention to these optional blocks.

The legitimate chain will get an PoA extra block every 6 blocks, giving it a small length advantage. The attacker can overcome this small advantage by having 54% of hashing power instead of 50.1%.

If you make the PoA block mandatory this problem is fixed. This is the reasoning behind the ABABAB system. The key point is that the block ordering is deterministic. The advantages to deterministic ordering apply to PoA as well. Alternate designs such as in PPCoin allow for random orderings of PoW and PoS blocks. This is bad. It allows attackers to win using just one block type. In PPCoin the duration during which attackers can win is limited through difficulty adjustments. This is useless in the short-run, but provides some long-run protection. In your case there is no difficulty adjustment for PoA blocks, so the attacker can win forever.

This is also the most important reason why I object to simple PoA. The PoA protection will be extremely weak unless the signatures are mandatory. Make them mandatory. Why not?

[iddo]

Right, oops, my mind was messed up and I forgot that the block is optional.
Need to consider what'd be the best way to deal with inactive stakeholders, instead of simply saying that the block is optional (which was a very bad idea).
Having significantly higher PoW difficulty for this block (if the lucky stakeholder is absent) is one option. Making the block mandatory so that the earlier block would have to be re-solved is another option. Maybe there are better options...

Edit: if the winning satoshi is R then we could have something like R_n=hash(R,n) (mod X) where X is the total amount of satoshis minted until this block, n=1,2,3,... represented number of minutes, and if you're the R_n stakeholder then you may generate the block if you attach to it a PoW proof that'd take n minutes to generate according to the current difficulty.

[cunicula]

Right, oops, my mind was messed up and I forgot that the block is optional.
Need to consider what'd be the best way to deal with inactive stakeholders, instead of simply saying that the block is optional (which was a very bad idea).
Having significantly higher PoW difficulty for this block (if the lucky stakeholder is absent) is one option. Making the block mandatory so that the earlier block would have to be re-solved is another option. Maybe there are better options...

Edit: if the winning satoshi is R then we could have something like R_n=hash(R,n) (mod X) where X is the total amount of satoshis minted until this block, n=1,2,3,... represented number of minutes, and if you're the R_n stakeholder then you may generate the block if you attach to it a PoW proof that'd take n minutes to generate according to the current difficulty.

I would just say orphan the block if the stakeholder is missing. A new block can be built which maps to a new stakeholder. Any non-mandatory solution will only work over a long time interval (like a difficulty adjustment).

You can deal with missing stakeholders as follows:

1) Include an optional signature which maps to a random stakeholder. Offer a reward for this signature.
2) If that signature isn't delivered in a timely fashion, there will be a record of it in the chain (this signature is optional).
3) Do not ask this public key to sign any blocks in the future. If a subsequent 'follow the satoshi' lottery maps to this key, then hash this draw again to get a new draw. Iterate if necessary.
4) The coins can reactivate themselves by getting moved to a new public key that hasn't been 'deactivated'.

If you do this then the lottery will constantly be updated to include only active participants.

[iddo]

3) We can increase T to meet my best case scenario demand that w=0.999. Then, T=499. Now consider the first scenario again. p=1/10 and s=1/10

I attempted to explain in post #78 why the non-public double-spending attack implies that big T such as T=499 is a bad idea.
Let's use your suggested p=s=1/10 and let's assume for example that the attacker has 20% of the total hashpower.
Suppose the attacker wishes to do 20-blocks reorg. He has 1/4 of the total hashpower, so he will generate 5 blocks in secret while the honest network generates 20 blocks. Because p=1/10, only 2 out of the 20 honest blocks will be signed, so the honest branch has 2T+negligible effective length. Therefore, the task of the attacker is to get 3 signed blocks in his 5 blocks branch. His success probability is 0.00856 according to binomial distribution with success probability s=1/10, meaning that once every 117 blocks he could do 20-blocks reorg (once every 19.5 hours with 10mins block-time).

[iddo]

Right, oops, my mind was messed up and I forgot that the block is optional.
Need to consider what'd be the best way to deal with inactive stakeholders, instead of simply saying that the block is optional (which was a very bad idea).
Having significantly higher PoW difficulty for this block (if the lucky stakeholder is absent) is one option. Making the block mandatory so that the earlier block would have to be re-solved is another option. Maybe there are better options...

Edit: if the winning satoshi is R then we could have something like R_n=hash(R,n) (mod X) where X is the total amount of satoshis minted until this block, n=1,2,3,... represented number of minutes, and if you're the R_n stakeholder then you may generate the block if you attach to it a PoW proof that'd take n minutes to generate according to the current difficulty.

I would just say orphan the block if the stakeholder is missing. A new block can be built which maps to a new stakeholder. Any non-mandatory solution will only work over a long time interval (like a difficulty adjustment).

You can deal with missing stakeholders as follows:

1) Include an optional signature which maps to a random stakeholder. Offer a reward for this signature.
2) If that signature isn't delivered in a timely fashion, there will be a record of it in the chain (this signature is optional).
3) Do not ask this public key to sign any blocks in the future. If a subsequent 'follow the satoshi' lottery maps to this key, then hash this draw again to get a new draw. Iterate if necessary.
4) The coins can reactivate themselves by getting moved to a new public key that hasn't been 'deactivated'.

If you do this then the lottery will constantly be updated to include only active participants.

This sounds computationally intensive, because the blacklisted addresses will be scattered in different places in the blockchain. Also, it's unclear how the nodes could verify that the blacklisted address wasn't added maliciously, and it's unclear what'd be the incentive to put the blacklisted addresses in the blockchain. Maybe this idea can be refined, though in the spirit of PoA I'm striving for a protocol that's as simple as possible.

Do you think that there's something inherently wrong with my R_n=hash(R,n) suggestion, or that it's just redundant? If the miners have to go several blocks back and re-solve, then there's a lot of unpredictability involved, with regard to how long it takes until some stakeholder will finally be found?
Maybe we could come up with more elegant ideas than that hash(R,n) suggestion.

Edit: on second thought, hash(R,n) can be attacked, the attacker can try to increment n until he derives himself as the stakeholder, then solve the block in n minutes. If the attacker has huge hashpower, maybe he could do it in secret, before revealing the (say) 5th block.

[cunicula]

3) We can increase T to meet my best case scenario demand that w=0.999. Then, T=499. Now consider the first scenario again. p=1/10 and s=1/10

I attempted to explain in post #78 why the non-public double-spending attack implies that big T such as T=499 is a bad idea.
Let's use your suggested p=s=1/10 and let's assume for example that the attacker has 20% of the total hashpower.
Suppose the attacker wishes to do 20-blocks reorg. He has 1/4 of the total hashpower, so he will generate 5 blocks in secret while the honest network generates 20 blocks. Because p=1/0, only 2 out of the 20 honest blocks will be signed, so the honest branch has 2T+negligible effective length. Therefore, the task of the attacker is to get 3 signed blocks in his 5 blocks branch. His success probability is 0.00856 according to binomial distribution with success probability s=1/10, meaning that once every 117 blocks he could do 20-blocks reorg (once every 19.5 hours with 10mins block-time).

You are assuming that unsigned blocks are permitted. That is a bad idea. Make signing mandatory. The perceived issue disappears.
Tolerating unsigned blocks has a wide array of negative consequences.

In particular, you stick yourself with the following tradeoff.
1) Protection is very weak.
or
2) There can be periodic long reorgs.
or
3) Some combination of (1) and (2)

This is the same thing that happens with ABAB blocks if you allow for random ordering (e.g. AABBBBABBAA instead of ABABAB). The same principle is at work here. Deterministic ordering is the solution.

[iddo]

Regarding signing-key / limited-withdrawal delegation:

Before getting into more useful/complex limited-withdrawal schemes, I'd first like to consider what'd be the least bloated way to implement key delegation.

We could have a single bit in each address that specifies whether it's a regular address or a delegated address. The protocol rule could be that a delegated address can only spend (say) 5 coins at each block. Another protocol rule would be that a delegated address is only allowed to receive coins once (except for winning the follow-the-satoshi lottery), and the delegated address is allowed to transfer all of its coins back to the address from which it received coins. In other words, the txn in which the regular address sends coins to the delegated address is where the linkage is established in the blockchain. Whenever someone tries to send coins to a delegated address (i.e. an address in which the delegate bit is set), we have to verify that this delegated address has never received coins before. When the delegated address wishes to restore all the coins back to its linked regular address, we have to look at the linkage txn in the blockchain, i.e. verify that the regular address was indeed the address that sent coins to this delegated address.
If the amount of coins that this kind of delegated address is large enough relative to expected stakeholder signing reward, then it'd discourage the stakeholders from selling their delegated addresses to the attacker. Whenever the delegated address spends coins, the stakeholder could receive notification via the client or via blockexplorer website, so in case the address was compromised he could withdraw the rest of his coins back to the linked address.
Could key delegation be implemented in a more simple way than this?

[iddo]

You are assuming that unsigned blocks are permitted. That is a bad idea. Make signing mandatory. The perceived issue disappears.

How to make signing mandatory? Do you mean post #72 and #73, i.e. the miner broadcasts his solved block and then the stakeholder has to sign it, before the chain could be extended from this block? That's quite different than PoA, and I think that your analysis in post #101 was about PoA, right?

I think that PoA with T=2 is conservative, meaning that it isn't less secure than pure-PoW, but it doesn't offer double-spending protection from attackers with 99% hashpower, only from attackers with 66% hashpower etc.

[iddo]

Any non-mandatory solution will only work over a long time interval

This comment actually appears to be the elegant solution that I was looking for: every 5th block combines the 4 blocks before it to derives the lucky stakeholder address, and this lucky stakeholder may create the 105th block (i.e. 100 blocks after this 5th block) without any PoW effort, instead of the 7th block that I said earlier. So blocks 5,10,15,20,25,... specify the lucky stakeholders for blocks 105,110,115,120,125,... and we get that every 5th block is generated by the stakeholders to thwart the empty blocks attack, which is even better than every 7th block. Therefore we can have the protocol rule of allowing the 105th block (and so on) to be generated in the regular fashion via PoW according to the current difficulty, to deal with inactive stakeholders. As an added bonus, the stakeholders rather than the attacker control the 5th blocks (unless we have an inactive stakeholder), so the attacker couldn't try to control the xor in order to derive himself as the next stakeholder. In fact, we might need to be worried about a malicious stakeholder who tries to derive himself as the next stakeholder (100 blocks later) by doing many signature attempts, so having the 5th block control only x/5 bits of the derived satoshi as in post #102 (or some other idea) can be useful.

Edit: an interesting thought experiment is to consider what would happen if we allow stakeholders to generate every block instead of every (say) 5th block, i.e. blocks 101,102,103 and so on instead of blocks 105,110,115 and so on. If the safe double-spending distance is 6, then the stakeholders who were chosen to generate the blocks 101,102,103,104,105,106,107 could collude by including the txn that they wish to reverse in block 101, then extend the chain until block 106 and thereby get the merchant to send the merchandise, and then instantly release an alternative branch 101*,102*,103*,104*,105*,106*,107* where block 101* doesn't contain the relevant txn. If stakeholders blocks are at every 5th block, then the stakeholder who was chosen for block 100 will have to generate blocks 101*,102*,... via PoW, he could only collude with the next stakeholder at block 105, so I suppose that it's better to have the interval between stakeholders blocks longer than the safe double-spend distance, so for example every 10th block instead of every 5th block.

[cunicula]

As long as the blocks are optional the attacker can just bypass them. They have to be mandatory to be useful. It will not help to link the 5th block to the 105th block. The 105th block can simply be ignored. If the 105th block is mandatory, then you would have to orphan the entire 100 block sequence whenever the 105th block's stakeholder is found. It is better to just make it the next block, then you only have to orphan one PoW block.

Why does it matter if the implementation differs from PoA? PoA is weak and ineffective.
PPCoin has already implemented a far superior (though still imperfect) solution. If you don't try to improve on PPCoin then what is the point?

[iddo]

As long as the blocks are optional the attacker can just bypass them. They have to be mandatory to be useful. It will not help to link the 5th block to the 105th block. The 105th block can simply be ignored. If the 105th block is mandatory, then you would have to orphan the entire 100 block sequence whenever the 105th block's stakeholder is found. It is better to just make it the next block, then you only have to orphan one PoW block.

Right, sorry, it was a dumb idea. The attacker could simply create PoW blocks around the 105th block.
Unfortunately, so far it seems to me that inactive stakeholders make this idea quite problematic.

As mentioned in your post #100, one option to to give high weight to the stakeholders blocks. This can be viewed as keeping the chain interval for which the winning stakeholder was absent, and just extending the chain afterwards (because the weight of the interval without stakeholder block is negligible). Though we could try to fine-tune the weights, so that PoW weights aren't so negligible when compared to stakeholders block weight. This approach opens the door to double-spending attacks by miners who collude with some lucky stakeholder who will reveal his non-PoW block later, which would cause a reorg because his block has high weight.

The other approach is to require that the stakeholders block will be generated. Suppose we want security against attacker with 99% hashpower who generates empty blocks. This attacker is almost 100 times faster than the honest miners. Let's use your frequent assumption that in the worst case the attacker still has less than 10% of the total stake (note: total stake, not active stake). If we go with my R_n=hash(R,n) idea in order to generate a new stakeholder if the previous stakeholder turned out to be inactive, it will take the attacker 10 attempts of hash(R,n) on average until he derives himself as the winning stakeholder, because he has 1/10 of the total stake. If we say that with n=1 you should attach PoW proof that's equivalent to generating 10 blocks according to the current difficulty, with n=2 you need PoW proof of 20 blocks, etc., then on average the attacker will win the lottery at hash(R,10) so he will have to submit PoW proof that's equivalent to generating 100 blocks, which is slower than the honest miners, and therefore he will fail if he tries to ignore the stakeholders block by generating PoW proof instead. We would also need to make sure that it isn't easier to go back (say) 5 blocks and extend the chain again in order to derive a new random stakeholder, so if stakeholders blocks are at every 5th block then we could say that the next stakeholder is derived from last (say) 15 blocks, and because those blocks contain 3 stakeholders blocks that the attack cannot generate himself via PoW, it'd be futile for him to try to reverse the chain. Deriving from the last 10 blocks (even if there weren't stakeholders blocks among them) is also good enough, because the attacker would need to generate 10 PoW blocks in order to get a single attempt at deriving himself as the random stakeholder.

Why does it matter if the implementation differs from PoA? PoA is weak and ineffective.

So far I think that simple-PoA is effective in preventing double-spending attacks. I'm still curious to hear your answers regarding the bribe attack (end of post #94). Regarding the empty blocks attack, the jury is still out, I'm still vague on what'd be the best option. The PoA-style idea seems to be inelegant so far, maybe I'm missing something and it could be improved. Helpful comments would be very much appreciated.

PPCoin has already implemented a far superior (though still imperfect) solution. If you don't try to improve on PPCoin then what is the point?

Is there a post that describes the PPCoin protocol?
I've tried to search a little now and I see for example this post that you've made: https://bitcointalk.org/index.php?topic=101820.msg1302737#msg1302737
Nobody answered your post there. Maybe the person who coded PPCoin has never participated in this forum, I doubt whether the proponents of PPCoin here actually understand the protocol. Also, if the source code hasn't been reviewed then quite possibly there would be messy mistakes in it.
Do you know whether PPCoin offers security against double-spending attacks?
Probably only killerstorm and you understand the PPCoin protocol, so maybe one of you could summarize how it works?

[iddo]

Actually, xor'ing the last 5 blocks was a bad idea, because the attacker could generate 4 blocks in public and then re-solve the 5th block repeatedly until he derives himself as the chosen stakeholder. One better way to do it would be something like this: suppose that the total number of satoshis minted so far is bounded by 2^x (say x=30), then each of the 5 block hashes derives x/5 bits (independently of the other 4 blocks), and the xor'd hash of all the 5 blocks derives a permutation out of the 5! or possible permutations. This should make it nearly impossible for the attacker to derive a satoshi that belongs to him by re-solving only the 5th block.
I still suspect that I'm missing more elegant (crypto oriented) ways to rely on all of the last 5 blocks in order to derive a uniform-random number. Suggestions?

Anyway, in practice we can easily overcome this issue by using scrypt with many iteration and a large memory buffer to derive the chosen stakeholder. Then the attacker couldn't afford repeated attempts to re-derive the stakeholder even if he has 99% hashpower, because the honest network with 1% hashpower only needs to derive the stakeholder once.

One other way to derive x-bits pseudorandom number from the last 5 block hashes: derive x pseudorandom bits from the first block hash and store them in R, then derive log(5)*x pseudorandom bits from the 2nd block hash and view it as base5 number of 30 digits (e.g. 3402104...), and if the ith digit of this base5 number is 0 then flip the ith bit of R, meaning that we flip each bit with 1/5 probability. Do the same with the 3rd,4th,5th block hashes as we did with the 2nd block hash.

[iddo]

Actually, there is a substantive difference between adding empty blocks security (via lottery) to pure-PoW versus adding it to simple-PoA. The difference is that with simple-PoA the attacker cannot keep his branch secret for too long, because he wouldn't accumulate PoA signatures so the honest branch will have more weight multipliers. We'd need to tweak the previous idea in order to take advantage of simple-PoA. The problem earlier was that if the (say) 5th block was a stakeholders block that some lucky stakeholder may create, then the attacker could simply generate the 1st,2nd,3rd blocks in public, and then generate the 4th,5th blocks in secret and reveal them together (if the lucky stakeholder could see the 4th block then he would generate the 5th block much faster than the attacker, but if he only sees the 3rd block then he cannot). Instead, we can view the blockchain as batches of 5 blocks, each batch of 5 blocks derives the pseudorandom stakeholder, and this lucky stakeholder may create a block (without PoW effort) in any place at the next batch of 5 blocks. Actually, it could be useful to use my botched idea from post #114 and introduce some large gap, for example the 1st batch of 5 blocks derives a lucky stakeholder for the 200th batch (i.e. 1000 blocks later), so that the lucky stakeholder will be notified early (unlike simple-PoA signatures where we cannot do it), and this might increase stakeholders participation. With the large gap, we cannot do hash(R,n) as in post #116 etc., so the protocol rule can be that if the first 4 blocks in each batch of 5 blocks didn't include a stakeholders block, then to generate the 5th block via PoW you'd need to meet a higher difficulty. The weight of a stakeholders block can be the same as the weight of a signed simple-PoA block, or higher/lower.

Let's try an example with specific numbers. Batches of 5 blocks as above, simple-PoA with 5-fold weight multiplier (T=4, as in coblee's OP). Note that to get security against double-spending with 5-fold you can still wait for 5-out-of-10 signed blocks and the attacker would need 7 secret consecutive signed blocks (see post #78). Let's assume that 75% of all stakeholders blocks will be created (large gap for notification, and the lucky stakeholder gets the entire reward of the block that he created, unlike when he provides PoA signatures and gets 10% of the reward). Therefore, we can set the PoW difficulty of generating the 5th block of a batch with no stakeholders block to be 4 times harder. This means that in 3/4 of the time the batch will have one block that is generated instantly, and in 1/4 of the time the batch will have a block that takes 4 times longer to generate, so on average we didn't decrease the performance. Let's assume that the weight of a stakeholder block is 10-fold, i.e. twice more than the weight of PoA signed block. Let's assume that on average half of the regular blocks get signed via simple-PoA.  Now, an honest batch of 5 blocks will have weight 10+5+5+1+1=22, and the secret branch of the PoW attacker has weight=1 in each block. This means that while the honest network generates 4 blocks to gain weight=22, the attacker will need to generate 23 consecutive blocks in order to outcompete the honest batch of 5 blocks, but among those 23 blocks there were 4 blocks that he had to generate with 4-fold increased difficulty. To sum up, the attackers needs to generate 35 blocks to outcompete 4 honest blocks, so his hashpower has to be 8.75 times faster than the honest miners, meaning that he has nearly 90% of the total hashpower in order to generate empty blocks continuously.

What might be sketchy with those specific numbers is giving twice more weight to the stakeholders block, so the lucky stakeholder could try to collude with miners and double-spend, though his weight advantage wouldn't be so big. One simple way approach to avoid this is to increase the simple-PoA multiplier to a little more than 5-fold, but then users might have to wait for a little more than 5-out-10 signed blocks to get security from double-spending, which would be fine with 2.5min block time. However, all of this assumes that half of the stakeholders provide PoA signatures, hopefully the incentives could be put in place for that.

Edit: 4-fold higher difficulty for 5th PoW block is good for the empty blocks attack, but bad for double-spending attacks, because the malicious stakeholder who was chosen in the lottery and creates a secret branch with his stakeholders block will also have time to create 4 additional blocks ahead of the honest network. Repeating the previous example with the same numbers and with regular PoW difficulty instead of 4-fold difficulty, we get that the attacker who generates empty blocks will need 85.2% of the total hashpower.

[iddo]

A very simple, radically different, and secure PoS algorithm is to appoint an elected committee that controls all txns.

Say there are 9 public keys that belong to committee members. These can start out as some founding fathers of the coin.
Any valid txn block must be signed by 5 out of committee 9 keys. This solves the consensus problem.

The committee could be corrupt. Thus they need to be voted in and out of office.

Any coin holder can destroy 100 coins in order to mine a voting block, i.e. he sends them to a destruction address. The voting block does not include txns, just votes.
The coin holder proposes the removal of one committee member (public key) and the addition of another committee member (public key). Normally, I think you would nominate yourself.

He then draws and announces a random number (he can control the random number seed, it won't really matter). The random number is then hashed 10,000 times to draw a random electorate.
The electorate is drawn randomly from satoshis that have moved within the last year (thus avoiding the problem of dead voters). Major stakeholders would get to vote more than once.

The voters then either vote yes, no, or fail to vote. People who fail to vote are assumed to vote no.
If a block eventually gets 5,001 yes votes, then it enters the blockchain and a committee member is replaced. His signing key no longer affects block validity.

The voting blocks are valid even if they are not signed by any committee members. Voting blocks only enter the block chain if they pass.

There is no single point of failure here. If a committee member gets compromised or fails to perform his duties, he gets replaced.
The committee can also perform useful functions such as levying txn fees to fund development work or any other public good.
If someone don't like this they can vote the bastards out.

Shouldn't all voting nominations and electorate votes be added to the chain without the central committee signatures? Otherwise the committe could block the votes?

If the majority of the central committee wishes to abuse their power, what could they do exactly? Only withhold txns? Maybe offer some type of insider trading bribes regarding which txns will be included and at what time? Could they try to do double-spending by signing two conflicting blocks with their 5 signatures, and then broadcast the two blocks to different parts of the network at the same time? Any other ideas for attacks by the central committee?

I'm biased against this kind of protocol, because the centralized entity would have too much power that it could abuse, and it'd take a long time to replace the centralized entity. So the central committee could boost confidence by behaving flawlessly until more participants use the network, then more and more money can be influenced by the central committee members, and then they might begin to abuse their power.

Maybe you should start a thread to discuss this kind of protocol, my biased opnion here is probably not so useful.

[cunicula]

Hey iddo,

Ignore the committee idea. I wasn't entirely serious. It is just seemed amusing that election of dictators solved problems.

I think it would be useful to recap my views. I think going into details can sometimes be distracting. It might be helpful to look at things from an outline perspective at this point.
Once we agree on the outline, then we can move on to details. I think it is best to discuss one point at a time though. Otherwise we may just jump around without ever reaching consensus.

1) some signatures on should be mandatory

mandatory sigs make secret PoW attacks very, very hard

2) there should be also be optional signatures

optional signatures create a record of nonparticipating stakeholders and allow them to be removed from the lottery. Without this, lost coins would eventually become a problem.

3) Allow random lottery winners to generate mandatory blocks is a good idea

The mandatory blocks prevent PoW denial of service. With this taken care of, my system of proof-of-stake becomes redundant and can be dropped. This simplifies things.

4) Signing Participation should be addressed by offering rewards and reducing costs

This is at least a three-pronged problem. 1) Provide adequate rewards for signatories. 2) Provide adequate security from theft for signatories. 3) Try to keep bandwidth requirements reasonable.

5) Fee payments need to be specified in the protocol. The txn fee system in bitcoin is very strange. Future txn fees are more or less completely unpredictable. This is not good. We should be able to predict (at least approximately) what rewards will be at any point in time. Just setting a fee = 0.01 won't cut it. Since price moves, this can mean anything and would need to be constantly readjusted. Secondly, freely adjustable fees provide a plausible bribe vector. I don't like this either.

I favor a fee or reward system based on coin-age. Options are 1) Inflation based on miners/signers coin-age. (fees are destroyed) 2) txn fees based on senders coin-age (coins are given to miner/signer).

[iddo]

If the stakeholders block is mandatory then it indeed provides excellent security against the empty blocks attack. The problem is what to do with inactive stakeholders (because of lost coins among other reasons). One way is to backtrack and re-generate an entirely new interval of the chain, it probably has to be an interval instead of just a single block because the lucky stakeholder should get early notification instead of being forced to generate the next block immediately after the last block was generated. This option isn't so elegant, neither for the users nor for the security analysis. Another option is the hash(R,n) idea, in post #116 I described what parameters we'd need for security against an attacker with 99% of the total hashpower and 10% of the total stake, namely the performance of the network degrades and becomes 10 times slower whenever the lucky stakeholder is absent. We could degrade the performance to be only 5 times slower etc., and then get security only against less powerful attackers. I'd be very much interested to hear about other ideas to deal with inactive stakeholders in the case of mandatory lottery blocks.

Correct me if I'm wrong, but I think that the question of whether we blacklist inactive stakeholders is orthogonal to to whether the stakeholders block is mandatory or optional. If it's mandatory then the fact that we have to re-derive the winning stakeholder handles inactive stakeholders. If it's optional then that in and of itself handles inactive stakeholders. The incentives structure should adjust so that the active stakeholders fraction is above some threshold, and dead/lost stake would be factored into this. Blacklisting is just an extra feature, I mentioned in post #110 why it seems problematic to me, but maybe it could be refined.

If the stakeholder blocks are optional, then we have trade-off between the effectiveness of empty blocks protection and the effectiveness of double-spending protection. The relevant parameters that affect the trade-off are the length of the batch that needs to include one stakeholders block (longer length provides better security against double-spending, but 99% PoW-only attacker would then generate a higher ratio of empty blocks), PoW difficulty multiplier in case the lucky stakeholder is absent, and the weight of the stakeholders block. When we increase these last two parameters we get better security against the empty blocks attack, but worse security against double-spending (end of post #118). In fact, in order for the stakeholders block to be completely neutral for double-spending attacks we need to give it zero weight. Then in the example in post #118 we have that the honest network generates 4 blocks to gain 0+1+1+5+5=12 weight, so the PoW attacker would need to generate 13 blocks versus 4 honest blocks, i.e. he needs 76.3% of the total hashpower, as opposed to 90% in the initial example.

I'm also open to debate whether something like ABAB or A9BA9B (+ simple-PoA) is better than "lottery empty blocks security" + simple-PoA. Maybe you even claim that double-spending security isn't important, so ABAB is enough, but still if we could devise a protocol that offers both empty blocks security and double-spending security then that would be better (at the very least from a PR standpoint). However, if we talk about too many issues simultaneously then it's easier to lose track, so I'd prefer that we first discuss what'd be the best way to do the "lottery empty blocks security".

5) Fee payments need to be specified in the protocol. The txn fee system in bitcoin is very strange. Future txn fees are more or less completely unpredictable. This is not good. We should be able to predict (at least approximately) what rewards will be at any point in time. Just setting a fee = 0.01 won't cut it. Since price moves, this can mean anything and would need to be constantly readjusted. Secondly, freely adjustable fees provide a plausible bribe vector. I don't like this either.

I favor a fee or reward system based on coin-age. Options are 1) Inflation based on miners/signers coin-age. (fees are destroyed) 2) txn fees based on senders coin-age (coins are given to miner/signer).

Please explain these two options in more details. Does option (1) imply infinite monetary inflation? Please also explain in more details why having optional txn fees so that the security properties of the network are set by the free market is a bad idea. I'm not saying that you're wrong, I'm just hoping that you could make your arguments more clear.

[cunicula]

I'm going to hold off on the other questions because I want to focus on what I think is the #1 issue here.

Why does the stakeholder need any advance notice at all (either to generate a block or provide a signature)? Stakeholders in PPCoin (for example) are always ready to generate blocks. It seems to work fine.

If the stakeholder does not need advance notice, I don't see what the problem is. Just orphan blocks that identify missing stakeholders.

Could you explain why you feel advance notice is necessary (or even just helpful in some way)?

[iddo]

Actually, xor'ing the last 5 blocks was a bad idea, because the attacker could generate 4 blocks in public and then re-solve the 5th block repeatedly until he derives himself as the chosen stakeholder. One better way to do it would be something like this: suppose that the total number of satoshis minted so far is bounded by 2^x (say x=30), then each of the 5 block hashes derives x/5 bits (independently of the other 4 blocks), and the xor'd hash of all the 5 blocks derives a permutation out of the 5! or possible permutations. This should make it nearly impossible for the attacker to derive a satoshi that belongs to him by re-solving only the 5th block.
I still suspect that I'm missing more elegant (crypto oriented) ways to rely on all of the last 5 blocks in order to derive a uniform-random number. Suggestions?

Anyway, in practice we can easily overcome this issue by using scrypt with many iteration and a large memory buffer to derive the chosen stakeholder. Then the attacker couldn't afford repeated attempts to re-derive the stakeholder even if he has 99% hashpower, because the honest network with 1% hashpower only needs to derive the stakeholder once.

One other way to derive x-bits pseudorandom number from the last 5 block hashes: derive x pseudorandom bits from the first block hash and store them in R, then derive log(5)*x pseudorandom bits from the 2nd block hash and view it as base5 number of 30 digits (e.g. 3402104...), and if the ith digit of this base5 number is 0 then flip the ith bit of R, meaning that we flip each bit with 1/5 probability. Do the same with the 3rd,4th,5th block hashes as we did with the 2nd block hash.

Actually, this appears to be quite bad if the attacker has a significant amount of stake. Let's say the total stake is 2^30 satoshis, and the attacker has 1/2^3=1/8 of the total stake. The probability that the Hamming ball of weight 6 around some (pseudo)random number contains a satoshi that belongs to the attacker (assuming that his satoshis are uniformly distributed) is 1-product[1-2^6/(2^30-k), k=0...2^27-1] > 1-(1-2^6/2^30)^2^27 = 0.9996, so the attacker could still re-solve the last block via PoW until he derives himself as the lucky stakeholder. The optimal way to rely on the entire history of the previous blocks (instead of just the last block) is to derive a single bit from each block, so we'd need to rely of 30 blocks (which is ok because those 30 blocks may include previous stakeholders blocks among them).

I'll also mention the simple argument why we cannot use commitment schemes etc. to force everyone to re-solve the last (say) 5 blocks, under the assumption that the hash function is a random oracle. If it was true that we have to re-solve all of the 5 blocks to derive a new winning stakeholder, then it implies that after solving the 1st block (in 10 minutes on average because of the difficulty adjustments) each of the next 4 blocks must have only one particular solution (because the random oracle is used to derive the winning stakeholder). So solving each of the next 4 blocks is equivalent to doing pre-image attack on the hash function, which is an infeasible task, as opposed to a task that takes 10 minutes. QED.

If the stakeholder does not need advance notice, I don't see what the problem is. Just orphan blocks that identify missing stakeholders.

Could you explain why you feel advance notice is necessary (or even just helpful in some way)?

The advance notice is just a feature that would hopefully increase the stakeholders' participation. We agree that the protocol becomes more secure when more stakeholders are encouraged to participate. The same issue exists with simple-PoA, meaning that if the simple-PoA rule is that you may provide your signature only in the next 3 blocks (instead of 6 blocks) after you were derived as the winning stakeholder, then attack scenarios such as the double-spending bribes service become more difficult for the the attacker, because his secret branch will have fewer opportunities to gather signatures from non-honest rational stakeholders when he goes public. The reason for specifying (say) 6 blocks instead of (say) 3 blocks as the limit in simple-PoA is to encourage stakeholders' participation by giving them more time. So it's a trade-off between two desirable properties. As I mentioned, the thing is that for the empty blocks security it's fine to give an advance notice of (say) 1000 blocks, while for the simple-PoA double-spending security we cannot give an advance notice that's longer than the safe double-spending distance because of those attack scenarios with the bribes service and so on.

But maybe it'd be better forget about the advance notice for the empty blocks security, we should consider to pros/cons of doing that. If we have mandatory stakeholders blocks and there's no advance notice, then the protocol would be for example that every 5th block derives the identity of the lucky stakeholder who must create the 6th block. In order to deal with an attacker who has 99% hashpower, we can have scrypt based derivation function to choose the lucky stakeholder which takes (say) 3 minute to calculate. Now, if an attacker who has 10% of the total stake tries to re-solve the 5th block in order to derive himself as the winning stakeholder, then he will need 30 extra minutes on average. So if the block time is 2.5 minutes, we're good.

Edit: even though the 99% attacker is 100 times faster than the honest hashpower, the fact that the scrypt derivation function is sequential means that he wouldn't have advantage over an honest miner who solves the block, so the penalty for the honest network when the lucky stakeholder is absent would also be (say) 3 minutes, which is good. However, there is a huge problem here, because nodes will have to spend 3 minutes to verify each stakeholders block. So if a new user download the blockchain (with e.g. 250,000 blocks) for the first time, it will take him weeks to verify it. So this is another reason why the advance notice and derving the winning stakeholder from the last several blocks is useful, unless we find a way around this problem.

[cunicula]

In order to deal with an attacker who has 99% hashpower, we can have scrypt based derivation function to choose the lucky stakeholder which takes (say) 3 minute to calculate.
Edit: even though the 99% attacker is 100 times faster than the honest hashpower, the fact that the scrypt derivation function is sequential means that he wouldn't have advantage over an honest miner who solves the block, so the penalty for the honest network when the lucky stakeholder is absent would also be (say) 3 minutes, which is good. However, there is a huge problem here, because nodes will have to spend 3 minutes to verify each stakeholders block. So if a new user download the blockchain (with e.g. 250,000 blocks) for the first time, it will take him weeks to verify it. So this is another reason why the advance notice and derving the winning stakeholder from the last several blocks is useful, unless we find a way around this problem.

I feel like you are trying to address an imaginary problem. Why not just have people continuously try to find and broadcast new block candidates until one of these block candidates gets signed and can be built upon? This is like how PoW mining operates currently except there is an additional hurdle to meet before you move on to mining the next block. Why wouldn't this work?

What concern are you trying to address with the special scrypt function (i.e. I don't see why it would be helpful)?

[The above questions are all basically the same, but I am rephrasing them in case one of the versions is easier to understand than the others.]

[iddo]

I feel like you are trying to address an imaginary problem. Why not just have people continuously try to find and broadcast new block candidates until one of these block candidates gets signed and can be built upon? This is like how PoW mining operates currently except there is an additional hurdle to meet before you move on to mining the next block. Why wouldn't this work?

If an attacker (who wishes to generate empty blocks) with 99% hashpower and 10% of the total stake isn't imaginary, then this problem isn't imaginary. This attacker can generate 99 PoW blocks while the honest network generates 1 PoW block during the same time. If the identity of the lucky stakeholder is derived just from the last single PoW block, then this attacker can afford to do 99 attempts at deriving himself as the lucky stakeholder, and having 10% stake implies that he only needs 10 attempts on average. In other words, an attacker with 99% hashpower and 1% stake could destroy the network.

Suppose we go by my suggestion of deriving the identity of the winning stakeholder from the last (say) 30 blocks by doing something like deriving a pseudorandom index j between 1 and 30 from each of the last 29 blocks and flipping the jth bit and hashing the final result. An attacker with 10% stake could get 16 attempts to derive himself by generating different derived bits for the last 4 blocks in secret, meaning that he will need to generate 30 blocks in secret (full binary tree of depth 4 without the root). Here simple-PoA can help, e.g. with 5-fold and 50% stakeholders' participation, because the attacker would need to generate 30 secret blocks to gain weight=4, while the honest network gains weight=1+1+5+5=12 when it generates 4 blocks. If we're generous and say the attacker with 10% stake gains 1 PoA signature when he generates 8 blocks, he'll still need to generate 60 blocks to gain weight=1+1+1+1+1+1+1+5=12, so he has to be 60/4=15 times faster than the honest network, meaning that he has 93.75% of the total hashpower. I'm assuming that the stakeholders won't provide their PoA signatures for empty blocks, because there's no reward there. Does that sound good?

Edit: actually that doesn't sound so good, even when deriving the identity just from the last block, an attacker with 10% stake needs 91% of the total hashpower.

Any better ideas on how to do empty blocks security via lottery, or via other methods?

[cunicula]

I think you are referring to the DoS problem, where the attacker can submit empty blocks. You could also be referring to the double-spending problem.

It doesn't matter. In either case, there are two simple options. Please pick an option. If you do not like either option, please explain why.

Denial of Service:

a) accept that an attacker with 91% of hashing power and 10% of stake will succeed [this is fine with me, but I prefer b]
b) select n random stakeholders who will mine mandatory blocks in sequence. Say n=3. These blocks can be mined immediately. Then our hypothetical 10% stake attacker would need to mine 1,000 blocks before he could draw his own stake three times in a row. Thus he would need 99.9% of hashing power to deny service, rather than just 91%.


Double-Spending:

a) accept that an attacker with 91% of hashing power and 10% of stake will succeed [this is fine with me, but I prefer b]
b) select n random stakeholders to sign each block. Say n=3. Then our hypothetical 10% stake attacker would need to mine 1,000 blocks before he could draw his own stake three times in a row. Thus he would need 99.9% of hashing power to double-spend, rather than just 91%.

Note: When I say 10% stake, I am referring to 10% of participating stake, which is likely less than 10% of total stake.

[iddo]

Denial of Service:

b) select n random stakeholders who will mine mandatory blocks in sequence. Say n=3. These blocks can be mined immediately. Then our hypothetical 10% stake attacker would need to mine 1,000 blocks before he could draw his own stake three times in a row. Thus he would need 99.9% of hashing power to deny service, rather than just 91%.

Interesting.
The first thing that springs to mind is that the 3 lucky stakeholders could collude with malicious miners to carry out double-spending, but we can easily take care of that by giving weight=0 to a stakeholders block (with weight=1 the safe double-spending length would decrease from 6 to 3 when the 3 stakeholders are corrupt, or maybe you'd refer to them as rational).
Another issue is that we might have to limit the txn-fees reward of each of the 3 consecutive stakeholders blocks to 1/3 of the average reward, otherwise the two latter stakeholders will sit idle and wait to collect txn-fees (assuming that monetary inflation has ended).
This idea would probably be more sensitive to the stakeholders' participation. With 50% participation, it will take 8 PoW solutions until the 3 consecutive stakeholders blocks will be created. So the performance of the network degrades, in particular in terms of double-spending security if weight=0 is used. How much degradation depends on the gap until the next stakeholders blocks.

Maybe n=2 would make more sense than n=3. I wonder if some of the parameters that we discuss should be dynamically adjusted by the protocol, but for this n=3 parameter we probably cannot adjust by detecting empty blocks, because the attacker could generate almost empty blocks etc.

Double-Spending:

a) accept that an attacker with 91% of hashing power and 10% of stake will succeed [this is fine with me, but I prefer b]
b) select n random stakeholders to sign each block. Say n=3. Then our hypothetical 10% stake attacker would need to mine 1,000 blocks before he could draw his own stake three times in a row. Thus he would need 99.9% of hashing power to double-spend, rather than just 91%.

Are you talking about the derived stakeholders for simple-PoA signatures, or the stakeholders who were derived to create a stakeholders block? Not sure what kind of double-spending attack you have in mind. The purpose of simple-PoA is to reduce the risk of double-spending, and with weight=0 the stakeholders blocks become neutral to double-spending attacks, so they just degrade the network performance.

[cunicula]

This idea would probably be more sensitive to the stakeholders' participation. With 50% participation, it will take 8 PoW solutions until the 3 consecutive stakeholders blocks will be created. So the performance of the network degrades, in particular in terms of double-spending security if weight=0 is used. How much degradation depends on the gap until the next stakeholders blocks.

Gradual degradation of network performance can be resolved by removing inactive public keys from the lottery list. We can talk about this once we have the block mining order and signature requirements fixed.

So the performance of the network degrades, in particular in terms of double-spending security if weight=0 is used. How much degradation depends on the gap until the next stakeholders blocks.

I'm not sure what you mean by weight. The key characteristic of these blocks is that they are mandatory and occur at deterministic intervals.

I feel like we should ignore any possibility for collusion right now and maybe revisit it later. In any consensus system, there are so many ways people can collude that it is very difficult to defend against. The best defense is probably just a) ensuring that collusion requires cooperation from many different people, and b) ensuring that the set of people is difficult to predict beforehand.

Maybe n=2 would make more sense than n=3.

I would prefer n=3.

Are you talking about the derived stakeholders for simple-PoA signatures, or the stakeholders who were derived to create a stakeholders block? Not sure what kind of double-spending attack you have in mind. The purpose of simple-PoA is to reduce the risk of double-spending, and with weight=0 the stakeholders blocks become neutral to double-spending attacks, so they just degrade the network performance.

Okay, let me review this to see if we are communicating. I'm only trying to describe the block ordering and not rewards etc. We should tentatively agree on the block ordering if possible.

Block 1: PoW Block is mined, random stakeholder is drawn. This random stakeholder is able to deliver an optional signature any time between block 1 and block 5c.
Block 3: PoW Block is mined, random stakeholder is drawn. This random stakeholder is able to deliver an optional signature any time between block 2 and block 6.
Block 4: PoW Block is mined, random stakeholder is drawn. This random stakeholder is able to deliver an optional signature any time between block 3 and block 7.
Block 5: PoW Block is mined, 3 random stakeholders are drawn.
Block 5a: Random stakeholder block 1
Block 5b: Random stakeholder block 2
Block 5c: Random stakeholder block 3
Block 6: PoW Block is mined, random stakeholder is drawn. This random stakeholder is able to deliver an optional signature any time between block 6 and block 10c.
...
Block 10: PoW Block is mined, 3 random stakeholders are drawn.
Block 10a: Random stakeholder block 1
Block 10b: Random stakeholder block 2
Block 10c: Random stakeholder block 3
...

Say the blocks have a 2.5 minute interval on average, so a full sequence 1-5 occurs about once every 15 minutes. The stakeholder blocks would appear almost instantly since they don't require work.

Is that correct? I think it would work fine this way.

[iddo]

I'm not sure what you mean by weight.

I meant the weight for deciding the winning branch among competing branches. It'd be weight=1 for unsigned regular PoW blocks, (say) weight=5 for signed PoW blocks via simple-PoA, and weight=0 for stakeholders blocks. The branch with the highest weight wins. Also, because the PoW block the precedes and derives the stakeholders blocks is significantly more reversible than other PoW blocks, it should also have weight=0 until all of the consecutive stakeholders blocks were created (so it'd be weight=1 or weight=5 for the batch that consists of this PoW block together with the consecutive stakeholders blocks that follow it).

In other words, we wouldn't rely on blocks that the stakeholders create in order to provide double-spending security. Or maybe we could somewhat rely on stakeholders blocks by giving them some weight, if the security analysis of the various possible scenarios would make sense. This would be similar to the situation we have with ABAB, where the type-A PoW blocks provide double-spending security, and the type-B stakeholders blocks provide empty-blocks-DoS security.

BTW regarding ABAB, post #68 was probably a bit too optimistic. If the attacker waits (say) several weeks so that he could generate (say) 3 type-B blocks much faster than the active stakeholders, then even if he has less than 50% hashpower he could outcompete the honest network by generating the 3 interleaved type-A blocks a little slower than the honest network, but overall his secret branch of 3+3 blocks wil be generated faster than 6 blocks of the honest network. We should have more exact analysis, but it seems to make sense that an attacker with less than 50% hashpower could double-spend if he waits for enough coin-confirms before he starts the attack.

Block 1: PoW Block is mined, random stakeholder is drawn. This random stakeholder is able to deliver an optional signature any time between block 1 and block 5c.
Block 3: PoW Block is mined, random stakeholder is drawn. This random stakeholder is able to deliver an optional signature any time between block 2 and block 6.
Block 4: PoW Block is mined, random stakeholder is drawn. This random stakeholder is able to deliver an optional signature any time between block 3 and block 7.
Block 5: PoW Block is mined, 3 random stakeholders are drawn.
Block 5a: Random stakeholder block 1
Block 5b: Random stakeholder block 2
Block 5c: Random stakeholder block 3
Block 6: PoW Block is mined, random stakeholder is drawn. This random stakeholder is able to deliver an optional signature any time between block 6 and block 10c.
...
Block 10: PoW Block is mined, 3 random stakeholders are drawn.
Block 10a: Random stakeholder block 1
Block 10b: Random stakeholder block 2
Block 10c: Random stakeholder block 3
...

Yes, this appears to be fine. But the particular variables should be considered. For simple-PoA signatures, the protocol could specify for example that you're allowed to provide your signature in the next x blocks, where x>6 is disallowed, initially x=3, and at the difficulty re-adjustment we do x=x-1 or x=x+1 depending on whether there was at least 50% stakeholders' participation in the last retarget window.

Deciding the gap between stakeholders blocks (the gap between 5a,5b,5c and 10a,10b,10c) seems to be more problematic. Ideally, I wish that we could devise some protocol rule so that in the default state the empty-blocks security is disabled (i.e. blocks 5a,5b,5c won't be created), and at the difficulty re-adjustment we detect whether empty-blocks security should be enabled for the next retarget window, maybe by looking at the coin-age that was used in the last retarget window relative to the retarget window before it (so for example coins that were created during the last retarget window will be insignificant). But could the attacker exploit this kind of protocol rule to deny service while keeping the empty-blocks security disabled, by transferring his own stake between addresses that he controls? If we cannot enable/disable, then maybe we could re-adjust the gap. If that's also insecure, then we'd have to picky some constant gap, probably higher than 5 if there'd be 3 consecutive stakeholders blocks.

I'm worried about the rewards that the stakeholders should collect. The stakeholders provide a useful function for the security of the network, so they probably should receive some reward, in particular if they take a risk by using unencrypted wallet or limited-withdrawal wallet. But it's arguable, we could claim that the stakeholders have an interest to protect their stake by keeping the network secure, so maybe it's appropriate that they receive little or no reward. This is also related to whether the reward should be determined by the free-market with stakeholders-fees, or enforced by the protocol so that the security would be more predictable. The issue the worries me is that if for example the simple-PoA fee is 10% of the block reward, and with 3 consecutive stakeholders blocks this 10% figure becomes even higher, then we can take some extreme scenario where a stakeholder who has 10% of the total stake doesn't spend his coins and waits until the other 90% spend their coins to collect 1/10 of that 90% so now he'd have close to 20% stake, then wait again until the 80% spend their coins to collect 2/10 of the 80% so he'd now have about 35% of the total stake, etc.

[cunicula]

I meant the weight for deciding the winning branch among competing branches. It'd be weight=1 for unsigned regular PoW blocks, (say) weight=5 for signed PoW blocks via simple-PoA, and weight=0 for stakeholders blocks. The branch with the highest weight wins. Also, because the PoW block the precedes and derives the stakeholders blocks is significantly more reversible than other PoW blocks, it should also have weight=0 until all of the consecutive stakeholders blocks were created (so it'd be weight=1 or weight=5 for the batch that consists of this PoW block together with the consecutive stakeholders blocks that follow it).

In other words, we wouldn't rely on blocks that the stakeholders create in order to provide double-spending security. Or maybe we could somewhat rely on stakeholders blocks by giving them some weight, if the security analysis of the various possible scenarios would make sense. This would be similar to the situation we have with ABAB, where the type-A PoW blocks provide double-spending security, and the type-B stakeholders blocks provide empty-blocks-DoS security.

You cannot "not rely" on the stakeholder generated blocks for double-spend prevention. These are mandatory components of the block chain. If you cannot create them, you cannot double-spend. In fact, these blocks will always be the primary obstacle to double-spending. The weights for mandatory blocks are more or less meaningless. Anything mandatory implicitly has effectively infinite weight. By comparison, voluntary components (whether signatures or blocks) have only a minor impact on double-spending.

I would recommend a weight of 1 for unsigned blocks and a weight of 2 for signed blocks. If you raise the weight to try to make voluntary signatures matter more, you are opening the door to long, unpredictable reorganizations. That is highly undesirable. I see the voluntary signatures as stakeholder heartbeats. Their most important use is providing a record of which stakeholder participation.

BTW regarding ABAB, post #68 was probably a bit too optimistic. If the attacker waits (say) several weeks so that he could generate (say) 3 type-B blocks much faster than the active stakeholders, then even if he has less than 50% hashpower he could outcompete the honest network by generating the 3 interleaved type-A blocks a little slower than the honest network, but overall his secret branch of 3+3 blocks wil be generated faster than 6 blocks of the honest network. We should have more exact analysis, but it seems to make sense that an attacker with less than 50% hashpower could double-spend if he waits for enough coin-confirms before he starts the attack.

Let's just drop my ABAB type blocks. The proof-of-stake blocks are redundant if random stakeholders can generate blocks. Complex nested systems should be avoided (unless they are necessary). Analysis becomes more complex in the nested system.

I'm worried about the rewards that the stakeholders should collect. The stakeholders provide a useful function for the security of the network, so they probably should receive some reward, in particular if they take a risk by using unencrypted wallet or limited-withdrawal wallet. But it's arguable, we could claim that the stakeholders have an interest to protect their stake by keeping the network secure, so maybe it's appropriate that they receive little or no reward. This is also related to whether the reward should be determined by the free-market with stakeholders-fees, or enforced by the protocol so that the security would be more predictable. The issue the worries me is that if for example the simple-PoA fee is 10% of the block reward, and with 3 consecutive stakeholders blocks this 10% figure becomes even higher, then we can take some extreme scenario where a stakeholder who has 10% of the total stake doesn't spend his coins and waits until the other 90% spend their coins to collect 1/10 of that 90% so now he'd have close to 20% stake, then wait again until the 80% spend their coins to collect 2/10 of the 80% so he'd now have about 35% of the total stake, etc.

Let's hold off on this. We need to understand the blockchain structure first. Everything is interrelated, so you cannot usefully analyze one thing at a time without holding other aspects of the system fixed.
Thus we need to fix some things before moving on.

[iddo]

You cannot "not rely" on the stakeholder generated blocks for double-spend prevention.

Let me try to explain what I meant.
Let's disregard PoA signatures and have weight=1 for every PoW block, and assume that after 6 blocks the merchant's client displays some green signal which means that it's safe to assume that the txn from 6 blocks earlier won't be reversed.
Suppose the the chain is: P0 --> S1 --> S2 --> S3 --> P1 --> P2 --> P3 --> P4 --> P5 --> P6
Where P0 is the PoW block that derived the three stakeholders blocks S1,S2,S3, and P1,P2,P3,P4,P5,P6 are regular PoW blocks.
Suppose that S1 is the block that included the txn that's relevant for the merchant.
If S1 has weight=1 and S2 has weight=1 and S3 has weight=1, then the merchant's client will display the green signal when it sees that the block P3 was generated, and then the merchant will send the merchandise to the double-spending attacker. Now, in order to reverse the txn, if the attacker controls (or colludes with) the stakeholders S1,S2,S3 then he could have prepared his secret branch by instantly generating 3 new blocks S1*,S2*,S3* that don't include the relvenat txn, and then use his hashpower to generate only 3 PoW blocks P1*,P2*,P3*, instead of having to generate 6 PoW blocks. So the attacker only needs to generate 3 PoW blocks to outcompete the honest branch, if he bribes the malicious/rational stakeholders to collude with him.
However, if we have weight=0 for the blocks S1,S2,S3, then the merchant's client will display the green signal only after seeing that P6 was generated, and we're good.
Does this make sense?

[cunicula]

You cannot "not rely" on the stakeholder generated blocks for double-spend prevention.

Let me try to explain what I meant.
Let's disregard PoA signatures and have weight=1 for every PoW block, and assume that after 6 blocks the merchant's client displays some green signal which means that it's safe to assume that the txn from 6 blocks earlier won't be reversed.
Suppose the the chain is: P0 --> S1 --> S2 --> S3 --> P1 --> P2 --> P3 --> P4 --> P5 --> P6
Where P0 is the PoW block that derived the three stakeholders blocks S1,S2,S3, and P1,P2,P3,P4,P5,P6 are regular PoW blocks.
Suppose that S1 is the block that included the txn that's relevant for the merchant.
If S1 has weight=1 and S2 has weight=1 and S3 has weight=1, then the merchant's client will display the green signal when it sees that the block P3 was generated, and then the merchant will send the merchandise to the double-spending attacker. Now, in order to reverse the txn, if the attacker controls (or colludes with) the stakeholders S1,S2,S3 then he could have prepared his secret branch by instantly generating 3 new blocks S1*,S2*,S3* that don't include the relvenat txn, and then use his hashpower to generate only 3 PoW blocks P1*,P2*,P3*, instead of having to generate 6 PoW blocks. So the attacker only needs to generate 3 PoW blocks to outcompete the honest branch, if he bribes the malicious/rational stakeholders to collude with him.
However, if we have weight=0 for the blocks S1,S2,S3, then the merchant's client will display the green signal only after seeing that P6 was generated, and we're good.
Does this make sense?

I don't think that P6 is the appropriate time to send the green signal. I believe you should wait for 2 full cycles of stake blocks to be completed before sending the green signal.

P0 --> S1 --> S2 --> S3 --> P1 --> P2 --> P3 --> P4 --> P5 --> S4 --> S5 --> S6 --> P6--> P7 --> P8 --> P9 --> P10 --> S7 --> S8 --> S9 --> P11

If the txn enters at S1, then I think you should wait to give the green signal until after P11 is found. That is after 11 PoW blocks. If each PoW block comes at 2.5 minute intervals on average and the stake blocks are very fast (say 20 seconds each), this is a total time of about 30 minutes.

[iddo]

Hello cunicula,
I'm not sure if you noticed it, but your last post raises a very interesting option. If the gap between stakeholders blocks is short (say 5 as in the example), then maybe we don't need simple-PoA at all, meaning that we don't need to derive lucky stakeholders who would provide their signature for an earlier PoW block. Instead, using lottery to derive lucky stakeholders who create blocks on their own, we get double-spending security (because the gap is short and therefore merchant can wait until the stakeholders act) and empty-blocks security.

Let's consider your example with an attacker who wishes to double-spend and has 99% hashpower and 10% stake. If he wishes to reverse the txn that entered S1, then he would need stakeholders S1,S2,S3,S4*,S5*,S6*,S7*,S8*,S9* to collude with him until his secret branch would reach P11. If the merchant's client listens and tries to detect double-spending attempts, then this collusion has to kept secret. In other words, the attacker's double-spending service couldn't be public, otherwise the merchat's client would also connect to the attacker's service and detect the double-spending attempt. This means that the attacker has to re-solve P5 about 1000 times on average (assuming that he controls 10% of the total stake), while the honest network with (say) 50% stakeholders' participation only needs 2^3=8 attempts on average, where each attempt is 99 times slower than the attacker's, so effectively less than 800 attempts. Same is true for P10, and the attacker would probably also need to re-solve P0.
What do you think?

[cunicula]

Hello cunicula,
I'm not sure if you noticed it, but your last post raises a very interesting option. If the gap between stakeholders blocks is short (say 5 as in the example), then maybe we don't need simple-PoA at all, meaning that we don't need to derive lucky stakeholders who would provide their signature for an earlier PoW block. Instead, using lottery to derive lucky stakeholders who create blocks on their own, we get double-spending security (because the gap is short and therefore merchant can wait until the stakeholders act) and empty-blocks security.

I did notice this and I agree completely. To me the most elegant solution is just to generate one PoW block and then have 3 random stakeholders generate blocks, i.e.

P0-S01-S02-S03-P1-S11-S12-S13-P2-...

Comparison of chains could be based purely on the sum of all blocks PoW difficulty, just as in bitcoin.  

However, voluntary signatures still have a strong use case. There could just be one voluntary signature per PoW block. The signatures would be valid if they are submitted up to say 20 PoW blocks after the voluntary signatory is selected. These signatures do not need to be directly rewarded and they do not need to influence chain selection in any way. Instead, the voluntary signatures would provide 'heartbeats' permanently recording stakeholders who failed to keep their stake online. Providing a heartbeat makes you eligible to win the lottery. It is kind of like a lottery ticket (except you can't have more than one). If you fail to provide a heartbeat, you lose your lottery ticket until you indicate 'resurrection' by moving your coins to a new address.

Heartbeats are useful for the following reasons:

Problem:  data transmission could get unmanageable if participation levels are too low.
With 100% participation every block meeting the difficulty target will be built on using three stake blocks and therefore enter the blockchain. With full participation, the data transmission is not significantly larger than bitcoin, litecoin etc.
With 50% participation, one out of every 1/(0.5^3)=8 blocks meeting the difficulty target will be built on. This is considerably more data transmission, but it should be easily manageable.
With 10% participation, one out of every 1/(0.1^3)=1000 blocks meeting the difficulty target will be built on. If we are talking about blocks up to 1 MB, that is 1 GB of data passing through the network every time a PoW block is mined. That seems like much too much and we should do something about this.

How Heartbeats help:
1) If someone fails to provide a heartbeat, we can guess that they are frequently not online. I call these guys 'dead' stakeholders. It is wasteful to transmit blocks that identify 'dead' stakeholders as block constructors. 'dead' stakeholders would burden the system. Therefore, blocks that map to 'dead' stakeholders should be invalid. Such invalid blocks would not need to be passed around from peer to peer. This means that, at least in the long-run, data transmission requirements would not be affected by participation levels. If only 10% of people participated, then only 1 out of 1000 blocks would be potentially valid. However, the 999 out of 1000 blocks could be immediately discarded. In effect difficulty would be 1000 times higher than the recorded value. The invalid blocks mapping to dead people would not need to be passed from peer to peer.
2) 'Dead' stakeholders could be a source of fees. The details are not that important here. I'll defer description of fee collection until later.
2a) One very cool thing about extracting fees from the 'dead' is that it increases the motivation to stay active. If participation fell, then the amount revenue collected from the 'dead' would grow. This would increase rewards from participation. This creates a negative feedback cycle stabilizing participation.
2b) Another cool thing about grabbing fees from the dead is that it provides a noninflationary and demand-sensitive source of revenue. If 100% of people are participating, then there is nothing to collect from the 'dead'. That is good. If 100% of people are participating there is no need to reward participation. It doesn't make sense to issue significant fees to stakeholders if stakeholders are willing to work for free. The PoW guys still need some money of course, but we can postpone how to pay them till later.

[iddo]

P0-S01-S02-S03-P1-S11-S12-S13-P2-...

Maybe, this maximizes the reliance on stakeholders. Obviously we cannot be even more extreme and ditch the PoW blocks completely, because then lucky stakeholders attempts will be derived at blazing speeds with no difficulty adjustments (and no good way to mint coins, because I think that only PoW blocks should get newly minted coins). If the reliance on stakeholders is so frequent, then it might involve an exccesive amount of fees that go to stakeholders. Maybe your previous suggestion of 5 consecutive PoW blocks makes more sense, we need a more clean understanding of the pros/cons of doing that.

Also, if we compare timestamps at the boundaries of the difficulty retarget window, then the time difference would be affect both by total hashpower flucuation, and stakeholder's participation level. This might be another reason why having (say) 5 consecutive PoW blocks is useful, because now we can distinguish between regular PoW blocks and PoW blocks that derive stakeholders, and deduce the PoW difficulty and the stakeholder's participation level separately from each other.

I wonder what'd the best way to devise an incentives structure that keeps the stakeholders' participation above some threshold (say 50% participation). We could split the newly minted coins of the PoW blocks with stakeholders blocks when we're below the threshold, but this doesn't specify what to do when block reward is based entirely on fees, assuming finite monetary inflation. Without a convincing incentives structure, mandatory lottery blocks would be a hard sell, meaning that people might be afraid that their txn will get stuck because of inactive stakeholders. From a purely theoretical perspective the situation isn't really different than pure-PoW, i.e. with pure-PoW their txn can also get stuck if all the miners are extremely unlucky and don't generate a block that meets the current difficulty, and similarly if we assume that stakeholders' participation is always above some threshold (because there's a re-adjusting incentive for stakeholders to participate), then deriving active stakeholders is similar to generating a regular PoW block.
Any other ideas on how to create incentives that keep stakeholders participation above some predictable threshold?

With 10% participation, one out of every 1/(0.1^3)=1000 blocks meeting the difficulty target will be built on. If we are talking about blocks up to 1 MB, that is 1 GB of data passing through the network every time a PoW block is mined. That seems like much too much and we should do something about this.

You don't need to transfer 1 MB blocks before it's evident that the 3 consecutive stakeholders are active. The protocol can say that the 1st stakeholder creates S01 and broadcasts h01 and sgn01=sign(hash(PO)|h01), then the 2nd stakeholder creates S02 and broadcasts h02 and sgn02=sign(h01|h02), the the 3rd stakeholder creates S03 and broadcasts h03 and sgn03=sign(h02|h03), and then the miners wait until the blocks S01,S02,S03 themselves are sent by the stakeholders and verify that h01=hash(S01),h02=hash(S02),h03=hash(S03), and now the chain can become P0-->(S01,sgn01)-->(S01,sgn02)-->(S03,sgn03)-->P1, where the P1 block includes h03, and so on.


About heartbeats, I agree that the features that you describe could be highly beneficial, but how would the nodes manage the list of dead stakeholders? I'm worried that this idea would be way too complex in practice, could you please describe the most simple implementation that you can think of?

[cunicula]

Maybe, this maximizes the reliance on stakeholders. Obviously we cannot be even more extreme and ditch the PoW blocks completely, because then lucky stakeholders attempts will be derived at blazing speeds with no difficulty adjustments (and no good way to mint coins, because I think that only PoW blocks should get newly minted coins). If the reliance on stakeholders is so frequent, then it might involve an exccesive amount of fees that go to stakeholders. Maybe your previous suggestion of 5 consecutive PoW blocks makes more sense, we need a more clean understanding of the pros/cons of doing that.

[begin tirade]
My ideal is to ditch PoW completely, but I don't know how so I accept PoW as a necessity. There needs to be a hard to manipulate random number seed. I don't know how to create this without PoW. I am also fine with PoW miners getting all of the block subsidy. The initial distribution needs to be diverse and PoW with scrypt accomplishes this. I feel that initial distribution should be greatly accelerated (for example 100% completed in 1 year's time). I am very much opposed to PoW miners receiving a large share of txn fees. I think they should get no more than 20%. The long-run efficiency of the system depends on minimizing the use of PoW to the fullest extent possible. PoW miners are parasites. They take out of the pockets of legitimate users and use it to pay for electricity and electronics. There is no point in overpaying them. Cryptocurrency was not created to subsidize Exxon, PG&E, and AMD. If you pay money to PoS miners you add value to the currency. If you pay that money to PoW miners, you destroy the same value. There is no point in destroying wealth unnecessarily. I think once people realize that they can earn txn fees just by investing and then leaving their computers on they will quickly realize that PoW was a horrible idea. In any case, if it turns out that you paid PoW guys too much, then someone can just modify the code and pay them less. The new currency will have lower effective txn fees and therefore be better all around. We should not leave space open for competitors to do this.
[/end tirade]

As far as block structure goes, I don't care much. I am fine with the either structure. Let's just go with regular PoW blocks and PoW -> lottery draw blocks.

Downside: With two block types, you need to wait for type B blocks to be found before you are safe from double-spends. The type A blocks just provide bitcoin-level security. Thus, if you have a large number of type A blocks before every type B block, then you have to wait longer.

Upside: Since the stake blocks are minted immediately, many of these blocks are likely to be empty or nearly empty. This is wasted space. Type A blocks are more efficient as far as storage and bandwidth requirements. I think 4A1B is a reasonable balance. By 4A1B, I mean P01-P02-P03-P04-P05-S05a-S05b-S05c-P06-P07-P08-P09-P10-S10a-S10b-S10c... The type B blocks P05 and P10 will take longer to mine than the type A blocks P01-P04 and P06-P09. To avoid this, there should probably be two difficulty levels (one for each block type). Chain validity should be determined by aggregate difficulty for type B blocks. Aggregate difficulty for type A blocks should only be consulted as a tie-breaker.

Also, if we compare timestamps at the boundaries of the difficulty retarget window, then the time difference could be affect either by total hashpower flucuation, or stakeholder's participation level. This might be another reason why having (say) 5 consecutive PoW blocks is useful, because now we can distinguish between regular PoW blocks and PoW blocks that derive stakeholders, and deduce the PoW difficulty and the stakeholder's participation level separately from each other.

Stakeholder participation would be measured directly via heartbeats. If you offer a heartbeat, it is safe to assume that you are willing to mine blocks using your stake.
You can also measure it using difficulty like you say. However, this measurement will not tell you who is responsible for low participation. It does not provide a mechanism to punish people for
low participation.

Any other ideas on how to create incentives that keep stakeholders participation above some predictable threshold?

I elaborate on my idea below after I describe heartbeats.

You don't need to transfer 1 MB blocks before it's evident that the 3 consecutive stakeholders are active. The protocol can say that the 1st stakeholder creates S01 and broadcasts h01 and sgn01=sign(hash(PO)|h01), then the 2nd stakeholder creates S02 and broadcasts h02 and sgn02=sign(h01|h02), the the 3rd stakeholder creates S03 and broadcasts h03 and sgn03=sign(h02|h03), and then the miners wait until the blocks S01,S02,S03 themselves are sent by the stakeholders and verify that h01=hash(S01),h02=hash(S02),h03=hash(S03), and now the chain can become P0-->(S01,sgn01)-->(S01,sgn02)-->(S03,sgn03)-->P1, where the P1 block includes h03, and so on.

Right, this is a good idea. The issue still applies though (# of messages blows up as participation approaches 0).

About heartbeats, I agree that the features that you describe could be highly beneficial, but how would the nodes manage the list of dead stakeholders? I'm worried that this idea would be way too complex in practice, could you please describe the most simple implementation that you can think of?
[/quote]
I think you need a database to implement a lottery. As I see it, this is just a minor addition to this database.
To construct the lottery, I think you need an ordered list of all public keys and their current balances.
Each client constructs this from the blockchain during the initial verificatoin. Then the database is updated every time a block is mined or orphaned.

Suppose this is our lottery database

Public Key       Linked Stake Public key         Balance  Cumulative Balance
A                             As                              1                1
B                             Bs                             2.5             3.5
C                             Cs                              3              6.5

The lottery draw would map to a uniform distribution on the support (0,6.5). Let x be the realization of the draw. If 6.5>x>=3.5, indicates C; 3.5>x>=1 indicates B; 1>x>0 indicates A.
Signatures can be provided either

  
To incorporate hearbeats, we just add a different column. Heartbeat? 1 = Yes , 0 = No. By default, every address that is in the blockchain has a heartbeat. As you make the database,
you record public keys that failed to provide voluntary heartbeats. These public keys lose their heartbeats forever. To show this, the heartbeat indicator switches from 1 to 0.

Public Key       Linked Stake Public key         Balance  Cumulative Balance  Heartbeat?
A                             As                              1                1                        1
B                             Bs                             2.5             3.5                        0
C                             Cs                              3              6.5                        1

Now 3.5>x>=1 indicates an invalid block. B is simply not allowed to mint any stake blocks.

The final thing that I want incorporated in the database is coin-age. Coin-age is used to calculate fees. Since PoW miners need to be paid regardless of participation, I think everyone should have to pay these fees. Coin-age is the weighted average age on coins held by a public key. It can be measured in blocks, but conversion to years is more intuitive. (e.g. if I received 10 coins 2 year ago and they haven't moved and if I received 10 coins 1 year ago and they haven't moved, then coin-age is 1.5 years. If coins have been sent or a block has been mined, coin age is reset to 0.)

Again, this can be updated everytime a block is mined.
If no send, Coin-age_t = Coin-age_t-1 + 1.
If send, Coin_age_t = 1.
If send and receipt of coins, Coin_age_t = 1.
If receipt of coins but no send, Coin_age_t = [Coin_age_(t-1)*balance_(t-1)+received coins]/balance(t)

Public Key       Linked Stake Public key         Balance  Cumulative Balance  Heartbeat?         Coin-age (really measured in blocks but years are more intuitive here)
A                             As                              1                1                        1               0.03 years
B                             Bs                             2.5             3.5                        0               0.1 years
C                             Cs                              3              6.5                        1               0.2 years

As far as fees go, my proposal is simply to make them an increasing function of coin age. You essentially pay an annual 5% tax on your balance, which is forgiven if you participate.
Mandatory Fee =  0.05 * balance * (Coin-age in years) / 1 year. )

This can be derived from other information in the chart. It is not necessary to put in the database.

Public Key       Linked Stake Public key         Balance  Cumulative Balance  Heartbeat?         Coin-age          Mandatory fee
A                             As                              1                1                        1               0.03 years              0.015
B                             Bs                             2.5             3.5                        0               0.1 years               0.0125
C                             Cs                              3              6.5                        1               0.2 years               0.03

There are two incentives to participate:
1) If you participate, then your mandatory fee will be reset to 0 every time you mine a block. Thus participation allows you to avoid txn fees.
2) If you participate, then you will get a share of the fees from people who don't participate. Thus participation allows you to accumulate coins.

Let's neglect the rewards for PoW miners (who will share in the fees) and think about stakeholder incentives:

Say you have 1 coin and 90% of people participate. Participants will accumulate 5% of the balances from the other 10% of stakeholders each year.
In other words, if you participate with 1 coin that 1 coin will have an expected value of 1.0055 coins after 1 year. If you do not participate, you will have 1 coin and will need to pay a fee of 0.05 coins to use that coin, so you effectively have 0.95 coins. This is a much smaller incentive. But a small incentive is adequate if the participation rate is high.

Say you have 1 coin and only 10% of people participate. The 10% of participants will accumulate 5% of the balances from the other 90% of stakeholders each year.
If you participate, in one year, you will expect 1.45 coins. If you do not participate, you will effectively have 0.95 coins. This is a big incentive. But such an incentive is needed to keep participation from dropping too low.

Say you have 1 coin and only 1% of people participate. The 1% of participants will accumulate 5% of the balances from the other 99% of stakeholders each year.
If you participate, in one year, you will expect 5.95 coins. If you do not participate, you will effectively have 0.95 coins. This is a tremendous incentive. It is like a pirate style scheme (3% interest/week)!
But such huge incentives are needed to guarantee a minimum level of participation.

Additionally, heartbeats provide a disincentive to mine attack chains. You will not want to accept a chain where you don't have your heartbeat recorded.

Participation should also be kept safe. Safe participation effectively keeps txn fees low. However, let's discuss the above first, before moving on to discussion of the Linked Stake Public Keys.

[iddo]

My intuition still says that heartbeats/blacklisting addresses is infeasible. I'll be happy to learn that I'm wrong if you or someone else could convince me otherwise, because the features that you describe would be great to have. Suppose you need one database entry per satoshi. This entry specifies the pubkey that controls this satoshi, and the rest of the data that you mentioned. With 2,100,000,000,000,000 satoshis, if each entry occupied 1 byte, then the size of the database can be about 1910 terabytes. If each entry holds two pubkeys and other information, the total database size is say 1000 times bigger. If it's Litecoin instead of Bitcoin, then it's 4 times bigger on top of that. All the nodes that verify the blockchain need to be able to derive this database in an unambiguous way. With the blockchain we have txn-fees that restrain the total size by discouraging too much fragmentation. With such a database it isn't even clear if having one entry per satoshi is enough, or maybe we need 2^160 entries (=addresses) or 2^256 entries (=pubkeys). These worst-case numbers could be exploited by attackers who wish to bloat the database. The operations that this database (or another data structure) need to support include (1) if optional winning address which was derived via follow-the-satoshi didn't provide the heartbeat then you have to discover all the other satoshis that are controlled by this address and mark them as blacklisted in the database, and (2) whenever someone transfers his coins to a blacklisted address we should blacklist those newly transferred coins too. So I wonder if we could have some data structure with which these operations would be feasible. I admit that I haven't fully thought it through yet, but it seems infeasible to me.

Additionally, heartbeats provide a disincentive to mine attack chains. You will not want to accept a chain where you don't have your heartbeat recorded.

Could you elaborate? If it's a double-spending attacker who creates a short competing branch, then there's a negligible probability that his branch will include your address without heartbeat (you couldn't provide heartbeat because his branch was secret), so when his branch goes public w.h.p. you're not affected by the heartbeats feature.


Regarding the 3 consecutive stakeholders blocks, I think that we should regard it as a single block that is being prepared by 3 different stakeholders, and those 3 stakeholders split the reward equally. Using the same terminology of post #135, the block S02 should actually be an extension of S01, something like S02=S01|sgn01|additional_txns_collected_by_the_2nd_stakeholder, and still have sgn02=sign(h01|h02) and so on. Maybe in the interest of simplicity only the 1st stakeholder should collect the txns, because probably there won't be many new txns to be collected by the 2nd and 3rd stakeholders anyway.

If we cannot blacklist address, then I think that the main issue that we should analyse is the incentive structure for stakeholders. Maybe it makes sense to go with optional fees that are set by the free market, and have a protocol rule that disallows the total fees reward for the stakeholders block to be too high, relative to the average miners fees reward according to the last difficulty retarget window. This way the stakeholders couldn't demand too high fees to further enrich themselves at the expense of non-stakeholders? The honest client should also calculate and set the minimal recommended fee as the default fee, and this fee should be the same whether the txn was included by miners or by stakeholders, I think?

Edit: Apologies that I haven't noticed your new thread (link) and wiki updates. I only looked briefly right now. I see that you switched from 3 to 5 lucky stakeholders, which gives better security but worse performance if it'd be more difficult to find 5 active stakeholders (which puts upward pressure on the reward for stakeholders). I'll try to read everything later, but if you'd like to focus on some particular new aspects that you've raised then please let me know.

[cunicula]

My intuition still says that heartbeats/blacklisting addresses is infeasible. I'll be happy to learn that I'm wrong if you or someone else could convince me otherwise, because the features that you describe would be great to have. Suppose you need one database entry per satoshi. This entry specifies the pubkey that controls this satoshi, and the rest of the data that you mentioned. With 2,100,000,000,000,000 satoshis, if each entry occupied 1 byte, then the size of the database can be about 1910 terabytes. If each entry holds two pubkeys and other information, the total database size is say 1000 times bigger. If it's Litecoin instead of Bitcoin, then it's 4 times bigger on top of that. All the nodes that verify the blockchain need to be able to derive this database in an unambiguous way. With the blockchain we have txn-fees that restrain the total size by discouraging too much fragmentation.

Good point, but I definitely don't think we should give up on blacklisting. It has very nice properties.

Bitcoin tries to decentralize too much. It is not practical to have individual public keys holding pennies. The prevelance of tiny inputs substantially bloats the bitcoin blockchain. Public keys with pennies should be discouraged.

My suggestion is to tax small inputs. Treat them as dead by default. Say we limit lottery eligibility to public keys containing 1 full coin. Then only public keys holding 1 coin or more need to go in the database. A 1 byte entry takes up 20 MB max and the total database takes up 20 Gigabytes max. That seems manageable.

If you have more than 1 coin, you get can get all your coins in the database by consolidating inputs into one public key. If you have less than 1 coin, then you win the lottery about once every 2 years. People with very small holdings should store their money in online wallets. The online wallets can hold money in larger accounts. These online wallets can offer interest to depositors.  

As far as the two linked keys almost doubling blockchain size, this is completely worth it. The theft problem is a really big issue.

Additionally, heartbeats provide a disincentive to mine attack chains. You will not want to accept a chain where you don't have your heartbeat recorded.

Could you elaborate? If it's a double-spending attacker who creates a short competing branch, then there's a negligible probability that his branch will include your address without heartbeat (you couldn't provide heartbeat because his branch was secret), so when his branch goes public w.h.p. you're not affected by the heartbeats feature.

It only works well for long attack chains. However even for a 6 block long attack chain it still could have some functionality. If there are 30 voluntary signatures every 6 blocks, then there may be people rich enough to be included twice. (The largest bitcoin account has over 600k. That is enough to be included twice.)

[iddo]

I don't see how exactly you could store only addresses that hold at least one coin. To pick a uniform-random stakeholder via follow-the-satoshi , we derive one uniform-random satoshi out of all the satoshis that have been minted, and given that the address that controls this satoshi might control at least one coin that's fragmented across many inputs, how would you tell whether the derived satoshi is blacklisted? You could have a cryptocurrency with 21,000,000 coins in total, instead of 2,100,000,000,000,000 coins in total, but that'd be hard to distribute among the entire population and wouldn't be good for micro-payments. If you agree that the total number of coins should be in the ballpark of 2,100,000,000,000,000 then it's unclear how you handle "pennies". The devil is in the details, I'm still unclear on what your proposed data structure is supposed to support exactly, without space/time complexity blowup. There should be a more detailed description of how the nodes calculate the two basic operations that I mentioned:

(1) if optional winning address which was derived via follow-the-satoshi didn't provide the heartbeat then you have to discover all the other satoshis that are controlled by this address and mark them as blacklisted in the database, and (2) whenever someone transfers his coins to a blacklisted address we should blacklist those newly transferred coins too.

I'd also like to analyse the non-blacklisting simplified protocol from economic and technical viewpoints:

If we cannot blacklist address, then I think that the main issue that we should analyse is the incentive structure for stakeholders. Maybe it makes sense to go with optional fees that are set by the free market, and have a protocol rule that disallows the total fees reward for the stakeholders block to be too high, relative to the average miners fees reward according to the last difficulty retarget window. This way the stakeholders couldn't demand too high fees to further enrich themselves at the expense of non-stakeholders? The honest client should also calculate and set the minimal recommended fee as the default fee, and this fee should be the same whether the txn was included by miners or by stakeholders, I think?

Simply capping the reward isn't good, because an attacker could broadcast a txn with high fee to exclude everyone else, and our objective is to include as many txns as possible in each block. We could cap the fee for each txn according to the average fee in the previous retarget window, and also cap the total number of txns. The property that I'm trying to achieve is that the stakeholders wouldn't try to enrich themselves too much by refusing to sign the block until they receive a higher total fee. The miners have to re-solve the block when there are no willing stakeholders available, so this should provide some competition among the stakeholders and hopefully push their fees downwards. I'm trying to figure out which incentives structure would work well, and we should also consider your bribe attack scenarios in this context. So far I think that these simple ideas are questionable and inelegant, maybe there are better ideas for the non-blacklisting simple protocol? Preferably without infinite monetary inflation, but we can consider ideas that use infinite inflation too. Maybe even have colored-coins as the reward for stakeholders? Though the colored-coins could be exchanged for regular coins, like BTC/LTC etc.

[cunicula]

[Okay, finished.]

I think the database is completely workable.

However, some concepts need to be introduced.
There are two databases that are used.
1) Blockchain: Source of all data that bitcoin uses + data on input age which is necessary to calculate demurrage fees on dead coins
2) Database of Blockchain Meta Info: Source of data for 1) lottery 2) demurrage fees reductions 3) recording of signatures


I'm not sure where to begin, so I'm just going to go through an algorithm for maintaining the database, running the lottery, and enforcing fees.

Here are the database fields that are going to be populated:

"Public Key (sorted by alphabet)"

"Linked Stake Public Key"

"Balance"

"Cumulative Balance"

"Coin-Age"

"Forgiven Coin-Age"

Here is the data which is taken directly form the block chain:

"Total Input Value"

"Average Input Age"

"Total Mint"

Part I Sending
1) For each txn in block t, check if the public key that signed the txn is listed in the database.
a) If yes,
      i) Txn fee on send: Txn Fee >= max(Balance,total input value)*(exp(max(Coin-Age, Average Input Age)*annual demurrage rate)-1) - Balance*(exp(Forgiven Coin-Age*annual demurrage fee)-1) [Otherwise the txn is invalid.]
      ii) If the txn is sent from a limited stake signing key, check: Change Returned to Root Public Key >= all coins sent to other addresses * {max(k,k*(t/coin-years on public key)} where k=9 and t=1/12.  [Otherwise the txn is invalid]
      iii) Set Balance_t= Balance_(t-1)-total value of inputs. [This could be less than 0. That is fine]
      iv) Set Coin-age=1 and Forgiven Coin-age=0.
      v) If Balance_t<1 , then delete the public key from the database together with all its associated data.
b) If no, then
     i) Txn fee on send: Txn Fee >= (total input value)*(exp(average input age in years*annual demurrage rate)-1) [Otherwise the txn is invalid.]
     ii) The database remains unchanged.

Part II Receiving
1) For each txn in block t, check if the receiving public key is listed in the database.
2) If yes,
       a) add to the balance on the receiving address as follows: balance_t=balance_(t-1)+received coins
       b) update the coin-age on the receiving address as follows: Coin_age_t = [Coin_age_(t-1)*balance_(t-1)+received coins]/balance(t)
3) If no,
        a) Check if the address has received more than one coin, if so add the receiving public key to the database.
             Step 1: Set the public key balance = the number of received coins. (this may be less than the true value of inputs controlled by the key)
             Step 2: Set the coin-age on the public key balance = 1. (this may be less than the true age of the inputs controlled by the key)
             Step 3: Leave the Linked Stake Public Key field blank.
             Step 4: Set Active=1.

Part III General Changes.
1) If an address has not received coins, its Coin-Age(t)=Coin-Age(t-1)+1

Part IV Assigning Linked Stake Public Keys: Special txns record linkages between public keys and limited stake public keys.
1) Check if the public key is listed in the database. [If not, the txn is invalid.]
2) If yes,
       a) check if the public key is already associated with a linked stake public key. [If yes, the txn is invalid.]
       b) if the public key has not been assigned a linked stake public key, then record the linked stake public key in the database.

Part V. Txn Fee Fund
1) If the block is PoW
         a) Txn Fee Fund(t)=0.9999*(Txn Fee Fund(t-1)+(1/2-Voluntary Sigs in Block/10)*Txn Fees (t))
         b) Generation to PoW miner = 0.0001*(Txn Fee Fund(t-1)+(1/2+Voluntary Sigs in Block/10)*Txn Fees (t))
2) If the block is PoS
         a) Txn Fee Fund(t)=0.995*((Txn Fee Fund(t-1)+(1/2-Voluntary Sigs in Block/10)*Txn Fees (t))
         b) Generation to each PoS signatory and PoS block miner = 0.001*((Txn Fee Fund(t-1)+(1/2+Voluntary Sigs in Block/10)*Txn Fees (t))
[Note there are a total of 5 Signatories including PoS block miner. There is an incentive to include Voluntary Sigs in Blocks]

Part VI. Mandatory and Voluntary Signatures. [For PoS Blocks only]
1) If the key has provided a mandatory signature or voluntarily signed the previous PoS Block.
    a) then forgiven coin-age (t)= coin-age(t-1).  [Note that coin-age is not reset by the signature. Forgiven Coin-Age is just increased.]
2) Voluntary Signatures
    a)Voluntary signatures are just special txns that are included in blocks. 
    b)For any voluntary Signature check if
        i) Has the voluntary signature been requested since time t-6 [If a block includes an unrequested signature it is invalid.]
        ii) Has the voluntary signature been provided in a block since time t-6 [If a block includes a duplicate signature, then it is invalid]
    c) A maximum of 5 voluntary signatures can be included in 1 block. [If not, the block is invalid.]
3) If a key's voluntary signature is requested at time t-6 but this signature is not in any block up to time t
    a) The entry for this key should be deleted from the database.
   
Part VII. Cumulative Balance
  1) After Balance is updated, the lottery probabilities will change. Cumulative Balance needs to be repopulated to account for changes in balance. Call the sum total cumulative for the last database entry "Total Balance"
  
Part VIII. Lottery Draw
  1) Check if PoW submission meets the difficulty target [If not draw is invalid]
  2) Hash PoW submission 10 times
  3) Map each hash to a draw from the uniform distribution on the interval [0, Total Mint]
  4) Check if all of the hashes map to the interval [0, Total Balance] (Note that Total Balance <= Total Mint)
        4a) If yes, identify the public key associated with each draw in the database. The first five draws indicate mandatory signatures. The next five draws indicate voluntary
               signatures.
        4b) If no, the PoW submission is invalid.

Part IX Mining Process
  1) PoW miner broadcasts message0={work submission; Hash(Previous PoS Block), ,Hash (This PoW block) }
  2) Message is transmitted. Receivers verify
              a) work submission meets target. 
              b) Hash (Previous PoS Block) refers to the most recent PoS Block they have heard of.
              c) work submission Lottery Draw maps to 10 addresses in the database.
              d) They have not previously heard this message.  [Note that it is fine if multiple PoW Blocks circulate simultaneously]
              e) They have not heard an updated version of this message that includes one or more signatures.
              f)  If (a)-(e) are true, receivers relay the message.
   3) Key holder provides his mandatory signature and transmits the new message. message1={work submission; Hash(Previous PoS Block),Hash (This PoW block); Sig 1(message 0)  }
   4) Receivers verify
              a) work submission meets target. 
              b) Hash (Previous PoS Block) refers to the most recent PoS Block they have heard of.
              c) work submission Lottery Draw maps to 10 addresses in the database.
              d) They have not previously heard this message.  [Note that it is fine if multiple PoW Blocks circulate simultaneously]
              e) They have not heard an updated version of this message that includes more signatures.
              f)  The mandatory signatures are the correct ones as indicated by a hash of the work submission.
              g) If (a)-(f) are true, receivers relay the message.
     5) Go to 3 and repeat until all 5 signatures have been added {work submission; Hash(Previous PoS Block),Hash (This PoW block); Sig 1(message 0); Sig 2(message 1); Sig 3(message 2); Sig 4(message 3) ; Sig 5(message 4)}
     6) PoW miner receives all 5 signatures and broadcasts block together with signatures.
     7) 5th Signatory hears of broadcast PoW block. He then broadcasts his own block and signs Hash (PoS block, PoW block). The PoS block contains payments for all the mandatory PoS signatories.

Part X) Block Validation.
         i) All txns in block are valid. (e.g. standard blockchain checks + additional checks as described above)
        ii) Each blocks must build on the previous one. (can be done in the standard way whatever that is)
        iii) The PoW submissions maps to to 10 signatures in the database. [The database needs to be constructed as the blockchain is validated.]
        iv) The PoW block contains the correct Txn fee payments to the generation address.
         v) The PoS block contains the correct Txn fee payments to the five mandatory signatories.
        vi) The block is not over the block size limit.

            
Not sure what else I am missing. I am sure there is plenty.

[iddo]

       6a) Check if the address has received more than one coin, if so add the receiving public key to the database.

What if an address that controlled less than 1 coin received only a few satoshis in this txn, but those few satoshis now caused it to control more than 1 coin? You would have to calculate the balance of each address in each txn of each block?
What if some blacklisted address (that controlled more than 1 coin and didn't provide a heartbeat) transfers a few satoshis so that it now controls less than 1 coin, do you remove this address from the database? If the answer is yes, then this address could then receive a few satoshis in order to get back into the whitelist so that it'd un-blacklist itself? If the answer is no, then blacklisted addresses are kept in the database, implying that the total number of entries in the database can reach 2^256

[cunicula]

       6a) Check if the address has received more than one coin, if so add the receiving public key to the database.

What if an address that controlled less than 1 coin received only a few satoshis in this txn, but those few satoshis now caused it to control more than 1 coin? You would have to calculate the balance of each address in each txn of each block?

Then that address is not counted in the database. If the owner wants to get in the database, he should consolidate his small change and send 1 coin to a single address. He should do this because the database is a whitelist and inclusion has advantages. He will get taxed when he performs the consolidation. But once he gets in the database he can avoid taxation.

What if some blacklisted address (that controlled more than 1 coin and didn't provide a heartbeat) transfers a few satoshis so that it now controls less than 1 coin, do you remove this address from the database?

Yes

If the answer is yes, then this address could then receive a few satoshis in order to get back into the whitelist so that it'd un-blacklist itself?

The answer is yes. Not exactly. The address needs to receive a full coin to get back in the database and only that full coin will be counted. The remainder of the small change is not counted in the database. To get the small change counted, the owner needs to consolidate the change and send it to the database address. The change will get taxed when it gets consolidated.

The txn fee check is:

Txn Fee >= (Balance)*(exp(average input age in years*annual demurrage rate)-1) - "Balance"*(exp(Forgiven Coin-Age*annual demurrage fee)-1)

You can only forgive fees on coins starting from when they enter the database. We will always have:

Average input age in years >= Forgiven Coin-Age

This is true because your average input age accumulates based on the blockchain. The forgiven coin-age accumulates based on the database. The database undercounts your true inputs and the true age of these inputs. To start getting all your coins counted, you need to consolidate your coins and send them to the database address. There is no rescuing uncounted coins from taxation. Coins outside the database cannot avoid taxation.

This is kind of complicated. I need to go through it carefully. I suggest you hold off with questions until I have completely finished the previous post (i.e. ask questions tomorrow).

[iddo]

How about this: whenever an address receives at least one coin, we increment a counter that's stored at the database entry of this address, and whenever an address spends an input of at least one coin we decrement the counter. When the counter reaches zero we remove the address from the database. If the address failed to provide a heartbeat then it's kept in the database and marked as inactive. This way the total number of entries in the database is bounded by 21 million. All addresses that control at least one (consolidated) coin will be in the database.

To derive a lucky stakeholder, we cannot just select a random address uniformly from the database, because addresses that hold more coins should have higher probability to be selected. We can use follow-the-satoshi, and if the address that controls the satoshi isn't in the database (because it controls less than one consolidated coin) or is blacklisted then it's ineligible we derive the next pseudorandom satoshi, until reaching 3 eligible satoshis. The drawback is that stakeholders that control less than one (consolidated) coin don't participate in the lottery, so the reasons why heartbeats are useful should be persuading (both because of this drawback, and because of the added complexity). One unfortunate property that's implied by drawback is that fragmented dead coins won't be blacklisted, but there's probably not getting around that, because we cannot allow blacklisting each single satoshi without complexity blowup. Do you think that there is a better ways to derive the lucky stakeholder, instead of follow-the-satoshi?

The database can be virtual, i.e. it isn't important whether all the nodes have exactly the same database (e.g. the addresses don't have to be in the same order) or if they use another data structure to maintain this information. The protocol rule can simply specify that the if derived pseudorandom satoshi is ineligible (because the address didn't provide heartbeat or because the address doesn't control at least one consolidated coin) then it must not be used, so we hash and derive the next pseudorandom satoshi, until getting 3 eligible satoshis. The official client would probably create this database in order to verify the calculations, but everything that's stored in the database can be derived unambiguously from the blockchain. We rely on the assumption that >50% of the nodes are honest. There might be a risk that lazy nodes will prefer to skip the extra calculations and ignore the database, if the stakeholders' participation level is very high?

Maybe the one consolidated coin threshold should be dynamic? Meaning that if stakeholders participation is high then an address would need more than one consolidated coin in order to enter the database? I think that this would add significant complexities, and the benefits aren't so crucial (e.g. 2 million database entries instead of 21 million entries).

I'm not sure whether the extra heartbeats mechanism is superfluous, and instead we could simply say that an address in the database that didn't spend any of its coins in the last (say) 1000 blocks is blacklisted. What'd be the disadvantages of this approach?

[cunicula]

How about this: whenever an address receives at least one coin, we increment a counter that's stored at the database entry of this address, and whenever an address spends an input of at least one coin we decrement the counter. When the counter reaches zero we remove the address from the database. If the address failed to provide a heartbeat then it's kept in the database and marked as inactive. This way the total number of entries in the database is bounded by 21 million. All addresses that control at least one (consolidated) coin will be in the database.

That sounds quite simple and workable. But I'm not sure about whether it will work well with everything else.

To derive a lucky stakeholder, we cannot just select a random address uniformly from the database, because addresses that hold more coins should have higher probability to be selected. We can use follow-the-satoshi, and if the address that controls the satoshi isn't in the database (because it controls less than one consolidated coin) or is blacklisted then it's ineligible we derive the next pseudorandom satoshi, until reaching 3 eligible satoshis. The drawback is that stakeholders that control less than one (consolidated) coin don't participate in the lottery, so the reasons why heartbeats are useful should be persuading (both because of this drawback, and because of the added complexity). One unfortunate property that's implied by drawback is that fragmented dead coins won't be blacklisted, but there's probably not getting around that, because we cannot allow blacklisting each single satoshi without complexity blowup. Do you think that there is a better ways to derive the lucky stakeholder, instead of follow-the-satoshi?

The mechanism I wrote about above blacklists fragmented dead coins. (only stuff sent to your address with > 1 coin is in the database; and stuff outside the database can't win the lottery. See the long post from yesterday.

How will we know if a satoshi is in the database or not? As I understand it, we don't know all of the satoshis controlled by an individual public key. I'm concerned that your lottery will require broadcasting the difficulty targets of all PoW blocks found instead of just the difficulty targets of PoW blocks that are potential winners. The mechanism I suggested allows the PoW blocks to be pre-screened for eligibility. Most PoW blocks would probably be tossed immediately. This should greatly reduce the number of messages you would need to transmit.

The database can be virtual, i.e. it isn't important whether all the nodes have exactly the same database (e.g. the addresses don't have to be in the same order) or if they use another data structure to maintain this information. The protocol rule can simply specify that the if derived pseudorandom satoshi is ineligible (because the address didn't provide heartbeat or because the address doesn't control at least one consolidated coin) then it must not be used, so we hash and derive the next pseudorandom satoshi, until getting 3 eligible satoshis. The official client would probably create this database in order to verify the calculations, but everything that's stored in the database can be derived unambiguously from the blockchain. We rely on the assumption that >50% of the nodes are honest. There might be a risk that lazy nodes will prefer to skip the extra calculations and ignore the database, if the stakeholders' participation level is very high?

Why don't we just have an ordering rule? The ordering rule allows the lottery to be conducted based directly on the database. Also why not have the nodes actually construct an official database and use it to verify blocks? They don't need to verify the same blocks twice, so this would only be taxing during an initial download.
Verifying blocks as they appear should not be too difficult.

I'm not sure whether the extra heartbeats mechanism is superfluous, and instead we could simply say that an address in the database that didn't spend any of its coins in the last (say) 1000 blocks is blacklisted. What'd be the disadvantages of this approach?

Hmm... I don't think so. Every address in the database would have to spend coins at least once every 1000 blocks. That could be a lot of txns. If there are 21 million entries, then that is 21,000 txns per block. That seems like much too much bloat (currently blocks can't even fit that many). Another disadvantage is that people could just turn on their clients once per week to satisfy this. Only clients that are actually online are securing the network, so I'm not sure we should allow people to do that (at least without penalty). The heartbeat approach uses random auditing. You are fairly unlikely to get caught at any point in time, but if you don't have your client online all the time then you are screwed if you happen to get audited. I think that is a much stronger approach. It is also much less bloated.  

I don't think that heartbeats would be that difficult to implement. It is basically just a txn that you throw in a block on demand to say, "Yes, here, reporting for duty."

[iddo]

Hello cunicula,

To derive a lucky stakeholder, we cannot just select a random address uniformly from the database, because addresses that hold more coins should have higher probability to be selected. We can use follow-the-satoshi, and if the address that controls the satoshi isn't in the database (because it controls less than one consolidated coin) or is blacklisted then it's ineligible we derive the next pseudorandom satoshi, until reaching 3 eligible satoshis. The drawback is that stakeholders that control less than one (consolidated) coin don't participate in the lottery, so the reasons why heartbeats are useful should be persuading (both because of this drawback, and because of the added complexity). One unfortunate property that's implied by drawback is that fragmented dead coins won't be blacklisted, but there's probably not getting around that, because we cannot allow blacklisting each single satoshi without complexity blowup. Do you think that there is a better ways to derive the lucky stakeholder, instead of follow-the-satoshi?

The mechanism I wrote about above blacklists fragmented dead coins. (only stuff sent to your address with > 1 coin is in the database; and stuff outside the database can't win the lottery. See the long post from yesterday.

How will we know if a satoshi is in the database or not? As I understand it, we don't know all of the satoshis controlled by an individual public key. I'm concerned that your lottery will require broadcasting the difficulty targets of all PoW blocks found instead of just the difficulty targets of PoW blocks that are potential winners. The mechanism I suggested allows the PoW blocks to be pre-screened for eligibility. Most PoW blocks would probably be tossed immediately. This should greatly reduce the number of messages you would need to transmit.

Apologies, I was confused. Obviously what I suggested also blacklists fragmented dead coins because they're ineligible as I mentioned.

Also, what I suggested wouldn't broadcast ineligible PoW blocks, because all PoW blocks will be in fact eligible: if the first pseudorandom satoshi isn't eligible then the protocol says that it isn't used, and we look at the 2nd pseudorandom satoshi, and so on, until reaching 3 eligible satoshis, and those 3 satoshis are the ones that are derived from the PoW block (this procedure is unambiguous because all nodes that follow the protocol will have the same info/database at this block). An alternative approach is that if any of the first 3 pseudorandom satoshis isn't eligible then the PoW block is invalid, but also with this approach the PoW miner wouldn't need to broadcast his failed block to the rest of the network, so I don't understand what was your concern. The PoW difficulty will re-adjust accordingly if we use the 2nd approach, so I think that the 2nd approach is actually more efficient.

Looking at your post #140, you suggest to store the balances of all eligible addresses, pick random number smaller than this cumulative balance, and find the corresponding address. The end result is the same as with using follow-the-satoshi, but your post #140 is much more strict: all nodes must use exactly the same database at every block, and might need to maintain different continuations of the database in case of chain forks, i.e. it's a duplicative effort in addition to maintaining the blockchain. Supposedly you're trading space complexity for time complexity, but my guess is that using follow-the-satoshi is better overall, and it's more elegant.

BTW, there's also a positive aspect to the eligibility requirement of having at least one consolidated coin, because it encourages less blockchain fragmentation.

Hmm... I don't think so. Every address in the database would have to spend coins at least once every 1000 blocks. That could be a lot of txns. If there are 21 million entries, then that is 21,000 txns per block. That seems like much too much bloat (currently blocks can't even fit that many). Another disadvantage is that people could just turn on their clients once per week to satisfy this. Only clients that are actually online are securing the network, so I'm not sure we should allow people to do that (at least without penalty). The heartbeat approach uses random auditing. You are fairly unlikely to get caught at any point in time, but if you don't have your client online all the time then you are screwed if you happen to get audited. I think that is a much stronger approach. It is also much less bloated.  

I don't think that heartbeats would be that difficult to implement. It is basically just a txn that you throw in a block on demand to say, "Yes, here, reporting for duty."

I agree that heartbeats aren't that difficult to implement, but I don't see why you think that it's less bloated. Each heartbeat signature has to be stored in the blockchain, so storing such a signature is similar to storing a txn. One difference is that the txn could be some txn that the stakeholder wanted to do anyway, implying that the txns approach is less bloated.


I have a request: could you please summarize all the benefits that we'd get from heartbeats/blacklisting, i.e. benefits that we don't know how to get without blacklisting? I realize that you already mentioned it in various posts, but maybe your understanding has progressed a little since then, and anyway it'd be useful to have a clear summary in order to decide whether the complexities of blacklisting are something that's worth doing. Regarding which benefits you should focus on, my main concern is the incentive structure that'd imply high stakeholders' participation. I think that regarding a protocol with mandatory stakeholders' blocks, the main focus should be what I mentioned in post #135:

I wonder what'd the best way to devise an incentives structure that keeps the stakeholders' participation above some threshold (say 50% participation). We could split the newly minted coins of the PoW blocks with stakeholders blocks when we're below the threshold, but this doesn't specify what to do when block reward is based entirely on fees, assuming finite monetary inflation. Without a convincing incentives structure, mandatory lottery blocks would be a hard sell, meaning that people might be afraid that their txn will get stuck because of inactive stakeholders. From a purely theoretical perspective the situation isn't really different than pure-PoW, i.e. with pure-PoW their txn can also get stuck if all the miners are extremely unlucky and don't generate a block that meets the current difficulty, and similarly if we assume that stakeholders' participation is always above some threshold (because there's a re-adjusting incentive for stakeholders to participate), then deriving active stakeholders is similar to generating a regular PoW block.

Though we should also be concerned that the reward for stakeholders isn't excessive (the rich get richer, extreme example in post #129), as well as bribe attacks.

[cunicula]

Hi Iddo,

Blacklisting/heartbeats aren't really necessary. What blacklisting does is assure a minimum level of incentive for participation. (i.e. if you get blacklisted you lose say 5% *(years since last signature)*balance. Without blacklisting, then the incentives to participate come from fees. Fees probably need to be somewhat higher to make up for this. I'm not that worried about this though.

The difficulty of reversing txns is proportion to the amount of coins online, so we want to keep this relatively high (not necessarily huge). I would say 40-50% is a reasonable target.

Before I go through the rest of the post, could you do me a favor and respond to this post: https://bitcointalk.org/index.php?topic=127952.0
I'm trying to understand how what we are talking about differs from a full proof-of-stake system where there are a very large number of signatures per block. I don't think the large number of signatures is as big a problem as it has been made out to be. 

Our system here seems sort of similar now that we have a list with a large number of eligible signatories. I'm thinking the list could be narrowed down to a smaller number, so the sigs per block could be quite manageable even if everyone signs.

There seem to be pretty big advantages to using a majority mass of signatures for each block without any randomization (eg. quicker txns, cheaper txns, simpler code).

You also wouldn't really need many incentives if the consensus group was limited to large holders. These guys will earn enough off small fees to make running a node worthwhile. The incentive of making sure the system operates would probably be enough.

[iddo]

Hello cunicula,

Blacklisting/heartbeats aren't really necessary. What blacklisting does is assure a minimum level of incentive for participation. (i.e. if you get blacklisted you lose say 5% *(years since last signature)*balance. Without blacklisting, then the incentives to participate come from fees. Fees probably need to be somewhat higher to make up for this. I'm not that worried about this though.

There could be rational/malicious stakeholders who always provide the voluntary signatures to avoid the demurrage fee, but would be less willing to provide the mandatory signatures. To measure the participation level of a particular stakeholder we have to use voluntary signatures, because mandatory signatures that he failed to provide won't be recorded anywhere. Therefore the benefits of blacklisting become less straightforward, even if we do the lottery only among stakeholders who provided a heartbeat (whitelist). In other words, the voluntary signatures indeed force the stakeholder to maintain a full node that's always online, but it doesn't force the stakeholder to participate in generating mandatory blocks. So we overcome the concern of "lazy" stakeholders who aren't online, but not the concern of rational/malicious stakeholders who attempt to enrich themselves by denying service until their demands are met. Assuming that the would-be lazy stakeholders are honest (i.e. accept the recommended fee price as specified by the protocol), the voluntary signatures will push the fees downwards (compared to non-blacklisting protocol). But if the would-be lazy stakeholders are rational/malicious, the voluntary signatures wouldn't help in this regard.

Regarding the simple non-blacklisting protocol. Suppose that every (say) 5th block is the PoW block that derives the winning stakeholders who should create their mandatory block, and at the end of the difficulty retarget window we measure two difficulties: the regular pure-PoW difficulty, and the difficulty of the special 5th PoW blocks (by summing up the time differences between every 5th and 7th blocks in the retarget window, where the 6th block is the stakeholders block). Now we can have a separate difficulty re-adjustment for the special 5th blocks, which means that if too many stakeholders are greedy/malicious and deny service until their demands are met, then at the next retarget window it would be easier for the miners to generate the 5th PoW block, so more potential stakeholders would get a chance to participate (by re-solving the block when there aren't willing stakeholders available), which will hopefully push the stakeholders' fees downward toward the recommended fee that's used by honest clients?

Edit: The alternative is to have only PoW blocks that derive winning stakeholders (your post #134). Then there'd be only one re-adjusted difficulty that takes into account both the PoW hashrate and the stakeholders' participation level. This should also work in this regard, it just maximizes the reliance on stakeholders, so it has other implications. BTW, the protocol should probably split the txn fees between the PoW block that derives the winning stakeholders and the following stakeholders block, because near-instant stakeholders blocks wouldn't have many txns. If it's a protocol with 3 winning stakeholders, then it could specify that only the 3rd stakeholder includes txns in their block.

What about you idea of using mandatory fixed fees, say 0.1% fees? We could re-adjust the mandatory fixed fee at the next retarget window for example according to total txn volume (fewer total number of txns imply that we need higher fixed fee) ? This way it'd be futile for stakeholders (and miners) to demand higher fees, they could only refuse to generate blocks while not enough (high-paying) txns were broadcast. I think that you mentioned this idea in relation to bribe attacks?

[cunicula]

Hello cunicula,

Blacklisting/heartbeats aren't really necessary. What blacklisting does is assure a minimum level of incentive for participation. (i.e. if you get blacklisted you lose say 5% *(years since last signature)*balance. Without blacklisting, then the incentives to participate come from fees. Fees probably need to be somewhat higher to make up for this. I'm not that worried about this though.

There could be rational/malicious stakeholders who always provide the voluntary signatures to avoid the demurrage fee, but would be less willing to provide the mandatory signatures. To measure the participation level of a particular stakeholder we have to use voluntary signatures, because mandatory signatures that he failed to provide won't be recorded anywhere. Therefore the benefits of blacklisting become less straightforward, even if we do the lottery only among stakeholders who provided a heartbeat (whitelist). In other words, the voluntary signatures indeed force the stakeholder to maintain a full node that's always online, but it doesn't force the stakeholder to participate in generating mandatory blocks. So we overcome the concern of "lazy" stakeholders who aren't online, but not the concern of rational/malicious stakeholders who attempt to enrich themselves by denying service until their demands are met. Assuming that the would-be lazy stakeholders are honest (i.e. accept the recommended fee price as specified by the protocol), the voluntary signatures will push the fees downwards (compared to non-blacklisting protocol). But if the would-be lazy stakeholders are rational/malicious, the voluntary signatures wouldn't help in this regard.

Regarding the simple non-blacklisting protocol. Suppose that every (say) 5th block is the PoW block that derives the winning stakeholders who should create their mandatory block, and at the end of the difficulty retarget window we measure two difficulties: the regular pure-PoW difficulty, and the difficulty of the special 5th PoW blocks (by summing up the time differences between every 5th and 7th blocks in the retarget window, where the 6th block is the stakeholders block). Now we can have a separate difficulty re-adjustment for the special 5th blocks, which means that if too many stakeholders are greedy/malicious and deny service until their demands are met, then at the next retarget window it would be easier for the miners to generate the 5th PoW block, so more potential stakeholders would get a chance to participate (by re-solving the block when there aren't willing stakeholders available), which will hopefully push the stakeholders' fees downward toward the recommended fee that's used by honest clients?

What about you idea of using mandatory fixed fees, say 0.1% fees? We could re-adjust the mandatory fixed fee at the next retarget window for example according to total txn volume (fewer total number of txns imply that we need higher fixed fee) ? This way it'd be futile for stakeholders (and miners) to demand higher fees, they could only refuse to generate blocks while not enough (high-paying) txns were broadcast. I think that you mentioned this idea in relation to bribe attacks?

I don't think you have to worry about people providing voluntary signatures only. It doesn't make any sense as a rational strategy.

If you are trying to force higher fees on people, then you want to control txn inclusion in as many blocks as possible. To do this, you refuse to sign blocks unless you are the PoS miner. Say there are 5 signatures and the fifth signer mints a PoS block. You are the minter and you have 10% of active stake to work with. To control blocks, you veto anything that doesn't make you the block miner. The base probability you are the PoS minter is 10%. The proportion of blocks you can veto is 1-(9/10)^4=34%. There will still be the other 56% of blocks that get through. For these blocks you won't be able to control anything. Going the veto route raises your effective control of block content from 10% to 10%/(10%+56%) = 15%. This would be scary if veto's were costless. However exercising a veto means giving up rewards. Previously, you earned a reward from 41% of blocks. Now you will only earn a reward from 15%. To justify this, you need to have increased fees by 2.7-fold. However you have only decreased non-controlled block space by 34%. Whether this is worthwhile or not depends on the price-elasticity of demand (defined as % change in quantity / % change in price) http://en.wikipedia.org/wiki/Price_elasticity_of_demand). For the strategy to be worthwhile, we need a price-elasticity of greater than -34%/270% = -0.125. This is not plausible. Only very cheap essential goods like salt have this characteristic. I'm pretty sure people will give up coin txns before they give up salt.

If you own more than 10%, then the math will get less attractive. However, if you own a lot you also have to think about the asset value which we haven't factored in. Presumably if fees go up, then price goes down.

This also silly because it ignores the PoW blocks, which the big source of vulnerabilities. It will be a couple of orders of magnitude cheaper to manipulate these. For this reason, I think there should be equal proportions of the two blocks rather than more PoW blocks than PoS blocks. In fact, if you want to control everything, the best way to do it is just get a lot of hashing power, drive up PoW difficulty, and then only announce PoW lottery draws which make you the PoS minter. This doesn't allow you to double-spend, however, unless people react to it, it would allow you to monopolize all the blocks. With 10% stake, you would need 10-fold greater hashing power than the rest of the network to achieve this. If we want to prevent this, we have to have multiple PoS blocks for every lottery draw.

Note: Another option is to get rid of PoW entirely and use txns as a source of a random number generator. I discuss this here: https://bitcointalk.org/index.php?topic=127954.msg1369600#msg1369600 Of course you could still use PoW to hand out free coins.

[iddo]

Note: Another option is to get rid of PoW entirely and use txns as a source of a random number generator. I discuss this here: https://bitcointalk.org/index.php?topic=127954.msg1369600#msg1369600 Of course you could still use PoW to hand out free coins.

Looking at your post there:

5) With any given iteration there is a chance of moving to block t+1 and starting the process over again.

If I understand correctly, any txn (above threshold of 210 coins) modifies the hash and thereby derives new lucky stakeholders who may sign the block, who would thereby move the blockchain to the next block t+1. If that's the case, how is it different than PoW mining? Any "miner" with large computational power could just tweak some txn (that he sends to himself) until the block gets solved. Each tweak attempt derives new pseudorandom lucky stakeholders, so it's equivalent to PoW hash attempts (actually PoW hash attempts at an extremely low difficulty, because creating ECDSA signature for the txn can be done quickly, so the competing "miners" will cause huge network sync problems).

[cunicula]

Note: Another option is to get rid of PoW entirely and use txns as a source of a random number generator. I discuss this here: https://bitcointalk.org/index.php?topic=127954.msg1369600#msg1369600 Of course you could still use PoW to hand out free coins.

Looking at your post there:

5) With any given iteration there is a chance of moving to block t+1 and starting the process over again.

If I understand correctly, any txn (above threshold of 210 coins) modifies the hash and thereby derives new lucky stakeholders who may sign the block, who would thereby move the blockchain to the next block t+1. If that's the case, how is it different than PoW mining? Any "miner" with large computational power could just tweak some txn (that he sends to himself) until the block gets solved. Each tweak attempt derives new pseudorandom lucky stakeholders, so it's equivalent to PoW hash attempts (actually PoW hash attempts at an extremely low difficulty, because creating ECDSA signature for the txn can be done quickly, so the competing "miners" will cause huge network sync problems).

No, there is an unexpected twist. Any block of height t containing N txns maps to exactly the same satoshis. The lottery is deterministic rather than random. The only random element is who happens to have their computer online. We could predict who is going to mine in advance. This isn't necessary to think about, but in theory the whole mining process could be scheduled because of this.

However, once the block hash is signed by the first winner, then the block contents cannot be modified by the other winners. By default, the group is not supposed to sign more than one version of block t. They could cheat and sign a very large number of versions of block t with N txns.

Three cases if they cheat:
1) If one version has already been built upon and the other blocks are orphans, then keep building on the longest version.
2) You are aware of more than one version, but haven't seen any that have been built on. In this case, combine any two duplicate blocks t and mine a 'null block'. The record of the cheating is put in the blockchain. All txn for time t are ignored and you move on to block t+1.
3) You are only aware of one version. In this case try to build on it until you hear about another. (You don't know that cheating has occurred yet.)

[iddo]

No, there is an unexpected twist. Any block of height t containing N txns maps to exactly the same satoshis. The lottery is deterministic rather than random. The only random element is who happens to have their computer online. We could predict who is going to mine in advance. This isn't necessary to think about, but in theory the whole mining process could be scheduled because of this.

However, once the block hash is signed by the first winner, then the block contents cannot be modified by the other winners. By default, the group is not supposed to sign more than one version of block t. They could cheat and sign a very large number of versions of block t with N txns.

Three cases if they cheat:
1) If one version has already been built upon and the other blocks are orphans, then keep building on the longest version.
2) You are aware of more than one version, but haven't seen any that have been built on. In this case, combine any two duplicate blocks t and mine a 'null block'. The record of the cheating is put in the blockchain. All txn for time t are ignored and you move on to block t+1.
3) You are only aware of one version. In this case try to build on it until you hear about another. (You don't know that cheating has occurred yet.)

If it's deterministic given t and N, then rational/malicious stakeholders could collude in advance regarding future interval of the chain where they are the derived winning stakeholders for N=1, by preparing a secret branch of length (say) 6 blocks with N=1 in all the 6 blocks, and reveal this secret branch after the honest branch reaches 6 blocks in order to reverse some txn and double-spend.

[cunicula]

No, there is an unexpected twist. Any block of height t containing N txns maps to exactly the same satoshis. The lottery is deterministic rather than random. The only random element is who happens to have their computer online. We could predict who is going to mine in advance. This isn't necessary to think about, but in theory the whole mining process could be scheduled because of this.

However, once the block hash is signed by the first winner, then the block contents cannot be modified by the other winners. By default, the group is not supposed to sign more than one version of block t. They could cheat and sign a very large number of versions of block t with N txns.

Three cases if they cheat:
1) If one version has already been built upon and the other blocks are orphans, then keep building on the longest version.
2) You are aware of more than one version, but haven't seen any that have been built on. In this case, combine any two duplicate blocks t and mine a 'null block'. The record of the cheating is put in the blockchain. All txn for time t are ignored and you move on to block t+1.
3) You are only aware of one version. In this case try to build on it until you hear about another. (You don't know that cheating has occurred yet.)

If it's deterministic given t and N, then rational/malicious stakeholders could collude in advance regarding future interval of the chain where they are the derived winning stakeholders for N=1, by preparing a secret branch of length (say) 6 blocks with N=1 in all the 6 blocks, and reveal this secret branch after the honest branch reaches 6 blocks in order to reverse some txn and double-spend.

Yes, they could definitely do that. I'm not worried about it for the following reasons:
1) For 6 blocks, this is collusion involving 24 keys. You can't just need to find 24 random people. You need to convince 24 specific people to do this. Moreover, some of these people will likely have a nontrivial investment in the system. I think that organizing this collusion would be prohibitively difficult.
2) If it is not difficult or there is a lot of money involved you can just wait. Say we wait a full day's worth of 10 minute blocks, this is then a conspiracy involving 576 people. At some point (I think less than a day, but perhaps more than 6 blocks) this becomes ridiculous.
3) The profit here is just a simple double-spend. If this occurs at rare intervals I don't see that as a big problem. If a lot of money is involved, you can wait.   
4) In theory, everything the network does can be scheduled. I'm not sure exactly how it would end up working, but I'm sure this would allow for very quick block intervals. Say we have a 1 minute block interval. This would mean that 1 hour of collusion would require a conspiracy of 240 different people.

[iddo]

Yes, they could definitely do that. I'm not worried about it for the following reasons:
1) For 6 blocks, this is collusion involving 24 keys. You can't just need to find 24 random people. You need to convince 24 specific people to do this. Moreover, some of these people will likely have a nontrivial investment in the system. I think that organizing this collusion would be prohibitively difficult.
2) If it is not difficult or there is a lot of money involved you can just wait. Say we wait a full day's worth of 10 minute blocks, this is then a conspiracy involving 576 people. At some point (I think less than a day, but perhaps more than 6 blocks) this becomes ridiculous.
3) The profit here is just a simple double-spend. If this occurs at rare intervals I don't see that as a big problem. If a lot of money is involved, you can wait.  
4) In theory, everything the network does can be scheduled. I'm not sure exactly how it would end up working, but I'm sure this would allow for very quick block intervals. Say we have a 1 minute block interval. This would mean that 1 hour of collusion would require a conspiracy of 240 different people.

Actually, collusion between different people might not be needed. We can have one attacker with (say) 10% stake, so if 3 lucky stakeholders sign each block, the attacker can prepare in advance a secret branch for some future interval of the chain, by doing N=1,2,3... attempts for each block in his secret branch (i.e. create a block with N txns that he sends to himself), and on average each of his blocks will have N=1000 txns.

If it's for example 5 lucky stakeholders instead of 3, then the honest stakeholders' participation level should meet a higher bar as well, etc. Edit: raising the 210 coins threshold would make the attack more difficult, but would also make it harder for the honest network to increment t when the pseudorandom stakeholders aren't active. I don't think that deterministic derivation is a good idea. Having different pseudorandom stakeholders for each txn of at least (say) 210 coins, where each such txn derives other stakeholders when it is tweaked, is probably better.

If the secret branch is too far into the future then it decreases his chances, because follow-the-satoshi can pick a satoshi among satoshis that haven't been minted yet, so the 10% stake figure of the attacker decreases. Edit: this isn't helpful if it's a protocol with finite monetary inflation.

Even if the attacker would want to prepare a secret branch that's closer to the present  (rather than far into the future), my earlier comment about doing PoW-style mining still applies. It's just PoW attempts with N=1,2,3... instead of PoW attempts with a tweaked txn.

How new coins are minted is also still vague. For now all the pure-PoS protocols seem dubious to me, if you could refine one of your ideas into a workable pure-PoS protocol then it'd be very impressive. So far it seems that the mixed PoW+PoA (mandatory blocks lottery) is workable.

[cunicula]

Results depend a lot on the parameters. You only get an attractive outcome if you tweak things carefully. I am trying to think of something more robust. I'm going to be busy for the next 10 days or so, so don't expect much communication. I'll be back.

[iddo]

I don't think you have to worry about people providing voluntary signatures only. It doesn't make any sense as a rational strategy.

If you are trying to force higher fees on people, then you want to control txn inclusion in as many blocks as possible. To do this, you refuse to sign blocks unless you are the PoS miner. Say there are 5 signatures and the fifth signer mints a PoS block. You are the minter and you have 10% of active stake to work with. To control blocks, you veto anything that doesn't make you the block miner. The base probability you are the PoS minter is 10%. The proportion of blocks you can veto is 1-(9/10)^4=34%. There will still be the other 56% of blocks that get through. For these blocks you won't be able to control anything. Going the veto route raises your effective control of block content from 10% to 10%/(10%+56%) = 15%. This would be scary if veto's were costless. However exercising a veto means giving up rewards. Previously, you earned a reward from 41% of blocks. Now you will only earn a reward from 15%. To justify this, you need to have increased fees by 2.7-fold. However you have only decreased non-controlled block space by 34%. Whether this is worthwhile or not depends on the price-elasticity of demand (defined as % change in quantity / % change in price) http://en.wikipedia.org/wiki/Price_elasticity_of_demand). For the strategy to be worthwhile, we need a price-elasticity of greater than -34%/270% = -0.125. This is not plausible. Only very cheap essential goods like salt have this characteristic. I'm pretty sure people will give up coin txns before they give up salt.

If you own more than 10%, then the math will get less attractive. However, if you own a lot you also have to think about the asset value which we haven't factored in. Presumably if fees go up, then price goes down.

Intriguing argument, though I don't claim to know enough about microeconomics to fully evaluate it.

The two issues were (1) should we incentivize stakeholders to maintain full nodes by penalizing them with demurrage fees, which involves the complex mechanism of blacklisting and voluntary signatures, or just letting stakeholders collect fees for the work that they do is enough, and (2) whether the protocol should enforce rules that prevent or disincentivize stakeholders from attempting to collect too high fees and thereby exceedingly enrich themselves.

Earlier I was a little concerned about letting stakeholders collect fees, as opposed to letting miners collect fees, because the work that the stakeholders have to do in order to enrich themselves is costless, while the work that the miners do is costly. However, another aspect of this is that active stakeholders have to maintain full nodes, which is useful in preventing network attacks on the cryptocurrency (mentioned for example here).

You claim that we shouldn't worry about (2), so the simplest option is to allow competition by having the miners re-solve the block, and additionally if a substantial enough amount of stakeholders are honest and calculate the fees via the recommended client rules (like the reference Bitcoin client) then hopefully the price of the fees will be pushed towards that target, because of the competition.
I still wonder about ideas for collective punishment to stakeholders if their fees are excessive, especially ideas that don't involve infinite monetary inflation. Maybe mandatory caps on the fees that are enforced by the protocol are also possible. For now I tend to agree that the simplest option is best.

About (1), if we take the complex route then I think that my suggestion of protocol rule that says that only addresses that control 1 (or 10, or 100, ...) consolidated coin(s) and aren't blacklisted are eligible for the lottery, so using a database would be just one possible implementation. You haven't replied yet to post #145 about storing heartbeats versus storing txns in the blockchain ("txns approach is less bloated" ?), if you think that we'd need to store many heartbeat signatures in order to take advantage of blacklisting, then this becomes even more burdensome. So far I still favor the simple approach of having only mandatory signatures.

It could make sense to allow all the (say 3) lucky stakeholders to include txns in their block, otherwise an attacker who tries to generate empty blocks will have an advantage.

I tend to agree with your post #134 (and with coblee) about having only one kind of block. The PoW difficulty could re-adjust simply by taking the time difference (as Bitcoin does), meaning that the re-adjustment is affected both by total hashpower and by stakeholders' participation level, and we cannot measure each individually. I think that each block should be created by one miner and three stakeholders, the monetary inflation reward should go only to the miner, and the fees should be divvied up between the miner and the 3 stakeholders (1/4 to each). Regarding who may include txns in the block, it should either be all 4 of them, or just the miner and the 3rd stakeholder, or just the 3rd stakeholder. It's a tradeoff between the amount of msgs that have to be sent over the network, and security against the empty blocks attack. Edit: maybe it's better that only the 3rd stakeholder includes the txns, otherwise it would be problematic to make sure that same/conflicting txns aren't added by the others, without sending large msgs over the network.

We should still discuss signing-key/limited-withdrawal delegation, I tried to initiate the discussion in post #112

[iddo]

BTW, just to give a few concrete numbers that compare our PoA protocol with Bitcoin's pure-PoW (assuming 3 pseudorandom stakeholders):

An attacker with 1/10 of the active stake will have an advantage over the honest network if he has x1300 x729 times more hashpower, i.e. about 99.8% of the total hashpower (see post #167 in this thread).

An attacker with 1/3 of the active stake will need about 88% of the total hashpower.

Obviously, an attacker with 1/2 of the active stake will need 50% of the total hashpower to get an advantage over the honest network. In other words, with pure-PoW an attacker with >50% of the total hashpower can carry out double-spending and empty-blocks attacks while having an advantage over the honest network, and with this PoA variant the attacker would also need 50% of the active stake in addition to his 50% hashpower.

Edit: fixed the numbers, see section 6 of the pdf in post #167 for further analysis/numbers.

[iddo]

Two ideas:

1) We could try to introduce competition between miners and stakeholders with regard to txn fees. There would be 2 types of txns, one which can only be included by miners, and another than can only be included by stakeholders. This also takes care of the issue of conflicting/same txns included by both the miner and the 3rd stakeholder. The default behavior of the reference client is to use the same exact fee for both miners and stakeholders, and choose the type randomly, so on average half of the txns will be included by miners and half by stakeholders. Only the miners collect the fees of the first type, and only the stakeholders collect the fees of the second type. The focus here is on the situation after the monetary inflation ended, I still think that the reward subsidy should go only to miners. If stakeholders attempt to collect excessive fees, then the users will opt to create txns of the type that can only be included by miners, and if the miners attempt to collect excessive fees then the users will opt to create txns of the type that can only be included by stakeholders. Thoughts?
Edit: it isn't so clear if it takes care of conflicting/same txns included by both the miner and the 3rd stakeholder, because a malicious user could broadcast txns of both types in order to bloat the block, but then the block will contain the incriminating evidence against him. We could have protocol rule to take care of it, but we should be careful not to allow other malicious users to hurt a user by re-broadcasting his old txn of conflicting type. From security and efficiency standpoints I suppose that letting only the 3rd stakeholder include txns is the better option, so the question is whether this idea has economic benefits.

2) Regarding voluntary signatures: since blacklisting is complex, how about that instead of penalizing the inactive address by blacklisting it, we will penalize the inactive address by confiscating (some fraction of) its coins? The substantive distinction in terms of complexity is that the blacklist penalty is something that should be examined in each successful hash attempt as we derive pseudorandom addresses via follow-the-satoshi, and the coin loss penalty is something that should be examined much less frequently using the already existing infrastructure (i.e. only when validating txn that involves those coins). Everything else should be similar, the block hash derives a voluntary pseudorandom address that should provide its signature in the next X blocks (possibly by doing a txn). If we wish to use this method revive dead coins which would be distributed among those who solve future blocks, then we must be careful that there wouldn't be incentives for miners/stakeholders not to relay the voluntary signature of the unlucky stakeholder in order for them to collect his confiscated coins. Thoughts?

[iddo]

Let me specify the best PoA protocol that cunicula and I came up with so far, because we started discussing it around post #97 and it's better to have a full description in a single post here:

1) The miners try to generate an empty block (i.e. a block without any txns, that contains the hash of the previous block, the pubkey address of the miner, and a nonce) according to the current PoW difficulty.

2) When a miner succeeds in generating such an empty block (meaning that the hash of the hash of his block + nonce meets the current difficulty), he broadcasts his empty block to the network.

3) The protocol specifies how the hash of his block derives 3 pseudorandom numbers (e.g. concatenate the block hash with 3 fixed values and hash it), that are used to derive 3 lucky stakeholders via follow-the-satoshi (for a description of follow-the-satoshi see the OP and the discussion between coblee and Meni in the first page of this thread), therefore all the nodes that follow the protocol can compute on their own these 3 lucky stakeholders.

4) Each stakeholder who is online checks whether the miner's block is valid (i.e. contains the hash of the previous block, and meets the current difficulty), and whether he is one of the 3 lucky stakeholders of the block that the miner broadcasted. When the first two lucky stakeholders discover that the block derives them, they sign the hash of the block with the privkey that controls their derived satoshi, and broadcast their signature to the network. When the 3rd stakeholder sees that the block derives him, he creates a wrapped block that extends the miner's block by including as many txns as he wishes to include, the two signatures of the first two lucky stakeholder, and his own signature for the hash of the entire wrapped block.

5) The 3rd stakeholder broadcasts the wrapped block to the network, and when the other nodes see that this wrapped block is valid according to the above, they consider it a legitimate extension of the blockchain and move on to continue to extend the blockchain from this wrapped block.

6) The fees from the txns that the 3rd miner collected are divvied up between the miner and the 3 lucky stakeholders (for example 1/4 to each, or 1/2,1/4,1/8,1/8), while the reward subsidy (monetary inflation) goes mostly/only to the miner. Having finite monetary inflation (for example 21 million coins) should be good with this protocol.

If some of those 3 lucky stakeholders were offline, then other miners will also generate the block and thereby derive 3 other pseudorandom stakeholders, so the overall difficulty will re-adjust both according to the total hashpower and according to what fraction of all the stakeholders is online.

The basic security analysis that compares this protocol with Bitcoin is described two posts above (post #156). This protocol offers good security against an attacker who invests in hashpower and tries to double-spend (see e.g. post #133 regarding killerstorm's double-spending bribes service idea), or tries to deny service by generating empty blocks in order to blackmail or destroy the network. It is also very helpful in preventing network attacks, because stakeholders are incentivized to maintain full nodes. Furthermore, it decentralizes the power that generates the blocks, unless most of the coins are held by a few people etc. The argument here is that it should make sense to vest this power in the hands of stakeholders, because they have an interest to maintain the value of their stake by keeping the cryptocurrency secure.

Edit: I'll also mention here why this protocol is better than our other ideas. To be protected from an attacker with huge hashpower who wishes to destroy/blackmail the network by denying txns (for the rationale cf. posts #97 and #100), we could have a protocol rule that requires (in its simplest variation) at least X amount of BDD in each block, but this would imply: (1) X has to be a significant amount, otherwise the attacker could create blocks with txns in which he always just transfers small amounts of coins among his own addresses, therefore (2) if it's a slow day and you wish to send some small amount of coins, you might have to wait for a long time until X BDD is reached, in other words we'd lose the predictability of 10min blocks, and more importantly (3) if the cryptocurrency's economy grows to (say) 1000*X BDD in each block on average, then the attacker could carry out his attack by creating blocks with only X BDD in them, and thereby harm/blackmail/destroy the network, etc. With the PoA protocol described here, we avoid these drawbacks in an elegant way, namely by letting a pseudorandom stakeholder create the block. Also, regarding double-spending attacks, the previous protocol (simple-PoA) wasn't secure against an attacker with more than 66% of the total hashpower and zero stake, assuming 50% stakeholders' participation level (see e.g. post #78), while this PoA protocol is secure even against an attacker with more than 90% of the total hashpower and 20% of the total stake, assuming 50% stakeholders' participation level: (1-2/10)/2 = 2 * 2/10, meaning that the attacker has 1/3 of the active stake and therefore he needs to be 9.5 times faster (see post #156).

Thoughts please?

[killerstorm]

Your analysis ignores the fact that some of stakeholders won't be online/active.

Suppose 50% of stake is online. (Which is optimistic, I'd say.)

Attacker who owns 33% of coins can pwn the network: with 17% leftover stake they have enough signatures for 0.49%  of blocks. (0.17^3). While attacker is successful for 3.7% of blocks. So basically he can win with only 11% of hashing power.

Don't forget that attackers are likely more organized than average stakeholders.

And don't forget that one can DDoS largest stakeholders.

[iddo]

Your analysis ignores the fact that some of stakeholders won't be online/active.

Suppose 50% of stake is online. (Which is optimistic, I'd say.)

Attacker who owns 33% of coins can pwn the network: with 17% leftover stake they have enough signatures for 0.49%  of blocks. (0.17^3). While attacker is successful for 3.7% of blocks. So basically he can win with only 11% of hashing power.

Don't forget that attackers are likely more organized than average stakeholders.

And don't forget that one can DDoS largest stakeholders.

I didn't ignore that fact, I used the terminology "active stake" to refer to stakeholders who are online. Apologies that I wasn't clear enough.
Using the same terminology of post #156, you describe a scenario where the attacker has 33/50 = 66% of the active stake, while the honest network has 17/50 = 34% of the active stake. Obviously, if the attacker has the majority of the active stake then this protocol becomes much less secure than Bitcoin's pure-PoW.

Edit: Also, I'm not sure whether the scenario that you were thinking of fits the numbers that you mentioned.  If we assume that the txn fees and signing-key limited-withdrawal delegation incentivize say 50% participation level of the honest stakeholders, and the attacker has 33% of the total stake, then the total honest stake is 66% which means that the active+honest stake is 33%, so the attacker still doesn't have an advantage over the honest network (unless he has >50% hashpower). In other words, the attacker would need more than 1/3 of the total stake in order to gain an advantage, assuming 50% participation level.

See for example cunicula's post #81 for the rationale behind our assumptions, I'll quote it here:

I think you need to prepare for an environment where the total network has only 30 Gigahashes and contains $100 million USD. That is what the network will look like without block reward. The numbers might not be quite good enough for this situation.

I wouldn't worry about double spends coming from someone with USD$20 million of bitcoin. He will be scrambling to keep the network secure and his fortune safe. Only an idiot would try to double spend from this position.

Worry about someone who owns 300 Gigahashes double-spending. 300 gigahashes costs less than $0.5 million USD to acquire. This is far less than the $20 million necessary for stake.

Moreover, the GPUs might retain significant resale value in the event of a devastating successful attack. The bitcoin would not.

[killerstorm]

I didn't ignore that fact, I used the terminology "active stake" to refer to stakeholders who are online. Apologies that I wasn't clear enough.
Using the same terminology of post #156, you describe a scenario where the attacker has 33/50 = 66% of the active stake, while the honest network has 17/50 = 34% of the active stake. Obviously, if the attacker has the majority of the active stake then this protocol becomes much less secure than Bitcoin's pure-PoW.

Yup. The problem is that amount of active stake might vary greatly, so attacker having minority of total coins might have a majority of active stake at some point.

Edit: Also, I'm not sure whether the scenario that you were thinking of fits the numbers that you mentioned.  If we assume that the txn fees and signing-key limited-withdrawal delegation incentivize say 50% participation level of the honest stakeholders, and the attacker has 33% of the total stake, then the total honest stake is 66% which means that the active+honest stake is 33%, so the attacker still doesn't have an advantage over the honest network (unless he has >50% hashpower). In other words, the attacker would need more than 1/3 of the total stake in order to gain an advantage, assuming 50% participation level.

Ah, OK.

I wouldn't worry about double spends coming from someone with USD$20 million of bitcoin. He will be scrambling to keep the network secure and his fortune safe. Only an idiot would try to double spend from this position.

Well, I dunno... What if he borrows bitcoins to short them? Or rents the stake?

Suppose I have a lot of USD. I would try to borrow or rent as much BTC as possible (I have a lot of collateral and can offer all sorts of legal protections), do some double-spends. Then sell BTC.

Exchange rate plummets from panic and perceived lack of security. I buy bitcoins back at low price. and return them.

[cbeast]

For a long time I was considering a way to "balance" Proof-of-Work. I was trying to work out a way to offer some way to reward "loyal" Bitcoin network supporters on a merit system. The ideas keep coming back to something akin to a proof-of-stake, which I reject wholeheartedly. It all comes down to the nature of competition. Then I realized I was looking at it all wrong. This isn't a game like checkers or rock-scissors-paper, Bitcoin is chess. The Bitcoin Network is merely the board. The pieces are the physical and virtual connectors on the network itself. Miners are merely pieces. The whole damn thing is just too complex for anyone to solve for a simple solution.

The nature of competition is not just to be bigger, faster, and stronger. It's to be smarter and more adaptable. Anyone who thinks they have it all figured out is fooling themselves. I think that's what the math is saying when Satoshi chose the protocols that went into Bitcoin. You can't beat all the other players, because the protocol has enough flexibility to adapt to any game anyone tries to play against it. The difficulty factor, the ten minute propagation, the inflation rate, etc. all make Bitcoin a very difficult system to game as it scales. Other players will see moves coming and have time to make counter moves to protect their own interests. Changing the protocol to be anything other than being open for competition from anyone would be like poisoning your own watering hole just to kill your rival.

[iddo]

cunicula, when you're back, please take a look in particular at post #157, and killerstorm's post #161

I updated post #158 with some more info regarding our best PoA protocol so far.
More peer review please? Anyone?

[iddo]

About reviving lost coins: cunicula said that one of the features of voluntary PoA signatures is that it provides a useful mechanism to revive dead coins, but I suspect that a similar mechanism of equivalent usefulness could be easily achieved with pure-PoW. I realize that it's arguable whether reviving dead coins is a desirable property, and that there have been several threads about it here in the past (BTW what's the best thread to look at?).
Here is another idea on how to do it with Bitcoin's pure-PoW: a special "bet" txn could be added to the protocol, where you can spend (for example) X/10 coins to bet that an address that holds X coins is dead. During the next Y blocks, those X/10 coins are locked. If that address with X coins didn't move its coins within Y blocks, then you receive those X coins. If that address moved its coins within Y blocks, then that address receives your X/10 coins. The client software could notify users that a bet against their address took place, and/or if it's a "saving account" address that isn't online then you could register on websites (e.g. online wallet websites) to get email notification when a bet against you took place.
I think that the main negative implication of this idea is that a thief wouldn't need to actually obtain your privkeys, but instead it'd be enough for the thief to somehow destroy your privkeys, and then bet against you. Also, if someone has inside knowledge that you wouldn't be around for the next Y blocks, then he could steal your coins.
So instead of having to spend X/10 coins to place the bet, the protocol could specify that you may place the bet for a small fee, and you'd only receive twice the fee's amount if you win, and the rest of the X coins would be spread among the miners over a long time frame (for example X/1000 added to the block reward in the next 1000 blocks). If the address that you bet against did move its coins, then it receives your fee. In other words, if you lose your privkey/wallet that controls X coins, you couldn't get those coins back, but there wouldn't be monetary deflation.

[iddo]

I didn't ignore that fact, I used the terminology "active stake" to refer to stakeholders who are online. Apologies that I wasn't clear enough.
Using the same terminology of post #156, you describe a scenario where the attacker has 33/50 = 66% of the active stake, while the honest network has 17/50 = 34% of the active stake. Obviously, if the attacker has the majority of the active stake then this protocol becomes much less secure than Bitcoin's pure-PoW.

Yup. The problem is that amount of active stake might vary greatly, so attacker having minority of total coins might have a majority of active stake at some point.

It could be helpful to consider why this isn't a concern with Bitcoin's pure-PoW: suppose an attacker has e.g. 100 gigahash/s while the honest network has e.g. 20 terahash/s, would it be reasonable to say that the honest hashpower might vary greatly so the attacker's 100 gigahash/s might become a majority at some point? I suppose that we agree that it's unreasonable to say that, because the miners have a financial incentive to participate in the network (in the form of the block reward and fees). Note that miners who immediately exchange the coins that they mine for fiat currency don't have an incentive to secure the network.
Similarly, if the financial incentive for stakeholders is big enough, then it would also unreasonable to say that the honest+active stake might vary greatly so the attacker might gain a majority of the active stake. The problem is that if the protocol rewards the stakeholders too much, then it'd result in a situation where the rich get richer, so we have to strike a balance between the desired stakeholders' participation level and the stakeholders' reward. I think that after the monetary inflation ends (or becomes insignificant in comparison to txn fees), it's straightforward to accomplish this balance by giving e.g. 1/2 of the fees to the miners and 1/2 of the fees to the stakeholders, but it's unclear to me how to achieve this balance while the block reward subsidy is still significant. Also note that it's reasonable to assume that stakeholders have a greater incentive to secure the network than miners, so this also contributes to the overall stakeholders' participation level.

I wouldn't worry about double spends coming from someone with USD$20 million of bitcoin. He will be scrambling to keep the network secure and his fortune safe. Only an idiot would try to double spend from this position.

Well, I dunno... What if he borrows bitcoins to short them? Or rents the stake?

Suppose I have a lot of USD. I would try to borrow or rent as much BTC as possible (I have a lot of collateral and can offer all sorts of legal protections), do some double-spends. Then sell BTC.

Exchange rate plummets from panic and perceived lack of security. I buy bitcoins back at low price. and return them.

I hope that cunicula would respond soon. Let me just remark that I think that there's a significant difference between the total amount coins that were generated, and the amount of coins that can be bought at the exchanges. So if the attack requires millions of coins (for example 20% of the total stake, see post #158), then we're good.

[iddo]

Another idea: the lucky stakeholder who creates the block is allowed to also include in it (in addition to the regular txns) all the other empty blocks that the miners broadcasted, i.e. empty blocks that extend the previous block but don't derive him as the lucky stakeholder. Note that an empty block for this purpose is actually just the pair (pubkey_addr, nonce) and we verify its validity by hash(nonce+hash(prev_block_hash, pubkey_addr)), so this idea doesn't bloat the blockchain too much. The benefit of this idea is that now at the difficulty retarget window we can measure the stakeholders' participation level by summing up the amount of all the empty blocks that were created since the last difficulty retarget. This way we could increase the relative reward of the stakeholders if their participation level is too low. Assuming 50% stakeholders' participation level, with 3 pseudorandom stakeholders we expect the stakeholder who creates the block to include 7 other empty blocks, therefore if we see at the retarget window that more than 7 empty blocks were added on average, then the stakeholders' participation level is less than 50%, so the protocol could specify that a higher ratio of the reward goes to the stakeholders relative to the miners during the next retarget window. This should incentivize the network to always converge to at least 50% stakeholders' participation level. If for example it's a protocol where there is 1 pseudorandom stakeholder instead of 3 that are derived for each mined block, then on average we expect 1 additional empty block to be included in each block (assuming 50% stakeholders' participation level), so again we could retarget the incentive of the stakeholders accordingly. Maybe the stakeholder who creates the block should receive a small reward for including those extra empty blocks, again as a higher ratio of the total reward relative to the miner who solved that block, in order to incentivize the stakeholders to add the extra empty blocks. Or maybe not, if the higher reward to all the stakeholders at the next difficulty retarget window is enough of an incentive.

Unrelated note: if we implement this PoA protocol in Litecoin then we'd probably need to go with the simplified variation that derives only 1 pseudorandom stakeholder (instead of 3), otherwise in order to get 2.5 minutes blocks we will need the miners to solve and broadcast a block after 150/8 = 18.75 seconds on average, assuming 50% stakeholders' participation level, and that would probably be too burdensome on the network.

[iddo]

PoA academic paper is now public:
http://eprint.iacr.org/2014/452
It was accepted to NetEcon/SIGMETRICS workshop:
http://www.eurecom.fr/~loiseau/W-PIN+NetEcon2014/program.html
Given that Charles Lee came up with the original core idea of PoA and helped with our further improvements, he encouraged me to try to implement PoA on a Litecoin testnet (separate from the testnet of the reference Litecoin client), and I'm interested in the Litecoin community reaction towards incorporating PoA into Litecoin.
In the paper we have some C++ and Python code for benchmarks, and I now plan the more efficient/complete implementation (with PoA protocol parameter N=1). If you're a programmer who'd like to join this effort then email me.
However, forking to obtain controversial goals (as opposed to benign softforks like BIP16) is risky, so it should only be done if needed for actual security improvements (regarding this, see in particular section 2.1 of the PoA paper). When our testnet implementation is ready, we will analyse and re-evaluate whether adding PoA to Litecoin makes sense.

Edit: presentation slides at http://www.cs.technion.ac.il/~idddo/PoAslides.pdf

[coinxed]

I like the idea of probabilistic PoS. I think the motivating problem is exaggerated but this could have other advantages too.

Another way (not sure if easier are harder to calculate) is to have the mod of the previous block hash deterministically pinpoint a single satoshi from a coinbase transaction. Then follow that satoshi as it travels from transaction to transaction until it reaches an unspent output. Then that output address will be selected as the next stakeholder. You can do this deterministically. Since the initial satoshi picked from a coinbase output is evenly distributed, the eventual selection will be evenly distributed also. I can explain more if people are interested in how this will work.

I don't think satoshis are tracked the way you think they do. If there's a 50 BTC coinbase which is split to two addresses you can't say "this satoshi went to output A and this satoshi went to output B". Not a major problem though, if you agree on a randomness seed (deterministically from the blockchain) you can simply trace the chain forward, in each step choosing a random output weighted by number of coins.

Satoshis are not tracked that way, but you could track it that way. You just need a deterministic way to do it. So just map every satoshi in the input to a satoshi in the output using an ordered 1 to 1 mapping. So for example, if you are looking at a transaction with an input of 50 BTC and 2 outputs of 25 BTC each and you are tracking the a satoshi that is located at 26.11111111 of 50 BTC, then you would follow the 1.11111111 satoshi in the 2nd output. Does that make sense?

Yes, you could do that. You need to be very careful though not only with the order of inputs and outputs, but also with the order of transactions in a block since the satoshi can end up as a tx fee.

Essentially this is equivalent to how I suggested to look at it.

There is a standard ordering of transactions in blocks, right? If not, having it alphabetized by address is fine. As long as all the nodes use the same deterministic way, we are good. Satoshi ending up as a fee is fully supported. Since those will just be sent to the miner's block reward and it can continue follow the path.

The only catch is it's possible for a miner to destroy coins by not redeeming the full 50 btc in the coinbase. When that happens to our tracked satoshi, maybe we decide that there's no stakeholder for the next block.

is it's possible for a miner to destroy coins by not redeeming the full 50 btc in the coinbase. When that happens to our tracked satoshi, maybe we decide that there's no

 for a miner to destroy coins by not redeeming the full 50 btc in the coinbase. When that happens to our tracked satoshi, maybe we decide that

 to destroy coins by not redeeming the full 50 btc in the coinbase. When that happens to our tracked satoshi, maybe we

 by not redeeming the full 50 btc in the coinbase. When that happens to our tracked satoshi,

 the full 50 btc in the coinbase. When that happens to our

 btc in the coinbase. When that happens

 the coinbase. When

 coinbase.

coinbase
coinbase
COINBASE
COINBASE!!!!
!!!!!COINBASE!!!!

[bitcad4u]

If this PoA is a solution to the 51% attack and IF litecoin forked to implement such a solution... I could see litecoin prices hovering back in the 50-100 dollar range.... we need to INVENT -and stop following bitcoin.  The next gen coins (like NXT) are all ranking up the charts because they are offering something NEW and not just being a faster BTC clone.

Do it coblee!


and lol @ post above - coinbase  when indeed

[instagibbs]

What happens if the N PoS "miners" aren't online? That seems quite likely very often.

[killerstorm]

What happens if the N PoS "miners" aren't online? That seems quite likely very often.

Let's say N=3 and only 10% of all stake is online. Suppose our target is to generate 1 block in 10 minutes on average.

Then PoW miners need to generate 1000 valid block headers in 10 minutes. Then, statistically, one of block headers will have all 3 stakeholders online.

So, basically, N=3 and 10% of active stake corresponds to 1000 times lower PoW difficulty.

[coinsolidation]

If there is no merkle tree in the blockheader, does that not leave it open to transactions being removed / replaced /  double spent?

[Meni Rosenfeld]

If there is no merkle tree in the blockheader, does that not leave it open to transactions being removed / replaced /  double spent?

The initial empty block header doesn't reference any transactions. The Nth stakeholder (derived by the empty header's work) adds the transactions, and a Merkle root to match.

[Gyrsur]

found the news about PoA by accident.

[iddo]

About the weird post above by coinxed: coins can be destroyed by not redeeming the entire coinbase, and also by sending an unspent output to (non-P2SH) script that always returns false. Some relevant info is discussed in this thread (e.g. post #164), and in footnote 9 in the paper (post #167) etc.

What happens if the N PoS "miners" aren't online? That seems quite likely very often.

The reason why you aren't worried that all the PoW miners will go offline is that they're rewarded for their work. Similarly, if stakeholders are rewarded, then we can expect some fraction of them to be online. In section 3.2.1 of the paper we describe how to incentivize a target participation level of the online stake.

BTW in case someone prefers to look at the presentation form, here are the slides that I presented in a couple of talks:
http://www.cs.technion.ac.il/~idddo/PoAslides.pdf

[Stery]

Really cool thread.

Whats "double spend" ?

[Meni Rosenfeld]

Really cool thread.

Whats "double spend" ?

https://en.bitcoin.it/wiki/Double-spending

[instagibbs]

The reason why you aren't worried that all the PoW miners will go offline is that they're rewarded for their work. Similarly, if stakeholders are rewarded, then we can expect some fraction of them to be online. In section 3.2.1 of the paper we describe how to incentivize a target participation level of the online stake.

Ok, I understand why people would mine, that wasn't the question, but are you saying the system will automatically tune to 10 minutes for finding a successful block? I suppose it will just readjust based on the implicit(explicit?) fraction of BTC stakes, as well as the PoW being done?

edit: Reading the slides. While it's well-written, I'm always annoyed that in one breathe people are concerned that miners will mine empty blocks, but similarly we shouldn't worry about PoA stakers to not do it. They're both invested in the same system with equiv capital(theoretically). It's not a substantial difference. Otherwise, I'm enjoying the read. It's easily the most "believable" for a PoS skeptic like myself, for a number of reasons.

edit2: If we are capping value of blocks, will we have a rule that allows a single transaction block that goes over that limit? Otherwise you wouldn't be able to spend BTC at extremely large valued addresses. Would the cap value mean miners will just include tons of dust transactions? Or would the value cap be *in addition* to the 1MB data cap? Or are we hoping the size propagation penalty will naturally force this down? Would this also encourage people to split up their BTC into smaller value, increasing the UTXO set? Just random things to think about.

[Gyrsur]

is there a full reference implementation to extend a full Bitcoin node with PoA?

[Gyrsur]

can it be combined with a distributed mixer? PoA nodes should be mixer nodes too?

[iddo]

I suppose it will just readjust based on the implicit(explicit?) fraction of BTC stakes, as well as the PoW being done?

Yes, by readjusting the PoW difficulty according to how many blocks were created in a retarget window, we can achieve a predictable gap between blocks, where the new difficulty is derived both from the stakeholders' participation level and the PoW participation level.

I'm always annoyed that in one breathe people are concerned that miners will mine empty blocks, but similarly we shouldn't worry about PoA stakers to not do it.

Stakeholders shouldn't want to mine empty blocks in a malicious attack to destroy the system, as this would diminish the value of their stake. The bigger concern is closely related to the centralization/monopoly risks, i.e. miners cartel that obtains dominance and could then impose their policies (exclude transactions that don't conform with the fees that they impose, etc.). If PoW mining hardware is completely unusable for anything besides the particular cryptocurrency, then stake and PoW hardware would indeed be very similar in this regard. But ASIC/GPU can be repurposed for other uses, in particular to mine other cryptocurrencies, even as part of auto-switching centralized pool.

If we are capping value of blocks, will we have a rule that allows a single transaction block that goes over that limit? Otherwise you wouldn't be able to spend BTC at extremely large valued addresses.

Since the objective is to discourage stakeholders (or miners) from accepting low-fee transactions, I don't see any problem with value cap rule that lets the last transaction overflow. It doesn't have to be a block that includes only a single transaction, for example if the limit is 100 BTC and there are transactions of 70 BTC and 60 BTC (with high proportional fees), then you can include the 70 BTC, then also include the 60 BTC, but then you must finalize the block because 70+60=130 BTC is over the limit.

Would the cap value mean miners will just include tons of dust transactions? Or would the value cap be *in addition* to the 1MB data cap?

It's "in addition", see the paragraph that starts with "There is also a third tragedy of the commons problem" in section 2.1 in the paper. The point is that if there's only data size cap and let's say Alice wishes to send a low-value transaction and Bob wishes to send a high-value transaction, then Alice and Bob will compete for space and whoever of the two who offers the higher fee gets included. With the value cap, users who transact with higher values will pay higher fees (same proportional amount but higher in absolute terms), which is more fair. The data size cap is more controversial because it should accommodate the economy and reflect the wishes of the users. This is easier to see when you consider an extreme example, e.g. if Bitcoin allowed only 5 transactions per block now, then obviously everyone will revolt, hence similarly if the transactions volume increases substantially in the future (due to popularity) then the users will revolt if the 1MB cap remains.

Or are we hoping the size propagation penalty will naturally force this down? Would this also encourage people to split up their BTC into smaller value, increasing the UTXO set? Just random things to think about.

I failed to understand, what is a size propagation penalty? Why split up into smaller values?

[Gyrsur]

the most important part of the paper is this:

Money supply

With pure Proof of Stake cryptocurrencies, distributing the coins to the interested parties in fair manner is
less straightforward than with PoW cryptocurrencies. For example, it is informative to observe the hardships
that Ripple runs into as it handles the initial distribution of its built-in coin [38].

With PoA, we have the benet of the PoW aspect that is incorporated into the system, which can be
used for handling the initial distribution of the coins. However, if the PoA protocol species that the block
reward subsidy is divided about equally between the miner and the N lucky stakeholders, starting from the
genesis block, then this is likely to enable the rich to get richer in an unfair manner. One alternative is to
use a pure PoW protocol until the first block reward halving after 4 years, and only then roll out the full
PoA scheme. Another alternative is to always give the entire reward subsidy to the PoW miner who solved
the block, and share the transaction fees between this miner and the N lucky stakeholders. This may imply
that users will have to pay nontrivial transaction fees starting from the genesis block, in order to incentivize
stakeholders to run full online nodes. However, it is reasonable to expect that the fees paid to stakeholders
would not be excessive. This should mean that the added incentive to hoard will be small, i.e. the fees can
be a nice added bonus if the stakeholder wishes to save the coins anyway, but if she has alternative uses for
the wealth then these fees will not be enough to make her hold.

The apportionment can be specied according to certain constants. The portion that goes to the N^th
stakeholder should be relatively big, unless perhaps if all the N lucky stakeholders must maintain the UTXO
set (see Section 3.2.2). E.g., with N = 3 the protocol can dictate that 1/2 of the reward goes the miner, 1/4
goes to the 3rd stakeholder, and 1/8 goes to each of the two other stakeholders. The apportionment can also
be dynamic, in accordance with Section 3.2.1.

to the core devs: you have an issue with the amount of full nodes and you have an issue with the centralization of hash power by pool mining. the network is one of the most essential part of Bitcoin like a payment backbone of other instituations.

this proposal could be a solution for the issues. act now!

[Nik1ab]

I read in an independent news outlet that GHash is close to be hitting the 51%.

[Gyrsur]

"Among the Litecoin devs we have come to agreement that PoA was a bad idea as it can be abused by centralization.  It will absolutely not happen with Litecoin."

https://litecointalk.org/index.php?topic=576.0

So the concept was a joke or how should this to be understandable??

what is the reason for the stop? please explain: "can be abused by centralization"

[killerstorm]

"Among the Litecoin devs we have come to agreement that PoA was a bad idea as it can be abused by centralization.  It will absolutely not happen with Litecoin."

https://litecointalk.org/index.php?topic=576.0

So the concept was a joke or how should this to be understandable??

Litecoin developers aren't the ones who have written the paper. It was coblee's idea (although the current version is very different from his), but it was just an idea, they weren't committed to implementing it.

what is the reason for the stop? please explain: "can be abused by centralization"

Litecoin's bread and butter is copying Bitcoin is some minor tweaks. They (neither developers nor users) aren't interested implementing new, experimental features. So this is understandable.

But "can be abused by centralization" is a bullshit excuse. It doesn't make sense.

PoA still can be implemented as an alt-coin. And perhaps after some testing more established alts will consider adopting it.

[Gyrsur]

to argue it makes no economic sense to do a 50+ percent attack is BS. if this concentration exist there is a chance for an abuse by a third party (e.g. a hack).

(maybe the PRoC will hack into GHash.IO and destroy Bitcoin)

EDIT: do not want to have an another shitcoin, want to have this issues fixed in Bitcoin.

[killerstorm]

to argue it makes no economic sense to do a 50+ percent attack is BS. if this concentration exist there is a chance for an abuse by a third party (e.g. a hack).

I hope this is something everyone agrees with. People who deny this are no better than AIDS denialists.

EDIT: do not want to have an another shitcoin, want to have this issues fixed in Bitcoin.

I do not like shitcoins either, but we need some chain to test this on (preferably with valuable coins, in order to observe real-world behaviours and give people incentive to try to hack it).

[Nik1ab]

to argue it makes no economic sense to do a 50+ percent attack is BS. if this concentration exist there is a chance for an abuse by a third party (e.g. a hack).

I hope this is something everyone agrees with. People who deny this are no better than AIDS denialists.

EDIT: do not want to have an another shitcoin, want to have this issues fixed in Bitcoin.

I do not like shitcoins either, but we need some chain to test this on (preferably with valuable coins, in order to observe real-world behaviours and give people incentive to try to hack it).

Litecoin would come to mind, but they said no.

[instagibbs]

I meant to ask: If there's only a value cap, that'd mean a miner could trivially blow up the blockchain in size by adding a bunch of near-zero transactions and everyone would accept it as valid.  

I'm sure it can be worked around, but would involve some sort of upper-bound cap.
 
As far as rolling out the ideas, it's hard. Something like Litecoin is perfect because it has actual value, which is the only real test of the hybrid systems, to be honest.

[Meni Rosenfeld]

I meant to ask: If there's only a value cap, that'd mean a miner could trivially blow up the blockchain in size by adding a bunch of near-zero transactions and everyone would accept it as valid.  

I'm sure it can be worked around, but would involve some sort of upper-bound cap.
 
As far as rolling out the ideas, it's hard. Something like Litecoin is perfect because it has actual value, which is the only real test of the hybrid systems, to be honest.

There won't be only a value cap. There are several costs for transactions, and the caps / hardcoded fees need to account for all of them. A value cap helps sponsor hashing, you'd also need a cap on size, and maybe also on computation.

[iddo]

I meant to ask: If there's only a value cap, that'd mean a miner could trivially blow up the blockchain in size by adding a bunch of near-zero transactions and everyone would accept it as valid.  

Not exactly, because the transaction fees policy can be such that if you wish to send a near-zero amount then you have to pay a large fee.

I attempted to give a more complete answer in the previous reply, regarding "third tragedy" paragraph in the paper. The data size cap should be aligned with the amount of compensation that the nodes who secure the network get, otherwise it would be unprofitable for them to provide this security.

[coblee]

I'm interested to see where this leads. Although it would have to be a very compelling and obvious win in order to risk changing Litecoin's PoW at this late stage of the game.

[killerstorm]

I'm interested to see where this leads. Although it would have to be a very compelling and obvious win in order to risk changing Litecoin's PoW at this late stage of the game.

I think it can be compatible with existing mining hardware. Whether it adds security or not depends on distribution of 'stake' and how much active stake there will be.

[doldgigger]

If the node which may sign the next block is determined by the network before it's signed, how to handle the cases where

* node with signing privilege refuses to sign, or

* signing node is attacked in order to prevent signing?

[dogisland]

If the node which may sign the next block is determined by the network before it's signed, how to handle the cases where

* node with signing privilege refuses to sign, or

* signing node is attacked in order to prevent signing?

It's possible more than 1 miner would solve the block at 1 time. So if the block is prevented from being signed as you mentioned above, another miner might get lucky.

The block that gets signed is the one that enters the blockchain.

[VanKushFamily.com]

I think Proof of Activity Sounds like a Good General New Protocol.

There is a Pitfall to be avoided, but we can get to that Now. There have been Tokens made on the Blockchain that made it where, I am not sure on the Math but to make it simple let's say the way it Worked (and this is how it Worked, I am just not sure on the Math) it Released 1 Token Every Time someone did some Specific Action. This seems Fair at First because anyone can come in and get one.

But they found that People could make Several Accounts and be Performing the Action Several Times, and this isn't much Different than ASICs Taking Over Blockchains, but it didn't Work for the Tokenomics. It Quickly became Unfair. Or a 51% Takeover.

51% Takeover used to be a Death Sentence, even if the Token or Coin Maker was the 51% Holder. That is, until Steemit, where they Promised to use the 51%+ that they Held to Fund New Accounts and Community Development. Since then there have been many Projects where the Creators Hold 51%+ and it has been more Accepted than it was before.

But the Point being, Increasing the Rewards Pool to meet Demand does not Work for Mining.

When Mining and doing Proof of Activity, it should be like Proof of Stake. Each Activity should count as like 1 Stake, they are called "Vests" in Steemit Language, and we could use that Word. Each Activity constitutes Vestment, Vests we could say, and the Rewards Pool does not become Larger. Instead, the Coins become more and more Rare.

This is what Bitcoin Mining Calls "Difficulty". As more and more People Mine, the Difficulty goes up, and where You used to be able to Mine with a Laptop, now the Difficulty has gone up, and You need a Mining Farm to do the same Thing a Laptop used to do. Just because there are so many more People with more "Vests", or "Hashrate" in Bitcoin Mining Language. The Vests and Hashrate are Similar.

In Proof of Stake, the Hashrate comes from the Vested/Staked Currency, so they are exactly Correlated. If we just use Proof of Stake as our Standard, then we can make this all Very Simple.

I am making a Proof of Burn Token. So the Burn will be a kind of Vest, or a Share, a Hashrate, once Burned the Hashrate will go to the Wallet that Burned the Token. And the Rewards Pool will not Grow. But instead, that Person gets a Hashrate, and it makes it Harder for Everyone else. The Difficulty goes up.

[coblee]

You just dug up a 10 year old thread. 

[VanKushFamily.com]

You just dug up a 10 year old thread. 

Lol

I was Scouring the Internet looking for Minable ERC20 Token Information, and there came up a very informational Article, it might have been Documentation somewhere, I wasn't Paying Attention to the Page it was on, it could have looked like a Wiki, I don't Remember. But it had 3 Types of Mining Listed, and "Proof of Activity" was there with the Other 2, and they were all Hyperlinked. And it took me to this Thread. I was Surprised to find that it existed and that it got so into the Subject of such a General Proof of- that could be used for Minable Tokens.

I was around for Proof of Solar, and when Peercoin Started Proof of Stake, I remember all of that, there was supposed to be Proof of Identity Chains where You would get Paid for Logging in with Your Government ID, and it would be however many Times a Day or whatever like Mining Blocks to Keep the Blockchain Moving.

But Proof of Activity, that is a Great General New Concept, and it is 10 Years Old, but I would say it is still New. Just like I thought that Minable ERC20 Tokens I had heard of would still be around, they are all kind of defunct because they met that Pitfall that I Talked about in the Post that Revived this Thread.

I just see it as Worth Discussing Now. We could Call the HIVE-Engine Smart Media Tokens, "Proof of Activity". This is Definitely going to be where Currencies head. Because this also then Covers like Basic Attention Token (BAT), which I think was Part of the Brave Browser it was maybe Called. And People would get Paid for using that Internet Browser.

And just me knowing all of this, and being in the Middle of Creating a Minable Token that Works by being Burned and that Creates a Hashrate, I thought I would Add to the Concept and maybe we could get Everyone thinking. Because these are the Important Discussions. More Features IN WALLET, which is kind of Ruled by Token Wallets Right now, Creating Tokenomic Wallets are the kind of Cutting Edge Tech, that being CoinBase Wallet, Trust Wallet, MetaMask, KeyChain and TronLink. This is the most FUNCTIONAL WALLETS IN EXISTENCE. It used to either be like Bitcoin where there was just kind of a Send Function in the Wallet, to Proof of Stake where You could Mine Directly in the Wallet and at the same Time People Created Point and Click Mining in Different ways, that was also when Butterfly Labs was making the First ASICs for Bitcoin Mining and You could still Mine with a Laptop, I think each Bitcoin was $25 instead of $65,000. But the Wallet Functionality Discussion, and the "Proof of-" Discussions are the most important we can have.

Security is Probably Next, but it gets a big Chunk of the Conversation, so maybe some of the Security Features Community could even Benefit Financially from Thinking this way.

We used to Talk about Solar Mining and Living on Boats in the Ocean, and 3D Printing Things to Live on in the Ocean, being Platforms, and all kinds of Crazy Designs that now AI could be used to Generate. We used to Talk about Creating a Town Called Bitcoin Town, and it seems that somehow Cryptocurrency is becoming almost Childish, almost like it is Reverting Psychologically to a Childhood Tool, and Children should Learn to use it, but Everyone else needs to know how to use it to, or else they are going to be behind when all the Kids come and they are just waiting to Read my Words and that is all they need to get to the Next Solar System. Because we used to Talk about that too, Colonizing Space. In the like 50s they Started Calling it "The Last Fronteir" just imagine that (and they did) they had that kind of forethought, that it would be a Frontier.