... I have found a wallet with BTC in it but I only have the wallet address and the bitcoin core passphrase,the wallet.dat is long gone
If the wallet.dat is long gone... then so are your coins  You need one of the following: - Wallet.dat (+ wallet password if any) - Private key for the address(es) that has bitcoin. If you don't have those, you don't have any control over the bitcoins and they're now effectively "lost". |
|
|
|
(Un)Fortunately, I have not been able to replicate this issue... Just downloaded and installed the 2.4.1 update (from within Ledger Live)... then did the auto coin app update (as suggested by the release notes) through the manager. Everything seems to be running fine. For the record I'm using: Edition: Windows 10 Pro Version: 1909 OS build: 18363.836 Mind you, I have a lot of the VC++ redist packages already installed due to the requirements of other apps that I have running. It's a shame that so many users are having issues... the new versions of LL are a decent improvement in my opinion |
|
|
|
Those first messages are just showing that it was syncing new blocks... you can ignore the "unknown version" messages... while it can be alarming to see, they're 'normal'. It's a bit tricky to diagnose when you're giving snippets of debug.log... so you got that "Error: Out of memory" AFTER you executed bitcoin-cli stop and the node was shutting down? Did you get the normal shutting down debug like this: 2020-06-05T06:31:18Z tor: Thread interrupt
2020-06-05T06:31:18Z opencon thread exit
2020-06-05T06:31:18Z addcon thread exit
2020-06-05T06:31:18Z Shutdown: In progress...
2020-06-05T06:31:18Z torcontrol thread exit
2020-06-05T06:31:18Z net thread exit
2020-06-05T06:31:18Z msghand thread exit
2020-06-05T06:31:44Z scheduler thread exit
2020-06-05T06:31:44Z Dumped mempool: 0.000997s to copy, 0.152187s to dump
2020-06-05T06:31:44Z FlushStateToDisk: write coins cache to disk (677775 coins, 94304kB) started
And then it died at this point with the OOM?  |
|
|
|
Good to know... I'll give up timing it then if it's been that long for you... I'm now at ~10 hours and still nothing in either the main inbox or even in the spam filter... They were able to send me a notification email telling me about their new "interest account" system tho  And yes, the 2FA emails take a few seconds... not sure why their reminder system is so broken. For the record, I already know the wallet-id, I just wanted to see how long it was going to take. |
|
|
|
Well, it's connected and achieving network connections to peers, so it should be receiving new blocks... Using the reindex option, you might need to give it some time to finish that process before it starts receiving/validating new blocks... is there anything obvious in the debug.log that might explain why it's not? |
|
|
|
Sadly i've installed this also.
unistalled it already. But i'm afraid it left something in my machine. Does anyone know what installed? or know how to analyze it? Can't format my Computer :\
Aside from the reformat option, there isn't much else you can do aside from using antivirus and/or antimalware scanners... The Bleeping Computer forums have a lot of useful resources and links to a lot of free tools that you can use. |
|
|
|
I get only about 402000 blocks.
For whatever reason, it seems like your node is not syncing... is the number of blocks increasing at all? What output do you get if you run bitcoin-cli getnetworkinfo? Do you see "networkactive": true and "connections": XX where XX is > 0? |
|
|
|
That means you created the wallet with a different email. Even wallets created in 2015 or earlier will be possible to request a wallet id an/or backup if you have access to the correct e-mail account
Not necessarily... their automated systems are somewhat unreliable as well as their notoriously slow support... as an example, this morning I've requested a wallet-id reminder for an email address that I know is 100% correct. It's been nearly 2 hours and the reminder email still has not arrived. My advice to OP is to not expect blockchain.info/com to respond to your requests in a hurry... set your expectations REALLY low  And I concur with mocacinno... you should move away from web wallets as soon as practical... I'd recommend Electrum as well if you want something lightweight and don't want to download and/or store the full 300+gigs of blockchain data with Bitcoin Core |
|
|
|
Well... currently, it's constrained more by amounts than anything else. Trying to find paths through channels that allow sending of more than 50k-100k sats can be problematic  |
|
|
|
Yes it is possible to do that... but you'd probably be reinventing the wheel... there are already blockfile parsers available: https://github.com/alecalve/python-bitcoin-blockchain-parserAnd yes, it is highly likely that the big block explorers like b.info, blockcypher, blockchair etc all have custom databases where they store indexed data that they have parsed from the blockchain data. |
|
|
|
... y not combining b4 sending?
Because that's the way Bitcoin works... it's not like a bank account where they just keep adding numbers to your balance when you deposit and you can take out an exact amount later on. Bitcoin is more like chunks of gold... and every piece you receive stays like that until you want to spend it, so you end up with different sized chunks worth different amounts. So you might have a 0.01 BTC chunk, a 0.02 BTC chunk, a 0.008 BTC chunk etc... when you want to send some to someone, you can't just break a piece off... you have to give whole chunks to the miners to break down for you... So, if you have received the following amounts in your wallet: 0.01 BTC 0.02 BTC 0.008 BTC And you want to send 0.017 BTC to your friend... your wallet would most likely select the 0.02 chunk and tell the miners to break off 0.017 and give that to the recipient, and return the rest to you as "change"... The transaction would look like: InputA: 0.02BTC ---> OutputA: 0.017 BTC ---> OutputB: 0.003 BTC OutputB would be your change. Or... the wallet might decide to do it like this: InputA: 0.01 ---> OutputA: 0.017 InputB: 0.008 ---> OutputB: 0.001 or it could use any other combination of 0.01, 0.02 and/or 0.008 that enabled the wallet to be able to create the 0.017 piece that you're trying to send and then give the rest back to you as change (minus the transaction fee) |
|
|
|
I can't find any way by myself to generate a seed from the wallet I own; what are the options I got?
That is because Electrum does not allow the "mixing" of seed-based wallets and imported private keys. Your options are: 1. Make multiple backups of your current wallet file and/or backups of the private keys in your "imported" wallet (ie. write them out on paper etc) or 2. Create a completely new Electrum "standard" wallet... (new/restore -> Standard Wallet -> Create a new seed)... once you have set that up and have the seed written on paper, simply send ALL the funds from your old "imported" wallet to an address from your new "standard" wallet (TIP: type a ! in the "amount" box to send ALL funds minus fee... Electrum will automatically calculate the max amount available based on the fee rate set) |
|
|
|
Can I use lightning network to solve this problem and send my BTC as fast as possible before the exchange rate drops?
Also, note that lightning generally isn't suitable for sending "large" amounts... for one, it is still in "beta" and putting in large amounts has a higher risk... also, most channels only hold a few hundred thousand sats at most... so, you'll generally only be able to send $10's of $ of value... rather than $100's or $1000's. Lightning is really aimed at micro-transactions for a few dollars. Sadly, the fees charged by most exchanges will eat into small dollar transactions quite significantly. |
|
|
|
What if those 2 addresses have 1000+ transactions in history, would it be affecting the loading again on new wallet?
Possibly, but only on the first sync... and the first time you try to consolidate or spend the UTXOs (or if they build up a large number of UTXOs again from 1000s of pool payouts). Consolidate regularly if you can, and it should stop it becoming a problem. A new SEED is not imperative thing. One can use the old one but define the new derivation path. For example, if the old derivation path for the pool with the native segwit addresses was like this m/84'/0'/0' one can outline the next pools with the derivation paths like m/84'/0'/1' , m/84'/0'/2', m/84'/0'/3', .... and so on.
Yes you can... but then you also run into the problem of needing to ensure you keep good notes regarding what you have done... otherwise, you will run into problems trying to restore the wallet in the future as most people don't (and some wallets don't allow to) modify derivation paths... Both options are valid, but I would say that having a new seed with a default derivation path is probably less hassle in the long run. User preference I guess...  |
|
|
|
I guess I should've expected an endless stream of niggles and holes with hardware wallets, but it still surprises me when yet another pops up.
You might want to read the release and the detailed explanation again... it's not an issue with the hardware wallet so much as it is a fundamental problem with the design of SegWit transaction validation. Note that this vulnerability is inherent in the design of BIP-143 I would think that theoretically any wallet could be exploited like this, not just hardware wallets... but looking at the details, I'd agree with Trezor's assessment that it is indeed a "corner case" and not likely to be a "real" problem. |
|
|
|
Just I am curious:
There is also a minimum Transaction sizeOutput Amount I think in Bitcoin Core. Yuu can not send 100 sat.
Sats are not related to transaction size. The reason your transaction failed is because there are inbuilt mechanisms to prevent the creation of "dust"... as bob123 mentioned, "dust" is defined as any output that would cost more to spend than it is worth. Currently, this is defined in the Bitcoin Core code as: // "Dust" is defined in terms of dustRelayFee,
// which has units satoshis-per-kilobyte.
// If you'd pay more in fees than the value of the output
// to spend something, then we consider it dust.
// A typical spendable non-segwit txout is 34 bytes big, and will
// need a CTxIn of at least 148 bytes to spend:
// so dust is a spendable txout less than
// 182*dustRelayFee/1000 (in satoshis).
// 546 satoshis at the default rate of 3000 sat/kB.
// A typical spendable segwit txout is 31 bytes big, and will
// need a CTxIn of at least 67 bytes to spend:
// so dust is a spendable txout less than
// 98*dustRelayFee/1000 (in satoshis).
// 294 satoshis at the default rate of 3000 sat/kB.
NOTE: quoted edited for clarity. So, if it is a "legacy" UTXO being created, it has to be at least 546 sats... if it is a "segwit" UTXO being created, it has to be at least 294 sats I tried that when I wanted to send 100 sat to Waren Buffet wallet.
Try sending Warren Buffet 546 sats (or 294 if he has a segwit address) |
|
|
|
It would appear increasingly likely that there is a hardware issue of some description. If you're getting corrupted files occurring randomly, then the most likely culprits are either your HDD/SSD or possibly bad RAM... there is also a possibility that it's the drive/memory controller and/or chipset on the mobo that is failing. Diagnosing the exact cause of these faults can be tricky... you might also want to try using Memtest86+ and see if there are any issues with your RAM. |
|
|
|
There is no direct RPC call built into Bitcoin Core that you can use to say "give me the balance of any given address". You would need to build your own bespoke database, derived from blockchain data that you could then query using your block explorer. Something similar to this open-source block explorer: https://github.com/iquidus/explorerYou'll see it has a "sync" module which parses transaction data and updates local database files. It also requires that your node is running with the txindex=1 option enabled (either on commandline or in bitcoin.conf) so that all transactions are indexed and not just ones that are related to your own wallet addresses. |
|
|
|
... I never put any 2FA codes into the malicius wallet and as I have removed the software and installed a non malicius version, I should be fine?
Does your wallet actually say "[2fa]" in the titlebar?  If it does, then your funds should be relatively safe, as there is nothing a thief can do without your 2fa codes. However, if it doesn't, and you just have a standard wallet, there is a chance that the malicious version could contain a keylogger and have sent your wallet file/seed/password to the hacker. In any case, the fact that you downloaded, installed and ran a "malicious" version of Electrum means that it could have been laced with any number of viruses/malware such as Remote Access Trojans (aka RATs), keyloggers, screengrabbers etc... Unless you do either a full system sweep using AV/Antimalware software or, preferably, a full system wipe and reinstall, then you can't really be confident that your system is "OK". Whether or not you're comfortable with that risk is up to you. |
|
|
|
|
Show Posts
