-
sarang
Hello all
-
maybefbi
sarang: hi. is Pedro Moreno-Sanchez in this chat room?
-
sarang
Not that I know of
-
maybefbi
eprint.iacr.org/2019/595.pdf Figure 3, says the keygen process should generate a random bitstring m. but when someone opens a payment channel, who generates m and how would they share it with each other? im thinking of putting it in the signature.
-
maybefbi
along with all the other ms from other signatures of course
-
sarang
They're defined using hashes of public transaction data when generated
-
maybefbi
hmm interesting
-
sarang
This isn't made explicit in that figure, but is discussed at several other points in the paper
-
sarang
Keep in mind, of course, that the DLSAG construction suffers from a tracing issue due to its linking tag construction
-
maybefbi
oh i didnt know
-
sarang
Yeah, I wanted that to be made much more upfront in the paper (it is mentioned, FWIW)
-
sarang
This issue can be solved with a self-spend on receipt of funds, but this operation can't be protocol-enforced
-
sarang
meaning it relies on user action for safety
-
sarang
We've tried to replicate the functionality of DLSAG without linear linking tags, but have not found a solution yet
-
sarang
(the linearity of the tags is what ruins things)
-
maybefbi
ouch
-
maybefbi
i already implemented a version
-
maybefbi
should have read the entire paper first lol
-
maybefbi
section 3.1 speaks of this tracing issue
-
maybefbi
im assuming these self spends should be done using other signature schemes like CLSAG
-
sarang
The issue is mentioned on page 6 and again on pages 23-24
-
sarang
I really wanted it to be mentioned immediately
-
sarang
:(
-
maybefbi
its ok
-
maybefbi
it is a fun exercise for me anyways
-
sarang
No, the self-spends can use DLSAG
-
maybefbi
oh ok
-
sarang
Because then the sender and receiver of the self-spend operation are the same entity
-
sarang
Of course, the timing of self-spends could lend itself to additional adversarial heuristics
-
sarang
but that was not examined in the scope of the paper
-
maybefbi
:(
-
sarang
Although hidden timelocks do mitigate this somewhat :)
-
maybefbi
i havent got to those in the paper. i assume it is like amount hiding but for block heights
-
sarang
Yep, the timelock is hidden using a Pedersen commitment
-
maybefbi
nice
-
sarang
and the signature construction is further modified to account for this
-
sarang
The hidden timelock construction could be used outside of DLSAG too
-
sarang
It's been examined by a few researchers in the context of the current Monero protocol
-
sarang
It would introduce a nontrivial addition to verification time, but is quite reasonable in terms of size
-
sarang
but is a very clever approach
-
maybefbi
im frankly amazed after reading Z2M2 by UkoeHB_ . all of it is very clever. mere mortals like me can only appreciate the music but never create it
-
UkoeHB_
maybefbi: keep in mind Monero has been, and continues to be, developed in a very incremental fashion. Most complex human constructions materialize that way.
-
sarang
We all stand on the shoulders of giants, as they say
-
moneromooo
Better than on their feet.
-
hyc
If I have not seen as far as others, it is because they were standing on my shoulders
-
hyc
and blocking my view
-
sarang
The lesson is to avoid wearing tall hats in theatres
-
sarang
Omniring received a small but important update:
eprint.iacr.org/2019/580
-
sarang
Another researcher and I independently pointed out a problem with a particular inversion step that didn't work in the original paper
-
sarang
They posted the update publicly last month after fixing this
-
sarang
Always a bit of a feather-in-your-cap to be listed in the acknowledgements of a paper :D
-
hyc
nice
-
Inge-
cool
-
Inge-
I guess this might be fairly tangential, but it would be quite cool if it was possible to have a Monero stablecoin. Unfortunately I can't think of a way to make it work
-
hyc
what makes any stablecoin work?
-
Inge-
the ability to sell it for the peg :P
-
UkoeHB_
speaking of incremental improvements, it seems we can reduce the 48-byte Janus Schnorr proof to 32 bytes (or even 16 bytes); however... it is a bit messy since we still need 48-byte proofs for 2-out tx
-
UkoeHB_
updated
monero-project/monero #6456, important part is Proposal Part 2 (new) method 3: 32-byte consolidated Schnorr proof. sarang would you mind taking a look? It's a new/unusual kind of proof dynamic
-
UkoeHB_
Im wondering if we could reduce the 32-byte proof to 16 bytes (e.g. only use a 16-byte response, and 16-byte challenge) by constraining the tx private key to 16 bytes. Doing so would also reduce the 48-byte proof to 32 bytes.
-
UkoeHB_
Yeah nvm, rather than unique it's just a convoluted way of encoding the tx private key. Now that I think about it, we might be able to do away with Janus proofs altogether and just use encoded tx private keys. What were the objections to encoding the tx private key in the past? knaccc
-
niocbrrrrrr
the ignorant one is posting a link, hopefully it is meaningful
-
niocbrrrrrr
-
monerobux
[ Ruben Somsen ⚡️🇳🅾️2️⃣❎ on Twitter: "SAS: Succinct Atomic Swaps The #Bitcoin block subsidy is not the only thing that's halving today! A regular atomic swap takes 4 transactions. What if I told you w ] - twitter.com
-
knaccc
UkoeHB_ i'm trying to remember, i guess you're saying you'd need to encode a tx private key per non-change output, right?
-
UkoeHB_
Right, only costs 32 bytes at most instead of 48 bytes. Then for change outs modify how derivation_to_scalar is computed (e.g. prefix with the private view key) to make the non-change out's knowledge of the tx private key irrelevant.
-
UkoeHB_
By doing that we wouldn't need an separate change tag to encode the amount, since the entire change output would be encoded with a change tag essentially
-
UkoeHB_
It's kind of annoying, but the other option is 48-byte schnorr which is 16 bytes more expensive
-
knaccc
i'm trying to think about implications for tx proofs when the tx private key is no longer only known to the sender
-
knaccc
since there is the "here is another ring signature for the same key images being spent" tx proof, i guess maybe it's not a loss
-
UkoeHB_
Yes OutProofs no longer prove you created an output, so you'd also need a SpendProof. However, solo OutProofs are still sufficient to prove about a recipient
-
UkoeHB_
Unfortunately OutProofs would need a special construction for change outs, which is really annoying too
-
knaccc
and one could argue that having many differnet types of tx proof was confusing anyway, so why not just have one type that is always used, regardless of whether you remembered the tx priv key or not
-
knaccc
i'm trying to remember, currently, is there a different txprivkey per output?
-
UkoeHB_
Only sometimes
-
knaccc
>=3 outputs is where you have multiple txprivkeys right?
-
UkoeHB_
In the new construction it would be that way yes, and in the current construction it's more situational
-
knaccc
how is it done currently
-
knaccc
what are the situations
-
UkoeHB_
There are multiple tx private keys when there are at least 2 non-change outputs and at least one of them is a subaddress
-
knaccc
it basically mirrors situations where there is more than one tx pubkey specified, right?
-
UkoeHB_
Yes tx pub keys always have their own tx private key
-
UkoeHB_
The tradeoff here is ~16 bytes per transaction vs a lot of development hassle
-
knaccc
you're saying that encrypting and sending the txprivkey is more dev hassle than adding the janus schnorr proof?
-
UkoeHB_
Yeah, due to 2-out tx where there is only 1 tx pub key
-
knaccc
so what are you proposing in that scenario
-
UkoeHB_
So change outs need a special construction that has broad repercussions
-
knaccc
it does sound a little messy
-
UkoeHB_
The basic problem is if I know the tx private key for someone else's output, then I could figure out who they are by testing known addresses.
-
knaccc
so change output is Hs( Hs(a||r)A )G+B instead of Hs(rA)G+B?
-
UkoeHB_
Yeah that's the gist of it
-
knaccc
that doesn't sound like that much of a hassle
-
knaccc
oh wait
-
UkoeHB_
More like H(a, rA)G + B
-
knaccc
ok i see
-
knaccc
is there a scanning time implication therE?
-
UkoeHB_
Well you have to keep track of change outs.. and then always apply the change out computation
-
UkoeHB_
No, since we can use view tags
-
knaccc
ah ok yes i see
-
UkoeHB_
Also OutProofs need some massaging to get them to work
-
UkoeHB_
Without revealing the view key
-
knaccc
yeah it feels a bit messy, but it does the job
-
knaccc
i'll see if i can think of any other implications of divulging the txprivkey
-
UkoeHB_
I also wonder if we can use a smaller tx private key, maybe 16 bytes. At that point Janus mitigation would be very cheap
-
knaccc
that sounds like playing with fire
-
UkoeHB_
Hmm there may be a way around the change out nonsense by exploiting view tags
-
knaccc
on what basis are you saying that a DH exchange would not need a full 32-byte scalar?
-
UkoeHB_
Well I imagine 31 byte tx private keys would be ok, so is there a limit how small they can go? I wonder what sarang thinks
-
UkoeHB_
More of a wondering and less of a real basis :p
-
knaccc
i mean it does make intuitive sense to me that txprivkey=Hs(16 byte random scalar) should deliver a 128-bit security level actually
-
UkoeHB_
And it only matters since it would reduce on-chain storage for the solution we are discussing
-
knaccc
i think you are onto something
-
knaccc
i guess it's a question of defense-in-depth and quantum resistance
-
UkoeHB_
For the change output, instead of altering derivation-to-scalar which is a core part of the tx protocol, make a 'hidden tx pub key' deterministically from the encoded non-change tx private key + the tx author's view key. This is cheap because of view tags. There are 2 tags: non-change tag and change tag. First compute the sender-receiver shared secret like normal with k_v*R, then the two view tags H("view",
-
UkoeHB_
k_v*R), H("view", k_v*R, k_v). If the former matches e.g. the first view tag in a tx, then set output index = 0 and check if the output is owned like normal. If it is owned then decode the tx private key and use it to check the tx pub key is legitimate. If the former matches e.g. the second view tag in a tx then set output index = 1 and compute the hidden tx private key r_hidden = H(r_encoded, k_v), and
-
UkoeHB_
hidden tx pub key R_h = r_hidden*G, then compute the shared secret k_v*R_hidden and use that to see if the output is owned. If it's owned, the Janus test automatically passes.
-
UkoeHB_
Anyway I'll update the proposal so it's more clear
-
sarang
Reducing the complexity of private keys sounds unwise
-
UkoeHB_
Regarding OutProofs.. I don't believe they work for all change outputs currently. Not that I can see a point to proving you sent yourself something
-
UkoeHB_
The workaround is an InProof + SpendProof
-
UkoeHB_
sarang idk how I feel about you crushing my hopes and dreams 😢
-
sarang
Replace all signatures with a written promise that you didn't cheat :D
-
sarang
knaccc: suppose you used `H(1 bit scalar)` as an extreme example...
-
moneromooo
It seems hard to get an attack that's better than brute force.
-
sarang
But if you're restricting your search space, brute force itself becomes easier