[{"data":1,"prerenderedAt":351},["ShallowReactive",2],{"docs-\u002Fdocs\u002Fcore-tech\u002Fmimblewimble-whitepaper-(june-2016)":3,"docs-surround-\u002Fdocs\u002Fcore-tech\u002Fmimblewimble-whitepaper-(june-2016)":340},{"id":4,"title":5,"body":6,"description":12,"extension":332,"image":333,"meta":334,"navTitle":333,"navigation":335,"path":336,"seo":337,"stem":338,"__hash__":339},"docs\u002Fdocs\u002Fcore-tech\u002FMimblewimble-Whitepaper-(June-2016).md","Mimblewimble Whitepaper (June 2016)",{"type":7,"value":8,"toc":329},"minimark",[9,13,21,24,27,30,33,49,52,59,66,72,77,80,83,94,97,104,107,115,118,121,145,155,158,172,175,178,183,190,193,200,203,214,217,222,225,228,235,238,241,247,252,255,274],[10,11,12],"p",{},"MIMBLEWIMBLE\nTom Elvis Jedusor\n19 July, 2016",[10,14,15,16,20],{},"**",[17,18,19],"strong",{},"\u002F\nIntroduction\n\u002F","**\\",[10,22,23],{},"Bitcoin is the first widely used financial system for which all the necessary\ndata to validate the system status can be cryptographically verified by anyone.\nHowever, it accomplishes this feat by storing all transactions in a public\ndatabase called \"the blockchain\" and someone who genuinely wishes to check\nthis state must download the whole thing and basically replay each transaction,\ncheck each one as they go. Meanwhile, most of these transactions have not\naffected the actual final state (they create outputs that are destroyed\na transaction later).",[10,25,26],{},"At the time of this writing, there were nearly 150 million transactions\ncommitted in the blockchain, which must be replayed to produce a set of\nonly 4 million unspent outputs.",[10,28,29],{},"It would be better if an auditor needed only to check data on the outputs\nthemselves, but this is impossible because they are valid if and only if the\noutput is at the end of a chain of previous outputs, each signs the next. In\nother words, the whole blockchain must be validated to confirm the final\nstate.",[10,31,32],{},"Add to this that these transactions are cryptographically atomic, it is clear\nwhat outputs go into every transaction and what emerges. The \"transaction graph\"\nresulting reveals a lot of information and is subjected to analysis by many\ncompanies whose business model is to monitor and control the lower classes.\nThis makes it very non-private and even dangerous for people to use.",[10,34,35,36,40,41,44,45,48],{},"Some solutions to this have been proposed. Greg Maxwell discovered to encrypt\nthe amounts, so that the graph of the transaction is faceless but still allow\nvalidation that the sums are correct ",[37,38,39],"span",{},"1",". Dr Maxwell also produced CoinJoin,\na system for Bitcoin users to combine interactively transactions, confusing\nthe transaction graph. Nicolas van Saberhagen has developed a system to blind\nthe transaction entries, goes much further to cloud the transaction graph (as\nwell as not needed the user interaction) ",[37,42,43],{},"3",". Later, Shen Noether combined\nthe two approaches to obtain \"confidential transactions\" of Maxwell AND the\ndarkening of van Saberhagen ",[37,46,47],{},"4",".",[10,50,51],{},"These solutions are very good and would make Bitcoin very safe to use. But\nthe problem of too much data is made even worse. Confidential transactions\nrequire multi-kilobyte proofs on every output, and van Saberhagen signatures\nrequire every output to be stored for ever, since it is not possible to tell\nwhen they are truly spent.",[10,53,54,55,58],{},"Dr. Maxwell's CoinJoin has the problem of needing interactivity. Dr. Yuan Horas\nMouton fixed this by making transactions freely mergeable ",[37,56,57],{},"5",", but he needed to\nuse pairing-based cryptography, which is potentially slower and more difficult\nto trust. He called this \"one-way aggregate signatures\" (OWAS).",[10,60,61,62,65],{},"OWAS had the good idea to combine the transactions in blocks. Imagine that we\ncan combine across blocks (perhaps with some glue data) so that when the outputs\nare created and destroyed, it is the same as if they never existed. Then, to\nvalidate the entire chain, users only need to know when money is entered into\nthe system (new money in each block as in Bitcoin or Monero or peg-ins for\nsidechains ",[37,63,64],{},"6",") and final unspent outputs, the rest can be removed and forgotten.\nThen we can have Confidential Transactions to hide the amounts and OWAS to blur\nthe transaction graph, and use LESS space than Bitcoin to allow users to fully\nverify the blockchain. And also imagine that we must not pairing-based cryptography\nor new hypotheses, just regular discrete logarithms signatures like Bitcoin.\nHere is what I propose.",[10,67,68,69,48],{},"I call my creation Mimblewimble because it is used to prevent the blockchain from\ntalking about all user's information ",[37,70,71],{},"7",[10,73,15,74,20],{},[17,75,76],{},"\u002F\nConfidential Transactions and OWAS\n\u002F",[10,78,79],{},"The first thing we need to do is remove Bitcoin Script. This is sad, but it is too\npowerful so it is impossible to merge transactions using general scripts. We will\ndemonstrate that confidential transactions of Dr. Maxwell are enough (after some\nsmall modification) to authorize spending of outputs and also allows to make\ncombined transactions without interaction. This is in fact identical to OWAS,\nand allows relaying nodes take some transaction fee or the recipient to change\nthe transaction fees. These additional things Bitcoin can not do, we get for free.",[10,81,82],{},"We start by reminding the reader how confidential transactions work. First, the\namounts are coded by the following equation:",[84,85,90],"pre",{"className":86,"code":88,"language":89},[87],"language-text","C = r*G + v*H\n","text",[91,92,88],"code",{"__ignoreMap":93},"",[10,95,96],{},"where C is a Pedersen commitment, G and H are fixed nothing-up-my-sleeve elliptic\ncurve group generators, v is the amount, and r is a secret random blinding key.",[10,98,99,100,103],{},"Attached to this output is a rangeproof which proves that v is in ",[37,101,102],{},"0, 2^64",", so\nthat user cannot exploit the blinding to produce overflow attacks, etc.",[10,105,106],{},"To validate a transaction, the verifer will add commitments for all outputs, plus\nf*H (f here is the transaction fee which is given explicitly) and subtracts all\ninput commitments. The result must be 0, which proves that no amount was created\nor destroyed overall.",[10,108,109,110,114],{},"We note that to create such a transaction, the user must know the sum of all the\nvalues of r for commitments entries. Therefore, the r-values (and their sums) act\nas secret keys. If we can make the r output values known only to the recipient,\nthen we have an authentication system! Unfortunately, if we keep the rule that\ncommits all add to 0, this is impossible, because the sender knows the sum of\nall ",[111,112,113],"em",{},"his"," r values, and therefore knows the receipient's r values sum to the\nnegative of that. So instead, we allow the transaction to sum to a nonzero value\nk*G, and require a signature of an empty string with this as key, to prove its\namount component is zero.",[10,116,117],{},"We let transactions have as many k*G values as they want, each with a signature,\nand sum them during verification.",[10,119,120],{},"To create transactions sender and recipient do following ritual:",[122,123,124,128,135,142],"ol",{},[125,126,127],"li",{},"Sender and recipient agree on amount to be sent. Call this b.",[125,129,130,131,134],{},"Sender creates transaction with all inputs and change output(s), and gives\nrecipient the total blinding factor (r-value of change minus r-values of\ninputs) along with this transaction. So the commitments sum to r",[111,132,133],{},"G - b","H.",[125,136,137,138,141],{},"Recipient chooses random r-values for his outputs, and values that sum\nto b minus fee, and adds these to transaction (including range proof).\nNow the commitments sum to k",[111,139,140],{},"G - fee","H for some k that only recipient\nknows.",[125,143,144],{},"Recipient attaches signature with k to the transaction, and the explicit\nfee. It has done.",[10,146,147,148,151,152,154],{},"Now, creating transactions in this manner supports OWAS already. To show this,\nsuppose we have two transactions that have a surplus k1",[111,149,150],{},"G and k2","G, and the\nattached signatures with these. Then you can combine the lists of inputs and\noutputs of the two transactions, with both k1",[111,153,150],{},"G to the mix, and\nvoilá! is again a valid transaction. From the combination, it is impossible to\nsay which outputs or inputs are from which original transaction.",[10,156,157],{},"Because of this, we change our block format from Bitcoin to this information:",[122,159,160,163,166,169],{},[125,161,162],{},"Explicit amounts for new money (block subsidy or sidechain peg-ins) with\nwhatever else data this needs. For a sidechain peg-in maybe it references\na Bitcoin transaction that commits to a specific excess k*G value?",[125,164,165],{},"Inputs of all transactions",[125,167,168],{},"Outputs of all transactions",[125,170,171],{},"Excess k*G values for all transactions",[10,173,174],{},"Each of these are grouped together because it do not matter what the transaction\nboundaries are originally. In addition, Lists 2 3 and 4 should be required to be\ncoded in alphabetical order, since it is quick to check and prevents the block\ncreator of leaking any information about the original transactions.",[10,176,177],{},"Note that the outputs are now identified by their hash, and not by their position\nin a transaction that could easily change. Therefore, it should be banned to have\ntwo unspent outputs are equal at the same time, to avoid confusion.",[10,179,15,180,20],{},[17,181,182],{},"\u002F\nMerging Transactions Across Blocks\n\u002F",[10,184,185,186,189],{},"Now, we have used Dr. Maxwell's Confidential Transactions to create a noninteractive\nversion of Dr. Maxwell's CoinJoin, but we have not seen the last of marvelous Dr. Maxwell!\nWe need another idea, transaction cut-through, he described in ",[37,187,188],{},"8",". Again, we create a\nnoninteractive version of this, and to show how it is used with several blocks.",[10,191,192],{},"We can imagine now each block as one large transaction. To validate it, we add all the\noutput commitments together, then subtracts all input commitments, k*G values, and all\nexplicit input amounts times H. We find that we could combine transactions from two\nblocks, as we combined transactions to form a single block, and the result is again\na valid transaction. Except now, some output commitments have an input commitment exactly\nequal to it, where the first block's output was spent in the second block. We could\nremove both commitments and still have a valid transaction. In fact, there is not even\nneed to check the rangeproof of the deleted output.",[10,194,195,196,199],{},"The extension of this idea all the way from the genesis block to the latest block, we\nsee that EVERY nonexplicit input is deleted along with its referenced output. What\nremains are only the unspent outputs, explicit input amounts and every k",[111,197,198],{},"G value.\nAnd this whole mess can be validated as if it were one transaction: add all unspent\ncommitments output, subtract the values k","G, validate explicit input amounts (if there\nis anything to validate) then subtract them times H. If the sum is 0, the entire\nchain is good.",[10,201,202],{},"What is this mean? When a user starts up and downloads the chain he needs the following\ndata from each block:",[122,204,205,208,211],{},[125,206,207],{},"Explicit amounts for new money (block subsidy or sidechain peg-ins) with\nwhatever else data this needs.",[125,209,210],{},"Unspent outputs of all transactions, along with a merkle proof that each\noutput appeared in the original block.",[125,212,213],{},"Excess k*G values for all transactions.",[10,215,216],{},"Bitcoin today there are about 423000 blocks, totaling 80GB or so of data on the hard\ndrive to validate everything. These data are about 150 million transactions and 5 million\nunspent nonconfidential outputs. Estimate how much space the number of transactions\ntake on a Mimblewimble chain. Each unspent output is around 3Kb for rangeproof and\nMerkle proof. Each transaction also adds about 100 bytes: a k*G value and a signature.\nThe block headers and explicit amounts are negligible. Add this together and get\n30Gb -- with a confidential transaction and obscured transaction graph!",[10,218,15,219,20],{},[17,220,221],{},"\u002F\nQuestions and Intuition\n\u002F",[10,223,224],{},"Here are some questions that since these weeks, dreams asked me and I woke up sweating.\nBut in fact it is OK.",[10,226,227],{},"Q. If you delete the transaction outputs, user cannot verify the rangeproof and maybe\na negative amount is created.",[10,229,230,231,234],{},"A. This is OK. For the entire transaction to validate all negative amounts must have\nbeen destroyed. User have SPV security only that no illegal inflation happened in\nthe past, but the user knows that ",[111,232,233],{},"at this time"," no inflation occurred.",[10,236,237],{},"Q. If you delete the inputs, double spending can happen.",[10,239,240],{},"A. In fact, this means: maybe someone claims that some unspent output was spent\nin the old days. But this is impossible, otherwise the sum of the combined transaction\ncould not be zero.",[84,242,245],{"className":243,"code":244,"language":89},[87]," An exception is that if the outputs are amount zero, it is possible to make two that\n are negatives of each other, and the pair can be revived without anything breaks. So to\n prevent consensus problems, outputs 0-amount should be banned. Just add H at each output,\n now they all amount to at least 1.\n",[91,246,244],{"__ignoreMap":93},[10,248,15,249,20],{},[17,250,251],{},"\u002F\nFuture Research\n\u002F",[10,253,254],{},"Here are some questions I can not answer at the time of this writing.",[122,256,257,260,267],{},[125,258,259],{},"What script support is possible? We would need to translate script operations into\nsome sort of discrete logarithm information.",[125,261,262,263,266],{},"We require user to check all k",[111,264,265],{},"G values, when in fact all that is needed is that their\nsum is of the form k","G. Instead of using signatures is there another proof of discrete\nlogarithm that could be combined?",[125,268,269,270,273],{},"There is a denial-of-service option when a user downloads the chain, the peer can give\ngigabytes of data and list the wrong unspent outputs. The user will see that the result\ndo not add up to 0, but cannot tell where the problem is.",[271,272],"br",{},"For now maybe the user should just download the blockchain from a Torrent or something\nwhere the data is shared between many users and is reasonably likely to be correct.",[10,275,276,278,279,285,278,288,292,278,294,298,278,300,304,278,306,310,278,312,316,278,318,323,278,325],{},[37,277,39],{}," ",[280,281,282],"a",{"href":282,"rel":283},"https:\u002F\u002Fpeople.xiph.org\u002F~greg\u002Fconfidential_values.txt",[284],"nofollow",[37,286,287],{},"2",[280,289,290],{"href":290,"rel":291},"https:\u002F\u002Fbitcointalk.org\u002Findex.php?topic=279249.0",[284],[37,293,43],{},[280,295,296],{"href":296,"rel":297},"https:\u002F\u002Fcryptonote.org\u002Fwhitepaper.pdf",[284],[37,299,47],{},[280,301,302],{"href":302,"rel":303},"https:\u002F\u002Feprint.iacr.org\u002F2015\u002F1098.pdf",[284],[37,305,57],{},[280,307,308],{"href":308,"rel":309},"https:\u002F\u002Fdownload.wpsoftware.net\u002Fbitcoin\u002Fwizardry\u002Fhorasyuanmouton-owas.pdf",[284],[37,311,64],{},[280,313,314],{"href":314,"rel":315},"http:\u002F\u002Fblockstream.com\u002Fsidechains.pdf",[284],[37,317,71],{},[280,319,322],{"href":320,"rel":321},"http:\u002F\u002Ffr.harrypotter.wikia.com\u002Fwiki\u002FSortil%C3%A8ge_de_Langue_de_Plomb",[284],"http:\u002F\u002Ffr.harrypotter.wikia.com\u002Fwiki\u002FSortilège_de_Langue_de_Plomb",[37,324,188],{},[280,326,327],{"href":327,"rel":328},"https:\u002F\u002Fbitcointalk.org\u002Findex.php?topic=281848.0",[284],{"title":93,"searchDepth":330,"depth":330,"links":331},2,[],"md",null,{},true,"\u002Fdocs\u002Fcore-tech\u002Fmimblewimble-whitepaper-(june-2016)",{"description":12},"docs\u002Fcore-tech\u002FMimblewimble-Whitepaper-(June-2016)","mQL5mSR9mIlV2A6TbsodmbZuUw8KUqFFIMkGEJjpZU8",[341,346],{"title":342,"path":343,"stem":344,"description":345,"children":-1},"Merkle Trees","\u002Fdocs\u002Fcore-tech\u002Fmerkle-trees","docs\u002Fcore-tech\u002FMerkle-trees","BEAM uses various kinds of Merkle trees and proofs.",{"title":347,"path":348,"stem":349,"description":350,"children":-1},"Mining Difficulty","\u002Fdocs\u002Fcore-tech\u002Fmining-difficulty","docs\u002Fcore-tech\u002FMining-Difficulty","Mining difficulty is a measure of how many attempts on average it is required to find the proof-of-work solution required to mine a block and receive the mining reward.\nOne can define the Difficulty as the inverse probability of a random solution being the correct one. Thus, a difficulty of 100 means that one in 100 tries should produce a valid block in average.",1783006076660]