SHARE
TWEET

sub-addresses

a guest Oct 24th, 2016 46 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. ----- Today October 25th, 2016 -----
  2.  
  3. One-time BOT [12:16 AM]  
  4. I was wondering if you guys saw this idea for one-time receiving Monero stealth addresses, and whether there is something wrong with it. From what I could tell, it seems like a promising and natural way to implementthe functionality of HD wallets in Monero. Here is the SE post: http://monero.stackexchange.com/questions/2469/one-time-receiving-monero-address
  5.  
  6.  
  7. One-time BOT [12:34 AM]  
  8. To be more specific, if the receiver; i.e. the owner of address (A,B) = (aG, bG), picks a number k and shares (C,D) = (a^k A, a^k B) with the sender, then, after the sender chooses random r, forms P = H(rC)G+D, and submits {rG, P, k} to the network, the receiver is able to spend using x = H(a^{k+1}*R)+a^k*b. Also, the view key still works fine in this setup: with k and (a, B), the auditor can still check that P = H(a^{k+1}*R)*G
  9.  
  10. jollymort [12:36 AM]  
  11. (C,D) is just another Monero address
  12.  
  13.  
  14. One-time BOT [12:36 AM]  
  15. This way, the wallet owner can produce as many stealth addresses as they wish, and check them all in constant time (as opposed to storint many unrelated keys).
  16.  
  17. [12:36]  
  18. Jollymort: That is correct
  19.  
  20. jollymort [12:36 AM]  
  21. with the link to (A,B) by means of k
  22.  
  23. [12:37]  
  24. you could make any (c,d) into a self-standing monero wallet
  25.  
  26.  
  27. One-time BOT [12:37 AM]  
  28. You could, if you'd like
  29.  
  30. jollymort [12:37 AM]  
  31. it's a HD scheme, where you store k's on the blockchain to optimize scanning for outputs
  32.  
  33. [12:38]  
  34. to me it looks like the terms are getting mixed up
  35.  
  36. [12:38]  
  37. stealth address is never reused as it's generated from an (address + random data)
  38.  
  39. [12:38]  
  40. the address here, can be a normal address, or your sub-addres (C,D)
  41.  
  42.  
  43. One-time BOT [12:39 AM]  
  44. Yes, I was referring to the pair (C,D) as a stealth address. I thought that was the convention
  45.  
  46. jollymort [12:39 AM]  
  47. nah, stealth address in CryptoNote context is something else
  48.  
  49.  
  50. One-time BOT [12:39 AM]  
  51. I thought P was the one-ttime address produced from it
  52.  
  53. jollymort [12:40 AM]  
  54. or I misunderstood it too :slightly_smiling_face:
  55.  
  56.  
  57. One-time BOT [12:40 AM]  
  58. Okay, no problem
  59.  
  60. jollymort [12:40 AM]  
  61. just to avoid confusion
  62.  
  63.  
  64. One-time BOT [12:41 AM]  
  65. So, the idea is to use the payment ID field to store k, but I guess that is not written in stone
  66.  
  67. jollymort [12:42 AM]  
  68. k would start at 1 and be incremented or just random?
  69.  
  70.  
  71. One-time BOT [12:43 AM]  
  72. I guess that is a matter of preference, and only depends on the implementation on the client side
  73.  
  74. jollymort [12:43 AM]  
  75. well, if it's incremented, than many transactions belonging to different users would have the same k
  76.  
  77. [12:43]  
  78. and your wallet would scan every one of them
  79.  
  80. [12:44]  
  81. (scan = attempt to decrypt with matching (c,d))
  82.  
  83. [12:44]  
  84. if it's random, there are some other risks involved
  85.  
  86. [12:44]  
  87. like the sender omits the k, and you lose your record of k's issued
  88.  
  89. [12:44]  
  90. and then, there's no way to recover the funds
  91.  
  92.  
  93. One-time BOT [12:46 AM]  
  94. Our wallets already scan every tx in the blockchain. The advantage is when compared to naively storing many unrelated keys: receiver scans the tx once for (A, B), and then another time using k, so that is at most two tries per output in the blockchain vs. n on a HD wallet with n unrelated keys
  95.  
  96. jollymort [12:47 AM]  
  97. i know. but HD scheme is less risky and more conservative
  98.  
  99. [12:47]  
  100. i've been using mycelium since 2014 and i have like 144 different addresses
  101.  
  102. [12:47]  
  103. doesn't seem too much
  104.  
  105.  
  106. One-time BOT [12:48 AM]  
  107. Indeed, not including k is a risk. One advantage of having this aproach being enbras=ced by the devs is perhaps having it included in the wallet's code, so that the receiver only broadcasts the tx with k attached to it
  108.  
  109. jollymort [12:50 AM]  
  110. well, if you just have some new address scheme, with a few extra chars to encode the `k` and the wallets would reocgnize this...
  111.  
  112.  
  113. One-time BOT [12:50 AM]  
  114. Yeah, I was just realizing that...
  115.  
  116. jollymort [12:50 AM]  
  117. you kind of force them to include it
  118.  
  119. [12:51]  
  120. like paymentID now
  121.  
  122. [12:51]  
  123. (when used in integrated address scheme)
  124.  
  125.  
  126. One-time BOT [12:52 AM]  
  127. Would that require a more profound change in the protocol? Or can we still implement this more or less superficially?
  128.  
  129. jollymort [12:52 AM]  
  130. i think no protocol change needed at all
  131.  
  132. [12:52]  
  133. just a wallet convention thing
  134.  
  135.  
  136. One-time BOT [12:54 AM]  
  137. Could we just use integrated address, you think? I mean, there is still the possibility that the sender would separate the two in their client, but they would have to actually mean to do that
  138.  
  139. jollymort [12:55 AM]  
  140. i guess you could. 1. generate random payment ID, calculate (C,D), create a integrated address of (C,D)+pID and give to sender
  141.  
  142. [12:55]  
  143. hell, you could be the only one using this scheme and nobody would know
  144.  
  145. [12:55]  
  146. and you'd have your personal HD wallet
  147.  
  148. [12:56]  
  149. without anyone else having to change anything
  150.  
  151.  
  152. One-time BOT [12:56 AM]  
  153. So, it is just a matter of programming it into the wallet? Maybe there is even no need to bother the devs about this? :)
  154.  
  155. jollymort [12:56 AM]  
  156. if you can code, you could make a branch to experiment with this
  157.  
  158.  
  159. One-time BOT [12:57 AM]  
  160. True. Sounds like a good exercise
  161.  
  162. jollymort [12:58 AM]  
  163. just one note
  164.  
  165. [12:58]  
  166. i think there's a risk of generating random pID
  167.  
  168. [12:58]  
  169. some incremenal k with some hashing should do it
  170.  
  171. [12:58]  
  172. no, wait, i'm wrong
  173.  
  174. [12:59]  
  175. you can just pretend that every tx with pID is conforming to your scheme and try to decrypti it
  176.  
  177.  
  178. One-time BOT [12:59 AM]  
  179. Yes, that is what I understand too
  180.  
  181. jollymort [1:00 AM]  
  182. but generating these pIDs with something like pID=hash((A)+k) where k would be incremental
  183.  
  184. [1:00]  
  185. might make everything faster
  186.  
  187. [1:00]  
  188. as you could just check the pID first, without trying the decrypt
  189.  
  190. [1:01]  
  191. dunno, i'm overthinking it now
  192.  
  193. [1:01]  
  194. at first i didn't really like the proposal, but now with this pID scheme i'm kind of getting excited :smile:
  195.  
  196. [1:02]  
  197. best part is, you don't have to tell anyone you use this scheme
  198.  
  199. [1:02]  
  200. you just give out a integrated address
  201.  
  202. [1:02]  
  203. like any other
  204.  
  205.  
  206. One-time BOT [1:03 AM]  
  207. Yes, I think it is pretty cool too!
  208.  
  209. jollymort [1:05 AM]  
  210. now I'm not versed in cryptography, so I guess we'd want someone to look at the way you go from (a,b) to (c,d) to be sure it can't be linked back or linked together
  211.  
  212.  
  213. One-time BOT [1:05 AM]  
  214. About your previous comment about the tx with unknown PID, you might want to check that one too, just in the off chance that it was sent to (A,B) and the PID means something else. The sender might decide to put anything as PID after all
  215.  
  216. jollymort [1:05 AM]  
  217. pinging our resident amateur-cyryptographer @theking01
  218.  
  219. theking01 [1:06 AM]  
  220. yo
  221.  
  222. [1:06]  
  223. What's the question?
  224.  
  225.  
  226. One-time BOT [1:06 AM]  
  227. Sure. That is one of the things I was looking for as well. I am not that confident in my understanding of crypto as well
  228.  
  229. jollymort [1:07 AM]  
  230. you saw this proposal for HD scheme with passing `k` ?
  231.  
  232. theking01 [1:07 AM]  
  233. Me either, but I'm another person, at least.
  234.  
  235. [1:07]  
  236. I think so.
  237.  
  238.  
  239. One-time BOT [1:07 AM]  
  240. We would like to know how safe a scheme is. I will copy what a I wrote:
  241.  
  242. theking01 [1:07 AM]  
  243. A simply scheme is just to wait for multisig.
  244.  
  245.  
  246. One-time BOT [1:07 AM]  
  247. To be more specific, if the receiver; i.e. the owner of address (A,B) = (aG, bG), picks a number k and shares (C,D) = (a^k A, a^k B) with the sender, then, after the sender chooses random r, forms P = H(rC)G+D, and submits {rG, P, k} to the network, the receiver is able to spend using x = H(a^{k+1}*R)+a^k*b. Also, the view key still works fine in this setup: with k and (a, B), the auditor can still check that P = H(a^{k+1}*R)*G
  248.  
  249. theking01 [1:07 AM]  
  250. *simpler
  251.  
  252.  
  253. One-time BOT [1:08 AM]  
  254. Doesn't  that solve a different problem?
  255.  
  256. jollymort [1:08 AM]  
  257. its could already be simple "generate random payment ID, calculate (C,D), create a integrated address of (C,D)+pID and give to sender"
  258.  
  259. [1:08]  
  260. the only change would be on the receiver end
  261.  
  262. [1:08]  
  263. for the sender, it'd be just another integrated address
  264.  
  265. theking01 [1:09 AM]  
  266. It would appear so, but multisig will actually allow you to solve the problem your trying to solve, I think.
  267.  
  268.  
  269. One-time BOT [1:09 AM]  
  270. This is just so the user doesn't have to handle the same address to different people, websites, exchanges eta
  271.  
  272. [1:09]  
  273. etc
  274.  
  275. theking01 [1:10 AM]  
  276. Like, what you do is you have a base address P, and for each person you need to send to, you give them the address 2-of-2 P, P'
  277.  
  278. jollymort [1:10 AM]  
  279. one-time i think it's a good idea if implemented adequately considering what we discussed
  280.  
  281. theking01 [1:11 AM]  
  282. a is view key, right?
  283.  
  284. jollymort [1:11 AM]  
  285. yeah
  286.  
  287. [1:11]  
  288. a and c
  289.  
  290.  
  291. One-time BOT [1:11 AM]  
  292. @theking01: Maybe. But even if it does, this seems like an elegant way to solve the issue of address reuse
  293.  
  294. [1:11]  
  295. Yes
  296.  
  297. [1:11]  
  298. And this feels like a low hanging fruit too :)
  299.  
  300. theking01 [1:12 AM]  
  301. You would need a new k for every transaction, for one.
  302.  
  303. jollymort [1:12 AM]  
  304. no
  305.  
  306. [1:12]  
  307. you can reuse it too
  308.  
  309.  
  310. One-time BOT [1:12 AM]  
  311. no
  312.  
  313. jollymort [1:12 AM]  
  314. no risk
  315.  
  316. [1:12]  
  317. every (C,D) is a regular monero address
  318.  
  319.  
  320. One-time BOT [1:12 AM]  
  321. Every output would still use the random r, just the same as a regular tx
  322.  
  323. theking01 [1:12 AM]  
  324. People would see reused k's.
  325.  
  326. jollymort [1:12 AM]  
  327. it's just that there's a one-way link (c,d) = f(a,b,k)
  328.  
  329. theking01 [1:13 AM]  
  330. If they are one chain.
  331.  
  332. [1:13]  
  333. Defeating the reason for stealth addresses.
  334.  
  335. jollymort [1:13 AM]  
  336. so what? people reuse payment id's too
  337.  
  338. theking01 [1:13 AM]  
  339. *on chain
  340.  
  341. jollymort [1:13 AM]  
  342. thing is, nobody could tell the difference
  343.  
  344. theking01 [1:13 AM]  
  345. Reusing payment ids are fine if they are encrypted.
  346.  
  347. jollymort [1:14 AM]  
  348. i mean, if you give out a integrated address
  349.  
  350. theking01 [1:14 AM]  
  351. But clear text payment ID reuse is a problem
  352.  
  353. jollymort [1:14 AM]  
  354. all tx sent to it will have same TX_EXTRA data, no?
  355.  
  356. theking01 [1:14 AM]  
  357. No
  358.  
  359. [1:15]  
  360. If you send to an integrated address twice, the tx extra will be unlinkable.
  361.  
  362. [1:15]  
  363. Since encrypted tx keys use a one time key.
  364.  
  365. [1:15]  
  366. *tx ids
  367.  
  368. jollymort [1:16 AM]  
  369. need to read up on this
  370.  
  371. [1:16]  
  372. but i think we're getting somewhere with this idea
  373.  
  374. theking01 [1:16 AM]  
  375. So if I reuse an encrypted payment id, it's fine.
  376.  
  377. [1:16]  
  378. I'm been thinking about the address reuse problem for sometime.
  379.  
  380. jollymort [1:17 AM]  
  381. read up for some ideas :slightly_smiling_face:
  382.  
  383. theking01 [1:17 AM]  
  384. Anyways, a^k would better be a*k.
  385.  
  386. jollymort [1:17 AM]  
  387. EC multiplication?
  388.  
  389. theking01 [1:17 AM]  
  390. Exponents are unnecessary.
  391.  
  392. [1:17]  
  393. Regular multiplication.
  394.  
  395. [1:17]  
  396. Since they are both numbers.
  397.  
  398. [1:18]  
  399. I think bilinear group cryptography would be required for an adequate solution.
  400.  
  401. [1:19]  
  402. The problem is you need to tell the receiver how to receive it, but without knowing what their keys are.
  403.  
  404. [1:20]  
  405. Like, you have Alice, Bob, and the world.
  406.  
  407. [1:21]  
  408. Alice wants Bob to pay her, but not know that she is Alice, and Bob wants to pay Ecila (Alice's pseudonym), without the world linking the transactions.
  409.  
  410.  
  411. moneromooo BOT [1:23 AM]  
  412. luigi1111w: luigi1114: luigi1112: luigiiiiii: ^
  413.  
  414. theking01 [1:23 AM]  
  415. Alice at least needs to remember her pseudonym with the current methods I think, since if you put it in txextra, the world wins.
  416.  
  417. [1:23]  
  418. Unless Alice gives Bob her keys, and then Bob wins.
  419.  
  420.  
  421. One-time BOT [1:23 AM]  
  422. @theking01: One thing is that, if k is small, say k = 2, one can check that C = 2*(A) = (2*a)*G without knowing a, whereas it would be hard to check whether C = (a*a)*G without knowing already a. Also, teh exponentiation is realy just a few multiplications already, if we use fast exponentiations.
  423.  
  424. [1:24]  
  425. that is: successive squarings
  426.  
  427. theking01 [1:24 AM]  
  428. Hmm, true
  429.  
  430. jollymort [1:24 AM]  
  431. the main problem i see is communicate `k` safely without it getting `lost`
  432.  
  433.  
  434. One-time BOT [1:25 AM]  
  435. k can be public\
  436.  
  437. theking01 [1:25 AM]  
  438. Actually, k can be small.
  439.  
  440. jollymort [1:25 AM]  
  441. thought we could use integrated address but seems i was wrong becasue i forgot pID there is encrypted with a
  442.  
  443.  
  444. One-time BOT [1:25 AM]  
  445. Oh, you mean the sender not including it?
  446.  
  447. theking01 [1:25 AM]  
  448. Alice still has to remember not to reuse k's though.
  449.  
  450. [1:26]  
  451. Also, instead of a^k, why not H(a,k)?
  452.  
  453.  
  454. One-time BOT [1:26 AM]  
  455. Why?
  456.  
  457. jollymort [1:26 AM]  
  458. but you can't stop a sender from sending again to the same kCD pair
  459.  
  460.  
  461. One-time BOT [1:26 AM]  
  462. I mean, sure :)
  463.  
  464. theking01 [1:26 AM]  
  465. If she reuses k, the identities will be linked.
  466.  
  467.  
  468. One-time BOT [1:26 AM]  
  469. Right, I agree
  470.  
  471. jollymort [1:27 AM]  
  472. ok how about this then
  473.  
  474. [1:27]  
  475. ignore, let me form my thoughts for 5min and i come back :slightly_smiling_face:
  476.  
  477.  
  478. One-time BOT [1:27 AM]  
  479. But that is the same deal with other implementations of HD wallets
  480.  
  481. theking01 [1:27 AM]  
  482. You could make k small id numbers.
  483.  
  484. [1:28]  
  485. That could efficiently be searched.
  486.  
  487.  
  488. One-time BOT [1:29 AM]  
  489. That would be an advantage. On the other hand, if you are sending a bunch of txs in short sucession, those sequential values could leak that fact a bit
  490.  
  491. theking01 [1:29 AM]  
  492. And could search the blockchain to see which id numbers have already been used.
  493.  
  494. [1:30]  
  495. But the ids could be hidden. You wouldn't need to store them in tx extra.
  496.  
  497.  
  498. One-time BOT [1:30 AM]  
  499. JollyMort suggested a Mycelium style pID=hash((A)+k)
  500.  
  501. theking01 [1:31 AM]  
  502. If k is small, it can be bruteforced by the receiver.
  503.  
  504.  
  505. One-time BOT [1:32 AM]  
  506. I see that now that you mention
  507.  
  508. jollymort [1:36 AM]  
  509. Ok, here goes:
  510.  
  511. Note: `(A,B)` refers to main address, `(C,D)` to some sub-address. Small caps are private view,spend keys.
  512. 1. The `k` will be incremented from 1 to ...
  513. 2. `k` is padded to the size of short pIDs with 0s, but the first byte could be "AA" or something.
  514. 2. User encrypts `k` with `a`, obtain `K`
  515. 3. User generates (C,D)=f(A,B,k)
  516. 4. User prepares integrated address consisting of (C,D) + K
  517. 5. sender pays to user
  518. 6. user decrypts K, and checks for first byte "AA", if yes, decrypt the output with (C,F)=f(A,B,k)
  519.  
  520. [1:38]  
  521. 3 & 6 should be small caps (private keys)
  522.  
  523. [1:42]  
  524. think there should be some sender random data + DK exchange added somewhere in the process :smile:
  525.  
  526. [1:42]  
  527. DH
  528.  
  529.  
  530. One-time BOT [1:43 AM]  
  531. Jollymort: I like the idea of carrying the information that the address was derived using this scheme by having a sufix, because I was just noticing that (A,B) would enjoy a special treatment in the user's wallet compared to any other (C,D) generated from it, in that the wallet always checks if a tx belongs to (A,B), or (A,B) plus the PID, which would be a (C,D), but never for (C,D) plus the PID.
  532.  
  533. [1:44]  
  534. Otherwise we would just revert to regulat HD linear grouth
  535.  
  536. [1:44]  
  537. in number of addresses to check
  538.  
  539. jollymort [1:44 AM]  
  540. this way you have a fallback method to restore all
  541.  
  542. [1:45]  
  543. but i still suspect i misunderstood integrated addresses, again
  544.  
  545. [1:45]  
  546. (looking for the paper describing them)
  547.  
  548. [1:46]  
  549. this: http://pastebin.com/bp5RKXuC
  550.  Pastebin
  551. [JavaScript] Stealth Payment IDs 0.8.5 - Pastebin.com (19KB)
  552.  
  553.  
  554.  
  555. One-time BOT [1:47 AM]  
  556. I am not sure I understand how the address and PID are encoded together, but it seems to reversible by playing with the wallet. I haven't tried reversing an integrated address that wasn't created by me though
  557.  
  558. jollymort [1:47 AM]  
  559. it's described in this link ^
  560.  
  561. [1:47]  
  562. reading it now
  563.  
  564. [1:48]  
  565. also, check out http://xmrtests.llcoins.net/addresstests.html
  566.  
  567. [1:48]  
  568. theres a nice explanation at the bottom of the page
  569.  
  570. jollymort [1:54 AM]  
  571. ah it can't work with integrated addresses in the current form
  572.  
  573. [1:55]  
  574. at least not in the way i imagined it
  575.  
  576.  
  577. One-time BOT [1:55 AM]  
  578. What problem did you see? I am still trying to understand
  579.  
  580. jollymort [1:56 AM]  
  581. encryption key = H(sharedSecret + 0x8d)
  582.  
  583.  
  584. One-time BOT [1:57 AM]  
  585. Is sharedSecret the r value?
  586.  
  587. jollymort [1:57 AM]  
  588. i think so
  589.  
  590.  
  591. luigi1111w BOT [1:57 AM]  
  592. sharedSecret is rA or aR
  593.  
  594.  
  595. smooth BOT [1:58 AM]  
  596. which one?
  597.  
  598.  
  599. luigi1111w BOT [1:58 AM]  
  600. the one that encryption key =
  601.  
  602. jollymort [1:58 AM]  
  603. but if you give out (C,D) you need to know which (c,d) to use to decrypt it
  604.  
  605.  
  606. luigi1111w BOT [1:58 AM]  
  607. indeed
  608.  
  609. jollymort [1:59 AM]  
  610. so that's why.. idea was to be able to use (a,b) to find these (C,D,k) transactions
  611.  
  612.  
  613. luigi1111w BOT [1:59 AM]  
  614. I'm still catching up on backlog, feel free to ignore me
  615.  
  616.  
  617. One-time BOT [2:04 AM]  
  618. Sorry, I have to be afk for a moment
  619.  
  620. jollymort [2:13 AM]  
  621. pero BOT [1:39 AM]  some hoppers in #monero-dev are solving P=NP
  622. [1:39]  moon soon
  623.  
  624. [2:13]  
  625. lol
  626.  
  627.  
  628. luigi1111w BOT [2:14 AM]  
  629. rofl
  630.  
  631. [2:14]  
  632. pretty sure that wouldn't be moon
  633.  
  634. jollymort [2:15 AM]  
  635. quite the opposite
  636.  
  637.  
  638. One-time BOT [2:20 AM]  
  639. I am back
  640.  
  641. [2:20]  
  642. But still reading
  643.  
  644. [2:20]  
  645. Will have to leave in 20 min again though...
  646.  
  647. theking01 [2:29 AM]  
  648. aR=rA
  649.  
  650. [2:29]  
  651. That's the point.
  652.  
  653. jollymort [2:29 AM]  
  654. so One-time, the problem of my proposal before is in step 6., because you're decypting the pID with `c`, but you can't know which `c` to use because you don't know the `k` which is hidden inside..
  655.  
  656.  
  657. luigi1111w BOT [2:30 AM]  
  658. you can't encrypt k, right
  659.  
  660. jollymort [2:30 AM]  
  661. so, bugger
  662.  
  663. [2:30]  
  664. if using ordinary pID
  665.  
  666. [2:30]  
  667. then you could give out a `k` encrypted with your a, just to obfucsate what's it for
  668.  
  669. [2:31]  
  670. but if sender uses the same pID few times, the transactions can be linked
  671.  
  672. theking01 [2:31 AM]  
  673. Can you generate random k in such a way that chance of collisions is negligible but can still be bruteforced?
  674.  
  675. [2:31]  
  676. @luigi1111
  677.  
  678. jollymort [2:31 AM]  
  679. all belonging to the same address (C,D)
  680.  
  681.  
  682. luigi1111w BOT [2:31 AM]  
  683. yes @jollymort that is the concern
  684.  
  685. [2:32]  
  686. you negate the advantage of stealth addresses if you reuse these "HD" ones
  687.  
  688. [2:32]  
  689. unless k is small
  690.  
  691. jollymort [2:32 AM]  
  692. yeah
  693.  
  694. theking01 [2:32 AM]  
  695. Like would 64-bits work?
  696.  
  697.  
  698. luigi1111w BOT [2:32 AM]  
  699. that's not small enough to negate the linkability thing
  700.  
  701. theking01 [2:33 AM]  
  702. I think 128 would be too big.
  703.  
  704. jollymort [2:33 AM]  
  705. 16 bits
  706.  
  707.  
  708. luigi1111w BOT [2:33 AM]  
  709. "any" is fine if you don't reuse
  710.  
  711. theking01 [2:33 AM]  
  712. Couldn't bruteforce k
  713.  
  714.  
  715. luigi1111w BOT [2:33 AM]  
  716. if you do reuse you have to be really small
  717.  
  718. [2:33]  
  719. so there's lots of collisions
  720.  
  721. [2:33]  
  722. but then you have to check them
  723.  
  724. [2:34]  
  725. most won't be for you
  726.  
  727. [2:34]  
  728. but that's less than checking all outputs now
  729.  
  730. jollymort [2:34 AM]  
  731. so again, plain HD would work better
  732.  
  733. theking01 [2:34 AM]  
  734. Yeah, I guess doing 64-bit bruteforce for every output would be a bit much.
  735.  
  736.  
  737. luigi1111w BOT [2:35 AM]  
  738. yes way too much :)
  739.  
  740. jollymort [2:35 AM]  
  741. 16bits gives you 65535 sub-addresses
  742.  
  743. [2:35]  
  744. more than enough for normal people
  745.  
  746. [2:35]  
  747. 179 years of tx/day
  748.  
  749. theking01 [2:35 AM]  
  750. 32 bits is way too many k-collisions
  751.  
  752.  
  753. luigi1111w BOT [2:35 AM]  
  754. why do we need to bruteforce k?
  755.  
  756. theking01 [2:35 AM]  
  757. So we don't need the put it in tx extra.
  758.  
  759. [2:36]  
  760. Or remember it.
  761.  
  762. jollymort [2:36 AM]  
  763. but if small enough you could put it in txextra, as it would collide with other users
  764.  
  765.  
  766. luigi1111w BOT [2:36 AM]  
  767. then there's nothing to identify it...
  768.  
  769. theking01 [2:36 AM]  
  770. (you could be using two wallets, for example)
  771.  
  772. jollymort [2:36 AM]  
  773. so you lose some linkability
  774.  
  775. [2:36]  
  776. anonymity set would be all the users who're using the scheme
  777.  
  778. theking01 [2:36 AM]  
  779. (and you don't want them to generate the same k if they aren't synced)
  780.  
  781. [2:38]  
  782. If you have memory, it's easier.
  783.  
  784. [2:39]  
  785. To make a new address, do A'=H(k,a)G+A, B'=H(k,a)G+B
  786.  
  787. [2:39]  
  788. And remember k
  789.  
  790. jollymort [2:39 AM]  
  791. what's G?
  792.  
  793.  
  794. luigi1111w BOT [2:40 AM]  
  795. the basepoint
  796.  
  797. jollymort [2:40 AM]  
  798. ah yes
  799.  
  800.  
  801. luigi1111w BOT [2:40 AM]  
  802. but how do you remember k?
  803.  
  804.  
  805. One-time BOT [2:40 AM]  
  806. Jollymort: I see. It just started to sink in for me that k can't go out in the clear, otherwise the trasactions that reuse it can be linked... Feeling a bit stupid right now, hahaha
  807.  
  808. theking01 [2:40 AM]  
  809. Computer memory
  810.  
  811. jollymort [2:40 AM]  
  812. nah, it was interesting
  813.  
  814.  
  815. luigi1111w BOT [2:40 AM]  
  816. One-time are you the reddit user?
  817.  
  818. [2:40]  
  819. @theking01 what about restoring the wallet?
  820.  
  821. jollymort [2:40 AM]  
  822. i learned something more, and i think you did too :slightly_smiling_face:
  823.  
  824. theking01 [2:40 AM]  
  825. I'm saying if you can save k to a file, for example.
  826.  
  827. jollymort [2:40 AM]  
  828. but if you lose it?
  829.  
  830.  
  831. luigi1111w BOT [2:40 AM]  
  832. yes but your computer crashes
  833.  
  834. jollymort [2:40 AM]  
  835. bruteforce
  836.  
  837. theking01 [2:41 AM]  
  838. And you could make them small.
  839.  
  840.  
  841. One-time BOT [2:41 AM]  
  842. No
  843.  
  844. theking01 [2:41 AM]  
  845. You need to remember them to prevent reuse though.
  846.  
  847.  
  848. luigi1111w BOT [2:41 AM]  
  849. who is user141?
  850.  
  851. theking01 [2:41 AM]  
  852. If your computer crashes, you need to salt the hash.
  853.  
  854. new messages
  855. [2:41]  
  856. For future hd addresses.
  857.  
  858. [2:42]  
  859. Or generate a new base address.
  860.  
  861.  
  862. luigi1111w BOT [2:42 AM]  
  863. you need to find old outputs with the restore..
  864.  
  865. [2:42]  
  866. you can't do that unless you can bruteforce the ks
  867.  
  868. theking01 [2:42 AM]  
  869. If k is small, that should be fine.
  870.  
  871.  
  872. luigi1111w BOT [2:42 AM]  
  873. or have them be deterministic
  874.  
  875. theking01 [2:42 AM]  
  876. Like sequential I'd numbers.
  877.  
  878.  
  879. One-time BOT [2:42 AM]  
  880. I have to go now. Catch up with you guys later
  881.  
  882. theking01 [2:42 AM]  
  883. *id
  884.  
  885. jollymort [2:43 AM]  
  886. the point of the idea was to avoid to have to try out each derived address, like you would in a HD scheme
  887.  
  888. [2:44]  
  889. maybe it's one of the "impossible" problems
  890.  
  891.  
  892. luigi1111w BOT [2:44 AM]  
  893. which is basically attaching k
  894.  
  895. jollymort [2:44 AM]  
  896. which could be proven impossible
  897.  
  898. [2:44]  
  899. yeah
  900.  
  901.  
  902. luigi1111w BOT [2:44 AM]  
  903. which isn't really different than a plaintext id
  904.  
  905. jollymort [2:44 AM]  
  906. exactly
  907.  
  908.  
  909. luigi1111w BOT [2:44 AM]  
  910. but yes I've given this some thought
  911.  
  912. [2:44]  
  913. haven't come up with a reasonable solution yet
  914.  
  915. [2:45]  
  916. (not HD)
  917.  
  918. theking01 [2:45 AM]  
  919. It would only be necessary during crashes.
  920.  
  921.  
  922. luigi1111w BOT [2:45 AM]  
  923. I mean the scan time vs linkability issue
  924.  
  925. [2:45]  
  926. they seem diametrically opposed
  927.  
  928. jollymort [2:45 AM]  
  929. yeah
  930.  
  931. theking01 [2:45 AM]  
  932. @luigi1111 I think bilinear groups could be a solution
  933.  
  934.  
  935. luigi1111w BOT [2:46 AM]  
  936. I haven't looked at those
  937.  
  938. theking01 [2:46 AM]  
  939. They essentially allow you to "multiply" group elements.
  940.  
  941. [2:47]  
  942. So you could do R=rG and X=R*C
  943.  
  944. [2:47]  
  945. Or something like that.
  946.  
  947.  
  948. luigi1111w BOT [2:47 AM]  
  949. interesting
  950.  
  951. theking01 [2:48 AM]  
  952. It might not work with monero's elliptic curve though. I haven't looked into it enough.
  953.  
  954. jollymort [2:51 AM]  
  955. it's an interesting problem, feels like the 5th piece to add to the privacy puzzle (1.unlinkability 2.untraceability 3.rCT 4.Kovri 5.no-address-reuse)
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