matching hashes here

can someone who did v0.18 build upload binaries somewhere?

I can when I get home

In 10-15 minutes

ty

selsta p2pool.io/v15

don't look :D

monero-mac-armv8-v0.18.0.0.tar.bz2

does it make sense to name it like this?

Downloads on getmonero.org don't use the original names anyway

yes i rename them usually

Download URLs

and thens end them to bF

send*

monero-architecture-OS-version.tar.gz

current naming is pretty straight-forward

that's how we rename them currently before uploading them to getmonero.org

also good

it's more important to keep it consistent

my worry was what happens when apple uses armv9 but it should be backward compatible

I suppose we could have used arm64 instead

arm64 would be better but it would be inconsistent with our existing armv8 used by other OS

ukoehb: I will do 8426 as well. Im probably one of the few people that knows the server code well enough

my preference was something piecemeal, which is why I was refusing to review it, but it seems like I am in the minority

Its merged already though

7999 please

ugh gross

I know I haven't been reliable as of late, so I guess I cant complain

Ill probably look at post merge changes on that one, I recall there being unnecessary code in spots unless jberman removed it

oh lord 7999, no way

I have an alternative that Im working on rebasing

Yeah, would be nice to have a once over on jbermans changes, as he did try to address some of your comments

there's almost no one that could maintain that other than me

I tried to re-write it in a sane way using stuff from monero-lws

Jberman has said he would do 7999

let me point him to the alternative then

jberman[m]

selsta asked for a rebase which will get done today somehow as well

jberman should be familiar with both styles, and at least one other commenter preferred the method I went with instead

its a more natural c++ style than that beast - reviewing for correctness was/is way more complicated than my patch imo

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.

so we decided to merge it

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

I specifically asked perfect-daemon about this boolean logic, here's what they said:

> 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 libera.ems.host/_matrix/media/r0/do…ffb8bf986213ac20373f35131291ec8ec2d)

I felt that was strong enough justification to leave it as is

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

<vtnerd__> "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

Do they both fix the same issues?

ofrnxmr: I assume that’s why it’s in the convo/proposed as an alternative. I want to review both

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?

5000 lines vs 2500, I assume there are at least some differences, just wondering, low level, what they are, if any :)

Ah, ya I’m curious too :)

" I have no preference aside from whichever is functionally better" At least for me complexity also plays a big role

And with this I don't only mean pure number of lines

But "complexity" in a more, well, complex sense :)

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

contain the coinbase enotes from the block 60 blocks ago). Does this seem viable, or is there a better solution?

Personally sometimes I choose a solution that it a little inferior in some interesting dimension if it's significantly less complex

You could make the rule "any output with a fake blinding factor (I) is locked for 60".

No need to store any extra data.

I'm not even sure why oinbase outs are locked for longer.

locked outputs can't be onchain due to deterministic ring member references

or at least * there can't be a non-uniform lock policy onchain

THis seems inconsistent with locking coinbase for 60, unless every other output is also locked for 60.

(and that's gonna cause some whining :D)

what's inconsistent?

I suppose it could be a 50-block cache lock, then the default 10 block onchain lock

"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".

Anyway, given I'm not following much anymore, I should really not waste your time and will shut up.

well it's a good point about the 10 block onchain lock, thanks

I guess it's more of an indexing lock, since the block that creates coinbase enotes will make them 'onchain'.

Why do coinbase outputs need to be locked 6x longer than normal ones?

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?

because a reorged coinbase output disappears forever, while a normal output goes back to the mempool and can be mined again

Ahhh ok got it, thank you.

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) ?

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)

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.

So while true, it doens't seem to be a good enough reason.

Ya, I think it’s a questionable decision

Unless there is more to it

Does Bitcoin do a similar thing ?

Oh they don't lock in the first place I think, nvm.

might be worthwhile to investigate removing that rule completely

surely if it has some value, someone somewhere in the big cryptocurrency world will know it

monero-project/research-lab #104 if anyone has any arguments in favor/against, here is a good spot

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

I agree this particular protection seems like it doesn’t really do much from an economic standpoint tho

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.

And these days a lot of transactions use coinbase outputs because of p2pool

Why is it (significantly) *more* damaging ?

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).

(this wuld not be the case if we moved to references to pubkeys instead of index, but we're not)

because output indices change?

right

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.

Couldn’t a malicious miner include arbitrary output denominations in their chain that specifically mess up the indexes for other outputs too?

Users of invalidated fake outs would cause a chain reaction for any transactions coming later

And that reaction becomes exponentially worse the deeper you go

From master-beta pre-0.18 (ive yet to update to latest )

selsta:

15:38:17.026 [P2P0] ERROR bulletproofs src/ringct/bulletproofs.cc:1073 Verification failure

Log level 1

any issues apart from that message?

No issues

it just means someone sent an invalid transaction from what i know

i see that every couple days

Ok 👍 thanks

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?

WillMorrison[m]: which version are you using?

<selsta> "Will Morrison: which version are..." <- Monero ‘Oxygen Orion’ (v0.17.3.2-unknown)

testnet forked already

do you know how to compile from source?

selsta: I’m on NixOS so packaging is a bit more complicated. I’ll figure it out. Thanks for telling me.

try to use stagenet instead