08:10:45 <br-m> <monerobull:matrix.org> whats up with the website
08:14:08 <br-m> <plowsof:matrix.org> which one sir 
08:24:58 <n1oc> [CCS Proposals] plowsoff opened merge request #614: monero garden: replace link https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/614
08:26:14 <plowsof> anhdres is this your new casino site? anhdr.es? :) 
09:43:18 <br-m> <anhdres:matrix.org> plowsof: WTF, that was an old domain I had because it looked cool but dropped some time ago because the Spain TLD were too limited.
09:43:18 <br-m> <anhdres:matrix.org> My website is at anhdres.com and of course the monero garden is monero.garden
09:43:34 <br-m> <anhdres:matrix.org> Thanks to whoever for the catch 
09:44:46 <br-m> <anhdres:matrix.org> Btw, I didn't abandon the garden and I know I'm missing the images, just didn't have the time. I have some already done, will try to finish it soon.
09:49:32 <br-m> <vanima:matrix.org> Feather, transaction caught in roleback, resynced with monerodev nodes, same error:
09:49:32 <br-m> <vanima:matrix.org> Internal error: Known ring does not include the spent output: 139284109
09:49:32 <br-m> <vanima:matrix.org> • You have found a bug. Please contact the developers.
09:49:32 <br-m> <vanima:matrix.org> is the xmr lost? 
09:57:12 <br-m> <spirobel:kernal.eu> @vanima:matrix.org: #feather:monero.social feather help desk 
09:57:39 <br-m> <spirobel:kernal.eu> might be worth it to paste the message there
10:13:47 <br-m> <ofrnxmr:xmr.mx> @vanima:matrix.org: Delete ~/.shared-ring-db folder
11:23:06 <br-m> <vanima:matrix.org> @ofrnxmr:xmr.mx: @vanima:matrix.org: fixed error and enabled transaction, but can't get a confirmation. seems it's an L
11:25:03 <br-m> <vanima:matrix.org> gotta love qubic
14:20:23 <br-m> <pigeons> There will be some short downtime on monero.social matrix server for maintenance shortly
14:36:00 <pigeons> done
15:52:53 <br-m> <rucknium> Looking more at the 18-block re-org: Rings usually need to be reconstructed when one of their members is invalidated because the global output index has changed.
15:53:50 <br-m> <rucknium> I pulled transactions that spent outputs associated with the key images of the invalidated txs.
15:54:36 <br-m> <rucknium> I'll just list the numbers by key images instead of whole transaction since that's easier.
15:55:46 <br-m> <rucknium> So far, 378 of the key images had one ring member in common with the invalidated tx. That means that the one ring member is definitely the real spend. That reduces privacy of the sender.
15:56:51 <br-m> <rucknium> 5 of the key images had _sixteen ring members in common with the invalidated tx. The privacy of these transactions was mostly unaffected (probably about one ring member in each of the rings could be eliminated as the real spend, but the other 15 could be the real spend).
15:58:52 <br-m> <rucknium> The 5 are strange because it was thought that the standard Monero software wouldn't be able to handle this case. The ring member indices stayed the same, but one of the public keys was not correct (misalignment of the global output indices). 
15:58:59 <br-m> <sgp_> What's the normal Monero wallet behavior for this? Is there some cache/logic to attempt to us the same ring members for spends of the same enote?
15:59:08 <br-m> <sgp_> Ah you beat me to it
15:59:31 <br-m> <rucknium> The ring signature was different, of course, because the at least one of the output public keys was different.
16:01:15 <br-m> <rucknium> This occurred in this pair of transactions, which both have the same key image. The first one was invalidated by the re-org. The second was confirmed later. The key image and ring member indices are the same, but the signature is different:
16:01:22 <br-m> <rucknium> Click "Show JSON representation of tx"
16:01:28 <br-m> <rucknium> https://explorer.xmr.mx/tx/cb559fa19ab075e6e9e7e0220289da4fa1f77914e9af661e3369d574c4fff8f9/1
16:01:28 <br-m> <rucknium> https://explorer.xmr.mx/tx/90ddd255f9e745ad19384b46bcaaeaf167f4a6671926e7f253d9744fed17700d/1
16:01:40 <br-m> <rucknium> I wonder if a different wallet implementation did this.
16:02:24 <br-m> <ofrnxmr:xmr.mx> Mymonero?
16:03:20 <br-m> <rucknium> 25 of the key images whose original txs were invalidated by the re-org have zero ring member indices in common between the original invalidated tx and the later confirmed transaction. I assume this means that the real spend was an output confirmed on the blockchain of the orphaned chain.
16:04:05 <br-m> <rucknium> Then the tx that contained the output was later confirmed on the mainchain blockchain.
16:04:13 <br-m> <rucknium> I assume.
16:04:39 <br-m> <ofrnxmr:xmr.mx> @sgp_: The sharedringdb
16:06:20 <br-m> <rucknium> In the 25 key image cases, I think you can figure out which of the ring members in the later valid tx was the real spend by looking at the which output the original ring member indices pointed to in the re-org zone.
16:08:03 <br-m> <rucknium> "in the re-org zone" = "on the orphaned chain"
16:11:44 <br-m> <rucknium> I wonder if the shared ringDB requires that the output public keys be kept the same or just the ring member indices. If it's the latter, then a valid tx can be re-constructed easily by communication with a node, maybe.
16:12:54 <br-m> <rucknium> That is, if the real spend was not on the orphaned chain (the case of the 5, not the 25).
16:14:48 <br-m> <ofrnxmr:xmr.mx> I think we should allow replacing invalid txs (if possible) while the invalid is in the pool, to be able to uae a "replace" tx that uses the same tx details
16:15:32 <br-m> <ofrnxmr:xmr.mx> it would of course leak privacy due to changing rings, but would otherwise act as an rbf for the same amt and destination
16:15:56 <br-m> <ofrnxmr:xmr.mx> In UX, it would look like "tx failed. Resubmit?"
16:33:30 <DataHoarder> explicitly when invalidated ^ not before
16:34:04 <DataHoarder> I suggested as well to require +60 heights past reorg that invalidated these for allowing replacement