4 ms·
I think as usual the crux of this debate is the security properties of figuring out correct software, and the parallels to checkpoints. I think you misunderstoo
by billytetrud 5y ago
I think as usual the crux of this debate is the security properties of figuring out correct software, and the parallels to checkpoints. I think you misunderstood me on a couple things, but I'd recommend that we focus mostly on the question of how a user can download correct software/data. If we can come to an agreement on that, I think how to get on the same page about the rest will become much clearer.
> That doesn't work: just because Bitcoin relaxes its decentralization in some ways doesn't mean it's okay for other solutions to relax decentralization.
Ok. Well that could be a valid point. However, discussing a design is only useful when comparing it to some realistic alternative. Bitcoin is the defacto standard of cryptocurrencies. I'm sure you'd agree its at least fair to compare to bitcoin, even if there might be other designs out there that claim to be better. I'd suggest that we both compare against bitcoin, because it seems likely that both of us understand that. Were you to bring up some other coin that you claim does it better, I think it would just hinder us coming to a mutual understanding. Once we've come to such an understanding, I'd be happy to move on to compare against something you think is better than bitcoin.
You're absolutely right that most people go to bitcoin.org to find full node software. However, that has nothing to do with bitcoin's consensus protocol, nor PoW vs PoS. Seems kind of irrelevant, as far as I can see.
> If I download the source code and have the technical ability to do so, I can verify that the source code does what it says it does.
Sure. Ignoring what you said about most people not being able to do that (and I'd argue that the vast majority don't have the combination of time and expertise to review changes to the source code and ensure there aren't things like security holes or maliciously injected code), the fact of the matter is that you can't know just by reading the source code whether or not that source code implements the protocol that everyone else is using (and calling "bitcoin", or whatever coin you're trying to use). In order to know that the software is compatible, you need to ask other people. There is no way around that. This isn't centralized trust, but it is decentralized minimal-trust. Just looking at a codebase or set of diffs can't tell you what chain is bitcoin.
> Checkpoints mean something entirely different: that means that I'm trusting the provider of the checkpoint about the state of the blockchain.
Given all that I said about how checkpoints can be verified against numerous connections, I would have hoped you'd at least have instead said "that means I'm trusting (many but a finite number of) providerS of that checkpoint about the state of the blockchain".
> Contrary to your statement, "There is no central source for the checkpoint," there IS a central source for the checkpoint: the server you're downloading from.
I thought you read my entire message? Why must someone download the checkpoint from a single source? Why not download it from many sources and ensure they all match?
> you receive two different source codes ... and need to figure out which is the real one
I agree with you, this is a problem. But tell me, how is this problem different for bitcoin or any other cryptocurrency? A prerequisite is that the user installs the correct software. How do they know which one is correct? How does a user know which software is the correct bitcoin software? Can they tell just by looking at the source code? Can they tell just by looking at the binary? What is the trustless way of installing the correct bitcoin software?
> The longer chain is correct, period.
This is not true in the case of a 51% attack, or more realistically, a dangerous majority consensus change. For example, what if bitcoin were the worldwide currency, and most people were tired of high onchain fees and decided to increase the blocksize by 100x with some kind of soft work. That would very likely be detrimental in the long run. However, it seems reasonably possible that this could actually happen some day. Smart people would fork off a different chain that preserves the old rules. So it would depend on what you mean by "correct". If by "corect" you mean the chain with the most economic activity - that's probably the longest chain. If by "correct" you instead mean the chain with the rules you expect, that chain may no longer exist, that chain may not be the longest chain. The only way to know is by asking people and learning what changes have happened, how many people followed what rules, and whether you agree with them. Its not always as simple as "follow the longest chain". However, I certainly agree that 99.9% of the time the longest chain is what you want.
> If you downloaded a malicious piece of software
It seems you somehow misread what I wrote. The case was if a user downloads "malicious checkpoint" and retains (their original) "honest software".
> but you've literally proposed one way [an attacker could accumulate enough minting power]
Of course its possible. That doesn't make it easy, cheap, profitable, or likely. A 51% attack is possible, but its (hopefully) difficult enough that it will never happen.
> Bitcoin Cash software from ten years ago can still detect a sybil attack on the Bitcoin Cash chain as long as you connect to one valid node.
And a PoS currency that uses checkpoints can also detect a sybil attack if they can download a checkpoint from at least one honest node. Its literally the exact same mechanism.
> I'm not convinced of your claim that this attack would be very difficult--while I don't know of a time that it has been implemented in practice, a lot of the piece of the attack have already been implemented in practice.
That's something I could analyse in more detail if you're interested.
> Vitalik and a great many other smart researchers are worried about how this could go wrong
There's certainly plenty that could go wrong. I'm not claiming that PoS is easy or a sure thing. What I am claiming is that most of the arguments against PoS that have been raised are solved problems. But that doesn't mean there aren't more subtle known problems that aren't raised as often, and it doesn't mean that there aren't unknown problems. There is certainly a possibility that PoS can't beat PoW. However I have yet to see convincing evidence that's the case.
- kerkeslager 5y ago> I think as usual the crux of this debate is the security properties of figuring out correct software, and the parallels to checkpoints. I think you misunderstood me on a couple things, but I'd recommend that we focus mostly on the question of how a user can download correct software/data. If we can come to an agreement on that, I think how to get on the same page about the rest will become much clearer. Okay. I agree that this is one of the two key points we disagree on. If you want to focus on your specific proposed implementation on PoS rather than all possible PoS implementations, we can narrow this further. I think you're saying that it's possible to verify the checkpoints in a decentralized way without PoW. Is that a fair statement of your opinion? The other key point I think we disagree on is that you seem to think that it's possible to verify that time has elapsed between block validations in PoS. Is that a fair statement of your opinion?
- billytetrud 5y ago> If you want to focus on your specific proposed implementation on PoS rather than all possible PoS implementations, we can narrow this further. Sounds good to me. > I think you're saying that it's possible to verify the checkpoints in a decentralized way without PoW. Is that a fair statement of your opinion? Yes. To elaborate, for users who don't have any software already installed, this would be a social process of asking many other people/sources what the correct software is. For users who already have correct software already installed, either that correct software has been running recently enough and can generate its own checkpoint, or that software was offline for long enough that it needs a checkpoint, but it can help substantially automate the process of validating a checkpoint and if it cannot validate it, the user should fall back to a similar process of social discovery to determine what the correct checkpoint/update is. Do you view the idea of asking many untrusted and/or trusted people/entities what the correct checkpoint is, as not decentralized? Or not sufficiently decentralized? > The other key point I think we disagree on is that you seem to think that it's possible to verify that time has elapsed between block validations in PoS. Is that a fair statement of your opinion? The question isn't clear enough to me. I think what I can say about that is, given that you have two time anchors (eg one in the past, the checkpoint, and one in the present, your own computer's clock), its possible to ensure that only a certain number of blocks can validly be added between those two time anchors, to a high degree of statistical probability. But maybe you could clarify the question?