How hard is it for an exchange to adopt native segwit? Is it not as simple as updating the address regex checker on the front-end?

Question

Just wondering, maybe I'm missing something. Are there changes on the backend needed to be implemented as well? Not as simple as changing the regex validation on the front end?

Answer 1

Adopting any deposit change at all is not as simple as "just change regex".

There are a few considerations:

1. Addresses must be generated, and generated properly. All generated addresses that are passed to the frontend must be valid otherwise you have now black-holed future user deposits.
2. Can your signing process sign for those new address types? Signing security may use HSMs or other special-purpose signers which may reject the new format for whatever reason.
3. 1+2: you should never credit deposits you can't reasonably spend. It's a one-way ticket to insolvency.
4. Companies with lots of funds under management will inherently be slower to adopt newer technology because of the associated risks. "Will users think they're hacked? Can the customer wallet support sending to it? What it not?" etc.
5. Larger firms have many teams, which means coordination at all these layers to get anything done. Effort bandwidth is limited.
6. At larger trading firms they're often busy putting out other fires, such as scaling their trading engine, hiring, client management, compliance, comms, etc. Being wasteful on block weight usage is embarrassing, but unlikely to bankrupt an exchange seeing 200% YoY growth and puts them at no regulatory risk.

Answer 2

I assume that you're referring to withdrawals, and I think that you're probably right if the company's backend relies on bitcoind to fully process transactions.

If the company's backend manually builds transactions, then that code needs to be updated. Even if you use a stateless bitcoind's RPC interface to build and sign transactions, you still need to update the code that calculates the transaction size to estimate the fee.

Answer 3

It is not as simple as checking the address format.

Different address formats represent different output types.

An address that starts with a "1" is a legacy pay-to-public-key-hash output. When writing wallet software signing transactions for this type of output requires a different order of operations to spend than let's say a pay-to-script-hash address that starts with a "3". Similarly, bech32 addresses are also a different output type, they are pay-to-witness-public-key-hash outputs and although similar to legacy, wallet software needs to be programmed differently to sign these types of outputs.

More information about segwit wallet development can be found at https://bitcoincore.org/en/segwit_wallet_dev/