04:04:46 <cjac> o/
04:15:11 -xmr-pr- cjac opened pull request #8673: removed unused refreshed bool
04:15:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8673
04:17:38 <cjac> they're watching what I'm doing.
05:55:24 <Guest43> Hi, kinda new here - is there a way to join the public testnet if there is one?
06:26:16 <Guest43> Or is there a way to test monero - well specifically dandelion++
07:28:32 <hyc> run monerod --testnet, boom you're there
12:26:37 <woodser[m]1> can someone kindly kick off the workflows for https://github.com/monero-project/monero/pull/8665 ?
13:00:11 -xmr-pr- MuzuWeb opened issue #8674: Compilation takes a very long time on raspberry pi zero w
13:00:11 -xmr-pr- > https://github.com/monero-project/monero/issues/8674
13:30:48 <gingeropolous> ""Couldn't open wallet: internal error: failed to deserialize keys buffer"" . https://old.reddit.com/r/monerosupport/comments/ziqcqf/cant_import_keys_file_to_gui_wallet/ . any ideas?
13:54:40 <hyc> only thing comes to mind is version incompatiblity, or wrong password
13:54:51 <hyc> but both of those have already been mentioned in that post
14:22:27 <xfedex[m]> I came up with a possible way to create much shorter Monero address, which would be especially useful for Seraphis-Jamptis, and would allow customized addresses.
14:22:28 <xfedex[m]> Basically, once you have a wallet with some coins in it, you send a special "TX" to the blockchain, which doesn't move money (apart from fees required). That TX would contain the full actual address, and an alias.
14:22:28 <xfedex[m]> This system would allow the creation of custom human-readable addresses.
14:23:50 <hyc> do you then expect the consensus software to prevent duplicate aliases?
14:24:08 <hyc> we already have OpenAlias ...
14:24:25 <xfedex[m]> hyc: Exactly
14:24:52 <xfedex[m]> hyc: OpenAlias is centralized and not trustless. DNS controls OpenAlias addresses
14:25:24 <xfedex[m]> xfedex[m]: Or just ignore them
14:27:57 <hyc> ignoring them would be bad, since allowing duplicates to accumulate in the chain would make it harder to actually look up the correct one to use
14:29:04 <hyc> The advantage of OpenAlias using DNS is that it's an inherently hierarchical namespace, which pretty much eliminates the possibility of collisions / duplicates
14:31:42 <hyc> with your scheme, there's nothing to prevent squatters from registering well known names before their real users do
14:32:07 <xfedex[m]> hyc: Not sure, but I think it's the same on Ethereum Name System
14:32:39 <gingeropolous> well...
14:32:43 <hyc> s/squatters/scammers/ in this case
14:34:17 <xfedex[m]> What if instead of including a custom name for address, you include in the tx the first 20 bytes of the address' keccak hash? Addresses would be shorter without the danger of "name stealing"
14:36:41 <DataHoarder> OpenAlias is neat, shame .onion doesn't have the ability for tagging arbitrary records on top
15:04:28 <UkoeHB> xfedex[m]: that would not work with monero's privacy tech (specifically the proofs we need for tx inputs)
15:05:41 <xfedex[m]> UkoeHB: I think you misunderstood what I meant. Once you have a wallet with some coins in it, you send a special "TX" to the blockchain, which doesn't move money (apart from fees required). That TX would contain the full actual address, and its 20-bytes hash.
15:06:28 <xfedex[m]> Any node can thus know that the 20-byte hash translates to the address, and sender node can translate that hash into actual address before sending
15:07:19 <UkoeHB> monero uses onetime addresses, which are masked user addresses (unique per enote onchain)
15:08:52 <xfedex[m]> I know, in fact the 20-byte hash address would not go on-chain
15:10:08 <UkoeHB> we also have subaddresses
15:10:40 <UkoeHB> doesnt seem practical to record all users subaddresses in the chain
15:12:01 <xfedex[m]> Yes, in fact only main wallet address would get stored. 
15:12:06 <UkoeHB> why
15:12:48 <UkoeHB> the goal of subaddresses is to reduce address reuse
15:12:51 <xfedex[m]> Another way I just thought of: instead of storing the "addresshash>address" on the blockchain, it could be stored on IPFS
15:13:21 <xfedex[m]> on IPFS, fees would be zero, so subaddresses could be shortened too
15:13:23 <UkoeHB> that would probably be more appropriate than on the monero chain
15:18:24 <hyc> advertising a fixed address would be ok for some things, like donation addresses I suppose
15:19:09 <hyc> really the same usecases as OpenAlias
16:07:02 <rbrunner> xfedex[m]: "OpenAlias is centralized and not trustless. DNS controls OpenAlias addresses"
16:07:44 <rbrunner> I don't understand. DNS is not centralized. I ran my own DNS server for years, and I was free to set up whatever second-level domain I wanted
16:17:24 <Stnby[m]> <rbrunner> "I don't understand. DNS is not..." <- DNS is not centralised but the control is in your governments hands.
16:19:30 <rbrunner> Sure. A case of finding the lesser evil. On the one side, the Swiss government that, in theory, could snuff out my domain
16:20:03 <rbrunner> On the other hand mechanisms like IPFS with potentially grave spam problems, duplicates without clear resolution, and other niceties
16:21:55 <rbrunner> Or bloating our blockchain with non-fungible / recognizable name-setting transactions.
17:03:23 <rbrunner> I just saw that DNX TXT entries can have a length of up to 255 characters without any special measures.
17:03:44 <rbrunner> So we are probably good with 200 character Jamtis addresses and OpenAlias
17:04:00 <rbrunner> *DNS
17:09:11 <DataHoarder> OpenAlias uses a bit more glue, for example, you need "oa1:xmr recipient_address=" at the start, and maybe "; recipient_name=[...]" afterwards
17:09:36 <DataHoarder> that is another 43 characters
17:09:58 <DataHoarder> which leaves just 12 characters for recipient_name
17:10:18 <hyc> why would you bother with recipient_name ?
17:11:02 <hyc> you already have foo.sub.domain
17:17:28 <DataHoarder> you can have it contain the whole character set
17:17:29 <DataHoarder> > At a minimum, the recipient_address key-value must exist.
17:17:52 <DataHoarder> that is what you need, but if you want to say for example "Project ABC Donations 🐱"
17:18:18 <DataHoarder> there are also further keys, anyhow
17:18:38 <DataHoarder> tx_description / tx_payment_id / tx_amount / address_signature / checksum
17:19:29 <DataHoarder> but that would probably also grow too large even with old address scheme
17:21:13 <DataHoarder> that said those keys seem overly verbose
17:22:05 <DataHoarder> well, if it goes over 255, that's just multiple strings in most cases in the response
18:28:26 <cjac> hi folks, could I get a LGTM for https://github.com/monero-project/monero/pull/8673 ?
18:29:04 <cjac> selsta: the FTBFS came from particularly strict gcc flags
18:29:34 <cjac> this is the debian policy, so it's keeping debian from building.  I could commit this patch to debian, but I wanted to check with you folks first.
18:30:21 <cjac> https://paste.debian.net/1263691/
18:52:16 <selsta> cjac: where did you add this GCC flag? and why does it cause the compiler to get killed?
18:54:07 <selsta> if you add some kind of "treat warnings as errors" flag it wouldn't kill the compiler as far as i'm aware
19:30:11 -xmr-pr- SChernykh opened pull request #8675: RingCT cache (huge block propagation speedup)
19:30:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8675
19:45:11 -xmr-pr- SChernykh opened pull request #8676: RingCT cache (huge block propagation speedup) [release-v0.18]
19:45:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8676
20:21:42 <jtgrassie> cjac: "this is the debian policy, so it's keeping debian from building." <- package maintainers are free t use whatever compiler options they like
20:22:22 <jtgrassie> you're only highlighting a warning, not an error
21:36:05 <cjac> jtgrassie, selsta: no problem.  I can patch the debian package, but our policy is to try to offer upstream first.  If you don't want this patch, no worries.