[CCS Proposals] spacekitty420 closed merge request #605: closing merge request, waste of time repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/605

bake

Made qubic-snooper.p2pool.observer/tree which is xmrconsensus output and has qubic blocks tagged and cached so it's fast to load on devices

<ofrnxmr:xmr.mx> Its pretty much a design flaw that reorgs permanently invalidate decoys (aiui, due to using output indexing)

<ofrnxmr:xmr.mx> anyway, this is also an issue for fcmo

<ofrnxmr:xmr.mx> Arguably worse for fcmp

<ofrnxmr:xmr.mx> seraphis-migration/monero #81#issuecomment-3197430438

<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.

couldn't a system similar to view tags be used here, or a running checksum for the input txids?

the binary encoding has the output indices, but then at the end just has a sum of all involved txids fetched

(or blocks, or whatever)

<ofrnxmr:xmr.mx> Smh wrong room, sorry

<boog900> You would need to reference outputs by hash which are bigger than idxs

<prisj:matrix.org> I love monero!

not reference

the txid would just have a sum hash for all inputs used

this is available when trying to verify the transaction

it's never sent on the wire, but can be quickly checked before spending time validating the expensive part

and it's already expected public information

which one is the right room @ofrnxmr:xmr.mx :D

<ofrnxmr:xmr.mx> I meant to post in lounge

that sum allows to quickly check "is the input data referred even there or still valid"

I can tackle my above comments as well then once it's reposted there :)

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)

<boog900> How would I find the outputs used in the tx

<boog900> I don't think that would solve the issue? The tx is still invalid

see p2pool.io/explorer/tx/2644325733cf9…dc4b64e0dcfc95d94576c8873083e7a6a/1

this lists ring members (plus index in binary representation)

no, that's not what this solves

it allows quickly checking if tx is valid instead of getting stuck

<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

<ofrnxmr:xmr.mx> Reposted

<boog900> But a change like this is too late when fcmp is so close

<boog900> Also it means you need the outputs used to get the tx hash ...yeah bad idea

yeah, FCMP works differently

FCMP txs (which I'd need to check details) could just bind to a specific block id (say, N heights deep or confirmation depth)

that'd just allow checking if the tx is even on a chain it says it can be validated against or not

however I'll read on FCMP specifically - the output index hashing was about how it currently works with decoys and rings

<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

yeah, but you have to spend time doing so :)

<boog900> I think this is probably more a problem with monerod rather than something inherent to the protocol

yep

I guess it doesn't change the concern which indeed is monerod txs staying in mempool for a week+ even if invalid

<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

<syntheticbird> FINALLY

<syntheticbird> a good news

<xmrscott> status.matrix.org/#

-14