<d​iego:cypherstack.com> Cypher Stack has done some novel work on the ten block unlocking function that is implemented at the protocol level. Particularly looking at the privacy implications of it.

<d​iego:cypherstack.com> github.com/AaronFeickert/pup-monero-lock/releases/tag/final

great addition to Ruckniums list monero-project/research-lab #94

<d​iego:cypherstack.com> Our paper more or less answers that open question, imo.

<r​ucknium:monero.social> Your paper says more research is needed.

<r​ucknium:monero.social> And maybe something else will be developed that allows spending outputs that are even in the txpool

<j​babb:cypherstack.com> Yes but it recommends reducing the lock time to 3 for sends to self and 5 for counterparty txs if further research into chain reorganizations doesn’t contradict that recommendation by showing that reorgs are common and deep enough to cause serious issues with a 3-5 block lock

<j​babb:cypherstack.com> Altho I do seem to remember that the author makes no endorsements :P will have to reread…

<k​ayabanerve:matrix.org> I strongly disagree with that paper. I feel it's missed a major part of the problem.

<k​ayabanerve:matrix.org> You can fingerprint wallets based on their choice of tree. The paper itself does note this in 4.0. It just doesn't appropriately consider how to resolve that IMO.

<k​ayabanerve:matrix.org> The solution for resolving that, IMO, is having everyone choose the n-block old anchor where n is the amount of blocks we use for effective finality in the Monero protocol. The point at which we assume reorgs will not happen to that depth.

<k​ayabanerve:matrix.org> The lack of 3-block reorgs in practice (a number I'd have to confirm) doesn't mean we should use 3-block old trees. Anyone who doesn't want to risk their transaction being reverted should use the confirmation depth tree. Anyone who has an output within those three blocks will have to use the newer tree.

<k​ayabanerve:matrix.org> And if that fingerprint were to be adopted, we'd have anyone using the newer tree effectively subset the privacy to just the last seven blocks of spendable outputs. That's why we can't have a tree fingerprint.

<j​babb:cypherstack.com> Yes but it recommends reducing the lock time to 3 for sends to self and 6 for counterparty txs if further research into chain reorganizations doesn’t contradict that recommendation by showing that reorgs are common and deep enough to cause serious issues with a 3-6 block lock

<k​ayabanerve:matrix.org> Also, the differing recommendations for when to consider outputs confirmed depending on their type may be fingerprintable? I'm trying to think if there's some specific commentary there...

<k​ayabanerve:matrix.org> Hm. Stupid/niche use-case, yet collaborative (not multisig) TXs would have to use a tree at the confirmation depth as they don't decouple proofs and membership proof invalidation is TX invalidation. If wallets preferred shorter trees, those would immediately be identifiable with a presumably very small anonymity set.

<k​ayabanerve:matrix.org> *shorter-depth trees, collaborative TXs would...

<d​iego:cypherstack.com> So your recommendation would be to leave as is?

<k​ayabanerve:matrix.org> Because some wallets will want certainty and some wallets want speed, and because that fingerprint is devastating (potentially revealing wallet software, revealing age of spend, etc), my recommendation is to adopt a universal recommendation of what tree to use regardless of circumstance.

<k​ayabanerve:matrix.org> I disagree that tree should be the n-block old tree due to the lack of n-block reorgs. That has stability issues which may be unacceptable in certain environments. It should be, IMO, the n-block old tree due to the infeasibility of n-block reorgs.

<k​ayabanerve:matrix.org> That latter `n` has been considered 10 for years. It's probably worth redoing the math given the current pool status? But that's a separate discussion.

<s​pirobel:kernal.eu> would an account based model make the situation better or worse?

<k​ayabanerve:matrix.org> We can't do full-set receiver privacy and the account model so horrifically worse.

<s​pirobel:kernal.eu> how come is there literature on this?

<k​ayabanerve:matrix.org> Because you'd have to do an O(n) write to every account on the blockchain?

<k​ayabanerve:matrix.org> You can't update the DB entry for an account, without revealing which account you wrote to, due to the DB access pattern. You'd need to update every entry for every account in an a uniform manner.

<s​pirobel:kernal.eu> proof could be different dont think its that obvious

<k​ayabanerve:matrix.org> It's not about the proof. It's legitimately about the notion of an account w.r.t. the database.

<k​ayabanerve:matrix.org> The closest research on this topic would be PIR, which is O(log n) and doesn't reveal the entry accessed. That's *reading* entries however. Not *writing* them.

<s​pirobel:kernal.eu> here is one paper for example eprint.iacr.org/2023/710 any others you recommend?

<k​ayabanerve:matrix.org> 1) FHE

<k​ayabanerve:matrix.org> 2) That's O(n)

<k​ayabanerve:matrix.org> I said it wasn't possible because it's O(n), as in, it can be done, it just is horrifically slow and doesn't scale.

<k​ayabanerve:matrix.org> The contribution of that paper is the transfers aren't O(n) size. They're still O(n) to apply.

<k​ayabanerve:matrix.org> Also, you can't make transactions in parallel. Every transaction is premised off some set of balances *and dirties every balance due to full-set sender privacy*. Any other transfer must now use the new set of balances, else you'd be able to double spend.

<k​ayabanerve:matrix.org> Hm. Those transfers may still be O(n) size... It says it forms a vector of key encryptions and I'm unclear the length of that vector. It may be one per account.

<k​ayabanerve:matrix.org> Oh, cool, they did solve parallelization using a key-image esque construction. Now its you can only spend from an account once per epoch (however long that is), not that you can't do any TXs in parallel.

<k​ayabanerve:matrix.org> And the size of their transfers are independent to amount of users.

<s​pirobel:kernal.eu> might be ms on a modern system like solana

<s​pirobel:kernal.eu> maybe not a fundamental limitation

<j​babb:cypherstack.com> I’m not sure how Solana’s Proof of History changes the situation. Or are you referring to some newer Solana tech?

<k​ayabanerve:matrix.org> At the end of the epoch, any non-included TXs would get dropped. It'd need to be at least several minutes due to the computational burden in signing/accumulating here.

<k​ayabanerve:matrix.org> Solana parallelizes its compute. That isn't some magic bullet to everything here.

<j​babb:cypherstack.com> Then you need to remake tx?

<k​ayabanerve:matrix.org> If you do push performance, sure, it may be 5-10m epochs. I won't comment how feasible it'd be to run a node (as the hardware available would need to grow with the amount of ever-registered users as it's O(n) per TX), but I won't say it's impossible to get such a tight epoch time.

<s​gp_:monero.social> I read the paper and have been talking to kayaba a lot directly. I think it makes sense to pick one value so we don't have different values that stick out based on wallet implementation. There's a reason Monero forces a min lock of 10 today; wallets picked different values when they could

<s​gp_:monero.social> I definitely don't want people to think a lock time of 3 is realistic or even recommended in the initial analysis here. For counterparty receives, it recommends 6 as a starting point, but that's assuming a valid analysis would confirm that reorgs past that were very uncommon, and even beyond than that, it's assuming that reorgs are the correct measurement for finality as kayaba has commented

<s​gp_:monero.social> Really, the paper is saying 6 should be the bare minimum if we need to pick one number, and that's only after a separate analysis confirms that 6 is safe (which this paper does not)

<r​ucknium:monero.social> I was surprised that the paper gave a quantitative suggestion without a quantitative analysis.

<s​gp_:monero.social> Was there anything supporting the number 6? Maybe I missed it?

<k​ayabanerve:monero.social> I wouldn't say it's assuming lack of reorgs are the correct measurement for soft finality. I'd say it's defining the metric as lack of reorgs, not as soft finality.

<k​ayabanerve:monero.social> I think in practice some TXs will prefer one for its speed and one for its stability (which may be a hard requirement). Accordingly, we're likely to see a fingerprintable split.

<k​ayabanerve:monero.social> The solution, IMO, is to create one universal option. We can make the stable option the fastest option by banning faster options. It sucks but it ensures uniformity.

<k​ayabanerve:monero.social> But I'd love to have that value reevaluated and hear we shouldn't be using 10-conf yet 6-conf, or not 10-conf but 20-conf (not because I'd be happy about that, but because we should be informed rather than ignorant).

<k​ayabanerve:monero.social> So no matter what, the next steps forward being a quantitative analysis of the likelihood of a n-block reorg by adversaries with various degrees of hash powers (up to 51%, our fundamental trust assumption), the historical rate of natural reorgs, and the the odds of few-block reorgs by low-hash rate DoSers would be great.

<r​ucknium:monero.social> I wonder if it is a good time to re-evaluate before the FCMP++ hard fork and possibly implement a change at that hard fork. Or wait until we get new data with FCMP++ activated. Slower tx verification may change the re-org probability.

<r​ucknium:monero.social> And there is monero-project/monero #9334 that would change tx propagation, too.

<s​yntheticbird:monero.social> As an end user I would love a lock time reduction after FCMP++ update (assuming we decrease it)

<s​yntheticbird:monero.social> that would be perfect timing