Stealth Release v2.2.0.0
Stealth.org is pleased to announce a new release for Stealth (XST), v2.2.0.0. This release, which goes live on block 2,378,000 (expected sometime on 11/14/2018) incorporates a number of improvements, but two major changes come to the Stealth core protocol: (1) removal of transaction timestamps and (2) removal of transaction ID malleability.
Here we describe the significance of these two core protocol changes.
Removal of Transaction Timestamps
At first glance, the inclusion of a timestamp in a cryptocurrency transaction seems to make a lot of sense. For example a transaction timestamp might allow recipients to know exactly when a transaction was created. It can also provide a reminder to the sender in case the sender loses other records, and can help auditors assess the historical value of transactions, since cryptocurrency values fluctuate with respect to the USD and other fiat currencies.
Transaction timestamps were introduced into cryptocurrencies in Peercoin (PPC), which was the first proof-of-stake (PoS) cryptocurrency. Peercoin was created by Sunny King and Scott Nadal, so I will refer to Peercoin PoS consensus as “King-Nadal consensus”. As a descendent of Peercoin, XST also presently uses King-Nadal consensus.
Timestamps in King-Nadal consensus are used to calculate what is known as coinage. Coinage is not only a word, but also a mathematical formula that means “a number of coins multiplied by their ages”. Coinage is important for calculating rewards in cryptocurrencies that use King-Nadal consensus. Coinage also determines how likely one is to sign a given block, in that a greater coinage corresponds to a greater chance of signing a given block. This concept is also known as “stake weight”. In other words, one’s stake weight increases with coinage.
A simple example will help clarify the concept of coinage and its importance to King-Nadal consensus. Let’s say Alice has 100 XST, which she has held for 60 days. This means Alice’s stake weight is 100 ⨉ 60 = 6000 coindays. If Bob also has 100 XST, but has had them for only 30 days, his stake weight will be 3000 coindays. Thus, Bob’s stake weight is half Alice’s stake weight, because Bob has had his coins half as long as Alice. Let’s imagine Alice and Bob both stake blocks with their 100 XST. Since Alice has twice as much stake weight as Bob, her reward will be twice as much.
Clearly, transaction timestamps seem important for accounting, audits, and PoS. However, as a practical matter, transaction timestamps are redundant because transactions reside in blocks and blocks have their own timestamps. Additionally, since the sender is responsible for creating the timestamp, the sender can backdate a transaction, potentially fooling the recipient and future auditors. This ability to arbitrarily modify a transaction timestamp without cost means that transaction timestamps are not reliable.
Transaction timestamps have another problem in that they can adversely affect integration with third-party service providers who use their own time servers to timestamp transactions. These transactions are then submitted to the cryptocurrency peer-to-peer (p2p) network. The issue arises because of differences between the clock of the third-party timestamping server and the p2p network clock. If these clocks are too far apart, the third-party transactions will be rejected.
These potential clock differences exist because the p2p nodes have to agree on a common clock without referring to a central authority, owing to the decentralized nature of cryptocurrencies. Often this common p2p clock drifts relative to what most people might consider official time, usually provided by governmental institutions, ISPs, or telecom providers. A timestamping server will most likely agree with official time rather than with a p2p network time with no authoritative clock.
Since XST is a proof-of-stake protocol, timestamps play a critical role in consensus, and new transactions with too loo large of a difference between the transaction time and the current network time will be rejected. For example, the propagation of a transaction with a timestamp in the future must wait until the its timestamp is earlier than the p2p network time. Notably, this exact problem arose shortly after Ledger Wallet launched support for XST because, since 2014, the XST network time has drifted about 13 minutes behind all official time sources. For a few days, it was difficult for users to send from their Ledger hardware. The problem was fixed through efforts of the Stealth and Ledger teams working together. The ad-hoc solution that was devised is still in effect, and will be replaced by a permanent fix when the v2.2.0.0 fork goes live on block 2,378,000.
The permanent solution to these types of problems is of course to remove transaction timestamps completely. This removal is justified on a number of levels. First, not only have transaction timestamps never been a part of Satoshi consensus (i.e. the Bitcoin protocol), they are not required for King-Nadal consensus because blocks already have timestamps. Second, removal of transaction timestamps has been proposed elsewhere. Most notably, of the ten major protocol improvements proposed for Peercoin, only the elimination of transaction timestamps has been approved. Removal of transaction timestamps has not yet been implemented for Peercoin, most likely because such a transition is technically challenging and potentially disruptive to a PoS network if not executed properly. To my knowledge, XST is the only King-Nadal consensus cryptocurrency to remove transaction timestamps.
As most readers may already know, Stealth will move to Quantum Proof-of-Stake (qPoS) soon, abandoning King-Nadal consensus. However, transaction timestamps are not coming back to Stealth with the transition to qPoS.
Removal of Transaction ID Malleability
Compared to understanding the issues that arise with transaction timestamps, understanding transaction ID (TxID) malleability takes a bit more contemplation.
Transaction ID malleability is the potential for TxIDs to be changed without invalidating a transaction. To give an imperfect metaphor, consider that you could make a unique TxID for a typical bank draft (a.k.a “check”) by joining the routing number, account number, and check number. Now, imagine that, after you mailed a check, someone could make a copy of it, modify the check number to anything they wanted, consequently changing the check’s TxID, then mail that copy of the check. This is similar in concept to TxID malleability (but not by any means an accurate technical description).
A more accurate description follows. Bitcoin-type cryptocurrency transactions get a TxID by taking a cryptographic digest of all the transaction information, including the signatures. A cryptographic digest can be thought of as a string of pseudo-random characters that represent all the information that went into creating the digest. For reference, the following Bitcoin TxID provides an example of a cryptographic digest:
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
TxIDs should be unique in that each transaction should have only one TxID. But a pitfall with Bitcoin-type transactions is that their signatures can be modified without invalidating the signatures. Since signatures are used in computing TxIDs, these modifications can create new TxIDs without invalidating the transaction, allowing the same transaction to have multiple TxIDs. This is the essence of transaction ID malleability.
Transaction ID malleability has allegedly been the source of numerous problems with the entire Bitcoin network. For example, MtGoX, the infamous exchange that went down in 2014, blamed its problems on individuals’ malleating TxIDs to fool MtGoX into sending the same withdrawal multiple times. As recently as last year, the Bitcoin network was spammed with millions of transactions that were created at low cost by applying malleability to a smaller number of transactions. The reason this type of spam is so effective is because transaction fees only need to be paid on the small number of transactions, but a large number of derived transactions can flood the network at practically no additional cost.
One obvious solution that covers all sources of TxID malleability is to simply create a TxID from the transaction information, then have the sender sign the TxID as part of the transaction. This would mean that if the TxID changed, it would invalidate the signature. The chicken-egg problem with this approach is that the signatures are used to create the TxID, meaning a signature would paradoxically have to sign itself. The solution to this paradox is to simply leave the signature out of the TxID calculation, then require the sender to sign the TxID. In this approach, a signature could be still modified without invalidating its transaction, but these modifications would have no bearing on the TxID. This solution is exactly how XST TxIDs are rendered immalleable.
— — — — — — —
Hondo
— — — — — — —
