But if all the ports are blocked in the firewall, won't this catch the port Tor is using too? Like 9050 (though I doubt that particular one because it's bound to localhost) or 9051 in OP's case.
It shouldn't. The port (9050) that Tor uses is a local port for Bitcoin Core to be binded to. It doesn't make sense to portforward it unless you're expecting any data to be transferred through the clearnet. Having both of those ports blocked should still be fine, that is actually my current configuration with none of those being portforwarded. |
|
|
|
This is not correct. You cannot get any incoming peers if your peer gossiping port is blocked. You need to open port 8333 on your firewall and then you should get incoming peers.
It's Tor. It doesn't have anything to do with your local firewall and portforwarding should not be needed, you're binding your listening service to Tor. It would be necessary for clearnet, which is not what OP is trying to achieve here. OP, try manually setting up the service and see if it works: https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md#3-manually-create-a-bitcoin-core-onion-service. |
|
|
|
|
Only via Grin and on-chain transactions for now.
|
|
|
|
If yes try to restore it again with Electrum with your seed and enable BIP39. After that go to wallet>information and look for xPub copy the text and paste it here https://blockpath.com/wallets/new?action=appxpubIt will scan all possible derivation paths and show all addresses with balances and used addresses. Once you found some used addresses with balances use the derivation path shows from the result and restore it again in Electrum but this time use the derivation path that you get from xPub Analyzer. I don't think Bitcoin.com uses any nonstandard derivation path and OP stated that it's BIP44. The built in function should serve OP just fine and won't be leaking that much privacy nor add any extra complexity. |
|
|
|
"How would I get the Public address for the new wallet I created?"
I am looking for the address that starts with bc1
Is there a specific reason why you need to get the address of the first index? If you've already called getnewaddress, try using listaddressgroupings. |
|
|
|
I think you meant passphrase? How did you use dumpwallet *DIRECTORY* in that format? It will not output any text in the cli pertaining to the dump but will create a file in the defined directory. The following syntax works for me. dumpwallet E:/Walletdat1.txt
|
|
|
|
I selected BIP39 and clicked next. I then selected P2PKH as the type and it created the wallet, but it's empty. My funds don't appear.
My wallet is old, it's BIP39 and P2PKH. How do I upgrade to a newer wallet with Segwit etc? Do you have to transfer from a old wallet to new wallet every few years and pay the fee? Is that's the only way to get an updated wallet?
Restore again and this time, click detect existing accounts. No. Your wallet is not old, it is just a P2PKH format and Segwit is a more efficient transaction format. You don't have to "upgrade" your wallet if you don't want to. People upgrade to Segwit to save in their fees but that doesn't mean it is mandatory. If you want to create a segwit wallet, generate a new seed with Electrum and send the funds there. I checked wallet information" and for "Seed available" it says "False".
Does that mean it failed?
No. Electrum doesn't store the seeds for BIP39. |
|
|
|
|
If the checksum passes, then it is probably a BIP39 seed. BIP44 is the standard for the derivation path, BIP39 defines the mnemonic standards. If you click next, you should be able to choose the derivation path. You can let Electrum decide the derivation path automatically and it should work.
|
|
|
|
Of course, this would require a fork, and not everyone would be willing to move or some people aren't going to move. At that point, you'd probably expect that a lot of coins would be available to target, but if we have enough notice, and good enough reasons to fork then I would expect the majority of people would move their coins to the quantum resistant algorithms.
So, this just leaves the coins which have been lost prior, those that didn't want to move, or those that didn't hear about the fork. These are risks, and unfortunately will happen when it comes to it. These coins could be targeted, however if they've been given good enough reason to move, and enough timeframe then they themselves are taking the risk of leaving their coins there. So, they accept the risk of losing them.
We could burn them, given enough notice that does seem very extreme though, and I'm not sure that's the best decision. Undoubtedly, any coins that are left that can be exploited, will likely be exploited eventually, and that would likely have an effect on the short term value of Bitcoin.
Most of Satoshi's block rewards are vulnerable; Bitcoin Core was configured for P2PK in the Coinbase transaction and that makes up for approximately a million (IIRC) of his coin or at least those that weren't moved or presumed lost/burned. Considering that each address has 50 coins, and at current prices, that would be north of 3 million per address. That is assuming Bitcoin doesn't grow further than 60K, which is hard to tell. The economic impact of losing that many coins won't bode well. |
|
|
|
Going to another standard may be somewhat tricky because the older customers' devices will work by old rules, newer device with the new seed and the user may have to know which standard/BIP his seed has, which may be difficult for the average Joe, for which using Electrum is already pretty much tricky.
You can generate a seed with a checksum that is only valid by Electrum's standards while invalid for BIP39 and follow the version bytes for that. Something like this could be done with a firmware update, depending on the kind of hardware wallets and make it possible to generate/restore Electrum type of seeds. |
|
|
|
|
Bitcoin Core does not use .wallet or key files. Those are from MultiBit and preferably, you'll want to download MultiBit to restore it. Since MultiBit is not encrypted, just open it with any text editor and you should see the private keys in it. You can import it into Bitcoin Core after synchronizing. Check if there is a lock at the bottom right corner to check if it is encrypted.
Replacing the wallet.dat should do the job all right. Since you said you used it till around 2014, you should start seeing transactions once you synchronize to that point.
|
|
|
|
I sent these transactions to another wallet as I'm in the process of moving in small amounts to a better wallet. The BTC arrived there but was removed after two days. After that they show unconfirmed on the blockchain. Its been 4 days now and nothing come back and my remaining balance on wallet cannot be moved as I get a "transaction failed to send" message.
Is the "transaction failed to send" message from having two stuck transactions? I did many google searches and cant find anyone else with this problem.
In the recent days, the minmempoolfee has increased to above 2sat/vbyte and in the process, purging anything with a fee rate below that. Blockchain.info seems to have a different policy with that and you won't be able to send any transactions without them first purging it on their blockexplorer. Either export your keys and import it into another wallet or just wait for it to be purged or confirmed. Is there anything I can do to get this BTC back sooner or just wait a long period of time?
Export your keys and use another wallet. |
|
|
|
|
.key extension was most commonly used with Multibit. If you were to open the wallet file with a text editor, are there any human readable parts? It should contains some references to Bitcoin addresses, they're around 34 characters long and starts with 1.
|
|
|
|
|
All of the nodes process transactions if you're going to define it as them validating the transactions. Non-economic nodes, as defined in the article, are important as well as they will be helping with the redundancy of the network and still enforce protocol rules.
While the article has a point, it really has little to do with the actual reality of Bitcoin. If you're using a service with a centralized server, the server has to accept the invalid block as well. It probably won't. But that is just how it can be if you're relying on someone else to tell you which blocks are valid and which aren't. SPV clients requires a diverse set of connection to be listening well to the network and prevent any sort of sybil attack so without having a significant control over the hash rate of the network, it can't be executed against SPV clients. So will the scenario in the article happen? Very unlikely unless everyone starts using a few centralized services.
Running a node does primarily benefit the user who is using it though, the scale of the network as it is right now would bring marginal benefits to the network.
|
|
|
|
I'm not sure the Electrum dev team think their seeds are "better," but are they?
They do. BIP39 was also marked as discouraged for implementation. They still use the same word list, and I imagine the provide the same level of entropy as a bip39 seeds for given phrase length. I thought the re-configured checksums of Electrum seeds are only meant to allow the phrase to define the type of wallet it creates, ie segwit vs legacy. Is there more to it than that?
The version bytes are defined at the start. Checksum has nothing to do with the type of seed it was meant to be. Electrum seeds doesn't require a fixed word list. Trezor's SatoshiLabs were involved with BIP39 development. I don't think it's impossible to implement something like this in their firmware but there isn't any problems with security or anything that urgent which would require something like this. While there's still a small chance that an Electrum seed is a valid BIP39 seed as well, Electrum will ensure that they won't inadvertently generate valid one that is compatible with both in the new release. |
|
|
|
In a way, it's good that the mnemonics aren't stored particularly if they aren't encrypted since the wallet password would then be useless.
My guess is that since the devs aren't thrilled about BIP39 importing support, judging by the depreciation notice on that window, they glossed over some details that were implemented for Electrum mnemonics, storing them in the wallet file (hopefully with encryption!) being one of them.
As mentioned, it probably doesn't make any difference in terms of security. While they aren't happy about people and wallets using BIP39, they could still have some form of uniformity with seed behavior. Having this could force them to eventually switch to Electrum but would be a pain if the user wants to continue using it for the time being. Since they've already implemented BIP39, might as well just be able to display the seed. Judging my the github issue above, it seems like they are alright with having a feature like this. |
|
|
|
I'm importing a BIP39 seed on Electrum 4.0.4. Your code doesn't seem to be the same with mine:
Oh. Electrum doesn't store the mnemonics when you're importing with BIP39, just generates the relevant seeds and discards the mnemonics. Not sure why it wasn't mentioned before actually but it was something I noticed when looking at the BIP39 specific codes. You can probably make an issue about it on Github if you want, should be an easy implementation. |
|
|
|
Are you opening the correct file? Are you importing BIP39 seeds or Electrum seeds? I've tested it again and I can't seem to replicate it. Here's the format represented in JSON in the wallet file with a recovered seed: "keystore": {
"derivation": "m/0'",
"pw_hash_version": 1,
"root_fingerprint": "-snip-",
"seed": "-snip=",
"type": "bip32",
"xprv": "-snip-",
"xpub": "-snip-"
},
If you are able to see the seeds from the UI, the seed should be stored in the wallet file. |
|
|
|
The government, military, and potentially high profile companies are the only ones that would be able to afford quantum computers, and even then a smaller division of this number will actually have a need for quantum computers. I would say that the government, and military are the only ones which could justify the cost. Now, you could say that the government are hostile towards Bitcoin, but that entirely depends on the government your talking about. Many governments have actually successfully regulated Bitcoin, and therefore Bitcoin earns them more money than not having it. By breaking Bitcoin if that was even theoretically possible would actually reduce the amount of money they earn. Bitcoin, isn't likely to replace fiat currencies, at least not for a long time. In fact, Bitcoin is probably not something that would replace it, but a similar implementation of Bitcoin might. Therefore, Bitcoin in its current state is of limited threat, and actually benefits the governments that have successfully regulated it.
By the time, Bitcoin was to become a threat or quantum computers became affordable enough to own for others, Bitcoin as well as banks, and other big industries would have already implemented quantum resistant algorithms, effectively making it redundant.
If the country's primary goal is to evade sanctions and improve financially instead of espionage or anything similar, they'll probably opt to attack Bitcoin. I'm pretty sure North Korea isn't developing quantum computer though. If not, then I think most countries would just start with deciphering the encrypted communication. The problem with quantum computers isn't with the kinds of algorithm that we could move towards in the future but the exposed public keys which would be inherently vulnerable even after the network forks to a new algorithm. Do you burn them or do you just leave a few million Bitcoins to be able to be exploited. Sure, quantum computers are expensive and the cost/benefit doesn't add up but as time goes by, these Bitcoins could eventually be a suitable target. You won't know if anything was broken by ECDSA; spending the 50 Bitcoins from the exposed addresses could just very well mean that whoever controls the private keys wanted to spend them. |
|
|
|
I am waiting to received my bitcoin then when I tried to check on my electrum on my cellphone, it shows EXPIRED on the receiving address that I mentioned that I've clicked NEVER expires.
That's weird. Electrum shouldn't do this by itself. Right click the requests, click Copy Requests and paste it into a text editor/notepad and check what is the exp=. It shouldn't be there. It wouldn't matter if it expires or not as you're going to be receiving multiple payments to the same address. Fair warning, this will result in both your and your sender's privacy being compromised as it is easy to tell apart the transactions when the address is reused. |
|
|
|
|
Show Posts
