another idea for janus mitigation: monero-project/research-lab #62#issuecomment-870147617

the next cheapest solution is 16 bytes per output (encoded txout priv key nonce), which is much more trivial to implement and verify

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

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.

Changes like that aren’t inconceivable, but certainly not on any short term horizons.

certainly aren’t on*

There would already be a new output pool for something like Triptych

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?

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

oh wait, i see the problem, the receiver needs their private spend key to do the check

and your ancillary key fixes that problem. Nice :)

yep :)

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?

there is only space for one signature but you need a unique txout private key for each output if subaddresses are involved

one sig since bulletproofs are aggregated*

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

knaccc: "i've long been in favor of enforcing 2 outputs for a tx" -> this is already consensus

a dummy 0 value output to a random address is added for single output sweeps

It isn't.

tobtoht i don't mean minimum 2, i mean exactly always 2 and no more

oh

my bad

yeah I would guess enthusiasm is lacking for that

High # output transactions have some clear usecases at least

Doesn't make much sense to me to restrict it when there are more important fungibility defects to address

Like fee precision, non-reference decoy selection or tx_extra

oh hadn't seen this was mentioned in relation to janus attack mitigation

I would favor keeping the current 16 output limit, still

I can't imagine exchanges/pools being too happy with having to continously split outputs because they can no longer batch payouts

at least 10 block lock time would have to be solved first

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

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

so paying 16 people would require waiting for log_2(16)*10 = 40 blocks, and would require a total of 16-1 = 15 txs

(splitting one output into 2, which are then each split into 4, which are then split into 8...)

you'd need to skew decoy selection to favor 10 block spends or else it's trivial to detect these chains

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

I added a section 'Reorgs' to monero-project/research-lab #84 showing how tx chaining lets you do away with 10 block lock times.

oh cool, i missed that. will read.

FWIW outputs are cheaper (in space and time) than inputs on the chain

So encouraging more transactions will incur long-term costs