EIPs VS bips

Even more relevant would be the Ethereum Improvement Proposal repo (where people submit proposals to change the spec):

https://github.com/ethereum/EIPs

Or the go-ethereum execution client (the most popular execution client):

https://github.com/ethereum/go-ethereum

It’s early in the life of the xERC20 standard, but progress is quickly being made. The standard has been audited and is already live with a few projects. The EIP to adopt the standard has been created, and implementation has begun. Alchemix recently announced support for the xERC20 standard. And Defi Wonderland has published a suggested implementation on their GitHub. This implementation has an interface for the xERC20 contract with eight core functions that the token issuer must implement. These are functions related to setting the Lockbox contract (setLockbox), issuance limits for bridges (setLimits, mintingMaxLimitOf, burningMaxLimitOf, etc.), and the core mint and burn functions.

Check out EIP-7517: Giving Consent for AI Data Mining on the Blockchain

ERC223 is not widely implemented, and there is some debate in the ERC discussion thread about backward compatibility and trade-offs between implementing changes at the contract interface level versus the user interface.

Ethereum Improvement Proposals (EIPs): These are proposals to change various aspects of Ethereum. They often contain detailed technical discussion and can be a good resource for understanding the finer points of how Ethereum works. EIPs can be found here: https://eips.ethereum.org/

Worth looking at: EIP6968: Contract Secured Revenue on an EVM based L2 https://github.com/ethereum/EIPs/pull/6969/files

Additionally, I have made an EIP that can help standardise and maintain official contract registry of each DApp. This can help identify official contracts of a protocol vs scammers using fraud contracts but presenting like official protocol. https://github.com/ethereum/EIPs/pull/6807

Bitcoin transactions involve locking funds in scripts, which can only be spent if those locking conditions are met. The part of the script that expresses these locking conditions are called ScriptPubKeys. On the other hand, the part that provides unlocking scripts to satisfy the locking conditions is referred to as ScriptSig for legacy transactions, and ScriptWitness for SegWit Transactions. These scripts are evaluated by a stack-based language called Script. This article will mainly focus on ScriptPubKeys.

Here’s the reference https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

There are 5 271 537 971 301 488 476 000 309 317 528 177 868 800 possible permutations of the bip39 wordlist found here: https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt when using 12 word seeds. You probably have better change to win the lottery every week for the rest of your life than cracking a 12 word seed in correct order

No one controls Bitcoin, because it's a protocol. Bitcoin Core is the reference implementation, but there are others, and anyone can create new implementations if they wish. Also, the Bitcoin Core maintainers can't just change something on a whim, because users would then switch to another fork. Maintainers (or miners or other groups) can't force their changes on users, because everyone can decide on their own which version they want to use.

The protocol development happens through BIPs (Bitcoin improvement proposals): https://github.com/bitcoin/bips

BIPs are discussed for years, before (and if) they are implemented, and basically everyone needs to agree on them, because no one wants to fork the blockchain, which could be devastating.

All the seeds generated from the CoolWallet (Number / Word) adhere to the BIP-39 protocol.

> users would be required to hand over control of their wallet to actually manage the massive proliferation of addresses needed

BIP32 solved this in 2012, and is used by basically all self-custodial wallets these days. https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...

> Which policy are we referring to?

* BIP 141 version bits and BIP 148 as a voting mechanism: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawi... and https://github.com/bitcoin/bips/blob/master/bip-0148.mediawi...

* core developer votes: https://en.bitcoin.it/wiki/Segwit_support

* posturing and maneuvering: https://cointelegraph.com/news/samourai-wallet-intends-to-ru...

> It evolves in a decentralized and organic manner, devoid of any formal political process or voting.

Just because its voting mechanisms are informal, that doesn't make them not voting mechanisms.