Moving towards user activated soft fork activation

[Uberse]

You could've upped the blocksize 4 years ago.

Yep. Could've just ordered all the miners and nodes to do it.

[1714646913]

1714646913

[Quickseller]

You could've upped the blocksize 4 years ago.

Yep. Could've just ordered all the miners and nodes to do it.

Im not sure about 4 years ago, but it would probably not be unreasonable to believe that concensus could have been reached for 8 MB blocks two years ago.

Judging solely by mores law, it would probably be safe to have a max block size of 8 MB 2 years ago if 1 MB was safe 7 years ago, especially if a very simple fix to the risk of having too many signatures in a transaction was also implemented.

[Carlton Banks]

You could've upped the blocksize 4 years ago.

Yep. Could've just ordered all the miners and nodes to do it.

Im not sure about 4 years ago, but it would probably not be unreasonable to believe that concensus could have been reached for 8 MB blocks two years ago.

Except 2 years ago, an overwhelming consensus of Bitcoin users rejected a less modest 2MB hard fork proposal (and then they also rejected essentially the same proposal by a "different" external development team a year hence, just in case the first rejection wasn't a clear enough message)

What makes you think that we would have all agreed to something 4 times the size of that? 8MB was on the table then, and no-one but a small minority of miners took that even slightly seriously

[-ck]

Judging solely by mores law, it would probably be safe to have a max block size of 8 MB 2 years ago if 1 MB was safe 7 years ago.

Except that we fell off the curve for Moore's law years ago. Technology is struggling to grow at even 1/4 the rate Moore's law predicted now.

[Quickseller]

Judging solely by mores law, it would probably be safe to have a max block size of 8 MB 2 years ago if 1 MB was safe 7 years ago.

Except that we fell off the curve for Moore's law years ago. Technology is struggling to grow at even 1/4 the rate Moore's law predicted now.

Looking at it strictly from a cost/unit, then yes you are correct. However in recent years, manufacturers of computer related products have invested less in being able to increase the number of units in the products they sell, and have invested more into making the products they sell more reliable, and otherwise increasing the utility of their products.

Take hard drives for example, while the rate at which the price per GB has declined has fallen, hard drives have failed at lower rates, and can access data more efficiently. This makes comparing the cost of a 1 TB HDD today to the cost of a 1 TB HDD yesterday not an apples-to-apples comparison. There is also the issue of the fact that from a retail user's point of view, there is little reason to need 2 TB worth of space on your HDD, especially considering that things like moves and tv shows can easily (and cheaply) be streamed as the user wishes to watch them -- this fact creates less pressure for manufacturers to create larger HDDs, which keeps somewhat of a mesh floor on the unit cost of HDD space. If a retail consumer has to choose between two hard drives, one with 500 GB worth of space, and one with 1 TB worth of space, he may choose the 500 GB HDD, even though the unit cost of drive space is higher because he has little/no use for the 2nd 500 GB worth of space.

Also, as HDDs become more reliable, consumers need to purchase less of them in order to keep their data on a HDD, along with necessary backups (or cheaper backup options can be used if as the chances of failure approach zero). Having to purchase HDDs less frequently and having to purchase less HDDs for backup purposes further skews the apples-to-apples comparison of unit costs.

If and when there are more real world retail demands for larger HDDs, manufacturers will invest more into creating larger HDDs, and I believe the unit cost will continue to fall at an accelerated rate.

[Carlton Banks]

All of which has nothing to do with Moore's law, Quickseller.

Moore's law is done, as ck said. It may be revived in the future, but it will need to use a totally different paradigm to double computational power every 12-18 months (as a side effect of shrinking transistors in size), which is what Moore's law stipulated

[pamparam]

The biggest problems for BTC and all crypto currency:

1. Its centralized. It will never be a decentralized system until all mining process will be as easy as downloading your bitcoin core wallet. Actually, it should be done like this: you can activate mining by clicking one button in your wallet. Now still the whole bitcoin thing is understandable only to small percentage of people in the world, and mining is only possible to those who are advanced level in tech and programming. If BTC has a vision to be better and more popular than fiat, it should be made much more easier to use and to mine. (Soon the whole mining power will be in few hands and it will no longer be different from fiat).

2. Voting power should be not only in miners hands, but in ordinary bitcoins users too. Now BTC is facing the problem that it is slowly transforming to the ordinary money system, where the whole power have federal reserve bank, and here the control is slowly taken by big mining pools and wealthy BTC holders. They want to make decisions to the rest of the users, because they think they can make better decisions.

The whole situation sucks, and the current path of BTC is wrong. Ordinary user with his wallet, should be a miner too, mining rewards should be split among everyone fairly, all have the voting power.

Well, I can understand your pain, and how nice would it be to go back in time and have yet another chance to mine easy BTC when the price was $1 or even less, but unfortunately it's old good 2017 :-) However, if you had that chance again, and knew nothing of what you know today, would you really be interested in Satohi's idea?

You missed my point. If the mining process from the begining would have been easier, like downloading the wallet and pressing button to start it, now we would have really decentralized coin. But from the begining all things related to BTC is too difficult for ordinary people to adopt it.

The beginnings of any technology is difficult for ordinary people. Look at Windows 3.11, or Windows 95 and so on. Do you remember how difficult it was to install device drivers back in late 90's? And now you don't even bother about it in modern Windows or Linux distros.

You got the point here, I agree, but It looks like crypto devs are do not bother to make it easier to mine...

[pamparam]

When I first time learned about BTC, the first question to me was: what will be with those block sizes and overall chain size? I understand that you can move it up always as needed, but cmon, if BTC will ever be the number 1 currency in the world, the blockchain will weight enormous amount of terabytes... anyone from devs thinking about it? Have any solutions to it? Even now on my new mac to download btc core wallet with all blockchain and to purge it to smaller size took like 3 days with normal internet... in future it could take ages...

[tomkat]

... It looks like crypto devs are do not bother to make it easier to mine...

Right, some of the devs (especially those from Core) are not interested in user experience too much.
Those guys are there for various reasons, and many of the reasons aren't necessarily economic.
As a result, they have no direct incentive for doing what users want, but rather trying to force their own views or ideas.

When I first time learned about BTC, the first question to me was: what will be with those block sizes and overall chain size? I understand that you can move it up always as needed, but cmon, if BTC will ever be the number 1 currency in the world, the blockchain will weight enormous amount of terabytes... anyone from devs thinking about it? Have any solutions to it? Even now on my new mac to download btc core wallet with all blockchain and to purge it to smaller size took like 3 days with normal internet... in future it could take ages...

I think it's already impossible for certain machines to download full Bitcoin blockchain. It's not only the problem of the size but also tech specs.
Few days ago I started to sync the blockchain from scratch on my older laptop (purchased 6-7 years ago), and it's "stuck" at 40% (with db_cache set to 2000 which was max for that machine). The progress is 0.2% per hour now, so I'm pretty sure it will never sync but wanted to check how bad is it :-)

I wonder if regular home-class users will be able to sync BTC blockchain at all in the future (let's say in 5-6 years). Maybe the only option for them will be bootstrap files, but not sure if it's possible to verify the downloaded blockchain against network version.

[hankyulpark]

I think it's already impossible for certain machines to download full Bitcoin blockchain. It's not only the problem of the size but also tech specs.
Few days ago I started to sync the blockchain from scratch on my older laptop (purchased 6-7 years ago), and it's "stuck" at 40% (with db_cache set to 2000 which was max for that machine). The progress is 0.2% per hour now, so I'm pretty sure it will never sync but wanted to check how bad is it :-)

I wonder if regular home-class users will be able to sync BTC blockchain at all in the future (let's say in 5-6 years). Maybe the only option for them will be bootstrap files, but not sure if it's possible to verify the downloaded blockchain against network version.

And we must remember that to run a node you need to have the full blockchain on your computer. With its size increasing at every block, the computational power demand will be constantly rising. This will probably kill the home based nodes, leading to the already much-discussed topic of undesired node centralization, right?

[tomkat]

I think it's already impossible for certain machines to download full Bitcoin blockchain. It's not only the problem of the size but also tech specs.
Few days ago I started to sync the blockchain from scratch on my older laptop (purchased 6-7 years ago), and it's "stuck" at 40% (with db_cache set to 2000 which was max for that machine). The progress is 0.2% per hour now, so I'm pretty sure it will never sync but wanted to check how bad is it :-)

I wonder if regular home-class users will be able to sync BTC blockchain at all in the future (let's say in 5-6 years). Maybe the only option for them will be bootstrap files, but not sure if it's possible to verify the downloaded blockchain against network version.

And we must remember that to run a node you need to have the full blockchain on your computer. With its size increasing at every block, the computational power demand will be constantly rising. This will probably kill the home based nodes, leading to the already much-discussed topic of undesired node centralization, right?

Well, if a node is already synced, then I think there won't be problems to follow the newly created blocks. If you run out of space on your current disk then you just add a new one and continue. If you run out of computation power, then you change the specs and use your synced blockchain.

The main problem is to sync it from scratch and in few years, with bigger blocks (be it Segwit, EC or something else), it may be a problem for any home user.
Having it synced now and keeping updated may be a valuable asset :-)

[stdset]

I'm trying to understand how UASF is supposed to work. Let's consider 2 scenarios:

1) Unupgraded miners are disorganised. Each of them mines on it's own.
Upgraded nodes see unupgraded blocks as invalid, don't relay them, that creates friction in unupgaded blocks propagation. Upgraded miners see unupgraded blocks as invalid, don't mine on top of them. But unupgraded miners see upgraded blocks as valid, mine on top them.

Say we have only 10% of hashpower upgraded, 90% of total hashpower mines on top of unupgraded blocks and 100% of total hashpower mines on top of upgraded blocks. Doesn't matter how long unupgraded chain grows, upgraded nodes see it as invalid. But it does matter when upgraded chain becomes longer than unupgraded, the latter gets orphaned by all nodes, even those who mined it. Nonetheless, permanent (at first sight) divergence is likely to happen. Once unupgraded chain outruns the upgraded (because of variance), unupgraded miners will be locked on it, because it has more accumulated PoW. Situation starts to look like a hardfork.

The greater upgraded hashpower part, the less likely permanent divergence to happen, but still it can happen, unless upgraded hashpower is more than 50%.

2) Unupgraded miners are organised, they detect upgraded blocks, don't mine on top of them. For example, they can create an unupgraded block with a tx conflicting with new rules, and mine only the chain, which contains that block, effectively setting a checkpoint. Essentially it's a hardfork.

In both cases we will likely have a hardfork-like situation, unless more than half of total hashpower is upgraded and unupgraded miners don't decide to fork off. What raises a question: does UASF have any advantages over an explicit hardfork? Well, there are some. I suppose economic majority supports UASF. BTC from the unupgraded fork are of much less utility than from the upgraded. Unupgraded miners will experience difficulties spending their rewards, what will incentivize them to upgrade. Once enough miners upgrade, the unupgraded fork will be naturally orphaned, without involving a real hardfork. In the case unupgraded miners decide to hardfork off, the onus of the fork is on them.

[Carlton Banks]

@stdset

You're making and invalid assumption: that miners using non-Segwit clients will reject blocks with Segwit transactions. They won't, the Segwit soft-fork was desgined in a way to prevent that happening.

What would happen as a result of a large proportion of the hashrate mining old style blocks only? The more users that use Segwit addresses, the more old-blocks miners won't be able to pick up fees from confirming the Segwit user's transactions. Segwit miners will be more profitable, but fewer Segwit transactions would be possible. Segwit miners will have more than double the blocksize to fill, so it's not as serious as it sounds, but users will also have to compete more to get their P2PKH/P2SH coins into P2WPKH and P2WSH addresses, because of the reduced amount of Segwit blocks available.

[stdset]

@stdset
You're making and invalid assumption: that miners using non-Segwit clients will reject blocks with Segwit transactions. They won't, the Segwit soft-fork was desgined in a way to prevent that happening.

I make this assumption only in the second scenario. In the first scenario this isn't the default unupgraded miner behaviour, but it can accidentally arise if unupgraded hashpower is more than 50%.

Let A be a valid segwit block accepted by both types of miners. On top of A two blocks (both of the same height) are mined: another segwit block B and a non-segwit block C. Now let's assume that half of total hashpower (including all segwit hashpower) mines on top B and another half mines on top of C, the latter group happens to be luckier and they mine another non-segwit block D. Now non-segwit fork is 1 block longer than the segwit fork and all unupgraded hashpower switches to the unupgraded fork. Upgraded hashpower however sees this fork as invalid and doesn't switch. Unless upgraded miners immediately experience an influx of luck, we have a permanent (at first sight) chain split.

[Carlton Banks]

There is no blockchain fork possible, regardless of the majority hashpower or the order in which Segwit or legacy blocks are found. Either type of block is equally valid to either type of miner, it wouldn't be a soft-fork if that were the case.

[stdset]

There is no blockchain fork possible, regardless of the majority hashpower or the order in which Segwit or legacy blocks are found. Either type of block is equally valid to either type of miner, it wouldn't be a soft-fork if that were the case.

Unless I completely misunderstand something, all upgraded nodes, including upgraded miners will be rejecting unupgraded blocks:

While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.

[tomkat]

There is no blockchain fork possible, regardless of the majority hashpower or the order in which Segwit or legacy blocks are found. Either type of block is equally valid to either type of miner, it wouldn't be a soft-fork if that were the case.

Unless I completely misunderstand something, all upgraded nodes, including upgraded miners will be rejecting unupgraded blocks:

While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.

So, can someone finally confirm what's gonna happen when bip148 activates? Is blockchain fork possible or not?

[Carlton Banks]

There is no blockchain fork possible, regardless of the majority hashpower or the order in which Segwit or legacy blocks are found. Either type of block is equally valid to either type of miner, it wouldn't be a soft-fork if that were the case.

Unless I completely misunderstand something, all upgraded nodes, including upgraded miners will be rejecting unupgraded blocks:

While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.

Hmmmm, not what I thought it was (BIP148). If that's the case, it won't work as a soft-fork, it's a Segwit hard-fork, UAHF not UASF.

Did the specification not change recently? I got a different impression from the draft I read, if this is a new change. Simply allowing Segwit-ready miners to begin mining Segwit blocks is sufficient.

[stdset]

Hmmmm, not what I thought it was (BIP148). If that's the case, it won't work as a soft-fork, it's a Segwit hard-fork, UAHF not UASF.

At first sight it seemed to me indistinguishable from a hardfork. But it isn't a hardfork. Unupgraded nodes remain compatible, they don't need to upgrade. As soon as economic majority forces miners to upgrade, unupgraded regular users have nothing to worry about.

[hv_]

Is everybody fine here with the reduced hashpower == security?

If major miners dont follow this what happens to the block time at beginning?

How safe are the first blocks after the activation?