<5​m5z3q888q5prxkg:chat.lightnovel-dungeon.de> exch.cx

<5​m5z3q888q5prxkg:chat.lightnovel-dungeon.de> Does anyone have an experience with this?

25$ for HDD vs 35$ for ssd.......

<o​frnxmr:monero.social> Sure

<o​frnxmr:monero.social> They often dont have xmr

<o​frnxmr:monero.social> otherwise, good

<5​m5z3q888q5prxkg:chat.lightnovel-dungeon.de> interesting

<5​m5z3q888q5prxkg:chat.lightnovel-dungeon.de> why the lack of XMR?

<o​frnxmr:monero.social> they allow you to create trade before it confirms

<t​rasherdk:monero.social> XMR is rather low on this 😢

<t​rasherdk:monero.social> matrix.monero.social/_matrix/media/…ero.social/dhcYGFlcTXEiNhCkHBGcgXvX

<t​rasherdk:monero.social> Low interests, I mean.

<t​rasherdk:monero.social> Last trade was 2 Nov.

<o​frnxmr:monero.social> So.. moneroocean

<o​frnxmr:monero.social> To mine a specific coin, you enter the algo in to password field after worker name, such as `worker1~rx/0`

<o​frnxmr:monero.social> Moneroocean has 2 rx/0 coins.

<o​frnxmr:monero.social> zephry and xmr.

<o​frnxmr:monero.social> so.. it seems theres no way to mine xmr directly, moneroocean is redirecting all rx0 has to zephyr

<o​frnxmr:monero.social> Hash*

<o​frnxmr:monero.social> So if yur mining rx/0 on moneroocean.. you might have started mining zephyr without realizing.

<o​frnxmr:monero.social> it says there is only 1 person mining xmr on MO

Some problems at accept: Too many open files, connections_count = 997

ugh

user@serveruser:~/.bitmonero$ ulimit -n

1000000

ugh ugh

<o​frnxmr:monero.social> All limits set with the ulimit command will apply to the current Bash shell only. To make a permanent change to system wide use, you must make changes to the /etc/security/limits.conf file.

<t​rasherdk:monero.social> Fuck me! The latest trend in KYC madness:

<t​rasherdk:monero.social> ```

<t​rasherdk:monero.social> Kittipat

<t​rasherdk:monero.social> Hello. Welcome to Orbix Trade. How can I help you?

<t​rasherdk:monero.social> With the 2FA access.

<t​rasherdk:monero.social> Kittipat

<t​rasherdk:monero.social> May I ask what problems you are encountering, sir?

<t​rasherdk:monero.social> avatar

<t​rasherdk:monero.social> I have gone through KYC with Satang in 2020, so I don't really feel like doing it again.

<t​rasherdk:monero.social> I don't have the phone with the OTP keys anymore.

<t​rasherdk:monero.social> Kittipat

<t​rasherdk:monero.social> Sorry for the inconvenience. Have you ever met us at our office, sir?

<t​rasherdk:monero.social> avatar

<t​rasherdk:monero.social> No, why would I go to your office? I'm currently in Pakchong.

<t​rasherdk:monero.social> Kittipat

<t​rasherdk:monero.social> In order to complete the KYC, Kyc includes important part which is face-to-face meeting for verification.

<t​rasherdk:monero.social> Face to face. That's a new one. Does all your customers travel to meet you in person?

<t​rasherdk:monero.social> Kittipat

are they buying you lunch?

<o​frnxmr:monero.social> Lmfao

<o​frnxmr:monero.social> This is satire.. right

<o​frnxmr:monero.social> Trasher must be kittipat. right??

<t​rasherdk:monero.social> Nope. SatangPro exchange have changed hands, and the new crew are going full stazi.

<t​rasherdk:monero.social> orbixtrade dot com is the new bitch in town.

<o​frnxmr:monero.social> Id ask them who im to meet with

<o​frnxmr:monero.social> and if i can bring my entourage

<o​frnxmr:monero.social> Also, if they are hiring

<o​frnxmr:monero.social> "please sir, dont come here"

<t​rasherdk:monero.social> I saw an arbitrage opportunity and wanted to swing by.

<t​rasherdk:monero.social> The last XMR/THB trade was over a month ago, so not much action.

<o​frnxmr:monero.social> "oh baby, you cant stop me now. Already bough 40 plane tickets we'll be there saturday at 3am"

<o​frnxmr:monero.social> "you guys have loudspeakers?"

<r​ucknium:monero.social> "Arbitrage opportunities" usually have a catch. You found it :P

<o​frnxmr:monero.social> haha

<t​rasherdk:monero.social> I was thinking about asking about reimbursement of travel expenses 🤣

<o​frnxmr:monero.social> Id offer them free tickets to ethprague

<o​frnxmr:monero.social> Did you google maps to see if the place exists?

<o​frnxmr:monero.social> If it doesnt, id call and tell them im outside

<t​rasherdk:monero.social> Well, I used to live close by, so I know the area. It's real.

<t​rasherdk:monero.social> Damn, I just got an email asking `How would you rate the support you received?` that's beyond parody.

<o​frnxmr:monero.social> well, then i dont know why theyre inviting you

<o​frnxmr:monero.social> is their motto "i dont want peace. I want problems ALWAYS!"

<o​frnxmr:monero.social> Personally, id never invite trasher to my workplace. 😆 (im jk)

<s​gp:magicgrants.org> **Voter applications and committee candidate announcements are now available for the MAGIC Monero Fund committee.**

<s​gp:magicgrants.org> With the Monero CCS incident, now is a very important time to focus on the MAGIC Monero Fund.

<s​gp:magicgrants.org> If you are keeping up-to-date with the Monero ecosystem, please apply to be a voter, and if you have the time, please consider running to the committee member positions.

<s​gp:magicgrants.org> **Apply**: magicgrants.org/Monero-Fund-2024-Election

<s​gp:magicgrants.org> **Tax-deductible donation**: monerofund.org

<v​ikrants:monero.social> Hi All! Just a reminder to all wallet makers, our polyseed implemention is opensource. Here it is if you want to put Polyseed in your wallet app. github.com/cake-tech/polyseed_dart

<e​dge7:matrix.org> Hi. I see that cake wallet mobile wallet allow to create wallet using 16 words (polyseed), listing as legacy the traditional 25 words.

<e​dge7:matrix.org> Is 16 words then usable in other wallets? Especially the official UI

<e​dge7:matrix.org> ?

<o​frnxmr:monero.social> You cannot use 16 in GUI or CLI

<o​frnxmr:monero.social> But you can convert 16 to 25, and use in cli/gui

<o​frnxmr:monero.social> Feather, anonero, cake/monerocom support 16 (polyseed)

<o​frnxmr:monero.social> mysu is almost ready, and i imagine stack not far behind

helloooo

is there a way to partition my two ssd's of 256 gb, instead of having one with 512 gb for having the full node?

slave_blocker: yeah you can do that with lvm and combine them to be a whole logical partition

<o​frnxmr:monero.social> You do mean, join 2x256gb ssds, right?

yes

yeah like doing raid0 on them

what are the bash commands?

slave_blocker: it goes something like this askubuntu.com/questions/7002/how-to…hard-drives-as-one-volume/7841#7841

<o​frnxmr:monero.social> You can also use an ssd as a ramdisk + hdd for storage

<g​fdshygti53:monero.social> SSD as write cache for the HDD

<g​fdshygti53:monero.social> lern LVM2

<o​frnxmr:monero.social> Do you still have your guide up?

<g​fdshygti53:monero.social> Nop, the host was shitting so I let it expire, I have to get another vps for it.

<g​fdshygti53:monero.social> will return online asap (with update)

im just asking because my 256 ssd is going to run out

<o​frnxmr:monero.social> Ok tyty

so an easy way todo that for each monerian would be nicu

<g​fdshygti53:monero.social> I was thinking about making script for my guide update

<g​fdshygti53:monero.social> so one could run the script, type the /dev/whatever he want to use for storage and cache, and have the script setup the LVM stuff

<g​fdshygti53:monero.social> (and when most linux boot, the LVM stuff is automatically detected and started so once you did set it up, it stay set)

furthermore the other day i was discussing this

<g​fdshygti53:monero.social> access.redhat.com/documentation/en-…-improve-logical-volume-performance

so the coupon collectors problem is isomorphic to the problem of a node syncing up partitions of a chain

say instead of two ssd's i have 500 ssd's

<g​fdshygti53:monero.social> That's for the write cache, I assume you can find the rest of how to setup LVM easily.

<g​fdshygti53:monero.social> I try to get the guide back online in less than a week

<g​fdshygti53:monero.social> You just need as much HDD as you want and a chunk of a SSD (32GB would be way enough)

and i could choose some subset of thouse 500 ssd's

hum

no typing without thinking not such a good idea

:)

but the argument is that spacial scaling is not an issue

ah yes

because maximally one could have 500 ssd's

for a full node

but then there are some that only have 10 ssd's

and it grows n log n

!

<g​fdshygti53:monero.social> 1 - add all disk (hdd and ssd chunk partition to LVM PV

<g​fdshygti53:monero.social> 2 - add all HDD PV to a VG

<g​fdshygti53:monero.social> 3 - create LV with whole size

<g​fdshygti53:monero.social> 4 - add the SSD chunk PV to the hdd VG

<g​fdshygti53:monero.social> 5 - set writecache the same size of that extra SSD chunk

<g​fdshygti53:monero.social> then you should be set

<g​fdshygti53:monero.social> Generic googling how to use LVM plus the link for write cache should set you up.

<g​fdshygti53:monero.social> Writecache is very important, you want to keep the lasts blocks of the blockchain in the SSD cache, you don't want normal cache as other older block that get read will contaminate the caceh

<g​fdshygti53:monero.social> s/caceh/cache/g

<g​fdshygti53:monero.social> If setup properly, you sync the whole thing in less than 10 hours or something

and the most current ssd is the most crucial and should be called the slave ssd

:)

so we all agree that ssd scaling is no problemo and everybody is happy?

i saw yesterday that roughly half a mb is being stored per btc blocktime in xmr

<g​fdshygti53:monero.social> Yep, you really don't need more than 32GB worth of SSD and that should be enough until we get to seraphis

<g​fdshygti53:monero.social> get 2-3 x 8GB HDD plus a corner of a SSD and it should be enough until you expire

<g​fdshygti53:monero.social> get 2-3 x 8TB HDD... lol, not GB

hum

<g​fdshygti53:monero.social> zerohedge.com/crypto/irs-team-reports-rise-crypto-tax-investigations

<g​fdshygti53:monero.social> Bring it 😂 The more the better.... for the Nero!

i mean

for 50 k tx /sec

global adoption stuff

worst case scenario

sleep well and stuff

<g​fdshygti53:monero.social> Should not be a problem even for hdd

<g​fdshygti53:monero.social> as you write new block sequencially

<g​fdshygti53:monero.social> Most used decoys are recent one, hence 32GB worth of SSD buffer should be enough

<g​fdshygti53:monero.social> But for 50k tx/sec to verify, I would really recommand 32GB worth of NVME write cache. Not Sata SSD...

<g​fdshygti53:monero.social> And quality NVME (with DRAM)

<g​fdshygti53:monero.social> If 32GB become insufficient before we get to Seraphis, then with LVM, you can "grow" the size of the cache as needed

<g​fdshygti53:monero.social> I did all my test with 16GB worth of NVMe

<g​fdshygti53:monero.social> And for the HDD, I did use a single SMR piece of cr*p

<g​fdshygti53:monero.social> 16GB is enough until you get to 98% sync or something like that lol so I recommend 32

16GB is enough until you get to 98% sync or something like that lol so I recommend 32 ?

<g​fdshygti53:monero.social> with 16GB worth of NVMe cache you are going to get an exponential amount of "cache miss" once you get to ~98% of the blockchain synced

what does that mean?

cache?

what cache?

<g​fdshygti53:monero.social> write cache, it's what you use to cache the 16GB or 32GB worth of recent blockchain.

<g​fdshygti53:monero.social> Did you even follow what I was talking about since the beginning?

<g​fdshygti53:monero.social> ie: instead of getting ton of SSD, you just buy massive amount of HDD TB and use SSD/NVMe write cache to cache the most recent part of the blockchain

hum

that sounds good

but not everyone will be able to buy all that stuff

there is no demand for huge date storage for retail

<g​fdshygti53:monero.social> It's a lot cheaper than SSD/Nvme storage

<g​fdshygti53:monero.social> you can get 8TB worth of HDD for the price of 2TB worth of NVME

a 100 tb ssd is still 40k €

<g​fdshygti53:monero.social> Yeah, seriously, just use HDD with LVM write cache.

<g​fdshygti53:monero.social> Cheapest solution to run the thing.

<g​fdshygti53:monero.social> I will put my guide online soon

<g​fdshygti53:monero.social> And I think that HDD with SSD write cache trick won't be needed anymore if we go to full membership proof... right?

write cache, it's what you use to cache the 16GB or 32GB worth of recent blockchain.

that sounds interesting

<1​23bob123:matrix.org> Explains why when i added l2 arc sync speed got quicker.

i was trying to convert my cousin dr in maths this weekend i wanted to give him some xmr

and he said:

what if everyone uses that

it wont work

hehe

<g​fdshygti53:monero.social> Yes, if you use "normal cache" then each time you read a block that is farter than 32GB then that block will be written in the cache, contaminating it and increasing the number of ssd write exponentially. Hence you need Write cache

great talk

:)

<g​fdshygti53:monero.social> l2 arc?

<g​fdshygti53:monero.social> Isen't Arc some compression algo we did use back in the good old DOS time?

<1​23bob123:matrix.org> Zfs L2arc

<g​fdshygti53:monero.social> oh, that probably help too, I mean, if data is compressed then it take less space on the drive.

<g​fdshygti53:monero.social> I do stay away from ZFS personally.

<1​23bob123:matrix.org> I have an lxc running monerod on proxmox

<1​23bob123:matrix.org> Yeah freebsd bug

<1​23bob123:matrix.org> 🚀

<g​fdshygti53:monero.social> I really prefer the layer way of doing thing

<g​fdshygti53:monero.social> Raid layer, lvm layer, etc, etc

<g​fdshygti53:monero.social> And I add drives regularly in my array, with is not possible in ZFS right? axcept if you add always sizeof(pool)

<g​fdshygti53:monero.social> with LVM I can add drivers, remove drive, relocate drive (without unmounting the volumes)...

<1​23bob123:matrix.org> They had an upgrade

<1​23bob123:matrix.org> Csnt remember what it was

<1​23bob123:matrix.org> Cant*

<g​fdshygti53:monero.social> Silent error protection is not even an argument as I have HDD for adults (they have 528 bits sectors instead of 512bits sectors... Each sector have a checksum of itself, right on the drive)

holy shit never heard of that

!

<g​fdshygti53:monero.social> But the main raison I stay away from ZFS, is... it's does not come with kernel.. If I play with out of tree FS, I play with Reiser5

and what about ssd's or stuff that you can or can not have data on it like hidden data

<g​fdshygti53:monero.social> SAS drive for adult, you need also a proper SAS controller for adult too, that support that special sector geometry

<g​fdshygti53:monero.social> my SAS controller is like 10 years old 😂

wtf are you talking about

:)

<g​fdshygti53:monero.social> 528 bits sectors. You need a controller that support that, the OS itself don't know about that

<g​fdshygti53:monero.social> and if you don't have a controller for adult (not consumer shiet) then it will just use the drivers as like they have 512bits sectors

<g​fdshygti53:monero.social> They have also 4K sector variant for that sheme too

<g​fdshygti53:monero.social> It's enterprise grade hardware

why do you call it adult?

<g​fdshygti53:monero.social> Because it's not toy like consumer hardware

<1​23bob123:matrix.org> Enterprise

let a monero tx be = 5kb, so (5 * 50 000 * 200)kb in a block

<g​fdshygti53:monero.social> 1.5kb

<g​fdshygti53:monero.social> My cheapo Raid 5 array (HDD) can absorb 600MB/s

<g​fdshygti53:monero.social> It's faster than Sata SSD 😂

so that makes 50 gb per block

<g​fdshygti53:monero.social> wait, I have to calculate that lol

<g​fdshygti53:monero.social> more like 14GB

<g​fdshygti53:monero.social> per 2 minutes

times (30*24)

thats 36000 gb per day

36 tb per day

hum

<g​fdshygti53:monero.social> But that 50k tx/s is like peek Visa right (peak as normally it's way lower)

the write cache argument sounds very healthy

but the tb of hdd

<g​fdshygti53:monero.social> assuming the majority will continue to be slaves, I don't think we will get to that number for the real money utilization

should be partitioned

such that the coupon collectors problem handles that

if it rises with n log n

hum

<1​23bob123:matrix.org> We’ll have the glass hdd by then!

how many distinct partitions of hdds would be needed

<g​fdshygti53:monero.social> It's already the case, been a while these are not made of rust

such that the entire set of blocks overall is covered

assuming the majority will continue to be slaves?

<g​fdshygti53:monero.social> afaik, HDD platters are already made of "glass" with a layer of some exotic rare earth metal mix layer

wrong narrative

<g​fdshygti53:monero.social> afaik, HDD platters are already made of "glass" with some exotic rare earth metal mix layer

<g​fdshygti53:monero.social> Yeah, the majority will continue to be slaves, that's unfortunate but that's confirmed.

<g​fdshygti53:monero.social> The slaves run the world (they mine materials, cook our bread and prepare our packaged foods, clean, fix....)

<g​fdshygti53:monero.social> Crypto people are technically extremely unproductive 😂

<g​fdshygti53:monero.social> if most people where to switch, who will work on the field, build our crap and maintain our services?

<1​23bob123:matrix.org> So we should buy mining farms in africa, gotcha!

<1​23bob123:matrix.org> Ccs in bound

if john doe adds 36 tb of data every day to his full node is this a problem in the future

?

and how big would the write cache be in that case?

<g​fdshygti53:monero.social> We wont geet to Visa peek number

<g​fdshygti53:monero.social> get*

<g​fdshygti53:monero.social> first, it's peek number, most of the time, it's lower

<g​fdshygti53:monero.social> and don't expect more than 5% to free themself

ok

for me its christmas every day

i deliver packages

(not blocks)

:]

<g​fdshygti53:monero.social> I'm waiting for packages, what are you waiting for?

<g​fdshygti53:monero.social> Cyber Monday stole some nero from me :(

and don't expect more than 5% to free themself?

wrong narrative

if john doe adds 36 tb of data every day to his full node is this a problem in the future

and how big would the write cache be in that case?

<g​fdshygti53:monero.social> If it's after Seraphis and we get full membership proof, you won't need the cache (as far as I understand)

<g​fdshygti53:monero.social> Can someone confirm this?

why?

<g​fdshygti53:monero.social> What slow the whole HDD shebang right now is the fact that node have to check the decoys when it verify the transactions. 16 decoys per transactions, that mean you have to read 16 older blocks per transaction you verify

<g​fdshygti53:monero.social> Seraphis will change that

<g​fdshygti53:monero.social> full proof membership will make it so the whole pool of TX are decoys if I understand, meaning you won't have to read 16 blocks per checked ring

16 decoys per input per transaction

<g​fdshygti53:monero.social> yeah, it's why I then mentionned "per ring"

<g​fdshygti53:monero.social> that is why you want the cache if you want to sync as fast on HDD setup

<g​fdshygti53:monero.social> most decoys in rings are recent, and it's the reason you want a write cache, so that you cache 32GB worth of recent tx

hum

<g​fdshygti53:monero.social> so if we don't get seraphis or it's does not have that full membership proof, I assume you will make the cache so it fit grossly a year worth of TX?

<g​fdshygti53:monero.social> Else, just use the cache until it's no longer needed

(36 * 365)tb

<g​fdshygti53:monero.social> non,

<g​fdshygti53:monero.social> lay say 5% of the world switch to monero

<g​fdshygti53:monero.social> will make it only 2.7GB per day

<g​fdshygti53:monero.social> Meaning you take 8 years to fill 8TB

how did you get that number?

<g​fdshygti53:monero.social> Yeah, i'm rechecking them lol

<r​ucknium:monero.social> RavFX: Any estimate for the ratio of time reading ring member data from SSD and HDD? Seraphis may have ring size 128 instead of full chain membership proofs. More ring members would be older if ring size goes to 128 (not proportionally, necessarily, but just more of them bevuase 128 > 16).

<g​fdshygti53:monero.social> So you fill a full 8TB hdd a year instead, still "relatively cheap"

<g​fdshygti53:monero.social> Yeah, so it will be more IO intensive if we don't go to full membership proof. Thanks

how many tx/sec ?

<g​fdshygti53:monero.social> What about transaction size?

<g​fdshygti53:monero.social> 2.5k

(not % of population)

<g​fdshygti53:monero.social> at PEAK

<r​ucknium:monero.social> Probably more IO intensive without FCMP, but the current FCMP proposal is much more CPU intensive than Seraphis or the current Monero design.

brb

how many tx/sec ?

g​fdshygti53

<g​fdshygti53:monero.social> But bottleneck is probably the IO if we talk about adoption.

<g​fdshygti53:monero.social> Cores are getting cheap (compared to fast storage). Do we have the number for the CPU usage?

<g​fdshygti53:monero.social> I'd say max 2.5 (peek so rare and not long)

<g​fdshygti53:monero.social> And average kb per TX : 1.5kb

<r​ucknium:monero.social> AFAIK, the FCMP proposal has 5.5 kB for a 2in/2out tx: monero-project/research-lab #100#issuecomment-1609536076

<r​ucknium:monero.social> Seraphis with 128 ring size is about 2.5 kB for a 2in/2out tx: monero-project/research-lab #91#issuecomment-1047191259

<g​fdshygti53:monero.social> So more data writing (but way less randomly accessed data).

<g​fdshygti53:monero.social> Thanks. So HDD will be king if we switch to FCMP

<r​ucknium:monero.social> Current 2in/2out Monero tx is about 2.1 kB

<g​fdshygti53:monero.social> So seraphis/128 would mean like 8x the number of IO we have now

<r​ucknium:monero.social> I don't know what IO has to be done to verify txs in FCMP

<g​fdshygti53:monero.social> From what I remember, might be wrong, is that you don't have to read all the decoy TX. Else it would be a problem anyway (reading the whole blockchain for each TX). So I assume there is more math stuff going it.

<r​ucknium:monero.social> CPU time per tx for FCMP is a lot. I am looking for the estimates. The CPU estimates are less certain because there could be optimizations in the math somehow.

<g​fdshygti53:monero.social> I understand.

<g​fdshygti53:monero.social> So we are going to massively pump the IO requirement, or the CPU requirement, but not both.

<g​fdshygti53:monero.social> Except if they have a way to not have to read 128 decoys per ring

Can we quantize the increase?

<g​fdshygti53:monero.social> Except if they have a way to not have to read 128 decoys per ring to verify

<r​ucknium:monero.social> You can do batched tx verification or non-batched. The CPU times required is different. AFAIK, you can do batch easily when syncing blocks, but with maintaining a mempool (verifying txs as you receive them), probably non-batched.

just a question

<r​ucknium:monero.social> RavFX: github.com/kayabaNerve/full-chain-m…ip%20Proofs%20MoneroKon%202023.pptx

say you keep one year of the latest blocks in the write cache

<r​ucknium:monero.social> > Verification is batched, with the larger the batch the lower the time per proof

<r​ucknium:monero.social> > Currently, ~100ms per proof in a batch of 10 for a set of 777 million outputs

<r​ucknium:monero.social> > With an academic progression, it’d be just ~33ms (again, batch size equals 10)

<r​ucknium:monero.social> > Grootle proofs, currently proposed for a ring of 128, are 3.7ms in a batch of 10

what comes before that?

<r​ucknium:monero.social> > Further optimizations are still available

<r​ucknium:monero.social> > Performance of the node overall will be impacted

just the headers of the blocks?

<r​ucknium:monero.social> As of 6 months ago, FCMP tx verification time on CPU is 10x slower than Seraphis with ring size 128.

<r​ucknium:monero.social> I think kayaba is expecting more optimizations for FCMP.

where can i read about that snycing only 1/8 thingy?

im very interested about syncing only partitions of the entire blockchain

?

slave_blocker, that happens when you use -prune

<g​fdshygti53:monero.social> LVM2

<g​fdshygti53:monero.social> sync the whole thing on HDD and keep ~1Y worth of blockchain LVM write cache.

<g​fdshygti53:monero.social> It's automatic, I will re-deploy the guide soon

--prune-blockchain

<g​fdshygti53:monero.social> Prune only remove 1/3 and it work on a different way.

<g​fdshygti53:monero.social> remove 2/3... you keep 1/3

yes

but that depends on the ring decoys being dropped and so on

is there a torrent trait to it?

<g​fdshygti53:monero.social> Yep, for now the LVM trick is great but when Seraphis / FCMP that's going to change

that sounds interesting

...

<g​fdshygti53:monero.social> Well, you get the new TX that enter the mempool p2p way, but then your node verify using the data it already have

ok

but how does it work for a john doe doing ibd

always --prune-blockchain

<g​fdshygti53:monero.social> I have no idea about how theses work. I never used prune

does such a syncing node always assume a full node somewhere?

<g​fdshygti53:monero.social> Syncing node can sync from full and pruned nodes afaik, p2p way, from many nodes.

<g​fdshygti53:monero.social> And many pruned nodes will easily produce a complete set there is no problem for syncing.

And many pruned nodes will easily produce a complete set

that is exactly what i wanted to read

:}

<r​ucknium:monero.social> s​lave_blocker: IIRC no tx output public keys are removed when you prune. If you want more info on pruning, check getmonero.org or Monero's Stack Exchange.

<r​ucknium:monero.social> Pruning only removed 7/8ths of prunable data. IIRC the prunable data isn't necessary to verify future txs.

<o​frnxmr:monero.social> Cuprate docs 👍👍

<o​frnxmr:monero.social> github.com/Cuprate/cuprate.github.i…main/src/monero/database/pruning.md

<r​ucknium:monero.social> They are finally doing it....WTFM 🥹

<b​oog900:monero.social> I've moved that pruning section to monero-book I think it's more at home there compared to Cuprates docs: cuprate.github.io/monero-book/pruning.html