Topic: [BIP] Full Autoupdating Node (FAN) for merchants (Read 1053 times)
Perhaps this idea has some merit. It would have prevented the brunt of our recent chain-fork.
Disclosure: this proposal likely has many flaws. Please point them out, but read the full thing first. Thank you.
In Satoshi's original whitepaper, he detailed a type of node that verifies only block headers. This type of node is useful for merchants who cannot afford to run a node that requires updating, as it can accept hard-forked blocks that don't match its rules. However, such a node has several disadvantages:
These disadvantages are problems for merchants, who cannot afford to be the target of an attack. As a result, many merchants stick to full nodes. These, however, have their own share of problems:
As a result, most merchants are left with no option but to run a full node that must be periodically updated. This is a problem for many; as it implies necessary downtime or extremely complex shenanigans.
However, it is possible to design a node that is neither victim to the attacks that an SPV node is vulnerable to, nor is hindered by the static nature of full nodes. Such a node is identical to a full node, but with some differences:
Notice that this node does not save any space for the merchant; the blockchain still needs to be downloaded in full. Transaction verification is done as normal, except that the scripts (including the signatures) are not verified.
Each problem and why FAN nodes are a solution is outlined below.
The quarantine attack is lethal against SPV nodes, while only double-spending is possible against full nodes.
Assume the node is quarantined. The attacker must issue a block containing theft transactions from random addresses to the merchant to exploit the merchant in any more lethality than a double-spending attack (which full nodes are also vulnerable to in a quarantine situation). The attacker has a lot of time to exploit the merchant, but no attack is likely unless the attacker controls a large portion of the network.
If the "much slower" curfew is taken at 40 minutes difference between blocks, the attacker is not likely to be able to actually mine a block that is faster than 40 minutes from the last. However, the attacker could fake the timestamps. Because the median of the past 11 blocks is valid (as the attacker would simply be wasting time if they did not initiate the quarantine directly), and the merchant's time should be accurate, the attacker's only optimal strategy is to timestamp the first block they mine as distant as possible (2 hours ahead of the actual time). As this block is "much slower", the attacker only has 160 minutes to mine the next block (otherwise, they would activate the alarm), 200 minutes to mine the next 2 blocks, and 240 minutes to mine the next three blocks. The chance of this happening is extremely small even at 5% of the network: the success rate is 1/5. As these blocks are simply getting wasted, and whether the node is actually quarantined is hard to determine, the random spending attack is not feasible.
Therefore, only a double-spend attack is feasible on a FAN node that is quarantined, giving it identical security to a full node.
If enough of the network switches to SPV nodes, miners could theoretically form a cabal to generate extra profits as fees.
This requires a more distributed approach. Assume that all BTC are in the hands of people who run either i) a full node or ii) a FAN node. The only way for miners to trick nodes into thinking that the fees for transactions are very high would be to "sign" the transactions from random addresses, sum the outputs to very little, and hope that FAN nodes believe the block as legitimate. However, when the FAN node that owns the outputs that are being stolen from receives the block in question, it will reject all blocks that build on that blockchain. Additionally, all full nodes will reject all blocks on that blockchain by default. Because so many nodes have rejected that blockchain, the relaying of rogue blocks will grind to a halt, splitting the rogue miner cabal's organization and restoring the original Bitcoin blockchain as the FAN node-accepted one.
Because such an attack will almost inevitably fail, no 51% of the network's miners will form the cabal in the first place. The maximum extent of damage is simply temporary isolation from the main blockchain before other FAN nodes relaying the blocks stop doing so. The cost of such an attack is too high to be feasible.
Blocks larger than 1 MB will be rejected if the merchant cannot update the node.
A miner cabal forming to create a chain of short blocks is the only issue here. Such a miner cabal cannot earn any money, and in fact is likely losing money due to fees. The damage of such an attack is isolation from the main network, and can lead to another attack, but at no further advantage than beginning the other attack immediately is present. Such a preemptive attack is possible against full nodes too, as it requires 51% of the hash power anyways.
Blocks with new transaction styles that utilize newly reenabled or added script codes will be rejected.
Scripts are not checked by FAN nodes, so this problem is resolved completely.
In Satoshi's original whitepaper, he detailed a type of node that verifies only block headers. This type of node is useful for merchants who cannot afford to run a node that requires updating, as it can accept hard-forked blocks that don't match its rules. However, such a node has several disadvantages:
- The quarantine attack is lethal against SPV nodes, while only double-spending is possible against full nodes.
- If enough of the network switches to SPV nodes, miners could theoretically form a cabal to generate extra profits as fees.
These disadvantages are problems for merchants, who cannot afford to be the target of an attack. As a result, many merchants stick to full nodes. These, however, have their own share of problems:
- Blocks larger than 1 MB will be rejected if the merchant cannot update the node.
- Blocks with new transaction styles that utilize newly reenabled or added script codes will be rejected.
As a result, most merchants are left with no option but to run a full node that must be periodically updated. This is a problem for many; as it implies necessary downtime or extremely complex shenanigans.
However, it is possible to design a node that is neither victim to the attacks that an SPV node is vulnerable to, nor is hindered by the static nature of full nodes. Such a node is identical to a full node, but with some differences:
- The node will accept any valid block, but if a short block is available, prefer it to the long one.
- The node will not process scripts. Inputs and outputs are processed as normal for all transactions, but scripts are left alone.
- The node will keep a log of all authorized transactions leaving its wallet.
- The node will reject any blocks with unauthorized transactions leaving its wallet.
- (Hashrate Slow) If (valid) block timestamps indicate that 2 of 4 consecutive blocks have been much slower than usual, the node tells the processor to wait for 12 confirmations instead of 6 confirmations. If more than 70% of the past 6n−2 blocks have been much slower than usual, the node extends the wait time to 6n+6 confirmations.
- (Hashrate Freeze) If the node senses that more than 70% of the past 22 blocks have been much slower than usual, it issues warnings and tries to verify everything as a full node. The wait time is capped at 30 confirmations (5 hours), but because of extensive verification, the node will likely reject all the blocks anyways.
Notice that this node does not save any space for the merchant; the blockchain still needs to be downloaded in full. Transaction verification is done as normal, except that the scripts (including the signatures) are not verified.
Each problem and why FAN nodes are a solution is outlined below.
The quarantine attack is lethal against SPV nodes, while only double-spending is possible against full nodes.
Assume the node is quarantined. The attacker must issue a block containing theft transactions from random addresses to the merchant to exploit the merchant in any more lethality than a double-spending attack (which full nodes are also vulnerable to in a quarantine situation). The attacker has a lot of time to exploit the merchant, but no attack is likely unless the attacker controls a large portion of the network.
If the "much slower" curfew is taken at 40 minutes difference between blocks, the attacker is not likely to be able to actually mine a block that is faster than 40 minutes from the last. However, the attacker could fake the timestamps. Because the median of the past 11 blocks is valid (as the attacker would simply be wasting time if they did not initiate the quarantine directly), and the merchant's time should be accurate, the attacker's only optimal strategy is to timestamp the first block they mine as distant as possible (2 hours ahead of the actual time). As this block is "much slower", the attacker only has 160 minutes to mine the next block (otherwise, they would activate the alarm), 200 minutes to mine the next 2 blocks, and 240 minutes to mine the next three blocks. The chance of this happening is extremely small even at 5% of the network: the success rate is 1/5. As these blocks are simply getting wasted, and whether the node is actually quarantined is hard to determine, the random spending attack is not feasible.
Therefore, only a double-spend attack is feasible on a FAN node that is quarantined, giving it identical security to a full node.
If enough of the network switches to SPV nodes, miners could theoretically form a cabal to generate extra profits as fees.
This requires a more distributed approach. Assume that all BTC are in the hands of people who run either i) a full node or ii) a FAN node. The only way for miners to trick nodes into thinking that the fees for transactions are very high would be to "sign" the transactions from random addresses, sum the outputs to very little, and hope that FAN nodes believe the block as legitimate. However, when the FAN node that owns the outputs that are being stolen from receives the block in question, it will reject all blocks that build on that blockchain. Additionally, all full nodes will reject all blocks on that blockchain by default. Because so many nodes have rejected that blockchain, the relaying of rogue blocks will grind to a halt, splitting the rogue miner cabal's organization and restoring the original Bitcoin blockchain as the FAN node-accepted one.
Because such an attack will almost inevitably fail, no 51% of the network's miners will form the cabal in the first place. The maximum extent of damage is simply temporary isolation from the main blockchain before other FAN nodes relaying the blocks stop doing so. The cost of such an attack is too high to be feasible.
Blocks larger than 1 MB will be rejected if the merchant cannot update the node.
A miner cabal forming to create a chain of short blocks is the only issue here. Such a miner cabal cannot earn any money, and in fact is likely losing money due to fees. The damage of such an attack is isolation from the main network, and can lead to another attack, but at no further advantage than beginning the other attack immediately is present. Such a preemptive attack is possible against full nodes too, as it requires 51% of the hash power anyways.
Blocks with new transaction styles that utilize newly reenabled or added script codes will be rejected.
Scripts are not checked by FAN nodes, so this problem is resolved completely.
Jump to: