Regarding Copernicus
Following the man who dared to be different — but with Bitcoin
Being different from people is something I do well. It is what I live and die with. Not always is it good to be different and take risks — no. Sometimes risks aren’t calculated enough to have been worth taking, but that is in retrospect. As an investor, I have put hours and days in a tireless quest for answers. That’s the beauty of Github — if you really want confirmation before you put your money into any crypto-investment, you can get it in open source code. A worldwide currency, technology, platform, decentralized internet processor with incentive, etc. is right around the corner. You would think more people would take a peek at Github and agree with me, but I have a feeling people are falling for the distraction of price, where they would rather obsess over Coinmarketcap and not take a hard look at some repositories of code. While everyone looks at the price for answers, I am staring at the Sun myself.
Just like Copernicus, who was proven correct in that the planets revolve around the Sun, this is the beginning of the events that will prove the gist of my theories are the truth. The code that comes out everyday validates me on that. Nicolaus Copernicus never blasted off into outer space to observe the movement of planets. He was not an astronaut. He simply made use of the things he saw and backed it up with an immense amount of research. I am not a programmer or cryptographer. I have taken it upon myself to figure a lot of that out this past year. The simple point I am trying to make is that if I can do it, the people behind the Bitcoin project have left enough out there for you to figure it out too.
If you were looking for modern examples of against the grain and heavily criticized, but eventually validated success stories, there is no greater example than Steve Jobs:
Why Copernicus?
You may wonder where my introduction came from in relation to the code I am about to present to you. The simple answer is it came from a very interesting repository on Github. Copernet/Copernicus is a repository with Bitcoin code that is preparing to make merge mining completed — joining in code and value with Bitcoin after all these years to form a complete network. Bitcoin is the trusted third party of the decentralized web, built on blockchain technology and the people’s desire to buck the internet’s corporate overlords. The clever code of merge mining and minting Bitcoins was Satoshi’s plan all along. I am quite certain it was also Hal Finney’s. I don’t talk enough about the two, because I do not even know if they exist as who they claim to be. I haven’t seen it with my eyes, but I have seen their actions in code and writing. I am bullish for my LIFE on the original Bitcoin 0.1-alpha release, which is recognized as the work of Satoshi and Hal. I am not interested in figuring out who helped or didn’t help them in that software. I am only interested in what I have found in that software’s code.
Copernicus is just one example of Bitcoin (and Ethereum) code repositories adding things that are merge mining friendly like script enabling, allowing certain coins to be transacted on Bitcoin software, and even referencing reorganizations of the Bitcoin blockchain. This is an effort I have covered extensively here so today I won’t explain what coins are important for merge mining, but rather the current and past features of software that allow for the events to unfold in the near future. Devcoin, I0Coin, and Ixcoin will see a huge boost in value as a result of the culmination of merge mining — and this will be a one time event like never before. It will be too late to catch the train once the software that is currently being prepared for public release unleashes this mechanism. I am about to say some things today that you have not heard me say yet. A side plug for my book which also has plenty of the information I have not been able to discuss here (if you choose to read it and support me, thank you).
Copernicus is currently adding code to add “Global coins” which I have seen referenced time to time in merged coin repositories. The code beneath comes from a test using Bitcoin’s UTXO set — which is where coins have been holding value in escrow/smart contract like states for years:
A series of op_codes, Bitcoin “script” fills up these tests to help facilitate the added code. These codes have always been present on Bitcoin’s blockchain — from the first time they received coins from a forked off, yet originally attached source (like Devcoin).
As these transactions and history are correctly rewritten, new transactions are formed in the very blocks the coins first arrived in. The software now is recognizing where the value was produced in these transactions, so a reflection has to be written as well as executed in scripts. This is the trustless execution of what was always promised to merge mined Bitcoins. The test process reveals the final step is recognizing the value of the “coinbasetx” which will without a doubt benefit the coins that came from that coinbase originally:
Another Copernicus test was done to simulate the merging of checkpoints at points “a” and “b” throughout the Bitcoin blockchain:
What we need to discuss is the fact that BTC blocks are only transaction records for genesis that takes place on other chains (ex. DVC raw blocks). For now, these are txs that will make corresponding blocks once matched up with actual blocks from these merge mined coins. The “a” and “b” in my theory is a Bitcoin “a” chain and an alternate coin that functions as a Bitcoin “b” chain. The code I found in a 2011 Devcoin merge mining file gives me reason to believe that Devcoin is at least one of the two:
If you still believe that is non-sense then I will remind you that in the alpha-release and 2008 “pre-alpha” release of Bitcoin (v0.01 ALPHA) there are plenty of references to combining “a” and “b” in the code:
If you browse through the 2009 release of BitCoin v0.01 ALPHA you will notice the same code for “a” and “b” here. I can prove that these two releases are “a” and “b” because the two repositories have two different genesis blocks! The 2008 version had genesis mined on September 10, 2008:
Mainly, recognize these are two separate Bitcoin chains. Notice how the top, 2008 genesis block mentions it is from the “debug” log. That is the same place I found my record of the true genesis/coinbase tx that precedes both of these genesis blocks for BitCoin v0.01 ALPHA at the empty string (see ‘hashprevblock’). This is the transaction that came “before” BitCoin from both September 10, 2008 and January 3, 2008:
Going deeper, after reading Duality and many of Satoshi and Hal Finney’s first posts I have a profound understanding of how Hal is involved in BitCoin. He was important in that he was the first one to debug (work on bugs) BitCoin software. There is a “debug” record of genesis that Satoshi never mentioned from September 10, 2008.
Hal Finney was Satoshi’s first “dev” and Devcoin began its life before these two genesis blocks as seen above. I believe Hal Finney is at the root source of Bitcoin, once the 2008 genesis block (prebitcoin) and now where the root currently stands, Devcoin’s debug log. Hal Finney creating Devcoin is all too fitting as the first publicly active dev in BitCoin. Since the forking and merging has created a reverse order from genesis to the present day, I will remind you that what once was a timechain has become a blockchain because of how software and networks are created. I will dive deeper into that when I discuss Devcoind (the Devcoin daemon) and why it is the parent block of all BitCoin. First, notice how the timechain is mentioned in the pre-alpha 2008 version of BitCoin:
It is a blockchain today and not a timechain at that point because blocks are not chronologically ordered. The passage below, from Duality, explains exactly what I have shown in code with the two genesis blocks. One genesis for timechain on 9/10/2008 and one for blockchain on 1/3/2009 (that has since moved to block 1 because of the metadata and upgraded API available at Blockcypher).
The record of genesis in 2008 mentions it is a timechain, which by being mentioned in Duality as well as in one of the earliest — if not the earliest — codebases to mention BitCoin (2008) confirms my beliefs that whoever Satoshi is wrote Duality. It seems like too much of a coincidence to have come from an imposter and it has too many relations to the code found in BitCoin’s pre-alpha and 0.01 ALPHA releases. To me, Duality has proven legitimate because of the facts front of us.
I want to discuss what has happened to the three genesis blocks I have described above. The two BitCoin genesis blocks have a previous transaction with an empty string address (all zeros). The parent block became visible as a record of Devcoin’s genesis in 2011 and precedes both BitCoin genesis blocks on the blockchain (order in time does not matter). A very interesting find in the 2008 main.h files explains where the timechain saves its blocks:
That part of the code is exactly the same in 2009’s v0.01 ALPHA main.h file. Both genesis blocks save to blk0001.dat files. That brings me to the Devcoin parent block once again:
The only place you can view a record the parent block’s genesis/coinbase tx is on Devcoin’s debug log. The position of where this transaction was recorded is at “blk00000.dat” which would come before any blk0001.dat files in a database even though Devcoin records its genesis block last of the three on 7/22/2011. The reflection of what I just stated is why Blockcypher recognizes the 2009 genesis transaction as a Block 1 as BTC currently stands (incomplete, without a Block 0).
It’s important to understand how software and networks operate to see how this order played out. Devcoind is a fork of one of the earliest Bitcoin daemons (bitcoind). When a daemon forks the original, a parent is born and immediately cuts off from the original, now child, daemon — which made bitcoind child to devcoind. Officially, devcoind (the daemon) and its wallet are as described by devtome.com:
The Devcoin daemon is a fork of the Bitcoin daemon and the client is a fork of the Bitcoin wxWindows version.
The legacy of the timechain and first BitCoin blockchain are merged into one file that Devcoind has a record of preceding. Forking the bitcoind daemon created a 50/50 split between both BitCoin versions (pre-alpha and alpha) and Devcoin today. Devcoin’s raw blocks ARE Bitcoin’s raw blocks. However the part of Devcoind that is missing is most likely the timechain’s path back in history to its own inception. First, you need to understand how a daemon is created and how it becomes the parent in a blockchain by forking the original:
In a Unix environment, the parent process of a daemon is often, but not always, the init process. A daemon is usually either created by a process forking a child process and then immediately exiting, thus causing init to adopt the child process, or by the init process directly launching the daemon.
The devcoind daemon also had other responsibilities:
“ In addition, a daemon launched by forking and exiting typically must perform other operations, such as dissociating the process from any controlling terminal(tty).”
The devcoind daemon also had to dissociate with the terminal that used to control “bitcoind” which would be why it rewrites transactions, connects between -1 and the parent hash of bitcoin (empty string), and stores the new transactions and reorganized records in the decentralized database (nodes). The whole point of Bitcoin being decentralized is the fact that it isn’t connected to a database like BDB, rather it runs off nodes. Hashcash uses a database for POW.
The github repository where the of devcoind, the forked daemon, and its codebase are available is at knotwork/old-devcoind. That is the same place where main parameters and auxpow files mention a coin “a” and “b” — just as the original BitCoin pre-alpha and v0.01 ALPHA code bases do. The reason Duality is “dual” is because there are two blockchains, and one timechain.
Because both BitCoin records from pre-alpha Bitcoin and alpha Bitcoin 0.01 have written code about connecting timechain and blockchain on their main.h files and record their data at the same blk0001.dat file, there are actually 3 genesis block records for 1 merged Bitcoin alone, and that’s not even accounting for the timechain birth after the parent block in 1970. I also believe that two of these genesis blocks, Bitcoin and prebitcoin, share a genesis block at the root of Devcoin at blk00000.dat. If you take into account that at genesis, what looks like a 50 coin reward was sent out for DVC, but without a block available, there may be no tokens issued in the corresponding raw transaction. Or is there another source of “tokens” at what will eventually be the genesis block (or half of it)? The term “log2 work” is used for POW in Devcoin, as seen in the debug log. I bring that up because the value for DevCoin at genesis (and as the parent block) may be in its bits.
There are 3 measures of value when taking into account proof of work and expanding with RPOW (which is recyclable proof of work). If POW goes forward from the 2008 genesis or earlier, it is all about the time spent (seconds), energy expended (bits), and laying down scripts for future redemption of POW. Think I am wrong? I suggest you read through each update on Adam Back’s Hashcash repository. It is definitely a part of every phase of Bitcoin because POW is how all UTXO’s will eventually be spent — unleashing value into anything Bitcoin has merge mined with.
I just couldn’t help but notice that all my questions were answered about scripting and how the general plan was made for this project a LONG time ago. There wasn’t one magic creators who came and left. He never truly left. The test was on the developers to finish the work and people to take advantage of the long hours and years of work developers put in to creating not just decentralized money, but decentralized EVERYTHING. Hashcash has been stamping and scripting just about everywhere coins or tokens that matter exist.
The last update for Adam Back on November 14, 2016 is where it gets truly interesting. If Hashcash POW went forward to stamp and lay down scripts from whenever the first Bitcoin was privately released, it could be working itself backwards as well. Let’s say the letters “HC” are just as important as the letters “BCH” — a codebase that has got my attention lately for enabling the necessary scripting to make merge mining complete. I have never given too much though that the value has been in scripting, thus Hashcash from the beginning. If there’s a Bitcoin A and B, then what about a proof of work A and B, or even A/B/C? A day after Adam Back stopped implementing upstream (think merge upstream) updates for HashCash someone deleted a whole file of HC v1.1 code that had been up since 2006! It probably explains why merging upstream is not helping DevCoin and other v1 merge mined coins receive their value back yet. The front end of Hashcash is done, but there was an early version cut out of the picture. Deleting files and possibly storing them somewhere for later. Just know that the blocks of these coins are filled with scripts to return “bit” value back to them.
Taking into account that Hashcash released its first 1.00 version on 07–08–2004 (that is DD-MM-YYYY format), then maybe we are about to head backwards with proof of work redemtion. Almost exactly 2 years later BCH (Hashcash “B”?) is working hard to shift scripts and flip scripts to make them readable. Flipping the script on one end but still having forward proof of work is the most quantum case of superposition ever, but then again, so is forking to become a parent daemon and then re-merging. Or even putting out an alpha version of Bitcoin with one genesis block while having a debugger working out there to go back and connect to a past or withheld genesis block. The debug log showed me the actual null string tx from the original timechain but it took place after the genesis of Bitcoin. You have to think both forward, back, up, and down to understand computing does not care about chronological order! Neither does decentralization. So Devcoin works as the parent, debugger, a bridge from past to present internet, and at the same time it is split off somewhere (likely by a day, just like Hashcash) and relying on another platform to pay its way back to the coinbase. The coinbase tx could have taken place sometime in the past, but blocks reorganize. Dates on blocks change as I have shown a few times on my twitter. The timechain days are over and anything is up for grabs. Hashcash could be doing its forward scripting through RPOW, which is based off of it, or even going backward with the debugger. Whatever direction, work is work. When people say Bitcoin uses Hashcash for proof of work it is to lay down redeemable scripts on the coins, bits, that are produced onto blocks. There’s a number of ways to slightly disconnect the network so value doesn’t return until its planned to, but once it does the DevCoin daemon assures me to know we will have a fully decentralized Bitcoin mainnet.
I have my reasons, some speculative like there being a Proof of Work A, a POW-B, and one that is a merged copy of the two. What BCH does is very similar to what I expected and it is hard forking two years to the date (November 15, 2018) from when Hashcash stopped moving upstream. Is this where Hashcash “flips the script” through the power of Bitcoin Cash??? Take a look at Bitcoin SV (updated from Bitcoin ABC):
The whole point of Bitcoin is to prove all people in society can work together without screwing eachother over. Money is the ultimate test, but the actors have done a great job hating on eachother, the news “outlets” have done their best to spread fear uncertainty and doubt, and the coders who will be paid in Devcoin have done a great job participating in the Prisoner’s Dilemma by being silent while leaving the truth in open source coding at Github and elsewhere. There are good times ahead for the alternate “b” version of Bitcoin! I believe there’s three of those in the end, with Namecoin being somewhere in that mix, possibly just as a layer to purchase internet domains on the decentralized web. There’s DUP’s spread everywhere too, so when I believe there’s 3 I really mean 6, and so on — but the most integral were the ones that came first. The first altcoins to merge mine with Bitcoin are special in ways that is obvious only to the people who immerse themselves and study these codes. For the coins issued there are tokens and for those tokens there are scripts to exchange value with real Bitcoins. For example:
- Devcoin is the parent hash because it forked off the original Bitcoin daemon, bitcoind in 2011. It works now to disassociate Bitcoin from the original timechain. It will later serve as a bridge between the decentralized and centralized web.
- The original 2008 November release of Bitcoin 0.1 and subsequent release of Bitcoin 0.01 ALPHA is similar to the 2011 debug record of the parent transaction of Devcoin. This is also the coinbase tx at the null string and COutPoint (remember Libcoin, What is a Coin?). Since proof of work may have had to run back and fork off the 2008 or 2009 BitCoin daemons, I believe that the work was credited to Bitcoin and now reflected yet onto Devcoin. Devcoin could be effected on one side even by something like a deletion of Hashcash 1.1. Devcoin is like middleware that feeds inputs and digests outputs. Bitcoin is all about information theory, and I believe that is exactly what Devcoin is protecting and debugging for the mainstream release of decentralized currency, Bitcoin.
- What you see at the moment is Devcoin rewriting history on the daemon, and that’s what daemons do. They WORK hard. They call Devcoin a token currency but it is unique in that it’s the only legacy address chain (pubkey) and that it mints Bitcoins on its raw blocks while directly attaching the value of DVC tokens in raw transactions. In the end the value of these tokens will be realized when scripts recognize the value of Devcoin tokens. However, you should know that Bitcoin is a COIN and in the end this will not be the same for future tokens because they don’t have years of script and minting to tie up value in them. The version 1 merge mined coins are the opportunity of a lifetime. Just as POW software has gone back to v1.00 (like Hashcash), or Satoshi’s Vision resetting to v0.1.0 for their November hard fork, the script will return the value of the coins as well. The parent is where you will make the most money.
- It’s important to understand that RPOW is a quantum like token currency in that it runs both ways and as the glue in between. RPOW is both issued and collected to be reissued again, thus recycled proof of work tokens. Hashcash is like cash put in escrow only to be released in the future. It’s not just the Bitcoins in escrow either, its the assets of information embedded in the blockchain that Ravencoin is about to release to the world, reserve currencies flooding out to penny coins like Devcoin when they were invested long ago. Lastly “bits” of code from POW, specifically “nbits” are being sent back to the coinbase. Think miner fees. Where those are headed is to the coinbase because the store of value for everything FOREVER benefits all crypto holders. Take a look at the transaction below for proof of this:
The transaction is for block 141,755 is from the “nNonce” part of the original November 2008 genesis. Since the parent hash precedes the earliest record of Bitcoin genesis and data showing that it writes to “blk0001.dat” I believe the result of this spent transaction comes from a redeem script that sent it back to the coinbase. It did not just redeem its subsidy of tokens (50 BTC), but it sent an extra .074 BTC with it. The miner in this case must’ve mined a block in the past to accept that payment. It may also be headed back to the input to pay off a “witness” — which is a script enabled feature that uses sidechains and child blocks to map back to the coinbase. There are hex-coded bits going back to the coinbase through the input. There is your RPOW feature that must be done to mine a script POW and redeem it. The answer is decoded as a script first to see how many bits are going anywhere first. That appears to be 436816518 bits.
"04864a091a016b" Hex Value + script address"result": {
"asm": "436816518 107",
"type": "nonstandard",
"p2sh": "38R8nqymnzEfzNPpZGLZcFxQ8WyPR8TJe4"
},
"error": null,
"id": null
The witness id is “null”… If we go to Blockcypher we see the same transaction shows the witness is the null string (empty zerohash) from the coinbase and that the bits are, in fact headed to the coinbase by the p2sh address. This type of transaction is how Bitcoin SV plans on spending outputs in the UTXO set backward to the coinbase transaction!
436816518 Bits = .00436816 BTCThe .074 BTC were sent another direction when this transaction spent itself the first time. This is the so called "change" leftover in bits to be sent once again. If converted inversely to Devcoins, it could be like sending 4.3 Bitcoins forward in full value toward the coinbase. The script to execute is described further on as a "alternate" counterbalancing stack so it could be used to trigger even more value from escrow scripting somewhere else. It may even just be used as RPOW right now only to be redeemed once the network has settled in the direction its headed once merged.
Blockcypher data doesn’t show the transaction going back to the coinbase transaction exactly, but it does reference the null string. The reason is because this is issuing the same type of “forward” transaction that happened in the past, but back to the past where it no longer has a completed record. The transaction was probably unspent on first relay to the BTC UTXO set. The blockchain.com record shows the transaction spent as of
2011–08–20 11:37:10.
The forward proof of work being laid by HC stopped in 2016 and I believe this was part of it. What appears to have happened was an opposite facing transaction using the same type of script to send “bits” back to the coinbase without redeeming the final part of the script “back” so that it resides in the coinbase “null string” which is also why the withness is not shown on Blockcypher — which claims the transaction was relayed three years later on 2014–11–18.
The last part of the script to be redeemed is in “bits” which we also converted from a hex planted on this transaction in its forward running script (double entry accounting!). The opcode here will send back value in bits. The reason why .074 was issued along with the spent reward on first execution of the script was because it came from somewhere else to fund POW and RPOW. RPOW can get reused. The Opcode OP_TOALTSTACK will send this coin to the output it needs to reach on the “null string” … because the first genesis block was merged into the next genesis block, and the two record all of their data on blk0001, the bits need to be pushed forward and flipped onto the “alt stack” created when the two Bitcoin genesis blocks merged. The last part of this is they have the entire stack executed and all value is sent to the future genesis block. Just as fees get pushed forward into escrow, they may be pushed back into escrow for a time by being flipped onto a stack, even with a spent block reward! Lastly, redemption of these bits sends them off to the coinbase, parent block transaction. Eventually the “null string” will have been id’d and connected to these blocks as they currently stand so all three records of the final product are realized. That is a major operation that is about to go down as the entire universe reorganizes towards the alternate source of sunlight, alternate blockchain “b”. Merging into blockchain “c” but also have counterdirectional balance in ways that work forward and back like you see here.
Starting with Bitcoin 0.01 ALPHA (think 1/3 of the first/future genesis) you can see that “50*COIN” is nowhere to be seen in the main.h parameters. However, this alpha version is not how things ended up playing out. What you see here are “satoshi’s” which can be converted from satoshi to “bits” by knowing there are 100 satoshi’s for each bit. These values are actual “bits” that miners mine and then leave in the UTXO set for the most part. Just as Satoshi mentions in Duality, the confirmation is actually 120 (the combination of the 20+100 is because the original Bitcoin code is not 2 parts combined into 2, but an A, B, and C that make one ultimate “D” going forward.
The above is the main.cpp file from the Bitcoin “0.1.0” release. The 50*COIN ends up being equal to something entirely different in the future. It won’t lose value, but the value will be recognized more on the otherside of the equation when an alternate measurement is expressed. Right now I believe it when I hear Devcoin tx’s (think tokens for RPOW) are off by 3 decimals. They could add three zeros and be thought of as .5 Bitcoins per block (as they are currently both Bitcoin and token). They can also be thought of as 1/1000 the value of current and future Bitcoin’s. Or, they could be exactly equal to Bitcoins because they are represented by nSubsidy and to be redeem scripted back to the source of value. The bits and subsidy return to the coinbase Devcoin has come forth from. What is happening in this case has to do with double entry accounting, which makes Bitcoin quantumly superpositioned with entries and changes of directions that help it scale literally any which way. The effect in the future is 1000 DVC = 1 BTC, or effected by bits going back into the coinbase from POW, we may see 1:1 value of what was once token/coin and now one super evolved Bitcoin:
The explanation in the caption explains how this transaction was born, but then also likely spent to the Devcoin “new parent hash” before it was removed from record. Think of parent hash from 2008 disappearing once BTC genesis happened on January 3, 2009. Then think about how the genesis block from 2008 was only 1/2 of block0001 at that point with the parent hash only popping up briefly on 07–22–2011. I am not entirely sure when it was removed but the record remains on the nodes in the network through the debug log. Because the altstack is left on the debug log we can assume that at least some of these subsidy tokens will be exchanged for mainnet, merged Bitcoins which will be coming from the genesis block that was scrubbed on January 3, 2009. Because half of this subsidy went forward, I believe the first part is headed to part of the first parent hash appearance. The other half will have to be “flipped” and then redeemed at the end of the altstack once the genesis block and coinbase tx are united at point “c”… its really that simple. ;)
Measurements and Building Processes
Databases, Nodes, Daemons, POWs, Scripts, Tokens, Bits, Coins, and Cents
In the beginning of the internet until the early part of this decade the internet was a centralized entity that keeps information on centralized servers. Bitcoin is using its Devcoin daemon to change that by rewriting transactions and storing valuable information securely, using cryptographic hashes, on P2P nodes. The debugging record is there for us to see, but the private keys are not. Bitcoin will always be decentralized and safe because of that.
In transferring from the timechain (chronologically ordered) to the blockchain (any order it wants), Bitcoin will always reflect the truth through its blockchain and automatic execution of contracts once centralized development is over. Hashcash and RPOW are the basis of script function and once the cloud and nodes take over where those two functions may have been storing info in the past (like the Berkeley DB), we may finally have data that is hosted by no one who can hurt it. There will just be nodes that put scripts in and execute them. The expansion of storage achieved by cloud and decentralization of servers and signals alike allow Bitcoin to scale. Servers get overloaded by the internets data history, scaling was a must. The following occurred in 2009 when Satoshi and Hal would discuss the client crashing due to database overload as well as the security of that timechain record. The timechain data as well as future database usage gives reason to completely rely on decentralized storage and scripts in the future. This is what we are building toward.
Satoshi attributes his first “dev” and debugger, Hal Finney for keeping Bitcoin running the first few days. This is likely why we have new genesis blocks revealing themselves through nodes and scripts, but also why Devcoin carry’s on the blocks on which Bitcoins are minted. The entire system could have flipped with Hal, with the original pre-alpha release going right along minting “token currency” on Devcoin only to reveal the coinbase and parent hash at a later date, and then hiding it again once it resumed minting Bitcoins on its raw blocks. Or, the opposite could be true. What if Devcoin raw blocks are really just the future of coins and the value flips but is balanced out by merging with bits that were redeemed through POW and RPOW tokens. POW tokens may have value, but RPOW tokens could be like the glue no longer needed to issue and redeem “two way tokens” between networks once completely decentralized. All that will be needed in the future is a smart contract to mint as many tokens as you would want but right now Bitcoin’s value is still maturing towards a mainnet. The money tied up in scripts and money potential in Devcoins is too valuable to corrupt, so IOU’s and checkpoints are issued out. There are times where Bitcoins were not minted but the value accrued and flipping of stacks + script execution for escrow and POW will connect all meaningful v1 COINS. The coin value will be decoupled from tokens entirely once the main network is read. From there whoever wants to issue tokens will have the security of the blockchain but the value will have to come from elsewhere.
The old proof of work was likely related to the timechain log1.0000000001 and it represented a value of -10 when converted from hex to decimal (satoshi). The -10 BTC value is likely why the first coinbase tx output to the NOV 2008 Block 1 was enough to pay the 1*CENT (10000 satoshi) mining fee. The genesis block will need to be mined once more and at that point the 10,000 satoshi (adjusted forward to 10 future Bitcoins) will have been enough to fund the transaction back into the parent block/coinbase. Remember that the transaction from first genesis became 1/2 of the future Block 1 (Now Jan 9, 2009). The 10,000 fee was probably paid in Bitcoin to Hal Finney at a price of 10 future BTC and will have use in the future as we wind back to go forward! Confused yet? See the transaction below, the 40 BTC probably comes from the Devcoin parent hash block before disappearing after July 22, 2011 by a P2SH forward that will ultimately have a corresponding 40 BTC + 10 BTC (from Hal) pushed forward into the new parent block/coinbase tx. Whether we see the other 1/2 of the missing November 2008 released “block 1” remains to be seen. It has a timestamp from September 10, 2008 for when it was mined originally. It could be in a database somewhere, or in a sub-directory as Satoshi mentioned above. What if Hal kept Bitcoin running as a “token currency” and dual-stack blockchain on say, Ethereum, only to have it fork to match moves made on blockchain “a” that was just issuing tokens and recording escrow on its nodes? There may be a lot of secretly mined blocks that we thought were Bitcoin but were actually mined in the creation of Ethereum. A fork may have separated the two enough in code where they have to fuse at a future date, but that’s as easy as a coding change or a database record that shows this actually did happen. What if Hal finished the decentralized work of RPOW and issuing redeem scripts for merge mining to Devcoin (the orignal debug chain)? D, does mean “Eth” and even more coincidentally the last hashcash merge upstream on November 16, 2016 issued a “MAX_DELTA” = 10,000 value. Delta is also representative of the number 4, and Devcoin is currently known as the “4th fork” of BitCoin. If we are talking about tokens, we are talking about where to connect 10,000 to the original output of 10,000 from the 2008 genesis. If Bitcoin moved from its first Block 0 to Block 1, this would be a way to move back to Block 0. Where this would happen we would also see nBits from the 2008 Genesis Block “1” sent half backwards to the new Block 0. To further confuse you, there are 5 ETH and 5 ETC unspent that would make a total of 10 Ether(s) headed back to the parent hash. That would account for all of the nBits that were at Block 1 in 2008, and then Block 1 has sent an equal amount of bits/COINS “Bitcoins” back to the parent block. The most confusing part of all would be recognizing that Devcoin may show the parent block and coinbase tx, but half of Devcoin was making tokens after forking the Bitcoin “bitcoind” daemon. The process of killing off its children may come after extracting all of the value out of the original Block 1 when it is no longer needed. The entire blockchain can merge and the Ethereum level can just be the final process with Bitcoins on it as a store of value. Hashcash describes how it can “kill children” blocks through script in a 2006 release by a guy called Hubert Chan (HC):
It’s important to note I found the same code released on an official github for Hashcash by the same Hubert Chan dated March 30, 2005:
The public key information is probably available from a date preceding 2005. Let’s just say I think I found that record.
Here is Satoshi’s public key from 2004 with signatures from 2008:
My take is that Satoshi is both his first developer as well as the creator in this situation. It’s not that I care for curiosity but it helps explain the transfer of keys and signing. The “pub” from 2004 does not mention Satoshi, it only ties someone’s identity to the user id “uid” from December 09, 2008 for the email on Satoshi’s whitepaper. Finally the last part carries a “sub” section that Satoshi mentioned as a place to protect the original timechain and first Bitcoin genesis log. He’s been doing this at MIT, which is where the MIT License for Bitcoin comes from too. The amount of information here could be immense as explained below:
The presence of 1 signature to start is paired with a public key that has an identity on it. The last two signatures are for the merging of the final parent hash and coinbase tx into a block (as it started in one, it will end in one). The final is a sigbind. Sigbinding to merge the networks would allow them to remain separated for a time but interoperable with the features of both in some areas:
A. Transaction signatures (TSIG) is a mechanism used to secure DNS messages and to provide secure server-to-server communication (usually between master and slave server, but can be extended for dynamic updates as well). TSIG can protect the following type of transactions between two DNS servers:
Zone transfer
Notify
Dynamic updates
Recursive query messages etc
TSIG is available for BIND v8.2 and above. TSIG uses shared secrets and a one-way hash function to authenticate DNS messages. TSIG is easy and lightweight for resolvers and named.
The end result is a bit and a coin, with one global, yet decentralized and masterfully crafted dual-operating blockchain. Having dual operations allows infinite scaling but also will lock the value of Bitcoin into the chain forever without risk of it being hijacked. Instant FOMO ensues.
The Value of a DevCoin: Nick Szabo’s “Theory of Collectibles”
If you were wondering where a Bitcoin’s value originated, it was probably in an extracted investment of funding and assets. This could continue as long as people buy with dollars or store value on the chain to extract. But if you were not aware the main idea behind Hal Finney’s RPOW is essentially based off of Nick Szabo’s Theory of Collectibles — which sounds a heck of a lot similar to the explanations of money on devtome’s wikipage. Both Szabo and devtome note how ethics are involved with these new age token currencies. If Szabo is the man behind smart contracts as well as tokenizing gold’s value in “bits” we have found the third Satoshi along with Finney and Adam Back. The execution of contracts would allow for the eventual good natured, everyone benefits, transfer of wealth to developers, miners (investors who are long on Bitcoin), and those who noticed the code. “D” is “Eth” if you look up the definition of Eth. The Devcoin logo has an “E” in it. The main point is on one end, Bitcoin came first and then was forked off to become Devcoin in part. The token currency is the alternate Bitcoin blockchain and has a lot of similarities in its scripts to the issuing and execution code of Ethereum smart contracts. The thing is, its all about patience and then the solution to the “Prisoner’s Dilemma” as Szabo notes. Where both Satoshi and Hal Finney have remained silent, so have the miners and developers. Everyone gets paid in the end after the network has proven itself. As far as selling now, no one who is still working on Bitcoin does not realize its value. That too is written in code and mentioned many times by Hal Finney in public forums. First, here is a link with dollar values related to Hashcash code. Reading the passage below you will note the shift to a merge mined BitCoin is almost certain:
The closed loop cycle is even mentioned in Hash Cash POW code near the time of BitCoin’s three instances of genesis as well as the initial forks of parent “altchains” — Devcoin. The title of the code is “fastmint_ansi_ultracompact_1.c” — compact being a word mentioned by Szabo himself as a reason for value. The valuation is in the velocity of transacting money and scaling space by P2P and cloud technology. Ditching the database and increasing transaction speed while decreasing to almost fee-less systems will make BitCoin explode in demand.
The code appeared on April 15, 2014 and could be the way tokens and scripts through both the tail end of POW and a copy of that tail end in RPOW work one day to combine value between BitCoins and tokens like Ether and ETC:
Finney built RPOW off the ideas of Szabo and took some of the Hashcash code with him. In the end tokens were a way to issue promises that would be upheld in future value. A way to record proof of work and transactions. The nodes are abundant and a main network will be amazing. Reaching $10M per BitCoin was a prediction Hal Finney made and seemed almost positive of:
“Hal Finney” Sun, 11 Jan 2009 10:22:14 -0800
Satoshi Nakamoto writes:
> Announcing the first release of Bitcoin, a new electronic cash
> system that uses a peer-to-peer network to prevent double-spending.
> It's completely decentralized with no server or central authority.
>
> See bitcoin.org for screenshots.
>
> Download link:
> http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rarCongratulations to Satoshi on this first alpha release. I am looking
forward to trying it out.> Total circulation will be 21,000,000 coins. It'll be distributed
> to network nodes when they make blocks, with the amount cut in half
> every 4 years.
>
> first 4 years: 10,500,000 coins
> next 4 years: 5,250,000 coins
> next 4 years: 2,625,000 coins
> next 4 years: 1,312,500 coins
> etc...It's interesting that the system can be configured to only allow a
certain maximum number of coins ever to be generated. I guess the
idea is that the amount of work needed to generate a new coin will
become more difficult as time goes on.One immediate problem with any new currency is how to value it. Even
ignoring the practical problem that virtually no one will accept it
at first, there is still a difficulty in coming up with a reasonable
argument in favor of a particular non-zero value for the coins.As an amusing thought experiment, imagine that Bitcoin is successful and
becomes the dominant payment system in use throughout the world. Then the
total value of the currency should be equal to the total value of all
the wealth in the world. Current estimates of total worldwide household
wealth that I have found range from $100 trillion to $300 trillion. With
20 million coins, that gives each coin a value of about $10 million.So the possibility of generating coins today with a few cents of compute
time may be quite a good bet, with a payoff of something like 100 million
to 1! Even if the odds of Bitcoin succeeding to this degree are slim,
are they really 100 million to one against? Something to think about...Hal
Hal and Satoshi informed as much as they could. Some people inform and disinform. Some people stay mute and some disappear. It’s all the same in Game Theory. It helps us in the long run. Hal played dumb because of the Game Theory, the Prisoner’s Dilemma. It would secure future fortunes for him as much as everyone else involved. Bitcoin is just a backwards processes of connecting and forking and reconnecting. Just like the software forks to establish its parent and kill the child part of it/fork off of it. The network is deeper than you’d ever think.
At one point in time, Satoshi supposedly sent Hal the first BitCoin transaction for 10 BTC. Apparently Hal wanted to send Satoshi some of his coins that were about to mature but Satoshi claimed he could not receive coins at the time. The coins were supposedly sent to Satoshi’s pubkey hash but would only arrive when Satoshi started to run his software again. In my opinion, the transaction is a forward transaction to the future genesis block from Hal’s original genesis block. Hal’s computer crashed most likely before this transaction was recognized in the mempool or corrupted the file enough to where only his wallet.dat could backup the transaction. I do believe that if these two are one in the future the PGP information once released (since they are already signed) will execute record of this tx and push it through the mempool or wherever it is backed up (MIT perhaps). These stories are informative without outright telling one the answer. What amazes me is how every part of Duality is relevant to my research findings. So, you definitely should read it.
So what of future value? It seems that POW has an idea originally published on March 30, 2011 but also the last update by Adam Back on November 14, 2016. That was the date it was marked “pre-release” and not merged upstream. So it can only go back to a day of a pre-release, where prebitcoin (Devcoin) comes to light as the original alternate source of BitCoin and token currency that made Ethereum possible. The value is all set to go back soon in my honest opinion. All that has to be done is a release of record for “pre-release” blocks that no longer show, perhaps the one that crashed Hal’s computer in 2009, perhaps the original record of 2008 genesis, and then we will see value return to the coin that carried on the legacy of bits and coins in Devcoin and merge mining. Value is said to have a timer on it in hashcash. If the script says that there is a locktime then hashcash says it will reject the “-b” from returning too early, and thus we are still in a time period where the “b(alt)stack” has yet to return its true value:
a period
Add (or subtract if number is negative) a random value from the current time before minting the stamp. This hides the time the stamp was created, which may be useful for anonymous users. Note adding (rather than subtracting) a random time may be risky if the stamp takes less than the added time to arrive as the recipient will reject stamps with time stamps in the future.
As a part of game theory this type of time locked contract is sealed in code and its best that nobody outright says anything of it or betrays it. Cooperation and staying silent on both ends will lead to the best value for everyone. Another way to interpret this is that the genesis block and future coinbase tx that Devcoin will be last to connect to comes with a future timestamp — so hashcash rejects the stamp from arriving early. In the future, the presence of a opposite facing altstack for scripts to run off of between dual-Bitcoins sounds great for both programming and scaling on the blockchain.
Devcoin: Years of Embedded Value
It’s all about obscuring the truth and leaving it out there for us to find. It creates Nick Szabo’s idealized fair passing down of generational wealth. The future of the Earth will flourish from the decentralized internet. It just happens to be a bonus that it will become one of the best funded markets imaginable due to the use of its currencies. Nick Szabo wrote this in “Theory of Collectibles” back in 2002:
To be useful as a general-purpose store of wealth and means of wealth transfer, a collectible had to be embedded in at least one institution with a closed-loop cycle, so that the cost of discovering and/or manufacturing the object was amortized over multiple transactions.
The escrow of DevCoin on Bitcoin’s v2 block chain makes it the best opportunity in crypto. I am 100% convinced on that and the more I look, the more I find the people that started Bitcoin back in the day whether it was Bit Gold, B-Money, RPOW, Hashcash. They were all part of the past, present, and future. The original DEV, Hal Finney created RPOW based off Nick Szabo and Adam Cash’s ideas and infused his own. There is no doubt in my mind they collaborated together on Bitcoin and merge mining. Markm “Mark Metson” is a DevCoin developer who has been around since the start as well. I was browsing over some emails from 2001 between Hal Finney, Adam Back, and a “Markm”:
Three people, one coin. Perhaps Nick Szabo’s idea was to have an alternate Bitcoin blockchain (“b”) through DevCoin so he could not only call back scripts to other blocks, but he could use P2SH once in each direction to make smart contract execution even more complex, and mainly secure. Look at the MIT PGP keys Satoshi has signed. Some of those keys have not been signed yet. Maybe its why Hal and Satoshi returning to the scene will use ones RPOW to redeem a script signed by the others RSA keys. Bitcoin doesn’t use RSA keys but RPOW does.
What is interesting about the above passage is it gives an explanation of why the September 2008 genesis block (debug software) was actually Bitcoin Block 1. Satoshi’s software was crashing at genesis and that may explain why there is no record of a block from January 3, 2009 to January 9, 2009. I quoted Satoshi early on where he admits Hal carried the block chain in the days after the January 3 genesis block up until the software was released in public on January 9. If Hal was running a UNIX like command interface then the odds are high that Hal carried on the development of the timechain and when Satoshi handed him the debug software it attached to Hal’s record of block 1 all the way back in September 2008. At that moment the software probably had to be configured to allow a block chain where it recognizes that timestamps do not matter as much as the correct order of transactions. It could also be that the timechain ceased to exist on January 3, 2009 and Hal’s transaction was included in a block for the first time (since timechain transactions are not on blocks, this is easy to understand). Once Satoshi hid the log.0000000001 file that both he and Hal were using, their blk0001.dat files became the dual block chain record of both their blocks. This was the first time the the time chain and block chain may have connected.
This could very well be where the first fork of the bitcoind daemon took place. It became a buffer zone in between the timechain and the block chain in 2009 and could have even worked there as a testnet to rewrite, reorganize, and develop the bridge between the old and new internet. It also could be the first use of RPOW going forth from one place and back to another. The September 2008 genesis block would have been able to use its 10000 Satoshi fee to tokenize and use RPOW as a buffer zone between timechain and block chain. The nBits out from pre-alpha in 2008 was 20, which would have allowed Hashcash to keep sending proof of work forward by relaying its minimum fee in bits to mine the next forward block. I am leaning towards the idea that the forking of bitcoind kept Hal Finney quitely going forward with DevCoin and whether he somehow used RPOW to quietly leave connections for a revelation of other blocks when a new data file comes to light I do not know. I do know at least 1,000 of the first Bitcoin blocks are UTXO’s. For instance, Block 1,000 as of today:
This transaction happens on the same day (January 19) as the Year 2038 Unix time overflow. Hal Finney may be the “Unknown” relayer of this transaction using his UNIX command interface to run Bitcoin. Maybe Hal’s greatest contribution to Bitcoin was to fix interactions between 32-bit software and 64-bit software to build a secure transaction on accurate timestamps between all timestamp formats, 32 and 64 bit software, and even using OS’s like Windows which have a different type of daemon built in that wouldn’t communicate correctly with other OS builds for Bitcoin at the time. We can take a look under the hood at Block 1000 over at Blockcypher and get even more answers:
The output of this transaction has script to send this transaction to another pubkey address, where code may be waiting to push it back to a script address. I just wanted to decode it to mention both inputs and outputs are waiting to be called or spent in script.
"result": {
"asm": "04f5eeb2b10c944c6b9fbcfff94c35bdeecd93df977882babc7f3a2cf7f5c81d3b09a68db7f0e04f21de5d4230e75e6dbe7ad16eefe0d4325a62067dc6f369446a OP_CHECKSIG",
"reqSigs": 1,
"type": "pubkey",
"addresses": [
"1BW18n7MfpU35q4MTBSk8pse3XzQF8XvzT"
],
"p2sh": "34oXnKoCvkkJjmYuyfkZh89eH9WgW6fzPz"
},
"error": null,
"id": nullA lot of the early days of this blockchain was left to be reorganized when processes like the one below had played out at a mathematically planned time in the future:
The mention of “Committing 1 changed transaction to coin database” lets one know that the debug log — devcoind is operating in both past and future. It is somehow in a loop between timechain and block chain and its pretty clear that when block -1 becomes block 0 along with the parent block there will be a new dual blockchain genesis block with two coinbase txs on it. Devcoin is also probably half merged with Bitcoin on upstream codebases too but quickly forked off. That is why it gets to access and mint new Bitcoin’s by being Bitcoin itself. Or we don’t even have to say a Bitcoin exists. Maybe bitcoind is configured to work by minting Devcoin’s to Bitcoin blocks. The last step from Hashcash involves “killing all children” for a file that is called hashfork.c as I explained earlier. There is a final fork where the network has to be cut off and use a token buffer zone from something like RPOW in order to communicate with the centralized web without compromising the decentralized web.
This may be why Devcoin has a dual nature of minting Bitcoins and issuing tokens, on TOP of what it does as a daemon:
Developer markm, around as early as the Hal Finney 2001 emails agrees that only little changes need to be made to set the network up as we see it functioning today:
It appears that markm was aware of Satoshi’s plan and it makes sense since he knew Hal Finney in online discourses since 2001. The token DevCoin sounds like it would be functioning forward and backward like RPOW at the beginning of this merge/code update. This is probably the beginning of DevCoin minting Bitcoin blocks and “BTC” not being anything more than a place for DevCoins to be held in tx escrow records until the execution of script. Again, after DevCoin had been embedded in Bitcoin scripts on the block chain for years — fitting Nick Szabo’s idea for store of value. Devcoin has valuable information that people proved they would pay high prices for on the Bitcoin blockchain. That money kicks back in the end. Hashcash POW would continue putting scripts into BTC transactions too, allowing RPOW to just function as DevCoin tokens when a checkpoint is passed. I believe in the end, all DevCoins and Dev “tokens” will merge because they have been Bitcoins all along.
Back to Satoshi’s Vision: Early Satoshi + Hal Finney Discussions
Satoshi put Hal’s log.0000000001 file in the database subdirectory. When the DB crashed apparently Satoshi got a write exception but Hal got a read exception. Maybe it had to do with the database being recorded as a sub-chain to Satoshi’s allowing Hal to continue mining blocks that are backed up somewhere. We can first take a look at block 375 and see if anything happened after Hal crashed his database:
Just as I thought there was some goofy stuff going on at Block 375. The nonce was extremely higher than normal (10-digits!) and the block didn’t show up on Blockcypher until 11/16/2014! In fact, it was almost an identical transaction to Block 1000 and arrived about 8 minutes later. Both outputs are unspent for now but there is a pay-to-pubkey that also has a script-key attached. The input will be sent with all of its bit-value back to the coinbase tx at the parent block/hash. I dug around looking for anything that would match that nonce and I found something pretty interesting on an explorer I have never been on, yet its memory captured the eventual result of this transaction. It is about to get a matching 50 BTC in its input. Could it be that going back to the original genesis things were messed up and duplicated tit for tat so that a majority of blocks are going to have balance inputs and outputs of 50 BTC?
So this makes sense. Bitcoin is reorganizing by doing two way accounting and balancing early block rewards equally. No doubt there was something up here when Satoshi and Hal were mining in one direction and debugging/potentially changing and overwriting directions back all the way to the coinbase. I hate to say it because if you look at the raw data you’d disagree (its nuts) — however, I have expected this to happen for months. Hal responds claiming he was debugging and running v0.1.3 without paying attention basically:
Hal acknowledges that he also did a few other debug runs. So what do the errors mean? Theymos as Jeff Garzik answered this question in 2011:
The exact same thing appears to have happened to this bitcointalk.org user as it happened to Hal in 2009. What is interesting is that everyone mentioned the same thing as Satoshi, except board administrator “theymos” hinted that a bitcoin.conf file may not have existed at that time (March 15, 2011). Theymos responded to a similar crash, this time having to do with log.0000000001. He first suggested to delete the same files, or to move the log file like Satoshi recommended to Hal. Next:
Hal for some reason could keep writing. Whether that had to do with him using MSVC to mine and not a CPU like Satoshi, I do not know. I don’t mine. I do know there is a record of UTXO’s littered in the first few thousand blocks. However, I want to go back and show you the raw data I pulled from the last block explorer where the 50 BTC output was balanced by a 50 BTC input in the “coinbase” tx. It is a null string at the moment and the block it was on (375) is stuck in November 2014 waiting for the next script to execute. This block explorer seems to think that the original txid is also the coinbase txid, hash, merkleroot, and block 375 tx:
There’s also more data attached here than before. My best guess at the part above is that Hal may have ended up making a copy of this transaction in the coinbase by continuing to write blocks.
Hal also may have been mining with his database log in the subdirectory like Satoshi recommended. I am just taking an educated guess that may have created a duplicate there of things already written when he was debugging? I don’t know what that would do, but lets go to Satoshi’s PGP key record again. There is a section for “sub” where Satoshi may have the right database on record, or a backup database that wasn’t corrupted.
If you notice, the only unsigned part of this PGP key is on the “sub” section. The bits/keyID has to mean something too. And why was this block given such a high nonce? Perhaps its a guess by the miner of when the block will be solved. Scripts seem to indicate the transaction belongs in the coinbase, and we can see that one signature is already signed off. But this is another one of those dual entry moments where the second signature is needed. Here is a good explanation of how a subkey is tied to a master key (private key) for signatures:
OpenPGP further supports subkeys, which are like the normal keys, except they’re bound to a master key pair. A subkey can be used for signing or for encryption. The really useful part of subkeys is that they can be revoked independently of the master keys, and also stored separately from them.In other words, subkeys are like a separate key pair, but automatically associated with your main key pair.
GnuPG actually uses a signing-only key as the master key, and creates an encryption subkey automatically. Without a subkey for encryption, you can’t have encrypted e-mails with GnuPG at all. Debian requires you to have the encryption subkey so that certain kinds of things can be e-mailed to you safely, such as the initial password for your debian.org shell account.
So I was just checking out the fingerprint from the same Satoshi PGP above and I ended up finding this exact match scattered across a github repository:
I have to say, I am not all that interested in the mystery of Satoshi but I am going to divert from the obvious issues in early BitCoin mining. So I opened up the file and it turned out to be a very, very possible Satoshi Nakamoto. First, look at the credentials:
Now read the other three pages, because the guy is a database expert, developed a trading system for a hedge fund (!), codes in literally every language, worked with literally every internet protocol.. you just need to read it all. Now this could be a big coincidence, and I am not pointing fingers, but there is this conference he attending in 2015 PgCon Ottawa:
Not only did Andrew Dunstan turn out to be the most capable and qualified Satoshi I ever saw on paper, he even goes to CONVENTIONS and spends two nights talking about horizontal scaling and freaking SHARDING with a guy named Satoshi N.!!! I may be a bit too excited but I mean so far the coincidence of finding Satoshi’s fingerprint scattered across Andrew Dunstan’s github is uncovering more and more of the tale. Here is an email from 2014 where he specifically expresses hatred for Bitcoin (which is like looking at a guys walls with his fav band all over it and then him saying they suck) — just see for yourself:
It’s a bit funny because Andrew in mentioning his disgust with Bitcoin also mentions things like token currency — specifically beads and shells — the exact things Nick Szabo covers in the Theory of Collectibles. The same Theory of Collectibles that Hal Finney himself called inspiring back when he created RPOW in 2004. Not to mention that “andrew” likes to sign off on his emails in lowercase like “satoshi” used to:
Andrew also uses the same “(dot) net” email software as both Hal Finney and Satoshi:
Not to mention the two guys are talking about something both wouldn’t have had problems with, nor would Andrew Dunstan because he’s greatest of many coding talents is DATABASE DEVELOPMENT. I have a hard time believing he’d be having this issues as Satoshi or Hal. The reason I bring Hal up is because we could be looking at someone who knew him, or even acted on his behalf. Hal Finney loved RSA keys and he wrote about it in RPOW:
Mind you Hal even glorifies the token currency that Andrew says he hates in 2014. But the reason I bring up RSA is because I never heard about RSA being used in Bitcoin and I don’t believe Satoshi ever implemented its use. However, Hal definitely put it into RPOW code. Could Hal/Andrew Dunstan be the one with the PGP Key left to sign in the subkey directory?
Dunstan’s company is achieving things that would enhance both coding and records/queries that are a perfect fit for Bitcoin:
Another feature is described as:
Implementation of SQL procedures, including transaction control. Transactions can be started and committed in PL/pgSQL, PL/Perl, PL/Python and PL/Tcl procedures, as well as via SPI.
I apologize but sometimes going down the rabbit hole just screams at me and I have never heard of this guy. Yet, he is more qualified than Satoshi in my honest opinion. Good for him.
(I’m just going to put this here to let things sizzle…)
