Quote from: achow101 on Today at 05:20:55 PM

Didn't read the article, but from the snippet you've posted, it's simply incorrect.

Assumeutxo is neither a new type of node, nor a pruning. It's about making the software usable without having to wait multiple days for it to sync. It doesn't reduce the hardware requirements to run, in fact, using assumeutxo probably requires more resources than without it.

Assumeutxo allows a node to start with a preset UTXO set (provided by the user, and does not necessarily correspond to a hardcoded hash in the binary, this detail has not been worked out yet). This UTXO set is the state of the chain at a particular block hash and height. The node can then begin syncing from that particular block. The idea is that the block will be recent, so the node will be caught up to tip very quickly, thus allowing the user to make and receive transactions way faster than if they had to wait for the entire blockchain to sync.

The point is to make the software usable much faster. A major complaint that we've heard from users is that it takes ages to sync. Users often don't have the patience to wait and will start giving out addresses. Then they panic when they don't see incoming coins because they haven't synced yet and they come into this forum, or github, or reddit freaking out about losing money, all just because they haven't waited for the node to sync. Assumeutxo reduces that because it "syncs" faster.

Obviously there's a trust requirement in this - users have to trust that the UTXO set that they are using is correct. Assumeutxo mitigates this by actually syncing the full blockchain in the background. While the user is using the state provided by the UTXO set and the chain state extended from it, a second chain state is built in the background from syncing and validating the blockchain. Once that background validation reaches the preset UTXO set's height, it checks that the two states are the same (same UTXOs, same blocks), and will kill the software and give the user an error if they are not.

This is, in fact, not pruning, and unrelated to pruning. Of course, it should be possible to do it with pruning, but I don't know if that's been implemented yet. Furthermore, two chain states are being maintained in memory and on disk while the background validation is going. This means that the resource usage is actually higher, not lower.

Agree 100%.
I have got to start pre-writing a lot of this stuff before posting and making an ass of myself because I left out a bunch.
Anyway...

What I wanted to start with, is although good in theory (still using the pruned node term. Is why do we want to have people use their nodes sooner. This is where the 3 step process I put in my post was about.

Which was then supposed to comment on how people will start it with HW that can't handle it but it will work till it does not (extra memory and RAM) and will cause issues.

What you can't read my mind about what I was thinking about posting. Tablet while remote accessing a PC to post here makes dave look dumb.

Even now you can install and try to donload the blockchain on too small a drive, it has the pruned check box on by default but does not even mention what may happen if you un-check it.

YES you can still do that now by installing on a 512 GB drive and running out of space, this just seems to encourage it. Once again IMO.

If I go to an amusement park signs are posted that you must be this tall to get on some rides. Other software will not let you install on some systems that cannot support it.

Core, says nah go ahead and put it on a 1st gen i3 with 2GB RAM and a 128 GB drive.
This causes people grief, we have seen it here and on reddit and other places. Is it that hard to say NO don't do this?

-Dave