00:18:16 <m-relay> <j​effro256:monero.social> https://github.com/monero-project/monero/pull/9042/files#r1382297951
00:21:02 <m-relay> <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
00:21:15 <selsta> thank you
00:21:38 <m-relay> <j​effro256:monero.social> Which is why it gets affected by different optimization levels
00:23:12 <m-relay> <j​effro256:monero.social> And doing weird pointer decay stuff seems to make the bug go away
00:26:58 <m-relay> <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 ...
00:39:46 <sech1> If it caught it, it would also trigger when compiled with UB sanitizer, but it doesn't
00:40:17 <sech1> I didn't write that code btw, this was the reference JH code
00:40:47 <m-relay> <j​effro256:monero.social> Oh yeah I wasn't saying you wrote it
00:43:25 <m-relay> <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
00:43:58 <sech1> 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
00:45:58 <sech1> And which is why it never failed in our unit tests
00:51:37 <m-relay> <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
00:52:41 <m-relay> <a​lpharabius:matrix.org> Guys i have a recommendation to make
00:52:51 <m-relay> <a​lpharabius:matrix.org> Make monero proof of stake please
00:56:10 <m-relay> <j​effro256:monero.social> https://www.reddit.com/r/Monero/search?q=proof+of+stake+&restrict_sr=on
01:05:07 <m-relay> <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`
13:37:29 <m-relay> <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?
17:24:17 <m-relay> <j​effro256:monero.social> Yea
17:24:42 <m-relay> <j​effro256:monero.social> You create a “partially signed tx” then pass it around until you reach the threshold of signers
17:26:07 <m-relay> <j​effro256:monero.social> kayabanerve: do you know of any solution which lets people share multisig info easily ?
17:28:05 <m-relay> <j​effro256:monero.social> Or anyone, just asking Luke cause he’s working on multisig applications on serai rn
17:29:52 <m-relay> <j​effro256:monero.social> Thinking of creating a service which lets people asynchronously and trustlessly coordinate multisig ceremonies and transaction signing
17:31:05 <m-relay> <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
17:31:24 <m-relay> <j​effro256:monero.social> Open source of course
17:31:34 <m-relay> <b​oog900:monero.social> I don't know how far along this is but there is this: https://github.com/creating2morrow/neveko
17:31:36 <m-relay> <j​effro256:monero.social> I wanna know if something like that already exists
17:32:42 <m-relay> <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
17:37:23 <m-relay> <b​oog900:monero.social> There is also a bounty to replace the MMS https://bounties.monero.social/posts/83/15-300m-bitmessage-rival-or-re-write
17:55:16 <selsta> vtnerd please also open against release
18:05:27 <m-relay> <v​tnerd:monero.social> Yup, working on that now
18:12:28 <m-relay> <s​needlewoods_xmr:matrix.org> I have built & tested it and it works, thanks vtnerd
20:39:14 <sech1> vtnerd huh, the fix is just in time. I found my node in "Unable to send ZMQ/Pub - ZMQ server destroyed" state today
21:47:28 <m-relay> <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.
21:49:32 <m-relay> <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>
21:49:32 <m-relay> <k​ayabanerve:matrix.org> mpletely incompatible with processes done over weeks/months by humans.
22:30:31 <m-relay> <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)
22:30:37 <m-relay> <h​bs:matrix.org> on stagenet that is
23:18:30 <gingeropolous> yay zmq bug fixed. glory days are upon us
23:44:46 <selsta> hbd: and v0.18.2.2 works?
23:51:32 <nioc> @hbs *  ^^