This article is the second part of the XSN blockchain architecture. It’s focused on the benefits of the SegWit activation.
For the first part of the XSN blockchain architecture: click here. The first article is focused on the stakenet blockchain metrics.
1.3 Benefits of a Bitcoin.core blockchain architecture
Because XSN is based on Bitcoin.core, all the achievements of Bitcoin development, like SegWit and the Lightning Network, can be integrated in the Stakenet blockchain architecture without much effort.
1.3.1 SegWit
Segregated Witness, so called SegWit, is the name used for an implemented soft fork change in the transaction format of the Bitcoin.core blockchain architecture, to include a variety of functions. Because most of them are very technical, the following pages will summarize the benefits of all these features for the Stakenet ecosystem. It should be noticed, that SegWit is much more than just a solution for the scaling problem — SegWit is the smallest common denominator for any cross chain communication. This sum up is based on BIP 140, 141, 143 and the current Bitcoin.core.
1.3.1.2 Linear scaling of sighash operations
In some transactions the signature hashing tends to scale more quadratically than linearly, depending on how these are structured. By just doubling the block size of a transactions, you would consequently also double the amount of data that needs to be hashed for the verification — which may cause an extremely longer validation time within the block generation process, especially then some of these large transactions are designed maliciously. Segwit solves this problem by adjusting the calculation of the transaction hash for signatures, by removing the quadratic scaling of hashed data for verifying signatures. Due this change each byte of a transaction never needs to be hashed more often than two times — so the same functionality is achieved much more efficiently.
Benefit: By removing the quadratic scaling of hashed data for the verification signatures, also large transactions can be generated in the Stakenets meta network without facing the previous difficulties with the signature hashing, even if those transactions are lager or generated maliciously.
1.3.1.2 Signing of input values
Before Segwit was enabled, a hardware wallet needed a full node copy of all input transactions to verify the total amount being spent and sign the transaction. Thus, it was also necessary to hash all those data to ensure, that no false data were fed, so executing withdraws from a hardware devise was not particularly cheap. SegWit solves this problem by only hashing the input value explicitly which makes it easier and safer for a wallet so sign the spending transaction, no matter how large or complicated it is.
Benefit: Hardware wallet user need to pay less transaction fees for executing secure and fast withdraws. Keep in mind, Stakenet will provide its own multicurrency hardware wallet in Q4 2018.
1.3.1.3 Increased security for multisig
Without SegWit, multisig payments were protected due a pay-to-script-hash (P2SH), which is secured by the 160bit hash (HASH160) algorithm. However, this encryption can be violated by a well-resourced attacker, who tries to find a collision address due brut forcing. SegWit prevents this fraudulent act by using HASH160 only for payments, directly to one single public key, while using an improved 256bit hash for the P2SH.
Benefit: This feature of the SegWit implementation will ensure extra security for everyone paying to a multisig address or smart contract within the Stakenet network or the cross chain ecosystem.
1.3.1.4 Script versioning
Every change to the Bitcoin.core script was developed to ensure improved security and improved functionality. However, the script design only enables backwards-compatible changes, caused by soft-forking, to be implemented, by replacing one of the ten extra OP_NOP opcodes with a new one. This procedure is sufficient for most changes — but it is slightly hacky (for example, OP_CLTV usually needs to be accompanied by an OP_DROP) and cannot be used to enable such simple features as joining two strings. Therefore, SegWit implements version number for scripts to enable even opcodes that would have required a hard-fork to be used in non-SegWit transactions, just by increasing the script version.
Benefit: Making changes to script opcodes easier, will cause an advanced scripting in all Bitcoin.core based blockchain architectures — so supporting sidechains or creating even smarter contracts by using Merklized Abstract Syntax Trees (MAST) can be achieved much easier by Stakenet.
1.3.1.5 Reducing UTXO growth
The unspent transaction output (UTXO) database is maintained by each fullnode of a blockchain to review whether a new transaction is valid or fraudulent. To ensure a fast an efficient network, this database needs to be very quick to query and modify. This challenge becomes even harder, the more users are using the blockchain, because every new user needs to have at least one individual UTXO entry. SegWit improves the situation by adjusting the signature data that way, that the UTXO group size is reduced by at least 75%.
Benefit: By reducing the UTXO size, the maintenance and the query of the UTXO database are reduced, which will counteract future limitations or performance problems and improves the current situation for everyone who runs a fullnode within the Stakenet ecosystem.
1.3.1.6 Efficiency gains when not verifying signatures
Bitcoin.core based blockchains do not check signatures for transactions prior to the most recent checkpoint by default. Furthermore, even some SPV clients don’t check signatures themselves at all, because they trust the validation by other nodes. However, the signature data is an essential proportion of the entire transaction. Due SegWit every node, that is not interested in signature data, can skip those data, to avoid downloading it to save resources.
Benefit: Because more transactions are proceeded using SegWit addresses, everyone who is running a pruned or SPV node in the Stakenet network, needs less bandwidth and disk space to operate.
1.3.2 Lightning
One of the main objectives of introducing cryptocurrency was to make payment processing faster and cheaper. However, as mining operations started to become expensive, transaction fees for Bitcoin also started raising. A version of the technology that is meant to make cryptocurrency payments faster and cheaper, called Lightning Network, is a second layer solution to enable off-chain transactions on Bitcoin.core based blockchains and is expected to be a game changer in the evolution of the crypto currency. By solving the transaction malleability problem, SegWit eliminates a major barrier to implement such a second-layer solution, like the Lightning Network, on top of a blockchain. The second-layer dependents upon the underlying architecture of each blockchain, using their native smart-contract scripting languages to allow for a massive increase in the network capacity by moving the bulk of transactions off chain for quick processing. Once it is deployed across all nodes, the network will speed up transaction processing and decrease their associated costs. The Lightning Network allows Bitcoin.core based blockchains to open payment channels directly between two nodes. The parties can then conduct transactions without having to broadcast them to the blockchain, avoiding delays and costs that result from recording those transactions each time. Once the channel is closed, only the resulting balances are recorded on the blockchain, not the full transaction history of the channel, and only then fees (can even be nearly zero) were paid. There is no required time or transaction limit required to close a payment channel, so they can potentially remain open for even years.
The major problem some criticism see, is how the sidechains within the Lightning Network work. They move the coins to a second-layer system, to not rely on the highly congested blockchain. In previous solutions, all transactions were needed to process by a trusted third party, without having to broadcast them across the entire network, which saves a lot of resources and time. Stakenet solves this problem, by processing and managing these transactions by a trustless and decentralized masternode network, called watchtowers which provide lightning channels for the Stakenet ecosystem. As we expect ~2000 masternodes to be online this will give our network a robust backbone to provide instant, private transactions to occur and liquidity on our Lightning Network.
1.3.2.1 Transactions for the future
The advantages of using the Lightning Network to cross communicate between all blockchains within the Stakenet meta network can be summarized very well by using the following four criteria.
Instant payments: Lightning-fast instant payments across the entire blockchain without any limitations caused by the block confirmation times. Due smart contracts, the security of the transactions is ensured without the need of an on-blockchain transactions, so a payment speed of milliseconds to seconds can be achieved.
Scalability: Allows the processing of millions to billions of transactions per second across the network. This capability outperforms all previous legacy payment rails and attaches a payment per action/click is now possible without custodians or third-party services.
Low cost: Using an off-blockchain transaction setting, causes exceptionally low fees in the Lightning Network. This enables completely new use cases such as instant micropayments.
Cross blockchains: Cross blockchain transactions will be possible, if both chains are connected due a compatible second layer protocol or are supporting the same cryptographic hash function on their own, it is possible to execute trustless transactions between different blockchains.
1.3.2.2 Powered by blockchain smart contracts
Lightning is a decentralized network between several nodes, which use smart contract functionality in the blockchain to enable instant payments between al participations.
How it works? Lightning dependents upon the underlying architecture of each blockchain, using their native smart-contract scripting languages to create a secure network and allow for a massive increase in the network capacity by moving the bulk of transactions off chain for quick processing.
Bidirectional payment channels: First, two individuals open a ledger entry on the blockchain which requires both participants for further actions. Then, both parties need to create transactions which refund the ledger entry to their individual allocation, without broadcasting this to the blockchain. This entry can be closed by each party at any time without completely trustless by just broadcasting the most recent version to the blockchain. If they’ve updated their individual allocations, only the most recent version is valid, which is ensured by a smart contract.
Lightning network: Due the creation of a network of these two-party ledger channels, it is possible to find a path across the entire network. Because all the nodes along these paths are not trusted, as the payment is ensured and secured by using a script which enforces the atomicity processing via decrementing time-locks.
Blockchain as arbiter: Because the blockchain itself is acting as an arbiter and intermedia, it is even possible to conduct transactions due off-chain solutions with the confidence of an on-chain transactions. It’s just like making a legal contract with someone else, without going to any notarian, because the smart contract ensures that no one can cheat. The court will only take actions in the event of non-cooperation to prevent fraudulent behavior.
