|
1121
|
Bitcoin / Electrum / Re: WALLET ADDRESS, IS IT PERMANENT?
|
on: June 20, 2021, 03:40:29 PM
|
|
Electrum (and Bitcoin) addresses do not expire. The payment requests that are made specifically only uses each receiving address once only for better record keeping and privacy. It is perfectly fine to use it for multiple transactions, it'll stay valid.
|
|
|
|
|
1122
|
Bitcoin / Development & Technical Discussion / Re: Does more seed words equal better security?
|
on: June 20, 2021, 05:36:49 AM
|
LoyceV's split phrases are SSS seeds, because the seeds are split into multiple shares in the same way and also have a smaller number-of-shares requirement for unscrambling the seed.
They aren't. Shamir Secret Sharing has entirely different properties from the split mnemonic by iancoleman, with far more complicated logic. The system implemented basically just splits the seeds up into different cards, which still allows the person to bruteforce (albeit less effectively) given a few of the shares. |
|
|
|
|
1123
|
Bitcoin / Development & Technical Discussion / Re: Does more seed words equal better security?
|
on: June 20, 2021, 04:56:06 AM
|
I think it is a fair assumption that an attacker trying to learn a seed would know the seed size, and most people use the same derivation path for the same coin, even if it is technically possible to use an arbitrary path.
That would only lower the complexity by a little. It is still more timeconsuming to bruteforce seeds via its entropy as compared to the addresses itself. While if you succeed in bruteforcing the seeds, you'll access more than a singular address, you're far more likely to succeed in bruteforcing addresses as most of the addresses out there are generated before HD wallet became a thing and that you need additional steps to go from a seed to an address. Hence, it wouldn't make a difference to how many addresses you can access with a successful attempt. It is quite futile to target specific groups of people, unless you know for a fact that their generation if is flawed or if majority of the users are using the same parameters for their seeds. For all intents and purposes, you are not going to successfully brute force anything with 128 bits of entropy. The same is probably true for anything with somewhere in the range of mid 70's bits of entropy, and I would argue it would be impossible to brute force anything with somewhere between the mid 80's to mid 90's bits of entropy, assuming the laws of physics as we know them hold true.
If you assume a "secret" is generated in a way without flaws (such as flawed RNG), you will receive no additional security (regarding brute force attacks) by having your secret having 129 bits of entropy versus it having 128 bits of entropy because in both cases, it is impossible to brute force the secret. The only reason you would want to generate a secret that would have more than 128 bits of entropy if you assume no flaws in the generation process is if you are making the assumption there may flaws in the process.
Yes. Same holds true for addresses and infact, people should be more likely to succeed at bruteforcing an address as compared to seeds. |
|
|
|
|
1124
|
Bitcoin / Development & Technical Discussion / Re: Does more seed words equal better security?
|
on: June 20, 2021, 03:47:55 AM
|
I would have to disagree with you on this point. Getting a private key of an individual address means you can access unspent outputs spendable by that private key. Discovering a seed will allow you to have access to all private keys associated with that seed. Some entities, such as an exchange potentially has thousands or millions of addresses associated with a single seed.
Trying to bruteforce HD seeds would require far more effort than trying to bruteforce addresses. Reason being that there are far more possible child keys derivations (which is stretched with HMAC-SHA512), due to the seed size and the possible derivation paths. All of these adds up to significantly more effort than trying to bruteforce addresses, given that most people will ensure that their seeds are generated with sufficient entropy. You're far more likely to gain from finding addresses instead of HD seeds. Attacking through the entropy (128bits) will require going through HMAC-SHA512 to get the master keys. |
|
|
|
|
1126
|
Bitcoin / Wallet software / Re: getting Bech32 address on paper wallet
|
on: June 19, 2021, 09:58:19 AM
|
According to this old GitHub issue ( #35), it was possible to generate private key with low entropy if user don't move the mouse. But i doubt it's what @fred21 meant since user usually move their move. Hmm, okay that I didn't know. I always thought bitaddress was using a browser CSPRNG (not math.random()) for the entropy. Mouse movement and the other variables should serve as a complement to the original entropy and shouldn't be overly-reliant on that. Anyhow, I think this proves my point that generating addresses in browser is inherently insecure. |
|
|
|
|
1127
|
Bitcoin / Development & Technical Discussion / Re: Does more seed words equal better security?
|
on: June 19, 2021, 09:49:14 AM
|
I've read about it several times, and each time realized I can't use it. Just look at Shamir's Secret Sharing on Wikipedia: it's complicated. Which means even if I'd be able to use it, I wouldn't fully understand it, which means I have to trust whoever created whatever software I'm going to use. It is. The implementation also requires certain degree of technical expertise. That I agree. It's been around for years ( Shamir is mentioned 600 times on Bitcointalk since 2010) but hasn't really been implemented anywhere. It's probably going to be mentiond for the coming 10 years too, and my guess it nothing will change. That's why I like Ian Coleman's simple 3 cards: it's very easy to understand. On a mathematical level it's probably inferior, as far as I understand Shamir's system doesn't give you any information if you have just one share, but it's much more practical. Yup correct. Actually Trezor and Armory both implements it as well. Of course, it isn't most suited for Bitcoin due to the aforementioned limitations by you and I. But it should offer a better theoretical security advantage even with using only 12 seeds, that is if it is done properly. |
|
|
|
|
1128
|
Bitcoin / Development & Technical Discussion / Re: Does more seed words equal better security?
|
on: June 19, 2021, 09:05:06 AM
|
The benefit of long seeds it that you can create "2 out of 3" Split mnemonic cards: Card 1: basket wrong sketch bar XXXX sad XXXX visa shrimp rally XXXX XXXX XXXX wild scene forum XXXX stage XXXX amused able XXXX thing add
Card 2: basket XXXX XXXX XXXX super XXXX mandate XXXX shrimp rally betray october whisper wild scene XXXX beef XXXX runway amused XXXX armed thing add
Card 3: XXXX wrong sketch bar super sad mandate visa XXXX XXXX betray october whisper XXXX XXXX forum beef stage runway XXXX able armed XXXX XXXX With 12 words, there are 4 unknowns on each card, which can be brute-forced. With 24 words and 8 unknowns, having one card is pretty much useless. What about Shamir's secret sharing? I've seen quite a few implementation of it but have yet to check the threshold for the number of compromised shares before it comes trivial to get the entire secret. For the record, I'm not aware of any standardized implementation and some of it has been plagued with certain vulnerabilities. Probably not as convenient as the system that you've mentioned. |
|
|
|
|
1129
|
Bitcoin / Electrum / Re: electrum wallet help Please
|
on: June 19, 2021, 08:37:45 AM
|
Do you have any slight idea of what your password might be? If you have the general idea of it, eg. list of passwords, patterns of your passwords, positions of the alphabets and numbers, you can probably try out BTCrecover[1]. It can take sometime and would probably work only if you have a general sensing of what the password is. [1] https://github.com/3rdIteration/btcrecover |
|
|
|
|
1130
|
Bitcoin / Bitcoin Discussion / Re: Anonymity and Privacy while using Bitcoin. Which one is the right word to use?
|
on: June 19, 2021, 08:33:29 AM
|
I think you can gain benefit from bitcoin both anonymously and privately. I actually do not see any difference between the two. When you enter bitcoin, your anonymisity is ensured already. No one can ever know any personal details about you as long as you do not expose it explicitly. You do not have to worry about your security as long as you stay careful, it is one of the advantage of making payments in crypto. Some people such as criminals take this opportunity so that they can commit crimes and make payments with illegal items without having their identity exposed.
Incorrect. Anonymity can never be guaranteed through using Bitcoin and I'd go as far as to say that it is almost never achieved with the activities that the average Joe would engage it. There are various points of failure present when one is trying to cover their track by disassociating various transactions from each other and that can be exploitable. The "degree" of anonymity that you can achieve is dependent on the various precautions and/or measures that you take to try to ensure your anonymity. With sufficient resources and if you're a person of interest, you'd have to go through even more loops to which I'll say that you're better off trying to use a crypto that is focused on your privacy. |
|
|
|
|
1131
|
Bitcoin / Hardware wallets / Re: Why do people say hardware wallets are unhackable?
|
on: June 19, 2021, 08:20:15 AM
|
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. |
|
|
|
|
1132
|
Bitcoin / Hardware wallets / Re: Why do people say hardware wallets are unhackable?
|
on: June 19, 2021, 01:41:02 AM
|
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. |
|
|
|
|
1133
|
Bitcoin / Wallet software / Re: getting Bech32 address on paper wallet
|
on: June 19, 2021, 12:56:43 AM
|
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. |
|
|
|
|
1134
|
Bitcoin / Development & Technical Discussion / Re: Does more seed words equal better security?
|
on: June 19, 2021, 12:47:09 AM
|
|
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.
|
|
|
|
|
1135
|
Bitcoin / Electrum / Re: How can I create an OP_RETURN TX with the Electrum console?
|
on: June 19, 2021, 12:44:25 AM
|
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. |
|
|
|
|
1136
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin and CO2 emissions (Should we care?)
|
on: June 18, 2021, 11:41:26 AM
|
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. |
|
|
|
|
1139
|
Bitcoin / Electrum / Re: Way to know number of multisig if you did not set it up?
|
on: June 17, 2021, 02:53:18 PM
|
-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. |
|
|
|
|
Show Posts
