Merge Mining to Reverse Entropy (Updated)
From ‘chaos’ (entropy) to coherence… I updated at the bottom of the story
Negentropy, is reverse entropy. It means things becoming more in order. By ‘order’ is meant organisation, structure and function: the opposite of randomness or chaos.
I wrote that on June 6, 2018 and I have since come to understand just the kind of chaos the state of Bitcoin is actually in. In fact, that chaos extends to Ethereum, Ethereum Classic, Litecoin, and other forks thought of as unrelated to Bitcoin. However, they so very much are and all have a part of its coinbase. In this article I am going to do my best to work my way through the facts I have found — like Devcoin being the input involved in “Newly Generated Bitcoins” — and the things I have uncovered to make sense of what lies ahead. In Duality, Satoshi Nakamoto — or the group responsible for the pseudonym — published that making Bitcoin work involves math, cryptography, and knowledge of C++. Recently I have gone deeper into all areas and what I have found make a lot of sense. I will expand that understanding Bitcoin involves knowing the technological evolution in computer processing and networks in order to make the peer-to-peer digital currency work. The technology now exists to go forth with the mainnet. If you thought we were on the mainnet for Bitcoin I will direct you to the fact that we are not:
Before going forward to the definition of testnet and mainnet addresses, take into account Bitcoin has script code and you should think of mainnet and testnet addresses explained by both the literal and the underlying meaning in script code. After all, script is used to push coins throughout the network between merge mined coins and Bitcoin software:
The official, non-script definition for Bitcoin testnet and mainnet addresses are as follows:
The first net byte “00” for the mainnet creates the pubkey hash with a prefix “1-” for Pay-to-public-key-hash addresses. This is the same address a vOut from Devcoin raw block data enters the blockchain.info ledger and circulates as a Bitcoin. Coinbase Bitcoin addresses use a “3-” prefix, which are the pay-to-script hash format for a leading byte of “05”. According to the previous explanation the 0x00 first byte is the one used by Bitcoin’s mainnet. Does that make Coinbase addresses incompatible? Currently it does not, but Coinbase is a private entity that can simply convert these transactions from a personal wallet to their own website, which uses a script key hash with the “3-” prefix.
You will also notice that 0x- is left out of the actual table explaining the different types of public key hash addresses. That is a way of omitting the underlying truth. The 00 would simply mean 0 in decimal. Without using the 0x- prefix (as we see in ETH, ETC, and ERC token addresses) the number is read as decimal. If Bitcoin is to be relayed in all software wallets its necessary to distinguish the hexadecimal by prefix. The problem by just using 00 in the first version byte spreads problems in accounting by code in many current and older software running on today’s internet:
I don’t think
0xover00was preference/awkwardness.00would break existing code.0010as octal is8, while0010as hexidecimal would be16.
Empty strings would be encoded wrong if Bitcoin implemented the use of java in the following manner:
Using a
0prefix for octal has caused so very many problems over the years. Notably in countries like the UK where telephone numbers start with a0. Javascript and many other languages would parse these as octal, mangling the number before storing. To add to the fun, one popular database product would silently switch back to decimal parsing if the number contained an8or9. – Basic Nov 24 '15 at 19:45
Bitcoin is already making transactions through java software, which causes a problem because the parsing of the code makes the string read as octal and not hexadecimal (See bitcoinj) Ethereum also uses Javascript in addition to C++ and go. The good thing about Ethereum and Ethereum Classic is they automatically document empty hex-strings as a “SHA3 uncle” which has a constant that makes tracing a block back all the way to the genesis block possible:
The process of RLP encoding and decoding recognizes and encodes/decodes different 0x-prefixed strings so that they become correctly read between different software and javascript software alike. In other words, this type of encoding makes hexadecimals read as hexadecimals and not incorrectly by parsing it as an octal.
So Bitcoin has a problem in its current Base58 encoding/decoding. RLP encoding would take care of hexadecimal encoding and decoding so that correct accounting would remain across all software platforms regardless of Javascript, C++, go, C, etc. It purposely excludes other important parts of making a mainnet address:
Base58 encoding is one way controlled chaos exists in the current Bitcoin software implementation. The solutions are also in place to include “3-prefix” pubkey hash addresses as well as other non 1-prefix addresses. If you knew how to create encoding/decoding incompatible, the developer would also know how to make coding interoperatable when the software merged into one compatible network.
The Base58 encoding basically makes addresses able to send or not send funds to current Bitcoin mainnet implementations from different types of software. Devcoin has a pubkey hash that is acceptable to relay newly mined AuxPow forward to the current blockchain’s mainnet. Coinbase has some sort of mechanism to transfer coins between its 3-prefix (0x05 — first byte) and the current Bitcoin core software wallets and exchange wallets. The possibility exists that Coinbase is already aware of main network protocol and all connected merge mined coins so that conversion is done internally and then once coins exit that address they are able to be sent out after approval and an internal conversion just how they are sent in by conversion and internal approval.
The messy publicly available collection of UTXO’s and frozen funds on Ethereum, Ethereum Classic is because we have yet to see a public state reorganization. However this chaos is controlled by developers — in an experimental version of Bitcoin software, with Bitcoin’s them self only available as a result of merge mining and future planned implementations allowing software compatibility and one two-state quantum ledger with the coins already being available for amazingly cheap prices if you look under the hood at the raw block data.
Merge Mining: From Bitcoin to Tonal
The hexadecimal notation is only not present in Bitcoin Core’s output to a public ledger. In the open source coded software “0x-” prefixes exist in the human readable files. When put into binary and run to produce new coins, the software spits out raw block data that ends up on the Bitcoin ledger as well as on the ledger for merge mined coins.
Examples of 0x- present in Bitcoin software code before run in binary, then output in decimal:
Ex 1 — Bitcoin Core code using 0x- prefixes in a human readable file before tests are run within software (the software reads hexadecimal strings):
Ex 2 — This is read in decimal (or possibly tonal) in merge mined raw block data that matches the tested string [the importance of this discussed later]
Ex 3 — Empty hex strings on the publicly available ledger are not written with hexadecimal prefixes for Bitcoin, but are written with hexadecimal prefixes for Ethereum based forks and tokens.
The relaying between different block explorer API’s causes a bit of a mix-up in actual value and actual amounts of coins in circulation. It even messes up the identity of the blockchain itself, theoretically. For example, here is API stats from Blockchain.com:
In computing, JavaScript Object Notation or JSON is an open-standard file format that uses human-readable text to transmit data objects consisting of attribute–value pairs and array data types.
The output of human readable text on the Blockchain.com API is in JSON, which as we know has issues with 0-prefixes and how that data is transmitted out to the world to view publicly on its ledger:
Using a
0prefix for octal has caused so very many problems over the years. Notably in countries like the UK where telephone numbers start with a0. Javascript and many other languages would parse these as octal, mangling the number before storing.
Because Bitcoin Core software uses these hexadecimal prefixes the relay of information is incorrect. The ordering of the blocks, the data that is readable and not readable is all incorrect in one way or another. Blockchain.com knows this and the fix will be quick, however a state reorganization will take place as a result of this and I will explain how that involves Ethereum, Ethereum Classic, and others.
So what would a better API look like? Blockcypher:
The recognition of BTC and ETH coding languages and blockchains that Blockcypher involves allow it to maintain a 99.99% uptime over Blockchain.com’s 99.89%. This is by design. This leads to better relay of information. Blockcypher also uses better technology and involves metadata which enhances correctness of the ledger display:
Ethereum Classic Block 0 is on the same cloud that BlockCypher is on (Cloudflare) so the network technology helps the relay of accurate information. The parent hash of ETC Block 0 and the “previous block” from BTC Block 0 on Blockchain.com are accurately read at BlockCypher.
The metadata is also a recognition of database records (such as the Berkley DB), which has data from merge mining that may have been wiped out intentionally so as not to show Genesis Block #0 for NMC, I0C, IXC, and DVC — the original merge mined coins that are still alive and well. So what would a better Block Explorer that connects to better technology recognize with database information and 99.99% “up time” show in its BTC Block Explorer?
The Genesis Block (#0) for BTC has moved to Block 1, and there is no record of Block 0 in BlockCypher’s BTC Block Explorer:
It is the exact same data you will find on the lesser linked Block Explorer at Blockchain.com for BTC Block “0”. It is the exact same in decimal that you would find linked to ETC Block “0” which notes the following data in hexadecimal (0x-). Is it the same data?
Let’s do some math:
We know in BTC, the total output is 50 BTC for the original Block 0 and would be identical for BTC Block 1. The 5000000000 number is a decimal representation in satoshi which means 50.00000000. If this output were translated into tonal from “5000000000” satoshi it would be equal to 5,000 mBTC.
The “gas limit” on ETC Block 0 is 5,000.
Gas is defined as:
Gas refers to the pricing value required to successfully conduct a transaction or execute a contract on the Ethereum blockchain platform. (See also, Gwei (Ethereum) Definition.)
The gas limit is defined as:
Gas limit refers to the maximum amount of gas you’re willing to spend on a particular transaction. A higher gas limits mean that more computational work must be done to execute the smart contract. A standard ETH transfer requires a gas limit of 21,000 units of gas.
If a block reward of 5,000 mBTC remains unspent (it does) would the missing gas used (currently 0) on ETC Block 0 come from the new BTC Block 1 block reward? There is currently no transaction on ETC block 0, and thus — no block reward has been mined. We have to answer a few more questions first:
What unit of measure is used to quantify 5,000 units of gas on Ethereum?
Gas is the internal pricing for running a transaction or contract in Ethereum. At the time of writing before the launch of Frontier it is fixed to 10 Szabo, which is about 1/100,000 of an Ether
So what about 5,000 “szabo”? First 1000 szabo would be 1/1,000 of an Ether, known as 1 “finney”. I do not believe it will be necessary to calculate the gas price in terms of Ether on a connected platform. The reason being the definition of gas itself:
It’s to decouple the unit of Ether (ETH) and its market value from the unit to measure computational use (gas).
That is how 5,000 units of gas would be expressed on any blockchain besides Ethereum, like Ethereum Classic (or Bitcoin).
The previous block hash is “0000000000000000000000000000000000000000000000000000000000000000” from BlockCypher’s BTC Block 1. That is not ETC Block 0 but correctly identified as the “Parent Hash” 0x0000000000000000000000000000000000000000000000000000000000000000.
That makes the block we are looking for linked to ETC Block “-1” which you can get to by clicking on the parent block hash:
The page exists for a reason. Gas has not been spent at ETC Block 0 yet, nor do we have the 5,000 unit of measure for the gas limit. If it is 5,000 mBTC on a connected network then that would make sense that the new BTC Block 1 has to be mined (currently has a 0 tx fee) back to the parent block of ETC Block 0, becuase the ETC 0 Parent Block hex matches the prevblock empty string from BTC Block 1. Then that brings me to my next point. This transaction can find its way back to the genesis block for all connected chains through “SHA3” uncles — the mechanism which Ethereum Javascript RLP encodes an empty string. The blocks that precede ETC Block 0 would all have to be SHA3 uncles at the address “0x 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347”.
So to find the new recognized Bitcoin genesis block we need to recognize a state reorganization where ETC Block 0 becomes ETC Block 1. ETC Block 1 is then passed through once to the new Genesis Block of a combined BTC/ETH/ETC, and then passes through a new ETC Block 1 into the future.
The process has already started and is 2/3 completed in state reorganizations. Currently Blockcypher recognizes the original BTC Block 0 as Block 1. The cloud has made this possible. The post fork ETH Block 1 is also equal to the first ETC Block 1. This represents a duplicate going forward for both chains. The miner is the exact same as well as the information on ETC + ETH Block 1's:
Ethereum Block 0 was mined 15 seconds earlier than ETC/ETH Block 1 and has the same parent hash and same uncle as ETC Block 0:
The uncles also match going out from ETH where they would have to match going into the genesis block (3 times) with the parent branch. You can see proof of the outbound uncles at ETH/ETC block height 1. If the parent hash preceded BTC Block 1 but is before Ethereum and Ethereum Classic’s Block 0’s then lets make a diagram of the possibilities:
Merge Mining Back to the Root Block 0 + Coinbase Tx
You first need to know what a coin actually is and why it is valuable:
So you want to find a coinbase COutPoint but you have no idea where to start? Don’t expect to find them on the public ledgers for BTC, ETC, and ETH. At the same time, good luck finding raw block data for these ledgers. This is exactly why you need to know what a “Coin” actually is. I will note it has a Block 0, which will have a transaction that has “COutPoint” and an index “n”. The index is reflected in its “sequence” on raw block data. I noticed awhile ago that Bitcoin was not minting coins, rather it was Devcoin and I0Coin. Well, when you open up the Devcoin qt-wallet you may find something special that goes unseen on API currently due to the direct withholding of such data. My guess is that the metadata required for broadcasting this transaction is kept secret. That is why you no longer find block 1’s for Namecoin, I0Coin, IXCoin, and Devcoin on their public block explorers. The qt-wallet, the Satoshi client, allows one to see the truth where Satoshi still speaks:
This is from the only current Devcoin qt-wallet which downloads to a folder 1.0.16 — which would in essence, make it a main network transaction from main network software:
However when you open the debug window, the version is still experimental and beta v 0.8.5.1. Here is a side by side of the I0Coin qt-wallet v 0.12.0.1 for comparison:
My proposal that the missing metadata was from a database would jive with the fact that I0Coin has the Berkeley database whereas Devcoin does not in its current software. So the combination of the empty string and sequence from Devcoin’s record of the coinbase transaction is only half complete. The coinbase will have to produce another output but as of right now we only know that two of the original merge mined coins are minting new coins. The pubkey hash on the output of the current DVC raw block data sends its block reward of 12.5 coins to BTC which is recognized on the ledger as newly generated coins. We know the Coinbase TX is seen in the debug file when you first boot up a Devcoin wallet. These coins are truly Bitcoins. Whether this data of 12.5 coins is in decimal or tonal is not known to me, yet.
We also know that the scriptpubkey hash (Hash 160 on BTC) matches the Devcoin output of newly generated Bitcoins at the same 12.5 block reward. This vOut (vector) ends up on I0Coin addresses that begin with a j-prefix for the pubkey hash. I have explained this in diagrams and previous articles that look like this:
Since Devcoin is a part of the coinbase I wanted to see how this came to be. Everyone calls Devcoin a fork of some sort but the biggest changes came when it was “forked” from I0Coin.
This resulted in a simple name change and a splitting up of the minting process of actual coins between I0Coin and Devcoin. Devcoin remained compatible with Bitcoin pubkey hash’s while I0Coin switched to a j-prefix (incompatible currently) but retains the same scriptpubkey (Hash 160) to match all equal DVC to BTC outputs. I have shown this above in I0Coin raw block data and records at blockchain.com.
So Devcoin has a view of the original COutPoint of actual “Coins”… without Coins in the ledger, there is no value from minting. So where exactly does I0Coin fit the definition of a “coin” per Libcoin?
The two most essential characteristics of a Coin:
- Presence in the COutPoint (empty string of 0's)
- An index, “n” which is the sequence and in the hex on all raw block data
On I0Coin we find both matches:
Luke Dash Jr. is running tests on finding this new coinbase with the exact hex string that I0Coin possesses. IXCoin also has this hex string which could be why it is recording vOuts of its own after merging with I0Coin (likely when it started to give back its ‘premine’) — which is a fact based working theory. Take a look at BTC core’s acknowledgement of this (this is ground breaking evidence):
To the right on the linked photo above is the exact data in an I0Coin hex string:
“coinbasetxn\”:{\”data\”:\”01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff\”},\”mutable\”:[\”coinbase/append\”]}”, simple_time_rcvd));
That is from the third coinbase tx where the genesis transaction cuts off before the Coinbase. If we were going from ETC Block 0 to ETC Block -1 and block -1 was the coinbase then the genesis block transaction would be cutting off before the coinbase. This could be seen in quantum computing as the setup for the reversal of what is to come. We have one state created but without a transaction at the setup point because we are waiting for the other state to come back through to the new coinbase from the new genesis block to form one transaction output that makes sense for three different ledgers (ETC, ETH, BTC). When will this take place? Two educated guesses:
- With Ethereum Classic being added to coinbase — making three ledgers in question acknowledge their root source transaction (genesis block) and automatically making the “Coins” in the ledger (I0C, DVC, IXC, NMC) quantum bitcoins. Completing the process of merge mining. NMC at the moment is just issuing IOU’s for every minted coin that IXC, DVC, and I0C mint in this current state. What makes sense in one state has to make sense in another.
- When the Devcoin block explorer expires on Chainz on 08–08–2018.
So what are Coins again? Besides born of a transaction with a COutPoint (DVC + I0C + IXC) and a matching sequence (“ffffffff”):
The COutPoint class is defined by a hash and an index to a transaction, and you can, by looking up the transaction in the BlockChain determine its value.
If you happen to be the owner of that coin, it also defines the quantum of bitcoins you can pay with.
If you want to pay less, you will get a new coin in return.
So a quantum of bitcoins is = to the vOut (vector out) of 12.5 coins for DVC, I0C, and IXC. It’s important to note that because a non-standard output is attached to every DVC to BTC ledger output (n:0) at “n:1” this is not a relayed transaction no matter how many full nodes you connect to. That means 12.5 coins leave DVC but they are not also called back by the op_code “OP_Return” as they are on I0Coin n:1 vOuts. Nulldata is a standardized transaction and will relay this to the Blockchain. The signature and op_code proves ownership of I0Coin’s on the BTC blockchain from DVC. DVC was a rename from I0Coin. So DVC is actually a tokenized value for the future 25 coin total in Bitcoins once I0Coin is recognized as the source of both DVC and BTC that are currently minted. IXCoin also has had this function in the past and has an output with nulldata that helps it do the same for transaction fees. Namecoin keeps the tokenized record (IOU) for 25 coins at the current moment, which makes for a total of 50 BTC being output quantumly. The same 50 BTC that we started with. 100 BTC in two-states (one at the start, one at the end) — both merging to make sense on each side.
Remember I said DVC is a token? It fits the exact definition of Ethereum as being tokenized but hardwired into the blockchain so as it always retains a 1:1 value with whatever it tokenizes (quantum bitcoins). Devcoin is hard coded to its own alternate Bitcoin blockchain and is currently rewriting blocks from -1 to the empty string (0⁶⁴) that I discuss as the previous block to BTC 1 and ETC and ETH block 0. I just look at its debug file for more proof:
Committing 1 changed transactions to coin database…
SetBestChain: new best=9067d431c46310fd4ad56f5a1e2ee5a3336e5d2d230f34b762d6a49aaaa2bbe1 height=336565 log2_work=85.01944 tx=546443 date=2018–07–29 08:17:13 progress=0.048471
ProcessBlock: ACCEPTED
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
So Devcoin is running a way to interconnect Ethereum with Bitcoin, but at the same time there has to be a part of it working quantumly, in two-states. Where it changes transactions in the root database, it also prints copies (tokens) to match in the quantum/tonal state. Simultaneously my debug file has picked up these transactions on the same day:
received block dbaf55a97fcc8251eb9cf545593402f899c7b327571068c482edeb6a15b2eb88
Committing 1 changed transactions to coin database…
SetBestChain: new best=dbaf55a97fcc8251eb9cf545593402f899c7b327571068c482edeb6a15b2eb88 height=337134 log2_work=85.093716 tx=547018 date=2018–08–02 17:02:13 progress=0.048428
ProcessBlock: ACCEPTED
coinAddressStrings: 1
Address 14wSpxdZZ5yUPaQQyAredr7rgXXEPwTYWC valid, value 4500000000000, minerValue 500000000000
Running DevcoinMiner with 1 transactions in block (223 bytes)
coinAddressStrings: 1
Address 14wSpxdZZ5yUPaQQyAredr7rgXXEPwTYWC valid, value 4500000000000, minerValue 500000000000
coinAddressStrings: 1
Address 14wSpxdZZ5yUPaQQyAredr7rgXXEPwTYWC valid, value 4500000000000, minerValue 500000000000
coinAddressStrings: 1Address 14wSpxdZZ5yUPaQQyAredr7rgXXEPwTYWC valid, value 4500000000000, minerValue 500000000000
coinAddressStrings: 1Running DevcoinMiner with 1 transactions in block (223 bytes)
Running DevcoinMiner with 1 transactions in block (223 bytes)
Running DevcoinMiner with 1 transactions in block (223 bytes)
The miner value is equal to 5,000 mBTC or 5,000 “szabo” but either way it also is equal to the gas limit necessary to connect ETC Block 0 with the previous hash which produced a block reward of 50 BTC (500000000000 satoshi’s). Devcoin supposedly mines 50,000 per block reward. However it is simple to adjust that based on mBTC and convert it by 1/1000 to 50 BTC’s per block. As for I0Coin? It is possible to adjust that total to match it by first multiplying its block reward (misrepresented in decimal) and by accounting for what it quantumly matches based on Devcoin’s actual output. I0Coin is only losing coins that DVC is putting in escrow on BTC’s blockchain via a name change. That should make sense at this point (two-states, all matching). By combining with IXCoin in the hex record of their COutPoint, IXC minted coins first, then I0Coin picked up where IXC left off. In one state I0Coin and IXCoin combine for 50 BTC output at the beginning and the end. Take I0Coin’s incorrect decimal amount of minted coins (0.0234375 I0C)and multiply by 1,000 to get its quantum total of 23.4375 I0C per block. 1/2 of that is matched in escrow by DVC. The current minting of IXC has gone from a similar total and down to 1.0 IXC per block.
However, the coins are most likely misrepresented by one decimal place and I can prove this. There should be 100 BTC in block rewards that are matched in escrow on BTC (in tokens), in ETH and ETC as hardwired into the blockchain, as well as ERC 20 tokens. If you take a look at IXC’s explorer you will notice it reports a satoshi price of x10 its current value. The reason for this being that 3 coins come back to the root between I0C, IXC, DVC by current definition of a coin. Each will have 33.333 corresponding matches on tokens on another blockchain:
So 99.999 M tokens will exist in a quantum state along a Bitcoin ledger with 99.999 M coins. How about Devcoin? Does the token escrow service from the BTC ledger have a corresponding match in tokens? Also, some Devcoins certainly are coins, do they balance anything out in ERC tokens?
There are a few accounts for ERC 20 tokens, but this one pushes the total just over 100 and under 101 M in tokens. This accounts for the fact that the genesis block also must have a coin that originated within and went out of it. My best guess is this is Namecoin’s only place where it was a coin and then proceeded to make quantum copies of all merge mined coins while changing their names as well during the “forking” part of merge mining.
The thing about being just over 101 means we get a quantum blockchain that combines three coins into the root (coinbase) which came out with a genesis block and tx, and went back in with a genesis block and tx. From the last output we can move forward into the quantum future of a 100% minted and fully mined BTC blockchain. The truth is we are no longer 99.98% minted, the uptime recognizes two outputs that surround and change the Bitcoin genesis block to Block 1 at Blockcypher (99.99% uptime means minted and connected). The last part will be merging back through Namecoin into quantum “Bitcoin” and if you ask me it will not be very hard to get to this point. Going peer to peer forward will decentralize the network completely from its experimental phase. The Bitcoin Core developers already ran the test to link the network here and it involves simple changes in the software code.
The motto of Devcoin is interesting:
“From the many, one
From one, the source”
The website, devtome runs on PHP and is the only missing “peer” in the current operation of Devcoin software. It was removed on purpose and the admin of devtome is unknown. Devtome has no Bitcointalk.org account. The simple answer here is that the “me” is Satoshi. If you do not believe me then why does the “Satoshi” client for Devcoin work behind the scenes in two states that are to connect through it to produce a quantum and coherent network. What will reverse entropy? What will bring order? The Satoshi client. Filling in blocks from -1 to the empty string of 0’s (parent block) as well as filling in the quantum blocks that are yet to be revealed. If you ask me the current value of Devcoin can probably be calculated in relation to the amount it currently reflects, but I won’t attempt it unless I get bored. Devtome, going back to Satoshi (the one developer). From one we get the source transaction — the coinbase transaction and index. That will spring us forward into the future as a fully decentralized P2P run network with digital currency that infinitely scales. It can be built on top of and is interoperatable with other blockchains and altcoin blockchains that were born from it. The chances of other coins being part of merge mining are unclear, at least in this class “version 1”. All raw blocks for these coins reflect the correct version. You can read about the first merge mined coins here at a website called “Null TX” (the Null Protocol mechanism which proves I0Coin has a BTC value before going quantum via Hash 160/scriptpubkey matches and OP_Return).
Quantum Superposition: Matching in Each State
The two states must make sense. What is a coin on one side must be a token on the otherside and vice versa. So what about a UTXO? On Ethereum and Ethereum Classic UTXO’s are held in certain addresses in a corresponding model:
Two types of record-keeping models are popular in today’s blockchain networks. The first method is called the UTXO (Unspent Transaction Output) Model and the second one is the Account/Balance Model. The UTXO model is employed by Bitcoin, and Ethereum uses the Account/Balance Model.
Meaning the UTXO’s are reflected in Ethereum 0x- prefixed accounts for their Hash 160 scriptpubkey address on BTC. The trapped Ether and ERC 20 tokens at 0x0000000000000000000000000000000000000000 and 0x0000000000000000000000000000000000000001? They have to match with UTXO’s in Bitcoin at “0000000000000000000000000000000000000000” and “0000000000000000000000000000000000000001”.
But what about the missing value in tokens? Look no further than the OMNI Layer for that. OMNI Layer has a token layer above the Bitcoin blockchain. If you take the USDT market cap of 2.41 B in USD? That’s awfully close to the token value of ERC20’s (2.44 B) at address “0x0000000000000000000000000000000000000000”:
That is just one simple way to relay the amount trapped in corresponding strings. The Ether at this address is valued at $3,164,502.10 USD and probably corresponds to the unspent Bitcoins at the empty string that corresponds.
This is just an example of the kind of balance you find on the quantum ledger. The math is worked out perfectly, the forks on one end are joined by Bitcoin forks on the other end. If you recall many coins had a “birthday in the past week” and in the next two weeks the original merge mined coins will have their “birthday” as well. You can see “birthdays” are just when the public availability began for these coins. Remember when I0Coin “died 3 times” and Bitcoin’s testnet was “reset three times” before 2013 from the beginning of this post? One in the same meaning. We can definitely use the information and hard facts here to see what is coming next for these original merge mined coins:
WWA1961: From the Many One, From One the Source, [E]pluribusunum
After finding that Devcoin originally updated from my root source theory in I0Coin and took part of its output in this current state I decided to look more into the creation of its repository. What does Devcoin do, why is it named “WWA1961/Devcoin” — the user only created the repo for this update of DVC. Then I found a document from 1958–1963 (a PDF) with many explanations of “WWA” and other functions Devcoin is possibly using to rewrite history and bringing us back to the future.
Within this PDF I was able to find a lot of significant meaning around “WWA” and how it meant “rewrite alphanumeric”. There is association with octals and starting blocks and ending blocks of data. There are reading codes for alphanumeric and reverse as well as writing alphanumerically and re-writing alphanumerically. The code there gave me a way of seeing how the meaning of WWA applies to Devcoin and once applied to coins on the way out (forking phase).
Funny name aside “mobidic” — there is a reason that particular rewrite is explanatory of correcting a lot of the coding we see in the current planned state of chaos. After Devcoin is done with its “WWA” we will see the correct ledger very, very soon.
It is said that the NSA created Bitcoin and here in fact is a US Department of Defense root in the madness as well. To say they created Bitcoin is absurd, but they definitely signed off on it. Otherwise anyone running a token called “USDT” would’ve had a broken down doorway and a life sentence in a CIA prison cell at the very least. That brings me to Devcoin’s motto “from the many one (Satoshi), from one the source” and their global receivers list of 1-prefix pubkey hash’s that are formatted “Pluribusunum”. Pluribus unum is on United States Currency and is in fact very similar to the Devcoin motto:
“ A motto of the United States; Latin for “Out of many, one.” It refers to the Union formed by the separate states. E pluribus unum was adopted as a national motto in 1776 and is now found on the Great Seal of the United States and on United States currency.”
Global receivers lists can be found here and they are missing a corresponding row of addresses. My guess is that these corresponding addresses are for the influx of USDT tokens set to hit DVC addresses… Perhaps USDT was even created out of USDT. The original source, the US Dollar backing the project. That makes quite a bit of sense now that I think of it.
Client Procedure
Receiver.h accesses a synchronized list of receivers.
For example, say the devcoin client requests the height 9000 receivers, the height step is 4000 and only the root receiver_0.csv saved. Receiver.h will first look for the receiver_2.csv file. Since it’s not there it will step down and look for receiver_1.csv. Still not there so it looks for and finds receiver_0.csv. It then downloads receiver_1.csv by looking at the peers in receiver_0.csv and saves in the data directory. It then downloads receiver_2.csv by looking at the peers in receiver_1.csv and saves in the data directory. Once it has receiver_2.csv, it parses it to get the list of receivers and uses height modulo list length to return the receivers for height 9000.
Receiver also looks ahead, after it is a random portion between 0.75 and roughly 0.95 of the way to the next step so that there is no mass downloading when the block height switches from x999 to x000. To resist ddos attacks and to work even when some web sites are down, it picks the page which the majority of peers have available. The step size of 4000 gives an update roughly each month. (NOTE: here is a way of corresponding to BIP34 which is a part of BTC, but not I0C)
Disbursing the Share (Receiver files in Devcoin)
The generation share is 90% of the block, which is 90% * 50,000 devcoins = 45,000 devcoins. It is disbursed to the devcoin addresses in the receiver file, in round robin order. In each generation round, for a given block height, the index of the line of addresses is the block height above the start of the round, modulo the number of addresses. The code snippet for that follows below.
So who is returning the “mining fund” and not tokens to match the Devcoin reimbursement? That would be IXCoin, which is returning the “mining fund” and almost updated to v16.1 — which will be completed by 08/11/18. Three days after 08/08/18 when the Devcoin block explorer expires on Chainz. There is a block explorer available on the cloud to keep balance. It is quite interesting, will something happen on the 9th? The 8th? It is likely the beginning of something for the Bitcoin mainnet.
Perhaps the E-prefix of E PluribusUnum is missing from DVC because it is missing ETC Block 0, Ethereum Classic which is born on a date in the 1960’s in one time format. Is the root date not 1970 as I previously thought but a time dating back to “MOBIDIC D” in 1961 (at least between 1 July 1958 and 1 February 1963)? Perhaps. What I know for sure is that as soon as you add Ethereum Classic to “Coinbase” you will get the correct ledger on the first place to allow a funnel of peer money into Bitcoin. On the way out, Coinbase the company has to be crossed once more. What I have thought all along is likely true. Coinbase doesn’t have to list IXC, I0C, NMC, and DVC because they are already Bitcoins. The definitions and developer testing of merge mining strings for a new coinbase prove this plan. We will finally see the first class of merge mined coins reflected in their true value. However, the coins could be kept as a copy in the same way we saw “Bitcore” distributed 1:1 with BTC public keys. They may then be sold as a finite amount of assets or take on other roles. I cannot predict what happens after the merge, only that the merge will show in Block Explorers and the proof will be there where the actual coins in three major ledgers BTC, ETH, and ETC came from.
The fact is we are ready to run a two-state peer to peer quantum cash system. There’s quantum mainframe computers to process, AI to manage a decentralized system, smart contracts to carry out automatically, and decentralized methods of exchange. If this isn’t enough to make you believe that BTC is a ledger reforming, then maybe you should have a look at its true value without actually having “BTC — Coins” within its books — yet.
In a true sense, the Bitcoin ledger is going to receive its value last. I can’t hardly wait for that moment.
What would forward and backward hash rate look like for the unified network of the merge mined coins I covered in this article if they met a protocol that recognized a state reorganization, say 0x?
RelayXCore is the github directory for Relay — which offers a dual blockchain solution (two-state solution?) for anonymous spending.
Here’s the exchange website where they are partnered with 0xProject:
Groupcoin & Other Merge Mined Two-State Math
In 2020, John McAfee predicted Bitcoin would hit $1M USD per coin. I think I know why. If Bitcoin running forward has always been I0C and “BTC” was merge mined from the start, then perhaps order one last surprise awaits BTC.
Groupcoin (Quick Description):
GroupCoin the predecessor to Devcoin (discussed below), is a coin where developers could test some ideas before implementing them into Devcoin. Additionally, by applying merge mining to GroupCoin first, the developers could fall back on this solution in case the updates would not work out with Devcoin. GroupCoin is an “inflation-forever” coin, which will continue to generate 50 GRP per block until it is no longer actively mined. Groupcoin only has a market cap of US$1,170, though.
If Groupcoin is the predecessor to the last merge mined coin for the first merge mined coin, then Groupcoin came first as well. MarkM describes how he developed GROUPCoin on Bitcointalk.org:
The thing is — today we see GRouPcoin adding 3 more capital letters to become “GROUPCoin” and it still has a working block explorer — meaning someone is still running its operations. If Devcoin is about to unleash USDT and pluribusunum on us from one end, there has to be a matching part of the past that will release the other store of value. Bitcoin is “Gold” and Litecoin is “Silver” is something @SatoshiLite says quite often. GRP would make the fifth merge mined coin + BTC. If Bitcoin exists in the end as a coin it must have began as a coin as well. Not in the 1960’s per say, but something will be added from that ERA as a store of value.
Could it be Gold? Here is GROUPCoin’s only working block explorer from CoinMarketCap:
Coin-days destroyed is probably a reverse operation reflecting “Bitcoin Days Destroyed” which was last updated on June 17, 2011:
GROUPCoin’s Gold Pieces block explorer stopped transactions yesterday at 1:05 UTC… In the first hour it reduced coin days destroyed from 82.8849% down to 82.8826%. If it is reducing the % of coin days destroyed that would be the inverse of the definition. Bitcoin’s are not being spent but returning as “unspent”… I know it’s confusing but why Gold Pieces? If the truth is that three ledgers will be linked at one genesis and that will reflect on the BTC ledger (3-to-1) — and that occurs in Devcoin (Pluribus Unum) then what do we get for GROUPCoin?
First, Version 1 may be the merging of NMC, I0C, IXC, DVC into one Bitcoin and the amount of USDT as well as other high cap tokens like “ADA” (Charles Hoskinson worked with ETH, then ETC, then begins ADA). Throw in another $3,286,894,356 market cap from NMC/I0C/IXC to Devcoin to the I0C/IXC/NMC source of Bitcoin.
If “Gold Pieces” is GROUPCoin’s block explorer and on version 6, maybe the best is to come slightly after BTC forms its super ledger and hits $1M in value. The address on Ethereum that may hold the key for GROUPCoin’s addition of Gold and Silver? “0x0000000000000000000000000000000000000001”
Currently there is about 2.5–3x the value of the 0x0000000000000000000000000000000000000000 account in ERC20 tokens. About $6.4 B in total USD. The majority of that value comes from a contract address with a contract for the ERC20 token:
So why do I think “Gold Pieces” is the ERC20 token’s contract on Ethereum address 1? If address 0 is USDT, then address one? Gold:
There is a blockchain linked at this particular ERC20 token address too, linking to the “Belance Blockchain”… funny play on letters, there is “balance from Ethereum to A”… Remember Bitcoin “ABE” is the creator of “Bitcoin Days Destroyed”… Then Ethereum needs its own amount of “coin days destroyed” which I liken to Gold Pieces working inversely… If the amount of USDT was able to fuel Bitcoin to $20K we can expect at least 2.5–3x that by the end of the 4th quarter — because Bitcoin is math. However, gold being added to the blockchain would be something else. As of a few weeks ago when the amount of “coin-days destroyed” was much higher, meaning there was a value in this account not yet reversed, there was 10x the amount of address -0 in address -1. Is the suffix -1 of the account that held the amount below weeks ago a sign of the root block ETC -1 adding in $22.4 B in ERC 20 Gold?
Nick Szabo created the concept of BitGold in 1998 and it is thought of as a direct precursor to Bitcoin. This was one year after Hash Cash was proposed in May 1997. Hash Cash was officially written in a whitepaper released on August 7, 2002 and is said to be Bitcoin’s proof of work. The proposal never implemented is still a “precursor” to Bitcoin. Unlike USDT and USD Szabo wanted to create BitGold becuase, “ “I was trying to mimic as closely as possible in cyberspace the security and trust characteristics of gold, and chief among those is that it doesn’t depend on a trusted central authority,”
2018 is 20 years from the proposed BitGold. If it is a precursor to Bitcoin it could be the fuel at Block -1. ETC Block 0 could be the beginning of Bitcoin for merge mined coins besides GROUPCoin. GROUPCoin may be added through ERC20 (20 years since 1998) to add gold to Bitcoin, as a store of value that doesn’t depend on a central authority like US Currency. So from Devcoin we get a connected Bitcoin with US Dollars invested within, among other tokens that did their part in connecting the blockchain and protecting the actual minted coins themselves from version 1 of merge mined coins. We can then assume the back tracking to Block -1 is the last store of value to be added, in Gold, through ERC20, through Gold Pieces, through one version of implementing GROUPCoin forward will be the last wave of stored value that hits the blockchain before it scales forever. Because GROUPCoin only has one implementation it seems that it also provides a cap for DVC so that they both hit a hard cap before decentralizing completely. Add in the ETF “Exchange Traded Fund” (Think Binance profits…) and you have a nice institutional investment in the true Bitcoins before the full truth is revealed.
Everyone wants to know when, so I will try some math to explain.
First the past has two points of genesis, one decentralized (ETC Block 0) and one centralized (XLM ‘Ledger’ 0). They share the same genesis date of 1969–12–31:
The fact that XRP/Ripple had rooted in 2004 and Stellar split off of Ripple as of July 31, 2014 (4 years ago) gives an idea to the timeframe of events in relation to the decentralized matching transaction when ETC Block 0 split off ETH Block 0 on July 30, 2015 (3 years ago). ETC and XLM exist in the same timechain, but they are split. This could be how Coinbase plans on integrating the centralized and decentralized currency system. Stellar (XLM) goes out to XRP (perhaps the two merge) and then ETC becomes the one merge mined version of Bitcoin. Not “adding” XRP will be solved by the merging of XLM back to XRP. It will remain centralized.
The roots of Ripple are in this description from Wikipedia:
The predecessor to the XRP Ledger, Ripplepay, was first developed in 2004 by Ryan Fugger,[13][14] a web developer in Vancouver, British Columbia.[15] Fugger conceived of the idea after working on a local exchange trading system in Vancouver, and his intent was to create a monetary system that was decentralized and could effectively allow individuals and communities to create their own money. Fugger’s first iteration of this system, RipplePay.com,[16] debuted in 2005 as a financial service to provide secure payment options to members of an online community via a global network.
So if going backward ETC block 0 meets XLM Ledger 0 at the same date, when did BTC block 0 truly begin? It wasn’t as far in the past so as to go back from 1969/1970, but if math serves right we can say BTC began with BTC+ETH in 2004. Why? Subtract half a year from 2005’s debut for RipplePay. Then divide it by 2 to understand we’re talking about both BTC and ETH equally. The root of Bitcoin, ETC Block -1, BTC’s true block 0?
The math actually isn’t so hard. We are missing a database to match the data we get from the Berkeley DB for Bitcoin. The database with record of Satoshi Nakamoto’s original PGP key and signature reflects a date of 2004–12–09 (YYYY-DD-MM). The MIT database. Why would the root and the source of gold’s inclusion into Bitcoin and Ethereum be in YDM format? It’s simple:
If read in YDM, there are simply not many countries that use this date format. The inclusion of gold, not dependent on any central authority, led me to read the date in this manner. Could the inclusion of gold be this year, specifically in September? We do know the true date of root genesis would be this date, from Satoshi’s MIT PGP key. This date would make a bridge from the beginning of the UNIX timestamp Y2K38 problem (resetting the clocks from Jan 19 2038 to Jan 1 1970) — exactly 34 years, 9 months, and 2 weeks. I originally guessed that Bitcoin genesis was around this actual date but now I have so much more conclusive evidence. So what gives with the extra 3.5 months? We can go back to “MOBIDIC D” which lasted 4 years and 7 months, 2 years and 3.5 months when halved. If this operation to link past reading of octals had to be fixed once backward but not forward from systems using hexadecimal then we can halve the amount of time. That would bring the date going forward of Bitcoin/Ethereum’s first forward genesis to 2 years and 3.5 months ahead of 9–12–2004 (MDY) to almost January 1, 2007. This could be the date forward for the root on its first trip forward. To find other genesis dates we’d have to know when Ripple began RipplePay in 2005 and split off the centralized network from the root the first time. I won’t get into all of that. I just don’t think it’s necessary.
In 2018 we are almost 20 years (if not already) of the inclusion of US Currency (via DVC and USDT tokens) and gold/silver (via ERC20 and GROUPCoin) into the Bitcoin merge mined mainnet product.
5 coins, merge mined into one. The source could simply be gold and we’re off to the races. As for Satoshi? He seems to be the first source, making NickSzabo the second source. Is Satoshi ADA, Vlad2Vlad? Is Vlad2Vlad a screen name for Charles Hoskinson? I will never asked Vlad outright who he is, but he knows what is going on from the inside :). What about Adam Back 3? Nick Szabo 4? Maybe Nick Szabo is not Satoshi, but the precursor to Satoshi’s plan. Perhaps Adam Back contributed proof of work and is also contributing that proof by connecting the chains. The thing is, maybe Adam Back, Nick Szabo, and Vlad2Vlad are all Satoshi, with Hal Finney being the precursor in his RPOW. I don’t truly know. I won’t know until they tell me. It is funny though, I didn’t realize the clues on Twitter until I tagged all of them because I am an attention ***** trying to get the word out to the public that merging is imminent.
Maybe Nick Szabo is “markm”… Or markm is an allusion to Bitmark, which has a node at zmark.org and could be run forward by Mark “Z” himself. After all, they want to purchase Coinbase. Regardless, this collaboration involves all forms of Silicon Valley players from the computer processing giants at IBM to the Linux Foundation to every OS to social media and then out to governments as well.
Making Bitcoin the greatest world currency yet to launch a true mainnet. But it’s so so soon.
Side note — Gold Pieces is supposed to “hard fork” on January 16, 2020. Perhaps that’s just another word for “merge”… and we will see that gold infused into Bitcoin as the last store of value before decentralization.
From the many one, from one the source. — Devcoin
The first BTC developer (sirius_m) that worked with satoshi as well as on Devcoin as well is now back. He stayed very briefly in 2009/2010. You can find his work at the end of the devtome official open source code. His last date of appearance in the code was on February 4, 2010. However satoshi had worked on the code the day before and then 6 days later. It appears that we are very close to seeing the reverse happen and Satoshi’s return.
A quote on sirius_m’s new cryptocurrency “AXE” a merge of two startups:
Bitcoin’s co-founder Martti Malmi, who worked together with the infamous Satoshi Nakamoto and owned with him Bitcoin.org, joins the team of developers behind a new cryptocurrency AXE. While being a combination of Malmi’s reputation system Identifi and a decentralized database system dubbed GUN, the project is expected to push the boundaries of decentralization.
Perhaps it is A that will cross with E and merge back into the root. Satoshi is most likely back as well. It could be any day now…
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Send me some DVC for this writing…
DVC: 1Ntg236dejeK4wdwsZkCNiw7j6C7kS6S6h
or
I0C: jah8A4cvbPbBwuecebgGN1mncygdNiRixg
I may update this later, but for now, you have enough facts to make a great investment.
