00:25:15 <derpy_bridge_> [keybase] <seddd>: How much of a concern are side-channel attacks? May I humbly suggest a constant-time switch for the ultra paranoid?
00:56:00 <sarang> That would likely require _significant_ restructuring
02:40:07 <derpy_bridge_> [keybase] <seddd>: Mb a long-term thing for next minor/major point release?
02:41:03 <derpy_bridge_> [keybase] <seddd>: If too much work for too little added protection, I understand. Would be willing to help w/ impl fwiw
02:45:47 <UkoeHB_> I think side-channel is only a threat to private information. There is no private information involved in validating blocks (or shouldn't be).
02:45:57 <derpy_bridge_> [keybase] <seddd>: Still going though the diffs, making headway. What is a good date for final review?
02:49:23 <derpy_bridge_> [keybase] <seddd>: UkoeHB_ only time it would concern private info iiuc is in tx recovery (includes at least pvt view key). Agreed non-constant-time doesn't seem like a huge thing in the validation context, but the proving side definitely involves long-term private info, and the variable time functions. Please correct me if I have misunderstood something
02:50:02 <UkoeHB_> Afaik constant-time is used on the proving side, and also wallet scanning side
02:51:04 <derpy_bridge_> [keybase] <seddd>: Hmm, then I must have missed something. Will pay close attention to he proving code on my next read-through
02:51:19 <derpy_bridge_> [keybase] <seddd>: the* proving
02:57:01 <selsta> seddd: https://github.com/monero-project/supercop/pull/3
02:57:42 <selsta> AFAIK this is constant time, but not merged yet.
03:44:55 <derpy_bridge> [keybase] <seddd>: selsta: ty, I definitely didn't see that
16:40:06 <sarang> Weekly meeting begins here at 17:00 UTC (about 20 minutes from now)
16:58:35 <sarang> OK, let's go ahead and get started
16:58:47 <sarang> The usual agenda: https://github.com/monero-project/meta/issues/451
16:58:50 <sarang> GREETINGS
16:59:00 <ArticMine> Hi
17:00:19 * sarang will wait a few moments
17:02:39 <Isthmus> Heya
17:02:48 <Isthmus> Sorry I fell asleep last week
17:02:57 <sarang> I'm feeling a bit under the weather today, so I'll try to keep things short and sweet if possible
17:03:02 <sarang> No problem Isthmus
17:03:06 <sarang> Let's move on to ROUNDTABLE
17:03:16 <sarang> My list is short but hopefully interesting
17:03:27 <sarang> The CLSAG preprint has been revised and updated on the IACR archive
17:03:38 <sarang> Link: https://eprint.iacr.org/2019/654
17:03:47 <sarang> New security model and proofs
17:04:06 <UkoeHB_> Oh hi forgot about this :p
17:04:20 <sarang> Alongside this, the code has been updated to make it easier to include trezor/ledger support
17:04:58 <sarang> Plumbing for device support: https://github.com/SarangNoether/monero/commit/94a7daad0f53074a28dbfb39c0ed1d68d5c40e86
17:05:16 <sarang> Support for ledger, courtesy of cslashm: https://github.com/SarangNoether/monero/pull/1
17:06:03 <sarang> Smaller items are proofreading for UkoeHB_'s Zero to Monero update, and finalizing a PR for hash function domain separation, along with the usual literature review
17:06:18 <sarang> Does anyone have particular questions, or otherwise have research of interest to share?
17:07:15 <sarang> I see that Isthmus has just added to the agenda issue
17:07:28 <Isthmus> https://user-images.githubusercontent.com/21246742/78165574-c14f9500-7408-11ea-8ae5-7d695b4321d3.png
17:08:17 <Isthmus> n3ptune and I have been exploring tx_extra some more
17:08:28 <sarang> neat
17:08:33 <Isthmus> A few months ago @UkoeHB_ suggested that the *ordering* of tags might leak some information
17:08:39 <Isthmus> This intuition turned out to be correct
17:09:33 <n3ptune> link to the issue: https://github.com/monero-project/research-lab/issues/61
17:10:04 <Isthmus> If we look at tx_extra in the wild since 1978433 (v12) we see 8 different ways that tags are assembled
17:11:05 <sarang> Enforcing an ordering and certain fields makes sense for uniformity; I wonder what the added time complexity would be for parsing overall
17:11:43 <sarang> This also ties in with an idea for Janus mitigation, which would enforce a per-transaction Janus transaction key and per-output tx pubkeys
17:11:58 <Isthmus> +1
17:12:12 <sarang> And, FWIW, there was a PR yesterday from moneromooo with an idea for an encrypted-memo-type addition to extra: https://github.com/monero-project/monero/pull/6410
17:12:16 <sarang> (I have concerns about that one)
17:13:28 <Isthmus> I would support encrypted memo if *length* and *inclusion* enforced in protocol. :- )
17:14:00 <Isthmus> Zcash has a 512 byte encrypted memo on all z2z transactions, and people are having a lot of fun with it
17:14:21 <Isthmus> (mostly whimsical fun at the moment, but I expect fun applications to follow)
17:14:22 <sarang> Of course, this seems to overlap in functionality somewhat with encrypted pIDs
17:14:40 <Isthmus> Oh yea, could just roll the PID into the memo
17:14:55 <sarang> But yes, I agree that if included, length should be enforced for uniformity
17:15:03 <Isthmus> Would it be per txn or per output?
17:15:10 <UkoeHB_> Im a bit skeptical about scope creep, since Monero is money, not random messages
17:15:11 <ArticMine> and kept small
17:15:26 <UkoeHB_> or email
17:16:06 <ArticMine> or a replacement for twitter
17:16:44 <sarang> AIUI that PR requires a single non-change output
17:16:50 <sarang> at least from my initial read of the code
17:17:45 <sarang> Its use in Zcash is per-output, I believe
17:18:11 <ArticMine> Can we actually do away with this messaging entirely?
17:18:19 <sarang> ?
17:18:21 <UkoeHB_> Isthmus's research indicates that even though the extra field is technically open ended, in practice people arent implementing random things
17:18:43 <UkoeHB_> supporting random messages with core code would directly lead to more random things in the chain
17:18:54 <Isthmus> Wait can we clarify "random"
17:19:03 <Isthmus> Do we mean a fixed tag that supports arbitrary payload
17:19:03 <UkoeHB_> non-standard
17:20:05 <UkoeHB_> I guess 'memo field' implies to me 'any random message you feel like'
17:20:37 <Isthmus> Ideally encrypted
17:20:51 <sarang> To clarify, this PR uses chacha to encrypt with the DH shared secret, including padding as needed to hit certain size resolution
17:20:58 <atoc> what are pros of including memo field?
17:21:10 <sarang> but it's not possible to enforce that the data are actually encrypted
17:21:31 <UkoeHB_> does chacha index each chunk in some way (so no two chunks are likely to be the same)?
17:21:36 <ArticMine> That is my question
17:21:39 <sarang> I think the goal was to enable encrypted recipient data as desired, to reduce the likelihood of non-standard inclusion of data in extra
17:21:58 <sarang> UkoeHB_: the chunks are appended before passing to chacha
17:22:14 <sarang> If I'm reading the PR correctly, the chunking is just to enforce size resolution
17:22:23 <Isthmus> From a technical/statistical info leak standpoint, we should either have *no* messages, or an encrypted message on *every* transactions. Which option we choose is partially a UX/design conversation.
17:22:47 <sarang> And at that point, you basically have a larger pID setup
17:22:56 <Isthmus> Yea
17:23:05 <sarang> Which was part of my concern
17:23:10 <Isthmus> Is there no way to mathematically verify that a field is encrypted?
17:23:47 <sarang> Not for the network AFAIK
17:23:58 <sarang> Nor is it possible in Zcash either
17:24:16 <sarang> It is possible to assure the _recipient_ that if they can decrypt properly, the data were encrypted as expected
17:24:30 <Isthmus> Ohhh yea that's how that works
17:24:41 <sarang> But otherwise, it's just uniformly distributed data
17:25:14 <UkoeHB_> I think that encryption or not isn't a concern, since implementers should want to harmonize with other implementations. The core impl would encrypt, so others would too
17:25:17 <ArticMine> All of this begs the question do we need this memo filed and even extra
17:25:23 <sarang> So the worst case in Zcash is that you throw a bunch of unencrypted junk into a tx that gets accepted by the network, but that the recipient won't properly decrypt
17:25:50 <Isthmus> " All of this begs the question do we need this memo filed and even extra" < I would be very happy to do away with both
17:26:04 <UkoeHB_> ArticMine: I think ultimately the extra field is useful when/if hard forks are no longer feasible.
17:26:27 <sarang> At the very least, enforcing ordering as UkoeHB_ listed in their issue would help a lot of this
17:26:41 <sarang> certainly not all cases though
17:26:51 <UkoeHB_> Imagine if Janus attack wasn't discovered until after hard forks stopped happening. We'd be in Bitcoin's situation of absolute chaos
17:27:39 <UkoeHB_> (i.e. if no extra field for wiggle room)
17:27:40 <ArticMine> How would extra help
17:27:54 <Isthmus> Geez, if that happened I think the issue is ossification
17:28:17 <UkoeHB_> wallets can implement janus mitigation on their own, since it's technically unverifiable anyway
17:29:06 <Isthmus> I'd like to proactively avoid a situation like that by keeping an agile codebase, not having an anything-goes tx_extra field
17:31:06 <Isthmus> Anyways, lots of different pros & cons to consider for each possibility
17:35:00 <sarang> The question at this point, I think, is to decide whether doing order enforcement (e.g. TLV) is something that a develop wishes to take on
17:35:25 <sarang> Which ties in to whether enforcement of a consistent Janus mitigation is desirable (I think yes, it is)
17:35:30 <UkoeHB_> After next gen tx protocol gets implemented, I imagine the stuff that can go in a hard fork will drop off quite a bit. Rather than losing the ability to make hard forks, we might just run out of hard forks to make. Once the expectation of making periodic hard forks fades away, subsequent hard forks will become much more difficult (also the case if adoption rises concurrently).
17:35:55 <sarang> Network upgrades also have the probable advantage of encouraging client upgrades
17:36:08 <Isthmus> Yeah "we might just run out of hard forks to make" is a different situation from encountering an issue (e.g. Janus) and not forking
17:36:10 <sarang> which provide other non-consensus fixes and benefits
17:36:40 <Isthmus> Regardless, let's separate the metadata question (should we enforce ordered TLV) from feature questions (should we have a memo field)
17:37:20 <sarang> Well, TLV enforcement has a big effect on non-standard data, since it requires a stated type
17:37:33 * Isthmus views this as a good thing
17:37:35 <UkoeHB_> I did make pseudo code for enforced sorted TLV, about 200lines
17:37:36 <sarang> yes
17:37:52 <sarang> But I mean that the features and the layout enforcement are closely intertwined here
17:38:02 <UkoeHB_> Current code already mostly does sorted tlv by default
17:38:38 <UkoeHB_> So all that needs to change is in tx validation
17:38:47 <Isthmus> 👍
17:39:01 <atoc> nice
17:39:15 <sarang> OK, so I think what should be brought up in -dev is a well-considered position for 3 things related to extra
17:39:25 <atoc> koe, what's your github
17:39:25 <sarang> 1. Decision on TLV enforcement, and responsibility for implementation
17:39:38 <sarang> 2. Decision on Janus mitigation, and implementation
17:39:49 <sarang> 3. Musings on the new encrypted-memo idea
17:40:13 <UkoeHB_> atoc https://github.com/monero-project/research-lab/issues/61
17:40:48 <sarang> My position is 1: yes, 2: yes, 3: not unless enforced uniformly (and then it runs up against ePIDs)
17:41:04 <Isthmus> 1: agree, 2: agree, 3: agree
17:41:28 <sarang> Anyway, good things to consider here
17:41:29 <gingeropolous> is the janus mitigation the thing with the subaddresses?
17:41:32 <sarang> Yes
17:41:49 <UkoeHB_> Janus https://github.com/monero-project/research-lab/issues/62
17:41:53 <sarang> Enforcing a mitigation has the added advantage of making the number of tx pubkeys uniform
17:42:02 <Isthmus> !!!
17:42:04 <Isthmus> yesplz
17:42:33 <gingeropolous> ima just throw it out there to play devils advocate, dunno if its been stated before. What about reverting to not having subaddresses?
17:42:38 <sarang> So you have one Janus-specific tx pubkey per transaction, and a separate additional pubkey per output
17:42:51 <fuwa> is it possible to replace tx extra completely with memo, so you don't need to sort anything
17:43:07 <sarang> You'd need to remove all non-recipient-specific data from memo
17:43:18 <sarang> Which IIRC moneromooo said would be a significant engineering effort
17:43:54 <sarang> Extra isn't an inherent problem if uniformity is reasonably enforced
17:44:06 <Isthmus> Oh, I was wondering something actually
17:44:24 <Isthmus> Suppose we decide that each transaction should contain X, Y, and Z
17:44:47 <UkoeHB_> gingeropolous: then Janus would no longer be a problem. That's about it afaik
17:44:58 <Isthmus> What's the performance difference between having 3 separate fields versus having 1 field with 3 enforced objects
17:45:31 <sarang> That's a good question, and I'm not sure
17:46:15 <gingeropolous> right. so i guess the underlying question is whether subaddresses are worth it.
17:46:34 <sarang> The scanning benefit is huge for large sets of addresses
17:46:56 <sarang> Hash lookups are much faster than doing multiple scans of all transactions per address
17:47:14 <sarang> and Janus checks are only needed for transactions that are already identified as being destined for you
17:47:22 <sarang> (and those checks are quite fast anyway)
17:47:46 <sarang> Also note that MLSAG -> CLSAG drops average tx size by 600 bytes already
17:48:03 <sarang> s/average/typical
17:48:42 <ArticMine> Like 2 in 2 out
17:49:07 <sarang> Yes, a 2-2 tx drops already from ~2.5 kB to ~1.9 kB
17:49:29 <sarang> So Janus mitigation adds something like about 64 bytes back in
17:49:37 <sarang> (more for multi-output)
17:49:53 <sarang> Meaning there's already plenty of wiggle room
17:50:15 <gingeropolous> well here's hoping its the last mitigation for subaddresses.
17:50:16 <atoc> that's a pretty good drop
17:52:18 <ArticMine> We can increase the ring size
17:52:43 <UkoeHB_> meeting is getting toward the end, so Ill add my update here: ztm2 should be ready to publish this weekend, I'm finishing up my last proofreading atm
17:53:08 <sarang> UkoeHB_: great!
17:53:12 <UkoeHB_> might take a bit for getmonero to update though, so we will see when I post about it
17:53:13 <atoc> koe - i sent you an email but to reiterate it's looking really good
17:53:25 <UkoeHB_> yeah saw that :)
17:53:27 <sarang> Since the hour is indeed almost up, does anyone else wish to share any topics of interest?
17:53:43 <Isthmus> https://www.reddit.com/r/Monero/comments/fnhm6u/maam_monero_ask_anything_monday_march_23_2020/flbbt45?utm_source=share&utm_medium=web2x
17:53:45 <Isthmus> ^ thoughts?
17:54:19 <Isthmus> I'm looking for projects for Fellows to work on, wondering if that seems like a good candidate
17:55:26 <sarang> That sounds like a question for -dev or -gui TBH!
17:55:31 <Isthmus> I could also have one of the software engineers implement ordered TLV if -dev wants somebody else to tackle it
17:55:37 <Isthmus> Oh yea, good point
17:56:17 <Isthmus> Any wish list projects for MRL? I have 2 software engineers, 1 mathematician, and some data scientists that are open to working on Monero stuff
17:56:30 <atoc> Isthmus this seems good. i am willing to help but probably can't commit too much atm
17:56:31 <sarang> Isthmus: perhaps pop over to -dev after meeting and let the channel know that a Fellow might be able to tackle TLV
17:56:35 <sarang> see what the responses are
17:56:57 <sarang> I bet moneromooo will have better knowledge of the effects that parsing would have on performance overall
17:57:06 <UkoeHB_> well this never got much traction but Im still a fan https://github.com/monero-project/research-lab/issues/59 could be a lot of work idk
17:57:40 <sarang> Isthmus: I know this important PR needed review... https://github.com/monero-project/supercop/pull/3
17:58:21 <sarang> and if any Fellows have sufficient interest, the new CLSAG security model in the paper could use some eyes
17:58:39 * Isthmus takes notes
17:59:10 <sarang> Anyway, let's start to wrap up
17:59:16 <ArticMine> I'll cover the fee, penalty and median proposal in the next meeting. By then I'll have most of this finalized
17:59:16 <sarang> Any ACTION ITEMS to share?
17:59:21 <sarang> Great ArticMine
17:59:56 <atoc> @sarang i'll probably ping you tomorrow to go over some zkp ideas for atomic swap
18:00:11 <sarang> I'll be doing some work on an older preprint, reviewing some ideas in a draft preprint that were sent to me by another researcher, and returning to some Triptych code
18:00:12 <UkoeHB_> there are two other big projects: fully-formed audit functionality, and extensive updates to multisig; mentioned those to TheCharlatan but they really are beasts I expect
18:00:23 <atoc> i have some resources i'd like to share
18:00:25 <sarang> for sure
18:00:42 <Isthmus> We can close up the meeting, but I'm curious later if anybody has speculation around what's going on with https://xmrchain.net/search?value=f6cff1edd1a7861ed13d494dd4ae7c4a7f42b5c3bf91457310d2166722c1316f
18:00:55 <Isthmus> It has an unknown tag type, and the length is recorded incorrectly
18:01:30 <UkoeHB_> are you sure it's a length and not a value byte?
18:02:00 <Isthmus> Not sure, that's why I'm asking
18:02:23 <sarang> All right, let's go ahead and adjourn for timing purposes, but discussions can of course continue
18:02:27 <sarang> Thanks to everyone for attending!
18:02:33 <sarang> Logs posted shortly on the GitHub agenda issue
18:02:57 <UkoeHB_> fee is weird too
18:03:45 <n3ptune> It breaks down like this: [tag 01][data 24485aaabc671f7d3069023c902109cf86fdd4c93fe65e042f25664c7118d260][tag 02][size 3e][data=fcaeccb51290c000c5c2748e017b2a02f58fbf97df4256d19bdaf54ab89944c7cc7b9db1ea9a3b614d7227b01b5b31d760323e23dec10b48675a70223c22][tag 0c]
18:04:35 <Isthmus> Yea, it's an odd transaction in a few ways
18:04:48 <n3ptune> 0c isn't a known tag and it doesn't have any size or data field either, so I think the 02 tag should be size 3F
18:05:09 <sgp_> sorry I didn't mean to miss this
18:05:12 <UkoeHB_> must be someone messing around who knows
18:09:00 <UkoeHB_> 0.002 is an old fee multiplier from v3, maybe an old implementation they are trying to bring back to life
18:09:40 <Isthmus> That wasn't the multiplier, the fee was 0.002 XMR absolute
18:10:56 <Isthmus> WOAH
18:11:09 <Isthmus> Oops didn't mean to all caps
18:11:31 <Isthmus> One of the ring members in that transaction is https://xmrchain.net/tx/3a2b02458c51b7f434212112a79af7544033362e4e904fc2993f87abcf356f8c
18:11:48 <Isthmus> Ha wait, nvm
18:11:53 <UkoeHB_> all the ring members are really old
18:12:53 <Isthmus> Oh yea, so it exhibits (1) anomalous tx_extra, (2) hardcoded fee, (3) unusual decoy selection algorithm
18:18:34 <Isthmus> Are there any more easter eggs in this txn?
18:27:03 <moneromooo> There is not much non recipient specific data in extra. Mostly the tx key. Easy to store separately.
18:27:46 <UkoeHB_> found something a bit weird
18:28:45 <moneromooo> Parsing extra should be very light performance wise.
18:28:58 <UkoeHB_> the 1/6 in/out ring member is a subaddress tx, and has as ring member a 1/11 ring member which is also a subaddress tx, and that one too has a 1/11 ring member, and so on quite far back
18:30:37 <sarang> moneromooo: the primary discussion, aside from Janus mitigation, was whether TLV makes sense from an engineering and performance perspective
18:30:55 <sarang> Isthmus et al.'s investigation found that enforcing order would remove some fingerprinting
18:31:13 <UkoeHB_> they go back to around march 2019 when a bunch of 1/11 tx appeared, and all reference each other
18:31:18 <UkoeHB_> some kind of churning?
18:31:43 <moneromooo> I'm not getting into that again. I still think it's pointless. You can stuff anything (including unsorted things) into something that matches your TLV structure. It just moves the problem one layer down.
18:32:41 <UkoeHB_> there is a difference between what is theoretically possible, and what we can practically expect from people
18:34:04 <UkoeHB_> case in point: as Isthmus found, barely anyone puts non-standard things in the tx extra field
18:34:12 <UkoeHB_> non-miners/pools anyway
18:35:39 <UkoeHB_> but, amongst those standard implementations, there are variations since there are multiple 'base configurations'
18:37:13 <Isthmus> Please remember that enforcing ordering and enforcing contents are two *different* issues, and counterarguments for the latter are not applicable to the former.
18:37:15 <Isthmus> Here is a concrete example:
18:37:24 <Isthmus> In the last few months, we have had 473507 transactions with pubkeys followed by encrypted PID.
18:37:26 <Isthmus> These are distinguishable from the 36384 transactions with encrypted PID followed by pubkeys.
18:37:36 <Isthmus> (differentiated only by the ordering leaking non-standard software)
18:37:45 <Isthmus> Enforcing ordering would make these 509891 indistinguishable transactions
18:38:16 <sarang> ^
18:50:08 <UkoeHB_> moneromooo: what would be the cons of enforcing sorted TLV? My thought is, while the benefits may be debatable, at worst we have wasted some time.
18:52:14 <sarang> Isthmus had also suggested an Insight Fellow might be interested/willing to do it
18:52:40 <sarang> But there's little point in doing so unless there's enough consensus to accept such work in a network upgrade
19:00:52 <moneromooo> It feels wrong to me. It's supposed to be freeform (though some form is needed by wallets).
19:01:24 <moneromooo> If it's only me not liking it, it can go in. I'd much rather move the canonical stuff out of extra though.
19:02:05 <moneromooo> It has all the advantages of "enforced TLV" and does not have the ickiness that comes with it of something half baked (my opinion only).
19:03:26 <moneromooo> (all the advantages except maybe saving 32 bytes if someone doesn't want a tx key, but this is also a con (distinguishability)).
19:05:35 <sarang> TBH simply moving all standard/enforced items out of extra seems entirely reasonable, and a much cleaner approach overall
19:05:38 <Isthmus> ^ I agree with mooo on implementation (designated fields for required features)
19:05:58 <sarang> As to tx pubkeys, the proposed Janus mitigation would/should/could require tx pubkeys for all outputs (and an extra Janus key)
19:06:05 <UkoeHB_> I am also fine without moving certain common items out of the field.
19:06:37 <sarang> UkoeHB_: s/without/with ?
19:06:44 <UkoeHB_> with
19:06:58 <sarang> Heh, we need that substitution bot in here =p
19:07:15 <sarang> (if you do a s/old/new in community, it'll repost the fixed comment for you!)
19:07:59 <UkoeHB_> Even if that is done though, I still think sorted TLV is valuable. Enforced TLV makes it easier for wallets to coordinate on adding new kinds of features, and also makes it easier for them to ignore features they don't care about. Parsing TLV is very easy
19:08:46 <sarang> The ability to do such coordination of non-standard features is, however, bad for uniformity in theory
19:08:59 <UkoeHB_> and if they are allowed to add new things, might as well have some kind of expectations about uniformity
19:09:15 <sarang> You still get fingerprinting with that
19:09:18 <sarang> depending on adoption
19:09:31 <UkoeHB_> yes but less fingerprinting than what we have
19:10:01 <sarang> At the very least, enforcing order via serialization with set fields would be a huge benefit
19:10:02 <UkoeHB_> if we have this extra field thing, what's the best we can do? imo, enforced sorted tlv
19:23:48 <Isthmus> Just had a funny shower thought about PIDs but have to run into a meeting !RemindMe 3 hours
19:25:15 <luigi1111w> what is tlv?
19:25:35 <UkoeHB_> type-length-value
19:26:14 <luigi1111w> thanks
20:10:54 <needbrrrrrrr90> Sarang: if you want monerobux in here you'll need to keep people from using price commands :p
20:11:14 <needbrrrrrrr90> But jwinterm would be happy to add it if you want sed replace, I'm sure
20:12:56 <sarang> Oooh
20:13:04 <sarang> having sed replace and UTC timing would be excellent
20:13:10 <sarang> Probably other features that I don't know about too
20:13:22 <sarang> PR notifications, maybe?
20:13:24 <needbrrrrrrr90> Invite monerobux
20:13:30 <needbrrrrrrr90> You're an admin
20:13:32 <needbrrrrrrr90> Add to room
20:13:41 <jwinterm> it doesn't do PR notifications now
20:13:42 <sarang> here goes nothing
20:13:43 <needbrrrrrrr90> Test
20:13:49 <needbrrrrrrr90> s/test/yay
20:13:52 <jwinterm> it does have some meeting logging capability
20:13:53 <sarang> Oh, that must be a different bot (I didn't really pay attention to bot names)
20:13:56 <needbrrrrrrr90> s/Tear/yay
20:13:59 <needbrrrrrrr90> Oof
20:14:01 <needbrrrrrrr90> Damn mobile
20:14:01 <UkoeHB_> .usd
20:14:02 <monerobux> Monero price in USD = $47.04
20:14:05 <needbrrrrrrr90> Noooooo
20:14:06 <sarang> This room is already publicly logged (see topic)
20:14:06 <jwinterm> .ban UkoeHB_
20:14:06 <monerobux> You are not a channel operator.
20:14:23 <sarang> But yeah, would be nice to only have applicable features
20:14:25 <UkoeHB_> well it works :p
20:14:27 <sarang> like timing and sed
20:14:28 <needbrrrrrrr90> Okay let's try it again
20:14:29 <sarang> .time
20:14:29 <monerobux> 2020-04-01 - 20:14:29
20:14:34 <needbrrrrrrr90> s/again/now?
20:14:34 <monerobux> needbrrrrrrr90 meant to say: Okay let's try it now?
20:14:54 <sarang> Lemme try
20:14:55 <needbrrrrrrr90> Monerobux hardest worker in ecosystem
20:15:00 <sarang> Pineapple on pizza is great
20:15:04 <sarang> s/great/terrible
20:15:04 <monerobux> sarang meant to say: Pineapple on pizza is terrible
20:15:09 <sarang> good bot
20:15:12 <jwinterm> not sure if I can limit per channel commands, but sed and time module are just part of default sopel bot
20:15:23 <jwinterm> so you could spin up fresh sopel bot instance for this channel
20:15:31 <jwinterm> s/you/me or anyone
20:15:32 <monerobux> jwinterm meant to say: so me or anyone could spin up fresh sopel bot instance for this channel
20:15:38 <sarang> I suppose we can just leave this one as-is, and just remove if it gets misused
20:15:46 <sarang> How does it log the channel?
20:16:11 <sarang> The topic statement and link to logs should be sufficient to notify people that this happens already (and of course, anyone can log with their client anyway)
20:16:19 <jwinterm> I believe it logs everything, but you can set it up to do meetings and then I can host logs on webserver
20:16:25 <jwinterm> .meeting start
20:16:29 <jwinterm> something like that
20:16:31 <jwinterm> I forget
20:16:32 <sarang> Oh, no need
20:16:32 <jwinterm> brb
20:16:42 <sarang> I put meeting logs on the github issues; it only takes a few minutes to do
21:01:29 <sarang> FYI may be unavailable tomorrow; have been feeling under the weather today
21:05:05 <niocbrrrrrr> sarang: hope you feel better soon
21:05:52 <sarang> Thanks; I'm sure it's nothing of consequence
23:48:45 <Isthmus> Oh yea, so I was thinking about encrypted versus unencrypted PIDs earlier. (right now both in use - 10% of txns have uPID, 83% of txns have an ePID, some have neither)
23:48:50 <Isthmus> As many have pointed out - encryption cannot be verified by an outside observer. From an information content perspective, a PID tag provides contains two pieces of information:
23:49:00 <Isthmus> (1) The PID itself (whose encryption or lack there of cannot be verified)
23:49:05 <Isthmus> (2) A flag to mark whether #1 is encrypted or unencrypted
23:49:47 <Isthmus> The second piece of information is self-reported on the honor system, could be a lie, and can’t be verified. In practice, it’s not a u/e flag, it’s a [core software]/[custom software] flag (useful mainly for transaction tree analysis)
23:49:52 <Isthmus> If we do move required features/keys out of tx_extra, it’ll be nice to have just a single PID field that is officially handled as encrypted. :- )
23:50:00 <Isthmus> Then if two users (sender & receiver) decide that they’re both going to flaunt core recommendations and use custom software that puts a plaintext ID in there I can’t stop them and I can’t prove it. (As opposed to now when it is literally declared to every blockchain observer)
23:50:08 <Isthmus> It’s a nice silver lining, to remove 1 of the 2 pieces of information.
23:51:30 <moneromooo> When you say right now, you mean when exactly ?
23:51:56 <moneromooo> There are still people using long pids now that support was taken out ? 10% sounds grossly wtf...
23:53:38 <selsta> AFAIK all wallets have taken out support for long PIDs