Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Segregated witness and deploying it for Bitcoin

No description
by

Pieter Wuille

on 7 December 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Segregated witness and deploying it for Bitcoin

Segregated Witness for Bitcoin
Pieter Wuille
Scaling Bitcoin, Hong Kong, 7 december 2015
Bitcoin transactions
Inputs
Outputs
Inputs
Outputs
Inputs
Outputs
TXID
Signatures
Amount
Amount
Script
Script
All equally needed?
Signatures are only for fully validating nodes
Do not ever enter the UTXO set, so no long-term resource costs.
60% of the blockchain
For now, just refers to the scriptSig in inputs
Segregated Witness is about ignoring them where possible
Not part of a transaction's effect, only proving it
was authorized.
Multiple possible, but we just care that one exists.
Such an example is called a witness.
Assume we can redesign Bitcoin from scratch?
Signatures are part of the hash
Inputs
Outputs
TXID
Amount
Amount
Script
Script
Signature
TXID
Signature
= Witness data
Block header
Merkle tree of txn and witness
Tampering
Advantages?
Drop signatures from relay



Prune old signatures



Solves all unintentional malleability
BIP62?
We can't...
This seemed hard
Inputs
Outputs
Inputs
Outputs
Amount
Amount
Script
Script
{v "Script"}
TXID ""
Signature
Witness
Soft fork scaling
Block header
Coinbase
Simulation:
What old nodes see
Script versions!
Instead of pushing the redeem script directly, add a version byte
An unknown version byte is treated as anyone can spend
All future Script changes become soft forks!
No longer restricted to redefining OP_NOP opcodes
We can immediately use that mechanism to allow pushing the hash of the redeem script instead
Fraud proofs
Currently, Bitcoin only has two security models:
* Full validation
* Header validation ("SPV")

The Bitcoin whitepaper suggested using fraud proofs
Bitcoin currently has no way to compactly prove subsidy fraud or spending non-existing output
* Add input value and UTXO creation location to witness

A proposal
Implement segregated witness now:
* Discount witness data by 75% for block size
* Or: block limit to 4 MB, but only for witness (soft fork!)
* Disincentivizes UTXO impact
* Fixes malleability
* Enables far simpler script upgrades
* Enables fraud proofs
* Allows pruning witness data for historical data
* Reduces bandwidth for light nodes and historical sync
* P2SH compatible for old senders
* Give time for IBLT and weak blocks to develop

Intend for a hard fork change near future:
* Switch to a cost-based metric
* Limited time cost growth
* Give time for higher level payment systems to develop

Thank you
Future work:
* Finish prototype implementation
(https://github.com/sipa/bitcoin/segwit)
* Write BIP




Thanks to: Gregory Maxwell, Eric Lombrozo, Luke Dashjr


BIP62?
Full transcript