No... I'm talking about sending to and it really has nothing to do with full nodes... it is simply bad programming on the part of the sites.

Example: Site/Wallet asks you to put your withdrawal address in or the address you want to send to... you enter a bc1 address it says "invalid address"... that is most likely a pure validation issue. Users are then like "Why cannot I send from <InsertBrokenSiteOrWalletHere> to my "bc1" address?"... and this ends up causing confusion and the incorrect belief that you can only send to certain types of addresses from specific address types.

It's probably more correct to say that you can only send to certain address types from some specific wallets/sites... but that's not an issue with Bitcoin, that's because those specific wallets/sites are "broken".

I doubt that is true... it more likely a result of "broken" programming that is doing address validation based purely on Base58 P2PKH and P2SH address formats... that is to say... "1" or "3"-type addresses.

The fallacy that "you can't send from X-type address to Y-type address" came about because certain (popular) websites just don't (or didn't) recognise bech32 addresses (aka "bc1") as being "valid" address types. It has nothing to do with whether or not they're running full nodes.

For instance, you can have v0.17.1 of Bitcoin Core running in the backend, but if your frontend UI is not setup to accept "bech32" as a valid address... then it's still not going to let you send to a bc1 address

Can you explain exactly WHY you want/need to have version 3.2.x?

If the AppImage for the latest version (with the patches for known bugs/vulnerabilities works), why do you want to install an older version?

"Confirmed" probably isn't the right word... there have been a lot of forks, some "successful", some "failures", some were just outright scams.

To my knowledge... the list of "surviving" forks would be whatever is showing in the top 100 on coinmarketcap:
Bitcoin Cash
Bitcoin SV
Bitcoin Gold
Bitcoin Diamond

Anything else is likely trash, failed or simply a scam... and even two (all?) of this list are relatively worthless

What you have described IS the phising attack... Despite the "upgrade" link showing up in Electrum, it was a "fake" message from the thief, pointing to a fake version of Electrum that was NOT hosted on electrum.org. So, you have indeed installed a fake version of Electrum which has sent all your funds to the thief.

Unfortunately, those funds are not recoverable.

That's why hardware wallets allow the use of "Plausible Deniability" and allow you to add a "passphrase" to your 12/24 words... You can create a "dummy" wallet with some spare change using the words... and your REAL wallet is hidden by the passphrase. If someone puts a knife to your neck, give them the seed, they get spare change only

Refer:
https://support.ledger.com/hc/en-us/articles/115005214529-Advanced-passphrase-security
https://blog.trezor.io/passphrase-the-ultimate-protection-for-your-accounts-3a311990925b

Your best option is to download the "AppImage" listed in the "Linux" section of the Electrum.org download page: https://electrum.org/#download

That AppImage includes all the necessary versions of the required libraries and should work without you needing to worry about trying to update Python etc.

If it says "Confirmed" and has a block number... then chances are good that the transaction has been included in the blockchain successfully.

This would then mean one of two things:

1. You sent it to the wrong address
2. Arbistar has not credited your account properly for whatever reason

If you can post your TransactionID(s) here, it will make it easier for us to assist, specifically, it will enable us to determine whether or not the transactions actually have confirmed, and if confirmed, exactly which addresses coins were sent to.

That will not work. Electrum generated seeds are NOT BIP39 compliant... and are incompatible with a Trezor Device.

You can however used a Trezor generated seed on Electrum as it will allow you to import a BIP39 seed.

Yes, that is the standard recovery method using your 24 words..


That is correct... when you use the "passphrase" functionality, you are effectively adding a "25th word"... this "extra word" results in the wallet generating a completely different seed, from which it will logically generate a complete different set of private keys and addresses (ie. a different wallet).

Note:  It could actually be a sentence or multiple words rather than a single word... "25th word" is just used for convenience.


Yes


Your 24 words + passphraseA = WalletA
Your 24 words + passphraseB = WalletB
...
Your 24 words + passphraseX = WalletX

So, if you enter the same "wrong passphrase"... you will generate the same "wrong wallet"


ANY passphrase used will generate a valid seed and therefore a valid wallet... it might not be the wallet you want, but it will be valid. Therefore, there is simply no way that any wallet software would be able to determine if your passphrase is wrong.


Using that information alone, the answer is NO. The only way to recovery that cryptocurrency, is to have the appropriate private keys... the only way to get those private keys is to restore your Trezor.

Using some of that information (ie. the address in your Trezor that you sent the funds to) + your 24 words + What you believe your passphrase is + LOTS of time... you might be able to discover what your passphrase was using some "brute force" methods using tools like "btcrecover"... However, it isn't very likely unless your passphrase is VERY simplistic (ie. less than 8 characters and only numbers/letters)... Anything longer or more complicated than that, and your chances of recovery go from very very very small to nonexistent

That seems to be a fairly accurate representation of how Bitcoin Core is currently setup... and should work.

Obviously, the tricky part is calculating the correct fee You really want to make sure you calculate it properly. If you're very desperate and you need a fast confirmation, overestimating is definitely better than underestimating... otherwise you might end up with TWO unconfirmed transactions left hanging!

I said nothing of the sort...


Bitcoin Cash = BCH

When the fork happened, you had Bitcoin Cash "ABC" and Bitcoin Cash "SV" both vying to be the "True" Bitcoin Cash... As far as I can tell, ABC won... so, BCH == "Bitcoin Cash ABC"... Bitcoin SV generally has a completely different "ticker" on the exchanges.

If you have BCH on your ledger, then it is going to be "ABC"... send it to "Bitcoin Cash ABC" on Binance

No... I'd say that it is most likely because you have an "upgraded" wallet.dat file that has new data fields in it. Pywallet hasn't been updated in a long time... and it doesn't play nicely with the newer wallet.dat format.

I posted a quick "workaround/hack" for it here: https://bitcointalk.org/index.php?topic=34028.msg30435668#msg30435668

Basically, it just ignores the new (irrelevant) data fields and should continue on it's merry way and dump the file contents.

37,000 addresses??!?

I think that is most likely the reason for your "syncing" issue right there... I'm not sure Electrum was ever really designed for that sort of workload!

Having to try and sync that many addresses is likely overwhelming whatever server(s) you are connecting to.  I'm not sure any amount of switching servers is going to resolve your syncing issue. It sounds like your use-case might benefit from running your own full node using Bitcoin Core... it is likely to be better at handling such a massive number of addresses/keys.

You might want to consider setting up Bitcoin Core, importing all your private keys from the Electrum wallet... and let Bitcoin Core do it's thing...

I believe that while it marks the transactions as RBF by default... the "wallet" component of Coinb.in doesn't offer a way to actually use RBF... instead, I believe you would need to create the RBF transaction yourself...


That *should* work... but I'm not sure if the coinb.in wallet itself supports coin control and being able to specify exactly which outputs to spend. You'd probably need to use the "New -> Transaction" functionality of the website and manually craft the transaction, specifying exact inputs, outputs and fees etc.

While it wasn't directly related to the amount of air dropped merit (ie. it wasn't on a 1:2 ratio like sMerit currently is for earned merit)... sMerit was handed out at the same time as merit was originally air dropped.

I believe I received 500 merit (as I was a Hero member at the time)... and received 100 sMerit from memory. The maths seems to sort of back that up.

(note: not entirely accurate stats as BPIP isn't 100% "live" data)

So, I should have had in total (784/2) sMerit = 392... given away 373 merit... difference of 19... but I actually have over 100 sMerit left.

Despite having 100+, I don't consider myself to be hoarding it (I have given 373 to 152 different users after all), it's just I rarely find posts that I think are "worthy"... despite actively reading through B&H etc looking for posts to merit... and I seem to accumulate at about the rate that I give it away

Theymos updated the thread with the details... 2541 people submitted the form but it is possible that not all of them were fools. I suspect that several were probably filled out with "joke" information... much like the selfie thread, there are a lot of people who realised it was a joke and responded accordingly.

If the appimage works, then do as Abdussamad suggested and simply continue to use that... It will save you a lot of time and mucking around trying to troubleshoot dependencies.

Now it seems that your issue is simply that you don't have a menu item for launching Electrum... or, more correctly, the menu item you do have doesn't work... Again, Abdussamad's suggestion is the one to follow. Uninstall the non-working Electrum... and then create a new shortcut for the AppImage.

You shouldn't need your seed to simply update the application... when you update Electrum, it will not overwrite your old wallet file. I'd still recommend that you make a backup copy of your wallet file ("File -> Save Copy" within Electrum), just in case... then simply install the update. You should find that your wallet opens normally and you can continue.

Also, given that you have lost the seed, you should make a completely new wallet and move those coins ASAP. Without the seed, recovery of a 2FA wallet in case of total wallet file loss is impossible.


You can't use that method with a 2FA wallet... an Electrum 2FA wallet is a 2-of-3 multisig... you only have one key stored in the wallet, TrustedCoin have another... the 3rd is "stored" in your backup seed (which you don't have).

Here is a link to the transaction: https://www.blockchain.com/btc/tx/d961cac7aa56c53ac73d7e30ca6eda2a3e318e07786f497504da1728dbec8191

Here is your raw transaction hex:

Simply rebroadcasting it won't result in it being confirmed any faster... your options are:

1. Wait (tough, but it's what a lot of folks are looking at given the current network load )
2. Try "Replace-By-Fee" (aka RBF)... not clear if you were sending from Electrum to Coinb.in... or you have started using Coinb.in as your wallet?
3. Try a "Child Pays For Parent" (aka CPFP)


#1 requires the least amount of effort... greatest amount of patience...
#2 requires that your wallet supports it... and the transaction was marked as RBF... looking at the decode, it is... "opt_in_rbf": true, but unfortunately... I suspect the "change" output is only 0.00000721 BTC which means that you will not raise the fee in any meaningful way (maybe +1 sat/vbyte at best)
#3 requires that you are able to spend either of the two outputs created in this transaction... and then create a transaction that spends the output with a HUGE fee... you'll want to make sure the fee will be big enough that the average fee across both transactions ends up being like 120+ sats/vbyte at current fee levels