Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

spectrum.ieee.org

Post reply on HN
Print view View original

271–280 of 301 posts

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#271

Post by kerkeslager »

billytetrud wrote: post #259
kerkeslager wrote: post #243

Earlier quoted context omitted.

The unstaking transaction can be on both chains and it's irrelevant to the attack. What matters is that a history exists starting from a block validated by the cheating validator. The fork starts from before the unstaking transaction. That's not a difficult thing to reason out, but you wouldn't have to reason it out if you had read the paper I linked.

> The fork starts from before the unstaking transaction. So what? The fork wouldn't be built on by anyone but the attacker. Any new entrant would have software that expects a blockchain being built substantially faster (or with substantially higher difficulty). > you wouldn't have to reason it out if you had read the paper I linked. I have read Peolstra's "pos.pdf" that PoS detractors incessently reference multiple t…

> Any new entrant would have software that expects a blockchain being built substantially faster (or with substantially higher difficulty).

"Difficulty" isn't a thing in PoS. Provable random functions that choose validators always have fallbacks, because if they didn't, a single absent validator would bring the entire chain to a halt.

Repeated fallbacks would look suspicious, so a smart attacker would simply neglect to include transactions from the real chain that transfer money or power away from addresses he controls, which would quickly lead to >50% ownership of the fake chain. It would be impossible to distinguish this on-chain from a real validator drop event (such as an AWS US1 East outage).

> He doesn't consider that hard coded checkpoints handily solve the problem of long-range revisions.

Hard-coded checkpoints do absolutely nothing to address this issue. If you're requiring that the checkpoints come from a trusted entity, you've just given up decentralization. If you're not requiring that they come from a trusted entity, then they can be spoofed just as easily as a block.

Instead of reading a paper and immediately believing what it says, you need to try to think like an attacker and see how you would try to get around the "solution". There's likely not a paper written on this, because it's so trivial to get around that it really doesn't require a paper to refute. The fact that you presented this idea non-ironically seriously undermines your credibility.

FWIW, I'm not a PoS detractor. I'm quite excited for Ethereum's implementation of PoS, because if anyone can solve the issues with PoS, it's the Ethereum team. My current thinking is very much in the "wait and see" camp.

Weak subjectivity with PoS is a real thing (if you don't believe me, perhaps you should listen to Vitalik Buterin, who cannot be accused of being a "PoS detractor"). What remains to be seen is how much of a problem it is in practice. The release of Ethereum 2.0 will be the largest full-scale test of a mature implementation, but depending on how quickly full roll-outs of PoS happens for Cardano or Polkadot happen, one of them may get there first.

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#272

Post by DennisP »

sparkie wrote: post #182
DennisP wrote: post #151

Earlier quoted context omitted.

The same thing happens in PoW networks. You have to wait several blocks to gain confidence that a transaction won't be reverted. In Ethereum's PoS, by waiting a similar amount of time you actually get finality; at that point your transaction cannot be reverted without a third of total stake being destroyed.

Unless Vitalik proposes a rollback.

And gets support for that rollback from a large majority of the community.

Given that level of community support, the same could happen in any PoW network.

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#273

Post by micropresident »

ywei3410 wrote: post #181
danbruc wrote: post #180

Earlier quoted context omitted.

Yes and no. Yes, proof of works prevents double spending or more generally establishes consensus on which transaction become accepted. But no, this could be achieved with many different consensus protocol and does in general not require any irrecoverable loss. Just issue a key pair to each human and make them send signed votes to establish consensus by simple majority. The true reason something like proof of work is…

For context, this is usually known as a 'Sybil attack'. [1] https://en.wikipedia.org/wiki/Sybil_attack

This is a common mistake w/r/t Proof of Work. It doesn't prevent Sybil attacks. The Bitcoin whitepaper performs slight of hand to say "instead of identities, we'll use CPUs" which are obviously what Sybil attacks are in the first place. One person can own lots of CPUs... (Thus mining operations.)

What it does do is make Sybilers larger and larger shareholders in the network to make it so that the more you Sybil the network the less you'd want to try to damage it.

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#274

Post by acjohnson55 »

dolmen wrote: post #206
acjohnson55 wrote: post #153

Technically, the consensus mechanism is the mining lottery, which is how transaction order is finalized, preventing double spends. The scheme for commitment of a scarce resource (e.g. PoW, PoS) is the Sybil resistance scheme, which is what makes lottery participation conform to some notion of fairness. You have to buy your lottery tickets.

Can you win at the BTC mining lottery with just one ticket? Is it worth mining with a slow machine?

Sure, you could. But much like the real lottery, it's not worth playing a game that has negative expected value. At this point, my understanding is that mining BTC with anything other than an ASIC is not going to be worth the cost in electricity.

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#275

Post by billytetrud »

kerkeslager wrote: post #269
billytetrud wrote: post #258

Earlier quoted context omitted.

Again, that's simply not true. Let's go through the hypothetical attack: 1. The attacker accumulates some coin then spends it / sells it. 2. The attacker starts building a chain using their old keys 3. The attacker presents this chain to a new entrant that they've eclipsed 4. The attacker buys something from the eclipsed victim Any self respecting PoS protocol would have long cooldowns that would force step 1 and ste…

1. The fact that 1 and 2 are far apart is irrelevant to nodes that were absent for the two steps. It's true that this requires a long absence, but given many people disconnect cold storage wallets for years , we can't rely on this for security. Indeed, the time when you most need to be able to distinguish between real and fake chains (because your cold storage wallets are likely to be your most valuable) is when your…

> many people disconnect cold storage wallets for years

Yes, and when they come back, they should update their software - which should have a hardcoded checkpoint in it from much more recently. That's the solution that you're repeatedly ignoring.

> a PoS attacker who creates a blockchain can emit blocks at a very high rate

You're just wrong. Show me a single active PoS protocol that works this way. You won't be able to because that's not how it works. No one else would accept most of these blocks. Why are you so sure about yourself when you clearly have enormous holes in your understanding of how PoS protocols work in general?

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#276

Post by billytetrud »

kerkeslager wrote: post #271
billytetrud wrote: post #259

Earlier quoted context omitted.

> The fork starts from before the unstaking transaction. So what? The fork wouldn't be built on by anyone but the attacker. Any new entrant would have software that expects a blockchain being built substantially faster (or with substantially higher difficulty). > you wouldn't have to reason it out if you had read the paper I linked. I have read Peolstra's "pos.pdf" that PoS detractors incessently reference multiple t…

> Any new entrant would have software that expects a blockchain being built substantially faster (or with substantially higher difficulty). "Difficulty" isn't a thing in PoS. Provable random functions that choose validators always have fallbacks, because if they didn't, a single absent validator would bring the entire chain to a halt. Repeated fallbacks would look suspicious, so a smart attacker would simply neglect…

> "Difficulty" isn't a thing in PoS

Yes it is. The more people with coins actively minting in the system, the higher the difficulty of getting chosen. Please do more research.

If you really want to keep discussing this with me, read through the WHOLE of https://github.com/fresheneesz/validatedProofOfStake and show me a full attack on it.

> FWIW, I'm not a PoS detractor.

You could have fooled me. But it sounds like you're saying you believe in Vitalik, and anyone else on the internet (ie me) must be idiots who can't understand solutions to these problems. Yet, you're not putting in the effort to understand the solutions out there. PoS protocols are more complex than PoW - there are more edge cases to shore up. So telling me you can "trivially" get around any particular solution ignores the fact that solutions work together. They aren't isolated. So slow down and actually try to understand a protocol holistically before attacking it. If you're not a detractor, than how about just trying to learn instead of insulting the intelligence of people who have actually worked on solutions to these problems?

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#277

Post by hypertele-Xii »

rmtech wrote: post #148
hypertele-Xii wrote: post #135

Earlier quoted context omitted.

I don't get it. Suppose a bad actor tries to double spend. They have to cryptographically sign both transactions, so the whole network will eventually receive knowledge of both transactions. Why can't the network simply wait for some duration of time before accepting a transaction, to verify that no double-spends propagate from elsewhere? If double spending is ever detected from a party, that party is dis-trusted by…

The problem with waiting AFAIK is that it's vulnerable to attacks on the underlying peer-to-peer network. Let's say you wait 1 hour to see whether there was a double spend. If an attacker wanted to, they could spend twice and somehow mess with the network for 1 hour. For example, an attacker at the internet service provider could intercept packets from the Bitcoin network and just block the other spend transaction fr…

Obvious fix, peg the time limit to measured network throughput.

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#278

Post by hypertele-Xii »

Marazan wrote: post #192
hypertele-Xii wrote: post #135

Earlier quoted context omitted.

I don't get it. Suppose a bad actor tries to double spend. They have to cryptographically sign both transactions, so the whole network will eventually receive knowledge of both transactions. Why can't the network simply wait for some duration of time before accepting a transaction, to verify that no double-spends propagate from elsewhere? If double spending is ever detected from a party, that party is dis-trusted by…

There is no such thing as dis-trusted. Bitcoin is "trustless". There is no trust of any form.

Public keys identify wallets. Key X tries to double spend, it is detected, proof propagates across network, nodes vote to insert into the consensus ledger a public record that key X has been "dis-trusted". The network thenceforth rejects transactions from wallet identified by key X.

Now key X has been dis-trusted.

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#279

Post by kerkeslager »

billytetrud wrote: post #275
kerkeslager wrote: post #269

Earlier quoted context omitted.

1. The fact that 1 and 2 are far apart is irrelevant to nodes that were absent for the two steps. It's true that this requires a long absence, but given many people disconnect cold storage wallets for years , we can't rely on this for security. Indeed, the time when you most need to be able to distinguish between real and fake chains (because your cold storage wallets are likely to be your most valuable) is when your…

> many people disconnect cold storage wallets for years Yes, and when they come back, they should update their software - which should have a hardcoded checkpoint in it from much more recently. That's the solution that you're repeatedly ignoring. > a PoS attacker who creates a blockchain can emit blocks at a very high rate You're just wrong. Show me a single active PoS protocol that works this way. You won't be able…

> Yes, and when they come back, they should update their software - which should have a hardcoded checkpoint in it from much more recently. That's the solution that you're repeatedly ignoring.

Setting aside for a moment the fact that users cannot be relied upon to update software, do you understand how this isn't a decentralized, trustless solution? If you're willing to download a checkpoint from a trusted, centralized entity, why even bother with decentralization? Why not just have the US Government sign blocks?

> You're just wrong. Show me a single active PoS protocol that works this way. You won't be able to because that's not how it works. No one else would accept most of these blocks.

Well, let's start with Cardano, Polkadot, or Tezos. Yes, all of these chains enforce a delay between blocks: the way they enforce that is that no one accepts blocks before they're supposed to, i.e. consensus.

...which is completely useless when you're entering the network and receive two conflicting blockchains, because you have no way of verifying when any of the blocks were validated. Consensus doesn't help you, because you don't know what the consensus is.

Show me a single mechanism in existence that can allow me to look at two blockchains and reject one based on the fact that the blocks were mined too quickly. Hint: it exists, but you're not going to like what it is!

Re: Cryptocurrency Blockchains Don’t Need to Be Energy Intensive

#280

Post by kerkeslager »

billytetrud wrote: post #276
kerkeslager wrote: post #271

Earlier quoted context omitted.

> Any new entrant would have software that expects a blockchain being built substantially faster (or with substantially higher difficulty). "Difficulty" isn't a thing in PoS. Provable random functions that choose validators always have fallbacks, because if they didn't, a single absent validator would bring the entire chain to a halt. Repeated fallbacks would look suspicious, so a smart attacker would simply neglect…

> "Difficulty" isn't a thing in PoS Yes it is. The more people with coins actively minting in the system, the higher the difficulty of getting chosen. Please do more research. If you really want to keep discussing this with me, read through the WHOLE of https://github.com/fresheneesz/validatedProofOfStake and show me a full attack on it. > FWIW, I'm not a PoS detractor. You could have fooled me. But it sounds like yo…

> Yes it is. The more people with coins actively minting in the system, the higher the difficulty of getting chosen.

I'm well aware. But eventually a large validator will get chosen--it's not difficult to get chosen, it's rare. The fact that PoS folks call this "difficulty" does not make it so.

> If you really want to keep discussing this with me, read through the WHOLE of https://github.com/fresheneesz/validatedProofOfStake and show me a full attack on it.

Given your proposed solution is checkpoints from a centralized trusted entity, you're giving up decentralization. Sure, your solution works. If you don't trust the source of the checkpoint, you're back to square one--it no longer works. And if you're willing to give up decentralization, may I suggest you just store all transactions in Postgres? You don't need a blockchain if you're just going to trust a centralized entity.

I'm not going to give your design a free audit. If there's some way this isn't centralized, feel free to explain, otherwise, this isn't relevant--I think we can assume that PoS is being discussed in the context of decentralized, trustless models.

> If you're not a detractor, than how about just trying to learn instead of insulting the intelligence of people who have actually worked on solutions to these problems?

I haven't insulted your intelligence. You're probably a smart guy. Which is probably why you're overconfident in your solution: smart people aren't used to being wrong, so you aren't taking the time to actually grok the attack I've already proposed, or why the only working solution you've actually proposed depends on centralization.

I did question your credibility to make claims here, because it's pretty clear you either don't understand the attack proposed by On Stake and Consensus, or you don't understand decentralization, which are both fundamental prerequisites to this discussion. The time constraints defense is literally in the paper, and the checkpoints solution you've proposed is just proof of authority by a different name. If you choose to feel insulted by someone saying you're wrong, that's your prerogative.

Post reply on HN