SHARE
TWEET

k-address pt2

a guest Oct 25th, 2016 32 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1.  
  2. theking01 [2:59 AM]  
  3. I think simplewallet supporting multiple addresses would be fine.
  4.  
  5. jollymort [3:00 AM]  
  6. probably enough for the normal user
  7.  
  8.  
  9. gingeropolous BOT [3:42 AM]  
  10. hrm, this thin blocks version doesn't like to sync
  11.  
  12. [3:42]  
  13. oh its at 100% CPU again
  14.  
  15. xmr_eric [3:45 AM]  
  16. what's the benefit of the thin blocks PR? I assume less to transfer when syncing?
  17.  
  18.  
  19. nioc BOT [3:49 AM]  
  20. @xmr_eric, https://monero.stackexchange.com/questions/1263/are-there-plans-to-optimize-bandwidth-usage-by-implementing-something-like-xthin/1268#1268
  21.  
  22. [3:49]  
  23. answer by fluffy
  24.  
  25. xmr_eric [3:50 AM]  
  26. Dope
  27.  
  28.  
  29. onisan BOT [8:53 AM]  
  30. exit
  31.  
  32. [8:53]  
  33. exit
  34.  
  35.  
  36. moneromooo BOT [11:20 AM]  
  37. kenshi84: https://paste.fedoraproject.org/460479/37999114/
  38.  
  39.  
  40. kenshi84 BOT [11:21 AM]  
  41. moneromoo: I've already read the log thanks to @jollymort who posted a link on reddit, but thanks!
  42.  
  43. [11:24]  
  44. and my response: https://www.reddit.com/r/Monero/comments/58oizb/idea_onetime_receiving_monero_address/d96ob9y/
  45.  
  46.  
  47. moneromooo BOT [11:25 AM]  
  48. I'm a bit confused where the payment id fits in there tbh.
  49.  
  50. [11:26]  
  51. AFAICT, it'd just "convenient place to stash some data".
  52.  
  53.  
  54. kenshi84 BOT [11:27 AM]  
  55. you mean, the payment id is for stashing some data?
  56.  
  57.  
  58. moneromooo BOT [11:27 AM]  
  59. That's what I think is meant above.
  60.  
  61.  
  62. kenshi84 BOT [11:28 AM]  
  63. yeah, I also thought so.
  64.  
  65. [11:28]  
  66. I'm now starting to feel that it's a bad idea to mix up payment id and k.
  67.  
  68. [11:28]  
  69. please take a look at my reddit comment above.
  70.  
  71.  
  72. moneromooo BOT [11:31 AM]  
  73. If needed, it's possible to add a new chunk type to extra anyway.
  74.  
  75. [11:32]  
  76. This should also pass the "can I prove payment" step btw.
  77.  
  78. jollymort [11:39 AM]  
  79. idea behind pID was to make transactions with `k` indistinguishable from others, on the blockchain
  80.  
  81. [11:40]  
  82. but then, re-using it would link any 2 tx with same pID belonging to the same user, reducing privacy overall
  83.  
  84. [11:41]  
  85. then there was the idea to use integrated address, but it can't really work
  86.  
  87. [11:41]  
  88. i just misunderstood integrated addresses at first
  89.  
  90. jollymort [12:13 PM]  
  91. 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
  92.  
  93.  
  94. kenshi84 BOT [12:15 PM]  
  95. @jollymort: (1) why should k be small? (2) why and how does k bring linkability?
  96.  
  97. jollymort [12:40 PM]  
  98. Because anyone can see them on the blockchain
  99.  
  100. [12:40]  
  101. And if its big and random
  102.  
  103. [12:41]  
  104. Any two tx with the same k probably were sent to the same user
  105.  
  106. [12:41]  
  107. You cant force the sender not to reuse k's
  108.  
  109. jollymort [12:47 PM]  
  110. 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
  111.  
  112.  
  113. kenshi84 BOT [12:48 PM]  
  114. 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.
  115.  
  116. jollymort [12:48 PM]  
  117. But then the one user who gets the  highest k would kind of stick out
  118.  
  119.  
  120. kenshi84 BOT [12:49 PM]  
  121. I see
  122.  
  123. jollymort [12:49 PM]  
  124. Imo, limit the size, and use random would make the distribution more uniform
  125.  
  126. [12:50]  
  127. You'd expect to find same number of any k's on the chain
  128.  
  129. [12:50]  
  130. 1 byte would probably be better
  131.  
  132. [12:50]  
  133. If you run out, make a new wallet and start again
  134.  
  135.  
  136. moneromooo BOT [12:50 PM]  
  137. It may be naive, but you can encrypt such a k with the recipient's public key, no ?
  138.  
  139. jollymort [12:51 PM]  
  140. Yes, but then you dont signal which k to use and which'c' to use to decrypt
  141.  
  142. [12:52]  
  143. If you use A to encrypt, well that means you gave the sender your main address
  144.  
  145. [12:52]  
  146. Which defeats the purpose of proposed scheme
  147.  
  148. [12:53]  
  149. Because all the recipient is supposed to give to sender would be (C,D,k) while keeping his main address (A,B) secret
  150.  
  151.  
  152. kenshi84 BOT [12:53 PM]  
  153. @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.
  154.  
  155.  
  156. moneromooo BOT [12:53 PM]  
  157. So you can't decrypt the "secondary" stuff with the primary keys ?
  158.  
  159. [12:54]  
  160. I think I see what you're saying now.
  161.  
  162. jollymort [12:54 PM]  
  163. Yeah
  164.  
  165. [12:55]  
  166. kenshi84 collision breaks the link and is desired for k's
  167.  
  168. [12:56]  
  169. The more collisions, the better you hide in the crowd of users using the scheme
  170.  
  171.  
  172. kenshi84 BOT [12:57 PM]  
  173. why do you think a scarce collision means a link? I'd consider it just an accident.
  174.  
  175. [12:57]  
  176. or coincident
  177.  
  178. jollymort [12:57 PM]  
  179. Depend on the allowed size of the k
  180.  
  181. [12:57]  
  182. If its 128 bits, than it's very unlikely to be accidental
  183.  
  184. [12:58]  
  185. Probably the sender reused your kCD
  186.  
  187. [12:58]  
  188. And you have 2 linked payments for everyone to see on the blockchain
  189.  
  190.  
  191. kenshi84 BOT [12:59 PM]  
  192. Ah, I see your point.
  193.  
  194. jollymort [12:59 PM]  
  195. But really, 256 sub-addresses ought to be more than enough
  196.  
  197. [12:59]  
  198. My mycelium wallet has only 150keys and i have it since 2014
  199.  
  200. [1:00]  
  201. If you use them all up you can make a new wallet and restart
  202.  
  203. [1:00]  
  204. Or reuse some, too
  205.  
  206.  
  207. kenshi84 BOT [1:00 PM]  
  208. 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.
  209.  
  210. jollymort [1:02 PM]  
  211. Ok, 2bytes - 65536 addies, 179 years for one tx per day
  212.  
  213. [1:02]  
  214. But im more inclined ti 256, to get enough collisions regularly appear
  215.  
  216. [1:03]  
  217. For similar reasons the tx fees are rounded, and we split outputs in denominations
  218.  
  219. [1:03]  
  220. To have many of the "same" appear so nobody can point at something strange
  221.  
  222. [1:04]  
  223. rCT will improve upon this, though
  224.  
  225.  
  226. moneromooo BOT [1:04 PM]  
  227. 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.
  228.  
  229. [1:05]  
  230. So a given user's "main" address might give offset 743, and the receiver (and miner) would have no idea.
  231.  
  232. [1:05]  
  233. Random offset means miners can't censor anyone using non-default addresses.
  234.  
  235. jollymort [1:07 PM]  
  236. Sry, I kind of lost you here, trying to figure out what you mean
  237.  
  238.  
  239. kenshi84 BOT [1:07 PM]  
  240. 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?
  241.  
  242. [1:08]  
  243. (sorry for dropping out random ideas without much thoughts)
  244.  
  245.  
  246. moneromooo BOT [1:08 PM]  
  247. 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 ?
  248.  
  249. [1:08]  
  250. 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.
  251.  
  252. jollymort [1:09 PM]  
  253. Kind of, theres a one way function f(a,b,k) -> c,d
  254.  
  255. [1:09]  
  256. Where a,b is your main address private keypair
  257.  
  258. [1:09]  
  259. You give the sender C D and k
  260.  
  261.  
  262. moneromooo BOT [1:09 PM]  
  263. @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.
  264.  
  265. jollymort [1:09 PM]  
  266. And he sends to C,D while puttingthe k in txextra
  267.  
  268.  
  269. moneromooo BOT [1:10 PM]  
  270. The sender would receive a random looking index, and would not know whether it's the "first" address, or a subaddress.
  271.  
  272. [1:10]  
  273. Point being, you can't mandate nobody uses subaddresses, in an attempt to blunt privacy.
  274.  
  275. [1:11]  
  276. And it also makes users of the scheme indistinguishable from non users of the scheme (same thing, said differently).
  277.  
  278. [1:12]  
  279. (assuming the k becomes mandatory)
  280.  
  281. [1:16]  
  282. _hopes he didn't misunderstand the scheme :)_
  283.  
  284. jollymort [1:16 PM]  
  285. so you're saying to use something like k=H(a,b,something)
  286.  
  287. [1:17]  
  288. and if k is mandatory, all tx look the same, but then we're bloating the blockchain
  289.  
  290.  
  291. moneromooo BOT [1:17 PM]  
  292. I guess it's a way to do it, yes. And the something would be the index.
  293.  
  294. jollymort [1:18 PM]  
  295. 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
  296.  
  297.  
  298. moneromooo BOT [1:19 PM]  
  299. Would have to be the hash the view secret key, actually, to preserve view wallet ability to see incoming txes.
  300.  
  301. jollymort [1:19 PM]  
  302. so it looks like, either allow re-use and have them small to have plausible deniability with many collisions
  303.  
  304. [1:19]  
  305. or forbid re-use and have them big to avoid any collisions
  306.  
  307.  
  308. moneromooo BOT [1:20 PM]  
  309. I don't see much of a point in forbidding reuse, if they're randomly distributed in the first place.
  310.  
  311.  
  312. kenshi84 BOT [1:20 PM]  
  313. I see. The problem is much more complex than I initially thought :(
  314.  
  315. jollymort [1:20 PM]  
  316. if the sender accidentially sends two times to the same (C,D,k)
  317.  
  318. [1:20]  
  319. you have the 2 txs linked
  320.  
  321. [1:21]  
  322. which may not be a problem, depending on how you feel about it, i suppose
  323.  
  324.  
  325. moneromooo BOT [1:21 PM]  
  326. C,D is the "standard address equivalent", right ?
  327.  
  328. jollymort [1:21 PM]  
  329. yeah
  330.  
  331.  
  332. moneromooo BOT [1:21 PM]  
  333. Then an observer can't tell from hte blockchain.
  334.  
  335. jollymort [1:21 PM]  
  336. the only thing different is that you're able to derive it from (a,b,k)
  337.  
  338.  
  339. moneromooo BOT [1:22 PM]  
  340. (assuming you don't have a huge k-space)
  341.  
  342. jollymort [1:22 PM]  
  343. so your wallet would need to attempt decrypt every output with (A,B) and (C,D) obtained from tx_extra
  344.  
  345. [1:22]  
  346. and if tx_extra contained the right k, the (C,D,k) would resolve to an output belonging to your wallet
  347.  
  348. [1:23]  
  349. kenshi84 it's an interesting problem :slightly_smiling_face:
  350.  
  351. [1:24]  
  352. 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`
  353.  
  354.  
  355. moneromooo BOT [1:24 PM]  
  356. @theking01 had something that might allow that.
  357.  
  358. [1:25]  
  359. But since he participated in that discussion, I guess it doesn't apply or he'd have mentioned it...
  360.  
  361. [1:25]  
  362. Worth asking I guess.
  363.  
  364.  
  365. awxmr BOT [1:42 PM]  
  366. 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?
  367.  
  368. jollymort [1:45 PM]  
  369. You could make a system one vote per cryptographic key, i suppose. But how do you ensure that each person controls exactly one key?
  370.  
  371.  
  372. awxmr BOT [1:46 PM]  
  373. Slack_1 guess that's the trick only one address(key) per person.
  374.  
  375.  
  376. moneromooo BOT [1:50 PM]  
  377. @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).
  378.  
  379. [1:50]  
  380. Shen did some research on that kind of thing.
  381.  
  382.  
  383. DaveyJones BOT [1:55 PM]  
  384. speaking of ^^ is he on vacation? :D
  385.  
  386. kenshi84 [3:19 PM]  
  387. joined #monero-dev
  388.  
  389. kenshi84 [3:26 PM]  
  390. (Hi, trying slack instead of irc)
  391.  
  392. kenshi84 [3:39 PM]  
  393. 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.
  394.  
  395. theking01 [5:43 PM]  
  396. @awxmr of course. In fact, you could use https://github.com/monero-project/urs
  397.  GitHub
  398. monero-project/urs
  399. urs - Unique Ring Signatures to sign messages anonymously
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top