all 43 comments

[–]boxhit 7 points8 points  (1 child)

Watching this is like reading a book and skipping dozens of pages. I need to watch it again.

[–]throckmortonsign 9 points10 points  (0 children)

As someone that did a good job keeping up with developments until about when mimblewimble was proposed, it's pretty much impossible now unless it's your job. I'm now having to rely more on people I know know their stuff, which is less than ideal. Privacy developments (while also maintaining scalability) are the single most important factor in making cryptocurrency a truely new asset class. I'm glad we are starting to get there.

[–]xiphy 7 points8 points  (2 children)

I was excited to hear about the Bulletproofs presentation from Benedikt because the paper was very hard to read for me, but in this talk he actually said the easy parts and skipped the interesting parts :(

[–]benediktb 9 points10 points  (1 child)

I hope that at some point I'll be able to give a recorded technical talk on this explaining the details of the protocol. For this audience it felt more appropriate to highlight its properties and applications.

[–]xiphy 4 points5 points  (0 children)

Thanks, I'd love a series starting from Greg's confidential transactions, as the text there is a bit too informal, and though your paper is awesome, it is a bit too formal with maybe less explanations than what I would like. Juat going through just the definitions of various classes of algorithms and comparing to the Wikipedia articles took a lot of time for me.

I know it's hard stuff generally but as it's clearly the future of Bitcoin I feel it's crutial that many of us understand the details.

Anyways thanks for the hard work!

[–][deleted]  (12 children)


    [–]nopara73[S] 13 points14 points  (9 children)

    Bulletproofs improves upon Confidential Transactions a lot. To the point where it is already practical to deploy it into Bitcoin.
    Taking a step back: CT masks the amount of transactions, which basically is the source of all evil and complexity in every Bitcoin privacy technique.

    [–]Auwardamn 4 points5 points  (7 children)

    I wouldn’t necessarily say “already practical”. While it reduces the size of the transactions, it doesn’t reduce their complexity and thus more powerful CPUs are required. But definitely viable within a decade.

    [–]DesignerAccount 4 points5 points  (5 children)

    Didn't he say if you batch txs you can actually outperform current BTC verification for the same number of non-aggregating txs? I think it should become more efficient with 7-8txs... Did I get that wrong?

    [–]RubenSomsen 4 points5 points  (1 child)

    He did say that, but that was a mistake, see here (batching is taken into account).

    [–]DesignerAccount 2 points3 points  (0 children)

    Got ya, thanks!

    [–]Auwardamn 2 points3 points  (0 children)

    I believe he is talking about outperforming from a memory standpoint. Sorry, I’m at work I can’t watch the video.

    Here’s a comment from /u/nullc who would be able to answer that far better than I can. I have a satellite’s level view of it from a conceptual standpoint.

    [–]benediktb 2 points3 points  (0 children)

    The newest number indicate that bach verifying bulletproofs is between 0 and 4 times slower than verifying an ECDSA signature. That definitely brings it in the realm of practicality. We'll post an update to the paper tomorrow.

    [–]andytoshi 1 point2 points  (0 children)

    There seems to be some confusion on this. Sorry about that -- we found the optimization, swagged its speed, added it to the talk at the very last minute, and only implemented it a couple days later. We wouldn't have added something so immature to a public talk except that the benefit was really really big.

    1. The time to verify ECDSA on our test system (my laptop, an i7-7820HQ throttled to 2.00Ghz) is about 86us. Not 800 as listed in the talk.
    2. The 200us number was a conservative estimate, but based on my initially overestimating the extent of the optimization. I would've said 500us had I not made this mistake. Our tests show 470us. We have a further optimization in the pipeline that I think will get this down to 400us.
    3. Benedikt later pointed out that the batch verification speed grows only logarithmically[*] in the size of the aggregate. So an aggregate of 2 rangeproofs takes 570us, or 290us per range. An aggregate of 16 takes 730us, or 180us ... so we do get the 200us number, you just have to be working on aggregate rangeproofs :).
    4. In fact if we go up to 32-range aggregates, the batch cost drops to 2.58ms, or 80us per range... beating (non-batch!) ECDSA. So there is a sense in which you can verify a range in a bulletproof faster than you can validate a signature.

    On my laptop without throttling all of these numbers are about 60% as large. All of them are single-core measurements; we haven't implemented a parallel version of our efficient multiexp code. The old rangeproofs in the same setup take about 8.5ms per 64-bit proof. So even the 500us number is a 17x speed improvement. 80us, which we can expect during IBD or when verifying a Provisions proof, is over 100x.

    The verification memory usage is trivial, under a kilobyte of memory per proof in a batch (plus whatever precomputed tables you have for the standard group generators). The old rangeproofs were also trivial.

    [*] Everything eventually grows linearly, since you have to at least read all of the input data. So when I say things like "grows logarithmically" or "grows like N/log(N)" I mean only for reasonably low batch sizes, like <10000, after which the otherwise-trivial linear components start to dominate.

    [–]logical 7 points8 points  (0 children)

    Bulletproofs are a new mathematical technique that has been discovered which can bring compact, fast and trust-less confidential transactions to bitcoin.

    It was worked on by some of the very best people in the crypto space.

    [–]nopara73[S] 2 points3 points  (8 children)

    Do I hear this right /u/andytoshi ? Did you just made (yesterday) verifying bulletproofs faster than ECDSA??!

    [–]RubenSomsen 8 points9 points  (7 children)

    Unfortunately he was incorrect. It is 5-7 times slower.

    RubenSomsen | andytoshi: I just finished watching Bulletproofs from BPASE '18. Am I understanding correctly that batch validation of bulletproofs brings validation time below that of ECDSA? That is huge.

    sipa | RubenSomsen: no, benedikt was wrong about how fast ECDSA was

    sipa | it's around 5-7 times slower to verify a bulletproof than ecdsa (when there are many proofs to verify in parallel)

    andytoshi | RubenSomsen: i will give a talk about this at a milan bitcoin meetup (i think), and hopefully i'll have better numbers by then in a couple days

    From #bitcoin-wizards

    [–]nullc 5 points6 points  (5 children)

    The comment in the talk was wrong, but the point being made was right. The talk said ecsda was 800us and the bulletproof was 400us.

    In actuality ECDSA is ~80us. HOWEVER, a batch validation of many aggregates can hit a marginal cost of around ~80us per 64-bit range added. So the point that it could be as fast as (unbatched) ECDSA is still true.

    [–]RubenSomsen 2 points3 points  (4 children)

    Thanks for the clarification. Let me see if I understand it right:

    • Unbatched bulletproofs: 4ms
    • Unbatched ECDSA: 800us
    • Batched bulletproofs: 400us
    • Batched ECDSA: 80us

    So batched bulletproofs are roughly 2x faster than unbatched ECDSA, but 5x slower than batched ECDSA.

    Edit: these numbers are off, see here.

    [–]nullc 4 points5 points  (3 children)

    • 64bit bulletproof: 470us
    • Unbatched ECDSA: 80us
    • Batched validation of N 32-range aggregated 64-bit proofs: 81us per range. (but with a pretty high constant cost for the first one, of about 62ms).
    • Batched ECDSA: 40us per signature (ECDSA can't technically be batch verified without two additional bits of data which are not present in signatures, but if it could be it would be about twice the speed in sufficiently large batches).

    The point is not really that they're similarly fast-- but rather if we believe that the unbatched validation used in Bitcoin and clone systems today is little enough cpu time to be viable, then since batched BP validation would only be a couple times more its plausible that it's also a viable amount of computation.

    We're also still finding speedups for bulletproofs, they're much newer and we've had less time to come up with clever ways to optimize the crap out of them compared to signatures. :)

    [–]RubenSomsen 2 points3 points  (2 children)

    little enough cpu time to be viable

    We're also still finding speedups for bulletproofs

    Thanks for the updated numbers. What has been achieved thus far is absolutely amazing. I would love to see CT come to bitcoin, though I am still undecided on whether I am comfortable with bulletproofs not being perfectly binding.

    [–]nullc 7 points8 points  (1 child)


    Right. Well at least we know for sure that nothing space efficient will ever be... so it's not like waiting might give us everything we could possibly want. :)

    I expect that for many other reasons CT would need to be optional ... so you could imagine that the system could track the total funds into CT and out from CT (or maybe even total funds into a connected CT subgraph and out of it); so then at least any risk of break would be carried only by the last out of the funds that stay in it. It need not carry any risk for others, and in that sense thats perhaps the best we really could ask for-- after all, people have the option of using insecure signatures.

    [–]RubenSomsen 1 point2 points  (0 children)

    the system could track the total funds into CT and out from CT [...] so then at least any risk of break would be carried only by the last out of the funds that stay in it

    Hmm yeah, that would shield the non-CT users from potential inflation.

    You're assuming that people get out before an attack occurs, right? I imagine the theoretical quantum attacker could take all the funds in a single transaction. It'd be an appealing first target.

    [–]somewhat_irrelevant -3 points-2 points  (16 children)

    I believe it benefits society that transaction amounts are visible to the public. I also would like to see the people undertaking transactions if it is possible. If i had to pick between the two, I would prefer it if the people transacting were revealed and the transaction amounts were hidden from everyone. I wouldn't be willing to invest in bitcoin if it was completely anonymous because the people who would benefit would be mostly criminals and corporations.

    [–]nullc 7 points8 points  (8 children)

    Not having CT doesn't make amounts actually visible. Data is not knowledge. Someone who wants to hide their amounts can do so, at a cost to them by splitting into many transactions and whatnot.

    What efficient privacy schemes do is also give privacy to people who aren't up to no good, and wouldn't pay to get privacy in other ways.

    [–]somewhat_irrelevant 0 points1 point  (7 children)

    I don't think splitting into many transactions would stop someone from figuring out what you are doing right now.

    [–]nullc 7 points8 points  (6 children)

    How many Bitcoin do I own, exactly?

    [–]somewhat_irrelevant 0 points1 point  (5 children)

    Idk. i can't look up your wallet. Why?

    [–]nullc 7 points8 points  (4 children)

    That is my the point. because wallets are in a zillion little parts, knowing even something about it often won't tell you much about the rest.

    [–]somewhat_irrelevant 0 points1 point  (3 children)

    but if you pay someone for something using multiple wallets then I can see that on their wallet

    [–]nullc 8 points9 points  (2 children)

    No you can't. Every payment uses different addresses-- if you're using a wallet that has only address then it is dangerously incompetent and you should stop using it ASAP.

    [–]somewhat_irrelevant 0 points1 point  (1 child)

    So e.g. my deposit address for LTC is LSjUMNs8N56RMFVcN6CUtUQWfBteScT3NX and I can look up and see that 4 LTC have been sent to this address. Is there something wrong with using this address multiple times? If you're trying to hide a transaction by using multiple addresses that receive bitcoin, then I would imagine that you'd need to request multiple addresses from the person you are sending the coins

    [–]midmagic 2 points3 points  (0 children)

    No. Technically you can give a single address to someone and they can pay to multiple addresses.

    [–]jbaum517 4 points5 points  (0 children)

    It has pros, yes, but I believe the cons outweigh the pros here. Privacy is something only corporations and whales have. The people deserve that too. There are also functions like paying salary that not everyone would want to be public.

    Andreas Antonopoulos has talked about the importance of getting more privacy into BTC a few times before in his talks recently.

    [–]bearCatBird 2 points3 points  (5 children)


    I think we can be more specific.

    It benefits society for transactions to be visible in cases where shared money and transparency are concerned.

    It benefits individuals for transactions to be confidential in cases where privacy between two consenting people is concerned.

    Basically, confidentiality for individuals, transparency for governments.

    [–]somewhat_irrelevant -1 points0 points  (4 children)

    Can you provide some examples of when it benefits individuals to have their financial transactions hidden?

    [–]jbaum517 3 points4 points  (2 children)

    Paying salaries over BTC is a pretty easy example to think of off the top of my head..

    [–]somewhat_irrelevant -2 points-1 points  (1 child)

    But you should know your coworkers' wages... Not knowing benefits the corporation, not you. There's laws that allow you to discuss your wages with your coworkers for that reason.

    [–]jbaum517 2 points3 points  (0 children)

    Being allowed to talk about it doesn't mean that people want to share it.. for example, I don't own a company or anything, but I wouldn't want my co-workers to know what I make. They can compare to each other if they'd like.

    [–]bearCatBird 1 point2 points  (0 children)

    Privacy in all aspects of a human's life is necessary for both

    1. a well functioning community (people need to be able to control information flow between themselves and others in order to maintain relationships)

    2. and for healthy individual psychology (people need space to keep aspects of themselves private, otherwise you hinder their ability to take risks and express themselves)

    Money and the human transactions it facilitates are a form of expression and an integral part of both aspects I listed above.