07:33:30 <ArticMine> I updated https://github.com/monero-project/research-lab/issues/70 with may recommendations to address this issue
08:28:13 <geonic> thanks h4sh3d[m], grateful for your contribution and looking forward to the review process :)
14:59:38 <sarang> Hello all
15:00:08 <sarang> Finally online today... had to rebuild a Linux environment after it broke :/
15:33:44 <sgp_> ArticMine: really great stuff
15:35:14 <sgp_> you too UkoeHB_
16:05:07 <sethsimmons> Really cool to see such detailed, low-level discussion happening to make sure we're prepared well in advance of potential network events
16:05:39 <sethsimmons> Awesome work to all involved, the fee market + block size in Monero is one of the lesser recognized, but extremely important developments spearheaded by Monero.
16:05:44 <sethsimmons> *along with tail emission to make both work
16:48:37 <sarang> Meeting here starts at 17:00 UTC (about 10 minutes from now)
16:48:40 <sarang> .time
16:48:40 <monerobux> 2020-08-05 - 16:48:40
16:59:12 <sarang> OK, let's get started with the meeting
16:59:13 <sarang> GREETINGS
16:59:16 <sarang> hello
16:59:30 <ArticMine> Hi
17:00:44 * needmoney90 realizes a meeting is happening 
17:01:49 <needmoney90> Is this thing on?
17:01:52 * needmoney90 taps mic 
17:02:09 <n3ptune> Hello
17:02:31 <sarang> Let's move to ROUNDTABLE, where anyone can share research of interest with the channel
17:02:42 <ArticMine> Well I will start
17:03:19 * Isthmus waves
17:03:29 <ArticMine> My main contribution is on https://github.com/monero-project/research-lab/issues/70
17:04:18 <sarang> Yes, it looks like some recommendations for fees and block growth
17:04:26 <sarang> UkoeHB_ also responded to it with questions
17:04:45 <ArticMine> It deals with ah issue that is actually very serious once the block growth grows significantly
17:04:57 <Isthmus> I haven't yet read in depth enough to comment, but can tell that this is very detailed/thoughtful work - thanks for contributing this pretty hefty analysis
17:05:53 <sgp_> hello
17:06:10 <ArticMine> I will be talking about this also at Defcon on Friday
17:06:16 <sgp_> I second Isthmus's comment
17:06:21 <sgp_> ArticMine: awesome
17:06:43 <ArticMine> At this point what I need of course is review and feedback
17:06:48 <sarang> right
17:06:53 <ArticMine> thanks sgp_
17:07:08 <sarang> I assume that it is not your intent to get this into the October upgrade ArticMine?
17:07:15 <sarang> The code freeze for that is August 17
17:07:29 <sgp_> speaking of that, did the janus mitigation stuff make it?
17:07:49 <sarang> nope
17:07:57 <sgp_> darn
17:08:15 <ArticMine> It is very tight for the October 17 upgrade
17:08:17 <sarang> There are a few approaches, and not enough broad agreement about choosing one
17:08:22 <sarang> ArticMine: I would not go for it
17:08:39 <sarang> Next upgrade could include fee/block update, transaction structure if desired, etc.
17:09:44 <ArticMine> The best alternative is to do nothing with respect to fees / scaling at this fork and keep the current reference transaction size etc.
17:10:14 <sarang> Even with the CLSAG transaction size change?
17:10:44 <ArticMine> There is no problem leaving things as they are
17:10:50 <sarang> Which drops the transaction size by 32*(N-1) bytes per spent input, at ring size N
17:10:55 <ArticMine> The other option can be a partial implementation
17:11:33 <ArticMine> The drop is from ~2600 to ~2000 bytes over all for a 2 in 2 out tx
17:11:45 <sarang> 2.5 kB to 1.9 kB for 2-2
17:12:17 <ArticMine> So the fees will still drop.
17:12:43 <sarang> I noticed you also commented on sgp_'s coinbase idea ArticMine
17:12:53 <sgp_> is it okay if the fees drop? honesty fees seem super low already
17:13:06 <ArticMine> Yes this is where it gats a bit interesting
17:13:33 <ArticMine> If the response is to increase the ring size to mitigate this
17:13:54 <sgp_> "If the selection is algorithm is weighted towards current transactions then one would expect at most about 5% of compromised coinbase outputs in a ring" I don't think this is correct
17:14:06 <sgp_> it's closer to 20%
17:14:17 <Isthmus> "If the response is to increase the ring size to mitigate this" :- D
17:14:52 <ArticMine> It is also the reason I provided a second option where the reference tx is basically the same
17:15:11 <ArticMine> SO it can accommodate a ring size increase
17:15:23 <Isthmus> "Sorry everybody Monero got too efficient, so we had to add some extra privacy to round things out" 😅
17:15:38 <sgp_> Isthmus: lmao hilarious
17:15:54 <sgp_> transactions were so tiny we just HAD to improve privacy, sorry all
17:16:31 <ArticMine> My 5% figure came from using current tx data. If one takes tx data from a year ago the results are very different
17:16:31 <UkoeHB_> the fee stuff is not time sensitive (we need a lot more tx volume for it to be serious) so I feel it's safe to hold off one hardfork
17:16:32 <sgp_> ArticMine: I don't agree with your assessment, but it's probably not worth discussing before my Defcon talk
17:16:32 <sarang> FWIW increasing ringsize 12-13 would put verification where it is right now
17:16:57 <ArticMine> The best place is to comment on the issue in response
17:17:44 <sgp_> ArticMine: I get that, but I have nothing to add now before the talk
17:18:13 <sarang> OK, anything else to discuss presently ArticMine?
17:18:44 <ArticMine> No that is a good summary. Thanks
17:18:53 <sarang> Thanks ArticMine
17:19:00 <ArticMine> You are welcome
17:19:05 <sarang> Isthmus: you had something on the agenda issue
17:19:27 <Isthmus> Ah yea, just some quick notes
17:19:30 <sgp_> just to be clear: we are deciding we do not need to make a decision on ringsize and transaction size/fees for this month?
17:19:49 * Isthmus pauses
17:19:52 <sarang> Unless there is a compelling reason, I do not think increasing the ring size for October should be done
17:20:13 <sarang> and big changes to fee/size so quickly seems unwise
17:20:54 <ArticMine> I am neutral on the ring size question. I will wait for sgp_ 's talk first
17:21:33 <ArticMine> ... but I do agree it is getting very close for the October fork
17:21:42 <sarang> Note that it was repeatedly stated that transaction size _will_ go down
17:22:11 <sgp_> my vote is no unless it's critical
17:22:52 <sarang> OK, Isthmus?
17:23:05 <Isthmus> We drew up a rough schematic of how an outside observer with a quantum computer could might approach systematic deanonymization of the blockchain without participating in any transactions:
17:23:11 <Isthmus> https://usercontent.irccloud-cdn.com/file/Dp8NjuDw/image.png
17:23:26 <sarang> What assumes a candidate destination address suspected by the attacker?
17:23:33 <sgp_> Isthmus: ooooooh can we share?
17:23:53 <Isthmus> sgp_: where
17:24:11 <sarang> sgp_: without a ton of context, people might freak out unnecessarily...
17:24:17 <needmoney90> I'm behind raising ring sizes. I would eventually hope we can hit three digits.
17:24:33 <Isthmus> sarang: what was your question?
17:24:51 <Isthmus> This assumes a noninteractive attacker just analyzing the blockchain
17:25:18 <sgp_> idk, twatter
17:25:26 <sarang> Payment IDs and amounts are encrypted using the DH shared secret, which involves recipient address and transaction key
17:25:41 <sarang> So are you assuming the attacker has a list of addresses they suspect could be recipients?
17:26:10 <sarang> If so, they could use these to check
17:26:10 <moneromooo> Am I reading it right above "I have relevant info but I'll send it to the media, not you" ?
17:26:25 <sarang> ?
17:26:57 <sgp_> ?
17:26:59 <UkoeHB_> nicely presented figure Isthmus
17:27:21 <moneromooo> < sgp_> ArticMine: I get that, but I have nothing to add now before the talk
17:27:39 <moneromooo> I have no background on this so I might be misinterpreting (I hope).
17:28:05 <Isthmus> Ah @sarang I see what you mean. I have a meeting with Adam later today, and will unpack the assumptions under the hood to clarify
17:28:14 <Isthmus> Given that, let's not share yet sgp_
17:28:32 <sarang> Isthmus: yeah, same with the stealth address stuff
17:28:43 <sarang> I think it's important to clarify what requires candidate addresses
17:28:52 <sarang> It doesn't make everything magically ok, but it's important IMO
17:29:06 <sgp_> okay I'll not share that image
17:29:15 <sarang> I read what you have now as "you need the chain and no other information"
17:29:16 <Isthmus> Maybe the rows should be reordered (3,1,2,4)
17:29:19 <sarang> but I don't think that's the case
17:29:29 <sgp_> but re: moo: yes I'll share all the researhc I've done on coinbase rings at Defcon after discussing them here for years
17:29:44 <sarang> also: "key signature" -> "key image"?
17:29:45 <sgp_> will be good to have a talk
17:29:55 <moneromooo> Ah, so this is just stuff already discussed, fine then.
17:30:25 <Isthmus> In other words, step 1 would be using Shor's + Grover's to extract real address from stealth address, then use that moving forward for the other decryptions
17:30:37 <Isthmus> But yea, lemme have some offline conversations and clarify next week
17:30:51 <Isthmus> ahhahaa "key signature"
17:30:54 <Isthmus> that was my bad, brain fart
17:31:11 <sarang> Can you briefly explain pulling addresses from stealth?
17:32:29 <sarang> If you pull addresses successfully, then sure, you can derive the shared secret and use it to get pID/amount
17:34:23 <Isthmus> Grover's algorithm kind of lets us brute force the address space in O(sqrt(N)) whereas classical computers are limited to O(N)
17:34:52 <Isthmus> Maybe O(N^(1/3)) but not committing to that yet
17:35:05 <Isthmus> I'll try to get a better diagram/explanation for next week
17:35:15 <sarang> OK
17:35:16 <Isthmus> Will have thorough public writeups in the next few weeks anyways
17:35:33 <sarang> Thanks for the update Isthmus
17:35:38 <Isthmus> Completely unrelated, Neptune engineered some great systems for parsing and analyzing tx_extra
17:35:43 <sarang> ah sorry, go ahead
17:35:44 <Isthmus> We found some whimsical unencrypted PIDs, see https://github.com/noncesense-research-lab/monero_tx_extra/blob/master/ascii_data.md
17:35:52 <Isthmus> Nah, that's all
17:36:07 <sarang> Another data point for stricter tx structure...
17:36:37 <Isthmus> Thought y'all might get a chuckle out of those on-chain easter eggs
17:36:52 <sarang> You misspelled "fingerprints" :/
17:37:25 <moneromooo> If something is found just once, it's not really a fingerprint. Are there duplicates ?
17:37:27 <sgp_> haha cool stuff
17:37:43 <Isthmus> Boatloads of duplicates
17:38:13 <moneromooo> If boatloads, that points more to malice.
17:38:36 <sgp_> I don't think it's that magnitude of "boatloads"
17:39:00 <sgp_> well, intent is whatever, but not enough to impact network privacy for other users
17:39:25 <Isthmus> "fluffypony is the best pony ever" alone was used 85 times
17:39:37 <sgp_> lol
17:40:00 <Isthmus> Dates also often repeated
17:40:02 <Isthmus> https://usercontent.irccloud-cdn.com/file/jJoGVIwT/image.png
17:40:36 <Isthmus> 101 txns that had the uPID `EYEixhEvFzEcyJapqxJsoEwmeNULJYFV`
17:40:45 <Isthmus> (to give some context for 'boatloads of duplicates')
17:41:35 <sgp_> cool treasure hunt
17:41:43 <sarang> Any other questions/comments for Isthmus on his update?
17:42:10 <sarang> If not, I'll provide an update
17:42:18 <Isthmus> Shoutout to n3ptune who built the whole framework that made the treasure hunt possible
17:42:25 <sarang> Pleased to announce that the CLSAG audit is complete: https://web.getmonero.org/2020/07/31/clsag-audit.html
17:42:34 <Isthmus> Nice!
17:42:40 <sgp_> great post
17:42:42 <sarang> Note that the audit report reflects the _original_ version of the preprint, not its update
17:42:48 <sgp_> cool logo too
17:43:01 <sarang> The update contains many updates to address the reviewers' concerns and improve the security model and proofs
17:43:15 <sarang> The code did not require any changes
17:43:45 <sarang> Ledger and Trezor support is continuing nicely, and I'm in contact with their teams
17:44:14 <sarang> I updated some branches/PRs for things like wallet signing, key encryption, transaction proofs
17:44:22 <sarang> Some minor things for `monero-site`
17:44:29 <sarang> Work related to BP+
17:44:48 <sarang> There's been a fair amount of discussion since the BP+ CCS was posted
17:44:59 <fluffypony> Isthmus: and that wasn't even me
17:45:24 <sarang> As I'd brought up recently, the original numbers proposed for moving from BP to BP+ would not be nearly as good as the table suggests
17:45:29 <iDunk> Various people did that, IIRC.
17:45:40 <sarang> since the authors didn't account for some optimizations consistently
17:46:02 <sarang> The short version of this is that we'd drop 96 bytes from each transaction, with a marginal speedup (very marginal)
17:46:45 <sarang> I'm of the opinion that BP+ is worth continuing to research and investigate, but I don't think the benefits are significant enough to rush into it
17:47:32 <sarang> However, the CCS proposers did say they were open to the idea of auditing a hypothetical future implementation, since they have expertise relating to the BP+ construction
17:48:02 <sarang> Any other thoughts on this?
17:49:24 <ArticMine> What kind of timeline would be reasonable for BP+?
17:49:36 <sarang> Certainly not the October upgrade
17:49:48 <ArticMine> That is out of the question
17:49:59 <sarang> But I think it could be within a few weeks to code and get initial tests up and running
17:50:07 <sarang> Auditing would be a separate timeline, of course
17:50:27 <ArticMine> Six months?
17:50:39 <sarang> Absolutely, provided the auditors have availability
17:51:01 <needmoney90> Six months between hard forks isn't manageable
17:51:05 * Isthmus has to hop into another meeting, will be back in a later
17:51:07 <needmoney90> At this point it's 9m min
17:51:11 * Isthmus takes off lab coat and goggles
17:51:39 <needmoney90> Just want to pipe in and mention that, because the coordination is hell and a lot of people not involved don't realize how bad it got
17:51:54 <sarang> Again, I don't think there's a particular rush for BP+ since the benefits, while present, are marginal
17:52:09 <sarang> needmoney90: I'm not necessarily advocating for any particular upgrade timeline, to be clear
17:52:19 <sgp_> if it happens, then it happens, whenever the next update would happen anyway :p
17:52:49 <needmoney90> I'm just trying to express that if it's not this update, we're nine months out min
17:53:04 <sarang> It will not be this update
17:53:06 <sarang> No way
17:53:12 <needmoney90> No advocacy either, just statement of fact
17:53:29 <sarang> And given how new the construction is, I would prefer that it receive additional scrutiny
17:53:37 <sarang> It's straightforward, but still very new
17:53:43 <ArticMine> Then lets us make it nine months for the next HF
17:54:35 <sarang> I do agree with needmoney90 that a longer time would be very beneficial for coordination and ecosystem communication
17:54:50 <sarang> Getting hardware device support for this update was a bit of an ordeal, for example
17:55:04 <sarang> to say nothing of software wallets, exchanges, etc.
17:55:04 <sgp_> ping dEBRUYNE to remind them about the relevant post on upgrades ^
17:55:08 <needmoney90> Plus code freezes, followed by translations team and wallet code
17:55:23 <needmoney90> Lots of stuff has to be done in serial for a release
17:55:27 <sarang> right
17:55:29 <needmoney90> And only after code freeze
17:55:38 <needmoney90> Which makes it a total nightmare
17:55:42 <sarang> Well, it sounds like there isn't any major opposition here to a longer time
17:55:45 <ArticMine> Lead time is a very valid issue
17:55:48 <needmoney90> Fixing an airplane while it's in the air and all
17:55:57 <sarang> and at any rate BP+ wouldn't make it for October
17:56:36 <sarang> I do think the CCS proposers would produce a quality code review
17:56:58 <sarang> And having additional researchers participating in the ecosystem is very positive
17:57:18 <needmoney90> How would you suggest we go hunting
17:57:18 <sarang> The proposers could write the code, but then they shouldn't audit it of course
17:57:27 <sarang> needmoney90: ?
17:57:39 <needmoney90> For additional researchers
17:57:56 <needmoney90> What can we do to entice more people onboard?
17:58:32 <needmoney90> Oh, I see you were referring to the CCS proposes as the researchers, I misread.
17:58:37 <needmoney90> Still, relevant question
17:58:42 <needmoney90> Proposers*
17:58:43 <sarang> Yes, sorry for any confusion
17:59:26 <sarang> That's also a good question, and not one I have a good answer to... researchers seem to find the project if/when they have aligned research interests
17:59:31 <needmoney90> Link to the CCS for the record?
17:59:40 <sarang> e.g. the DLSAG team, Isthmus and friends, the BP+ CCS researchers
17:59:41 <sarang> one sec
17:59:41 <needmoney90> Since we're talking about it.
17:59:56 <sarang> BP+ CCS: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/156
18:00:02 <needmoney90> Thanks.
18:00:41 <sarang> For clarity, I am claiming that the improvements shown in Table 1 at that link are not representative of what we'd see in an implementation
18:00:47 <sarang> at least not for verification
18:02:13 <sarang> All right, in the interest of time, does anyone else wish to share research of general interest?
18:03:20 <sarang> OK, in that case, let's adjourn!
18:03:25 <sarang> Thanks to everyone for joining
18:03:30 <needmoney90> I had a discussion with articmine about the potential for dynamic block times, in addition to block sizes (such that the block time can adjust in response to size increases to keep orphan rates low)
18:03:32 <sarang> Logs will be posted shortly to the agenda issue on github
18:03:33 <needmoney90> oh
18:03:34 <needmoney90> nbm
18:03:40 <needmoney90> we can talk about it later :D
18:03:42 <sarang> No, feel free to continue discussion!
18:03:55 <sarang> Adjourning is just for log purposes
18:04:00 <sarang> So I know what to post
18:04:21 <needmoney90> The general feeling I got from articmine was interest but infeasibility, but im still stuck on it.
18:04:42 <sarang> You mean in terms of the difficulty adjustment?
18:05:06 <ArticMine> It comes down to the network being able to measure the number of orphan blocks
18:05:07 <needmoney90> yeah, letting it drift with some sort of multiplier as block sizes go up
18:05:16 <needmoney90> I mean, does it?
18:05:29 <needmoney90> thats the question. If it requires recording orphans its a nightmare
18:05:31 <sarang> So what's the metric for this?
18:05:40 <ArticMine> That was my point
18:05:47 <sarang> Well, and the network needs to know it for verification
18:05:49 <moneromooo> A miner becoming aware of orphans for recent block could include them in a subsequent block, for some reward.
18:06:07 <needmoney90> that actually fixes my main concern
18:06:09 <moneromooo> (small, to avoid encourating mining on not-the-tip)
18:06:13 <needmoney90> ofc
18:06:29 <needmoney90> my main concern was the inability to determine if an orphan from a block in the past was generated then or now
18:06:41 <dEBRUYNE> sgp_: Yes, still on my list
18:06:46 <needmoney90> Only the hash is needed for that, too
18:06:53 <needmoney90> to prove it passed the diff check
18:07:00 <dEBRUYNE> With respect to BP+, I am kind of hesitant about touching sensitive code in case of mere size optimizations
18:07:03 <dEBRUYNE> Seems not worth the trade-off
18:07:25 <moneromooo> You need the block, or you could put some random hash with the high bits zeroed.
18:07:46 <needmoney90> do we not use some sort of double hash?
18:07:52 <needmoney90> hash(Blockhash)?
18:08:23 <needmoney90> Because if you have the end hash passing the diff check, I dont think the block would be necessary then
18:08:25 <sarang> dEBRUYNE: would you have felt similarly if CLSAG had no verification benefits?
18:08:26 <needmoney90> only proof the work was done
18:08:37 <dEBRUYNE> sarang: yes
18:08:42 <dEBRUYNE> I would have objected against implementing it
18:08:47 <sarang> interesting
18:08:51 <sarang> I would have disagreed
18:08:53 <moneromooo> So you'd want to supply preimages of hashes passing diff check ?
18:09:39 <ArticMine> sarang> dEBRUYNE: would you have felt similarly if CLSAG had no verification benefits? <---- or BP causing the drop from 13.5 kB to 2.5 Kb?
18:09:41 <needmoney90> sounds about right, yes. You wouldnt need the block by any means, just proof the work was done for it (and therefore its orphan)
18:09:54 <dEBRUYNE> ArticMine: That drop is significantly larger though
18:09:58 <needmoney90> which dramatically cuts the storage requirements
18:10:01 <moneromooo> I don't know if randomx does that eacxt thing at the end, but it'd seem possible to just pass the preimages if it does.
18:10:27 <ArticMine> There is a risk / reward issue here so it come down to how comfortable we are with the change vs the reward
18:10:42 <moneromooo> 13.5 -> 2.5 was definitely worth it.
18:11:29 <moneromooo> CLSAG is simple enough that it is worth it even if the verificatoin performance was unchanged IMHO.
18:12:05 <needmoney90> So, now I'm wondering how to prove that the orphan presented came from the current tip
18:12:26 <needmoney90> you could probably just not prove it, because you have proof its not a duplicate
18:12:28 <moneromooo> Blocks have a previous block hash field :)
18:12:37 <needmoney90> yes, but if we use preimages the block isnt being passed
18:13:18 <needmoney90> And passing the block is out of the question for this
18:13:28 <needmoney90> (onto the chain that is)
18:14:24 <needmoney90> A scheme that allows people to 'redeem' orphans (any orphans) if their difficulty is below the target and previously unredeemed could work, but could possibly also be abuseable
18:14:44 <needmoney90> because you could store a bunch and release them later to...I guess jump the block time?
18:14:55 <gingeropolous> isn't that what ethereum does? uncles?
18:15:12 <needmoney90> something like that, but its for different reasons
18:15:42 <needmoney90> this is intended to allow the network to raise its own block times in the event that orphan rates spike
18:20:23 <sarang> Ethereums uncle block reward construction has been studied with respect to incentives for bad miner behavior
18:21:05 <needmoney90> Could you use orphans as a way to lower your own difficulty?
18:21:10 <needmoney90> That could be interesting.
18:21:18 <needmoney90> Temporarily. For one block.
18:21:56 <needmoney90> Doesn't create new coins, and gets balanced out by rising block times (possibly. I need to think more)
18:22:32 <needmoney90> And also seems relatively less abuseable