Sorry, sendrawtransaction indeed works.
Seems like I have used the wrong UTXO on my previous test.
The previous transaction and its descendants were automatically booted out of the node's mempool.

The problem here is Bitcoin [BTC] isn't [USDT].
What you've received in Electrum was the Bitcoin transaction made to "mark" the USDT transaction; bec. Electrum only supports BTC, it only saw the BTC tx.
Next time, make sure to check the unit of the coin, not just the address format before sending.

Refer to the post above for the possible solution.

After manually creating a replacement signed raw transaction?
You will probably get "txn-mempool-conflict" due to the same reason achow101 explained above (I've only tested in on regtest).

But sending that RAW transaction through other clients might work as long as the to-be-replaced transaction is RBF.

By using the posted images of the advanced preview above, find the drop-down menu beside the fee slider that has "ETA" as default.
Change it to "mempool" and the fee estimation should be "fixed".

It should go down a lot if there are too many high-fee transactions despite having a lower average rate.
But as they said, if your wallet have used too many inputs, then the total fee will still be relatively high.

No, you wont be able to broadcast that transaction before the set locktime, using RBF isn't necessary in that case.
You can give him the signed RAW TX so he can broadcast it himself after the locktime;
if you're not satisfied, create a new TX spending the input of that RAW transaction before the locktime to invalidate it.

Plus, delaying the payment and "promising" not to make a replacement transaction involves a lot of risk for the merchant and trust to the buyer (you).

One of the reason to verify signatures is to confirm that the compiled /downloaded file was really built from source by the author(s)/contributor(s).
If you've downloaded from source which you should've audited since it's "open-source", then there's no point in verifying.

Okay, seems like there's something wrong with Vanitygen when it comes with Altcoins, but there's a workaround to that.

You can convert the result invalid WIF private key into the correct format by base58-decoding it into HEX, remove the checksum and network bytes,
and you got the private key.
Then covert that into WIF by doing vice-versa but this time, use "0x80" instead of '0x0A' in front.

This page automates all of that, displays an example and the steps: https://gobittest.appspot.com/PrivateKey,
Just paste the N, M or L WIF prvkey to the first text box, hit "send", and the result will be displayed under "Private key to wallet import format" at step #7.
But it's not available offline, if you want a secure method, find a script or something.

I have a machine with the same (unsolved even with v4.0.2) issue, but it's not MAC.

For now, try to see if you can find something in the "log";
to enable it without a working Electrum GUI, you need to edit the config file in the data directory: Data Directory Locations
(AFAIK it will create the files even if the GUI won't launch)
Open "config" with a text editor and edit "log_to_file": false, into "log_to_file": true,
If there's no line for the log config, manually add it below "is_maximized": false, (follow the indentation).

Then launch Electrum, it won't start since it's the issue.
After a few seconds, open 'Data Directory\logs' and open the log (txt) file and check the contents for possible 'clues'.
If you didn't find entries like "...|     INFO | gui.qt.ElectrumGui | Qt GUI starting up", we have the same issue: electrum/issues/5974

AFAIK, you should be able to use the result of vanitygen to IXC,
if '1' isn't useable, you should convert the address manually by 'BASE58 decode' the address then change the network bytes and checksum.
The private key should be the same as Bitcoin WIF prv key (uncompressed) based from an IXC paper wallet generator (link).

Everything you said here aren't what vanitygen would produce. Vanitygen's result WIF prvkey for mainnet will always start with '5' consisting of 51-characters.
Are you sure that you're using the right binary (from OP) or commands?

Are you using this to bruteforce a private key? Bec. it's not recommended for that.

Yes, open the console and type listaddresses(), then 'copy->paste' the results to a text file.
To show the console, click "View->Show Console".

HCP tried it and it worked, I have also done the same steps and it worked.
If you're sure that it restored the same username as the one he had set in the original wallet (used username can't be set to another wallet),
then the only way to resolve this is to wait for their response to your customer support inquiry because the backup should've restored the address using native SegWit's default derivation path.

There's also a chance that there's a corruption happened and that's out of their support's scope.

Or, is you "friend" your friend or another party of a deal?

"Coinbase App" and "Coinbase Wallet App" are two different applications. (weird naming system right?)
The former can be used in conjunction with the webpage, but the latter is a non-custodial wallet. (info)

@BitCryptex I think it will only need an average of 1 day to retrieve the funds in case of force-closure.
I've tried to force close mine and according to this:


It will only require 144blocks = 1day (for 10min/block) to broadcast the saved "our_ctx_to_local" transaction.
And it did automatically broadcast after a day+.

The address is Native SegWit so it couldn't be anything other than: m/84'/0'/0' for BIP84 or m/0 if Coinbase is using BIP141 for SegWit.
Since it's Coinbase Wallet App, it must be BIP84.
But for Electrum, you should first select "native segwit (p2wpkh)" before editing the derivation path;
otherwise, It'll create legacy addresses despite the change of derivation path.

There's also a chance that the address is at higher index than Electrum's default of 20,
in that case, try to create more addresses by typing this in the console (View->Show Console):
Then restart Electrum.
Change "False" to "True" if you want to generate change addresses.

Lastly, sharing the address' public key wont help anyone in finding the correct derivation path.
It should be the "Master Public Key" (zpub), but that will cause your 'friend' privacy issues.

For what purpose, may I ask?

Because if it's to access the wallet files and you don't have root access, you can use the "backup" feature of v4.0+.
The wallet file backup will be saved inside "org.electrum.electrum" folder in the root of your phone/external storage.

How to Backup: Click the wallet name above, then Click "Save Backup"

Blockchain()com calls the seed phrase (BIP39 seed) as "Backup Phrase". Does the term ring a bell?
It's the 12-word backup that you can retrieve in the "Security" section while you're login. (of'couse you can't retrieve it now)

BTW, I've tried to login my dummy account just now and I immediately received the authorization email.
Try logging in at this hour.

Thanks!
Seems like it's done to prove that it's possible, an example or something like a publicity stunt. The two zero-fee transactions were included by them obviously.
I thought those are like full blocks where the miner didn't claim the transaction fees (I'm a bit disappointed, just a bit :D).

So, there were two non-empty-zero-fee blocks in 2020, can you specify the height of those blocks?
I'm a bit curious on the included transactions (just a bit). TIA

AFAIK, some clients will let you set tx fee to '0' or lower than 1sat/B like Electrum... but most nodes wont relay it (including the servers) because of BitcoinCore's later version's default "minimum transaction relay fee".
0 fee isn't invalid and the relay setting is configurable so, it's possible to send a <1 or 0 sat/B TX by sending it directly to a "friend" solo miner or pool.

Then your dumpprivkey attempt should work.
Make sure to paste the right address after the command, maybe because the transactions in the 'transactions' tab
only show the recipient(s) and 'copy address' option also only copies the recipient(s). <-based from latest version BTW.

As instructed above, you need to dump the private key of the sender's address (your address).
You can find it in the previous "inbound transaction" that funded that "forgotten transaction".
Also, use walletpassphrase first before using dumpprivkey, IDK how 0.8.3 behaves when the wallet is encrypted and you try to dump keys.

If it still resulted with "error code -4", then, you most likely doesn't have the private key for that input to begin with or the wallet was corrupted somehow

That means your wallet doesn't have the private key for the specified address in the dumpprivkey command.

Are you the sender? then you should type the inputs instead of the outputs of that "forgotten" transaction.
If you're the receiver, then use the output(s) but if it's a dropped unconfirmed transaction, there should be any balance in that address.

Shouldn't it be 58^52? And in case BlackHatCoiner has OCD, here's the long version:

Number of possible private keys (0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140):
115,792,089,237,316,195,423,570,985,008,687,907,852,837,564,279,074,904,382,605,163,141,518,161,494,336

Versus the number of possible WIF private keys - w/ 'compressed' flag [2(58^51)] - bec. as PawGo said, 1st char can only be L or K:
1,721,304,354,322,858,219,998,073,995,373,832,299,052,209,661,408,398,572,522,296,403,141,565,996,879,834,236,147,728,384

@BlackHatCoiner isn't that good? Because unlike addresses, there will be an astronomically lower chance of collision for Prv key and WIF (Wallet Import Format).