bips VS EIPs

Some years ago, I saw a wallet called [Spark](https://sparkwallet.io/) that let you generate a QR-code to view in your Apple Wallet and Apple Watch Wallet. It was for receiving over lightning, not sending.

I guess with unified [BIP21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawi...) QR-codes, anyone can already add a RECEIVING wallet code to Apple Wallet today.

I don't think Apple want's to be the middle man in receiving Bitcoin payments though because “tainted” coins exist in the C-suite mind, and they would rather not receive and handle those.

But Jack Mallers recently told me he wants to integrate Apple Pay into [Strike](https://strike.me), so who knows, something similar will exist soon.

Anything you put elsewhere is not more secure, unless you are more secure than Apple's servers, which seems highly unlikely. If you don't have it, it can't get compromised.

The user has an iCloud account, you can write to iCloud storage without making them "sign in" to your app. It's their data, they can find it in the folder for your app in their iCloud drive on a Mac.

And see https://developer.apple.com/game-center/ for a way to let two users coordinate "play", multiplayer, turn based, achievements, etc., which cover most of the interaction you'd need.

For sharing personality test, a person can do their own and their partner's, but for a better take on the partner you and your partner can each take your own test then generate a sharable fun code that captures the "bits" of the answers without repeating the test. As partners, you could tell each other the sharable code as a NFC bump or QR code to scan, or generate one of the word based codes like bitcoin wallet passwords.

See BIP39: https://github.com/bitcoin/bips/blob/master/bip-0039.

(This passphrase would be short if the test results distill down to a smaller set of outcomes, like 64 questions give 8 results. It would be long if you need all 64 questions' answers to match with.)

Modern bitcoin addresses use a base-32 character set that leaves out some of the most ambiguous pairs and also permutes the address ordering so that the most visually similar remaining characters produce single bit errors which are better handled by the addresses error detecting (and potentially correcting) code.

https://github.com/bitcoin/bips/blob/master/bip-0173.mediawi...

Context: Bitcoin miners have just adopted a 50% pay cut for themselves. This pay cut was baked into Bitcoin protocol at the launch of the network (mostly, see "BIP 42" [1]). The OP link gives information about the block in which this pay cut was made.

I get that HN comments tend to dismiss Bitcoin. But the fact that for the fourth time this pay cut has happened without a hitch speaks volumes to what makes Bitcoin interesting: It's a rare combination of economic incentives and technology that keeps chugging. Nobody can stop it. And it's extremely resistant to change. It requires no governmental approval. All attempts at subversion or interference have failed. There aren't many things that come close to that kind of record.

[1] https://github.com/bitcoin/bips/blob/master/bip-0042.mediawi...

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

EIP-1191 extends EIP-55 by incorporating chain IDs into the checksum calculation. The goal is to prevent users from mistakenly sending funds to an address on a different network, such as Ethereum Mainnet vs. Ethereum Testnet.

To address this issue, and to bring a more reliable solution, on November 15, 2015 a new improvement was proposed (EIP-7) to bring new OPCodes and fix the problem with CALLCODE, leading to the introduction of Delegate Call (delegatecall).

The Ethereum upcoming upgrade — Pectra, scheduled for Q1 2025, will introduce several Ethereum Improvement Proposals (EIPs), including the much-anticipated EIP-7702. With the Pectra update, developers aim to significantly enhance the UX for interacting with decentralized applications (dApps) on Ethereum. In this article, we’ll dive into the essential role of EIP-7702 in the Ethereum ecosystem and explore how it will impact both users and developers. For more information about the EIP feel free to check EIP-7702 Github.

/** * @dev Sets a `value` amount of tokens as the allowance of `spender` over the * caller's tokens. * * Returns a boolean value indicating whether the operation succeeded. * * IMPORTANT: Beware that changing an allowance with this method brings the risk * that someone may use both the old and the new allowance by unfortunate * transaction ordering. One possible solution to mitigate this race * condition is to first reduce the spender's allowance to 0 and set the * desired value afterwards: * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 * * Emits an {Approval} event. */ function approve(address spender, uint256 value) external returns (bool);

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.