01:10:21 <n1oc> [CCS Proposals] spacekitty420 closed merge request #605: closing merge request, waste of time https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/605
06:49:02 <owenota> bake
15:17:20 <DataHoarder> Made https://qubic-snooper.p2pool.observer/tree/ which is xmrconsensus output and has qubic blocks tagged and cached so it's fast to load on devices
16:28:20 <br-m> <ofrnxmr:xmr.mx> Its pretty much a design flaw that reorgs permanently invalidate decoys (aiui, due to using output indexing)
16:28:20 <br-m> <ofrnxmr:xmr.mx> anyway, this is also an issue for fcmo
16:28:32 <br-m> <ofrnxmr:xmr.mx> Arguably worse for fcmp
16:29:26 <br-m> <ofrnxmr:xmr.mx> https://github.com/seraphis-migration/monero/pull/81#issuecomment-3197430438
16:30:48 <br-m> <ofrnxmr:xmr.mx> > if a pool tx's FCMP++ reference height is >= 10 current chain tip [...] the daemon could end up needlessly trying to re-validate a tx that would never re-validate correctly.
16:32:30 <DataHoarder> couldn't a system similar to view tags be used here, or a running checksum for the input txids?
16:32:57 <DataHoarder> the binary encoding has the output indices, but then at the end just has a sum of all involved txids fetched
16:33:10 <DataHoarder> (or blocks, or whatever)
16:33:19 <br-m> <ofrnxmr:xmr.mx> Smh wrong room, sorry
16:34:02 <br-m> <boog900> You would need to reference outputs by hash which are bigger than idxs 
16:34:11 <br-m> <prisj:matrix.org> I love monero!
16:34:45 <DataHoarder> not reference
16:35:02 <DataHoarder> the txid would just have a sum hash for all inputs used
16:35:16 <DataHoarder> this is available when trying to verify the transaction
16:35:51 <DataHoarder> it's never sent on the wire, but can be quickly checked before spending time validating the expensive part
16:36:01 <DataHoarder> and it's already expected public information
16:36:26 <DataHoarder> which one is the right room @ofrnxmr:xmr.mx :D
16:37:24 <br-m> <ofrnxmr:xmr.mx> I meant to post in lounge 
16:37:27 <DataHoarder> that sum allows to quickly check "is the input data referred even there or still valid"
16:38:05 <DataHoarder> I can tackle my above comments as well then once it's reposted there :)
16:38:54 <DataHoarder> but yeah, point is to not change how txs refer to decoys/outputs to spend, but just have a single checksum of these included in the transaction for all (which would add however many bytes needed)
16:39:09 <br-m> <boog900>  How would I find the outputs used in the tx 
16:39:35 <br-m> <boog900> I don't think that would solve the issue? The tx is still invalid 
16:39:35 <DataHoarder> see https://p2pool.io/explorer/tx/2644325733cf973da90a14c7d33c763dc4b64e0dcfc95d94576c8873083e7a6a/1
16:40:00 <DataHoarder> this lists ring members (plus index in binary representation)
16:40:05 <DataHoarder> no, that's not what this solves
16:40:15 <DataHoarder> it allows quickly checking if tx is valid instead of getting stuck
16:40:24 <br-m> <boog900> You could, instead of idxs hash the outputs used directly into the tx, then send the outputs identifier used with the tx as ephemeral data that gets changed to idxs after it is mined
16:40:27 <br-m> <ofrnxmr:xmr.mx> Reposted
16:40:41 <br-m> <boog900> But a change like this is too late when fcmp is so close 
16:41:02 <br-m> <boog900> Also it means you need the outputs used to get the tx hash ...yeah bad idea
16:41:27 <DataHoarder> yeah, FCMP works differently
16:43:50 <DataHoarder> FCMP txs (which I'd need to check details) could just bind to a specific block id (say, N heights deep or confirmation depth)
16:44:47 <DataHoarder> that'd just allow checking if the tx is even on a chain it says it can be validated against or not
16:45:21 <DataHoarder> however I'll read on FCMP specifically - the output index hashing was about how it currently works with decoys and rings
16:47:58 <br-m> <boog900> Tbf if a tx has a ring signature that is invalid it will always be invalid unless the chain reorgs and the outputs change > <DataHoarder> it allows quickly checking if tx is valid instead of getting stuck
16:48:36 <DataHoarder> yeah, but you have to spend time doing so :)
16:48:43 <br-m> <boog900> I think this is probably more a problem with monerod rather than something inherent to the protocol
16:48:49 <DataHoarder> yep
16:49:04 <DataHoarder> I guess it doesn't change the concern which indeed is monerod txs staying in mempool for a week+ even if invalid
19:44:01 <br-m> <xmrscott> matrix.org is down with no estimated time to recover... should anyone here have critical comms with someone on a matrix.org based account
19:45:47 <br-m> <syntheticbird> FINALLY
19:45:52 <br-m> <syntheticbird> a good news
19:47:21 <br-m> <xmrscott> https://status.matrix.org/#
20:03:05 <dukenukem> -14