<j​effro256:monero.social> monero-project/monero #9042/files#r1382297951

<j​effro256:monero.social> The "compiler bug" sech mentions in the issue post is likely due to not following the strict aliasing rule, then modifying `state->x` by the `E8` function between dereferences

thank you

<j​effro256:monero.social> Which is why it gets affected by different optimization levels

<j​effro256:monero.social> And doing weird pointer decay stuff seems to make the bug go away

<j​effro256:monero.social> I guessing that the compiler then automatically catches that we're breaking the rule and makes adjustments accordingly so that we get our intended behavior some of the time ...

If it caught it, it would also trigger when compiled with UB sanitizer, but it doesn't

I didn't write that code btw, this was the reference JH code

<j​effro256:monero.social> Oh yeah I wasn't saying you wrote it

<j​effro256:monero.social> Also idk if UB sanitizer would catch it. I've heard that its iffy at catching strict alaising but I could def be wrong. I'm gonna try to reproduce the bug with gcc 11.4

The only cases when UB breaks logic at different optimization levels, is integer wraparound and casting between integers and floats, also unaligned accesses. That kind of code there is too common to be "optimized" by compilers like that. Which is why gcc fixed it in later versions

And which is why it never failed in our unit tests

<j​effro256:monero.social> Yeah I agree that accessing byte buffers thru int pointers is fairly common, and compilers should be aware of that fact for practicality reasons, but doing so is still undefined behavior. Any anyways, IIUC, this portion of the code doesn't need optimization

<a​lpharabius:matrix.org> Guys i have a recommendation to make

<a​lpharabius:matrix.org> Make monero proof of stake please

<j​effro256:monero.social> reddit.com/r/Monero/search?q=proof+of+stake+&restrict_sr=on

<j​effro256:monero.social> sech1: Just installed gcc 11.4 and ran the provided main.c from the issue. Using old jh.c, got different hashes for `-O2` and `-O3`. *With* the `memcpy` changes, however, I got the right answer for both `-O2` and `-O3`

<h​bs:matrix.org> Regarding multisig, I don't really understand what is meant by "Transactions are still signed with a single spend key. The spend key is a sum of all N private keys.", is the signing process itself actually incremental?

<j​effro256:monero.social> Yea

<j​effro256:monero.social> You create a “partially signed tx” then pass it around until you reach the threshold of signers

<j​effro256:monero.social> kayabanerve: do you know of any solution which lets people share multisig info easily ?

<j​effro256:monero.social> Or anyone, just asking Luke cause he’s working on multisig applications on serai rn

<j​effro256:monero.social> Thinking of creating a service which lets people asynchronously and trustlessly coordinate multisig ceremonies and transaction signing

<j​effro256:monero.social> So that users only have to setup up a “room” with selected peers then hit one button to generate a multi dig wallet and/or sync partial key images and other multisig info

<j​effro256:monero.social> Open source of course

<b​oog900:monero.social> I don't know how far along this is but there is this: github.com/creating2morrow/neveko

<j​effro256:monero.social> I wanna know if something like that already exists

<j​effro256:monero.social> Thanks for the link! Never heard of this project … I’ll contact the author to see if the multisig part meets my requirements

<b​oog900:monero.social> There is also a bounty to replace the MMS bounties.monero.social/posts/83/15-300m-bitmessage-rival-or-re-write

vtnerd please also open against release

<v​tnerd:monero.social> Yup, working on that now

<s​needlewoods_xmr:matrix.org> I have built & tested it and it works, thanks vtnerd

vtnerd huh, the fix is just in time. I found my node in "Unable to send ZMQ/Pub - ZMQ server destroyed" state today

<k​ayabanerve:matrix.org> jeffro256: The best bet would likely be LibP2P without a formal guarantee of verifiability, which likely can be argued secure with an off-network verification process.

<k​ayabanerve:matrix.org> Serai itself uses a verifiable broadcast layer which has a synchronous BFT consensus. The generated key is decided by n-of-n agreement posted onto another sync BFT blockchain. There is an open issue to make the first one asynchronous BFT, yet even that may not be enough for Monero multisig. It'd still require a supermajority be online for the delivery of *all messages*. It'd be co<clipped message>

<k​ayabanerve:matrix.org> mpletely incompatible with processes done over weeks/months by humans.

<h​bs:matrix.org> Has anyone managed to generate multisig wallets using 0.18.3.1? I keep getting an error on the second exchange_multisig_keys call (Failed to derive public key)

<h​bs:matrix.org> on stagenet that is

yay zmq bug fixed. glory days are upon us

hbd: and v0.18.2.2 works?

@hbs * ^^