[{"data":1,"prerenderedAt":235},["ShallowReactive",2],{"docs-\u002Fdocs\u002Fcore-tech\u002Ftransaction-graph-obfuscation":3,"docs-surround-\u002Fdocs\u002Fcore-tech\u002Ftransaction-graph-obfuscation":224},{"id":4,"title":5,"body":6,"description":12,"extension":216,"image":217,"meta":218,"navTitle":217,"navigation":219,"path":220,"seo":221,"stem":222,"__hash__":223},"docs\u002Fdocs\u002Fcore-tech\u002FTransaction-graph-obfuscation.md","Transaction Graph Obfuscation",{"type":7,"value":8,"toc":203},"minimark",[9,13,31,38,43,46,54,61,65,68,75,80,83,91,94,98,101,118,121,126,129,132,136,139,142,174,178,181,184,187,190,193,197,200],[10,11,12],"p",{},"MW offers great anonymity out-of-the-box, because of the following:",[14,15,16,20,23],"ol",{},[17,18,19],"li",{},"No addresses",[17,21,22],{},"Transaction values are blinded",[17,24,25,26,30],{},"Transaction graph is ",[27,28,29],"u",{},"obfuscated",".",[10,32,33,34,30],{},"Now, it may sound surprising, but the (3) is actually a ",[35,36,37],"strong",{},"misconception",[39,40,42],"h3",{"id":41},"what-why","What? Why?",[10,44,45],{},"As we know, original transactions are merged in a block non-interactively, so that the block is one big transaction, and there is no feasible way to recover the original transaction graph. All the UTXOs look just as arbitrary EC points, and every input can literally correspond to any output. And the bigger the block is - the higher is the obfuscation degree.",[10,47,48,49,53],{},"But let's think how the transactions make their way to the block. First they are prepared by the participants, and then they are ",[50,51,52],"em",{},"broadcasted"," to the network. And the participants are interested to broadcast it to the entire network, to as many nodes as possible, to increase the probability of it being accepted in a block, and the block mined eventually.",[10,55,56,57,60],{},"If this is indeed the case, i.e. transactions are just broadcasted as-is to the entire network, then the attacker can easily see the original transaction graph with just a ",[27,58,59],{},"single"," malicious node, and the later obfuscation in the block doesn't matter anymore.",[39,62,64],{"id":63},"so-what-no-addresses-so-why-bother","So what? No addresses, so why bother?",[10,66,67],{},"Is the transaction graph really important? It is. Moreover, in MW hiding the transaction graph seems to be way more important than hiding the user identities.",[10,69,70,71,74],{},"MW transaction is anonymous, but it reveals one important thing: there is clearly a ",[27,72,73],{},"relation"," between the users. So looking at the transaction graph attacker sees the \"relation\" graph. If arbitrary user gets revealed (for whatever reason) - he can disclose the related users, and the attacker knows for sure there is a relation.",[76,77,79],"h4",{"id":78},"example","Example",[10,81,82],{},"Suppose Bob has a store, and Alice is his rival, she wants to know Bob's supplier. So she pays Bob (buys something from him), then Bob pays his supplier Charlie, later Charlie pays Dan, Dan pays Erin. Alice sees all those transactions, but has no idea of user identities.",[10,84,85,86,90],{},"Eventually Erin gets revealed - buys something from Alice for instance. Alice kindly asks ",[87,88,89],"span",{},"bribes \u002F threatens \u002F tortures"," Erin to tell her who did he get that UTXO from, this way Dan gets revealed. And so on. At every step Alice is certain there is a relation to the next user.",[10,92,93],{},"In contrast, if we assume that the user identity are not well concealed, but the transaction graph is obfuscated - then there is almost no problem. Attacker only gathers the information that a specific user performs a transaction, without any knowledge of the transaction amount, and who is that designated for.",[39,95,97],{"id":96},"are-there-existing-solutions","Are there existing solutions?",[10,99,100],{},"Of course. There are known solutions: CoinShuffle, ValueShuffle, but they are not perfect.",[102,103,104,107],"ul",{},[17,105,106],{},"This requires groups of unrelated people to cooperate",[17,108,109,110],{},"Attacker may create many malicious users \"for free\", that would pretend to participate in CoinShuffle, but in practice can:\n",[102,111,112,115],{},[17,113,114],{},"Learn the transaction graph. Would act as unrelated users, but actually belong to the attacker.",[17,116,117],{},"DoS attack: created invalid transactions (reference non-existing inputs, etc.)",[10,119,120],{},"Those techniques may be useful, but may cause hassles for the users: more preparation time, higher chance to spoil the transaction.\nThis means in turn that the majority of users may decide to skip this obfuscation, and broadcast the original transaction as-is, because \"they have nothing to hide\". This naturally would affect the privacy of other users (anonymity works best when obeyed by all the users).",[122,123,125],"h2",{"id":124},"proposition-in-node-obfuscation","Proposition: In-Node obfuscation",[10,127,128],{},"Given the fact that MW transactions are merged non-interactively - Nodes can automatically obfuscate the original transaction graph up to some degree. It may not necessarily replace, but complement transparently the obfuscation done by the users.",[10,130,131],{},"This can easily be done in a modified Dandelion. Though originally developed to conceal the user identity, it can be adopted to obfuscate transaction graph during the stem phase, where the transactions get passed through several nodes, but before they are broadcasted to the entire network.",[39,133,135],{"id":134},"non-interactive-merge","Non-interactive merge",[10,137,138],{},"That is, while in the stem phase, instead of immediately passing the transaction to a single peer, the Node may wait for some reasonable timeout to try to merge it with another one. So that the transaction grows like a snowball.",[10,140,141],{},"The following however should be taken into consideration",[102,143,144,147,155,163],{},[17,145,146],{},"To be \"fair\" Node should only merge transactions with comparable fee\u002Fsize ratio. Otherwise this would reduce the motivation for users to increase the fee (if it'll be diffused anyway).",[17,148,149,150],{},"In particular a Node can just  \"hijack\" the fee: append its transaction without any fee to another one.\n",[102,151,152],{},[17,153,154],{},"There's nothing can be done to prevent this, but users may see the unfair behavior a-posteriori, and ban that Node.",[17,156,157,158],{},"Malicious Node can record the transactions that it passes in the stem phase, and then see the difference when they're broadcasted in the fluff phase.\n",[102,159,160],{},[17,161,162],{},"To minimize the amount of leaked info Nodes should merge only transactions of comparable size, instead of incrementally add small transactions.",[17,164,165,166],{},"To prevent DoS attacks Nodes should ensure there are no conflicts. Means:\n",[102,167,168,171],{},[17,169,170],{},"All the being-merged transactions are valid, and reference existing inputs",[17,172,173],{},"No double-spends or etc.",[39,175,177],{"id":176},"dummy-utxos","Dummy UTXOs",[10,179,180],{},"Another possibility: any Node can easily \"enlarge\" a transaction by appending one or several dummy outputs to it. By \"dummy\" we mean an UTXO which encodes zero value, but looks just as good as the others.",[10,182,183],{},"For every such an appended dummy UTXO the Node sets a random timer (in terms of blocks num), after which it would append the same UTXO as an input in a random transaction later, which (probably) has no relation to the original one.",[10,185,186],{},"By this the Node creates a \"background activity\", which is mixed with and should be indistinguishable from the real activity.",[10,188,189],{},"The obvious disadvantage of this scheme is the creation of dummy UTXOs, waste of the block space, and network traffic + resources for validating it. But the good part is that it won't affect the scalability in the long-run, since kernels aren't created, and all the dummy UTXOs are spent eventually.",[10,191,192],{},"In practice it seems that a combination of both schemes should be used: merge real transactions whenever possible, or add dummies.",[39,194,196],{"id":195},"how-much-should-the-transaction-graph-be-obfuscated","How much should the transaction graph be obfuscated",[10,198,199],{},"No exact numbers yet. But it seems that even a slight obfuscation has a dramatic positive effect on the anonymity. For instance, if we merge just 2 transactions at once, it already creates roughly 1\u002F2 uncertainty for the input-output relation. So that if an attacker reveals a user after 10 hops - there is only roughly a 10^-3 probability for the user relation.",[10,201,202],{},"Since the transaction being-passed doesn't have an indication is it original or not, the obfuscation criteria should be based on the visible transaction parameters. Which comes down to the number of inputs and outputs.",{"title":204,"searchDepth":205,"depth":205,"links":206},"",2,[207,209,210,211],{"id":41,"depth":208,"text":42},3,{"id":63,"depth":208,"text":64},{"id":96,"depth":208,"text":97},{"id":124,"depth":205,"text":125,"children":212},[213,214,215],{"id":134,"depth":208,"text":135},{"id":176,"depth":208,"text":177},{"id":195,"depth":208,"text":196},"md",null,{},true,"\u002Fdocs\u002Fcore-tech\u002Ftransaction-graph-obfuscation",{"description":12},"docs\u002Fcore-tech\u002FTransaction-graph-obfuscation","EaBWuFeJa3wtZ-sCHOMdqTLNaiyQIgGEsLDIZINWHGE",[225,230],{"title":226,"path":227,"stem":228,"description":229,"children":-1},"Transaction creation protocol","\u002Fdocs\u002Fcore-tech\u002Ftransaction-creation-protocol","docs\u002Fcore-tech\u002FTransaction-creation-protocol","Creating transactions in Beam (as with other MimbleWimble implementations) is interactive. In order to create a new Beam transaction, the sending and receiving wallets communicate with each other. The wallets exchange parameters which produce the transaction. As a result, the protocol between the wallets is extendable.",{"title":231,"path":232,"stem":233,"description":234,"children":-1},"Transaction Ordering And Front Running Protection","\u002Fdocs\u002Fcore-tech\u002Ftransaction-ordering-and-front-running-protection","docs\u002Fcore-tech\u002FTransaction-ordering-and-front-running-protection","The following is a design of a trading system, which aims to achieve 2 goals:",1783006084826]