If you are using Electrum as your interface while sending from a hardware wallet and the device isn't displaying the change address, you can cancel the transaction and check if the change address is part of your wallet in Electrum.
If the firmware gets compromised, it will display any falsified information that it wants, I'm assuming that the firmware actually handles both the transaction display and signing logic. When you get to the stage where Electrum displays all the inputs and outputs before it pushes the info for you to confirm on the screen of your hardware wallet, copy the change address, cancel the transaction, and go and check if the change address is part of your wallet. If it is, recreate the transaction and make sure the same change address is used. Wouldn't that work?
That is assuming, as the scenario says, that the malware doesn't have control to your computer. If you run the risk of both the hardware wallet and computer being compromised, there is nothing that you can do. That is why either the hardware wallet or the computer must maintain its integrity. The firmware will mostly remain uncompromised, it is signed by the manufacturer and I assume that they have necessary procedures to avoid any possible attacks. |
|
|
|
That's correct. Did you notice that the HW doesn't show your change address to verify it? Now just imagine that the HW is made to work as a certain external (hardcoded?) address is the change address. You won't notice a thing and your money will go *spoof*
The firmware should recognize the change address and that is why some HW wallets don't display it. Specifically, ColdCard checks for the change address with their internal list. I can't speak for the other wallets as I don't use them. If the firmware is modified in a way that changes the change address, it could've tricked you in many other ways as well. |
|
|
|
I have heard that bitaddress.org generated address was crackable but not anymore now.
It isn't. Javascript-based generation is notorious for being subpar as compared to your normal wallets. Having to rely on your browser to correctly communicate with the OS CSPRNG with no assurance isn't very good if you need to ensure that your generation involves enough entropy. JS cryptography modules aren't very well implemented or audited either, there has been cases where users have lost funds due to poor implementation by the developers or just from the limitation of javascript. I wouldn't bother running JS sites, offline or not. The fact that you'll have to trust put your trust in so many different components and have no assurance of whether it would be working perfectly is quite dangerous. Consider just using a normal desktop wallet for generation instead. |
|
|
|
|
The benefits of having longer seed words diminishes as you increase the number of seed words and would just make storing it a hassle; given that the security of your individual addresses are only 128bits.
People often associate the security of their seeds only with the number of seed words that they have, that is untrue. The way you're generating it will affect it significantly. Generating it in an environment infested with malware will provide zero security. Generating it with a weak RNG resulting in a lesser than desired entropy will also result in a very weak seed.
|
|
|
|
Could you not call the same method as is called through the GUI? I have seen other methods that are not GUI commands be called this way and I'm not familiar with python.
Not AFAIK, or perhaps I haven't delved into it enough. I'm aware of certain GUI methods to be called through the console, QR codes etc. The creation of the transaction itself calls the transaction module, while the parsing of the output is done with paytoedit. As for requiring an address, wouldn't OP_RETURN require one as well? I'll admit I've never used it (see below,) but I was under the impression that it required a fee, and some bitcoin to burn.
Outputs are scripts, addresses are scripts as well. They're not treated differently in terms of the fees required, it is always dependent on the size of the transaction. OP_Return is a special kind of output that allows for 0 value output. |
|
|
|
CO2 emissions is the new speech against bitcoin, and is becoming a huge trend since Mr. Musk says he will accept bitcoin payments on tesla when 50% of the miners become green. And it's really fun how bitcoin is becoming the bad guy because of the enormous contamination. and I want to ask you, is it a bitcoin fault?
No. The city with the biggest energy consumption is Las Vegas, and did you know where that energy comes from? it comes from carbon burning, but bitcoin is the bad guy.
We don't feed the miners with carbon or fuel, we feed them with electricity and we give zero fuck about the source of that energy because it's a service that our governments provide. If it's green energy or not that's out of our hands. So, people need to stop blaming bitcoin for the CO2 emissions, the governments will always choose the cheapest way to produce energy, so, those emissions aren't from bitcoin they are from the providers. If people want to blame someone they should find the right focus.
Elon Musk should be worried about the contamination generated by batteries and not about CO2 emissions, but that's a topic that he never talks about. So, this is just a nonsense drama.
Consider this: How much utility is gained by expending the energy on Bitcoin mining (and thereby the security of Bitcoin) as compared to its alternatives? How much ewaste is produced as a byproduct of Bitcoin mining? These are still fairly real concerns. Deflecting criticisms by directing them at something else isn't a solution, neither is shifting to an alternate algorithm. Your only way is to prove that the environmental impacts is worth it for the benefits that Bitcoin provide. |
|
|
|
If my memory doesn't fail me, it isn't compatible with newer version of Bitcoin Core and OP seems to want to avoid using Core as well. This module will work if OP can get the TXID and index for the raw transaction: https://pypi.org/project/bitcoin-utils/. |
|
|
|
-snip-
Multisig has to be done with authentication, ensuring that the individual public keys are corresponds to each of the parties involved. Using all of the public keys, you should be able to reproduce the corresponding addresses. The responsibility should be on each of the parties to check if the conditions are correct, so there really isn't any trust required as you'll know the conditions to release the funds explicitly. You should advice the person to be doing so, you can't spend the funds without knowing the redeem script or all of the public keys anyways. Is there a "young" partner if there's and older one and are you a cosigner? I'd recommend doing 4 of 6 and holding 3 keys yourself just in case two people screw up (or are they actually unlikely to do this)?
Provided that they trust you of course. Doing something like this risks having the one who holds the majority of the keys to be able to keep the funds hostage. Defeats the point if the purpose is to distribute the control of the funds evenly in the first place. |
|
|
|
|
Neither payto nor paytomany accepts OP_return as a parameter. You can only do so in the GUI, not the RPC or console.
|
|
|
|
I actually didn't know that you can connect Ledger with Bitcoin Core the same way you can do with Electrum  I can't remember ever reading a thread about it. I know that Ledger introduced an experimental feature a few months ago that allowed users to connect their full node to Ledger Live, but that's it. That's why I failed to see the connection between his Bitcoin Core wallet.dat and a Ledger seed missing some words. Yeah. Just introduce a bridge between the device and Core. An example would be HWI: https://github.com/bitcoin-core/HWI. The feature introduced by Ledger doesn't allow you to use Bitcoin Core to sign transactions, etc. Only allows you to fetch transactions using that. |
|
|
|
So you used Bitcoin Core in the past and you have the correct wallet.dat? Is the file corrupted or password-protected that prevents you to load the wallet in Bitcoin Core? Why don't you download Bitcoin Core, open your wallet, and let the software sync? You can try exporting all your private keys by entering 'dumpwallet' (unless the command changed). After that, import those keys in Electrum if you don't feel like downloading the whole blockchain from scratch. Would that not work?
Since OP mentioned Ledger, I assumed that they used Bitcoin Core as an interface for the Ledger and hence why the seed phrase was mentioned. Without the actual hardware wallet, any wallet that has been created is a watch-only wallet. |
|
|
|
i want to recover the coins from the address. is that possible? i have only seven words though. I bought another laptop the other day, An Asus ROG Zephyrus Duo 15 GX550LXS. had also recently finished upgrading my linux o.s as well.
You need all 12 words. You cannot recover just by using the addresses. Any idea on how i can recover the rest of words?
I tried FinderOuter and btcrecover, but i clearly is not to familiar with the console commands for extracting
If you've lost it, then bruteforcing is the only way albeit with very low probability. BTCrecover has a quick start guide on GitHub.. |
|
|
|
|
Other than the methods the above replies mentioned, you can also check the redeem script itself. I'm assuming that you keep a backup of your redeem script, which is standard practice.
The redeem script should begin with 53 (OP_3) and end with 54ae (OP_4 OP_CHECKMULTISIG).
|
|
|
|
You'll need the seed phrase to be able to spend your Bitcoin. Unfortunately, since you're missing 5 of the words, it'll be quite impossible to be able to crack it. If you want, you can give it a try with BTCrecover: https://github.com/3rdIteration/btcrecover. |
|
|
|
Public key or address are generated from one way hash function with SHA-256 encrypted algorithm which are meant to be public and there is no risk in exposing them unless your seed for the wallet is compromised with hackers.You can generate as many address like bech32,P2SH,P2KH address for different purposes so it doesn't matter.There are so many dormant bitcoin address lying there with thousands of Bitcoin in them but nothing can be done as only the owners possess the corresponding valid private keys and digital signature to spend the funds with them.Reverse transaction is not possible due to one way hash function of SHA-256 and Rimped-160 algorithm which provides security of funds in your wallets.Moreover the technology is not so developed at this time that you can make reverse decryption with quantum computing also at this time.So the answer is simple "NO".
SHA256 and RIPEMD-160 are not encryption algorithms, they are hash functions. You also cannot crack encryption or pre-image HASH160 with quantum computers. Addresses are generated from the public keys with SHA256 and RIPEMD-160, public keys are based on ECDSA and does not involve SHA256 at all. Please do some fact checking before posting. Also, it isn't very relevant to the topic. |
|
|
|
|
The blocks in Bitcoin contains a version field. It was used for soft fork signalling by the miners to indicate support for the various forks and new rules/features. Mining a block that is below Version 4 will result in the reference client rejecting them; though ASICBoost introduced quite a variety of alien versionbits, support for Taproot is still signalled via that with speedy activation. I believe Core still checks for the minimum nVersion of the blocks and generating a block with an old client could potentially produce blocks that can be invalid.
|
|
|
|
When we are generating a wallet we have seed. The addresses generated against the set of the seed obviously is following a complex algorithm or we would see one address could easily found with another set of seed. I have no idea how the algorithm works and how hard it is. But this is pretty sure that the current computing system we have is not able to decode the algorithm very easily, possiblity is nearly zero. However, what about the future?
Not likely. The reason why quantum computers are perceived to be of a threat against Bitcoin is because of the fact that Shot's algorithm provides an exponential speed up against asymmetric algorithm, specifically ECDSA in Bitcoin's case. This means that the attacker has to have the public key to be able to get to the private key in the first place. It can be mitigated as long as you're able to not reuse address and assuming that the transaction gets confirmed within a reasonable period of time. Again, the running cost of quantum computers likely does not justify the profits from something like this. Quantum computers also run Grover's algorithm which provides a far lesser speedup for preimage attacks. That isn't very beneficial and would probably not be an area of concern for Bitcoin. Computer industry is working on quantum computing in fact, in the next 10 to 15 years we may see perhaps thousands even millions times faster computing than the current computing system we have. With a faster computing system the current algorithm could be compromised very easily.
I am sure the developers are aware about this, I am surely not the first one who is thinking about it. I would like to know how we are progressing to face this upcoming advanced speed.
Quantum computers cannot be measured the same way as classical computers. While asymmetric cryptography would probably be compromised given sufficient time, hash functions like SHA256, SHA512, RIPEMD160 could be weakened in due time but it still wouldn't be enough. |
|
|
|
Each electrum seed is already extended with the word “electrum”, if you choose to extend it more with another seed phrase it'd become “electrum<seed_phrase>”. So it doesn't double the entropy, instead, the entropy remains the same. What it does change is a salt. Once you're done with the seed generation and salt selection, the result is being put through a key derivation function called “PBKDF2”. But, you can of course do it, it'll provide around the same security for a human being.
Would this effectively double my entropy? No. I might be a bit dense today, and hence deleted my previous post after realizing something.  If I'm not wrong, the seed isn't extended by adding 'Electrum' to it. The salt is however, 'Electrum + passphrase' instead of 'mnemonic + passphrase'. If the seed can be used in the salt to produce a different 512bit output, wouldn't there still be a considerable increase in entropy as long as the ENT of the input < length of the output? I'm sure I'm missing something here. My main motivation behind this post is to have my backup in two pieces to protect against a physical intrusion. A 24 word seed with higher entropy has no benefit over a 12 word seed if the physical backup is stolen. If I break the 24 word seed with 256 bits into two 12 word parts, can I safely store them in two separate locations like I can with the seed extension?
Yes. I'll suggest using the method using Electrum console as mentioned above. You'll be covered under the checksum and won't have to mess with the passphrase as much. I'll consider Shamir secret sharing for some redundancy as well and split them up further. |
|
|
|
Well, you could encrypt a message to the owner of the address without having to ask him to give it to you. You could avoid a possible MITM attack this way.
Fair. I would probably recommend people to start using implementations that are designed for secure message exchange instead, PGP etc. Electrum's ECIES was incorrectly implemented in the past and AFAIK isn't widely reviewed either. How could one spend an output without proving it with a signature? I may have misunderstood this. As for the multi-signature, it could show any key that is exposed from the specified address. Maybe not all of them, if it's not a N-of-N multi-sig.
Not all unlocking scripts require a signature.
Electrum's current protocol documentation doesn't include this. Might be a bit of a hassle implementing this? |
|
|
|
|
Show Posts
