Blackwolfsa You do have basepoint multiplication for a variety of curves in your first method for the purpose of verifying it's the cross-curve point from the specified scalar. It's a script shim to solve a lack of a DLEq proof, one uneeded and unflexible.

I understand it isn't actually a DLEq proof yet it's on chain code replacing one, hence why nI called it that.

Blackwolfsa: I did see the linked StackOevrflow for the DLEq proof. AFAICT this is completely invalid

*StackOverflow, sorry.

For a given X1, X2, t, s, v, "The verifier computes u and verifies v⋅G=t+u⋅X1 and v⋅H=s+u⋅X2.". Set v to 0 and have t/s be any values which cause X1/X2 to add to the identity point.

Like this is based on the idea you can't subtract points. You can. It's trivial.

Wait. No. I'm an idiot. t/s is committed to as part of u.

... this still shouldn't be this simple AFAIK, but I'd have to double check with someone else.

Yeah that proof is simple, but I cant see why it should not work. Perhaps I am missing something?

Blackwolfsa So I found the history of it

It's Chaum Pedersen's signature algorithm from 1993

The whole point (pun intended) of the discrete log equality idea is that it works across arbitrary groups, and therefore arbitrary curves, without an algebraically meaningful map between them. It opens up possibilities of atomic swaps with non-ed25519 constructions. The notation in the Cloudflare article is informal and seems (at first glance) to imply a single group structure; please correct me if this is wrong.

This was sarang's comment on it when he was presented with it after announcing the work on his proof in the first place, which was actually posited by Poelstra

I legitimately wouldn't trust this as it's saying Poelstra didn't know of this, despite it going around a fare bit, and sarang improperly dismissed it, without one of them confirming it's valid (though I also don't suggest bothering them, making this a questionable comment)

Unless the comment is that it's for some exotic set of curves? I have no idea what those exotic qualities would be yet that theoretically means it's fine for secp/Ed25519?

TL;DR Don't know. Only one person suggested this be used across entire groups and it's a SO post with no research backing that it holds for different groups. I don't know why it wouldn't. sarang seemingly dismissed it (though they may have dismissed it based on its intent, instead of its merits), and Poelstra... no idea. I wish I could find his original positing of this proof as it may open this up but I have no idea where it'd be

and Google has nothing.

I am going to try and look at the uncompressed edwards points for the Ristretto points and Ed25519 points as used by Monero again, because if we don't need a DLEQ proof then at least for Monero swaps this whole thing is moot.

But it would still be interesting to find out if this proof is valid and if its not why not?

You don't need a DLEq proof if you have on chain verification the scalar in question maps to the expected public key. That's not a flexible system and forces you to include more and more curves in your node software. You're still welcome to do it. I just don't recommend it.

As for the DLEq proof you use, I'm definitely stumped and can't comment further. I recommend MRL-0010 until you find out Poelstra's/sarang's commentary against (or for) CP93 across groups. It sounds like sarang does know an edge case and I honestly couldn't comment what it is.

For reference, you're currently looking at requiring 5 different curves if you want to support the XMR-BTC swap protocol across all curves which benefit from its inclusion. secp256k1, Ed25519, Ristretto, Jubjub, and whichever of Pallas/Vesta is actually used for the SpendAuthSig in ZEC

OR you have an offchain library handle curve management and leave your node software untouched, also shifting computations to the swap participants and away from the network.

But your decision to make ;) I just wanted to offer my advice.

And if you do learn anything about CP93's cross group potential, please let me know. I'd love to learn of it

Oh

Blackwolfsa: Doesn't this break whenever v is naturally greater than a scalar modulus?

One system will reduce it when the other won't causing v != v and the proof to fail accordingly, even if r, x, and u are < each modulus

x * u should cause several reductions on its own creating a series of disparaties.

Is v not just a simple scalar?

But if the scalar size differs between curves, like 256 bit and 128 bit?

kayabaNerve: i don't think i ever posted my proof publicly because i didn't realyl flesh it out. maybe i posted a pastebin here or something

i definitely passed it around privately to people who i thought would fill it out and publish it

anyway the argument is pretty forward ... "discrete log equality" is meaningless between groups of different order, as you have noticed

but what you can do is break the DL into its binary decomposition

and simultaneously reconstruct the result in both groups (you will get different overflow behavior but this is fine for many usecases ... e.g. for adaptor-signature applications you can just start with a 128-bit secret and then if you reconstruct that in two different groups of order 2^255ish there's no problem)

and so you get a proof of "equivalent" discrete log, where the "equivalence" is that the two discrete logs have the same bits when you write them as numbers

and which isn't defined on the entirety of the larger group

(btw i am Poelstra, i realize you only highlighted me by that name, not andytoshi)

Meeting 2 hrs: monero-project/meta #637

put me on for next week i cant make it today

maxwellsdemon: No problem. Take care

meeting time: monero-project/meta #637

1. greetings

hello

Meeting time! 🤩

Hi there

Hello

Howdy

2. updates, what has everyone been up to the past week?

Hi

Hi

Hi

btw andytoshi isn't DLP security half the number of bits? If you know the DL of your secret key is between [G, 2^128 G], won't your security only be 64 bits?

Ha, this time I have sometimes. I ran some tests with the latest multisig PR code, as written in the issue. All successful, zero problems.

*something

cool thanks rbrunner; this week I reviewed a multisig patch from wfaressuissia and got to learn all about the wonderful `export_multisig()` and `import_multisig()` functions. I feel your pain...

Been more rigorously re-testing "batched" wallet scanning based on UkoeHB's feedback on view tag PR (1 more small commit incoming soon, no significant changes), started reviewing multisig PR (grateful vtnerd is reviewing this, it's fairly challenging for me but I'm getting the gist of the code), started reviewing Rucknium's preliminary OSPEAD work (not much to report on that yet on my end, but looking solid)

Doing some work on mining revenue, sort of in preparation for tail emission issues. Getting feedback from jberman on my "dry run" of OSPEAD. Have decided for now to use the Akaike Information Criterion (AIC) to compare distribution families when using Maximum Likelihood Estimation (MLE). MLE visualization and results table should be posted in github.com/Rucknium/OSPEAD soon.

However, my Monero work is slowing since I need to pivot back to BCH work. BCH people are asking "What has BCH CashFusion Red Team been up to lately?" The answer is red-teaming Monero ;)

UkoeHB: great question. i *think* the answer is no

i think in a 256 bit group, the security is always the minimum of 128 and the entropy of your secret

but i guess, there is almost certainly some way that you could choose a secret with 128 bits that'd give a boost to pollard-rho..

i just don't think that "choose from [0, 2^128]" is such a way

anyway i am not confident. you should not take my word on this :)

maybe, to be sure, users should just always use 224-bit secrets, which should be fine even if they lose half their bit-security

I think baby step giant step would do it if you just generate the keys [0, 2^64] ( en.wikipedia.org/wiki/Baby-step_giant-step ).

> users should just always use 224-bit secrets

yeah I was thinking this as well

yeah you might be right about baby-step-giant-step. i'll try to work it out

254-bits*

UkoeHB: hows the seraphis POC work going? i dont see any updates in the ccs

thanks for the updates guys

2. discussion, any topics to discuss today? I don't think there are _new_ agenda items. Maybe we can highlight tevador's seraphis address scheme idea ( monero-project/research-lab #92#issuecomment-985018982 ).

bbqcore[m]: a couple weeks ago I released performance results monero-project/research-lab #91

Right now I am in the 'taking a break' part of the ccs, where design decisions need to be made and I need to finish the paper.

The only new item was from maxwellsdemon , and they cannot make it to the meeting today.

ah

wow almost a month since perf results...

UkoeHB: yeah i remember seeing this now. whats next?

I want to reiterate now that if anyone want to see the OSPEAD technical specification, i.e. "Document A", let me know and I can send it to you. I haven't posted it publicly since i want to make a somewhat laypeople-friendly version soon and I don't want two versions floating around out there in public.

It's important for interpreting github.com/Rucknium/OSPEAD (and even now I am working with jberman on improving the interpretability of the dry run results there)

"I reviewed a multisig patch from wfaressuissia" Is this public, or still hidden / connected with Hacker One?

Ok yeah since that report I mostly took a vacation, worked on reviewing multisig security issues, and added an efficiency section to the paper (with various other updates). Next steps, I need to finish the paper (coinstudent2048[ continues to work on/improve the security model, which is non-trivial), and I am hoping we can hone in on an address scheme and decide which seraphis variant to use. After that, I will fork my

perf branch to clean up the code so I can hand it off to other developers for a potential future hard fork.

rbrunner: not public yet... hopefully later this week if wfaressuissia gets back to me

Holding my breath :)

There was talk of submitting something to some conference. Did that happen?

I think the flood analysis, right?

UkoeHB: i only ask because the ccs proposal said 6 weeks. not rushing you, just curious as to the status and what the next steps are possibly getting seraphis into monero codebase

yeah, for design decisions I really need the input of other people at this point... especially people who have read and understood the paper

Think we should do a meeting dedicated to some design choices for Seraphis that have to be made

Seraphis-Squashed seems promising, but relies on unusual security assumptions.

rbrunner: Yes, isthmus submitted the "Fingerprinting a Flood" paper to the Science of Blockchain conference.

Nice!

dEBRUYNE: sounds good to me

I expect that we should hear a reply on acceptance within the next two weeks maybe since the conference happens late January.

What would an audit process on Seraphis look like? Who might do it and how long do these things typically take?

Idk the process, but it would be a very big audit since there are two new proof structures and an entire tx protocol.

With a whole new address scheme.

Are there any plans to run Seraphis as a testnet first?

Maybe a look back to the Bulletproof audits will shed some light on this, e.g. blog.quarkslab.com/security-audit-of-monero-bulletproofs.html

one-horse-wagon[: I would be amazed if it doesn't run on testnet for over a month before use.

At least 2 different companies reviewed the code, as far as I remember

With CCS to finance

Yeah, running on testnet first is a must

<UkoeHB> "yeah, for design decisions I..." <- What can people like me who don't really understand cryptography do to help with feedback? "Nothing" is a valid answer :)

you can look at monero-project/research-lab #92

Well, some design decisions have UI/UX consequences, and those should be accessible to us non-cryptographers ...

Yes, other than address schemes the other UI/UX decision that comes to mind is whether to support collaborative funding or not.

And what to do about timelocks...

Nuke them from orbit, of course

And, the best way to implement ring-member-references for large rings (e.g. monero-project/research-lab #84 monero-project/research-lab #88 ).

This will probably keep us busy the whole 2022

rbrunner: I'm wondering if there is an alternative timelock scheme that could be simple but useful. It would be really helpful if the advanced users like atomic swap experts could cleanly describe what would/wouldn't be useful from timelocks.

Would be interesting to hear, yes

Timelocks were talked about a little before. Few people use them. I believe the number was about 200.

If you just removed the timelocks, the coins would still be there. I wouldn't let the issue interfere with the movement toward the adoption of Seraphis.

Timelocks are also a possible vector of attack as they stick out on the block chain.

I think timelocks that are encrypted avoid many of these problems, but are quite costly, if I got that correctly.

seraphis is a tx protocol, so it would be nice to have all the tx protocol questions worked out before finalizing the design

And it looks like atomic swaps really could take off, so users of timelocks could, in theory, be finally there

but, it isn't necessary; just bringing up the topic so we can make progress

<UkoeHB> "rbrunner: I'm wondering if there..." <- I've gotten some more feedback on that. Thomas from COMIT answered a bunch of q's I had. First off, again, current timelocks are not and wouldn't be useful for atomic swaps. Second, a timelock that prevents an output from being spendable in the chain until height N would be useful and I have to go back through the conversation to get full details on exactly how

> a timelock that prevents an output from being spendable in the chain until height N

This is literally the timelocks we have right now.

Well, now it's all outputs of a tx, maybe that's the difference?

Maybe it is "tx cannot be mined until block N" That's bitcoin-style time locks, right?

yeah, with btc for example you can *sign* a transaction that can't be mined until N, so the monero lock time on outputs is different

I miswrote, that^ is what I meant

like the tombstone concept you've mentioned in the past

Can you get that effect right now by spending an output that is timelocked?

No because it still allows the ability to spend the output with a separate tx

you mean the timelocked output?

so there s a race condition

You could collaboratively sign a tx with another party that can't be included in the chain until time N but spends output X, but before time N are still able to spend output X

Can't you do that with bitcoin timelocks as well? I am confused

This is Bitcoin's equivalent: en.bitcoin.it/wiki/NLockTime

You can't do this with Monero's timelocks today because if output X is in the chain and timelocked until time N, no one is able to spend it until time N

No, the idea is you make a timelocked dummy output, then spend it in your tx you want locked.

UkoeHB: yeah, i'm pretty sure baby-step-giant-step will work just fine breaking a DL in a known range (with runtime sqrt(that range)

thanks!! i will stop casually suggesting that 128 bit secrets are ok

sure :)

ok we are at the end of the hour, so I will call the meeting here; thanks for attending everyone

UkoeHB: I think part of the benefit of BTC-style time locks is that one party gives the signed but currently unmineable tx to another party. Then if something goes wrong, Bob can broadcast that timelocked tx to recover funds or something.

which would only work if the tx includes sufficient txn fees

"The reason nLocktime is useful is because we can agree on a joint-output and pre-sign a TX that refunds the money after time T. Once I have this TX in my pocket, ready to use, I am happy to commit funds to a joint-output. Without this "backup" TX, I can be held hostage once I moved money into the joint-output."

So it seems you have to be able to move the funds into the joint-output where it is spendable with this "backup" nLocktime'd tx, or with another tx that can be created separately before the nLocktime

hyc: Yes, which is why the Lightning Network will fail. But I digress...

I'm pretty sure you can do that with current monero timelocks, so long as there is tx chaining available.

? current monero timelocks, the txn is mined immediately, but outputs are unusable till timer expires.

Using the dummy timelocked output idea. However, it would be better to switch from current timelocks to a 'spendable range' timelock: tx can be added to a block in range `[start, end]`, given the current system's flaws re: deterministic rings.

you can't use that for a refund mechanism, because that would require being able to spend the same outputs twice - once in real txn and once in timelocked

hyc: yes, you make a timelocked tx that creates a dummy output (0 amount), then you 'spend' that dummy output in another tx, effectively locking that tx until the dummy is spendable.

the 2nd txn can't be mined until the lock expires ... ?

right

got it

I'm getting it too, ya I think this achieves the same effect

so..... to make sure the txn will be usable when it unlocks, you might consider using higher-than-default fee. but then the txn would be fingerprintable

So the other non-dummy output is spendable at any time by creating a separate tx, which is similar to what bitcoin-style time locks do, I think.

I think hidden txlockranges can be done far more cheaply than hiding current timelocks. You just need 2 range proofs.

maybe ~5-15% increased verification cost, <100 bytes

It seems a little clunky in that there would be 1 extra input/ring sig in the chained tx that spends the dummy output (+ the dummy output itself), which could be avoided with an nLockTime equivalent

yes, I am just trying to understand why people think the current timelocks don't work

I think you're right in that they would work to enable the effect of nLockTime

the dummy output concept, like moo's subscription idea

andytoshi: Yeah, I know who you are ;) I didn't want to bother you though. I'm definitely not the best cryptographer but am happy I managed to realize why this didn't work with enough time. Thanks for chiming in yourself :)

kayabaNerve: no prob :) thanks for not pinging me. though FYI i also highlight on "poelstra" :)

Ha. Definitely not my intent. Time for Poelstr_a then

lolol, don't worry about it. i can interpret poelstra as an unintential ping and ignore it

Blackwolfsa: Bit length shouldn't matter, just modulus value from my understanding. If one has a modulus of 5 and one has a modulus of 6, `v = r + u * x` = 20 will cause v to equal 0 and 2 at the same time.

Hence why this shouldn't work if you even just try and get a PoC of it up.

<hyc> "so..... to make sure the txn..." <- To get around the increasing fee issue, bitcoin supports this thing called "child-pays-for-parent" where the recipient of the unconfirmed UTXO spends that UTXO in a new tx including a higher fee, so miners will be incentivized to mine both the parent and child tx at the same time

Seems possible to do but trickier. I can't see how to do this in a way that isn't finger-printable

Surely the ten block lock forbids this?

carrington: That's what I was thinking, too.

You could prevent the parent output from being used in other rings, should a child tx that spends the parent output be included in the same block (and so allow these child tx's). But this parent-child tx is finger-printable, and probably other issues with this I'm not seeing

I mean you can't do this today, would require a protocol change

Are you saying that child-pays-for-parent would have to be a consensus-level exception to the ten block lock?

Yea

Right

I'm not sure higher than normal fee would be needed anyway. It's not clear to me whether XMR will develop any kind of meaningful fee market because of the dynamic block size

Suggestions have been made to make fees less fingerprintable lowering the significant digits

carrington[m]: more than a suggestion, it will be wallet policy if this PR is merged: /

Not consensus though right?

no

has there been talk of reducing fees relative to ring size/tx size increases?

no

Why would fees be lower for larger transactions?

Not sure I understand the suggestion bbqcore

carrington[m]: lowering the fee rate to account for increase in tx size

bbqcore: We had an apparent spam incident earlier this year. Slightly higher fees could help reduce the spam risk. I don't think there is much appetite for lowering fees at this time.

not lowering fees

but making larger txs cost the same as current ones

From what I remember, the plan is to make fees higher in the next upgrade (ringsize 16) to reduce spam risk. I think seraphis will not substantially change the fees from that level under current estimates. Maybe that's wrong though.

The fee changes for the next hard fork are supposed to raise fees, I think:

The best current estimate for the cost of the spam incident is only 5 XMR:

bbqcore[m]: The fee rate is based on a 'reference' tx size of 3kB. Since seraphis won't cause standard tx to exceed 3kB, it's not necessary to change the fee calculation. ArticMine[m] can tell you more