Topic: SegWit: Segregated Witness (Read 303 times)
Awesome. I finally gasp some understanding why there is the need for that segwit to be implemented. Although it's not going to really solve the problem as we are all going to face Malleability problem in the future. How easy can it be done to stole some btc by changing tiny pieces of transaction information and has anyone actually did it?
DEFINITION OF TERMS
Merkle Tree
Merkle Tree
- A Merkle tree is a hash-based data structure that is a generalization of the hash list. It is a tree structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. Typically, Merkle trees have a branching factor of 2, meaning that each node has up to 2 children. Merkle trees are used in distributed systems for efficient data verification. They are efficient because they use hashes instead of full files. Hashes are ways of encoding files that are much smaller than the actual file itself. Currently, their main uses are in peer-to-peer networks such as Tor, Bitcoin, and Git.
SEGREGATED WITNESS
[1] What is SegWit
- The idea for SegWit was first introduced by Pieter Wuille at a Bitcoin conference in 2015. Wuille is a Bitcoin developer and the co-founder of Blockstream, a software company which specializes in digital security for financial services.
- Wuille suggested SegWit as a solution to a flaw in the Bitcoin protocol. In software development, solutions to flaws are called patches. The problem he wanted to fix is called transaction malleability. Transaction malleability is a nerdy way of saying that Bitcoin can be stolen from users by changing tiny pieces of transaction information.
- Wuille’s SegWit proposal caused a big debate in the Bitcoin community and it was nearly two years before it went live. It was finally activated on August 23, 2017. The same patch was applied to the Litecoin protocol on May 10, 2017.
- Segregated Witness (abbreviated as SegWit) is an implemented protocol upgrade intended to provide protection from transaction malleability and increase block capacity. SegWit defines a new structure called a witness that is committed to blocks separately from the transaction Merkle tree. This structure contains data required to check transaction validity but is not required to determine transaction effects. In particular, signatures and redeem scripts are moved into this new structure, which does not count towards the traditional 1 MB block size limit. Instead, a new weight parameter is defined, and blocks are allowed to have at most 4 million weight units (WU). A byte in the original 1 MB zone of the block weighs 4 WU, but a byte in a witness structure only weighs 1 WU, allowing blocks that are technically larger than 1 MB without a hardforking change.
- Segwit is a scaling solution meant to solve Bitcoin’s blockchain size limitations by allowing more transactions to be added in each block thereby increasing Bitcoin transaction speeds. The trick involves splitting a transaction into two segments, moving the unlocking signature (“witness” data) from the original segment to a “witness” segment
- Segwit is not a permanent solution to Bitcoin's scaling problem, but in theory, it would double the current capacity. If the network continues to grow then the same congestion issues will eventually be encountered again.
The Problems
- The signature is bulky and takes up to 65% of space and there is only limited space available in the block this, filled up the block rather quickly with information which is not that useful in the long term
- the signature date is vulnerable to manipulation which may cause transaction malleabilty
- Transaction Malleability
-Another property of SegWit is "transaction malleability". Even though every transaction is cryptographically signed, the signature doesn't encompass all transaction data. Many people consider this a flaw because a user can potentially change a transaction ID. This could lead to extra bitcoin being sent if a user claims they never received the bitcoin and the sender checks the original transaction ID to verify (which would not exist on the blockchain if the ID was changed).
The reasons malleability was introduced are because it enables signatures to be added after the transaction is created (which is necessary for Lightning Network), and because it reduces the transaction size by 65%
- Scalability
-A new block is added to the chain at random intervals averaging, by design, ten minutes (proof-of-work causes this delay). Together with the limit on block-size, this limits the number of transactions that can be processed in a given time. Some sites work around this problem using "off-chain payments", conducting transactions without waiting for confirmation by the bitcoin network. Others have proposed changes to bitcoin that would reform the blockchain format in a backwards-incompatible way. For example, FlexTrans (Flexible Transactions) would make transactions smaller by changing how they are described as a "tag" system, allowing more transactions per block. This is not compatible with systems that do not upgrade.
The Solution
- SegWit proposes significant backward compatibility. It hides its increased block size by changing the definition of a block to be measured as one million "units" instead of bytes. The signature data called the witness would be separated from the Merkle tree record of who is sending or receiving the bitcoins. The witness data is moved to the end, and each byte of it would only count as one-quarter of a "unit". The overall effect would be changing the average block size to about 1.8 MB instead of This means the existing Bitcoin protocol doesn't change, allowing it to work without as much upgrading of software
It also addresses signature malleability, by moving signatures out of the transaction data, making them impossible to change. The transaction ID is no longer malleable. This makes Bitcoin safer to use with Lightning Network, a way to speed up small payments by bundling them and only writing to the blockchain at the beginning and end of their execution, which would be (slightly) risky while the malleability problem still exists.
The Benefits
- Weighting data based on how it affects node performance
- Signature covers value
- Linear scaling of sighash operations
- Increased security for multisig
- More efficient almost-full-node security
- Script versioning
The Pros And Cons
PROS
- Increases the number of transactions that a block can take.
- Decreases transaction fees.
- Reduces the size of each individual transaction.
- Transactions can now be confirmed faster because the waiting time will decrease.
- Helps in the scalability of bitcoin.
- Since the number of transactions in each block will increase, it may increase the total overall fees that a miner may collect
- Removes transaction malleability.
- Aids in the activation of the lightning protocol.
CONS
- Miners will now get lesser transaction fees for each individual transaction.
- The implementation is complex and all the wallets will need to implement segwit themselves. There is a big chance that they may not get it right the first time.
- It will significantly increase the usage of resources since the capacity, transactions, bandwidth everything will increase.
- As the creation of Bitcoin Cash shows, it did ultimately split up the Bitcoin Core community.
- Another problem with Segwit is the maintenance. The sidechain containing the signature data will need to be maintained by miners as well. However, unlike the main blockchain, the miners have no financial benefits on doing so, it will need to be done pro-bono or some reward scheme needs to be thought of to incentivize the miners.
Sources:
Source 1
Source 2
Source 3
Source 4
Source 5
Source 6
Source 7
Source 8
Source 9
Jump to: