What makes you say that?

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

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


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



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

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

Here you go:


About 8 seconds per hash attempt with 512 megabytes, so it'd take 18 days to verify the initial download of a blockchain with 200,000 blocks.

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


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


Interesting idea, I'll keep that in mind.


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

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

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

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


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


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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hello cunicula,

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

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

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

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

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


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

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

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

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

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

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

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

I received that 90% payment message yesterday, and approximately 5 hours after receiving the email the BTC indeed showed up on the blockchain (about 44 BTC).

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


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

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


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


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

Nevermind that you didn't analyse your protocol, I haven't even seen evidence that you know how the protocol works. Remind us again why you refuse to post the protocol specifications? Maybe someone else wrote parts of the code and disappeared, leaving you clueless? IMHO killerstorm is being far too respectful towards you than he should be.

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

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

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

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

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

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