7 ms·

> transfer my coins to another address, and then use my original, "trusted" address to validate a chain of blocks Any new entrant would be able to clearly see

> transfer my coins to another address, and then use my original, "trusted" address to validate a chain of blocks Any new entrant would be able to clearly see the transaction on one of the chains and from that can determine that the chain not containing that transaction but instead using that output to mint blocks is the cheating block chain. Your attack wouldn't work.

jude- 5y ago
An attacker only needs to fool the network for a short amount of time -- e.g. to double-spend someone. It doesn't matter to the attacker that they are eventually discovered; what matters is that they can get away with it before getting caught.
- billytetrud 5y ago
  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 step 2 to be pretty far apart (on the order of months). In step 3, a fake chain would not fool new entrants because the new chain would be growing at a much slower rate than expected (because only the attacker is building on top of it). So there's two reasons that the attack wouldn't work here.
  - kerkeslager 5y ago
    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 proposed solution doesn't work. 2. That's simply incorrect, and I'm quite unsure why you think that. Proof of Work is the thing that slows down the creation of blockchains: a PoS attacker who creates a blockchain can emit blocks at a very high rate. The fact that they are the only validator doesn't slow them in any way.
    - billytetrud 5y ago
      > 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
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.
- billytetrud 5y ago
  > 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 times. The paper's conclusion is not correct. All the problems he presents are solvable at once (eg in this protocol: https://github.com/fresheneesz/validatedProofOfStake https://github.com/fresheneesz/validatedProofOfStake). He doesn't consider that hard coded checkpoints handily solve the problem of long-range revisions.
  - kerkeslager 5y ago
    > 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.

jude- 5y ago

An attacker only needs to fool the network for a short amount of time -- e.g. to double-spend someone. It doesn't matter to the attacker that they are eventually discovered; what matters is that they can get away with it before getting caught.

billytetrud 5y ago
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 step 2 to be pretty far apart (on the order of months). In step 3, a fake chain would not fool new entrants because the new chain would be growing at a much slower rate than expected (because only the attacker is building on top of it). So there's two reasons that the attack wouldn't work here.
- kerkeslager 5y ago
  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 proposed solution doesn't work. 2. That's simply incorrect, and I'm quite unsure why you think that. Proof of Work is the thing that slows down the creation of blockchains: a PoS attacker who creates a blockchain can emit blocks at a very high rate. The fact that they are the only validator doesn't slow them in any way.
  - billytetrud 5y ago
    > 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

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.

billytetrud 5y ago
> 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 times. The paper's conclusion is not correct. All the problems he presents are solvable at once (eg in this protocol: https://github.com/fresheneesz/validatedProofOfStake https://github.com/fresheneesz/validatedProofOfStake). He doesn't consider that hard coded checkpoints handily solve the problem of long-range revisions.
- kerkeslager 5y ago
  > 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.