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.
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 ...
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 ...
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. ...
No, I don't think that sharding is as simple or beneficial as portrayed here. Here are a few thoughts:
Splitting by addresses doesn't seem plausible. Most transactions have either multiple inputs or multiple recipients. It's not clear how transactions would be handled that attempt to spend funds from both chains or pay to both chains. If they need to be ...
If you look closely, you'll notice that BIP 32 and BIP 44 actually have the same root key and it begins with xprv. Then BIP 49 and BIP 141 also have the same root key and it begins with yprv. BIP 84 has a root key that's different from the others that begins with zprv. Now if you were to take all of those root keys and Base 58 decode them, you'll find that ...
I am not aware of one comprehensive write-up, but Aaron van Wirdum has a few great write-ups of various proposals in Bitcoin Magazine, the Bitcoin Optech newsletter has covered a number of the more recent proposals in depth, there are a number of talks (and transcripts of those) about BIPs on Youtube from conferences, workshops and Bitcoin meetups. There are ...
It doesn't. You read it wrong, first snippet shows you account key for m/44'/0'/0'/0 derivation path, second snippet for m/44. As the derivation paths are different - obviously the accounts' keys are different too.
bip39-lib.js works along with bip32-lib.js AND bitcoinjs-lib.
BIP39 is strictly regarding the mnemonic phrase and HD seed.
In order to derive child keys from an HD seed you'll also need to use BIP32.
BUT... BIP32 has no concept of addresses either so ultimately you'll also need bitcoinjs-lib.
In other words you need to use all three libraries to go from ...
It seems to have expired
BIPs should be changed from Draft or Proposed status, to Rejected status, upon request by any person, if they have not made progress in three years. Such a BIP may be changed to Draft status if the champion provides revisions that meaningfully address public criticism of the proposal, or to Proposed status if it meets ...
Ended up answering my own question! If anyone else runs into a situation like this, the problem is that the code is deriving a non-hardened child key but checking for the hash associated with a hardened child key. According to the BIP32 docs, to derive a child key you hash the private key prepended with a single zeroed out byte and appended with a hardened ...
It appears many unused opcodes were disabled in 2010 for security reasons (at least OP_CAT) or as a security precaution (many others).
Pseudonymous commented that the first BIPs didn't start until 2011 - a year later.
BIP 342 does not add any of these opcodes, and it is not possible to perform elliptic curve operations in it.
The only new/changed opcode semantics in BIP342 are:
Schnorr signatures instead of ECDSA.
OP_CHECKSIGADD instead of OP_CHECKMULTISIG(VERIFY).
OP_SUCCESSx opcodes for future extensibility
Unknown pubkey types for future extensibility.
Changes in ...
I need to know how to get the corresponding public key of a private key in hd-wallets, I don't need the derived ones but the public key who is related to the private I got.
A private key derived using the BIP32 hierarchical derivation is similar to any other one and the corresponding public key is obtained by "multiplying" your private by G, as ...