Why don't we prune to scale?

[DooMAD]

So let's say we implement it in a way that miners first commit to a utxo set by including its hash in a block and n blocks after that ( choose a high enough n so that it is practically impossible to change that block ) we attach the utxo set to the block. This way when the hash of the utxo set is put into a block everybody could verify whether it is correct. If it's not nodes will reject that block, if it is correct nodes will accept it.

SDUC-compatible nodes could verify it.  Non-SDUC-compatible nodes (i.e. all the current nodes on the network) would not have the functionality to verify it because they won't know of the existence of this new hash, let alone be able to verify it.  The only way it could work in a trustless fashion is if a significant proportion of the network were to adopt it simultaneously.

[1714897468]

1714897468

[1714897468]

1714897468

[1714897468]

1714897468

[1714897468]

1714897468

[1714897468]

1714897468

[aliashraf]

So let's say we implement it in a way that miners first commit to a utxo set by including its hash in a block and n blocks after that ( choose a high enough n so that it is practically impossible to change that block ) we attach the utxo set to the block. This way when the hash of the utxo set is put into a block everybody could verify whether it is correct. If it's not nodes will reject that block, if it is correct nodes will accept it.

SDUC-compatible nodes could verify it.  Non-SDUC-compatible nodes (i.e. all the current nodes on the network) would not have the functionality to verify it because they won't know of the existence of this new hash, let alone be able to verify it. The only way it could work in a trustless fashion is if a significant proportion of the network were to adopt it simultaneously.

OR
A strong enough portion of miners could adopt it and SDUC nodes would wait for enough commitments to a UTXO to accumulate for considering it as a confirmed UTXO, e.g. 1000 commitments in 3000  blocks in a scenario when 33% of miners are compatible. SDUC nodes wouldn't stop querying the blockchain (in reverse, top-down order) unless they probably find a UTXO with enough accumulated commitments.

A more aggressive approach would be implementing UTXO commitment as a UASF once a majority of mining are signaling their support.

PS: If you know that these ideas have been discussed before, could you give me a source where I could find the discussion or a special term for such kind of proposal which I can search for?  

Check this: https://bitcointalk.org/index.php?topic=5046152.msg46662809#msg46662809

[cellard]

It's always going to be a tradeoff. The most hardcore users aren't going to buy that cutting off a chunk of the blockchain is safe. As long as it was optional then let other people do it, but don't ruin it for those that want to sync since the genesis block. In any case from what I can remember reading when I asked the same thing a while ago what I think I was told is that basically you couldn't sync without doing it from scratch anyway. Correct me if im wrong but you cannot run a node in pruned mode unless you sync from scratch even to this day (you can save a ton of space by not storing the entire blockchain as it cuts as it downloads but it must be downloaded and validated from scratch). I think at 1MB this is not a problem, however with bigger blocksizes I wonder if in in the future it would become a problem trying to sync from scratch but thus far is not an issue.

As I've extensively discussed it above-thread and elsewhere, it is absolutely possible for nodes to decide about the length of the chain they want to download (in boot process) and maintain because bitcoin essentially is a consensus mechanism for the state of a ledger such that as time passes this consensus gets more and more stronger and unforgeable. Taking advantage of this inherent property, it would be trivial to download an old (and secure) enough representation of the state (the UTXO at a given height) instead of rewinding the tape to big bang.

But not rewinding the tape to big bang is like it or not a tradeoff. As technology progresses, it shouldn't be a problem to keep being able to download the tape since the big bang, again assuming blocksize isn't raised to the point that this becomes impossible.

I would need to see numbers to see % of potential exploits being possible if you start cutting the tape. Exploits or failure to reach consensus can happen in a long enough timeline and if that happens then you want to be able to have as many copies of the entire blockchain not to mention being able to download it from scratch.

[aliashraf]

It's always going to be a tradeoff. The most hardcore users aren't going to buy that cutting off a chunk of the blockchain is safe. As long as it was optional then let other people do it, but don't ruin it for those that want to sync since the genesis block. In any case from what I can remember reading when I asked the same thing a while ago what I think I was told is that basically you couldn't sync without doing it from scratch anyway. Correct me if im wrong but you cannot run a node in pruned mode unless you sync from scratch even to this day (you can save a ton of space by not storing the entire blockchain as it cuts as it downloads but it must be downloaded and validated from scratch). I think at 1MB this is not a problem, however with bigger blocksizes I wonder if in in the future it would become a problem trying to sync from scratch but thus far is not an issue.

As I've extensively discussed it above-thread and elsewhere, it is absolutely possible for nodes to decide about the length of the chain they want to download (in boot process) and maintain because bitcoin essentially is a consensus mechanism for the state of a ledger such that as time passes this consensus gets more and more stronger and unforgeable. Taking advantage of this inherent property, it would be trivial to download an old (and secure) enough representation of the state (the UTXO at a given height) instead of rewinding the tape to big bang.

But not rewinding the tape to big bang is like it or not a tradeoff. As technology progresses, it shouldn't be a problem to keep being able to download the tape since the big bang, again assuming blocksize isn't raised to the point that this becomes impossible.

You can always find a way to over-secure a system by reducing the utility level and/or spending more. The naivest approach to securing bitcoin but would be demanding "infinite work" (which is impractical anyway) to reach kinda "finality".
Bitcoin is secure against long range attacks because of its incentive model, there is no finality in bitcoin, what we have is just accumulation of work to levels that makes it unprofitable for adversaries to commit long range attacks. No absolute security in bitcoin.

As of technology progress, I don't think it would be a good practice to complicate things and impose artificial bottlenecks to a system and pray for technology to help and I don't see any potential for technology to win the race from blockchain growth and consecutive bandwidth requirements, helping the current situation with slow and expensive bootstrap of bitcoin full nodes.

I would need to see numbers to see % of potential exploits being possible if you start cutting the tape. Exploits or failure to reach consensus can happen in a long enough timeline and if that happens then you want to be able to have as many copies of the entire blockchain not to mention being able to download it from scratch.

Potential exploits always exist for bitcoin but they are ways more expensive to be considered an exploit. A pruned node with like 2000 blocks height is practically secure just like conventional full nodes. Supporting a fast bootstrap protocol for pruned nodes have nothing to do with their security as long as the base UTXO is confirmed by enough work, the same factor that justifies pruning.

[cellard]

@aliashraf so what is your proposed solution to being able to sync with the blockchain with a pruned mode node only downloading the latest X MB of blocks (X space being secure based on what calculations again? because you must input a minimum safe requirement for the user and this X value will change depending on current hashrate and I guess other variables). Because again as far as I remember this wasn't possible and no one was proposing a realistic solution. Would it require a hardfork?

[aliashraf]

@aliashraf so what is your proposed solution to being able to sync with the blockchain with a pruned mode node only downloading the latest X MB of blocks (X space being secure based on what calculations again? because you must input a minimum safe requirement for the user and this X value will change depending on current hashrate and I guess other variables). Because again as far as I remember this wasn't possible and no one was proposing a realistic solution. Would it require a hardfork?

Given the current ultra right wing dominance in bitcoin politics in which nobody GAS for progressive ideas and the cause and it is just about keeping bitcoin uncompromised to save whales assess, I see no future for radical improvement proposals other than hard forking, but as far as we discuss technically, no it doesn't require such a fork because UTXO commitments could be implemented using special coinbase outputs that legacy nodes wouldn't reject and and a UTXO would become confirmed when enough commitments is achieved.

In my SDUC proposal, a very steep migration path is considered in which we can start even with a minority of hashrate in the beginning and wait for more occasional confirmations.

By enough I mean the height that is considered safe by user and not the protocol. In pruning, user chooses the height according to his security requirements and understanding of chain rewrite threats, it would be the same for UTXO commitment.

[cellard]

@aliashraf so what is your proposed solution to being able to sync with the blockchain with a pruned mode node only downloading the latest X MB of blocks (X space being secure based on what calculations again? because you must input a minimum safe requirement for the user and this X value will change depending on current hashrate and I guess other variables). Because again as far as I remember this wasn't possible and no one was proposing a realistic solution. Would it require a hardfork?

Given the current ultra right wing dominance in bitcoin politics in which nobody GAS for progressive ideas and the cause and it is just about keeping bitcoin uncompromised to save whales assess, I see no future for radical improvement proposals other than hard forking, but as far as we discuss technically, no it doesn't require such a fork because UTXO commitments could be implemented using special coinbase outputs that legacy nodes wouldn't reject and and a UTXO would become confirmed when enough commitments is achieved.

In my SDUC proposal, a very steep migration path is considered in which we can start even with a minority of hashrate in the beginning and wait for more occasional confirmations.

By enough I mean the height that is considered safe by user and not the protocol. In pruning, user chooses the height according to his security requirements and understanding of chain rewrite threats, it would be the same for UTXO commitment.

The problem is, if you start adding "progressive ideas" into Bitcoin instead of treating it as a sort of a rule that we all must follow, you may give space for politicians to start molding the protocol at will.

Your idea seems interesting. However "By enough I mean the height that is considered safe by user and not the protocol." How does the user know what's safe enough for him? people is typically too lazy and underrate risk in order for convenience. If people start using unsafe heights couldn't this undermine the overall safety of the network?

Anyway I hope you get this all coded and presented as a soft fork.

[aliashraf]

@aliashraf so what is your proposed solution to being able to sync with the blockchain with a pruned mode node only downloading the latest X MB of blocks (X space being secure based on what calculations again? because you must input a minimum safe requirement for the user and this X value will change depending on current hashrate and I guess other variables). Because again as far as I remember this wasn't possible and no one was proposing a realistic solution. Would it require a hardfork?

Given the current ultra right wing dominance in bitcoin politics in which nobody GAS for progressive ideas and the cause and it is just about keeping bitcoin uncompromised to save whales assess, I see no future for radical improvement proposals other than hard forking, but as far as we discuss technically, no it doesn't require such a fork because UTXO commitments could be implemented using special coinbase outputs that legacy nodes wouldn't reject and and a UTXO would become confirmed when enough commitments is achieved.

In my SDUC proposal, a very steep migration path is considered in which we can start even with a minority of hashrate in the beginning and wait for more occasional confirmations.

By enough I mean the height that is considered safe by user and not the protocol. In pruning, user chooses the height according to his security requirements and understanding of chain rewrite threats, it would be the same for UTXO commitment.

The problem is, if you start adding "progressive ideas" into Bitcoin instead of treating it as a sort of a rule that we all must follow, you may give space for politicians to start molding the protocol at will.

Your idea seems interesting. However "By enough I mean the height that is considered safe by user and not the protocol." How does the user know what's safe enough for him? people is typically too lazy and underrate risk in order for convenience. If people start using unsafe heights couldn't this undermine the overall safety of the network?

Anyway I hope you get this all coded and presented as a soft fork.

Analogically speaking, we need to distinguish between constitutional and statutory rules. Bitcoin does not have a legislation or jurisdiction body and it triggers governance problems that make it very hard to deal with political issues but it doesn't mean that such issues do not exist.

Bitcoin is one of the most political tech events in recent history, it was built around a hacker idea of resistance and as a libertarian movement and progress has always been a core principle of such movements. Discussing radical improvements is not what makes bitcoin political on the contrary political nature of bitcoin turns a pure technical improvement proposal to a political one.

As of users choice of enough security, it is very common, right now users choose to wait for how many confirmations and they choose pruning height.

To run a wallet that is not considered to make multi million dollars transactions, I'd rather run a pruned node with like 200 blocks height and if UTXO commitment was mandatory (a hard fork) I wouldn't change that parameter more than 2x-3x but for a soft implementation (SDUC) I'd go for 1k-2k chain height. A miner with huge investment, may tune to 100,000+ block height while a home miner would stick with 1000 or less height. Bitcoin whales who maintain/trade large amounts of bitcoin, exchanges, ... might choose to keep chains in ranges between 10k-50k. Historians, researchers, watchdogs, ... may keep the full history by tuning to a very large number or simply turning prun mode off.

Thanks for the support, by the way.

[cellard]

@aliashraf so what is your proposed solution to being able to sync with the blockchain with a pruned mode node only downloading the latest X MB of blocks (X space being secure based on what calculations again? because you must input a minimum safe requirement for the user and this X value will change depending on current hashrate and I guess other variables). Because again as far as I remember this wasn't possible and no one was proposing a realistic solution. Would it require a hardfork?

Given the current ultra right wing dominance in bitcoin politics in which nobody GAS for progressive ideas and the cause and it is just about keeping bitcoin uncompromised to save whales assess, I see no future for radical improvement proposals other than hard forking, but as far as we discuss technically, no it doesn't require such a fork because UTXO commitments could be implemented using special coinbase outputs that legacy nodes wouldn't reject and and a UTXO would become confirmed when enough commitments is achieved.

In my SDUC proposal, a very steep migration path is considered in which we can start even with a minority of hashrate in the beginning and wait for more occasional confirmations.

By enough I mean the height that is considered safe by user and not the protocol. In pruning, user chooses the height according to his security requirements and understanding of chain rewrite threats, it would be the same for UTXO commitment.

The problem is, if you start adding "progressive ideas" into Bitcoin instead of treating it as a sort of a rule that we all must follow, you may give space for politicians to start molding the protocol at will.

Your idea seems interesting. However "By enough I mean the height that is considered safe by user and not the protocol." How does the user know what's safe enough for him? people is typically too lazy and underrate risk in order for convenience. If people start using unsafe heights couldn't this undermine the overall safety of the network?

Anyway I hope you get this all coded and presented as a soft fork.

Analogically speaking, we need to distinguish between constitutional and statutory rules. Bitcoin does not have a legislation or jurisdiction body and it triggers governance problems that make it very hard to deal with political issues but it doesn't mean that such issues do not exist.

Bitcoin is one of the most political tech events in recent history, it was built around a hacker idea of resistance and as a libertarian movement and progress has always been a core principle of such movements. Discussing radical improvements is not what makes bitcoin political on the contrary political nature of bitcoin turns a pure technical improvement proposal to a political one.

As of users choice of enough security, it is very common, right now users choose to wait for how many confirmations and they choose pruning height.

To run a wallet that is not considered to make multi million dollars transactions, I'd rather run a pruned node with like 200 blocks height and if UTXO commitment was mandatory (a hard fork) I wouldn't change that parameter more than 2x-3x but for a soft implementation (SDUC) I'd go for 1k-2k chain height. A miner with huge investment, may tune to 100,000+ block height while a home miner would stick with 1000 or less height. Bitcoin whales who maintain/trade large amounts of bitcoin, exchanges, ... might choose to keep chains in ranges between 10k-50k. Historians, researchers, watchdogs, ... may keep the full history by tuning to a very large number or simply turning prun mode off.

Thanks for the support, by the way.

As long as its doable with a soft-fork then I guess it will not be any less controversial than what prune nodes are already. However a hardfork, we all know what happens with hardforks.

In any case you may add your proposal here:

https://bitcoinhardforkresearch.github.io/

Whenever there is an actual hardfork that somehow ends up without 2 Bitcoins, some of these stuff could be added, but like I said, I just don't see a successful hardfork happening anytime soon if ever.