01:00:14 another idea for janus mitigation: https://github.com/monero-project/research-lab/issues/62#issuecomment-870147617 01:03:53 the next cheapest solution is 16 bytes per output (encoded txout priv key nonce), which is much more trivial to implement and verify 02:33:16 I like this. Addresses are already long enough that most users rarely check each byte. Making it longer would be little cost to most users, but provide this huge benefit for everyone. Great work UkoeHB 02:36:32 Thanks chad[m]. I think the implementation effort and ecosystem burden of something like this could only be justified if done alongside more radical changes to the tx protocol. Changes that would require both new output construction math and new addresses for all users. 02:37:04 Changes like that aren’t inconceivable, but certainly not on any short term horizons. 02:37:18 certainly aren’t on* 02:57:20 There would already be a new output pool for something like Triptych 08:44:26 UkoeHB very interesting use of commitment mask check. I'm wondering though why we need the ancillary private key at all when we already have a per-subaddress private key that can be used to achieve the same thing? Am I missing something? 08:50:20 in the old notation, a subaddress was (C,D) where C == aD == a(B + Hs(a||i)G). The txpubkey in old notation was R==rD==rdG. So the mask check would be checking rG == 1/(b+Hs(a||i)) R 08:52:22 oh wait, i see the problem, the receiver needs their private spend key to do the check 08:53:19 and your ancillary key fixes that problem. Nice :) 09:54:27 yep :) 19:04:07 UkoeHB i vaguely remember that there was space in the bulletproof to store data - so that could be used to store a signature proving the txpubkey was on the correct public key. or was that ruled out as a possibility? 19:28:42 there is only space for one signature but you need a unique txout private key for each output if subaddresses are involved 19:29:02 one sig since bulletproofs are aggregated* 19:47:09 ah ok. i've long been in favor of enforcing 2 outputs for a tx, for the purposes of tx uniformity, but i'm not sure how enthusiastic people might be about that 20:01:55 knaccc: "i've long been in favor of enforcing 2 outputs for a tx" -> this is already consensus 20:02:32 a dummy 0 value output to a random address is added for single output sweeps 20:02:41 It isn't. 20:02:43 tobtoht i don't mean minimum 2, i mean exactly always 2 and no more 20:02:59 oh 20:03:01 my bad 20:40:05 yeah I would guess enthusiasm is lacking for that 20:45:19 High # output transactions have some clear usecases at least 20:45:34 Doesn't make much sense to me to restrict it when there are more important fungibility defects to address 20:45:46 Like fee precision, non-reference decoy selection or tx_extra 20:56:39 oh hadn't seen this was mentioned in relation to janus attack mitigation 20:56:48 I would favor keeping the current 16 output limit, still 20:57:16 I can't imagine exchanges/pools being too happy with having to continously split outputs because they can no longer batch payouts 20:57:59 at least 10 block lock time would have to be solved first 21:12:07 i see the easy "solution" to the lock time would be to simply implement queuing in the wallet, so you can tell it to do a subsequent transaction and then let it do the waiting for you 21:13:39 and the wallet can intelligently split an output up, so that if you ask the wallet to pay out to 16 people, it'd do that by splitting an output into 16 21:15:08 so paying 16 people would require waiting for log_2(16)*10 = 40 blocks, and would require a total of 16-1 = 15 txs 21:16:33 (splitting one output into 2, which are then each split into 4, which are then split into 8...) 21:17:37 you'd need to skew decoy selection to favor 10 block spends or else it's trivial to detect these chains 21:19:07 i think it's a good thing in general to tweak ring size such that it's almost certain that every output created on the blockchain is quickly referenced by a subsequent transaciton. so that there is a "hot zone" that happens early 21:49:10 I added a section 'Reorgs' to https://github.com/monero-project/research-lab/issues/84 showing how tx chaining lets you do away with 10 block lock times. 21:51:30 oh cool, i missed that. will read. 22:51:53 FWIW outputs are cheaper (in space and time) than inputs on the chain 22:52:00 So encouraging more transactions will incur long-term costs