Keep same address prefixes as Bitcoin

[develCuy]

Is there any valid reason to not use Bitcoin address prefixes? We aren't on 2013 any longer, nowadays crypto users very well know when they are using Bitcoin or an altcoin. Ethereum alts use the same 0x prefix and nobody complains, actually Metamask makes a great job at showing up what network you are connected to. Devcoin could have a nice SPV client like PaliWallet, which will provide a similar UX to Metamask for UTXO networks. Last but not least, source code will be quite better to maintain, I spent a heck amount of time updating prefixes for 22.x, a hell that I won't repeat for 23.x, so please make my life easy and consider everybody smart enough to realize what UTXO network they are using. Thanks!

Idea thanks to:

[Satoshi0x]

https://chrome.google.com/webstore/detail/mpurse/ljkohnccmlcpleonoiabgfggnhpkihaa

Works on Monaparty but uses Monacoin standard P2PKH address (M-prefix). Magic Web 3 chrome extension but no EVM needed. ;) The possibilities to just use our own addresses in Web 3 :)

[Satoshi0x]

Maybe our address is best remaining the same for an additional reason that our genesis is peculiar and interesting in that it is for 50.00000000 when using emfox's d.evco.in Abe 0.8 explorer "Devcoin 0" :) I also think it's cool bc Mark was the one who created the genesis block per the original thread in Bitcoin Development of the Bitcoin Forum when UTB began Groupcoin devel with a bounty and then on 7/22/2011 the same thread born Devcoin's genesis block. "markm" made that particular genesis block himself and "left satoshi his coins" in his own words. I think it's interesting bc the output of the Bitcoin (BTC chain) genesis block on Jan 3 2009 is not a real txn. The 50 BTC output was hardcoded in and per source code "not originally in the database"... I think to start a chain like Bitcoin a lot of these block "subsidy" payment originally were configured in a CONF file and they basically made rules for how much the subsidy would be, and then a postSubsidy in some cases after a subsidyBlock (sorry I dk the term correctly top of my head). I know for Tenebrix the conf file specifies that the genesis initialsubsidy was 7769999 (aka it's "premine") which made me think, a genesis blog is indeed not mined at all, hence that subsidy being "pre-mined"... the next block (block1 or genesis + 1 block) has a subsidy of 50... and that block is also the one I mentioned that specifies the block at which after the postSubsidy would kick in for all other blocks and in TBX case its 25.... Now there's no block halving but I believe once QT wallets came into the picture they were still using the BDB 4.7 as Github's copy of the original source code files (posted in 2014 by a benjxyz user on Github but also shared on bitcointalk.org) specifies that Satoshi's v0.01 ALPHA code compiled using BDB 4.7.25.

Therefore, since you cannot go from using BDB 4.7 to an upgraded BDB main release (so 5.x) and have it backwards compatible with your files then I believe Bitcoin has a fundamental misunderstanding about UTXO, block rewards, how every chain begins or how chains using the same Base58 P2PKH have a special ability to be used on every compatible chain using that particular prefix for its address version...

The wxwidgets version was used until satoshi left and then it was Gavin A who stripped out all the GUI and just used what is known as "bitcoind" and runs in a cmd or terminal depending on your OS...

Still, the best thing for us to do is to keep the same base58 key as Bitcoin's Jan 3 2009 genesis chain, and I think the fact that the same base58 p2pkh that is on Bitcoin Block 0 with a hardcoded credit of 50 BTC is the same base58 p2pkh that Devcoin 0 gives a block reward of 50.00000000 in its genesis tx output.... Similar protocols that all run on Bitcoin have coins as UTXO sitting in the "1Exodus" address that was used for the Mastercoin "IPO" with BTC, and MSC (which per omnilayer protocol has always been property "1")... And something xbalances.io noticed in May 2015 when using certain api it soon switched that it called a counterparty test coin which the raw data showed with the BTC balance and "MSC" and test MSC balances as "1.00000000 XCP/TEST"... obviously what this all means is maybe things are not all happening on different chains in the UTXO way we think. We think of a bridge like from one account to another account on "compatible" networks with different blocks like EVM. But what if because UTXO is just a tally of transactions at whatever blocks a node or block explorer thinks its reading, but another API for a protocol on that same blockchain reads it differently or is pruned and maybe sees the amount of unspent "coin" at an address not the way another older node or pre-modified node does. I wonder if because the hardcoded genesis block for Bitcoin was in a DB that is not backward compatible with v5+ not having that genesis block output of 50 BTC is as necessary to keep record of an original state, and remember that the genesis block is a book mark to make the "genesis" of subsidys by actual people running the OG software a "reality" and not just hardcoded in. That is, finding a "nonce" by computation and getting a coin - making it real because of the cost function. The previous block was needed (the genesis) to make reality of mining/generating blocks for rewards.

But what if DVC began the same way. Maybe it's best all these protocols merge themselves to make sense of it all. I know many ways to "wrap" or bridge UTXO to EVM is to send to an address. Leave the amt as UTXO, use the dAPP on a site to make the necessary interaction with your EVM wallet usually like "metamask" and then you get minted ERC20 tokens usually that EVM can just add to its "account based" address u used and when you wanna go back to the UTXO, the code reverses the process, and the UTXO coins address sends the coins back to your base58 addr.

However, I think... and call me crazy, if just one block in our blockchain is using something eventually that can be said to be agnostic or make sense of DVC/BTC genesis or a "bridge" in the UTXO sense is a testnet common to both chains that shares a merkle root with a mainnet... then we stand a chance to be a very special future solution to a process that people don't even realize began without the "mining protocol" and may just be a spot in time that blockchains can eventually augment eachother's ledger balance so that we don't have all these different nodes and disagreements that F things up but are maybe 55% correct according to some big miners so the true balances of BTC or DVC or merge mined coins with script sitting in eachothers chains and the "lie" of genesis block being mined haha - makes a harmonious reason that stops speculation, chaos, and moves us into the future.

I know that's a long post - but my contention is - Devcoin needs to keep its "legacy" Bitcoin base58 address version.

It could be the link necessary to give Devcoin a derived value automatically from Bitcoin, and maybe Namecoin ;) that is computed (maybe with a fiat value that isnt from spot exchange) based on fundamentals, energy costs, energy efficiency, block security, difficulty, script in other merge mined chains where value is recorded on the ledger and finally readable by nodes that used to either ignore or conflict making a lot of devcoin's blocks carry "non-standard" bitcoin transactions.

TL,DR = keep it :) Let's go back to the future after we bring the truth of the past into the consensus of the UTXO SHA-256d chains that use the same POW for whichever blocks they are mining with Bitcoin. :)