Topic: Proof of Stake - page 2. (Read 16423 times)

I think you were already answered:
As soon as the cabal that holds 51% of the stake in PetkoCoin starts cheating, the trust in PetkoCoin will fall, a new currency - CBeastCoin - will appear (probably with same source code), and the cabal will lose the real-life wealth they have invested in PetkoCoin. This is what guarantees that the cabal (if any) will not be malicious. Of course, it is out of question that the currency software should be open-source (IMO).

It's not that. It's the rich will have untouchable anonymous power. There is no way to stop a cabal of people from taking permanent control and reversing transactions discretely.

So, apart from the guys shouting "rich will get richer" (if I have invested several thousands dollars in mining hardware, I would have been shouting that too), the only problem for having a PoS-only currency is the initial distribution of the stake (correct?). And the current solution is the hybrid PoW/PoS implemented in PPCoin. Ah, and the other problem is that noone is willing to write the code.
Let's put this another way: the stake shows how much each participant has invested in the currency. If someone owns 99% of the stake, the last thing he will want is to destroy the currency (keeping the coins for himself will effectively destroy the currency because every payment method is meant to be used for payments). That being said, I cannot see another party who deserves more the initial stake than the guys who actually wrote the code (since they are the only ones who invested something in this currency). Then, let The Free Market decide how much is each coin worthed.

hmmm
I think the POS technology is still not so developed and proved to make a hard fork on it. But PPCoin and Novacoin also are good experiments and maybe some day could be so far.
Some occasions could also accelerate this process, for example if governments would begin seizing mining hardware.

lol

You can have separate private keys for voting and spending.

POS would mean keeping your coins in an unlocked wallet like by PPcoin and I wouldn't say that is a security improvement.

The 90% attacker can also feign an attack upon itself, and create confusion as to which blockchain is the real one, for an extended period of time, though I do not know how for how long.

I created a bounty for the first Proof-Of-Stake coin AKA StakeCoin.

If it takes so long to explain, it probably won't work. Give me your elevator pitch, no more than one paragraph and 3 or 4 sentences. Tell me exactly how to implement it in the current system, and tell me exactly how it won't be materially different then what we are used to, so that users don't get scared. If you can't, you have failed, and it isn't worthy of consideration.

Ah, but remember the asymmetry of the two communities' goals. Imagine the 90% attacker (I'll use the word "attacker" because we can live with a benevolent monopolist - it's when they stop being benevolent that we have to start caring, so to speak...) has already built a tall contiguous chain run, perhaps tens or hundreds of blocks tall, which is purely theirs - the attacker has (so far!) kept successfully reversing and excluding the blocks offered up by the 10% of honest miners. Thus, so far the attacker's chain has kept out the transactions the honest miners are including as a matter of course (to earn the fees), and has let in only those transactions (if any) the attacker wants to deign to permit.

At this point, because the honest 10% aren't trying to build an honest-10%-only chain - a goal they would indeed have no hope of achieving - but merely to get an honest block into the chain here and there, we have the interesting situation that both communities are trying to build on the attacker's proudly built tall chain.

This is where "proof of blockchain fair sharing" - a suitably cleverly chosen structure-aware chain height formula - could swing into action. The attacker's would-be (n+1)th block is keeping things as skewed as ever - the 90% having 100%, the 10% having 0%; whereas the honest miner's would-be block is at last moving things incrementally towards proportionality - the 90%'s share down a little to 99% or whatever, the 10%'s share up from 0% to 1% or whatever. So, with the right formula, we can hope that the candidate chain we're rooting for, i.e. the one with n attacker blocks followed by 1 honest miner's block, will win over the "pure evil" one (with n+1 attacker blocks)! - And so on up from there, giving the reasonable interspersal the honest miners crave.

OK, I freely admit that this is all talk until I, or someone else, actually comes up with a structure-aware formula with that property. But I think the omens are good - there's such rich pseudonymous structure in a proof-of-stake chain (compared with a proof-of-work chain) that some formula can maybe do the job! (It doesn't have to be literally a "formula" in the traditional mathematical sense - "algorithm" would be a better word really.)

It's precisely to get as large a talent pool as possible thinking about these possibilities that has motivated me to go ahead and publish the broad framework right now, without having come up with a formula myself. Better that, I think, than to have just me working silently away on a formula, and, uh, perhaps not having the talent to find one that someone else could find quickly!

I applaud your creativity, but don't see how this could work. Presumably a monopolist can choose not to contribute blocks to a chain he doesn't like. This would make the disfavored chain highly nonrepresentative (more so than the monopolist's chain). Isn't that a serious (fatal?) problem for this design.

Note: i prefer the term monopolist to attacker because i don't accept the claim that a monopolized chain will always lead to abuses of power. This depends on the monopolists incentives. proof of stake provides very strong incentives to behave responsibly.

(Copied, with minor edits, from my recent contribution to https://en.bitcoin.it/wiki/Talk:Proof_of_Stake.)

Proof of stake - done right - is maybe, just maybe, the way to eliminate 51% (even 90%!) attack worries altogether!

The vigorous debate about which of various systems, on a spectrum from pure proof of work to pure proof of stake via hybrids in between, is very enjoyable and thought-provoking. But when all is said and done, the evaluation process always boils down to "which system is least likely to allow the horror of a 51% attacker getting total control?". It's just assumed, by everybody as far as I can tell reading through the forums etc, that a 51% attack is a sure-fire route to total control, and that there's nothing anyone can ever do about that.

(And make no mistake, total control will not stay benevolent, even if it starts off that way. The temptation of the total controller to start acting exactly like the banking system as we know it today - inventing ever more elaborate rules for what sort of transactions it will deign to process, how much it feels like "knowing" about its "customers", and so on - and, beyond that, the temptation of the political system to put unstoppable pressure on the controlling entity to do all these things and more - will be huge, permanent and irresistible. "Decentralisation" will become worthy only of a hollow laugh.)

But, I would like to ask: are we thinking imaginatively enough about this? What about seeking a protocol where even a much more than 50% attack still fails? (Where the "%" figure refers to whatever the scarce resource is - work, stake, an optimum Cobb-Douglas mix of the two in a hybrid system... whatever.)

It's been taken as "obvious" that a 51% attack will succeed. One unit of the scarce resource is the same as another, and 51% beats 49%, and that's all there is to it! But proof of stake means the scarce resource is not the fungible "stuff" we're used to from proof of work. Stakeholders (unlike proof-of-work miners) are pseudonymously trackable. (They sign with a pseudonymous identity when they supply bitcoin days destroyed into a coinbase transaction, or whatever similar thing they have to do to establish they're a stakeholder.) And they can't cheaply change their pseudonymous identity (sloshing bitcoins around before landing them on a coinbase throws away all those lovely bitcoin days that could have been destroyed into the coinbase).

This opens up wonderful new possibilities. We no longer have to compute the "height" of a candidate blockchain as just the sum of atomistic contributions from each block (like the sum of their difficulties, in the case of the current Bitcoin). We can reward preferred structures and patterns in the way the pseudonymously-trackable stakeholders are interleaved in the chain.

In particular: we can reward "closeness", in some mathematical sense yet to be pinned down, to a sort of proportionality or "fair sharing" pattern. So, for example, a miner or set of miners with 10% of the deployable stake, who so far has less than 10% occupation fraction of the blockchain (maybe they've barely started mining at all), can have each block they mine (and help bring their share closer to the "ideal" 10%) be deemed to contribute more incremental height to the chain than an atomistic sum formula would have given. And conversely, if they overshoot and already have 15%, a structure-aware chain height formula can allocate less incremental chain height for the overshooting fraction than an atomistic formula would have given.

I believe that if we choose such a formula cleverly, we may well be able to protect against attacks that have been considered an obvious lost cause - 51%, 80%, 90%. For note that the attacker(s), say with 90% of the stake resource, and the honest miners, with the remaining 10%, have asymmetrically different goals.

The attacker, or attacker cartel, wants (in the scenario we're traditionally most worried about) to either bring down Bitcoin, or keep it going but with control over what transactions are "acceptable" - e.g. to act like a know-your-customer bank, or to harass targeted persons or economic sectors by rejecting their transactions. To achieve this, the attacker has to keep all blocks generated by the honest 10% out of the winning blockchain. (If even an occasional one got through, in a way the attacker couldn't reverse, it would of course include all the accumulated pool of "ordinary, reasonable" transactions the attacker is trying to reject - the 10% just want to earn an honest profit by collecting all those fees.)

By contrast, the honest 10% do not have to aim for the symmetrically opposite goal (of excluding the malicious 90%). They merely have to aim for achieving a reasonable interleaving of their honest blocks into the winning blockchain. Then ordinary users will get their transactions handled (albeit more slowly than they might have got used to); and the honest miners will collect their fees.

The challenge, then, is to design the structure-aware chain height formula so that the attacker's would-be chain loses (even though, of course, a mere sum of stake-achievements block by block would allow a 90% attacker to effortlessly win). The idea is that, if closeness to fair share interleaving is being especially highly rewarded, then the attacker's chain gets penalized for being far away from fairness: the 90% have 100% occupancy, and the 10% have 0%. The competing chain with some honest blocks here and there gets strongly rewarded by comparison (say for example the 90% have 93% and the 10% have 7% - that's closer to fair shares than the attacker-only chain). It wins!

The exasperated attacker fumes, "Why the hell can't I reverse these pesky honest blocks? I'm deploying 90% of the network's entire power! My chain without them should be the winner!" Ah, but structure-awareness is rewarding their presence and penalizing their absence. And with a strong enough such effect, who knows, perhaps any percentage level of such a style of attack can be thwarted!

I've created a draft page, https://en.bitcoin.it/wiki/Proof_of_blockchain_fair_sharing, for ideas fitting into this general milieu. At the moment it just has a teaser description of the general idea (pretty much similar to what you've just finished reading here). I had hoped to spring a polished structure-aware height formula on the world; sadly, my first effort I believe has subtle economies and diseconomies of scale (giving stakeholders perverse incentives to either club together, cartel-like, or disaggregate, taking on multiple pseudonymous identities each). That's not the end of the world perhaps - especially since the whole point of this revolutionary new approach is that a cartel (even going above 50%) is no longer something to be terrified of - but I'd prefer long-run scale-neutrality if possible. More importantly, I now also believe my first effort doesn't achieve a strong enough bias in favour of fair-shares chains to make much difference (it maybe means a 67% attack is needed to gain total power, rather than 51%... mildly helpful I suppose, but I still aspire to the dream case where no finite attack succeeds in the long run).

Naturally, I'm hoping to invent a formula that achieves the miracle of letting any honest minority, no matter how small, achieve a non-zero occupation fraction of the winning chain. (Their achieved occupation fraction might not be exactly the "fair" one; but any non-zero fraction would let Bitcoin continue, albeit slowly and creakily, and with luck the attacker eventually concedes defeat.) To speed up progress, I thought it only fair to throw open this challenge to all mathematically-minded Bitcoin folk - after all, there are doubtless others far more talented than me!

Thanks...reading....bump thread for further input...

I've added a description of my PoS system to the wiki. But I'm beginning to like cunicula's system, it seems more robust against DoS attacks.

I completely agree about the possibility for many additional improvements completely unrelated to proof of stake. I focused on the proof of stake issue because it seems more important to me than any other single issue.

To put together a new project, there has to be a consensus among the design participants about its desired functionality. Obtaining consensus is hard, especially among people who haven't developed mutual trust and understanding. Thus, it seems to me that formation of a plausible groups of core contributors has to begin fairly early on in any group project. Once a group of people can agree on one core goal, there is a basis for negotiation over additional goals.

Okay, I got you. Part of the problem is that I am not at all familiar with coding. I think this seriously limits my ability to make any complete design without substantial help. It also means that I don't even understand the process of making a design very well. I imagined that it was something like scrape together a prototype, find out where it is broken, fix it, find out where it is broken,..., continuing until you are satisfied with the prototype and ready to release it. Apparently more thought goes into the pre-prototyping process than I had imagined.

One thing that would help is if I knew everything that a complete pre-prototype design needs to contain.

Anyone care to make a list for me? I can make a new wiki and gradually try to fill in the necessary details (hopefully with a lot of help).

Easy?  Well, I'll take your word on that.  My point is that since you can't ask a programmer to implement anything based on an incomplete design, I don't see how the current lack of a coding volunteer is a pressing problem right now - as cunicula seems to suggest.  Worrying about a coding resource at this stage is putting the cart before the horse, no?  Maybe I misunderstood cunicula's post, though.   


Agreed.  No need to worry about programming/deploying an altchain until a design is developed and a consensus achieved (particularly if you're increasing the scope of the project beyond PoS and including other improvements).

BTW, have you got any further details on the nature of your PoS proposal?  As I mentioned earlier, I find these ideas fascinating...even though I might not fully understand them.   

This is a relatively easy problem to fix if we want to go forward.

But in case there is any doubt, I oppose creating this altchain anytime soon. Unless it is very well thought out (preferably with some additional improvements over the original Bitcoin. There are quite a few issues in need of fixing) and has several supporters willing to dedicate effort to making it succeed, it will do more harm than good.

mmm...I thought you were still identifying requirements and refining/vetting a design to meet those requirements for your PoS altchain.  If I was a programmer (I'm not), I wouldn't be inclined to begin coding anything until a design phase is complete (especially on a volunteer basis).  I've read through this thread and the wiki entry a couple of times, and I still don't see a workable design for an altchain yet...am I missing something?

If you're saying the altchain design is complete, and it's represented by:

Hash Difficulty >= Difficulty Target / ( max(Coin-confirmations used to sign block, 100 satoshi-confirmations) )^( p / (1-p)) with p = .8

the design clearly leads to a mining monopoly under any likely startup scenario.  Why would such a design attract interest from volunteer programmers?  After the very first roll of the die, isn't the new altchain reduced to an academic exercise in monopolist behavior?

Seems to me that until a mechanism is designed into the new protocol to prevent the "instant monopoly" problem, you're not going to attract interest from volunteer programmers (or anyone else for that matter) in an altchain.  Whether the mechanism is based on a y confirmation limit, an escrow scheme, growing p over time, or some other option, don't you think the issue has to be addressed before it's handed off to a programmer?

If you're saying that your formula above constitutes a sufficient design for implementation in the current network, then your ONLY problem is adoption.  Not trying to be a dick here, but since the bitcoin developers are among the first ones you'll need to convince of the merits of your proposal, you may want to refrain from posting things like "The bitcoin developers don't understand economics very well" going forward.