VeriBlock Adopts SegWit (And Will Now Take More Space on Bitcoin)
The VeriBlock team is very excited to release an alpha SegWit-enabled PoP miner! Source code is available here and precompiled binaries are available here. Big thanks to BitcoinJ for recently adding SegWit support which made releasing a SegWit-enabled PoP miner possible.
Given the alpha status of the miner, please only deposit very small amounts of BTC. We are actively working on robustivity and stability improvements to address some hiccups encountered by volunteer community testers when running the SegWit PoP miner in testnet mode over the last few days.
Using SegWit, individual PoP transactions consume less “space” (weight) on Bitcoin, meaning each individual PoP transaction will be less expensive. In normal conditions, SegWit (bech32) PoP transactions will be ~28.9% less expensive than their standard-transaction counterparts. Paradoxically, this means that VeriBlock will actually take a larger portion of the actual on-disk Bitcoin blockchain, and the same amount of in-block “weight.” If you’re curious about why this is (or how SegWit works in general), keep reading!
For those unfamiliar with VeriBlock and Proof-of-Proof: The Proof-of-Proof (“PoP”) consensus protocol allows any blockchain to inherit the full Proof-of-Work security of Bitcoin in an entirely Decentralized, Trustless, Transparent, and Permissionless (“DTTP”) manner. PoP introduces a new form of mining wherein PoP miners compete for rewards by performing “security transactions” where they publish fingerprints of a PoP-secured blockchain to another blockchain to inherit its security. The VeriBlock blockchain uses PoP to secure itself to Bitcoin, and acts as a security aggregation layer, allowing other blockchains to inherit Bitcoin’s security in the most easy, cost-effective, and secure manner possible. You can learn more at our community website, on our Discord, or by reading our whitepaper. You can also follow us on Twitter and LinkedIn for project updates.
What is SegWit?
Every transaction on Bitcoin carries two separate pieces of information: the effects of the transaction, and the proof of validity.
The transaction’s effects are what the transaction does (such as moving coins), and the proof of validity proves that the sender(s) authorized the transaction (input scripts are satisfied, often with correct signatures and matching public keys).
On the surface, the raw data for a standard BTC transaction and a full SegWit transaction look fairly similar (displayed transactions are PoP transactions on Bitcoin testnet, standard: cbd3d090e8f9d12ee29e339e15db646c8d8f8e26f95fd8f5e564018df80bee95 SegWit: c0db6d91213b44d3fb0c56121eea2c1a1fe892dc7eb41c214b1255fa7a8c2a7b):
Bytes in blue are related to witnessing the transaction (in both of the above examples a signature and public key which allow the sender to successfully spend the prescribed input comprise the witness data).
We can see that the position of the witness data is different in the SegWit transaction, and there are two other fields immediately after the version in the SegWit transaction (Marker and Flag) which aren’t present in the standard transaction.
The difference between the two becomes much more apparent when we look at the filtered version of the SegWit transaction though:
The filtered SegWit transaction is all that ends up in the base Bitcoin block; the filtered witness data is stored separately (or more accurately, is “authenticated” differently by the block hash, and counted differently towards the total block “weight”). The following visual explains why SegWit transactions take up less data in the base Bitcoin block, and thus result in lower fees:
Rather than being limited to 1 MB (1,000,000 B) of block size (as was the rule prior to SegWit), post-SegWit-activation miners are limited to 4,000,000 vB (“virtual bytes” or “weight units”), where each scaffolding/transaction effect/legacy witness byte counts at 4 vB, and each witness byte in a SegWit transaction counts as 1 vB.
As a result, transactions which use SegWit count less towards a miner’s block weight allowance than transactions which don’t use SegWit. The end result is that the “same” transaction (transaction with the same effects) costs less when using SegWit inputs.
A common SegWit misunderstanding is that SegWit transactions are smaller. SegWit transactions are actually roughly the same size as their non-SegWit counterparts, but their witnesses are counted differently towards the block weight limit.
It should be noted that SegWit transactions also have additional benefits that are beyond the scope of this article, such as preventing signature malleability which makes payment-channel technology (like Lightning) easier to implement and more secure to use.
VeriBlock + SegWit = Larger Bitcoin Blocks?
As discussed in the previous section, SegWit transactions pay lower fees than their non-SegWit counterparts because SegWit transactions consume less of a Bitcoin miner’s weight allowance.
For VeriBlock specifically, a normal non-SegWit PoP transaction takes up ~284 bytes (or 1,136 weight units). A SegWit (using bech32 addresses) PoP transaction takes up the same ~284 bytes, but 110 of them are witness bytes, so the transaction only consumes 808 weight units (184 non-witness bytes and 110 witness bytes; 184*4+110=808). As a result, the SegWit PoP transaction can pay ~28.9% lower total fees. You can see this in action by counting the witness and non-witness bytes in the example SegWit PoP transaction (filtered vs unfiltered) in the previous section.
Let’s review what we know so far:
· PoP miners using SegWit can perform a PoP transaction cheaper
· Despite being less expensive, a SegWit PoP transaction still uses the same number of on-disk bytes
Most users of Bitcoin demand a particular amount of effects on the Bitcoin blockchain (ex: an exchange has a particular number of withdrawals to process per day). In this case, these Bitcoin users still consume the same on-disk (and on-network) amount of data when using SegWit because their transactions aren’t any smaller. However, their transactions each consume less weight, so they pay lower fees. As a result, more total effects from other users can now fit in the block, and the particular Bitcoin user paid less because they consumed less total block weight.
This is because PoP mining doesn’t demand a particular quantity of effects (like a total number of OP_RETURNs per day), but rather splits a bounty amongst every participant who performs one of the effects (publishing VeriBlock blockchain fingerprint data to Bitcoin) during a particular time period. As a result of the decreased fees, PoP miners will send more PoP transactions in the same time period, in aggregate consuming approximately the same number of weight units as before. The favorable anti-censorship and decentralization incentivization properties of this reward schedule are beyond the scope of this article but are covered extensively in our whitepaper.
In some cases, SegWit PoP mining will actually consume more weight units than its non-SegWit alternative. For example, if the bounty offered by VeriBlock is enough to afford 5,000 vB at PoP-relevant priority, then non-SegWit PoP mining would afford 4 PoP transactions of 1,136 vB each for a total of 4,544 vB, but SegWit PoP mining would afford 6 PoP transactions of 808 vB each for a total of 4,848 vB (more vB consumed with SegWit than without). A rough analogy: you can usually consume more of your total trunk space when packing in smaller bags.
In summary: Using SegWit, VeriBlock PoP miners will still use the same amount of weight in each Bitcoin block, and will use more on-disk space, because each weight unit they purchase corresponds to more on-disk bytes than before. SegWit does however improve the decentralization of PoP mining by enabling more PoP miners to participate at a given per-unit-time VeriBlock security budget, and allows PoP miners to continue to afford sufficient PoP transactions for VeriBlock to maintain Bitcoin-level security in higher Bitcoin fee markets than before.