03:45:02 <scoobybejesus> matching hashes here
13:41:17 <selsta> can someone who did v0.18 build upload binaries somewhere?
13:52:49 <sech1> I can when I get home 
13:53:28 <sech1> In 10-15 minutes 
13:53:34 <selsta> ty
14:08:33 <sech1> selsta https://p2pool.io/v15/
14:09:01 <selsta> don't look :D
14:37:37 <selsta> monero-mac-armv8-v0.18.0.0.tar.bz2
14:37:42 <selsta> does it make sense to name it like this?
14:41:17 <sech1> Downloads on getmonero.org don't use the original names anyway
14:41:25 <selsta> yes i rename them usually
14:41:26 <sech1> Download URLs
14:41:29 <selsta> and thens end them to bF
14:41:34 <selsta> send*
14:42:27 <sech1> monero-architecture-OS-version.tar.gz
14:42:34 <sech1> current naming is pretty straight-forward
14:43:22 <selsta> https://paste.debian.net/hidden/b64b9f0d/
14:43:46 <selsta> that's how we rename them currently before uploading them to getmonero.org
14:44:21 <sech1> also good
14:44:31 <sech1> it's more important to keep it consistent
14:45:11 <selsta> my worry was what happens when apple uses armv9 but it should be backward compatible
14:46:31 <hyc> I suppose we could have used arm64 instead
14:55:18 <selsta> arm64 would be better but it would be inconsistent with our existing armv8 used by other OS
15:37:01 <vtnerd__> ukoehb: I will do 8426 as well. Im probably one of the few people that knows the server code well enough
15:39:37 <vtnerd__> my preference was something piecemeal, which is why I was refusing to review it, but it seems like I am in the minority
15:40:25 <ofrnxmr[m]> Its merged already though 
15:40:27 <ofrnxmr[m]> 7999 please 
15:40:38 <vtnerd__> ugh gross
15:40:57 <vtnerd__> I know I haven't been reliable as of late, so I guess I cant complain
15:41:22 <vtnerd__> Ill probably look at post merge changes on that one, I recall there being unnecessary code in spots unless jberman removed it
15:42:11 <vtnerd__> oh lord 7999, no way
15:42:28 <vtnerd__> I have an alternative that Im working on rebasing
15:42:34 <ofrnxmr[m]> Yeah, would be nice to have a once over on jbermans changes, as he did try to address some of your comments 
15:42:42 <vtnerd__> there's almost no one that could maintain that other than me
15:42:57 <vtnerd__> I tried to re-write it in a sane way using stuff from monero-lws
15:43:07 <ofrnxmr[m]> Jberman has said he would do 7999 
15:43:20 <vtnerd__> let me point him to the alternative then
15:44:41 <vtnerd__> https://github.com/monero-project/monero/compare/master...vtnerd:monero:replace_p2p_serialization
15:45:05 <vtnerd__> jberman[m]
15:45:50 <vtnerd__> selsta asked for a rebase which will get done today somehow as well
15:46:13 <vtnerd__> jberman should be familiar with both styles, and at least one other commenter preferred the method I went with instead
15:46:54 <vtnerd__> its a more natural c++ style than that beast - reviewing for correctness was/is way more complicated than my patch imo
15:50:10 <selsta> we had to make a decision with merging or not merging and it wasn't clear how available you are in the future. jberman spent a lot of time reviewing 7760 and without it the remote node performance is quite spotty.
15:50:15 <selsta> so we decided to merge it
16:26:52 <jberman[m]> vtnerd__: on 8426, there was some unused logic from 7760 that I didn't remove, I made 0 logic changes to the PR; the cancel_ booleans/if ladder structure seemed to be useful to have greater explicit control over execution flow. In the handshake solution, it's a lot clearer how it works to achieve that
16:26:56 <jberman[m]> I specifically asked perfect-daemon about this boolean logic, here's what they said:
16:27:23 <jberman[m]> > I want strict async code that can be started/stopped and reused on the same memory. It means all dependencies within async code are handled.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/23af2ffb8bf986213ac20373f35131291ec8ec2d)
16:27:31 <jberman[m]> I felt that was strong enough justification to leave it as is
16:28:07 <jberman[m]> Still, I think it would be useful for you to take a deep pass at it (though fwiw, I think multisig makes sense to prioritize; I would work on multisig if I felt I have the skills to meaningfully push it forward in a reasonable amount of time). I agree piecemeal 7760 would have been nice, but the problems were structural enough in nature I understand why they chose a complete rewrite + they did (/do?) want to implement even more changes
16:29:53 <jberman[m]> <vtnerd__> "https://github.com/monero-..." <- Have seen this + yep have gotten deeper into lws serialization stuff as well. First pass, I'd probably prefer yours too. I was gonna look at both 7999 and yours at the same time
16:32:59 <ofrnxmr[m]> Do they both fix the same issues?
16:33:00 <ofrnxmr[m]> https://github.com/monero-project/monero/pull/7999#issuecomment-938125704
16:33:00 <ofrnxmr[m]> https://github.com/monero-project/monero/pull/7999#issuecomment-938177169
17:41:04 <jberman[m]> ofrnxmr: I assume that’s why it’s in the convo/proposed as an alternative. I want to review both
17:52:18 <ofrnxmr[m]> Competing PR's was one of ooo's wishlist items either way 😉. I have no preference aside from whichever is functionally better. The naming of them is similar, but whether they both solve the same issues, or one does more/less etc is just my curiosity. Ie, are these directly competing? Or just some overlap?
17:52:18 <ofrnxmr[m]> 5000 lines vs 2500, I assume there are at least some differences, just wondering, low level, what they are, if any :)
18:02:18 <jberman[m]> Ah, ya I’m curious too :)
19:15:30 <rbrunner> " I have no preference aside from whichever is functionally better" At least for me complexity also plays a big role
19:15:38 <rbrunner> And with this I don't only mean pure number of lines
19:15:55 <rbrunner> But "complexity" in a more, well, complex sense :)
19:16:51 <UkoeHB> With seraphis I have deprecated locktimes for new txs, but coinbase enotes still need to be locked (e.g. for 60 blocks like currently). My tentative solution is to just have a special 'coinbase enotes cache' that stores a new block's coinbase enotes temporarily, then after the coinbase locktime they are automatically added 'officially' in the block where they are unlocked (as a matter of consensus - so a block is invalid if it doesn't 
19:16:51 <UkoeHB> contain the coinbase enotes from the block 60 blocks ago). Does this seem viable, or is there a better solution?
19:16:53 <rbrunner> Personally sometimes I choose a solution that it a little inferior in some interesting dimension if it's significantly less complex
19:17:57 <moneromooo> You could make the rule "any output with a fake blinding factor (I) is locked for 60".
19:18:12 <moneromooo> No need to store any extra data.
19:18:49 <moneromooo> I'm not even sure why oinbase outs are locked for longer.
19:18:56 <UkoeHB> locked outputs can't be onchain due to deterministic ring member references
19:19:21 <UkoeHB> or at least * there can't be a non-uniform lock policy onchain
19:20:03 <moneromooo> THis seems inconsistent with locking coinbase for 60, unless every other output is also locked for 60.
19:20:19 <moneromooo> (and that's gonna cause some whining :D)
19:20:30 <UkoeHB> what's inconsistent?
19:20:54 <UkoeHB> I suppose it could be a 50-block cache lock, then the default 10 block onchain lock
19:21:08 <moneromooo> "there can't be a non-uniform lock policy onchain" vs "coinbase enotes still need to be locked (e.g. for 60 blocks like currently)" coupled with my assumptiom of "nornmal outs are locked for less than 60".
19:21:56 <moneromooo> Anyway, given I'm not following much anymore, I should really not waste your time and will shut up.
19:22:50 <UkoeHB> well it's a good point about the 10 block onchain lock, thanks
19:23:56 <UkoeHB> I guess it's more of an indexing lock, since the block that creates coinbase enotes will make them 'onchain'.
19:57:13 <BusyBoredom[m]> Why do coinbase outputs need to be locked 6x longer than normal ones? 
19:57:13 <BusyBoredom[m]> The only answer I can find online is a stackexchange answer that vaguely says it's to protect against reorgs, but what makes reorgs involving spent coinbase outputs so dangerous compared to reorgs with normal outputs? 
19:58:35 <tevador> because a reorged coinbase output disappears forever, while a normal output goes back to the mempool and can be mined again
20:00:17 <BusyBoredom[m]> Ahhh ok got it, thank you. 
20:01:58 <moneromooo> Why is that worse (beyond the fact that a reorged non-coinbase output has a chance to be mined again with the same index, which is a small chance) ?
20:03:45 <jberman[m]> Locking coinbase outputs longer makes a deep reorg more costly for a malicious miner since it makes it harder to sell their coinbase outs and then reorg (the malicious reorg has to be much deeper)
20:05:33 <moneromooo> That's a good one, thanks. Though a malicious miner could do the same with outputs of much higher non coinbase value in the first place.
20:05:48 <moneromooo> So while true, it doens't seem to be a good enough reason.
20:06:00 <jberman[m]> Ya, I think it’s a questionable decision
20:06:11 <jberman[m]> Unless there is more to it
20:07:45 <moneromooo> Does Bitcoin do a similar thing ?
20:08:09 <moneromooo> Oh they don't lock in the first place I think, nvm.
20:11:57 <UkoeHB> might be worthwhile to investigate removing that rule completely
20:12:14 <UkoeHB> surely if it has some value, someone somewhere in the big cryptocurrency world will know it
20:18:53 <UkoeHB> https://github.com/monero-project/research-lab/issues/104 if anyone has any arguments in favor/against, here is a good spot
20:24:43 <jberman[m]> Versus bitcoin reorgs are more destructive in Monero because they can ruin txs which reference reorged away decoys; those txs can’t just be re-added to the new chain like a lot of Bitcoin txs could if there was a deep reorg, they’re invalidated. So it makes sense Monero has more protection from reorgs than bitcoin
20:24:56 <jberman[m]> I agree this particular protection seems like it doesn’t really do much from an economic standpoint tho
20:29:35 <sech1> If coinbase output gets reorged, it disappears as tevador pointed out, so it can't be mined again and all transactions that used it as a decoy get invalid. So it's more damaging.
20:29:55 <sech1> And these days a lot of transactions use coinbase outputs because of p2pool
20:30:25 <moneromooo> Why is it (significantly) *more* damaging ?
20:31:09 <moneromooo> If a non coinbase out gets reorged, users of it as a fake out will be invalidated, een if it gets mined again (except in the fairly unlikely it gets the same index, as I said above).
20:31:59 <moneromooo> (this wuld not be the case if we moved to references to pubkeys instead of index, but we're not)
20:35:38 <sech1> because output indices change?
20:35:40 <sech1> right
20:36:36 <moneromooo> Ooooh, I think I might know. Prior to rct, indices might not have changed as easily, since there were a lot of denomiatins and few txes per block.
21:07:42 <jberman[m]> Couldn’t a malicious miner include arbitrary output denominations in their chain that specifically mess up the indexes for other outputs too?
21:08:27 <merope> Users of invalidated fake outs would cause a chain reaction for any transactions coming later
21:09:21 <merope> And that reaction becomes exponentially worse the deeper you go
21:42:01 <ofrnxmr[m]> From master-beta pre-0.18 (ive yet to update to latest )
21:42:02 <ofrnxmr[m]> selsta:  
21:42:02 <ofrnxmr[m]> 15:38:17.026	[P2P0]	ERROR	bulletproofs	src/ringct/bulletproofs.cc:1073	Verification failure
21:42:02 <ofrnxmr[m]> Log level 1 
21:43:06 <selsta> any issues apart from that message?
21:48:54 <ofrnxmr[m]> No issues 
21:49:47 <selsta> it just means someone sent an invalid transaction from what i know
21:50:04 <selsta> i see that every couple days
21:52:20 <ofrnxmr[m]> Ok 👍 thanks 
21:59:20 <WillMorrison[m]> I’m trying to send myself testnet XMR but nothing is coming through. My daemon is at height 2024778 and the explorer says the transactions are in block 2025895. Am I doing something wrong? Why is my node so far behind without saying anything is wrong?
22:25:15 <selsta> WillMorrison[m]: which version are you using?
22:42:36 <WillMorrison[m]> <selsta> "Will Morrison: which version are..." <- Monero ‘Oxygen Orion’ (v0.17.3.2-unknown)
22:42:57 <selsta> testnet forked already
22:43:27 <selsta> do you know how to compile from source?
22:45:45 <WillMorrison[m]> selsta: I’m on NixOS so packaging is a bit more complicated. I’ll figure it out. Thanks for telling me. 
22:46:03 <selsta> try to use stagenet instead