01:34:17 <vnkctqssufvu> Look on the bright side. At least you don't need to obsess over signs of life from FUK now.
04:47:07 <endogenic> https://github.com/zhuowei/nft_ptr
04:47:16 <endogenic> oops wrong chan
11:09:59 <woodser> why doesn't 0.17.2.0 include longstanding prs on master, like 6986, 7074, and 7422?
11:16:02 <moneromooo> 7074 looks like a bug fix. Did you PR it to the branch ?
11:16:13 <moneromooo> The others aren't AFAICT. Am I wrong ?
11:34:59 <woodser> 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?
11:35:34 <sech1> You need to make another PR to the branch
11:35:38 <sech1> It's not automated
11:36:25 <woodser> to what branch?
11:37:43 <woodser> release-v0.17 ?
11:39:54 <sech1> yes
11:45:09 <woodser> should non-bug fixes also be PRd to the branch manually, or do they wait until the next release branch is available?
12:00:32 <moneromooo> The latter.
13:31:05 <selsta> woodser: if you PR the bug fix to release-v0.17 now we can include it in the next release
13:39:01 <woodser_> ok
19:02:35 <moneroist> is CLSAG implemented last year incompatible with DLSAG?
19:04:11 <sethsimmons> What do you mean by compatible?
19:04:20 <sethsimmons> They are different approaches and not used concurrently.
19:06:33 <fluffypony> hence the hard fork
19:10:14 <moneromooo> I doubt the change from MLSAG to CLSAG invalidates the approach as the approaches are very similar AFAIK.
19:12:03 <moneroist> because as far I know after implementing DLSAG there would be open way to implement payments channel
19:12:39 <moneroist> but if now there is CLSAG we need new approach for payment channels right?
19:16:29 <sethsimmons> 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.
19:16:52 <sethsimmons> IIRC an approach to payment channels was possible on CLSAG, though...
19:18:52 <moneroist> I can not find any information about that, there is research about Payment Channels but need first DLSAG be implemented
19:19:25 <sethsimmons> https://eprint.iacr.org/2020/1441.pdf
19:19:28 <sethsimmons> Does not rely on DLSAG
19:19:46 <sethsimmons> "PayMo does not require any modification of Monero and can be readily used to perform off-chain payments"
19:20:37 <moneroist> https://www.youtube.com/watch?v=x4q38ndnQnw
19:20:56 <moneroist> this is the same?
19:26:21 <sethsimmons> No
19:27:01 <sarang> 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
19:27:18 <sarang> It would also not remove the tracing issue that DLSAG has (requiring self-spends to mitigate)
19:27:55 <moneroist> Yes I am aware that DLSAG was drawbacks like tracing issues
19:27:58 <moneroist> Thanks for infomration
19:28:33 <sarang> It would be interesting to see the CLSAG approach worked up in detail for DLSAG to confirm its applicability
19:28:44 <p3rL> .pap trx
19:28:47 <p3rL> ops
19:43:59 <cornfeedhobo> is i2p packaging still underway?
19:45:03 <hyc> I think i2p-zero is the result of i2p packaginmg
19:48:52 <cornfeedhobo> indeed. last I checked in, that was still in the works. is that out now?
19:50:56 <sethsimmons> It's been out for quite a while.
19:51:09 <sethsimmons> https://github.com/i2p-zero/i2p-zero
19:55:15 <nikg83[m]> Any plans for i2p/tor integration into gui/cli package
19:55:34 <nikg83[m]> * Any plans for i2p/tor integration into gui/cli package ?
19:55:41 <sethsimmons> They both integrate quite easily so not sure a bundling makes a lot of sense.
19:55:54 <sethsimmons> That introduces another dep to keep track of and increases package sizes for all users.
19:55:55 <selsta> I think the most realistic will be Tor with GUI
19:56:07 <selsta> but for CLI users it should be easy to setup without bundling
19:56:34 <sethsimmons> It's certainly doable but not sure it's warranted with how easy it is to install Tor in most distros
19:57:23 <nikg83[m]> 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
20:07:14 <kzv> Hi. Where is monero genesis?
20:11:12 <luigi1111w> https://github.com/monero-project/monero/blob/master/src/cryptonote_config.h#L216
20:13:33 <kzv> @luigi1111w thank you! Is there any docs how to create new genesis block?
20:14:04 <luigi1111w> not that I know of
20:51:06 <lbbyeilhu> 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.
21:13:04 <Pepin[m]> 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?
21:14:51 <moneromooo> Hi. What language(s) are you familiar with ?
21:16:58 <Pepin[m]> Primarily C, I prefer system programming over high-level scripting langs
21:17:27 <moneromooo> Does this extend to C++ ?
21:17:54 <moneromooo> (Monero itself is C++)
21:18:32 <Pepin[m]> Yeah, I know, I've worked only with a small subset of C++, don't really know the whole lang
21:18:48 <moneromooo> I don't either.
21:19:03 <virgildante[m]> (Not even Bjarne)
21:19:23 <Pepin[m]> :D
21:19:29 <moneromooo> 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.
21:20:49 <moneromooo> Then you can start doing bigger things things. That's what I did.
21:21:09 <moneromooo> The issues list on github may also give ideas.
21:22:12 <Pepin[m]> 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.
21:22:18 <moneromooo> 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.
21:22:27 <moneromooo> Sure thing.
21:23:04 <moneromooo> One thing it really needs is a rw lock to replace the blockchain mutex. But this needs experience with moenro first.
21:23:26 <moneromooo> That mutex is held for long periods while syncing, which kills readers.
21:23:48 <moneromooo> It's something I should do I guess. Someday.
21:24:32 <virgildante[m]> <moneromooo "One thing it really needs is a r"> Is there a GH issue for this?
21:24:32 <Pepin[m]> 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.
21:24:57 <moneromooo> Someone posted a patch, but it was interspersed with unrelated changes so never got in.
21:25:00 <moneromooo> No issue.
21:25:17 <moneromooo> Because it can use both at once I think.
21:26:59 <Pepin[m]> I think it can be unified, the way it is now is kinda messy. I will take a look at it.
21:27:55 <virgildante[m]> 7624 should also be a good starter if you are familiar with boost program opts
21:28:20 <moneromooo> In that area, there's a recent issue about making the different RPC ports configuration clearer and less ad hoc.
21:53:09 <toor> i'm looking for some example rust projects using the monero-rs crate
21:54:51 <moneromooo> Try looking at the monero-ecosystem account on github, might have some.
21:55:03 <toor> ok, thank you
21:55:18 <toor> in particular i'm looking for integrated address generation
21:59:39 <virgildante[m]> toor: https://github.com/monero-rs/monero-rs/blob/master/src/util/address.rs
22:02:03 <toor> yeh i've been looking at that
22:02:09 <toor> i am new to rust :)
22:02:48 <hyc> everybody in the world is new to rust. it hasn't been around that long.
22:03:10 <toor> one thing i didn't understand from that source file was that impl Address::subaddress uses public_spend and public_view
22:03:28 <toor> i was able to get what i wanted using the cryptonode module and get_subaddress
22:03:45 <toor> but then i found that merchants should use integrated not subaddress
22:04:00 <selsta> why should merchants use integrated addresses?
22:04:12 <hyc> sounds like obsolete recommendation
22:04:20 <virgildante[m]> integrated addresses are inferior, inferring the primary address is trivial
22:04:25 <toor> hmmm, ok, sounds possible
22:04:43 <toor> something to do with payment ids and not having to keep track of them
22:05:05 <toor> https://monerodocs.org/public-address/integrated-address/
22:05:45 <toor> '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.'
22:06:20 <toor> 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
22:06:53 <hyc> you would need that db anyway, to track which txn goes with which payment ID
22:06:54 <toor> 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.'
22:07:04 <virgildante[m]> <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.
22:07:34 <toor> virgildante[m]: ok, so i will continue with subaddress then
22:07:49 <toor> in addition i found no mention of it in the gui wallet
22:08:01 <selsta> of what?
22:08:08 <toor> integrated / payment id
22:08:12 <virgildante[m]> I guess it depends on the system you're integrating with, but subaddresses are superior, not sure if monero-rs is compatible with them
22:08:16 <selsta> yea, it's not useful for a user
22:08:24 <selsta> but sending to an integrated address works fine with GUI
22:08:28 <virgildante[m]> subaddresses have superseded payment ids AFAICT
22:08:39 <toor> yeh, i just figured the gui wallet had everything conceivable
22:56:06 <gingeropolous> integrated address requires tx_extra, right? its essentially the same as payment ID ... ?
22:57:21 <moneromooo> Yes.