Gold collapsing. Bitcoin UP.

[sidhujag]

cool thanks, but I thought unspent outputs would be derived from transactions which would no longer exist in the "backend" node. How does it know the unspent balance without tallying up all of the transactions it was involved in?

The way pruning works is the node still receives all transactions as before. The ones that get spent, it throws away. So the ones left are the ones it keeps in its database. Those are the unspent ones. This requires much less storage.

Makes total sense. Yea I even read that part of the code didn't clue in, duh.

[1713534078]

1713534078

[marcus_of_augustus]

cool thanks, but I thought unspent outputs would be derived from transactions which would no longer exist in the "backend" node. How does it know the unspent balance without tallying up all of the transactions it was involved in?

The way pruning works is the node still receives all transactions as before. The ones that get spent, it throws away. So the ones left are the ones it keeps in its database. Those are the unspent ones. This requires much less storage.

Makes total sense. Yea I even read that part of the code didn't clue in, duh.

The unspent transaction outputs (UTXO) is the actual distributed ledger. They are contained within the journal of all transactions seen on the network (the blockchain) which needs to be sorted through and filtered for unspent outputs.

You can tell all the "blockchain tech." was a bunch of marketing BS spouted by followers, not leaders, because the blockchain is already obsolete. UTXO is the future and where all the bleeding edge development is happening.

[cypherdoc]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

this is why spv clients will sample several different peers.

[cypherdoc]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

Ahh i see so essentialy those that dont want to sync fully can download a lite wallet which gets blocks via spv mode via a trusted node( ssl rpc).. so pruning doesnt really come into play here? If you prune then you wont be able to get your tx if trusted node pruned that block. So spv solves the blockchain sync time and pruning solves what? Being able to store on small flash disks running to relay transactions?

SPV solves being able to create and receive transactions without the bandwidth requirements of a node. Pruning solves being able to run a node that validates and relays transactions (and can even mine!) without storing the entire blockchain. They can even serve SPV clients, because they have all of the unspent transactions, and that's all SPV clients would ever want. These nodes just can't sync new nodes though (at least not by themselves) since they don't have all the old blocks to share.

actually, pruned nodes can't interact with SPV clients since they won't have the blocks. 

SPV clients use a bloom filter looking for the addresses and transactions they are interested in to the peer. The peer then only includes the relevant transactions in blocks it returns, together with their Merkle paths to prove that these transactions were indeed part of returned block.

[cypherdoc]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

Ahh i see so essentialy those that dont want to sync fully can download a lite wallet which gets blocks via spv mode via a trusted node( ssl rpc).. so pruning doesnt really come into play here? If you prune then you wont be able to get your tx if trusted node pruned that block. So spv solves the blockchain sync time and pruning solves what? Being able to store on small flash disks running to relay transactions?

SPV solves being able to create and receive transactions without the bandwidth requirements of a node. Pruning solves being able to run a node that validates and relays transactions (and can even mine!) without storing the entire blockchain. They can even serve SPV clients, because they have all of the unspent transactions, and that's all SPV clients would ever want. These nodes just can't sync new nodes though (at least not by themselves) since they don't have all the old blocks to share.

By unspent I assume you mean the ones in mempool. But how would one import their wallet key into an spv thin client backed by a pruned node and get correct balance? It needs tx that have been pruned?

i think you are mixing up these concepts.

think of 3 types of nodes:

1.  SPV clients:  only store headers, no blockchain.  has to trust other mining peers by measuring their POW.  subject to Sybil attacks.
2.  full nodes:  full blockchain with all historical tx history.  heavy data storage demands which is what primarily drives up the cost of running a full node.
3.  Pruned full node:  in between #1 & #2.  highly cost effective as it trims the blockchain down to 1.3GB.  initially downloads entire blockchain to verify tx history and build UTXO set and then deletes older blocks up to 2016 blocks back (i hear it can vary depending on a flag with the minimum being 288).  pruned nodes won't be able to serve up the blockchain to new nodes but it can validate, verify, relay and mine.  they will actually improve mining decentralization.

[cypherdoc]

cool thanks, but I thought unspent outputs would be derived from transactions which would no longer exist in the "backend" node. How does it know the unspent balance without tallying up all of the transactions it was involved in?

The way pruning works is the node still receives all transactions as before. The ones that get spent, it throws away. So the ones left are the ones it keeps in its database. Those are the unspent ones. This requires much less storage.

UTXO's have always worked this way; throwing away the spent ones.  The UTXO set is very small compared to blocks because it only contains info on unspent data and doesn't contain any signatures or data, thus, this is not what results in less storage.  it is the discarding of old blocks.  in the case of saving the last 2016 blocks (minimum 288), 351874 of them as of now.

[molecular]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

[solex]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Yes, keeping whole block ranges (randomly determined before pruning) is an important feature of pruning which will hopefully be included in due course.

[sidhujag]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Kinda like bittorrent ? This would just optimize the p2p layer of the protocol but need to
ensure its safe from attacks maybe thats why we didnt
do it to be on safe side.

[smooth]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.

[sickpig]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Kinda like bittorrent ? This would just optimize the p2p layer of the protocol but need to
ensure its safe from attacks maybe thats why we didnt
do it to be on safe side.

I think that more than Bittorrent you should look at something along the line of DHT. There's a very informative thread in the Development & Technical Discussion
section of the forum... found:  

"Using a DHT to reduce the resource requirements of full nodes" by DeathAndTaxes
https://bitcointalk.org/index.php?topic=662734.msg7470866#msg7470866

Especially look at gmaxwell reply.

Another really helpful source of info about the approach adopted in the prune implementation is
this this 2014 thread on bitcoin core dev mailing list:

"[Bitcoin-development] Service bits for pruned nodes"
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CAPg%2BsBjSe23eADMxu-1mx0Kg2LGkN%2BBSNByq0PtZcMxAMh0uTg%40mail.gmail.com/#msg30779911

[cypherdoc]

starting to roll:

[sidhujag]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Kinda like bittorrent ? This would just optimize the p2p layer of the protocol but need to
ensure its safe from attacks maybe thats why we didnt
do it to be on safe side.

I think that more than Bittorrent you should look at something along the line of DHT. There's a very informative thread in the Development & Technical Discussion
section of the forum... found:  

"Using a DHT to reduce the resource requirements of full nodes" by DeathAndTaxes
https://bitcointalk.org/index.php?topic=662734.msg7470866#msg7470866

Especially look at gmaxwell reply.

Another really helpful source of info about the approach adopted in the prune implementation is
this this 2014 thread on bitcoin core dev mailing list:

"[Bitcoin-development] Service bits for pruned nodes"
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CAPg%2BsBjSe23eADMxu-1mx0Kg2LGkN%2BBSNByq0PtZcMxAMh0uTg%40mail.gmail.com/#msg30779911

Yea gmaxwell pretty much said its not worth it for the risks you inherit. And DeathAndTaxes pretty much admitted himself that a more efficient p2p layer without DHT complexity would solve the problem in an effective manor.

[cypherdoc]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Yes, keeping whole block ranges (randomly determined before pruning) is an important feature of pruning which will hopefully be included in due course.

So what  do all these pruned nodes do with the blocks they mine going forward? Immediately delete them after they get accepted into the longest chain?

[cypherdoc]

http://a16z.com/2015/04/27/a16z-podcast-the-five-stages-of-bitcoin-disdain-dismissal-curiosity-oh-fk-and-acceptance/

[ssmc2]

http://a16z.com/2015/04/27/a16z-podcast-the-five-stages-of-bitcoin-disdain-dismissal-curiosity-oh-fk-and-acceptance/

Oh fuck indeed

[sidhujag]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.

Isn't the pruning approach Satoshi alluded to in his whitepaper #7 (https://bitcoin.org/bitcoin.pdf) the better approach? The hash of the block remains so full verification is still possible after pruning.. blocks are still around just the spent tx's are gone... so you can reindex to get them again if you wish.

In the current commit the blocks are pruned themselves.. which deletes the merkle tree. Satoshi's approach was more of a compacting of the block by pruning transactions instead of pruning blocks altogether.

hmm, I guess if all nodes ended up pruning the spent tx's there could be a point where a new node syncing would not be able to replay the chain and verify it properly? Even though the hash of the block is preserved , the spent transactions wouldn't be foudn anywhere to download them, so all you would have left is the UTXO, no more historical ledger for accounting purposes.

[smooth]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.

Isn't the pruning approach Satoshi alluded to in his whitepaper #7 (https://bitcoin.org/bitcoin.pdf) the better approach? The hash of the block remains so full verification is still possible after pruning.. blocks are still around just the spent tx's are gone... so you can reindex to get them again if you wish.

No, unless you can verify the flow of transactions yourself you are ultimately trusting the miners. They put the transaction in the block; the hash proves that. But how do you know they were not cheating when they did? Also, you don't know that they didn't prune something they shouldn't. Maybe you got a payment, and the miner doesn't want you to see it (or the government told him to remove it), so they prune it (retaining only the hash, but the block is still valid).

Satoshi's pruning is basically the same in terms of trust as SPV.

[sidhujag]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.

Isn't the pruning approach Satoshi alluded to in his whitepaper #7 (https://bitcoin.org/bitcoin.pdf) the better approach? The hash of the block remains so full verification is still possible after pruning.. blocks are still around just the spent tx's are gone... so you can reindex to get them again if you wish.

No, unless you can verify the flow of transactions yourself you are ultimately trusting the miners. They put the transaction in the block; the hash proves that. But how do you know they were not cheating when they did? Also, you don't know that they didn't prune something they shouldn't. Maybe you got a payment, and the miner doesn't want you to see it (or the government told him to remove it), so they prune it (retaining only the hash, but the block is still valid).

Satoshi's pruning is basically the same in terms of trust as SPV.

In the back of my mind im still intertwining the concepts of bandwidth/time required for sync versus storage requirements of the blockchain. The bandwidth/time was solved by SPV and perhaps ultimately for desktop users be useful to have a lite wallet download which would be in SPV node and have a default trust of a bitcoin foundation node or something configurable OOTB.. so avg joe can simply click on it and run, but with the fine line that its only for new users who don't already have a wallet.

The storage which isn't really that big of a problem but solves being able to store on smaller flash disks is now solved by the pruning of old blocks of spent outputs.

Correct?

[smooth]

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.

Isn't the pruning approach Satoshi alluded to in his whitepaper #7 (https://bitcoin.org/bitcoin.pdf) the better approach? The hash of the block remains so full verification is still possible after pruning.. blocks are still around just the spent tx's are gone... so you can reindex to get them again if you wish.

No, unless you can verify the flow of transactions yourself you are ultimately trusting the miners. They put the transaction in the block; the hash proves that. But how do you know they were not cheating when they did? Also, you don't know that they didn't prune something they shouldn't. Maybe you got a payment, and the miner doesn't want you to see it (or the government told him to remove it), so they prune it (retaining only the hash, but the block is still valid).

Satoshi's pruning is basically the same in terms of trust as SPV.

In the back of my mind im still intertwining the concepts of bandwidth/time required for sync versus storage requirements of the blockchain. The bandwidth/time was solved by SPV and perhaps ultimately for desktop users be useful to have a lite wallet download which would be in SPV node and have a default trust of a bitcoin foundation node or something configurable OOTB.. so avg joe can simply click on it and run, but with the fine line that its only for new users who don't already have a wallet.

The storage which isn't really that big of a problem but solves being able to store on smaller flash disks is now solved by the pruning of old blocks of spent outputs.

Correct?

The current pruning scheme that is implemented compromises nothing in terms of trust. You receive the entire blockchain and verify it completely, but you only keep some N recent blocks (or maybe specified amount of storage? i'm not sure). It uses the same bandwidth as before, but less storage.

This doesn't really address where those old blocks will be stored, so that is being worked on as discussed in the last several posts.

If you want to reduce bandwidth you are going to end up with various weaker models in terms of trust because since you aren't receiving the entire chain, you obviously can't verify everything yourself. You end up needing to trust somebody somehow.

SPV is fine for end users, and it has pretty much the minimum possible bandwidth usage. It does have some privacy compromises because you have to tell the nodes which addresses you are interested in (or at least a superset of that).

Satoshi's pruning is ultimately similar to SPV in terms of trust (you are trusting the miners) but has intermediate bandwidth usage (less than full trustless verification and more than SPV) and unlike SPV does allow mining.