The video published on the project's main page mentions Dropbox as one of the examples that could be recreated as a distributed system with this project, but I couldn't find any info on the more interesting question: how?

Which of its facilities would be useful for that? Who would store the data? Would it be a separate system which just happens to use ethereum for user authentication, or would it actually has anything to do with data storage? How would the insanse amount of data stored distributedly in a way that it doesn't choke the individual nodes, but would be readily available any time?

Dropbox really stands out of the other example applications and without at least some basic techincal description it sounds like just a marketing stunt... so can we have some more info?

wow, thank you!

2083517044157347473

(ps.: atm I am just passively following the thread due to lack of time, but there are still a few issues that I feel haven't been thoroughly checked, so beware:) )

Ok, I misunderstood what you wrote the first time,  I am a bit tired now, I think I will continue thinking when I am more rested


I've seen this "transparent forging" mentioned in this thread multiple times. Is there a description somewhere on what it is?

Hmm... so it seems to be right that this Proof-of-Stake scheme penalises the small accounts. (not just those that are handled by a single entity, but everyone else the same way)

But I don't think that it exactly balances out the block-choosing algorithm.


I don't think so. You have two accounts, but can only use one of them, so it doesn't double your reward. There is a chance that the second one helps you to get one more though. (though that's much smaller) Also there is what I said about the time spent gathering fees: if you choose the later one, you get more fees as you can wait for more transactions.

So there are a bunch of factors in play here. But it seems sure that this PoS doesn't make the distribution "truly fair". Maybe quite close though.

Why? They don't have to be eligible at the same timestamp. As you "see the future", you know whether you have two eligible accounts at different timestamps too.

I am also still not convinced that the collisions reduce the chances of the fragmented accounts, but it's difficult to prove or disprove it without seeing some formal specs of the protocol.

It may also be possible to have different accounts that are never eligible at the same time. (I think eligibility is calculated as difference from a hash, so you just need to ensure that your accounts are not covering the same hash intervals) (ok, this isn't true, all relevant hashed changes with every timestamp)

Ok, so basically what you are saying is that Bob's accounts are at a disadvantage because they are competing against each other, and the loss is where both accounts hit the target at the same time. (as it doesn't give twice the winnings). But... this could be said of any two accounts regardless of who controls them. The question is what happens when two hits the target the same time? It seems to me that there is a kind of difficulty defined and the one with the higher difficulty wins. In that case we are back to:
Because the time when they hit their target doesn't matter.


I don't see why it would be incorrect. The only difference between the two approaches is that the second one disregards the timing of the events, and collapses the selection process into one step. Your approach can account for the lowered block-generation rate in the "gaming the lottery algorithm" I described, but because only the fees are given to the forger, it doesn't matter. (well, actually it just adds to the incentive to not publish the first winning ticket and use the second one, even when the second one isn't giving you the winning hash for the next block. So you can wait for a few more transactions and get the fees from those too. This makes gaming the system even more worthwhile than my original formula suggests)

Which bits are limited and why you think that is relevant?

I don't really understand your math here. Why would Bob's chance be lower than 0.001 ?

I think we can agree that after any given block there is a 50% chance of selecting Alice next, and 25% for each of Bob's account. It's easier to reason when it is presented this way.

Where Bob has an edge is that if one of his blocks is selected, he may check whether it is better for him to not publish his block. That happens when his other block is going to be the second best one, and makes the genSignature to select him after that too.

Yes I know that there are some mechanisms to punish accounts that are not publishing when it's their turn, but that doesn't matter if the accounts are small and many enough.

Btw, this question itself can be answered without any of the game-theory math I did above:

Because the 1440 blocks out-of-the-game period is independent of the account's balance, it is obvious that the smaller the account you are using for the forging the better. If you have one big account, you're completely out of the block creation process for 1440 blocks, but if you have it distributed to many small ones, only one of them is disables so you still have most of your accounts taking part in the lottery.

So without further thinking it can be seen that this 1440 block disabling period is unfair towards big accounts and incentivises splitting them to small ones.

Edit: Ok, this may not be true... do I understand correctly that once an account created a block, it's effective balance is zeroed out for 1440 blocks? If not than what I wrote in _this_ post is incorrect, but doesn't change what I wrote above about using the second-best accounts for forging.

I guess I couldn't explain the idea if this is still a question  Lot of small ones is more profitable. If you only have one account, you never have an option to choose from your own accounts (as you have no other) and it's also going to be out of the lottery process for the 1440 blocks after it create a block, so it gives exactly the "fair" chance, no more.

Because there is a chance that he not only has the first winning ticket of the "who's gonna forge" lottery, but also the second one. In this case he can choose which one to use: if the second one makes him the winner for the next block too, he chooses that, instead of the first one.

That's what I am saying. It is intended to be a Poisson process, and it is as long as you are using the algorithm in the published source. But someone may decide to "optimise" it further for their own benefit. In that case it isn't strictly a Poisson process anymore, as he is creating a block, he has a slightly higher chance to create the next one too.

Also I made a typo when copying: it's x*(p+(1-p)*p^2) + (1-x)*p = x , the solution is the same

So for those not following: A user may have many small accounts instead of one, and may sometimes be able to choose which one to use for forging in a way that the next block also belongs to him.

Of course there are some limitations because of the fees, but for now let's assume that a user has "p" stake [0..1], and it is available in many small accounts: specifically the number of accounts is significantly higher than 1440, so that we can ignore that the 1440 block waiting period disables some parts of the accounts. We also assume that all the other accounts are many small non-colluding users.

Now if this user has a probability "x" of creating a block, then we can express that probability as a recursive formula. Generating the next block will happen with probability:

x*(p+(1-p)*p^2) + (1-x)*p = x

The second part means that with probability (1-x) someone else is generating the block, the account has no word in the selection process, so he will get his fair "p" chance in this case.

However when with probability "p" it happens that the account with the best chances is one of his owns, he can also check whether he also has the second best account. So in this case there is a "p" chance of generating the next block in the "fairly deserved way", by choosing the best block which also happens to grant the second block, but when this isn't true (chance (1-p)), he can check whether he has the second best block too (*p) , and whether it grants him the next block too. (this also happens with "p" probability) So this case adds an additional chance of (1-p)*p*p for this branch.

Solving the equation gives x = p / (p^3 - p^2 +1)

As I said this is not a big difference. Gives some incentive for colluding though, a few players with 5%-10% stakes each may decide that the few extra percents are worth grabbing.

Now I won't be at my computer for a while but I will clean it up and post later.

No. In PoW the cumulative work clearly decides the valid branch, there is no option that you see two branches and can't decide which one is the "real one" accepted as the consensus.

Then what is rationale behind it? Pretty much the main point of proof-of-work is that this can't be done.

Instead of running simulations I did the math and the effect is much smaller than I expected. For example someone having 33% stake can get up to 36% of the blocks if the rest of the network are many small non-colluding participants.

No, we can't. Someone in the chain up to our expected block may fall off the network and not publish their block, changing everything afterwards. (if I understand the system correctly)

On the other hand if we can, then it's possible to "mine" an address 1440 blocks ahead and grab a block. Also if only one or two users stop participating in the next 1440 blocks, we can adjust our "mining" algorithm for that too, especially if we do some data mining to see which accounts are "reliable block generators" and which are not. And this may actually be a problem with enough users playing greedily and optimally.

After 10 more minutes of thinking, I am pretty sure that if everyone plays optimally the ratio of blocks generated by a single entity or a group of colluding entities is not linearly proportional to their stakes. And I feel that this may just be one of the weaker statements and there may be bigger problems here.

The creators really have to disclose their research backing this PoS scheme.

I am concerned about a single entity completely taking over the block generation.

I found one more line of importance that I didn't see originally: in line 288 the hash of a new block is only determined by the hash of the previous block and the pubkey of the account creating the new one.

Now I think I understand the thought process, but I would have preferred to read it from the creator in their own words. I still feel that this requires a formal proof that it can't be gamed (not even by a large enough stake), and it's far from convincing.

I agree that these are fundamental questions, and are the only reason why I wanted to look into the code, or have some specifications. This coin advertises itself as the first 100% proof-of-stake system, without revealing anything about how they solved the problems that prevented others to create one.

Looking into the code I couldn't find anything addressing the usual concerns about 100% PoS. (or is this one of the "injected" bugs? the part of the code securing PoS is simply missing?)

Answer to (1) is pretty much the same as Bitcoin: it just builds a chain of blocks, stores everything, cross-checks new blocks with old ones. It adds some spin to how accounts and public keys are stored, but there is no real innovation here.

(2) and (3) are more interesting. The algorithms seems to be the straightforward PoS: From the previous block it creates a hash. Each second it creates a (hash('time elapsed since last block' ,  'own account key') * 'amount of coins on account') which it calls "target", and that determines whether the account has the right to create a new block or not. Additionally 'amount of coins' is zeroed out if the account has created a block within the last 1440 blocks.

I spent only around 30 mins reading the code, so at this point there are three options:
- There are somewhere else some additional rules to make the scheme actually secure that I haven't found.
- This is one of the purposefully injected bugs.
- The PoS is insecure and doesn't even attempt to address the issues that prompted the creators of other coins (such as peercoin) to also incorporate PoW to fix the shortcoming of PoS.