What’s the magic key version bytes for BIP49

I’m implementing BIP49-compatible key derivation for bitcoin-s, but I’m having a hard time finding the magic version bytes to use for the extended keys.

I’ve been looking at BIP49, but can’t find anything there.

Also, is there multiple schemes for deriving P2WPKH-nested-in-P2SH? I’ve been looking at the Samourai fork of BitcoinJ, Trezor’s implementation and the test vectors in BIP49, and I can’t get the vectors to pass by using the magic version bytes from Trezor/Samourai.

Maybe I’m confused by which magic bytes from Samourai corresponds to mainnet/testnet P2WPKH-nested-in-P2SH, so any clarification is appreciated here. From my understanding, the mainnet version bytes are 0x049D7CB2 (pub) and 0x049D7878 (priv) and testnet are 0x044a5262 (pub) and 0x044a4e28 (priv).

As a final thing, any pointers to test vectors for BIP49 and BIP84 is appreciated. Currently I’ve come across the BIPs themselves, as well as SLIP132.

Following SegWit implementation, is BIP-146 signalling and implementation still on the docket?

Is BIP 146, which defines using the low S value, still on the docket to be signalled and implemented given that SegWit fixed the txid malleability issue by moving the witness outside the transaction? I’m asking because it can fix the wtxid malleability which now requires re-syncing of transaction data when it is changed from what it was originally relayed.

Also, will the implementation be a soft-fork which would treat this transactions as non-standard but miners can still include them in the block, or will it treat the transactions with high S value as invalid?

How do cryptocurrency exchanges work with so many currencies at the same time?

To implement automated deposits/withdrawals of a single currency for a business there has to be a lot of code in place specific for that currency. For example if I want to automate sending and receiving bitcoin – I would write an application around bitcoin’s software – bitcoin core. Obviously, there won’t be similar node software for every coin, say Ethereum, would have a different core, if it even has one (it’s an example). Would you need to write a new app that would adapt for that core? Then does it mean that big exchanges write new software that does the same job but for each coin? Where did I go wrong here, or is cryptocurrency development really this complex?

What are the major technical differences between Bitcoin and Bitcoin Cash?

For a research project I’m trying to detect the major technical differences between Bitcoin and Bitcoin Cash. I know that BCH uses a larger block size and does not support SegWit. But what other differences are there?

I know this is a broad question – I’m looking for an overview only, not an exhaustive, detailed list.

In particular, but not exclusively, I’m interested in:

  • Which features are only implemented in one of both chains?
  • Do the data structures differ (blocks, transactions, inputs, outputs)?
  • Is there a difference in which script instructions are supported?
  • What about addresses and address types?
  • Do both chains commonly implement the same BIPs or are BIPs usually exclusive to one chain? Is there a list of which BIPs are implemented in which chain?
  • Overall, what’s the best approach to track past and future changes in both chains? Can you recommend any resources on that issue?

Finding differences by looking at the code does not seem practical to me given the time it’d take me to pinpoint and understand all changes. I used git log --oneline master --reverse on both chains and diffed the results to get some insight, but it’s still hard to detect changes that are relevant to me.

How to make a homomorphic preimage/payment hash with current lightning network / Bitcoin implementations?

If I remember / understand it correctly by using the mechanisms from the scriptless scripts paper we could easily create homomorphic preimages / paymenthashes.

I think this would be a very desirable property (in combination with shamir secret sharing) for example to create trustless escrow services (and not only for payment decolleration)

As far as I understand SHA-256 – which is currently used for payment hashes – is not homomorphic. In fact it is not even supposed to be homomorphic.

Does anyone see any way to gain the onchain enforcable homomorphic property with the current setup / protocol for htlcs and Bitcoin script without the necessity to change to 2party ecdsa magic / scriptless scripts or schnorr?

I fear the answer would be it is impossible but I thought I would ask since I am still a beginner with low level cryptography.

Hash rate, transaction and block relationship

I’m aware that when the hash of the block header (block hash) is below the difficulty target, a block is deemed as validated.

But because I’ve never run a bitcoin node before (will soon), I had a few questions regarding the mining process.

1) When miners are running the BTC software, are they by default confirming transactions in the mem pool based on the highest fees, or are they allowed to choose which transactions they may validate?

2) If you have a higher hash rate, does this mean you can validate transactions quicker as well?

3) When a block is validated on average every 10 minutes, as set by the BTC protocol, are miners also trying to validate transactions too?

4) How are transactions validated?