8 ms·

> many people disconnect cold storage wallets for years Yes, and when they come back, they should update their software - which should have a hardcoded checkpo

> 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?

kerkeslager 5y ago
> 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!
- billytetrud 5y ago
  > users cannot be relied upon to update software Their software can be relied on to tell them when its too out of date to be used. > this isn't a decentralized, trustless solution It is in fact decentralized. Nothing is trustless, but it is in fact just as trust-minimized as bitcoin is. > 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? So many false assumptions in there. You know what they say about making assumptions don't you? What really bothers me is that you just assert that what I'm talking about is broken without even attempting to understand what I'm talking about. You don't seem to care about actually having a conversation, but instead just want to win. I don't appreciate that. If you want to keep talking about this, I'd like you to ask me some questions that clarify your understanding of what I'm talking about and show me you're actually trying to understand me instead of just trying to take the most attackable misunderstanding of my words and attack that. I'm getting very frustrated at you because of your willful misunderstanding, and unless you change your attitude, I'm just going to start ignoring you. So go ahead, you want to talk about this? Ask me how I'm proposing these checkpoints work. Ask me how they're decentralized. Ask me how they're trust minimized. Instead of asserting things that aren't true based on false assumptions. I'll give you one more chance.
  - kerkeslager 5y ago
    Okay, how do the checkpoints work, and how are they decentralized?
    - billytetrud 5y ago
      Checkpoints would be hardcoded into the software (not downloaded dynamically from some centralized source). As such, the checkpoint would simply be a peer reviewed change to an open source codebase, just like anything else. How is it decentralized? Anyone can create an independent codebase that implements the protocol. Anyone can review the code and raise the alarm to the community if the checkpoint isn't correct. Ideally there would be a number of independent implementations of the software, each with many devs and numerous reviewers. In addition to that, the previous version of the software could be used to automatically validate that the new software contains a checkpoint that matches the longest chain as seen by that software - and again, it can raise an alarm to the user if it doesn't match, who can alert the community. Any change in bitcoin works like this. Changes are discussed, implemented, and reviewed by hundreds or thousands of people. Users need to find the correct software in some way. Generally they would use the internet to find the right software, hopefully cross checking multiple sources. They might ask their friends what software to run. Etc. But there is no math to find the right software - each person has to use their social network (and the internet) to figure out which software is "Bitcoin". Once they download the software, it can do the rest. The same is true for a piece of software with a hardcoded checkpoint. There is no central source for the checkpoint. Everyone who is currently part of the network can validate that the checkpoint is correct. Many people will actually do it. It would be so easy to validate that it could be automatically reviewed by people's software (unlike most other codebase changes). So in what way would a PoS checkpoint be different than bitcoin? As I've shown above, the checkpoint itself is just another piece of the code like any other code change. The difference is that the checkpoint would be necessary to do at some regular frequency (say once a year). By contrast, you could imagine a future where the core Bitcoin software has been frozen and has not changed for years - decades maybe. And one could expect to go offline for 10 years and still be able to bring up their software without updating it. A PoS system would be slightly different. Because of the issues around short-range and long-range revisions, people who have been offline long enough should at very least download a new checkpoint (even if the rest of the software remains the same). The new checkpoint a user downloads should be recent enough that the chances of a short-range revision attack (eg a history attack) with sufficient accumulated minting power (or whatever your preferred alternative term is for "accumulated difficulty") is sufficiently unlikely. One new checkpoint per year would ensure that a user downloading the latest checkpoint is downloading a checkpoint no farther in the past than 1 year. This would require that a sufficient number of devs and reviewers get together to review and validate the released checkpoint to make the release sufficiently decentralized. This could realistically be structured so software checks this automatically and raises an alarm to the user if the new checkpoint doesn't match or if too much time goes by without a new checkpoint being released. Millions of people could realistically participate in that - anyone that runs a full node. Even anyone that runs a light node. Furthermore, when a user does download a checkpoint, some users are going to be careless and download some malicious checkpoint. If they do, but they have honest software, the software can ask their connections if the new checkpoint matches up with them. If it doesn't, it can again raise an alarm to the user. For a person with an old version of the software to get a malicious checkpoint without an automatic alarm being raised, they would have to either have a virus that changed the code of the software (at which point any software PoS or PoW is vulnerable), or they would have to be eclipsed by the attacker (connected to only attacker nodes) and the attacker must also have a way to sign the release (of the checkpoint) with the authors' signatures (which the software should also automatically check) and the attacker must have accumulated enough minting power (eg in old keys bought from people who have drained those addresses already) since the software last left the chain. The attacker can't simply create a brand new chain with a different genesis block - the software would raise an alarm about that. For a new entrant to the system, there is a higher risk, but it is no higher than with Bitcoin. The new entrant must find and install the right software somehow, on a machine that isn't compromised. This wouldn't be different for PoS. In summary: A. Users who have been connected to the network all along can't be tricked by any kind of history attack. B. Users who are newly connecting to the network simply need to download the correct software, as they need to do with bitcoin. C. Users who have been connected to the network for a time, but left for a period of time, just need to (manually) download and (automatically) verify a checkpoint. Item C is situtation that differs most from current Bitcoin. There is some additional possibility for an attack there, but it would still be extraordinarily difficult to pull off. In Bitcoin, there is no need to download any new data, and so there is no equivalent attack vector similar to tricking the user into accepting an invalid checkpoint. However, this attack would be very difficult (eclipse, key theft), cost a lot (buying old addresses with no coins currently in them), and has a pretty limited reward potential (only the possibility of attacking returning and new entrants they can eclipse). So yes, it is a trade off. I think its a good trade off to buy higher security against a 51% attack and lower fees. Does this make it clearer how checkpoints can be decentralized?

kerkeslager 5y ago

> 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!

billytetrud 5y ago
> users cannot be relied upon to update software Their software can be relied on to tell them when its too out of date to be used. > this isn't a decentralized, trustless solution It is in fact decentralized. Nothing is trustless, but it is in fact just as trust-minimized as bitcoin is. > 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? So many false assumptions in there. You know what they say about making assumptions don't you? What really bothers me is that you just assert that what I'm talking about is broken without even attempting to understand what I'm talking about. You don't seem to care about actually having a conversation, but instead just want to win. I don't appreciate that. If you want to keep talking about this, I'd like you to ask me some questions that clarify your understanding of what I'm talking about and show me you're actually trying to understand me instead of just trying to take the most attackable misunderstanding of my words and attack that. I'm getting very frustrated at you because of your willful misunderstanding, and unless you change your attitude, I'm just going to start ignoring you. So go ahead, you want to talk about this? Ask me how I'm proposing these checkpoints work. Ask me how they're decentralized. Ask me how they're trust minimized. Instead of asserting things that aren't true based on false assumptions. I'll give you one more chance.
- kerkeslager 5y ago
  Okay, how do the checkpoints work, and how are they decentralized?
  - billytetrud 5y ago
    Checkpoints would be hardcoded into the software (not downloaded dynamically from some centralized source). As such, the checkpoint would simply be a peer reviewed change to an open source codebase, just like anything else. How is it decentralized? Anyone can create an independent codebase that implements the protocol. Anyone can review the code and raise the alarm to the community if the checkpoint isn't correct. Ideally there would be a number of independent implementations of the software, each with many devs and numerous reviewers. In addition to that, the previous version of the software could be used to automatically validate that the new software contains a checkpoint that matches the longest chain as seen by that software - and again, it can raise an alarm to the user if it doesn't match, who can alert the community. Any change in bitcoin works like this. Changes are discussed, implemented, and reviewed by hundreds or thousands of people. Users need to find the correct software in some way. Generally they would use the internet to find the right software, hopefully cross checking multiple sources. They might ask their friends what software to run. Etc. But there is no math to find the right software - each person has to use their social network (and the internet) to figure out which software is "Bitcoin". Once they download the software, it can do the rest. The same is true for a piece of software with a hardcoded checkpoint. There is no central source for the checkpoint. Everyone who is currently part of the network can validate that the checkpoint is correct. Many people will actually do it. It would be so easy to validate that it could be automatically reviewed by people's software (unlike most other codebase changes). So in what way would a PoS checkpoint be different than bitcoin? As I've shown above, the checkpoint itself is just another piece of the code like any other code change. The difference is that the checkpoint would be necessary to do at some regular frequency (say once a year). By contrast, you could imagine a future where the core Bitcoin software has been frozen and has not changed for years - decades maybe. And one could expect to go offline for 10 years and still be able to bring up their software without updating it. A PoS system would be slightly different. Because of the issues around short-range and long-range revisions, people who have been offline long enough should at very least download a new checkpoint (even if the rest of the software remains the same). The new checkpoint a user downloads should be recent enough that the chances of a short-range revision attack (eg a history attack) with sufficient accumulated minting power (or whatever your preferred alternative term is for "accumulated difficulty") is sufficiently unlikely. One new checkpoint per year would ensure that a user downloading the latest checkpoint is downloading a checkpoint no farther in the past than 1 year. This would require that a sufficient number of devs and reviewers get together to review and validate the released checkpoint to make the release sufficiently decentralized. This could realistically be structured so software checks this automatically and raises an alarm to the user if the new checkpoint doesn't match or if too much time goes by without a new checkpoint being released. Millions of people could realistically participate in that - anyone that runs a full node. Even anyone that runs a light node. Furthermore, when a user does download a checkpoint, some users are going to be careless and download some malicious checkpoint. If they do, but they have honest software, the software can ask their connections if the new checkpoint matches up with them. If it doesn't, it can again raise an alarm to the user. For a person with an old version of the software to get a malicious checkpoint without an automatic alarm being raised, they would have to either have a virus that changed the code of the software (at which point any software PoS or PoW is vulnerable), or they would have to be eclipsed by the attacker (connected to only attacker nodes) and the attacker must also have a way to sign the release (of the checkpoint) with the authors' signatures (which the software should also automatically check) and the attacker must have accumulated enough minting power (eg in old keys bought from people who have drained those addresses already) since the software last left the chain. The attacker can't simply create a brand new chain with a different genesis block - the software would raise an alarm about that. For a new entrant to the system, there is a higher risk, but it is no higher than with Bitcoin. The new entrant must find and install the right software somehow, on a machine that isn't compromised. This wouldn't be different for PoS. In summary: A. Users who have been connected to the network all along can't be tricked by any kind of history attack. B. Users who are newly connecting to the network simply need to download the correct software, as they need to do with bitcoin. C. Users who have been connected to the network for a time, but left for a period of time, just need to (manually) download and (automatically) verify a checkpoint. Item C is situtation that differs most from current Bitcoin. There is some additional possibility for an attack there, but it would still be extraordinarily difficult to pull off. In Bitcoin, there is no need to download any new data, and so there is no equivalent attack vector similar to tricking the user into accepting an invalid checkpoint. However, this attack would be very difficult (eclipse, key theft), cost a lot (buying old addresses with no coins currently in them), and has a pretty limited reward potential (only the possibility of attacking returning and new entrants they can eclipse). So yes, it is a trade off. I think its a good trade off to buy higher security against a 51% attack and lower fees. Does this make it clearer how checkpoints can be decentralized?