00:15:02 <gingeropolous> Inge-, sure. but hardforks weren't as straining during the pre ASIC-era
01:57:22 <gingeropolous> moving from conversation in GUI again. How often does ETH hardfork? Do they just make a big hooplah about the forks? Or is there a schedule?
02:00:27 <gingeropolous> a quick googling indicates its ad hoc.
09:48:22 <dEBRUYNE> gingeropolous: Pre-asic the ecosystem also was way smaller
12:04:38 <gingeropolous> luigi1111, binaryFate , dEBRUYNE , .... ok, im being persuaded and assuaged. I guess what I want to hope for is that if we switch to a yearly (or 9 month) schedule, that even in the absence of necessary consensus changes, that a version change still occurs.
12:06:50 <gingeropolous> i.e., i'd hope that we don't find ourselves in 2 years going "well, lets just leave it alone because 1 year ago, don't you remember? It was stressful and everyone got indigestion"
12:10:08 <gingeropolous> at least in this case, the next window is only 5-6 months away, so full dandelion power will be seen relatively soon
12:11:02 <gingeropolous> and then triptych will be ready and it'll happen and we'll all have pancakes and want the fork
12:12:45 <selsta> have some consensus changes and after 9 / 12 months ? -> fork
12:12:54 <selsta> no consensus changes -> no fork IMO
12:15:02 <dEBRUYNE> +1
12:17:09 <gingeropolous> fascinating. the thing that has provided monero a mechanism to employ continued votes of confidence .... weird is all im saying. this just feels weird. but i guess i'll just live in my little weird bubble.
12:30:35 <Inge-> I can understand and agree with the need for protocol agility still. But it also seems to me that htere is a consensus that over time, the amount of disruptive relases will fall in number / be spaced out more. i.e. there has been talk about moving from 2x a year to 1x a year
15:35:41 <KnifeOfPi_> when trying to split inputs, what’s the best number to blend in with mining pools?
15:35:50 <KnifeOfPi_> split outputs** sorry
15:37:08 <asymptotically> KnifeOfPi_: i think the big pools have to split their payments into many transactions, so using the maximum (15 i think) is probably best
15:37:23 <sarang> The output limit is 16
15:37:25 <asymptotically> https://supportxmr.com/ if you use the menu in the top right to go to payments
15:38:11 <KnifeOfPi_> wonderful, we’ll use 16
15:39:19 <KnifeOfPi_> just trying to consider the privacy implications of an built-in output-splitting function
15:39:36 <sarang> FWIW there's been discussion on whether it would be useful to extend the limit to 32
15:39:40 <sarang> (nothing decided AFAIK)
15:39:53 <KnifeOfPi_> alrighty!
15:39:54 <sarang> The limit effectively needs to be a power of 2 because of how bulletproofs work
15:40:16 <KnifeOfPi_> that’s interesting.
15:40:37 <KnifeOfPi_> we’re trying to design a (semi) automatic output splitting function that preserves privacy
15:41:46 <KnifeOfPi_> would it be beneficial to not evenly split the outputs, so that it’d almost always be possible to construct a transaction using a small number of inputs?
15:48:47 <sarang> That seems to act against the idea that it's also useful to have available (i.e. unlocked) outputs available for multiple transactions
15:50:51 <sarang> However, txs with a small number of inputs are also statistically less distinguishable (absent other metadata) based on the chain i/o distribution
16:30:10 <KnifeOfPi_> Well, you’re right sarang, the point is to create a happy medium. Probably, the biggest output would try to be around 1/3 of the total wallet amount.
16:30:46 <KnifeOfPi_> In the worst case scenario, if thousands of users use this feature, and all of their transactions stick out with too many inputs, would it harm the overall blockchain’s privacy at all?
16:31:18 <sarang> Anything distinguishing should be avoided where reasonably possible IMO
16:32:24 <KnifeOfPi_> Yeah, we’ll definitely go for some kind of uneven distribution then.
16:32:54 <sarang> Note that unless a large number of implementations follow some atypical pattern, it fingerprints those transactions to a particular implementation
16:50:50 <hyc> start using standardized denominations when splitting? 1/2/5 10/20/50 etc
16:52:48 <UkoeHB_> could that leak some info about the amounts people are transacting with?
16:53:21 <hyc> not much, since the actual values are still hidden
16:54:19 <hyc> e.g., a txn with two outputs oculd as easily be 500+.01 or .05+1000
16:54:27 <hyc> or whatever else
16:57:47 <sarang> Even so, I'm sure that a clever analyst could build heuristics against it
16:58:00 <sarang> and taken to an extreme, it would bloat the chain
16:58:05 <UkoeHB_> Im thinking of some EAAE cases or similar, where eve might learn a lot about how much is contained in the outputs she doesnt receive back
16:58:07 <sarang> and lead to poor pre-CT-style scaling
17:05:27 <sarang> Reminder that #monero-research-lab has a meeting today at 18:00 UTC (about one hour from now)
17:37:30 <binaryFate> gingeropolous: I'd prefer not to force a fork if there is no consensus change personally. We can present it as the half-way smooth transition to one-per year regular upgrades.
17:39:01 <binaryFate> would be awkward to chase services and exchanges (it's more and more tedious) so they upgrade and when they ask what are the changes technically are we say "no change to consensus, we just enforce it so you keep having the right habits"
17:47:06 <hyc> the recent hardforks were more straining because they required miners to update
17:47:24 <hyc> without PoW changes, the hardforks weren't really a big deal
17:48:00 <hyc> majority of ecosystem doesn't run their own nodes, don't need to do anything on most hardforks
17:48:12 <sech1> User still had to update their wallets with each hardfork
17:48:13 <hyc> the PoW changes were the only ones that required 100% of ecosystem to move
17:52:18 <selsta> we will need some dev power in the next month to get dandelion++ and supercop stuff reviewed for v0.15.1.0
17:52:29 <selsta> then we can discuss HFs :P
17:52:30 <hyc> anyway, for the moment it feels like we should continue to keep a 6 month schedule, with the option to waive hardfork if there's nothing pending on a particular interval
17:54:50 <binaryFate> Agree with 6 month schedule for release, but I don't find forcing a consensus fork when there is no need appealing. All exchanges if nothing else use their own nodes and it's quite hard now to get them to update in time
17:55:00 <sech1> damn, it's been already more than 3 months since the last fork
17:59:23 <sarang> Meeting in #monero-research-lab begins presently
18:53:14 <camthegeek> master branch okay to build from?
18:55:44 <selsta> yes
18:57:52 <camthegeek> eep, getting an error. will post details in a moment
19:23:06 <camthegeek> http://paste.debian.net/hidden/1737b9f3/  -- im going to assume boost issue here and it needs updated.
19:23:32 <camthegeek> all was fine on my ubuntu 18.04 system (boost 1.65.1)
19:24:05 <moneromooo> Most likely.
19:34:15 <camthegeek> What's the recommended version of boost now?
19:34:49 <camthegeek> Better yet, the minimum version. Readme could use an update on that :)
19:43:46 <iDunk> Same error here with 16.04. Looks like #6205 broke it. It would be nice to know the new minimum boost version and update CMakeLists.txt and the readme.
19:48:08 <selsta> According to boost source code `boost::asio::ssl::context::tls` got introduced with boost 1.64
19:52:07 <selsta> Would it be smart to add `#if BOOST_VERSION` or just update min boost to 1.64?
19:52:40 <camthegeek> for 16.04, pretty sure we'd have to do the additional boost steps (steps found under raspian jessie).
19:53:32 <iDunk> https://github.com/monero-project/monero/blob/master/CMakeLists.txt#L856-L860
19:59:12 <camthegeek> Not sure on the resolution you guys are going to take on this.. but I think I'm going to upgrade my OS. It's overdue anyways :p
20:00:01 <iDunk> I think I'll wait until April, at least :)