This page's design is great and what I thought tufte-ian journalism would have led to. Using the presentation of quasi-mathematical facts in relatively grokkable formats to explain the state of the world in a way that can update itself several months or years later.
Specifically some of the political discussions lately feel like they could use better dashboards. The call to action at the end of this article with three main solutions called out now has some context in several dimensions (time, space, monetary).
The doge.gov website for instance would've been a prime candidate for that, like some sort of observablehq.com ability slice and dice a data dashboard. But then you also have to be able to trust the data I suppose.
The whole point of restricting the block size was to ensure space in the blockchain was scarce to drive the price of fees up, better securing the network. Well, that and keeping the blockchain total size small enough to be processed on an regular user's PC for decentralization sake. While a loss of some decentralization is non-ideal,
increasing the block size dynamically, similarly to how difficulty is handled, would be a reasonable compromise to ensure the security of the network long term.
That wasn't the reason to restrict block size. There is no way to scale the number of transactions on the main layer to anywhere near the level required to cover daily transactions. The bitcoin main layer was always destined to be for settlements between financial institutions anyway. Making any accommodations for use cases that are fundamentally unsustainable never made sense. Buying coffee was always going to have to be on a second or third layer, so restricting the block size introduces an incentive to develop those layers that are needed anyway.
This big block propaganda piece fails to address the most obvious issue with their proposal: that increasing block sizes will just increase fees linearly. No one will pay more in fees per transaction because there will be a lot of space left in blocks, so people will keep paying $0.20 per transaction, which today gets us $400, so now we'll get $800? That if increasing the block size doesn't reduce the base $0.20 to some smaller average.
The actual solution to the security budget is to make a ton of payments in a (blindly) merge-mined sidechain and ensure those transactions there pay lower fees but those lower fees get aggregated into a single high-fee paid on Bitcoin. That is the Drivechain proposal: https://drivechain.xyz/.
I've said it before but really feels like a flaw that the halvings are discrete and happen suddenly every four years, instead of gradually each block. As far as I can tell the only advantage to it is that it makes the math simpler. The disadvantage is that it creates weird market dynamics in which large amounts of mining capacity are plunged into unprofitability in one instant. If I wanted to run a 51% attack, I'd look to buy up suddenly-unprofitable capacity immediately after a halving.
Lol total garbage people have been whining about the blocks regularly being EMPTY now, a huge % of transactions just occur off chain on exchanges/lightning/etc. There are no 100 dollar fees you can basically do everything for basically free.
https://mempool.space/
look, you can see how many blocks aren't filled lol. This piece is literally just garbage. Big blockers are scam artists.
I think switching to something like proof of stake where bad actors can be punished is the best way forward to avoid honest nodes betraying the network.
Trying to maximize mining profit is adversarial with the end users and makes using bitcoin unattractive.
So the two questions that I cannot see answered there.
How much does the security budget need to be?
When is it projected to drop below that?
The closest they come to addressing that seems to be a quote saying
"We might have only two halvings left before this becomes a serious issue."
So 8 years-ish?
The original intention was to fund the network entirely off fees eventually. I don't think there was a stated expectation of block size, but it was intended to be made larger at some point.
Before coming up with specific solutions to the cost of securing the network I would think that evaluating what the acceptable range of cost/security should be would be the first starting point.
I feel they also neglect a realistic evaluation of the likelihood of a 51% attack. As soon as someone interferes with the network by 51% attack, everybody knows that it has happened. What countermeasures might be deployed?
While a miner confirming a block is like a rubber stamp from an auditor, there is nothing to stop other people from checking their work. If there are shenanigans they can be spotted, if a genuine 51% attack were to happen people would be highly motivated to counter it. That may involve bringing more compute to the network, or even changing the protocol. Ultimately the network is decided by the consensus of the users. Accepting signed blocks is the consensus. Because of the scale required to do a 51% attack on BitCoin it would almost certainly be detectable who was doing it. Under an attack people would be prepared to swiftly agree to some rule to exclude the attacker, the alternative is just two severe. You could think of it as a fork or you could think of the attackers version as the fork. You could have anything from, 'Today we stop accepting blocks from that pool over there', to 'From now until this mess is resolved, Kate confirms all blocks with her private key, We trust Kate, she's nice' The mitigation could be prosaic or fantastic, it doesn't matter, the thing that people agree upon will be the new chain. A fallback proof of work algorithm that requires more generalised hardware would work well. In case of attack, switch back to GPUs and a lower hash rate on a newer algorithm. ASICs become redundant and the network redistributes to whoever is supplying the GPUs. Then to do a 51% attack the attacker must not only have enough to 51% the ASIC hash rate, but have in reserve more GPUs than the rest of the world can bring to bear at short notice to 51% the fallback method.
I like that no one brings up the question that Bitcoin is not really decentralized. Most of the Core devs are paid by a company (iirc it was Blockstream but might've changed), and ultimately, the paycheck they receive dictates which direction the most used Bitcoin wallet should go, which dictates the direction of the project as a whole.
There were several attempts of merging important BIPs, which were rejected because some developers thought it wasn't in line with the direction their employer wanted.
the issue you are talking about just came up where core basically just did what mining companies want. The result was 14% of nodes now use bitcoin knots a fork of core that doesn't allow that. Core is just 1 github repo it only matters until it doesn't.
If you receive btc in a transaction, the question is, when you consider it to be settled. In other words, how much energy is enough for you to consider it infeasible for an attacker to rewrite recent blocks so that you no longer are the recipient of some btc.
One way to think about it is to relate the total fees to the value of your transaction. If fees in blocks with a block height above the block with your transaction total $10000 (the security budget) then an attacker might be willing to spend that amount on energy to rewrite the chain. Another way to think about it is to relate the security budget to all recent transactions, assuming the attacker is the counter party to all of them (worst case).
In either case, there is no obviously correct answer to how high the security budget has to be on a per-block basis. The question is how long you're willing to wait for the security budget to accumulate and cover your transaction. If the block subsidy decreases and fees don't rise to replace them, then settlement time increases. Don't hand out goods to a counter party if the value of your transaction hasn't at least been met by the security budget. No need to wait longer than the point at which the value of all transactions of the block which includes your transaction has been exceeded by the security budget. An attacker would be losing money at that point if they tried to scam you.
14 comments
[ 4.7 ms ] story [ 39.7 ms ] threadSpecifically some of the political discussions lately feel like they could use better dashboards. The call to action at the end of this article with three main solutions called out now has some context in several dimensions (time, space, monetary).
The doge.gov website for instance would've been a prime candidate for that, like some sort of observablehq.com ability slice and dice a data dashboard. But then you also have to be able to trust the data I suppose.
The actual solution to the security budget is to make a ton of payments in a (blindly) merge-mined sidechain and ensure those transactions there pay lower fees but those lower fees get aggregated into a single high-fee paid on Bitcoin. That is the Drivechain proposal: https://drivechain.xyz/.
Trying to maximize mining profit is adversarial with the end users and makes using bitcoin unattractive.
How much does the security budget need to be?
When is it projected to drop below that?
The closest they come to addressing that seems to be a quote saying "We might have only two halvings left before this becomes a serious issue."
So 8 years-ish?
The original intention was to fund the network entirely off fees eventually. I don't think there was a stated expectation of block size, but it was intended to be made larger at some point.
Before coming up with specific solutions to the cost of securing the network I would think that evaluating what the acceptable range of cost/security should be would be the first starting point.
I feel they also neglect a realistic evaluation of the likelihood of a 51% attack. As soon as someone interferes with the network by 51% attack, everybody knows that it has happened. What countermeasures might be deployed?
While a miner confirming a block is like a rubber stamp from an auditor, there is nothing to stop other people from checking their work. If there are shenanigans they can be spotted, if a genuine 51% attack were to happen people would be highly motivated to counter it. That may involve bringing more compute to the network, or even changing the protocol. Ultimately the network is decided by the consensus of the users. Accepting signed blocks is the consensus. Because of the scale required to do a 51% attack on BitCoin it would almost certainly be detectable who was doing it. Under an attack people would be prepared to swiftly agree to some rule to exclude the attacker, the alternative is just two severe. You could think of it as a fork or you could think of the attackers version as the fork. You could have anything from, 'Today we stop accepting blocks from that pool over there', to 'From now until this mess is resolved, Kate confirms all blocks with her private key, We trust Kate, she's nice' The mitigation could be prosaic or fantastic, it doesn't matter, the thing that people agree upon will be the new chain. A fallback proof of work algorithm that requires more generalised hardware would work well. In case of attack, switch back to GPUs and a lower hash rate on a newer algorithm. ASICs become redundant and the network redistributes to whoever is supplying the GPUs. Then to do a 51% attack the attacker must not only have enough to 51% the ASIC hash rate, but have in reserve more GPUs than the rest of the world can bring to bear at short notice to 51% the fallback method.
There were several attempts of merging important BIPs, which were rejected because some developers thought it wasn't in line with the direction their employer wanted.
One way to think about it is to relate the total fees to the value of your transaction. If fees in blocks with a block height above the block with your transaction total $10000 (the security budget) then an attacker might be willing to spend that amount on energy to rewrite the chain. Another way to think about it is to relate the security budget to all recent transactions, assuming the attacker is the counter party to all of them (worst case).
In either case, there is no obviously correct answer to how high the security budget has to be on a per-block basis. The question is how long you're willing to wait for the security budget to accumulate and cover your transaction. If the block subsidy decreases and fees don't rise to replace them, then settlement time increases. Don't hand out goods to a counter party if the value of your transaction hasn't at least been met by the security budget. No need to wait longer than the point at which the value of all transactions of the block which includes your transaction has been exceeded by the security budget. An attacker would be losing money at that point if they tried to scam you.