.merges

.merge+ 8131 8130 8135 8126 8123 8117 8116 8112

Added

vtnerd: do you plan to do more multisig reviews or should we merge it now? I think the majority of your comments have been addresses on both #7877 and #8149

I think both PRs are in a good place now

jberman[m]: Thanks for the info, got it. I make an attempt today to achieve that. Had already partial success yesterday, but no breakthrough yet. As you found out already, it's tricky :)

would be sweet if you find a nice way to do it

thanks for looking into it :)

Did you stumble over a concrete example of software that stumbles with that particular difference in the JSON structure and would definitely need adjusting after the hardfork?

I am not yet sure there is a nice way to do it, might be a little hacky, but not too complicated once sorted out - hopefully :)

I don't think I did. I can't remember if the explorer needed finnagling because of it or not. I figure eventually it could cause needless problems/headaches, and because the view tag is just an optional thing there to make it faster to check if an output belongs to you, then it can in theory be ignored without breaking anything when reading a tx

I see

hey guys, just wanted to share my thought about the idea of banning pools by implementing mining key requirement like on Wownero fork: Low-spec machines will have no chance in solo-mining and ever increasing diff will kick out smaller miners, then medium miners, until there are only big farms left.

We are holding a dev meeting in a bit over a week. Feel free to add a comment suggesting the topic in the agenda if you want to.

Do note v15 network upgrade has a much higher relevance right now.

which would centralize the network hashrate in a more devastating way than what we have now with the pools,

kk

ypavtv97lx[m]: You may want to join #monero-pow as well. Lots of PoW algorithm discussions take place in there. :)

Matrix room should be #monero-pow:monero.social, or something similar.

is there any place where I can download signed hashes.txt for older Monero releases?

sech1: Doesn't the list of all releases on here have each their signed hashes.txt below? github.com/monero-project/monero/releases

it has sha256 hashes in the text, but not the signed ones

they all link to getmonero.org/downloads/hashes.txt which changes with every new release

Let's ping binaryFate on this then. Hopefully he can chime in w/ better insight than myself.

sech1: Github history has it

github.com/monero-project/gitian.sigs ???

that's reproducible builds from various people, not the actual hashes.txt from older releases

It's on monero-site, one sec

sech1: github.com/monero-project/monero-si…commits/master/downloads/hashes.txt

dEBRUYNE saving the day, once again. You are welcome. ;)

jackpot

thanks!

np :)

Now that spam on github seems to have quiet down, i would suggest to allow running workflows for all users except new github accounts. I see that in the GUI workflows are still locked for all new contributors, which could be quite annoying for both contributors and reviewers. See for example monero-project/monero-gui #3829

thanks dEBRUYNE, that's the place :)

im remaking the monero coingecko info text, can i throw out the bytecoin mention? i dont think a single person reading that cares about how monero was forked off a scummy dev a decade ago, out of anyone, you guys are probably the only people who even remotely care so i would like to hear your opinion

obviously the text will still state monero is based on cryptonote

monerobull: better ask in the general room. It's off topic here 🙂

ErCiccione: we have the default settings in regards to workflows, that person is a new contributor

There are three settings, one of the three allows new contributors to run workflows. Right now the stricter one is set, which doesn't allow new contributors to run workflows at all. I was suggesting to switch to the setting that disallow only new github users from using the worklows.

I think github set the stricter one as a default to save resources

but it's actually the most unconvenient of the three for open development

the monero repos are set to the second one

ok luigi1112 ^^ could you set this for monero and monero-gui?

Are boost errors common with monerod? Is there a way to build a version of boost for monero and just link that at build time?

what kind of boost errors?

let's see. I can get the stacktrace. seems to run fine (maybe a bit slow)

done

luigi1112: ty

bad_weak_ptr + some other runtime errors

But, I noticed in the issues that several people have similar issues.

monerod will run essentially ok, and in the logs they all had lengthy stacktraces. I can give some issue numbers to id what I mean

#6696 and #8132 especially

8132 seems most similar

The weak ptr one is common, can be ignored, it's a noisy error check.

randomx ones can also be ignored, there are fallbacks.

If there are others, might be interesting.

.