Delta 8 distillate for sale, XMR accepted: moneromarket.io/listing/3e43b22f-4830-45f3-9a0f-3f9c9813a8cc

I have a question. Does Monerod not constantly exchange i2p nodes? I notice that the number of such notes increases dramatically at 00 minutes

in the cli wallet is there a way to directly save a signed transaction to file so that it can be submitted later?

it seems to be possible to use a view only wallet to create an unsigned tx saved to file and then use a wallet with the spendkey to sign it but there doesn't seem to be a way to directly save a signed tx?

<lxx7[m]> "Delta 8 distillate for sale, XMR..." <- THC is illegal in most countries.

In case you forgot, I remind you that it's against the Monero Community Guidelines to post or promote illegal content.

Doesn't matter if it's not illegal where he's from

People sell gun build kits on moneromarket, obviously not legal everywhere but that doesn't mean they can't offer them

maybe the CCS with the rust node could first implement the whole network stack and dandelion++ instead of building the whole node ...

starting the wallet with "--do-not-relay" seems to do what i want

hello everybody, i havent used monero since 2019 and im looking to import 2 old wallets, i used the macOS gui wallet back then and have walley.key files for each wallet along with a wallet file.

i have the seed for one of the wallets, easy to recover.

however when i try to import using the linux gui walet, i have to enter the public address and more

sorry, when i try to import using the key option

nm nm, user error

sorry

atomfried[m]: wouldn't dandelion++ require a functional node?

Boog900 has closed their CCS proposal without comment plus deleted their Reddit post and also user: reddit.com/r/Monero/comments/zzd19g/ccs_proposal_rust_monero_node

<selsta> "atomfried: wouldn't dandelion..." <- i dont actually know, but isnt dandelion++ just the algorithm which decides how information is spread accross the network?

i dont think that needs all other stuff, but i could be wrong.

sure in the end it will be transactions which are broadcasted, but if a piece of software can broadcast anything with dandelion++, it can surely also broadcast transactions in that manner

it's how transactions are propagated

i don't think dandelion++ can easily be implemented as some isolated piece of code that can be later reused but maybe I'm wrong here

Right now it's pretty inter-twined with the rest of the code. Maybe if you started a daemon from scratch you could implement it as an abstract class

and then the actual transaction passing-on subclassed from that

right but that was also require you to know the daemon design first

Put it under the pillow, sleep over it, done.

Just to avoid misunderstandings: With my "hard no" comment on GitLab I spoke out against that particular proposal, not the person making it.

You could do many sensible things towards rusty Monero. Why not start with a good feasibility study? I think a solid CCS for that would have good changes to get financed.

*chances

And could be very interesting.

Sorry I should have commented, but I closed it because it was a bit ambitious and a couple comments were (rightly) a bit harsh so I thought I would save time and just close the proposal now, I deleted my reddit post for obvious reasons but my account is still active, I didn't delete it.

Can Rust code be called easily from C++ so more-or-less isolated current monerod code can be implemented in a Rust-fork incrementally?

good to hear!

First instinct would say no, not easily, especially given the less-than-ideal current structure of the code

But, again, that would be an interesting question to try to answer with a feasability study ...

I also commented in -community, but to summarize here:

I disagree with sech1, who I do, of course, respect. I'd guess a PoC, which is using P2P to exist on the latest HF, would be a few months of effort. It'd suck. It'd also exist.

With the existing amount of code out there, and my own understanding of it, I'd imagine a year as feasible to get everything up *as a node*, albeit poorly.

My issue with this proposal is an overall lack of documentation. I think clarity needs to be set on individual components, I'd hope for a better overall plan than just "node in Rust" (considering styles a la Erigon), before finally being broken down into much smaller segments.

I'd also say the current XMR codebase is filled with garbage and a pure LoC on it isn't a sane comparison.

"P2P to exist on the latest HF" means you have to implement all previous hardforks too, to be able to sync from scratch

which is a massive task

unless you do shortcuts with hardcoded block hashes up to the latest HF

kayabanerve[m] I've been working on medium/big/huge C++ projects since 2006, and I know how easy it is to underestimate the work. Once you actually start working on something big, it's suddenly one thing piling up on top of another which you never expected when you estimated

*working professionally

some PoC that barely works with a ton of hacks under the hood - sure, one programmer can do it in 9 months

but is it what's really needed?

LMDB, for example - just take it as is and make a Rust wrapper? Or rewrite in Rust? Same for Cryptonote's crypto math functions, same for networking layer. Rewriting just these is a huge task for each of them.

and if it's just Rust wrappers around all the base layer code, what's the point of Rust then?

Don't forget that nodes not only talk to themselves but have to serve wallets. Implementing the whole RPC interface with full compatibility alone is a big task.

sech1: I was thinking assume valid given a hash and just populate outs, yeah

And that still isn't complete as you need to be able to spend old TXs. I had to deal with that recently...

As for work experience and underestimating, yes, I totally hear you. I was basing this on spending 3 months on my current Monero work and having built a node before.

You can write P2P code in a few hundred lines. Is it garbage? Yes. Is it functional? Yes. Can you probably hook up to XMR's P2P lib, with no where near the same level of tuning, in a few hundred lines? Eh, maybe 1 or 2k I'd guess. I do have to caveat I have yet to look at Monero's P2P layer.

My premise was, even if it was 1-2k lines which is a minimal variant, that's not necessarily a hack. That's just a building block. So I wouldn't say with a ton of hacks, I would say as a minimal product. I'd hope after a year, the true 'hacks' are gone.

Also, the main selling point of Rust is memory and thread safety at compile time, right? I think it will be more productive to actively integrate C/C++ memory/thread runtime tools into CI

like memory/leak/thread sanitizer

yes, it's runtime, but it's almost plug and play for C/C++

and add more tests with sanitizers to our unit tests

As for C++ code... I wouldn't support pure-Rust from the start. I'd point to wrapping LMDB/RocksDB (hides from hyc) and then in the future moving to sled. I'd care more about DB diversity than moving to a Rust DB tbh.

I'd also be fine grabbing C++ RandomX to start, if the current Rust rewrite isn't there. Then moving to the Rust rewrite.

When I did monero-serai, it initially hooked into C CLSAG verification. I knew it'd work. Then, I wrote a Rust version, labelling it as unsafe. Eventually, I traced through a variety of functions to ensure my understanding of behavior, corrected differences, and moved over.

If we really implement a second node in whatever language I think we should make damned sure we fully grab the chance to re-architect to the max, based on experiences made

Part of the benefit isn't just the language. It's client diversity. It helps to identify previously undocumented protocol rules.

Thus, no attempt to rush through it as fast as possible, but with a very thorough first phase of discussions and architecting

yeah, rewrite that produces new codebase AND detailed specs is what's really desired

For example, we don't have input sorting high-to-low nor low-to-high. It's std::sort. Sure, that's internally h-t-l or l-t-h, but it's also us picking C++ over some actual specification. I believe Rust default sorts the other way.

The main issue with specs is that by the time anyone struggles through the code, they no longer want to touch it anymore, and they don't write specs :/

Yeah, the "good and complete spec" stands right next to the "good and complete user manuals" on the bookshelf :)

So what we actually want is: 1) Specifications 2) Proper planning 3) Not just doing bitcoind/go-bitcoin/whatever yet actually looking to projects like Erigon 4) Client diversity

It's just when we ask what language we want the client to be in, we love Rust :p

I can also propose PASCAL though if it'd be less controversial /s

Eh. That's a bit improperly ordered. Specs, Client diversity, planning, intelligent design. I'd say that for order

But as sech1 said, you would have to weight that against all the tons of good things we could do with such massive amounts of work and donations, based on the current codebase

... possibly? I lean towards no?

And frankly, we don't find devs for a lot of things that are waiting, where would all those Rust Monero devs suddenly spring up?

I always consider this idea a separate project and that idea a bit of a fallacy.

I'm not trying to say I couldn't do anything for the existing codebase. I'm saying if I tried to replace our Ed25519 code with dalek, an industry gold standard, I'd get run out.

New projects allow full flexibility with the ability to make decisions outside of the entire community as a committee. That shouldn't be unappreciated.

Also, there are plenty of Rust devs in the community. h4shed, lederstrumpf, TheCharlatan, zkao, whoever's working on COMIT...

jeffro256, this guy who just made a CCS proposal, myself...

*guy intended as a gender-neutral term

... also h4sh3d, not h4shed.

"that idea a bit of a fallacy" I don't understand. Which idea, and how a fallacy?

I have no interest in contributing to the current codebase because: 1) Lack of time 2) Lack of returned value (circling back to lack of time) 3) It's a monstrosity 4) It's in C++

If the same amount of work was directed to the current codebase, it'd be great. Sure, if you could direct that much work. You can't.

I can justify my Rust code because I have a project in Rust which relies on this. I can't justify C++ contributions the same way. I'd also highlight integration accessibility as yet another reason to do such work.

I believe there are already complaints about wallet2 not playing well with API. I believe those calls are for a C wrapper, yet I can point to the hell which is statically linking wallet2. Even if it cleanly built to a C API, I'd still prefer a Rust lib if I was coming from Rust (though sure, a Rust crate around the C API would be tolerable).

Er ... you are aware that I lead a work group that tries to fully supersede wallet2 with new code? Just not in Rust, but in C++.

As for the current codebase being a monstrosity... I don't what it is and I understand why it is what it is. Most of my experience is with the cryptography and wallet side of things (and TX flow). I've stayed away from the P2P layer and generally don't bother with the blockchain. There's an insane (to anyone used to language's with a package manager) lack of vendoring. We frequently reuse code instead of creating modular functions.

wallet2 throws around tens of arguments with no consideration for logical thought nor runtime safety achieved at compile time. All of these make me feel overwhelmed when tackling the current codebase. And then personally, even ignoring C++'s memory safety issues, I haven't worked with it in years and can't claim to be current with it. I find it missing several basic functions for dev UX though.

I do know of that org/repo, hence why I knew of the C API discussions :p I didn't realize/rememeber you led it, sorry.

Well, so far there wasn't much proper discussion about writing it in C, or providing a pure C interface, because nobody so far except the proposer thinks it's feasible, given our constraints

I thought there was a call for a C API and it was shot down to the fact anyone already could have, already no one has, and it's an extra outside of current bandwidth

So not necessarily a lack of proper discussion, yet mainly a lack of bandwidth, which I'm not here to dismiss.

Not trying to be pedantic, trying to ack how it was a feature request

No problem. And no danger whatsoever - code does not care what people wish for, or what people tell and write. Only actually writing code helps in any way.

That I can agree with :) My main comment is people wanting to work on/contribute in Rust cannot be dismissed on the premise "they'd do just as much good contributing to the C++". While yes, they may (assuming equivalent C++ knowledge), they may not want to work in C++. There's also other benefits to client diversity and a better path for non-C++ integrations.

Donations, sure, possibly, until you reach an org using Rust who wants quality Rust tooling/an idealist who wants client diversity and/or memory safety/some rust fetishist :p

My very unprofessional opinion is that a better option might be to make transitioning to Rust a long term goal. As pointed out earlier, the current codebase could use some restructuring. The investment may be justified for the better long term safety, better accessibility, and better modularity/extensibility provided by a rewrite in Rust.

As the old hand that I am I worry a bit about the "grass is always greener on the other side" effect.

While I can argue for Rust FFI internal to the Monero codebase as viable, which is almost never, I cannot argue for ever commenting about the abandonment of the current C++.

A shiny, sexy "new daemon in Rust" project would probably suck dev capacity out of the C++ programming side, which would get strained even more than it actually already is

if we are not very careful

rbrunner: One of the benefits of it being separate is the ability to move fast and get ignored faster.

I don't believe anyone uses monero-serai and if no one ever does, it fades away. If people appreciate it...

as a side note, I do truly love its wallet handling <3

How would you manage a really separate Monero Rust daemon project? How would you finance that separately?

Seraphis implementation and a daemon in Rust fighting for scarce CCS money ... not the best of possible worlds, right?

docs.rs/monero-serai/0.1.2-alpha/mo…ro_serai/wallet/struct.Scanner.html You can scan an individual transaction, and get it without global indexing, or scan an entire block and get it with global indexing. All returned outputs are always TImelocked<>, forcing you to ignore the timelock or accept within some range :D The global indexing is a privacy thing (grabbing an individual TX's index), the timelock is a safety thing.

Maybe anything "rusty" should take Seraphis as a starting point anyway, in a sensible longterm planning

*Some of those types aren't clickable for documentation. I'm immediately unsure why and will have to update that.

Someone has to sit down and do plans, I guess? For monero-serai, I just got to work... that's not an issue if you're one dev (especially when you solely do a TX library, not an entire daemon). I'd hate to suggest a project of this scope as one dev/without planning.

We had the Erigon dude, who effectively did have planning, yet went against the flow (causing community criticism, including from myself) and I don't believe is around anymore :/

I don't think we chased him out, though sure, we could've been friendlier. I think it's a lot of work and they moved on.

Have some pointers? I hear "Eridon" for the very first time today, and wonder a bit about that fact

er, "Erigon" as it seems

As for finances... I can't comment there 😅 I worked for 3y on my own project (never taking finances) and am doing the same with Serai. I am paying some developers on Serai, yet out of pocket from former bug bounties.

Erigon was in the news recently as Paradigm wrote their own ETH node, based on the same design principles, and the dev got into a feud about that

(taking the ideas yet not giving back the code, whole thing, many opinions to have)

But if you pull up Paradigm's posts on why, it should be a decent shill piece on the design :p There's also Erigon docs somewhere...

I believe it's mainly about staging data inwards and highly efficient DB management.

paradigm.xyz/2022/12/reth for Paradigm's commentary, which is decent on both logical design, codebase design, and the scope the amount of work it is, is

Source: monero.graphics/all/monero-happy-new-year-2023

🎉

See ya folks

Happy new year

anarkiocrypto[m]: happy new year to you, too