The coinbase mentioned in BIP34 is not the company; it is referring to the first transaction in a Bitcoin block (which is special as it is allowed to bring new currency into circulation).
Coinbase-the-company didn't even exist when BIP34 was written (or at least, wasn't known/public). The company was named after this special transaction.
The concept of 'accepted' is pretty fuzzy, as it depends on what a BIP affects. Some things are wallet-only, or only affect the protocol, or are optional to implement for different implementations. When BIPs affect the consensus rules of the protocol (the rules which determine which blocks are valid), the whole network needs to adopt them in lockstep, though ...
BIP 39 is not in Bitcoin Core largely for implementation reasons and because BIP 39 is not as secure as it could be.
The structure of Bitcoin Core's wallet doesn't really allow for BIP 39 to be implemented. The current structure doesn't allow for 512 bit seeds as BIP 39 specifies, and adding it would require some significant changes to the wallet code. ...
You're right that the elliptic curve multiplication is indeed the most expensive operation in the validation algorithm. And as both single signature validation and batch validation require two EC multiplication per signature, it would seem that no speedup can be gained from batching.
However, several algorithms are known for computing the sum of multiple EC ...
The separation between internal and external addresses comes from BIP32.
Using a different chain for each permits you to give out an xpub for just the external ones to an auditor. They would then be able to observe your incoming payments, but not your spending.
You are correct that effectively Bitcoin PoW involves computing the Merkle root every now and then in addition to the hash grinding.
However, this is negligable. Even ignoring nTime rolling, the Merkke root computation is just a dozen or so hashes every 232. It's so little because not the entire Merkle tree needs recomputation; just the coinbase transaction ...
This question is based on a misconception. Miners do not vote on proposals. Consensus changes to Bitcoin are made by the entire ecosystem transitioning to new rules that they choose, by running node software that enforces these rules.
Miners are a part of that ecosystem, and their enforcing of new rules is part of what makes them safe. But if miners refuse ...
Has SegWit and it's benefits and costs:
Code complexity (of acceptable amount)
Witness data is discounted in SegWit transactions, somewhat rectifying the fact that outputs are cheaper to create than to spend.
3rd person malleability fix for SegWit transactions
RBF transactions (optional, destroys 0-conf)
Ability to soft-forks to ...
Bitcoin Core probably will never have a "1.0". 1.0 is a socially significant number which indicates some kind of finality or completeness (at least initially). This itself is holding back developers from declaring that there may even be a 1.0 or creating some timeline for a 1.0. Bitcoin Core is being continuously developed and there is no point at ...
BIP 113's goal is not to aim for a specific offset.
Its goal is guaranteeing monotonicity (treating every block's timestamp as strictly larger than the timestamp of each of its ancestors). It does this by leveraging the existing consensus rule which states that the median of the timestamp of a block has to be strictly larger than the median of its 11 ...
BIP9 only describes a new deployment method of softforks to the Bitcoin network. I therefore assume that you mean the deployment of BIP141 by method of BIP9.
The deployment of segwit requires 95% of the blocks of a difficulty period to signal readiness for it by setting bit1 in the version field. Since the difficulty period was already in the middle when ...
The process is not formalized precisely because only really non-controversial changes are supposed to make it in at all.
This hasn't always been the case, but is becoming more true in the last year.
Right now the process goes like this:
Start by thinking of some feature/improvement.
Convince the dev team(s) of the relevant parts (core consensus, wallets, ...
In order to use a relative time lock, you need to provide the requirements in the scriptPubKey to which the Bitcoin is sent.
scriptPubKey for escrow with 30 day timeout:
2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIG
"30d" CHECKSEQUENCEVERIFY DROP
<Alice's pubkey> CHECKSIG
BIP's and RFC's are similar in that they
debate an implementation in the community in order to improve it, and
produce documentation that's useful to other coders.
However, they're different in a lot of other ways. This is largely because the two solve different problems: RFC's usually invent new protocols, whereas BIP's amend an existing system.
AFAIK, the two most common sets of HD wallet mnemonic seeds used are BIP 39 compliant or Electrum Wallet compliant. Most of the more secure hardware HD wallet devices support the BIP 39 standard, which appears to be deprecating the older set of Electrum HD seed words. People should not have to do a deep dive into Electrum Python code to find the list of ...
Speedup in well optimized cryptographic functions are hard to come by. In libsecp256k1 we'll usually celebrate a 4% algorithmic speedup. Figures on the order of 2x are reasonable for the usage in Bitcoin, though larger might be possible in the future during initial block download since much larger batches could be used.
A single validation on a single core ...
This is specified in BIP 39 itself:
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the ...
I am assuming that you are talking about BIP 39 here.
A BIP 39 mnemonic can have any number of words with the most common being 12, 18, and 24 words. There is a checksum encoded into this mnemonic. This checksum is actually just a "part of" the last word, i.e. the last word encodes some of the actual initial entropy, and some of the checksum, depending on ...
The current BIP process is defined in BIP-2. An author drafting a new BIP leaves the BIP number in the preamble marked as XXXX. A BIP editor assigns a number to that BIP when the draft phase is complete. The number is chosen by the BIP editor, while generally one of the next higher numbers is assigned. Some number ranges might be reserved to allow BIPs with ...
See my answer here to address some of your misconceptions. TL;DR: miners signal support in blocks for certain rule changes in order to coordinate activation, not to determine whether it is accepted or not.
As for the actual mechanism used to signal, a number have been used in the past:
Time based: BIP16, BIP30
Early softforks (up to mid 2012) used a simple ...
If you have no trouble with Alice, Bob and Claudia know about each other, you could create a single transaction with 3 outputs, one for each of them. In such case they will all three get bitcoins, or all three would not get bitcoins (because actually it would be 1 transaction, which will get into blockchain, or would not).
I can show you the way to ...
It is a median, not an average, thus it selects the 6th block's timestamp after sorting.
If you're a non-native English speaker, international maths heuristics can be quite tricky. Double-check on the Internet before translating into your head.
If I understood correctly https://github.com/bitcoin/bips contains a list of change proposals that have been accepted as BIPs by the BIP editor?
Why are some of the numbers missing, for example 0155.mediawiki to 0158.mediawiki?
They haven't been assigned yet. The BIP editor sometimes chooses to reserve a range of number for BIPs around ...
BIP 149 is different in that it does not enforce orphaning of blocks that don't signal readiness for SegWit. Instead just the supporters enforce the rules on any blocks that contain SegWit data and allow regular blocks to be mixed into the chain. Thus, miners that don't change anything will build on the SegWit chain.
To split the network, miners would need ...
There isn't any blockchain voting for accepting a BIP: See How is a BIP accepted? and BIP0001.
Rather, the BIP is accepted or rejected on the basis of consensus. Consensus is never defined, but even if you interpret it fairly broadly, I don't think any of the three will reach consensus.
There are frequently blockchain votes about activating the new rules, ...
1) MAST: Essentially folded into Taproot
2) Taproot: Planned to be part of the upcoming SegWit V1 softfork. A formal proposal for that has been about two weeks away for half a year, so could appear any day now. ;)
3) Schnorr: All SegWit V1 transactions will only allow Schnorr signatures and no ECDSA signatures. I am not sure whether the first release of ...
These improvements are specified in BIP340, BIP341, and BIP342. These documents are fairly mature, and there seems to be community traction for them (though, disclaimer: I may be biased as I'm a co-author), but it's inherently hard to predict when activation will happen.
This is a Lightning feature, as far as I know. ...