text:
Is it possible to set RBF as always-on in bitcoind?
I can't seem to find any cli commands for this. Is it even possible? Or does RBF need to be opted into on a per transaction basis?
I would just like every transaction sent by my node to be RBF enabled.

You're looking for walletrbf=1.
You can configure bitcoind to always create transactions that signal replaceability by using the -walletrbf startup option or setting walletrbf=1 in the config.
Relatedly, Bitcoin Core creates by default replaceable transactions from the GUI since v0.16.0, and will also create replaceable transactions by default when using RPCs starting with the upcoming v24.0 release (see PR 25610).
Orthogonal to your question, some people contend that all transactions should always be replaceable even if the sender did not opt-in by signaling replaceability originally. Also to be released in v24.0, PR 25353 added the -mempoolfullrbf startup option which would configure a node to permit transactions in its mempool to be replaced per the established replacement rules without requiring the original transaction to have signaled replaceability. If sufficient node operators and miners choose to adopt to this updated mempool policy, the possibility of doing replacement without prior signaling may emerge on the network.

Thanks Murch. I was thinking there might be a global cli command to make it constant, in a similar vein to 'settxfee'.  The config didn't even occur to me until I read through the PR's that Michael initially replied with. So thanks guys, crisis averted :)

This is in a state of flux at the moment and could be changed in the near future (e.g. Bitcoin Core PR 25600).
There are two aspects to RBF: whether your wallet signals for RBF on transactions it constructs and broadcasts and how your node treats transactions that signal or don't signal for RBF.

Or does RBF need to be opted into on a per transaction basis?

Today for transactions that your wallet constructs and broadcasts it does need to signal for RBF, yes. Otherwise by default a Bitcoin Core node for example will not accept a RBF for that transaction. PR 25600 (open and unmerged at the time of writing) seeks to change this and allow a node to accept RBF transactions even if the original transaction wasn't signaling for RBF.
The Bitcoin Core wallet since the merge of PR 25610 (and included in the upcoming 24.0 release) signals for RBF by default. Other wallets may take a similar or a different approach.

Thanks, sounds like the 24.0 release will do what I want . Will “walletrbf=1” in the config file also work?

Yes that will ensure all transactions constructed from your Core wallet signal for RBF.

This answer does give some good background on the overall landscape but sidesteps the main question of the asker:  "I would just like every transaction sent by my node to be RBF enabled."

Agreed. I'd recommend you put Murch's answer rather than this as the accepted answer @Aaron :)


text:
Does version of Bitcoin Core determine my consensus?
As far as (voting) on the network?
I run a full node, but do not mine.
I hear people say we have a choice when changes are made.
Is it the version of Core that determines that?

There is no vote on what the rules of the network are, and your own node has no influence on the rules other nodes enforce.
Fully validating nodes (aka full nodes) locally enforce all rules of the Bitcoin protocol. A node operator expresses what they consider to be Bitcoin by deciding which node software to run. Since a node will reject any blocks or transactions that break its rules, the node operator can be sure that whatever blockchain their node shows follows the rules that they wish to enforce.
If a majority of the hashrate enforces stricter rules than some node, the stricter ruleset will produce blocks that are acceptable to those with looser rules. This can be used to introduce rule changes in a so-called soft fork: soft forks tighten rules and thus are forward-compatible to less-strict Bitcoin software. This makes the general rules on the network emergent. The network rules emerge from many users making a choice about the software they are running and the common denominator being enforced by the economic majority.
However, if a minority of the nodes enforces stricter rules than the majority of the network (without support of a majority of the hashrate), they will reject the longest chain and end up stuck on a stale chaintip.
To give some concrete examples:

a miner may choose to miner smaller blocks than allowed
a miner may choose to exclude inscriptions from their blocks
a node that unilaterally decides not to accept blocks with inscriptions will stop following the best chain
a miner that mines a bigger block than the majority of the network permits will see its block rejected

As far as (voting) on the network? I run a full node, but do not mine. I hear people say we have a choice when changes are made.

Assuming there is a soft fork (consensus change) activation attempt in progress you as a full node operator have three choices. You can run the latest version of Bitcoin Core which generally would include the new consensus rules and enforce those new rules. You can run an older version of Bitcoin Core which wouldn't include the new consensus rules or enforce them but because it is a soft fork (rather than a hard fork) this wouldn't fork you off the network. Or you could run an alternative client (if it exists) that either seeks to force through activation of that soft fork (user activated soft fork, UASF) or seeks to resist activation of that soft fork (user resisted soft fork, URSF). Consensus changes are very high stakes (they can cause chain splits and network splits) so at least in my opinion they should occur rarely, with ultimate caution and unless the user knows exactly what risks they are taking on they shouldn't deviate from their usual software practices.

Is it the version of Core that determines that?

The version of Bitcoin Core will determine whether it enforces the new consensus rules or not, yes. Very old versions of Bitcoin Core (pre v0.16) don't enforce SegWit or Taproot consensus rules for example. It is theoretically possible that a consensus change could be attempted without Bitcoin Core enforcing those new rules and without that code being merged into Bitcoin Core. But given Bitcoin Core's dominance on the network it would be difficult to activate a consensus change in this way.

Thank you! Appreciate the info

You are on the right track, I will attempt to explain from what I understand. Just be aware this could be inaccurate, do your own research beyond what I or anyone else says.
Bitcoin versions represent what are known as Soft Forks . The consensus code does not change meaning none of the original coin owners lose access to their coins, and they are also not forced to upgrade their clients(they may still want to though for other reasons which I will mention at the end).
As far as I have read, old nodes will just strip away extra data that they see as irrelevant to the transaction making it impossible for anyone with that node to USE said stripped data for a further transaction. However an upgraded node could be coded to keep that data and therefore use it to spend coins in an upgraded way that makes uses of the extra data. Now the old node has the same chain as the new node but it just cannot help anyone looking to make a transaction out of an updated output.
As I mentioned earlier there are reasons people may feel willing to upgrade their nodes, one obvious one is a reduction in future chain storage space or transaction fee cost. If there is an update that improves this it is unlikely that no one would adopt it. That being said it is set up in a way that no one HAS to adopt it because everyone verifying the chain can do with the data as they please as long as it is the correct verifiable data.
So YOU as a node runner are enforcing potential scalability on bitcoin, or any other potential soft-fork updates that may come down the line. In a sense your node is your vote and you can vote with more nodes however technically now miners have to include the transactions from a node into the blockchain. As long as the outputs being spent are valid technically they could be included in an old nodes tx pool (i am speculating i could be dead wrong here) but it is still unlikely as I assume they would just flag it as an nonstandard transaction. Not sure how that plays out, maybe its fine and the miners dont have to update? Like I said I could be dead wrong about this last part, but either way, as a node runner you're opting into supporting fee-reducing transactions that also enable backwards compatibility and reduction of block-space-bloat.

Mind blower! Thank you for the content.

No problem, I also meant to mention that there could be updates that you for example DONT want to approve of in the future, as a node runner you are technically voting for whether or not you want to approve any updated software in the future. That is what is the difference between a voting node operator and a passive one, if you care about the content of the update or not.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Elliptic Curve and SECP256K1
Just for curiosity, considering that there is a server communicating with other machine (local machine let's call it). If we have the two public keys from Local and Server and we know that Private and Public key from local machine are generated using secp256k1. Would there be any possibility to get the private key of Local? How? By considering Twist attacks?
Thanks.
Regards.

Would there be any possibility to get the private key of Local?

No. If the keys have been generated correctly (sufficient entropy etc) and independently (whether on the same machine or on different machines) then knowledge of one private key leaks no information on the other.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Is it possible to use the getboolarg function in interpreter.cpp
I'm looking to use the GetBoolArg() function in the interpreter.cpp file what changes do I have to make for it to work?
I'm still new to development c, I tried several #include but without success.
Thank you in advance.

You've tried #include <common/args.h> ?

@MichaelFolksonYes despite the fact that it is declared in this file it did not work.

You're recompiling after you've made the change?

@MichaelFolkson Yes, I get the following error: error: use of undeclared identifier 'GetBoolArg'

interpreter.cpp is part of the internal libbitcoin_consensus library, while GetBoolArg() is in common/args.{h/cpp} which is part of the internal libbitcoin_common library. The Makefile specifies a linking order that has libbitcoin_common depend on libbitcoin_consensus. In order for implementation to work, you would have to modify the Makefile and shuffle things around so that libbitcoin_consensus could depend on libbitcoin_common without any circular dependencies.
However this is an indicator that your implementation probably has a layer violation. Things in libbitcoin_consensus should not need access to things in libbitcoin_common, Rather you should add or modify one of the data passing classes to hold the value for the parameter that you want passed, and that class will be filled by callers located somewhere that already depends on both libbitcoin_common and libbitcoin_consensus.

I see thank you for the answer, I will try to modify my code accordingly.


text:
does connecting to full node via rpc over the public internet reveal your credentials?
While trying to connect to my full node, I accidentally entered my public ip address in the rpcconnect field of bitcoin.conf. Should I be worried that my  password is now out there and anyone can connect to my node via rpc? As a side note, the connection would not be successfull because I specify rpcallowip to only connect with local addresses.
rpcuser=user
rpcpassword=password
rpcconnect=public_ip

Did you actually make a connection over the internet? (i.e., is public_ip equal to the IP of the machine you ran bitcoin-cli on?)

no it is a different machine on the same local network. I realized my mistake as soon as I entered the command, so I exited before I got a response.

If it's on another machine on the local network, the connection wouldn't go over the internet. So unless you don't trust your local network administration, I don't see an issue.

The credentials for the RPC interface are sent in cleartext, so anyone who was able to observe the packets containing that information would now know the username and password for the RPC interface of your node, as well as its IP address.


text:
How to see highest available block number in "Bitcoin Wallet" app for Android (Schildbach wallet)?
If I have downloaded the "Bitcoin Wallet" by "Bitcoin Wallet Developers" (Schildbach wallet) onto an Android phone from the Google Play store, how can I see the latest block number that the wallet knows about?

At the main screen tap the menu icon (three dots at top right) and choose "Network Monitor" from the available options.

Then swipe left to switch from the "Peers" tab to the "Blocks" tab.

The top of this list shows the highest block number that the app knows about.


text:
What software do exchanges use to manage wallets?
Do they write wrappers around bitcoind or is there a better solution out there? Some exchanges handle dozens of digital currencies, does this mean they are running bitcoind, litecoind, dogecoind, etc concurrently?

From an exchange's perspective, the best option would be to write mostly your own software. From a technical perspective, an exchange only has to fulfill the following in order to be accepting a crypto-currency:

Must allow deposits of Bitcoin or coin the exchange claims to accept.
Must allow withdraws of Bitcoin or coin the exchange claims to accept.

Normally bitcoind or the altcoin variant of it, litecoind, dogecoind, etc., take care of both for a user of a crypto-currency. But an exchange has special demands. Here are some issues I can think of that may happen to an exchange if they used the core client.

Core clients are not designed to work in a multiple server environments, something vital for large exchanges.
Private keys and corresponding addresses need to be stored under special conditions. An exchange may want add a username along with an address or even reuse addresses for efficiency.
Core clients aren't exactly lightweight. An exchange doesn't need a lot of features commonly packaged together with a core client. As an example, accounts; it's purely for organizing money cosmetically, something exchanges don't need.
Core clients don't allow for more intricate control of transactions or other components, SatoshiDice is impossible to create using bitcoind because it require manipulation of transaction inputs to create sends, something you can't currently do with bitcoind.

So what should an exchange be doing?
Using a combination of the two, or even ditching the core client. There are many programming libraries that simplify all aspects of Bitcoin technology, libbitcoin is a C++ library that allows you to make a partial or full node in no time. SatoshiDice is constructed on BitcoinJ, a popular Java library for Bitcoin. There are also many libraries available for other languages, but the point is that building a node isn't too hard.
I recommend a hybrid use because bitcoind is a lot more safe and bug-free than your own code. You can accidentally create code that creates invalid transactions or even accidentally send coins to the wrong address. I'd use a library and my favorite language to detect deposits and accredit them to accounts, and then push raw transactions to a bitcoind instance running on my own or possibly the same server where it will validate it and take care of sending it other nodes in the network. Less space to mess up in code.
For altcoins, you'd need an instance running or just doing small modifications to the code to differentiate. There isn't a huge difference between the protocols all the crypto-currencies use. You should know anyways if you're planning to accept a coin as an exchange.
TL;DR
Exchanges should be using software they wrote themselves. This isn't hard to do as there are many libraries available that give you nitty-gritty access to Bitcoin. Core clients can be a bottleneck at times but can be used in conjunction to avoid said bottlenecks while maintaining a safety net for an exchange and can even simplify certain parts.

Thanks for the answer, but this all sounds like speculation.

That's true it is an educated guess on what they should be doing. No exchange has detailed how their wallets works precisely but the approach I've explained is really efficient and likely. For all we know they can be using bad implementations like Mt. Gox supposedly did. Hard to prove.

Fair enough, although not an exact answer it's still good information. I read on reddit that a common approach is to interact with the daemons with the json (rpc?) interface. I'm wondering if that is a good solution up until a certain volume of transactions.

I don't think exchanges are actually managing wallets for you, for two reasons:

For many cryptocoins, it takes time to transfer funds into a wallet. But when you purchase a certain cryptocoin on an exchange, it immediately ends up in your 'wallet'.
AntShares do not support fractions. You can only own whole units of them in a wallet. When you purchase AntShares on an exchange, you can purchase them in fractions and they will sit in your 'wallet' in fractions. It's not until you transfer them to your own wallet (no quotes) that the decimals will be truncated and you are left with whole units.

My conclusion is that exchanges merely keep records of what you own. These records may be viewed as IOUs. When you withdraw, they will tap into their own wallets.
I don't see how else it could work.

You're right concerning balance changes within the exchange, but when the exchanges perform withdrawals these obviously must happen on the blockchains. What do you think do they use to create transactions on various blockchains?

Also when withdrawing, how they send money from "your exchange address" -> "your withdrawal address" instantly? Because they don't keep it in "your exchange address", and if you withdraw money, you can see that transaction starts from "your exchange address". If exchange first transfers money from "their hot wallet" -> "your exchange address", that would add delay+fee, i don't see such delays?
cc @Murch

I think they don't send back your money (when withdrawin) from "your exchange address", but from "their hot wallet": https://support.kraken.com/hc/en-us/articles/115006441267-Differences-between-a-crypto-exchange-and-a-crypto-wallet-service

Right, if they first staged the withdrawal in a specific address and then sent it to you, they'd just do two payments when one would suffice.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Is there any altcoin with improvements in blockchain download time?
Let me introduce my idea.
Given:

sizeof( Blockchain ) = 16Gb
Downloading of one avi film 16GB from the pirate bay ( 5mb/s ) = 2-3 hours
Downloading of bitcoin's blockchain ( 5mb/s ) = 2-3 days
One day = 6 * 24 = 144 blocks.
Drag - cryptography.

Task:

Accelerate boot of fresh client to the torrent speed. Similar to Bootstrap.

As I can see, downloading of blockchain is the same hard as mining, because there is every time recalculation of hash, comparing, checking of signs, etc...
What if client will only download this 144 blocks for a day and one super block with 144 hashs of the last valid blocks, thereafter only compare current wallet's addresses with addresses in this 144 blocks without any calculation of its hash.
Is there any alt-coin with such accelerator?

E.g. this super blocks might be archived into another ultra-block for a month. Than we have similar to sha(sha(text)) cascade shield against bruteforce attack.
Downloading of blockchain should takes at max the same time as downloading of 16GB avi from the pirate bay. Say, 5mb/s internet channel + p2p / 16 Gb = 2, may be 3 hours ( in the no peers case ), but I spent 2 - 3 days, and I see that this is no internet speed reason, it is CPU + harddisk very very hard job.

I think I understand your question now: Do you mean that there should be two parallel blockchains, one with single blocks and one with consolidated large blocks that are compatible to each other, so that for synchronization one can only validate the chain of consolidated blocks, but end up being compatible to the single block blockchain?

Methinks, I have meet such alt-coins, there was a super blocks. This block must be in the blockchain like any other. Ofcouse, this is hard fork from current blockchain.

I don't think there is such an altcoin although a neat idea.

Another potential improvement: merge a QT client with bittorrent so no machine had the obligation to store the whole blockchain if undesired, rather requesting different parts of it from the network and paying the storers as they consume. And of course, receiving payments in the coin for the "service" of storing copies of the blockchain when it fulfills such a request. It could even be expanded to a DAC that provides anonymous cloud data storage, and you get paid for renting an amount of your hard disk space to it. My 2 satoshis.

Downloading the blockchain is several orders of magnitude easier than mining. Validating is just taking the blocks, hashing them and verifying that the proposed solution a) matches such hash and b) at the specified difficulty level. If a received block passes these validations, it's accepted as valid an the next one is requested, and so on.
Per comparison, downloading a movie or software implies no validation until the very end, when you check the archive is not corrupted. In case it indeed is, you have to download the whole big mess again .
As you correctly assume, most of the time is spent in verifying blocks. That's why even if a friend lends you a DVD with the blockchain, loading it for the 1st time won't be instantaneous but will take (depending on your PC's speed) from half an hour to several hours.
Your idea of creating a "resume" block at the end of the day (why not weekly/monthly/annually as well?) looks promising, I've heard of no coin implementing any such idea. It's not without potential problems, but it could be.

Your premise is wrong. The work required to download and validate the blockchain has nothing at all to do with the work required to mine it.
As far as the block hash goes, validating it requires just one hash while mining the block requires quintillions of hash calculations.
Validating the block also requires computing the hashes of the Merkle tree but the main work is validating ECDSA signatures. Your method is not going to help with that.
(On a meta note, it's rude to offer "improvements" when you don't understand well enough what currently exists.)

Could you please clarify than, why downloading of blockchain ( 16GB ) in 24x more slower than downloading the same blob file, like avi movie?

@AnomalousAwe:

Verifying all the ECDSA signatures (CPU)
Looking up previous outputs for each transaction input (Hard drive)

Having an SSD can greatly help with #2.

Once read at bitcointalk a proposal to integrate the code to hash in the GPU (e.g. taken from cgminer) into the QT client and have the GPU run the validations in parallel with the CPU, potentially yielding a big speed boost but to day there's no implementation. But then if the biggest speed block is #2 (is it? sounds reasonable to me) then accelerating #1 to almost zero won't do much to improve times.

@JoePineda
Hash != ECDSA verification.
Possibly GPU is suitable for ECDSA verification as well but it wouldn't be related to any of the existing mining software.

@Meni Rosenfeld, cascade of sha(sha(..(sha(text))..) for super-blocks - day + ultra blocks - months， will allow to skip ESDSA verification. Each block contain hash of prevision. Super block contain hashs of 144 prevision, etc... There would be only O(number of blocks) sha calculations. Ordinary CPU give you at least kh ~ 1000 per sec, 8-7 days per sec. 480-420 days per minute (months). 12 minutes = years. 24 minutes = 2 years. 2-3 hours - all of current life time

@AnomalousAwe: If you want to skip ECDSA verification, you can do so already (but then you're trusting others to do the verification for you). It has nothing to do with hashes, computing all hashes in the Merkle trees of all blocks is cheap.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Where is my money, do i have access to it?
On 10/06/21 I tried to pay for an order with bitcoin. BCH. It went from bitcoin to blockchair to simpleledger:pzt39mmtjfs8trthwvvpq0v7ktjc4wyvyqtdpmf2eh,
Transaction hash b420f82e47df1d884615a5730958fe1377977f520b69a3388e0eb54df31ac2e6
I have no idea what these transactions mean.
Can you help me find my money?

What is simpleledger? It is expecting BTC? It is expecting BCH?

"Bitcoin" (BTC) is a completely different currency than "Bitcoin Cash" (BCH). This website is for questions about "Bitcoin" (BTC), not for questions about "Bitcoin Cash" (BCH). According to blockchair your recipient has conclusively received your payment (of BCH). If your recipient was not expecting BCH, they might not have any way to access that money and might not accept that payment has been made. Just like sending Japanese Yen to someone expecting US Dollars.


text:
How do I retrieve address balances to build a Merkle sum tree?
Curious about building my own proof of solvency program. I understand how the Merkle sum tree works in theory but I am having issues understanding the practical ways of getting the information I need.
Let's say that my client, for example Newton, has 400,000 addresses for each of their 400,000 clients.

How do I get the balance for those 400,000 addresses?

How do I create the tree in such way where a customer is able to go check the balance of their address?

A Merkle sum tree is a way to prove to someone what the balances are in a verifiable way. You don't use it to look up balances. If you're the one constructing the Merkle tree, you put the account balances of all your customers im it. I don't understand why you'd want to learn them - you're the one who has the information and puts it in there.

I know what it is my question is how to get each account balance to construct it. For example, does Newton provide 400,000 different balances via an api or are the balances just on an excel spread sheet

How the account provider keeps track of their account balances is up to them, and has nothing to do with Merkle trees or proofs of reserve. It could be a database, or Excel files, or something far more complex.


text:
is it possible to recover my exodus wallet, from a backup file?
I have a one year old back-up (exodus.zip). When extracted from ZIP and placed that folder in AppData/Roaming/ now it asks for passwords which I don't remember anymore.
Inside the 'exodus.wallet' folder there are 6 files, five (info, seed, storage, twofactor, twofactor-secret) of them are '.seco' extension and one is 'passphrase.json'.
'passphrase.json' is as follows:
{
  "passphrase": "44character longs tring",
  "system": true
}

Is all my money gone? Or is there any way to recover?


text:
"which bitcoind" outputs nothing
I installed bitcoind using Windows 10 WSL Ubuntu.
I see the bitcoind.exe file in the src directory, but when I run "which bitcoind" I get no output.

This is expected.
which only searches for binaries in your $PATH variable (e.g. it needs to be placed in /usr/bin or /usr/local/bin for that). If you didn't put bitcoind there, you'll need to invoke it using the pathname (e.g. ./src/bitcoind in the directory that holds it).

This is expected after following the instructions in the doc\build-windows.md file? can I add the installation folder (/home/myuser/bitcoin) to PATH?

@RonyTesler: many open source software allows you to "auto" be added to PATH via /usr/local/bin/ if your run "make install".

@Mercedes I already ran 'make install DESTDIR=/mnt/c/workspace/bitcoin' before runnin 'which bitcoind'

/mnt/DRIVE_LETTER// could be part of WSL's PATH by default, or not. I don't and won't know, I can't answer you.

What's the difference between adding /mnt/c/bitcoin to PATH and adding /home/myuser/bitcoin?

@Mercedes Or should I add '/mnt/c/workspace/bitcoin'? Because I used 'make install DESTDIR=/mnt/c/workspace/bitcoin'

@RonyTesler if it is installed there, you would want to add there to PATH


text:
bitcoin-qt -testnet wallet dumped error EXCEPTION: NSt8ios_base7failureB5cxx11E
I got an error message but don't understand what to do now, to fix this.
************************
EXCEPTION: NSt8ios_base7failureB5cxx11E
CDataStream::read(): end of data: iostream error
bitcoin in opencon

terminate called after throwing an instance of 'std::ios_base::failure[abi:cxx11]'
  what():  CDataStream::read(): end of data: iostream error
Aborted (core dumped)

My regtest and signet are doing fine. It's only wallet testnet v3.
I hope somebody can point out what it is and how to fix it.

what does this iostream error mean? anybody ?

I'm not a specialist in these things but to me smells like some lib is broken. If you try this on a brand new install of a stable version of mainstream distribution, I would sort of doubt that this kind of bug would be going to happen.

thank you i fixed it by making an clean install thank you for your responce .


text:
best btc node and lightning to run in lubuntu
I run lubuntu in my ~#missing#~. I have made multiple efforts to install umbrel, I tried it but I couldn't install to my external SSD because I run out of space. I used all the possible commands but with no success. I need another software for my lubuntu to build my node without buying more hardware if that is possible.

Mh yes, this is one of the tricky parts of the lightning network! Sorry about that
In my early years, I worked on this problem and how to solve it with core lightning, and I came out with a solution that used the https://github.com/clightning4j/btcli4j plugin to fetch the bitcoin data in a different way (including the Rest API, so you do not need a bitcoin node)
You can find the description in my article that uses the docker to run all the architecture https://github.com/clightning4j/clightning4j-node
Otherwise, if you want to run core lightning without docker, you can just install the plugin and run it with the command lightningd --disable-plugin bcli


text:
What's a rule of thumb for setting the maximum number of connections?
Connectivity of full nodes varies a lot, ranging from phones with mobile service to servers in data centers. Also, many nodes probably have asymmetric bandwidth.
Assuming the goal of maximizing utility for the Bitcoin network, is there a rule of thumb for setting the maximum number of connections (-maxconnections) in a full node? How was the current default value of 125 in Bitcoin Core chosen?
My thinking is that more connections will make it possible to learn about the existence of  (candidate) blocks and transactions earlier, but at some point bandwidth will suffer too much with the effect that transferring the data will take too long.
To keep the scope of the question limited, I'm primarily interested in the networking parameters and not so much in memory and CPU limitations.

The -maxconnections setting primarily controls how many inbound connections a peer can accept. The number of outbound ones is independently limited (~10), so unless -maxconnections is set lower than 10, it doesn't affect outbound connections.
My mental model is that inbound connections are primarily a service you provide to the network. As your node cannot control who connects to you (apart from evicting "bad" connections when the limit of connections gets exceeded), quality of inbound connections isn't guaranteed. Certainly they may be helpful too, but in adversarial settings we cannot assume that. Thus, we generally assume outbound connections are "better" (though quantifying this is very hard).
So I believe the answer to your question of "what should I set -maxconnections" to is simply as much as you can tolerate, but there are few benefits to you personally.
Let me go into some aspects that this setting impacts:

(+) eclipse/partition resistance: More connections does mean that you're more likely to have at least one honest connection to the network, but with the caveat that due to the limited control we have over inbound connections, outbounds are far better to accomplish that. Of course, connectable slots are a (sometimes) scarce resource too, which restricts how many outbound connections is reasonable to have nodes make.
(-) (average) bandwidth There is a bandwidth impact from having more connections (something that Erlay aims to partially address), primarily because every transaction will be announced at least once over every connection (~36 bytes per transaction), in one of the two directions. On average this adds maybe ~1 KiB/s per connection in an honest steady-state situation (block-only connections have a lower impact).
(-) block propagation latency More connections means more nodes you'll announce newly discovered blocks too; if they all fetch those at the same time, your network connection may get saturated to the point where it increases the latency of your connections.
(-) memory usage This is probably the most important impact a connection has in common situations. The various buffers and data structures used to keep connection state can (especially in adversarial conditions) amount to several megabytes. There are certainly systems running Bitcoin nodes that couldn't tolerate thousands of times that.
(-) CPU usage I don't really have hard numbers for this, but I expect that the CPU impact of an additional connection is relatively low. After all, you won't see meaningfully more blocks or transactions with more connections, as even with a single (honest) one you're expected to see ~all of them. There is cost on the P2P side of things too (just shuffling messages around, checksumming them, decrypting them in case of BIP324). And in adverserial situations, an attacker can probably saturate the Bitcoin Core network thread with just a few connections anyway.

There is a project to increase the default number of inbound connection slots in Bitcoin Core if they're blocks-only connections (which have lower bandwidth/memory costs), with a prospect to increase the default outbound connection limit later.

Thanks, this is a great overview for newcomers. Nevertheless, I think it misses the essence of my question somewhat, which is the trade-off you touch upon in the paragraph "block propagation latency". Indeed, if the node has too many connections, block propagation delay will increase, so "simply as much as you can tolerate" is probably not the final word here. But I admit that this quantifying this without further assumptions, e.g., about the bandwidth of connected nodes, seems pretty hard...


text:
Possible number of signers with MuSig
With multisig, up to 20 signatures may be used in a threshold signature scheme (What are the limits of m and n in m-of-n multisig addresses?).
As far as I understand, there should be no hard-coded limit with MuSig, as to the blockchain every scheme would always look like just one single signature (from one single key-pair), even if in reality those were multiple signatures that just were aggregated into one.
Is there anything else that limits the amount of signatures that can be used with MuSig, or is this number of possible signatures essentially infinite?

The number of signers with MuSig (and MuSig2) is practically infinite. For example, creating a MuSig signature with 1 million signers takes about 130 seconds on my laptop (see https://github.com/jonasnick/musig-benchmark).
However, MuSig(2) does not have the same functionality as OP_CHECKMULTISIG. MuSig only supports m = n which is the definition of "multisignature" outside the Bitcoin space. OP_CHECKMULTISIG supports m <= n and is therefore more accurately referred to as "threshold signature". There is a scheme called FROST that allows creating threshold signatures that look like a single Schnorr signature and ongoing work to implement it for use in Bitcoin.
Note that tapscript disables OP_CHECKMULTISIG and instead introduces OP_CHECKSIGADD, which does not have the 20 signature limitiation.


text:
Signing a raw transaction with multiple inputs
So I am creating a simple P2PKH transaction and after I researched about this found few useful posts and answers here; I was able to successfully spend a a single P2PKH UTXO but it is really getting complicated when I try to spend transaction with multiple inputs. I have spent a day entirely on this.
All transactions are on Bitcoin Testnet.
Outputs I am redeeming:

Tx Hash: 9742ed783bfec215ec6484d82dae20fba582229e54c49e06d662a91ead3f6a54
  Index: 0
  scriptPubKey: OP_DUP OP_HASH160 81f52d4061313b6f63549efc03f3df6cb6f0149e OP_EQUALVERIFY OP_CHECKSIG
Tx Hash: 40dbd3c25073cb7222becead1eb9bb2195cf309cf5b24af559f3391168ec6318
  Index: 0
  scriptPubKey: OP_DUP OP_HASH160 81f52d4061313b6f63549efc03f3df6cb6f0149e OP_EQUALVERIFY OP_CHECKSIG

Now I read an answer from here that suggested if using multiple inputs, one should replace scriptSig for rest of inputs (the ones not being signed) to empty;  And I have tried these variations so far:
1. Replacing scriptSig for inputs with "00"
So only the input (UTXO) that is being signed will have its scriptPubKey, and other input(s) should have "00" in place.

Serialized input #1 when signed:
  01000000
  02
  546a3fad1ea962d6069ec4549e2282a5fb20ae2dd88464ec15c2fe3b78ed4297
  00000000
  19
  76a91481F52D4061313B6F63549EFC03F3DF6CB6F0149E88ac
  ffffffff
  1863ec681139f359f54ab2f59c30cf9521bbb91eadcebe2272cb7350c2d3db40
  00000000
  00
  ffffffff
  01
  c0fb390000000000
  19
  76a914DD02C23FF4C3FFC6DA1C74B7EA5BCB0891B0E98288ac
  00000000
  01000000

and...

Serialized input #2 when signed:
  01000000
  02
  546a3fad1ea962d6069ec4549e2282a5fb20ae2dd88464ec15c2fe3b78ed4297
  00000000
  00
  ffffffff
  1863ec681139f359f54ab2f59c30cf9521bbb91eadcebe2272cb7350c2d3db40
  00000000
  19
  76a914A17C43FE0E1F8E660B044C9538E2CEF4ABFDCED288ac
  ffffffff
  01
  c0fb390000000000
  19
  76a914DD02C23FF4C3FFC6DA1C74B7EA5BCB0891B0E98288ac
  00000000
  01000000

main transaction with both inputs signed: (signatures without 01 hash code type suffix and public keys are bold)

01000000
  02
  546a3fad1ea962d6069ec4549e2282a5fb20ae2dd88464ec15c2fe3b78ed4297
  00000000
  6a
4730440220E4A366646391B3CFB06C0C4B0343E678B560BE8A2D20418233DEE863986105E502207245C5BA3DB516E59B95764C1716F5B39850E20429F08B91389C4780CE45430E0121025F69830D2BA35D04CA9EFB3EA46AA2645BBBDCB592A189A539480657C9696137
  ffffffff
  1863ec681139f359f54ab2f59c30cf9521bbb91eadcebe2272cb7350c2d3db40
  00000000
  6a
4730440220C41C498D0CA55E38FE85DD158FDE82BB451068124E2B3AA2391D861BA9281EDD0220165712ADF71B19DF525583D8F48B82DFF06B2E556C17A583F4D5C54E99412C6B0121039F9AF4A84A8D5C35DD7A5628F8C2DC1894C2B4BDD4815DAFFDCBC9102FE2BA26
  ffffffff
  01
  c0fb390000000000
  19
  76a914DD02C23FF4C3FFC6DA1C74B7EA5BCB0891B0E98288ac
  00000000

now decode raw transaction works but when trying to broadcast it, bitcoind gives these errors:

mandatory-script-verify-flag-failed (Signature must be zero for failed
  CHECK(MULTI)SIG operation) (code 16)

or

non-mandatory-script-verify-flag (Non-canonical DER signature) (code
  64)

I have tried different variants:

Replace scriptPubKey of inputs that are not being signed with just "00"
Replace scriptPubKey of inputs that are not being signed with just ""
Remove sequence number from inputs "ffffff"

but nothing seems to work. What am I doing wrong? Your help will be appreciated :)

and other input(s) should have "00" in place.

Keep in mind that you replace the "scriptsig" with "empty" and the 0x00 is the size of the empty script.

non-mandatory-script-verify-flag (Non-canonical DER signature) (code 64)

The problem here is the DER encoding used in your signatures. r values in a signature are positive and since each r value that you have has its most significant bit set they need a preceding 0x00 to tell the DER-decoder that the numbers are positive:
0xE4 = 0b11100100
0xC4 = 0b11000100

Each signature should change to this: 483045022100E4A3...

You are right!!! I was going nuts over transaction preparing while the issue was from ECDSA lib side. Thank you mate!


text:
transfer btc core wallet to electrum
I am running a btc node and it is taking too long to sync. Is there any way to transfer the wallet to an electrum wallet? If so how?
1)Upgraded my btc node
2)Syncing
3)Transfer receiving addresses from btc to electrum
4)Whole amount from btc wallet does not match electrum wallet
5)About 15% difference
I am ready to shut down my btc node and save electricity.  Will I still be able to retrieve the lost bitcoins some time in the future.
I imagine a day where I could bring it to a place like Walmart or Best Buy to fix it.  Or Are there places you can bring it now?

Have you received funds to the bitcoin-core wallet already?

Yes, I've emptied out all the receiving addresses but it does not equal the total in the btc core wallet. It is less. Don't know why. Any suggestions?

????????????????

Can you edit your post to include an order of events? How many times did you receive funds to the wallet made with bitcoin-core? Did you somehow send funds out of the bitcoin-core wallet in the past? Have you exported private keys from bitcoin-core and imported them to electrum? -- You could try running the command bitcoin-cli listunspent to see if there are any UTXOs still controlled by the wallet, but it may not return an accurate result if your node has not yet fully synced with the network

@requim: If you ever sent funds out of the wallet, some might be in a change address.

Change address? Can you explain that further? How would I find that address and private keys?


text:
Why would a popular e-commerce lack incoming liquidity?
I am not able to understand why if a popular ecommerce will not lack incoming capacity and the below highlighted part

Closing channels will incur an on-chain fee and will reduce your
Lightning node’s capacity and connectivity. However, if you run a
popular ecommerce node, you will not lack incoming capacity and can
strategically close channels with large local balances, essentially
“bundling” your funds for movement on-chain. You may need to use some
channel rebalancing techniques (see “Rebalancing Channels”) before you
close channels to maximize the benefits of this strategy.

This is a matter of liquidity. A payment channel of 1BTC may only transfer at most 1BTC [0] in each direction.
Let's take an example: Alice and Bob have a 1BTC payment channel:
Alice <- 1BTC -> Bob

There is 1 bitcoin locked in the channel. Funds are necessary on one side or the other. For instance, let's say Alice unilaterally funded the channel. At the beginning, she'll have all funds on her side:
Alice            Bob
-----            ---
1 BTC            0 BTC

Now if she pays Bob, the amount of funds locked in the channel will not change. She necessarily sends some from her side to the other:
Alice            Bob
-----            ---
1 BTC            0 BTC
0.9 BTC          0.1 BTC

If Bob is selling stuff and getting paid in BTC through this channel (whether it is Alice paying him or someone else routing their payments through Alice's channel with Bob), Bob will tend to get all the channel funds on his side of the channel over time:
Alice            Bob
-----            ---
1 BTC            0 BTC
0.9 BTC          0.1 BTC
0.6 BTC          0.4 BTC
0.7 BTC          0.3 BTC
0.1 BTC          0.9 BTC
0 BTC            1 BTC

At this point Bob cannot receive funds from this channel anymore. He can close the channel to withdraw onchain his 1BTC. This is what the text you quote is referring to. We can say Bob "bundled" a large number of small incoming payment in a single onchain transaction moving an entire BTC.

[0] Conceptually. Technically, it's less than that.

Heh, looks like i read your question too quickly and didn't actually answer it. The response might just be that the document assume if the e-commerce is popular, people will open channel to them and therefore they wouldn't lack incoming capacity.


text:
LevelDB error after power outage
After a power outage, starting bitcoind I recieved this errors (circled in the image). Reading online some users suggest to do a reindex and i did it but after 11 hours my node isn't reindex yet... The process is still going on about the file blk03375.dat. How many blk*.dat it have to reindex? Is this the right procedure for my error?

This is the right procedure, although you could have tried a reindex-chainstate first since the corruption looks related to the chainstate. It is faster since it only rebuilds the UTxOs index, without the blocks index.
It's to be expected that the reindex takes in the order of hours or days depending on your machine. The number of blk*****.dat varies, but after 11 hours and being at the 3375th blk file you are probably close to completion. A more accurate way of tracking the progress would be to look at the debug.log's UpdateTip messages.


text:
Sigop count and its influence on transaction selection
This question was inspired by this recent mempool phenomenon: some transactions were left out from blocks even when they had a competitive fee-rate simply because they had a positive sigop count and the max sigop count was reached before the block template was totally filled. Whatever empty space remained was filled using zero sigop txs.
It seems that miners have to solve a knapsack-like problem where they are constrained by two hard limits: one is the size of the block and the other is the maximum amount of sigops. The former is the one actually optimized for in the standard mining algorithm, and the latter is more-or-less considered due to the content of this PR, which penalizes the size of a transaction if it has a high sigop count.
I have two questions:

Suppose the mempool contained no zero sigop transactions and that the selection algorithm constructed a block template consisting of high sigop count transactions only but lots of available space. Is it guaranteed by the choice of nBytesPerSigOp that this block template is more convenient for miners that one where the block is full and high sigop transactions are avoided?
Judging by this answer it'd seem as if indeed the miner could earn slightly more if they did some clever work, but that it'd be hard for it to actually happen in practice.
Why isn't the standard mempool-based fee estimation algorithm sigop-aware? In a context in which there are lots of high sigop transactions with competitive fee-rates, there are two different next block fees depending on whether the transaction one is about to craft has a positive sigop count or not.

The fee estimator uses virtual size, which is influenced by the number of sigops. Why do you say it's not sigop-aware?

@AntoinePoinsot True, my question was poorly worded. What I meant to say is that in the case that sigops are a limiting factor, as mononaut explains in their answer, there are in fact two next block fee-rates: one for zero sigop txs and one for non-zero sigop txs.

Q1: Suppose the mempool contained no zero sigop transactions and that the selection algorithm constructed a block template consisting of high sigop count transactions only but lots of available space. Is it guaranteed by the choice of nBytesPerSigOp that this block template is more convenient for miners that one where the block is full and high sigop transactions are avoided?

There are no guarantees that templates generated by Bitcoin Core will be optimal.
The adjusted vsize introduced by PR #8365 significantly underweights the contribution of high sigop transactions to the sigop limit, charging only 40% of the equivalent usage of the weight limit.
This means that in such extreme scenarios, the miner would likely lose out on fees compared to a weight-maximizing block.
However in practice it's very rare for sigops to be a limiting factor in template construction. Over the last 10,000 blocks (between heights 815316 and 825316), only 62 were constrained by the sigop limit, despite an abnormally large number of high sigop transactions during that period.
As long as sigops are not a limiting factor, it's more profitable to accept the additional fees incurred by the bytespersigop adjustment than to exclude them by raising the penalty further. So the current default of 20 weight units per sigop is likely to be more profitable than a "fair" cost of 50 WU/sigop most of the time.

Q2: Why isn't the standard mempool-based fee estimation algorithm sigop-aware? In a context in which there are lots of high sigop transactions with competitive fee-rates, there are two different next block fees depending on whether the transaction one is about to craft has a positive sigop count or not.

I suspect that nobody anticipated this scenario would actually occur, or thought it would be too rare to justify the additional effort and complexity.


text:
Is the signature check performed when the signature is the empty vector?
In this answer Vojtěch Strnad wrote the following:

OP_CHECKSIGADD always performs one check per signature, since unused
public keys are required to be paired with an empty witness item and
are skipped.

I'm interested in the following. If we provide zero (OP_0 / no item on a stack / empty witness item) and public key to OP_CHECKSIG (pre-segWit/post-segWit), to OP_CHECKSIGADD or to OP_CHECKMULTISIG (pre-segWit/post-segWit) will it perform any check operation or it will just skip the check (as Vojtěch said) and put 0 on the stack?

For pre-Tapscript opcodes (CHECKSIG and CHECKMULTISIG), the empty signature is checked against the public key. Note that by standardness if the check fails, the signature is required to be the empty vector.
For Tapscript opcodes (CHECKSIG and CHECKSIGADD), the signature check is not performed at all if the empty vector is passed as the signature. Note that by consensus if the check fails, the signature is required to be the empty vector.

What is the purpose of OP_CHECKSIGVERIFY then? According to what you said, OP_CHECKSIG and OP_CHECKSIGVERIFY then have the same meaning.

Nvm, I found it in BIP342.

Yes, CHECKSIG and CHECKSIGVERIFY behave in the very same way with regard to signature checking. CHECKSIGVERIFY just immediately stops execution if the signature check failed.

Well I missed to add "in Taproot". In taproot there is no difference between CHECKSIG and CHECKSIGVERIFY, they will both immediately stop execution if the signature check fail.

Only difference, as I see from the BIP342, is that if the check is valid, CHECKSIG will push TRUE (0x01) on the stack, while CHECKSIGVERIFY won't do anything. Also, if the signature is empty vector, CHECKSIGVERIFY will terminate the execution and invalidate script while CHECKSIG will push empty vector (even though I do not know how can you push an empty vector; its like pushing air?).

OP_CHECKSIGVERIFY is exactly equivalent to OP_CHECKSIG by OP_VERIFY. The stack consists of a list of byte vectors. E.g. OP_0 pushes the empty vector, which represents the number 0 (to numeric opcodesk).

@PieterWuille Yes, but in non-Tapscript. However, as I see from the BIP342, in Tapscript they are literally the same (plus this additional differences I wrote above). They both terminate and invalidate script if the signature is not valid (unlike in non-Tapscript where CHECKSIG would not invalidate it but only put 0x00-empty vector on the stack). So it would even be okay if one of these two opcodes was removed. Right?

Even in BIP342 Tapscript, OP_CHECKSIGVERIFY is equivalent to OP_CHECKSIG plus OP_VERIFY. All the OP_*VERIFY opcodes are redundant, as they are all equivalent to another opcodes plus OP_VERIFY.

@PieterWuille I want to say that in Tapscript you do not even need OP_VERIFY after OP_CHECKSIG to get the same effect as OP_CHECKSIGVERIFY opcode since OP_CHECKSIG will also immediately invalidate (halt) script if the signature is not correct (same as OP_CHECKSIGVERIFY).

That's true for invalid signatures in general, but not for empty signatures, which causes OP_CHECKSIG to leave an empty element on the stack, while it causes OP_CHECKSIGVERIFY to abort.


text:
What determines the block's timestamp?
As a miner, what happens if I propogate a block with a future timestamp, or yesterday's timestamp? What determines the block time? Can I just give any time here or is it okay to change it with 1-2 seconds?

The timestamp of a block must be higher than the median of the timestamps of the past 11 blocks. It also needs to be less than 2 hours in the future (wall clock) at the time of validation.
Note how a block invalid by the second rule can become valid eventually.

So what you are saying is there can be a recent block whose timestamp has a previous date than the latest block?

Yes, as long as its timestamp is higher than the median of the past 11 blocks.


text:
How are transaction fees computed
For example, how much would the fee be to send $350 to someone? The person is trying to tell me it would cost $270 for 225 bytes

A person is telling you this is the fee? Why is there a person involved? This makes me wonder if you are somehow caught up in a scam. Can you elaborate on the situation at all?

The Bitcoin transaction fee depends on :

The size of the transaction
The current feerate

The transaction fee in $ depends in addition on the price of a bitcoin in dollar.
Simply put, the size of the transaction basically depends on the number of time you received bitcoins in the past (if you want to send 350$ the transaction size will be higher if you received a hundred times 3.5$ than if you received ten times 35$). This is the number of inputs of the transaction.
The feerate depends on the current demand for block space.

The bytes were 225

The estimated fee rate for your transaction to be included in one of the next ten blocks (1h40) is currently of 0.00002121btc / kilovbyte.
The current price of a bitcoin in dollars is about 8800$ / btc.
This transaction would cost you about 0.042$ (to be confirmed in the next ten blocks).
>>> 0.00002121 * 225 * 8800 / 1000
0.04199579999999999


text:
Does number of inputs or outputs affect bitcoin transaction fee?
I would like to know how inputs and outputs affects my bitcoin transaction fee using legacy address, and how using a segwit address will decrease the same  transaction?
and how they will be calculated?
if input and outputs affects how can avoid that, apart of segwit address method?
thanks a lot.

Does this answer your question? What is the size of different Bitcoin transaction types?

The number of inputs and outputs affect transaction size (bytes). The more inputs/outpus you have, the larger is the transaction size. Segwit addresses reduces transaction size.
So the best is to always consolidate your inputs when the fees are low, so that we the network is congested you can make a transaction with a single input and two outputs (one for change).
To consolidate inputs just make a transaction with the inputs you want to consolidate to an address of yours. Electrum wallet allows you to choose which input you want to expend.
At this website you can play around with the number of inputs, outputs and address type, and the respective fee for the transaction.
https://www.buybitcoinworldwide.com/fee-calculator/

Format for 1 input 2 outputs (1 to receiver, 1 change to owner). Normal non-seg transaction
P2SH    73 bytes(input) 32x2 (output)
P2PKH  about the same as P2SH
To reduce fees reduce
a) no of inputs.
b) Use exact match (with no change output) if possible.
c) when fee is low, use more inputs or consolidate your input to fewer UTXO.(reduction of input for your future tx).
I think fee reduction increases a lot when you use multi-sig using seg-wit.
Output format 2of3 multisignature
      Input size    Out size
P2SH    297 32
P2SH-P2WSH  140 32  Wrapped Segwit
P2WSH   105 43 Native Segwitness
P2TR    58* 43 Pay to Taproot
P2PKH   148 34

means the recovery is more expensive.

To be actually sure of saving then you may want to go through the exercise of manually decoding every different type of bitcoin TX with various no of input and output.
(up to byte level where U can actually count).


text:
What are Bloom filters and why does Bisq require them to be activated on my local node?

First of all, why does Bisq care about Bitcoin Core being installed or not?
Then why does it require it to be fully synced and not pruned?
Finally, the error message talking about "Bloom filters" is confusing me, what are they and why does Bisq need them ?

Bloom filters are a legacy way for a light client to query transaction data from a P2P node.
They are defined by BIP37 and we usually refer to these clients as "SPV wallets".

Why does Bisq care about Bitcoin Core being installed or not?

So that it can query transactions from localhost instead of scanning from some external source (with the well-known privacy leaks of bip-0037).

Why does it matter if it's "fully synced" or not before Bisq is started?

Considering the application, they may want to be sure to be to the latest Bitcoin state before taking any action on their own P2P network.

Why does it matter if it's "running in pruned mode"?

You'd be missing blocks and potentially some historical transaction data that Bisq might want to query for.


text:
How to raise the bad-txns-vout-negative error?
I wanted to replicate the bad-txns-vout-negative error scenario. I tried the following but getting 'Amount out of range' only:
Here is the command i tried:
bitcoin-cli -named createrawtransaction inputs="[{\"txid\":\"af7cc9204d0ab7d52f66a5dacb79b77c34c90013e3288a391557ee8e07c3c307\",\"vout\":"0"}]" outputs="{\"data\": \"6e636861696e20626974636f696e207361746f73686920766973696f6e\",\"myTmAe67rCuJU5X1fqKiEYohb53TEQrxP3\": 6.249996,\"mt8QSx6m6Fwqt8zMVcji16UiVYS8xYRwFi\": -0.001000}"
error code: -3
error message:
Amount out of range

https://en.bitcoin.it/wiki/Protocol_documentation#Transaction_Verification
The above link helped me in achieving the scenario.
Original raw_tx:
020000000107f0dd405759fa448d500ea323e4e4a088bcdbf160e87c262e0467df61156166000000004847304402205e5a5d6dff4c7dcce55e5b1271e9d4da3cfefe1661103dba9806966954ac27420220366556056450adbee603ed76a157d518d38767edc1f6a6c86f51be7d8c29f90f41ffffffff0210270000000000001976a9148d0391dafaa4157b0349f1f5b44855a36e46a7b388ac70e45302000000001976a914e4eddb8f459be89a0ac48bd76f11f0198b20a98188ac00000000
020000000107f0dd405759fa448d500ea323e4e4a088bcdbf160e87c262e0467df61156166000000004847304402205e5a5d6dff4c7dcce55e5b1271e9d4da3cfefe1661103dba9806966954ac27420220366556056450adbee603ed76a157d518d38767edc1f6a6c86f51be7d8c29f90f41
ffffffff
02
1027000000000000 - 10 27 00 00 00 00 00 00 - 00002710 - hex o decimal - 10000 * 0.00000001 = 0.0001
19
76a9148d0391dafaa4157b0349f1f5b44855a36e46a7b388ac
70e4530200000000 - 70 e4 53 02 00 00 00 00 - 0253e470 - hex to decimal - 39052400 * 0.00000001 = 0.390524
19
76a914e4eddb8f459be89a0ac48bd76f11f0198b20a98188ac
00000000
Final raw_tx required for this error scenario:
020000000107f0dd405759fa448d500ea323e4e4a088bcdbf160e87c262e0467df61156166000000004847304402205e5a5d6dff4c7dcce55e5b1271e9d4da3cfefe1661103dba9806966954ac27420220366556056450adbee603ed76a157d518d38767edc1f6a6c86f51be7d8c29f90f41ffffffff0210270000000000001976a9148d0391dafaa4157b0349f1f5b44855a36e46a7b388ac70e45302ffffffff1976a914e4eddb8f459be89a0ac48bd76f11f0198b20a98188ac00000000
As you can see above that I just replaced eight zeroes to eight f's.

The createrawtransaction command will do a sanity check of the arguments and return the Amount out of range error if the value is not >= 0 and <= 21000000 * 10e7, so that you don't shoot yourself in the foot.
You need to craft the invalid on your own, you can see an example of precisely what you are trying to achieve in the functional test suite (which uses python-bitcoinlib).


text:
Cannot start C-lightning after reboot
I have problems starting up C-lightning's lightningd on Debian Buster under vagrant.
Steps I followed:

Fresh install bitcoind
Install lightningd
Run rpc commands - all good.
Reboot system
Get the error

Following is the output of lightnind after reboot:
2020-07-20T02:59:44.639Z UNUSUAL plugin-bcli: Could not connect to 'lightning-rpc': Connection refused
2020-07-20T02:59:44.652Z INFO plugin-bcli: bitcoin-cli initialized and connected to bitcoind.
2020-07-20T02:59:44.730Z UNUSUAL lightningd: Waiting for initial block download (this can take a while!)
2020-07-20T02:59:44.732Z UNUSUAL lightningd: Unable to estimate opening fees
...
2020-07-20T02:59:44.732Z UNUSUAL lightningd: Unable to estimate max_acceptable fees
2020-07-20T02:59:44.925Z UNUSUAL plugin-bcli: bitcoin-cli getblock 00000000000000ad6082acfe902b2ee294f4d1219f12b67bf59f88bb9d4af729 0 exited with status 1

Can you post your lightning config file and how you start lightningd? (maybe also for bitcoind) - remember to remove sensitive passwords first if you have those in these files. Also are you sure Bitcoind is running? The log entry suggests it but just making sure

The first line is normal behaviour:
UNUSUAL plugin-bcli: Could not connect to 'lightning-rpc': Connection refused

Your lightningd cannot start if the underlying bitcoind is not up-to-date:
2020-07-20T02:59:44.730Z UNUSUAL lightningd: Waiting for initial block download (this can take a while!)
2020-07-20T02:59:44.732Z UNUSUAL lightningd: Unable to estimate opening fees
...
2020-07-20T02:59:44.732Z UNUSUAL lightningd: Unable to estimate max_acceptable fees

You just need to wait for bitcoind to finish IBD. lightningd will regularly poll it and launch as soon as it's synced.


text:
`reindex-chainstate` configuration in bitcoin.conf?
Is there a specific flag I can place in bitcoin.conf to reindex the chainstate (not command line)?
Ie:
reindex=1 does a full reindex is there a flag like
reindex-chainstate=1 or similar?

Yes. All command line options can be specified in the bitcoin.conf file using the same name without the leading dash (-). For -reindex-chainstate, you add reindex-chainstate=1 to your bitcoin.conf.
Note that putting options into the config will run them every time you start Bitcoin Core. In the case of reindex-chainstate, you really want to only use the flag once—you do not need to start with reindexing every time you restart Bitcoin Core. So be sure to remove any options that you only wanted to run once after restarting Bitcoin Core the first time.

Though, you really shouldn't. It's something you should only pass once. If you put it in your bitcoin.conf, it'll start over with reindexing every time you restart.


text:
Syntax for c-lightning RPC commands
I am trying to use the getroute command, specified as such:
getroute id msatoshi riskfactor [cltv] [fromid] [fuzzpercent] [exclude] [maxhops]

Do I need to include all the elements above, or can I ignore the optional elements (which I understand to be the ones in square brackets) and rely on their default values?
If I can ignore the optional elements, how do I do that?
How can i specify the exclude parameter? I had an error trying with:
getroute 024...a67 1000000sat 10 exclude="687193x890x0/0, 687193x890x0/1"

(I am using Spark wallet's RPC console, FYI.)

Using C-lightning RPC interface you can avoid specifying optional parameters, just by not specifying them. Using the console in Spark wallet shouldn't be different.
You can refer to a specific optional argument by its name while omitting the others by using the -k command line option of lightning-cli. So for the example your gave:
lightning-cli -k getroute id=024...a67 msatoshi=1000000sat riskfactor=10 exclude='["564334x877x1/0","564195x1292x0/1"]'

I don't know if Spark provides a way to refer to options by their name. You can always just specify the default of the options as documented.

Thanks. When I enter the above, including the square brackets, I get the following error: exclude: should be an array: invalid token '"[“687193x890x0/0”,“687193x890x0/1”]"'

This is a quote escape issue. Use single quotes around the array.

Thanks. I included single quotes around the array - '["687193x890x0/0","687193x890x0/1"]' - and now get the error: exclude: should be an array: invalid token '"["687193x890x0/0","687193x890x0/1"]"'

Take a look to the double quote posted in the solution, there are wrong! See why here https://bitcoin.stackexchange.com/a/119278/91194

Ok posting a solution of the https://bitcoin.stackexchange.com/a/107205/91194
Sorry if the command line params in JSON are a little bit a mess in core lightning, but it is the best standard format that we found.
The problem is that there is a very difference between double quotes in OSX and double quotes in Linux. Simply are different and our parser go crazy!
So take the example inside the answer of Antonie, he has a OSX system base just because the quote posted is “ and not ".
So if you run now the command with this difference in mind
clightning -k --testnet getroute id=03b39d1ddf13ce486de74e9e44e0538f960401a9ec75534ba9cfe4100d65426880 amount_msat=1000 riskfactor=1 exclude='["564334x877x1/0","564195x1292x0/1"]'
{
   "route": []
}

Done! but if you can open a issue by linking this answer we try to find a solution for this parser bug (I am not sure that it is a bug btw)

For what it's worth @vincenzopalazzo i don't have an OSX-based system. No idea how comes the quotes in my answer seem backward.

@AntoinePoinsot Yeah I was thinking why you were using OSX based too, but this happens with OSX a lot, I am not sure if there is another way to write them too


text:
How does a node send a chain?
I understand that in selfish mining a malicious node can "send its entire hidden chain". Exactly how is this done? I know that usually a single block is broadcast-ed right after it is mined, but how does it relay an entire chain?
I am looking at the original bitcoin protocol https://en.bitcoin.it/wiki/Protocol_documentation#inv
It seems that inv can broadcast many objects. So would a malicious node send an entire chain via one call to inv or many?

@Prayank, I read a few links describing that the entire hidden chain is "published" when the length of the hidden chain is N+1 where N is the length of the main branch.This link https://decentralizedthoughts.github.io/2020-02-26-selfish-mining/ says "The selfish miner continues to extend her secret branch until the public chain is one step behind. Then she publishes her secret chain."

I understand that in selfish mining a malicious node can "send its entire hidden chain". Exactly how is this done? I know that usually a single block is broadcast-ed right after it is mined, but how does it relay an entire chain?

Forks appear naturally, when two miners produce competing blocks approximately simultaneously. Such forks may have arbitrary length (thankfully, with exponentially decreasing probability under reasonable assumptions), which may need to be resolved. Doing so involves having a mechanism of synchronizing chains where the receiver is missing multiple blocks. So there isn't anything special here, it's just the normal protocol for relaying blocks that is used.
What that protocol is depends on the software used.

The basic approach involves sending an inv for the new tip. The receiver will then fetch the block using getdata, notice it is missing its parent, and ask for that parent using another getdata and so forth, until it reaches a parent that the receiver already has.

Since Bitcoin Core 0.10, nodes will respond to an inv with a getheaders, to retrieve all block headers between a point the receiver already has and the announced tip. The request contains a list of recent block hashes the receiver has to avoid duplicating things. Only when the receiver has all the headers, and has validated them, it will start asking for the full blocks that are missing along the way. This permits fetching blocks from multiple peers in parallel.

Since the adding support for BIP130 ("sendheaders") in Bitcoin Core 0.12, announcements of new blocks themselves are done by immediately sending the headers, avoiding an inv + getheaders step.

Since adding support for BIP152 ("compact blocks") in Bitcoin Core 0.13, blocks can also be announced (in negotiated cases) without any inv or headers message at all, instead sending a compact block directly (which uses an encoding that avoids transactions the receiver is assumed to already have). In case there are missing transactions, or parent blocks, those are requested using the normal means (getdata or getheaders).

Note that all mechanisms are still available for all nodes on the network. The more modern ones are generally superior, but older or simpler software implementations can still use the inv/getdata approach if desired.


text:
Is it possible to import a `wallet.dat` in Electrum?
I ran into an error when trying to import a wallet.dat into Electrum. I run Kali Linux.
Here is a screenshot of the error i get.

Does this answer your question? Electrum wallat.dat

A wallet.dat file is most likely a wallet database created by the Bitcoin Core wallet. It is specific to the Bitcoin Core wallet, you won't be able to open it using Electrum.

Thank you very much for answering my question

This wallet.dat file is from bitcoin core wallet. You will have to decrypt the wallet.dat file with your password. That file contains private keys which you will be able to use to import funds to electrum wallet (private keys, not wallet.dat). You cannot import wallet.dat into electrum wallet because Electrum does not support this file type.


text:
Why is there a block size limit and why not increasing it?
Storage costs are now ridiculously smaller than they were when the limit was introduced more than 10 years ago. I am concerned keeping this arbitrary limit set by Satoshi could be holding us back.
Why do we still have a 1MiB block limit?

What are the arguments for and against the increase of the block size limit?

A block size limit is necessary to avoid a trivial DOS vector. See this answer for some explanations. But from the body of your question it rather seems you are asking why the limit isn't increased.
First of all we should ask the obvious: what for? Such a change comes at the tremendous cost of a hard fork: there is nobody in charge of Bitcoin to say "starting tomorrow blocks can be twice as large". Therefore the upsides of the increase should at least compensate for the cost of a hardfork. I'm not aware of any upside to an increase in the block size limit which i would consider meet this bar.
In addition, there is more costs to a block size increase than the sole use of a hard fork:

It would proportionally increase the maximum rate at which the UTxO set can be bloated.
It would increase blocks propagation time, most likely leading to further mining pool centralization (see this and this answers for details).
It would increase the barrier to entry for running a fully-validating node.

There is also more subjective objections to increasing the block size, which i don't think even need to be considered in this context. These include for instance uncertainty about miners' revenue in a low- or post-subsidy world. Or the fact that fiddling with the block size is tweaking the market for block space which is a can of worms in itself (what is the right value? If it's modified once and some, potentially unrelated, bad things happen there will be a lot of pressure to modify it again).
In conclusion, i believe the block size was never explicitly increased through a hard fork because it does not pass a technical risks/benefits analysis. And the technical community members did not yield to the huge amount of pressure that was once put on them to disregard the costs. At the end of the day, Bitcoin is a system in which all full participants validate, store and broadcast all the onchain transactions of every single other participant. This obviously cannot scale (only) by increasing the number of onchain transactions each participant can make.

Because throughout 2012-2015, after Satoshi Nakamoto disappeared, "no hard-forking upgrades" became a de facto social rule of the Bitcoin network (BTC) so old non-upgraded nodes won't become stranded on upgrades.
This is why SegWit was the only possible way to increase TPS capacity without breaking UTXO view for old nodes (further increase via soft-forking would only be possible through extension blocks, which would break UTXO view for old nodes).
The other de facto social rule is that node running should be as widely accessible as possible. Thanks to increases in bandwidth and propagation tech such as compact block relay block size limit could be higher without much risk of pool centralization (8 MB should be manageable today and wouldn't 8x the risk of centralization). However, it would mean that bandwidth-limited nodes couldn't keep up or would take too long for initial block download.
The Bitcoin network kept the limit low for this reason as well, and current stewardship of the project maintains that decision.
Bitcoin code is free open-source (MIT license) and anyone can fork the code and change the limit for himself.
However, he can't force others to accept the changed rules by running such software.
What happens if he manages to convince only a subset of the network to run patched node software?
A permanent hard fork, and then the forked network has to convince the social / markets layer to give it value, and use the value to bid for mining hashes.
We have seen this play out with main forks of Bitcoin.
See also here for a brief history of the blocksize limit, and here and here for a timeline of events that led to the first permanent fork of Bitcoin.
Note that "Nakamoto Consensus" doesn't decide which blockchain wins the branding / ticker. It is market & social forces which map blockchains to recognized currencies.

Actually, the block size limit is no longer 1MB. That changed with the big segWit soft fork. Currently, block size is measured in virtual bytes, not bytes. The current block limit in virtual bytes is 4(v)MB. Looking at the "real" bytes, those 4v(MB) could go to around 3,8MB. However, the average is slightly less than 2MB.
Therefore, the block size has been increased from 1MB.
Here you can see the size of each block together will other related information (purple-blue chain/blocks).
Block #813485 is interesting since it's size is 3.82MB.

While this answer correctly challenges the framing and explains how the blocksize was increased, it could be improved by elaborating on why there is a limit in the first place.


text:
What is "(mempool) policy"?
In answers concerning validity or propagation of transactions as well as topics surrounding consensus, people frequently mention "policy" or sometimes "mempool policy".

What do people mean when they mention "policy" or "mempool policy"?
How is that related to (non-)standard transactions and transaction validity?

Standardness refers to a stricter set of rules enforced by full nodes on a transaction in addition to the consensus rules. Policy is an even broader set of rules or processes followed by a node. Contrary to standardness it is not local to a single transaction nor is it specific to validation rules.
Taken broadly, policy is everything that is not consensus. The set of rules dictating whether a block is valid is consensus. All the rest: how the block is relayed, whether a cache of unconfirmed transactions was used to speed up its transmission and validation or how unconfirmed transactions are propagated through the network is policy. For example:

A transaction is invalid by Bitcoin consensus if the sum of the value of its outputs is larger than the sum of the value of its inputs. (In other words, its fee is less than 0.)
A transaction is invalid by Bitcoin Core standardness rules if it has a fee lower than 1sat/vbyte.
Sending an unconfirmed transaction which has 25 or more unconfirmed ancestors violates Bitcoin Core policy rules.

Mempool policy is the set of rules describing the validity of a transaction from the point of view of a node's mempool. Probably the biggest difference with standardness is that it is contextual. An unconfirmed transaction may well be valid according to standardness (and therefore consensus) but still be refused by a node's mempool. The ancestor rule from above is one such example.
The mempool isn't however the only area where policy rules apply. For instance, transaction relay is another. For instance, the maximum number of transactions a node will request or announce per peer is often referred to as policy.
Finally, while policy may vary from a node to each other not all rules are equally important. A node for instance may choose to not store and relay unconfirmed transactions which store data in OP_RETURN outputs, or not store and relay unconfirmed transactions at all, and still be part of the network. But you can think of any stupid policy a node may have (for instance only finding peers and/or relaying blocks through its own custom protocol), in which case it would hardly even keep up with the network although it does implement all consensus rules. And there is every degree in-between, with the corresponding expectations one may have about the network.

Note this is an attempt at an answer; terminology is notoriously confusing in Bitcoin and people may have a different view of what "policy" represents. It's just the definition i've been using (without ever spelling it out, so thanks for the question) and found useful when discussing related matters with other Bitcoin developers.

How about a partial answer?  It appears the answer I was looking for is in the code! :-)
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/amount.h
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/validation.h
I'm still confused as to how policy is not consensus when there are policy checks in the consensus validation checks, tho...
TX_INPUTS_NOT_STANDARD,   //!< inputs (covered by txid) failed policy rules
TX_NOT_STANDARD,          //!< otherwise didn't meet our local policy rules
TX_MEMPOOL_POLICY,        //!< violated mempool's fee/size/descendant/RBF/etc limits
TX_RECONSIDERABLE,        //!< fails some policy, but might be acceptable if submitted in a (different) package

But I won't ask anymore questions until I ponder more.  :)


text:
How create coinbase transaction with createrawtransaction?
I would like to generate a transaction with createrawtransaction such that it can be passed to submitblock along with the block header.
I tried to use:
[{"txid":"0000000000000000000000000000000000000000000000000000000000000000","vout":0}]{"bc1qd8hza5w3mz7t3tudtlplm9xht4sjwg0e3t9gy2":6.25000000}

but it's not outputting a coinbase transaction:
020000000100000000000000000000000000000000000000000000000000000000000000000000000000ffffffff0140be40250000000016001469ee2ed1d1d8bcb8af8d5fc3fd94d75d612721f900000000

How is that not a coinbase? The null input is the key characteristic.

i was test it with fresh blockchain with 100% valid block , with  markle root from this tx , submitblock was no accept it and say "Block does not start with a coinbase (code -22)"

there are also other coinbase rules as well such as bip34 height in scriptSig.

ok, but how add them for make coinbase valid for submit  block ?  a dont see any other rules at createrawtransaction help.

Oh I see one more thing -- the vout for coinbase input should be 0xffffffff not 0

yes , and how do this no answers , maybe it imposible do at console .
but if avaliable command submitblock and submitheader, most exist somting for create coinbase tx.

You're so close, just try "vout": 4294967295 instead of 0

to not work , it say's our of range...

It is not possible to create a coinbase transaction using createrawtransaction. There are numerous rules that coinbase transactions must follow that the createrawtransaction RPC does not have the ability to set the fields to meet those rules. For example, BIP 34 requires the coinbase contain the block's height in the scriptSig. However createrawtransaction does not allow you to set the anything in the scriptSig.
Miners must use software that can independently create the coinbase transaction. Miners actually prefer doing this because they want to be able to modify the coinbase to use as an extra nonce so that when they run out of nonces, they don't necessarily have to re-select the transactions to include in the block. Instead they can change the coinbase to cause the merkle root to change.

According to BIP 34, you must include the block Height to your Coinbase transaction, otherwise, it will be invalid,
The scryptSig of your coinbase transaction, must begin with number of pushed bytes (Actually is 0x03) and then the hex representation of your candidate block, dont forget the little endian conversion

I recommend looking over this code in python which will illustrate how the coinbase is constructed, it is the simplest example I can think of, and is commented well - https://github.com/vsergeev/ntgbtminer/blob/master/ntgbtminer.py#L166


text:
First Bitcoin transaction
When making your first bitcoin transaction, at what time do you generate the public and private keys and how do you store your private key on a hardware wallet?

at what time do you generate the public and private keys

Your wallet (the software managing your keys and your connection to the Bitcoin network) handles this for you, typically just before you generate an address to receive a payment.

how do you store your private key on a hardware wallet

The hardware wallet comes with a software which handles the storage of the key(s) on the hardware.
You might want to take a look to the wiki page about "storing bitcoins" and follow the links :).


text:
Do I have to open port 8333 for incoming connections?
Just wondering if I can still have valid transactions without accepting incoming connections.
Example:
I am working on a Windows-To-Go drive that has my Bitcoin Core on it.
Sometimes I will be unable to open that port. Will I have any problems sending or receiving
transactions?

No, you will not have any problems receiving, sending, or validating transactions.
The only difference is that all your connections willl be made by your node, from your node to others. There won't be any connections from others to you.
Enabling listening is a service you can choose to provide to the network, and clearly, some people need to enable it or nobody could make connections. But it doesn't affect your personal ability to interact with the network in other ways.

OK  Thank you!  Good to know


text:
How do descriptors work with miniscript in the library bitcoinerLab?
What I want is to be able to spend the funds from an address, either with its private key or with the private key of another address that I designate in the policy.
As I understand it, it works like this:
When using the descriptor, it provides an address where the miniscript is stored, which tells me how the UTXOs associated with that address can be spent.
Then, if I want to spend the UTXOs associated with that address, I have to create a transaction with PSBT where I need to create the same descriptor that I made when generating the address that I explained earlier, and sign it with a private key, either that of the address itself or the other one designated in the policy, thus allowing me to spend the funds from the other address.
This is the reasoning that I have, but I think it is incorrect. Therefore, I have the following questions:
How do descriptors work? I know more or less what they are, but I don't know how they work programmatically, that is, how to use them to unlock an output that has a descriptor and a miniscript in it, from a new transaction that I create.
I am attaching a small code snippet that we are developing. Specifically in CODE 1, I don't understand how the signersPubKey parameter works:
const wshDescriptor = new Descriptor({
    expression: wshExpression,
    network,
    signersPubKeys: [EMERGENCY_RECOVERY ? emergencyPair.publicKey : unvaultKey]
  });

The first code is how to create an address with the spending conditions that you can see in the policy POLICY =`or(pk(@emergencyKey),and(pk(@unvaultKey),after(20)))`;
The second code shows how we make a transaction that unlocks the funds from the previous address.
The CODE 2, we can see signersPubKey again. We are reaching the conclusion that in the first CODE, when generating the address, the descriptor that we create with signersPubKey, SignersPubKey doesn't really do anything, and in the second CODE, when signing the transaction, the descriptor really uses the signersPubKey parameter, but we are not sure.
This is what the GitHub page of the descriptor library that we are using says about SignersPubKey, but we don't fully understand it:
      “The last part to explain from the code block above is that when a descriptor has multiple spending paths, the user needs to set which one to use. This is done by passing the public keys that will be used to sign the transaction using the variable signersPubKeys. The corresponding unlocking script (the script witness, in this case) will be computed later from this      information when finalizing the transaction. Note that in order to test different configurations, you can set EMERGENCY_RECOVERY variable to true or false back and forth.”

Therefore, how does the SignersPubKey field work when creating an address through the descriptor, and how does it also work when creating the transaction?
CODE 1, to create an address with miniscript
import { Psbt, networks } from 'bitcoinjs-lib';
import * as ecpair from "ecpair";
import * as secp from "tiny-secp256k1";
const ECPair = ecpair.ECPairFactory(secp);
import * as fs from 'fs';
import * as secp256k1 from '@bitcoinerlab/secp256k1';
import * as descriptors from '@bitcoinerlab/descriptors';
import { compilePolicy } from '@bitcoinerlab/miniscript';
import { generateMnemonic, mnemonicToSeedSync } from 'bip39';

const { Descriptor, BIP32, ECPair2 } = descriptors.DescriptorsFactory(secp256k1);

let unvaultMnemonic;
const EMERGENCY_RECOVERY=true;
const network = networks.testnet;
const POLICY =`or(pk(@emergencyKey),and(pk(@unvaultKey),after(20)))`;
const WSH_ORIGIN_PATH = `/69420'/1'/0'`;
const WSH_KEY_PATH = `/0/0`;

var emergencyPair = ECPair.makeRandom();
console.log(`emergencyPair WIF: ${emergencyPair.toWIF()}`);

unvaultMnemonic = generateMnemonic();
console.log(`unvaultMnemonic: ${unvaultMnemonic}`);

const unvaultMasterNode = BIP32.fromSeed(mnemonicToSeedSync(unvaultMnemonic),network);
console.log(`unvaultMasterNode WIF: ${unvaultMasterNode.toWIF()}`);

const { miniscript, issane } = compilePolicy(POLICY);
console.log(`miniscript: ${miniscript}`);

const unvaultKey = unvaultMasterNode.derivePath(`m${WSH_ORIGIN_PATH}${WSH_KEY_PATH}`).publicKey;
const unvaultKeyBase64 = unvaultKey.toString('base64');
console.log(`unvaultKey BASE 64: ${unvaultKeyBase64}`);

const wshExpression = `wsh(${miniscript
    .replace(
      '@unvaultKey',
      descriptors.keyExpressionBIP32({
        masterNode: unvaultMasterNode,
        originPath: WSH_ORIGIN_PATH,
        keyPath: WSH_KEY_PATH
      })
    )
    .replace('@emergencyKey', emergencyPair.publicKey.toString('hex'))})`;

console.log(`wshExpression: ${wshExpression}`);

const wshDescriptor = new Descriptor({
    expression: wshExpression,
    network,
    signersPubKeys: [EMERGENCY_RECOVERY ? emergencyPair.publicKey : unvaultKey]
  });

console.log("wshDescriptor: "+wshDescriptor);
const wshAddress = wshDescriptor.getAddress();
console.log(`address: ${wshAddress}`)

const data = [`adress: ${wshAddress}`,`emergencyPair WIF: ${emergencyPair.toWIF()}`,`unvaultMnemonic: ${unvaultMnemonic}`,`unvaultKey: ${unvaultKeyBase64}`, `wshExpression: ${wshExpression}`];

try {
  fs.writeFileSync("info_address.txt", data.join('\n'));
  console.log(`\n//////////// Se ha guardado en el fichero los siguientes datos ////////////\n\n${data.join('\n')} `);
} catch (err) {
  console.error(err);
}

CODE 2, to create a transaction that spend the balance of the previous address
import { Psbt, networks } from 'bitcoinjs-lib';
import * as ecpair from "ecpair";
import * as secp from "tiny-secp256k1";
const ECPair = ecpair.ECPairFactory(secp);
import * as fs from 'fs';
import * as secp256k1 from '@bitcoinerlab/secp256k1';
import * as descriptors from '@bitcoinerlab/descriptors';

const { Descriptor, BIP32, ECPair2 } = descriptors.DescriptorsFactory(secp256k1);
const toAddress='n12kEsK3LnqvYFMTdMvzAXbb8JtF6qcDSP'
const network = networks.testnet;
const EMERGENCY_RECOVERY = true;
const EXPLORER = 'https://blockstream.info/testnet';

// Leer los datos del fichero
const data = fs.readFileSync("info_address.txt", { encoding: 'utf-8' });

// Analizar los datos y extraer los valores
const lines = data.split('\n');
const wshAddress = lines[0].split(': ')[1];
const emergencyPairWIF = lines[1].split(': ')[1];
const unvaultMnemonic = lines[2].split(': ')[1];
const unvaultKeyBase64 = lines[3].split(': ')[1];
const wshExpression = lines[4].split(': ')[1];

// Convertir los valores a los tipos originales
const emergencyPair = ECPair.fromWIF(emergencyPairWIF);
const unvaultKey = Buffer.from(unvaultKeyBase64, 'base64');

console.log('wshAddress:', wshAddress);
console.log('emergencyPair:', emergencyPair);
console.log('unvaultMnemonic:', unvaultMnemonic);
console.log('unvaultKey BASE 64:', unvaultKey.toString('base64'));
console.log('wshExpression:', wshExpression);
const unvaultMasterNode = BIP32.fromSeed(mnemonicToSeedSync(unvaultMnemonic),network);

// // Busca el utxo a gastar
const utxo = await (
  await fetch(`${EXPLORER}/api/address/${wshAddress}/utxo`)
).json();

if (utxo?.[0]) {
    const txHex = await (
    await fetch(`${EXPLORER}/api/tx/${utxo?.[0].txid}/hex`)
  ).text();
  const inputValue = utxo[0].value;

  const psbt = new Psbt({ network });

  const wshDescriptor = new Descriptor({
    expression: wshExpression,
    network,
    signersPubKeys: [EMERGENCY_RECOVERY ? emergencyPair.publicKey : unvaultKey]
  });

  wshDescriptor.updatePsbt({ psbt, txHex, vout: utxo[0].vout });

  psbt.addOutput({
    address: EMERGENCY_RECOVERY
      ?  toAddress
      : 'tb1q4280xax2lt0u5a5s9hd4easuvzalm8v9ege9ge',
    value: inputValue - 1000
  });

  //Now sign the PSBT
  if (EMERGENCY_RECOVERY)
    descriptors.signers.signECPair({ psbt, ecpair: emergencyPair });
  else descriptors.signers.signBIP32({ psbt, masterNode: unvaultMasterNode });

  //Finalize the tx (compute & add the scriptWitness) & push to the blockchain
  wshDescriptor.finalizePsbtInput({ index: 0, psbt });
  const spendTx = psbt.extractTransaction();
  const spendTxPushResult = await (
    await fetch(`${EXPLORER}/api/tx`, {
      method: 'POST',
      body: spendTx.toHex()
    })
  ).text();
  console.log(`Pushing: ${spendTx.toHex()}`);
  console.log(`Tx pushed with result: ${spendTxPushResult}`);

}

Hey, i'd be glad to answer this question. But "how do descriptors work" is too broad. It looks like you are stuck at using the satisfier? Could you break up your question about how descriptors work into several more focused ones? Also please copy code snippets instead of pasting screenshots.

I`ve already corrected, thanks

Author of the library mentioned in the OP here. I've updated the signersPubKeys parameter documentation on GitHub & site for better clarity. Check out the updated docs. If you had issues understanding just that parameter, let me summarize: signersPubKeys is an array of the public keys used for signing the transaction when spending the output associated with a descriptor. This parameter is only required if the descriptor object is being used to finalize a transaction. It is necessary to specify the spending path when working with miniscript-based expressions that have multiple spending paths.

@landabaso In the last case that you mentioned, I dont understand : Leave it undefined if you only need to generate the
scriptPubKey or address for a descriptor, or if all
the public keys involved in the descriptor will sign the
transaction. In the latter case, the satisfier will
automatically choose the most optimal spending path in terms
of tx size (if more than one path is available).

Update [2023-Nov-15]: This answer has been updated to reflect the changes in v2 of the library.
As the author of the @bitcoinerlab/descriptors library, I'd like to provide some clarification on the usage of the Output class and the signersPubKeys parameter.
Bitcoinerlab's descriptors module can be used for several things, all involving the creation of a Output class instance. From the code you provided:
const wshOutput = new Output({
    descriptor: wshDescriptor,
    network,
    signersPubKeys
  });

Let's first check what signersPubKeys is in the docs:

  signersPubKeys // (Optional): An array of the public keys used for signing
                 // the transaction when spending the output associated with
                 // this descriptor. This parameter is only used if the
                 // descriptor object is being used to finalize a transaction.
                 // It is necessary to specify the spending path when working
                 // with miniscript-based expressions that have multiple
                 // spending paths. Set this parameter to an array containing
                 // the public keys involved in the desired spending path.
                 // Leave it `undefined` if you only need to generate the
                 // `scriptPubKey` or `address` for a descriptor, or if all
                 // the public keys involved in the descriptor will sign the
                 // transaction. In the latter case, the satisfier will
                 // automatically choose the most optimal spending path in terms
                 // of tx size (if more than one path is available).

As per the docs, signersPubKeys is optional and only required when you want to spend from a specific spending branch. Let's break down the different cases for further clarity:
Receiving bitcoin
If you want to receive Bitcoin locked by a specific policy (specified in a miniscript), you'll need to generate an address or scriptPubKey. To do this, you don't need to pass signersPubKeys to the constructor:
const wshOutput = new Output({
    descriptor: wshDescriptor,
    network
  });
const address = wshOutput.getAddress();
const scriptPubKey = wshOutput.getScriptPubKey();

Spending bitcoin from a miniscript-based descriptor
Assuming you've received Bitcoin to a UTXO you control, you can use the library to spend it. This is where signersPubKeys may or may not be necessary:
Single spending branch UTXO
If there's only one spending branch, you don't need to pass signersPubKeys. The satisfier will use the provided signatures and build the script witness for the unique branch.
Multiple spending branches UTXO
For multiple spending paths, different possibilities arise. Let's consider the policy from your post:
POLICY =`or(pk(@emergencyKey),and(pk(@unvaultKey),after(20)))`;

If you can (and will) sign with both @emergencyKey and @unvaultKey, and the timelock has been released, you don't need to pass signersPubKeys. The satisfier will pick the most optimal solution in terms of tx size and discard the unused signature.
Now, consider a different scenario. Suppose you can only sign with @emergencyKey, or you can sign with both keys but have decided to use the emergency path to avoid waiting for the timelock.
In such cases, you need to pass signersPubKeys: [emergencyPubKey] and then sign with @emergencyKey. This ensures that the spending transaction is created with the desired unlocking script.
This information is indeed used in a couple of places within the code you provided:
// `signersPubKeys` is used internally here to set the appropriate
// `nLockTime` and `nSequence` for the transaction (the psbt below):
const finalizer = wshOutput.updatePsbtAsInput({ psbt, txHex, vout: utxo[0].vout });

// `signersPubKeys` is used internally here to generate
// the appropriate script witness for the input:
finalizer({ psbt });

In summary, the signersPubKeys parameter is essential when working with miniscript-based descriptors that have multiple spending paths, and you want to specify a particular path. Depending on your use case, you may or may not need to include this parameter.

Now I understand all, It is a very nice explication, thanks!!

Thank you, this has been very helpful


text:
Terminology on what do hardware wallets actually store?
Going by the BIP39 standard, it seems that what is stored is the seed (lets call it A). But what is confusing is that people elsewhere seem to be conflating the mnemonic (the 24 or 12 word list, lets call this B) with the seed, while BIP39 appears to say that the seed (A) is derived from the mnemonic (B) by PBKDF2, which is one-way, so they are not the same thing. I always thought the mnemonic is the seed, and the thing that is derived from the mnemonic (seed) is a master private key, and it's the master private key that is stored on the hardware wallet.
In this context, is it correct that

hardware wallets store A?

A is derivable from B, but going the other way is not possible?

can A be called a private key, or is it just some binary value of appropriate length?
I guess one could argue that for some asymmetric key algorithms any value with correct length will do as key, but lets add the condition that it would need to be used for signing or decryption: i.e is A ever used for signing or decryption?

hardware wallets store A?

Yes. It wouldn't make sense to do the 2048 rounds of hashing (HMAC-SHA512) between the mnemonic (B) and the seed (A) every time you want to derive child keys or create a signature.

A is derivable from B, but going the other way is not possible?

Indeed, hash functions are one way and this hash function is applied 2048 times.

can A be called a private key, or is it just some binary value of appropriate length?

A must be kept private as all funds from the HD wallet (from all the various child public keys) can be spent with knowledge of the seed. It is 512 bits and could be represented in any format including binary.

What is a good term to call A (e.g a seed, root, key, or a secret)? What would a cryptographer call it?

@CigaretteSmokingMan: Seed seems most common. Definitely not key or secret given how many keys and secrets are dotted around a HD tree. Sometimes for non-technical audience seed and mnemonic are used interchangeably as from a user perspective they just need to worry about the securing the mnemonic from which the seed can be calculated e.g. the tag here on StackExchange is mnemonic-seed.

Thanks, all this makes it a lot clearer!