05:55:37 <narodnik> gm
08:20:59 <shresdee[m]> Gm
15:14:51 <UkoeHB> Meeting 1.75hr
17:00:45 <UkoeHB> meeting time
17:00:55 <UkoeHB> 1. greetings
17:00:57 <UkoeHB> hello
17:00:59 <one-horse-wagon[> Hello!
17:01:07 <rbrunner> Hello
17:01:20 <vtnerd> hi
17:01:24 <Rucknium[m]> Hi
17:01:29 <dangerousfreedom> Hi
17:02:31 <UkoeHB> 2. updates, what’s everyone working on?
17:03:16 <vtnerd> I did some serialization stuff again (tests still dont work), and got sucked into lws dev work (first potential commerical deployment)
17:03:38 <vtnerd> so not much related to -mrl, more -dev
17:04:05 <vtnerd> the lws work shouldnt be too long hopefully
17:04:54 <Rucknium[m]> Analyzing data about mining pools' block template update behavior. It affects the amount of time it takes for a transaction to receive its first confirmation on the blockchain.
17:05:11 <UkoeHB> me: continued library cleanup, also did some reviewing of dangerousfreedom’s seraphis knowledge proof work and made some adjustments to jamtis to support enote ownership proofs and address index proofs
17:05:40 <endogenic> (greetings)
17:08:46 <dangerousfreedom> UkoeHB: I have a question to your new proposed scheme. Why K_1 represents a full address? An address is not defined by three public keys, K_1,K_2,K_3? If you are proving knowledge of only K_1 I believe that there may be room for generating a fake proof even if the enote would be unspendable. I dont see a real use case for that since enotes are meant to be owned by someone but it may leave room for that, what do you think?
17:09:03 <dangerousfreedom> I agree it is much cleaner though now
17:09:10 <dangerousfreedom> (the schemes)
17:12:30 <UkoeHB> 3. discussion
17:13:16 <SerHack> hi
17:14:09 <UkoeHB> dangerousfreedom: ownership doesn’t require spendability I think
17:14:50 <rbrunner> (Those "updates" should be these, I think: https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4432591#gistcomment-4432591 )
17:15:30 <UkoeHB> Anyway, including an address ownership proof and amount proof is sufficient to prove an enote is spendable
17:16:30 <dangerousfreedom> Yeah, Ok. I agree with that.
17:16:40 <rbrunner> I have a question out of curiousity, as a layman regarding crypto: Was it easy to find these adjustments you propose there?
17:17:18 <rbrunner> To me it looks almost like magic - add a factor here, hash a bit more there, and presto, the system has more desirable capabilities
17:17:34 <rbrunner> Somehow amazing that such a complex construct is still so malleable
17:22:19 <rbrunner> And do I see that correctly: If Seraphis and Jamtis were already active on Mainnet, such changes would need a hardfork to introduce?
17:22:23 <Rucknium[m]> p2pool will upgrade to reduce the number of p2pool payout outputs by 50-66%: https://www.reddit.com/r/MoneroMining/comments/1095730/psa_p2pool_network_upgrade_aka_hardfork_on_march/
17:22:27 <UkoeHB> wasn't too hard for me, but I have a lot of experience with crypto protocol engineering
17:24:27 <UkoeHB> Rucknium[m]: it's good news nice work sech1
17:24:54 <dangerousfreedom> Rucknium[m]: Nice!
17:25:09 <rbrunner> I hope that p2pool hardfork does not get contested, and the variants multiply :)
17:26:14 <Rucknium[m]> With the p2pool upgrade, I think the proposed (1) coinbase consolidation tx type and (2) avoiding selecting coinbase outputs as decoys is still needed. Just not as urgently needed.
17:28:14 <rbrunner> So maybe we can muddle through until Seraphis
17:29:38 <UkoeHB> right, I proposed this last week https://github.com/monero-project/research-lab/issues/108
17:29:48 <UkoeHB> after thinking about it more, I'm not sure that's the right direction
17:30:15 <Rucknium[m]> Coinbase consolidation tx type has to wait for a hard fork anyway. Decoy selection changes could (and probably should) be implemented at the same time as OSPEAD improvements, assuming OSPEAD passes review.
17:31:06 <UkoeHB> needing to merge coinbase enotes is one example of a broader class of problems - a public group consolidating enotes is statistically significant
17:31:43 <UkoeHB> a coinbase consolidation tx type is not a general solution, it is a specific solution
17:32:05 <rbrunner> You mean a public group of Monero users that do something, namely consolidate?
17:33:13 <fr33_yourself[m]> Will the code surrounding bulletproofs + need to be rewritten for Seraphis? The part of the code that proves inputs = outputs + fee?
17:33:17 <UkoeHB> this solution amounts to elevating the circumstances of miners to first-class status in the protocol, while still leaving the general problem unsolved (e.g. what about consolidating the outputs of consolidation txs?)
17:33:42 <UkoeHB> fr33_yourself[m]: no, range proofs are plug and play
17:35:25 <fr33_yourself[m]> So that part of the codebase(rangegproofs) won't be touched meaning the security level of Seraphis transaction amount proofs will be exactly equal to what it currently is?
17:35:29 <UkoeHB> rbrunner: well any user that receives multiple enotes from outside parties and consolidates those enotes will have a statistically significant tx
17:36:11 <UkoeHB> fr33_yourself[m]: yes, unless BP++ is implemented (which should have equivalent security properities) https://github.com/monero-project/research-lab/issues/101
17:37:02 <rbrunner> I see. Doesn't sound that a bit like an unsolvable problem? Like trying to consolidate without consolidating, because with that I get too many enotes on a single heap?
17:37:04 <UkoeHB> actually I did duplicate BP+ so I could use the seraphis transcript and multiexponentiation tools, which add a little bit of efficiency
17:37:25 <UkoeHB> rbrunner: the solution is a global membership proof
17:37:37 <fr33_yourself[m]> Sounds good, thanks for the quick response. I think the fact that transaction amount proofs stay the same in terms of security will help lessen friction of Seraphis upgrade down the pipe.
17:38:50 <rbrunner> Is something like that akin to nuclear fusion, always 20 years in the future? :)
17:39:15 <fr33_yourself[m]> As an end user, I only think transactions size in kb and overhaul of address scheme could turn out to be points of friction in the future assuming the security of the code implementation of bulletproofs + or ++ is the same as it is presently.
17:39:20 <UkoeHB> rbrunner: perhaps
17:40:25 <UkoeHB> fr33_yourself[m]: tx size will not increase by more than 2x (probably only 1.3x or so)
17:42:23 <fr33_yourself[m]> UkoeHB: Thanks I thought I read something similar to this recently. Like a Seraphis will be about 3kb as opposed to 2kb currently. However, is the tradeoff of having more ring members really worth increasing the tx size? One of the things that I think has helped Monero's adoption over the past hardforks is that transaction size has decreased and speed has increased consistently.
17:44:11 <fr33_yourself[m]> I think the shift from standard rangeproofs to the first implementation of bulletproofs greatly spurred people to shift from other cryptos to Monero and consider the tradeoff of running a full node more favorable than it would've been previously with the huge rangeproof tx's
17:44:59 <Rucknium[m]> fr33_yourself: The decision on the tradeoff between tx size and ring size is something that is in the hands of the community. As someone who researches statistical attacks against Monero user privacy, IMHO, the tradeoff would be worth it.
17:46:16 <fr33_yourself[m]> Rucknium[m]: I understand your perspective and appreciate the work you have done on statistical monitoring of spends. However, isn't there some middle-ground solution where we keep the transactions size in kb of Seraphis equivalent to what we have now?
17:46:43 <rbrunner> Is it so that much of the size increase comes from the larger rings? I doubt it a bit because they are "binned" / encoded in a completely different way.
17:47:02 <UkoeHB> fr33_yourself[m]: for me, the advantage of increased ring sizes is binning the decoys - basically instead of single decoys selected from the chain you select clumps of decoys in the same way. This addresses an analysis mode that uses timing information about when you receive enotes to ignore decoys that don't match the timing profile.
17:47:15 <fr33_yourself[m]> Rucknium[m]: Would be the difference in ring size of the current proposed Seraphis tx versus a Seraphis tx that is only 2kb\
17:47:42 <UkoeHB> fr33_yourself[m]: you can look at estimates I made here https://github.com/monero-project/research-lab/issues/91#issuecomment-1047191259
17:48:48 <UkoeHB> right now I have seraphis-squashed implemented
17:49:06 <rbrunner> I think almost everything is a bit bigger with Seraphis, I doubt we win much if we go down to e.g. 50 ring members, but I may be mistaken
17:50:09 <UkoeHB> verification time is actually lower than clsag with 16-size rings with seraphis-squashed at 128-size rings
17:51:02 <fr33_yourself[m]> I mean it's not the end of the world if transactions are 3kb, but I feel like there is a Monero adoption timeline where hardware begins to trouble individuals wanting to run full nodes. Currently, it's hard to imagine with less than 20k tx per day, but things can change quicker than we may imagine.
17:51:55 <rbrunner> Would that be, in the doc linked above, the graph "Reference Set Size vs Transaction Size"? To check the influence on number of ring members on tx size?
17:52:04 <Rucknium[m]> Preliminary results on tx confirmation delay: Most mining pools update their block template only once: when they see a new block. They don't include new transactions that appear in the mempool after the previous block was found.
17:52:24 <Rucknium[m]> As a result, the average time to first confirmation is actually 30 seconds longer for a XMR tramsaction than a Litecoin transaction, despite Litecoin having a 2.5 minute target block time (compared to XMR's 2 mins).
17:52:37 <UkoeHB> fr33_yourself[m]: you can read a bit about the advantages of binning here https://github.com/monero-project/research-lab/issues/84 and in the references
17:53:18 <Rucknium[m]> If all centralized pools used p2pool's update policy, the average time to first confirmation would fall by a full minute
17:54:42 <rbrunner> Quite surprising that this fact becomes known so late.
17:54:46 <Rucknium[m]> I'm going to release a write-up on the results with graphs next week. I think the course of action is to try to convince mining pool operators to update their block templates more frequently and/or change the defaults on jtgrassie 's monero-pool software.
17:55:32 <Rucknium[m]> If centralized pools refuse, then we will go all-in with p2pool adoption! (This is a joke)
17:56:07 <Rucknium[m]> Anecdotally, I noticed this with my own transactions. You can also see it on txstreet.com
17:56:18 <rbrunner> Do these pools win something by doing so?
17:56:25 <UkoeHB> btw, I think you could use a SAG (simplified CLSAG) with seraphis to get 16-size rings and verify txs maybe 20-40% faster than today
17:56:39 <Rucknium[m]> The Isabellas are kicked off the bus right before it launches into the blockchain.
17:57:56 <Rucknium[m]> p2pool on average is getting 0.003 XMR more in fee revenue per block than other miners. So pools are losing a bit. But according to sech1 the pools need to do database operations when they update the block templates, which may cost money.
17:58:36 <sech1> They need to update db when they send out new jobs to all connected miner workers
17:58:44 <sech1> which can be tens of thousands jobs for each block template
17:59:48 <Rucknium[m]> I wonder if other PoW coins (I am analyzing LTC, BCH, and DOGE) have more mining centralization so they don't have the database cost.
17:59:58 <sech1> They do
18:00:03 <sech1> but they still update template more often
18:00:20 <Rucknium[m]> They do have the cost or they are more centralized?
18:00:30 <sech1> I looked at pool code before, and I think 90% of the problem is pool operators just use what's default
18:00:38 <sech1> Monero pools can update more often
18:00:42 <sech1> at least every 30 seconds
18:01:00 <sech1> but it will require some qualification and knowledge from pool operators
18:01:22 <Rucknium[m]> Yes I would guess that it is "default-itis" rather than a deliberate decision.
18:02:09 <Rucknium[m]> One of the pool operators seems to update every two minutes if a block hasn't been found. So a +2,+4, +6, etc. minutes
18:02:18 <Rucknium[m]> Most of the other ones don't update
18:02:37 <Rucknium[m]> The pool labeling data was gathered by datahoarder.
18:04:31 <UkoeHB> we are past the hour so I'll call it, thanks for attending everyone
18:50:46 <fr33_yourself[m]> <UkoeHB> "we are past the hour so I'll..." <- UkoeHB, what is VTnerd's verdict on your current code implementation of binning? I was deeply comforted to see some intelligent criticism of your binning proposal, but he seems to have reached the conlcusion that binning privacy is at least equivalent to single decoy selection privacy so long as the number of bins is 16 or greater (our current single decoy size) ?
18:52:19 <vtnerd> Id have to look at it again, but the initial struggle was there was two different binning modes, and the one representing recent outputs was a bit funky
18:52:55 <vtnerd> overall, it _probably_ is better after I thought about it (theres a decent space savings with no obvious privacy downside)
18:53:32 <vtnerd> arguably the randomized mode we have now is preferrable, but I dunno its still a tough argument
18:54:16 <Rucknium[m]> fr33_yourself: Binning has not been rigorously analyzed by any statistician. Hopefully we will have a rigorous analysis before the include/exclude decision is needed closer to Seraphis mainnet activation.
18:54:19 <fr33_yourself[m]> vtnerd: I would appreciate it if you share your thoughts and pin me after you've looked at the most recent implementation. I can't read code, but I want to thank you deeply for pushing back with reasonable criticism. One thing that made me a bit bearish on Monero is how quickly people are assuming that Seraphis is all good with no bad. I think preserving the current level of supply integrity and privacy are paramount
18:54:19 <fr33_yourself[m]> above all other possible gains.
18:54:45 <UkoeHB> that MRL issue describes a fully-deterministic approach, but my implementation is only partially deterministic so it's a bit simpler
18:55:23 <fr33_yourself[m]> vtnerd: What about security downsides? Is there any way binning increases, even if at the edge / margin, the probability of an inflation bug?
18:59:39 <fr33_yourself[m]> UkoeHB: And if my understanding is correct, the idea is that with binning an increase or decrease in total key_images or decoys or whatever doesn't have a huge impact on tx size, so may aswell do 128 as opposed to 64 decoys
19:00:34 <fr33_yourself[m]> ^ If this is true, then I'm fine with tx size in kb going up some as it seems to be an inherent feature of binning, so might as well increase decoys a notable amount if decreasing decoys doesn't decrease tx size much.
19:00:48 <UkoeHB> yes the size scaling is better
19:01:09 <fr33_yourself[m]> Ok i am happy camper then
19:01:12 <UkoeHB> it's unrelated to binning though, binning just saves some reference bytes (~4-6 bytes per decoy)
19:01:44 <fr33_yourself[m]> if scaling is reasonable and supply security (no bugs in coin emission or amount proofs) occur, then Seraphis seems to have low tradeoffs
19:02:37 <fr33_yourself[m]> That just leaves address scheme overhaul, but as someone who monitors Monero network and dev discussion this doesn't seem like a big deal to me.
19:03:07 <fr33_yourself[m]> Maybe it will be for people who have a cold wallet sitting dormant that they can't access until "n" years after Seraphis roll out
19:04:03 <UkoeHB> cold wallets won't be able to receive funds without being updated, but legacy funds will be spendable seamlessly
19:05:18 <fr33_yourself[m]> I know it's annoying in the moment for you guys to debate and argue as developers, but it's quite nice to see strong pushback on different sides of issues. For a while I was seeing some weird rhetoric surrounding seraphis like people making comments along the lines of: "if we present seraphis this way, it will lessen people's angst about possible vulnerabilities or bugs" or something like this
19:06:32 <fr33_yourself[m]> UkoeHB: ahhhh, so basically a cold wallet must be updated post-seraphis to receive funds, but it will be able to spend funds seamlessly from an airgapped laptop or hardware wallet 
19:07:30 <rbrunner> "if we present seraphis this way, it will lessen ..." That sounds weird. Maybe I am biased, but I never read something that I would put into this particular drawer.
19:08:07 <fr33_yourself[m]> I do have a question about Bitcoin though, I thought I saw someone state that Bitcoin protocol could somewhat survive a splinternet by having wallet software resend a tx immediately after the subnetwork chain reconnects to the mainchain? is this really true? If so it is a genuine technical advantage bitcoin has over Monero in this case.
19:08:54 <fr33_yourself[m]> rbrunner: I don't think it was a developer who said it, but someone else in one of the matrix rooms.
19:10:10 <rbrunner> Well, then all bets are off :) We have an average of over 1000 people present in the Monero subreddit at almost any given time
19:10:24 <fr33_yourself[m]> I also don't appreciate all these instant gratification consumer's trying to weasle a way around the 10-block lock lol. It doesn't make any sense to me. Like why can't you just wait 30 minutes chill
19:10:25 <fr33_yourself[m]> If the person's use-case is, I want to give up my privacy to spend immediately after receiving, then they should use Litecoin or BCH or something IMO
19:10:25 <rbrunner> Sometimes I wonder why not *more* nonsense gets posted, with so many people
19:10:45 <UkoeHB> fr33_yourself[m]: I guess it depends on the cold wallet implementation - do existing cold wallets not have to update with each hard fork?
19:10:58 <Rucknium[m]> The transactions in a bitcoin splinternet would be erased after reconnection to the chain with the most proof-of-work
19:11:01 <fr33_yourself[m]> I feel like most of the low IQ comments remain on reddit as it is easier to access than the matrix rooms
19:11:59 <Rucknium[m]> The transactions in the splitnet that spend outputs from the splitnet would be invalid on the main chain after reconnection.
19:12:01 <fr33_yourself[m]> UkoeHB: I don't know. I've never tried to spend from a cold wallet.
19:12:47 <rbrunner> I would say cold signing only works with a Monero version of the right version, most of the time. Maybe there were hardforks where you could "cheat" and continue to sign with an older version.
19:12:55 <fr33_yourself[m]> UkoeHB: Are you being sarcastic here? If my understanding is correct, then I can send XMR from a hot wallet running the 16 member version of Monero to a cold wallet that's address was generated in offline software and it will still go to the appropriate cold wallet because the address scheme is the same.
19:12:56 <rbrunner> *Monero software
19:13:37 <rbrunner> Maybe we are talking about two different kind of "cold wallets" now.
19:14:05 <fr33_yourself[m]> Basically sending to cold wallet from hot wallet only becomes impossible if the address scheme changes, not simply due a hardfork which does not tamper with the address scheme
19:14:16 <fr33_yourself[m]> rbrunner: I'm talking about a paper wallet
19:14:19 <rbrunner> Of course you can send to a mere address as long as you like, until the address format changes, as it will with Jamtis
19:14:28 <rbrunner> Ah, yes, "paper wallet" is it
19:14:48 <UkoeHB> ? you can't send to legacy addresses in a seraphis tx, but you can spend from legacy wallets if your software supports it
19:15:06 <fr33_yourself[m]> Let's say you generated a paper wallet with Moo's offline wallet generator (I think he made that right?) then you can send to it UNTIL the address scheme changes assuming Seraphis is implemented
19:15:31 <rbrunner> I would say so
19:16:23 <rbrunner> As I said, can't see what would stopping you sending XMR to the correct address of your paper wallet
19:16:40 <rbrunner> As long as the address itself stands
19:17:01 <fr33_yourself[m]> UkoeHB: Got it, but the idea is that in order to spend you will have to update the wallet anyways. I guess the only way something could go wrong is if someone didn't update after Seraphis and funds were sent to their cold wallet with legacy address
19:17:41 <rbrunner> Who would mine that tx?
19:18:00 <fr33_yourself[m]> Will the GUI wallet post-Seraphis automatically block a sender from sending to a legacy address to prevent the funds from getting burned?
19:18:03 <Rucknium[m]> In a splinternet situation, most miners would probably stop mining in the minority hashrate region since their coins would disappear when connect to the majority hashrate region. So probably no transactions would be confirmed on the minority splintnet anyway.
19:19:04 <rbrunner> You can't send to a legacy address. There is no way to construct a tx for doing so. Even if somebody forgot to check and allow the input of old address, a valid tx could not be built, IMO
19:19:09 <Rucknium[m]> As far as I know, funds cannot be sent to legacy transactions after non-Seraphis txs would be discontinued on mainnet.
19:19:15 <UkoeHB> fr33_yourself[m]: you'd need to do a lot of dev work to make a seraphis tx using a legacy address, so no that situation should never occur
19:19:39 <moneromoooo> Challenge acc... nevermind
19:19:40 <fr33_yourself[m]> Rucknium[m]: how quickly do you think miner's would react? Do you think the miner's are also savvy enough to know what a splinternet is and that they would have the means of detecting that one was implemented within hours of a splinternet implementation?
19:20:31 <fr33_yourself[m]> UkoeHB: Basically wallet software will prevent funds from being sent to legacy addresses by default? No one will accidentally burn funds?
19:20:51 <fr33_yourself[m]> Sorry these are ELI5 questions some technical things I still don't understand clearly
19:22:04 <moneromoooo> Think of it like a key and a keyhole. If you change keyhole, old key doens't fit. Unless someone takes the time to file the key to make it sort-of-fit (but not actually work).
19:22:37 <fr33_yourself[m]> Gotcha
19:23:06 <fr33_yourself[m]> I'm just trying to ensure that simpletons like me don't accidentally burn XMR post-seraphis
19:23:18 <fr33_yourself[m]> because it is impossible or near impossible by the sounds of it
19:23:58 <moneromoooo> There are easy ways to prevent that (though you can't of course stop dumbasses making their own code that misuses keys).
19:25:33 <one-horse-wagon[> fr33_yourself: Check for the latest monero software at GetMonero.org, download it, get it going, and you'll be good to go after any future update.  There really isn't anything else you'll need to do.
19:25:46 <UkoeHB> it would take some very sketchy hackery since jamtis uses x25519 keys for the DH exchange
19:26:30 <fr33_yourself[m]> moneromoooo: I am too big of a dumbass to make my own code so I am safe :)
19:27:25 <fr33_yourself[m]> one-horse-wagon[: I know, I was concerned about a paper wallet that has never touched the GUI software before and was generated using a paper wallet generator.
19:27:50 <fr33_yourself[m]> But looks I will need to bring that online when/if Seraphis is implemented 
19:28:06 <fr33_yourself[m]> Not complaining, just making sure I understand correctly
19:29:55 <Rucknium[m]> I don't think you have to bring it "online". You will have to generate a new address with an airgapped computer if you want to receive funds after the hard fork.
19:30:43 <one-horse-wagon[> fr33_yourself: The gist of the Seraphis upgrade is "No Wallet Left Befhind".  That is the name of the Matrix room where the developers are meeting.  They are taking the task very seriously because some people's life savings are at stake.
19:33:08 <fr33_yourself[m]> gotcha thanks sir
19:34:16 <fr33_yourself[m]> Rucknium[m]: roger, and then I can spend the legacy funds in the cold paper wallet after I download the seraphis software and restore this paper wallet from mnemonic seed?
19:34:39 <fr33_yourself[m]> inside the new seraphis software
19:39:39 <Rucknium[m]> fr33_yourself: Yes. Why don't you write a FAQ based on the answers here? They we can link other users to it.
19:40:23 <fr33_yourself[m]> Just ping me when you get other simpletons like me asking questions 
19:40:34 <fr33_yourself[m]> and i will answer them
19:40:35 <fr33_yourself[m]> I like talking about monero
19:41:00 <fr33_yourself[m]> haha rucknium getting tired of answering my questions haha
19:43:33 <Rucknium[m]> :P Well, it's much more time efficient to answer questions in a FAQ format for all users.