.merges

Well, guess I've got some stuff to review when I wake up again.

Is this the actual list of the merges for the next round? And are merge candidates still collected? If yes, can I humbly propose to include my PR #6614? Thanks!

rbrunner: these are just the reviewed ones AFAIK

Then I am a little confused: Is #6614 not "reviewed" in this sense?

Ah, maybe it needs a re-review after my latest conflict resolution changes?

rbrunner: approved it

Thanks!

.merge+ 6337

Added

.merge+ 6614

Added

.merge+ 6733

...

Hello everyone :)

I'm currently working on the integration of CLSAG signature for the Ledger Nano S/X. I've finished to integrate CLSAG on the Monero application and I need to test with the Monero client. I just want to be sure what to do before compiling branch clsag-reviewed-rebased!

What is your actual question ?

Is there any additional thing to do except adding a new hard fork in hardforks.cpp?

Use --fixed-difficulty 1 to avoid waiting for a long time when testing.

Nothing else I can think of.

Great!

(--offline of course, to avoid sending those bad blocks outside)

Thanks

moneromooo: It should 10 or even 11 in your #6753 patch. Can you explain why 9?

weight can be calculated since bulletproofs2 which is being forced since 11 hardfork, not 10 or even 9; And there are blocks with bulletproof tx between 10 and 11 hardforks.

Because borromean proofs are banned from v9.

In my log problem was with bulletproof tx too.

Which tx ?

there are many blocks with bulletproof tx [constant 3] before 10 hardfork

CHECK_AND_ASSERT_MES(tx.rct_signatures.type >= rct::RCTTypeBulletproof2 <<< Due to this get_pruned_transaction_weight supports only bulletproof2 txs.

That are being forced only since hf 11. So all blocks before can potentially contain unsupported txs.

Am i correct?

p.s. internet is awesome in my country :)

I guess so. I can't remember what the changes were. IIRC it was just ancillary stuff.

Should be very easy to change to all bulletproofs.

Yes you can improve weight calculation as you said before. But current version works with bulletproof2 only.

in short: I've synced with this patch paste.debian.net/plainh/cf925257

That looks right. Thanks. What name/email if any do you want for the patch ?

^ user.name=cohcho; user.email=chat.freenode.net/cohcho

btw, that p2p dos on minexmr and other pools was done by me

I know one more bug on p2p code but no way to test it now.

btw, was it applicable to hackerone bounty program? I thought no and decided to abuse it in reality.

Depends on the details. If you can DoS monerod via the p2p port, then it typically qualifies. Feel free to post it there.

^ I'm about concrete bug that you fixed shortly before recent release. xnbya told your privately about it.

Ah, the thing that uses lots of ram ? OK.

Was it heavy enough to get some reward via hackerone program?

That one's a bit on the unsure side. Using more ram is always possible, so when it starts becoming a security bug is... well, fuzzy.

Dunno. I guess we'd have had to chat with luigi and pony to decide.

& I have c++ app that i was used for DoS to prove that i'm the author.

That code can DoS even fast server with SSD since LMDB can't hide random accesses to DB.

does it really count as a DoS if monerod is still servicing requests?

even if it's running at degraded speed?

hyc 4 minutes between any requests to DB?

It is unappropriate speed for monerod used for mining.

my target was pools with open p2p port

4 minutes seems excessive, yeah. is the machine really in 100% I/O wait the entire time?

^hyc, no the reason isn't due to 100% I/O

anyway it was before cooperation btw xnbya and moneromooo. It will behave a bit differently after their patch.

But there are still some bugs.

and i don't know how much this info costs and didn't spend time on working PoC

dilemma :|

what dilemma? Identify the bug, submit a fix.

that's how open source projects work...

FWIW it's known that monerod isn't good at anti DoS generally. It's not really its job either.

monerod code is grossly inefficient, all over. gratuitous memory allocations, memory copies, all over.

would take a full bottom-up rewrite to improve.

Perhaps when the chain matures (whatever that means) some effort could be put into such endeavour

I like that problem was fixed somehow within 24hrs after my DoS on minexmr, moneroocean, 2miners, miningpoolhub. I didn't know any other way to cooperate efficiently. And It's took a lot of my time to write abuse PoC without any significant reward. That's disappointing.

Anyway I like this project and will try help somehow.

hello

we’re trying to figure out how that user a few days ago faked his XMC transactions into cake wallet

would it be enough to connect cake to an XMC node, or would he have to specifically modify the wallet?

AFAIK what you call XMC is an old monero versoin, right ? If so, the daemon will not accept those blocks as they're now invalid. Only daemons that didn't update still see them as valid, not the rest of the network.

It’s an old monero version which forked some years ago to officially support ASICs, yes.

If the daemon is old and accepts those blocjs, it's likely the wallet will sync from it.

It'd have to ignore the RPC version check.

Would that require modifications to the wallet?

But otherwise RPC is backward compatible AFAIK.

I'm not trying that to see.

Alright.

moneromooo did you go to college for computer science or are you just a rainman?

Or both?

Privacy and opinion, respectively.

I'm just curious about your training. How does one gain skills like you have? I would be happy to talk privately, but my motivation is only self-improvement and a desire to help the community.

Practice and curiosity.

You see something you'd like to change, and you try to change it.

Also, coding games is a fun way to learn stuff.

(small ones)

Also, grit. Stuff will break. Keep hacking at it until you vanquish the beast :P

And you need time. It helps to become immortal. You get a lot of time to think.

+1 coding games, that's where I started

actually I started by breaking existing games

I made a game before but then I look at the monero codebase and it is way more complex than my little space blaster game.

you work your way up in complexity over time

work on the nethack code

stoffu: in wallet2::set_tx_key, the code calculates rG (r being entered by the user) to compared with the R from tx extra. If the tx key was made from a transfer to a single subaddress, the R derivation is different, and involves the subaddress public spend key, which we do not have here.

AFAICT, there's no way to ascertain whether the r given by the user is correct. Is that right ?

If this is indeed the case, I'll remove the rG check.

I guess we could ask the user to also pass the subaddress.

Yes, might be better. If the user has r, they likely also have the subaddress.