gigamegablocks

[vapourminer]

decentralization = ONE (ok manybe a few) datacenter that has the capacity to process this BSV nearly infinate size (at some point) gigabigabloatware data where everything including the kitchen sink and toilet plus the contents of those that goes down it and is stored on chain? i guess always wanted to know the exact composition of my septic tank contents. a "decentralized" blockchain that only huge AWS instances or other supercomputers and the likes likes can run?

No. But nice mischaracterization. At this point, there are plenty of 'normal' computers processing the BSV blockchain.

sure, now. im talking years out (if it doesnt die off in the meantime)

AFAIC, as long as there are no exclusionary barriers for new entrants to participate, then non-mining validation is exactly as decentralized as it need be. More such 'decentralization' is a red herring that serves no useful purpose. I realize this is a controversial perspective, but it is the one I hold.

just the money constraint. perhaps youre so loaded that 100+ grand for a datacenter and update cycle that will be needed eventually is a barely noticeable expense for the convenience and security. so say 50 grand for a casual setup that maybe that would last a couple years? so whats the upper limit for "just verifying" my transactions?

The alternative is to dumb down the entire system to 3 to 7 transactions per second. The notion of such a system working as world money is so ludicrous that it beggars the imagination that anyone would so think.

i agree here. work is needed. it is being done. i may not agree with some of it but stuff is happening regardless.

[figmentofmyass]

The alternative is to dumb down the entire system to 3 to 7 transactions per second. The notion of such a system working as world money is so ludicrous that it beggars the imagination that anyone would so think.

i agree here. work is needed. it is being done. i may not agree with some of it but stuff is happening regardless.

i've scaled back my hopes for bitcoin as some sort of global currency for this reason. i don't think we were being realistic in the early days about the security trade-offs of high transaction throughput.

my biggest concern is actually not the decline of full nodes, but that the hard cap on money supply combined with insufficient mining fees will break bitcoin's security model. miners are in an arms race to accumulate the mining subsidy. that subsidy is quickly dropping. without a block size limit to drive fee revenue up (to replace the mining subsidy) i don't understand how the incentives prevent massive future declines in hash rate. this exposes the network to attack by previous generations of mining hardware, not to mention the chaos it could cause due to congestion and delayed difficulty adjustments alone.

[vapourminer]

huh this post was meant to be a reply to a post in the WO thread, unsure how it got here as a new topic (user error im sure).

but since its here..

one thing ive done in case of miners bombing the difficulty (or vice versa) and the occasional mempool problems is park a bit of coin on exchanges (yes not your keys etc) but at least its there to sell on a moments notice. yeah it can be confiscated, stolen by aliens, all that.

but until there is a fast way to get a tx on chain to somewhere, even if an exorbitant fee is needed (which im actually OK with), it wont work the way i need it to when the mempool is full and im in an emergency situation. i can pull cash from a bank in an instant more or less. try to pull btc out in a cold wallet for whatever in a hurry during peak fomo.

please note im not a big blocker as that has issues of its own. but hopefully the folks with the bulging brains will come up with something.

[suchmoon]

but until there is a fast way to get a tx on chain to somewhere, even if an exorbitant fee is needed (which im actually OK with), it wont work the way i need it to when the mempool is full and im in an emergency situation. i can pull cash from a bank in an instant more or less. try to pull btc out in a cold wallet for whatever in a hurry during peak fomo.

Why would an exorbitant fee not work during peak FOMO moon-sized mempool?

Unless you want to do it in less than ~10 minutes.

[buwaytress]

Accidental new topic but anyway, also my brain can't really process how it would work once the subsidy disappears (and it's not too far off in the future, either. Next halving already gives 3, and then presumable at the next one at least one would hope ~1.5 btc would still bring in enough on the market to make mining worthwhile, but I'm not sure what happens after that. The most logical thought that comes to mind is that at such a high price, mining fees really are enough to keep nodes and rigs active, with massive fees paid perhaps by Lightning node owners who feed off the bulk of transactions happening off chain?

Yes I'm aware I sound dumb. I can't think even 4 years ahead, much less 8 or 12.

[vapourminer]

but until there is a fast way to get a tx on chain to somewhere, even if an exorbitant fee is needed (which im actually OK with), it wont work the way i need it to when the mempool is full and im in an emergency situation. i can pull cash from a bank in an instant more or less. try to pull btc out in a cold wallet for whatever in a hurry during peak fomo.

Why would an exorbitant fee not work during peak FOMO moon-sized mempool?

Unless you want to do it in less than ~10 minutes.

there will (most times) always be someone willing to pay a bigger fee than i and bump me out. but youre right, with proper planning i wouldnt care if it takes days to confirm.

my tentative plan is regularly cash out an amount that should last at least a few months at a time in normal circumstances. just hope an emergency doesnt come up where i need it fast (hours or a day or so tops). but again, thats on me as i should have sufficient fiat reserve for such things.

[figmentofmyass]

one thing ive done in case of miners bombing the difficulty (or vice versa) and the occasional mempool problems is park a bit of coin on exchanges (yes not your keys etc) but at least its there to sell on a moments notice. yeah it can be confiscated, stolen by aliens, all that.

this is actually the purpose of leverage for me. i keep a small fraction of my coins split between bitmex and kucoin futures. i always keep enough coins on deposit that i can hedge 100% of my stash in a "shit hits the fan" type scenario, like this past march.

[o_e_l_e_o]

there will (most times) always be someone willing to pay a bigger fee than i and bump me out.

There will always be someone willing to pay a bigger fee, sure, but rarely will that be enough people willing to pay a bigger fee to bump you out of a block entirely, I would have thought. If you're paying some ridiculous fee like 1000 sats/vbyte, then you are looking at 10 BTC worth of fees to fill a block with higher fee transactions to push yours out. Plus that 10 BTC worth of fees would need to be sustained for every block to keep your transaction unconfirmed.

If that's the case, then the issues regarding the falling mining reward would be solved.

[npuath]

I hope there aren't any rules against necroposting (I'm still confused over why that's reviled).

Isn't pruning a partial solution?

[o_e_l_e_o]

Isn't pruning a partial solution?

If blocks are too big for you to store, then sure you can prune, but that doesn't stop you from having to download them all and verify them all in order to reach the chain tip in the first place. And you have to download them from somewhere. If it becomes so uneconomical to run a full node that only one or two mega rich individuals do so, then that becomes a big problem for decentralization.

Pruning also does nothing to address the issues with the mempool or the fee rate as discussed above.

[npuath]

... you can prune, but that doesn't stop you from having to download them all and verify them all in order to reach the chain tip ...

In my vocabulary, that's the root not the tip (I mention this since nodes regularly use the tip, but seldom the root). Nomenclature aside, you are truistically right in that one would have to download the full tree in order to locally verify the full tree. And that's important; don't trust, verify.

For one-time verification purposes, there's no technical need to hold the full tree locally at the same time; each branch can be verified separately.

Also, once the validity of the full tree is established at a local node, little is gained from full revalidation. This is the principle which makes pruning possible in the first place.

Of course, the full tree still needs to exist, preferably at as many locations as possible. But not necessarly in an expensive (i.e. fast, locally complete and randomly accessible) form.

[o_e_l_e_o]

In my vocabulary, that's the root not the tip (I mention this since nodes regularly use the tip, but seldom the root).

When nodes perform the initial block download and verification, they start at that genesis block and work towards the chain tip, which is the most recent block.

For one-time verification purposes, there's no technical need to hold the full tree locally at the same time; each branch can be verified separately.

True, but bear in mind pruned nodes can be vulnerable in the scenario of a chain split. And as blocks become exponentially larger, then chain splits tend to become both become more frequent and longer.

Also, once the validity of the full tree is established at a local node, little is gained from full revalidation. This is the principle which makes pruning possible in the first place.

You still need a full node if you are going to run a wallet or indeed view any transactions prior to your most recent block. Having only a handful of full nodes responsible for fetching data on all but the most recent UTXOs is a big risk.

[npuath]

When nodes perform the initial block download and verification, they start at that genesis block and work towards the chain tip, which is the most recent block.

Got you. For a full verification, this is likely the most efficient way, and also how my own implementation works. After that, new blocks are verified up towards the root until a previously verified branch is reached.

... pruned nodes can be vulnerable in the scenario of a chain split ...

Instinctively, I would say that chain splits present no prune-specific vulnerabilities; even in the extreme case that the split is so far towards the root that it can't be reached from a pruned node's partial branches, there's no risk of false verification. In any case, chain splits are so rare and contentious that it would be prudent to revalidate from scratch after each one, pruned node or not.

... as blocks become exponentially larger, then chain splits tend to become both become more frequent and longer ...

Perhaps you mean local chain reorganisations, not actual forks? A node may indeed discover a new, longer chain, orphaning previous blocks, but I don't see how this is prune-specific (given reasonable pruning parameters).

... You still need a full node if you are going to run a wallet ...

I'm sure you don't really mean this  

... or indeed view any transactions prior to your most recent block. Having only a handful of full nodes responsible for fetching data on all but the most recent UTXOs is a big risk.

Yes, I agree on both. My hopeful guess is that a large enough share of transaction needs could be fulfilled by cheap, pruned nodes (with all blocks from, say, the last 6 months), and that the rest of the data might be stored (locally, hence trusted, or non-locally if partner trust can be established) in a cheap, slow, non-transactional manner.

[o_e_l_e_o]

Instinctively, I would say that chain splits present no prune-specific vulnerabilities; even in the extreme case that the split is so far towards the root that it can't be reached from a pruned node's partial branches, there's no risk of false verification. In any case, chain splits are so rare and contentious that it would be prudent to revalidate from scratch after each one, pruned node or not.

They are not that rare, but in general in bitcoin are limited to one or sometimes two blocks and so don't pose an issue to pruned nodes. This changes if we adopt blocks which are gigabytes in size. The scam coin BSV, for example, experiences frequent chain splits, some over 100 blocks long. And verifying from scratch every time when their blockchain is over 8 TB in size is no small task if your node is pruned and you have to redownload from scratch.

Perhaps you mean local chain reorganisations, not actual forks? A node may indeed discover a new, longer chain, orphaning previous blocks, but I don't see how this is prune-specific (given reasonable pruning parameters).

A chain reorg is a fork. And if the fork happens from a block your node has already pruned, then it will be unable to verify the new chain.

I'm sure you don't really mean this  

You do if you want to do it securely, privately, and be based on verification rather than trust. If you are not running a wallet with data from your own node, then you are running it with data from someone else's node.

[npuath]

They are not that rare ... a chain reorg is a fork.

Sure, the terms are fuzzy. In this case, I contrasted forks with local chain reorgs. YMMV, but I know of only 6 global and sustained forks (excluding XT, BTH, Gold etc): 2010 (overflow bug), 2013 (db migration fix), 2015 (DER encoding), 2017 (Segwit), 2018 (double spending fix), 2021 (Taproot). Few and big enough that I would advocate revalidation, pruned node or not.

The "other kind" of reorgs, where blocks get orphaned because two or more blocks are mined almost at the same time, has as far as I can tell not occurred since 2019. It used to be much more frequent and might increase again (if f.x. inter-miner latency went up again), but with reasonable pruning parameters, this shouldn't affect a pruned node specifically, as far as I can tell; as soon as a new block is mined (from either chain), the tie is broken (in all likelihood).

This changes if we adopt blocks which are gigabytes in size. The scam coin BSV, for example, experiences frequent chain splits, some over 100 blocks long.

I take it you don't share the Satoshi Vision I think BSV has a max block size of 128 MB, and if we change BCT rules to allow gigabyte blocks, my current viewpoints may indeed be invalidated. I still fail, however, to grasp why a larger block size would cause orphans more frequently, let alone in chains of more than a hundred blocks at a time - how could a larger block size stop nodes from receiving any and all blocks from a competing chain in more than a thousand minutes? Especially since the competing chain actually worked harder for 625+ coins (if not, no split and no issue)?

And verifying from scratch every time when their blockchain is over 8 TB in size is no small task if your node is pruned and you have to redownload from scratch.

Precisely! That a gigantic blockchain is no small task is the point of this thread  I'm suggesting that maybe pruned nodes, in combination with cheap, slow, non-transactional storage of pruned-away data, might help alleviating part of the consequences.

[thecodebear]

Why is anyone even still talking about this? Big blockers who wanted centralized garbage altcoins got their trash coins BCH and then BSV years ago and both failed miserably, and nobody cares about them. Bitcoin meanwhile, is the most secure network in human history and is growing into the world's store of value and eventually the world's alternate currency, something it wouldn't be able to do if it went with big blocks and therefore compromised the very thing that makes it valuable and unique.

Also Bitcoin's security model is fine. Energy use on Bitcoin will probably peak at some point and then fall a bit to long term equilibrium. Which is fine because that level will likely be much higher than it is today and already today the hash power of bitcoin mining is a huge amount that could never be duplicated by any attackers. Even as the reward subsidy dwindles it'll be fine. The price of transactions will no longer be a cheap $1 or whatever but that's okay because doing on-chain transactions will be sort of like wiring money is today, something you don't do very often. On-chain will be just for large transactions where the tx fee is entirely negligible, or moving money around, while everything else will be done on Lightning or possibly other later developed L2's where you pay like a penny for a transaction. So it'll be alright for users. And for miners it'll be fine because by then miners will almost entirely be using either essentially free stranded energy (startup cost but then extremely low maintenance cost for renewable energy) or they will be mining companies who are tied directly into power plants (which is already being done today) to strengthen the energy infrastructure of society while also getting super cheap energy for mining. Any miners not doing these things, like those that are actually paying for energy through providers on-grid, will have been kicked out of the mining business due to costs.

Basically, as the mining rewards gradually over the decades become mostly from tx fees, it just means the mining industry will get far more efficient. Those who don't won't be able to mine anymore. And the mining industry will move entirely to operating directly at the sources of energy, instead of being end users of power, which will actually be better for society in an additional way because no longer will we hear stories of miners eating up the electricity of some random town. As in all things related to Bitcoin mining, an equilibrium will be reached where the economic cost of mining will be a bit lower than the economic reward for mining, and it'll still be plenty enough for Bitcoin to be globally secure, the most secure network in the world.

[npuath]

Why is anyone even still talking about this?

In my case, because with a gigantic chain size, decentralisation is at risk (see above regarding costs etc).

The price of transactions will no longer be a cheap $1 or whatever but that's okay because doing on-chain transactions will be sort of like wiring money is today, something you don't do very often. On-chain will be just for large transactions where the tx fee is entirely negligible, or moving money around, while everything else will be done on Lightning or possibly other later developed L2's where you pay like a penny for a transaction. So it'll be alright for users.

This scares me. What you're describing is mitigation by centralisation, forced trust and forced custody. Unless you're proposing that every user should run her own L2 node, in which case we're back where we started (prohibitive costs).

And for miners it'll be fine because by then miners will almost entirely be using either essentially free stranded energy (startup cost but then extremely low maintenance cost for renewable energy) or they will be mining companies who are tied directly into power plants (which is already being done today) to strengthen the energy infrastructure of society while also getting super cheap energy for mining.

Unfortunately (in my view), this separation between "users" and "miners" already is a fact. The original reason to use proof of work instead of simply counting IP addresses (to determine majorities) was to mitigate the fact that certain actors are able to allocate huge numbers of addresses. The scenario you're describing is magnitudes worse but not at all unlikely, I'm afraid. It's not really the topic of this thread though (but very related, I agree).

[o_e_l_e_o]

The "other kind" of reorgs, where blocks get orphaned because two or more blocks are mined almost at the same time, has as far as I can tell not occurred since 2019.

That link is very out of date. The most recent fork I am aware of is at block 772,981, which was around 2 weeks ago. There was a competing block with the hash 0000000000000000000682990a0dae862b48e0451d619938215dd47ed9560200 mined by Foundry. Usually we see on average around one such event a month.

but with reasonable pruning parameters, this shouldn't affect a pruned node specifically, as far as I can tell; as soon as a new block is mined (from either chain), the tie is broken (in all likelihood).

I completely agree, with bitcoin as it is just now. But if you are talking about inflating the block size to several gigabytes or more, then such stale blocks become significant more frequent, and the chains of stale blocks also become longer.

I think BSV has a max block size of 128 MB

It's actually 4 GB.

I still fail, however, to grasp why a larger block size would cause orphans more frequently

Because it takes longer to download, verify, and then broadcast that block to other nodes. It can take tens of minutes for such a block to make its way across the entire network, as opposed to the few seconds as happens in bitcoin at present. During those minutes, all other miners will continue to work on top of the previous block, and therefore have extra time to find a solution. If they find a solution by the time the other block finally arrives at them, they'll simply ignore it and keep trying to build on their own block, causing a growing re-org.

Let's call you miner A, and call me miner B. We are both mining on top of the same block. You find a block, which we will call A1, which you broadcast. It take minutes to reach me, and in that time, I find block B1, at the same height as A1. You are now mining on top of A1, and I'm mining on top of B1. I find B2, and broadcast it. By the time it reaches you, you have found A2, and some other miner has also found C2. Each of us keeps mining on top of our own blocks, because the time delay in broadcasting such oversized and bloated blocks means it takes a long period of time until someone finally gets ahead enough to win the race, resulting in a re-org many blocks deep.

Here's another link explaining this: https://bitcoin.stackexchange.com/questions/86169/why-do-large-blocks-increase-the-probability-of-chain-reorgs

[npuath]

The "other kind" of reorgs, where blocks get orphaned because two or more blocks are mined almost at the same time, has as far as I can tell not occurred since 2019.

That link is very out of date. The most recent fork I am aware of is at block 772,981, which was around 2 weeks ago. There was a competing block with the hash 0000000000000000000682990a0dae862b48e0451d619938215dd47ed9560200 mined by Foundry. Usually we see on average around one such event a month.

Indeed it is. I got it from a fellow forum user in another thread. It looks live, but it hasn't been updated since 2020.

I think BSV has a max block size of 128 MB

It's actually 4 GB.

Right you are again, I lazily relied on english WP.

With gigabyte block sizes, I understand and agree completely.

Appearantly this topic was created accidently, and it's title isn't really matching the first posts. My interpretation of the OP has been that, as the total chain size (not individual block sizes) grows ever larger, prohibitive hard- and netware costs may cause a (further, potentially massive) decline of full nodes.

With current bitcoin block sizes, I still think hybrid pruning (as per my posts above) might be part of a solution to that potential problem.

[o_e_l_e_o]

Right you are again, I lazily relied on english WP.

That page isn't incorrect. When BSV first split, their max block size was indeed 128 MB. However, it is now 4 GB, and their total blockchain is over 8 TB.

My interpretation of the OP has been that, as the total chain size (not individual block sizes) grows ever larger, prohibitive hard- and netware costs may cause a (further, potentially massive) decline of full nodes.

With current bitcoin block sizes, I still think hybrid pruning (as per my posts above) might be part of a solution to that potential problem.

Yeah, if you don't have the storage space for the entire blockchain then running a pruned node instead of a full node is a logical step. However, it's probably worth pointing out that even after 14 years, bitcoin's blockchain is yet to hit 500 GB in size, and you can buy a 4 TB hard drive for under $40. I don't think we will run in to the problem where it is prohibitively expensive to run a full node for a long time.