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.
Topic: Proof of Activity Proposal - page 3. (Read 34062 times)
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?
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?
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?
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?
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 hasx1300 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.
An attacker with 1/10 of the active stake will have an advantage over the honest network if he has
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.
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.
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
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.
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.
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.
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.)
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.
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.)
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.
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://bitcointalksearch.org/topic/m.1369600 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.)
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://bitcointalksearch.org/topic/m.1369600 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).
Hello cunicula,
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?
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://bitcointalksearch.org/topic/m.1369600 Of course you could still use PoW to hand out free coins.
Hello cunicula,
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?
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?
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://bitcointalksearch.org/topic/market-based-solution-to-the-decentralization-vs-speed-trade-off-127952
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.
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://bitcointalksearch.org/topic/market-based-solution-to-the-decentralization-vs-speed-trade-off-127952
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.
Hello cunicula,
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.
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:
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.
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 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.
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."
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?
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).
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?
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?
YesIf 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).
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
[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:
Here is the data which is taken directly form the block chain:
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.
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.
Jump to: