text:
Cache the Bitcoin Datadir to Improve Performance? Increase Bitcoin DB Cache Size?
Bitcoin is very disk-intensive and that slows it down. It seems to flush data to disk often thus preventing proper caching. With the datadir on a RAMdisk it is much faster.
Is it possible to increase the db cache size or do something else to improve cache performance.
Of course it would be nice to keep the wallet and important data saved but I would not mind the blockchain to be heavily cached.
I'm asking mainly about Windows OS.

It's not really clear what you're asking. Very disk intensive when? During startup? When downloading the block chain? When processing GUI requests? The OS should already be caching all disk data that it can fit in memory anyway.

A getnewaddress took 20 secs or so...   I reduced virtual memory and changed the cache settings to "server" - not sure if it did anything but it is much faster now. Will close the question.

That was likely because you have it set to create several hundred addresses when it runs out. It didn't take as long after that because it was giving you the addresses it had pre-generated.

Hmm I tested it at least five times and it always took so long.

The very recently released bitcoin v0.6.0 has modified bdb cache settings (25 megabytes by default), and provides a way to change this via the command-line option -dbcache=N, with N a number in megabytes.
This change caused a very significant speedup for synchronizing the block chain indeed.

Can setting the number of MB assigned to the cache to be greater than the number of MB of RAM of the machine further increase the speed of syncing? E.g. Would setting the cache at 2500 MB (instead of 2000 MB) on my laptop that has only 2GB of RAM increase the speed of syncing?

@JerzyBrzóska That is a very bad idea. You can set it higher, but at that point your system will either run out of memory and kill things, or it will start using swap space which will cause far more slowdown than just using a smaller cache.

Bitcoin (through BerkleyDB) frequently flushes writes to disc to main transaction integrity in wallet.dat and the blockchain databases. The operating system can cache the entire blockchain normally,
I have restarted Bitcoin several times and had it start instantly because the entire blockchain is already cached by the OS.

for the record:
file DB_CONFIG:
set_lg_dir database
set_lk_max_locks 120000
set_cachesize 2 524288000 1
--> 2.5GB cache
http://docs.oracle.com/cd/E17076_02/html/api_reference/C/set_cachesize_parameter.html
For versions higher v0.6 Pieter's way sure is better. This still could be useful for older versions.
Unfortunately I can't get it to work with Namecoin 3.50


text:
Where can I find a list of reliable Bitcoin full nodes?
I already know about this list  but it does not seem to be reliable or even up-to-date. Is there any other place where I can find a better list?

Best place is https://getaddr.bitnodes.io/nodes/leaderboard/
Nodes are rank according to various parameters

A list of reliable nodes is inherently a trusted list. Therefore a reasonably trustable place to get some node IPs would be by hitting the DNS seeds hardcoded in the reference client.
The list is community-curated, contains multiple sources, and the seeds are themselves dynamically managed. This makes it more resistant to censorship than a single website link.
As of now, there are 9 hardcoded DNS seeds:
seed.bitcoin.sipa.be // Pieter Wuille
dnsseed.bluematt.me // Matt Corallo
dnsseed.bitcoin.dashjr.org // Luke Dashjr
seed.bitcoinstats.com // Christian Decker
seed.bitcoin.jonasschnelli.ch // Jonas Schnelli
seed.btc.petertodd.org // Peter Todd
seed.bitcoin.sprovoost.nl // Sjors Provoost
dnsseed.emzy.de // Stephan Oeste
seed.bitcoin.wiz.biz; // Jason Maurice

An easy way to get a list of IPs from them is by using the dig utility:
$ dig -t A dnsseed.emzy.de

; <<>> DiG 9.16.8-Debian <<>> -t A dnsseed.emzy.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39289
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 26, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;dnsseed.emzy.de.       IN  A

;; ANSWER SECTION:
dnsseed.emzy.de.    3600    IN  A   116.202.196.182
dnsseed.emzy.de.    3600    IN  A   121.147.241.223
dnsseed.emzy.de.    3600    IN  A   47.198.209.213
dnsseed.emzy.de.    3600    IN  A   188.134.74.188
dnsseed.emzy.de.    3600    IN  A   51.161.36.145
dnsseed.emzy.de.    3600    IN  A   35.180.187.229
dnsseed.emzy.de.    3600    IN  A   5.61.50.213
dnsseed.emzy.de.    3600    IN  A   79.98.31.253
dnsseed.emzy.de.    3600    IN  A   45.151.125.218
dnsseed.emzy.de.    3600    IN  A   15.161.90.31
dnsseed.emzy.de.    3600    IN  A   216.8.188.217
dnsseed.emzy.de.    3600    IN  A   34.82.27.114
dnsseed.emzy.de.    3600    IN  A   42.148.150.79
dnsseed.emzy.de.    3600    IN  A   157.245.140.86
dnsseed.emzy.de.    3600    IN  A   108.7.205.58
dnsseed.emzy.de.    3600    IN  A   49.247.215.43
dnsseed.emzy.de.    3600    IN  A   101.162.90.21
dnsseed.emzy.de.    3600    IN  A   151.48.99.212
dnsseed.emzy.de.    3600    IN  A   24.21.229.157
dnsseed.emzy.de.    3600    IN  A   101.179.1.53
dnsseed.emzy.de.    3600    IN  A   202.184.0.102
dnsseed.emzy.de.    3600    IN  A   138.68.14.104
dnsseed.emzy.de.    3600    IN  A   54.217.186.6
dnsseed.emzy.de.    3600    IN  A   144.76.138.23
dnsseed.emzy.de.    3600    IN  A   84.67.126.130
dnsseed.emzy.de.    3600    IN  A   87.9.136.5

As a last resort you can also find a list of hardcoded IPs in the Bitcoin-Core project, updated before each release (roughly every ~6 months).

source: Stack Exchange

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

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

sort: votes


text:
The order of the generator point G used in bitcoin
Hi I was just wondering how the order of the generator point G used in bitcoin was actually calculated.
From the specification listed http://www.secg.org/SEC2-Ver-1.0.pdf for secp256k1 I can see listed is the generator point G along with its order, however I am unsure how this was actually calculated.
In one of the books I was looking through it was mentioned that Hasse's Theorem was used to calculate this value, however upon looking up this theorem this seems to only provide a bound. Any insight would be appreicated thanks :)

What you're looking for is Schoof's algorithm.

It's easy to verify the order (n):  Multiply G by n and find that you get the point at infinity. This proves that n is either the order or a multiple of it. Then convince yourself n is prime using a Baillie-PSW primality test, so it must be the order itself and not a multiple of it.
Finding the order is not quite so simple as verifying it. To do so you would use Schoof's_algorithm, which requires quite a bit of number-theory complexity. The Wikipedia article on Schoof's explains how Hasse's theorem is critical to this process by restricting the range of orders that could possibly be the correct one.

The order of G is the number of time you will have to add G to get a point at infinity. You start at G, then add G you get 2G. If you add G a total of n times, you will get a point at infinity. This order n will tell you how many times you can add G before you reach infinity or how many distinct points are there on the curve.

While correct, this is not how the number of points on the curve is computed (counting to 2^256 is rather infeasible).

True. I tried to provide more of a qualitative commentary around that.

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


text:
What to do when a website says that my bc1... address is invalid?
 I used local Bitcoins wallet to send bitcoin to my bitcoin wallet. But it said wrong address

What wallet software or app or device did you use to generate the bc1 address?  There may be a setting to have it generate a "legacy" address instead, starting with 1 or 3.

The address that you are using starts with bc1 and is a bech32 address. Many online wallets still do not support this form of address, which is the reason you are getting the invalid Bitcoin address error. If you want to use segwit and still be compatible with these online wallets that do not support bech32, you can use a P2SH(P2WPKH) addresses that begin with 3.

Ugam Kamat ,Thanks but can you help me how to change the address?

@RehemaOlonya which wallet software are you using to generate the bc1 address?

@UgamKamat is right. You need to either pass a legacy address "1..." or a segwit compatible one "3...". If your wallet has the capability to generate native segwit address "bc1..." I'm sure you could get what you want!

@Ugamkamat I used my Android phone to download bitcoin wallet. When I downloaded the address came automatically

@RehemaOlonya ok, but which software did you use? Mycelium?

Bitcoin. Com is what I used

Ok, because it's important as your wallet should be segwit aware to spend bitcoins that are sent to P2SH(P2WPKH) addresses that begin with 3. You cannot generate one on the fly on anywebsite and import that address in any other wallet. You can do that only if you have the private key associated with the address.

@RehemaOlonya I'm still unsure how you got the bc1 address from bitcoin.com wallet. I have confirmed that they do not support native segwit addresses.


text:
Why can't I bumpfee the 25th tx in an unconfirmed chain?
I have a chain of 25 unconfirmed transactions. There's a default mempool limit of 25 chained unconfirmed transactions, so my change output of the 25th transaction is not usable until some of the transactions have confirmed.
To make it confirm, I thought I'd bumpfee the last (25th) tx.
$ bitcoin-cli bumpfee <txid> '{"fee_rate": 410}'
error code: -4
error message:
Unable to create transaction. Transaction has too long of a mempool chain

Why do I get this error? I'm not making the chain longer, I'm just trying to replace the last tx.

In the mempool validation logic, the maximum chain size checks are performed without first removing the transaction to be replaced. That is, if there is a chain of 25 unconfirmed transactions such as:
txA <-- txB <-- txC <-- ... <-- txY

And a candidate for replacing txY (txY') is submitted, the mempool limits will be checked with the following topology:
txA <-- txB <-- txC <-- ... <-- txY
                            \-- txY'

txA will therefore fail the descendants count limit check (since it's now 26, accounting for itself) [0].
The wallet logic when creating a transaction (not only for fee bumps) mimics this logic (1, 2). This is why the bumpfee command for the 25th transaction in an unconfirmed chain fails.

[0]: This ignores the RBF carveout for simplicity.

Ok, thanks. What's the rationale for this behavior? What's the risk of allowing the replacement?

I wasn't around when it was introduced, but thinking through how one would make this change seems like a lot of hassle for little gain. It could however be documented as it's an interface for external softwares.

The gain would be that I can get my 25 stuck transactions unstuck. A workaround for this issue is to avoid creating the 25th tx in the first place, to save it fee-bumps so to speak.


text:
Connect C-lightning to a remote bitcoind through tor
I would like to connect my C-lightning node to a remote Bitcoin node, in order to be able to run lightningd on a small storage capacity VPS.
I could achieve this by using clearnet connection and wanted to know if would be possible to proxy the connection through the Tor network ?

Yes but not by default.
C-lightning uses a pluggable Bitcoin backend. The default one, bcli, will use the bitcoin-cli executable to make requests to a bitcoind.
It exposes bitcoin-cli's rpcconnect startup option to lightningd which does not not support onion hosts. And you probably don't want it to as it is not meant to be exposed.
If you want to run C-lightning without having the full block chain locally you'd probably opt for a light backend solution, such as:

A pruned bitcoind (beware of misconfiguration)
An explorer-backed backend.
For example, the Sauron plugin which you could connect to an external
Esplora instance you would run on a machine with more space. It supports onion services.

If you really want to remotely access bitcoind's RPC, you should probably opt for an SSH tunnel.

Thank you. I will check the prune parameter for bitcoind and also a plugin c-lightning-pruning-plugin


text:
Inner working of OP_IF and OP_ELSE
How does OP_ELSE work exactly? Is there an else if in Script?

According to https://en.bitcoin.it/wiki/Script#Flow_control, the statements after an OP_ELSE are executed in three cases. It says:

If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are.

I'd like to understand how the 3rd case works, i.e. when there's a preceding OP_ELSE that is not followed. Consider this script and a True at the top of the stack:
OP_IF
    <foo>
OP_ELSE
    <bar>
OP_ELSE
    <baz>
OP_ENDIF

If we follow the explanation of the quote to the letter, then that means that <foo> and <baz> are executed. This however is quite counter-intuitive. If this is the case, then the second OP_ELSE is redundant, as <baz> can simply go after <foo> to the same effect and with less opcodes.
Is there some other interpretation I'm missing?
I stumbled upon this detail while trying to write a script with 3 different branches, something like
OP_IF top stack item is 0
    <foo>
OP_ELSEIF top stack item is 1
   <bar>
OP_ELSE
   <baz>
OP_ENDIF

I know the above isn't valid Script, but can something to this effect be achieved without resorting to the following?
OP_IF
    <foo>
OP_ELSE
    OP_IF
        <bar>
    OP_ELSE
        <baz>
    OP_ENDIF
OP_ENDIF

Note that this is more expensive not only because it has more opcodes, but because two stack items are needed in the witness in order to execute <bar> or <baz>.

Inner working of conditionals in Bitcoin Script
The conditionals in Bitcoin Script are conceptually implemented using a stack of booleans, each boolean indicating whether to execute the current opcode when iterating through the Script for each depth of the conditional (nested IF / ELSE).
To grasp the functioning, let's first consider a single-boolean conditioned execution of opcodes. The interpreter will iterate through the Script by setting the boolean to true (do execute ops) at the beginning. When encountering an IF it will set the boolean to the value of the pushed data preceding the IF, casted to a boolean (CastToBool in the reference implementation).
If this was true it will continue the execution of the following opcodes, effectively executing "the if {} branch".
If it was false, it will suspend execution until .... It encounters an ELSE! Encountering an ELSE will toggle the global boolean suspending execution. If it was previously false, it will become true and effectively execute "the else {} branch".  To the contrary if it was true, it will become false and suspend execution of "the else {} branch".
With a bit of ASCII art (fExec is the global boolean telling whether to actually execute the OPs):
Value of fExec:  true    true      true         true  true    true         false      false            ???

Script        : |start| OP_BLABLA OP_DOSOMETHING <1> OP_IF OP_DOSOMESTUFF OP_ELSE OP_DOANOTHERSTUFF OP_ENDIF

Value of fExec:  true    true      true         true  false    false       true      true             ???

Script        : |start| OP_BLABLA OP_DOSOMETHING <0> OP_IF OP_DOSOMESTUFF OP_ELSE OP_DOANOTHERSTUFF OP_ENDIF

Note how i marked the value of fExec as ??? when encountering OP_ENDIF. That's because the real implementation is slightly more complicated: in order to support nested conditionals, this is not a single boolean but a vector of booleans that are used to determine execution. That is:

OP_IF will push a new boolean to the vector
OP_ELSE will toggle the last boolean of the vector
OP_ENDIF will pop the last element of the vector

Going further
Multiple ELSE for a single IF
Note that the implementation of the ELSE being a single toggle it means that nothing prevents to toggle two times in a row. That is, you can have many following ELSE opcodes before the ENDIF. Two following ELSEs would effectively toggle the last boolean twice, hence executing the following opcodes as it would for "the if {} branch".
Therefore in the example from your question:
OP_IF <foo> OP_ELSE <bar> OP_ELSE <baz> OP_ENDIF

That's indeed <foo> and <baz> that will be executed.
Quadratic behaviour when computing fExec from the vector of booleans
The implementation of the conditional logic was modified in 2020 by Pieter Wuille to fix a quadratic behaviour found by Segio Demian Lerner.
Therefore the actual implementation does not actually use a stack for the booleans anymore, rather it stores the "top boolean" in a dedicated data structure imitating the previous implementation.
Slightly related Tapscript rule
The proposed new addition to the Script rules as part of the proposed Taproot soft fork (Tapscript) lifts the limit of 201 OP codes. This was made possible by the elimination of the aforementioned quadratic behaviour.

IIUC, the behavior of multiple OP_ELSE for a single OP_IF is indeed the "redundant" one described in the question, correct? And there is no OP_ELSEIF equivalent?

Yes, i edited the answer to precisely answer your example :)


text:
Electrum: display redeem script of a P2SH utxo
I use Electrum with a multisig wallet. I would like to figure out how to prove ownership of a "coin".
I understand that I need to share the whole redeem script so that it's hash can be verified against the UTXO I want to prove ownership off. And then I need to sign a message using at least N of M (as defined when creating the multisig wallets) private keys corresponding to the public keys in the redeem script.
My question is how can I display the redeem script in Electrum, in a human readable way that allows to clearly identify N, M and all of the public keys?
How can I display the data structure encoding the redeem script on the blockchain, whose hash constitutes the ps2h address (without spending the UTXO)?

Good question. For the future, i hope wallets will implement lifting Bitcoin Scripts to Miniscript policy: they allow a more natural sight over spending condition (see http://bitcoin.sipa.be/miniscript/) . In the meanwhile i don't have an answer to your question but i think the title should be "how to display the redeemScript on Electrum", feel free to revert the EDIT if i'm wrong!

I understand. But I'm willing to accept answers that involve using external tools other than Electrum, as long as it is reasonably achievable by a non-programmer. For instance if Electrum can somehow display the redeem script in a binary/hex format, and there is an external tool to decode it, I'm interested.

I did not find a good answer, so I coded a small GUI to perform signatures using private keys, verify a signature using a public key (or an address) and verify a p2sh M-of-N multisig script against a list of N public keys and the parameter M.
This information is easy to find with a simple right click on an address in Electrum (View Details).
https://github.com/PiRK/signverify
I made it primarily for BCHA, but it works for BTC if you paste a legacy p2sh address instead of a CashAddr.


text:
C++ code for traverse though all the blocks in blockchain?
In my project for one particular functionality, I want to traverse through all the Transactions. For that purpose I want to traverse through all the blocks in blockchain.

If you are intent on doing it with c++, there is a blockchain parsing library that may help you here https://code.google.com/p/blockchain/.
Depending on your application, though, I might recommend just writing a terminal script to use the daemon. It probably won't be as fast, but I bet it would be easier to get up quickly. These commands can be called to get you the info you need:

// Gets the block at index index
./bitcoin-cli getblockhash {index}

// Gets the block using the result of the first statement
./bitcoind-cli getblock {hash}

// The block has an array of transactions in it
for (Tx tx : block.tx) {
    ./bitcoind-cli getrawtransaction {tx} 1
}

What language is that? Or is it pseudocode?

Oh, and you have to use ./bitcoin-cli now.

Pseudo code. Yeah, you're right, I'll change.

Also make sure you enable txindex=1 in your bitcoin.conf and run build the transaction index (bitcoind -reindex) before you iterate all (=also non-wallet) transactions.

Thank you very much for the answer. It is really helpful Stephen. By the way, Is there any method to retrieve the last index of the block received? If so it would be helpful for me to run a for loop to get all the blockhashes.

Glad it helped! you probably want to do something like while $(./bitcoin-cli getblockhash(i)) != null,error, because the best block when you start running this code won't be the best block when you finish running it. If you just want the height of your blockchain, look in $(./bitcoin-cli getinfo)

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


text:
Transaction was rejected - Bitcoin QT, recovered wallet.dat
I recently installed a new version of Windows on a new HDD, but I'm having problems getting my old wallet.dat to work.
Here's what I've done:

Install latest Bitcoin Core.
Copied over the blocks and chainstate folders from the old hard drive.
Run Bitcoin Core and allowed it to sync up to date.
Closed Bitcoin Core
Removed Wallet.dat from my roaming\Bitcoin folder
Copied Wallet.dat from old HDD to the roaming\Bitcoin folder
Run Bitcoin Core with '-rescan' parameter.

When I run the software, I get the following message:

Warning: Wallet.dat corrupt, data salvaged! Original wallet.dat saved as wallet.{timestamp}.bak in C:\blah\de\blah

There's nothing wrong with the old HDD, or the previous wallet. In fact I could boot up the previous Windows install, but it's a ballache for various reasons involving symlinks and other such non-standard tomfoolary.
On subsequent runs, I receive the following message:

Warning: error reading wallet.dat! All keys read correctly but transaction data or address book entries might be missing or incorrect.

So now I can see my coins in the wallet, and my transaction history - it looks like it's worked, except I can't spend any of the coins. I get a message stating:

The transaction was rejected! This might happen if some of the coins in your wallet were already spent, such as if yuo used a copy of wallet.dat and coins were spent in the copy but not marked as spent here.

I've not made any use of the wallet since installing my new version of Windows, it's all up to date on the old HDD... so I can't see how it would be listing coins that have already been spent... but the start up message suggests that tansactions are missing from my history, so perhaps I have less than I think?
Can anyone shed light onto why this process hasn't worked?
Thanks.

Could you try looking at one of your balances on a block explorer like blockchain.info? It sounds like either the wallet changed without your knowledge, or your coins were spent without your knowledge.

Not sure I really understand how to do that... How do I get the balance addresses from the software, and wouldn't the balance be split across multiple addresses?

Also, that doesn't explain the 'corruption' messages.

So I had to fire up the OS on the old HD and run an older version of Bitcoin code - lo and behold, no problems with the wallet at all. Transferred balance to another address, installed new Bitcoin core and generated a new wallet.dat.
None of this fills me with confidence for long term storage of my coins!!


text:
Sum of block values not zero?
Take for e.g. block 163440. The amount paid out in the coinbase transaction is not reward+fees. Does the network not require blocks to have a sum of zero for all transactions + block reward? Confusingly blockchain.com reported 50 BTC to be minted. In this case this is not correct right?

The amount paid out in the coinbase transaction is not reward+fees.

The link you shared shows

Input Value   3,067.86 BTC
Output Value  3,117.80 BTC

The difference ought to be the reward claimed by the miner in the coinbase transaction, but the difference is only 49.94
It also shows

Minted 50.00 BTC
Reward 50.05750000 BTC

So it does seem there is a discrepancy.
I compared it with https://blockchair.com/bitcoin/block/163440

Input total  3,067.86 BTC
Fee total        0.0575 BTC
Generation      49.94 BTC
Output total 3,117.80BTC

Note the difference between this explorer's Generation and blockchain.com's Minted.
It shows the output for the coinbase transaction as 50 BTC.
So I suspect the miner forgot to claim the transaction fees and only claimed the mining reward for the block.
I believe the explorers wrongly interpret this as the miner having claimed 0.0575 BTC in fees and under-claimed approximately 49.94 BTC as a mining reward for the block. Blockchain.com shows 50 as "Minted" - which is an inconsistency in its presentation. It shows the total reward that could have been claimed, not what was actually claimed.
This under-claiming of rewards is within the Bitcoin rules, the miner cannot claim more than block-reward plus transaction fees but they can claim less.

You’re right, the “minted” value looks misleading in this context. It seems that it actually contains the “allowed amount to be created” rather than the amount of new bitcoins that were actually created by the block.

Generally, the sum of output values on a transaction must be equal or smaller than the sum of input values. The difference between input values and output values is referred to as the transaction fee:
Σ(inputs) – Σ(outputs) = transaction_fee

The exception to this rule is the coinbase transaction.  The coinbase transaction is the only transaction that can have a bigger output than input. It does not spend a UTXO in its input, but it may collect the mining reward in its outputs. The mining reward is composed of the block subsidy and transaction fees. The block subsidy depends on the block height and the transaction fees depend on the transactions included in the block:
reward ≤ ⌊5×10^9 × 0.5^(⌊block_height/210,000⌋)⌋ + Σ(tx_fees)

That means that generally the sum of outputs of transactions in a block will exceed its inputs by the block subsidy. However, a block is still valid if the miner collects less than the allowed amount— the unassigned rest is simply lost forever.
Beside the block that you are looking at, miners collected less than allowed on more than 1000 blocks already, see the answer on this question for a few examples: Will there be 21 million bitcoins eventually?


text:
How to create SegWit address from mnemonic in Python 3.8.10
I am having trouble creating SegWit address from mnemonic. I can't find any useful code to do that. I tried using BitcoinLib but I don't know how to disable saving wallets to disk.
EDIT:
I found solution that I was looking for. It now shows correct wallet on TrustWallet and on my PC. I used cryptotools libary. Here is the code:
from cryptotools.BTC import Xprv
m = Xprv.from_mnemonic('... mnemonic ...')
print((m/84./0./0./0/0).address('P2WPKH'))

check out https://github.com/mcdallas/cryptotools

thanks, will check it out and let you know if it worked.

Fixed, thank you so much

@cloudzik: If you answered your own question can you post an answer rather than answering it in the question? Thanks

import cryptotools

# Set up the mnemonic and derivation path
mnemonic = "your mnemonic goes here"
path = "m/0'"

# Derive the private key and public key from the mnemonic and path
private_key = cryptotools.bip32.master_key(mnemonic.encode())
derived_private_key = private_key / path
public_key = derived_private_key.public_key()

# Generate the SegWit address from the public key
segwit_address = cryptotools.bech32.encode("bc", 0, cryptotools.hash160(public_key.to_bytes()))

print(segwit_address)

Note that this code assumes that you have already installed the cryptotools library using pip. Also, make sure to replace "your mnemonic goes here" with your actual mnemonic phrase, and "m/0'" with the actual derivation path you want to use.
As for disabling wallet saving in BitcoinLib, you can set the BitcoinSecret.Saving property to false to prevent the wallet from being saved to disk. Here is an example code snippet:
BitcoinSecret secret = new BitcoinSecret("your private key goes here");
secret.Saving = false;

Again, replace "your private key goes here" with your actual private key. This code assumes that you have already installed and imported the NBitcoin library, which BitcoinLib is based on.

Stop using ChatGPT, ill report this.


text:
How Wallet Mobile Softwares deal with Wallet Balance and Transaction history?
I'm trying to build a mobile software Wallet made in Flutter with a Bitcoin Core Full node that communicates with a  Node.js backend.
The problem I can't find the answer to is: how can wallet softwares keep up all the incoming transactions from potentially thousands of addresses?
I wouldn't really like to rely on any third party APIs like blockchain.com but in the other hand Bitcoin Core and bitcoin-cli don't allow me to check transactions starting from an addresses other than the ones from manually imported wallets (which would be clearly impractical from a software that is expected to work fast, with multiple HD wallets and mostly of all, where I don't have to store the private key other than the user device.).
So, how do wallets work in this regard? Do they rely on a third party and if so, how are those parties able to work as well as (for example) blockchain.com? What am I missing?
If the solution is to import into BC all the wallets created via Dart, is there a way to manage thousands of users in one or more Bitcoin Core nodes ensuring 100% security and speed?
Thank you to everyone that provides as many details as possible.

Read about key derivation, hierarchical determinism, addresses lookahead... You are supposed to not rely trust on a third party.

I was able to find an answer which for me was Electrum Server and similar (for example ElectrumX).
I wasn't aware at first of the existence of softwares able to analyze blockchain and provide many informations like UTXOs and transaction history starting from data provided by the Bitcoin Node.
Here's the link for electrumX:
https://github.com/spesmilo/electrumx
I want to link also this website that helped me a lot:
https://bitcoin.design/
Please be aware that many software like this exist and I haven't tested extensively any of them.
So please Do not trust, verify, always.


text:
OP_LSHIFT & OP_RSHIFT purpose & functionality
What is the purpose & functionalities of the LSHIFT & RSHIFT Script OP codes ?

In the early versions of bitcoin the software used the openssl bignumber lib to perform left and right shift.
E.g. Look at script.cpp in v0.2.13
For example, The OP_LSHIFT (L595) uses bignum.h (L503) and openssl/bn.h to define << operator and ends up at this definition of lshift:
https://github.com/openssl/openssl/blob/1c0eede9827b0962f1d752fa4ab5d436fa039da4/crypto/bn/bn_shift.c#L104
It seems they were disabled in response to a DoS security concern:
https://en.bitcoin.it/wiki/Incidents#CVE-2010-5137

For all intents and purposes, Bitcoin has no such opcodes.
Very early versions of Bitcoin's reference implementation did, until version 0.3.10 (August 2010) when they were disabled together with a number of other opcodes. New opcodes with identical functionality could be re-introduced now with a softfork, but the fact that similar opcodes existed historically wouldn't make that any easier (or harder) - they'd just be new opcodes.
As for what they did: they implemented an operation similar to the >>= and <<= C/C++ style operators, multiplying and dividing by a specified power of two.


text:
How do I create a taproot multisig address requiring 21 of 210 keys to spend?
I understand that prior to taproot activation, m-of-n multisig addresses had an "n" max limit of 20 keys. I also saw the 998/999 tapscript multisig transaction that recently caused issues with LND, so this tells me that the 20 max key limit may no longer be in play.
If this is correct, how can I create a multisig address using 210 keys, and requiring 21 of them to spend?
I'd like to do this using nothing other than Bitcoin Core 0.22 QT Console and a text editor (I use notepad++).
Right now I use this command to create a multisig address in the QT Console
createmultisig mKeysRequired "[\"pubKey1\",\"pubKey2\",\"pubKey3\",...]"

What would be the proper format to allow me to create a tapscript 21/210 multisig address?
Thanks!

This will be possible in the upcoming Bitcoin Core 24.0 release, using RPCs like deriveaddresses and importdescriptors, which take as input specifications in the output descriptor language.
RPCs like createmultisig, addmultisigaddress, etc. only work in the older legacy wallets. Since version 0.21.0 a new type of wallets, called descriptor wallets, are supported by Bitcoin Core. These new wallets operate around the descriptor language, which precisely describes which addresses/outputs belong to the wallet.
In the descriptor language, for example one can write:

pkh(PUBKEY) for a traditional P2PKH single-key output
sh(multi(2,PUBKEY1,PUBKEY2,PUBKEY3)) for P2SH-embedded 2-of-3 multisig over the provided keys.
sh(wsh(multi(1,PUBKEY1,PUBKEY2)) for P2SH-embedded P2WSH with 1-of-2 multisig in it.

In Bitcoin Core 22.0 support was added for tr() in the descriptor language, though without multisig support (as the OP_CHECKMULTISIG opcode which the multi() descriptor language feature maps to does not exist in taproot scripts). In the upcoming Bitcoin Core 24.0 release, multi_a is added which works like multi(), but using a taproot-compatible script. It supports up to 999 keys. The way to use it would be:

tr(KI,multi_a(21,K1,K2,K3,K4,...,K210))

where KI is the internal public key you want to use (which will need to be unspendable unless you want it to implement an (1-of-1)-or-(21-of-210) policy. BIP341 gives an example of an unspendable key, namely 50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0. K1 through K210 would be the public keys you want to use. They can be in 66-character hexadecimal notation (starting with 02 or 03), 64-character hexadecimal notation (for x-only pubkeys), or xpubs or xprvs. See the linked document above for more details.

Thank you very much for this answer! I was able to use 24.0rc2 to create a quick 2-of-3 taproot multisig address, by following your directions.
Now I am trying to spend from the address, but I don't know how to sign the transaction.
For a normal miltisig, I use this command to sign the multisig raw tx hex.
signrawtransactionwithkey "hexstring" ["privatekey",...] '[{"txid":"hex","vout":n,"scriptPubKey":"hex","redeemScript":"hex"}]'
But when I created the address I didn't get a redeemScript. I tried to sign w/o it and got;
"error": "Witness program was passed an empty witness"

You need to use PSBT RPCs for everything related to descriptor wallets, and certainly taproot. They supplant the raw transaction RPCs.

Your solution worked perfectly, thanks. Now I have a question about your reply. Can you please explain why the unspendable key must be used UNLESS I want it to implement a 1-of-1 or 21-210 policy? (and what is the other option? 1 of 210?)

If the inner public key were spendable, whoever knows it would be able to make a P2TR keypath spend using the inner public key and the hash of the taptree. Thus, the policy would be either keypath or scriptpath, i.e. 1-of-1 or 21-of-210. This can be sidestepped by explicitly making the inner public key unspendable.


text:
Clarifications on hd multisig wallet
I need clarification on multisig hd wallets. Let's imagine we have a 2/3 multisig. The first key is generated by the user on a mobile wallet, the second is kept on a server while the third is off-line (for emergencies). In an hd wallet the seed is generated from the seed phrase and, from this, the Master Private Key.

How does the generation of the other 2 Master Keys happen?

What do these keys share?

When new private keys are generated by the user are new keys derived also on the server?

Private keys are simply 256bit random numbers. A seed phrase is simply a different way to generate 256bits of randomness in a more human-readable way.
So, to answer your questions

How does the generation of the other 2 Master Keys happen?

You need to securely generate a 256bit random number. This can be done in software.  You can also generate them in a HSM.  Regardless, for a secure, multi-sig setup, these keys must be generated on different machines, and ideally using different random number generation schemes.

What do these keys share?

For your example, they should share nothing.  The user's key and the service/backup keys should be as independent as possible, and hopefully never be active on the same machine.

When new private keys are generated by the user are new keys derived also on the server?

Each master private key must be kept on separate machines, otherwise, you're nullifying most of your multi-signature benefits.  Derivations using the private key should only be done when as needed for signing, and the derivations must be independent for each key.
Derivation of the public key can be done on any machine (it's public information).  This can help with generating derived multi-sig addresses that can be computed anywhere.

So the generations happen independently. Do they work as if they were independent wallets? I don't understand how they can agree to sign a transaction.

HD is really about back-ups and wallet recovery, a multisig address can be created from any public keys regardless how/where they were generated. Heck you could use the same public key 3 times, although I wouldn't recommend it I'm just trying to prove a point.
To answer your exact questions:

How does the generation of the other 2 Master Keys happen?

Do you want 2 more master keys, or do you just think you need them? Additional master seeds are not necessary, but if you want more master keys then create additional HD seeds.

What do these keys share?

The master keys? They shouldn't share anything, again not relevant to creating a multisig address.

When new private keys are generated by the user are new keys derived
also on the server?

Private keys are not needed to create a multisig address, just the public keys. If you only want one HD seed to back-up, then use different accounts for each key pair. By accounts I'm referring to the derivation path, for example Account 1 Index 0: m/0/0/0/0, Account 2 Index 0: m/0/0/1/0, Account 3 Index 0: m/0/0/2/0, this would produce 3 key pairs, all with an index of 0 and the public key of each would be used to create the multisig address.


text:
Linking libsecp256k1 as shared library to Bitcoin Core
I'm not sure if this question is better suited in the context of Autotools, but since it's about Bitcoin Core, I'll try to ask it here.
I am trying to Compile/Link libsecp256k1 as a shared library with Bitcoin Core.
configure.ac is calling configure of libsecp256k1 but just removing "-disable-shared" isn't engough
https://github.com/bitcoin/bitcoin/blob/7ff64311bee570874c4f0dfa18f518552188df08/configure.ac#L1637
And here it looks like it is static compiling.
https://github.com/bitcoin/bitcoin/blob/7ff64311bee570874c4f0dfa18f518552188df08/src/Makefile.am#L61
Could someone point out to me if this is even possible in a simple way and if so how.
Thanks a lot

Why on earth would you want to be dynamic linking a security and safety critical library?

It is not a productive system!
But even if it were a productive system.
Isn't it obscurity rather than security.
I suspect the reason was optimization
of course a LD_PRELOAD or similar would be possible.
But then we are talking about a deeper system level security problem
and such a system is the wrong place for your coins in the first place.
But I am open to other points of view.

No, the reason why Bitcoin Core is distributed as a static binary is due to security concerns, not "security by obscurity". What we've seen in the past is that many distributions of packages tend to be providing hilariously outdated versions of core libraries like OpenSSL, which for a time was consensus critical. Two versions of Bitcoin Core that are otherwise identical could become out of sync with one another just due to minor changes within its dependent libraries.

The only reason for dynamic dependencies in software at all is for space saving, which is not a consideration today with the size of modern storage, and the fact that the several megabyte bitcoind binary will probably be downloading 300GB of data shortly after installation.

Ok I get the point, but this could be fixed with rpath and a separate directories.
Anyway. I just wanted to benchmark different modifications.
Without recompiling the whole thing by swapping symlinks :)

There's inbuilt benchmarking for libsecp256k1, but be aware that it's not the purpose of the library to be fast for signing or key generation. There's many functions which are made intentionally, seemingly arbitrarily slow to avoid secret dependent memory accesses and other secret leaks through timing.


text:
Trust in bitcoin networking
I am new to the subject, but as I was studying I wasn't able to understand something and I would appreciate if anyone could help me.
I understand that in most aspects bitcoin doesn't rely on trusting the nodes. It's in the best interest of each node to validate and append blocks broadcasted by other miners, so we can assume that the nodes will do it. It's in the best interest of each node to validate the transactions they put in a block, otherwise it will be rejected. But why do nodes gain in propagating the transactions they receive? If that's not how it works, how is the transaction poll created?

There is a distinction between miners and nodes though miners will (or at least should) run a full node to check that the blocks they are attempting to mine are valid blocks. I think you are using the terms "miner" and "node" interchangeably here. There are many nodes (majority) on the network that just validate transactions and blocks and don't attempt to mine blocks.

Why do nodes gain in propagating the transactions they receive?

Full nodes and miners want to receive information on the latest transactions and blocks from peers. And hence effective propagation relies on software that can both send and receive this information. In theory the software could be altered to only receive and not send. But if this became a serious problem on the network some nodes could choose to only maintain connections with nodes that are both sending and receiving and the "selfish" nodes might struggle to maintain connections with peers.

The nodes run software which contains the best-for-everybody rules about how the network should operate. One of those rules is that nodes should forward new transactions to other nodes.
There is no incentive for them that I know of, other than, to not do so, would risk not participating in the network of nodes that do follow the best-for-everybody rules. By not participating, they are spending their own resources without being able to participate in the network's rewards.
And as another commenter mentioned, they would be made to not participate, because the nodes that are following the rules would eventually ignore them.

Mining bitcoin is based on game theory. Play by the rules and get financially rewarded. Selfish miners risk not making a profit and damaging the coin's reputation. And alternative node software gets squeezed out by the majority because nodes/miners follow the longest chain. Not sure if this answers your question?


text:
What is payment batching?
How does Bitcoin transaction batching work exactly?  How does this end up looking compared to a regular block of a bunch of transactions?  Also, I have read people claim batching causes weaker privacy, how is this exactly?

How does Bitcoin transaction batching work exactly?

Instead of paying multiple people using a new transaction for each person, you make one transaction that pays those multiple people.
For example, suppose you need to pay 3 people. Instead of making 3 different transactions with one output each, you make one transaction with 3 outputs to the 3 people you are paying.

How does this end up looking compared to a regular block of a bunch of transactions?

It is cheaper partially because each transaction has a fixed amount of overhead. By batching transactions, you only have to pay for the overhead once, not multiple times. Furthermore, usually each transaction will have a change output, and many times that change output must be spent again in the next transaction. This means that if you are sending to 3 people, you are creating 3 change outputs, and 2 inputs that have to spend from a change output. By batching, you only need to make one change output and you don't need to have those 2 additional inputs that spend the change. Those effectively cancel out and are thus removed from the transaction.
In a normal case with paying 3 people:
Input 1 -> Person 1
        -> Change 1 -> Spend Change 1 -> Person 2
                                      -> Change 2 -> Spend Change 2 -> Person 3
                                                                    -> Change 3

By batching:
Input 1 -> Person 1
        -> Person 2
        -> Person 3
        -> Change 3

So you have cut out Change 1 and 2, and Spend Change 1 and 2 which means you are paying less transaction fees.

Also, I have read people claim batching causes weaker privacy, how is this exactly?

All of the people being paid in a batched transaction can see who else you are paying and how much. However it is hard for observers to also know the true identities of those people.


text:
Difference between PoW and BFT
What is the difference PoW algorithms (as used in Bitcoind) and BFT (used for instance in Libra) ?

They really don't have any similarities, so I'm not sure that there's much point in comparing them or talking about their differences. If you understand what PoW is and what it does and you understand BFT algorithms and what they do, there's no much else to know.
Both algorithms are algorithms designed to get eventual agreement on how to make forward progress in systems that can make forward progress in more than one valid way where agreement on which way to go forward is needed for the system to be useful.
PoW algorithms are slow and expensive and don't provide any actual finality but eventually provide practical finality. They're vulnerable to majority attacks and require honest participants to actually spend, on a continuous basis, to protect the network more than any attacker is willing to spend to harm it.
PoW algorithms are dangerous on blockchains that have non-native tokens. For example, Ethereum's security comes from PoW and the value of its native token, Eth. But it also has an ERC-20 ecosystem of non-native tokens. Things get scary if the value of Eth doesn't remain high enough to keep this ecosystem secure. Ethereum is a secure platform to build DeFi on so long as all these DeFi projects together don't get too valuable for Eth to secure.
BFT algorithms are fast and cheap and can provide actual finality. You get to choose who you trust, rather than having to trust whoever has money and cheap power as you have to do with PoW algorithms.
One very important thing to understand about Libra is that it cannot possibly ever be decentralized. Whatever legal entities control the assets that back Libra are parties without which the Libra currency will lose its value. That means that for any proposed hard fork, those custodians get to decide which side of the fork keeps the economic value. Because any rules change can be imposed by a hard fork, that means that the custodians get to choose the rules, period. That means no real decentralization ever, period.
Suppose, for example, that someone proposes adding respect for a government-provided censorship list to Libra. If the custodians say that they will issue and redeem on the censorship side of the hard fork, then that's it. The censorship wins, and it doesn't matter what anyone else wants or says. The censorship side of the fork will have the backing which is what gives Libra its value. By design, Libra cannot ever possibly be decentralized so long as it is backed.

I very much like this answer, but perhaps one additional important distinction: in BFT solutions the participants need to have identities that are known to other participants. PoW is designed to work without prior knowledge of who may be participating (implying you can participate anonymously).

@PieterWuille They don't. Since they can't double spend, it's perfectly fine to just choose anyone anonymous (by public key) that appears to be operating properly. If you choose people who don't let the network make censorship-free forward progress, you can just change who you chose. It is true, though, that PoW can be used to do the initial distribution of a cryptocurrency while BFT algorithms really can't. If the network makes censorship-free forward progress, and the "participants" can't double spend or censor, then it doesn't matter who "participates". (You often can't even tell!)

Well that still requires some pseudonymous identity at least, with public keys as identifiers, and participants need to choose to accept these keys. In PoW, you cannot distinguish whether two attempted updates were created by the same party or not.

If you're talking about BFT where everyone is assumed to just accept any key that shows up until they show signs of misbehaviour, I expect you'll end up with trivial DoS attacks - something PoW doesn't suffer from.

@PieterWuille No. I'm talking about BFT where you and the people you want to do business with agree on a set of keys that appear to be behaving reliably. It's like letting three companies in China choose which transactions go in which blocks except you pick those three companies, don't pay them millions of dollars a day, and can easily change them if they censor. And you don't have to wait an hour. ;)

@DavidSchwartz That's a perfectly reasonable choice, but it involves identity!

@PieterWuille If you consider an arbitrary public key an identity even if you can't map it to any real world person or entity. No identities are needed for that process other than public keys.

If you're going to use it to associate a reputation with, yes.

@PieterWuille Then I would argue that using demonstration of SHA256 hashing power as a way to get trust is identity as well. You are associating a reputation with the majority holder of the hashing power. I think it's a vacuous use of the concept of identity.

@PieterWuille For example, say at some defined day we chose the public keys with the lowest SHA256 hashes, rejecting any that misbehave and keeping any that behave properly. It's PoW for setup, but then BFT from then on. Is that identity because we use a public key? I don't think you can make this meaningful.

Perhaps identity is a confusing term then. Howabout permissionlessness vs DoS protection? A system where operators need to make a choice what keys to accept is clearly not permissionless. One where this choice is made automatically based on apparent-good behavior is trivially vulnerable to DoS. PoW allows combining DoS resistance with permissionlessness. I don't see a way in which BFT can do that.

Let us continue this discussion in chat.


text:
How does total cost of mining affect the price of coins?
The goal of this question is to explore what the correlation is between the cost of the total energy consumption behind a PoW-based cryptocurrency and its price.
Obviously, the cost of mining cannot be lower (in the long run) than the price of the coin, because more and more miners would join.
But is the converse (empirically) also true?
Has the price of coins been historically bounded from below by the cost of mining?
Of course, the cost of mining is hard to compute, because of differences in hardware, electricity price and cryptojacking.
Yet, one can find some nice charts here about Bitcoin, so some estimates can be made.
Has anyone looked at this?
For example, the market cap of Bitcoin is about twice the market cap of Ethereum.
Is it true that about twice as much energy is/has been spent on Bitcoin than on Ethereum?

I was just thinking about this today and created this spreadsheet to model my question.

Welcome to Bitcoin.SE! Your answer is good but can be improved if you are able to source some empirical data to use as your basis, or at least find some referencable sources.


text:
Bitcoin Core Old Wallet.dat Vulnerability
Own a wallet.dat file from 2010-2011. Yesterday I saw there was a vulnerability which is makes attacking somewhat easier if your wallet is generated by old client and I'm pretty sure my wallet is affected that vulnerability because my last transaction is made 2010.
So my problem is I don't have any idea about wallet passphrase. Maybe the vulnerability helps to open my wallet. It is about AES padded encryption. But i don't have enough cryptographic knowledge to handle it. I'm aware it is brute force task but the vulnerability decreases time of task.
I hope that someone can create a brute force tool for me which is using the vulnerability, so that I can recover my wallet.
Github Report about vulnerability : https://github.com/bitcoin/bitcoin/commit/c682cdf3eda0f55297eb0e72a04508b7b9c2f5df
VulDB report : https://vuldb.com/?id.4883

The vulnerability affects the encryption of the wallet file, weakening the encryption by lowering the resources needed to brute force attack it.
Practically, this means if an attacker were to get a copy of your wallet.dat file, they would have an easier time brute force attacking it (ie. guessing your password would become a little easier), compared to an attack against a wallet.dat file using the same password, that is not affected by the vulnerability.
Any attack that exploits this vulnerability would have to be highly targeted, so for affected users the threat of attack is probably quite low. Perhaps ironically, by asking for help, you may draw attention to yourself as an affected user,  so I would be very wary of anyone offering a 'tool' to help you fix the issue!
I assume that your goal here is simply to ensure your bitcoins are secure. If you are concerned that someone may steal (of have already stolen) your encrypted wallet.dat file, a simple fix would be to create a new wallet using software of your choice, and then send the entire balance of the old wallet to the new one. This way, your new wallet file will not be affected by the vulnerability.

Hey, I altered the question. I don't remember my passphrase and thought it is helps to find it much faster due to vulnerability.

Ah okay, that changes the scope of the question substantially. Note that in general, it is against site rules to offer a reward for help. I do hope you are able to recover your wallet!


text:
Why does every "defi" thing only support garbagecoins and never Bitcoin?
I swear, I seriously feel like I've already gone insane and I can't even trust my senses at this point. I've been chewing through website after website listed as "defi", repeatedly finding the exact same thing:
Bitcoin is not supported, and they all want me to "connect my wallet" inside the browser.
What's with this? Why do they support 927 different garbagecoins I've never heard of (outside of these websites) but never Bitcoin (BTC)?
I honestly believe that all of those websites are made by the same entity, and that they are all some kind of elaborate scam. But what I can't figure out is why none of them even support Bitcoin -- the only real crypto currency.
What am I missing?

Bitcoin is pushing most use cases and applications to second layers (e.g Lightning, sidechains) because blockchains don't scale. Most "DeFi" apps use the blockchain for transactions, filling up blocks and raising onchain transaction fees. Development is easier if you assume blockchains scale and can stay decentralized as they scale (which they can't).
It is true that Ethereum's Solidity is more expressive than Bitcoin Script (allows for infinite loops etc) but you can still do a lot with Bitcoin Script. Ethereum has found a niche of making it very easy to issue tokens and selling them at vast prices. It is much harder to support an infinite number of tokens moving over say Lightning where channels are primarily denominated in Bitcoin.
There are some projects buildings "DeFi" like applications on Lightning e.g. discreet log contracts (DLCs) but it takes a lot longer to build if you actually want to keep it decentralized rather than merely labelling it "Decentralized" (De).

This is a very roundabout way of saying Bitcoin does not support DeFi by design (which is fine, it doesn't have to).

I don't think you've read my answer. DLCs would be deemed actual "DeFi" ie decentralized finance rather than fake DeFi (centralized or unscalable). You don't need infinite loops to write "smart contracts".

That's not what OP asked though. Sure, some sort of smart contract ability exists, but what the OP refers to as "DeFi", as defined by turing-complete tokens built atop of the Ethereum blockchain, is not supported by Bitcoin.

A specific example of a financial contract you can write in Ethereum (that you need Turing completeness for) that you can't with Bitcoin? I think you just deal in platitudes and buzzwords.

Atomic token swaps? Pegged stable coins? This isn't platitudes, it's the reality, Bitcoin does not cover all use cases that exist today in cryptocurrency.

Vitalik originally wanted to create the smart contract language on bitcoin, but decided to start from scratch due to the limitations on scripting at that time. lightningnetwork Rootstock and Polkadot are projects which attempt to port much of the smartcontract defi code too btc as a layer two

Bitcoin does not support the kind of turing-complete "smart contracts" (decentralized code) that DeFi projects typically require to function, hence these kind of projects are usually built on top of the Ethereum blockchain (which does support it) or other Ethereum-like projects.


text:
Missing Checksum error when importing multisig wallet via descriptor
I'm trying to import a multisig wallet on regtest, but getting a strange error. What am I doing wrong? I've tried it with xpubs, tpubs, and Vpubs (converted here) and get the same error for all.
Command:
bitcoin-cli -regtest importmulti '[{"desc": "wsh(multi(2,tpubDDgGUQsV9M7N5DD3WQmkqkq9UXkSvfHvyefNDx2b7KwmukE6FfuFk3JfncmjCNnG9scWcdz6MEeNPZXHArkGFuTXTsZNr4288ULxuTDjB6u/0/0/*,tpubDCDw2UcGohVP3rK8kPW8g9hwBojpwzYdjLxQ6AnnuRvThH7q1vwGneGAUkfZYqJo9eKFGzuP4WwaKsQkEqqnwLd1eT2CtpAKQispgxadHWB/0/0/*))", "range": [0,10], "watchonly":true, "timestamp":"now"}]'

Error:
[
  {
    "success": false,
    "error": {
      "code": -5,
      "message": "Missing checksum"
    }
  }
]

According to the documentation, some RPCs need a checksum. importmulti is one of those.
You can use getdescriptorinfo to add a checksum to an existing checksum-less one.

Thank you! We might want to update https://bitcoin.stackexchange.com/questions/86059/create-multisignature-wallet-from-xpub-keys-in-bitcoin-core/86077#86077 with a comment about this as well


text:
Which are considered not-for-public fields of the ones returned by getaddressinfo?
Create a new address in a descriptor wallet, then getaddressinfo - a result like the following is output:
{
  "result": {
    "address": "bc1qf...",
    "scriptPubKey": "00144f...",
    "ismine": true,
    "solvable": true,
    "desc": "wpkh([5ba92dac/84'/0'/0'/0/0]0321c...)#cp9v54cz",
    "parent_desc": "wpkh([5ba92dac/84'/0'/0']xpub.../0/*)#9udarq7y",
    "iswatchonly": false,
    "isscript": false,
    "iswitness": true,
    "witness_version": 0,
    "witness_program": "...",
    "pubkey": "...",
    "ischange": false,
    "timestamp": 1679913806,
    "hdkeypath": "m/84'/0'/0'/0/0",
    "hdseedid": "0000000000000000000000000000000000000000",
    "hdmasterfingerprint": "...",
    "labels": [
      ""
    ]
  },
  "error": null,
  "id": "getaddressinfo"
}

Which of all these fields are considered safe if accessed by the public, and which are not?

From a security perspective (i.e. could directly lead to loss of funds) the only thing you should be worried about are private keys or seeds that are used to generate private keys. There are no private keys or seeds in this output.
From a privacy perspective it is all data that isn't required to be public so you wouldn't choose to make it public. But if it was all leaked it wouldn't be a disaster and lead to loss of funds. Some fields (e.g. the address) are already public on the blockchain and others (e.g. part of the descriptor) is made public on the blockchain when you spend from the address.


text:
How can I access remote lightningd with pyln-client
I'm looking for a way to do python graph analytics on a local machine that can call a remote lightningd to get up to date nodes and edge data from the lightning node server.
How do I need to configure the node and setup lightningrpc from pyln-client to make this happen?
Thanks in advance

Does this answer your question? https://pypi.org/project/pyln-client/ What specific configuration are you unsure of?

c-lightning by itself does not expose it's RPC over the network. This is to avoid having to dictate what kind of authorization and authentication to use in order to provide access control.
There are however a couple of options that are easy to implement and will do what you want:

Implement a small proxy plugin that'll export the information you need over HTTP and then just retrieve that info from your analysis machine. It'd just take a couple of lines with pyln and flask for example and since there is not write access you're good to go.
Use socat to expose the RPC Unix socket over TCP and then use any JSON-RPC library you'd like. Simple, but may require a.bit of care since now your exposing read write access on an unauthenticated and unencrypted network connection.
Use an existing rpc proxy such as sparko to expose the RPC over whatever your favorite rpc protocol is.

In your case I'd go for the first option, since you're likely just using read only access and you can do some filtering and processing on the node reducing the amount of data that needs to be transferred.


text:
What does Bitcoin Core use port 8334 for?
Bitcoin Core listens on three ports, as can be seen by running the following command after it has started:

sudo netstat -tulpn | grep LISTEN

By default, the ports it listens on are:

8332 for the RPC client (i.e. bitcoin-cli)
8333 for bitcoin clients (other nodes who want to contact this node)
8334 for ????

Searching for information on port 8334 does not seem to turn up anything useful.
By observation, if the port is already bound to, it does not cause a fatal error. Bitcoin Core continues to start, although the debug.log shows the following:

Unable to bind to 127.0.0.1:8334 on this computer. Bitcoin Core is probably already running.

What does Bitcoin Core use port 8334 for?
Furthermore, other ports can be overridden using command-line arguments such as -rpcport=18332 and -port=18333 or similar configuration options in bitcoin.conf. How can Bitcoin Core be made to listen on a different port number than 8334 for whatever it uses that port for?

It is used for incoming Tor connections.
See here and here for more info.
You can use -bind=127.0.0.1:XXXX=onion to use port XXXX instead.


text:
Is there a limit on the number and size of script inputs when spending a script path in a P2TR transaction?
From BIP 341,

Spending using one of the scripts: A Taproot output can be spent by satisfying any of the scripts used in its construction. To do so, a witness stack consisting of the script's inputs, plus the script itself and the control block are necessary.

However, I don't see any mention of the limits in size or witness count explicitly. In BIP 342, following two resource limits are mentioned that are indirectly relevant (which weren't relaxed by the Taproot upgrade).

Stack + altstack element count limit: The existing limit of 1000 elements in the stack and altstack together after every executed opcode remains. It is extended to also apply to the size of initial stack.

Stack element size limit: The existing limit of maximum 520 bytes per stack element remains, both in the initial stack and in push opcodes.

Also, in BIP 341, on the section of Script Validation Rules, the last step is:

Execute the script, according to the applicable script rules[11], using the witness stack elements excluding the script s, the control block c, and the annex a if present, as initial stack. This implies that for the future leaf versions (non-0xC0) the execution must succeed.[12].

This means that only the script inputs are pushed to the stack during the script execution.
Does this all mean that there can be a maximum of 1000 script input items each with <=520 bytes, with a total limit of 520 KB? And since the limit on initial stack was added by Taproot, this means that Taproot actually reduced the limit compared to before Taproot, and pre-segwit P2SH transactions could have unlimited script inputs (limited by block size/transaction size limit).
If this is the case, something like the Ordinal Inscriptions did not need Taproot to pack the big amounts of data into a Bitcoin transaction. This conclusion doesn't sound correct, but I don't know what I'm missing. Could someone enlighten me?

Ordinals predate inscriptions by many months, and Taproot predates ordinals by many years.

@Mercedes Yes, but I'm trying to ask something entirely different. If someone wanted to pack <520 KB of data, could they do it with a different design than Ordinal Inscriptions, i.e. by using the rest of the witness rather than the script? With this alternative design, we can inscribe and reveal a piece of data using just one transaction, rather than two required by the Inscriptions.


text:
Raw Block data in Hexadecimals
Is there any Web API available for us to query Blockchain data in hex format?
The format should follow the standard (https://en.bitcoin.it/wiki/Block#Block_structure) structure rather than JSON.

What kind of API do you want? Do you mean API with your local Bitcoin Core or do you need web-API?
Have a look to http://webbtc.com/block/000000000000000001f942eb4bfa0aeccb6a14c268f4c72d5fff17270da771b9 (this is an example)
It is possible to download block as [json] / [hex] / [binary] there if you know the hash of the block
UPDATE (december'17):
block in raw hex example : https://blockchain.info/block/000000000000000000a7b4999c723ed9f308425708577c76827ade51062e135a?format=hex

At least webbtc is opensource, can set up own instance.

Blockchain Data API
https://www.blockchain.com/api/blockchain_api:

Single Block

https://blockchain.info/rawblock/$block_hash
You can also request the block to return in binary form (Hex encoded) using ?format=hex

Blockchair has this api available that currently works (in 2022) https://blockchair.com/api/docs#link_M31
Example for block 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
https://api.blockchair.com/bitcoin/raw/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
and see the raw_block field


text:
Can wider acceptance cause the value to fall?
I've noticed lately that more vendors/companies are accepting Bitcoin: Microsoft being one of the latest and largest.
As far as I can tell, though, these companies seem to (mostly) immediately convert the currency into "real" money at the current exchange rate, and the transaction is often only completed once your Bitcoins are sold.
Again as far as I can tell (with my limited knowledge of economics), this will increase the Supply of BTC on the open market (more coins being sold) without particularly increasing the Demand (people without BTC are likely to just pay cash, rather than going through the hassle of buying BTC with cash to use with the vendor)
Does this mean that as more companies accept BTC, the value will drop?

This isn't really a question, more of a discussion point, with no real right or wrong answer. What you have to bear in mind is that even though some companies may convert back to fiat, the consumer must have first acquired bitcoin, and that must occur before everything. Often people forget this point and only look at the conversion as affecting market price in a downward way, but that is balanced by the prior purchase.

Perhaps my question is "Is there any evidence to show this?", rather than "Is it a thing?" - and I'm not forgetting it, it's part of my original query: people seem to only spend BTC if they already have it either as an investment or from mining, people don't go out of their way to acquire it to make a purchase: ie they don't convert fiat to BTC and make a purchase, they just pay with fiat (note this isn't a "never", just that it seems to be the trend)

No there is no evidence one way or the other. This is pure speculation. People do go out of their way to get bitcoin.

Of course there's evidence one way or the other: whether it's known to be empirical or circumstantial evidence is a different question, but there is certainly a history of Bitcoin value and a way to find that value compared to Bitcoin adoption in large organisations. The question is speculative, for sure, but the answer need not be.

This should be taken for discussion on Reddit it is not a question for this forum.

There are no guidelines limiting Bitcoin.SE to technical questions. While this question might not be easy to answer definitely either way, arguments and expert opinions can be given on the points of the question. As with any other question, however, low-quality answers should be downvoted, flagged, and/or removed.

The point you bring up is fundamental to understanding how the bitcoin market operates.
The majority of companies that have grown quickly in the space help merchants accept bitcoin. As you mentioned, these merchants generally end up selling bitcoin for fiat currency. Companies that provide bitcoin payment processing have grown more quickly over the past year than consumer wallet companies (which help consumers purchase bitcoin). Consequently, the bitcoin price has experienced downward price pressure over the past year, since we find more market participants selling bitcoin than buying it.
As regulation and banking becomes more attainable for bitcoin businesses over the coming year, we should see consumer wallet companies grow, which would lead to more people buying bitcoin. Until then, expect to see continued downward pressure on the bitcoin price.
PS: I'm the CEO of bitcoin exchange Coinsetter.

Yes, you are right. I think situation can change if people start accepting payments for their work in bitcoins. Everyone interested in bitcoins should ask boss to get part (or whole) of his wage in bitcoins. It could make the market more balanced.


text:
I am trying to get cgminer on Ubuntu 14.04 and the Guide is troubling me
Okay, I am trying to follow this instruction guide:
http://www.distrogeeks.com/install-cgminer-3-7-2-ubuntu/
and the 20th step did not work because it could not find the server. I downloaded it from AMD themselves except not version 5.0, but version 6.0.
I go up to the 24th step and when I typed that in it said, "cp: target 'ADL_SDK/' is not a directory"
I then installed it and ran it, but then it gave me this message every few seconds or so:
"KnC spi: Can not open SPI device /dev/spidev1.0: No such file or directory.
Please help, I really want to mine some bitcoins and also the similar questions did not help.

It sounds like you were not in the right directory. Modify this if needed and see if it helps
cp /home/USER/include/* /home/USER/cgminer-3.7.2/ADL_SDK
Just replace USER with your username. If you are running as root (not recommended) then change /home/USER/ to /root/
If that still says directory not found then I don't think you extracted the package from AMD to the right directoy


text:
Error trying to send payments with RPC sendmany
Need help fixing this error.
Error trying to send payments with RPC sendmany {"code":-8,"message":"Invalid parameter, duplicated address
I a running a NOMP mining pool that has payment job breaking because there are two same wallet address payments in the same sendmany job. I need to limit amount sent to minimize chance of having the payment in the same transaction for a while until I get rid of this so that the payments go thru. Or, do something so that this is ignored.

You are probably posting the same address twice. Please take an RPC capture, so one can see what you are posting on the server.

I know, this is a NOMP pool and there is a user that has two workers with the same address. How can I fix this? Is there a way to ignore this and submit the payments?

Count outgoing sums of every address together before doing sendmany.

Is there PM in this site?

Count outgoing sums of every address together before doing sendmany... Not sure how to do this.

Is there a way to limit or control the amount of payments sendmany groups at a time? This may help me in these payouts while duplicate address removed.

@cmilian We don't know what your question is about now. Who or what is issuing these commands?

I a running a NOMP mining pool that has payment job breaking because there are two same wallet address payments in the same sendmany job.
I need to limit amount sent to minimize chance of having the payment in the same transaction for a while until I get rid of this so that the payments go thru.

@DavidSchwartz I a running a NOMP mining pool that has payment job breaking because there are two same wallet address payments in the same sendmany job. I need to limit amount sent to minimize chance of having the payment in the same transaction for a while until I get rid of this so that the payments go thru. Or, do something so that this is ignored. rather ignore duplicate wallet addresses.

@cmilian: No, Stack Exchange does not support private messages.

So, whatever code implements the "payment job" (i.e. the code that is calling sendmany in the first place) should detect when multiple outputs to the same address are requested, and combine them into one.  For instance, if you have a payment to address 1abc for BTC 0.1, and another to the same address for BTC 0.2, you should call sendmany asking for one payment to 1abd for BTC 0.3.

I understand, you are correct, that is the issue. trying to paste code to show.
[link] https://onedrive.live.com/redir?resid=CD88B09A5E2E741E!34171&authkey=!ACs6xjZnKgsjnBU&ithint=file%2ctxt [link]
how can I do that in this code?

Please edit your question to include the relevant code there.

I had this problem on a NOMP pool recently, I will share how we fixed it. For us, the problem was that a user had used the same address twice, but added some whitespace to their username the second time. So NOMP wouldn't recognize it as a duplicate, but the sendmany command would still fail. The solution for us was to do two things.

Eliminate the whitespace from workers' names. This commit shows how to do that.
Combine payouts together when there is more than one worker with the same address. The code for that is shown below.

In paymentProcessor.js, change
var address = worker.address = (worker.address || getProperAddress(w));
worker.sent = addressAmounts[address] = satoshisToCoins(toSend);

to
var address = worker.address = (worker.address || getProperAddress(w)).trim();
if (!worker.sent) {
    worker.sent = 0;
}
worker.sent += satoshisToCoins(toSend);
if (!(address in addressAmounts)) {
    addressAmounts[address] = 0;
}
addressAmounts[address] += satoshisToCoins(toSend);

If you want to know more about what caused this, the problem here is just what was explained in the error: there are duplicate addresses in the JSON object.
For example, I generated a new address of my own (1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy) and ran:
./bitcoin-cli sendmany "" '{"1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.01, "1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.01}'

And the error was:
Invalid parameter, duplicated address: 1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy (code -8)

To fix this problem, you either need to (1) add up all the amounts and pay to the address in one go, or (2) do separate RPC sendmany RPC calls, making sure to not have any duplicates.
In my case, (1) would look like:
./bitcoin-cli sendmany "" '{"1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.02}'

And (2) would look like:
./bitcoin-cli sendmany "" '{"1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.01}'
./bitcoin-cli sendmany "" '{"1PSXKQdR5nG8T5ueG76RaWwhdwqv9JJWzy":0.01}'


text:
What is -vbparams argument and what its the difference with -testactivationheight on Bitcoin functional tests?
Taproot test use the argument -vbparams , but other test like SegwWit use -testactivationheight, what is the use of each one and the difference for using one or the other?
class WalletTaprootTest(BitcoinTestFramework):
    """Test generation and spending of P2TR address outputs."""

    def set_test_params(self):
        self.num_nodes = 3
        self.setup_clean_chain = True
        self.extra_args = [['-keypool=100'], ['-keypool=100'], ["-vbparams=taproot:1:1"]]
        self.supports_cli = False

class SegWitTest(BitcoinTestFramework):
    def set_test_params(self):
        self.setup_clean_chain = True
        self.num_nodes = 3
        # This test tests SegWit both pre and post-activation, so use the normal BIP9 activation.
        self.extra_args = [
            [
                "-acceptnonstdtxn=1",
                "-rpcserialversion=0",
                "-testactivationheight=segwit@432",
                "-addresstype=legacy",
            ],

-testactivationheight is defined here.
argsman.AddArg("-testactivationheight=name@height.", "Set the activation height of 'name' (segwit, bip34, dersig, cltv, csv). (regtest-only)", ArgsManager::ALLOW_ANY | ArgsManager::DEBUG_ONLY, OptionsCategory::DEBUG_TEST);

-vbparams is defined here.
argsman.AddArg("-vbparams=deployment:start:end[:min_activation_height]", "Use given start/end times and min_activation_height for specified version bits deployment (regtest-only)", ArgsManager::ALLOW_ANY | ArgsManager::DEBUG_ONLY, OptionsCategory::CHAINPARAMS);

-testactivationheight is setting the name (segwit, bip34, dersig, cltv, csv) of the soft fork and the activation height (on regtest) for each soft fork. It is not testing the deployment of a particular soft fork (miner signaling etc, how a
soft fork can get activated), just the block heights at which soft forks activate.
-vbparams is setting the start, end and min_activation_height of a deployment (on regtest). It is testing the deployment of a particular soft fork rather than just setting the activation height for various soft forks.


text:
nLockTime in Bitcoin Core
Currently, the Bitcoin Wiki states:

A part of the original Bitcoin implementation, nLockTime is a field that specifies the earliest time a transaction may be added to a valid block. A later Bitcoin soft fork allowed nLockTime to alternatively specify the lowest block height a transaction may be added to a valid block.

Is the ordering correct? It appears that the source code as of v0.1.5 used the block height and v0.1.6 extended this to handle timestamps. Also, does this new ordering make it a hard-fork?

The Wiki was incorrect (I wrote the original text and I apologize).  As indicated in the question, the ordering on the Wiki was backwards.  However, upon investigating, I don't believe it was a hard fork.  In the original Bitcoin 0.1 code, we find the following function:
bool IsFinal() const
{
    if (nLockTime == 0 || nLockTime < nBestHeight)
        return true;
    ...
}

This function is called in the mining code that selects which transactions to mine:
if (tx.IsCoinBase() || !tx.IsFinal())
      continue;

That means no node running the default Bitcoin 0.1 code would mine a transaction unless its nLockTime was less than the next block's height.  However, I don't see any code in 0.1 that rejects blocks with a "non-final" transaction, so this isn't a consensus rule.
Months later, in code that became part of Bitcoin 0.1.6, the timelock feature is added:
-    bool IsFinal() const
+    bool IsFinal(int64 nBlockTime=0) const
     {
-        if (nLockTime == 0 || nLockTime < nBestHeight)
+        // Time based nLockTime implemented in 0.1.6,
+        // do not use time based until most 0.1.5 nodes have upgraded.
+        if (nBlockTime == 0)
+            nBlockTime = GetAdjustedTime();
+        if (nLockTime == 0)
+            return true;
+        if (nLockTime < (nLockTime < 500000000 ? nBestHeight : nBlockTime))

And the same commit also adds consensus enforcement for both heightlocks and timelocks:
+    // Check that all transactions are finalized (starting around 30 Nov 2009)
+    if (nBestHeight > 31000) // 25620 + 5320
+        foreach(const CTransaction& tx, vtx)
+            if (!tx.IsFinal(nTime))
+                return error("AcceptBlock() : contains a non-final transaction");

In short, in version 0.1.0 had no consensus rules about the nLockTime field and version 0.1.6 added a consensus rule that included both heightlocks and timelocks.  That's making the rules more strict and so I believe it was a soft fork which activated at block 31,000.
Perhaps of interest, this is the earliest soft fork of which I'm aware (as of this writing, it's earlier than any entries at the time of writing on the Wiki's consensus versions list or BitMex's consensus forks list).  Despite being so early, the fork was obviously made with care, giving the network about a month to upgrade and preparing for potential problems ahead of time.

I believe you are correct, both about the fact that height-based logic came first and time was added later, and the fact that this is a hard-forking change. A transaction with a locktime > 500000000 would not have been acceptable before the change, but possibly valid after.
Of course, given that no such transactions occurred (to the best of my knowledge), it isn't exactly a fork; but it was a change that could have led to one.
Also, before the removal of OP_VER, technically speaking every new release had a hard forking change of this nature.


text:
How to emulate SIGHASH_NOINPUT using CHECKSIGFROMSTACKVERIFY?
I read on bitcoin-dev that CHECKSIGFROMSTACKVERIFY (CHECKDATASIG in BCash) can be used to emulate new sighash flags. How would that work, concretely? As an example, please provide an example update transaction based on figure 4 of the Eltoo paper, or aj's simplified lightning (that doesn't work with watchtowers).

You also need OP_CAT or OP_SUBSTR. If you are still interested in this question, I can answer this in detail

@sanket1729, Yes, I am still interested! Thanks! Looking forward to reading your answer.

Sorry for the super long delay, I finally have an answer for you. This may be a lot to take in, so let me know if something needs more clarification.

Eltoo relies on a primitive SIGHASH_ANYPREVOUT or SIGHASH_NOINPUT (hereafter referred as APO) BPI118, constructing Eltoo from APO would be replacing the CHECKSIG figure 4 of Eltoo paper with a modified script.
Most of this answer is based on a blog post by Russell O'Connor from this link(which goes into other covenant constructions too). For completeness, let us look at the basics of transaction introspection and later hop into how to construct APO. The answer is for Segwit Signature Hash and the ECDSA signature algorithm. Unfortunately, extending this to taproot requires additional opcodes/other changes which I will explain at the end of the answer.

OP_CHECKSIGFROMSTACK:(hereafter CSFS) There is no formal proposal for this opcode yet, but most likely this would work as follows: pop 1) a pubkey pk, 2) a message m, and a 3) digital signature sig. The operation would perform the verify the sig as ECSDA.Verify(pk, sha256(m), sig) and push the result onto the stack top.
OP_CAT: Pop two items from stack top and next_top and push next_top || top onto the stack where || denotes the byte string concatenation. I will be assuming a SIGHASH_ALL for the below construction, but the construction can be used for sighash type.

First we will look at basic transaction introspection using OP_CAT and OP_CSFS:
Consider the following script:
1. OP_OVER OP_SHA256 <pubKey>
2. 2 OP_PICK 1 OP_CAT OP_OVER
3. OP_CHECKSIGVERIFY
4. OP_CHECKSIGFROMSTACKVERIFY

with the witness stack
<sig>
<sig_msg>

Where <fixed_pk> is public whose secret key is known to everyone. Say, the generator G whose secret key is 1. <sig_msg> denotes transition digest being signed.
At the end of Step 1, the stack is
<pubKey>
<sha256(<sig_msg>)>
<signature>
<<sig_msg>>

At the end of step 2, the stack contents are
<pubKey>
<sig;SIGHASH_ALL>
<pubKey>
<sha256(sig_msg)>
<sig>
<sig_msg>

Note that 1 is translated as SIGHASH_ALL and catted to sig. This creates a regular bitcoin signature which we can verify using regular OP_CHECKSIG. After Step 3, the stack contents are
<pubKey>
<sha256(sig_msg)>
<sig>
<sig_msg>

Which would call OP_CHECKSIGFROMSTACKVERIFY to leave only <sig_msg> onto the stack. The OP_CHECKSIGFROMSTACKVERIFY of step 4 uses the same pubKey and signature. This operation performs another SHA-256(double sha256 is required for segwit sighash algorithm) and does a digital signature validation on the doubly hashed <sig_msg>. Note that because we are using exactly the same <pubKey> and <sig> that we used for the previous OP_CHECKSIGVERIFY operation, the current OP_CHECKSIGFROMSTACKVERIFY can only succeed if <sig_msg> is identical to the message that was checked during step 3’s OP_CHECKSIGVERIFY operation. At this point, we are certain that the <sig_msg> on the stack top is the same as the signed transaction message.
Note that since the private key to <fixed_pk> is known, anyone can create this signature, but this script would only succeed if the <sig_msg> is correctly specified as mentioned above.
Onto ANYPREVOUT:
Anyprevout essentially is substituting some things from the regular signature hash messages and replacing those with 0's. In detail, we can now split our sig_msg into multiple parts as defined in BIP143 using OP_SUBSTR. It is also possible to use OP_CAT to initially supply the split up the message and then CAT it together.
Now that we have signature hash message as per BIP143 on the stack, we manipulate it to make certain fields 0's. In particular, we make items 2-4 0.
2. hashPrevouts (32-byte hash)
3. hashSequence (32-byte hash)
4. outpoint (32-byte hash + 4-byte little endian)

We take a OP_DUP OP_SUSTR 0 <4> to get item 1, version. onto the stack. and similarly, obtain a concatenation of items 5-10 onto the stack. Finally, we CAT them together by <ver> <[0; (32+ 32 + (32 +4))]> <items 5.10>` to get a new sighash which we use for Eltoo update key.
Let introspect_script =
OP_OVER OP_SHA256 <pubKey> 2 OP_PICK 1 OP_CAT OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIGFROMSTACKVERIFY

as we discussed above. And let manipulate_txdata_script be the script to modify the stack contents from BIP143 sighash message to get a new message which sets the respective items to 0s. Then our final substitute for OP_CHECKSIGANYPREVOUT would be the following script.
final_script(eltoo_pk) = <introspect_script> <manipulate_txdata_script> <eltoo_pk> OP_CSFS

Satisfying this would require the following onto the initial witness stack.
<sig_from_fixed_key>
<sig_msg>
<sig_from_eltoo_update_priv_key>

Lastly, the eltoo script would now look like:
OP_IF
    10 OP_CSV
    2 A(s,i) B(s,i) 2 OP_CHECKMULTISIGVERIFY
OP_ELSE
    <Si + 1> OP_CHECKLOCKTIMEVERIFY
    final_script(Au) final_script(Bu)
OP_ENDIF

Note how the two of two multi-sig is split into two parts.
Taproot Signature Hash:
The same technique does not work for Taproot Signature Hash algorithm(see BIP341) and Schnorr signatures (see BIP340) because of tagged hashes. At a high level, because of tags, the size of these messages is more than 520 bytes which is currently the maximum supported by bitcoin network. It is possible to overcome this limitation by adding 1)streaming SHA256 opcodes, 2) by raising the per stack element limit, Or 3) adding support for tagged hashes by new opcodes.


text:
Can R/r in Musig be derived from only seeds and message hashes?
I am wondering if the first two roundtrips of pre-committing and then revealing R/r in MuSig signing can be moved to the keygen phase and made deterministic. That reduces the amount of messages that need to be exchanged; since keygen is done only once, we want to expand that phase. This would be especially useful for HD wallets: at the expense of making wallet creation more complicated, signing would need fewer interactions.
The musig paper on page 10-11, specifies the following (from perspective of signer 1):
MuSig scheme
Key generation

generates private key x1 and corresponding public key X1
sends X1
receives Xi

Signing (specifically the part about agreeing on Ri)

sends t1=Hcom(R1)
receives ti
sends R1
receives Ri
checks that Hcom(Ri)==ti

r1 is specified to be random.
Signing includes three rounds of interaction, two of which is used for the above steps (agreeing on Ri).
I want to move these steps to the keygen phase.

A HD wallet would presumably use BIP32 to generate X1.
Can we use BIP32 for deriving Ri/ri too?
Consider the following scheme instead.
(from cosigners 1's perspective)
Proposed HD scheme
HD wallet setup phase

generates xprv y1 and corresponding xpub Y1
generates xprv k1 and corresponding xpub K1
sends xpub Y1
sends u1=H(K1)
receives xpub Yi
receives ui
sends xpub K1
receives xpub Ki
checks that H(Ki)==ui

Key generation

from xprv y1 along some BIP32 path p, derive private key x1 and public key X1
from xpub Yi along same BIP32 path p, derive public key Xi
from xprv K1 along same BIP32 path p, derive private key j1 and public key J1
from xpub Ki along same BIP32 path p, derive public key Ji.

Signing (specifically the part about agreeing on Ri)

compute r1=j1+hash(m) and R1=J1+hash(m)*G
compute Ri=Ji+hash(m)*G

This approach only has one round of interaction during signing (sending si, omitted as its not changed from what is described in the paper).
I have read the derandomization section, but the explanation for why it doesn't work requires Ri to be chosen by the attacker. If we make it deterministically derived, and BIP32 is safe, then this attack does not apply. The paper states "each signer must ensure that whenever any Rj sent by other cosigners or the message m changes, his ri value changes unpredictably. As long as f is deterministic, this implies a circular dependency in the choice of random values."
Where is this circular dependency? The f from RFC 6979 only depends on key and m.

I can't comment about the interaction with Musig, but I'll add my intuition here in a comment.  If by your design, the signature's nonce is chosen by the signer by way of public key derivation, and this is disclosed to another party who learns the public derivable path between private key and nonce, then they now have a function of the nonce as the public key.  This most likely will leak the private key when a valid signature over some message is published by the signer.

The circular dependency only appears when there are multiple parties. In order for a deterministic algorithm to be secure, it must require every party's nonce to depend on every other nonce (because as long as anyone's nonce changes between two runs, yours must also - or you leak your private keys). You can't have k1=F(x1,m,k2G) and simultaneously k2=F(x2,m,k1G).

This circular dependency only appears of the nonce isn't provably deterministic. If everyone would be able to prove to everyone else that their nonce was computed from just their private key, the message, and everyone's public key, there wouldn't be a problem either. The circular dependency is only when one party could choose to use a different algorithm.

The construction you're suggesting will likely work as long as you don't sign more than one message. By effectively choosing the R points ahead of time, you've constructed a single-show signature.
However, the derivation you're using for the different R values is pointless. It's not enough that you don't reuse R values; you can't use multiple related R values either. All the R values you are constructing are related through a single linear equation. That is sufficient for an attacker (who knows about the relation) to derive the private key from seeing two signatures.

Technically linear relations can be okay so long as there are more unknowns than equations.  E.g. if you agree on a 3000 degree polynomial, you can use messages hashes to pick locations to interpolate, and make up to 2999 signatures.  But critically all of this stuff is SUPER hard to get right and super hard to verify. Most cryptographic constructions are broken.  I would really caution anyone against being too clever with this stuff.


text:
How to get scriptPubKey from public key hash
My goal is to create a transaction. For that I need to know the following things:

The private key signing the transaction.
Who can spend the bitcoins that I'm sending.
Valid UTXOs that the sender can spend.

When creating the outputs, I need to add the scriptPubKey, which in my understanding is a script that specifies how the bitcoin can be spent. I know how to get the scritPubKey from and address (actually, I mean there is a way to do it if using Peter Todd's python-bitcoinlib codebase here. But, given a public key hash, I don't really understand how to do it.
Ex: Given this hash of a public key: mz64DQXTMiSYwZFQqaggUrMG82MA4TW2wx, how to get the scriptPubKey from it?
What I expect in term of answer (not exclusively):

Clarification on what is the difference between these things: public key hash, scriptPubKey, addresses.
Implementable steps to get the scriptPubKey.
I realise that using this hash of the public key, I can send transactions directly to it and treat it as an address and some explorer calls it address, how is that possible?
Resource recommendation to go further in the understanding.

What is clear to me:
From this site, I understand that the hash comes from hashing the public key with hash160 and adding checksum 4 bytes. I believe by reverting this process, I could get the public key and generate an address and get the scriptPubKey from the address, but I believe there can be better way to do it.

Clarification on what is the difference between these things: public key hash, scriptPubKey, addresses.

Public key hash represents, as it name says, the hash of the public key. So you take the public key and first do SHA256 hash function on it, and then RIPEMD160.
scriptPubKey represents a locking script that you use to lock satoshis. To unlock them, you must provide a valid unlocking script, also known as scriptSig.
Addresses does not actually exist in Bitcoin protocol. They are just called like that in Blockchain explorer to simplify Bitcoin protocol for end users. Addresses actually represent just a hash of the public key, nothing else (in case of P2PKH). It is worth mentioning that they are more often represented in some encoded form like Bech32 or Base58check.

Implementable steps to get the scriptPubKey

There are no implementable steps to get the scriptPubKey. You can lock your satoshis the way you want. You just need to take care that you are using valid opcodes and that your locking logic is valid since if it is not, you won't be able to unlock funds. There are some standard ways to create this locking script like P2PKH, P2SH etc.

I realise that using this hash of the public key, I can send transactions directly to it and treat it as an address and some explorer calls it address, how is that possible?

It is the one of the standard scriptPubKey, where you lock your funds to hash of the public key. It is called P2PKH.

Resource recommendation to go further in the understanding.

Master Bitcoin book (Andreas Antonopolus), Grokking Bitcoin, Programming Bitcoin (Jimmy Song).
All the mentioned books take you in detail through how to create scripts and how bitcoin works in general. They are worth reading and will give you answers to many questions, including the one you asked.

I believe by reverting this process, I could get the public key and generate an address and get the scriptPubKey from the address, but I believe there can be better way to do it.

You can't revert hashing. Hash functions are one way functions. However, you do not even need to revert it. Since the hash of the public key represents address, you are creating scriptPubKey using it, not directly public key.

Nicely answered! Thank you for the the time. I actually solve the problem by creating a P2PKH script from it since it's the hash of my pubk.

@NahumMaurice No problem, glad you made it.


text:
Should the nodes of a channel have the same Time Lock Delta?
Consider this channel https://1ml.com/channel/612829298476056576 :
Node 1: Caffeine
        Time Lock Delta: 10

Node 2: HODLcat.com
        Time Lock Delta: 144

How is an HTLC passing through this channel affected ?
Would the channel work more reliably if the time-lock deltas were the same?

No it does not have to be the same value.
The timelock somewhat reflects the openness to risk. The lower the value the quicker a node has to engage into force close if there is an unsettled htlc and the partner does not respond to communication.
Thus the higher your partner's cltv delta the longer you can be offline before your partner might force close channels. AFAIK there is currently no real recommendation for the cltv delta. Though nodes seem to lower the default value over time. Remember that high values can lead to longer locked funds. This it is a tradeoff anyway

An HTLC passing from node 1 (here Caffeine) to node 2 (here HODLcat.com) will be added a 144 blocks time-lock.
An HTLC passing from node 2 (here HODLcat.com) to node 1 (here Caffeine) will be added a 10 blocks time-lock.
The channel operation does not depend of the CLTV deltas, it really is a pure personal setting as it defines the time a forwarding node has to redeem an HTLC on-chain in case it gets timed out down the route and your peer becomes unresponsive.
However, wallets take it into account when computing routes as they sum up along the route and determine how many blocks funds of the end-payer may be stuck in a worst-case scenario.
You can find more details in the specification (it's called cltv_expiry_delta), which gives a really detailed explanation and some recommendations which have been updated lately with the discovery of the recent attacks.