[Laforet]

Is the threat of long range attacks in PoS any worse than PoW in practice?

Bitcoin for example still relies on a list of hardcoded nodes for bootstrapping clients. Not to mention very few people actually bother to verify the full chain (360GB and counting) from genesis.

As for auditing the the integrity of the code or binary, it is signed by GPG keys hosted on public key servers accessed using X509 certificates pinned by a a couple of trust anchors preloaded in your OS. So much for distributed consensus...

[inter_netuser]

> As for auditing the the integrity of the code or binary, it is signed by GPG keys > hosted on public key servers accessed using X509 certificates pinned by a a > couple of trust anchors preloaded in your OS. So much for distributed consensus...

You can literally validate the entire chain with a simple python script. Millions of those on github.

>Not to mention very few people actually bother to verify the full chain (360GB and counting) from genesis.

Absolutely wrong. The chain is validated in its entirety upon first sync. 100% from genesis to tip.

>Bitcoin for example still relies on a list of hardcoded nodes for bootstrapping clients.

It doesn't. Longest valid chain with most work is the canonical chain. Hardcoded seed nodes exist to speed up the discovery.

[tromp]

> You can literally validate the entire chain with a simple python script.

I challenge you to present a "simple python script" that implements the exact bitcoin consensus rules (as codified in bitcoin core). Bitcoin is not all that simple and there's a nontrivial amount of complexity in bitcoin script alone [1].

> The chain is validated in its entirety upon first sync. 100% from genesis to tip.

The default behavior is to skip signature verification for all signatures before some relatively recent block [2].

[1] https://github.com/bitcoin/bitcoin/blob/master/src/script/in...

[2] https://github.com/bitcoin/bitcoin/pull/9484

[Kranar]

You're misunderstanding the default behavior which is fine becaue it's commonly misunderstood and discussed. At any rate signature verification is not skipped by default, what assumevalid skips is script verification. Everything else including UXTO, proof of work, the transactions themselves, are validated.

[dlubarov]

That seems a bit pedantic; the client itself prints

> Assuming ancestors of block %s have valid signatures.

when using -assumevalid. I agree it's imprecise, but it's not exactly wrong, since skipping scripts implies skipping signatures.

[ricardolopes]

The Bitcoin Core client includes a hardcoded list of DNS servers that point to thousands of nodes. These lists get updated frequently by different people. Other clients may use other lists. What is the threat model you're suggesting here, exactly? Do you know any other way to bootstrap a peer to peer network without centralised authorities?

All network participants are forced to verify the full chain from genesis. Some might be OK with validating block header signatures only, and not the full transaction set. It's a tradeoff.

You don't need to use those public key servers if you somehow distrust the CA certificates in your OS. Feel free to contact the repository maintainers or whatever else floats your boat.

Anyway, bitcoin is an open source protocol, not a particular client implementation. If you distrust everything and everyone, no one can stop you from building your own client that works with the rest of the network.

[comex]

> Do you know any other way to bootstrap a peer to peer network without centralised authorities?

I’m not the parent, but – no, I don’t. But that’s exactly the point. The need to bootstrap from centralized authorities is what’s supposedly so bad about weak subjectivity in proof-of-stake. Yet in practice, it’s needed with proof-of-work as well.

[ricardolopes]

Maybe I didn't word it right, but I wasn't calling bitcoin's method reliant on centralised authorities, just asking if there were more methods out there that weren't as well.

Bitcoin is an open source permissionless protocol, so you have multiple clients to chose from, each with their own list of bootstrapping nodes, many open source where you can submit a PR to add your node too. You can even build your own client and point to whatever you want. You can also just ignore them and just point directly to nodes in a list from a public forum, a private chat, whatever.

Also, you're not just connected to those bootstrapping nodes: you use them to find the rest of the peers in the network.

[colordrops]

It seems that PoW is like recursion. You don't get it at all until you completely get it. It's a leap to understand it and somehow many very technical people don't understand a seemingly simple protocol even a decade after it became mainstream and is threatening national banks due to the very characteristics these people claim it doesn't have.

[inter_netuser]

Indeed, a very strange phenomena. Willful ignorance?

[comex]

> Bitcoin is an open source permissionless protocol, so you have multiple clients to chose from, each with their own list of bootstrapping nodes, many open source where you can submit a PR to add your node too. You can even build your own client and point to whatever you want. You can also just ignore them and just point directly to nodes in a list from a public forum, a private chat, whatever.

I characterized this as relying on centralized authorities (albeit several of them), but sure, it can also be considered decentralized to some extent.

The point is that it's a mechanism outside of the proof-of-work network itself. Instead of relying on a machine to reach consensus via a formal protocol, you the human are probing for a social consensus by evaluating statements made by other humans (via GitHub, public forums, or private chats, or just talking to people in person).

In both proof-of-work and proof-of-stake, you need to find social consensus in order to initially obtain the software, after which point you can rely on the network's consensus.

The difference with proof-of-stake is that you have to redo this if you disconnect from the network for months on end.

In practice, for a variety of reasons, practically all users of cryptocurrencies download regular software updates, and thus continue to rely on social consensus, regardless of whether the currency is proof-of-work or proof-of-stake.

[yanmaani]

I want to take a moment to note what you're doing here. You're making a negative argument, in want of a better word. It goes something like this:

1. X is a problem?

2. But Y is also a problem, in my opinion.

3. X and Y are both the same, I think.

4. Therefore X is not a problem.

We can - theoretically - verify the correctness of PoW software by downloading the source code, reading it over, etc. We can also refuse to update, reducing ourselves to SPV security. We can internally verify the checkpoints using 100% objective standards. There are other things as well. This is not the case for PoS, where our "signature A existed at time B" has to be taken as faith, or evidence of things unseen. There is no internal way to verify the veracity of such a statement.

The fact that users aren't personally doing this, is not the same as saying it makes no difference whether they are able to or not. I'm not personally going to withdraw all the money in my bank account - that would be ridiculous - but if the bank informed me I was no longer able to withdraw the money in my account, that would not be suitable at all. The assurance that I can do it makes it so that I don't have to.

[dlubarov]

> 3. X and Y are both the same, I think.

It seems like you reject this premise, maintaining that PoW networks are objectively verifiable? But you didn't really refute the parent's point there, which was that there are no "objective standards" in deciding which bootstrap nodes to use; it's ultimately a matter of trust. If I trust the wrong bootstrap nodes, I can be eclipsed from the real network.

Granted, I only have to trust that a single bootstrap node from the list will faithfully connect me to the honest network. But PoS involves a very similar 1-of-n trust model; I can request checkpoints from n semi-trusted sources and check that they match.

Also, granted, if I pick bad bootstrap nodes, I can still detect if I'm being eclipsed by looking at the hash rate. But how do I know what hash rate to expect? I could check n websites with hash rate charts, but that brings us back to 1-of-n trust.

> 4. Therefore X is not a problem.

IMO it's a manageable problem. Users just need to be cognisant of these trust assumptions they're relying on, and be thoughtful about picking semi-trusted peers (whether bootstrap nodes or checkpoint providers).

[Laforet]

Hi Nick, very well said and this is precisely my point as well.

Satoshi tried to convince us that we could decentralise trust by doing honest work instead of relying on authority. It turns out that doing work is actually pretty hard, people are lazy, and security is still the nemesis of efficiency.

[benlivengood]

> Do you know any other way to bootstrap a peer to peer network without centralised authorities?

In IPv4 a client might have a chance at auto-discovering peers.

It's also not necessary to rely on a single centralized authority. There are many things (DNS, Encyclopedias, Linux kernel mirrors, etc.) where the majority of existing centralized authorities agree with each other.

[jimmydorry]

DNS is based around central authority though. Every root zone has name servers that serve as the authority. Their responses get cached at various levels but take those servers offline until TTLs start expiring and everything breaks.

What part of DNS do you feel is possible without a centralized authority?

[yanmaani]

> Bitcoin for example still relies on a list of hardcoded nodes for bootstrapping clients.

It does, but it doesn't have to. You can use any mechanism you want to obtain one initial node and take it from there. You will still be connected to the network just as well, and you will be guaranteed to obtain the same results. This differs from Proof of Stake, where the quality of the results will be influenced by the quality of the bootstrap.

[madacol]

I verified the full chain a couple of weeks ago (But I admit I trusted umbrel to choose the "correct" bitcoin-core software to run), It took less than 3 days to sync on a Rpi4