Bitcoin Forum
May 09, 2024, 07:23:10 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 ... 589 »
561  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.19.0.1 Released on: January 07, 2020, 04:15:54 AM
Just recently upgraded to latest version and the US English or simply English language options are gone!
Looks like it was removed, probably accidentally. I've opened a PR to restore it.

Selecting Default gives me some English mixed with partially translated Latvian and best working option now is UK English.
Default will use your systems local language settings, which I guess is Latvian. It looks like there isn't a full Latvian translation yet, so Core will fallback to using the original English strings.

Why there is not one option for one language? I know there is like 7+ Spanish options and English in various parts of world have different dialects. But why?
Because there are multiple regional dialects. Bitcoin Core uses [Transifex](https://www.transifex.com/bitcoin/bitcoin/) for translations which allows people to translate for a ton of languages and their regional dialects. Some of those people will choose to translate for the various dialects, so those translations end up in the software.

And if so, why there is no at least 4 versions of Russian (for each country where Russian have official status) or U.S. East Coast, U.S. West Coast and Texass English?
Either because no one has bothered with translating for those dialects, or Transifex does not give those dialects as options to translate to.
562  Bitcoin / Development & Technical Discussion / Re: Bitcoin Core Linux binaries installation question on: January 06, 2020, 11:50:28 PM
The proper way to install it is to extract everything and copy all of the files into their respective directories in /usr/ So everything in bin goes to /usr/bin; include to /usr/include; lib to /usr/lib; share to /usr/share

You don't really need everything in the bin folder, some of those are the unit test binaries. But just copy everything anyways. The include and lib folders are only needed if you want to write or use a program that is dynamically linked against the libconsensus library provided by Bitcoin Core. I don't think anyone uses that though. The share folder contains the manpages.
563  Bitcoin / Development & Technical Discussion / Re: Exporting xprv from Bitcoin Core HD wallet on: January 06, 2020, 11:43:57 PM
Sure, but what should I do when my all digital storage (including cloud one) fails?
Make more backups in other locations so it's unlikely that everything would fail simultaneously. And when a storage device fails, the data isn't gone permanently unless the device is physically destroyed (but you should have remote backups), and even then, not always. It's possible to recover data from storage devices even after they are "dead". For example, if you use a spinning hard disk drive and the drive motor, control board, or read head fails (some of the most common causes of drive failures), specialized data recovery services can open up that drive, pull out the platters, and recover all of your data anyways. And you can avoid catastrophic failures by using multiple drives in a RAID array.

Obviously you should have remote backups, whether that's cloud storage or a physical drive you plug in every so often and put a backup on it.

Bit rot is a thing that could affect your backups, but routinely making and verifying backups is something that you should be doing so it really isn't a problem.

If you insist on having a paper backup, you can hex encode or base64 encode the wallet.dat file and print that out  Tongue



I suppose what you are really looking for is the HD seed that Bitcoin Core uses. The HD seed is used to derive the xprv which is then used to derive the child keys. The HD seed is what Bitcoin Core is able to store and use, not the derived xprv. You can find the HD seed in the file created by dumpwallet. It is a private key that is marked with hdseed=1. You'll probably also want any of your previous HD seeds (if you've changed HD seed before or just encrypted your wallet but had used it before encrypting). Those are private keys marked with inactivehdseed=1. All HD seeds will have hdkeypath=s so that's another way you can find them.

A new Bitcoin Core wallet can have a HD seed set by using the sethdseed command.



But, I still wouldn't recommend backing up the HD seed. This kind of backup, while it does backup your private keys, loses a ton of other data. You'll lose all transaction data, which may be annoying to get back if you've exhausted the keypool before (in general, keypools and gap limits are issues with private key only backups). You'll lose any metadata like labels. And you lose the creation date and time of keys (important for making rescans faster).

What you really should be doing for backups depends on what your thread model is. What are you trying to protect against by backing up?

Are you trying to protect against ransomware or other malware that locks you out of your computer? An offline digital backup is sufficient. You could use a hard drive that you backup your whole PC to every once in a while. Or use a remote storage service. You should also encrypt it. To protect against that case, you should be backing up your entire PC anyways, so making an additional physical backup to protect against it doesn't make that much sense.

Are you trying to protect against your house burning down (or some natural disaster) destroying everything in it? Well, your physical paper backup isn't going to stand against a fire. So in that case, again, a digital backup to a remote storage service. You could use a sturdier physical storage medium like metal, but good luck finding it after your house burns down. But it could still be destroyed or rendered unusable by damage. Yes, you could send that physical backup to somewhere else to be stored, but then you need to trust that whoever you are storing it with does so securely, and that that place isn't also destroyed. At least with a remote digital backup, you can be certain that the service provider is backing up their stuff so if their data center is destroyed, your data will still accessible. And you can encrypt it so it will be secure.

Or are you one of those people who uses tails and then nukes the computer they used it on (and more generally, uses ephemeral OSes so everything needs to be re-installed and re-initialized every use)? In that case, a physical backup is probably better for you. Obviously you want to keep your private keys as offline as possible, only putting them on a computer for as little time as necessary. So a physical offline backup is better for your use case. But you still need to consider the implications of your backup being lost or destroyed, so you better have multiple and you'll need to trust whoever is storing them for you.



So suppose you've made digital backups and a physical backup, and the reason for the physical backup is "just in case all digital backups fail simultaneously". I don't think that's a good reason to make a physical backup. The reason being, if all digital backups failed simultaneously, you've got bigger things to worry about. Think about what might cause your own computer to physically fail and data become unrecoverable. Think about what a remote service who specializes in cloud storage to lose all of their data and all of their backups. For both to happen simultaneously, the only things I can think of are cataclysmic events. Either some terrible natural disaster has occurred like an asteroid hit the Earth, or a war has broken out and a bunch of cities just got nuked. In either case, you are either dead or have bigger things to worry about than the safety of your Bitcoin. Hell, money probably doesn't matter, and the Internet will basically be destroyed (tons of physical connections will have been severed).

So why would making a physical backup be a bad idea? Well, it's another thing to keep track of, another thing to verify still works. And most people aren't going to encrypt their physical backups (because the UX for doing that sucks). So if you lose that backup or it gets stolen, you'll need to go through the hassle of making a new wallet and moving all of your coins there. Otherwise you risk your coins being stolen. So why risk that? Just make a digital backup instead.



In general, I don't really recommend using paper backups if you are using just a software wallet. There are so many other things in a wallet that are necessary for working, more than just private keys. The wallet file provides those things, so really you should be backing up the wallet file, not just the private keys.

If you're using a hardware wallet though, then yes, making a paper offline backup makes sense. The seed is all you need to restore a hardware wallet, but is not enough to restore a software wallet, you need to have both the hardware wallet seed and the wallet file data to truly restore your wallet. But it doesn't make sense to digitally backup the hardware wallet's seed since the whole point of a hardware wallet is to have a kind of airgap. So a physical backup makes sense there. But, as mentioned earlier, you still need to protect against that backup being lost or destroyed.
564  Bitcoin / Development & Technical Discussion / Re: Exporting xprv from Bitcoin Core HD wallet on: January 06, 2020, 04:42:58 PM
While this may "backup" your Bitcoin Core HD wallet, you will not be able to restore it to Bitcoin Core. Currently, xprvs cannot be imported into Bitcoin Core. Furthermore, Bitcoin Core does not use the standard BIP 44/49/84 derivation paths so you will need to find a wallet that lets you enter a custom derivation path. And that wallet needs to let you also use hardened derivation for the addresses themselves.

I would not recommend anyone use this method of backing up your Bitcoin Core wallet.
565  Bitcoin / Bitcoin Technical Support / Re: unknown wallet.dat format on: January 03, 2020, 04:26:48 PM
Yes I know, I tried dumpwallet.py and pywallet.py. This is not about reading the file but rather recognize the coin inside the wallet which I have disclosed earlier.
Download and install Berkeley DB 4.8.3 from https://www.oracle.com/database/technologies/related/berkeleydb-release-history.html

Open up a command prompt in the directory containing your wallet.dat file and do
Code:
db_dump wallet.dat
You will want to copy (or redirect) that output into a text file/editor.

Search for the string 1262657374626c6f636b. Look at the next like, it should be fairly long. Starting at the 10th character, copy the next 64 characters. This is a block hash represented in hex. You will need to byte swap it because it is stored in internal byte order. This means that every two characters at the beginning are swapped with their symmetric two characters from the end. You can then search for that block hash in various block explorers until you find one for the coin that it belongs to.

For example, in my wallet, I have:
Code:
 1262657374626c6f636b5f6e6f6d65726b6c65
 bcbe02001f398d305048481ee6b096d2a96ab996ad380c6865e5521f000000000000000000aa01a3461474942498219b371a297489c8e98e0726ca2d00000000000000000009a41bd091b58a66c3086ee87dfffac82f56d8a9cc1520000000000000000000d99c9828fec374230d19c9ce041d18bb0abbd902a1821f00000000000000000036a5f285a97de07dd3a36e8002d284a918c2ac5095ee0000000000000000000010dcd433003dd70a97169db7a03d784cc4c1f9204aa71c00000000000000000047d5c32538d7240af5bc1fcd162c656f4cc0a41b28820800000000000000000056ecc938d227a0d85af190a9b34dac6a5d8fc374adcf0c0000000000000000002690eed687e53530066986945ae7df3d1694be411f320a000000000000000000af828b14fa61f57401754aa5625635c27c96bc93b8261800000000000000000088f53e4684d64ec75e2ace5e4e138effbf838a2d1a4e1200000000000000000041317742072dc3779ed50d11f8f0f81974db61f9f89503000000000000000000deeace08a82d82c12787bdd986b38673bcd37328b79813000000000000000000f75ec406dce3b6933bbb5dbfca0681befe63432b49452a00000000000000000024692509bdb166ae9edf0369763ffef5ed33764d9c0c220000000000000000007f33440c4c65647b2c79a9dcc05db931e81b14d929950800000000000000000020d876aaddb18d93414a0b41c651c0955230acd3cd9203000000000000000000460d02a06510794a5af955984530706dbdce386b6a8711000000000000000000b9944fae9baf038329f1d618d18de8589b1c724184842a000000000000000000aa33e53a7a77f9cb39aab9b9bf229e872633187ede4504000000000000000000f696c443c06a2552f8193b7dc93a3b62f48e6294bb1b1b00000000000000000014f1054a9fc8cdf8893f7634fc0a0afa0f8554cba0b62a000000000000000000f01cc261faa46dae158f5f4372af5e02d5a17c6994772b000000000000000000ae51a37bd455a1d6790d43e133c995988aabb163176a04000000000000000000867af3560bf4aab1cea599889b5830f702d2b9650a5f03000000000000000000d3b00067c837dcbdec5dd1fb5cda597fa03f8c90f12c29000000000000000000ca75b9384b21187013044c74585573b4e46fb9a71207480000000000000000004e504c2b55677b208da3867b4f628db2da6eace0ec834e040000000000000000d85b9f567ff6bbed506960c8b76498bae153c086d56d2e5f0000000000000000726e26f93314df0ed59c2af2c9f891f1f435f3dab0f8e534e336543f000000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000

Skipping the first 10 characters gives me:
Code:
398d305048481ee6b096d2a96ab996ad380c6865e5521f000000000000000000aa01a3461474942498219b371a297489c8e98e0726ca2d00000000000000000009a41bd091b58a66c3086ee87dfffac82f56d8a9cc1520000000000000000000d99c9828fec374230d19c9ce041d18bb0abbd902a1821f00000000000000000036a5f285a97de07dd3a36e8002d284a918c2ac5095ee0000000000000000000010dcd433003dd70a97169db7a03d784cc4c1f9204aa71c00000000000000000047d5c32538d7240af5bc1fcd162c656f4cc0a41b28820800000000000000000056ecc938d227a0d85af190a9b34dac6a5d8fc374adcf0c0000000000000000002690eed687e53530066986945ae7df3d1694be411f320a000000000000000000af828b14fa61f57401754aa5625635c27c96bc93b8261800000000000000000088f53e4684d64ec75e2ace5e4e138effbf838a2d1a4e1200000000000000000041317742072dc3779ed50d11f8f0f81974db61f9f89503000000000000000000deeace08a82d82c12787bdd986b38673bcd37328b79813000000000000000000f75ec406dce3b6933bbb5dbfca0681befe63432b49452a00000000000000000024692509bdb166ae9edf0369763ffef5ed33764d9c0c220000000000000000007f33440c4c65647b2c79a9dcc05db931e81b14d929950800000000000000000020d876aaddb18d93414a0b41c651c0955230acd3cd9203000000000000000000460d02a06510794a5af955984530706dbdce386b6a8711000000000000000000b9944fae9baf038329f1d618d18de8589b1c724184842a000000000000000000aa33e53a7a77f9cb39aab9b9bf229e872633187ede4504000000000000000000f696c443c06a2552f8193b7dc93a3b62f48e6294bb1b1b00000000000000000014f1054a9fc8cdf8893f7634fc0a0afa0f8554cba0b62a000000000000000000f01cc261faa46dae158f5f4372af5e02d5a17c6994772b000000000000000000ae51a37bd455a1d6790d43e133c995988aabb163176a04000000000000000000867af3560bf4aab1cea599889b5830f702d2b9650a5f03000000000000000000d3b00067c837dcbdec5dd1fb5cda597fa03f8c90f12c29000000000000000000ca75b9384b21187013044c74585573b4e46fb9a71207480000000000000000004e504c2b55677b208da3867b4f628db2da6eace0ec834e040000000000000000d85b9f567ff6bbed506960c8b76498bae153c086d56d2e5f0000000000000000726e26f93314df0ed59c2af2c9f891f1f435f3dab0f8e534e336543f000000006fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000

The 64 characters at the beginning are:
Code:
398d305048481ee6b096d2a96ab996ad380c6865e5521f000000000000000000

Byte swapping that results in the hash:
Code:
0000000000000000001f52e565680c38ad96b96aa9d296b0e61e484850308d39

When looking up that hash in a block explorer, you will see that it is block 564035 in the Bitcoin blockchain.


If you don't find that particular string, try searching for 0962657374626c6f636b instead.
566  Bitcoin / Development & Technical Discussion / Re: Uninstall compiled Bitcoin in linux on: January 03, 2020, 04:13:28 PM
You just need to delete the files where they were copied to. Do:
Code:
cd '/usr/local/bin' && rm -f bitcoind bitcoin-cli bitcoin-tx bitcoin-wallet test_bitcoin bench_bitcoin bitcoin-qt test_bitcoin-qt
cd '/usr/local/include' && rm -f bitcoinconsensus.h
rm -f '/usr/local/lib/libbitcoinconsensus.la'
cd '/usr/local/share/man/man1' && rm -f bitcoind.1 bitcoin-qt.1 bitcoin-cli.1 bitcoin-tx.1 bitcoin-wallet.1
cd '/usr/local/lib/pkgconfig' && rm -f libbitcoinconsensus.pc
567  Bitcoin / Bitcoin Technical Support / Re: unknown wallet.dat format on: January 03, 2020, 06:19:16 AM
may it cost to open it through a text editor?

Why not try it.

If it is not encrypted with password you can see your address including xprv or the private key from the wallet.dat file but if it's encrypted you can see some text with boxes or random characters it will look like this below if you open it with notepad++


wallet.dat files are not text files. You will not get a ton of readable text regardless of encryption. Furthermore, you most definitely will not see an xprv, Bitcoin Core does not store or use xprvs.

wallet.dat files are Berkeley DB files. You will need to have a tool specifically designed to read BDB files to really get meaningful information from them.
568  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.19.0.1 Released on: January 02, 2020, 04:55:55 PM
Some time ago I upgraded bitcoin v0.18 to v0.19.0.1.
I downloaded it from https://bitcoin.org/en/download (Mac OS version), but Bitdefender antivirus detected Bitcoin-Qt as a threat.
Is this just a "False Positive" Antivirus Problem?


Yes. As long as you have checked the hashes and PGP signature of the download, it is legitimate. Antivirus often falsely flag Bitcoin Core as malware because it contains mining logic.
569  Bitcoin / Bitcoin Technical Support / MOVED: serious problem electrum on: December 31, 2019, 12:18:21 AM
This topic has been moved to Trashcan.

Duplicate
570  Bitcoin / Development & Technical Discussion / Re: Bitcoin math question on: December 19, 2019, 04:10:39 PM
Yes, you should get the same thing.
571  Bitcoin / Development & Technical Discussion / Re: why is alert message being sent before handshake completes? on: December 13, 2019, 04:44:44 PM
It's because of TCP guaranteeing order.

The verack is sent first, so the other node will receive that first. If they like the version and verack, then they can send their own verack indicating readiness to receive further messages. If not, they will just kill the connection. The protocol is not violated by sending the alert immediately after the verack and nothing bad happens.

The alert message in this instance is a special message. It is part of the old P2P alert system that has since been deprecated and removed. The alert message is only sent to old nodes that indicate that they still have the alert system. It is being sent immediately after connecting because that alert message will cause the "Alert Key Compromised" message to be displayed on nodes that still have the alert system.

However sending messages immediately after verack before receiving the other node's verack is a common thing to do. There are a couple of other messages that are not responses to anything and can just be sent immediately after verack. You should see this same behavior with the sendheaders message.

i am also wondering why bitcoin core nodes can't recognize a message if it has preceding garbage bytes (random bytes before the magic) but they are fine if it is after it. what's the point of magic then if it isn't used as the message start marker?
Because it is expecting only messages in discrete chunks. TCP generally gives it the messages in a single recv(). It is expecting the magic bytes at the beginning. If someone is sending garbage, then it wants to just disconnect as fast as possible because that could be a DoS attack. However garbage at the end of the message is fine because the message itself is self descriptive in size and garbage after the message can be discarded.

The magic bytes are not a start marker. They are an unique identifier.
572  Bitcoin / Bitcoin Technical Support / Re: Traversing Bitcoin by bitcoin-cli on: December 07, 2019, 12:20:35 AM
OK. How do blockexplorers work then? Because I found one API, which has this feature. Do they have any backend on the server, that tries to connect every input of a new transaction to its previous output?
They don't  use Bitcoin Core, or at the very least, not stock Bitcoin Core. Instead they have their own custom  software and databases which parse and index the blockchain data so that lookups are fast. They also do other things which link together things that aren't actually linked in the blockchain, such as "input addresses".
573  Bitcoin / Bitcoin Technical Support / Re: Traversing Bitcoin by bitcoin-cli on: December 06, 2019, 04:45:44 PM
If you can  create  a transaction spending the output, then  you can create a transaction and use testmempoolaccept.

Otherwise, there is no way to check whether an output was spent. It wouldn't be terribly hard to add an RPC for that, but I'm not sure of the  usefulness of this.

With a spent output, you definitely cannot find the transaction it was spent in. Bitcoin Core does not store this information because it is not useful to it. To extract that information, you would have to go through every transaction in the blockchain and store  which outpoints are spent in which transaction.
574  Bitcoin / Development & Technical Discussion / Re: Bitcoin weak transaction nonce question on: December 06, 2019, 04:20:29 PM
I found some addresses in which the signatures (s part) start with the same bytes, is that a sign that an address has been using a weak nonce?
Not necessarily. It depends on how many bytes are the same.

What would it be, if the same s is re-used in the formula, but the r's are different?
I don't believe that it is possible to get the private key when s is repeated. The reason that a repeated R works  is because R is part of the calculation for s  which allows you to rearrange the formula for s so that you can compute the private key. The nonce term disappears in that formula because you know it is the same  so it can be rearranged and written out.

But s is not used in any formula. It is a single calculation and I don't think a repeated s gives any more meaningful information about the nonce or the private key.
575  Bitcoin / Bitcoin Technical Support / Re: Bitcoin 0.19.0.1 Mempool info show N/A on: December 05, 2019, 01:27:18 AM
Known issue: https://github.com/bitcoin/bitcoin/issues/17576

Fixed by https://github.com/bitcoin/bitcoin/pull/17427 and backported for inclusion in 0.19.1 (to be released at a later date).
576  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.19.0.1 Released on: November 28, 2019, 06:34:03 PM
I can help chip in for the certificate fee for that site if you need. Roll Eyes
The cert's been renewed already. It uses Let's Encrypt so it's free. I think Matt just forgot to renew it (something about not wanting to install certbot on the web server so it's renewed manually).
577  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.19.0.1 Released on: November 28, 2019, 05:10:59 PM

Bitcoin Core version 0.19.0.1 is now available from:

https://bitcoincore.org/bin/bitcoin-core-0.19.0.1/



Did you mean https://bitcoin.org/bin/bitcoin-core-0.19.0.1/ ?

Anyway, ty for the info!! let's update!
No, I did not. bitcoincore.org is the website for the Bitcoin Core project. Bitcoin.org happens to also host binaries for Bitcoin Core, but bitcoincore.org is still the official place to get downloads.
578  Bitcoin / Bitcoin Technical Support / Re: Quick question about the verison number on: November 27, 2019, 11:05:25 PM
1.0 is a  magic number which  indicates  some  sort of finality and readiness. While changing the version number to 1.0 would probably mean absolutely nothing, people would perceive it as some sort of  milestone. Furthermore, some  developers do actually believe that making a version 1.0 would actually implementing certain features, and in that case, getting everyone to agree on what should be in a 1.0 release is rather difficult.

It is unlikely that there will ever be a 1.0 release or that the versioning convention will ever change.

It has been suggested in the past that we simply drop the leading "0." and just continue with the current numbering scheme. We are already using the second number as a major version number anyways so this wouldn't change much and it would not have the same societal implications as a version 1.0. There has also been another suggestion to change to using a date version scheme like Ubuntu does.

But every time changing the version numbering scheme is brought up, it usually dies quietly with people going "meh", "who cares", and "what's the point". It really isn't worth the effort and time for what amounts to a cosmetic change. So the version numbering scheme is probably not going to change, and it's probably never going to become 1.0. It's literally just a counter for releases.
579  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.18.1 Released on: November 26, 2019, 04:24:17 PM
Bitcoin Core 0.19.0.1 has been released
580  Bitcoin / Development & Technical Discussion / Re: Increase Bitcoin Core Mempool size? on: November 26, 2019, 12:58:49 AM
Your node's mempool is not being artificially limited. The  mempool size limit is 300 MB.

The discrepancy is likely due to blockchain explorers having long running nodes, well connected nodes, multiple nodes, and less restrictive mempool acceptance rules.

If your node has not been running for a long time, then you will have  fewer transactions in your mempool as you will be missing transactions broadcast while you were offline. If your node isn't as well connected as the services' nodes (them having multiple nodes also helps with that as they can be distributed but record to the same database), then you may be missing some transactions.

And lastly, the most important thing is that those services will run nodes that use a less restrictive mempool acceptance policy. Bitcoin Core by default has a minimum relay fee of 1 sat/vbyte. Then there are also all of the transactions that are considered non-standard. Services will  often reduce or remove these restrictions so that they can show the most transactions as possible. However Bitcoin Core has these restrictions in order to prevent Denial of Service and other attacks.

Even if you were to disable those on your own node, you still need to be very well connected in order to see as many unconfirmed transactions. Your peers will likely still be running with those rules so unless you aren't connected to the people broadcasting those transactions, you won't see them as they get filtered out by all of the other nodes.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 ... 589 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!