Change From Legacy Wallets To Descriptor Wallets Will Break A Ton Of Supporting Infrastructure

[JaredTate]

It appears the change in RC4 to default to Descriptor Wallets Instead of Legacy Wallets is breaking a ton of infrastructure and causing it to need to be rewritten. Much of this is not an easy task as I have found out trying to get a digihash test mining pool up and running over the last week. Most of the supporting infrastructure built for DGB relies on legacy wallets and has been worked on for 10+ years now. I think we need to revert the changes and stick with legacy wallets in RC4 in the meantime. People can still make descriptor wallets if they want, but it breaks so much stuff it is going to be a disaster for us trying to get 3rd parties to upgrade to 8.22.

The following supporting infrastructure for sure breaks with the default change to descriptor wallets & move away from legacy wallets:

• Mining Pools / NOMP/ DigiHash
• Exchanges, all exchanges I could publicly validate are still built on legacy wallet integrations for UTXO chains, even coinbase for BTC.
• DigiAssets, Digiassets will be affected too.

This change from legacy wallets to descriptor wallets is causing a ton of issues. It completely breaks the digihash nomp pool, and rewriting the mining pool is turning into quite the job. I have spent a couple days trying to re-configure digihash for test mining 8.22 rc4 and it's turning into a much more problematic situation than I expected.

For DigiHash test pool to be compatible with descriptor wallets the entire key management code, pool payouts code, and cryptography/key handling code needs re-written. Also, Code needs to be added for wallet management & many different RPC commands. It is not a simple task. This would also be needed for any closed-source exchange code & public DigiAssets infrastructure.

We simply do not have the team & people to re-write so much infrastructure. Or to provide support & know-how for this. Especially when the overwhelming majority of platforms making up not only DGB but BTC ecosystem still use legacy wallets.

[JaredTate]

We were supposed to still be able to create legacy wallets via RPC commands, but after numerous attempts & research, I cannot get 8.22.0-rc4 to correctly generate legacy wallets correctly. I am not sure if this is a bug or if I am using the incorrect way of doing this. For example:

./digibyte-cli -datadir=.digibyte-scrypt createwallet "ScryptMain" false true false true

./digibyte-cli -datadir=.digibyte-scrypt -rpcwallet=ScryptMain getnewaddress "" "legacy"

I get various errors such as no private keys exist, no wallet exists, and more. Doesnt seem to create a proper legacy wallet.

Also the command dumpprivkey no longer works with descriptor wallets and the command listdescriptors is needed but its a totally different format and key structure. Tons of RPC command changes to descriptors and total cryptographic format changes break tons of stuff.

[JaredTate]

I was able to finally figure out how to generate legacy wallets via digibyte-cli on digihash test pool with following commands:

./digibyte-cli -datadir=.digibyte-scrypt -named createwallet wallet_name=ScryptFinal descriptors=false load_on_startup=true

./digibyte-cli -datadir=.digibyte-sha256 -named createwallet wallet_name=Sha256Final descriptors=false load_on_startup=true

./digibyte-cli -datadir=.digibyte-skein -named createwallet wallet_name=SkeinFinal descriptors=false load_on_startup=true

./digibyte-cli -datadir=.digibyte-qubit -named createwallet wallet_name=QubitFinal descriptors=false load_on_startup=true

Then to get an address for each wallet:

./digibyte-cli -datadir=.digibyte-scrypt -rpcwallet=ScryptFinal getnewaddress

./digibyte-cli -datadir=.digibyte-sha256 -rpcwallet=Sha256Final getnewaddress

./digibyte-cli -datadir=.digibyte-skein -rpcwallet=SkeinFinal getnewaddress

./digibyte-cli -datadir=.digibyte-qubit -rpcwallet=QubitFinal getnewaddress

[JaredTate]

To generate a legacy address with just the "d" prefix I ran:

./digibyte-cli -datadir=.digibyte-scrypt getnewaddress "" "legacy"

./digibyte-cli -datadir=.digibyte-sha256 getnewaddress "" "legacy"

./digibyte-cli` -datadir=.digibyte-skein getnewaddress "" "legacy"

./digibyte-cli -datadir=.digibyte-qubit getnewaddress "" "legacy"

[JaredTate]

I will close this issue but it is important for people to know the descriptor change does require re-configuration of how keys are managed, addresses are generated and much legacy infrastructure will need to be updated. We should expect issues with pools and exchanges complaining about this.

[ghost]

We can easy change it back. I created a PR @JaredTate

[ghost]

I will close this issue but it is important for people to know the descriptor change does require re-configuration of how keys are managed, addresses are generated and much legacy infrastructure will need to be updated. We should expect issues with pools and exchanges complaining about this.

Also nice that people know. If Digibyte 8 RC4 will be released there will be complains about legacy wallet. Because it freeze. https://github.com/DigiByte-Core/digibyte/pull/227 ( video in this pr ) when the wallet becomes to big. Plus legacy wallet is not turned off. Only default is set to descriptor. So with old wallets or by creating a new wallet getnewaddress "Walletname" "legacy" There is no difference in rpc. For any exchange or pool.

[beggsdl]

Also nice that people know. If Digibyte 8 RC4 will be released there will be complains about legacy wallet. Because it freeze. #227 ( video in this pr ) when the wallet becomes to big.

I had my testnet descriptor wallet closed for 10 days. This is the wallet that is getting all my testnet mining rewards. When I opened it, it was taking a fairly long time to sync and then just crashed. It was frozen the whole time. I reopened it. It did open successfully this time, but it did freeze quite a bit while opening. There were close to 70million DGB in it, all coinbase TXs. So while I do think the small freezing that we had seen with the legacy wallet is better, it can still freeze while opening with a lot of new TXs.

[JaredTate]

How many txs do you think are in the wallet? The amount doesn't matter as much as the number of txs. I once tried to open a DigiHash wallet with 100s of thousands of txs in a GUI back in 2016 and it would always crash, just too much data. This is why digibyted was made for servers.

[beggsdl]

There were probably about 77,000 new TXs when I opened it after it was closed for 10 days. And that's just the coinbase TXs for what is currently in the wallet. A couple hundred million have already been sent out. Like when we discussed it while ago, people probably would not normally have the number of transactions that I do going through the QT wallet.

[JaredTate]

There were probably about 77,000 new TXs when I opened it after it was closed for 10 days. And that's just the coinbase TXs for what is currently in the wallet. A couple hundred million have already been sent out. Like when we discussed it a while ago, people probably would not normally have the number of transactions that I do going through the QT wallet.

Wow, yes that is a ton of TX's. Thank you for the feedback! I would bet that if you ran that same wallet via command line/ terminal on a server digibyted or locally you would have no issues.