03:33:00 <UkoeHB> https://github.com/monero-project/research-lab/issues/95 an idea I had today
05:02:54 <jetsteel[m]> UkoeHB: If the goal is to allow immediate spends without the possibilty ofna reorg affecting it, could there be a protocol whereby a transaction uses inputs that are currently in the tx pool?
05:07:59 <jetsteel[m]> UkoeHB: then a block producer could choose to include all relevant blocks in the order required, or not include the transaction at all.
05:08:52 <jetsteel[m]> UkoeHB: if it gets included, then reorged it doesnt matter because all the txs that it referred to also got reorged?
13:57:01 <UkoeHB> jetsteel[m]: yes you could do that, but I think it would have limited utility since it requires extra coordination between sender and receiver.
14:01:21 <sech1> zero-decoy spends feel wrong to me
14:01:41 <sech1> you can at least use decoys from mempool and 1-2 last blocks
14:03:14 <UkoeHB> sech1: then you get back into the reorg problem
14:04:22 <sech1> real reorgs rarely touch more than 2 last blocks
14:04:25 <UkoeHB> I think ‘bump tx’ that add fees to txs in the mempool could reduce the impact of the grace-period-expiry problem (which is a DDOS vector).
14:08:58 <sech1> also, double spends usually don't even enter mempool under normal conditions, even with reorgs
14:10:43 <UkoeHB> Those statements are only true in a non-adversarial environment. What if there is a selfish miner, or the double spender is injecting double spends at different places in the network simultaneously?
14:14:58 <sech1> then there will be double spends in different mempools, but only one will be mined
14:15:23 <sech1> if you don't take decoy from mempool, only actual reorg attacks can cause problems
14:27:37 <UkoeHB> A natural reorg occurs when two different miners publish competing blocks. Those miners have different mempools, which can be in conflict.
14:30:17 <UkoeHB> Also, taking decoys from recent blocks/mempool is not compatible with deterministic binning (large ring sizes). The goal of my proposal was to minimize the damage fast-spends can do to fully anonymized spends (full ring signatures). If some outputs are spent in small rings, this weakens other ring signatures that reference those outputs.
14:31:22 <UkoeHB> Hence, the proposal completely removes provably spent outputs from decoy-eligibility as soon as possible.
14:33:50 <merope> But now you are creating separate anonymity pools
14:35:32 <merope> And since there is (presumably) no restriction on how many zero-decoy transactions there can be in a block, there is now a significant incentive (for the people who have no idea what they're doing) to use zero-decoy txes as much as possible, because ain't nobody got time to wait 10 blocks
14:36:36 <merope> You would be effectively reverting the previous decision to enforce a mininum ring size, and reintroducing the option of no privacy in exchange for expedience
14:38:00 <merope> Besides - the only people who would be able to do this whole "identify the real spend" dance would be those actively monitoring the chain for reorgs and collecting all the data they can. Anyone else catching up after the fact would have no idea that it ever happened
14:41:57 <merope> Imo, the potential damage that zero-decoy transactions could bring far outweighs the partial privacy degradation for a few transactions in the event of a reorg
14:42:38 <UkoeHB> The minimum ring size would still be enforced, this just expands the conditions when tx can be constructed.
14:43:05 <UkoeHB> Reorgs don’t cause privacy degradation... what are you referring to?
14:44:35 <Lyza> probably this: "However, if that output is used as a decoy in other users' txs, then since observers know it has been spent, they will know it is a decoy in those other users' txs. This weakens those users' ring signatures. To prevent that weakening, the 10-block-lock time is enforced. This way all decoys in a tx input are plausibly the real spend."
14:44:46 <UkoeHB> Also, ‘as much as possible’ is misleading. It would be used whenever convenient (expedient as you say).
14:45:49 <Lyza> I don't understand from reading this how ring size is still enforced --- it seems to state pretty plainly that zero decoy TXs are used. maybe I need to read it again after my 2nd cup
14:46:12 <UkoeHB> It’s enforced for all inputs that reference old outputs.
14:46:42 <UkoeHB> Implicitly* since a zero-decoy cannot be older than 30 blocks.
14:47:47 <jetsteel[m]> Is the problem of a reorg after a quick spend driven solely by the fact that xmr references ring members by index, and that index would change on a reorg? Or is there more to it?
14:48:09 <UkoeHB> No, the problem is a reorg can remove a decoy from the chain entirely
14:50:14 <jetsteel[m]> Removing the decoy would invalidate the signature as there would be no record of what the tx pub key for that decoy was on chain, so you couldnt verify the sig, yeah?
14:50:43 <UkoeHB> Lyza: reorgs make it risky to use recent outputs as decoys; if all your decoys are always old (> 10 blocks) but the real spend is recent (< 10 blocks), then observers will know it is a real spend. That’s what I was saying there.
14:51:29 <UkoeHB> jetsteel[m]: right, which means a tx you submitted would become invalid due to the actions of completely unrelated third parties (violating censorship resistance)
14:52:45 <Lyza> I think the privacy risk is in rebroadcasting an invalidated TX because you will reveal the real spend
14:53:13 <Lyza> since the 10 decoys will be diff but the real spend is the same
14:53:25 <jetsteel[m]> So, what if we allowed references to young outputs by tx pub key rather than index? The worst case is you lose one decoy if it gets reorged away. Sig can still be verified
14:54:08 <UkoeHB> jetsteel[m] it is illegal to reference an output that isn’t in the blockchain (this would let you mint coins)
14:56:09 <UkoeHB> Lyza: yes that’s a risk, but the necessity for 10-block-lock lies in txs getting invalidated in the first place
14:57:28 <Lyza> so I guess this proposals seems to mostly limit the privacy harming effects of 0-decoy TXs to the person making the transaction, but I guess my concern would be that it lowers the available pool of decoys from what it would be with the lock time enforced
14:57:36 <Lyza> don't get me wrong I'd love to get rid of the lock time
14:58:53 <jetsteel[m]> UkoeHB: of course. 🤡
14:59:04 <Lyza> tevador's idea about using the change output as a decoy seems itneresting
15:01:59 <UkoeHB> It would prevent you from removing provable spends from the decoy pool. An output spent in a 2-member ring isn’t a lot better than one provably spent.
15:06:29 <jetsteel[m]> <merope> "And since there is (presumably..." <- What if you mandate a convenience fee? Nobody is going to needlessly make quick respends if it costs significantly more than waiying 10 blocks....unless they really need to.
15:06:40 <Lyza> I guess you could still remove those from the decoy pool but then I guess you're removing even more than in the 0-decoy scenario
15:07:08 <Lyza> mmm convenience fee, I kinda like it
15:09:59 <carrington[m]> Meeting over in -community in just over an hour to discuss CCS/workgroup updates and any other relevant topics
15:09:59 <carrington[m]> https://github.com/monero-project/meta/issues/644
15:10:08 <carrington[m]> Just under an hour*
17:37:52 <n1k0laz> hi there