Take note that Bitcoin Gold and Bitcon SV are forks of bitcoin. So, if you find a private key of a bitcoin address funded before those hard forks time, you should be able to move the forked coins as well. A bitcoin private key isn't a valid ethereum private key or a valid Dash private key and you can't use that private key to move fund in those blockchains.
|
|
|
The seed phrase you are talking about is called BIP39, not BIP32.
A 12 word BIP39 seed phrase provides 128 bits of entropy and is secure enough. Do not worry about the safety of your seed phrase. Even if electrum doesn't support BIP39 seed phrases in the future updates, there won't be anything to worry about. There are many other tools that can be used to derive the private keys from a BIP39 seed phrase.
|
|
|
If you want to pay lower transaction fee, consider consolidating your UTXOs when transactions can be made with the fee rate of only 1 sat/vbyte. If you haven't consolidate your UTXOs before and now you want to make a transaction, select your UTXOs so that the number of inputs is as small as possible. The more inputs you add to your transaction, the more fee you have to pay. It doesn't really matter which UTXO has been received earlier and which one has been received later.
Note that in the case you care about your privacy, it may be bad if you use multiple UTXOs in a single transaction.
|
|
|
It may worth mentioning that Electrum 4.3.2 has a change in its behavior, and may be exactly your "problem". The thing is that, from the others' point of view, this is a fix. (fixes #7927). With that update, electrum should regenerate an address that has been generated before in another request, if the previous request has been expired and the address has never received any fund. Since OP has set the expiry time to never, electrum shouldn't generate the same address again. I don't think what's happening in OP's wallet is the correct behavior.
|
|
|
yes the transaction screen then appears but not getting anywhere with it as there is nothing to combine, export or sign so close is the only option left.
Click on "sign" button and then broadcast the transaction. After that, the original transaction will be replaced by a new one paying higher fee. Edit: As I see in the mempool, you increased the fee rate to 2.7 sat/byte successfully.
|
|
|
rbf is enabled. Clicked on transaction and then increase fee, oked that but no sign that it took effect and still reporting old fee no error.
As the original transaction is still valid, you haven't increased the fee at all. If you had increased the fee, the original transaction should have been replaced by a new transaction. What happens when you click on "OK" button? After that, a new window in which you broadcast the replacing transaction should popup.
|
|
|
The only thing that comes to mind is that you restored your wallet using your seed phrase and electrum generated your unused addresses again. When you restore your wallet using your seed phrase, you create a new wallet file and electrum doesn't know which addresses have been generated before, unless they have received fund.
|
|
|
It has been more than 5 years since segwit soft fork has been introduced. So, almost any wallet should allow you to send bitcoin from legacy address to bech32 address and vice-versa. If there's a wallet or an exchange that doesn't allow you to do so, you should avoid it. Because it would mean that they haven't updated their system even after 5 years.
Bitcoin protocol allows sending bitcoin from any address type to any address type.
|
|
|
isn't there a simple site where you can input few data and it gives you an estimated transfer fee? I want to know how much it costs to transfer 10 Bitcoin from 1 wallet to another wallet.
Note that transaction fee doesn't depend on the amount you send. So, it doesn't matter whether you are sending 1000 BTC or 1000 satoshi. When you make a transaction, you should set the fee rate according to network state and how fast you want your transaction to be confirmed. The total fee depends on number of inputs and outputs and address(es) type as well. You can use bitcoindata.science (a tool created by the forum user, bitmover) to calculate the total fee based on number of inputs and outputs, your address type and the fee rate.
|
|
|
This wallet is multi-functional and supports different blockchains, but if you really want to separate your BTC from your altcoins is better to choose Electrum wallet for BTC and TrustWallet for the altcoins. Both are open-source wallets that you can trust, as long as it is open-source we can assure that our fund is safe and we have control over our portfolio.
Trust wallet isn't open-source and there is no way to know how the keys are generated and whether they have access to users keys or not. In their website, they claim that trustwallet is open-source, but they are lying. It used to be open-source and their source code has been last updated around 4 years ago.
|
|
|
Its weird since the issue is only for me.
Maybe, there's a problem with your internet connection. It's possible that your internet service provider is preventing the captcha from being loaded or the captcha service provider has blocked your ISP. Have you tried loading the webpage with a VPN?
|
|
|
So basically using multi-Sig cold wallet on airgapped machine provides the ultimate security?
With using a multi-signature wallet, you may increase your security, but I recommend you use it if it's really required. Multi-signature addresses are usually used when a transaction should be signed by multiple parties. If you generate a single-signature wallet on an air-gapped device and keep your keys safe, it's secure enough. I was thinking what if someone generate the same private key as my address in case of single address (which is very very unlikely) but using multi-sig makes this impossible,yes?
Whether you use a single-signature address or a multi-signature address, that's impossible. If an address is multi sig of say 3 address then attacker has to find 3 private keys correct?
It depends. If the address is a 3 of 3 multi-signature address, all the three private keys would be required. If the address is a 1 of 3 multi-signature address, a single private key would be enough. Also bitcoin send to individual address which generate multi-Sig can also be spent individually right?
Yes. Each of private keys used for generating the multi-signature address can be used for generating a single-signature address individually.
|
|
|
What is the public key of actual address that i mentioned in OP which is the address 3BJKWL5ipkVe2bjkRSt6ZNbVWQaRrEFjMs ?
That address is a multi-signature address and for generating that, you need all the three public keys. In a m of n multi-signature address, there are n private keys and n public keys and you need m of the private keys to spend fund from that. The address in question is 2 of 3 multi-signature. So, there are 3 public keys and 3 private keys and for spending fund from it, 2 of private keys are required.
|
|
|
I mean for multi-sig wallet it's harder to find public key if there's output transactions?
No. It's not really hard. As mentioned by jackg, you should use the redeem script to get the public keys. I didn't know how it can be done. I just made a search and found out it's really easy. Click here to see one of the transactions made from the address you referred to in the OP. See the input with the index number 135. The sigscript includes 3 hex data. The last one is the redeem script. Redeem script: 522102707f8c41a9ce80bd85c335ce37617388fe8fd5c7b6079f730fc8b7159867cb3e2102f61a255027b492203f04396474e032e759367ad32cdb1b317074e216718f9b532102ae11e6f80d33717c8dffcbd4e480b95f82f9fe7478cb166beebddd5b062c9f9653ae For getting the public keys, all you need to do is to decode the redeem script using coinb.in tool. The three public keys used for generating the address in question are as follows. 02707f8c41a9ce80bd85c335ce37617388fe8fd5c7b6079f730fc8b7159867cb3e 02f61a255027b492203f04396474e032e759367ad32cdb1b317074e216718f9b53 02ae11e6f80d33717c8dffcbd4e480b95f82f9fe7478cb166beebddd5b062c9f96
|
|
|
It's easy to test by signing the same message twice: the signature changes.
The signature changes? It seems that there's something I don't understand here. I just signed a message. Address: bc1qy22tj52f469y8zf9jalzyhc6snldqq8nqzfw56 private key: L5VtBJJUv6NKym6JZLfF53iqAfA34kadmAsFAc5DV8vqrNYNJJwK
Message: This message is signed for testing purposes. Signature: IGu0FwHYh48v5UU9/SQLTq/f9WPEi6N0qz4N7+oT4/GXIpjmvlZ8rj72r8Eoyj6DEkLsWX9D/c9qSvkwsHYvCZI= How can you have a different signature if you sign the same message from the same address? Shouldn't you have the same signature every time you sign the the same message from the same address?
|
|
|
I made a second transaction with the same source/destination address and amount, just with a higher fee. From there I got the same transaction hex.
This is not possible. For increasing transaction fee, you have to either add an extra input or decrease the output value. With the change in transaction data, the transaction hash should change as well.
|
|
|
1.) I know 100% that when you send bitcoins from legacy Address (P2PKH) then your public key gets revealed in transaction signature So this is also true in case of other Address formats (P2SH and P2WPKH) ?
Yes, your public key is always revealed. Since nodes need your public key for verifying your transaction, you have to reveal it. The address in question is a multi-signature address and has been generated using three different public keys. I don't know how, but it should be possible to derive all the three public keys from data of a transaction made from that address. 3.) How can i hide my public key while still Re-using the same address for spending? I suppose it's possible because the address i mentioned in question 2 is able to achieve that.
I don't see any reason for hiding the public key and I said above, you have to reveal your public key whenever you make a transaction.
|
|
|
if tx ID is made by hashing tx data, and the data doesn't change (destination, amount fee, locktime, etc), then the hash result will always be the same, correct?
If nothing is changed, you have actually made the same transaction and if you broadcast it, you actually re-broadcast the previous transaction. Though now I'm curious also about seoincorporation's post... what did they change to get a diff ID? Is it that "clam-speech" bit? What's that?
I don't really know what's "clam-speech". As I see in the post made by seoincorporation the "time" has been also changed.
|
|
|
NotATether didn't say that he changed the fee or locktime.
I don't know what exactly NotATether did. He probably made a new transaction which should have a different ID. If you click on the link he provided in the OP, you will see that transaction doesn't exist. Yes, if you change these intentionally, you will get a different txid. But what is the reason to change the txid? Do the nodes accept it as a new transaction (with the same input) if the old one is in the mempool?
If the transaction has the same ID, that's not a new transaction at all. That would be the same transaction. If the original transaction hasn't been flagged as FBF, nodes will reject the new transaction. If the original transaction has been flagged as RBF and the new transaction meets the requirements specified in BIP125, it will be accepted by the nodes.
|
|
|
|