4 ms·

> 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

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

kerkeslager 5y ago
> 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? I'll allow that this falls on a spectrum of decentralization and is definitely more decentralized than "not decentralized at all". Whether it's "sufficiently decentralized" is a difficult question for two reasons: 1. Maybe you have some formal algorithm for social discovery that you haven't presented here, but without that, it's quite difficult to speculate how it would play out. 2. From the way you're describing this, you're not relying on a formal algorithm, but on a reliable, diverse network. Maybe you're aware that computer networks are inherently unreliable, so you're getting around this by not using a computer network: for example, making a phone call to get a checkpoint hash from someone you trust. There's a lot of human elements here, and humans are unpredictable. My gut feel is that no, it's not sufficiently decentralized, at least not in a way that presents any real advantages over simply trusting the network, but something like a PGP web of trust[1] could make this more reliable--it's hard to say without fleshing this plan out more. The two claims I'm willing to confidently make here are: 1. As far as I can tell, you're not proposing an automated way to bootstrap trust OR consensus here, and without this, it's going to be both slow, and prone to the introduction of human error. 2. This system is inherently less decentralized AND less secure than PoW. Verifying a blockchain via PoW doesn't require trust (or put another way, you trust the math, not the nodes you're connected to), so there isn't a need to bootstrap trust. I don't know how PoS will play out, but I do know how PoW will play out in the situations described by Poestra. PoS may work out in practice: I genuinely hope it does, because there would be significant upsides! But I'm not confident that PoS will work out, and I am confident that PoW will. > > 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? Okay, given this explanation, I think this basically falls back to your system of bootstrapping trust. Yes, if you can trust the checkpoints, you can trust the times between them. So this disagreement basically collapses back to the first disagreement: I would say that the reliability of the elapsed time between checkpoints is only as valid as the reliability of the checkpoints, and I am not confident in the reliability of the checkpoints. You did claim earlier that all PoS implementations have elapsed time between blocks, and I'm still mystified as to how you're claiming this is enforced. [1] https://www.linux.com/training-tutorials/pgp-web-trust-core-concepts-behind-trusted-communication/ https://www.linux.com/training-tutorials/pgp-web-trust-core-...
- billytetrud 5y ago
  > Maybe you have some formal algorithm for social discovery that you haven't presented here, but without that, it's quite difficult to speculate how it would play out. However, this process is already important when choosing software in the first place, or when updating software. Even when using PoW, every new entrant to the network needs to do some kind of social discovery to figure out which software to download in the first place. And even with PoS, people that have been regularly connected to the network do not need any social discovery. With PoS, there is an additional kind of user that an attacker can force to need to do social discovery: users who were at one point part of the network but have been offline for a long period of time. My conjecture is that this set of users is quite small in comparison to either the set of new entrants or the set of nodes who have been online frequently enough to not need any social discovery. Would you agree that if that set of users is small enough, the difference might be insignificant? Eg would increasing the number of users that have to do some kind of social discovery by 1% be acceptable? > My gut feel is that no, it's not sufficiently decentralized I would tend to agree that the process of finding the right sofware is generally not decentralized enough - too easy for people to find bad software or virus ridden downloads. The only thing that saves us is that the vast majority of humanity isn't malicious. > something like a PGP web of trust[1] could make this more reliable I think there are a lot of things we could do like that. We have a long way to go towards actually making good computer security accessible to a significant fraction of people. First step is operating systems - or maybe even hardware. > you're not proposing an automated way to bootstrap trust OR consensus here Correct. What I'm proposing is a way to verify with confidence if the data (checkpoint) you received is very likely valid in cases where you're not being attacked, and a way to alert the user when an attack might be happening. The trust / social discovery part of things is basically out of scope - but already exists in its own haphazard individualized way. > You did claim earlier that all PoS implementations have elapsed time between blocks, and I'm still mystified as to how you're claiming this is enforced. Well I meant that the timestamps that blocks have are enforced. The actual time they're created can't be enforced. But to elaborate, in VPoS, every UTXO gets one chance per second to mint a block. Nodes will know well in advance whether or not they can mint a block or not (although other nodes can't know which peers will get that chance until that peer actually broadcasts a block). However, a node will reject blocks with a timestamp greater than its clock. Furthermore, a "difficulty" adjustment happens similar to bitcoin. X blocks per minute are targetted on average, and if 2X blocks/minute are minted in a given time range, the "difficulty" will increase until only X blocks/minute are minted. Basically, if a number C of coins has 2 chances in 10,000 of minting a block, if the difficulty doubles, that number of coins then has 1 chance in 10,000. This is how its ensured that blocks are, on average, minted some target time apart. With a quorum based system like Casper, each quorum is allowed to mint a particular number of blocks, probably with timestamp constraints as well. And the quorums themselves must change after a specific number of blocks. I assume some similar difficulty-like adjustment is done to keep these timed properly, so that both quorums and blocks are maintained at a cadence. Is this what you mean, or are you talking about something else?

kerkeslager 5y ago

> 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? I'll allow that this falls on a spectrum of decentralization and is definitely more decentralized than "not decentralized at all". Whether it's "sufficiently decentralized" is a difficult question for two reasons: 1. Maybe you have some formal algorithm for social discovery that you haven't presented here, but without that, it's quite difficult to speculate how it would play out. 2. From the way you're describing this, you're not relying on a formal algorithm, but on a reliable, diverse network. Maybe you're aware that computer networks are inherently unreliable, so you're getting around this by not using a computer network: for example, making a phone call to get a checkpoint hash from someone you trust. There's a lot of human elements here, and humans are unpredictable. My gut feel is that no, it's not sufficiently decentralized, at least not in a way that presents any real advantages over simply trusting the network, but something like a PGP web of trust[1] could make this more reliable--it's hard to say without fleshing this plan out more. The two claims I'm willing to confidently make here are: 1. As far as I can tell, you're not proposing an automated way to bootstrap trust OR consensus here, and without this, it's going to be both slow, and prone to the introduction of human error. 2. This system is inherently less decentralized AND less secure than PoW. Verifying a blockchain via PoW doesn't require trust (or put another way, you trust the math, not the nodes you're connected to), so there isn't a need to bootstrap trust. I don't know how PoS will play out, but I do know how PoW will play out in the situations described by Poestra. PoS may work out in practice: I genuinely hope it does, because there would be significant upsides! But I'm not confident that PoS will work out, and I am confident that PoW will. > > 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? Okay, given this explanation, I think this basically falls back to your system of bootstrapping trust. Yes, if you can trust the checkpoints, you can trust the times between them. So this disagreement basically collapses back to the first disagreement: I would say that the reliability of the elapsed time between checkpoints is only as valid as the reliability of the checkpoints, and I am not confident in the reliability of the checkpoints. You did claim earlier that all PoS implementations have elapsed time between blocks, and I'm still mystified as to how you're claiming this is enforced. [1] https://www.linux.com/training-tutorials/pgp-web-trust-core-concepts-behind-trusted-communication/ https://www.linux.com/training-tutorials/pgp-web-trust-core-...

billytetrud 5y ago
> Maybe you have some formal algorithm for social discovery that you haven't presented here, but without that, it's quite difficult to speculate how it would play out. However, this process is already important when choosing software in the first place, or when updating software. Even when using PoW, every new entrant to the network needs to do some kind of social discovery to figure out which software to download in the first place. And even with PoS, people that have been regularly connected to the network do not need any social discovery. With PoS, there is an additional kind of user that an attacker can force to need to do social discovery: users who were at one point part of the network but have been offline for a long period of time. My conjecture is that this set of users is quite small in comparison to either the set of new entrants or the set of nodes who have been online frequently enough to not need any social discovery. Would you agree that if that set of users is small enough, the difference might be insignificant? Eg would increasing the number of users that have to do some kind of social discovery by 1% be acceptable? > My gut feel is that no, it's not sufficiently decentralized I would tend to agree that the process of finding the right sofware is generally not decentralized enough - too easy for people to find bad software or virus ridden downloads. The only thing that saves us is that the vast majority of humanity isn't malicious. > something like a PGP web of trust[1] could make this more reliable I think there are a lot of things we could do like that. We have a long way to go towards actually making good computer security accessible to a significant fraction of people. First step is operating systems - or maybe even hardware. > you're not proposing an automated way to bootstrap trust OR consensus here Correct. What I'm proposing is a way to verify with confidence if the data (checkpoint) you received is very likely valid in cases where you're not being attacked, and a way to alert the user when an attack might be happening. The trust / social discovery part of things is basically out of scope - but already exists in its own haphazard individualized way. > You did claim earlier that all PoS implementations have elapsed time between blocks, and I'm still mystified as to how you're claiming this is enforced. Well I meant that the timestamps that blocks have are enforced. The actual time they're created can't be enforced. But to elaborate, in VPoS, every UTXO gets one chance per second to mint a block. Nodes will know well in advance whether or not they can mint a block or not (although other nodes can't know which peers will get that chance until that peer actually broadcasts a block). However, a node will reject blocks with a timestamp greater than its clock. Furthermore, a "difficulty" adjustment happens similar to bitcoin. X blocks per minute are targetted on average, and if 2X blocks/minute are minted in a given time range, the "difficulty" will increase until only X blocks/minute are minted. Basically, if a number C of coins has 2 chances in 10,000 of minting a block, if the difficulty doubles, that number of coins then has 1 chance in 10,000. This is how its ensured that blocks are, on average, minted some target time apart. With a quorum based system like Casper, each quorum is allowed to mint a particular number of blocks, probably with timestamp constraints as well. And the quorums themselves must change after a specific number of blocks. I assume some similar difficulty-like adjustment is done to keep these timed properly, so that both quorums and blocks are maintained at a cadence. Is this what you mean, or are you talking about something else?