br-m: Okay, good to know. I'm wondering if a feature could be added to create like a new torrent each month that is created from a checkpoint in the blockchain file? That way a new node just downloads the torrent plus the changes over the last month.

<preland> Ryushin: That….isn’t the worst idea

<preland> To make sure that the torrent is a correct history though, the hash of it would need to be carried and transmitted by the nodes that are already synced up

br-m: That is what I was thinking. It would be like an official torrent that only the pre-existing complete nodes would have. It would save a lot of wear and tear on storage devices.

<hbs:matrix.org> Anyone knows what he is mentioning about Monero? xcancel.com/zachxbt/status/1980612190609576229?s=46

Ryushin: usually syncing from scratch nowadays is faster than importing a blockchain dump

they use different processes afaik

<321bob321> @hbs:matrix.org: UI/UX complaints apparently

<hbs:matrix.org> @321bob321: Yes but in what context or tool? Doesn't seem clear.

<321bob321> Wallet ?

<torir:matrix.org> Zashi is a mobile wallet, so I assume ZachXBT is referring to UX issues with a mobile Monero wallet.

privacy as a service

DataHoarder: The actualy process of syncing is very IO intensive with an incredible amount of write amplification. The blockchain is currently 276GB. But in the process of syncing it will write several terabytes. I originally put the blockchain on a ZFS dataset on 30 drive HDD pool, then to a 6 drive SSD pool, and once I realized I was dealing with a huge mount of write amplification due to 15 minutes snapshots growing at an astounding rate,

I stuck it on a RAM drive and let it finish. After it was done I moved it back to the 30 drive HDD pool.

My main idea was creating monthly checkpoints of the block chain that acts as a bootstrap for new nodes, every from the beginning of the blockchain to the checkpoint is transferred like a bittorrent, then once the torrent piece is transferred, it does a catch up sync for up to a month of data. The only heavy IO is done just for that last catch up.

You mean db dumps and not raw exports

Raw esports get checked db dumps not really

So you switch verifying blocks with trusting torrent maker, unless the structure of it can be deterministic ally made, then at least just need to trust the people who made these dumps and verified the result

Raw exports*

Well the nodes also act as a torrent. Sharing the beginning of the block chain to the monthly checkpoint, then that giant chunk is bootstrapped as a torrent, then a final sync once it completes downloading.

Yay! I mined my first XMR this morning.

Ryushin: and how do people know if this data is legit?

The nodes could be colluding to tell you it's legit

Perhaps the official Monero site can have a SHA2 for the checkpoint, if it matches then it can continue. The official torrent bootstrap ile can come from the Monero site as well that the official wallet client uses.

I'm just trying to think of a way to bootstrap the file while having a distributed transfer.

so then you are indeed trusting the downloads are legit

Ryushin: having a boostrap'd file that gets imported more or less works, though a light version would be to verify the block headers, then assume txs are legit, which is the expensive part, then check this vs network

but the clients could end up isolated on their own little island

however, that's sort of the embedded checkpoints for releases

so dumps up to that height+id could be done fine (as we are trusting at-depth checkpoints in monero releases match reality)

Yea, we are trusting the downloads are legit, but we are verifying the bootstrap is correct by verifying the sha2 from the official site, then it can sync the changes since the last checkpoint.

Then this only works this way when using the official client that has been verified with the correct hash. This should also solve the problem with those that want to use a hdd instead of an ssd.

except I see those using HDD not keeping up on p2pool so they can't mine properly :)

Wrote a little script to monitor a linux system and adjust XMRIG's CPU percentage amount to keep it between a threshold: pastebin.com/upKvhHxn

I put it into a cron job to run every two minutes. It runs on server that does other things so I wanted a script to adjust the CPU as needed.