00:53:43 <UkoeHB> as requested, multisig PR overview for hardfork: https://github.com/monero-project/monero/issues/8237
01:10:56 <selsta> ty!
01:10:58 <selsta> .merges
01:10:58 -xmr-pr- 7936 7937 8053 8166 8177 8179 8180 8195 8196 8197 8205 8207 8211 8212 8213 8215 8222 8223
02:17:52 * spirobel[m] uploaded an image: (23KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/sVoSghzCsdidSlHcsqfUhBwi/image.png >
02:18:18 <spirobel[m]> what is the index in a MoneroOutput? Where can I find out more about it?
02:34:10 <spirobel[m]> nvm. Found something in Zero to Monero. Still dont get the significance 100% though. 
02:36:25 <spirobel[m]> are all of these fields available without the TXKEY? I will research ... 🧐
04:45:15 <jeffro256[m]> spirobel Every output has an index, which is the order the output appears in the blockchain. Referencing output by a small 64-bit integer instead of the 256-bit public key, for example, allows TXs to stay pretty compact
04:46:14 <jeffro256[m]> Future TX versions will possibly index transactions using "bins", which is an even more compact way of describing a certain selection of the existing outputs 
15:52:19 <kayabanerve[m]> <binaryFate> "We could put some communication..." <- Regarding funding, one of the MAGIC Monero Fund's purposes is funding audits. We'd be extremely interested in helping have audits performed, especially for key parts of Monero such as multisig :)
15:52:52 <kayabanerve[m]> (I'm replying on matrix to a message from after the most recent dev meeting, for those on IRC)
15:54:47 <kayabanerve[m]> Also, on a personal level, I'd be interested in reviewing as I can. I think I'm sufficiently skilled at cryptography to comment on the implementation, even if I won't be able to calculate fractional bits of bias and their effects? After Monerotopia I'm already planning to submit a Ristretto PR for Seraphis and have discussed multisig with Ukoe a bit.
17:15:25 <binaryFate> kayabanerve[m] kayabanerve: nice to hear! Any help would be welcome
18:14:39 <gingeropolous> master as of ~32 days ago stability:  uptime 32d 14h 12m 58s , xmrchain node
18:26:10 <chesterfield[m]> Does anyone know if the xmrchain.net api works on stagenet?
18:29:16 <gingeropolous> it probably doesn't. I think this stagenet explorer api works: https://community.rino.io/explorer/stagenet/
18:29:42 <chesterfield[m]> awesome! thank you
18:30:46 <chesterfield[m]> (and yes it works!)
20:11:57 <selsta> luigi1111: can you block https://github.com/CryptoGodfatherVA23 from the monero-project org?
20:12:18 <selsta> seems to be a bot that is approving random PRs
20:13:38 <luigi1111w> onk?
20:13:40 <luigi1111w> link?
20:14:12 <selsta> https://github.com/CryptoGodfatherVA23
20:20:03 <luigi1111w> no to spam
20:26:47 <selsta> for example https://github.com/monero-project/monero/pull/2994#pullrequestreview-930898176
20:28:57 <selsta> you can also give them a warning but their whole github history is approving random patches, it's just noise
20:38:29 <luigi1111w> thanks, done
23:43:56 <spirobel[m]> stupid idea or not? I am building a browser wallet. The browser could close at any time. I want to reduce the amount of times where I need to save the wallet data. Plan : https://moneroecosystem.org/monero-javascript/MoneroWalletListener.html only save the wallet onOutputSpent or onOutputReceived. When OnNewBlock is called just take the new height and save it in indexdb. When the wallet is opened again do setHeight to the saved height.
23:43:56 <spirobel[m]> On top of that there is two slots where the wallet data is saved and a flag if the write was successful. Similar to how microcontrollers do firmware updates. The alternative would be to just periodically save the wallet (like every 30 seconds or so). I am not sure what is easier to implement in the end but it should be as straight forwards as possible. Am I overthinking this? Is there anything that I am missing? or should I just save the
23:43:56 <spirobel[m]> wallet on every new block synced? (OnNewBlock)? maybe I need to debounce, queue or throttle this somehow. 
23:47:25 <spirobel[m]> I want to save the wallet in the browser storage because the default behavior with the filesystem will most likely lead to trouble because the browser could close at anytime and I am not sure about the path and any other program on the computer could access those wallet files.
23:50:01 <kinghat[m]> you mean via the new filesystem storage api?
23:50:14 <kinghat[m]> * the new browser filesystem storage
23:50:29 <kinghat[m]>  * you mean via the new browser file system storage api?
23:53:34 <spirobel[m]> kinghat[m]: The two options are basically the File API where you access the normal file system of the OS. Or the webstorage API. I started out with storage.local and it is already working. But I am rewriting it to use indexdb(different story but related. Want to use this as an opportunity to rethink my approach)
23:54:38 <spirobel[m]> I dont want to use the filesystem. I want to keep it inside the browser, because the logic to write it needs to be somewhat custom anyway, because the browser will close out of the blue. 
23:56:42 <spirobel[m]> I am trying to think through if there is another way to do this. Currently the logic is that at a certain interval (like every 30 seconds) the wallet is saved. But I am thinking it might be more clean to use these Monerowalletlistener events to drive the saving logic.
23:57:23 <spirobel[m]> The question I am trying to answer is if that is a stupid idea or not. 😅🥺🧐😀
23:59:08 <selsta> I think the CLI wallet saves every time you send a transaction and on exit.
23:59:47 <selsta> The GUI has an option for periodic saving in addition to the above, CLI might have that option too not sure.