What is Segwit?
Will it truly allow for Bitcoin to scale
for mass adoption?
And how does it even work?
Well stick around,
in this episode
of Crypto whiteboard Tuesday
we’ll answer these questions and more.
Hi, I’m Nate Martin
and welcome to
Crypto Whiteboard Tuesday
where we take complex
break them down
and translate them into plain English.
Before we begin,
don’t forget to subscribe to the channel
and click the bell
so you’ll immediately get notified
when a new video comes out.
Today’s topic is Segregated Witness,
or Segwit for short.
Segwit is an upgrade
to the Bitcoin network
that was activated in August of 2017.
It was first introduced
by Developer Pieter Wiulle
at the Scaling Bitcoin conference
in December 2015.
Segwit aims to solve several issues:
one of which is Bitcoin’s scalability.
Bitcoin transactions are written
on a Blockchain,
an immutable ledger
on which transactions
are bundled together into blocks
that are chained one to the other,
in order to determine their order.
A new block is created
roughly every 10 minutes.
Bitcoin’s protocol limits
the capacity of a block to 1mb,
which limits a Bitcoin block to around
2700 transactions on average.
This creates a problem
when a lot of people are trying
to send Bitcoins simultaneously
as the queue of transactions
waiting to enter the blockchain
gets longer and longer..
While Visa can process
1,700 transactions per second,
Bitcoin can process only 4,
not nearly a scale that could handle
In order for Bitcoin to truly
become usable on a worldwide scale,
it needs to find a way to increase
its transaction capacity.
Another issue Segwit addresses
is transaction malleability.
Every Bitcoin transaction has 3 parts –
who sent it (also known as input),
who receives it (output),
and a digital signature
that verifies that the sender
is eligible to send the coins.
It turns out that Bitcoin’s code
allows digital signatures to be altered
while a transaction is still
waiting to get confirmed.
The signature alteration
can be done in such a way that
if you run a mathematical check on it,
it is still valid according to the network.
But if you run
a hashing algorithm on it,
it gives a different result.
Let me explain with an example:
For the sake of simplicity
let’s say that
the signature value was “3”,
but instead of “3”
I change it to “03” or “3+7-7”.
the values are all the same,
so it’s still a valid signature,
if I hash these different versions
I will get different results,
since hashing depends on
how you write the value
and not just the value itself.
Since the hash is the transaction’s id
in the blockchain,
this means I can effectively change
any unconfirmed transaction’s id
to a different id
and it will still be valid.
Creating a new transaction id
for an existing transaction
can be problematic
for a number of reasons:
First, if you want to build
second layer solutions
on top of the Bitcoin network,
like the Lightning Network,
you need to make sure
no one can alter the first layer
since the one relies on the other.
If you want to learn more
about the Lightning Network
make sure to catch our episode
about it as well.
Second, altering transaction ids
can cause issues
if you’re spending or accepting
Let’s go through another example:
Alice pays Bob in transaction X
which is currently unconfirmed.
Bob uses these unconfirmed funds
to pay for a product online
from Charlie (transaction Y).
Meanwhile, Charlie sends Bob
before waiting for confirmation
on transaction Y.
After receiving his product,
Bob does some technical tinkering,
and maliciously changes,
or malleates, Alice’s payment
so that her transaction,
X gets confirmed
but with a different transaction id.
which is what Bob sent to Charlie,
is now invalid
since it relies on transaction X’s
original transaction id
that now no longer exists.
So Charlie won’t get paid
even though he’s already delivered
the goods to Bob.
While scalability and malleability
are the two most burning issues
that Segwit addresses,
there are a variety of other
that Segwit tackles
that don’t necessarily affect
the end user directly.
Now that you know what Segwit is,
let’s talk a bit about
how it actually works.
is a proposed change
to how blocks are structured.
Non segwit blocks,
also known as legacy blocks,
have a total of 1mb space
for all of the block data:
inputs, outputs, signatures
and additional scripts.
Segwit blocks, on the other hand,
are in fact large 4mb blocks
that consist of a base transaction block
and an extended block.
So contrary to popular opinion,
Segwit is indeed a block size increase.
Segwit blocks move the digital signature
and other data known as “the witness”
outside of the base transaction block.
The witness data
will still be transmitted,
but it is placed inside the extended block.
So the base transaction block includes
the information about the sender
and the receiver
and the witness data is left blank
and doesn’t take up any more space.
This allows for more transactions
to fit inside
the 1mb base transaction block.
The extended block (the additional 3mb)
include all of the witness data
that isn’t mandatory
in the base transaction block.
The new block format
achieves two major goals:
First, it moves the digital signature
outside of the base transaction block.
if someone changes the signature
on the transaction,
it won’t affect the transaction id.
This in effect solves
the transaction malleability issue….
Second, it shrinks down
the base transaction data.
Since the witness data takes up to
65% of the transaction size,
moving it outside of
the base transaction block
allows more transactions
to fit inside that 1mb block.
I know what you’re probably thinking.
If Segwit is in fact
a block size increase,
why not just increase the block size
to 4mb in the first place?
Why all of this hassle
and block size debate
if the end result is in fact bigger blocks.
The answer is really quite simple –
developers wanted to avoid
a contentious hard fork
in the Bitcoin network.
You see, Bitcoin’s protocol
specifically states that
blocks can’t exceed 1mb.
So, developers had to find a solution
that will allow the network to accept
both Segwit and Non Segwit blocks
if a hard fork were to be avoided.
The solution of a 1mb block
with an “extension” of another 3mb
is something that is still acceptable
under the existing protocol.
Legacy nodes receive
only the 1mb base transaction block
without the extended block.
They still consider them valid.
Segwit nodes receive
both the base and extended block
(up to 4mb in total)
and can validate
the transactions in full.
This backwards compatibility
is also known as a soft fork.
This approach is a lot less risky
since it doesn’t require nodes to update
their software to support Segwit.
It means that even if it takes years
for all of the nodes to upgrade,
the network will still function.
Now let’s move on to how
Segwit blocks are measured by miners.
While legacy blocks
are measured in size,
Segwit blocks are measured in weight.
Block Weight is a new concept
introduced in Segwit,
and it’s calculated
on a per-transaction basis.
Each transaction has a “weight”
which is defined this way:
The size of your Base Tx
(meaning that which doesn’t include
the witness data) *3
+ the Full Tx size,
that=your transaction weight.
don’t have the ability to strip away
the witness data from the base transaction,
so their weight will always be
4 times the tx size.
For example, a legacy TX of 1000 bytes
will have a weight of 1000*3 + 1000
Segwit transactions, on the other hand,
are going to have a weight of less than
4 times the tx size.
a 1200 byte Segwit transaction
comprised of 400 bytes of witness data
will have a weight of
(1200 (the total transaction size)-400
(the size of the witness data))
leaving the base transaction size of 800,
add the total transaction size of 1200,
the larger the size of the witness data,
the lighter the tx weight will be.
This incentivizes miners
to prefer ‘lighter’ Segwit transactions
over ‘heavier’ ones,
since they can fit more of them
inside a base transaction block,
which increases the potential miner’s fee,
should that block be accepted
While in theory Segwit transactions
can create a block up to 4mb in size,
in practice the average block size
that includes Segwit transactions
is around 2mb.
Today, almost 50% of
all Bitcoin transactions
are Segwit transactions.
Since legacy transactions
are larger in size,
they require higher network fees
to get confirmed faster.
Segwit addresses start with a “3”
while legacy addresses start with a “1”.
Thanks to its advantages,
more and more popular wallets
and exchanges support Segwit.
Ledger, TREZOR, Electrum,
Exodus and Coinomi
are just some of the major
that have already adopted Segwit.
It’s important to note that
if you have a legacy wallet
and you want to move
to a Segwit wallet
you will need to create
a brand new Segwit wallet
and move all of your funds
to its address.
There’s no way to just upgrade
your existing legacy wallet
to work with Segwit.
Segwit is the first of many upgrades
that will gradually allow for Bitcoin
to scale for mass adoption.
It’s a fundamental change
that will allow further developments
down the road
like the Lightning Network,
Schnorr Signatures and more.
As more and more wallets
it will soon become the standard
for any Bitcoin transaction.
Well, that’s it for today’s episode
of Crypto Whiteboard Tuesday.
Hopefully by now you understand
what Segwit is –
An upgrade to the Bitcoin protocol
that Segregates the witness data
from the base transaction data,
hence achieving a smaller
from malleability issues and more.
You may still have some questions.
If so, just leave them
in the comment section below.
And if you’re watching this video
and enjoy what you’ve seen,
don’t forget to hit the like button.
Then make sure to subscribe
to the channel
and click that bell
so that you’ll be notified
as soon as we post new episodes.
Thanks for watching me
here at the Whiteboard.
I’m Nate Martin,
and I’ll see you…in a bit.