make test says it can't find /usr/bin/python. does it need python3 or python2?

I can symlink it but right now I have only python2.7 and python3

We may have something like a stalemate regarding the multisig PR 8149: monero-project/monero #8149

Looking back in the log over the last 2 days, this is how I interpret the comments of various devs - YMMV:

In favor of merging 8149 as-is: moneromooo, ErCiccione, kayabanerve[m], arnuschky[m], rbrunner

Against: UkoeHB, jeffro256[m], ooo123ooo1234567

(List just for info; with this I don't propose to do simple vote-counting.)

Any good idea how to proceed and come to a decision regarding this and the upcoming hardfork release? selsta, luigi1111

I would want to re-hear UkoeHB's commentary as they have the most important voice here and I'm honestly willing to simply defer to them. That would make it 4:4 from 5:3 though, and not really help :p

Well, he even suggested to disable current multisig, so the release would not support *any* multisig at all

and people wanting it had to compile their own binary

Considering it's flagged and explicitly experimental, AFAICT there's no concerns of liability (not that there was already. Just saying even from a PR standpoint as a project...). Anyone considering an enterprise deployment knows to wait. Anyone who already has one is already screwed. This can't make it worse and may solve it.

Yeah, and if we disable it now we probably will have to endure pointed questions why we did not disable current multisig months ago already ...

But that doesn't really help to decide either :)

So koe isn't against this over the current, koe is against it at all?

... ack. I'm fine with that.

But I'd hope for the sake of progress we get #8149 merged and THEN we open a partner to #8328 to make a compile time def

Which I fully ack will probably kill koe's movement to get it disabled and this is absolutely what a politician would say lol

That's how I interpret them, yes: libera.monerologs.net/monero-dev/20220607#c106196

But at the same time, this is stalled not because people are against this code compared to the current, but because people are saying we shouldn't ship unreviewed cryptography

The way to move forward is to separate the two

Though I will note I'm suggesting merging 8149 then tackling a 8328 compliment. We can tackle a 8328 compliment and if we make this a compile time def, 8149 integration doesn't matter as much.

So that'd give koe time to present their arguments on a fair playing field, instead of one predicated on being better than what ewe have, while still moving forward.

I am not sure what you mean with "8328"

Ah, I see: monero-project/monero #8328

And tbh, considering how multisig 1.0 did, I'll agree with that. Make multisig hidden behind a compile time def BUT I'd also advocate merging 8149 so we're not pointing people to koe's personal branch for multisig.

The "Disabled by default" merged PR

8328 made it a config. I'm discussing a compliment to make it compile time, not run time.

I see

Another variant, in a way

Compile yourself, but in a way that's a little easier

It's a separation of the two discussions which levels debate, as I'm only saying merge 8149 as current multisig is absolutely garbage, while enabling progress.

If we're removing multisig from Monero as we don't have any reviewed option and believe in ensuring security... good.

But not we have a WIP which likely handles most of the discussed issues and we have some users who already have multisig wallets. I see no reason to bar them from it. So now they have to compile multisig themselves to fully commit to an experimental feature while showing some level of tech proficiency.

It's open to debate, up to a point, whether 8149 is "unreviewed". IMHO only a review of the last few changes is missing.

Do we want them to compile the current garbage or compile 8149? Obviously, 8149. I don't want to point anyone to a personal GH though. Therefore, we should remove the current garbage as an option (as someone may mistakenly compile master instead of 8149), by merging 8149.

Maybe that's the compromise people can rally around. I am bit sceptic, however ...

rbrunner: I still have a review pending on my end, and I'm kinda stuck traveling the next week or so leading up to MoneroKon D: That said, it has had a notable amount of review, and I believe it's had more review that most changes to Monero at this point. The issue is a lot of review has been skin deep due to a lack of knowledge.

So for sufficient review...

<kayabanerve[m]> "Do we want them to compile the..." <- That's essentially my position too. It's madness to keep the current multisig mess in the code (it should have been removed months ago). 8149 is a significant step up (and I agree, at this point it had a lot of reviews).

I'm fine saying still not enough review and making this a compile flag though. EXPERIMENTAL_MULTISIG=1. I want to be clear there

Once merged, a few things can kick off: integration with partner libraries (monero-js, monero-cpp) etc, people can adapt to the new KEX changes etc. All this is possible once the code is merged.

I'm also fully ready to shame any corp/org which uses such a flag :p

*in prod

Integration would be healthy :)

As a separate discussion, the project should decide how to protect users / limit liability. I think a runtime option after a disclaimer is totally sufficient - it's crypto, everything's experimental, and honestly we're going a bit over board on the nanny-governance here imho.

But generally I think it's a great idea by kayabanerve to separate those two issues in order to progress in the decision making.

And then because I've been accused of having a conflict of interest here, in the most other-privacy-coin-bs way possible, I will comment I have my own original multisig work (fully MIT, not planning on making any money by limiting access to it). Therefore, I have the possibility to gain some form of notoriety by limiting Monero's native multisig so my own gains... market share? And something something, if I was evil, I'd say it

should be disabled.

¯\_(ツ)_/¯ I don't really get it. I think when I said it shouldn't be disabled, that's also what I would've said if I was evil, but if I knew it was problematic. Can't really win there

All I know is I was told I have a CoI and was talked to in a way which suggested I was evil :p So grain of salt to the people here, I guess

And thanks for the ACK :)

nah that conflict of interest argument didn't make any sense at all imho.

I don't either lol. Just getting out ahead of it before it comes up again

And if someone thinks it does make sense and this is relevant... well now it's a non-issue because I disclosed it

Reading the above, is the issue that the old 8149 is reviewed enough, but the new one isn't ? If this is what stops sone people, just merge the previous one and not the second one yet.

As far as I know that would be a bit unfortunate because then the functionality to make multisig tx *before* the hardfork would be missing

Sounds weird. That ought not take any cryptography.

So this suggests the new changes are this + some crypto, and they're likely independent.

Then... merge original plus compat, leave the new crypto out.

<moneromooo> "Reading the above, is the..." <- Afaik the new changes are all code-level:

- rebases to BP+ and viewtags

- low-level comment fixes

- enabling non-BP+ use of the new multisig code

Assuming it doesn't take too much time to split.

Then the "it's not reviewed crypto" argument seems bad faith ?

Who made it and can explain ? :)

it comes from another point: the crypto in 8149 is complex and had mostly surface reviews

More likely my inductions above are wrong :D

So this argument is against the whole of 8148 then ?

afaik nobody other than ukoe really went deep down on verifying them. all reviews on 8149 were code-level or superficial

so there's a lingering unease about the crypto changes in 8149

the rest has been reviewed plenty - more than most changes in Monero afaik

OK, that makes more sense then. Thanks.

That's why we commissioned the audit: have someone go deep on the crypto changes (of 8149 alone)

I think "lingering unease" is quite a good characterization. But anyway, technically it works. It just may be that we switch one vuln with the next :)

Quite unlikely IMHO, but still.

you all are choosing right words to justify whatever is needed to be justified, but I'm not sure how it helps to solve technical problems

ooo123ooo1234567: Technical problems is a bogeyman until we have explicit examples. We can't prove a negative though.

So we're discussing how to balance this as we should. My recommendation would be make this compile time set, not runtime like it is now, yet still merge 8149 to purge the garbage and move ownership into Monero.

Then we can get further review to solidify our stance the bogeyman doesn't exist before we start being open to attacks by the bogeyman.

And I don't use the term bogeyman to say there aren't issues. I'm saying we should make this compile time and unofficial (instead of official as experimental). I use the term bogeyman to highlight he will always exist and we'll never truly know.

why did you delete your rust package with multisig ?

not ready / experimental ?

<kayabaNerve> "ooo123ooo1234567: Technical..." <- negative side effect can be proven with exploit, positive side effect can be proven by passed test, lack of negative side effects can be proven with proper verification; what exactly can't be proven ?

<kayabaNerve> "ooo123ooo1234567: Technical..." <- I've said you all are good at choosing words and you're using this "bogeyman"; facepalm

tests only prove lack of known bugs

you can't prove that it's bug free

unless you dive into formal code verification

<ooo123ooo1234567> "why did you delete your rust..." <- I didn't delete it. I had a rust multisig, not monero multisig package public and privatized it for a few reasons. Please stop with the ad hominem confrontations

sech1: did you notice "positive side effect" ?

"lack of known bugs" = positive side effect

ooo123ooo1234567: You can prove a positive. You can prove there is an exploit by... Proving a negative is distinct. Sure, there is formal verification. I don't believe it's feasible to formally verify the entire Monero binary and the OS it runs on for such perfect security.

It becomes a question of scope. We can write up the algorithm and get that formally verified. I wouldn't be against that and I may even say we should hold off on deployment until... But even that wouldn't be truly proven.

MuSig was considered secure and had several pages of proofs. Then Drijver's published their work.

GG20, considered secure. Alpha Rays.

kayabanerve[m]: MuSig and 4 other signatures had broken security proof

We can't sit around to the heat death of the universe here. Merging this removes the horrible code that definitely shouldn't be used. Putting it behind a compile time guard ensures only people with sufficient technical savvy can enable it, which hopefully gives the opportunity to communicate its status.

ooo123ooo1234567: Wow imagine completely missing what I said

"considered". MuSig was considered secure. Yes, work was done to prove otherwise. I'm not contesting that. I'm saying despite their pages of proofs, and the bounds they believed they proved despite acknowledging questions remaining, those bounds were broken only after a notable amount if time

Please try to be trolled in another channel.

I'm saying it's completely infeasible to perfectly verify the theory and implementation of Monero multisig. There may be errors in the write up, errors in the proof, new theoretical attacks, errors in the implementation, errors in the OS predicated on Monero's usage... So at some point we have to say this is good enough. It is how it is

<sech1> "unless you dive into formal code..." <- and then you can only prove it matches a specification - but there may be bugs in that specification...

Let's ack mooo and move on from this.

kayabanerve[m]: if someone can't write proof and there is at least 1 example in history with failed proof then there is no need for proofs. it's what you're saying

kayabanerve[m]: Btw, do you know what was wrong in their proof ?

arnuschky[m]: The audit should be finished shortly right?

> <@kayabanerve:matrix.org> You can prove a positive. You can prove there is an exploit by... Proving a negative is distinct. Sure, there is formal verification. I don't believe it's feasible to formally verify the entire Monero binary and the OS it runs on for such perfect security.

>

> It becomes a question of scope. We can write up the algorithm and get that formally verified. I wouldn't be against that and I may even say we should hold off on deployment until... But even that wouldn't be truly proven.

Imagine someone would say all these words for the question: "can you prove security of this?"

<moneromooo> "Please try to be trolled in..." <- It isn't me who is choosing right words to justify blind merge.

<kayabanerve[m]> "I didn't delete it. I had a rust..." <- I'm about monero-sign-rs repo.

Anyway, according to earlier decisions which nobody revoked so far we aim for a release on June 16, which is pretty damned sure

So I would say we best arrive at a decision what to do with 8149 in the next few days

It doesn't look to me that we are getting close, unfortunately

So good ideas are needed how to resolve this problem

I don't have any right now, but we are quite a number of people here. Not yet time to despair.

Er, I meant of course "pretty damned soon" :)

in one week

How many Monero blocks is that? :)

a week's worth

5040 blocks

Clearly, we must switch to 10 min blocks in an emergency fork, just to push back the next fork.

That proposal is at least innovative

<rbrunner> "It doesn't look to me that we..." <- Split the two proposals. Select the people you want to weigh in. Get their comments. Provide a summary. We can trivially merge 8149 AFAIK. I'd ask if mooo is available to make the runtime flag compile time. Then the only remaining question is final review of the multisig C++ and double checking the compile time view.

That's my vote, anyways, and I've already provided my comments on the split proposals.

I feel most people objecting to the merge are objecting to multisig. Not objecting to this multisig over the current.

moneromooo: "Please try to be trolled in another channel." this msg falls into this category too

<kayabanerve[m]> "I didn't delete it. I had a rust..." <- Question about repo isn't "ad hominem confrontation". It's just an interesting piece of code/information that is currently not available. I've just asked why.

if koe is against merging 8149 as is then i would follow his recommendation

he spent the most time on it apart from ooo

I'd want to check their thoughts on merging 8149 with the compile time guard. AFAICT, it's either that or we leave the current multisig code in (with the runtime guard or with a compile time guard). Given that choice...

merging improvements vs trying to do it properly on first try becomes a philosophical question, in both cases multisig would stay insecure until considered otherwise

selsta: One is known to be incredibly insecure. One is considered insecure to be safe. This PR is an improvement.

in both cases multisig should not be used in production so it doesn't matter

While I'm not endorsing it as a result, and not saying we should remove the runtime guard (the opposite, actually), I am endorsing taking a step towards something better while we wait for the RINO audit and figure out our next steps, such as formalization and further audits.

selsta: Considering I assume we have existing users who use multisig and can't simply give it up... I feel it's important they at least use the better option.

I'm mainly concerned about people with existing cold wallet setups.

As in, organizations and exchanges who already use multisig and need to continue to use it to function. They can't sit on funds they need access to.

<dEBRUYNE> "arnuschky: The audit should be..." <- yes, we should have results early next week

So while I agree it shouldn't be actively used, I'm advocating this as a way out.

I thought we are adding a runtime flag for that that makes it clear all multisig participants have to be trusted.

... right, but there's still known attacks on it. 8149 doesn't have known attacks.

So while we should at least keep that runtime flag, it's still undeniably better to have it next to 8149 than the current.

The other discussion is making it a build time guard so users actually need to compile a daemon and agree to that notice, rather than download the bin and set a config. I'm also leaning in favor of that and it's what I wanted to query koe about.

So I'm proposing at least +8149 and preferable +8149 with a build time guard for multisig as well

kayabanerve[m]: original PR also doesn't have known attack, but for some reasons someone decided to add few more patches on top of it and now you're pushing to merge it; facepalm

The original PR does have a known attack.

kayabanerve[m]: which one ?

I believe it was already disclosed on koe's PR. I don't care to further disclose anything at this time.

It wasn't introduced in that PR, yet it also wasn't handled by it.

So there's a reason those "few more patches" exist.

Maybe this: monero-project/monero #8149#issuecomment-1114060387

Considering you abandoned that PR, I also wouldn't bring it up now. It's an egotistic attempt to the person who's the PR author (instead of co-author) when your work is much more limited and the co-author you're trying to remove rescued it.

* attempt to be the person

rbrunner: Yep. That was fully disclosed then.

kayabanerve[m]: Why is it considered as abandoned ?

So selsta: It's not about endorsing 8149. It's about being robust by fixing several issues. The warning will remain. People still shouldn't use multisig. Some people still will. Now they have less to worry about.

kayabanerve[m]: right, I can follow your thoughts but I still think it's best to not merge it yet if koe recommends that. runtime vs compile time doesn't matter to me personally.

kayabanerve[m]: write code that fixes problems - egoistic, resubmitting patch of someone else - not egoistic; facepalm

For me it's interesting to hear what he thinks about the compromise of merging but disabling so people have to compile to arrive at working multisig

I don't think that version was on the table yet in past discussions

You're egotistic for trying to be the sole author when the co-authored work is the best form. You abandoned it when you stopped discussing it with koe for weeks and left multiple comments unresolved, didn't object to the new PR, didn't contribute to it, and didn't incorporate its changes into your own work to reclaim the mantle before koe spent months with this. I appreciate your original work, and am not calling it egotistic, and

koe explicitly noted your contributions, making their work not egotistic. I've not replied to several of your messages, and will go back to that, yet wanted to be clear on my stance here.

I only hope that we don't finally arrive at a situation where scammers will be able to take advantage of

"No working multisig in your Monero daemon? And not able to compile yourself? Here, use my RAR, password is SCAMMER"

my recommendation: add runtime flag and everything else gets merged when we are confident, without rushing it because it's a theoretical improvement. will keep it as that otherwise we are running in circles

rbrunner: I was also concerned about this, which is why I was going to suggest keeping the runtime warning, yet that could also just be compiled out and...

We could of course also decide to treat Monero users as mature and reasonable beings, able to decide themselves, and offer them 8149 plus runtime config, but maybe now I am just dreaming :)

<kayabanerve[m]> "You're egotistic for trying to..." <- if some discussion about PR is stopped then it doesn't mean that PR is abandoned.

rbrunner: 8149 being on a branch is a compile time config :p Issue is the default is the one that's definitively worse.

selsta: "because it's a theoretical improvement" I think this is a part that makes the whole thing so difficult: It's definitely more than a "theoretical" improvement

I think it replaces code with one or even several known vulnerabilities

rbrunner: same applies to 7760 and it's still unmerged

Yes, another place where some people run around in circles :)

I just wait until the running around in circles regarding the serialization improvement / replacement PR starts ...

<kayabanerve[m]> "You're egotistic for trying to..." <- Previous multisig had a lot of co-authors, but for some reason wasn't secure. Is it sufficient counterexample for your theory about what's the best sole author or co-author ?

I think soon enough our planet will have turned further enough for UkoeHB being able to join the splendid fun we have here

Maybe let's have a working multisig for the worldwide Monero community and add the authors there then? 🤔

<kayabanerve[m]> "You're egotistic for trying to..." <- How is it possible to refer to the same with egoistic and not-egoistic in the same paragraph without cognitive dissonance ? Where is your critical thinking ?

<kayabanerve[m]> "You're egotistic for trying to..." <- by this logic anyone could add stupid questions under arbitrary PR, wait until PR author will start ignoring them and then resubmit PR in the same vein; facepalm

Solution? ooo123ooo1234567:

Or what do you believe to be the best action to take regarding all of your PRs?... (full message at libera.ems.host/_matrix/media/r0/do…d1a2dc13a871e2328af5e798048fb261941)

Since ooo123ooo1234567 is too immature to take responsibility (which is so incredibly unmanly and pathetic), the changes I made in 8149 don’t have any reviews. Waiting for the audit results should be the bare minimum before merging, unless someone else actually looks at all the diffs and approves it.

UkoeHB: For those who took responsibility and failed what would be the punishment ? The same question for previous multisig or any other failures ? So far it looks like responsibility for any flaws was shifted to auditors which are known to be good at dodging any responsibility. So no responsibility in practice.

<UkoeHB> "Since ooo123ooo1234567 is too..." <- And why do you think that I've refused to take responsibility for my own patches ?

I would say blind merge is a sign of lack of responsibility. And careful treatment of changes is a sign of responsibility.

So far it looks like blind merges have the highest reward and 0 punishment. And careful merging has 0 reward and the highest punishment.

ooo123ooo1234567: Review some of these bad merges ? You're seeing things the reviewers are missing (or not even looking at)

Wow, 4 or 5 people discuss for hours how to treat 8149 sensibly and responsibly, and still get accused of "merging blindly", "lack of responsibility" and similar. Motivates like hell.

while we're at it, can someone merge 8381 blindly? :D

Folks. The wording used by s

Somebody is clearly crafted without the intention of building a constructive discussion. Please keep that in mind

Don't answer to the continuous provocations and insinuations of the anon. No amount of knowledge compensates the ability of working in team, which is the only fundamental skill necessary to do collaborative development.

No need to push to the other extreme...

Not an extreme at all. An important work is jeopardized by the unability of some people of collaborate. Everyone is useful, no one is necessary.

I scrolled now one day of conversation and it was filled by useless provocations and answers to those provocations

If the "other extreme" is to ignore somebody unable to conversate without ridiculizing their counterpart, so be it.

Knowledge is power

Obviously, the extreme is "the ability of working in [a] team [is] the only fundamental skill necessary to do collaborative development.". You also need enough capability to not be a net negative.

Both are needed.

Sure, i simplified to make the point. Obviously you need to be able to collaborate and other things.

Should we just set a meeting where we can decide what to do once for all?

We really need to take a decision on this and seems like the discussion keeps going in circle. Let's set a meeting and decide there once for all. Even by vote if necessary. Stalling on this cannot be an option. Would people participate? Maybe the coming week end?

After the audit results are known maybe ?

Then we know if it's good, easy to fix, or borked.

ErCiccione: idk what we can decide without the audit results

other than 'lets see what the audit has to say'

Sure. That's what i proposed the last time. I'm assuming the audits will arrive before the weekend, but we can wait for them to be released before setting a date if we are more comfortable with that.

<dEBRUYNE> arnuschky[m]: The audit should be finished shortly right?

arnuschky[m]> <dEBRUYNE> "arnuschky: The audit should be..." <- yes, we should have results early next week

not before the weekend, apparently.

<ErCiccione> "I scrolled now one day of..." <- everything can be treated as useful or useless depending on the goal, what did you keep in mind when decided that it was useless ?

I assumed wrong then, my bad. Let's already set a meeting for next weekend then?

<moneromooo> "Then we know if it's good..." <- or inconclusive

In fact, I'm not sure if we need a meeting. If the audit says all good, it goes in. If it's just stuff that's easy to fix correctly, fix and it goes in. Bad stuff, it doens't go in. We only need a meeting if it's not too bad but not trivial to fix...

UkoeHB likely being the one to assess how easy it is to fix.

(but we can have a meeting too)

Yeah. Bit pointless to fork out for one if it was going to be unused.

<ErCiccione> "Not an extreme at all. An..." <- writing patch that fixes problems and waiting for proper review - jeopardized, resubmitting patch of someone else with unimportant changes on top and skipping proper review - not jeopardized; facepalm

" everything can be treated as useful or useless depending on the goal". So true. For once this put a smile on my face.

Note the week-end next week (18/19th) is Monerokon in Lisbon so lot of people will be busy

something is wrong with monero-lws and wallet2

where is the definition of light_wallet_get_unspent_outs()?

its declartion is in wallet2.h

wallet2 does not have a current or even complete impl of light wallet client features

i mentioned in my 2019 talk there's an assertion in there with the wrong condition

if anyone runs it i bet it will trip

ohh damnnnn

we just thought it supports monero-lws

no

wallet2

oops

wallet2

ugh

anyway it does not

damnnnn

monero lws uses scanning code from core crypto and makes its own algo

that's why it should all converge

lol

i was curious about why monero-lws fails at parsing JSONs from wallet2

idk what a json from wallet2 is tbh

damn wallet2

the reasons are all visible in the lws code

why damn wallet2?

you mean other options like monero-cpp?

it merely needs to be factored as i have done and i need to set aside some time to PR those factors

what are other options??

we've discussed this a few times by now i think

i'll share my most recent repo very soon

would be nice to have a helping hand

but for now i have no one helping me

anyway my blocker is legal at present

just waiting on attorney

the code i wrote is copyrighted sufficiently etc

complicated and stupid mess of a situation though

but simple solution. give it a couple days pls

mymonero core cpp is flawed

i fixed various issues in it besides the ones that were given to it after i left

C++ is dumb

uh no

CMake is more dumb

sure

ttyl dude

C++ can be written gooooodü

butttt

there are some issues in minds

about design patterns and things

i really can't understand this codes

why written like this

cursed code

a kind of cursed code the reason behind this is damn C++ and its design patterns and approaching curse

structs and snake case namespace in C is the besttt

i really can't understand why Monero devs didn't write build recipes for dynamic and static libraries for Monero API

we could use them easily

because you didnt write them yet

that is the answer

anyway they do exist

i agree the open source way

but still wrong

private parties have little incentive to release or maintain them unless they have enough resources

because they don't care while they are writing harder parts

MeowingCat: yes you are right

and how are you different?

i said this in my talk

basically

i said MeowingCat specifically

likes to meow a lot

i mean the code is there

The existing light wallet code in wallet2 is most likely inoperable. I remember at least one obvious "this can't work" thing, though I can't recall what it was, but it was prima facie evidence it did not work.

so use my code dude

just need build recipes for static and dynamic libraries

endogenic, it can't be built lol

i mean this

i wrote my lws code ages before it was added to wallet2

CMake is dumb

when i open the source folder in VSCode

linter can't do anything

for Monero sources

sorry dude

that sucks

because the linter can't work with non relative include paths

can you DM me?

or some ghost macros

i'll help you get up and running if i can

gtg 4 now

<MeowingCat> "something is wrong with monero-..." <- can you elaborate

hiiii again

MeowingCat: for static analyzer, copy the compile commands file from your build/release directory into the main directory (afaik it has to be generated by the make command if you want the tests directory to be included).

Or configure your analyzer to read that file from build/release I guess

build/[yoursystem]/release *

UkoeHB, i know compile_commands.json

it is really an interesting thing

trying to fix a wrong approach with another wrong thing :(

Ok I don’t care about that

we can't build monero-cpp and other Monero things because of this design issue

damn CMake and other things :(

for example linking wallet2 API is a very common thing

but i worked hard to find all static libraries that i need to link for that

it might be easier

when i finish Monero part i will just build it to also a dynamic library and use it in my C# library for making transactions

and we will have a .Net library that can derive keys and make transactions for Monero

butttttt i would wish this things could be problemlesssss

when i see building issues that are not because of code's platform abstractions

i feel really badddd

just build script issues

Sounds like something you could work on to improve

i willl when i have time

Great to hear :)

im not an extreme math catttttttttt

i would like to implement Monero's transaction builidng and signing in other languages :(((

In Whitespace. Good language for privacy tech. Appears all the same.

Alternatively, Malbolge. Comes pre-encrypted.

finding the library dependencies is easy enough. just read the CMakeLists.txt

<sech1> "moneromooo ooo123ooo1234567..." <- what's the maximum execution time for get_block_template_backlog so far ?

looks good so far: paste.debian.net/hidden/f6282567

my node is running this PR

those timings are for the whole submit_block RPC though

2642086 was a full block with 162 transactions, it took 1.25 seconds

this function is closer to fill_block_template, but it's a bit more dumb since p2pool has more sophisticated internal solver; previously it was greedy and slow backlog fetcher, after patch it will simplified fill_block_template for p2pool specific needs

* this function is closer to fill_block_template, but it's a bit more dumb since p2pool has more sophisticated internal solver; previously it was greedy and slow backlog fetcher, after patch it will be simplified fill_block_template for p2pool specific needs

<sech1> "2642086 was a full block with 16..." <- that's the same as fill_block_template or very similar, not sure what's the precision of current comparison

<sech1> "those timings are for the..." <- m_txs_by_fee_and_receive_time is in sync, it's what is being used by internal miner during new block template update and called right after miner notifications within blockchain.cpp

sech1, what do you expect from backlog of txs received via zmq ? your code doesn't verify anything except doing optimizations for the best block reward.

s/your/p2pool/

what's the point of this question?

why p2pool should verify anything?

sech1: if there is an edge case when returned txs can't be combined into block, then is it expected or not expected ?

can't be combined why?

monerod checks every tx before sending it

<sech1> "can't be combined why?" <- github.com/monero-project/monero/bl…c/cryptonote_core/tx_pool.cpp#L1548, there are duplicate key images from blockchain (such txs excluded by is_transaction_ready_to_go) and there are duplicate key images within mempool itself, fill_block_template is checking for both, get_block_template_backlog is checking for duplicates relatively to db

> <@sech1:libera.chat> can't be combined why?

* github.com/monero-project/monero/blob/master/src/cryptonote\_core/tx\_pool.cpp#L1548, there are duplicate key images from blockchain (such txs excluded by is\_transaction\_ready\_to\_go) and there are duplicate key images within mempool itself, fill\_block\_template is checking for both, get\_block\_template\_backlog is checking only for duplicates relatively to db

In theory, if p2pool will get 2 double spend txs from mempool such block will be invalid

<sech1> "while we're at it, can someone..." <- indeed, why not to merge ?