Y2K is the root cause of Bitcoin— to prepare for “Y2K38" by providing solutions
Y2K is an abbreviation for “year 2000.” As that year approached, many feared that computer programs storing year values as two-digit figures (such as 99) would cause problems. Many programs written years ago (when storage limitations encouraged such information economies) are still being used.
(Note: After writing this I have discovered that there is much more to it than Y2K38. Scaling is infinite)
I started investing in crypto blindly. It is a mistake a lot of people make. My interest has survived financial ups and downs, the highs and lows of the volatility we see in the market. One day, I got tired of assuming I knew what cryptocurrency was about or speculating what it could be used for. I researched the subject for the better part of 2018. What I found in code and documentation was what hooked me. This thing we call currency is more like a technological asset that will save the internet as we know it. The value of which I cannot even describe yet. Think of Bitcoin at $19,000 as a “test run” for the real thing. When the truth comes to light, some of these projects (or coins, blockchains, bits) — whatever they call them — will make it to the promised land as an inflation proof, stabilized digital asset. Some of these are going for nickles and dimes because they are viewed as dead, and as “currency” and that is where people are really making a mistake. We are talking 1,000x potential in due time.
Primer: Before there was Bitcoin, there was Y2K
“I’m one of the culprits who created this problem. I used to write those programs back in the 1960s and 1970s, and was proud of the fact that I was able to squeeze a few elements of space out of my program by not having to put a 19 before the year. Back then, it was very important. We used to spend a lot of time running through various mathematical exercises before we started to write our programs so that they could be very clearly delimited with respect to space and the use of capacity. It never entered our minds that those programs would have lasted for more than a few years. As a consequence, they are very poorly documented. If I were to go back and look at some of the programs I wrote 30 years ago, I would have one terribly difficult time working my way through step-by-step.”
— Alan Greenspan, 1998
Cryptocurrency, Bitcoin, all of them can be thought of as protocols for an internet scaling solution, as well as security, that are born in binary code. How those codes translate between different software and websites will be explained on the surface in this entry, but what is most important to know is the term we hear quite often in crypto:
“Interoperatability”
Technically, it is not even a real word. What it means in a Bitcoin sense is the ability of a blockchain to interact with another in its operation. Truthfully, it is a way to describe the need for scaling and security on the World Wide Web. We have not come up with a true solution for network time protocol (NTP) vulnerabilities.
In 1997, the British Standards Institute proposed measures to overcome this software problem, one of which was making the year 2000 a leap year (defined below):
Mostly, a year is a leap year if it is evenly divisible by four. A year divisible by 100, however, is not a leap year in the Gregorian calendar unless it is also divisible by 400. For example, 1600 was a leap year, but 1700, 1800 and 1900 were not. This method works fine for the year 2000 (because it is a leap year), and will not become a problem until 2100, when older legacy programs will likely have long since been replaced.
Some systems had problems once the year rolled over to 2010. This was dubbed by some in the media as the “Y2K+10” or “Y2.01K” problem:
The main source of problems of Y2K+10 were:
- Hexadecimal number encoding (think cryptographically hashed tx id’s, public keys, and private key code)
2. Binary-coded decimal encodings of numbers.
Binary coded decimals take up a lot of space. They are the programming language that run the software for your wallets, exchanges, and embedded programs for all cryptocurrency. Space can be saved by using tonal, instead of decimal. There was even a tonal bitcoin project — and it very well may exist to this day. Saving space on coding language creates a language that can be used to scale the internet by saving storage space. This could allow a transmittance of such a code via peer-to-peer mobile networks (think light node networks). If Bitcoin goes tonal, Bitcoin can also go mobile. Mobile networks will allow for the expansion of decentralized exchanges. You get the picture here.
Decimal and binary coded decimals have compatibility issues described below (notice this looks similar to the structure of an Ethereum key string):
Both hexadecimal and BCD encode the numbers 0–9 as 0x0–0x9. But BCD encodes the number 10 as 0x10, whereas hexadecimal encodes the number 10 as 0x0A; 0x10 interpreted as a hexadecimal encoding represents the number 16.
In fact, if you are reading any string that starts with a 0x in decimal, you are reading it wrong. A quick explanation can be found on the BitcoinWiki page for Tonal Bitcoin:
The tonal notation is not supported by fonts bundled with popular operating systems, and so usually requires extra fonts to use. Within the programming community there is a widely accepted convention for hexadecimal notation: use A-F for the higher order digits. Thus, one counts 0,1,2,3, … , 9,A,B,C,D,E,F,10,11 …. There are even two conventions, (which are lacking in tonal notation) for distinguishing a base-16 number from a decimal. The C convention prefixes 0x and the Motorola convention suffixes h. So, the number san, 256 (decimal) would be written 0x100 or 100h. In tonal notation, it would only be written 100, and thus potentially confused with decimal 100 which is 0x64, though this confusion is less of a problem for Bitcoin since the context is always explicit (SI/BTC vs Tonal/TBC units).
Just know that 0x strings are being read wrong and that leads to messed up outputs in Ethereum key strings, much like binary codes being read wrong would lead to timestamps resetting to a time in the past.
For example, here is a problem expressed both as an incorrect key string (0x0⁴⁰) as well as an incorrect timestamp (1969? which is also read as 01–01–1970 at 0:00 UTC). This problematic error can cause attacks on the Ethereum Classic network which I will describe in detail later on. The main problem the internet needs to solve in order to securely scale and solve the Y2K38 problem is:
Any change to the definition of the time_t data type would result in code compatibility problems in any application in which date and time representations are dependent on the nature of the signed 32-bit time_t integer. For example, changing time_t to an unsigned 32-bit integer, which would extend the range to the year 2106, would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers. Increasing the size of the time_t type to 64-bit in an existing system would cause incompatible changes to the layout of structures and the binary interface of functions.
Think of 32-bit software and 64-bit software. Or 32-bit keys and 64-bit keys. Or 32-mb blocks and 64-mb blocks. The problems of compatibility between all types of software and codes that hinder the internet, also hinder cryptocurrency. I believe we are at the start of the solution for both the internet and cryptocurrency as well.
How Do We Fix Errors in Time Formatting Code?
Alternative proposals have been made (some of which are in use), such as storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed 64-bit integer, providing a minimum range of 300,000 years at microsecond resolution. Other proposals for new time representations provide different precisions, ranges, and sizes (almost always wider than 32 bits), as well as solving other related problems, such as the handling of leap seconds. In particular, TAI64 is an implementation of the Temps Atomique International standard, the current international real-time standard for defining a second and frame of reference.
Think of each possible solution for secure internet transactions as a possible solution for secure, decentralized Bitcoin transactions:
Storing milliseconds or microseconds since an epoch (UTC start date) can be thought of as milli-bitcoins or micro-bitcoins. Such a denomination is the tonal language solution for Bitcoin storage. You will notice qt-wallets have this denomination already for your own usage.
Another solution is for TAI64 (Atomic Time), which can be thought of as the ability to “atomic swap”. TAI64 is just a way of expressing time in a way that relates to all time coding standards, because they are all based off of that standard. To atomic swap, you just need a 3rd party (trusted) that can produce a transaction between two unrelated softwares or blockchains. If the 3rd party is a coin itself that is presented in a Bitcoin sidechain, we can transact Bitcoin’s with any blockchain and any code without losing Bitcoins due to time format vulnerabilities.
Blockstream’s Crypto-focused Solution — The Liquid Sidechain (Atomic Swaps, DEX, Trusted 3rd Party)
A Bitcoin sidechain would give the ability to transact Bitcoin with any blockchain and any software without risk of losing your Bitcoin’s. It also is a way to do “off-chain” transactions, which is a decentralized exchange must if Bitcoin is going to completely separate from forms of centralization. The user will be able to swap Bitcoin’s without using an exchange. That solution requires things like a Liquid sidechain as well as peer-to-peer networks to scale. Peer-to-peer networks would require coding solutions such as tonal because they are not running off of large centralized severs, but rather your smart phone.
Smart phones did not exist in the year 2000. They now provide an amazing scaling solution. Enter peer-to-peer networks to alleviate congestion between ISP’s and IXP’s (internet service providers and internet exchange points) and for cloud storage (think mini-blockchains or pruned chains) to make the impossible, entirely possible in a decentralized way (without centralized exchanges, servers). Peer-to-peer networks also provide more accurate timestamps:
Precision Time Protocol (PTP) is a master/slave protocol for delivery of highly accurate time over local area networks
Thus, the combination of the Bitcoin sidechain along with mobile nodes from peer-to-peer (P2P) exchange is the solution for a decentralized Bitcoin protocol that includes cross-chain transactions as well as making it more secure by avoiding centralization. However, that sidechain must be secure as well.
To understand sidechain security, one has to understand the different types of blockchain attacks. These are due to centralization of ownership as well as time manipulation tactics altering a transaction:
Example 1 — Double spend attacks
A double spend attack can only be attempted with a substantial fraction of the hashrate used in the Proof-of-Work of the Bitcoin network. The attackers will start a double spend race against the rest of the network to replace the last blocks of the blockchain by secretly mining an alternate blockchain.
The solution?
A sidechain with honest nodes, the longest standing blockchain possible, that serves as a third party for transactions so correct timestamps can be logged on each participating blockchain.
Example 2 — Block-withholding
The solution?
A sidechain with honest nodes, the longest standing blockchain possible, that serves as a third party for transactions so correct timestamps can be logged on each participating blockchain.
Example 3— Timestamp manipulation attacks on Ethereum Case Study
Manipulating the local clock at a victim node can turns a ‘established’ node with knowledge of the network (and is known to other geth nodes in the network) into one that knows nothing about the network (and is unknown to other geth nodes). Worse yet, the victim will refuse to accept network information learned from most honest nodes, while happily accepting information from the attacker.
(The attacker) will maliciously change a victim’s clock so that it is more than 20 seconds in the future, by e.g., attacking NTP [31], [32]. This means that the victim will reject any honest UDP message as expired (because, from the victim’s point of view, the request is more 20 seconds old). This results in two things
Full study: here.
NTP, or Network Time Protocol, is what you need to focus on here. NTP is the protocol for clock synchronization over the internet. The result? Your loss in cryptocurrency funds, or the 51% attack on an entire blockchain. A current example of this type of attack is occuring right now with Bitcoin Gold.
The below passage describes internet and software Y2K38 attack vulnerabilities, but we could easily insert “crypto” before each type of attack and describe a cryptocurrency attack vector.
Several security concerns arose in late 2014. Previously, researchers became aware that NTP servers can be susceptible to man-in-the-middle attacks unless packets are cryptographically signed for authentication. The computational overhead involved can make this impractical on busy servers, particularly during denial of service attacks. NTP message spoofing can be used to move clocks on client computers and allow a number of attacks based on bypassing of cryptographic key expiration. Some of the services affected by fake NTP messages identified are TLS, DNSSEC, various caching schemes (such as DNS cache), BGP, Bitcoin and a number of persistent login schemes.
- Ethereum Classic resetting to the equivalent of 01–01–1970 is the result of a binary coding error which is seen outside crypto in a Year 2038 (Y2K38) problem error:
The Year 2038 problem relates to representing time in many digital systems as number of seconds passed since 1 January 1970 and storing it as a signed 32-bit integer. Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038.
2. Using this timestamp may or may not have caused a coding translation error by not matching up a correct timestamp with the block explorer website for Etherhub.io. When this occurs, the hexadecimal output is a string of 0's.
3. It also messes up the miner’s public key string. There are massive amounts of money on both ETC and ETH at the same address.
4. The nonce should be read in a tonal coded language but has been rolled over to 0’s because the code is read as a decimal number, and that format of the nonce is too large (greater than 16 characters, base 16).
5. The extra data presented is in a tonal script that most computers do not have the font to read. Tonal can be correctly read as code without such a font and then translated to decimals and hexadecimals crypto enthusiasts understand.
Many people will tell you this is just a default pre-written address on most Ethereum wallets and this is the result of big thumbs. Not so, the bulk of this money ($751 million dollars!!!) is from a coding translation error between an Ethereum string and the block explorer. This is a real life issue as much as a cryptocurrency issue. We finally have possibility of a solution for unrelated timestamp formats as well as secure blockchain interoperatibility.
The solution?
A sidechain with honest nodes, the longest standing blockchain possible, that serves as a third party for transactions so correct timestamps can be logged on each participating blockchain.
Why Did We Need Crpytocurrency to Solve Y2K Related Issues?
We needed cryptocurrency because the solution includes your smart phones for scalibility and because Y2K solution funding by today’s standards is even more expensive because of inflation:
The total cost of the work done in preparation for Y2K is estimated at over US$300 billion ($426 billion today, once inflation is taken into account).[57][58] IDC calculated that the US spent an estimated $134 billion ($190 billion) preparing for Y2K, and another $13 billion ($18 billion) fixing problems in 2000 and 2001. Worldwide, $308 billion ($438 billion) was estimated to have been spent on Y2K remediation.
If you told people to invest in 2009–2018 to save the internet using different protocols, you would likely find far less of the public putting their money forth as they do with “coins” and tokens.
So knowing all of this, you can focus your investments on:
- Secure blockchains — solutions that prevent miners from controlling the network or manipulating enough timestamps to gain control of the network. Merge mined coins are more secure for such a reason. They have a Bitcoin related hashing power rate because they were mined alongside Bitcoin. Ixcoin is a sidechain that has been attached to Bitcoin since it began merge mining in 2011. Ixcoin is also fully mined, so the only mining done now is in the form of IXC transactions — making a 51% attack unlikely. It presents a Bitcoin sidechain that is secure and can conduct trusted 3rd party Bitcoin tx’s, atomic swaps, and decentralized exchange in general. This is an example use seen in Blockstream’s Liquid sidechain.
- Block size — how many transactions can a coin handle per block? If this is to be an internet wide solution, block size would have to be large. Bitcoin Cash (32 mb) and Ixcoin (64 mb) have increased their block size recently to handle the transfer large strings between blockchains. The conversion to large blocks is the only way that Bitcoin will survive as a usable internet currency. Bitcoin Cash functions as a currency of its own, and it dwarfs Bitcoin’s 4–7 transactions per second rate. If Bitcoin ran its transactions by using Ixcoin’s blockchain as a 3rd party, it could securely scale for lightning fast transactions.
- Use as a two-way peg — Blockstream defines the type of sidechain usage described above as a “two-way peg” which literally just means the value being staked (Ixcoin’s) is used to hold the value being offered by one client in Bitcoin for another client’s return in whatever crypto asset they are sending back. This prevents time forged robberies by using an intermediary blockchain that can translate both types of time coding. It also reports back to each blockchain the correct timestamp for a transaction as a result. Bitcoin would have to use one of its own sidechains as a two-way peg. That being said, the value of Ixcoin as a two-way peg, that is also fully minted would skyrocket based off of Bitcoin’s value.
- Inflation Resistant Coin (done mining) — coins that have reached their max supply are only mined in transaction fees. If Bitcoin had a sidechain that couldn’t be attacked by miners withholding enough blocks and with a hash rate that is similar to prevent 51% attacks, it could use that sidechain to scale and improve its tps rate. The coin would have had to benefit off of Bitcoin’s hash power via merge mining as well as be fully minted (done mining new coins). Enter, Ixcoin and I0coin as the original Bitcoin merge mined blockchains that have reached almost 100% of their 21 million max supply. These secure, inflation resistant coins can be had on the cheap right now (as low as 16 to 3 cents, respectively). Remember, Ixcoin has the largest blocks in crypto. That means Ixcoin is able to processes the most transactions per second (tps) in crypto on a secure Bitcoin sidechain. I0coin could be used as a mini-blockchain or cloud format type p2p network because it has faster block times. Both of these coins were created with a specific reason in mind at a time (2010–2011) when Satoshi was the only one in town creating coins. The mining of new coins finished for Ixcoin in 2014, and in I0coin this year. What better way for Bitcoin to scale using secret sidechains that have been around to see almost all of its ups and downs. Furthermore, the distribution of both sidechain coins is so fairly spread out among holders, that it would take an almost impossible amount of transactions to gain 51% control over the blockchain — as long as that sidechain goes to Proof of Stake (POS).
Proof of Real World Work (Hybrid POS Solution)
The actual name for it is Proof of Beans (POB) — which is absurd, but also warranted because Bitbean, now known as Bean Cash, was the first to experiment with it. Three things it does well that Ixcoin could do for Bitcoin include:
- Pioneering Big Blocks for More Transactions
- Using An Initial Proof Of Work Phase
- Switching Over to Proof of Stake to Secure Its Even Distribution
Note: BitBean is the first crypto to implement 20MB blocks, based off Gavin Andersen’s proposals to fix Bitcoin’s scale-ability limitations.
About BitBean Proof of Work phase
SHA-256 ASIC mining is energy efficient so it was chosen as the algorithm for the pow period. After initial distribution of 10,000 blocks, to those who mined all around the world, BitBean became a pure Proof of Stake (PoS) crypto currency. PoS was active during the PoW mining period, so about a third of those 10,000 blocks issued were proof of stake blocks. BitBean’s money supply is currently over 600 million virtual beans created. The amount of existing BitBeans is still small compared to the maximum cap of 50 billion BitBeans that are yet to be created with pure Proof of Stake. Proof of Work is a great way to initially distribute coins. It is certainly better than an IPO or ICO where almost always the developers and insiders buy all the coins. This makes for massively pre-mined coins. BitBean had no premine or IPO.
BitBean’s Proof of Stake is different from other PoS crypto currencies. BitBean requires 6 hours for beans to mature before they are eligible to stake a block. In addition, unlike other PoS crypto currencies, BitBean creates new blocks using a similar approach as PoW crypto currencies. Blocks which are found are static blocks similar to PoW. Each PoS block reward is 1,000 virtual beans. This is a much better form of proof of stake than determining rewards based on a percentage basis. Crypto currencies are supposed to be a payment system. BitBean’s PoS encourages people to actually process transactions instead of hoarding their coins. Hoarding coins and only processing transactions rarely to collect an interest payment, does not make for a good payment transaction network.
If Ixcoin was staked in a similar manner, the usage case for it as a Liquid sidechain is undeniable.
The type of use case Blockstream proposes in Liquid for Bitcoin scaling fits the definition of an Ineternet Exchange Point (IXP):
An Internet exchange point (IX or IXP) is the physical infrastructure through which Internet service providers (ISPs) and content delivery networks (CDNs) exchange Internet traffic between their networks (autonomous systems).
“IX” 😉
So Why Have You Never Heard This From Anyone?
Liquid sidechain is a Blockstream scaling solution for Bitcoin using a capable Bitcoin sidechain. I view Ixcoin as the best blockchain to provide a Liquid sidechain service, but I could be wrong. Blockstream has not yet named the Bitcoin sidechain they will be using. They have denied the option to create a new blockchain; however, so speculation on an old merge mined coin is warranted.
If you want to go tinfoil hat theories, Ixcoin’s official twitter uses a header background image of San Francisco. Blockstream is located in San Francisco.
Blockstream recently merged code with IBM in the Linux Foundation led Hyperledger blockchain. IBM has been all over blockchain in the past year in many different areas. One interesting, yet vague venture their company has offered?
“iX” an AI based tool to develop businesses and apps (and more)…
IBM being behind IXC would be a game changer. IBM also has “quantum computers” so they have the processing power to be the engine behind IXP’s (Internet Exchange Points that connect different ISP’s), as well as P2P mobile networks that connect long distance data transmission using IXC’s (interexchange carriers).
IX can also be used as an Index Fund if it is used as a sidechain to facilitate transactions between the likes of high market capitalization coins and tokens. We are seeing many types of Crypto Index Funds starting up from Mixin as well as Circle and others. These index funds tend to include Bitcoin, Bitcoin Cash, Ethereum, Ethereum Classic, and Ripple. Using Ixcoins as an even exposure to transactions using the types of coins above would give it a very large value.
Last but not least, the secret sidechain theory may have been to keep that sidechain secure until it was secured enough by being done generating new coins and also by securing the blockchain for an eventual switch to Proof of Stake. Ixcoin doesn’t have a timestamp on its genesis block in the github code, nor does it have a “block 0” in its block explorer. That leaves a door open that Ixcoin could infact be Bitcoin 2.0 (improved Bitcoin), or at least around at Bitcoin’s 2009 genesis date. I believe a time is coming very soon for Ixcoin. At 16-cents/IXC today (5/25/18) — you could very well “1,000x” or more with Ixcoin. Time will tell.
The article presented to you here was based on theory driven by research. All speculation is mine alone and I do not represent views of Blockstream, IBM, Linux Foundation, Ixcoin, or any cryptocurrency related entity. Do your own research.
