<r​ucknium:monero.social> MRL meeting in this room in two hours.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1247

<r​ucknium:monero.social> 1) Greetings

<a​rticmine:monero.social> Hi

Hello

<v​tnerd:monero.social> Hi

<s​yntheticbird:monero.social> Hi

<j​berman:monero.social> *waves*

<c​haser:monero.social> hello

<j​effro256:monero.social> Howdy

<g​ingeropolous:monero.social> hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<v​tnerd:monero.social> Me: currently fighting the monero_c build process

<r​ucknium:monero.social> me: Setting up "honeypots" to discover more about spy node infrastructure. Monitoring Qubic hashpower share: gist.github.com/Rucknium/0873b10b6d36ff6c9d6f8f54107d16f7 I submitted a new research CCS proposal: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/599

<j​effro256:monero.social> Me: finished firs draft of hot-cold FCMP++/Carrot wallets, reviewing rbrunner7's subnet dedup PR

<j​berman:monero.social> me: squashing bugs reported by ofrnxmr in the fcmp++ integration, refactoring refresh() to *not* download all hashes in the chain from before the wallet's restore height (since this has no tangible benefit as is)

<g​ingeropolous:monero.social> me: still driving the bots to build monerosim.

<a​rticmine:monero.social> I have been working on the scaling. Expect to have a revised document for the next meeting.

<a​rticmine:monero.social> A long term sanity median is very much feasible and the wallets can be insulated from constant fee calculations

<a​rticmine:monero.social> The value will also be in using MA for node relay bandwidth caps to effectively manage the blocksize

<r​ucknium:monero.social> 3) [Transaction volume scaling parameters after FCMP hard fork](github.com/ArticMine/Monero-Documen…lob/master/MoneroScaling2025-07.pdf).

<a​rticmine:monero.social> As I mentioned a sanity median is in the works.

<a​rticmine:monero.social> One thing I am looking for is the latest stress net TPS for FCM++

<a​rticmine:monero.social> FCMP++

<j​effro256:monero.social> Did the tx byte sizes from last week affect your analysis at all?

<a​rticmine:monero.social> Not materially

<a​rticmine:monero.social> The more critical issues in my mind iss going to be verification times

<a​rticmine:monero.social> Since 1) they are serious and 2) can be mitigated substantially outside the consensus

<a​rticmine:monero.social> Multi thread and GPU / graphics verification will be critical here

<j​effro256:monero.social> I am going to disagree that GPU verification is critical. It's a nice-to-have, but far from critical IMO

<a​rticmine:monero.social> Byte sizes alone point to verify large block sizes because of current bandwidth availability. In my analysis the impact of sizes is for the most part factored in with the change to ZM

<a​rticmine:monero.social> It means we have to restrict blocksize in non consensus

<a​rticmine:monero.social> But it is not required right now

<a​rticmine:monero.social> GPU verification

<s​yntheticbird:monero.social> I wonder how many years left before we're going to ask ourselves about NPU verification

<a​rticmine:monero.social> It depends on transaction demand

<r​ottenwheel:unredacted.org> draft of a gist on it, or code-related? any links? 😁

<j​effro256:monero.social> rottenwheel: working code: seraphis-migration/monero #52

<o​frnxmr:monero.social> monero-project/monero #9856 this sped up initial sync by 40% for me

<r​ottenwheel:unredacted.org> ah, yes; saw that before around here. thank you.

<o​frnxmr:monero.social> Not sure about w/ fcmp or w/o checkpoints

<r​ottenwheel:unredacted.org> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) good luck with the new proposal. thanks for the continued research and reports.

<j​effro256:monero.social> ofrnxmr: FCMP++ uses curves (Helios-Selene) where that scalar-point multiplication wouldn't be applicable, so the speedup will almost certainly be less pronounced syncing FCMP++, but that's very interesting

<j​berman:monero.social> Wondering if there are any changing thoughts on tx weights clamping to powers of 2? Just reiterating from last week, this would incentivize the creation of multiple tx of lower input combinations instead of single larger txs (e.g. 1-in + 2-in > 3-in)

<a​rticmine:monero.social> My take is that there will be significant improvement in verification after the FCMP++ fork.

<a​rticmine:monero.social> 1 in + 2 in > 4 in becomes the test

<a​rticmine:monero.social> With power s of 2

<j​berman:monero.social> By ">" I meant, a user is incentivized to spend 3 inputs across 2 txs (a 1-input and a 2-input), instead of in a single 3-input tx

<a​rticmine:monero.social> I understand

<j​effro256:monero.social> We also would prefer people do a 4-in over a 3-in & 1-in, so it has to be bounded in both directions

<a​rticmine:monero.social> If the cost of 3 in and 4 in are the same. Then we end up comparing 1 in + 2 in to 4 in

<j​berman:monero.social> What if a user only has 3 inputs?

<a​rticmine:monero.social> They have to pay for 4

<a​rticmine:monero.social> 3 in is still valid

<j​berman:monero.social> They would be better off spending as a 1-in and 2-in instead of 3 though

<a​rticmine:monero.social> Then this is the case against powers of 2

<j​berman:monero.social> right I was wondering if there are any thoughts on changing the currently proposed powers of 2 approach, taking that case into account

<a​rticmine:monero.social> Yes. This really comes down to the t numbers

<a​rticmine:monero.social> Both size and verification time.

<a​rticmine:monero.social> It is not just proof sizes. There is also the base part of the tx to consider

<a​rticmine:monero.social> and the greater number of outputs

<j​effro256:monero.social> jberman: depending on the specific weight function, your issue of making a 2-in + 1-in instead of a 3-in because of the powers of 2 weight might not be so bad if we model the sender as also taking into account the *future* weight of having to spend 2-in versus a 1-in

<a​rticmine:monero.social> There is another advantage to powers of 2. It encourages the consolidation of dust

<j​berman:monero.social> In that case it's even worse no? because the future 2-in weight will be > future 1-in

<j​effro256:monero.social> Now if in the future, they only needed a small input from one of the two, then they pay no additional cost, however, if they needed to consolidate, they would pay that cost. So its strange b/c it's conditional on how they schedule their future payments

<j​berman:monero.social> Oh you're saying it's more expensive to them in the future to consolidate those 2 future outputs, gotcha

<j​effro256:monero.social> Right, which would naturally disincentive the sneder from doing that

<j​effro256:monero.social> Methinks we need a fee market simulation

<j​berman:monero.social> I can work on a table of all FCMP++/Carrot byte sizes and current verification times of default txs of 1 - 128 inputs and 2 - 16 outputs

<g​ingeropolous:monero.social> did someone say simulation

<j​effro256:monero.social> It contains rational actors trying to pay the least amount of fees while fulfilling payments in a certain timeframe

<r​ucknium:monero.social> Did someone say market

<j​effro256:monero.social> While node actors adjust the fee market policy to minimize verification time and storage costs

<a​rticmine:monero.social> This would be very helpful

<a​rticmine:monero.social> ... and answer this question

<j​berman:monero.social> Will do that and comment it here: seraphis-migration/monero #44

<r​ucknium:monero.social> 4) [FCMP++ optimization coding competition](getmonero.org/2025/04/05/fcmp++-contest.html).

<r​ucknium:monero.social> Last meeting we planned to have a post-mortem discussion about this.

<j​effro256:monero.social> jberman do you want to dump the post here now, or publish it in a bit ? I'm fine w/ now

<r​ucknium:monero.social> IMHO, the big win was `ec-divisors`, which attracted one (IIRC) submission, but got a 30x speedup.

<r​ucknium:monero.social> Oh, there is a post

<j​berman:monero.social> I'll dump it here, one sec

<j​effro256:monero.social> Is xmrack here today?

<r​ucknium:monero.social> And the `ec-divisors` win makes me wonder if the speedup could have been achieved by doing a review of the relevant literature and finding the fast algorithm that way, instead of a competition. I mean, as a lesson for the future.

<a​ck-j:matrix.org> Hello

<j​berman:monero.social> paste.debian.net/1388773

<j​effro256:monero.social> The one thing I wanted to talk to xmrack about is how they went about scouting for contestants, and if there is anything to be taken away from that process. (you don't have to answer now lol I kinda put you on the spot). That was something I wasn't involved in, but the outreach that they did produced good results. IIRC they contacted Fabrizio directly. Is that correct?

<j​berman:monero.social> Fabrizio ack'd kayabanerve 's idea to use an FFT as "likely better" here: fabrizio-m/fcmp-competition #1#issuecomment-3033736170. It was also a matter of finding someone to do the work

<a​ck-j:matrix.org> Correct. I looked at the ZPrize contest (recommended by kayaba at some point) which was the most similar contest to what we planned on running. github.com/z-prize/2023-entries

<a​ck-j:matrix.org> I went through each of the submissions for 2022 and 2023 and dug out contestants email addresses from their submissions and reached out to them directly. I only received a few replies with Fabrizio being one of them.

<a​ck-j:matrix.org> I also reached out to people who have published monero-related cryptography related research papers but had no luck there.

<a​ck-j:matrix.org> I’m not sure I have any lessons learned besides that we got really lucky with Fabrizio being a wizard and a perfect fit for our rust-based competition

<a​ck-j:matrix.org> I think posting to reddit was good for general awareness but I’m not positive that was successful at attracting competitors.

<r​ucknium:monero.social> Ready to move to the next agenda item?

<r​ucknium:monero.social> 5) [FCMP alpha stressnet planning](seraphis-migration/monero #53#issuecomment-3053493262).

<o​frnxmr:monero.social> - Unable to connect a wallet to an unrestricted rpc if txpool > 100mb: monero-project/monero #9473

<o​frnxmr:monero.social> - dynamic block sync size: monero-project/monero #9494 also here seraphis-migration/monero #78

<j​effro256:monero.social> jberman mentioned that the >8-in PR is ready for review now, I will take a look at it very soon

<j​berman:monero.social> I'd also like to knock out this wallet refresh refactor too to address ofrnxmr 's bugs

<o​frnxmr:monero.social> Ive tested the bss numerous times, but am unsure about 9473's correctness

<o​frnxmr:monero.social> Ive tested the dbss (9494) numerous times, but am unsure about 9473's correctness

<j​berman:monero.social> what was the reasoning on 9473 for not just requesting max 100 txs at a time on unrestricted too? that seemed like a simple solution to the issue there

<o​frnxmr:monero.social> I dont know. Batching into 100 (or even 500) seems like the most simple solution

<j​berman:monero.social> can discuss it further later

<j​berman:monero.social> w.r.t. stressnet, I'd say let's get 1 more week to address above (refresh refactor, 9473, 8 input PR, and dynamic block sync size)

<o​frnxmr:monero.social> What will it take before we can use the optimized libs?

<o​frnxmr:monero.social> (currently takes me abt 20 seconds to build an 8in 8out tx, iirc)

<j​berman:monero.social> Lederstrumpf's helioselene optimizations + kayaba's optimizations on top are already merged upstream. Open PR over here for fabrizio's: kayabaNerve/fcmp-plus-plus #33

<j​berman:monero.social> If fabrizio's not in by next week, I'll just push to my fork and we can use it from there in fcmp++-stage

<r​ucknium:monero.social> 6) [Spy nodes](monero-project/research-lab #126).

<r​ucknium:monero.social> I've set up some "honeypots" to try to learn more about the spy node infrastructure. No results to report yet.

<r​ucknium:monero.social> My proposal to make a few changes to the DNS ban list contents is available for comments & questions: monero-project/meta #1242

<r​ucknium:monero.social> Like jeffro256 say, he is working on reviewing rbrunner's PR: p2p: Improved peer selection with /24 subnet deduplication to disadvantage 'spy nodes' monero-project/monero #9939

Thankful for that :)

<r​ucknium:monero.social> Anything more on spy nodes?

<r​ucknium:monero.social> 7) [Proposal and spec for Proof-of-Work Enabled Relay ("PoWER")](monero-project/research-lab #133).

<o​frnxmr:monero.social> Not spy node related, per say, but there are miners that seem to check ports and possibly mine on them

<o​frnxmr:monero.social> my xmrig-proxy has 20 unknown monero addresses that have connected to it over the past month or so

<r​ucknium:monero.social> ofrnxmr: You mean trying to start the miner through an unrestricted RPC? Or just a nodeless miner looking for block templates?

<j​berman:monero.social> I think boog900 raised some valid points that bump favorability of Equi-X over RandomX in discussion starting here: monero-project/research-lab #133#issuecomment-3130110655

<b​asses:matrix.org> Thanks a lot for your hard work!

<o​frnxmr:monero.social> No, i mean a miner (probably xmrig) is connecting to my xmrig-proxy

<j​berman:monero.social> I'm still curious how long RandomX PoW construction on light mode would take, assuming it takes some reference machine 1-2s on fast mode

<j​berman:monero.social> Haven't gotten around to testing that out

<o​frnxmr:monero.social> They have their user section of xmrig set to a primary monero address, so it doesnt seem to be just knocking kookijg for unrestricted rpc, but an actual miner looking for a stratum or rpc

<r​ucknium:monero.social> 8) PoW mining pool centralization. [Qubic Monero Hashpower Share](gist.github.com/Rucknium/0873b10b6d36ff6c9d6f8f54107d16f7). [TEE-assisted Censorship-Resistant Block Template Production](monero-project/research-lab #134).

<r​ucknium:monero.social> Qubic changed their mining wallet at around 9:30 UTC today, so their mined blocks cannot be deduced from the method I used in the gist ^ anymore. And their pool API has stopped working AFAIK.

<r​ucknium:monero.social> But you can get a good approximation of the number of blocks they have mined by getting all the blocks that other mining pools claim, then seeing what's left.

<a​rticmine:monero.social> Is there anything in tx extra?

<r​ucknium:monero.social> I see 15 - 25% of blocks unclaimed by other pools, in the last 24 hours

<a​rticmine:monero.social> That is unique to Qubic?

<r​ucknium:monero.social> I am not sure about the tx_extra contents

<a​rticmine:monero.social> So the unclaimed blocks may have a signature

<o​frnxmr:monero.social> The unclaimed blocks were like 5% before? I dont remembwr

<a​rticmine:monero.social> Tx extra for the coinbase is used by Tari

Unknown blocks were 1.5% of all blocks before, so just subtract 1.5% from what miningpoolstats.stream/monero pie chart shows

<r​ucknium:monero.social> Years ago, DataHoarder made this Go program that pulls the blocks claimed by most major pools' APIs: git.gammaspectra.live/WeebDataHoarder/monero-blocks

could update it to re-fetch data

<o​frnxmr:monero.social> miningpoolstats.stream shows 5% unknown, 12% qubic over the last 1000 blocks. And 11% now (unknown)

<a​rticmine:monero.social> Also the PoUWin Qubic is highly centralized with like 90% control

<r​ucknium:monero.social> And then p2pool.observer/api gives you p2pool-mined blocks

<r​ucknium:monero.social> Qubic claims that many miners are switching to their pool. I don't yet believe that claim without evidence.

DataHoarder: Please do if you can spare the time

<a​rticmine:monero.social> I will be on MoneroTalk regarding Qubic later today

<o​frnxmr:monero.social> I dont believe that claim at all

4.71 GH/s are not on their pool at the moment. So they need 4.71 GH/s to overtake them

So far they haven't shown more than 2.2 GH/s even at peak moments.

<r​ucknium:monero.social> I wonder how much info the makers of xmrig have about miners possibly switching pools, from the 1% hashrate donation behavior.

The only evidence about switching miners was from supportxmr

p2pool.observer/api mini.p2pool.observer/api (and nano, old, old-mini) etc. but they can be coalesced

they had ~300 MH/s miner profit switching between Monero and Qubic

<a​rticmine:monero.social> They need to incentivize by paying Qubic to get the hash rate to move

in general if the mining coinbase has quite some outputs it tends to be p2pool, specially with the merge mining tag

<r​ucknium:monero.social> If subsidizing attacking hashpower is their strategy, two (or more) can play that game. XMRvsBeast already does some subsidization of p2pool miners with the hashrate raffle, AFAIK.

<a​rticmine:monero.social> So about 6%

Current Qubic price is $0.000002281 per coin, and give 1T/week emission, it's $325k/day going to miners

double that of Monero's miner subsidy

So they in theory can overtake Monero in raw hashrate, they do have the money (daily subsidy)

The question is, how do they manage to keep the price from falling, they're a small cap coin

<a​rticmine:monero.social> This depends on the price difference and the effective emission of Qubic vs Monero

<o​frnxmr:monero.social> Do they have the buy liquidity to support that 325k/day 🙃

Their effective emission (in $) is two times bigger right now

<o​frnxmr:monero.social> You can claim 325k by looking at spot,but its not real if you cant exit your position without crashing the price to 0

<a​rticmine:monero.social> No they are getting Qubic to cover this

<a​rticmine:monero.social> It. Is an effective merged mining

So someone is dumping big money to keep the price afloat and subsidy the miners

<a​rticmine:monero.social> They have to keep the Qubic price afloat

<o​frnxmr:monero.social> right. They sell xmr for 30k/day, buy qubic with 30k (or put up buy walls)

<o​frnxmr:monero.social> hoping nobody actually mines qubic,sells 100% of it and buys 2x as much xmr

<a​rticmine:monero.social> Then they have to pay for power

Also, TradeOgre is currently down (this exchange had a huge amount of Qubic on the sell side).

<a​rticmine:monero.social> Bingo

That makes it easier to keep the price afloat, because there is a lot of coins locked there now and for an indefinite time

<a​rticmine:monero.social> Feed the Qubic to the bears

<a​rticmine:monero.social> ... but they can manipulate Qubic to mitigate this bear raid approach

<a​rticmine:monero.social> By locking the Qubic up

Also Qubic plan the halving in 3 weeks time, that will reduce the subsidy proprotionally (unless they manipulate the price again)

<a​rticmine:monero.social> Awareness can be a real problem for them

<r​ucknium:monero.social> If you want to fight fire with fire, the Core General Fund could temporarily subsidize honest hashpower. (Of course, I love volunteering other people's money 😁.)

The best way to subsidize XMR hashrate would be to pay P2Pool miners (proportionally to their hashrate) - it's easy to put together a list of miners every day for a manual payout, DataHoarder's observer can do it

<r​ucknium:monero.social> I don't know what other realistic active countermeasures there may be.

how would honest miners be picked

<r​ucknium:monero.social> If countermeasures are considered necessary.

I just wrote how

weight of their shares in difficulty units is tracked as part of consensus

<r​ucknium:monero.social> Right. The p2pool sidechain is a secure, honest way to get the addresses of miners.

Currently, all P2Pool miners earn 20-22 XMR/day. If 50 XMR/day are paid to them, that's double the profit and a good enough incentive for other miners to switch

No, not the double. More than triple, because it adds up

ah okay, and qubic block structure is incompatible with p2pool requirements?

Yes, they are incompatible

p2pool can merge mine, are they "merge mining" or doing something else?

<r​ucknium:monero.social> What if Qubic points its own hashpower at p2pool? Wouldn't the forced orphaning tatic fail, because other p2pool miners would be mining on other miners' honest blocks?

Qubic is merge mining Tari

<o​frnxmr:monero.social> Qubic was using p2pool before

No, they used nanopool

<o​frnxmr:monero.social> They used p2pool for a while too

I'm not aware of that, and I watch p2pool daily

<r​ucknium:monero.social> The `--enforce-dns-checkpointing` optional flag also exists, but IMHO its use should not be encouraged. Just a reminder that it exists: docs.getmonero.org/interacting/monerod-reference/#server

<a​rticmine:monero.social> I see as the better strategy " merge" mining Qubic by honest Monero miners

"Mining" Qubic leaves you no choice but to also participate in their attack

they use some centralized approach for mining

They just let you run xmrig pointed to their pool. Did nobody here actually try?

<o​frnxmr:monero.social> Moneroocean wrote about adding qubic to their pool, but wasnt as simple as a regular chain

<a​rticmine:monero.social> No if one can decentralize Qubic

<o​frnxmr:monero.social> matrix.monero.social/_matrix/media/…ero.social/QozzcjCsmwKnwuYBsREzxdyy

<a​rticmine:monero.social> Take the fight to their chain

They don't have one :)

<o​frnxmr:monero.social> matrix.monero.social/_matrix/media/…ero.social/vGPKThqFvmAAnCBOZVQjpBJg

<r​ucknium:monero.social> rbrunner: And xmrig doesn't let you pick the block template, right?

It runs fully under control of their "miner"

And you know what is really hilarious? So far on each day except Saturday they run xmrig only 50% of the time

<a​rticmine:monero.social> Is there the possibility of a Qubic chain split

Again, there is no chain.

<r​ucknium:monero.social> They have block explorer IIRC

Please, you all. Have a closer look. It's a very interesting beast. Very different.

<r​ucknium:monero.social> a block explorer*

<a​rticmine:monero.social> It is

No, they have a tick explorer

Those are not blocks in some blockchain

<r​ucknium:monero.social> Yes, what are those ticks?!

git has a commit explorer too

<r​ucknium:monero.social> I looked at the explorer a while, trying to understand.

I don't spill the secret, because people should have a look themselves.

Just for the record: Please take them serious as a credible threat.

<a​rticmine:monero.social> I agree

The first for years. Maybe that makes it all so difficult. To mentally switch.

<a​rticmine:monero.social> The degree of centralization in Qubic is key to the threat

Well, if ofrnxmr is right about Qubic using p2pool before (I don't remember that), then mining subsidy should be sent to centralized pools, preferably smaller ones. Because P2Pool lets you use your own node and therefore run an attack (orphan blocks).

<d​uggavo:matrix.org> I think the Qubic owner is a serial shitcoin creator. He does this just to gain attention and investors in his otherwise useless coin. Stop giving them spotlight and the solution will be already half way there.

Yeah, what a shitcoin IOTA was ... no innovation, no ideas, no nothing.

<a​rticmine:monero.social> My take is that the greater the awareness of this in the Monero community the lease the threat

Everybody here could have invented that, right? :)

<r​ucknium:monero.social> I could work on a couple of data tasks in this area: Set up a webapp for real-time charts of Qubic's probably hashpower share. I could also work on displaying any alt chains that appear and any transaction double-spends.

<o​frnxmr:monero.social> The problem is that monero community panics instead of doing anything

Even the Qubic fans themselves long for the realtime info they lost today, so do go ahead

<r​ucknium:monero.social> Alt chains are easy to get from the node. Double spends could be detected from the txpool data collection infrastructure I've helped run for years.

<a​rticmine:monero.social> I went through the 2018 Bitmain attack. The Monero community did a lot

ofnrxmr, please write down somewhere what "could be done".

<d​uggavo:matrix.org> I think the only way to really stop the risk of a 51% attack from the QUBIC - forever - would be changing the consensus system. Possibly to something similar to Zano's private 50% PoW 50% PoS. I know this would be very controversial here, but I think it could raise the security. Especially if the PoS blocks have a reduced block reward compared to PoW blocks.

<o​frnxmr:monero.social> People could spin up their miners instead of writr twitter threads about how we should switch to scrypt

<r​ucknium:monero.social> I have been thinking of ofrnxmr 's idea of a "delayed payout" for PoW miners. Seems interesting. But that's long-term. What are available plans in the short term?

<a​rticmine:monero.social> We need to avoid an overreaction

... as well as underreactions ...

The real way to stop it is to own all of the available CPU power, which Monero is far away from. They are only able to do this because their mining subsidy is higher at the moment.

if they are fully centralized and they can just point miners to new solution - no merge mining per se, but they can merge mining if they desire, they are like a big single centralized pool effectively

<o​frnxmr:monero.social> I said in lounge that i'm against POS, but also said that if we DID add hybrid POS that it should only allow staking of virgin, pow mined coins

<a​rticmine:monero.social> Monero is way stronger after 2018

pow mined coins are public, and then also there's the coalescing issue somewhere on github

<a​rticmine:monero.social> Selling manure can be very profitable

#108 and #109

would do well :D

<o​frnxmr:monero.social> And i'd also add that hybrid pos should be a 90:10 split, with 4 minutes per pow block and 4minutes per pos block

<r​ucknium:monero.social> I like the delayed PoW payout idea because it reduces the threat of malicious short-term CPU rental.

In terms of hashrate, Monero is way stronger than even a year ago. It was 2.2 GH/s a year ago, not it's 4.5-4.7 GH/s (not counting Qubic)

If Qubic happened last year, they would already be able to 51%

<d​uggavo:matrix.org> I'd agree with 9:1 reward split and 4 min PoW / 4 min PoS.

<a​rticmine:monero.social> POS has a host of issues

<d​uggavo:matrix.org> A low PoS reward mitigates many of the downsides of that approach.

<o​frnxmr:monero.social> my idea would only allow staking virgin POW coins. No buy-ins.

organically sourced moneros

<a​rticmine:monero.social> There is also another angle. Copyleft for mining code

<r​ucknium:monero.social> Those are "Coinbase Consolidation Tx Type" monero-project/research-lab #108 and

<r​ucknium:monero.social> "Avoid selecting coinbase outputs as decoys" monero-project/research-lab #109

<o​frnxmr:monero.social> Xmrig is copyleft

<a​rticmine:monero.social> The issue with POS is borrowing coins

They have a repository for their slightly modified xmrig. Again, nobody actually checked, right?

they'd have to borrow the private keys of a miner

<c​haser:monero.social> if there is a good overlay PoS design, this^ is it. I've been toying with a design for a while that has the same property.

<a​rticmine:monero.social> With a strong copyleft one can take down the repository

besides setting donation to 0 rbrunner this is the only relevant commit there yep rbrunner xmrig/xmrig b41fcf5

<r​ucknium:monero.social> ofrnxmr's idea mostly prevents borrowing coins because they cannot be transferred in an on-chain tx. And if you "sell" a private key to someone, then the seller can just use it, too. ANd nothing prevents you from "selling" the key to multiple buyers.

<c​haser:monero.social> and there need not be a staking reward per se. changing the monetary policy is off the table.

<d​uggavo:matrix.org> That would prevent "mine-and-dump", but I am not sure it could actually be secure. The stakers would be only a subset of the miners. I think it could actually reduce the security.

<a​tomfried:matrix.org> Wouldnt that mean a 51% pow attack acquires more and more power over the network?

<a​ntilt:we2.ee> after dedoubling eigentrust would be worth checking out (in the long run)

<r​ucknium:monero.social> It is better to spread the power over the network across a lot of time instead of concentrate in a few minutes, especially with an ASIC-resistant mining algorithm.

<o​frnxmr:monero.social> it would be a 25.5% attack if they have 51% of the pow

there was the wow change to require private keys to generate PoW solutions

that'd kill pools, generally

is that still working fine?

<d​uggavo:matrix.org> This assumes all the miners stake the coins indefinitely.

<r​ucknium:monero.social> For example: Today, a miner mines a coinase of about 0.6 XMR. They can spend 0.3 XMR of that now. In a randomly-selected time in the future, within the next year or something, they have to validate a block with their private key to make the other 0.3 XMR spendable.

<d​uggavo:matrix.org> Yes, Wownero requires the mining blob to be signed with the miner's private spend key. It works, but killing pools and killing P2Pool is not viable. Monero's blocks are too infrequent to allow that. It would centralize the network.

<r​ucknium:monero.social> I read that some pools implemented closed-source mining software to avoid wownero's strategy.

<r​ucknium:monero.social> I'm not sure how true what I read is.

<d​uggavo:matrix.org> Those pools must remain private and with trusted users. A pool with open registration would be leeched by miners who steal block rewards.

<r​ucknium:monero.social> like...Qubic (effectively)?

if you can run the miner locally, you have the keys

No, not exactly

Wownero solution only leaks you the tx spend key for a block you're currently mining

I remember because I helped them implement it

<d​uggavo:matrix.org> That makes sense. It's a sort of delayed Proof-of-Work. But how would that work with miners on pools or solo/p2pool miners who aren't always online?

Still, you can steal a block if you find it

either it's delayed or you can actively act in consensus PoS to accelerate that

so you can take very delayed coins, or PoS? but then the delay on part effectively does the same

doesn't change 51% attacks

that's done on hashrate alone, and if PoS would be a very minor part of the slice, that'd not affect as much

<r​ucknium:monero.social> duggavo: Pool operators get the coinbase reward, not the miners. So pools stay online. p2pool miners must stay online. If they block that you have to validate is at a specified time in the future, just make sure you are online when it's your time to validate.

p2pool miners don't have their wallets unlocked or have to

They don't need private keys to mine, no

in my case I mined to a cold wallet somewhere backed by a hw wallet

<r​ucknium:monero.social> It would change how much time you would have to possess 51% of hashrate.

<d​uggavo:matrix.org> I don't understand why not with 10:1 PoW:PoS block reward with 240s:240s PoW:PoS target block time. What's wrong with that?

<r​ucknium:monero.social> Then get online and get with the program :D

<r​ucknium:monero.social> HW wallet makers say don't mine to a HW wallet.

51% of hashrate or 51% of reward?

<r​ucknium:monero.social> That's up for discussion.

<r​ucknium:monero.social> It's a new idea worth exploring IMHO.

<r​ucknium:monero.social> Anyway, back to short term. Short term things that can be discussed?

like, if it's rations like 10:1 or anything like that it'd be at most 20% harder?

as mentioned before if they are effectively just a big centralized pool they can point hashrate anywhere, p2pool, other pools (?)

so funding these miners might not do the right thing

<r​ucknium:monero.social> You can have the share of blocks validated by the two mechanisms be different from the share of rewards. e.g. half of blocks validated by the delay mechanism, but 25% of rewards to the delayed payout.

<d​uggavo:matrix.org> Ratio of 10:1 would be for the reward, the difficulty ratio would be 1:1.

<d​uggavo:matrix.org> So in practice: 50% of the blocks are found with PoS, and they contribute to 50% of the overall cumulative difficulty. But they receive only 10% of the rewards.

<r​ucknium:monero.social> Alternatively, hashpower could be directly rented through miningpoolrentals.com

<r​ucknium:monero.social> The money would not "go as far" when directly renting, vs. subsidizing, I think.

Time for monero to make its own centralized pool funded by monero funds to mine monero?

<r​ucknium:monero.social> The meeting's length is about two and a half hours.

they could just point miners to this :(

<o​frnxmr:monero.social> thanks ruck. Ttyl

<r​ucknium:monero.social> People should feel free to continue discussing, but we can end the meeting here.

<r​ucknium:monero.social> Thanks everyone.

I thought this was the meeting after-hours talk!

I'll update my scripts to fetch block data from current pools that are available at least

<r​ucknium:monero.social> Thanks, DataHoarder. I ran the script today and everything seemed to work fine, but I did not check everything carefully.

<d​uggavo:matrix.org> I've had a couple of ideas about the eventual hybrid PoW / PoS consensus for Monero. Please let me know what you think. gist.github.com/duggavo/7b5f1f8cad5bd56c9f27648ccc1728ba