k-address pt2

theking01 [2:59 AM]
I think simplewallet supporting multiple addresses would be fine.

jollymort [3:00 AM]
probably enough for the normal user


gingeropolous BOT [3:42 AM]
hrm, this thin blocks version doesn't like to sync

[3:42]
oh its at 100% CPU again

xmr_eric [3:45 AM]
what's the benefit of the thin blocks PR? I assume less to transfer when syncing?


nioc BOT [3:49 AM]
@xmr_eric, https://monero.stackexchange.com/questions/1263/are-there-plans-to-optimize-bandwidth-usage-by-implementing-something-like-xthin/1268#1268

[3:49]
answer by fluffy

xmr_eric [3:50 AM]
Dope


onisan BOT [8:53 AM]
exit

[8:53]
exit


moneromooo BOT [11:20 AM]
kenshi84: https://paste.fedoraproject.org/460479/37999114/


kenshi84 BOT [11:21 AM]
moneromoo: I've already read the log thanks to @jollymort who posted a link on reddit, but thanks!

[11:24]
and my response: https://www.reddit.com/r/Monero/comments/58oizb/idea_onetime_receiving_monero_address/d96ob9y/


moneromooo BOT [11:25 AM]
I'm a bit confused where the payment id fits in there tbh.

[11:26]
AFAICT, it'd just "convenient place to stash some data".


kenshi84 BOT [11:27 AM]
you mean, the payment id is for stashing some data?


moneromooo BOT [11:27 AM]
That's what I think is meant above.


kenshi84 BOT [11:28 AM]
yeah, I also thought so.

[11:28]
I'm now starting to feel that it's a bad idea to mix up payment id and k.

[11:28]
please take a look at my reddit comment above.


moneromooo BOT [11:31 AM]
If needed, it's possible to add a new chunk type to extra anyway.

[11:32]
This should also pass the "can I prove payment" step btw.

jollymort [11:39 AM]
idea behind pID was to make transactions with `k` indistinguishable from others, on the blockchain

[11:40]
but then, re-using it would link any 2 tx with same pID belonging to the same user, reducing privacy overall

[11:41]
then there was the idea to use integrated address, but it can't really work

[11:41]
i just misunderstood integrated addresses at first

jollymort [12:13 PM]
But at the end, to avoid linkability 'k' should be kept small enough to have enough collissions while big enough to accomodate some number of addresses


kenshi84 BOT [12:15 PM]
@jollymort: (1) why should k be small? (2) why and how does k bring linkability?

jollymort [12:40 PM]
Because anyone can see them on the blockchain

[12:40]
And if its big and random

[12:41]
Any two tx with the same k probably were sent to the same user

[12:41]
You cant force the sender not to reuse k's

jollymort [12:47 PM]
But if they're kept limited to, say 2bytes, chances are your k will be same as someone else's, so one couldn't link any 2 tx together with 100% certainty


kenshi84 BOT [12:48 PM]
OK, let's say that all k's are generated incrementally starting from 1, then 2,3,... In this case, colliding k's are the norm and it makes zero sense to link between transactions with the same k.

jollymort [12:48 PM]
But then the one user who gets the  highest k would kind of stick out


kenshi84 BOT [12:49 PM]
I see

jollymort [12:49 PM]
Imo, limit the size, and use random would make the distribution more uniform

[12:50]
You'd expect to find same number of any k's on the chain

[12:50]
1 byte would probably be better

[12:50]
If you run out, make a new wallet and start again


moneromooo BOT [12:50 PM]
It may be naive, but you can encrypt such a k with the recipient's public key, no ?

jollymort [12:51 PM]
Yes, but then you dont signal which k to use and which'c' to use to decrypt

[12:52]
If you use A to encrypt, well that means you gave the sender your main address

[12:52]
Which defeats the purpose of proposed scheme

[12:53]
Because all the recipient is supposed to give to sender would be (C,D,k) while keeping his main address (A,B) secret


kenshi84 BOT [12:53 PM]
@jollymort: I like your idea! But I guess the size of k can be much larger, like 4 bytes or even more. Here, collision of k would be scarce and accidental, but such a collision doesn't necessarily mean a link.


moneromooo BOT [12:53 PM]
So you can't decrypt the "secondary" stuff with the primary keys ?

[12:54]
I think I see what you're saying now.

jollymort [12:54 PM]
Yeah

[12:55]
kenshi84 collision breaks the link and is desired for k's

[12:56]
The more collisions, the better you hide in the crowd of users using the scheme


kenshi84 BOT [12:57 PM]
why do you think a scarce collision means a link? I'd consider it just an accident.

[12:57]
or coincident

jollymort [12:57 PM]
Depend on the allowed size of the k

[12:57]
If its 128 bits, than it's very unlikely to be accidental

[12:58]
Probably the sender reused your kCD

[12:58]
And you have 2 linked payments for everyone to see on the blockchain


kenshi84 BOT [12:59 PM]
Ah, I see your point.

jollymort [12:59 PM]
But really, 256 sub-addresses ought to be more than enough

[12:59]
My mycelium wallet has only 150keys and i have it since 2014

[1:00]
If you use them all up you can make a new wallet and restart

[1:00]
Or reuse some, too


kenshi84 BOT [1:00 PM]
really? What I imagine is to give a new sub-address to Shapeshift every time I buy XMR. Definitely I want to do it more than 256 times.

jollymort [1:02 PM]
Ok, 2bytes - 65536 addies, 179 years for one tx per day

[1:02]
But im more inclined ti 256, to get enough collisions regularly appear

[1:03]
For similar reasons the tx fees are rounded, and we split outputs in denominations

[1:03]
To have many of the "same" appear so nobody can point at something strange

[1:04]
rCT will improve upon this, though


moneromooo BOT [1:04 PM]
You could have each address have an offset based on hashing the private key. With enough users, you'll get a random use of the k-space even without anyone using anything else but 0.

[1:05]
So a given user's "main" address might give offset 743, and the receiver (and miner) would have no idea.

[1:05]
Random offset means miners can't censor anyone using non-default addresses.

jollymort [1:07 PM]
Sry, I kind of lost you here, trying to figure out what you mean


kenshi84 BOT [1:07 PM]
Alternatively, how about completely prohibiting the reuse of the same k (whose size is large enough), just like double-spent is prohibited by checking key images?

[1:08]
(sorry for dropping out random ideas without much thoughts)


moneromooo BOT [1:08 PM]
Well, I'm a bit hazy about the scheme, but my understanding is that the recipient gives the sender an index, which the sender writes into the tx in the clear. Right ?

[1:08]
kenshi84: that would mean if two people send a collision to unrelated third parties, one of htem becomes unusable if the other gets used, I think.

jollymort [1:09 PM]
Kind of, theres a one way function f(a,b,k) -> c,d

[1:09]
Where a,b is your main address private keypair

[1:09]
You give the sender C D and k


moneromooo BOT [1:09 PM]
@jollymort: then what I said is, let that index be not 0-based, but based on a deterministic value from the private key's hash.

jollymort [1:09 PM]
And he sends to C,D while puttingthe k in txextra


moneromooo BOT [1:10 PM]
The sender would receive a random looking index, and would not know whether it's the "first" address, or a subaddress.

[1:10]
Point being, you can't mandate nobody uses subaddresses, in an attempt to blunt privacy.

[1:11]
And it also makes users of the scheme indistinguishable from non users of the scheme (same thing, said differently).

[1:12]
(assuming the k becomes mandatory)

[1:16]
_hopes he didn't misunderstand the scheme :)_

jollymort [1:16 PM]
so you're saying to use something like k=H(a,b,something)

[1:17]
and if k is mandatory, all tx look the same, but then we're bloating the blockchain


moneromooo BOT [1:17 PM]
I guess it's a way to do it, yes. And the something would be the index.

jollymort [1:18 PM]
and if k is forbidden from being re-used, then not only we're bloating the blockchain, but could render someone elses tx fail to send if he generated a colliding k, and our tx got in first


moneromooo BOT [1:19 PM]
Would have to be the hash the view secret key, actually, to preserve view wallet ability to see incoming txes.

jollymort [1:19 PM]
so it looks like, either allow re-use and have them small to have plausible deniability with many collisions

[1:19]
or forbid re-use and have them big to avoid any collisions


moneromooo BOT [1:20 PM]
I don't see much of a point in forbidding reuse, if they're randomly distributed in the first place.


kenshi84 BOT [1:20 PM]
I see. The problem is much more complex than I initially thought :(

jollymort [1:20 PM]
if the sender accidentially sends two times to the same (C,D,k)

[1:20]
you have the 2 txs linked

[1:21]
which may not be a problem, depending on how you feel about it, i suppose


moneromooo BOT [1:21 PM]
C,D is the "standard address equivalent", right ?

jollymort [1:21 PM]
yeah


moneromooo BOT [1:21 PM]
Then an observer can't tell from hte blockchain.

jollymort [1:21 PM]
the only thing different is that you're able to derive it from (a,b,k)


moneromooo BOT [1:22 PM]
(assuming you don't have a huge k-space)

jollymort [1:22 PM]
so your wallet would need to attempt decrypt every output with (A,B) and (C,D) obtained from tx_extra

[1:22]
and if tx_extra contained the right k, the (C,D,k) would resolve to an output belonging to your wallet

[1:23]
kenshi84 it's an interesting problem :slightly_smiling_face:

[1:24]
i don't know if there's some crypto magic, which would let the sender encrypt using `C`, but have the recipient decrypt with `a`


moneromooo BOT [1:24 PM]
@theking01 had something that might allow that.

[1:25]
But since he participated in that discussion, I guess it doesn't apply or he'd have mentioned it...

[1:25]
Worth asking I guess.


awxmr BOT [1:42 PM]
Hi, I have a question that may not be directly in topic... But hypothetically could a technology like monero be used as a fair voting system? would it be provably fair? one vote per person?

jollymort [1:45 PM]
You could make a system one vote per cryptographic key, i suppose. But how do you ensure that each person controls exactly one key?


awxmr BOT [1:46 PM]
Slack_1 guess that's the trick only one address(key) per person.


moneromooo BOT [1:50 PM]
@jollymort: same as currently. The central body for which the election is sends each voter an atomic unit (or that plus enough for a fixed fee).

[1:50]
Shen did some research on that kind of thing.


DaveyJones BOT [1:55 PM]
speaking of ^^ is he on vacation? :D

kenshi84 [3:19 PM]
joined #monero-dev

kenshi84 [3:26 PM]
(Hi, trying slack instead of irc)

kenshi84 [3:39 PM]
Regarding jollymort's mention about sending to the same (C,D,k) more than once, how about using something similar to key image in the form of kC? This scheme forbids specifically reusing the same k & C, but allows colliding k used with different C's. The output key P could be changed to P+kC to prevent the sender from putting arbitrary data to this kC-reuse-checker field.

theking01 [5:43 PM]
@awxmr of course. In fact, you could use https://github.com/monero-project/urs
 GitHub
monero-project/urs
urs - Unique Ring Signatures to sign messages anonymously