My password is probably around 10 digits
since 10 digits can be cracked very quickly.
10 digits implies that it consists only of numbers in the range 0 to 9? What we do know is: * "Officials said they did not use the conventional BIP standard algorithm". * The seed phrase alone doesn't produce the same set of addresses as it did in the past. So it must be something similar to the BIP-39 passphrase, meaning it appends to the seed phrase and produces another set of keys. OP, have you tried importing the words to Electrum? Just in case they use the same standard that Electrum does. Also, do you recall if they also offered LN features? Because they could potentially use aezeed cipher seed EDIT: I just saw you posted a valid BIP39 seed phrase. I hope it's not yours. |
|
|
|
Nope. A hdparm speed test doesn't care about the filesystem.
So the current speeds have gone up to: /dev/sda:
Timing cached reads: 1666 MB in 2.00 seconds = 834.15 MB/sec
Timing buffered disk reads: 328 MB in 3.15 seconds = 104.15 MB/sec
I feel stupid, but here is what happened... I was using the USB 2.0 port and not the 3.0 port. |
|
|
|
I can't find an English review for this exact model, but my Intenso USB stick is faster than what you get.
Perhaps a format will solve the issue... |
|
|
|
Which SSD do you have exactly?
This is my disk: https://www.amazon.de/-/en/Intenso-Internal-Inch-SATA-Black/dp/B0B63HPPG3I'm just guessing here: is it possible you're using a very low quality USB cable? Have you tried Gnome Disks? It has a Benchmark feature. Or have a look at GSmartControl, see if it can give you a reason for the low speed. No errors unfortunately... with GSmartControl Could the format be an issue? My disk is exfat EDIT: I think I will backup my drive and then format to ext4 |
|
|
|
Most microSD cards are faster than this nowadays. It should be 10 times faster:
Did you run your disk speed test during IBD? If so, that's probably why it's slow.
The type of SSD matters too: some perform just as you'd expect, and others are only fast "in short burst", and after writing the burst data, it gets much slower, up to the point that combined read and writes can make the entire system freeze for a while. That doesn't matter much for normal computer usage, but it matters a lot during heavy tasks (such as the IBD).
Hi Loyce. No my IBD is finished and my node is stopped. So essentially my RPi is connected to an SSD which has the whole bitcoin-core structure, but bitcoind is not running. I also ran fstrim -v on the mounted directory and it trimmed some data, but it didn't work afterwards. I mean no amelioration was seen. |
|
|
|
I wanted to test it further, so I did: To my surprise, I got: /dev/sda:
Timing cached reads: 1776 MB in 2.00 seconds = 888.80 MB/sec
Timing buffered disk reads: 62 MB in 4.67 seconds = 13.28 MB/sec
Isn't it too slow for an SSD ? Especially the second timer. |
|
|
|
Edit: Some appear to talk about new platforms. From January 1st we will move the campaign to another platform. To get the update please subscribe to my Telegram Channel. We will disclose it very soon and existing participants will receive an offer to partner with the new Mixero promotion. I use telegram, but I don't think it's a proper platform to continue the campaign there. There is too much spam / scam and fud there. I would argue we should abstain from using telegram for this reason. But let's see what the manager decides. |
|
|
|
Isn't monero getting dropped left and right from exchanges? Guess the "privacy and anonymity" that it offers couldn't work to its advantage huh.
Yes, but this is exactly the reason CEXs don't like Monero. Its anonymity and privacy is a threat for them, because they can't censor it and they can't have any control over it in case any central authority (i.e. government, bank etc) ask for it. So, to comply with their rules, CEXs have to ignore Monero. It is by default, too good for us, too bad for them. |
|
|
|
- Discovery of the Year: apogio, vjudeu, paid2 - Crazy guys who burst into our community like a hurricane.
- Discovery of the Year: apogio, I only familiar with his name in this year unlike last year where PowerGlove is completely dominating
Thank you guys! Much appreciated.
- Hero of Good: o_e_l_e_o
- Golden Feather: o_e_l_e_o
- Bitcointalk Ninja: LoyceV, TryNinja, suchmoon
- Bitcoin Geek: o_e_l_e_o, BlackHatCoiner, NotATether
- Event of the Year: It's my first year on this forum!
- Fail of the Year: Ordinals
- Discovery of the Year: vjudeu, icopress
- Best SpamBuster: GazetaBitcoin
- Best ScamBuster: Learn Bitcoin, GazetaBitcoin
- Craft Master: icopress
- AntiHero:
- Miss Bitcointalk: Foxpup
|
|
|
|
Since OP can't import that "phrase" he has into Bitcoin Core, it's probably not a private key or a key in a format that Bitcoin Core recognizes.
HD wallets were introduced somewhere in 2013. OP says the paper is 10 years old. It might be an early-stage recovery phrase.
The obvious question is, does the paper contain clearly visible English words or is it one big string of uppercase/lowercase letters and numbers?
Another thing. Did you invest or own bitcoin in the past and just now came across the paper?
As you said, BIP-39 was invented in 2013 (according to this: https://en.bitcoin.it/wiki/BIP_0039) I wasn't there at the time, but could it be some software that generated some custom solution?Anyway, as you say, there is no way to find out until OP provides more details. My best guess is it may be a " Brainwallet" passphrase but do not do anything with it while online, unless you have access to an air-gap machine ( wiki: Air gap). In that case, you can try if it'll produce an address with balance using a working brainwallet tool ( example) while completely offline. This is my guess too. They must have been very broadly used back then. |
|
|
|
If the owner of the forum said no then I think it would be not right to question him.
While it is not happening in the next 27 days why argue with the authority of the owner of this forum?
"Why argue with the authority of the onwer of this forum?" Do you keep the same stance in every occasion in your life? Let's say the "owner" of "something" wants YOU to do something you don't like, don't you have the right to express your opposite opinion? Even theymos himself knows that we have the right to express an opposite opinion. We didn't insult him, we didn't poduce violence through our writtings, but we want to express our opinions. |
|
|
|
Ps. I am not sure whether all these 93 characters can be used but if I recall correctly they can, I am just busy at the moment and I can't check online. If someone could confirm this please
BIP39 actually specifies that any passphrase will be normalized to UTF-8 NFKD, so you can actually have a character set in the tens of thousands if you wanted, provided your wallet software supports these characters, and use any unicode character such as ½, Ü, or ←. I wouldn't recommend going down this route, however, since there are a lot of unicode characters that look very similar or even identical, and would obviously lead to completely different wallets if confused. For example A, A and A are all different characters (Latin, Greek, and Cyrillic). Yeah, I wouldn't go down this path. The dataset I will use is: A - Z (excluding O and I) -> 24 characters a - z (excluding l) -> 25 characters 0 - 9 (excluding 0) -> 9 characters @#$%^&* -> 7 characters So in total I have 65 characters. I plan to go for more than 20 characters long passphrases, which will give me ENTROPY > ln(65^20)/ln(2) ~= 120 bits. I will collect random data using the following command: cat /dev/urandom | tr -dc 'ABCDEFGHJKLMNPQRSTUVWXYZ123456789abcdefghijkmnopqrstuvwxyz@#$%^&*' | fold -w 20 | head -n 1 |
|
|
|
By the way, my conversation with o_e_l_e_o above intrigued me and I started reading some papers in regards with bitcoin's security level. I will not add them here, but I will, instead, add this topic I found https://bitcointalk.org/index.php?topic=2859033.0 which explains what o_e_l_e_o said above in more details, in case anyone is interested. |
|
|
|
All 95 printable ASCII characters can be used for a passphrase. Here is a screenshot taken from electrum.  Brilliant! Thank you, so my numbers will change slightly (in decimal range). The bits will remain the same even with 95 instead of 93 available characters. |
|
|
|
The combination of several capital letters, lower case letters, several numbers and several characters with a total of 10 to 15, for me is strong enough to be used as a password and passphrase. Using this combination makes it easier for me to remember a time.
For one device and another I use different, but not more than two passphrase.
Combining all the possible printable characters from the ASCII table(93 in total) wil give the following entropy (in bits): For 10 total characters: 65 bits For 15 total characters: 98 bits So I suggest you use anything larger than 15 characters to get a good entropy. Ps. I am not sure whether all these 93 characters can be used but if I recall correctly they can, I am just busy at the moment and I can't check online. If someone could confirm this please |
|
|
|
The PK can be theoretically brute forced regardless of the wallet setup by brute forcing 128 bits I think the point to understand is that 128 bits of security will not be brute forced. The energy required to brute force a single key with 128 bits of security would boil all the oceans on Earth 16,384 times. So until we can construct a Dyson sphere to harvest the entire energy output of the sun, 128 bits is quite safe. With that in mind, then all the additional security options we have - passphrases, multi-sigs, etc. - are not designed to increase this 128 bits of security (and indeed, as I've explained above, they can't. The final security of a bitcoin private key will never be more than 128 bits.) Rather, they are designed to protect against human error, compromised devices, viruses and malware, and so on. Yeap that is exactly the point I made above, isn't it? I just ask to verify that I have understood properly. |
|
|
|
|
To sum up:
The IBD went from 0 to 790,000 in 5 days, then from 790,000 to 810,000 in 3 days, then from 810,000 to 814,000 in 2 days and currently, from 814,000 to 816,000 in 10 hrs. I guess it will reach 819,000 soon enough.
Thank you all for the answers, apparently it was what Loyce said above regarding the ordinals and the larger transactions.
Now, I am at 816,000 and it moves quickly. It must be finished later during the day.
Finally, I did increase my dbcache to 6000 (from a total of 8GB RAM), as all of you suggested. However, I did not use the assumevalid directive, because I wanted to read more about it before using it, but unfortunately I didn't have the time.
|
|
|
|
...
Fascinating! Therefore, one can argue that security is only set in danger by human mistake. Even with multisig, or strong passphrase etc, the security level is technically equal. But, human error can lead to losses. So we have transitioned our focus to providing solutions that avoid human mistakes, not to solutions that add more security in terms of bits. The PK can be theoretically brute forced regardless of the wallet setup by brute forcing 128 bits |
|
|
|
The maximum security provided by a 256 bit private key on the secp256k1 curve is 128 bits. This is because the most efficient way to attack a 256 bit private key is not brute force, but by solving the ECDLP, which will take on average 2 128 operations. So all bitcoin private keys, regardless of how much entropy was used to generate them, will never provide more than 128 bits of security You can see this in Standards for Efficient Cryptography. SEC 2: Recommended Elliptic Curve Domain Parameters. (Table at the bottom of page 4.) According to this, adding the passphrase is a protection measure only if someone steals the seed phrase, so you can make sure they would never guess the passphrase. But, theoretically, an attacker that brute forces bit-by-bit could generate 128 bits that would lead to the exact same private key that the wallet of 12 words seed + 128 bits passphrase would create, correct? And if so, this also applies to the example I provided with the multisig, correct? |
|
|
|
Technically yes, but the final security of your private keys won't be any more than 128 bits.
Ok this causes me confusion. Would you please elaborate? I also had another question: Let's say I have a 2-of-2 multisig. Let's say both of the cosigners have 12 word seed phrases. Is the final security 256 bits? (128 + 128) Also if I have a wallet with 12 words seed phrase and a passphrase of 128 bits. Is the final security 256 bits? You said it's not, but I would love it if you could explain. Is the security of the 2 wallets equal? |
|
|
|
|
Show Posts
