where is monerod.exe storing the blocks it syncs?

only in-ram?

nope, definitely not ram

hansh, C:\ProgramData\Monero

or something

\ProgramData\bitmonero maybe

C:\ProgramData\bitmonero yeah

thanks

np

is it basically verifying everything since the beginning of the network?

yea, exactly

and when was the start of the network?

2014

if you run with pruning it will end up ~30 GB

without pruning ~90 GB

and minimum ram requirements for cli wallet?

It won't verify some stuff for the first 95% or so. Use --fast-block-sync 0 to force verification of everything.

does a sender need to know anything about the recipient other than the "public view key" ?

I think both public view and spend keys

but I am not a mathologist

yes, to send you need both public keys

hmm slightly confusing, seems a mining pool is only asking for the primary address, is knowing the primary address sufficient to send to someone?

yes

so in order to send to someone, you need *either* the "public view key:public spend key" pair, -or- the primary address, does that sound correct?

sdfgdgbnh

Just opened a wallet in the CLU it's using <20 MB of RAM

never heard of using pub keys to send to someone but ig you could

I think you'd use the pub keys to generate addresses then send to an address

sorry im just confused.. and should probably be in bed anyway

well, the "address" is a 95-ish character long base58 string

which contains both public keys

oh

maybe that's what they're asking for

yes definitely, thanks

pfft sorry I was thinking of private view key doy

should also be in bed ig

the topic says "stay away from minergate", i've been using them a little, but i moved over to herominers.com , anything to say about herominers.com ?

is the "address" basically just the 2 public keys concatenated, or is there more to the address than the 2 public keys?

nope, just two public keys encoded in a slightly weird way

well, there's also the network ID byte at the start and a checksum

oh thank you

... network id?

yeah, like mainnet, testnet etc

ok, i guess there's supposed to be less than 257 of them for the foreseeable future? :p

what does this mean, why is it both "54% synced" and "38% synced" at the same time?: Synced X/X (54%, X left, 38% of total synced, estimated X hours left)

probably % of blocks and estimated % of time completed

don't know how reliable the time is

#monero

#monero

wordi #monero

#monero

#monero

wordi #monero

#monero

fullmetalScience?

wordi #monero

#monero

i see

In GUI is there a known bug with Trezor on Mac? Getting 'BridgeTransport enumeration failed:Bridge enumeration failed'

'No matching Trezor device found. Device specifier: ""'

'Device connect failed'

This happens on the screen where the HW device is selected, after filling all forms and trying to continue to the next screen.

fullmetalScience: do you have the latest trezor firmware?

and latest version of trezor bridge?

selsta: Good question. Is the Trezor Bridge even required? On Linux with Monero CLI it works without it.

It's not required on all systems. It might be required on Mac.

Hm .. Trezor Wallet (the online one for BTC and others) works. I'll try to gather more info.

I would still try installing trezor bridge and latest firmware

I did. With bridge installed it works, which is strange given that it wasn't installed before, but it worked last year (with the previous Monero version).

on the same OS?

Same machine and OS.

Although I determined that bridge wasn't installed before solely by what the Trezor site told me. So there's a chance I simply forgot I installed it back then and the site didn't notice an old version being there. Maybe Mac has some logs about installs some where ...

Oh, it actually has and there's an entry for Trezor Bridge dating back to mid of 2019.

So that was probably it. My bad.

Trezor bridge should not be necessary theoretically

according to the trezor dev

but guess there might be a bug

A bug that wants to go a different route than direct USB access?

what's the meaning of launching monerod in "simple mode" ?

Frenn_: from the GUI?

matthewcroughan_: yes but manually like --no-sync

I don't think there is a CLI "simple" mode

Is that synonymous ? That's bad. "Simple mode" sounds attractive, and --no-sync is bad.

--no-sync will not sync the chain, it was meant to allow a node to look for public RPC nodes on the P2P network.

moneromooo: I synced monerod last night and realised it takes up a crap ton of space lol

How much does monerod rewrite?

Oh wait, it'd do that... nvm.

I don't want to use this, just wanted to understand what is it. Oh ok thanks moneromooo

In other words, how bad is Monero's DB for an ssd? Does it only write once?

It writes every time you get a new block, or a new tx.

what about re-orgs?

Basically my question is whether it's really that bad for something such as an SD card?

Raspberry Pi nodes.

If it only writes once, and *does not* re-write under any circumstances, it may not be that bad.

The firmware decides what to rewrite.

monerod writes a lot, nevertheless.

No I mean does monerod rewrite?

Does it get things wrong a lot, and thus cause more writes than necessary?

e.g half-download a block, half-write a block, then give up and try again.

or does it do all of that in ram, instead of on disk?

What I would want is for it to do all write intensive operations in RAM, and *never* sync to disk unless it only has to write once.

i.e not using the disk as ram, unless it really needs to. Even if this slows down sync massively, as to allow RPi-like devices with sd card flash media to last longer.

That should be in RAM.

It's the OS's decision what to swap though.

Yeah but imagine there's no swap configured

I would hope that monerod works this way already, but I have no idea if it does :D

moneromooo: we also have a simple mode that syncs the chain

Rpi doesn't have enough RAM

the user can select it on first startup

hyc: what determines the minimum ram requirements?

the volume of the blockchain

why couldn't the node just slow down?

a pi is pretty slow

syncing on a different device and then moving the blockchain to the raspberry should work

Indeed, but why is there such a thing as minimum ram requirements? Why couldn't the node just process slower?

the software already uses ram optimally

it already does exactly that

There's also --db-sync-mode=fast

there is no hard minimum unless you're mining

--db-sync-mode=fastest:async

So a slow node when mining is goin to leave you with a lot of orphans? Is that right?

the default is already async with background flushes

yes, but the cpu usage is massive, because it =safe instead of =fastest, right?

no

safe doesn't use more cpu

oh, I thought it did

Does --fast-block-sync use the checkpoints.cpp?

fast-block-sync uses checkpoints.dat

which is different from checkpoints.cpp afaik

So have the hardware requirements for Monero grown, to run a node?

monero has way more usage now

So the mempool is full more? Or do you mean something else?

more transactions per block

Is there anything for Monero that has been discussed that would allow people to run nodes on more embedded devices, such as a phone or a pi?

Some sort of lighter node. If at all possible.

15:44 <selsta> syncing on a different device and then moving the blockchain to the raspberry should work

does that work?

I run nodes on VPS with 2GB ram

Yeah but they're hacks.

raspberry has 4gb afaik, so should work

MimbleWimble inherantly allows pruning of transactions, for example.

MimbleWimble has other tradeoffs

Is there anything we could do to implement that sort of thing, past a certain date, to make all future transactions prunable with no drawbacks, for example?

Or better yet, what is the state of second layer networks with Monero?

Ah is that really Tari? The marketing for Tari seems to change year by year :D

This was posted recently eprint.iacr.org/2020/1441

Tari is not related to this.

I think the daemons for bitcoin and monero are just too bloated already

The daemons?

the chains, rather, they're so big already.

If there is no solution for pruning in either base chain, there's going to come a point at which it's just too demanding for regular users to sync

30GB for a pruned monero chain is quite manageable IMO

Yes, today. But I'm thinking about 5 years later.

Storage capacities will also increase in 5 years.

Today, it took almost no time at all (20 mins) on my gigabit internet, lotsa ram

Hmm, how does this pruning work?

I didn't think the chain was pruned.

--prune-blockchain

do you mean how does it work internally?

If every node in the world ran with `--prune-blockchain`, what would the consequence be?

Pruned nodes keep a random 1/8 of the pruneable data unpruned

wouldn't it be detrimental to the network for everyone to prune their nodes?

so even if all nodes were pruned it would be possible to sync up and verify the blockchain completely

that's crazy

did not know that's how it worked

alright, the state of things is progressing nicely, hah

so the only real scaling issue for the daemons is storage space

16:05 <selsta> so even if all nodes were pruned it would be possible to sync up and verify the blockchain completely <-- this is assuming that there are enough other nodes out there

phones ship with 64-128GB base storage now, I would not worry about storage in 5 years

They've shipped with that as base storage for the last 6 years

obviously depends on usage

My OnePlus One came with 64GB, that was released in 2014, 6 years ago.

iPhone 6 shipped with 16GB base storage

Apple's cheap

iPhone 12 64 / 128GB

that is absolutely pathetic lol

I can't believe that

took them 6 years to catch up haha

The largest amount of Monero's chain growth was between once RingCT was introduced.

Luckily bulletproofs were developed afterwards which reduced transaction sizes by 80% or so.

Now we have CLSAG and in the future Bulletproofs+ which will also reduce chain growth.

BP+ is less than 5% improvement tho, right?

g

you're not firefox D:

using a tiling window manager, sometimes you accidentally hit the wrong window lol

anyway - devs are on top of things, scaling is well in hand

you can still run a node on a pi if you want to. personally I hate Rpis.

selsta: that eprint.iacr post is great.

but my geekbox still works, and a bunch of other arm64 tvboxes I have around the place

I don't actually see the utility of BTC if Monero scales off chain like that.

BTC is a dinosaur

Not having privacy on the base chain is a massive, massive, understated mistake.

and like a dinosaur, it takes a while for the brain to realize itś actually dead

Maybe people will find out the hard way.

HMRC is already tracing BTC nicely.

hyc: sarang posted some BP+ numbers in #monero-research-lab

How does Monero compare to BTC in terms of scale, as-is?

Can it currently handle more capacity? Despite all the privacy features increasing transaction size?

Dynamic block size is helping Monero.

Right, but what I mean to ask is whether BTC is inferior even in terms of scalability, compared to Monero, today?

Or whether there are enough features packed into BTC Core to be competitive

yes, Monero today can handle more capacity than BTC

Exciting.

BTC is still hard-limited to 7tx/s. in practice, it never exceeds 3.5tx/s.

And with all the benefits of privacy, what reason not to use it? :p

And better code, maybe..

(If you look at the chain during the 2017 bullrun, youĺl never see it exceed 3.5tx/s even with all the mad rush going on)

So what is Monero's tx/s?

limited only by network speed

what, blocktime?

over 1000tx/s back in 2017

or you mean propogation of txs across nodes?

it is naturally faster now with the tx optimiztions done since then

FreeBSD vs Linux. BTC vs Monero.

poor comparison, freeBSD has fewer developers than linux. BTC has more than monero

they're just not as progressive

Yup, just like FreeBSD :D

I suspect if corporations invested as much in freeBSD as they did in Linux, the result would be comparable

the same is clearly not true for BTC vs Monero

since we have already done much more with far less.

hyc: I don't think so. FreeBSD has lots of investment.

It's the license difference.

And not just that, but they just don't want to implement certain technologies like runc containers.

They believe things must be done in a different way. Which has lead to less corporate adoption. Additionally, those who do use them do *not* contribute back.

yes, BSD-style licenses suck

they are anti-developer, pro-corporate

Take a look at games consoles, macOS, netflix. They all use FreeBSD so they can get free shit. Of those, only Netflix has contributed back to the kernel.

Sorry, I meant BSD, not FreeBSD lol.

<hyc "they are anti-developer, pro-cor"> not really

<hyc "yes, BSD-style licenses suck"> lots of developers like to be able to use source code as is and not make their code open source in the process.

which is pure BS

they took from the community for their benefit and gave nothing back in return

not true. thats an abstract idea you have. lots of people write code and license it under bsd style. that is giving.

if they don't make their code open source in the process, they are not giving.

that's not abstract, that's quite concrete.

you're talking about two different groups of developers.

yes, lots of devs license their code with a FLOSS license

not really true that they are "not giving" if they dont open source their code. they could be giving in a different way. or they could be shitty coders and maybe its good that they dont contribute. or they could give in another way. some coders like to give their code for actual free. licenses where you have to open source your derivative is not fully giving. its giving with a stipulation. and one could argue they are

not giving.

devs who exploit open source but don't release their own code in return are not giving, simple as that

Precisely true.

Where is the Nintendo Switch code?

I'd love to understand more about the PS4.

And the PS5.

But no, they just took it.

What about macOS' Darwin kernel? There's PureDarwin, but that took a lot of effort and wasted a lot of people's time.

"or they could be shitty coders and it's good that they don't contribute" - this is a laughable excuse

if they're shitty coders contributing gives them an opportunity to learn

and if whatever they tried to write was important enough that they were motivated to write it, it may also be important enough to someone else

who will then come along and improve it

Linux really shoulda been a MicroKernel though.

Would lend itself well to the community and GPLv2 aspect of Linux.

microkernels suck

So do vendor drivers that break your shit.

performance is all sucked away by IPC

its great to contribute to open source. its just not great to use the law to force people to contribute.

Some performance is sucked away by IPC.

donkeydonkey[m]: the law is already used to prevent people from having access. twisting the law to enforce access seems to me like justice.

I just do not think it is acceptable that NFS or Intel Wifi can take my system down.

vendor drivers that break shit won't be fixed by microkernels. it gets fixed by better code, which comesfrom open source.

because of a change some code monkey somewhere made.

plenty of greedy evil corps already steal and derive and keep secret the opensource code that has a license where derivatives are required to open sourced

hyc: Avoiding errors is *not* the same as stopping these errors from breaking your system by architectural design.

donkeydonkey[m]: that's not an excuse

Avoiding errors is not a good approach. Having errors be inconsequential is a better approach than simply avoiding issues by writing better code.

In addition, lines of code and bugs is a linear correlation.

13,000 lines of code for Minix, 500,000 for Linux. Linux has more bugs, statistically.

Microkernels are objectively better, but have performance issues like you said. But I want to run one.

that's a meaningless statistic

How?

if you add enough drivers to minix so that it has the same breadth of features as linux, it will have a large line count too

How is it meaningless?

More lines of code = more bugs. How is this meaningless? Don't you want less bugs?

it's meaningless because minix has nowhere near the capability as linux

It's about as simple as saying more cars = more car accidents.

yes but useless

How is it useless?

because the number of people who need cars to get where they're going isn't going to decrease

Why not?

I could make the argument that people need cars less now, especially with coronavirus.

this is a temporary state

That's unprovable.

lol

Everything is temporary.

this line of discussion is pointless

Everything's pointless to a nihilist such as yourself :P

if you have a population of 150 million drivers, telling them "there'd be fewer accidents if fewer of you drove" is an empty statement

unless you can remove the reasons why they need to drive.

but you haven't addressed that.

so yes, your discussion is pointless.

Have you not seen NetBSD/Minix3?

it's like saying "if we didn't need to breathe oxygen, we could go into space without space suits"

You can run a lot of NetBSD packages under Minix3.

It's not that disadvantageous. You make it seem worse than it is.

It's not even on the same level as car vs bike.

read this test result realworldtech.com/forum/?threadid=197081&curpostid=197081

hyc: You make a lot of false equivalences :D

hyc: What does that have to do with microkernels?

of all the x86-based POSIX OSs, Linux has the fastest system call interface, fastest context switches

Yeah, and TempleOS is even faster.

MacOS is built on a microkernel you dimwit

It's like an Atari.

TempleOS is very easy to crash, Linux is almost as easy to crash.

hyc: Well I had no idea.

Don't call me a dimwit D:

"TempleOS is a biblical-themed lightweight operating system designed to be the Third Temple prophesied in the Bible." are you f'in kidding me?

it's serious

I'm looking around and I can't find anything stating that Darwin is a microkernel.

don't ask stupid questions like "what does a linux vs macos comparsion have to do with microkernels"

matthewcroughan_: I read some paper or something on its architecture many years ago. I think Darwin is a hybrid kernel where they started with the mach microkernel and added a bunch of monolithic Apple shit to it

so probably not microkernel, for formerly microkernel

MacOSX came from NeXT. NeXTOS used Mach as its base, and put a 4.3BSD interface on top

hyc: Well, you didn't know what TempleOS was

it is still a microkernel, with a lot of services isolated into separate kernel processes

you big stinky

also Linux runs a ton of stuff in separate kernel processes these days, so it's not like you can call it monolithic

hyc: it's not self evident that those perf differences have anything to do with microkernel stuff

It proves there is a difference. That is all.

sure, that's just one forum post

there's tons of research tho, any runtime profile will tell the same story

I'd like to see more detail yeah.

I'd love to see something pinning the blame on more specific parts.

Guess we'll never have that since it's not really open source, lol

it's the same as the perf difference between SYsV STREAMS vs BSD sockets

SysV STREAMS wastes a ton of time queueing messages from one protocol layer module to the next

BSD sockets just does direct function calls from IP to TCP to whatever

message-passing is slow, inherently.

message passing is flexible. SysV STREAMS lets you stack protocol modules in arbitrary order, define new protocols dynamically, etc.

but nobody needs that kind of flexibility today, nobody is developing brand new network protocols. they only need performance.

hyc: Actually, that test you gave me is representative of nothing.

Compiling Firefox on macOS vs Linux is flawed comparison.

It is *not* the same amount of work. Both platforms require use of different libraries at build time.

They are not equivalent load.

eh? that test is pretty significant to me, a a software developer

firefox is amazing

Yeah fair enough, but it's not represenative of the massive difference you want to claim about microkernels.

at least 90% of the libraries are identical, because they're all bundled in the firefox source tree

It's representative of a difference in compile time between macOS and Linux. Not of their kernels, but of the platform differences in compile time due to libraries.

> since you can cross-compile the inputs are also identical. Thus the differences are down to low-level libraries (libc, pthread), the kernel and a handful of system utilities such as tar, cp and friends.

should be negligible

yep

hmm

thank you for highlighting that

you can eliminate the difference in system utilities if you just run GNU fileutils on both

but at that point the differences are in the noise

hyc: Friend says being tested in a VM makes this flawed.

lol

you would have to show that the virtual devices are giving different performance for Linux than for some other OS

otherwise, you have to accept that both OSs are running in uniform environment.

No, you just have to prove the results are invalid.

invalid why?

you have to show that there was an unfair behavior somewhere

No, you just have to do the test outside of a VM and show differing results.

That's science.

What you've provided is a fallacy :D

nonsense. but you can certainly repeat the test on real hardware.

You do *not* have to prove why, you just have to prove difference.

Science 101

turn your PC into a hackintosh, you'll get the same end result

That's a hypothesis.

if you can't explain the difference, then you're just engaging in superstition

Needs someone to do it.

That is incorrect. That comes later.

cargo cult. "when I do A, B happens. therefore I will always do A."

that is not science.

All you have to do is prove different results from the same instructions outside of a VM.

That is it. Nothing more, nothing less.

That will either prove or disprove the validity of the article you linked.

You've misrepresented what I have just said.

What I am saying is: If A says B, but C gets different results than A, B must be false.

That is what I am saying, and that is absolutely the most basic truth in science. It's literally explained by Feynman here, the most popular video I know of on the scientific method. youtube.com/watch?v=EYPapE-3FRw&t=217s

scientific method is a tool, yes. it is not an end in itself. the end is knowledge and understanding. without explanations and understanding, you haven't conducted science.

you have collected data.

nothing more.

And by collecting that data, have added evidence to suggest that B is wrong.

As with blockchain, there is only a confidence in a result, not absolute truth or certainty.

close enough. Knowing that gravity on the surface of the moon is 1/6th of the Earth's, I can calculate how much I will weigh on the Moon without having to go there and measure it. With high confidence.

Because I understand the difference between the earth and moon's surface.

And we only have that confidence because of the reproducibility of experiments.

Knowing where the potential sources of perf change can arise in a virtual machine, I can predict whith high confidence the difference in behavior between running on real hardware and running in the VM

Many hundreds of thousands of experiments. Before we sent people to the moon on that basis.

Rather than one post from realworldtech.com that suggests there is a 30% difference in gravity on the moon.

which is why I said to you - point out where the virtual devices will behavoe differently between OSs

there's a large body of experience with virtual machines by now

You'll notice that we don't have to explain *why* gravity is different on the moon

We only have to say what that difference is, with math, over and over.

I don't have to prove what's causing it. I only have to disprove this result.

only then can we hone in on the cause, but it has to happen in this order.