How will 2Mb affect the UTXO pool?

[Jet Cash]

I read somewhere that 2Mb blocks would increase the size of the UTXO pool. To me, this seems to be the opposite of the obvious result. The other comment was that full nodes would need to allocate more memory to running the core, and that this would lead to a reduction in the number of nodes. At the moment, running core doesn't seem to use many resources on this computer, how will this change in the future? I'm not interested in hard drive storage, I'm interested in cpu and system memory ( and maybe page swops).

[Cconvert2G36]

I read somewhere that 2Mb blocks would increase the size of the UTXO pool. To me, this seems to be the opposite of the obvious result. The other comment was that full nodes would need to allocate more memory to running the core, and that this would lead to a reduction in the number of nodes. At the moment, running core doesn't seem to use many resources on this computer, how will this change in the future? I'm not interested in hard drive storage, I'm interested in cpu and system memory ( and maybe page swops).

According to technical experts... disk space is the biggest concern:

[franky1]

in short, if a Raspberry Pi can handle bitcoin. then a laptop from 2005 can handle 2mb+segwit bitcoin because laptops of a decade ago were twice as powerful in every way as a Pi.

infact more recently, if we stop living in the past and live in the current. standard laptops and desktops are even more powerful again.

[Jet Cash]

Won't 2Mb blocks increase the hard disk space requirement. This is because of the probable lower transaction density within blocks. There will also be an increase in buffer size to cope with larger blocks. However, improvements in computer hardware should negate this. I believe that improvements in Core 0.12 will improve the use of cpu and memory, but this is aside from the 2Mb issue, but is a case for sticking with the core development team.

My question was really about the UTXO and the memory pools though.

[Jet Cash]

in short, if a Raspberry Pi can handle bitcoin. then a laptop from 2005 can handle 2mb+segwit bitcoin because laptops of a decade ago were twice as powerful in every way as a Pi.

infact more recently, if we stop living in the past and live in the current. standard laptops and desktops are even more powerful again.

Isn't that the proposed path for core development? I thought all the current stress resulted from the demands for an immediate 2Mb blocksize with no other improvements.

[Cconvert2G36]

in short, if a Raspberry Pi can handle bitcoin. then a laptop from 2005 can handle 2mb+segwit bitcoin because laptops of a decade ago were twice as powerful in every way as a Pi.

infact more recently, if we stop living in the past and live in the current. standard laptops and desktops are even more powerful again.

Isn't that the proposed path for core development? I thought all the current stress resulted from the demands for an immediate 2Mb blocksize with no other improvements.

Path proposed over 5 years ago... pls... 2MB would be a joke to handle.

It can be phased in, like:

if (blocknumber > 115000)
    maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

limit sigops to the max in 1MB blocks... this dispute is about more than that. It's about steering fees for a generation.