6 ms·

> They do; for a transaction to be revocable means you haven't accepted that it went through. If every block is revocable indefinitely, then you can't say that

> They do; for a transaction to be revocable means you haven't accepted that it went through. If every block is revocable indefinitely, then you can't say that 20 confirmations confirm a block, because they don't. From the blockchain perspective a block with a confirmation is confirmed. But everyone else can make new rules on top regarding payments: Do you consider most crypto exchanges to not support "Bitcoin" since they require 6 confirmations per transaction before they credit it? > With a consensus of decentralized, less-than-perfectly-synchronized miners, you'd want a fuzzier boundary -- which is what "wait for 20 following transactions" provides. This is done to raise the cost of reversing the transaction (the more confirmations deep, the more expensive your attack needs to be).

thaumasiotes 8y ago
>> With a consensus of decentralized, less-than-perfectly-synchronized miners, you'd want a fuzzier boundary -- which is what "wait for 20 following transactions" provides. > This is done to raise the cost of reversing the transaction (the more confirmations deep, the more expensive your attack needs to be). No, it isn't done at all. You state as much: > From the blockchain perspective a block with a confirmation is confirmed. As far as I can see, this is just a design mistake. (And equivocating over the meaning of "confirmed".) The current system never treats any block as confirmed. The only statuses a block can have are "invalid" and "provisionally accepted". There is no "accepted" status, and a valid block may be revoked at any time, no matter how long it may have been valid for. But there's also no reason not to have an "accepted" status, and to reject candidate blockchains which alter accepted blocks. This should be part of the mining protocol. Treating it as non-binding advice to merchants misses the point.
- Robin_Message 8y ago
  So, I just ran through the same thought process and the problem is this: How does a new entrant to the network know which is the valid chain? They didn't see the previous 20 confirmations, so the only rule they can use is picking the longest chain. Another way to do it is to have a separate voting system to attest to the "valid" chain, but then you could use an ordinary botnet to outvote the real chain. In short, confirmations are there for vendors to be sure a few blocks weren't mined at the same time, but they do nothing against a 51% attack.
  - thaumasiotes 8y ago
    I don't follow this. A new entrant to the network knows which is the valid chain because the chain the network uses defines "the network". Consider the case[1] of Ethereum Classic (ETC) versus Ethereum (ETH). They are exactly the same, except for the chain each group of miners follows. The ETC blockchain is a valid ETH blockchain and the ETH blockchain is a valid ETC blockchain, but miners adhere to one or the other for political reasons. As a new entrant to the ETC network, how do you know which blockchain to use? Well, you use the ETC blockchain, because that's the network you're entering. [1] I'm describing my understanding of the ETH/ETC split. If they've diverged more than I was aware of, that doesn't affect the argument; just substitute other names for ETH and ETC.
    - Pyxl101 8y ago
      What you're missing is the process by which new blocks are added onto an existing chain. Let's say that you take the "true" Bitcoin or ETC blockchain, if you want to think of it that way, and now multiple actors are proposing to add blocks onto it, potentially multiple blocks. Which one of those additions wins? The one that's the longest and has the most work behind it - that one wins. If you propose an addition that is one block long, and I propose an addition that's 2 blocks long, then my chain wins. (These all have to be valid blocks that solve the mining challenge). Miners select the chain with the most work. That's the consensus mechanism by which the blockchain is established (among nodes operating all with the same rule sets). At any given instantaneous point in time, there may be multiple instantaneous forks of the main blockchain - people who have mined out valid next blocks and are fighting to get them accepted as the primary chain. Imagine that two different miners by coincidence mine out the next block. One of those chains has to win. The chain that wins is the one that propagates through the network most quickly such that other miners begin building upon it and extending the chain - the one with the most work wins. The other chain(s) die and the transactions on it have to be resubmitted. When multiple branches exist on the blockchain, some consensus process has to reconcile which of them wins. That process is that miners select the longest chain. Don't act as if one single block is magically appended to the chain and everyone knows which block that is; a consensus process operates to select that block (or sequence of blocks), and it operates by selecting the longest chain. When two or more blocks are mined out simultaneously by different miners, the one that wins is likely to be the chain that propagates more quickly to other miners. Since miners build on the longest chain, then the miner who distributes their chain more widely among other miners is likely to win, since those miners will begin building upon it (seeing it as the longest chain thus far). To continue the story, let's say that you and I both simultaneously mine out the next block of Bitcoin. You don't tell anyone about your block, and keep it to yourself. I distribute my block to the entire network. Thus, other miners start building on my block, and it becomes part of the main bitcoin blockchain. Once that happens, it doesn't matter if you start telling other people about your block -- it's not part of bitcoin any more because my chain exists which is much longer (my block + whatever other blocks people have mined out on top of it).
- vvillena 8y ago
  The original Bitcoin white paper explains this pretty well. The Bitcoin blockchain is never frozen, and the longest (the hardest) chain is always the valid one. The paper includes a formula to calculate the probability of a block being replaced by another, and sets 6 confirmations as the frontier where it is almost impossible for the chain to change. What the paper doesn't say is that the formula doesn't work if there is more than one chain. Since an ETH miner can easily switch to ETC at any time, proof-of-work isn't really protecting ETC at all. There is another chain that was a lot harder to calculate, which means the ETC chain stands on thin ice. Why not freeze the blockchain at certain points, then? Well, it cannot be easily done. There is the problem of choosing which blocks should be frozen, and when. How do you calculate that? What if there's a network split at that time? What happens if the protocol results in an unwanted fork? What happens if malicious actors try to settle on a wrong chain? This is the very problem that Bitcoin solved. Forgetting the idea of a final truth, and making the blocks work like a wave of consensus that eventually reaches everyone. Clever and simple, but with some drawbacks that have to be understood. Of course, there are lots of people working on new ways of establishing decentralized consensus. The Ethereum devs have been working hard on this for a few years.
- ryani 8y ago
  Let's say there was a catastrophic event that split the internet and disconnected Australia and the surrounding islands from the internet for 36 hours. Let's also say for the sake of argument that 10% of the BTC mining capacity is in that region. The network self-adjusts so that every hour 6 blocks get confirmations, but over this short time period you wouldn't expect this to happen. This means that every hour the Australia split would confirm 0.6 blocks and the non-Australia split would confirm 5.4 blocks. After 36 hours Australia would have confirmed ~21 blocks, and according to your proposal, the first of these is now 'accepted' and can't be rolled back. In the same time the remainder of the network would have confirmed ~194 blocks, many of which are now accepted. What would actually happen according to the consensus protocol is that RestOfWorldBTC is the longer chain and therefore "is" BTC, and AustraliaBTC would get thrown away. Any BTC transactions made in Australia during that time would get rolled back. But if blocks become permanently accepted then these 2 chains are fundamentally incompatible; they are no longer the same coin. Your proposal says that the network should fork into 2 coins here -- AustraliaBTC and RestOfWorldBTC. This would be a pretty disruptive event. People who traded BTC for services in Australia would claim that they paid their obligation (after all, it's in an 'accepted' block) and therefore don't owe their counterparty any RestOfWorldBTC. But AustraliaBTC would likely become worthless very quickly, given that most of the transactions in those 36 hours were confirmed on the RestOfWorldBTC chain. Australian counterparties would get stiffed pretty hard. OTOH, if you roll back those transactions and accept the mainline, those counterparties can more easily argue that you still need to pay them. Note that the network can't enforce you paying these obligations, but the legal system still exists! And assuming the actors were acting in good faith and didn't attempt to double-spend their coins, their transaction would get re-propogated automatically and get included in a future RestOfWorld BTC block once the network split ended.

thaumasiotes 8y ago

>> With a consensus of decentralized, less-than-perfectly-synchronized miners, you'd want a fuzzier boundary -- which is what "wait for 20 following transactions" provides. > This is done to raise the cost of reversing the transaction (the more confirmations deep, the more expensive your attack needs to be). No, it isn't done at all. You state as much: > From the blockchain perspective a block with a confirmation is confirmed. As far as I can see, this is just a design mistake. (And equivocating over the meaning of "confirmed".) The current system never treats any block as confirmed. The only statuses a block can have are "invalid" and "provisionally accepted". There is no "accepted" status, and a valid block may be revoked at any time, no matter how long it may have been valid for. But there's also no reason not to have an "accepted" status, and to reject candidate blockchains which alter accepted blocks. This should be part of the mining protocol. Treating it as non-binding advice to merchants misses the point.

Robin_Message 8y ago
So, I just ran through the same thought process and the problem is this: How does a new entrant to the network know which is the valid chain? They didn't see the previous 20 confirmations, so the only rule they can use is picking the longest chain. Another way to do it is to have a separate voting system to attest to the "valid" chain, but then you could use an ordinary botnet to outvote the real chain. In short, confirmations are there for vendors to be sure a few blocks weren't mined at the same time, but they do nothing against a 51% attack.
- thaumasiotes 8y ago
  I don't follow this. A new entrant to the network knows which is the valid chain because the chain the network uses defines "the network". Consider the case[1] of Ethereum Classic (ETC) versus Ethereum (ETH). They are exactly the same, except for the chain each group of miners follows. The ETC blockchain is a valid ETH blockchain and the ETH blockchain is a valid ETC blockchain, but miners adhere to one or the other for political reasons. As a new entrant to the ETC network, how do you know which blockchain to use? Well, you use the ETC blockchain, because that's the network you're entering. [1] I'm describing my understanding of the ETH/ETC split. If they've diverged more than I was aware of, that doesn't affect the argument; just substitute other names for ETH and ETC.
  - Pyxl101 8y ago
    What you're missing is the process by which new blocks are added onto an existing chain. Let's say that you take the "true" Bitcoin or ETC blockchain, if you want to think of it that way, and now multiple actors are proposing to add blocks onto it, potentially multiple blocks. Which one of those additions wins? The one that's the longest and has the most work behind it - that one wins. If you propose an addition that is one block long, and I propose an addition that's 2 blocks long, then my chain wins. (These all have to be valid blocks that solve the mining challenge). Miners select the chain with the most work. That's the consensus mechanism by which the blockchain is established (among nodes operating all with the same rule sets). At any given instantaneous point in time, there may be multiple instantaneous forks of the main blockchain - people who have mined out valid next blocks and are fighting to get them accepted as the primary chain. Imagine that two different miners by coincidence mine out the next block. One of those chains has to win. The chain that wins is the one that propagates through the network most quickly such that other miners begin building upon it and extending the chain - the one with the most work wins. The other chain(s) die and the transactions on it have to be resubmitted. When multiple branches exist on the blockchain, some consensus process has to reconcile which of them wins. That process is that miners select the longest chain. Don't act as if one single block is magically appended to the chain and everyone knows which block that is; a consensus process operates to select that block (or sequence of blocks), and it operates by selecting the longest chain. When two or more blocks are mined out simultaneously by different miners, the one that wins is likely to be the chain that propagates more quickly to other miners. Since miners build on the longest chain, then the miner who distributes their chain more widely among other miners is likely to win, since those miners will begin building upon it (seeing it as the longest chain thus far). To continue the story, let's say that you and I both simultaneously mine out the next block of Bitcoin. You don't tell anyone about your block, and keep it to yourself. I distribute my block to the entire network. Thus, other miners start building on my block, and it becomes part of the main bitcoin blockchain. Once that happens, it doesn't matter if you start telling other people about your block -- it's not part of bitcoin any more because my chain exists which is much longer (my block + whatever other blocks people have mined out on top of it).
vvillena 8y ago
The original Bitcoin white paper explains this pretty well. The Bitcoin blockchain is never frozen, and the longest (the hardest) chain is always the valid one. The paper includes a formula to calculate the probability of a block being replaced by another, and sets 6 confirmations as the frontier where it is almost impossible for the chain to change. What the paper doesn't say is that the formula doesn't work if there is more than one chain. Since an ETH miner can easily switch to ETC at any time, proof-of-work isn't really protecting ETC at all. There is another chain that was a lot harder to calculate, which means the ETC chain stands on thin ice. Why not freeze the blockchain at certain points, then? Well, it cannot be easily done. There is the problem of choosing which blocks should be frozen, and when. How do you calculate that? What if there's a network split at that time? What happens if the protocol results in an unwanted fork? What happens if malicious actors try to settle on a wrong chain? This is the very problem that Bitcoin solved. Forgetting the idea of a final truth, and making the blocks work like a wave of consensus that eventually reaches everyone. Clever and simple, but with some drawbacks that have to be understood. Of course, there are lots of people working on new ways of establishing decentralized consensus. The Ethereum devs have been working hard on this for a few years.
ryani 8y ago
Let's say there was a catastrophic event that split the internet and disconnected Australia and the surrounding islands from the internet for 36 hours. Let's also say for the sake of argument that 10% of the BTC mining capacity is in that region. The network self-adjusts so that every hour 6 blocks get confirmations, but over this short time period you wouldn't expect this to happen. This means that every hour the Australia split would confirm 0.6 blocks and the non-Australia split would confirm 5.4 blocks. After 36 hours Australia would have confirmed ~21 blocks, and according to your proposal, the first of these is now 'accepted' and can't be rolled back. In the same time the remainder of the network would have confirmed ~194 blocks, many of which are now accepted. What would actually happen according to the consensus protocol is that RestOfWorldBTC is the longer chain and therefore "is" BTC, and AustraliaBTC would get thrown away. Any BTC transactions made in Australia during that time would get rolled back. But if blocks become permanently accepted then these 2 chains are fundamentally incompatible; they are no longer the same coin. Your proposal says that the network should fork into 2 coins here -- AustraliaBTC and RestOfWorldBTC. This would be a pretty disruptive event. People who traded BTC for services in Australia would claim that they paid their obligation (after all, it's in an 'accepted' block) and therefore don't owe their counterparty any RestOfWorldBTC. But AustraliaBTC would likely become worthless very quickly, given that most of the transactions in those 36 hours were confirmed on the RestOfWorldBTC chain. Australian counterparties would get stiffed pretty hard. OTOH, if you roll back those transactions and accept the mainline, those counterparties can more easily argue that you still need to pay them. Note that the network can't enforce you paying these obligations, but the legal system still exists! And assuming the actors were acting in good faith and didn't attempt to double-spend their coins, their transaction would get re-propogated automatically and get included in a future RestOfWorld BTC block once the network split ended.