Bitcoin Forum
May 24, 2024, 09:39:30 AM *
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 ... 590 »
61  Bitcoin / Bitcoin Technical Support / Re: Fatal error when installing bitcoin core ! on: March 17, 2024, 04:25:15 PM
As the debug.log states, a corrupt block was found on disk, which indicates a potential hardware failure. This could just be a fluke (e.g. a cosmic ray bit flip) and you could try to resolve it by deleting the blocks and chainstate directories so that it will resync from scratch. However, if you do that and continue to have block corruption errors, you probably want to run some diagnostics to check if your hardware is failing.
62  Bitcoin / Bitcoin Technical Support / Re: Help with understanding Taproot tree expression on: March 17, 2024, 04:23:23 PM
Not all Miniscript can be signed yet. I think we haven't implemented everything that's needed to pass in the information required to sign for both kinds of timelocks as well as hashlocks.
63  Bitcoin / Bitcoin Technical Support / Re: Help with understanding Taproot tree expression on: March 17, 2024, 04:31:27 AM
Descriptors cannot describe all arbitrary scripts, only a subset with specific properties that make them analyzable. You must use Miniscript for those scripts.

The miniscript that you want is probably something like
Code:
and_v(v:pk(key3),older(10))
and that would make a script of
Code:
<key3> OP_CHECKSIGVERIFY 10 OP_CHECKSEQUENCEVERIFY
64  Bitcoin / Development & Technical Discussion / Re: Why did my bitcoin core descriptor wallet generate 16 output descriptors? on: March 12, 2024, 10:12:34 AM
I'm not too aquatinted with technical knowledge but from a quick search I just did, such thing happens if you have created or imported an old wallet while the Bitcoin core is running and then you deleted it from the disk while it's still in memory and then you created another one using the same name, it proceeds to write both the deleted and new wallet descriptors to the wallet.dat [1]

This might be totally wrong because from the source I read it from it was specifically for ordinals issues.


[1] https://github.com/ordinals/ord/issues/2719#issuecomment-1866006258
I still can't prove whether the new wallet descriptors are the same as those excluded by the previous wallet.dat.
There's no guarantee that all previous descriptors would show up, and certainly not with their private keys. You'd have to do a pretty weird sequence of things for all of the previous descriptor to appear. If that happened, it probably wouldn't load without errors either.

So is it normal behavior for the wallet to create 8 new descriptors, leaving 16 in total after encrypting the wallet?
Yes,
65  Bitcoin / Development & Technical Discussion / Re: Why did my bitcoin core descriptor wallet generate 16 output descriptors? on: March 11, 2024, 10:13:02 AM
If you've encrypted your wallet since creating it, you'll get new descriptors. This behavior is analogous to the legacy wallet dropping the keypool and generating new keys when encrypting.
66  Bitcoin / Bitcoin Technical Support / Re: Is a newly migrated Wallet contain the same private key for re-funding ? on: March 08, 2024, 02:43:20 AM
Will the new migrated OutletWallet still receive funds when I will utilize my QR code paper wallet to fund again ?
Yes, migration will ensure that everything in the legacy wallet ends up in the migrate wallet. Nothing will be deleted.

In the event that there is an error which does delete things accidentally, a backup is automatically made and this backup is placed in the wallet directory. It will be named in the form <wallet name>-<timestamp>.legacy.bak This backup of your wallet can be restored with the wallet restoration functionality in Bitcoin Core, or it can be opened directly.

Code:
dumpwallet "yourwalletsname"

For a single private key, you can use this command below.

Code:
dumpprivkey "bc1sampleBTCaddress"
These RPCs as disabled for descriptor wallets, as well as all of the other dump and import commands, except for importdescriptors and listdescriptors.

How about the dumpprivkey? it works for me my current Bitcoin core version is v26.0.0 the dumpwallet also does not work for me except for dumpprivkey it should work to you unless your wallet is encrypted with passphrase you will need to use the command below to unlock it first before you dump the private key
The version of Bitcoin Core does not matter for whether these RPCs work. What matters is the type of wallet, which is stored as part of the wallet file itself.
67  Bitcoin / Bitcoin Technical Support / Re: All about "stuck" transactions and what you can do to fix them on: March 03, 2024, 08:10:20 PM
Is it possible to tell your own node to forget the transaction, then connect to your node from electrum, for example, to resend it?
No.

That wouldn't really do anything useful, and would be misleading. The user might think a transaction has been dropped and a new one propagated, but in actuality, only their own node knows about the new transaction and it has not been propagated to other nodes since you cannot force other nodes to drop a transaction.
68  Bitcoin / Bitcoin Technical Support / Re: What is the proper procedure to update the Bitcoin Wallet ? on: March 02, 2024, 08:56:17 PM
You can copy all of the files, but most are not needed for the average user. bitcoind and bitcoin-qt are the main binaries. They are each self contained and do not rely on each other or any other files in the release.

/bin has all of the executables. Besides bitcoind and bitcoin-qt, bitcoin-cli is the only binary that might have meaningful changes between releases that you'd want to also copy it over. But generally, it's fairly version agnostic. The other executables in /bin are just utilities and the unit tests which are really only interesting to a very small set of people who probably aren't asking this question.

/include and /lib contain files for libbitcoinconsensus. If you don't know what that is, you don't need those files.

/share has manpages and a script for generating rpc credentials, most people don't need these either, unless you like using man instead of -help.

The easiest way to install is to just copy the folders into /usr, and do the same for every upgrade. That will copy every binary over, and also overwrite any existing binaries with the new version when you upgrade.
69  Bitcoin / Bitcoin Technical Support / Re: Is there a quick solution to Blockchain Rescan Failed ? on: March 02, 2024, 08:48:05 PM
Please post the contents of your debug.log file.
I assume you want to see the debug.log file in the bitcoin folder ?
That file is relatively huge:  10 MB that's a lot of lines ! 61166 lines, to be specific.
Probably due to a "rescanblockchain" from yesterday.
No, rescanning doesn't output that much, it's probably mostly just all UpdateTip lines for every block that was received and validated

Search through the file for any lines that have the word "rescan" in them and copy those lines and a bunch around them.

Is there a way I can attach a file on this post ?
Upload it to a file sharing service and post the link here.
70  Bitcoin / Bitcoin Technical Support / Re: Is there a quick solution to Blockchain Rescan Failed ? on: March 02, 2024, 06:32:19 PM
Please post the contents of your debug.log file.
71  Bitcoin / Development & Technical Discussion / Re: Core: unconfirmed transactions containing a specific address on: February 26, 2024, 02:02:58 AM
And there is a lot of memory usage too - the way Bitcoin Core reads the data when it gets the raw transaction, causes it to use several gigabytes if you batch too many transactions in your RPC call at once, which will definitely crash a server with any amount of RAM due to "out of memory" errors.
Memory usage is probably due converting transaction info to JSON text so it can output it, rather than reading transaction data. Mempool transactions are always held in memory and do not use disk for storage. Writing to disk is only to preserve the mempool across restarts.

When you are requesting for the transactions via getrawtransaction, they need to be encoded as text which is not very efficient. And if you're looking for decoding, then that's a whole lot more text for the decoded info, and all of that text will only ever live in memory.

None of these problems really exist when using ZeroMQ as it gives you the raw transaction itself (is this correct, @achow101?) so you can build a list of transactions from the time you start your node.
Yes
72  Bitcoin / Development & Technical Discussion / Re: Core: unconfirmed transactions containing a specific address on: February 23, 2024, 06:27:26 PM
My org is building a payment processor and we need to identify transactions as soon as they enter the mempool, so that a status message can be displayed. It is necessary to download the entire mempool because Core doesn't have a "get all transactions of an address" RPC call except if you use the wallet subsystem, but the rescanning overhead after importing each address makes that non-viable. Then our copy of the mempool is parsed into a better format which can be queried for any address. This is updated every 10-60 seconds (subject to RPC latency benchmarking that I'm performing now).

We already have a workflow for getting confirmed transactions in a block. But because getblock also returns raw transactions (and undo data), it has never been a problem.
I suggest that you use the ZMQ interface as it can provide the raw blocks and transactions as they are verified. It's actually quite reliable. It also notifies about transactions being removed from the mempool which can be useful. Since ZMQ is a push service, there won't be a polling delay where things could happen that you aren't aware of.
73  Bitcoin / Development & Technical Discussion / Re: Core: unconfirmed transactions containing a specific address on: February 21, 2024, 05:11:55 PM
Are you sure that returns decoded transactions because every time I use that parameter, I get an output that looks like the one described in the RPC docs::
Oops, I was thinking of getblock
74  Bitcoin / Development & Technical Discussion / Re: Core: unconfirmed transactions containing a specific address on: February 21, 2024, 12:12:04 AM
- Use getrawmempool, and call getrawtransaction on each of the returned transaction IDs
getrawmempool has a verbose parameter which will return the decoded transactions rather than just txids.

- Use scantxoutset (But I'm not sure if you can make this only look for unconfirmed transactions)
I don't think it searches the mempool at all.

I am also aware of the ZMQ topic that publishes raw transactions. The issue is I'm not sure how reliable that is.
Although the documentation states that it does not guarantee that data was sent, I don't think it in practice has ever been unreliable, especially if used locally.

Ideally if mempool raw transactions are cached on the disk, this will be the fastest way to process them all.
Although Bitcoin Core does write mempool transactions to disk, it only does this on shutdown as the purpose is to allow mempools to persist across restarts. You could use the savemempool RPC to force this and then parse it, but of course the file will not be updated with any new tranasctions, until you do savemempool again.
75  Bitcoin / Bitcoin Technical Support / Re: migrating legacy wallets on: February 19, 2024, 03:52:39 AM
Migration of a wallet does not invalidate keys. It only changes how things are stored and organized in the wallet. While you will get newly generated keys and all previous keys are "retired", those keys are still in the wallet and can still be used to send and receive Bitcoin.

Migration is a local operation that happens on a wallet file. It will not change any other wallet file, even ones that share the same keys. There is no signal nor anything observable that some other wallet on another node would be able to tell that a wallet has been migrated. However, if you have 2 copies of the same wallet, migrating both of them will result in a completely new and different set of keys being generated from that point on. After the migration, they will no longer generate the same addresses, although all previously generated addresses (and their keys) remain, as stated earlier.
76  Bitcoin / Development & Technical Discussion / Re: Taproot with scriptTree only on: February 16, 2024, 08:53:56 PM
BIP 341 recommends using the following provably unspendable pubkey: 50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0

Otherwise, just pick your own provably unspendable pubkey to use as the internal key.
77  Bitcoin / Bitcoin Technical Support / Re: Bitcoin-Qt maxconnections ignored on: February 09, 2024, 09:37:53 PM
What bitcoin-qt.conf? Bitcoin Core does not have such a file for people to write configuration options to.
78  Bitcoin / Development & Technical Discussion / Re: PSBT Transaction RPC Error: bad-txns-inputs-missingorspent on: February 08, 2024, 05:54:49 PM
but I get a new error: non-mandatory-script-verify-flag (Invalid Schnorr signature).
I don't know what does the error mean.
It means your signature is invalid.

Without seeing the actual transaction, it's hard to actually provide specific help.
79  Bitcoin / Development & Technical Discussion / Re: How to import an xpriv to a descriptor wallet in bitcoin core? on: February 02, 2024, 05:38:50 PM
Assumption:

How do I import a bech32, bech32m, nested-segwit, etc. master key into a blank wallet?
You create a descriptor including your key for whatever address type you want and import it with importdescriptors.

For example, let's say you have the xprv xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6Ln F5kejMRNNU3TGtRBeJgk33yuGBxrMPHi and wanted to import that to create Taproot addresses derived using the BIP 86 derivation path standard.

First you can look at Bitcoin Core's document on descriptors and see that a tr() type descriptor creates P2TR addresses. Now you can construct the descriptor without a checksum:

Code:
tr(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/86h/0h/0h/0/*)

However, in order to import this, you need to the checksum, so you can put it through getdescriptorinfo for that:

Code:
$ bitcoin-cli getdescriptorinfo "tr(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/86h/0h/0h/0/*)"
{
  "descriptor": "tr(xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8/86h/0h/0h/0/*)#vfh547jk",
  "checksum": "sffjysau",
  "isrange": true,
  "issolvable": true,
  "hasprivatekeys": true
}

Notice how the descriptor it gives you back contains the xpub, not the xprv. This is intentional to avoid reflecting back private keys. But also see how the checksum field is different from the checksum in the returned descriptor. That's because the checksum field is the checksum for whatever you input, while the returned descriptor has its own valid checksum.

So you can now construct the full descriptor by taking the part that you've already constructed, adding the checksum separator character of #, and adding the checksum:

Code:
tr(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/86h/0h/0h/0/*)#sffjysau

Now you can import it with importdescriptors:

Code:
$bitcoin-cli importdescriptors '[{"desc":"tr(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/86h/0h/0h/0/*)#sffjysau","timestamp":"now"}]'
[
  {
    "success": true,
    "warnings": [
      "Range not given, using default keypool range"
    ]
  }
]

That is the most basic type of import - one which contains just the descriptor and a timestamp to start rescanning from. This descriptor is now in your wallet, but you cannot use it to retrieve new addresses. But it will see any transactions to and from addresses derived from it that were setup elsewhere. If there is a transaction history, you'll need to set the timestamp to be older so that this history is picked up. It can be given as a unix timestamp, or as a block height. This is used to find the oldest block to start scanning from.

To be able to get addresses from this, you would have to add "active": true to your import command:

Code:
$ bitcoin-cli importdescriptors '[{"desc":"tr(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/86h/0h/0h/0/*)#sffjysau","timestamp":"now","active":true}]'
[
  {
    "success": true,
    "warnings": [
      "Range not given, using default keypool range"
    ]
  }
]

Now you can use getnewaddress to get new bech32m addresses:

Code:
$ bitcoin-cli getnewaddress "" "bech32m"
bc1pqqeyhah6g75dwr942xv40h255q4nshqw4k8ylyhe7plej2eg3mnqz9w4np

But what about change addresses? Change addresses are derived from a different descriptor (well you could use the same one, but that's not recommended. It would still work though). The BIP 86 standard specifies a different derivation path for change addresses, so you can still use the same key but make a different descriptor that has a different derivation path:

Code:
tr(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/86h/0h/0h/1/*)#pavne9dy

To import this to be used for new bech32m change addresses, you need to also specify "internal":true, in addition to "active": true:

Code:
$ bitcoin-cli importdescriptors '[{"desc":"tr(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/86h/0h/0h/1/*)#pavne9dy","timestamp":"now","active":true,"internal":true}]'
[
  {
    "success": true,
    "warnings": [
      "Range not given, using default keypool range"
    ]
  }
]

This can be verified by using getrawchangeaddress:

Code:
$ bitcoin-cli getrawchangeaddress "bech32m"
bc1pze68k8k30zu29nzzllmhvet26avtxyfec5n88ymwzmd59mxw0wpqlt3mwu

Now importing these one by one is kind of tedious, but if you know JSON and looked closely, you'd see that importdescriptors accepts an array. So you can actually provide multiple descriptors in the same command, e.g. to import both descriptors used for change and receiving:

Code:
$ bitcoin-cli importdescriptors '[{"desc":"tr(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/86h/0h/0h/0/*)#sffjysau","timestamp":"now","active":true},{"desc":"tr(xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi/86h/0h/0h/1/*)#pavne9dy","timestamp":"now","active":true,"internal":true}]'
[
  {
    "success": true,
    "warnings": [
      "Range not given, using default keypool range"
    ]
  },
  {
    "success": true,
    "warnings": [
      "Range not given, using default keypool range"
    ]
  }
]

The same goes if I just want to import an xpub (I believe it's the same command, just changing the descriptor and checksum, correct me if I'm wrong).
Yes, if you want to import a xpub to watch, then you do the same as I described above but with an xpub. Note however that descriptors without any private keys can only be imported to wallets that have private keys disabled (i.e. watch only wallets). This is something you must turn on when creating the wallet. Likewise, descriptors with private keys can only be imported to wallets that have private keys enabled (the default when making a new wallet). Furthermore, wallets with private keys enabled requires all descriptors to have at least one private key.

And is there any command in bitcoin core to import a bunch of private keys into a descriptor wallet at once? (Similar to the importwallet command).
importdescriptors can be used to import multiple descriptors simultaneously, as I showed above. They do not have to be related, and is equivalent to just running the command once per descriptor, but much faster.

And can I import as many descriptors (xpriv, xpub etc) into a descriptor wallet as I want or is there a limit? Or does the wallet have a limit and replace the native descriptors with the new imported descriptors?
There's no explicit limit. It is not necessary to replace the native descriptors nor only have replacements for them. You can have however many descriptors that you want, so long as you have the disk space and are willing to put up with the wallet eventually getting slower. I've done some test and somewhere in the neighborhood of a few thousand descriptors it'll get noticeably slow to respond. But there are ongoing changes to improve that, and if you use xpubs and xprvs, then it shouldn't be a problem.
80  Bitcoin / Development & Technical Discussion / Re: Why is there no possibility to export privkeys when creating a descriptor wallet on: January 31, 2024, 06:30:22 PM
there is no tutorial on the internet teaching how to use it.
What is there to teach about it?

The design of descriptor wallets and migration is such that, when actually using the wallet, you don't notice anything different. It is not any different to send or receive Bitcoin than it is with a legacy wallet. The wallet software has abstracted everything away for you, just as it was for legacy wallets.

what should I do when my balance is in a descriptor wallet and I don't know how to export and import the private descriptor from that wallet to another wallet in case of emergency?
... Then learn how to do that? How did you know how to export and import a private key? You had to read it somewhere, just like you can read somewhere (e.g. my earlier posts) about how to that. Are you looking for specific instruction and can't find it?
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 ... 590 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!