I'm a little late to this thread, but FYI the reason that the doc uses a MIT license rather than a "documentation license" is that the document itself is code. It is written in PostScript and can be edited or viewed with a text editor (in case you want to verify e.g. that the volvelles or tables were computed correctly).

I have proposed a rewrite of BIP-322 on the ML:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018313.html

Full text (also included in the ML post, but rendered here)

https://github.com/apoelstra/bips/blob/2020-12--bip322-overhaul/bip-0322.mediawiki

tiagocs, pooya87, I think it's important that BIP322 work with arbitrary scripts, for the reasons that gmax has stated. But I also agree that BIP322 is written currently to require very heavy machinery (basically, linking to libbitcoinconsensus to do absolutely anything, and goes out of its way to expose sharp edges of Script. For example, allowing non-low-S signatures and then requiring verifiers to mark this as "inconclusive" appears to serve no purpose.

I wonder if you would support a version of BIP322 which:

1. Required all standardness rules be obeyed (and allowed as an "extension" to validate such signatures, somewhere cordoned off at the end of the BIP where nobody needs to see it)
2. Specified what these standardness rules were/meant
3. Allowed implementations to return "inconclusive" for scripts they did not understand, while still permitting them to implement only templates if they really want.
4. Cleaned up the prose a bunch

The first two rules would let you use off-the-shelf Minscript software (such as this implementation in Python to support all widely used scripts except HTLCs, so even if you did not write a full BIP-322 verifier (which would require libbitcoinconsensus or Core) you would still be able to support a wide array of real-world usecases.

Unless you have specific information to the contrary, I'd assume the Bitcoin Core repo is more accurate than the wiki, regardless of timestamps.

Have you heard of sidechains?

Not to detract from the main point, but if you were implementing this multiplication yourself, using the "powers of two" ladder is a bad idea for security reasons. Specifically, for each 1 bit in your secret key you're adding 2^i*G, while for each 0 bit you're not doing anything. Somebody timing your algorithm could easily determine how many powers of 2 you added, i.e. how many bits in your secret key are 1.

In general, you want to use a multiplication algorithm that never puts secret data into if-conditionals [1] or into array indices [2][3]. It is possible to efficiently do this, which I think is actually even more surprising than the fact that you can do the multiplication in sublinear time.

One such algorithm, though by no means the most efficient one, is as follows (a special case of [4], unless I screwed it up):

1. Compute x' = (x + 2^256 - 1)/2 mod the secp256k1 curve order. The bits of this number have a special property: if you interpret all the 0's as -1's, they also represent the original secret key x. See [5], top of page 9.
2. Compute G, -G, 2G, -2G, 4G, -4G, ..., 2^256G, -2^256G and put them in an array P.
3. Compute the sum of { x_i'*P[2*i + 1] + (1 - x_i')*P[2*i] } over each bit x'_i of x'.

[1] "Don't branch on secret data" is folklore, I don't have a citation for it.
[2] https://cryptojedi.org/peter/data/chesrump-20130822.pdf
[3] http://www.tau.ac.il/~tromer/papers/cache.pdf
[4] https://github.com/bitcoin-core/secp256k1/pull/546
[5] https://eprint.iacr.org/2012/309.pdf

There are OTS libraries for Python, Java, Javascript and Rust. See https://opentimestamps.org/#code-repositories

I count four transactions in what you described.

You can do adaptor-signature based atomic swaps in Bitcoin without Schnorr; see https://eprint.iacr.org/2018/472 which has a full security proof (and security model, which is a nontrivial thing to define for transitive atomic swaps). Adaptor signatures can be used to make arbitrary sets of transactions atomic; and to even add transactions to these sets after the protocol has started. They are definitely not restricted to pairwise exchange, though in practice I expect you'll find it's hard to coordinate much else.

It is not possible to do a cross-chain atomic swap with only two transactions because you need at least one transaction on each chain, and the first transaction on each chain can be invalidated by publishing a conflicting transaction alongside it.

This is false. Where did this idea come from?


What does "probably relatively benign" mean in cryptographic terms?


Why is this?

What is your idea? There is a good chance you can just build it on top of Bitcoin or some other existing project.

Creating an entirely separate currency to implement some technical improvement is a lot of work, entails significant legal risk and moral hazard, and will hamper users' ability to use your system trustlessly.

MimbleWimble is just a technology; the blockchain which is supporting its own currency is called "grin" (similar to CryptoNote vs Bytecoin except without the scam surrounding it). I really wish these wouldn't be conflated in the public eye, but the reporting seems to do it quite a bit.

Regarding moving away from Bitcoin, I proposed a scheme to the grin developers by which they can softfork in a Bitcoin peg onto their chain (using Confidential Assets it can cheerfully support its own currency alongside pegged bitcoins alongside whatever, they don't affect each others' security but they do share a privacy set) which they seemed quite enthusiastic about.


There has been a lot of research and development happening in the Mimblewimble space lately, but it's extremely fast moving and there hasn't been a lot of writing about it. You can follow the mimblewimble-dev mailing list for some of it, but unfortunately the non-boring stuff been largely happening in meatspace. A short list of developments since this thread was started

• ability to support multiple asset types
• my proposal to have a testcoin alongside the native currency and to support softforking in a bitcoin peg once the bitcoin side is figured out, as well as pegs from other currencies (including blinded-amount pegs from CA-supporting chains)
• the realization that amiller's idea for blinded exponents could be used to efficiently add many "denominations" to each asset, allowing shrinking their rangeproofs with much less of a privacy hit than we'd originally expected
• the realization that we could attach some forms of scripting to mimblewimble after all
• the realization that for many things we could get script functionality with much better privacy and without any changes to the Voldemort design at all and this would be uncensorable because it would result in normal looking transactions
• oh, and we can Lightning this way
• oh, and this doesn't have much to do with MW at all, any blockchain that supports schnorr signatures will allow these uncensorable efficiently verifiable hyper-private contracts which include atomic swaps between the chains
• more to come on this front, still iterating and working out details...
• realization that Ruffing and Moreno-Sanchez's ValueShuffle is compatible with Mimblewimble+Confidential Assets allowing coinjoin where the original transactions never hit the network so nobody can record them and PS it compresses Mimblewimble's already-cool "one signature per transaction" to "one signature per aggregate transaction" which is way better and will incentivize people to use the tech, improving their privacy

and I'm sure there's other stuff I'm forgetting.

Alpha is using a third-party federation which processes peg-outs (though the details of this are purely mechanical, it is not too hard to write software that verifies that the federation is doing exactly what it is supposed to and no more). Peg-ins are done by Alpha's consensus code, though I don't know the details of this well enough to point you to the code.

We were a bit worried about this point of confusion when we used the word "peg" in the sidechains whitepaper, but it was the cleanest word we could come up with. You're right that in the finance world, a peg between two different assets requires some authority to maintain the peg (and they do so basically by fighting every market movement, at cost to themselves). This is how sidechains work on a technical level, but not on a moral one.

A sidechain peg is not between two separate currencies, like Ethereum and Bitcoin. It is between the same currency on different blockchains. For example, there is a testnet sidechain, Elements Alpha, out there. You can distinguish between "testnet coins on the testnet chain" and "testnet coins on Alpha", and these are technically distinct entities, but every coin on Alpha is 100% backed by a locked coin on testnet, and using the peg mechanism you can swap a testnet coin on Alpha for one of its backing coins on testnet. So there can't be market movements of the coins on one chain relative to the other, except up to time-preference since the peg is slow, otherwise people will arbitrage out any price difference using the peg.

Unfortunately it would probably be reasonable to expect that every unmerged transaction was visible to surveillance companies (although CT does still protect the amounts). Although I'm sure services would pop up that take in transactions, merge them, then publicize them after merging (and it'd be so easy to set up such a service that they wouldn't all be in cahoots or NSA-controlled).

Can you describe these risks?

I did not suggest that "pruning doesn't happen" in the paper. Again, can you describe these risks? What do you mean by "who pays who"? Ignoring the question of associating people to outputs when all outputs are uniformly random curvepoints, how does one even associate the outputs with the inputs?

That's correct, this is me. But MW does not support using static addresses like this, it is required for people to send me money that I interact with them, and then why would I use the same keys if I have to interact anyway?

Why would they loop through themselves? If they want to take all the fee they can do that in one shot. Then good luck for them trying to relay the transaction further with no remaining fee.

Bitcoin right now has abysmal privacy properties, and yet even these don't seem have helped in tracking down the executor of the BFX heist. (Perhaps this will change, of course, it is still early days.) It certainly is not going to help getting the money back. In general, people who want to do illegal things are able to be anonymous about it, often taking huge losses in the process -- maybe it costs you 50% to launder money, but if you stole all the money in the first place, this is acceptable. Meanwhile people who are just trying to live their lives cannot afford to be taking huge haircuts all the time, don't get the anonymity that criminals can afford, and wind up being screwed by the poor privacy properties of whatever payment system they're using.


There is an old article by Mike Hearn called merge avoidance which describes many reasons that financial privacy is important for ordinary people. For businesses the consequences are even more severe; you cannot run a business with entirely public accounts.

Add as others have said, "you don't get to choose what things you need to hide".


See my above comment about criminals already being able to hide their activity, since they value this more and have more money to burn.


It is already possible to delete all historic data in Bitcoin and track only the unspent outputs. You will not be able to help others join the network with full security, and you would not've be able to join the network yourself without validating this data. But it hardly seems ridiculous on its face that it could be validated more cheaply than downloading all of it.

It does not. Can you say more about why you think this? The paper explicitly addresses why inflation remains impossible.

The paper does not talk about removing blocks at all. Did you read it?

Are you familiar with confidential transactions? This is an existing technology that has been in use on the sidechain Elements Alpha for over a year now, and is exactly what the MW paper uses.

This is largely addressed by the use of OWAS and CT, which again is discussed in the paper itself. (Note that MW's mechanism for doing OWAS is novel and not related to the one in that link.)

Can you paste an address that will allow me to learn the blockchain's chainstate with full security and without complete history, while also hiding its transaction graph even from people who have the full blocks? If not, can you say how somebody would make one?

Because MimbleWimble doesn't support Bitcoin script, it supports far less functionality than Bitcoin and isn't a viable upgrade path for Bitcoin itself.

Having said this, it certainly makes sense that MW should be a sidechain, given that huge amounts of Bitcoin's use is for simple "move money from party X to party Y" transactions, which MW does support. I've been thinking that I might work on this if I can find some spare time. Aside from finding time and people, here is a short list of things I think need to be solved before this could be done:

• Further review (though I'm increasingly comfortable with the idea). This means somebody needs to do a proper writeup (I might do this in the coming days); I will try to present this at Scaling Bitcoin in Milan to increase its exposure, assuming the real author doesn't appear and that my submission is accepted.
• Payment channel support. I think I have a way, but it involves unprunable blockchain data whenever a CLTV branch is taken, which is annoying. Should be possible to do better.
• Figuring out a bunch of fiddly stuff. Like, because input refs can be completely pruned, they should count for more blockspace than outputs, which can only be pruned when spent, which in turn should count for more blockspace than these excess "kG" values, which can never be pruned.
• Going through the engineering work to spec out the UX for payments; paying requires both sender and receiver to produce data. So should everything happen through a payment protocol? Can we finally get rid of user-visible "addresses"? How should payment channels/Lightning interact with this? Multisig requires interaction among all parties even to receive money, how should this work?
  
• I want to spend more time trying to shrink the unprunable data. This can be done interactively, so maybe there is some engineering/UX work that'd make that easy? It can also be done with pairing-based crypto, maybe we should evaluate that option?

This is really exciting stuff, but the paper that was deaddropped by the anonymous author unfortunately leaves a lot of work to get to an actual implementation.

Good idea, I might add some tables usable for wNAF.

And you can extend my coordinates to Jacobian by simply adding a third `1` coordinate to everything .

How much precomputation are you willing to do? Is it OK to use a computer for this? Note that you can verify this multiple ways (by patching some quick-and-dirty code into libsecp, and using sage are my go-tos) and that the precomputation will have nothing to do with your secret key at all, so you can also ask outside parties to verify.

Depending on your answer, this might not be too crazy, and you could do it in less than a day per pubkey. Here's one scheme:

0. As others have mentioned, the public key is derived from the secret key by means of x → x*G, where x, your secret key, is a 256-bit number, G is a standard generator of the secp256k1 elliptic curve, and * means repeated addition of G to itself by the elliptic curve group addition formula.

0a. The formula can be found on Wikipedia and here. I recommend you understand the wikipedia formula algebraically, then go to that link to find more computationally efficient schemes. In particular you'll want to use a coordinate system that lets you avoid doing any modular inversion, because that's a bear to do by hand. (You will eventually need to do this, because the final form needs to be in affine coordinates, but you can put it off to the end instead of doing it at every step.)

0b. The formulae that libsecp256k1 uses are in this Sage script, which if you run, will also check that they are actually algebraically equivalent to the cleaner formula found on wiki and elsewhere. libsecp's computational goals (avoid inversions, strongly prefer addition to multiplication) are similar enough to a human's goals that it's probably faster to just use these than to go researching better ones.

0c. The formulae for doubling and adding distinct points are different. You'll need to double to do the precomputation, but never afterward. So that will simplify your life a bit.

Ok, the actual scheme:

1. Take your secp256k1 generator G, and compute G, 2G, 3G, ..., 15G. Then compute each of these times 16, times 16^2, times ..., times 16^63. (This isn't as bad as it looks since each generation can be gotten from the last by multiplying by 16 again.) To multiply by 16, double 4 times. This is a total of 15×64 = 960 points you need to precompute. Now, I'm not in your head, but I really think your ghosts will allow you to do this using computers, since it's independent of your secret and you can do it multiple ways.

1a. I think it would be funny for the libsecp project to sell books with these precomputed tables, like the books of logarithms that sailors used to use. It's a quick job in sage and LaTeX, if I still think it's funny by the end of this post I'll make a PDF.

2. Now, take your secret key in hex-encoding. This is a base 16 encoding, something like x = a + b*16 + c*16^2 + ... and so on, where all of a, b, c, are between 0 and 15 inclusive. There will be 64 digits, some of which (four of them, on average) are zero. So you can write x*G = (a + b*16 + c*16^2 + ...)*G = a*G + b*16*G + c*16^2*G.

2a. Here's the cool part: the 0*G's you can ignore. Everything else that's multiplied by G in the above formula is in your precomputed table. So you'll have (at most) 64 points that you simply look up, and you have to add them together. 63 additions. To do this in 24 hours, you'd have to do each one in a bit under 23 minutes. This is plausible, but I couldn't do it.


By increasing the size of your precomputed table you can reduce the work from 64 points, but the table gets much bigger. (To halve your work, you roughly have to square the size of the table.) To add 32 points, you'd need 8160 precomputed points; for 16 points you'd need a bit over a million; for 8 it's 35 billion ... for 1 you'd need to write out literally every single point.)


Edit: Here, I have done the precomputation for you. You want page 38, base 16 digits. https://download.wpsoftware.net/bitcoin/todl.pdf