<j​ohnfoss68:matrix.org> themoneromoon.com/p/the-monero-moon-issue-65

Hello, I required some help

I want to export my pruned monero db to my server, but you cant use blockchain=prune

i sent the .mdb file, and i presume its configured for my computer and not the server, so it cant be imported

```

2024-05-01 04:54:55.862    I Loading blockchain from folder /home/retkid/.bitmonero/lmdb ...

2024-05-01 04:54:55.862    D option: fast

2024-05-01 04:54:55.862    D option: async

2024-05-01 04:54:55.862    D option: 250000000bytes

2024-05-01 04:54:55.862    T BlockchainLMDB::open

2024-05-01 04:54:55.863    T BlockchainLMDB::need_resize

2024-05-01 04:54:55.863    D DB map size:     87732275200

2024-05-01 04:54:55.863    D Space used:      76084457472

2024-05-01 04:54:55.863    D Space remaining: 11647817728

2024-05-01 04:54:55.863    D Size threshold:  0

2024-05-01 04:54:55.863    D Percent used: 86.7235  Percent threshold: 90.0000

2024-05-01 04:54:55.863    D Setting m_height to: 3137649

2024-05-01 04:54:55.864    T mdb_txn_safe: destructor

2024-05-01 04:54:55.864    T Blockchain::init

2024-05-01 04:54:55.864    T BlockchainLMDB::height

2024-05-01 04:54:55.864    T BlockchainLMDB::block_rtxn_start

2024-05-01 04:54:55.864    T mdb_txn_safe: destructor

albassort: Normally the data.mdb file is compatible across different operating systems

dEBRUYNE i assume rsync is corrupting across the 70 gb. I am now syncing it with syncthing

Did you leave the Monero software running? That may have caused a corruption

No, I don't think so.

I tried 2 separate times with full transfers

syncthing was probably the right tool for it, anyway

<3​21bob321:monero.social> is the db getting witten too?

.xmr

norman: You must have bot account & be logged in

whats up?

<n​orvegan:nope.chat> #shum

<m​onero_fan:matrix.org> Hi there, can you PM me how to start using it ?

<5​m5z3q888q5prxkg:chat.lightnovel-dungeon.de> good, well deserved for using BTC

<p​cre:monero.social> A little tip for all Linux users who mine Monero on their work PC and don't want to be disturbed by the mining process. Use »nice -n 19 ./xmrig«. This sets xmrig to the lowest priority in the process scheduler. The higher the number, the nicer the process: -20 = not nice to 19 very nice. See also »man nice«.

<r​avfx:xmr.mx> Can also use less nice but tell xmrig to not use all cores

<p​cre:monero.social> ^⁻ This could also be useful to prevent the CPU from overheating.

<p​cre:monero.social> You don't necessarily have the best coolers on a normal PC.

<p​cre:monero.social> xmrig --cpu-priority=N does not work als good. I wonder why?

<p​cre:monero.social> I often switched off xmrig because it just got on my nerves when I wanted to do something on the PC. Compiling something etc. That is now history.

<p​cre:monero.social> It now behaves like a submissive slave in the background.

<e​dge7:matrix.org> This is the real way.

<r​avfx:xmr.mx> I find it more responsive that way, when you use the computer in the same time

<p​cre:monero.social> Why not both at the same time? Fewer cores and a high nice value?

<t​igerix:matrix.org> kayabanerve: I just listened to your Twitter Space! Great Insides!

<t​igerix:matrix.org> I got a very happy takeaway. Am I right with this?

<t​igerix:matrix.org> The 10 block lock time wouldn't be an issue anymore, because a wallet can easily create pocket change, so you can make multiple spends without waiting time!

<t​igerix:matrix.org> And the locktime isn't an issue for merchants who are willing to take the risk of unconfirmed transactions, which means Monero can offer an instant transaction user experience just like Bitcoin Cash.

<e​rembax:matrix.org> Is there a rule that decoy inputs are never selected if they spawn from the same transaction?

<r​ucknium:monero.social> erembax: No, there is no rule like that. I assume you cannot see this message soon since you are on the matrix.org home server.

rucknium: Speaking of not seeing messages, I have given up on element. FYI if you are including node count in any of your work I would not rely on the number shown at monero.fail/map

<r​ucknium:monero.social> Do you think it is too high? I do, too. But if we include it in the cost effectiveness measure, then we are just overestimating the node storage costs. My analysis so far already says that increasing the ring size (which increases storage costs) is more cost effective than increasing the fee/byte.

Many of the shown nodes are 'last seen 8 months ago.' I believe their records are not correct, or not updating.

The other tool I am aware of that shows this is tools.rino.io/network/

which shows something like 1.5-2k nodes.

<r​ucknium:monero.social> My memory is a little fuzzy, but IIRC that map does not actively crawl the network.

<r​ucknium:monero.social> I could try to run github.com/endorxmr/monero-node-p2p-scanner to get a firsthand count. AFAIK that code <--- is similar to what monero.fail uses.

I am not sure if rino is correct, but the numbers do change on a daily basis. I think monero.fail has been stuck at 22537 for quite some time.

<r​ucknium:monero.social> Rino's is probably just a list of known peers from...that command that gets the list of peers

<3​21bob321:monero.social> This is why there needs a health check endpoint -.-

<k​ayabanerve:matrix.org> Pocket change isn't a complete non-issue (output quantity technically still is a fingerprint) yet it wouldn't be the issue it is today. The question is no longer about fingerprints within a graph subset yet rather the entire chain, and you can't trace intermediary TXs (between pocket changes).

<k​ayabanerve:matrix.org> I would not say that makes the 10-block lock a non-issue nor claim Monero instant nor claim BCH instant Tigerix:

hello so, I did a manual transfer in parts and the checksum is identical to the version that works on my pc

context: im trying to send the .mdb from my pc to my server for a node

i cant export it due to it being pruned

with this error:

2024-05-01 23:08:49.283    E Failed to parse block from blob