Look on the bright side. At least you don't need to obsess over signs of life from FUK now.

oops wrong chan

why doesn't 0.17.2.0 include longstanding prs on master, like 6986, 7074, and 7422?

7074 looks like a bug fix. Did you PR it to the branch ?

The others aren't AFAICT. Am I wrong ?

yeah 7074 is the only bug fix. I PR'd it to master ~4 months ago and it was merged. is this what you mean by PR it to the branch?

You need to make another PR to the branch

It's not automated

to what branch?

release-v0.17 ?

yes

should non-bug fixes also be PRd to the branch manually, or do they wait until the next release branch is available?

The latter.

woodser: if you PR the bug fix to release-v0.17 now we can include it in the next release

ok

is CLSAG implemented last year incompatible with DLSAG?

What do you mean by compatible?

They are different approaches and not used concurrently.

hence the hard fork

I doubt the change from MLSAG to CLSAG invalidates the approach as the approaches are very similar AFAIK.

because as far I know after implementing DLSAG there would be open way to implement payments channel

but if now there is CLSAG we need new approach for payment channels right?

Or if it made sense we could move to DLSAG -- it's just not generally worth the tradeoffs ATM and payment channels/L2s are not a necessity ATM.

IIRC an approach to payment channels was possible on CLSAG, though...

I can not find any information about that, there is research about Payment Channels but need first DLSAG be implemented

Does not rely on DLSAG

"PayMo does not require any modification of Monero and can be readily used to perform off-chain payments"

this is the same?

No

There was discussion in the DLSAG preprint (don't recall if it made it into the paper) about CLSAG-type key aggregation, but I don't think anyone actually worked it up in detail at the time

It would also not remove the tracing issue that DLSAG has (requiring self-spends to mitigate)

Yes I am aware that DLSAG was drawbacks like tracing issues

Thanks for infomration

It would be interesting to see the CLSAG approach worked up in detail for DLSAG to confirm its applicability

.pap trx

ops

is i2p packaging still underway?

I think i2p-zero is the result of i2p packaginmg

indeed. last I checked in, that was still in the works. is that out now?

It's been out for quite a while.

Any plans for i2p/tor integration into gui/cli package

* Any plans for i2p/tor integration into gui/cli package ?

They both integrate quite easily so not sure a bundling makes a lot of sense.

That introduces another dep to keep track of and increases package sizes for all users.

I think the most realistic will be Tor with GUI

but for CLI users it should be easy to setup without bundling

It's certainly doable but not sure it's warranted with how easy it is to install Tor in most distros

Bundling will make it easy for new users to make transaction over tor/i2p ; TX broadcast over tor/i2p is a must specially due to fuk attack which he is still doing silently

Hi. Where is monero genesis?

@luigi1111w thank you! Is there any docs how to create new genesis block?

not that I know of

Why are you here? For the tech? Then you should be off at Zcash instead of trying to con newbies into a coin that doesn't work. For the money? If you put your money in BTC or ETH you would have been better off. For the magical crypto friends? Monero leadership laughs from losers like that. Find yourself more healthy realationships that don't laugh at you when they steal your money.

Hey everyone, I'm pretty new to monero and would like to improve the project or the ecosystem around it. I'm a developer/sysadmin kind of guy, is there anything that comes to your mind could be improved?

Hi. What language(s) are you familiar with ?

Primarily C, I prefer system programming over high-level scripting langs

Does this extend to C++ ?

(Monero itself is C++)

Yeah, I know, I've worked only with a small subset of C++, don't really know the whole lang

I don't either.

(Not even Bjarne)

:D

I suggest using monero, and trying to fix little things that you find annoy you. By doing this, you start learning what's where, etc, in manageable steps.

Then you can start doing bigger things things. That's what I did.

The issues list on github may also give ideas.

Thanks. Monero seems pretty mature at this point, however I find monerod a little slow, I might take a look what its doing behind the scenes.

Systems programming... network ? I can think of a couple network things that would be nice to have: the ability to bind to a partcular NIC for outgoing comms.

Sure thing.

One thing it really needs is a rw lock to replace the blockchain mutex. But this needs experience with moenro first.

That mutex is held for long periods while syncing, which kills readers.

It's something I should do I guess. Someday.

<moneromooo "One thing it really needs is a r"> Is there a GH issue for this?

Binding to an interface would be really nice. Also I'm not sure why there are separate settings for ipv4 and ipv6. Thanks for the ideas.

Someone posted a patch, but it was interspersed with unrelated changes so never got in.

No issue.

Because it can use both at once I think.

I think it can be unified, the way it is now is kinda messy. I will take a look at it.

7624 should also be a good starter if you are familiar with boost program opts

In that area, there's a recent issue about making the different RPC ports configuration clearer and less ad hoc.

i'm looking for some example rust projects using the monero-rs crate

Try looking at the monero-ecosystem account on github, might have some.

ok, thank you

in particular i'm looking for integrated address generation

toor: github.com/monero-rs/monero-rs/blob/master/src/util/address.rs

yeh i've been looking at that

i am new to rust :)

everybody in the world is new to rust. it hasn't been around that long.

one thing i didn't understand from that source file was that impl Address::subaddress uses public_spend and public_view

i was able to get what i wanted using the cryptonode module and get_subaddress

but then i found that merchants should use integrated not subaddress

why should merchants use integrated addresses?

sounds like obsolete recommendation

integrated addresses are inferior, inferring the primary address is trivial

hmmm, ok, sounds possible

something to do with payment ids and not having to keep track of them

'Back to integrated addresses, note that embedded payment IDs are 64-bit. This means the space is large enough that one can simply generate them randomly and reliably assume uniqueness.'

my idea right now before i discovered integrated was to use a db and keep track of the index when generating subaddresses for each transaction

you would need that db anyway, to track which txn goes with which payment ID

i also liked this 'No private key is necessary to generate integrated address. In contrast, to generate a subaddress, one needs a private view key.'

<toor "my idea right now before i disco"> I think that's recommendation that used to be in the RPC docs, I think there's better ways to go about it.

virgildante[m]: ok, so i will continue with subaddress then

in addition i found no mention of it in the gui wallet

of what?

integrated / payment id

I guess it depends on the system you're integrating with, but subaddresses are superior, not sure if monero-rs is compatible with them

yea, it's not useful for a user

but sending to an integrated address works fine with GUI

subaddresses have superseded payment ids AFAICT

yeh, i just figured the gui wallet had everything conceivable

integrated address requires tx_extra, right? its essentially the same as payment ID ... ?

Yes.