09:38:05 <tevador> https://github.com/monero-project/monero/issues/6668
13:24:29 <tevador> Is there a particular reason why subaddresses have a different network byte? Does the sender need to know they are sending to a subaddress?
13:25:24 <moneromooo> Yes, the sender makes different crypto ops in that case.
13:25:27 <sarang> yes
13:26:37 <tevador> OK, thanks
15:15:36 <fluffypony> hyc: I was just thinking about your reply on that issue
15:15:58 <fluffypony> we don't allow things like null CT proofs
15:16:37 <fluffypony> so a soft fork to something like Bulletproofs+ would have to include the Bulletproof and then the Bulletproofs+ in tx_extra
15:41:11 <moneromooo> vtnerd: fyi: https://github.com/monero-project/monero/pull/6671  (you might have a better fix)
15:45:42 <moneromooo> I guess we might want to avoid that at some point if we add dandelion timeout functional tests.
19:56:04 <vtnerd> approved that PR. its a tricky one either wa
20:10:37 <niocbrrrrrr> as it was discussed a few days ago, when I send a dandelion++ tx it takes about 30 sec before it shows in an explorer vs <5 seconds before the update
20:24:05 <moneromooo> Wheeee. Looks like the timeout is 173 seconds on average. Lots more than I expected.
20:24:20 <moneromooo> So it looks like you're not hitting the timeout, but propagation is just slow...
20:29:50 <sarang> 30 sec seems quite long
20:53:23 <niocbrrrrrr> sarang: the first time was around that but didn't measure and the second time I did
20:54:26 <sarang> Is there any good data on this that isn't just one time cases?
20:55:03 <sarang> I'm not disputing claims it could be longer than expected, but having a broader data set would be useful to assess this
20:55:24 <niocbrrrrrr> I can do a unch of sweep_all
20:55:29 <niocbrrrrrr> a bunch
20:56:25 <niocbrrrrrr> should get better as more people update to ++
20:56:42 <niocbrrrrrr> any idea how many have updated?
20:58:04 <moneromooo> If Alice has not updated, she relays txes as normal, so it'd be faster.
21:41:59 <jtgrassie> xmrpow: yes