The days of 1 sat/byte transactions are gone for a while, I suspect...



and at one point it was purging transactions below 5 sats/vbyte: https://statoshi.info/d/000000020/memory-pool?orgId=1

Given the insane bull run we're on and breaking $50k... nodes are now purging transactions below 4 sats/vbyte due to "mempool min fee"... I can't even attempt to send a 3.6 sat/vbyte transaction:

Blockchain.com shows the time it last "received" a transaction... currently, your transaction is showing with a datetime received (in UTC) of:

BTC.com doesn't have it
Blockchair says: Time (UTC) 2021-01-30 16:01(18 days ago)
Blockcypher doesn't have it
Blockstream.info doesn't have it

and my local node here doesn't have it either:

I suspect that blockchain.com rebroadcasts transactions... at least to it's own mempool... but the transaction is not currently "well propagated". Given that most nodes seem to have dropped this transaction, the odds of it being confirmed in a block are actually relatively poor.

Indeed... it seems that your transaction has been a "victim" of the "mempool min fee":

Given the massive uptick in activity with breaking the $50k barrier etc... it seems that transactions below 4 sats/byte (!!?! ) are being "purged": https://statoshi.info/d/000000020/memory-pool?orgId=1

Likely their system is just under immense load given the bull run and new 50+k "all time high"... lots of users trying to access/use the system etc and it is not handling it well. Likewise, I imagine their support is swamped... they've always been slow to respond to support tickets and I imagine it has only become worse.

Also, given you tried a new email address and it worked OK, it's possibly also a delay caused by your email provider. You should check with them too.


Is this some sort of "staking" thing where you have to deposit your funds into a special account or something? If so, then there is likely no way to recover this without help from Blockchain.com support

Yet another reason why users should be wary of using "custodial" services... as always "not your keys, not your coin"!

PyWallet is in the process of being updated by the author who has made some "breaking" changes... and unfortunately, a lot of the old "tutorials" and commands no longer work.

So, do as the deprecation message suggested and use the --wallet option instead of --datadir:
This assumes that your "wallet.dat" file is actually called wallet.dat and is in the same directory as the pywallet.py script file... if not, just change wallet.dat to be the full path to the "wallet.dat" file

Just a quick note... you should NOT be using WIF keys that start with a "5" for generating SegWit addresses... these are for "uncompressed" keys... and can cause a great deal of grief!

Only use WIF keys that start with a "K" or an "L" for SegWit. I would hope that any decent wallet would spit out an error and/or warning when trying to use "uncompressed" keys.


No, it doesn't... you'd need to use https://segwitaddress.org/ (for Nested Segwit aka "3" type) and https://segwitaddress.org/bech32/ (for native segwit aka "bc1")

Do you remember exactly how you got this address from the Chrome app?

Did you click the "receive" tab in the Chrome app and it was displayed onscreen... or did you select it from a drop down list box?

If you got it from the drop down list box, then there is a chance that it is actually a "change" address... or that it is out past the gap-limit on most wallets. The dropdown list was not meant to be a way to get "receive" addresses... and was not "ordered". It has caused several users problems locating their coins in the past.

If it's a "change" address, you'd need to modify the derivation paths you're looking in ever so slightly... ie. m/49'/0'/0'/0/0 would become m/49'/0'/0'/1/0
If there is a possibility that it was out past the "gap-limit", you'd need to try using a wallet that supports modifying this (Ledger Live does, but you'd need to update your firmware).


The other possibility, although highly unlikely given the address is still funded after 3+ years, is that you had a clipboard malware back in December 2017, and when you sent the coins, the address you likely "pasted" (into whatever wallet/service that you transferred the 3.31 BTC from) was replaced with a hackers address. However, it is highly unlikely this is the cause because the coins haven't moved.

And whereabouts is the Armory GUI "stuck"? Is it still "parsing tx hashes"? or has it finished and is showing "connected (XXXXXX blocks)"?

Out of curiosity... do your passwords contain any "special" characters or are they all just alphanumeric (ie. letters and numbers only)?

Also, were the wallets created on computers where English was not the default language setting?

You don't have to reinstall... just disable all the prune settings. You will need to remove the "prune" line from bitcoin.conf and also check the "Settings -> Options -> Main" tab in Bitcoin Core and make sure that the "prune block storage to..." option is NOT checked.

Once you have double checked those settings... you can either just delete the blocks folder and start Bitcoin Core... or you can start Bitcoin Core with -reindex... either way it will start downloading and verifying the blocks again.

Are you talking about the Coinbase "Exchange" wallet or the actual separate Coinbase wallet application?

If it's the exchange, you're likely out of luck. They don't provide access to private keys as it is a custodial service, you have no private keys, it's all controlled by coinbase. However, if you're using the their Android/iOS wallet app, you should have the 12 word recovery phrase that can be used in external wallets (like Electrum)... so you can just import the 12 word recovery phrase into a wallet that supports signing messages.

I was being a bit generous with usernames involving numbers and the other one was a very short username that I guess just accidentally lined up.

Ooof... that was a bit of a workout... but I eventually got there after a couple of "red herrings"... "found" 2 (!!?! ) "extra" usernames

verification

OP is using Bitcoin Core... which will let you generate all three... Legacy, Nested and Native... (and create MultiSig's if you want )

So, it's entirely possible they have 30 P2SH and 10 bech32 inputs... Generally, it's caused by using the "default" options (which tries to generate bech32 addresses), but then unchecking the "generate native segwit (bech 32) address" box in the "receive" tab... this will give you a P2SH-P2WPKH (nested) receive address... but when you spend these coins, Bitcoin Core will default to bech32 change addresses if you haven't explicitly set it using the commandline arguments.

What do you see in the dbLog.txt file? Is there anything being added to that? I suspect it might be ArmoryDB that is not working correctly.

A couple of things...

That is an outdated version of Armory... it likely won't work with newer versions of Bitcoin Core... I assume you got it from https://www.bitcoinarmory.com/ DON'T USE THIS WEBSITE!

It's an old and outdated version... you need to get the latest version from here: https://btcarmory.com/ (currently 0.96.5)


Unfortunately, you've just removed all the data that Armory needs. I wasn't suggesting that you use pruned mode, I simply wanted to know if it had been set to that as Bitcoin Core often suggests you do this during install if you don't have a lot of storage space and Armory doesn't work with Bitcoin Core in pruned mode.

Armory requires an unpruned node... you're going to need to remove that line from your bitcoin.conf... and then let Bitcoin Core reindex the entire blockchain. Do you have 350+ gigs of free storage to hold the full blockchain?


And that is why you see nothing... because Armory has not got to the block where your transaction is, so as far as Armory is concerned, your transaction doesn't exist. Until you get Bitcoin Core fully synced and not pruned, you will not be able to get Armory to see all the blocks.

Additionally, the reason Armory stopped at block 352530 is either because your Bitcoin Core node was not fully synced, or due to the fact that it was the old version and doesn't understand newer fields in the block data being provided by Bitcoin Core 0.21.0. Once you have updated to Armory 0.96.5, it should be able to parse the blocks properly (assuming that Bitcoin Core is actually fully synced)

---

From this point, I suggest you shutdown Armory and leave it closed. Remove the "prune" line from your bitcoin.conf, then start Bitcoin Core with the -reindex option... let Bitcoin Coin fully sync before attempting to do anything else.

Once Bitcoin Core is fully synced, start Armory and let it try and parse the blocks and transaction data (you may need to use the "Help -> Rebuild and Rescan Databases" option in Armory)

I would think that given that it couldn't read the code properly... whatever it "saved" is most likely garbage data... so converting that back into a QRcode and then rescanning it, would simply yield the same garbage... "GIGO"

It's certainly a tricky problem that UI/UX designers need to consider... "Ease of onboarding" vs. "ensuring customer data is secure"... especially in today's world of "instant gratification, please"

Perhaps another strategy would be to highlight to the user the risks of "transacting" without having created a backup? ie. If you click "receive" (showing intent to receive funds into the wallet) and the backup process has not been completed, either a big warning or another prompt to complete the backup process or both!


I felt like an idiot when it happened to me. I'm just thankful that when I learned the "backup first" lesson... it only cost me a couple of satoshis.

At least you're taking the time to investigate and learn before really diving in... a lot of folks just think it's like fiat banking, open "an account" somewhere and then wonder why they're being asked for KYC/AML, passports, driver's license when they attempt to withdraw etc.


It is definitely secure if you're using the offline airgap setup etc... no doubt about that... but I wouldn't say it was necessarily any more or less "private" than any other Bitcoin Full Node solution.


I believe Trezor claim they don't log IP addresses... they seem to take privacy fairly seriously, so maybe not something you need to be too concerned about? Additionally, the new "native" Trezor Suite application includes a TOR switch.


But, I'm by no means a privacy "expert"... so, I would definitely encourage you to continue to do your own research... and/or have a conversation with @bob123, his knowledge of that sort of stuff is a lot better than mine

Calculating a required bet amount to recover a specific loss is not too difficult...and if you're randomly selecting the chance, this complicates things slightly, but it should still be doable... For starters, you'd need to know the "house edge", so you can calculate the payout from the given "chance". I believe that the dicebot has an inbuilt "house edge" variable... site.edge

For example, when logged into Crypto.games, it shows as:

The formula for calculating payout from chance is:

So, if we randomly generate a chance --> 40

Payout = (100 - 0.8 ) / 40
Payout = 2.48

So far, so good... but that's the easy stuff! Calculating the required bet to recover our total losses is a bit "complicated":

Profit required = (Bet * Payout) - Bet

Which reduces down to:

If our basebet was 10 PLAY... and we'd lost... our profit would be -10 PLAY... so with a payout of 2.48 we'd need to bet:

Bet Reqd = 10 / (2.48 - 1)
Bet = 10 / 1.48
Bet = 6.76

---

Or, if after several losses, our profit was at -100 PLAY... and the "random" chance picked for our next bet was 87... the calculations would be:

Payout = (100 - 0.8 ) / 87
=> 1.14

Bet Reqd = 100 / (1.14 - 1)
=> 100 / 0.14
=> 714.29


If you can't work out the actual code required to implement these two formulas, let me know and I'll try and whip up a demo script.

You'll find the "bitcoin-wallet.exe" in the same location as "bitcoin-cli.exe" and "bitcoind.exe" etc... on Windows, if you have used the Bitcoin Core Windows installer, that should be:

So, using "Command Prompt" (press the Windows key, then type: "cmd"  You should see "Command Prompt", then press enter)... you should be able to enter the follow commands, one at a time:

Couple of notes:
- Make a backup (or three) of your wallet file BEFORE you attempt to use the salvage... it makes permanent changes to the wallet file!
- If your bitcoin datadir is NOT the default location (ie. you set a custom location when running Bitcoin Core for the first time), you'll need to use the -datadir option as well (you can find the datadir in Bitcoin Core GUI under "Window -> Information")