Presentation held at Pisa Bitcoin Meetup about the implementation of segregated witness and bitcoin scaling debate. I collected public available material from many different sources so I couldn't credit all of them, I mentioned only the biggest ones.

1. Pisa Bitcoin Meetup
Segregated Witness and Bitcoin Scaling Debate
Diego Dal Canto
Navacchio 24 Luglio 2017

2. Credits
• Coindesk
• Cointelegraph
• Bitcoin Magazine
• We use coin
• Bitcoin wiki

3. Agenda
• Bitcoin transactions
• Bitcoin Improvement Proposals
• Segregated witness
• The scaling debate

7. Input

8. Output

9. There are no bitcoins, only records of bitcoin transactions
Instructions on how to
unlock the input, only the
owner can generate it
The sender creates a new lock that only the receiver can unlock
proving that he owns the private key corresponding to his public key
and generating a new scriptSig

10. Stack Script Description
Empty.
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash>
OP_EQUALVERIFY OP_CHECKSIG
scriptSig and scriptPubKey are combined.
<sig> <pubKey>
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY
OP_CHECKSIG
Constants are added to the stack.
<sig> <pubKey> <pubKey>
OP_HASH160 <pubKeyHash> OP_EQUALVERIFY
OP_CHECKSIG
Top stack item is duplicated.
<sig> <pubKey> <pubHashA> <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG Top stack item is hashed.
<sig> <pubKey> <pubHashA>
<pubKeyHash>
OP_EQUALVERIFY OP_CHECKSIG Constant added.
<sig> <pubKey> OP_CHECKSIG Equality is checked between the top two stack items.
true Empty. Signature is checked for top two stack items.
Transaction confirmation

11. Transaction malleability
• The ability of someone to change (mutate) unconfirmed transactions without making them
invalid, which changes the transaction’s txid, making child transactions invalid.
• Although the modifications are non-functional—so they do not change what inputs the
transaction uses nor what outputs it pays—they do change the computed hash of the
transaction.
• Since each transaction links to previous
transactions using hashes as a transaction
identifier (txid), a modified transaction will not
have the txid its creator expected.
• This isn’t a problem for most Bitcoin transactions
which are designed to be added to the block
chain immediately. But it does become a problem
when the output from a transaction is spent before
that transaction is added to the block chain.

12. Segregated witness
• Signatures are not transmitted as part of the
transaction
• They are transmitted alongside the transaction in a
separate data structure:
• Nodes that wish to validate transactions can chose to do so
(download and store the witness repository)
• Nodes that do not wish to validate transactions can choose
to do so as well (do not need to download data)
• Discovered in 2015 that this could be implemented as a
Soft Fork by Bitcoin Core and Blockstream developer
Pieter Wuille

13. Benefits of Segregated witness
• Separations of signatures from transactions fixes transaction malleability
• Once a transaction is included in a block, the signature is irrelevant (can save up
to 75% of blockchain)
• Miners will want to get transactions with witness in order to maintan
consistency, nodes instead can better scale the blockchain since signatures only
need to be validated when a transaction is first presented for inclusion on the
blockchain. No need to carry it around by nodes that are not interested in
validating the transaction further
• Up until now block version and transaction version have been used, not the
script language version. Segwith introduces the ability to upgrade the scripting
language (script versioning) enabling new features like confidential transaction
adding a fully fungible transaction layer

14. Protocol upgrade, soft and hard forks
In a pure distributed system no actor has
the full control
• Users (give value/use)
• Miners (chose which coin to mine)
• Developers (guide the debate)
• Nodes (decide which client to run)
• Exchanges (create markets)
Set of rules
Example:
Old Blocksize limit 1 MB
New Blocksize limit 0.5 MB
• Old versions accept new ones
• Protocol upgrade
Example:
Blocksize limit 1 MB
New Blocksize limit 2 MB
• Old versions do not accept
new ones
• Protocol replacement
• Currency split risk

15. A system designed to be hard to control

16. How to upgrade a software in a fully distributed network?
BIP = Bitcoin Improvement Proposal
• BIP141 = The current implementation of Segregated Witness. BIP141 is activated through the activation method defined by
BIP9. This means that 95% of all blocks within a two-week period need to include a piece of data: “bit 1.” This indicates that
a miner is ready for the upgrade. As such, SegWit would be activated if the vast majority of miners are ready for it.
• BIP148 = User Activated Soft Fork, On August 1st, anyone running Bitcoin software that implemented BIP148 will start
rejecting all blocks that do not include bit 1, the SegWit signalling data. If BIP148 is not supported by a majority of miners
(by hash power), Bitcoin’s blockchain could split in two. In that case, there would effectively be two types of Bitcoin, where
one activated BIP148 and the other did not. This may resolve over time — or it may not
• SegWit2x = Is the scaling agreement reached by a number of Bitcoin companies and over 80 percent of miners (by hash
power), drafted just before the Consensus 2017 Conference. SegWit2x would only require 80 percent of support, moreover
its readiness would be signaled using another piece of activation data: “bit 4” instead of “bit 1.”
• BIP91 = Is a proposal by engineer James Hilliard which was specifically designed to prevent a coin-split by making SegWit2x
and BIP148 compatible. Upon activation of BIP91, all BIP91 nodes will reject any blocks that do not signal support for
SegWit through bit 1. As such, if a majority of miners (by hash power) run BIP91, the longest valid Bitcoin chain will consist
of SegWit-signaling blocks only, and all regular BIP141 SegWit nodes will activate the protocol upgrade. Where BIP91 differs
from BIP148 is that it doesn’t have a set activation date, but is instead triggered by hash power. BIP91 nodes will reject any
non-SegWit signalling blocks if, and only if, 80 percent of blocks first indicate within two days that’s what they’ll do. This
indication is done with bit 4. If this is done before August 1st, it’s also compatible with BIP148, since BIP148 nodes would
reject non-bit 1 blocks just the same.

21. How consensus is measured

22. Developes
The corporate takeover of bitcoin in one commit

23. Users / Bitcoin Companies
A P2P protocol for cheap transactions, seriously?

24. Node clients

25. Node clients
Bitcoin Unlimited
Overview
Bitcoin Unlimited is a fork of the Bitcoin Core
reference client with the intention of providing a voice
to all stakeholders in the Bitcoin ecosystem. The
project seeks to remove existing practical barriers to
stakeholders expressing their views in these ways.
Protocol Scaling Plan
• BUIP001 Fixed block limit made obsolete
• BU follows the blockchain with most PoW as per
the original Nakamoto Consensus
• Separation of the mining block size (default 1MB)
from the non-mining block acceptance size (default
16MB)
• Block size limits and acceptance depth individually
configurable
Bitcoin Core
Overview
Bitcoin Core (formerly Bitcoin-Qt) is the third
Bitcoin client, developed by Wladimir J. van der
Laan based on the original reference code
by Satoshi Nakamoto. It has been bundled with
bitcoind since version 0.5. Bitcoin-Qt has been
rebranded to Bitcoin Core since version
0.9.0.54
Protocol Scaling Plan
SegWit + Lightning Network, Schnorr
signatures, MAST.
Bitcoin UASF
Overview
Clone of Bitcoin Core for user activation of the Segwit
softfork

26. UASF: the Independence day

27. Miners

28. Miners

29. Block signaling

30. Block signaling