Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

To my limited understanding of Ethereum and Bitcoin, the network already has rules in place to punish nodes that misbehave or cheat. In the case of Bitcoin, that is part of layer 1 so it is independent of any application layers and thus it should always be at the core of the network.

With PoS cheating is likely to become a bigger issue [1], since with PoW the miners who get punished will have wasted their time and electricity.

Would be great to hear comments from more knowledgable people.

[1] https://twitter.com/hugohanoi/status/951762596255838209



Certain kinds of misbehavior are punished. If you mine an invalid block, everyone will reject it, and you won't get any reward (you burnt electricity and hardware time for nothing). It works the same in PoS -- if you mine an invalid block, then (depending on the protocol) either your entire security deposit will be destroyed (ouch!) or no one will build atop your fork and you won't have any mining reward (same as PoW).

Block validation can only enforce certain kinds of rules, such as:

* People can only spend outputs they have the private key for

* You can't spend an output that has already been spent

* The block reward has a predetermined size

There are other kinds of rules that we don't know how to enforce yet. For example, we might want the rule, "Always create blocks with the top n transactions that offer the highest fee per byte, out of all the new transactions you've learned about". The trouble is that we don't know how to prove that a miner has learned of a transaction over the network. (Maybe there was a network partition, or maybe their internet connection died for a minute-- how can we tell between those conditions, and the case where the miner learned of but ignored a transaction?)

The "misbehaviors" listed in the article fall into this category: things we might like to make rules against, but don't know how to (or know how to, but haven't bothered yet).


Proof of stake doesn't work in practice unless we can find a source of randomness that is globally available, non-influencable and everyone can agree on [1]. At the moment, that source of randomness is completely elusive. It might be possible to create a random source from some form of binary astronomical event which can be widely verified but it would have an incredibly low bit rate of new randomness. One possible candidate is randomly nulling pulsars [2]. Unfortunately, the equipment required to observe this phenomenon is probably not widely available outside of large observatories. Having said that the costs would still be lower than the energy costs of the Bitcoin network.

[1] http://www.truthcoin.info/blog/pos-still-pointless/

[2] https://arxiv.org/abs/1706.05407


Here is how I understand the argument made in the first link:

If you give people a certain block reward, say 1$ per year, then the capital they are willing to invest to gain that reward will be 1$ divided by the worldwide rate of capital returns at the given risk level.

The argument is that it doesn't matter if we are dealing with capital that is locked away in mining hardware + lost as electricity or in a smart contract. The total amount of "economic work" locked away will be the same.

I think that's correct. Proof of stake is not cheaper for the short-term economy than proof of work.

But what about the long term? 100 years? The kind of time frame that investors don't worry about, but we as mankind should?

I guess what I'm saying is that locking away capital today maybe has less long term damage than wasting extreme amounts of energy.


Can imagine a protocol for generating randomness to some arbitrary security level (at the expense of locking up security deposits):

(1) Anyone can decide to become a 'randomness provider' by putting up a large security depsoit

(2) Every epoch (some number of blocks), each provider chooses a private random number and commits to it by publishing its hash

(3) During the next epoch but, each provider publishes the random they committed to earlier.

(4) xor together all the random values. The result is a pseudorandom number everyone can agree on, and which should be sufficiently good for many applications include PoS selection

If any provider fails to publish the random number they committed to, they lose their security deposit and there is no random value provided for the associated epoch. The process starts over.

If you're worried about bribing attacks over all providers, recognize that all we need is a single altruistic provider to keep the system safe. Altruistic behavior may be rare compared to selfish behavior, but I think we can usually rely on its nonzero presence.

If you're still really worried that collusion could be going on amongst ALL randomness providers, just become a provider yourself.

It's possible for a provider to wait for all other providers to reveal their values, and then privately determine whether or not the final random value would be favorable to them; they then have the option of canceling the epoch by keeping their private value hidden and losing their security deposit. This option (in combination with a particular application, and the size of the security deposit of providers) puts a bound on what the random value can be safely used for (e.g., if it's for a lottery, the expected value of another truly random swing at the jackpot has to be lower than the value of a security deposit).


> If you're worried about bribing attacks over all providers, recognize that all we need is a single altruistic provider to keep the system safe. Altruistic behavior may be rare compared to selfish behavior, but I think we can usually rely on its nonzero presence.

You also need to be sure that the others don't ignore the single altruistic source.

In a byzantine system, you can't distinguish if somebody is offline or if the others are silencing him.


> You also need to be sure that the others don't ignore the single altruistic source.

Well sure, but the code people run listens to all the providers. Everyone is listened to automatically. That's part of the social consensus encoded in software. If you don't follow along, you end up on your own fork. That's how these systems work — e.g, you also need to make sure that people don't "ignore" the consequences of failed hash checks throughout a cryptocurrency codebase.

It would be quite possible to run your provider on a machine hidden somewhere, and inject your transactions to nodes at random points in the network. It'd be pretty tough to silence someone directly.

Miner censorship attacks, e.g. a 51% attack, are also possible (i.e., all miners, or a sufficient majority, refuse to mine your tx until the epoch ends). This kind of censorship threat is always present for all kinds of transactions; in theory they're particularly pernicious for protocols like this one that require a tx to be submitted by a deadline. But no one is claiming that these systems are completely invulnerable to a misbehaving majority of miners or validators.


I don't see any incentive to actually publish random values - wouldn't it be easier to just commit to and publish zero every time?


Altruism probably works here. It's cheap to pick a pseudorandom value. But if you didn't want to rely on altruism, the system could offer a reward to anyone who reveals the secret someone committed to early (half that provider's security deposit could be destroyed; the other half given over in reward to the reporter).


That's all well and good but who manages the security deposit?


The system itself, e.g. the code of a smart contract. Example implementation: https://github.com/randao/randao


So the randomness providers secure the deposit of their own randomness. The circularity of the system means it won't work in practice. RANDAO is secured by the proof of work miners.


Actually, this kind of "snake eating its own tail" loop is exactly how cryptocurrencies operate. For example, proof of work blockchains secure themselves by creating mining incentives with money that has value because it is secure.

It works because the system can regress over time, e.g. value at t=n can be used to secure a greater amount of value at t=n+1. (Although value needn't be strictly increasing for system to operate; if value decreases, so do the security requirements)


Publicly verifiable randomness is possible without relying on astronomical events. Check out threshold relay by the Dfinity team (which we're porting to Ethereum), or RandHound and RandHerd [1].

1 - https://eprint.iacr.org/2016/1067.pdf


That paper assumes that at most f out of at least 3f+1 participants are dishonest. In practice one can't make that assumption since sybil attacks are easy.


You can bootstrap a Sybil-resistant system using PoW or some other method. This is one building block.


How about using stock markets?

They are of course vulnerable to some amount of manipulation, but with a good algorithm that could be rendered sufficiently costly to become impractical.


They are probably as good as we have today but even they could be manipulated if large amounts of money was on the line. I can't see any way of introducing algorithms to make it more difficult to manipulate though.


> does this apply both to blockchain-style proof of stake and BFT - style proof of stake?


Both styles since both reward the creators of a block and both select the creators of a block through some form of randomness. So in both schemes there is an incentive to bias that randomness in your favour.


Doesn't BFT reward anyone that's validating a block? Meaning that everybody who validates the right block gets the same reward?

Or is there an extra reward for the creator?


Miners who cheat will be punished even more under PoS than under PoW, provided they are caught. If you get caught mining a "bad" block under PoW, you lose only the work that went into that block. If you get caught mining a "bad" block under PoS, you lose everything you staked on that block. It's almost as if you have mining hardware that doesn't use any electricity, but self-destructs if you misbehave.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: