Advertisement
Guest User

Untitled

a guest
Jul 18th, 2018
176
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.22 KB | None | 0 0
  1. Within-group privacy in CoinJoin (or, the lack of it).
  2. ======================================================
  3.  
  4. Coinjoin with 2 participants:
  5. =============================
  6. No kind of crypto moon math is going to prevent the other participant from knowing your output address.
  7.  
  8. Coinjoin with N *peer* participants:
  9. ====================================
  10. By 'peer' I mean - not distinguishing roles like maker/taker.
  11. In simplest implementation without blinding:
  12. Peers negotiate a transaction. In doing so, they must tell their output addresses to at least one other peer. So at least this little bit of privacy is lost.
  13.  
  14. Various other implementations:
  15. ==============================
  16. -Can use multiparty computation to create protocols where peers throw addresses into a hat and somehow they are jumbled such that nobody knows which output corresponds to which input. Problem: MPC is not a workable technology today, really.
  17.  
  18. Implementation with blinding:
  19. =============================
  20. Assume a central server to negotiate the Tx.
  21. Now it becomes a multi-stage protocol:
  22. Stage 1: All participants send their inputs, amounts to server. They also send the output address, but blinded.
  23. Stage 2: Server signs the blinded output and sends it back.
  24. Stage 3: Participants have to reconnect/anonymise, then send the unblinded output addresses to the server.
  25. Stage 4: Now server can verify the signatures, so he knows he has all the right outputs without knowing who sent which.
  26. Stage 5: server can construct the transaction, send out to participants, who can then sign (bitcoin sign) (on any kind of connection).
  27.  
  28. This is all a bit of an ugly mess, but it does solve the problem of not having the participants know each others' business.
  29.  
  30. Coinjoin with M 'maker' participants and 1 'taker' participant:
  31. ===============================================================
  32. An intriguing, almost psychological twist:
  33.  
  34. Assuming non-colluding 'greedy-honest' makers:
  35. ==============================================
  36. The taker knows the makers' outputs, but the makers are assumed to have only the vice of greed, so that their joining activity was only intended to make them money.
  37. The makers do not need to know the taker's output. Since the taker assembles the transaction he gets the information from all makers, but if makers do not collude they cannot distinguish M of the M+1 outputs (those other than their own).
  38.  
  39. Assuming colluding makers:
  40. ==========================
  41. If all M makers collude with each other, then they can pinpoint the taker's output address. If any 1 of the M makers is not a colluder, then at least some privacy is achieved.
  42.  
  43. Summary
  44. =======
  45. It seems that the central issue/question remains: how does such a system defend against sybil by non-financially motivated actors offering the service for free? Although that does not leave the user in a worse position than he was originally (totally transparent tx graph), it could serve as a honeypot.
  46. The only answer is Chaumian blinding, but this requires not only a multi-stage protocol, but also that the participants use internet anonymity techniques. Only the most motivated user is going to stop and restart with a new internet connection to complete the protocol - unless this can be managed for the user.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement