Bitcoin State Reorganization: Are You Prepared for June 30, 2018?
“Bitcoin is going mainstream” -Vlad2Vlad
Update: Bank of America, which has filed more crypto patents than any other company, seems to have ties to Coinbase in its signed certificate timestamps. See Bottom of this article.
Update 2: ALERT KEY TRIGGERED on I0COIN (see bottom)
Note: The Coinbase, SHIFT debit card backed by Visa would not adhere to Open PCI DSS v 3.2.1 because currently BTC is on “libsecp256k1” which would not meet the protocol that Visa, Mastercard, American Express, Discover, and more are enforcing on June 30, 2018 in Open PCI DSS. The only way Bitcoin can make it as a credit card company backed debit would be if they used Open SSL with a security patch that meets security standards of Open PCI DSS. I0Coin is the only crypto I have come across with Open SSL in use and a security patch (1.0.1k) that would protect it by enforcing strict DER encoding. Just know, I0C and potentially IXC seem to be the only coins dating back to v 0.12.0.1 and v 0.13.0.1, respectively, that could operate on a Visa, Mastercard, American Express, or Discover card network as a crypto debit card. That would give Bitcoin instant use and adoption. What a scenario for I0C and IXC. What say you, Coinbase?
On June 30, 2018 requirements for the Payment Card Industry Data Security Standard (PCI DSS) are going to be enforced for v 3.2.1. As a result, Bitcoin will use its state reorganization and built in security mechanisms in I0C and IXC to go mainstream as an acceptable, Visa/Mastercard/American Express/Discover backed payment:
The 30 June 2018 deadline is a very important milestone. After this date, SSL and Early TLS may no longer be used as a security control for PCI DSS, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect, as defined in PCI DSS Appendix A2.
In 2014, Bitcoin had started to recognize its consensus mechanism from BIP 34 allowed miners too much time to use outdated clients which allowed them to use ASN.1 BER encoding. This allowed them to fork the blockchain because BER encoding is not able to be used correctly across all cryptographic codebases. By using BER encoding and not only DER encoding (which would’ve fixed the issue), using Open SSL only created security vulnerabilities:
The problem is related to the signature encoding rules.
Bitcoin's signatures are ASN.1 BER encoded. BER is a complex standard
that allows many different encodings for the same data. Since Bitcoin
Core 0.8, a standardness rule has been in effect that only allowed
subset of encodings (DER) for relay and mining, even though any BER
remained valid in the blockchain - at least in theory.
In practice, BER has many weird edge cases, and I have not found a
single cryptographic codebase that can parse all of them correctly.
This includes OpenSSL, Crypto++, BouncyCastle, btcec, and our own
libsecp256k1 library.
This on itself would not be a problem, as full nodes on the network
currently use OpenSSL. However, while researching what was needed to
make libsecp256k1 compatible with it, I discovered that OpenSSL is even
inconsistent with itself across different platforms.
ASN.1 BER is a standard for encoding Bitcoin signatures. Bitcoin Core 0.8 uses only DER, a subset of ASN.1 BER to encode signatures:
ASN.1 is Abstract Syntax Notation 1, a method for describing data objects. It was created in the 1980s, is a binary format, and as the name says, it is abstract. To actually store or transfer an ASN.1 object, it must be encoded in a standard way. Distinguished Encoding Rules (DER) is the encoding used for X.509, and is an unambiguous subset of Basic Encoding Rules (BER).
The problem arises when using a cryptographic codebase (for a coin) that uses something besides OpenSSL + DER as of Bitcoin 0.8. All DER encodings are valid as BER encodings because DER is a subset to DER.
The problem with using BER encodings was that it could cause forks of the blockchain fairly easily:
A specially-crafted transaction could have forked the blockchain
between nodes:
* using OpenSSL on a 32-bit systems and on 64-bit Windows systems
* using OpenSSL on non-Windows 64-bit systems (Linux, OSX, ...)
* using some non-OpenSSL codebases for parsing signatures
Bitcoin miners using pre-0.8 clients with BER encoding were able to fork the blockchain. This problem would have been solved if BIP 34 allowed BIP 62 to be implemented immediately. Instead BIP 62 was skipped:
2015-Jan-10: OpenSSL releases versions 1.0.0p and 1.0.1k, with a fix
for CVE-2014-8275. The fix introduced a restriction on ECDSA signatures
to be strict DER, which would have solved all problems related to
signature encodings, except Bitcoin's consensus-critical nature
requires bug-for-bug compatibility between nodes. Worse, it seemed that
there was again a small (1%) number of blocks being created with
non-DER signatures in it, resulting in actual forks. The only immediate
solution that did not introduce more risk for forks was parsing and
re-encoding signatures using OpenSSL itself before verification to
bypass the restriction, making the problem persist. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007097.html.
Open SSL with patch 1.0.0p or 1.0.1k would’ve fixed all problems related to signature encodings by using strict-DER for ECDSA signatures — however BIP 34 (consensus) prevented the problem from being fixed because all nodes were not in consensus (not updated and using DER). Since miners were not updating to clients 0.8 and above, they were introducing blocks that used BER encoding at a 1% rate which caused the automatic forks described above.
Bitcoin’s fast solution was to ditch Open SSL altogether because it had zero time to wait for BIP62 implementation. They chose to ditch Open SSL in order to quickly implement strict DER encoding without it:
2015-Jan-21: The new attention to signature encoding might have
revealed the vulnerability, and the presence of miners not enforcing
strict DER might have made the vulnerability actually exploitable.
BIP62 was still a moving target, so we wanted a faster means to solve
this. Therefore, a new BIP was proposed with just the strict DER
requirement, numbered BIP66. This would both allow non-OpenSSL
verification, and solve the vulnerability, without needing to fix the
less urgent malleability problem that BIP62 wanted to address. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007156.html.
This led to Bitcoin adopting libsecp256k1 by 0.12.0:
Features:
secp256k1 ECDSA signing/verification and key generation.
Adding/multiplying private/public keys.
Serialization/parsing of private keys, public keys, signatures.
Constant time, constant memory access signing and pubkey generation.
Derandomized DSA (via RFC6979 or with a caller provided function.)
Very efficient implementation.
To recap:
- Miners were exploiting and forking the chain by using pre 0.8 clients that allowed BER encoding, instead of strict DER + Open SSL.
- Because only Open SSL patches (1.0.0p & 1.0.1k) were introduced to enforce strict DER, and a single cryptographic codebase was not available to correctly use BER encoding for ECDSA signatures — the quick choice was just to abandon Open SSL and keep consensus from BIP 34.
- BIP 66 would allow strict-DER without using Open SSL after it achieved a 95% consensus. This was achieved on 4 July 2015. The quick fix was not entirely a quick fix considering attacks were allowed to persist from BER encoding clients pre-version 0.8 for over a year since its discovered vulnerability.
- Bitcoin then switched to libsecp256k1 in v 0.12.0. This created incompatibility issues with any Open SSL clients by creating incompatibility between different platforms doing cross-chain transactions.
Bitcoin’s problems in stem from a quick fix in BIP 66 because it did not choose to fix all issues of malleability proposed in BIP 62:
Several sources of malleability are known:
Non-DER encoded ECDSA signatures Right now, the Bitcoin reference client uses OpenSSL to validate signatures. As OpenSSL accepts more than serializations that strictly adhere to the DER standard, this is a source of malleability. Since v0.8.0, non-DER signatures are no longer relayed already.
Non-push operations in scriptSig Any sequence of script operations in scriptSig that results in the intended data pushes, but is not just a push of that data, results in an alternative transaction with the same validity.
Push operations in scriptSig of non-standard size type The Bitcoin scripting language has several push operators (OP_0, single-byte pushes, data pushes of up to 75 bytes, OP_PUSHDATA1, OP_PUSHDATA2, OP_PUSHDATA4). As the later ones have the same result as the former ones, they result in additional possibilities.
Zero-padded number pushes In cases where scriptPubKey opcodes use inputs that are interpreted as numbers, they can be zero padded.
Inherent ECDSA signature malleability ECDSA signatures themselves are already malleable: taking the negative of the number S inside (modulo the curve order) does not invalidate it.
Superfluous scriptSig operations Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.
Inputs ignored by scripts If a scriptPubKey starts with an OP_DROP, for example, the last data push of the corresponding scriptSig will always be ignored.
Sighash flags based masking Sighash flags can be used to ignore certain parts of a script when signing.
New signatures by the sender The sender (or anyone with access to the relevant private keys) is always able to create new signatures that spend the same inputs to the same outputs.
Because BIP 34 made it possible for miners to use previous BER encoding Bitcoin clients by delaying the correct fix, the miners would be able to fork the chain until 95% consensus (not achieved until July 4, 2015).
2014-Feb-10: I proposed BIP62 to deal with transaction malleability.
The BIP62 draft includes a rule that would make version 2 transactions
with non-DER signatures invalid.
Bitcoin ditching Open SSL for a quick fix was a big mistake. By not using Open SSL 1.0.1k or 1.0.0p and strict-DER encoding for ECDSA signatures and allowing consensus to delay the fixing of malleability issues, Bitcoin will not adhere to the upcoming PCI DSS. Libsecp256k1 is not a secure cryptographic codebase in relation to Open SSL/TLS, which are allowed, with security patches such as 1.0.1k to be used in the upcoming PCI DSS v 3.2.1. In other words, not only does libsecp256k1 not allow backwards compatibility with Bitcoin’s Open SSL past transactions, it also does not allow Bitcoin to be backed by Visa, Mastercard, American Express, Discover and other PCI DSS v 3.2.1 compliant payment card industry giants. Thus, Bitcoin would not be able to be used on these payment systems.
Simple Facts to Focus On: Don’t Even Worry About The Facts Above
Simply using Open SSL 1.0.1k would allow Bitcoin to be used for payment on any Visa, Mastercard, American Express, and Discover payment processing network via PCI DSS 3.2.1 which is strictly enforced on June 30, 2018.
You would be able to use the Shift Visa Crypto Card from Coinbase anywhere… actually right now you can use that Visa backed crypto to payment card anywhere Visa is accepted. Why is that?
Because Coinbase (thus, I0Coin) is the Bitcoin and Ethereum coinbase and uses an I0Coin v 0.12.0.1 wallet as well (see next section). Coinbase would have to use a wallet compliant with PCI DSS v 3.2.1 to even offer a SHIFT Visa backed Bitcoin/crypto card. I love to add that on Coinbase these cryptocurrencies are already in a state that links ETC, BCH, BTC, LTC, and ETH via I0Coin to allow such a card to exist and be used/backed by Visa. Chew on that.
I want my Twitter reinstated Mr. Dorsey.
The Open SSL Patch 1.0.1k exists on I0Coin v 0.12.0.1
Open SSL 1.0.1k is Bitcoin’s key to adoption. Consider all transactions from forks since “null” and about to be reverted back to the source as I have indicated and explained here many, many times. Just look at my complete archive of articles before this. I0Coin uses this Open SSL fix. Remember:
* 2015-Jan-10: OpenSSL releases versions 1.0.0p and 1.0.1k, with a fix
for CVE-2014-8275. The fix introduced a restriction on ECDSA signatures
to be strict DER, which would have solved all problems related to
signature encodings, except Bitcoin's consensus-critical nature
requires bug-for-bug compatibility between nodes. Worse, it seemed that
there was again a small (1%) number of blocks being created with
non-DER signatures in it, resulting in actual forks. The only immediate
solution that did not introduce more risk for forks was parsing and
re-encoding signatures using OpenSSL itself before verification to
bypass the restriction, making the problem persist. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007097.html.
So what about consensus, which took place as a result of BIP 34? Could that not cause the same problems all over again after reverting all the way back to I0Coin v 0.12.0.1? Not as of November 29, 2015 when BIP 34 activation was from I0Coin’s codebase:
Apparently BIP 34 was never activated on I0Coin’s blockchain. It only makes one think, what else did I0Coin developers wait to add, that Bitcoin core already added?
A: Segwit, which triggers the 51% attack to NLX (Zerocoin protocol, Null Protocol), which sends value back to I0Coin via a state reorganization and then triggers the ERC 20 0x Protocol connecting both Bitcoin and Ethereum. All of the forks will now go back to I0Coin as well. Read about that here:
The end result? All PCI DSS compliant credit card companies and banks now allow Bitcoin cards to be used on their payment processing networks, as if they were not behind part of the cryptocurrency development project all along.
If Bitcoin fails to reorganize correctly and revert back to I0Coin, the source of all Bitcoin and Ethereum, it fails as a peer-to-peer and instantly adopted form of worldwide currency backed by Visa, Mastercard, American Express, and Discover. Coinbase is coinbase. I0Coin is coinbase.
I am just going to end this article right here. There is far more than anyone will ever need to realize what’s going on before anyone ever uttered a word of the truth. You don’t have to believe me, but I am certainly trying to help you out. Good luck. I won’t even ask for donations anymore — I have received zero. Perhaps it is a positive sign for 0coin. :)
Update 1: The “Long Secret Bitcoin Key” is retired but technically still active in I0Coin. The key may be a possible way to sign BTC invalid transactions back to the source (I0C) by allowing transactions from Open SSL (inactive in BTC) to be signed by a specific DER encoded mechanism, which will trigger all value back to I0C. Apparently Mt. Gox had this “alert key” and its been deactivated in Bitcoin Core. This may be how Mt. Gox coins come back to I0C as well. Going back to I0C and using Open SSL 1.0.1k cryptography is absolutely necessary by June 30, 2018 0:00 UTC for it to be acceptable as a payment card that is compatible with Visa, Mastercard, American Express, and Discover payment networks. This would be the essence of state reorganization and “backwards compatibility” with old Open SSL certificates.
Update 2: BAM, I0C has the alert key message!
Satoshi could be speaking through I0C, here is a little history of the alert key and its rare usage:
The alert system was hastily implemented by Satoshi Nakamoto after the value overflow incident on August 15, 2010. Satoshi never actually used this system; it remained dormant until the February 20, 2012 protocol change, for which an alert was issued on February 18.[3]
In 2016, the alert system was retired[1] because of the possibility of privileged users sending political alert messages, and because of the possibility of the alert key having been taken from Mark Karpelès by the Japanese police in 2014.[4]
The alert key was scheduled to be released to the public in May 2017, but this has since been postponed.[1]
Update 3: Bank of America and Coinbase (matched by similar SCT List)
- Coinbase SCT List (open its certificates)
2. Bank of America SCT Match
The signed certificate timestamps for Bank of America and Coinbase look like something I have seen before I just cannot remember… yet.
Update 4: And now I remember, it was from USDT to BTC crosschain txs as an input script which no doubt needs to be corrected in all this chaos…
Step 1: Create a lot of USDT
Step 2: Use input and output scripts to push along USDT ($$$) in the BTC ledger… Notice the input script looks similar to the first part of the codes I found on Coinbase and Bank of America’s SCT Lists.
Example A of SCT List from Coinbase.com:
Example B of SCT List from Bank of America according to coder:
Example C (srs) Bank of America HQ was founded and built originally in San Francisco. Strong presence in that city where Coinbase resides.
— — — — — — — — — — — — — — — — — — — — — — — — —
I will offer consult in relation to crypto going forward from the adoption date for free. Stay tuned. Someone has to be honest and truthful.
If you can at least help spread the word, perhaps we can help some people in need better their lives. I refuse to crawl back to Twitter, but they are free to invite me back. I forgive and forget. Look at the facts, search for truth, share with the people. Ignore all the noise. Find meaning. That is what allowed me to get here myself. Special thanks to Vlad2Vlad for his help on this.
