Mimblewimble: Private, Massively-PrunableBlockchains

Andrew Poelstra

grindelwald@wpsoftware.net

November 21, 2016

1 / 50

History

04:30 UTC, August 2nd, 2016: “Tom Elvis Jedusor” posts a.onion link to a text file on IRC, titled MIMBLEWIMBLE anddated July 19.

Next morning: myself and Bryan Bishop verify it’s actuallyjust text and rehost it.

Following week: discussion on Reddit with Greg Sanders andothers leads to understanding Mimblewimble’s trust model,and hints that the new crypto has merit.

September: myself and Avi Kulkarni develop an extension,“sinking signatures”, to greatly improve its scaling properties.

October 8th: released a paper showing Avi’s and my work forScaling Bitcoin Milan

2 / 50

History

04:30 UTC, August 2nd, 2016: “Tom Elvis Jedusor” posts a.onion link to a text file on IRC, titled MIMBLEWIMBLE anddated July 19.

Next morning: myself and Bryan Bishop verify it’s actuallyjust text and rehost it.

Following week: discussion on Reddit with Greg Sanders andothers leads to understanding Mimblewimble’s trust model,and hints that the new crypto has merit.

September: myself and Avi Kulkarni develop an extension,“sinking signatures”, to greatly improve its scaling properties.

October 8th: released a paper showing Avi’s and my work forScaling Bitcoin Milan

3 / 50

History

04:30 UTC, August 2nd, 2016: “Tom Elvis Jedusor” posts a.onion link to a text file on IRC, titled MIMBLEWIMBLE anddated July 19.

Next morning: myself and Bryan Bishop verify it’s actuallyjust text and rehost it.

Following week: discussion on Reddit with Greg Sanders andothers leads to understanding Mimblewimble’s trust model,and hints that the new crypto has merit.

September: myself and Avi Kulkarni develop an extension,“sinking signatures”, to greatly improve its scaling properties.

October 8th: released a paper showing Avi’s and my work forScaling Bitcoin Milan

4 / 50

History

04:30 UTC, August 2nd, 2016: “Tom Elvis Jedusor” posts a.onion link to a text file on IRC, titled MIMBLEWIMBLE anddated July 19.

Next morning: myself and Bryan Bishop verify it’s actuallyjust text and rehost it.

Following week: discussion on Reddit with Greg Sanders andothers leads to understanding Mimblewimble’s trust model,and hints that the new crypto has merit.

September: myself and Avi Kulkarni develop an extension,“sinking signatures”, to greatly improve its scaling properties.

October 8th: released a paper showing Avi’s and my work forScaling Bitcoin Milan

5 / 50

History

04:30 UTC, August 2nd, 2016: “Tom Elvis Jedusor” posts a.onion link to a text file on IRC, titled MIMBLEWIMBLE anddated July 19.

Next morning: myself and Bryan Bishop verify it’s actuallyjust text and rehost it.

Following week: discussion on Reddit with Greg Sanders andothers leads to understanding Mimblewimble’s trust model,and hints that the new crypto has merit.

September: myself and Avi Kulkarni develop an extension,“sinking signatures”, to greatly improve its scaling properties.

October 8th: released a paper showing Avi’s and my work forScaling Bitcoin Milan

6 / 50

History

At 23:47 UTC, October 20, “Ignotus Peverell” appeared onIRC announcing a project to implement MimbleWimble.

A few minutes later, Bryan Bishop called me to tell me to jointhe conversation. I pointed out that aggregate signatures givespace savings on top of the Voldemort scheme, even withoutnew crypto.

Other Harry Potter characters arrived over the next few weeks;the project continues to move forward. Though I’ve beeninvolved with the project, I have not contributed any code.

I am not Ignotus Peverell.

7 / 50

History

At 23:47 UTC, October 20, “Ignotus Peverell” appeared onIRC announcing a project to implement MimbleWimble.

A few minutes later, Bryan Bishop called me to tell me to jointhe conversation. I pointed out that aggregate signatures givespace savings on top of the Voldemort scheme, even withoutnew crypto.

Other Harry Potter characters arrived over the next few weeks;the project continues to move forward. Though I’ve beeninvolved with the project, I have not contributed any code.

I am not Ignotus Peverell.

8 / 50

History

At 23:47 UTC, October 20, “Ignotus Peverell” appeared onIRC announcing a project to implement MimbleWimble.

A few minutes later, Bryan Bishop called me to tell me to jointhe conversation. I pointed out that aggregate signatures givespace savings on top of the Voldemort scheme, even withoutnew crypto.

Other Harry Potter characters arrived over the next few weeks;the project continues to move forward. Though I’ve beeninvolved with the project, I have not contributed any code.

I am not Ignotus Peverell.

9 / 50

History

At 23:47 UTC, October 20, “Ignotus Peverell” appeared onIRC announcing a project to implement MimbleWimble.

A few minutes later, Bryan Bishop called me to tell me to jointhe conversation. I pointed out that aggregate signatures givespace savings on top of the Voldemort scheme, even withoutnew crypto.

Other Harry Potter characters arrived over the next few weeks;the project continues to move forward. Though I’ve beeninvolved with the project, I have not contributed any code.

I am not Ignotus Peverell.

10 / 50

What is Mimblewimble?

Mimblewimble is a design for a blockchain-based ledger that isvery different from Bitcoin.

It can be implemented as a sidechain, or softforked intoBitcoin (as an extension block).

In Bitcoin transactions, old outputs sign new outputs; outputshave “script pubkeys” that are independent of each other. InMimblewimble transactions, outputs have only EC pubkeys,and the difference between new outputs’ keys and old ones’ ismultisigned by all transacting parties.

Mimblewimble transactions are inherently scriptless.

11 / 50

What is Mimblewimble?

Mimblewimble is a design for a blockchain-based ledger that isvery different from Bitcoin.

It can be implemented as a sidechain, or softforked intoBitcoin (as an extension block).

In Bitcoin transactions, old outputs sign new outputs; outputshave “script pubkeys” that are independent of each other. InMimblewimble transactions, outputs have only EC pubkeys,and the difference between new outputs’ keys and old ones’ ismultisigned by all transacting parties.

Mimblewimble transactions are inherently scriptless.

12 / 50

What is Mimblewimble?

Mimblewimble is a design for a blockchain-based ledger that isvery different from Bitcoin.

It can be implemented as a sidechain, or softforked intoBitcoin (as an extension block).

In Bitcoin transactions, old outputs sign new outputs; outputshave “script pubkeys” that are independent of each other. InMimblewimble transactions, outputs have only EC pubkeys,and the difference between new outputs’ keys and old ones’ ismultisigned by all transacting parties.

Mimblewimble transactions are inherently scriptless.

13 / 50

What is Mimblewimble?

Mimblewimble is a design for a blockchain-based ledger that isvery different from Bitcoin.

It can be implemented as a sidechain, or softforked intoBitcoin (as an extension block).

In Bitcoin transactions, old outputs sign new outputs; outputshave “script pubkeys” that are independent of each other. InMimblewimble transactions, outputs have only EC pubkeys,and the difference between new outputs’ keys and old ones’ ismultisigned by all transacting parties.

Mimblewimble transactions are inherently scriptless.

14 / 50

Mimblewimble Transactions

A Mimblewimble transaction is the following data:

Inputs (references to old outputs).

Outputs: confidential transaction outputs (group elements,which blind and commit to amounts), plus rangeproofs.

Excess: difference between outputs and inputs (groupelement), plus signature (for authentication and to provenon-inflation)

15 / 50

Mimblewimble Transactions

A Mimblewimble transaction is the following data:

Inputs (references to old outputs).

Outputs: confidential transaction outputs (group elements,which blind and commit to amounts), plus rangeproofs.

Excess: difference between outputs and inputs (groupelement), plus signature (for authentication and to provenon-inflation)

16 / 50

Mimblewimble Transactions

A Mimblewimble transaction is the following data:

Inputs (references to old outputs).

Outputs: confidential transaction outputs (group elements,which blind and commit to amounts), plus rangeproofs.

Excess: difference between outputs and inputs (groupelement), plus signature (for authentication and to provenon-inflation)

17 / 50

Mimblewimble Transactions

18 / 50

Mimblewimble Transactions

19 / 50

Mimblewimble Transactions

20 / 50

Mimblewimble Transactions

21 / 50

Mimblewimble Blocks

Blocks consist of:

A merkle tree of transaction inputs.

A merkle tree of transaction outputs and rangeproofs.

A list of excess value(s) and signature(s)

22 / 50

Mimblewimble Blocks

Blocks consist of:

A merkle tree of transaction inputs.

A merkle tree of transaction outputs and rangeproofs.

A list of excess value(s) and signature(s)

23 / 50

Mimblewimble Blocks

Blocks consist of:

A merkle tree of transaction inputs.

A merkle tree of transaction outputs and rangeproofs.

A list of excess value(s) and signature(s)

24 / 50

Mimblewimble Transactions

25 / 50

Mimblewimble Transactions

26 / 50

Mimblewimble Transactions

27 / 50

Mimblewimble Transactions

28 / 50

Trust Model: Transactions

A transaction is valid if:

It is non-inflationary (total input amount equals total outputamount)

The owner of the input(s) has signed off on it.

29 / 50

Trust Model: Transactions

A transaction is valid if:

It is non-inflationary (total input amount equals total outputamount)

The owner of the input(s) has signed off on it.

30 / 50

Trust Model: Transactions

A transaction is valid if:

It is non-inflationary (total input amount equals total outputamount)

The owner of the input(s) has signed off on it.

31 / 50

Trust Model: Blockchain

It should be verifiable that

A transaction, once committed to a block, cannot be reversedwithout doing enough work to rewrite the block (and all itsdescendants).

The current state of all coins reflects zero net theft andinflation.

The exact historical sequence of transactions does not need tobe publicly verifable.

32 / 50

Trust Model: Blockchain

It should be verifiable that

A transaction, once committed to a block, cannot be reversedwithout doing enough work to rewrite the block (and all itsdescendants).

The current state of all coins reflects zero net theft andinflation.

The exact historical sequence of transactions does not need tobe publicly verifable.

33 / 50

Trust Model: Blockchain

It should be verifiable that

A transaction, once committed to a block, cannot be reversedwithout doing enough work to rewrite the block (and all itsdescendants).

The current state of all coins reflects zero net theft andinflation.

The exact historical sequence of transactions does not need tobe publicly verifable.

34 / 50

Trust Model: Blockchain

It should be verifiable that

A transaction, once committed to a block, cannot be reversedwithout doing enough work to rewrite the block (and all itsdescendants).

The current state of all coins reflects zero net theft andinflation.

The exact historical sequence of transactions does not need tobe publicly verifable.

35 / 50

Trust Model: Block Verification

It is possible to verify the blockchain with only the following data:

Block headers

Unspent outputs from each block

Excess values and signatures.

Rangeproofs for the above (witness data)

Full blocks near the tip should be kept to handle reorgs

In Bitcoin there are 150 million transactions and 40 millionunsigned transaction outputs: 21.6Gb of historic data, 2Gb ofUTXOs and 100Gb of UTXO rangeproofs.

36 / 50

Trust Model: Block Verification

It is possible to verify the blockchain with only the following data:

Block headers

Unspent outputs from each block

Excess values and signatures.

Rangeproofs for the above (witness data)

Full blocks near the tip should be kept to handle reorgs

In Bitcoin there are 150 million transactions and 40 millionunsigned transaction outputs: 21.6Gb of historic data, 2Gb ofUTXOs and 100Gb of UTXO rangeproofs.

37 / 50

Trust Model: Block Verification

It is possible to verify the blockchain with only the following data:

Block headers

Unspent outputs from each block

Excess values and signatures.

Rangeproofs for the above (witness data)

Full blocks near the tip should be kept to handle reorgs

In Bitcoin there are 150 million transactions and 40 millionunsigned transaction outputs: 21.6Gb of historic data, 2Gb ofUTXOs and 100Gb of UTXO rangeproofs.

38 / 50

Trust Model: Block Verification

It is possible to verify the blockchain with only the following data:

Block headers

Unspent outputs from each block

Excess values and signatures.

Rangeproofs for the above (witness data)

Full blocks near the tip should be kept to handle reorgs

In Bitcoin there are 150 million transactions and 40 millionunsigned transaction outputs: 21.6Gb of historic data, 2Gb ofUTXOs and 100Gb of UTXO rangeproofs.

39 / 50

Trust Model: Block Verification

It is possible to verify the blockchain with only the following data:

Block headers

Unspent outputs from each block

Excess values and signatures.

Rangeproofs for the above (witness data)

Full blocks near the tip should be kept to handle reorgs

In Bitcoin there are 150 million transactions and 40 millionunsigned transaction outputs: 21.6Gb of historic data, 2Gb ofUTXOs and 100Gb of UTXO rangeproofs.

40 / 50

Trust Model: Block Verification

It is possible to verify the blockchain with only the following data:

Block headers

Unspent outputs from each block

Excess values and signatures.

Rangeproofs for the above (witness data)

Full blocks near the tip should be kept to handle reorgs

In Bitcoin there are 150 million transactions and 40 millionunsigned transaction outputs: 21.6Gb of historic data, 2Gb ofUTXOs and 100Gb of UTXO rangeproofs.

41 / 50

Next Steps

Development, development, development!

Nail down chain parameters

Sidechain / asset support

More crypto ;)

42 / 50

Next Steps

Development, development, development!

Nail down chain parameters

Sidechain / asset support

More crypto ;)

43 / 50

Next Steps

Development, development, development!

Nail down chain parameters

Sidechain / asset support

More crypto ;)

44 / 50

Next Steps

Development, development, development!

Nail down chain parameters

Sidechain / asset support

More crypto ;)

45 / 50

Open Problems

Unconditionally sound commitments and rangeproofs

Smaller rangeproofs? Aggregation of rangeproofs?

Peer-to-peer protocol that can handle transaction merging

Quantum resistance

46 / 50

Open Problems

Unconditionally sound commitments and rangeproofs

Smaller rangeproofs? Aggregation of rangeproofs?

Peer-to-peer protocol that can handle transaction merging

Quantum resistance

47 / 50

Open Problems

Unconditionally sound commitments and rangeproofs

Smaller rangeproofs? Aggregation of rangeproofs?

Peer-to-peer protocol that can handle transaction merging

Quantum resistance

48 / 50

Open Problems

Unconditionally sound commitments and rangeproofs

Smaller rangeproofs? Aggregation of rangeproofs?

Peer-to-peer protocol that can handle transaction merging

Quantum resistance

49 / 50

Thank You

Andrew Poelstra <grindelwald@wpsoftware.net>

50 / 50