I will rephrase your method quickly with my own words just to make sure I got everything right. Questions are inline.
First, we have:
- ASV = Account Stake Value: It is equal to the lowest balance that the account has had during the last N blocks.
Yes.
An account that was recently created or which has won a block fewer than N blocks ago has an ASV of zero.
I did say that, but then changed my mind. Forgot to unsay it; beg pardon.
The current iteration of this scheme allows accounts to win more than once per N blocks, but only as a last resort. A valid block from any account which has not won in the last N will always beat one from one that has, but this is now done further into the algorithm, not here.
- BSV = Block Stake Value: The BSV of the block extending a chain equals to it's own ASV plus the ASV of all other PoS+B and PoS-B extending the same chain (in the future or in the past? Is it just the cumulative ASV up to "now"?). No account's ASV is counted more than once in the past N blocks.
My original thinking was as follows:
All PoS contain a hash of the previous PoS+B, specifically of the branch they regard to be the current winner. Out of all the valid PoS+B submitted extending this branch, the one with the bighest ASV will win, but its BSV will then equal the sum of the ASVs of every PoS hashing to the same previous PoS+B. You should interpret every PoS as a vote to extend a particular chain, though only PoS+B come with a block to extend it.
A side-chain may also receive PoS-B and PoS+B from various accounts which indicates that other nodes think that the side-chain is in fact the main chain. If a side-chain attracts more stake value than what a node believes to be the main chain, then that's an indicator that the node's belief is incorrect.
The PoS part of a PoS+B would do double duty, both supporting the block nomination, and voting for the chain it tries to extend. Hence if both a PoS+B and a PoS-B were received from the same account, delete the PoS-B.
My current thinking revises this as follows
It would be simpler if the PoS+B were simply to nominate the block, while the PoS-B (which would come later in the revised 4-stage schedule) votes for which chain to extend. Consequently, both a PoS+B and a PoS-B from the same account should be expected and accepted. An honest PoS miner ought to vote against his own winning block, if he saw a block on a close-running side chain supported by a much higher ASV. However there's no way to enforce this.
- CSV = Chain Stake Value: The CSV is the sum of the last N blocks' BSVs. (did I get it correctly that we have sums of sums of ASV's? Counting older ASV's more often then newer?)
Yes, sums of sums of ASV's, in principle all the way back to the genesis block. In practice you only need to go back as far as the oldest live forkpoint. My current thinking is that only the most recent PoS-B, (in any branch) should count. Hence if an account switches its support to a different branch, it's previous support is cancelled.
Then, we have two different "proof of stakes":
- PoS+B = PoS with associated block (i.e., including and confirming transactions)
- PoS-B = PoS without associated block
Yes, but according to my current thinking, the PoS+B only nominates a block, it does not vote for the chain it extends. The account should send a PoS-B to do that.
Now starts the so called so-called voting period:
- Nodes broadcast a PoS+B block for each of their accounts A where ASV(A)>x% * OLD_WINNER_ASV, that is, the ASV of account A is x% of the ASV of the winner of the last block or higher.
- Additionally, each Node broadcasts an PoS-B (here, without a block, i.e., without confirming any transactions) for each of their accounts A where ASV(A)>threshold. The threshold is fixed and no hash target has to be met.
My current thinking is that there are two periods which might be called the "nomination period" when PoS+B are launched and the "voting period" when PoS-B are launched. I also think a node should always launch exactly one PoS+B, the best it can for the branch in considers to be the winner
unless it receives a better PoS+B from somewhere else before it launches its own. I've abandoned the idea of a lower limit of x%.
Thinking about "Nothing @ Stake", I cannot see a way, if a node controls more than one account, to prevent or detect it launching multiple PoS+B, each from a different account, each to a different branch. There would be no point in launching multiple PoS+B to the same branch, because it will know ahead of time which one would win.
I am assuming that there is nothing tying an account to the node that controls it.
Then this happens
All launched PoS (both PoS+B and PoS-B) should extend the chain with the greatest CSV, according to the launching node. (not sure I get that: all valid blocks extend that chain? Not just the "best" one? Or is it rather one best PoS+B and one best PoS-B? I fear I am not 100% aware of what exactly is added to the collateral and what is extending the chain. Also, is the collateral persistent, or is it just for the voting phase?)
Current thinking is just the one best PoS+B (There can be only one winner), but as many PoS-B (each for a different account) as the node can validly launch. Collateral is persistent, until that account launches another PoS-B, at which the previous collateral for that account is cancelled.
The end result of all of this, is that so long as a node controls at least one account with ASV > 0,
Or even if it doesn't, if we allow zero-ASV account to PoS+B if there is nothing better.
there will be at least one chain extended by a PoS+B.
Again, this works only if we abandon the >x% criterion and allow any account to PoS+B
Any chain not so extended dies. Also a chain dies if it's CSV is less than y% of the CSV of the winning chain.
Current thinking is that any new side-chain <y% be allowed a stay of execution of a limited number of blocks, just in case it has more support than the node knows about, perhaps due to connectivity problems.
But yes, at some point a judgment has to be made that a side-chain
is no more; it has ceased to be; It's expired and gone to meet its maker.
Apart from the addition of PoS-B, The new scheme differs from the previous in that an account's ASV is no longer the time integral of its balance. Instead it is equal to the lowest balance that the account has had during the last N blocks.
Yes.
An account that was created or which has won a block fewer than N blocks ago has an ASV of zero.
Created fewer than N blocks ago, yes, because its balance before creation logically must have been zero.
Last won a block fewer than N blocks ago, no. So long as it maintained a +ve balance throughout the last N blocks, it will have a +ve ASV.
The block extending a chain has a BSV equal to it's own ASV plus the ASV of all other PoS+B and PoS-B extending the same chain. Call these other contributors of ASV to the BSV "collateral support". No account's ASV is counted more than once in the past N blocks, so if any of the PoS, including the winning PoS+B has already contributed collaterally to the BSV of an earlier block in the chain, then it is not counted again.
See above. We will be counting only an account's most recent PoS-B, so it is the earlier one(s) which will be ignored.
Nor, if a block is added to a collateral supporter, does the new block add to the collateral support. In other words, collateral support is given to sisters, not aunts. The CSV is the sum of the last N blocks' BSVs.
Current thinking is that PoS+B never contributes collateral support whether or not there is a PoS-B from the same account. All a PoS+B does is nominate the block.
Strictly speaking collateral support is given to
mothers, but of course it is all the winning daughter who are supported when mother is supported, i.e. the sister of the collateral supporter. I hope this makes sense.
The idea behind collateral support is that the main chain will benefit from honest PoS more than any side-chain, including a side-chain being built by an attacker. (If the attacker's chain benefits more, then it is the main chain by definition.) Moreover an attacker can gain nothing by diverting his resources into his own collateral sybils, since this will just take away ASV from his winning blocks. This is a zero-sum game for him. PoS-B allows every account-holder with any ASV at all a chance to contribute collaterally to blockchain security, though they can never win a block unless their ASV is enough to allow them to launch a PoS+B.
Yes.
Every PoS, with or without block, will need to has all the PoW supporting it's predecessor.
Don't understand the sentence.
So essentially, at least from what I understand, we no longer rely on any hash. As the hash was the only random factor in the scheme we now have a deterministic order
Deterministic, but not necessarily predictable because an attacker (or anyone else) does not know which other accounts will stake at any time.
That said, my ultra-ultra-latest thinking is that, just to inject more randomness into the system, perhaps we should have a hash target, but one that is the same for all accounts, and independent of the SV. However we will have to be careful to ensure that an attacker can neither predict whether an account he doesn't control will pass its target on a particular turn, nor manipulate the accounts he does control to ensure that they will.
who from a subset of N "online" users will win which block.
The subset is not limited to N.
Also, I an not yet fully sure how the ASV will be "reaccumulated" after it was dropped to 0 upon creation of a new block. Will the ASV recover fully after N blocks have passed?
That was my original idea. The sole purpose of dropping to zero was to prevent accounts from staking more than once in any N consecutive blocks. This is now achieved in a different way.
If so, this could leave an attacker the possibility to create N high-stake account and winning blocks with them "round robin".
Yes, he can do that. They would have to be
all higher than any other staking account, which would be quite hard to achieve.
(Snip recapitulation of obsolete scheme.)
Sorry if I get that wrong, bit don't we have the same problem here? Its just not that you need N accounts, but M accounts (which is less actually, as M<=N?)
M >=N. M is actually the distance back to the last confirmed block. This will be N unless there is a long-lasting fork whose fork-point is further back.
Step 1. Normalise each candidate's ASV by dividing by the largest ASV of any of the last N block winners. This will not affect their rankings in any way. From now on, when I refer to a candidate's ASV, it is the normalised value I'm talking about.
Step 2. Iterate through the candidates in decreasing order of ASV. For each candidate, if the account last won more than max(M,N/ASV), or if it has never won, it wins; exit. Otherwise multiply the ASV by the number of blocks to the last win. Use this figure in the tiebreaker described in step 3.
Step 3. If no candidate won during step 2, then the winner is the candidate that has won the least number of times during the last M blocks. If there is a tie, then use the figure calculated in step 2 as a tiebreaker.
There is still a strange, though not necessarily undesirable property about this system. Sometimes more stake can hurt an attacker. For example, suppose the same honest accounts are staking throughout. An attacker with N accounts each with equal balances greater than the highest-value honest stake would win every block forever (or until a non-staking account with a higher balance decided to start staking) If these N accounts were the N highest, the attacker could permanently shut out transactions of his choice, including any transaction that might enable another account to compete.
But it would be really obvious that he was doing this. So let's suppose that the attacker had some more funds, and randomly increased the balances of some of his accounts, then he would no longer prevent accounts he doesn't control from winning the occasional block.
Maybe its just because its sunday midnight, but I don't see the point why increasing his amounts would break his monopole. Could you please explain that in 2 lines?
Not in two lines, but in one short paragraph: If all the attacker's accounts have the same minimum balance, i.e., the same raw ASV (and all no lower than the honest account with the largest raw ASV) then, after the normalisation in step 1, all the attacker's accounts will have a normalised ASV (nASV) of 1. On the other hand, if one of his accounts has a higher ASV than the others, the highest account will normalise to 1 and the lower accounts will normalise to < 1 These account will not be able to win every N blocks. Instead, they will win every N/nASV > N blocks (assuming that M is not higher than this.)
What also came to my mind: what he could also do is to move the funds to a different account the moment he has found a block. This of course would lock his new account down for the next N blocks (until the ASV is mature) but allowing him then to mine a block with a new "identity" without any "past". He just needs enough "coins in the buffer" to pull it off successfully. Calibrated correctly, every block a new account (belonging to the attacker) with a sufficiently high ACV wins.
I.e., Assuming C coins is enough to win a stake and N>M, then the attacker needs (N+2)*C coins of which N*C cannot be used as they need N blocks to get mature (we call them coins-in-the-queue), and 1*C of them are used to "be sent to a different account" one block after they staked a block, and 1*C are winning the current block.
I think he only needs N accounts all with a raw ASV higher than any other staking account, to win every block forever. He won't need to shuffle his money around. The question that needs to be asked is, what can an attacker achieve if he succeeds in his attempt to do this? As far as I can see, other than winning all transaction fees, the only thing he can do is shut out transactions of his choice. To attempt to double-spend would require a side-chain attack, and the rule that (1) no transaction is considered confirmed if it is not in a block preceding the earliest fork point, and (2) no forking block is accepted if it is later than a confirmed block, prevents all possible double-spending attacks.
In other words, the worst that an attacker can do is DoS.
I have two ideas to defeat this. First is the ultra-ultra-latest idea of randomness. No matter how low we set the probability of an account not being allowed to stake that turn, and no matter how many high-value accounts he has,
eventually all his accounts will be blocked in the same turn, and his monopoly (or even his monopole
) will be broken, if only temporarily.
My second (brand new) idea is to introduce a new metric that nodes can use to decide which branch is the current winner - not difficulty, nor stake-value, but
unsociability. A branch's unsociability is the total number (or perhaps the total value) of all transactions the node knows about that are not yet included in the branch, excluding very recent ones, and perhaps giving a higher weight to older ones. Anyone
not including all the transactions he knows about into his blocks will soon find his branches losing to more sociable side-chains.
And if the attacker with N high-value accounts locks out all others, and is completely sociable, in what way is he attacking?
