<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-04-01T21:31:36.547Z
2021-04-01T21:31:36.547Z
Gabriel
<p>It is not as simple as checking the address format.</p>
<p>Different address formats represent different output types.</p>
<p>An address that starts with a &quot;1&quot; 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 &quot;3&quot;. 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.</p>
<p>More information about segwit wallet development can be found at <a href="https://bitcoincore.org/en/segwit_wallet_dev/" rel="nofollow noreferrer">https://bitcoincore.org/en/segwit_wallet_dev/</a></p>

CC BY-SA 4.0
2021-03-20T02:00:32.570Z
2021-03-20T02:00:32.570Z
m1xolyd1an
<p>Adopting any deposit change at all is not as simple as &quot;just change regex&quot;.</p>
<p>There are a few considerations:</p>
<ol>
<li>Addresses must be generated, and generated properly. All generated addresses that are passed to the frontend <em>must be valid</em> otherwise you have now black-holed future user deposits.</li>
<li>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.</li>
<li>1+2: you should never credit deposits you can't reasonably spend. It's a one-way ticket to insolvency.</li>
<li>Companies with lots of funds under management will inherently be slower to adopt newer technology because of the associated risks. &quot;Will users think they're hacked? Can the customer wallet support sending to it? What it not?&quot; etc.</li>
<li>Larger firms have many teams, which means coordination at all these layers to get anything done. Effort bandwidth is limited.</li>
<li>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.</li>
</ol>

CC BY-SA 4.0
2021-03-22T01:04:12.930Z
2021-03-22T02:00:29.300Z
2021-03-22T02:00:29.300Z
instagibbs
<p>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?</p>

CC BY-SA 4.0
2021-03-20T02:28:10.690Z
Do you mean adopting native segwit addresses for sending or for receiving payments? Since you speak of an address regex checker, I am thinking you meant sending support, but @m1xolyd1an's response makes me think he understood receiving support.
Murch
CC BY-SA 4.0
2021-04-07T08:46:40.610Z
@Murch yes for receiving funds, like when you try to withdraw bitcoin from an exchange.
Dwyte
<exchanges><segregated-witness><bech32-address><p2wpkh><deposit>
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?
Dwyte
# 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?

(Asked by: username_0 on 2021-03-19)

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?

**Tags:** exchanges, segregated-witness, bech32-address, p2wpkh, deposit

> **Comments:**
> **username_1**: Do you mean adopting native segwit addresses for sending or for receiving payments? Since you speak of an address regex checker, I am thinking you meant sending support, but @username_3's response makes me think he understood receiving support.  
> **username_0**: @username_1 yes for receiving funds, like when you try to withdraw bitcoin from an exchange.  

---

## 3 answers

### Answer by username_4 on 2021-03-22. Score: 5 | Accepted answer

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 by username_2 on 2021-04-01. Score: 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 by username_3 on 2021-03-20. Score: 1

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/>


---

