Shouldn't all voting nominations and electorate votes be added to the chain without the central committee signatures? Otherwise the committe could block the votes?

If the majority of the central committee wishes to abuse their power, what could they do exactly? Only withhold txns? Maybe offer some type of insider trading bribes regarding which txns will be included and at what time? Could they try to do double-spending by signing two conflicting blocks with their 5 signatures, and then broadcast the two blocks to different parts of the network at the same time? Any other ideas for attacks by the central committee?

I'm biased against this kind of protocol, because the centralized entity would have too much power that it could abuse, and it'd take a long time to replace the centralized entity. So the central committee could boost confidence by behaving flawlessly until more participants use the network, then more and more money can be influenced by the central committee members, and then they might begin to abuse their power.

Maybe you should start a thread to discuss this kind of protocol, my biased opnion here is probably not so useful.

Actually, there is a substantive difference between adding empty blocks security (via lottery) to pure-PoW versus adding it to simple-PoA. The difference is that with simple-PoA the attacker cannot keep his branch secret for too long, because he wouldn't accumulate PoA signatures so the honest branch will have more weight multipliers. We'd need to tweak the previous idea in order to take advantage of simple-PoA. The problem earlier was that if the (say) 5th block was a stakeholders block that some lucky stakeholder may create, then the attacker could simply generate the 1st,2nd,3rd blocks in public, and then generate the 4th,5th blocks in secret and reveal them together (if the lucky stakeholder could see the 4th block then he would generate the 5th block much faster than the attacker, but if he only sees the 3rd block then he cannot). Instead, we can view the blockchain as batches of 5 blocks, each batch of 5 blocks derives the pseudorandom stakeholder, and this lucky stakeholder may create a block (without PoW effort) in any place at the next batch of 5 blocks. Actually, it could be useful to use my botched idea from post #114 and introduce some large gap, for example the 1st batch of 5 blocks derives a lucky stakeholder for the 200th batch (i.e. 1000 blocks later), so that the lucky stakeholder will be notified early (unlike simple-PoA signatures where we cannot do it), and this might increase stakeholders participation. With the large gap, we cannot do hash(R,n) as in post #116 etc., so the protocol rule can be that if the first 4 blocks in each batch of 5 blocks didn't include a stakeholders block, then to generate the 5th block via PoW you'd need to meet a higher difficulty. The weight of a stakeholders block can be the same as the weight of a signed simple-PoA block, or higher/lower.

Let's try an example with specific numbers. Batches of 5 blocks as above, simple-PoA with 5-fold weight multiplier (T=4, as in coblee's OP). Note that to get security against double-spending with 5-fold you can still wait for 5-out-of-10 signed blocks and the attacker would need 7 secret consecutive signed blocks (see post #78). Let's assume that 75% of all stakeholders blocks will be created (large gap for notification, and the lucky stakeholder gets the entire reward of the block that he created, unlike when he provides PoA signatures and gets 10% of the reward). Therefore, we can set the PoW difficulty of generating the 5th block of a batch with no stakeholders block to be 4 times harder. This means that in 3/4 of the time the batch will have one block that is generated instantly, and in 1/4 of the time the batch will have a block that takes 4 times longer to generate, so on average we didn't decrease the performance. Let's assume that the weight of a stakeholder block is 10-fold, i.e. twice more than the weight of PoA signed block. Let's assume that on average half of the regular blocks get signed via simple-PoA.  Now, an honest batch of 5 blocks will have weight 10+5+5+1+1=22, and the secret branch of the PoW attacker has weight=1 in each block. This means that while the honest network generates 4 blocks to gain weight=22, the attacker will need to generate 23 consecutive blocks in order to outcompete the honest batch of 5 blocks, but among those 23 blocks there were 4 blocks that he had to generate with 4-fold increased difficulty. To sum up, the attackers needs to generate 35 blocks to outcompete 4 honest blocks, so his hashpower has to be 8.75 times faster than the honest miners, meaning that he has nearly 90% of the total hashpower in order to generate empty blocks continuously.

What might be sketchy with those specific numbers is giving twice more weight to the stakeholders block, so the lucky stakeholder could try to collude with miners and double-spend, though his weight advantage wouldn't be so big. One simple way approach to avoid this is to increase the simple-PoA multiplier to a little more than 5-fold, but then users might have to wait for a little more than 5-out-10 signed blocks to get security from double-spending, which would be fine with 2.5min block time. However, all of this assumes that half of the stakeholders provide PoA signatures, hopefully the incentives could be put in place for that.

Edit: 4-fold higher difficulty for 5th PoW block is good for the empty blocks attack, but bad for double-spending attacks, because the malicious stakeholder who was chosen in the lottery and creates a secret branch with his stakeholders block will also have time to create 4 additional blocks ahead of the honest network. Repeating the previous example with the same numbers and with regular PoW difficulty instead of 4-fold difficulty, we get that the attacker who generates empty blocks will need 85.2% of the total hashpower.

One other way to derive x-bits pseudorandom number from the last 5 block hashes: derive x pseudorandom bits from the first block hash and store them in R, then derive log(5)*x pseudorandom bits from the 2nd block hash and view it as base5 number of 30 digits (e.g. 3402104...), and if the ith digit of this base5 number is 0 then flip the ith bit of R, meaning that we flip each bit with 1/5 probability. Do the same with the 3rd,4th,5th block hashes as we did with the 2nd block hash.

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

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

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


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


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

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

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

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

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

Regarding signing-key / limited-withdrawal delegation:

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

Any comments regarding my new idea in post #97 ?

Hello cunicula,

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

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

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

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

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

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

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

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

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

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

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

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

Also, I still take issue with your initial assumtion:


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

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

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

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

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

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


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

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


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

Edit: looking at your other comment:


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

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

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


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

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

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

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

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

Right, it was my mistake, I now compiled with -O3 and it's faster, in particular the SSE version. However, it's using only a single thread, so assuming that single Xeon gets 10kh/s I tested how long this non-optimized implementation takes to finish 10k invocations, and it took about 4.5 seconds. So you can assume that it's 4x slower than the Litecoin miner implementation (with r=1, i.e. in cache).


So it's more like 2 seconds instead of 8 seconds per hash attempt, with 512 megabytes.