One of your Coinbase BTC deposit address is fine for most cases but a non-custodial wallet is a must.
I'd suggest Electrum (electrum.org) for Beginners/low spec PC and Bitcoin Core (bitcoin.org) for Advance users with huge internet bandwidth, DYOR.

One important note: you can only mine bitcoin with specialized mining devices such as "SHA256d ASIC" like some Antminer models,
you can't mine them through a browser with your GPU/CPU, anything that offers such service is most likely an altcoin miner paying very small amount of BTC or a just a malware.
There's a board for bitcoin mining where you can get more info: Bitcoin Forum > Bitcoin > Mining

If you mean to sync the descriptions in the history and addresses: You can use "LabelSync" plug-in.

In Desktop, you can access it via: "Tools->Plugins->LabelSync" (you can force upload/download to sync immediately)
In Android Electrum, it's in: "Menu/...->Settings->Label Sync->Enable" (need app restart after enabling)

With that, your labels will sync across devices as long as the wallet has the same "master public key".
It doesn't have to be a wallet with seed or have the same wallet name.

You'll have to include it as a separate output.

Get the hex-encoded data after "OP_RETURN", and use that as a value for "data".
eg.:

Here's a reference with OP_Return: https://developer.bitcoin.org/reference/rpc/createrawtransaction.html

I think you're right, I've only checked the script in a commitment transaction, it has a RSMC output with this script (can be seen when spent):

Okay so, "public_key1" is the "revocation key" (not electrum trampoline's public key)
which can only be spent by deriving its private key from "electrum trampoline's" "revocation_basepoint_secret" and his "per_commitment_secret".

---

What I'm concerned with is: his wallet might fail to spend the "to_local" output because of the issue.
In that case, if manually editing the wallet file didn't work, he can still coordinate with the owner of Electrum trampoline to recover his funds.

Looks like the channel was already forced-closed by the other party or your recent attempts because the output of: txn 138223... was already spent by txn 258a0b...
The output is P2WSH which likely has "OP_CSV" indicating that it's indeed a result of "force-close" channel.
(Based form the txns, your wallet is P2WPKH)

That's just minutes after your (OP's) last reply and before Rath_'s reply.

Normally, the wallet should automatically create a local transaction with a label: "our_ctx_to_local <short_channel_ID>" to prepare to redeem your funds after the set time in the script.
If you can see a local transaction like that in the history, then it's all good.

---

Nothing?
You can try Rath_'s suggestion and the wallet might create that said transaction after a few restarts/hours.
(I've experienced something similar in testnet after manually editing a channel or I just imagined it)

If not and about a day has passed, you can create an issue in GitHub (link) and they may be able to return your funds since AFAIK, that output's script should have another public key (for the other party's wallet) that can spend it without waiting for the set time.
Good thing it's "electrum trampoline" which might be owned by one of the devs.

Ah, that explains the error when those lines are removed from the config.
He used the command in that linked thread that uses port 18444 but didn't followed the configuration to set the port to 18444.

@decent1984 you got two options to 'fix' it:
Change your code's port to default 18443; or keep it and set 18444 in the config file as instructed in the tutorial.

I see that you have a reply to this thread: How to use regtest - the definitive guide
I followed the instructions in that thread and it worked at my end.
I used your command, changed the rpc user and password then added a command and it worked.

I tried to remove some of the config and it returned with the same error when both these lines are removed:

• connect=127.0.0.1:18444
• rpcport=18444

I can't reproduce it by other means.

Have you included the configs that should be added to the bitcoin.conf file?
take note that it should be in the default data directory and not in the custom datadir that you've set (if you set a different one).

Have you considered that your wallet.dat files may be an Altcoin's wallet files?
It could be a Litecoin wallet.dat since it's an old fork of Bitcoin.

The quoted message from theymos in post #2 should answer your question.
If it wasn't clear, "grandfathered" means "exempted", and the "old ones" are the already-in-use animated avatars before it was disabled.

Exact same thing happened?

Yes? Then redo post number two but check your "debug.log" for the latest lines with:
<date/time> ERROR: AcceptBlockHeader: block xxxxxxxxxxxxxxxxxxBLOCK_HASHxxxxxxxxxxxxxxxxxx is marked invalid
And use that block hash to the command: reconsiderblock

Is it the mobile version? v4.1.5?

Perhaps it behaves differently than the desktop version?
But AFAIK there should also be a payment invoice there after you sent a transaction.

Just follow my suggestion above:


I think it's because of the previous payment invoice's description.
If it's for the same address, the previous ones will be added to the history as well.

So I guess that exchange is an exception from the usual, looks like they assign addresses and manage funds like a non-custodial wallet, except they are in control of the keys.

No, I was talking about most Exchange's usual withdrawal procedure, as explained by Danny.
They consolidate all the users deposits to a hot wallet and use some of it for withdrawal, so the address used for withdrawal is in their control, not the user.

You must be talking about your Shakepay deposit bitcoin address.
They do change deposit address but if it work just like any exchange, the address used for withdrawal isn't tied with your account.
It could be one of their "hot wallet" address that's specifically used for users' withdrawals (can't be 100% sure without the address).

If it's AML policy, try to explain to them that you've bought bitcoins through Shakepay (a custodial service) and sent the bitcoins to them.
Sending them your transaction history and the specific transaction's details might help. (Link: help.shakepay.com - Where can I see my full transaction history on Shakepay?)
You can also send this thread's link as a reference.

There should be a qualified technical support that can understand that Exchange withdrawals doesn't work like a non-custodial bitcoin wallet.

In the developers' notes, Electrum's seed is better than BIP39's (reference: electrum.readthedocs.io/en/latest/seedphrase)

The only disadvantage is you wont be able to restore the seed phrase to other wallets that doesn't support Electrum seed.
That's a minor issue since you can always export the private keys of the addresses with balance
or the master private key (through the console, most wallets can import this) if needed.

You're talking about a new wallet right?

That is the actual use-case of the "seed word extension" so, yes.
But I'd make a separate offline backup of the passphrase (the extra word) just in case because it's not really reliable to keep it "in brain" alone.

It's because it wont work in the first place.
In BIP39, the "mnemonic sentence" itself will be used to generate the seed (binary seed), not the 'entropy' where the words are based.
So if you translate them just based from the position in the wordlist, it will generate a valid seed phrase but an entirely different wallet.

What you want to do is to paste your BIP39 seed phrase to an offline instance of iancoleman's BIP39 tool (iancoleman.io/bip39/, read "Offline usage").
Then select BIP44 tab below, and copy "Account Extended Private Key" that starts with "xprv".
Use that to restore your wallet to your Electrum by selecting: "Standard wallet->Use a master key" and it should generate the same set of addresses as long your Copay wallet is using the default derivation path for BIP44.

(see when you change language in 'BIP39 tool', it uses the same entropy to translate the seed phrase in other language but the "BIP39 Seed" below it changes)

That's because this thread is older than the quoted post.
Also, the decryption tool is for users who know their wallet's password, it can't bruteforce passwords.
The OP in that thread knows his password and got his old mnemonic (only login backup) but cannot login to blockchain.com due to inaccessible email.
It probably didn't worked because of crypto-recovery's tests above.

That's their official wallet decryption tool.
It's quite outdated but still works at that post's timestamp (but it isn't a "cracking tool"), I haven't tested it after they added native SegWit to users' wallets though.

I'd just like to suggest you to please be careful on sending information and files over email/PM.
Specially your wallet.dat, your passphrase and the file where your alleged encrypted private keys are.

Keep the discussion public without giving private information as much as possible so other users can comment on the legitimacy of the "help" you're getting.

---

I wont reply any further until the inconsistencies are cleared.

Regards.

Then it's not a wallet.dat from 2009-2010 or even a few years after because AFAIK HD functionality was just introduced in 2016.
Bitcoin core's version is not the issue.