Topic: Proof of stake instead of proof of work (Read 32542 times)

Yes, it is possible to have combined PoW + PoS system, and then PoW difficulty can drop to one to be soft-fork compatible. All that is needed is moving existing coins to some timelocked outputs. The coinbase transaction is timelocked-by-default to 100 blocks, so all miners are staking their coins for 100 blocks by default, but they can expand it as any other user, just by adding timelock.

So, that kind of transition is possible, but since PoS is unfair (if you have more coins, then you have even more coins) and it requires PoW miners to get rid of their power (and makes it impossible to compete for newcomers, because to have more coins, you need some coins, you cannot mine them without buying some amount of them first), it will simply never happen. And to be soft-fork compatible, all blocks have to meet the difficulty, so that PoW is still needed and cannot be entirely eliminated. But theoretically, yes, if everyone want PoS, it is technically possible to have a chain where PoW difficulty will drop to one and PoS will be activated by some kind of soft fork.

For now, Ethereum want PoS, let's see how they deal with it. I think that all PoW-to-PoS-transition-related things should be redirected to them, because it is more likely to happen there than on Bitcoin (also because Bitcoin miners have no reason to accept such things).

Times have changed and are changing. It is necessary to keep up with it.

bitcoin
bc1qvcth09djjldpq2eua60ea9vlcjpsnhzz7rk9ya

thats science!

Every post from @anunymint apparently was deleted.

Some of this thread was archived here and here.

It's so fascinating that my keyword search of "Proof of Stake," a very common part of the modern crypto lexicon, may have been born out of this thread started 7 years ago. It's a true testament to the open source nature of blockchain technology. I hope to see the continued success of crypto and look forward to being in the world that functions as a part of this technology.

I think, this historical topic is a good evidence that PoS is not a new idea just a matter of common sense in the most naive way ever: let's instead of consuming energy and spending costs secure the network with our reputation/deposit whatever, easy peasy  

This idea, PoS is trending now not because of its brilliance but because of PoW crisis, imo. Pools, ASICs, ... have ruined PoW and are getting more aggressive on a daily basis and governance is an unsolved problem and we can't improve, we can't evolve. Bitcoin is experiencing an ice age and it is so natural that naive ideas like PoS are becoming more popular.

I don't think PoS is a better idea so, it has been around for a long time, before bitcoin and PoW.

It can't do anything about inflation it shouldn't, it is just ridiculous to let coins to reproduce.

As of what op has suggested 7 years ago, PoS being adequate for transaction processing, I doubt it too ...

PoS has a centralization gradient, like what many claim about PoW (because of pools and ASICs) but for PoW there is cure  while PoS has no cure, it is of best interest of stake holders to form banks and cartels and let them decide about what or whose transactions to confirm or reject. Pos is nothing more than a cartoon of traditional banks, imo.

Of course, Proof-of-stake algoritm is much better than POW in efficiency, but it's the question whether we can implement it in Bitcoin network or not.

I think that it is much more likely that a proof of stake coin will displace Bitcoin than Bitcoin will transition to proof of stake. A lot of people are in Bitcoin for speculation not because of the protocol, if we.start seeing mass adoption of an alt they will flee out in to that lowering the price , but difficulty will stay the same.

I think the only consensus algorithm suitable for public chain is POW, take the dpos (used in EOS) algorithm for example, DPOS has many drawbacks, for example, if a witness node was controlled by a attacker, then the attacker can broadcast many conflicting block with the same block height, in such condition, the whole witness network would be split to many sub-network which are not compatible with each other, at that moment,
if the confirmations of these conflicting blocks is less than 2 / 3 of total num of witness, then the whole network would be suspended. you might say that if can not reach 2 / 3, the system has a timeout mechanism, but wait, if system allow one witness produce two height within a small interval, in some network edge conditions, the different witness would generate different LIB (last irreversible block), in a distributed network environment, There is no uniform time and confirmation number.

With this comment i want just mark this piece of crypto-history for myself.

Hi QuantumMechanic - I'm digitalindustry I have a lot of respect you and this idea of yours and was wondering where i could discuss further aspects with regard to sociology and psychology around the design and market place penetration of "Novacoin"  - my interest is primarily in economics and sociology policy and humans generally.

if any nice person could give me a direction , i'd like to perhaps contribute .

Thank you.   

I would propose a hybrid sytem which uses proof of work and proof of stake. Transactions would still be verified using mining but people would have to pay for mining rights.

Suppose that a 100 btc security deposit had to be placed for each bitcoin mined per year. Miners could send 100 btc to a time-locked escrow transaction. The escrowed coins could be sent to other addresses as escrowed coins. Anyone holding the private key to this time-locked transaction could mine up to one bitcoin per year. The mined BTC can be spent immediately. Miners could request a withdrawal of the escrowed btc, but the request would be subject to a 6 month time lag. During the 6 month lag, no minng would be allowed and the escrowed coins could not be sent.

Initial distro could be handled by grandfathering in all existing btc accounts in a new blockchain. Users would have say 6 months to download a new client. The new client would begin enforcing the escrow rule at the end of the 6 months. Accordingly it would refuse to validate new coins except for the coins that had been grandfathered in.

Are there technical obstacles to this system?

Note: i know that this could not accommodate the current btc generation schedule since the system would place an upper bound on money supply growth of 1% per year. Just ignore this issue for now.

Edit: I think my questions were answered in this post http://forum.bitcoin.org/index.php?topic=28565.msg363945#msg363945

My curiosity won't stop nagging, so here's some bounties

Thanks for the link!

Please forgive all the parentheses in the following...

The first two problems you listed I think can be avoided by treating votes just like bitcoins, but having "election cycles" to compensate for their irretractablility.  For every election cycle (measured by some fixed number of blocks that is limited by the cost and time of running an election), every bitcoin address (or a uniquely determined address, so that bitcoin-containing private keys don't have to be network facing) is issued an equal number of "votecoins".  (Can actual blockchain-recorded transactions be avoided for this issuance?  Can it be done by an understanding that spends from the determined votecoin address up to the amount contained in the determining bitcoin address at the start of the election cycle are allowed during the the election cycle?)  During the rest of the election period, the network will accept votecoin transactions only for those issued during the current election cycle, until the end when some fixed number of addresses containing the most votecoins are elected to be the "representatives" during the next election cycle.

I'm not sure how resource intensive this search for the top votecoin containing addresses would be.

Perhaps voter participation could be incentivized using some portion of the transaction fees and newly issued bitcoins.  I'm reluctant to propose schemes to do this, though, since all the ones that I can think of don't really produce the right incentives, and also create perverse ones.  The larger bitcoin holders obviously have an interest in delegating their votes, but hopefully a really simple UX (vote delegation needs to be automated every election cycle according to user inputted delegates and weightings) and some peer pressure/annoying requests from the client/P. Diddy would be enough to motivate the rest.  Then again, maybe it won't matter if a bunch of the bitcoin-poor don't care enough to vote.

Notice that the public nature of the votecoin transaction history would help keep the delegates honest/effective.

Also note that storage requirements shouldn't be an issue since votecoin transactions from old election cycles don't need to be held on to.

Miners still seem to be necessary to keep time and bundle transactions, but the hashing power/reward they require could possibly be minimized the elected representatives' ability to regulate/make recommendations in the block selection process.

And if all the representatives are really doing is making recommendations to miners, then wouldn't only the miners have to be checking their signatures, usually?  This could allow for a much greater diversity of representatives, since the miners are already geared to accommodate higher overhead than clients.  I figure the only time the clients would need to check the signatures of the representatives is if the miners wanted to ignore the representatives en masse, creating a longer fork, and the clients wanted to ignore this longer fork.  But this might become too likely an attack vector if a significant amount of the overall hashing power of the miners is made obsolete by this system.

And if it's just recommendations, then would any of this require a separate blockchain/breaking change to the protocol?  Can the votecoin rules (their periodic creation and finite trading period) be accommodated somehow into the existing protocol?

Edit: From Mike, "There is a method of batch verifying ECDSA  signatures that's much faster than normal. It might change the economics of what you want to do: http://www.springerlink.com/content/h758580006764h26/ "

I was thinking a future Bitcoin client would need a screen of trusted certificates - sort of how your web browser already has one for SSL (well hidden), that helps it decide whose signatures are trusted, and can ultimately be controlled by the user.

Today, it is already a major pain in the ass to redownload the block chain, which takes hours, presumably while every single signature for every transaction is checked.  Yet, if I trusted a certificate from Gavin Andresen, and Gavin published a checkpoint certificate vouching for the correct hash of block 130,000 (for example), and this was relayed in a future version of the p2p protocol, then my client could just accept all blocks before that as valid without checking every bloody signature in every block.  And if I as a user didn't like or trust that behavior, I would merely remove Gavin's public key from my trusted certs list, or add a key of someone I trust more, the same way I can do this with SSL CA certs in my browser.

By the way, if you're interested in delegated voting, I wrote a paper on using it in a democracy some time ago:

  https://docs.google.com/document/pub?id=1jidmNJHWAtsPLCUD7EPPm8jOEV93kSXbZOMycqCWOyA

I think delegating voting is a great idea. I'm less convinced that it would work for replacing hashing in the block chain, but it might.

Some more problems for you to consider:

• If I control a key with 10 delegators, then I spend that key to 10 new keys, what happens to the delegations? Does it make sense for a key to have fan-out (ie 1 key to delegate to 10 other keys)? Do you split the value evenly or not?
• How do you efficiently detect and resolve delegation loops? ie, key A delegates to B, B delegates to C and C then delegates to A? You have to do this efficiently because otherwise setting up new delegations is a way to DoS the system. Note that detecting cycles in a large graph is slow, Tarjans algorithm is O(number of edges). If each key in the system takes part then every new address in the system potentially makes setting up new delegations harder. As the number of keys in the system grows without bound over time, that could be an issue
• Keys are owned by end users who may or may not know/care about the inner workings of their currency. How do you get new users to delegate appropriately?

It should be possible to run a parallel block chain based on proof-by-stake, but using the same transactions. It could be done with an adapted Bitcoin software. Once such a chain was up and running you could compare the results vs the existing chain.

I don't have the time/energy to do this myself.

It sounds like it could scale to more than just a few.  And the voting power might flow much more easily away from corrupted players than with SWIFT due to the almost zero barriers to retracting votes, and to enter into the market to supplant the established delegates.  Remember, with delegated voting you don't necessarily give your vote directly to who will eventually cast it - you can just pass it on to someone you trust, hopefully solving the problem of rational ignorance/apathy.  That or the bad guys will just buy up all the votes  Or maybe the good guys will?

I guess the relevant question is if this would do a good enough job of decentralizing the "voting power" and making it accountable?  If so, the benefits listed above (that have survived) seem pretty significant.  It might at least be a good approach to smaller blockchains that don't expect to attract enough outside computing power to keep them secure.

That is good to hear!  I understand that proposals from people who obviously aren't qualified to program the shit they propose, not to mention that most of what they propose is indeed shit, probably gets pretty annoying.

Not at all!  I quite appreciate your thoughtful responses!

If there are relatively few delegates then what you have is effectively similar to todays payment networks, in which a few big players with pre-established trust relationships come to a consensus on who owns what between themselves. You'd have invented an open source SWIFT.

Bitcoin is somewhat like that as well today due to the (unforeseen) power of the pools. But there are workable proposals for breaking that power and restoring Bitcoin to many thousands of voters again instead of just a few. They haven't been implemented but that's because talk is cheap, whereas working C++ isn't.

By the way, I'm not trying to pour cold water on your idea. Proof of stake doesn't seem like an inherently bad idea to me, and I think everyone agrees proof of work seems wasteful, even if in the end it's less wasteful than the current financial systems. But there's a huge gulf between "how about this?" and a working system that scales.

If there are relatively few delegates, and if they could each store their votes in single addresses, this could save a significant amount overhead for the network as a whole during voting/checking.

I suppose stakeholders by definition have an incentive to delegate their votes in such a way as to minimize the overhead in the network, but could this alone lead to some stable equilibrium?

Maybe you could also cull some necessary amount of the least influential addresses in the vote in order to help to reduce overhead to a workable amount?

I'm not sure if there's a transaction signing scheme to deal with retracted votes though, so I don't know if such a delegated voting scheme can even work.

You need to run some simulations to prove out your theories first. I agree with hashcoin, this idea is one that is intuitively "obvious" but I think it will fail when you run the numbers.

Consider that there are people today who have some non-trivial fraction of the entire chains value under their control (like MtGox). So to have any confidence in a chain you really need a lot of value to sign over it. That means huge numbers of keys.

An ECDSA verification takes around 2-3 msec today:

  https://en.bitcoin.it/wiki/Scalability

Assuming 2msec you can check 500 signatures per second. 500 keys is obviously not enough to accumulate enough value to have much trust in that block. You'd probably need hundreds of thousands of keys. That's a problem because if we assume a block every ten minutes then we can check at max:

  10 * 60 * 500 = 300,000 keys

before we are spending ALL our cycles doing nothing but figuring out how many people signed the  block and can no longer keep up with the chain.

This isn't even taking into account signing time, storage or bandwidth.

Not every Bitcoin address in existence. Just those with a large number of bitcoins. And it needn't be for every block.

This is exactly why I say this should be used in conjunction with hashing. A small amount of proof-of-work provides the skeleton and protection against casual double-spends, while proof-of-stake provides an occasional rock-solid confirmation against massive attacks.


Nobody knows exactly how to prevent miners from including low-fee transactions, and hence, making sure people pay fees. Even if we figure it out, if we want transaction fees to remain low enough, there will be little incentive to mine, making the overall hashing capacity low. Thus the network will be vulnerable to attack, and people will not be able to safely send large amounts.

I see this as a major problem, which the inclusion of proof-of-stake, done correctly, can solve.

Haha, I thought it felt a bit too obvious.  Well at least I have a greater, more justified, appreciation for Bitcoin now.

This whole thing actually came from thinking of a way to solve the checkpoint problem Ben Laurie wrote about.  If votes don't need to occur very often, then would the bandwidth/checking cost be such a big deal?  Is his issue even really a problem?

I think a hybrid approach would only allow stakeholders to sign whole blocks that have already been found.  And then miners could defer authority to the stakeholders when they do, and work forward from that block.  This would decrease the confirmation time to 10 minutes on average.  And it would remove the need for checkpoints, making Ben Laurie a happier camper.

This is the obvious way to do consensus, that doesn't work because of the massive amount of bandwidth needed to have a vote for every bitcoin address in existence.  Keep in mind everyone needs to do this checking too.  The entire point, and clever part, of bitcoin, is the idea that one can trade bandwidth/digital signatures for CPU-intensive "hash signatures" that are very small and easy to verify.

In other words, if you asked someone to design a system like bitcoin before bitcoin came out, what you propose is what most would have said...

Another thought: Currently there's a problem with very large transfers, since guarding them against double-spending can take days (at least) of confirmations. Paying transaction fees won't help because it can only get it in a block faster, it can't significantly affect block generation rate afterwards.

With the new system (work/stake hybrid approach), senders of large amounts can include a signature fee in addition to the regular miner fee, which goes proportionally to stakeholders who sign the block in which the transaction appears. This will incentivize stakeholders to sign, making the transaction secure without having to wait for more confirmations.

I think a fork is more appropriate, since it incentivises the existing userbase to participate and avoids alienating them, and it solves the initial distribution problem, allowing for a very diverse voting group from the start.  I see Bitcoin as having made some progress at solving the social problems (bootstrapping a new currency) just as much as it has solved the technical ones.  No need to throw this progress away IMHO.

But Ben Laurie would be much happier

This is vulnerable to attacks on the network topology. You can "fake" a Bitcoin node, you can't fake having bitcoins.

I need to look more closely into the current implementation though.

We already have this in the form of checkpoints in the client software.  You don't need voting for it, because there is no ambiguity or controversy about the identity of the block hundreds of steps ago.    Better to have a check performed by _everyone_ than just people that happen to have a lot of bitcoin already.

This is brilliant. Of course there's still a lot of work to figure out if it's technically feasible and resistant to manipulation, concentration of power etc. But it could solve a lot of the problems Bitcoin will face going forward.

This change is significant enough to warrant a new genesis block rather than forking the current chain. This leaves the problem of initial distribution. Mining serves the purposes of both transaction validation and initial distribution, so if validation rights depend on current possession it will obviously be problematic.

I think this will work best together with, rather than instead of, hash-based mining. Blocks are confirmed with hashing as normal; this is enough for casual double-spend attempts. When a block is old enough, stakeholders can sign it. If a major attacker tries to build an alternative branch, clients will reject it because it conflicts with a branch already signed by stakeholders. This will create a much lower mining requirements for a given level of security.


I'll go as far as saying that if this pans out and is indeed novel, you deserve a place right next to Satoshi in the annals of Bitcoin.
(Edit Nov 28 2013: I retract that last statement... Sure, it's a great idea and all, but a place in the hall of fame requires a bit more than that. Also I'm not sure how novel the idea really is.)

This alternative wouldn't need computing power - that's the point.

Furthermore, if you want more influence in the current system, all you have to do is buy yourself more computing resources.  Morally not much different than buying yourself more bitcoins AFAICT.

Lastly, if the bitcoin-rich (as opposed to the computing power-rich) started "voting" themselves more new bitcoins than the allowed amount, then people would lose confidence in the currency, and the bitcoin-rich would no longer be rich in any meaningful sense.  They have more incentive to maintain the currency's value than the current miners do, it seems.

Company shares sounds like a great application, too.  The proof-of-stake alternative seems like it could be a good way to prevent unwarranted outside influence from messing with smaller scale public ledgers like they can with proof-of-work.

This unwarranted outside influence also seems to be why alternative Bitcoin implementations don't seem feasible now - you need enough miners to be on board to secure the network against outside attackers, whereas attackers can only come from within using the proof-of-stake alternative.  All it needs is a sufficiently diverse userbase.

This is relevant to Bitcoin as an alternative means of forming consensus on the valid transaction history, or the public ledger at least.  But all it would necessarily borrow from Bitcoin is the public ledger contained in the block chain, in order to co-opt its userbase.

It would save a lot of computing power, but it doesn't solve the core problems of defeating double spending and attracting more compute power to the network to check against that spending. Even if there were random elements, I think peer-to-peer voting(even if done by the software itself) would be too easy to game and unduly favor dishonesty and cheating. It would make trust = wealth, which is a fallacy because what if all those private keys contained stolen bitcoins, etc?

The idea has a huge amount of merit, not necessarily for Bitcoins.

Suppose I start a company and decide to issue its shares as a block chain.  Instead of miners getting 50 shares each, the block chain would be programmed where I just issue all the shares up front to the proper shareholders, etc.  The block chain is used as a means to buy and sell the shares on the peer-to-peer stock market (which doesn't exist yet).  Miners maybe get transaction fees.

In such a case, proof-of-stake voting might be fantastic.

But I don't see what relevance it would have to Bitcoins as they are now known.

I've got an idea, and I'm wondering if it's been discussed/ripped apart here yet:

I'm wondering if as bitcoins become more widely distributed, whether a transition from a proof of work based system to a proof of stake one might happen.  What I mean by proof of stake is that instead of your "vote" on the accepted transaction history being weighted by the share of computing resources you bring to the network, it's weighted by the number of bitcoins you can prove you own, using your private keys.

For those that don't want to be actively verifying transactions, and so that not all private keys need to be facing the network, votes could be delegated to other addresses via some kind of nonstandard Bitcoin transaction.  In this way, voting power would accumulate with trusted delegates instead of miners.  New bitcoins and transaction fees could be randomly and periodically distributed to delgates, weighted by the number of votes they've accumulated, thereby incentivising diversity of the delegates and direct voters.

If the implementation could be done, it proved to maintain at least a similar level of privacy and trustworthiness, and it only minimally complicated the UX, I'm thinking that a proof of stake based fork could out-compete a proof of work one due to much lower transaction fees, since its network wouldn't need to support the cost of the miners' computing resources.  (Note that the vote delegation scheme has bandwith/storage overhead that would offset these savings by some amount which would hopefully be relatively small.)

Some other potential improvements this system could offer:

• Possibly quicker, more definite confirmation of transactions, depending on how it can be implemented.
  
• The "voting power" may be more trustworty, since it would accumulate in a bottom-up fashion via a network of trust, instead of in the somewhat arbitrary way it accumulates now.  (Note the potential problem of vote-buying here.)
• It would remove the physical point of failure of bitcoin mining equipment, which can be confiscated or made illegal to run.
• It could be used to provide stakeholders a means of making their voices heard (via the delegated voting system it establishes) when it comes to proposals for software updates and protocol changes.

Anyway, I just wanted to throw the idea out here to see if there are any obvious reasons why it couldn't be implemented, and to hopefully spark a discussion amongst those better qualified than me.

Cheers.