Has anyone ported the electron wallet to monero yet?

electrum?

electrons are a conspiracy.. pretty sure

i mean think about ir

it

yanmaani: as a user I perhaps do not want to do the work of verifying transactions myself, but nor do i want to offload that work to an unknown entity with uncertain incentives

but our world is already built on trust; i would be happy offloading that work to someone in my "community", for some definition of community

endogenic: stick a fork in your electrical socket to prove it

ok edison

I'm really new to how all this works so this might not make sense, but, with the way ring signatures work, would I have to send through several different addresses to obscure the trail or does it have the same affect if I were to keep sending to my own? I'm having trouble grasping the logic of this

burry: sending back to yourself is equivalent to sending to another of your addresses, so long as you aren't polluting the 'trail' with new outputs or creating trail 'loops' which both add a lot more complexity

Tari Labs compliance paper update from tari TG: "Very close here - we hope to confirm the publication date this week. Whitepaper + short form version in Bloomberg Law and a Harvard journal"

hello

what is the coinbase structure for v12 block version?

paste.debian.net/1158408 is v1 version

what is the coinbase structure for v12 block version?

v1 is here paste.debian.net/1158408

thank u

banama: I don't think many Monero devs look at this on the byte level and have the info handy in this format. Personally, I would start with the C++ source, work out how that probably serializes and then check against an actual hexdump of a block

i check all hardfork changes but stil cant understand where code check for block version

or maybe is cutted in many pieces and i dont know enough c++

this link explain enough monero.stackexchange.com/questions/…ucture-of-a-monero-transaction?rq=1

bigslim[m], jbg: Yes, you can do that securely, but the problem is that if everyone does it, you will no longer have security.

so the devs make it harder for that reason

yanmaani: huh?

hola

blogged lately kayront

?

not lately, not lately

lots of ideas flowing and might write something soon though. it's idle but not forgotten :)

nice of you to ask

haven't been on IRC much either, but every day brainstorming crypto stuff, hehe

how's it going over here?

i'm listening to schiff on the what bitcoin did podcast, deconstructing all of peter's arguments one by one would be a good writeup

dude's a true nonbeliever

i remember his debate with molyneux years ago

schiff was saying there's no inherent value, stef was saying the inherent value is the utility. essentially

he's using the same arguments everywhere

also on rogan

that's his ideology. Why would he change his position? Nobody can effectively refute them, as far as I can see, as they are based in belief (and not all incorrect either)

why would he change? why do people debate things? presumably to arrive at truth

come to think about it, maybe that's not so obvious nowdays

lol, they actually mention monero by name at the 1h mark

as usual in the context of providing cover to do something illegal

useful, when laws don't match common sense, but is it really so hard to understand that privacy in day to day things is also valuable, if not desirable?

anyone here running a full node on btrfs/zfs? if so how do you deal with the huge fragmentation in the db file causing lots and lots of i/o?

it's just what monerod does artefact

i got a giant l2arc nvme and now it's only a problem with a cold cache

i don't think it's zfs specific, though if you misconfigure zfs then that likely won't help the case

can't do that yet with btrfs sadly

it's just slow on mechanical disks in general, lots of random I/O

(monerod)

get more ram, also works

is it already on an ssd? then fragmentation should be ok

it's on spinning rust atm. i have a nvme drive but nowhere near enough free space for the chain

16g of ram so plenty of space for cached pages

just had a look at mine, and presently 80GB are allocated in l2arc

not all of it monero stuff, but it's by far the most active daemon in the whole system

i hope it slows down a lot once it's caught up with the network

well, zfs is copy on write, so the philosophy is that you have to live with it

imagine your node is fully synced already, and you connect your wallet to refresh - you haven't for a few days .. every transaction has decoys, and the decoys have to be looked up by monerod as it serves your wallet the data

that's my working theory as to why it's so slow in hdds. it's very perceptible with a cold cache when syncing wallets especially, i don't think it's coincidence

right. hopefully i don't have to do it very often

as long as you have enough free memory the os should cache as needed

when it has to fall back to reading the disk continuously, say goodbye to performance

(not a problem with ssds/nvmes ofc)

btrfs/zfs are extremely poor choices for storing the blockchain

they are copy-on-write filesystems, and LMDB is internally a copy-on-write dataase, so you're getting massively redundant writes

for LMDB the simpler the filesystem the better

the less the FS tries to do, the better...

nodatacow is always an option, but i'd rather not use it unless absolutely necessary

or put the blockchain DB on a separate filesystem. easiest is ext4 with journaling turned off

not feasible for practical reasons

with a couple small patches, the best option would be its own raw partition

(I have written the patches, but not merged and released)

how about patches that make the db dumber for smart fses :-)

sorry nope

you should read the usenix report from here twitter.com/Superfind/status/1287609039875121155

FSs all suck

LMDB's own data reliability mechanism works better than all of them

not sure you pasted the right link

bah

well, a filesystem isn't a rdbms. rdbmses aren't filesystems.

lemme try again

LMDB is a DB engine, and can be used in an RDBMS but it is not an RDBMS itself

yes, i recall that fsync issue from postgres mailing lists too

and differences aside, filesystems should not allow data to be corrupted without warning

they assumed that if fsync failed , you could retry it, and if it succeeded, it meant that all the data was safe on the platter. turns out, no

it goes deeper than that. the psotgres thing was only one particular failure mode

and yet, the only filesystems afaik that do data checksumming are COW filesystems

anyway, i don't want to hijack the channel and start a debate, i just got here :-)

read the report, or at least the presentation slides

they claim two distinct failure modes for LMDB, one of which I'm pretty sure they're wrong, and the other is the fault of ext4's journal

which we can't do anything about, and we always tell our customers not to use that journaling mode anyway

what do they mean by “ext4 data mode” in the slides? data=writeback?

data=ordered

thanks

their writing is pretty unclear on that, if I were a reviewer of their work I would've pointed that out and asked for revision

there's no excuse for using fuzzy terminology in a tech paper with well established technical terms...

kayront: an ideology is a belief structure or system, not a search for truth. I can believe it's better to eat beans for breakfast, and you can believe it's better to eat bacon. There doesn't have to be a unified truth.

only morons use BTC ...

but muh network effect!

reading about lmdb. reminds me somewhat of judy arrays. very clever and very fast, but still rare in the field for some reason