Monero Dev Meeting Note Highlights – 2019-03-24
Logs
351 lines
dEBRUYNEIt's 5:00 PM utc, let's begin
dEBRUYNEI made a few notes, that I think will be worthwhile to start the meeting
dEBRUYNE- The tweaks are inherently centralizing and potentially dangerous. They thus need to stop.
dEBRUYNE- Dual PoW, in its current form, is considered unsafe and therefore undesired.
dEBRUYNE- The path of least resistance seems to be adopting RandomX as soon as viably possible (October perhaps) and switching to SHA3 in case it fails (i.e. no pre-commitment to SHA3 unless RandomX fails) or switching to SHA3 when the tail emission starts.
dEBRUYNE- In order to be proactive, we need a back up plan in case RandomX fails. Preferred current back-up plan seems to be SHA3, as a RandomX failure would mean we've basically exhausted our options.
dEBRUYNE- In case RandomX fails, no further tweaks should be made.
dEBRUYNE- We need to come up with some heuristics that define failure. In my opinion, the easiest heuristic is ASIC miners taking over the network and thus driving out all other miners, thereby showing a significant efficiency advantage.
dEBRUYNEIf anyone has remarks, please let them hear and let's start :)
moneromoooTweaks are no more centralizing and potentially dangerous than randomx.
moneromoooIf you disagree, you get to give arguments for it.
hycrandomX has been in development longer than 6 months
el00ruobuob_[m]"ASIC miners taking over the network" would you use the "unknow hash" metric here?
hycand won't be changing every 6 months
tevadorI should add that there are ways in which RandomX could be tweaked in the future if it lasts a few year to match the progress in CPU design
fluffyponymoneromooo: they are highly centralised, they require a small group of people to collaborate on it and dictate what the network should do
gingeropolous"the easiest heuristic is ASIC miners taking over the network" how will we get evidence of this? there's some thoughts that what we saw recently wasn't asics but some kind of fpga
vp11It might be hard to define how ASICs are in the network. Maybe if the top CPU in the market not becoming profitable anymore? That would mean no normal user should be profitable do we can assume ASICS are in the network
dEBRUYNEAlso tweaks have to occur every 6 months, whereas RandomX envisions to be a long-term algorithm
moneromoooI dispute not the claim they are centralized, but the imlication that randomx is better because of it.
gingeropolousare the pow forks more or less centralizing than the consensus changes we've been making every 6 months regardless of PoW?
dEBRUYNE+ we can let it get audited
dEBRUYNEgingeropolous: Definintely more in my opinion
fluffyponymoneromooo: fair - I don't have strong feelings on RandomX
hycre: ASIC miners taking over the network - are we relying on miners to self-report?
hyc"Hey, my profitability sucks, I'm abandoning XMR and mining something else now"
dEBRUYNEI don't think we should absolutely rely on that, but we can certainly take it into account as a factor
el00ruobuob_[m]hyc, https://minexmr.com/pools.html should give a good idea of how profitable for random miner it is.
endogeniccan we examine the question of whether randomx has as much flexibility in being tweaked as the existing algo?
sech1steep increase in hashrate (and profitability drop) without price changing is a strong indicator of more efficient hardware (ASICs)
ArticMineI see the reason behind tweaks as key here. Making a hard fork to improve the algorithm makes sense. Changing the algorithm for the sole purpose of breaking ASICs with no improvement is a no no
el00ruobuob_[m]the more "unknown" source of hasrate there is, the worst it is.
moneromoooIdeally all hash rate would have an unknown source.
dEBRUYNE^ I disagree with that one actually
dEBRUYNEIt's an easy metric to be gamed
dEBRUYNE(was referring to el00ruobuob_[m], not moneromooo)
fluffyponyel00ruobuob_[m]: profitability is trivially gamed
jtgrassie"unknown source" is a terrible metric.
gingeropolous^
oneiric_could have been private pools or temp switch of large mining farms too
el00ruobuob_[m]so what kind of metric?
fluffyponyel00ruobuob_[m]: no clue, it's been ENTIRELY subjective thus far
jtgrassieIt just means an unlisted pool or solo-miners
dEBRUYNEthere's some thoughts that what we saw recently wasn't asics but some kind of fpga <= Does that matter though? A single group secretly gaining the majority of the network hashrate is inherently bad
hyc^ agreed with dEBRUYNE
dEBRUYNEel00ruobuob_[m]: we're trying to discuss probable heuristics currently
oneiric_it matters in the approach taken to counteract
hycwe don't care if it's ASICs or FPGAs, if it's not CPUs or GPUs it's a threat
gingeropolous^, agreed, but … it'd be nice to get specific
moneromoooChanging the algorithm to prevent a 51% makes sense to me. That is a definite, explicit improvement.
dEBRUYNEOne more note I forgot to add, tevador recently changed some parameters for RandomX, which significantly improved verification time -> https://github.com/monero-project/meta/issues/316#issuecomment-475651654
gingeropolousis this the 4 gb to 1 gb switch?
oneiric_if it was fpga, reaction should be different than a big cpu farm swatiching over
fluffyponythat makes me happy
tevadorverification time is on par or better than CN
dEBRUYNEgingeropolous: 2 GB iirc
tevadormuch better on low end hardware
hycyes, 4GB to 2GB
fluffyponymoneromooo: out of interest, what would it take to make you comfortable with RandomX?
rbrunnerYes, 4 GB was crazy
moneromoooI'm not sure. I also have not looked at it yet.
dEBRUYNEmoneromooo: Whilst I agree, last time the entity had already gained the majority of the hashrate before we set a fork date with a new PoW tweak
dEBRUYNEImo we were just praying at that point they wouldn't do anything malicious
needmoney90^
needmoney90Agree, that was an uncomfortable period of time
fluffyponyyeah
gingeropolousaye
moneromoooI'm not necessarily unfomfortable with it per se. I'm more opposed to the claim that it is less centralized and dangerous, at least without good arguments.
fluffyponythat said, I don't think RandomX solves the economies of scale problem at all
hyc^^ probably true
dEBRUYNEmoneromooo: Arguably it is less centralized because we don't have to change it every 6 months
gingeropolouswell, for me, the commodity hw PoW has an interesting thing in that scenario, right?
fluffypony^^
needmoney90Switching the PoW at the same time as making consensus changes is basically forcing compulsory adoption of those changes, it centralizes everything with the devs
dEBRUYNERandomX envisions to be an algorithm which can sustain ASIC resistance for a long time
moneromoooYou're guessing as much as we did before.
needmoney90I've been thinking about this for a bit now
fluffyponygingeropolous: there is no such thing
ArticMineThere is a good change it will lead to ASIC co existence rather than domination
gingeropolousif we supposedly had some massive hr gain and we're locked into randomx, someone could buy a bunch of server time etc.
fluffyponyany "commodity hardware PoW" will cease to be "mostly commodity hardware" within short order if Monero continues to become increasingly valuable. it's a battle that is already lost, give it up.
gingeropolousif its gets to that situation in an asic dominated networ, what then?
dEBRUYNEArticMine: Depends on what kind of efficiency gain they get though
ArticMineThat is the fundamental key
dEBRUYNEI think this is a reasonable heuristic -> <sech1> steep increase in hashrate (and profitability drop) without price changing is a strong indicator of more efficient hardware (ASICs)
dEBRUYNEEspecially if it drives out all other miners
hyc^ makes sense
gingeropolouswhat happens if , in a world where we go sha3, we figure out the network is pwned?
ErCiccione[m]dEBRUYNE: I agree that's the best way to look at it
fluffyponygingeropolous: pwned by whom? at 7nm the ASIC performance gap evens out
ArticMineIt also means if I can say 30% of my home heating bill I mine but for only 0.5% why bother
ArticMinesave
vp11But then, again, ASICS coexistence might even be desirable if they’re not hundreds times faster than the fastest cpu on market
moneromoooASICs are good if they do not cause a party to have control over too much of the network hash rate.
ArticMineIt is better than no ASICs
midipoetcan i ask how likely it would be that someone develops an ASIC for SHA-3 with substantial efficiency gaines, before everyone else, patents it, secretely mines with it, and leads us to exactly the same situation with regards the potential for 51%?
fluffyponygingeropolous: and if a single entity amasses 70% of all the hashrate in existence at 7nm then, frankly, they have enough money to amass 70% of the hashrate regardless of what we do - depressing, but true
oneiric_dEBRUYNE: that does make sense. sech1 what metric would one use to tell the difference b/w fpga & asic?
gingeropoloustrue fluffypony , true
dEBRUYNEoneiric_: Arguably, if RandomX is dominated by FPGAs, it may make more sense to switch to SHA3
gingeropolousbut its pow, so its a constant burn. so it would have to be a long fight
fluffyponymidipoet: we're pretty close to 7nm, which means that improvements from competitors will be marginal - the braintrust in the big players is substantial
gingeropolousif its an asic world, its no different than a PoS world
sech1oneiric_ FPGA can't be efficient at RandomX, forget it
ph4r05moneromooo: you are right about the "const size_t len_chunks"
gingeropolousasic dominated is PoS, there i said it
fluffyponygingeropolous: word
dEBRUYNEfluffypony: Especially with an algorithm such as SHA3
needmoney90dEBRUYNE: I'm not sure. FPGA commoditization is at least a discussion avenue that's relatively unexplored.
dEBRUYNEWhich is one of the simplest algorithms
oneiric_can you give some details?
needmoney90I realize they aren't even really commoditized yet, which makes it more concerning
xmrmatterbridge<learninandlurkin> Surely that heuristic could could be games easily. If the ASIC Dev knew we would switch to their preferred algorithm the moment there is a spike in HR, it would be in their interest to cause such a spike for delayed profits.
oneiric_saw hyc's softcore post, is it for those reasons?
tevadordEBRUYNE: FPGAs cannot run RandomX at anywhere near CPU efficiency
sech1oneiric_ yes
fluffyponylearninandlurkin: which heuristic?
oneiric_ok thanks
dEBRUYNEtevador, sech1: Thanks for clarifying
dEBRUYNEfluffypony: This one -> <sech1> steep increase in hashrate (and profitability drop) without price changing is a strong indicator of more efficient hardware (ASICs)
fluffyponyoh, yeah
fluffyponythey could just hire a botnet to cause a spike
ArticMinefluffypony We need to consider 3D chips both on the ASIC and non ASIC side 7 nm is not a limit
dEBRUYNEfluffypony: Do you think there would be botnets out there that would be vastly bigger than Monero's total hashrate?
dEBRUYNEBecause that's what needed to increase the hashrate steeply
oneiric_guess my question applies now though, how would one tell the difference b/w fpga and asic being responsible for hash increase?
dEBRUYNEI am kind of skeptical about that
fluffyponyArticMine: 7nm is a pretty practical limit right now
hycwhat would that botnet have been doing before they hired it? why would it not have been mining the whole time?
ArticMinebut not long term
oneiric_pre-cnr
fluffyponydEBRUYNE: no clue, maybe Craig Wright's supercomputer :-P
dEBRUYNEHah
moneromoooBotnets spawn. It might not have existed before.
fluffyponyhyc: could be hiring a few botnets that were doing other things before
ArticMineINTEL is looking at 3D for this ear
ArticMineyear
midipoetgingeropolous: if "asic dominated" is essentially POS - just in a different format, then i hate to say it, but its a very big waste of energy.
hyconeiric_: FPGA would be on par with GPU. not better. FPGA is irrelevant.
needmoney90For sure Hyc?
fluffyponymidipoet: non-ASIC is essentially PoS
fluffyponymidipoet: that's how economies of scale work
oneiric_ok, so no way a fpga farm could have looked like asics?
fluffyponymidipoet: the people with the most money win
tevadorArticMine: it's still many years away and no ASIC manufacturer will use immature technology
gingeropolousi meant in the attack vector. you buy asics once, they work, you own the network
ArticMine3D is already in our cellphone
gingeropolousin a non-asic network, you develop asics, but others can do other stuff
gingeropolousi really don't understand keeping the keys to the system behind a locked door
midipoetfluffypony: not if the hardware requirements meant that mining could be a "side" process as apposed to a fixed process
fluffyponymidipoet: we already tried background mining, nobody is going to do it
gingeropoloushonestly, i can't get the argument, so i just gotta watch this from afar. good luck everyone!
fluffyponymidipoet: even if they do, they will be out-competed by manufacturers spinning up boards with 36x embedded GPUs or whatever
fluffyponyat ~some high marketcap it becomes feasible to do so
xmrmatterbridge<learninandlurkin> In the interest of adding some structure to the debate/meeting, might it be a good idea if the RandomX folks can describe the state of RandomX, their own detailed opinions, maybe how close to audit-ready it is. Then everyone else can comment upon that and work from there?
ArticMinefluffypony At a high enough marketcap ASIC become competitive with RandomX I agree with that. the real question is by how much
rbrunnerYes, a state summary would be really nice
hyctevador?
tevadorwe have more or less complete specification here: https://github.com/tevador/RandomX/blob/master/doc/specs.md
tevadoralso design notes: https://github.com/tevador/RandomX/blob/master/doc/design.md
sech1RandomX has working implementation and documentation
tevador+ working code of course
sgp_Can someone link the chart I made? It's a good overview
fluffyponyArticMine: it's not ASICs necessarily, could just be large custom boards with embedded GPUs suspended in oil, mining on "free" renewable energy in sub-zero climates, which leads to either (1) hashrate is dominated by a single entity, or (2) if commercialised it completely crowds out home miners
hycI've been rustling the bushes of CPU/hardware design forums looking for reviewers/auditors
xmrmatterbridge<learninandlurkin> But maybe for people who haven't poked their heads into #monero-pow in a while, what's recently been going on? I saw there were some interesting test results from many people
dEBRUYNEWould it be preferable if the community hired an audit firm to perform an audit of randomx? We could ask either kudelski or quarkslab
tevadorcode includes: reference interpreter (portable, but slow), x86 JIT compiler for fast verification and mining
dEBRUYNEAdditionally, I think wownere is set to implement RandomX on their mainnet, which should yield some test data as well
fluffyponydEBRUYNE: are either of them well-suited to it?
dEBRUYNEfluffypony: Well, there's two reviews needed basically
fluffyponyI wonder if Halong or Innosilicon or whoever would be up to audit it for pay
dEBRUYNE1. We need to review the algorithm for bugs / exploits etc.
ArticMinefluffypony Yes I agree but again the question again becomes what is the advantage
hyc^ good suggestion but I wonder about their incentive to be forthright / honest
dEBRUYNE2. We need to review the algorithm with a view of how asic resistant it is
fluffyponyhyc: true
xmrmatterbridge<learninandlurkin> I think hardware experts would be needed as well as traditional code auditors, for sure
dEBRUYNEfluffypony: I think Tim Olsen wanted to provide a free review of RandomX
oneiric_a prof crypto consulting firm with pow specialists would be good
tevadorTim Olson promised a free review, but hasn't delivered yet
fluffyponyoneiric_: there isn't really such a thing
oneiric_erm
ArticMineThe small player can get effective free electricity by displacing electric resistance heating for example
oneiric_im almost certain there is
midipoetwe should make one!
ArticMineor surplus solar power
midipoetlol
fluffyponyoneiric_: a "PoW specialist" ?
oneiric_yeah pow been around for before cryptocurrency
fluffyponyyes but largely ignored
oneiric_surely there is a consultancy firm with such an expert
fluffyponyAdam Back is about the closest you'll get to a PoW expert :-P
oneiric_if that's accurate, we should get him
dEBRUYNEBtw, we also have to think about what course of action to take if we get a report from an expert that clearly states the algorithm wouldn't hold
xmrmatterbridge<learninandlurkin> Surely that depends on the nature of the failure
jtgrassieI dont think we need a PoW expert, rather a hardware expert.
tevadordepends on what you mean by wouldn't hold
sech1This expert should also propose ways to improve RandomX
jtgrassie^ excatly
jtgrassie*exactly
tevadorTim Olson said a good estimate of ASIC efficiency requires several months of work on the design and costs six figures
dEBRUYNEtevador: basically a large efficiency advantage that would surely drive out all other miners
oneiric_jtgrassie: disagree, domain specialization is key in cryptanalysis
dEBRUYNEx4-x5 and you can be reasonably sure that all other miners are driven out
fluffyponyjtgrassie: I agree
fluffyponyjtgrassie: a hardware designer, someone who's actually built ASICs from algorithms
oneiric_also would prefer outside the monero-sphere
oneiric_someone known independent from the community
ArticMinex5 means a 20% rebate on my heating bill in XMR
dEBRUYNEfluffypony: The problem is to find someone reliable though :-P
jtgrassieoneiric_: this is about efficiency to perform a hash though on certain hardware rather than consensus.
fluffyponyI know that OhGodAGirl / Kristy-Leigh Minehan has glanced at it
xmrmatterbridge<learninandlurkin> six figures? can the CCS take that in a bear market? might take longer than october lol
fluffyponyand I can ask her how much she'd charge to give it a thorough look
oneiric_its also about the cryptographic strength of a new hashing algo jtgrassie
fluffyponyoneiric_: cryptographically it's fine
dEBRUYNEoneiric_: I think it uses well known algorithms
fluffyponythe underlying hash is Keccak or whatever
dEBRUYNEtevador can probably clarify
tevadorit uses Blake2b under the hood
oneiric_has a pro cryptographer outside monero signed off on that?
fluffyponyoneiric_: it's pretty easy to see that internally
oneiric_in unique and new ways
tevadorbasically we need 2 reviews: one will include only the specification and the other one will review the code for bugs
oneiric_my point is, until an outside professional looks at it, would just be taking your word. no offense
fluffyponythe contention isn't whether it correctly uses Blake2b, but whether it'll survive first passes by ASIC designers
hycany auditor can do the bug review
xmrmatterbridge<learninandlurkin> with hardware/ASIC/PoW "experts" being needed for the spec review?
midipoetand also a review by an ASIC designer, no?
dEBRUYNEtevador: I fear a specification review will still be somewhat subjective
fluffyponyoneiric_: there are enough people in this room that can confirm that, we don't need to waste time on that
dEBRUYNEAlso a reviewer might miss stuff
dEBRUYNEWe won't know how asic resistant it actually is until we see it in practice
oneiric_again my point is they shouldn't be in this room
dEBRUYNEmidipoet: that's basically specification review
midipoetdEBRUYNE: ok, thanks
hycyou really aren't going to know unless you pay a hardware design house to actually design an ASIC for it
oneiric_the point of a review isn't to pat oneself on the back. it's to have a disinterested party look at the code/algos critically
hycand see what it's projected performance and cost are
oneiric_+1 to hyc's point
dEBRUYNEoneiric_: That's basically covered by a code review
fluffyponyoneiric_: you're focusing on the wrong aspect - if you don't trust the people in this room to get something that basic right then you should be reviewing PRs, many of which have only my review on them before they're merged
ferretinjapanoneiric_, not everyone in this room is on the same side. Theres plenty of sceptics alreay here.
midipoetis paying a HW deisgn house to design an ASIC out of the question?
dEBRUYNEOne more thing we have to keep in mind is that we cannot stop the network and have to decide on what to do in October within a few months. Would people prefer another tweak or implementing RandomX (it is probably ready by then)?
oneiric_ok, maybe what i said is coming off wrong. i didn't mean any devs didn't know how to use blake2b, that's dumb. i was saying whoever does the audit shouldn't be associated with monero-project at all
rbrunnerAny idea of cost of that ASIC design? six figures?
fluffyponymidipoet: they'd charge us for tape-out probably
dEBRUYNEI personally think the tweaks ought to stop, hence my preference for RandomX
fluffyponyso call it $1m+
tevadorjust a 16 nm mask costs ~5M
dEBRUYNEoneiric_: An external audit firm will be hired to review the code
fluffyponytevador: we can work at 28nm for this purpose, surely
hycI would stop short of prodction, just get a design that runs in a simulator is fine
fluffyponyit's just to get a feel on how it would perform
dEBRUYNEhyc: Even that would be quite costly I think
hycyes, but probably under $1M
xmrmatterbridge<learninandlurkin> So could we maybe get Tim Olson & Kristy-Leigh Minehan and whoever else people know into a meeting to talk about the practicalities of a spec review and/or ASIC commissioning?
dEBRUYNEI don't think the community would be able to fund $500k at the moment though
dEBRUYNEEspecially given that we have a lot of other proposals seeking funding as well
hycTim has declined the project for pay
tevadorfunding an ASIC design for RandomX makes no sense
tevadorwe need some experts to review the specification
dEBRUYNEHopefully Tim Olsen will provide the review soon, that would already set us a big step forward
rbrunnerWell, and if the only way to get them to seriously review *is* making an ASIC design?
hyctevador: so far we've had several experts give casual response. I'm not sure anything less rigorous than a working design will tell us more
oneiric_an expert look at specs + design + impl could produce better results than a "casual response"
oneiric_or you're paying the wrong firm
tevadorthe problem is finding those experts
oneiric_agreed, doesn't seem easy
xmrmatterbridge<learninandlurkin> what have those casual responses been like? any valuable and constructive suggestions so far? and negative responses?
tevadorLinzhi already refused to make any comments about RandomX because they clearly don't want it adopted
rbrunner:)
xmrmatterbridge<learninandlurkin> Just "we can 10x this, I swear", right?
hycright
oneiric_mebbe they can
tevadorcausal responses from Tim Olson were "you are on the right track"
midipoetASIC designers would also have the incentive to tell you its an effective design, even it it wasnt.
oneiric_yeah, another narrowing of the candidate field
hycyes, we already touched on this. element of trust is lacking.
tevadoralso we have modified the design slightly based on critical reviews on one hardware forum
ArticMineor if they are hones refuse to comment
ArticMinehonest
kovri-slack<woodser> Just voicing my support for RandomX, being the best known asic resistant option we have. If it fails an audit or in practice, and nothing better has come along, then I’d support throwing in the towel with an asic friendly algorithm.
xmrmatterbridge<learninandlurkin> link? I doubt I'll understand it but could be valuable for the logs
xmrmatterbridge<learninandlurkin> to the hardware forum discussion I mean
endogenichow about gmaxwell's criticisms of algos like randomx?
fluffyponywoodser: ProgPoW has good pedigree too, so I would say it's among the best
dEBRUYNEfluffypony: There is some speculation ProgPow is finetuned for Nvidia though
kovri-slack<woodser> @endogenic can you reference or elaborate on gmaxwell’s criticisms of algos like randomx?
xmrmatterbridge<learninandlurkin> If we just wait for the inevitable collapse of ETH, we would have the option of switching to ProgPow without being minority chain! lol
tevadortake those responses with a grain of salt, though
xmrmatterbridge<learninandlurkin> thanks I'll bookmark for reading
tevadorthe only valuable thing was their criticism of the lack of branches in RandomX, which we have since fixed
hycright, most of those responses are hand-waving. the devil is in the details, and none of them will account for the details.
rbrunnerHah, in 10 years we will have a Spectre-like bug in RandomX
hyclol
onlycoffeedidn't randomx change on their nonce grinding suggestion?
hycrandomX changed nonce approach based on gmaxwell critique
ferretinjapanrbrunner, that assumes monero is still around in 10 years :P
onlycoffeealright, so they did have some fair criticisms, which I think can be summarized as concerns over non-obvious "shortcuts" in the algorithm
hycwe're coming up on 50 minutes. what do we need to accomplish in this meeting? action items?
tevadormore like shortcuts in the design of an ASIC
tevadorcompared to a CPU
tevadorwe should find reviewers
hycI am still searching for reviewers
ArticMinecan we come up with an action plan. or example RandomX if fail then SHA-3?
rbrunnerI am a little wondering that nobody drives in and shouts bloody murder on behalf of GPU miners …
dEBRUYNEArticMine: That's one thing I wanted to discuss in this meeting
hyc … due to the controversy around progpow I would prefer to avoid hiring Kristy-Leigh for this
vp11But then we need a very clear definition of “failure”
dEBRUYNEAs far as I can see, the path of least resistance in the (Dev) community is either:
xmrmatterbridge<learninandlurkin> Touching on a point dEBRUYNE brought up, if getting proper reviews/audits stalls and the network is rekt before October, could CN-R be tweaked as a stopgap?
vp11Because you don’t want people saying “oh well I don’t consider this as a failure” and divide the community.
jtgrassie^ hyc ditto
dEBRUYNE- Implement RandomX, switch to SHA3 in case RandomX fails, do not precommit to a set date
dEBRUYNEor:
ferretinjapanvp11, indeed.
dEBRUYNE- Implement RandomX, switch to SHA3 in case RandomX fails, precommit to a set date for SHA3
dEBRUYNEvp11: The metric sech1 described is probably the best we can get in my opinion
ArticMineI would say Implement RandomX, switch to SHA3 in case RandomX fails, do not precommit to a set date.
dEBRUYNEAlso if an asic manufacturer, for some reason, publishes an actual device, we can compare efficiency numbers
rbrunner- Implement RandomX, do not yet pre-commit to any further action because too early / too unsecure?
dEBRUYNErbrunner: We have to be proactive, not reactive imo
dEBRUYNEfluffypony explained why in the Github issue (#316)
oneiric_rbrunner: gpu miners probably realize their concerns will be ignored anyway
xmrmatterbridge<learninandlurkin> the second option seems like a contradiction because how can you only switch in the case of failure, yet also have a predetermined date to switch?
ferretinjapanproactive can't predicct the future is the problem there.
tevadorit would be better to say there will be no reactive tweaks anymore, so we can at least see the ASIC being offered publicly…
fluffyponyferretinjapan: and reactive is centralised
fluffyponychoose the lesser of two evils
dEBRUYNElearninandlurking: if it fails before the precommited date
kovri-slack<woodser> I don’t see how we can commit to a date without knowing if it will be necessary
ferretinjapanfluffypony, indeed, theres always a tradeoff.
vp11I agree with not precommitting to a date. I think other coins are switching to SHA3 so manufacturers could start hw development without Monero precomitting
ErCiccioneoneiric_: why ignored? i noticed not many in the community seems to be against a cpu-only algo
hycI'm with ArticMine, first option
moneromoooI *really* don't like this "centralised" pseudo argument, when the claimed point of centralization is to remove a greater centralization.
ferretinjapanthe thing is you have more flexibility being reactive.
ArticMineGPU miners win vs ASIC and loose vs CPU. I am not sure they come out as looses with RandomX
jtgrassiehyc ArticMine +1
ferretinjapanproactive could see you walking off alciff too.
dEBRUYNEBeing proactive also means a greater risk of community split imo
ferretinjapancliff*
oneiric_ErCiccione: i noticed anyone voicing concerns about keeping gpu being ignored, ridiculed, or downvoted
dEBRUYNEUh reactive*
fluffyponymoneromooo: there's serious regulatory risk with having a small group of people dictate changes to the network, at worst we're making sure nobody comes after you or I
oneiric_those in control of this community give 0phux bout gpu miners
fluffyponyoneiric_: you're starting to sound like MoneroCrusher :-P
jtgrassiehaha
oneiric_exactly lol
moneromoooAre those risks particularly about PoW, or also about any other consensus change, or also about any major non-consensus change ?
fluffyponyWHEN DUAL POW
oneiric_and it begins
ErCiccioneoneiric_: that's not what i've seen, but i could have missed it. But we are having meetings and multiple discussions on multiple platforms, and i don't see their voice being silenced.
dEBRUYNEoneiric_: As far as I can see, gpuminers are not totally alienated. sech1 estimated a CPU advantage of 2:1 and I think that gap can be closed further by a competent GPU miner developer
vp11Monero can express the intent to switch to SHA3 keeping the two variables that I don’t know the name an incognito which would let manufacturers get almost everything ready “just in case”. Other coins are switching to SHA3 so I don’t really see that much gain by precommitting to a date
dEBRUYNEAlso GPUs are easier to scale
oneiric_didn't say silenced
fluffyponymoneromooo: particularly about PoW because of the need for last-minute changes (or secrecy on tweaks, equally undesireable)
dEBRUYNEvp11: Do you mean Monero will choose it's own custom parameters for SHA3?
oneiric_dEBRUYNE: if thats true i'm all for it
dEBRUYNEwill/can
fluffyponywith non-PoW consensus changes we can plan them well in advance
vp11Yes dEBRUYNE
ArticMinefluffypony I agree which is why a hard fork change has to be justified by overall improvement in the algo
xmrmatterbridge<learninandlurkin> surely these centralisation risks of forks would be somewhat mitigated by reproducible builds? Maybe that should be kicked up in the list of priorities
fluffyponylearninandlurkin: nope, builds don't even factor into it
el00ruobuob_[m]couldn't we: Implement randomX and precommit to a SHA3 ASIC, without a clearly defined date first? And set the date later?
vp11I think Tim Olson commented something about it in the github issue
dEBRUYNEvp11: Yes I remember, that would work I guess
dEBRUYNEThough that doesn't render any 'design' invalid
el00ruobuob_[m]by later, i mean, in a 6 month to 1 year window
rbrunnerI don't understand why people already want to set a fixed successor for RandomX. What if none is needed?
xmrmatterbridge<learninandlurkin> fluffypony: could you explalin why not? Surely it lessens the fundamental reliance on "lead" maintainers and devs, and hence lowers the risks you were talking about?
kovri-slack<woodser> wouldn’t SHA3 be unecessary if RandomX delivers all our hopes and dreams?
moneromoooI believe one of the "legal" tests for a decentralized cryptocurrency is that anyone has a chance at mining. Arguably, not trying to fix a party having » 50% means we stop being such.
dEBRUYNErbrunner: Again, in order to be proactive
vp11Precommitting to a date for me is akin as maybe finding the cure for a disease but kill your patient anyway.
dEBRUYNEwoodser: Yes, but we still need a backup plan in case it fails
needmoney90rbrunner: The point is mainly signalling to the community that forking more than once a year has become untenable, and we need to make a choice if things break
ferretinjapanrbrunner, hence my concerns of "walking off a cliff" someone could manipulate such a timetable.
needmoney90many people assume things are fine
fluffyponylearninandlurkin: it does nothing to lessen the reliance on maintainers and devs - even if every node compiled its own software they're still running software from a "central" repository dictated by the people who work on that
rbrunnerOk, the condition "if RandomX breaks" went missing. With that in I can agree
kovri-slack<woodser> Agreed, then we’d need to clearly signal an action plan
needmoney90Yeah, If RandomX pans out I'm all in, but I'm being realistic that this is basically our last shot
needmoney90and the community needs to realize that
needmoney90the number of people advocating for a 4-6 month fork schedule is insane
needmoney90And they need to be let down gently
rbrunnerA little behind that the whole concept of PoW is put into question, if you ask me
needmoney90thats a bigger discussion
rbrunnerWith no clear alternative in sight, of course
ferretinjapanneedmoney90, that in itself can cause a schism.
ArticMineWe cannot create a dependence on 4-6 months forks.
fluffyponyneedmoney90: I agree
sech1I think "RandomX failed" condition comes true only when there is no debate about it in the community at all. Like when hashrate spiked so much and for so long time that everyone gets 20% (at best) from money spent on electricity.
needmoney90With who? People who want to fork constantly?
needmoney90Let 'em, they wont keep our market cap
needmoney90they cant, we're too big
fluffyponyferretinjapan: anyone who wants 4 month forks are welcome to fork off
fluffypony:-P
rbrunnerLol
midipoetwe could just let ASICS rule Monero, and move the whole community to a brand new implementation of MimbleWimble
ferretinjapanneedmoney90, with trying to give a "gentle" ultimatum
needmoney90the only way to fork that often is to drop the market cap / ecosystem size
needmoney90go for it
ferretinjapanfluffypony, I've never advocated a 4 month fork schedule.
fluffyponyferretinjapan: was joke
needmoney90then you tacitly allow asics if randomx fails
tevadoreven if there was a 2x ASIC, it doesn't require the same response as a 50x ASIC
needmoney90If you advocate asic resistance and not a 4-month fork schedule, you're willfully ignoring reality
ferretinjapaniKnow :) but some people might think I'm opf that mind
fluffyponymidipoet: MW is already coming via Tari, not sure if doubling down on that is helpful - also MW requires interactivity, where Monero does not, it would be a fundamentally different thing
dEBRUYNEsech1: Yeah that sounds reasonable
needmoney90this is not counting randomx of course*
ferretinjapanneedmoney90, aaaand theres the ulimatium :)
needmoney90RX is our prescription for asic resistance
moneromoootevador: if randomx appeared to fail, would you want to continue trying to get a better algorithm, hypothetically ?
tevadordepends on how it fails
midipoetfluffypony: ah i was just joking. i lked the idea od taking all our devs and community and starting on a 2nd/3rd generation tech.
needmoney90Mcash would be interesting, but they'll run into the same issues if they get big
tevadorI wouldn't consider a 2x more efficient ASIC a failure
moneromoooIf it fails by having a party suddenly seem to get close to 50% of the network hash rate.
needmoney90mooo, I think its a "we'll cross that bridge when we get to it" issue
tevadorand we could still make annual PoW upgrade as new CPUs are introduced
moneromoooI'm not asking to start now :)
dEBRUYNEI'd be strongly opposed to an "annual PoW upgrade"
ArticMinea 2x ASIC is not a RandomX failure Would you accept a 50% rebate payable in XMR on your heating cost by running a peice of software on our computer? 30% 10% 5% 1% .1% This becomes the question
dEBRUYNEArticMine: You also have to factor in that not everyone uses their miner for heating
ferretinjapanannual POW would probably be too late.
fluffyponydEBRUYNE: as would I
tevadordEBRUYNE: what time scale would you be comfortable with? no changes at all until the end of time?
needmoney90Anything under annual PoW is basically off the table right now
needmoney90barring emergency forks
needmoney90we can maybe get one more off
dEBRUYNEtevador: Yes, no changes
dEBRUYNEReintroducing tweaks reintroduces the same risks smooth described here -> https://github.com/monero-project/monero/issues/3387#issue-304296870
xmrmatterbridge<learninandlurkin> I think it is clear that even a perfect CPU favouring algorithm would eventually need to be changed, because CPUs will eventually change
dEBRUYNEWhich we're trying to get away from with a long-term algorithm
ArticMineThis is an example why 2x or even 10x may not be a failure. 100x Yes that is a failure
dEBRUYNE10x will invariable drive out all other miners
tevadorwell, what if CPUs start routinely ship with 4 MB of cache per core
ArticMineThere are a host of other situation where a small miner would have an advantage. Excess solar is another case
dEBRUYNEtevador: Aren't we then finding ourselves in a situation where new CPUs are more suitable for the algorithm than old CPUs?
sech1Botnets have 0 power costs, don't forget it. They can always compete with ASICs.
ArticMine10x is marginal
dEBRUYNEI don't think that is necessarily a problem that requires tweaking
ferretinjapanI'll just say I think it's naieve to think that its "randomX because nothing else is viable in the future. Ever.".
rbrunnerI'd like to throw in that looking far into the future is nice and all, but we have an urgent problem *now* - somebody owned our network, and maybe will again …
needmoney90ferretinjapan: If you have any actionable directions as opposed to "its gotta exist because I want it", I'm all ears.
needmoney90we are all ears*
ferretinjapanthat kind if thinking eradicate all future innovateions ever.
dEBRUYNEsech1: Sure, but at some point they only own a negligible amount of the hashrate
dEBRUYNEIn the last 3 months leading up to the hard fork, they were probably still mining, but probably owned only like 5-10%
xmrmatterbridge<learninandlurkin> If newer generation widespread CPUs perform better than older simpler ones, then older simpler ones become a form of ASIC, right?
dEBRUYNE<ferretinjapan> that kind if thinking eradicate all future innovateions ever. <= That seems more like wishful thinking imo
ferretinjapanneedmoney90, you didn't understand what I said. I said taking all options off the table forever is naieve.
xmrmatterbridge<learninandlurkin> but yeah looking that far ahead is kinda pointless right now
needmoney90The ecosystem size and market cap are taking the options off the table, my dude
needmoney90we cant keep forking like this
ferretinjapanDead2, Ring CT is wishful thinking?
ferretinjapandEBRUYNE, ^
dEBRUYNEArguably that's different than PoW algorithms
ferretinjapanthe point is, things improve, even though you ccan't see an alternative right now.
sgp_It's good to have an idea and plan even if it may change
ferretinjapan^
needmoney90you're free to make a coin that forks constantly to resist asics, and piss off exchanges/wallet providers/the ecosystem.
fluffyponyferretinjapan: nobody is suggesting it will never change
hycyeah, saying PoW will never change again is a bit shortsighted
fluffyponybut I think planning for it to change regularly vs. planning for it to change infrequently are different
moneromoooI'd rather pissed off exchanges than a party with 51% of the hash rate.
ferretinjapan^
needmoney90Suggesting you want asic resistance and also not being willing/able to fork more than once a year is a direct contradiction
needmoney90you need to choose one
fluffyponyI also don't think that the Monero protocol should ossify because we need to constantly improve privacy
fluffyponybut I do think that PoW should ossify, for reasons that I hope are obvious
ArticMineThe difference is an improvement POW is no different in this respect. Endless tweaks with no improvement in POW is very different
needmoney90And we can't do the latter
ferretinjapanneedmoney90, you're cutting off your nose to spite your face. You could very well box the entire network into a corner.
xmrmatterbridge<learninandlurkin> A future where we have annual protocol upgrades which occasionally also involve a PoW upgrade to better reflect innovations in the CPU market sounds pretty good to me
dEBRUYNEArticMine: sure, but imo we don't need to tweak if a new generation of CPUs simply outclasses the old generation of CPUs
needmoney90What are you even suggesting ferret?
dEBRUYNEIsn't that basically natural evolvement
xmrmatterbridge<learninandlurkin> at a FIXED date
needmoney90You keep saying "no, reality sucks, choose a different reality"
needmoney90theres only one reality
hycdEBRUYNE: yeah I basically agree with this
ferretinjapanneedmoney90, I've already made myself clear. I said it above.
needmoney90fork every 4 months, I know
ArticMineSo if we find a way to lower the ASIC advantage from say 5x to 1.5x with RandomX that is a valid "tweak"
needmoney90If you dont want 4-month forks, you dont want asic resistance
needmoney90asics will be de facto present on the network
dEBRUYNEArticMine: How do you know that tweak will work out though?
dEBRUYNEOnly practice will tell and we may be at risk of another manufacturer again gaining a x5 advantage
oneiric_needmoney90: even with cnr?
needmoney90im not sure.
ArticMineOne can test an verify ahead of time
needmoney90we'll see
sgp_dEBRUYNE: I think this was a hypothetical example
dEBRUYNEIn my opinion, if RandomX gets overrun by ASICs, we should just switch to an asic friendly algorithm and not try to apply band-aid
needmoney90but I'm suspecting its 4-6m
needmoney90and then asics are out again
dEBRUYNEArticMine: Not fully, only practice can tell
ArticMineOne can also argue intent
oneiric_if cnr keeps at 6+ mo fork, that at least buys time for review + discussion about RandomX and other alternatives
sgp_dEBRUYNE: I think it depends on the circumstances of it being overrun, but I largely agree except for bug-like fixes
kovri-slack<woodser> also agreed
ArticMineIf on the other hand the tweak leaves the ASIC advantage at 5x and only bricks the ASICs that is not a valid tweak
sgp_Agreed
ArticMineThis is the key difference Intent is critical
moneromoooIt is, if the ASICs were, or were threating to be, at > 50% of the network hash rate.
dEBRUYNEWe also have to weigh off the risks involved with a tweak against the risks of switching to SHA3 at that point
moneromoooIt is a short term fix, but it is one nonetheless.
xmrmatterbridge<learninandlurkin> MONERO 2039 NETWORK UPGRADE CHANGELOG: 1) Changed to QuantumX to lower the advantage of Quantum ASIC advantage, and slow the encroachment of the Terminator hoards.
fluffyponyLOL
ArticMinemoneromooo then one tweak followed by SHA-3
dEBRUYNEAt that point it may be better to just introduce SHA3 in a few months
sgp_ArticMine: yes, only as an emergency option to buy ~3 months before SHA3 if needed
oneiric_lol skynet is online
dEBRUYNEIt will be sufficient for manufacturers to tape out a device
dEBRUYNEReacting to a party gaining the majority of the hashrate with tweaking may also raise the possibility of them acting maliciously
moneromoooI am far from confident SHA-3 will lead to a healthy non oligopolistic market. Though it might, but that's wholesale speculation.
midipoet^
needmoney90I do not disagree mooo
moneromoooAnd it loses us the "ease of starting mining", for sure.
rbrunnerAgree
midipoetat tpd
dEBRUYNEDon't disagree either, but I think it's a better option than trying to apply band-aid to RandomX in case it fails
hycagreed. that's why I've opposed any plan that unconditionally says "we shift to SHA3"
dEBRUYNETo kind of conclude this subject, I think most are in favor of "- Implement RandomX, switch to SHA3 in case RandomX fails, do not precommit to a set date" right?
xmrmatterbridge<learninandlurkin> It really really depends on the nature of the failure and the band-aid. Audits, audits, audits….
oneiric_maybe, but maybe the market matures enough in the next 1-2 years that asic-friendliness makes sense. maybe it doesn't. agree with flexible algo for asic-friendly
midipoetunless we manfacture SHA-3 ASICS. but am not sure how that worked for SIA.
dEBRUYNEBand-aids are per definition tweaks, which we're arguably trying to get away from
dEBRUYNEmidipoet: SIA is a poor example, they forked off other manufacturers that made more efficient devices
dEBRUYNEAlso they used a relatively complex algorithm
fluffyponyI'm of the opinion that we need to precommit to a SHA-3 date so that manufacturers start working towards it
jwintermmoneromooo: I agree, but I think I'm more confident that sha3 will lead to a non-oligopolistic market than I am that randomx will not lead to a single entity producing custom hw leading to that entity controlling 51% of the network hashrate
hycfluffypony: there are already other coins using SHA3
fluffyponyhyc: no, there really aren't
fluffyponyShitcoin #7 doesn't count
hycwhy do manufacturers need to wait for us?
sgp_Two tweak types: 1) narrow ASIC advantage, 2) break existing ASICs. I think most agree 1 is highly preferable to 2
jwintermmax keiser would like a word with you fluffypony
fluffyponylol jwinterm
needmoney90Fluffypony, keccack has some actual adoption
oneiric_fluffypony: what about not committing to algo, and selecting one that has highest likelihood of adoption at the time of the decision?
needmoney90not top-20 adoption
vp11Band-aids are different from technological evolution too. ArticMine is correct that we should be open to improve the algorithm even if ASICS are not dominating. We don’t need a schedule for that nor a specific PoW fork. This could be added to a “normal” network upgrade.
dEBRUYNEvp11: "improvement" is a tweak
needmoney90nvm, keccack has no real adoption
dEBRUYNEAnd who can objectively determine that it is an improvement?
oneiric_keccack is used by eth no?
needmoney90statement retracted its all garbage
fluffyponyneedmoney90: was about to say
fluffyponylol
xmrmatterbridge<learninandlurkin> Not really a tweak if it's something like "Made the Randomness of RandomX more Random"
ArticMinefluffypony A few months is all manufactures need. Pre commit makes no sense if RandomX is working
dEBRUYNEI thikn a lot of people are underestimating the risks involved with a tweak
needmoney90^^^^^^^^^
vp11These improvements can be tested in stagenet, test net, other coins, etc.
fluffyponyArticMine: for them to truly compete and reduce large differences they need more time
fluffyponythe arms race is about being first to market
oneiric_+1 for Articmine
jwintermsha-3 ip is available through numerous asic producers (not just cryptocurrency asics), for instance: https://www.silexinsight.com/products/security/sha-3-ip-core/ or https://www.xilinx.com/products/intellectual-property/1-gex6yw.html
vp11Yes, improvements are tweaks if you want, but intent is different. Do you think Bill Gates was right when he said that 640k was enough for everyone? Evolution happens.
sgp_dEBRUYNE: ironically I think we understand this better than ASICs given the past actions and observed behaviors
fluffyponyby pre-committing we get rid of the "first to market" race
moneromooojwinterm: based on particular reasons ?
jwintermI think it would be trivial to turnaround an asic for sha-3 in under three months by simply licensing ip
dEBRUYNEsgp_: The fact that some people are still advocating for them makes me think we don't
sech1fluffypony no one is going to work on SHA3 ASIC 2 years in advance, it's an eternity in crypto
jwintermbased on the experience with cryptonight and tweaks moneromooo mostly
moneromooofluffypony: if it's all about being first to market, then we WILL end up with a monopoly.
dEBRUYNE<fluffypony> the arms race is about being first to market <= I don't think that is necessary a problem in the beginning
hycand an eternity in silicon
dEBRUYNEAs long as it doens't lead to a manufacturer dominating
tevadorI don't think we need to precommit to a date for SHA-3 at the moment
dEBRUYNEmoneromooo: most manufacturers have similar tape out times
tevador6-month advance notice should be enough if we want to switch in the future
fluffyponysech1: I know, but I also don't see value in precommitting to a short-term date because then RandomX is largely pointless
sgp_dEBRUYNE: I think it's important to distinguish between planned tweaks with the intent of breaking (current) and RandomX improvements. These have very different impacts and implications
vp11We’re already precommitting to the possibility of SHA3. Isn’t that enough? :)
fluffyponytevador: if RandomX is broken and someone manufacturers a 10x ASIC then it will be a panic-switch and NOBODY will be ready on the manufacturing side
fluffyponythen it'll be the Bitcoin ASIC arms race all over again
needmoney90Vp11: it's a process, this is Signalling
xmrmatterbridge<learninandlurkin> I'm general afraid of commitment, so I vote against committing to a date
el00ruobuob_[m]vp11 +1
dEBRUYNEsgp_: "Improvements" are still tweaks, same risks involved. Besides, who can objectively determine they are actually improvements?
needmoney90If it's not in the consensus layer, this is the best we can do
needmoney90Gauge consensus and get everyone on the same page
dEBRUYNEfluffypony: If that happens, we can plan a fork 6 months in the future I presume
oneiric_having a set of viable alternative for backup makes more sense than precommiting to me
jtgrassie^
ferretinjapan^
dEBRUYNEImo the only viable option if RandomX fails is SHA3
fluffyponydEBRUYNE: given the history I STRONGLY DOUBT everyone will be able to chill whilst someone takes over the hashrate
sgp_dEBRUYNE: I disagree with grouping a possible 2 year off improvement that isn't rushed to have the same risks and annoyances that we have now
dEBRUYNEThere's certainly a lot of overlap
oneiric_dEBRUYNE: and if in 6-months something better comes up?
dEBRUYNE^ sgp_
vp11dEBRUYNE: who can objectively determine if the current improvements on the protocol are actual improvements? The answer should be because there are tests, research and audits. Why it should be different to pow research?
dEBRUYNEoneiric_: It's a risk, but a slight one
dEBRUYNEvp11: That doesn't rule out the "improvement" yielding an advantage for an ASIC manufacturer
fluffyponyok so consider these two scenarios:
oneiric_just don't see the harm in saying: "we'll fallback to one of SHA3, Blake2b, ChaCha, etc."
vp11That doesn’t rule out the improvement (on protocol) yielding a possibility of breaking the whole thing.
fluffypony1. RandomX fails and a 10x ASIC appears, we decide to fork in 6 months and in the meantime a single manufacturer controls 90% of the hashrate
dEBRUYNEvp11: I don't see how that is related
fluffypony2. We have precommited to SHA3 in 2 years. 6 months in, RandomX fails and a 10x ASIC appears, we decide to emergency fork in 8 weeks, and at least some manufacturers already have plans in place and can accelerate them.
fluffyponyoption 3 is no precommit + emergency fork, which is untenable
dEBRUYNEfluffypony: Do you think asic manufacturers will realistically start designing 18 months in advance?
dEBRUYNEI am kind of skeptical about that
tevadorI don;t think anyone would make any work on SHA-3 ASIC 1.5 years in advance
mrantraxthat would be a waste of time
rbrunnerAnd what in those arguments speaks for SHA3? Why not piggyback on Bitcoin ASICs?
ArticMineIn case 2 the creator of the 90% takeover starts making the SHA-3 ASIC since they know a head of time that is the fall back
moneromoooBecause someone would have 99% of the hash rate.
ferretinjapanfluffypony, I'm for 3. otherwise, a miner could decide to game the network by hiring a huge botnet to spike the HR and fake RandomX asics, thus triggering a non-rollbackable switchover. Remember Miners do NOT like RandomX they'll be incentivised to nerf it.
fluffyponydEBRUYNE: they will start the process of raising money, designing, aiming for 7nm, etc
jwintermrbrunner: that puts monero at the mercy of f2pool or whatever
vp11The same argument against the tweaks in PoW can be used against the tweaks in the protocol. If someone finds a better way to improve RandomX in the future (while we’re on it) we should consider implementing it in a responsible way, the same way we do for the protocol improvements.
vp11dEBRUYNE:
ArticMineOut of the frying pan 10x into the fire 100x
dEBRUYNEIt's vastly different
oneiric_if asic manufacturers can already do <6 mo design on something as complicated as cryptonight, dont see sha3 asic taking more than a couple weeks
xmrmatterbridge<learninandlurkin> Any announcement of a switch date relies on (SHA-3 ASICs produced to sell freely)»(SHA-3 ASICs produced to mine fore profit at the moment of the fork)
fluffyponyvp11: the argument being made is that RandomX is the be-all and end-all of ASICs
dEBRUYNEThere's no way you can compare improvements in the protocol to "improvements" in the PoW algorithm
xmrmatterbridge<learninandlurkin> so the a fair market emerging is quite an assumption, especially immediately
fluffyponysorry of ASIC resistance
vp11I just did :)
ArticMinefluffypony RandomX is not the be-all and end all of all ASICs far from it
hycRandomX will kill single-purpose fixed function hardware. That's unequivocal.
tevadorthere are already SHA-3 designs available, ETH ASIC contains Keccak cores; the only investment would be the tapeout/mask which nobody would do 2 years in advance
fluffyponyvp11: no, I mean that there is expected to not be a "better way to improve RandomX" much, if at all
hycthe only open question is how efficient you can make a programmable chip
moneromooorandomx is the best we have. But then 6 months ago (or wahtever) it was somehting else. Years ago it was CN. Maybe a better way will be found in the next year or two. Claiming randomx is the last now does not seem too productive. It might be the last you're willing to countenance, but that is another claim.
rbrunnerThere must be some logical contradiction somewhere in using RandomX first and already committing to SHA3
hycrbrunner: agreed
hycprecommit to SHA3 before knowing how well randomX performed is illogical
ferretinjapan^
rbrunnerOr use it at all if SHA3 is so good …
oneiric_^
jtgrassieagreed
fluffyponyhyc: RandomX *will* eventually fail, though
ferretinjapanAnd theres incentives for miners to (pardon pun) undermine RandomX
fluffyponyrbrunner: I'm for side-stepping it, but few others are
sech1fluffypony you can't be 100% sure about that
needmoney90Moneromooo: it's the last we can realistically use before we succumb to ASICs due to ecosystem size
sgp_fluffypony: yes, which is why I think it's good to share an intent to switch if it breaks
dEBRUYNEfluffypony, sech1: Only practice will tell I guess
needmoney90Even if we find another option or two, the network will be de facto ASIC mined until then. And it would take a lot of time to switch over.
fluffyponysech1: yes, I can. It will not achieve its stated objective in the long run - a custom motherboard with a bunch of CPUs or GPUs on it is indistinguishable from an expensive ASIC.
hycfluffypony: theoretically yes. Even if an ASIC was only 1% more efficient, there is presumably a marketcap value where it becomes profitable to build that ASIC
dEBRUYNEBut it is prudent to have a back up plan in case it fails
hycbut those outcomes are far away
needmoney90Moneromooo in years past we had the benefit of being small/flexible, we could adapt rapidly
needmoney90We're kind of a billion dollars now
sech1fluffypony then we have different definitions of failure
tevadorcustom montherboard with a 1.5 efficiency advantage can hardly be called an ASIC
fluffyponyneedmoney90: we're over a billion Dollars in a bear market
ArticMinefluffypony hyc: RandomX *will* eventually fail, though <—- that is very debatable It may well lead to co existence in the 1.5x to 10x range
fluffyponytevador: it's functionally equivalent
needmoney90I'm trying not to overstate things Fluffy.
tevadorthe last batches of ASICs were 10-50x more efficient
tevadorthat's a different situation
fluffyponyArticMine: 3x - 10x would be sufficient to allow a single manufacturer dominate hashrate
needmoney90Just pointing out the realoty that even if more asic resistant algos exist, we don't have the luxury of algo hopping more than once a year at this point
hycthat's really a different argument. it's always true that whatever the mechanism, the one with the deepest pockets can buy the most of them
moneromoooI don't see that as an impassable obstacle. Pissed off exchanges -> fewer exhanges; someone with > 50% hash rate -> pointless coin.
needmoney90Even then is reckless
sech1custom multi-cpu motherboard with 1.5x efficiency - no sense in keeping it in secret, much more sense in selling it to millions of miners
fluffyponysech1: no, keep it secret and mine for a while until you've made enough money, then blow off the dust and sell them
fluffyponythat's the Bitmain Model (tm)
ferretinjapanthe other thing is RandomX has ubiquity on it's side to balance out advantages ASICs can have.
needmoney90?
sech1fluffypony this model doesn't work with only 1.5-3x efficiency
ferretinjapanASIC manufacturers can't buy up ALL CPUs/GPUs.
ArticMine3x is very debatable given the ETH experience 10x maybe
ArticMineThis also assumes only one ASIC manufacturer for RandomX
needmoney90Articmine is it possible that the pos fork / difficulty bomb have delayed investment in asics
needmoney90Due to fears of their longevity on the network
dr-mikeCurrent ETH ASICs available on the market are only 2.3x more efficient
xmrmatterbridge<learninandlurkin> yes ubiquity is a powerful force in stopping a 51% attack. Maybe it's controversial but I'm actually in favour of botnets if they decentalize things with common hardware
ArticMineIt did not. What is happening in ETH is the advantage is low 2x -4x
ArticMineAlso while this is going on the CPU do not stay static
xmrmatterbridge<learninandlurkin> The barrier to entry for building a botnet is potentially much lower than the one to build an ASIC farm
moneromoooIs Ethereum mining feasible on CPU ?
dr-mikeno.
sgp_If you don't mind, would it be all right if I focus the discussion more into a few main topics? We can more reliably debate about the pros and cons under different scenarios and help predict actions. Otherwise this conversation can go on forever.
dr-mikeGPU advantage is well over 10x
ArticMineIt is on GPU well after a year of ASICs
dEBRUYNEI think only practice can tell what kind of efficiency advantage will drive out other miners
ArticMineSo you ave co existence GPU / ASIC which also leads to competition between ASIC manufactures. The very thing SHA-3 is trying to engineer
ArticMinehave
xmrmatterbridge<learninandlurkin> I think from reading this discussion that longer term plans are pretty much pointless until we've had some audits/reviews/testing of RandomX especially because people are against hard-coding failure by adding a date for SHA-3
moneromoooThen maybe if RandomX fails (to have small enough of a CPU-to-ASIC efficiciency gap), then switching to Ethereum's hash might be better than SHA-3. We lose a lot of ease of access, but it's still a lot better than ASIC or nohting.
moneromooo(once Ethereum is PoS, which it apparetnly is not yet)
dr-mikeSounds reasonable.
dEBRUYNEI am skeptical the asic advantage for ETH asics will remain at 2.3x though
ArticMinemoneromooo That is a very interesting option if ETH goes POS
rbrunnerSounds reasonable today. Nobody knows about tomorrow.
ArticMineSo another fall back
dr-mikedEBRUYNE, Me too.
tevadorETH ASIC with HBM will be 6x-10x more efficient than a GPU
hycThere are still a lot of factors. Even if ASICs can be 2-3x more efficient, they aren't produced in volumes that can challenge GPUs
sgp_I think it will unfortunately become less reasonable over time, but it's an option. Ethereum also needs to actually make the switch of course
xmrmatterbridge<learninandlurkin> (or if ETH just collapses)
hycthe ASIC companies are lower priority, don't get the same access to chip fabs as the bigger players
sgp_hyc: plus the extra purposes of GPU/CPU and more stable market have added value that's hard to calculate
moneromoooDo you need a GPU to (feasibly) sync the Ethereum blockchain ?
ferretinjapanalmost seem more rational to do a mashup of multiple POWs as a stopgap to ensure decentralisation if RandomX fails, :P
moneromoooOr, rather, anyone knows how much verifying a hash on CPU costs ?
smoothmoneromooo: GPU is of no benefit to syncing ETH
xmrmatterbridge<learninandlurkin> you need a time machine to feasibly syn the ETH blockchain
oneiric_lol
tevadormoneromooo: no, but you need a quad core CPU, 32 GB of RAM and an SSD
dEBRUYNE^ Even then syncing will be quite difficilt
dEBRUYNEdifficult*
moneromoooIt was a bad questiuon. The second question is what I intended :)
asymptoticallyferretinjapan: i don't think that really works. see DASH or other coins that uses X11
ferretinjapanasymptotically, was half joking for the record.
dr-mikemoneromooo, Syncing eth chain takes 8 hours on a beefy i7 with a ssd and a 100mbit/s connection. No gpu required.
ArticMine… and you need to be near the ETH miners because of the 15 sec block time
dr-miketevador, No you dont neewd 32GB ram, 4GB will do.
moneromoooI'm really interested in "if we had Ethereum's hash in monero, how much would the PoW verification cost". Hence why my first question was bad.
moneromoooSince ethereum has probably way more blocks than us, if 15 seconds.
tevadorI think CPU verification of ethash is roughly 4 ms or so
moneromoooWhat's CN on a similar CPU ?
xmrmatterbridge<learninandlurkin> to be clear, are we discussing ETHs current hash or ProgPow?
jwintermethhash
tevadorCN is 12-15 ms on similar CPU
moneromoooThanks.
dr-mikeWhy is ProgPow not an option for monero?
xmrmatterbridge<learninandlurkin> although feasibly we could steal either as a back up plan once they go PoS
moneromoooIt could be, if randomx fails.
hycdr-mike: GPU-centric
oneiric_not-invented-here
ArticMineif fluffypony were to mine an ETH block at home for me to mine also at home on top of his block there is ~500 msec for the speed of light and switching alone out of 15 sec
moneromooo(and no other suitable candidate is apparent)
hycshrouded in controversy
dr-mikeI agree RandomX should be given a chance, if it fails ProgPow is the next best thing.
hyconeiric_: not true, it *was* invented here.
tevadornvidia sponsored PoW
ArticMineMega orphan risk
oneiric_my mistake
rbrunnerWhy should RandomX fail and ProgPoW *not*?
rbrunnerIsn't the basic approach the same?
hycrbrunner yes
xmrmatterbridge<learninandlurkin> No reason at all, but it's nice to know there are other PoW that can be stolen if RandomX fails and a stopgap is needed
dEBRUYNEIf randomx fails, isn't progpow likely to fail as well?
moneromoooProgpow targets an arch that's already optimized to be massively parallel.
sgp_learninandlurkin I think that's a good way of looking at it, a stopgap
rbrunnerNo shortage of stopgaps. Take basically anything, just different
moneromooo(though I do not know what it does)
dEBRUYNElearninandlurkin: not sure why we would need a stopgap at that point though
hycrbrunner but progpow claims to fully utilize a GPU, as randomX claims to fully utilize a CPU. progpow actually doesn't use more than ~40% of a GPU tho
dEBRUYNEImo it would be better to switch to asics then
crCr62U0How much does cost to pay ASIC manufacturer to build 10x more efficient miner of RandomX comparing to CPU?
crCr62U010e+6$?
tevador10x more efficient? I don't think even whole AMD R&D budget would be enough
dEBRUYNEWe're kind of digressing a bit from the original topics btw, I'd like to switch back to the initial points
rbrunnerA bit? :)
oneiric_if feasible randomx + progpow seems to solve a lot of controversy. though i don't know the technical consequence of something like that
dEBRUYNEFirst, does the randomx team think RandomX can be viably implemented in October?
dEBRUYNEAnd if so, would people prefer RandomX over another tweak?
xmrmatterbridge<learninandlurkin> Linzhi already has one ready to go apparently
ArticMinetevador?
sgp_dEBRUYNE: if it can be done, I prefer it over another tweak
hycPretty sure rnadomX will be ready codewise
hycthe only holdup now is reviewers
tevadorit's definitely possible for Oct
dr-mikeWhen can we have RandomX on a testnet?
dEBRUYNEIf the code is reviewed, is randomx not better than another tweak?
moneromoooWith the large caveat that I did not look at randomx yet, I think I'd prefer a CNv4 tweak about 5 months (rather than 6) after the past march fork first, then randomx.
crCr62U0All those reviewers are mute now.
sgp_moneromooo: so you're looking for RandomX addition around January 2020?
moneromoooUnless randomx is 100% ready.
moneromoooYes, sounds plausible.
dr-mikeRandomX must be ready before October.
xmrmatterbridge<learninandlurkin> Can we maybe get Outreach to bomb the whole internet with links to RandomX docs, just to get more eyes on it?
tevadordaemon integration will be a bit more work than CNv4
dEBRUYNEmoneromooo: Then it seems imperative for the community to ensure RandomX is 100% ready in october
sgp_dEBRUYNE: yes, everything would need to be a go
dEBRUYNEIn my opinion, it is achievable, we've got about 6-7 months left
oneiric_< will dedicate some time to RandomX review over the next weeks
jtgrassielearninandlurkin: I'd be highly suprosed if the Outreach team would find qualified reviewers.
jtgrassie*supprised
tevadoralso we need to prepare: pool software and a reference miner
xmrmatterbridge<learninandlurkin> Also maybe retitle the General Fund on CCS to "Desprately needed RandomX audit fund"
oneiric_^
dr-mikeWe should hite the same auditors ethereum hires for progpow.
dr-mike*hire
jwintermthat seems fairly aggresive for oct release
jwintermpresumably you would want everything finalized by end of aug or so
oneiric_dr-mike: has that already happened, or will happen?
jwintermthat's four or five months from now
dEBRUYNEjwinterm: Right, but according to tevador RandomX, in its current state, is basically ready
dEBRUYNESo we can use 4-5 months for testing and reviewing
dr-mikeIt will happen in the next 2-3 weeks
hycafaik ETH has only recently decided to o ahead with audits for progpow
moneromoooDid it not add loops like a week ago ? That seems like a large change for it to be ready yet.
oneiric_has the auditor already been selected? if so, who?
tevadorbtw is there a need to rewrite RandomX into C for review?
tevadorcurrently C++
xmrmatterbridge<learninandlurkin> or 4-5 months of looking for reviewers and failing to raise the funds for it :( it's a possibility
dr-mikeNo, but it was given a GO, core devs will hire the auditors in the next 2-3 weeks and will notify the community.
ferretinjapanwhat would be the estimated cost to hire someone/some firm to do an independent review?
xmrmatterbridge<learninandlurkin> Are the auditors for ProgPow just Nvidia?
oneiric_thanks, look forward to seeing who they select, and reading the audit when it's finished
hyctevador: probably not needed. that was just a personal preference of mine
dEBRUYNE<moneromooo> Did it not add loops like a week ago ? That seems like a large change for it to be ready yet. <= tevador, any comment on this?
moneromoooI'm not asking for it to stop improving btw :)
tevadornot loops, one instruction was modified to jump back in such way that loops are impossible
moneromoooOK, branches.
tevadorit was not a major change from my point of view
moneromoooI thought it did not have branches before. But admittedly I mostly follow the backlog quickly.
tevadoryes, it did not have branches before
sech1branches were added in respose to critics on HW forum
tevadornow there are branches with a fixed 1/128 probability
moneromoooOK, so now it has, but in such a way that it is always "safe". Right ?
tevadorit was tuned to have almost no effect on CPU performance
hycyes, safe, no loops
sech1yes, no infinite loops are possible with this type of branches
rbrunnerSo this is on the side of "nice to have", not "damn, how we could forget that"
tevadorit should be easy to prove that it cannot have an infinite cycle
sech1tevador these branches are even designed to not trigger after they've triggered, loops are simply impossible
dr-mikerbrunner asking tough questions :)
tevadorthe main purupose is to take advantage of the commit/retire stages in CPUs
moneromoooMy understanding is that programs won't be known in advance like what sech1 did with CNR. Correct ?
ferretinjapandr-mike, someones gotta :)
tevadorwithout this, ASIC could have a simplified pipeline
tevadormoneromooo: 8 random programs per hash
tevadorunique
sech1moneromooo it can be formally proved that branches are safe in RandomX, we made sure it's easy to do
moneromoooAre these 8 random programs per hash knowable in advance, or not ?
sech1No, they're generated on the fly
oneiric_having a formal verification tool as a deliverable from the audit would be awesome
tevadorno, you have to execute Nth program to find out the code for the N+1st program
moneromoooWell, that does not necessarily preclude knowing in advance.
tevadorand the first program is generated from the block header
moneromoooRight. That does. Thanks.
tevadorfull block header hash
needmoney90Wait, why do loops matter?
rbrunnerBranches
needmoney90I thought it just took program state after X instruction executions
rbrunnerNot loops :)
hycloops make runtimes too variable
tevadorit's not so easy to have loops and keep approximately the same runtime per hash
moneromoooYou can't do that (fast) without a hardware insns counter + exception.
tevadorwe tried in RandomJS and it was not pretty
needmoney90This is better suited for -Pow, sorry
moneromooo"that" being "program state after X instructions[s]".
hycyeah we're off in the weeds here
needmoney90Carry on, I'll speak up if I have something useful to speak of
dEBRUYNETo sum up this point, people prefer RandomX in october as long as it is ready and audited.
notmikeno
dr-mikeyes.
notmikehard pass
hycyes
jtgrassieyes
el00ruobuob_[m]yep
sech1yes
tevadoryes, except stoffu
ferretinjapan^
ArticMineyes
dEBRUYNELet me switch to another point I'd like to get a bit of a vote on. Like I said, the path of least resistance seems to be either:
needmoney90It's not just preference, the consensus is pretty much unanimous except for the gpu mining bloc
moneromoooI think so, the "ready and audited" being a bit subjective I suppose.
dEBRUYNE1. RandomX -> Switch to SHA3 in case RandomX fails
dEBRUYNE2. RandomX -> precommit to SHA3 on a set date
jwintermI'd prefer going straight to sha-3 and being done with it, but obviously I'm in minority here with notmike and stoffu
dEBRUYNECan I get a bit of a vote on this ^
hyc1
dEBRUYNEIf you don't like either options, you can abstain and mention it
dr-mike3. None of the above ?
ArticMine1
jtgrassie1
tevador1
el00ruobuob_[m]1
sech1111
ferretinjapanabstain
jwintermwhat does "fails" mean?
needmoney901, but with the caveat that failure be rigidly defined
jwintermI don't know that I saw resolution on that term
ferretinjapanjwinterm, thats the million dollar question.
sech1jwinterm we spent first 40 minutes to discuss it
ferretinjapanits way too vague.
dEBRUYNEjwinterm: This basically -> <sech1> steep increase in hashrate (and profitability drop) without price changing is a strong indicator of more efficient hardware (ASICs)
hyc(if ETH has gone PoS by then, we could consider ETHash instead of SHA3. I'm still opposed to pre-committing to SHA3 in any form)
jwintermin light of being too vague I'll go 2, probably would go 2 anyway tbh
rbrunner1, but with no dedicated successor yet
moneromoooRandomX, and then (1) if we have another contender ready, switch to that, or (2) if the apparently ASICs seem to be barely getting to 50%, then a tweak, or (3) SHA-3.
sgp_1
dr-mikethat sounds better moneromooo
ferretinjapanyeah, I' like moo's option better. Option M for me.
ErCiccione[m]1
moneromoooAnd yes, ethhash maybe instead.
sgp_Again, I think the failure is up for some discussion, especially the nature of it. I'm for switching to SHA3 if RandomX catastrophically fails for sure
xmrmatterbridge<learninandlurkin> I vote for hyc's last comment
dEBRUYNEMy personal preference is option 1 fwiw
ferretinjapanI think the consensus is theres not enough of a plan to have a consensus :P
xmrmatterbridge<learninandlurkin> actually I vote for this -> <moneromooo> RandomX, and then (1) if we have another contender ready, switch to that, or (2) if the apparently ASICs seem to be barely getting to 50%, then a tweak, or (3) SHA-3.
vtnerd___Fwiw -> Sha3 precommit (2)
ArticMineThere is a very strong consensus to proceed with RandomX at this point.
sgp_Adding to this, there is about a 3 month turnaround time between when a failure is determined and Monero can move to SHA3, if that's the desired action. Monero can generally either use a stopgap for those months or wait it out
sgp_I think the nature of the failure will determine which of the two actions are taken
sgp_ASICs control 90%? Stopgap maybe warranted
vtnerd___Randomx by October seems aggressive if daemon integration is complicated. And an x86 only optimized version is unfortunate
sgp_ASICs at 20%, proven advantage and growing? Maybe wait it out
dEBRUYNEtevador: Would you be able to integrate randomx with the daemon as well?
xmrmatterbridge<learninandlurkin> The nature of theoretical failures is the big limitation to planning beyond auditing RandomX REALLY REALLY well
hycvtnerd___: shouldn't take long to get an ARMv8 version going
moneromoooAnd then if we switch to SHA-3 and we end up with a laughing > 50% ASIC manufcaturer, what do we do ? Go home ? Resurrect Cryptonite and ask MRL to find how to make it private ?
vtnerd___Eh, not April yet so might be doable
ferretinjapansgp_, yeah, "failure" could mean literally anything.
ArticMineThe question I possible see is 1a RandomX if fail SHA-3 vs 1b RandomX if fail ETHhash / ProgPOW if fail SHA-3
sgp_moneromooo: the switch to SHA3 should ideally be the final option, at least for a long while. We would probably out of options after that
jwintermmoneromooo: considering sia and decred each have at least three asic manufacturers and they are lower on the totem pole that seems unlikely, imo
vtnerd___There seems to be plenty of fear driving the decisions which could result in a worse outcome
dEBRUYNEjwinterm: Plus both of those coins have more complex algorithms
jwintermnot by much, I think they both use variants of blake, which is another sha3 finalist I think
sgp_The intent is that before the SHA3 switch, Monero can have resources that help meet the manufacturers halfway and lower the barriers to entry
moneromooojwinterm: ok, 3 still seems not good though, but I suppose beggars can't be choosers…
tevadorif one manufacturer is 2-3x more efficient that's exactly like a RandomX 'failure' situation, at least temporarily
jwintermat least four for decred - ffminer, bitmain, innosilicon, and obelisk
sgp_tevador: yes, I agree that the mere existence of ASICs isn't necessarily failure
dEBRUYNEtevador: I doubt any manufacturer will be 2-3x more effficient though at this stage
dEBRUYNEEspecially with a friendly algorithm like SHA3
dEBRUYNEjwinterm: Thanks for correcting me
rbrunnerYeah, at some point PoW itself is a failure, even if that insight does not help much
ferretinjapansgp_, SHA3 might not be the best though. Its just the "safest/easiest" right now.
moneromoooferretinjapan: for "ease of entry into ASIC manufacturer club" ? If you have better, feel free to list :)
sgp_ferretinjapan: that's why I'm not for a set sunset date. We could say "switch to the best ASIC-friendly PoW algorithm" instead. But we would need to keep making resources for whatever that is to not be caught off-guard
DaveyJones+1 ^
ferretinjapanmoneromooo, well, my money is on RandomX :P
tevadorWhatsMiner is about 2x more efficient than Bitmain at SHA256 at 16 nm, so it's not impossible to have one manufacturer dominate even a simple algorithm
dEBRUYNEArguably sha256 is relatively mroe complex though :p
dEBRUYNEmore*
niocsgp +1
ferretinjapanBut that said, who knows, QC could put a monkey wrench in SHA3 for all I know, and 5 -10 years later, and we're back here again.
moneromoooph4r05: so {} inits to NULL for sure, right ?
dEBRUYNETo sum up this point, people mostly prefer this course of action -> "RandomX -> Switch to SHA3 in case RandomX fails", where I suppose SHA3 can be substituted by "an asic friendly algorithm"
sgp_ferretinjapan: that's possible, which is why it's important to focus on the logic of the decisions rather than the specific implementations as much for these high-level discussions
sgp_dEBRUYNE: yes, I think that's mostly fair
hycdEBRUYNE: +1 with that modification
rbrunnerAgree more or less
sech1yes, it doesn't have to be fixed at SHA3
sgp_I added a summary of our thoughts a little over a week ago here: https://github.com/monero-project/meta/issues/316#issuecomment-472589586
ph4r05moneromooo: to be sure, I set it to null now
ferretinjapansgp_, not that I think QCs will be viable for a long time (if ever) but if we wanted to hedge against the possibility, RandomX would probably be much better than SHA3.
sgp_You can substitute "SHA3" for "an ASIC-friendly algorithm" in it
dEBRUYNEOn an administrative note, would people like for me to open a new issue on Github where we can further discuss stuff?
ferretinjapanThough I could be talking out my backside on that point…
dEBRUYNEOne thing I'd like to see a more in depth discussion on is how to classify failure of RandomX
moneromoooCool. It might well be it's for sure, I'm still confused by this construct :) Thanks.
hycsure. new issue, summary from today
sgp_dEBRUYNE: I recommend focusing the discussion on more specific points. Possibly several issues. Eg: what if RandomX fails day 1 of implementation?
sgp_that way we can focus the discussions and cut through the general nonsense
moneromoooThen gmaxwell gets to laugh mercilessly at us for months :P
dEBRUYNEThe previous ticket had a pretty good signal to noise ratio tbh
dEBRUYNEUntil shortly before the end :p
sgp_dEBRUYNE: yes, the last week was useless :(
dEBRUYNEThat being said, I'll try to list some more specific points
ferretinjapanyeah, there'll probably be a whole spectrum of different "failures" you'd want to define.
sgp_ferretinjapan: exactly
sgp_fwiw, at the bottom of the chart I added "emergency tweak to break ASICs." I think we can have a good discussion about that
sgp_some more background:
dEBRUYNEI'd like to conclude the meeting soon fwiw :-P
sgp_this situation would be triggered if 1) Monero implemented RandomX, and 2) Monero doesn't have a good ability for a quick ASIC-friendly turnaround
dEBRUYNEI am goign to call an end to this meetings. Thanks all for coming and participating!
dEBRUYNEI'll create a new Github issue tomorrow where we can further discuss some stuff in detail
sgp_Thanks dEBRUYNE for setting it up
el00ruobuob_[m]Thank you all, i'll be posting those logs in a minute
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2019-03-24, getmonero.org. The official post carried the raw log and pointed readers to Hello Monero for the overview.
- Original Hello Monero URL slug recovered from the Wayback Machine index; the original page content did not survive, so this reconstruction carries the log as archived by the Monero Project.