09:39:51 <Inge-> "In a paper published this week in Nature Electronics, researchers from Microsoft and the University of Sydney, Australia, explain how they've developed a chip called Gooseberry that can support thousands of qubits – significantly more than the 65-qubit design touted by IBM last year – though they haven't actually made such a device."
09:39:56 <Inge-> https://www.theregister.com/2021/01/29/microsofts_gooseberry_is_a_dish/
11:52:56 <zoimxdgflwy> Why are you here? For the tech? Then you should be off at Zcash instead of trying to con newbies into a coin that doesn't work. For the money? If you put your money in BTC or ETH you would have been better off. For the magical crypto friends? Monero leadership laughs from losers like that. Find yourself more healthy realationships that don't laugh at you when they steal your money.
11:55:42 <tmsufzhlf> Why are you here? For the tech? Then you should be off at Zcash instead of trying to con newbies into a coin that doesn't work. For the money? If you put your money in BTC or ETH you would have been better off. For the magical crypto friends? Monero leadership laughs from losers like that. Find yourself more healthy realationships that don't laugh at you when they steal your money.
15:36:12 <sgp_> meeting here at 17 utc
15:36:48 <dEBRUYNE> I will probably have to skip, but can add thoughts afterwards
15:38:13 <sgp_> did you see the rough timeline? https://github.com/monero-project/meta/issues/547#issuecomment-772600779
15:46:50 <jwinterm> .time
15:47:05 <jwinterm> 75 min
16:17:44 <midipoet> .time
17:00:00 <sgp_> meeting time
17:00:03 <sgp_> 1. Greetings
17:00:15 <hyc> hola
17:00:23 <zkao> hoi
17:00:25 <sethsimmons> hey all
17:00:33 <sethsimmons> I'm actually around for something 😀
17:00:39 <rottenwheel> Hallo.
17:00:59 <sgp_> ping sarang moneromooo ArticMine knaccc vtnerd
17:01:08 <rbrunner> Hi (lurking a bit here for once)
17:01:17 <h4sh3d[m]> hi
17:01:52 <zkao> jwinterm midipoet
17:02:05 <endogenic> endogenic
17:04:21 <sgp_> hello everyone
17:04:28 <lederstrumpf> hello
17:04:29 <sgp_> are sarang and moneromooo here?
17:05:34 <ArticMine> Hi
17:06:27 <sgp_> hmm, apparently not
17:06:47 <sgp_> let's just start with the first high-level topic
17:06:48 <sgp_> https://github.com/monero-project/meta/issues/547#issuecomment-772600779
17:07:09 <sgp_> we need to think about which plan we prefer of the two
17:07:23 <sgp_> this has been discussed in prior meetings, but now they are written down
17:07:49 <sgp_> sarang mentioned that the research work for triptych will take approximately 2 months
17:07:57 <sgp_> 3 months for moneromooo is an estimate
17:08:07 <sethsimmons> I just don't see the need to delay a network upgrade for multisig, which is so infrequently used.
17:08:11 <sethsimmons> So Option 2 seems better to me.
17:08:30 <sgp_> just for clarity:
17:08:31 <sethsimmons> If we can work on multisig in parallel or fund someone else for that portion, great.
17:08:40 <sgp_> option 1 and option 2 will have some multisig wallet support
17:09:02 <sgp_> option 1 is doing 2 hardforks: 1 for BP+, another for triptych
17:09:10 <sgp_> option 2 is doing 1 hardfork with both
17:09:39 <sethsimmons> ah
17:10:07 <hyc> seems like the cautious route is to change one thing at a time
17:10:43 <ArticMine> My preference is option 1. I think the timeline for Triptych for option 2 is very optimistic.
17:10:45 <rottenwheel> Would love to first hear an informed stance from noether or moo before casting a vote, though one at a time is more cautious indeed.
17:10:49 <h4sh3d[m]> agree with hyc, an hard fork with two big changes is more risky
17:11:03 <zkao> hyc's point to me that sounds the most scientific way of doing things
17:11:09 <sgp_> fwiw, two hardforks also creates more headaches for the ecosystem than 1
17:11:17 <ArticMine> Still I want to hear from sarang on the timelines
17:11:40 <sgp_> note that I can speak for sarang in the 2 months for research. That is what he is telling me
17:12:00 <sgp_> I can't really speak for moo
17:12:24 <hyc> a 2nd hardfork 10 months after the previous doesn't sound like a big hassle
17:12:40 <hyc> considering we used to do them every 6 months, why is 10 months a problem?
17:13:11 <rbrunner> I don't understand yet the long time of 5 months in option 1 where there is only 1 bar "Support ..." active somehow. What happens there?
17:13:25 <sgp_> I'm just passing along that Cake kinda interrupts their dev process each time
17:13:51 <sethsimmons> Option 1 is the better option IMO as well -- fewer moving parts in a single HF, faster ring-size increase, still lots of lead time.
17:14:07 * needmoney90 is actually awake at a reasonable hour 
17:14:15 <sethsimmons> <rbrunner "I don't understand yet the long "> I would assume delaying 2nd HF so that it's not too much pain on the ecosystem while focusing on improving musig support.
17:14:18 <needmoney90> [takes a seat]
17:14:37 <endogenic> still dreaming needmoney90
17:15:06 <rbrunner> Ok
17:15:17 <hyc> that part didn't bother me too much, presumably there will be other work to justify a hardfork as well
17:15:24 <sgp_> is August the soonest we can have v15? I'd actually rather move forward as much as possible if we want to go with option 1
17:16:42 <needmoney90> Are debruyne or selsta around?
17:16:43 <sgp_> I'd rather make it June tbh
17:17:07 <needmoney90> Both of them are front line support, and I think their perspectives here would be valuable.
17:17:43 <ArticMine> The other item for the HF is issue 70
17:17:52 <needmoney90> Lots of small fires to put out every HF, they have to deal with it every time.
17:18:25 * zkao is waiting till august
17:22:00 <sgp_> dEBRUYNE is not here, but they were the one mostly championing option 2
17:22:16 <sgp_> I still personally prefer option 2, but I also get the arguments behind option 1
17:22:27 <rbrunner> Trouble once instead of trouble two times?
17:23:00 <ArticMine> There is an advantage to option 2 in that it does simplify the scaling side in that there is only one tx size (weight) to deal with
17:23:01 <moneromooo> I think timing will mostly depend when the code gets reviewed, no ?
17:23:18 <moneromooo> BP+ is all ready to go, bar review.
17:23:46 <moneromooo> Triptych is not plugged at all, and we might need a new way to represent rings, depending on how much we bump ring size.
17:25:05 <sarang> Hi
17:25:09 <moneromooo> Also, fucking multisig users over is not nice. We'd have to allow CLSAG txes in parallel, probably, so they can still spend their coins while multisig is worked out.
17:25:20 <gingeropolous> ^
17:25:40 <sgp_> moneromooo: it's my understanding that they wouldn't be "fucked over" in option 2
17:26:23 <sgp_> but it seems like most people are generally for option 1
17:26:25 <needmoney90> If Deb is behind option 2, I'm inclined to lean towards that option.
17:27:01 <sethsimmons> Both are fine IMO, I just lean towards one for faster ring-size increase, mostly, which is probably not a good enough reason.
17:27:25 <hyc> didn't realize this would be a breaking change for multisig
17:27:39 <hyc> so yeah, let's not screw anyone...
17:28:18 <moneromooo> When I said review above, I meant audit by a third party. Not PR review.
17:28:21 <sethsimmons> Both options complicate multisig FWIW
17:28:25 <rbrunner> Potential multisig problem would be to not be able to spend coins out of a multisig wallet for a certain period?
17:28:44 <sarang> Research areas for this still include: cross-transaction batching, multisig algorithms and analysis, anonymity set binning
17:28:49 <needmoney90> There are ecosystem-wide repurcussions every HF. We should be leaning towards more consistency in our releases if at all possible. I think two HFs (when we know what will be included in both ahead of time) is less ideal due to this
17:28:56 <sgp_> rbrunner: I don't believe that would happen
17:29:02 <sethsimmons> sgp_: do you have a summary of the multisig effects of both?
17:29:25 <rbrunner> Just wondering what would be the "fuckery" ...
17:30:02 <sgp_> clsag multisig wallet users need to "convert" their wallet to a non-multisig wallet before they can spend triptych funds received in this same wallet
17:30:26 <sethsimmons> <needmoney90 "There are ecosystem-wide repurcu"> If we go this route and combine BP+ and Triptych, I'd vote for a long and pushed testnet/stagenet testing time.
17:30:44 <sethsimmons> With lots of pushes to get people running nodes, maybe even simple scripts for stress-testing scenarios
17:30:53 <sgp_> maybe I need to document this all clearly since there is a ton of confusion it seems
17:31:10 <needmoney90> That would cause much less strain on time, resources, and our surrounding ecosystem.
17:31:11 <rbrunner> Could do no harm :)
17:31:16 <sgp_> okay, so how about this
17:31:17 <sethsimmons> We generally don't do a ton of public test/stagenet testing before forks and its just a few of us involved. I'd like to see us actively try and rope in more users and define more test-cases.
17:31:28 <sgp_> I'll open a github issue for these two options with all the details I know of
17:31:30 <sethsimmons> <sgp_ "maybe I need to document this al"> Its very confusing lol
17:31:38 <sgp_> then everyone will have a week to comment
17:31:47 <sgp_> longer if needed
17:31:51 <needmoney90> A pushed back timeline would be a great chance for us to do a push for testing.
17:32:10 <sgp_> before I do that, why v15 in option 1 in August?
17:32:35 <moneromooo> BP+ isn't a huge advance over BP so I'd be fine pushing it till later tbh.
17:32:40 <sethsimmons> I'd vote for 1-2mo after audits complete.
17:32:51 <moneromooo> It doesn't hurt as it did for 12 kB -> 2.5 kB.
17:33:12 <sgp_> ArticMine: is really pushing for their fee change being included soon
17:33:39 <sgp_> so we can have bp+ audit finished in 2 months, pretty easy
17:33:46 <sethsimmons> For sure.
17:33:53 <sgp_> so that's sooner than August
17:33:54 <sethsimmons> I would only advocate a HF for it with other improvements like MRL70 and ring-size increase.
17:34:27 <sethsimmons> <sgp_ "so we can have bp+ audit finishe"> June sounds viable then.
17:34:40 <sgp_> is anyone here against late June?
17:35:17 <sgp_> because if no one is against late June, I can adjust option 1
17:35:42 <needmoney90> I would prefer to hear from our front line support before making a call here
17:35:54 <ArticMine> So BP+ audit by April HF in June. That makes sense
17:36:22 <moneromooo> This should be in -dev anyway. Research isn't concerned with fork timing.
17:36:27 <sgp_> okay, looks like I have some work to do then
17:36:53 <sgp_> I'll put out a github issue tomorrow AM at the latest with a summary
17:37:11 <sgp_> ArticMine: can you talk about the fees then?
17:37:20 <sgp_> https://github.com/monero-project/research-lab/issues/70#issuecomment-768036260
17:37:41 <sgp_> I'm a little concerned with the increase in the scaling limit from 1.4 to 2
17:37:57 <sgp_> it seems aggressive to me
17:38:28 <sgp_> if Monero adoption grows faster than whatever limit we set, the network doesn't break; transactions just get more expensive temporarily
17:39:41 <sgp_> does anyone have thoughts here?
17:39:44 <ArticMine> While I agree that under many circumstances something like 1.6 or 1.8 might be enough. There would be very little margin for error
17:40:30 <UkoeHB> p.s. I have not looked at fees yet... no head space at the moment
17:40:48 <sgp_> 2 would allow for a 32x increase in block size per year
17:40:55 <ArticMine> In 2016 we saw a rate over several months in excess of 2 and there was no increase in adoption during the 2014 - 2015 bear market
17:41:10 <sgp_> 1.4 allows for ~5.4x
17:41:39 <ArticMine> in 2019 - 2020 we saw an increase in adoption during a bear market
17:42:35 <sgp_> well, maybe we should make the upper limit in growth per year to whatever brings us up to Bitcoin's current transaction throughput
17:42:50 <sgp_> since the BTC network does work today with a limited size
17:43:29 <sgp_> is that unreasonable?
17:43:45 <ArticMine> add to this the recent regulatory changes and a repeat of what happened in 2016 and we will will be over 2
17:44:09 <ArticMine> Bitcoin is dysfunctional because of its limits to growth
17:44:24 <ArticMine> So following Bitcoin is unreasonable
17:44:49 <sgp_> there's still provision for growth however
17:45:33 <sgp_> it's a capped growth rate not a capped static siz
17:45:35 <ArticMine> Just because we have 2 it does not mean that that it will be maxed out
17:45:51 <sgp_> we need to prepare for spammers to try and cap it out however
17:46:18 <ArticMine> That is why the we introduce the LT median
17:46:54 <ArticMine> The attack that happened was the reverse
17:47:05 <ArticMine> I mean just a month ago
17:47:27 <sgp_> yeah I get that, capping the decrease rate
17:47:36 <jwinterm> if it was maxed out under the two scenario: 1) how much would the blockchain grow in one year, and 2) how much in XMR fees would be paid in total over the year?
17:47:45 <jwinterm> if you happen to know
17:48:20 <sgp_> jwinterm: with this proposal, it would allow blocks to be max 32x larger than they were at the start of the year
17:48:29 <ArticMine> If we allow the short term median to remain above the long term median for an extended period of time then the type of attack we just has would be chap and disruptive
17:48:51 <ArticMine> cheap
17:48:52 <needmoney90> I think 32x/year is excessive, and gives us little time to react to an attack. We should be considering lead times in years at this point, not months.
17:49:11 <ArticMine> There is plenty of time
17:49:30 <ArticMine> to respont
17:49:36 <needmoney90> There is a flurry of support/ecosystem issues that pop up every HF.
17:49:42 <ArticMine> The is only just over 2 hour on the other side
17:49:54 <needmoney90> Those must be considered in this equation
17:50:05 <ArticMine> That is ho long the short term median can fall drastically
17:50:19 <sgp_> Bitcoin has a little over 10x as many tx/day as Monero right now
17:50:22 <selsta> June is stressy and unrealistic
17:50:31 <needmoney90> Ah, welcome selsta
17:50:43 * selsta didn't read all backlog
17:50:58 <needmoney90> You should. Please catch up, your opinion here is greatly appreciated
17:51:16 <needmoney90> Since you deal with the support fallout from HFs
17:51:17 <ArticMine> So we are talking under 2 hours vs over 2 months to respond to an attack
17:51:28 <sgp_> ArticMine: let's separate these two things
17:51:44 <sgp_> there's 1) the maximum decline rate. We seem in agreement here
17:51:47 <ArticMine> What two things
17:51:55 <sgp_> then there's 2) the maximum increase rate
17:51:58 <sgp_> is this correct?
17:52:37 <ArticMine> Yes but you are ignoring that the short term median can still be above the long term median for an extended period of time
17:52:45 <ArticMine> Setting the stage for an attack
17:53:03 <ArticMine> Such as the one that just occurred
17:53:58 <ArticMine> The whole point of the long term median is to give the community over 2 months to respond
17:54:05 <ArticMine> This does not change
17:54:44 <sgp_> because it's capped at ~2x growth?
17:55:27 <ArticMine> The Short term median is capped at 50x over the long term median
17:55:48 <ArticMine> To allow for a retain surge over a 1 - 2 month period
17:56:14 <ArticMine> This is why VISA has over 20x their average use as a maximum capacity
17:56:45 <ArticMine> This was all done when the long term median was introduced in 2019
17:57:07 <sgp_> I still think the bump is ambitious
17:57:20 <sgp_> sorry we are getting close on time
17:57:31 <sgp_> selsta: is August the earliest you support?
17:57:43 <sgp_> what are your thoughts there
17:57:47 <ArticMine> It is actually very prudent
17:58:03 <ArticMine> base uppon the transaction data
17:58:15 <sgp_> I think we will need to schedule another dedicated discussion on the block caps
17:59:08 <ArticMine> I suggest the argument be made first in the issue on GItHub
17:59:22 <ArticMine> GitHub
18:00:34 <needmoney90> Let selsta catch up and reply to the upcoming github issue, take some time to collect their thoughts
18:00:38 <ArticMine> MAke the case for 1.6 or 1.8 vs to there
18:00:54 <ArticMine> vs 2
18:01:07 <selsta> needmoney90: can only catch up later
18:01:12 <sgp_> yes I can comment
18:01:17 <selsta> have to go again
18:01:18 <sgp_> but I also don't want the default to be an assumed increase to 2
18:01:25 <sgp_> the change to 2 is the proposed change
18:01:41 <selsta> but yes, last meeting I said I would be for late July / August
18:01:53 <sgp_> okay ty selsta
18:02:34 <sgp_> any final thoughts?
18:02:51 <sgp_> if someone wants to join the 2nd BP+ audit calls with me, please let me know
18:03:09 <sgp_> my takeaways:
18:03:12 <needmoney90> Are they going to be published later?
18:03:15 <needmoney90> The calls that is
18:03:24 <sgp_> needmoney90: no, I'm not going to record the calls
18:03:30 <sgp_> but the SoWs will be public
18:03:30 <needmoney90> OK.
18:03:36 <needmoney90> When will that be?
18:03:41 <needmoney90> The calls that is.
18:03:45 <sgp_> TBD, ideally within a week
18:03:54 <sgp_> it's on me to schedule
18:04:01 <needmoney90> Got it
18:04:11 <needmoney90> No further thoughts from me
18:04:13 <sgp_> I really would prefer sarang or someone else knowledgeable there
18:04:20 <sgp_> since I have no idea what this code is LOL
18:05:52 <sgp_> anyway
18:06:01 <sgp_> look for the update summary/timeline github issue
18:06:24 <sgp_> thank you everyone
18:07:13 <sgp_> oh, and I will also comment on the block size issue
18:07:41 <sarang> Sorry, which code are you asking about? (haven't read scrollback)
18:08:08 <sgp_> sarang: I can take the BP+ call by myself but if they have specific questions I'll be useless
18:08:39 <sarang> I'm happy to provide insight on that code and any auditor comments/questions
18:09:17 <sgp_> sweet, are you able to join the calls too?
18:09:42 <sarang> Time permitting, sure
18:10:09 <sgp_> okay I'll DM you some times
18:16:20 <ArticMine> I have to leave the meeting. I have a conference call in a few minutes
18:16:49 <sech1> "Such as the one that just occurred" What attack are you talking about? I'm out of the loop
18:17:30 <ArticMine> If an attacker disrupts the nodes. The tx rate can drop over 65%
18:18:08 <ArticMine> This happened during the attack in late December
18:18:41 <ArticMine> There was no impact on fees or scaling becasue the network was in the penalty free zone all along
18:19:34 <ArticMine> The scenario is a similar or greater collapse of the short term median in the penalty zone
18:20:07 <ArticMine> ... and all it takes is for the attacker to keep up the attack for under 2 hours very cheap
18:21:14 <ArticMine> and the blocksize can fall by a factor of say 10x or more
19:26:56 <dEBRUYNE> <ArticMine> add to this the recent regulatory changes <= What are you referring to exactly?
19:27:53 <dEBRUYNE> <sgp_> dEBRUYNE is not here, but they were the one mostly championing option 2 <= Yes
19:28:06 <dEBRUYNE> I'd also adamantly oppose option 1, mostly because the upgrade is fairly minor
20:05:28 <ArticMine> dEBRUYNE The regulatory changes by FinCEN and by the US Congress, effectively treating cryptocurrencies as cash
20:07:30 <ArticMine> One impact of this is that there can be a significant pressure to move transactions on chain and the need for additional on chain transactions to legally avoid onerous reporting requirements
20:09:40 <ArticMine> For example if 1) A merchant uses payment processor to accept Monero who then pays the merchant in USD. The Payment processor has to KYC the customer
20:10:47 <ArticMine> but if 2) The merchant first accepts Monero and then sends the Monero to the payment processor, there is no need to KYC the customer
20:11:02 <ArticMine> This is actually in the 2019 FinCEN guidance
20:12:00 <ArticMine> In case 2) there are 2 transactions on the Monero blockchain. In case 1 there is only one transaction on the Monero blockchain
20:12:46 <ArticMine> Also section 70 upgrade is not minor and that would be included in option 1
20:15:47 <ArticMine> There is a very real risk with the current situation of severely disrupting the Monero network once Monero is deep into the penalty zone. An attack would only need to be maintained for 100 minutes to cause the short term median to fall drastically and fees to skyrocket
20:17:05 <ArticMine> So prudence is that we address MRL issue 70 before the blocksie scales over 300000 bytes. This could happen in 2021 with the recent rate of growth
20:17:15 <ArticMine> blocksize
20:20:23 <ArticMine> There is no immediate problem. If we wait for Triptych to address issue MRL issue 70 there can be a real problem particularly if Triptych is delayed
20:24:55 <ArticMine> The wake up call on MRL issue 70 was the drop in transactions during the attack last December
20:28:19 <moneromooo> Is there still discussion about your proposal in the PDF I see linked ?
20:28:49 <ArticMine> I have not see a response in the issue
20:29:13 <ArticMine> on Github
20:29:49 <moneromooo> Let me rephrase then. Do you expect this proposal to stay as is and thus be ready to code in monero ?
20:30:23 <moneromooo> ie, is this the synthesis of discussion with people who are interested in the nuts and bolts of that particular issue ?
20:31:44 <ArticMine> Yes my latest proposal was a response to UkoeHB and the concerns raised
20:32:01 <ArticMine> It did not go far enough
20:32:36 <ArticMine> There was also the question of a misunderstanding on Big bang attacks
20:33:42 <ArticMine> The attacker has to support the short term median for the period of the long term median to continue the attack
20:35:17 <ArticMine> So the scenario where the short term median is below the long term median does not play in Big Bang
20:36:52 <ArticMine> By the way I proposed the 2x increase rate for the long term median that sgp has questioned rate back in August of last year
20:37:44 <UkoeHB> I have not yet assessed to updated proposal
20:38:02 <ArticMine> I know
20:38:25 <UkoeHB> for moneromooo's question ^
20:38:50 <moneromooo> Thanks. Ping me when you're happy with it please.
20:39:11 <UkoeHB> sure