06:57:22 <rbrunner> .merges
06:57:22 -xmr-pr- 6329 6493 6500 6542 6546 6593 6600 6601 6618 6632 6634 6661 6662 6677 6679 6689 6691 6693 6698 6703 6712 6715 6716 6718 6720 6722 6727 6736
06:59:02 <Snipa> Well, guess I've got some stuff to review when I wake up again.
07:00:14 <rbrunner> 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!
07:01:59 <selsta> rbrunner: these are just the reviewed ones AFAIK
07:02:56 <rbrunner> Then I am a little confused: Is #6614 not "reviewed" in this sense?
07:04:05 <rbrunner> Ah, maybe it needs a re-review after my latest conflict resolution changes?
09:06:59 <selsta> rbrunner: approved it
09:08:22 <rbrunner> Thanks!
10:02:51 <moneromooo> .merge+ 6337
10:02:52 <xmr-pr> Added
10:35:55 <moneromooo> .merge+ 6614
10:35:55 <xmr-pr> Added
10:36:54 <moneromooo> .merge+ 6733
10:36:54 <xmr-pr> ...
13:34:51 <grydz> Hello everyone :)
13:41:26 <grydz> 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!
13:43:32 <moneromooo> What is your actual question ?
13:45:57 <grydz> Is there any additional thing to do except adding a new hard fork in hardforks.cpp?
13:46:33 <moneromooo> Use --fixed-difficulty 1 to avoid waiting for a long time when testing.
13:46:46 <moneromooo> Nothing else I can think of.
13:46:53 <grydz> Great!
13:47:06 <moneromooo> (--offline of course, to avoid sending those bad blocks outside)
13:49:08 <grydz> Thanks
15:50:50 <cohcho_> moneromooo: It should 10 or even 11 in your #6753 patch. Can you explain why 9?
15:52:40 <cohcho_> 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.
15:53:20 <moneromooo> Because borromean proofs are banned from v9.
15:53:49 <cohcho_> In my log problem was with bulletproof tx too.
15:53:57 <moneromooo> Which tx ?
15:54:30 <cohcho_> there are many blocks with bulletproof tx [constant 3] before 10 hardfork
16:00:19 <cohcho> CHECK_AND_ASSERT_MES(tx.rct_signatures.type >= rct::RCTTypeBulletproof2 <<< Due to this get_pruned_transaction_weight supports only bulletproof2 txs.
16:00:44 <cohcho> That are being forced only since hf 11. So all blocks before can potentially contain unsupported txs.
16:00:53 <cohcho> Am i correct?
16:01:09 <cohcho> p.s. internet is awesome in my country :)
16:01:33 <moneromooo> I guess so. I can't remember what the changes were. IIRC it was just ancillary stuff.
16:02:10 <moneromooo> Should be very easy to change to all bulletproofs.
16:02:45 <cohcho> Yes you can improve weight calculation as you said before. But current version works with bulletproof2 only.
16:04:06 <cohcho> in short: I've synced with this patch http://paste.debian.net/plainh/cf925257
16:06:30 <moneromooo> That looks right. Thanks. What name/email if any do you want for the patch ?
16:08:16 <cohcho_> ^ user.name=cohcho; user.email=chat.freenode.net/cohcho
16:09:58 <cohcho_> btw, that p2p dos on minexmr and other pools was done by me
16:10:23 <cohcho_> I know one more bug on p2p code but no way to test it now.
16:11:02 <cohcho_> btw, was it applicable to hackerone bounty program? I thought no and decided to abuse it in reality.
16:12:00 <moneromooo> Depends on the details. If you can DoS monerod via the p2p port, then it typically qualifies. Feel free to post it there.
16:12:38 <cohcho_> ^ I'm about concrete bug that you fixed shortly before recent release. xnbya told your privately about it.
16:13:01 <moneromooo> Ah, the thing that uses lots of ram ? OK.
16:13:43 <cohcho> Was it heavy enough to get some reward via hackerone program?
16:14:05 <moneromooo> 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.
16:14:38 <moneromooo> Dunno. I guess we'd have had to chat with luigi and pony to decide.
16:15:02 <cohcho> & I have c++ app that i was used for DoS to prove that i'm the author.
16:16:49 <cohcho> That code can DoS even fast server with SSD since LMDB can't hide random accesses to DB.
16:23:14 <hyc> does it really count as a DoS if monerod is still servicing requests?
16:23:23 <hyc> even if it's running at degraded speed?
16:23:31 <cohcho> hyc 4 minutes between any requests to DB?
16:23:57 <cohcho> It is unappropriate speed for monerod used for mining.
16:24:12 <cohcho> my target was pools with open p2p port
16:24:14 <hyc> 4 minutes seems excessive, yeah. is the machine really in 100% I/O wait the entire time?
16:24:29 <cohcho> ^hyc, no the reason isn't due to 100% I/O
16:25:38 <cohcho> anyway it was before cooperation btw xnbya and moneromooo. It will behave a bit differently after their patch.
16:25:54 <cohcho> But there are still some bugs.
16:26:12 <cohcho> and i don't know how much this info costs and didn't spend time on working PoC
16:26:17 <cohcho> dilemma :|
16:27:37 <hyc> what dilemma? Identify the bug, submit a fix.
16:27:44 <hyc> that's how open source projects work...
16:27:46 <moneromooo> FWIW it's known that monerod isn't good at anti DoS generally. It's not really its job either.
16:29:12 <hyc> monerod code is grossly inefficient, all over. gratuitous memory allocations, memory copies, all over.
16:29:35 <hyc> would take a full bottom-up rewrite to improve.
16:30:27 <dsc_> Perhaps when the chain matures (whatever that means) some effort could be put into such endeavour
16:39:38 <cohcho_> 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.
16:40:14 <cohcho_> Anyway I like this project and will try help somehow.
16:45:01 <KnifeOfPi_> hello
16:45:24 <KnifeOfPi_> we’re trying to figure out how that user a few days ago faked his XMC transactions into cake wallet
16:45:57 <KnifeOfPi_> would it be enough to connect cake to an XMC node, or would he have to specifically modify the wallet?
16:47:08 <moneromooo> 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.
16:47:36 <KnifeOfPi_> It’s an old monero version which forked some years ago to officially support ASICs, yes.
16:47:48 <moneromooo> If the daemon is old and accepts those blocjs, it's likely the wallet will sync from it.
16:48:25 <moneromooo> It'd have to ignore the RPC version check.
16:48:37 <KnifeOfPi_> Would that require modifications to the wallet?
16:48:40 <moneromooo> But otherwise RPC is backward compatible AFAIK.
16:48:59 <moneromooo> I'm not trying that to see.
16:50:04 <KnifeOfPi_> Alright.
17:52:13 <caralho> moneromooo did you go to college for computer science or are you just a rainman?
17:53:08 <caralho> Or both?
18:02:24 <moneromooo> Privacy and opinion, respectively.
18:07:00 <caralho> 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.
18:10:01 <moneromooo> Practice and curiosity.
18:10:31 <moneromooo> You see something you'd like to change, and you try to change it.
18:10:41 <moneromooo> Also, coding games is a fun way to learn stuff.
18:11:36 <moneromooo> (small ones)
18:13:12 <moneromooo> Also, grit. Stuff will break. Keep hacking at it until you vanquish the beast :P
18:15:20 <moneromooo> And you need time. It helps to become immortal. You get a lot of time to think.
18:21:08 <hyc> +1 coding games, that's where I started
18:21:19 <hyc> actually I started by breaking existing games
18:21:58 <caralho> 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.
18:24:22 <hyc> you work your way up in complexity over time
18:24:48 <hyc> work on the nethack code
19:10:31 <moneromooo> 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.
19:10:54 <moneromooo> AFAICT, there's no way to ascertain whether the r given by the user is correct. Is that right ?
19:11:09 <moneromooo> If this is indeed the case, I'll remove the rG check.
19:12:15 <moneromooo> I guess we could ask the user to also pass the subaddress.
19:13:01 <moneromooo> Yes, might be better. If the user has r, they likely also have the subaddress.