Why is the last percent of the chain synchronized in time as much as the entire previous chain

It's really weird

llacqie[m]: checkpoints

the last percentage usually doesn't contain any checkpoints which means it takes longer to sync as it has to do more work

selsta: That is, when synchronizing the first 99 percent, not every block was checked, and when synchronizing the last one, each one is checked and therefore slow?

all blocks were checked but PoW verification was skipped as we has known hashes hardcoded

have*

Okay so when choosing to prune the blockchain for init or going with full node... is this correct in thinking the pruned chain might remove block data that is not relevant to ones specific wallet? Id like to swap random wallets in and out so if so, a full unpruned node sounds better. Or I dont understand what monerod is pruning exactly...

No, your wallets don't play any role. You will be able to continue to use any wallets with a pruned blockchain, and create any new ones.

I think for understanding what *exactly* gets thrown away, or better not stored, you would know quite some "crypto", but it does not hinder the functioning of wallets, of that I am sure

Thank you rbunner. I read some web page claiming this, which is why I was concerned. Logically it made sense, as it would seem you need a complete list of TXs from genesis block to know who has which coins

Well, a pruned blockchain still contains *all* transactions, with all outputs, but about most of them not all data anymore, just the "basics" so to say, including destinations and amounts

There is full data for 1/8th of the transactions, but the size of the blockchain file is not 1/8th of the full blockchain, but more like 1/3rd, because of this

er, the size of the *pruned* blockchain file is not 1/8th

rbunner: why keep full data for 1/8th anyway?

also, is this true of other coins that offer pruning, like BTC and LTC?

You keep 1/8th of the data so that even if all users of the network were to run exclusively pruned nodes one day, there would still be a very high chance that no chain data is ever lost

Otherwise, the entire network would be 100% reliant on people running full nodes, because iirc you cannot fully verify the validity of the chain based on pruned data alone

(Iirc you can verify block templates, but not the pruned transactions, because you don't have enough data to calculate the full tx hash)

Transparent chains like BTC and LTC on the other hand, where you can clearly see the outputs spent in each tx, allow you to go as far as running SPV nodes - which verify the chain during the initial sync, but only store info related to unspent tx outputs only, and nothing else

So they're much lighter to run, but have no way to verify any past chain history, or look at the transaction history of an address

Can't do that with Monero, because you never fully know for sure if an output has been spent or not

endor00: thanks! but I think when you first sync a pruned Monero node, you also have to download entire chain, right? What you wrote made it sound like this is only applicable for transparent chains...

Also I am confused how this even works if what you say is true, that «you cannot verify validity of the chain based on pruned data» … I mean this goes back to my original confusion how I can swap random wallet private keys from different times/sources and a pruned chain/node can figure out how many coins that key/wallet is able to spend...

Pruned data includes things such as rings, I was under the impression that a pruned node contains the full tx history

underpantsgnome[, you do download the entire chain.

Everyone goes through the entire chain during the sync, even SPV nodes for trasparent chains. What changes is the data they keep after the initial verification. Pruned nodes in Monero verify all the blocks in full, but they only save to disk 1/8 of the full tx data; that means that if/when a second node will try to do the initial sync by connecting to you, you will only be able to provide them with the full data for only 1/8 of the chain, and they'll have

to find the missing full 7/8 from someone else

Because everything else was discarded after the initial verification

<ofrnxmr[m]> "Pruned data includes things such..." <- Iirc they discard some of the ring signature data, which is actually the bulk of the tx

And therefore you cannot compute the tx hash after you discarded it

(But I could be wrong)

Pruned nodes can still calculate TX hashes.