Inge-, sure. but hardforks weren't as straining during the pre ASIC-era

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?

a quick googling indicates its ad hoc.

gingeropolous: Pre-asic the ecosystem also was way smaller

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.

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"

at least in this case, the next window is only 5-6 months away, so full dandelion power will be seen relatively soon

and then triptych will be ready and it'll happen and we'll all have pancakes and want the fork

have some consensus changes and after 9 / 12 months ? -> fork

no consensus changes -> no fork IMO

+1

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.

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

when trying to split inputs, what’s the best number to blend in with mining pools?

split outputs** sorry

KnifeOfPi_: i think the big pools have to split their payments into many transactions, so using the maximum (15 i think) is probably best

The output limit is 16

supportxmr.com if you use the menu in the top right to go to payments

wonderful, we’ll use 16

just trying to consider the privacy implications of an built-in output-splitting function

FWIW there's been discussion on whether it would be useful to extend the limit to 32

(nothing decided AFAIK)

alrighty!

The limit effectively needs to be a power of 2 because of how bulletproofs work

that’s interesting.

we’re trying to design a (semi) automatic output splitting function that preserves privacy

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?

That seems to act against the idea that it's also useful to have available (i.e. unlocked) outputs available for multiple transactions

However, txs with a small number of inputs are also statistically less distinguishable (absent other metadata) based on the chain i/o distribution

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.

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?

Anything distinguishing should be avoided where reasonably possible IMO

Yeah, we’ll definitely go for some kind of uneven distribution then.

Note that unless a large number of implementations follow some atypical pattern, it fingerprints those transactions to a particular implementation

start using standardized denominations when splitting? 1/2/5 10/20/50 etc

could that leak some info about the amounts people are transacting with?

not much, since the actual values are still hidden

e.g., a txn with two outputs oculd as easily be 500+.01 or .05+1000

or whatever else

Even so, I'm sure that a clever analyst could build heuristics against it

and taken to an extreme, it would bloat the chain

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

and lead to poor pre-CT-style scaling

Reminder that #monero-research-lab has a meeting today at 18:00 UTC (about one hour from now)

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.

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"

the recent hardforks were more straining because they required miners to update

without PoW changes, the hardforks weren't really a big deal

majority of ecosystem doesn't run their own nodes, don't need to do anything on most hardforks

User still had to update their wallets with each hardfork

the PoW changes were the only ones that required 100% of ecosystem to move

we will need some dev power in the next month to get dandelion++ and supercop stuff reviewed for v0.15.1.0

then we can discuss HFs :P

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

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

damn, it's been already more than 3 months since the last fork

Meeting in #monero-research-lab begins presently

master branch okay to build from?

yes

eep, getting an error. will post details in a moment

paste.debian.net/hidden/1737b9f3 -- im going to assume boost issue here and it needs updated.

all was fine on my ubuntu 18.04 system (boost 1.65.1)

Most likely.

What's the recommended version of boost now?

Better yet, the minimum version. Readme could use an update on that :)

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.

According to boost source code `boost::asio::ssl::context::tls` got introduced with boost 1.64

Would it be smart to add `#if BOOST_VERSION` or just update min boost to 1.64?

for 16.04, pretty sure we'd have to do the additional boost steps (steps found under raspian jessie).

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

I think I'll wait until April, at least :)