text:
Verify Bitcoin Transaction
Following the great post [Redeeming a raw transaction step by step example required, I came up with  code below but the verification failed.
// pubkeyBytes, len: 65
// 042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9

// data, len: 32
// 30f10a6468b7d98257af63fb40dfcf2cefe991346fd37c67cf7b51ff8d4404d3

// signatureBytes, len: 71
// 30450220587ce0cf0252e2db3a7c3c91b355aa8f3385e128227cd8727c5f7777877ad772022100edc508b7c14891ed15ab38c687019d7ebaf5c12908cf21a83e8ae57e8c47e95c

    ECPublicKey publicKey = (ECPublicKey)KeyBuilder.buildKey(KeyBuilder.TYPE_EC_FP_PUBLIC, KeyBuilder.LENGTH_EC_FP_256, false);;
    Secp256k1.setCommonCurveParameters(publicKey);
    publicKey.setW(pubkeyBytes, (short) 0, (short) pubkeyBytes.length);

    Signature eccSign = Signature.getInstance(Signature.ALG_ECDSA_SHA_256, false);
    eccSign.init(publicKey, Signature.MODE_VERIFY);
    boolean verified = eccSign.verify(data, (short)0, (short) data.length,
                signatureBytes, (short)0, (short)signatureBytes.length
            );
    Assert.assertTrue(verified);

Assertion failed at the end.
Have been stucked for hours. Cannot figure it out. Any help is highly appreciated. Thanks.

Usually the issue is the Signature Verification algorithm used. Bitcoin uses double SHA-256 as the hashing algorithm for ECDSA, thus the Z value is the Double SHA-256 hash of the unsigned transaction. Looking at the Signature Hash Algorithm you're using:

Signature algorithm ALG_ECDSA_SHA_256 generates a 32-byte SHA-256 digest and signs/verifies the digest using ECDSA with the curve defined in the ECKey parameters

You are taking in the Z value already but then hashing it again with only 1 round of SHA-256. You could try to pass in a preimage of only 1 SHA-256 hash then let the Signature object handle the second round, but I do not have much luck with this method using standard Java Security libraries. In order to accomplish Bitcoin Transaction signing/verification in Java, you will need to either (1) implement your own ECDSA signing/verification, or (2) use a library such as BitcoinJ. The following is the code I use in my own project(s) within my ECPubKey class (note that I am using a ton of other custom code that you will see method calls from, yet are not included here, but you will get the gist):
/**
 * @param preimage the Preimage to verify
 * @param signature An ECDSA Signature (R/S Value pair)
 * @return whether this Public Key was used to generate the signature for the given preimage
 */
public boolean verify(String preimage, ECSignature signature) {
    String sigHash = HashUtil.doubleSha256(preimage);
    BigInteger z = new BigInteger(1, ByteUtil.hex2bytes(sigHash));
    BigInteger r = signature.getR();
    BigInteger s = signature.getS();
    BigInteger sInv = s.modInverse(CurveParams.n);
    BigInteger u1 = z.multiply(sInv).mod(CurveParams.n);
    BigInteger u2 = r.multiply(sInv).mod(CurveParams.n);
    ECPoint u1Point = ScalarMultiply.scalmult(CurveParams.G, u1);
    ECPoint u2Point = ScalarMultiply.scalmult(this.getPoint(), u2);
    ECPoint sigPoint = ScalarMultiply.addPoint(u1Point, u2Point);
    return r.compareTo(sigPoint.getAffineX().mod(CurveParams.n)) == 0;
}

The methodology was essentially copied directly from the ECDSA Wikipedia Page and translated into Java.

static void test_sig ( )
{
  const MyByteArray pubkey ( QByteArray::fromHex ( "042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9" ) );
  const MyByteArray signat ( QByteArray::fromHex ( "30450220587ce0cf0252e2db3a7c3c91b355aa8f3385e128227cd8727c5f7777877ad772022100edc508b7c14891ed15ab38c687019d7ebaf5c12908cf21a83e8ae57e8c47e95c" ) );
  const MyKey32     digest ( QByteArray::fromHex ( "30f10a6468b7d98257af63fb40dfcf2cefe991346fd37c67cf7b51ff8d4404d3" ) );
  qDebug ( ) << ( digest.verify ( pubkey, signat ) ? "passed" : "failed" );
}

my result is:: passed
the signature is correct for digest and public key
may be something is wrong in your verification code with decoding hex values and/or byte order in digest?


text:
How to migrate Lightning (LND) from local laptop to external myNodeBTC node
I am in the process of migrating my LNP/BP stack from a Windows laptop to a dedicated myNodeBTC (RaspPi) device. My node on the Windows laptop was installed using Node Launcher.
I already have the new Bitcoin node running, but I haven't setup LND yet on the new device. I do have 3 Lightning channels open on the old device.
What's the current best practice for moving from the old node to the new node so that I don't lose any sats in the process?
I suppose I could just close all my channels and then move my sats to a different wallet, spin up the new node and re-establish my channels. But I'm not sure if that's the most network-friendly approach?
Thanks!

This sounds like the age old proverb of "Good, Cheap or Fast - Pick Two"
I like your original suggestion, but you do have options:

Close all channels, wait an hour, then restore the new lnd node w/ your mnemonic seed and password.
Close all channels, wait an hour, send an on-chain transaction from your original lnd node to the new lnd node.
Dont close anything, save your static-channel-backups file, restore with the static channel backup/mnemonic seed and password and wait patiently for multiple days for the funds to be recovered due to force closes (Please don't do it like this)

There are other creative ways to do this (opening new channels on the new lnd node and transferring the funds through invoices or something), but i've stuck to simple examples here.
To move to a new node, we'll have to take your channels offline (not network friendly). We'll have to take them offline, close them, and then reopen them on the new node, so your best bet is to use the option that you are comfortable with.
Closing your channels, then on-chain transaction to the new node may cost more sats due to transaction fees, but it is an easy and fool-proof way to migrate your node.

Thanks Danny, I'm not sure how familiar you are with Node Launcher, so maybe this follow-up is out of scope, but, do you know where the BTC that is locked up in channels will go back to once I close the channels? The Node Launcher GitHub (and related links) don't really talk about any Wallet specifically. So I'm hesitant to close channels. Don't want to nuke my BTC!

BTC in channels will go to the btc wallet that is created in LND.

source: Stack Exchange

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

sort: votes


text:
Please take a look at my server print out to see if all looks well or if the repeating errors mean something is wrong
So it is not clear to me if my bitcoin server is syncing and all is fine or if the "potential stale tip detected, will retry extra outbound " message means I have to do something. Searching for that string does not actually provide me an answer. I thought Bitcoin full node install would be a bit more intuitive. Any help appreciated
Solution Update:
My server was not connecting to peers because my ROUTER had a FILTER, set to medium, that was just allowing in some popular known ports. When I set it to Low, My server then started to see peers immediately. Just weird how the router chose to implement this firewall this way. It did not honor the fact that I forwarded the port.

The message
potential stale tip detected, will retry extra outbound peers

is associated with at least two situations:

A firewall is blocking port 8333 and your node cannot communicate with peers.
Problems with genesis block (delete blocks and chainstate directories and restart).

Thank you. It was in fact that my ROUTER had a FILTER, set to medium, that was just allowing in some popular known ports. When I set it to Low, My server then started to see peers immiedietely. Just weird how the router chose to implement this firewall this way. It did not honor the fact that I forwarded the port.

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


text:
How to connect LND to bitcoind RPC with authentication cookie stored in a custom folder?
I configured bitcoind RPC to authenticate clients with an authentication cookie. However I cant figure out if it's possible to use this method with lnd while connecting to bitcoind RPC.
I would like to clarify that I'm running bitcoind and lnd in two separated docker containers that share a volume where bitcoind save the authentication cookie. The problem is that lnd doesn't allow to specify the folder in which it could find the cookie... In bitcoin.conf for exemple you can specify the path where you can find the authentication cookie of the tor control port for example...
Someone knows how to do this in lnd ? Is it possible ?
Thank you!

It should be possible: https://lightningwiki.net/index.php/RPC_auth_for_bitcoind

RPCauth is not the authentication cookie, with authentication cookie you don't need to create a password, a cookie is generated and shared between bitcoind and lnd on the same file system or shared folder...

It is supported according to the LND installation guide

NOTE:
The auth parameters rpcuser and rpcpass parameters can typically be determined by lnd for a bitcoind instance running under the same user, including when using cookie auth. In this case, you can exclude them from the lnd options entirely.

I'm running bitcoind and lnd in two separated docker containers that share a volume where bitcoind save the authentication cookie. The problem is that lnd doesn't allow to specify the folder in which it could find the cookie... In bitcoin.conf for exemple you can specify the path where you can find the authentication cookie of the tor control port...

The auth cookie lives in the data_dir for bitcoind.
lnd finds the data_dir by first finding the bitcoin.conf file, which it finds based on the bitcoind.dir argument passed at runtime. It then parses that for the data_dir directive.
You can see this in the src code:
https://github.com/lightningnetwork/lnd/blob/master/config.go#L1505
So, if you are using a non-default location for your data_dir you need to ensure that you have a data_dir directive in your bitcoin.conf file and that you pass the bitcoind.dir at runtime.
Note: lnd won't find your data_dir directive if you preface it with main ot test.


text:
How about force the use of unbalanced Merkle tree in Taproot?
I noticed this sentence in Taproot about the MAST build.

The remaining scripts should be organized into the leaves of a binary tree. This can be a balanced tree if each of the conditions these scripts correspond to are equally likely. If probabilities for each condition are known, consider constructing the tree as a Huffman tree.

But in the case of a balanced Merkle Tree, an observer can infer the number of layers in the tree by the Merkle proof and thus get an approximate number of leaves(scripts). For example, a P2TR ends up unlocked with a time lock, and I infer from the Merkle proof that there are 2 scripts in total. Then I can guess the other lock is a hash lock(since this is the most common script with two conditions and one of them is a time lock).
It seems that forcing the user to use an unbalanced Merkle Tree would also be an option (e.g. randomly initialising the coefficients and then constructing a Huffman tree)? Or maybe put in some fake leaves?

Apologies for confusing the concept of a balanced binary tree, the example in the question is not accurate.

For example, a P2TR ends up unlocked with a time lock, and I infer from the Merkle proof that there are two scripts in total.

You can't infer this for certain. You know what layer of the Merkle tree the script was taken from (in this case the first layer) but there may be scripts present on the second, third, fourth layers etc that you don't know about. I agree that if a script is taken from the first layer it is possible (perhaps likely) there are two scripts.

Then I can guess that this is a MAST containing a hash time lock (since this is the most common script with two conditions and one of them is a time lock).

I'm not sure why you think having one leaf script with a timelock infers that another leaf script contains a hash timelock. If you are referring to Lightning, the most common channel closes are cooperative 2-of-2 closes where no alternative script paths need to be included in the output. In the case of rarer uncooperative closes it is obvious to a blockchain observer that it is an uncooperative Lightning channel close, you can't hide this.

It seems that forcing the user to use an unbalanced Merkle Tree would also be an option (e.g. randomly initialising the coefficients and then constructing a Huffman tree)? Or maybe put in some fake leaves?

You can definitely construct the Taproot tree however you wish. You can put scripts in lower layers than they need to be so it seems to a blockchain observer there are more script paths than there actually are. Typically to save on fees you will want to put the script you are most likely to use on a higher layer of the Merkle tree but if you are more concerned with privacy you may choose not to do this.

First of all thank you very much for your answer!

About leaves in lower layer: Maybe I misunderstand the balanced tree, I thought it likes the Merkle tree in SPV where all the leaves would be at the lowest layer.
About lightning network example: What I want to discuss is whether it is possible to distinguish hash time locks from normal time locks? This will be easy if the number of scripts can be inferred.
Finally, I may have misunderstood the balance tree. What I want to suggest is as you said, we should make each layer have scripts instead of putting all leaves at the last layer.

You do not need to put all the scripts on the same lowest layer. That would be inefficient and more costly to spend if you say had 3 scripts and were forced to put them all on the second layer rather than 1 script on the first layer and 2 scripts on the second layer. Re Lightning I'm sorry I don't understand the question. The script for a hash timelock obviously contains a hash lock as well as a timelock. I don't understand why revealing a timelock script infers that a second script is a hash timelock. I suspect you are misunderstanding how Lightning works (but I could be wrong)

Oh, my bad, I forgot to clarify the context.
I suspect that in future Lightning Network will split the hash time lock into two separate scripts to meet Taproot, a hash lock and a time lock.
So when I see that one lock is a time lock and that this MAST has two scripts, I'm guessing that the other script is a hash lock and the MAST represents the HTLC.

You wouldn't be able to do this because only one script (leaf) can be used/spent in the Taproot tree. You can't combine multiple leaf scripts to spend from the output. Hence if you want an encumbrance that contains a hashlock and a timelock they both need to be within a single leaf script

Yes, but I think what HTLC means is that Alice can redeem with preimage or Bob can redeem after a timeout. It would be a script that could be split.

No you are confusing HTLCs with uncooperative channel closes. A HTLC is a script that includes both a hashlock and a timelock. These are constructed every time a new payment is made on Lightning. An uncooperative channel close is when a transaction is broadcast that includes two outputs: one paying your counterparty without a timelock and one output paying you with a timelock. These are two outputs rather than two scripts that can be combined.

Yes, you are right, there are two outputs when non-cooperative closing. the output Alice gives herself is locked by a time lock, and another output Bob can get immediately (but I think these are two different P2TR scripts?. I'm only talking about the P2TR that Alice gives to herself). And, the lightning network will allow Bob to take Alice's output as a penalty via a preimage to prevent one party from committing the old state, a mechanism called RSMC.
Note that I am only talking about the script of output that Alice gives to himself. The MAST of this output has two scripts.

One script for Alice to get the refund after the timeout.
Another script for Bob to get the money by preimage to punish Alice.

This is getting long (and moving onto Lightning which isn't the focus of the original question) so we should move to chat. But no, Bob has a time interval to broadcast a punishment transaction that spends Alice's timelocked output to an address that he controls if Alice has broadcast a revoked state. That is an additional transaction not an alternative script path within a single transaction.

Yes, let's assume that Alice's UTXO is P2TR. There be two scripts in MAST, right (one for Alice, one for Bob)? So if Bob uses preimage to unlock and show that there are two scripts (let's assume this all scripts are placed on the same layer). Then the observer guesses that the other script is the time lock, which is what I meant initially.

Spending does not revealing anything about other scripts in the same tree. You can construct a depth-128 tree with just one script. It would be inefficient, though, as you need 128 dummy branches.

The answer is very simple, you can't independently verify that the user is using an unbalanced Merkle tree without knowing its structure in full – rendering all anonymity benefits pointless. But you are overestimating how much information about the Merkle tree can be inferred. Since during a Taproot spend only one Merkle path is revealed, unless the script is located right under the Merkle root – in which case it is provably the only script in the tree – there is no way to know for sure how many spending conditions were defined.
However, to prevent anyone from even making reasonable guesses, a wallet software could randomize the Merkle tree structure with every transaction, similarly to how some wallets randomly shuffle transaction outputs to disguise the change output.


text:
bech32 address not showing in watch-only wallet (using HWI descriptors)
First of all thanks for all the awesome tools. Especially Andrew Chow and Sjoors Provoost, for my use case.
Now, I´m a little confused. A transaction I sent from a mobile wallet to a watch only wallet in core is not showing.
I am on bitcoin core 0.19.01 on Raspbian , running hwi.py v1.0.3 and using a Trezor One.
The steps i followed:
1. in bitcoin core GUI, create an unencrypted wallet without private keys (i.e. watch only)
2. unlock trezor using pin challenge on wallet.trezor.io
3. export public keys from trezor using HWI
./hwi.py --fingerprint xxxxxx getdescriptors --account 0

returns the expected .json with 1 pkh, 1 sh(wpkh) ,1 wpkh each for receive and internal (change?)

create .json file to parse as argument to importmulti like so

'[{"range": [0, 1000], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "sh(wpkh([..../0/*...", "internal": false},
{"range": [0, 1000], "timestamp": "now", "keypool": true, "watchonly": true, "desc": "sh(wpkh([..../1/*...", "internal": true}]'

by copy pasting the sh(wpkh lines in the output from getdescriptors
5. run importmulti jsonstring_above --> success and success for both xpub´s
6. rescanblockchain --> found all the addresses previously sent to my trezor, they all start with 3 - all the money is there, the watch only wallet works
   SO FAR SO GOOD

in this wallet, generated a receiving address with default bech32 format (starting with bc1)
scanned the qr code with mycelium (can send an receive bech32) and sent the transaction (was only a small amount for testing)
it went into the next block and got confirmed 3-4 times in 10 minutes
went back to core and ran rescanblockchain block_height_a_few_hours_back
but there's no new transaction. Core didn't notify me when it hit the mempool or the blockchain.
The send address in mycelium is the same as generated in core.
tried importing the wpkh xpubs to the wallet using importmulti, also success and success, rescanblockchain, but still no sign of the transaction.

So my question: where my money at? :) Can you help please?
 How can the watch only wallet derive bech32 addresses just by knowing the pubkeys? And why does it not see/report transactions it has created itself? It makes for a strange user experience.  Also the fact that the receive address is no showing/verified on the trezor makes it a bit scary process. This seems like the place where scammers would attack a noob like me.
That wallet.trezor.io does not support bech32 receive addresses doesn´t help confidence, altough that's not directly related to my issue I think.
Hope this makes sense. Thanks already for the help!!

Update
Thanks, Andrew!
I had to first index the transactions, took a little while. Below is the output of the commands. I am not sure what they mean though.

22:06:56
￼
gettransaction 1f10f68c1c21fbab3ddda0138cfb3dfec55e158f630c56997ea690adaece56e2

22:06:56
￼
Invalid or non-wallet transaction id (code -5)

22:07:14
￼
getrawtransaction 1f10f68c1c21fbab3ddda0138cfb3dfec55e158f630c56997ea690adaece56e2

22:07:14
￼
0100000000010159e285bec79b5287fc82eb200fe460537a3a299ee39b65755a8c61ad8a1443820000000000ffffffff0260e3160000000000160014bb7017605d2c404a9e161ae9a8b8d82166dcee3f9eac1f0000000000160014a38c7bd94c6daf16408338d1b424a1a7635faaf702483045022100deae3ae36d8373cffc4a925ac2ef68e12c855ce6451abcd9f91b651b73fda14602200b72c3b452eb97cb10a766976d3718e516d177e979ed576ba4c661decea90663012102b682a49236776bff9a29b844d4b1234202a628abdb10deab7924d87a682c5c7f00000000

The receive address I created shows in Bitcoin core as bc1qhdcpwcza93qy48skrt563wxcy9ndem3lu43d9r
The Blockstream block explorer shows that this is the address where the transaction was sent:
https://blockstream.info/tx/1f10f68c1c21fbab3ddda0138cfb3dfec55e158f630c56997ea690adaece56e2?expand
As far as I understand, it checks out.
Any idea why I cannot list it in Bitcoin core in the transactions list?

This is what the command return in core. I don't see the derivation path. Am I missing something obvious? The part with "ismine":false   is a little stressful lol.
Any idea?

20:33:00
￼
getaddressinfo bc1qhdcpwcza93qy48skrt563wxcy9ndem3lu43d9r

20:33:00
￼
{
  "address": "bc1qhdcpwcza93qy48skrt563wxcy9ndem3lu43d9r",
  "scriptPubKey": "0014bb7017605d2c404a9e161ae9a8b8d82166dcee3f",
  "ismine": false,
  "solvable": false,
  "iswatchonly": false,
  "isscript": false,
  "iswitness": true,
  "witness_version": 0,
  "witness_program": "bb7017605d2c404a9e161ae9a8b8d82166dcee3f",
  "ischange": false,
  "labels": [
  ]
}

I unlocked the trezor and tried this in the bash console. Based on what I understood about the displayaddress arguments.
The error messages are not clear to me.
$./hwi.py --fingerprint xxxxx displayaddress --path m/49h/0h/0h/1/*
{"error": "('Invalid BIP32 path', 'm/49h/0h/0h/1/*')", "code": -7}
$./hwi.py --fingerprint xxxx displayaddress --desc sh(wpkh([xxxxx/49h/0h/0h]xpub6DQ...../0/0))
bash: syntax error near unexpected token `('

I am still confused.

Why does the Bitcoin Core watch-only wallet not watch transactions that it lists in the 'Receiving Addresses'? Is this the bug you mentioned?
I couldn't find the path that was used to derive the address in getaddressinfo output.

But I get something out of the device that makes more sense.
$ ./hwi.py --fingerprint xxxxxx displayaddress --path m/84h/0h/0h/0/0 --wpkh --> trezor returns a bc1qxxxxxx address that is also in the list seen in Core at 'Receiving addresses'
Same with m/84h/0h/0h/0/1. But I imported 1000 addresses as you can see in my importmulti.
Is there any way to find the m/84h/0h/0h/0/n n-th address that correspond to bc1qhdcpwcza93qy48skrt563wxcy9ndem3lu43d9r? I don't want to have to for-loop 1000 tries with the trezor :D  Thanks!
Update
The fix with the manual edit worked! No for-loop needed haha.
I removed the sh() around wpkh and calculated/replaced the hash as you suggested. Did impotmulti and rescanblockchain and now the bc1 address shows up.
Thanks!
Now i have to figure out if the funds are spendable with a trezor.

Do either of gettransaction or getrawtransaction work for your transaction?

Are you able to display that address on your device using hwi displayaddress? You can find the derivation path using the getaddressinfo RPC. I think this is related to a rescanning bug in Core that I have been unable to nail down.

The getaddressinfo output indicates that your wallet isn't actually watching for these addresses. For the displayaddress error, your arguments are incorrect. You have given it the derivation path range that imported. You need to give it a single derivation path like m/49h/0h/0h/1/0.

The only way to figure out which index it is is to just try them all in a for loop. But there's one other thing I would like you to try first. Can you do the importmulti again but changing sh(wpkh() descriptor you have into a wpkh()? Don't use the wpkh() given by HWI. Rather take the sh(wpkh()), remove the beginning sh( part and the last ) you see. Also remove the checksum (the #.... stuff at the end of the descriptor). You will need to first use getdescriptorinfo with that modified descriptor to produce a correct checksum. Then you can import it with importmulti.

In a proposed edit of the question, the question author (under a different ID) wrote:

Update The fix with the manual edit worked! No for-loop needed haha. I removed the sh() around wpkh and calculated/replaced the hash as you suggested. Did impotmulti and rescanblockchain and now the bc1 address shows up. Thanks!
Now i have to figure out if the funds are spendable with a trezor.

(This Community Wiki answer created so that Q is removed from unanswered questions list)


text:
How Does the SPV merkle path form of multiple transactions in Merkle block looks like?
While I'm studying about the Bitcoin, I've wondered how many merkle paths should be contained in merkle block.
From the point of view of Merkle path, it is generated as the form of containing hashes of counterpart stepping up from bottom to top.
For example, if I have 4 transactions(let me use tx1, tx2, tx3, and tx4) in a block, then the hashes of them(h1, h2, h3, and h4) will be located at the bottom as the leaves. The parents of them will be (h12 and h34), after all, the merkle roots will be (h1234). So, if a SPV node want to verify that the tx2 is in the block, the full node can offer h1, h34 as a merkle path (as well as block header), so that they can prove as the step of hashing will lead them to the merkle roots which is contained in block header.
However, If I requests to verify multiple transactions in a block (e.g. using Bloom filter), then what would be contained into the merkle block (which contains merkle path and block header)?
Does they have multiple merkle paths for each transactions which are interested in, so that the transactions can be verified respectively? or adapted merkle path to be included which encompass all transactions related? (e.g. if we want to verify tx1, tx3 then generating h2, h3; though this exmample seems not to be guaranteed to show the order of transactions)

bip37 has fallen out of use, and isn't a default option in Bitcoin Core anymore, so therefor filtered blocks aren't really a consideration for new designs. You could conceivably have a format for describing multiple transactions and their intersecting (or not) paths within a block, but this was never supported by the Bitcoin p2p protocol.

Thanks for your answer first. Then how does the Bitcoin support for anonymity? I've read it from the book, Mastering Bitcoin. Further, I think there must be exist the case of multiple transactions included in a block which transactions are owned by same address. In that case, how can I request and response by using SPV?

SPV is just a mechanism of verification; it's orthogonal to the question of requesting block data. There are multiple ways (a) just request the full blocks (the most private), (b) use BIP157/BIP158 filters which let you find the blocks that contain txn you care about (and fetch those fully), (c) keep using BIP37 which does support requesting subsets of block txn (d) use a third-party protocol like Electrum's to ask for transactions (where you give up privacy to the server you're talking to).


text:
BTC-Wallet from "Airgap.it" asks for Receipient-Adress-Prefix "1ABC". What format is that?
I am trying to set up a Cold and a Hot Wallet.

Hot Wallet = "Exodus" on my everyday mobile phone. Adressformat is Bech32 with Prefix "bc1" or legacy-prefix from format "P2PKH" then adresses start with "1".
Cold Wallet = "Airgap Vault" on offline Device plus "Airgap Wallet" on everyday mobile phone. Both from "airgap.it".
I tried to send a test amount from the Cold-Wallet to the Hot-Wallet, but Cold-Wallet "Airgap Wallet" only accepts BTC-Adresses starting with Prefix "1ABC". How do I obtain this adress from my "hot" Exodus-Wallet and how is this adress-standard/-format called?

I could only find BTC-Cash-related entries in Google, but BTC-Cash-Adresses start with "q" or "bitcoincash:q". Also the wallet software would have to be very misleading, because BTC-Cash is not even supposed to be supported. I can't even imagine that, so I guess I am really dumb right now. Any help is very much appreciated, thank you!

As I had Exodus and AirgapWallet on the same device I used copy&paste for the address instead of QR-Code. QR-Code of the same address is accepted by Cold-Companion-App "AirGap Wallet". Possibly some really weird validation-error. Up till now I wasn't able to transfer funds due to other problems, though. I keep this Question open in the mean time.

The Prefix "1abc" is part prefix "1" and part wildcard "abc". so it asked for the P2PKH-format all along. there is NO secret third format with a fixed prefix that is always "1abc".
I reported the issue of the QR-code accepting BECH32-format with the developers. using the right address everything works like a charm and is a very nice alternative to a hardware-wallet if you have a old smartphone to spare.

I found fast and hands-on help in the Telegram-Group. If you have questions regarding airgap.it try https://t.me/AirGap


text:
how to create Bitcoin address , p2sh segwit and Bitcoin segwit address on python console from pubkey?
i am new on python,
i know it
how to create Bitcoin address , p2sh segwit and Bitcoin segwit address on python console ?
i  use https://github.com/richardkiss/pycoin
and command-line
(base) C:\Users\MM>ku 04c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee51ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a
 input                        : >04c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5\
                                  1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a
 network                      : Bitcoin mainnet
 symbol                       : BTC
 public pair x                : 89565891926547004231252920425935692360644145829622209833684329913297188986597
 public pair y                : 12158399299693830322967808612713398636155367887041628176798871954788371653930
  x as hex                    : c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
  y as hex                    : 1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a
 y parity                     : even
 key pair as sec              : 02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
  uncompressed                : 04c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5\
                                  1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a
 hash160                      : 06afd46bcdfd22ef94ac122aa11f241244a37ecc
  uncompressed                : d6c8e828c1eca1bba065e1b83e1dc2a36e387a42
 Bitcoin address              : 1cMh228HTCiwS8ZsaakH8A8wze1JR5ZsP
 Bitcoin address uncompressed : 1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m
 Bitcoin segwit address       : bc1qq6hag67dl53wl99vzg42z8eyzfz2xlkvxechjp
 p2sh segwit                  : 3FWHHE3RVgyv5vYmMrcoRdA25uugWvQbso
  corresponding p2sh script   : 001406afd46bcdfd22ef94ac122aa11f241244a37ecc

python console
(base) C:\Users\MM>python
Python 3.7.4 (default, Aug  9 2019, 18:34:13) [MSC v.1915 64 bit (AMD64)] :: Anaconda, Inc. on win32 Type "help", "copyright", "credits" or "license" for more information.

>>> from pycoin.encoding.hexbytes import h2b
>>> from pycoin.symbols.btc import network
>>> pub = '04c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee51ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a'
>>> hpub = h2b(pub)
>>> key = network.keys.public(hpub)
>>> key
<BTCSEC:04c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee51ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a>
>>> key.address()
'1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m'

I want generate these address on python console, but how ?
 Bitcoin address              : 1cMh228HTCiwS8ZsaakH8A8wze1JR5ZsP

 Bitcoin segwit address       : bc1qq6hag67dl53wl99vzg42z8eyzfz2xlkvxechjp

 p2sh segwit                  : 3FWHHE3RVgyv5vYmMrcoRdA25uugWvQbso

It seems you already have it?

first result  ms-dos command-line tool  "input pubkey", i want to python console, make address form pubkey.


text:
When did the main Bitcoin client become known as Bitcoin Core? When/Why/How did this happen?
Afaik at some point in 2014/2015, Bitcoin became known as 'Bitcoin Core'. I assume this was to differentiate it from other implementations of Bitcoin.
When and how did this decision come about?

You can read more about it here: https://github.com/bitcoin/bitcoin/issues/3203

"from other hard forked variations" => This looks confused. The name isn't related to a hard fork in any way. (Although later dishonest advocates of said hardforks tried to mislead people by using the renaming of the reference client as such.)

Thanks for this MCCS. I was looking for when the discussion occurred. Thanks for clarification Darosior, Ill change my phrasing in future :-)

The renaming was merged in December 2013 with prior discussion on this GitHub issue. The general motivation was to distinguish between one particular implementation of the Bitcoin protocol (many refer to Bitcoin Core as the "reference implementation") versus other implementations (libbitcoin, btcd, bcoin, bitcoin-s etc) that either existed at the time or came later.
At the time most of the well known altcoins (Litecoin, Dogecoin etc) didn't hard fork the Bitcoin blockchain. They started their blockchain from a different genesis block to Bitcoin. The well known hard forks came later in 2017 with BCH, BSV etc.

Thanks for this Michael, this is exactly what I was looking for :-)

As MCCCS commented, https://github.com/bitcoin/bitcoin/issues/3203 covers this

Rebrand client to 'Bitcoin Core' #3203

laanwj opened this issue on 5 Nov 2013 · 23 comments
laanwj commented on 5 Nov 2013
To remove the confusion between the Bitcoin network and the reference client implementation that we maintain in this repository, both confusingly named 'bitcoin', we'd like to rebrand the client.
This has been discussed a lot before, but the following is the proposal by @gavinandresen and I agree:
Bitcoin-Qt -->  btcore (full name 'Bitcoin Core')
bitcoind --> btcored (full name 'Bitcoin Core Daemon')
bitcoin-cli --> btcore-cli (full name 'Bitcoin Core CLI Client')

Renaming the executables is going to break some scripts, so we'd likely want to combine it with the bitcoind CLI deprecation to make sure the migration pain is short and swift instead of drawn out.

So the primary motivation seems to have been to avoid having the one word "Bitcoin" refer to both of two very different things - the network of Bitcoin nodes and a specific software implementation (one of many).

Thanks MCCCS. I did not realise we had terminology to differentiate between the network of nodes and software implementations. I had been referring so far in my work to 'Bitcoin clients' and 'Bitcoin nodes' ect to differentiate. Cheers for the clarification here :-)


text:
What was the first BIP9 block? Block 370,434 (0x20000007) or Block 398,364 (0x30000000)?
Block 370,434 (00100000000000000000000000000111) and (0x20000007)

Yes: BIP9 says set top 3 bits to 001.
No: BIP101 explicitly says set first, second, third and 30th bits to 1.
No: No mention of BIP9 anywhere in BIP101.
No: BIP9 was published after this block.

Block 398,364 (00110000000000000000000000000000) and (0x30000000)

Yes: This is definitely compatible with BIP9, but not explicitly BIP9. It is mentioned in BIP109.

In my opinion block 398364 is the first BIP9 block.
Block 370434 was signaling BIP101. As you say, BIP9 was not created at the moment and even if is was meant to signal BIP9, it would also signal csv and segwit which where not active at the time: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
Block 398364 uses a BIP9 format to signal BIP109. The 4th bit is used to indicate the block version, 0b00110000000000000000000000000000 (0x30000000) which is within the defined version range of BIP9. But other proposals used the last bits in the version number.
Block 407021 is the first block with version number 0b00100000000000000000000000000000 (0x20000000) so a clear vote for only BIP9.
The green line below shows the BIP109 blocks and blue line BIP9.


text:
When did BIP16 pass the 550/1000 threshold?
BIP16 says on 01 Feb 2012, if more than 550 out of the previous 1000 blocks include "/P2SH/" in the coinbase, then BIP16 will activate on 15 Feb 2012 (Source).
BIP16 was later revised. On 15 Mar 2012, if more than 550 out of the previous 1000 blocks include "/P2SH/" in the coinbase, then BIP16 will activate on 01 Apr 2012 (Source).
After searching the coinbase of every block, it looks like the 550 block threshold was reached at Block Height 171,455 on 16/03/2012 22:07:16. Since this is after the evaluation date of 15 Mar 2012, how/why was this considered to pass the threshold by the deadline, when it actually did not?
Any help appreciated. It is driving me nuts :-)


text:
Port 8333 closed, fwd on Router OK, firewall port open, full-node not reachable
I have set up my bitcoin/lnd full node and found out that port 8333 is closed.
When checking using https://bitnodes.io it tells me it's down
I've checked the router config and port 8333 is forwarded to the IP of the node.
If I scan or use telnet to connect locally to my node, it seems to be blocked.
Also ufw has been checked and sudo ufw allow 8333/tcp has been added.
As well sudo netstat -tunlp tells me that the port is in listen state.
Now, I'm kind of stuck and looking for help.
Many thanks in advance for a reply and stay healthy.

I have found bitnodes erroneously reports no inbound access (I use Tor, not sure if this is relevant). Check for inbound connections to your node with bitcoin-cli getpeerinfo and check the inbound field. If you have jq installed run: bitcoin-cli getpeerinfo | jq '.[] | {addr: .addr, inbound: .inbound}'. If your node reports inbound connections, the problem may be with bitnodes.

First, check your router opens that port too and redirects that port to you computer.
Then check CGNAT. If the external IP address your router shows isn't the same as you find when you search for "what is my ip", your ISP is giving the same IP to multiple customers. So you won't be able to open a port.

the port is open on the router and redirects that port to my node. the external address is the same as shown in "what is my ip" but I think that's not the problem, as on my internal network 192.168.1.* my net analyser show that port 8333 is closed.

I don't understand as the command sudo netstat -lptu, shows me that port 8333 is listening.
tcp        0      0 localhost:8333          0.0.0.0:*               LISTEN      6260/bitcoind

You can try from another computer in your network to use nmap or something like this to check if the port on your computer is reachable from your local network too.

if I disable tor, then port 8333 is open and can be seen by using https://bitnodes.io...

bitnodes.io has been spotty for me, especially when checking availability of .onion addresses, but also regular ipv4 addresses. I've had better luck checking availability with their API, as mentioned in this StackExchange


text:
Connection refused when using bitcoinrpc on Linux
I am new to python-bitcoinrpc(also new to VM Linux actually) and I want to use the blockchain parser from alecalve to get ordered blocks. I used Windows to download the blockchain data into an external hard drive as well as bitcoin.conf but then I found that this parser could only be used on Linux, so I downloaded Bitcoin Core again on Linux and run
./bitcoin-qt -datadir=/media/myharddrive/Bitcoin -conf=/media/myharddrive/Bitcoin/bitcoin.conf

to avoid re-downloading the data.
However, it seems I cannot connect to rpc because the simple code
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332"%('rpcuser', 'myrpcpassword'))

best_block_hash = rpc_connection.getbestblockhash()

returns error like this
Traceback (most recent call last):
  File "process1.py", line 129, in <module>
    parser(block)
  File "process1.py", line 62, in parser
    prevtxhex = rpc_connection.getrawtransaction(prevtxidhash,0)
  File "/home/lylian/.local/lib/python3.8/site-packages/bitcoinrpc/authproxy.py", line 132, in __call__
    self.__conn.request('POST', self.__url.path, postdata,
  File "/usr/lib/python3.8/http/client.py", line 1230, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.8/http/client.py", line 1276, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.8/http/client.py", line 1225, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.8/http/client.py", line 1004, in _send_output
    self.send(msg)
  File "/usr/lib/python3.8/http/client.py", line 944, in send
    self.connect()
  File "/usr/lib/python3.8/http/client.py", line 915, in connect
    self.sock = self._create_connection(
  File "/usr/lib/python3.8/socket.py", line 808, in create_connection
    raise err
  File "/usr/lib/python3.8/socket.py", line 796, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

I wonder if it's because my code cannot find bitcoin.conf(I put it both in the default location and my hard drive) or there is something wrong with my settings.
rpcuser=xxx
rpcpassword=xxx
server=1

Thanks very much!!

can you upload also your bitcoin.conf?

already did, it's just simple...

add rpcuser=sandbox , rpcpassword=sendbox, rpcport=8332 bind=127.0.0.1 and you can use this python script to test the node with python


text:
How to import address with private key using importmulti
Problem. importmulti function has a lot of parameters and they are more difficult to understanding then the parameters of another Bitcoin RPC-API functions. Those who are not profi in modern cryptographic achievements have difficult with understanding how to use importmulti function.
Here is the task that demonstrates the problem.
There is 2 wallets with the Bitcoin Core v.0.19.1:
wallet1 - the wallet with private key for export.
wallet2 - empty wallet into which we need to import the PK+address from wallet1.
So in the wallet1 we have the bitcoin address created by getnewaddress.
[root@wallet1 ~]# bitcoin-cli getaddressinfo 3M5e4QMBUYtpEewwuuoWCArpiM2fT4KEDy
{
  "address": "3M5e4QMBUYtpEewwuuoWCArpiM2fT4KEDy",
  "scriptPubKey": "a914d4b1b498c8be8813273937b834be6d9d1f488b9087",
  "ismine": true,
  "solvable": true,
  "desc": "sh(wpkh([675dc179/0'/0'/0']02607cb6c05a575fd040498ec8c44eabfa2a4f0fc320aeacf494a77b3a408d84af))#r6dvu4wk",
  "iswatchonly": false,
  "isscript": true,
  "iswitness": false,
  "script": "witness_v0_keyhash",
  "hex": "00144c88353345f2e03abc8e96b818fd030c3c9f59ab",
  "pubkey": "02607cb6c05a575fd040498ec8c44eabfa2a4f0fc320aeacf494a77b3a408d84af",
  "embedded": {
    "isscript": false,
    "iswitness": true,
    "witness_version": 0,
    "witness_program": "4c88353345f2e03abc8e96b818fd030c3c9f59ab",
    "pubkey": "02607cb6c05a575fd040498ec8c44eabfa2a4f0fc320aeacf494a77b3a408d84af",
    "address": "bc1qfjyr2v697tsr40ywj6up3lgrps7f7kdtvw6mnu",
    "scriptPubKey": "00144c88353345f2e03abc8e96b818fd030c3c9f59ab"
  },
  "label": "",
  "ischange": false,
  "timestamp": 1589545405,
  "hdkeypath": "m/0'/0'/0'",
  "hdseedid": "7cf768d4050dc142a69a149666798cc434045c6c",
  "hdmasterfingerprint": "675dc179",
  "labels": [
    {
      "name": "",
      "purpose": "receive"
    }
  ]
}

[root@wallet1 ~]# bitcoin-cli dumpprivkey 3M5e4QMBUYtpEewwuuoWCArpiM2fT4KEDy
Kwngf5FSYmHM5oPHjSoKxtHWUxXiQ5YN5ZR6shmzkYpMMftBh92c

I've tried to import that address to wallet2 but have failed.
[root@wallet2 ~]# bitcoin-cli importmulti '[{ "scriptPubKey": { "address": "3M5e4QMBUYtpEewwuuoWCArpiM2fT4KEDy" }, "timestamp":"now", "keys": { "Kwngf5FSYmHM5oPHjSoKxtHWUxXiQ5YN5ZR6shmzkYpMMftBh92c":0 }  }]' '{"rescan": false}'

result
[
  {
    "success": false,
    "error": {
      "code": -1,
      "message": "Missing required fields"
    }
  }
]

What the correct way to import that address using importmulti? Show the example please.

$ bitcoin-cli help importmulti
importmulti "requests" ( "options" )

Import addresses/scripts (with private or public keys, redeem script (P2SH)), optionally rescanning the blockchain from the earliest creation time of the imported scripts. Requires a new wallet backup.
If an address/script is imported without all of the private keys required to spend from that address, it will be watchonly. The 'watchonly' option must be set to true in this case or a warning will be returned.
Conversely, if all the private keys are provided and the address/script is spendable, the watchonly option must be set to false, or a warning will be returned.

Note: This call can take over an hour to complete if rescan is true, during that time, other rpc calls
may report that the imported keys, addresses or scripts exist but related transactions are still missing.
Note: Use "getwalletinfo" to query the scanning progress.

[...SNIP..]

Examples:

> bitcoin-cli importmulti '[{ "scriptPubKey": { "address": "<my address>" }, "timestamp":1455191478 }, { "scriptPubKey": { "address": "<my 2nd address>" }, "label": "example 2", "timestamp": 1455191480 }]'
> bitcoin-cli importmulti '[{ "scriptPubKey": { "address": "<my address>" }, "timestamp":1455191478 }]' '{ "rescan": false}'

As for your specific import you are passing the keys array (specified as such in the help, see the command above) as an object so bitcoind could not give you a helpful message :
$ bitcoin-cli importmulti '[{ "scriptPubKey": { "address": "3M5e4QMBUYtpEewwuuoWCArpiM2fT4KEDy" }, "timestamp":"now", "keys": [ "Kwngf5FSYmHM5oPHjSoKxtHWUxXiQ5YN5ZR6shmzkYpMMftBh92c" ], "redeemscript": "00144c88353345f2e03abc8e96b818fd030c3c9f59ab"}]' '{"rescan": false}'

[
  {
    "success": true,
  }
]

The result of your import is solvable=false. That's mean the private key have not imported.
But I need to do import specified address with private key.
The result of function importprivkey is 3 addresses in wallet. But I need only one that I specified.

I don't understand what you mean ? The error message here is clear : you can't import already imported keys.
Also, if you need to import external keys be sure to specify the redeemScript field.

derosier, thank you for your attention.
According to the task conditions, there are two wallets. One with the secret key. The second is new. Import must be done in the second (clean) wallet.
How I can get a redeemScript?

@kimon getaddressinfo outputs it as the hex field (see bitcoin-cli help getaddressinfo)

bitcoin-cli importmulti '[{ "scriptPubKey": { "address": "3M5e4QMBUYtpEewwuuoWCArpiM2fT4KEDy" }, "timestamp":"now", "keys": [ "Kwngf5FSYmHM5oPHjSoKxtHWUxXiQ5YN5ZR6shmzkYpMMftBh92c" ], "redeemscript": "00144c88353345f2e03abc8e96b818fd030c3c9f59ab"}]' '{"rescan": false}'
it works. thank you!


text:
Hi. Today I tried to sent coins to Mostyn Lewis Investment. But I sent it somewhere else?Where?
And here I sent it.Could you help me please. This is the adres I have sent it to;bc1qtpqqawlvye7elp3sp3snmfts7lfkqtduefe8jq so I do not know where I can find help.And where the money are sent to. I wanted to send it to Mostyn Lewis Investment. But it showed me from coinbasewallet that I do not have enough. Then I put all I had. And also checked it in blockchain explorer. A lot of confirmation and still confirming..where was this sent to?(back to me or I lost it) And I really do not know. If sb knows the answer even is bad, please answer me...Thanks

I sent it and do not know where to..I see that transaction in blockchain/explorer. I sent this bitcoins from Coinbase wallet. Please hulp me. I do not know what to do, and where is the money sent.I wanted to send it to Mostyn Lewis Investment. Scanned the QR code. And know nothing more...Sb van help me? Please. That was about 721euros.

You can (and should) edit your question to include additional information instead of adding comments. Putting that address into any blockchain explorer shows what has happened. About 721 EUR worth of BTC was sent from
bc1qtpqqawlvye7elp3sp3snmfts7lfkqtduefe8jq to bc1qpc3d32x4ujwkpc06etu97fxvleplsk5nc0aw3y on Tuesday at 15:21 UTC. --- That is all anyone can tell you.

Ok. Everybody can see..but what does it mean? I have already posted that question above. Sorry then. And what then..noone knows..Thanks for comment..probably I lost it..

Are you using the Coinbase app or the Coinbase wallet?. The first is custodial and so you must talk to Coinbase. The second is non-custodial - in which case, as well as the receiving-address you should know the sending-address and the transaction-id. Adding those to your question might help people here to work out an answer.

@RedGrittyBrick is saying that all we can know is that money was successfully sent to that address.  Presumably it's the same address that was encoded in the QR code you scanned.  If you were expecting Mostyn Lewis to do something after you sent the money, e.g. credit your account or respond in some other way, you have to take it up with them; we can't help you with that.

I'm sorry you sent money to a scam.

I have both. Coinbase app and Coinbase wallet. Money was sent from phone app wallet.I contacted Coinbase without answer. And about Mostyn Lewis I do not know what exactly happenned. At first when I scanned the QR it showed me that there is not enough money, what was not true. Many times. Scanning is easy. I do it always. But here was sth that I do not understood. I was confused and tried to send first not all cryptyo, but then i sent all. And I had to authenticate.After sending the portfolio was empty. I aprecciate your cares. Coinbase is informed. Blockchainexplorer too.Tomorow  I write more

Hello. I have contact Coinbase. They told me that they had looked and I have to wait about 7 working day...thank you all..i will let you know later then..have a good weekend


text:
library for validating bitcoin private and public keys
I am building a python script that gets a string and determines if it is a valid bitcoin private key or public key, and if so it returns its type/format (base58, BIP32, HexaDecimal etc.) and its derivations (public key from private key and address from public key).
Is there any free library that I can use its code inside mine, to get those details?
I have tried to do so myself but there are a lot of formats of keys and mathematical computations for validation and derivation the keys.
Thank you.

No sane application should EVER attempt to validate a private key by attempting to pass it to an external API. That's a ridiculously easy way to lose all your funds if the API operator is malicious, compromised, or someone is eavesdropping on your communication with said API.
You should do this yourself, preferably using a well tested, community supported, open source library for your choice of language - most major languages have such libraries.
If this is too much work, you should reconsider building something like this. Do not compromise on safety, especially if you intend for other people to trust this code with their funds.

I now see that I did not explained myself correctly. I meant that I need a library and not API (a code that I can download from github or somewhere else and use it in my code without copyrights issues). I will edit my question accordingly. thank you @Raghav Sood

See if this library will suit you
https://github.com/bitaps-com/pybtc


text:
How to reference different wallets with curl JSONRPC requests Bitcoin core
I have a headless Bitcoin core 0.17.1 running on Debian 10, and have created a second wallet "johns-wallet".
I'd like to get the walletinfo (or any wallet request) of that specific wallet via curl, not the cli.
The Bitcoin core API reference doesn't offer an example of how to target different wallets when not using the CLI (and neither did my Google search).
I've tried:
curl --user johnsmith --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getwalletinfo", "params": [] }' -H 'content-type: text/plain;' bitcoind:18332/wallets/johns-wallet/

and also
curl --user johnsmith --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getwalletinfo", "params": ["/wallets/johns-wallet/"] }' -H 'content-type: text/plain;' bitcoind:18332

And also variations on the path itself to the wallet - none of them return a result, let alone an error.
Running without trying to specify a wallet returns:
{"result":null,"error":{"code":-19,"message":"Wallet file not specified (must request wallet RPC through /wallet/<filename> uri-path)."},"id":"curltest"}

(In case it matters, the Bitcoind is running in a docker container, with a named volume)

Off the top of my head, the path needs to match the wallet path relative to your datadir - so bitcoind:8332/wallets/john only works if your wallets are actually in $datadir/wallets/. I might be wrong on this though

This is the command I use - the http address is the address of the docker container that the Bitcoin daemon is running in
curl --user johnsmith --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getbalance", "params": ["*", 6] }' -H 'content-type: text/plain;' http://10.0.0.1:18332/


text:
How to deal with situations when the buyer tries to gain the system? (online shop with price in fiat, BTC payments also possible)
I'm a developer. I have a custom online store, with code I wrote myself, where I sell products in fiat money. I plan to introduce payments in bitcoin.
Issue: the customer may try to gain the system by taking advantage of the fact that bitcoin price always fluctuates.
For instance: on Monday BTC, or any abstract coin, costs $100, and on Tuesday it will  $75.
A customer makes an order of $500 on Monday, with an intention to  pay in BTC. The shop will generate price for thim: $500 => 5 BTC. But a customer waits a day ("may be tomorrow BTC will  decline? Let's see") and sends those 5 BTC on Tuesday but claims that he really sent bitcoins on Monday.
That is, he should've sent me 6.66.... BTC (rate of Tuesday, $500 = 6.66 BTC) instead of 5  BTC (rate of Monday, $500 = 5 BTC).
I end up loosing 6.66 - 5 BTC = 1.66 BTC as of Tuesday.
Question:
How to deal with such situations?
How would I know that a customer sent me coins on Monday, when BTC was more expensive, and not on Tuesday?
Note:

At this point I don't want to run a full node, because I  want to keep things simple. It's for now. I'm using Electrum and I think  its API will do. Or at least semi-manual checking for bitcoin payment  will work because I don't expect tons of orders, let alone in bitcoin.

I don't consider third-party payment processors or software to resolve this issue. I may use some  public API of those, but I don't want to sign with them, go through KYC,  pay them fees...
Electrum the wallet is ok at this stage, something similar will do to.

The question is about an algorithm and isn't about software or payment service.

I think the BTCpayserver software will work for you. It is an open source project that allows you to self host a bitcoin payment gateway. It will take care of the issues you are worried about.

@chytrik you don't understand. I'm telling you "I'm a car manufacturer, how do I deal with a problem X"? You're telling me "You just buy Ford and it'll work as is". I'm not asking what software to use.

You seem to be somewhat confused about how currency markets, specifically for Bitcoin work, so I'm going to breakdown how a payment service using Bitcoin works for using your example.
You have a shop that sells an item, let's say a basket, for $500.
On Monday, 1 BTC = $100. The customer places an order on Monday, and you generate an invoice based on that price - the customer needs to send you 5 BTC. You note down the time you generate this invoice, let's say 13:00.
Scenario 1:
The customer sends you 5 BTC on Monday AND it is mined into a block within 60 minutes of your invoice being generated. That means the block must be mined prior to 14:01 on Monday.
In this case, all works well - you have your BTC, and can proceed to liquidate it for fiat at the price you intended
Scenario 2:
The transaction is broadcast on Monday, but is not mined into a block on Monday, either due to slow block times or low fees.
In this case, after 60 minutes from the generation of the invoice have elapsed, you simply cancel the order, and send back a transaction that refunds the BTC to the customer - remember, a refund transaction can be made even if the parent is unconfirmed, they will both be mined in sequence.
You should only make a refund using the incoming coins to avoid certain classes of attacks.
Now, the customer can attempt to place a new order if they still wish to proceed - the new order will be invoiced using the exchange rate at the time of the new order.
Scenario 3:
The transaction isn't broadcast until Tuesday, but the customer claims it was sent on Monday.
This is effectively the same as Scenario 2 - the order is cancelled 60 minutes after it was placed, and once the transaction is sighted on the network on Tuesday, you make a refund transaction.

This is the only sane way to achieve the kind of price fluctuation protection you're asking for - if this is not acceptable for your use case, you should consider working with less volatile coins, or coins with faster block times where this is less likely to be an issue.

Ok. Yes, but the customer may not be aware of the difference the low and normal fees make in terms of pace of propogation or mining of a transcaction. Should I advice the customer about that or what? How would I calculate the amount of fees that'll make  a transcaction to be delivered within 60 minutes, in order to suggest that amount to a customer?

Moreover, even if the customer sest a good fee, it doesn't guarantee that a transaction, or at least the 1st confirmation, will arrive withing 60 minutes, does it?

Bitcoin Core offers a fee estimate API which gives you a suggested fee for confirmation within a number of blocks specified by you, and no, it is not guaranteed to confirm in 60 minutes, or at all, even with high fees

I won't run a full node. Can using Electrum wallet and its timestamps be relyable for this case, what do you think? I may use Electrum wallet manually, because I don't expect many BTC payments. Or perhaps API of Electrum servers or wallet directly too. Or perhaps, some other public free APIs of other companies. The bottom line, I won't run a full node on my own for now and will be using either Electrum desktop app or some free public APIs.

The electrum API also has a fee estimation method: https://electrum.readthedocs.io/en/latest/protocol.html#blockchain-estimatefee. The choice of API is not really important, as long as you are aware and able to deal with the currency fluctuations, or have a way to refund BTC when it is uneconomical for you

All you need to do is generate an invoice in your backend system at the time of checkout, which includes a specific amount of BTC to be paid, to a specific address. Then you just need to watch for payments to that address, and can consider the order 'paid' if an incoming payment for the correct amount of BTC is confirmed in a block.
In the event an incorrect amount of BTC is paid, you could simply create a customer service policy that stipulates a refund will be paid back to the customer (less transaction fees, perhaps).
As a suggestion, the open-source BTCPayServer project might work well to solve your problem. During checkout BTCPayServer generates an invoice requesting a specific amount of BTC, payable to a specific address, with a customizable time-out period for the payment to be considered 'completed'. If the software itself isn't quite what you want, you could at least consider copying it's workflow.

You haven't grasped the core issue raised in my question.

I understand your issue to be "How do I deal with accounting for payments, when the BTC/USD exchange rate is fluctuating?" My answer is: at the specific point in time when the sale occurs (during 'checkout'), you declare an amount of BTC to be paid (according to the $ value of the item and the exchange rate), and then expect the customer to send that amount. Can you elaborate on how this doesn't answer the question, or what the actual question is?

Sell me 10 bitcoins for  $10 -- the price I'd have paid for them 10 years ago.

No, the issue isn't How do I deal with accounting for payments, when the BTC/USD exchange rate is fluctuating?"

@Leloucha that issue is why the invoice you generate should have a time limit on it, that the payment must be confirmed within. As per your example, obviously any offer to buy/sell bitcoin would be time-limited. As a savvy trader, I would offer my BTC at the going rate, but put a time limit on that offer, so that years later someone couldn't take advantage of me by claiming a long-past exchange rate.

Exchange-rate-risk is something to be considered, for certain. I'd suggest considering a timeout for payment confirmation of maybe just an hour, or a few hours at most, so that you can be fairly sure that the price won't change much while you are awaiting payment.

Yes, time limit. But I said "how do I ensure that a customer sent coins within that time limit?" provided that there're delays in bitcoin network. And also that with low fees a payment, even the 1st confirmation, may take a day to appear

How would I know whether a customer tries to gain the system by lying or it's been a delay in the network due to a low fee / delay on its own (overload)?

Software can simply watch the address that was specified in the invoice, for an incoming payment of the specified amount. If a payment does not confirm before the invoice times out, then the invoice is considered unpaid an invalid, and any BTC received after that could simply be returned to the sender (how this is done might take some consideration, but that is the basic idea at least). There is no need to worry about being gamed: you set the rules of the transaction at the time the other party is invoiced. They either make the payment correctly, or not.

Software! Yes! Re-read my question, software-man

I will be very impressed if you manage to build a system to receive bitcoin payments, that involves no software... but in any case, yes, the software would watch for a payment to be confirmed. Under the hood, this means that a transaction which pays you (as specified in the invoice) has been included in a new valid block on the bitcoin network. If you see this block arrive before the invoice times out, then the transaction would be considered complete. If no block contains a transaction paying you before the timeout period ends, then the transaction is to be considered incomplete.

@chytrik I think you are wasting time, I gave an answer that got a -1 because started with "You can try some service" without even understanding I was suggesting to use a service as an user to see how it behave, going then deeper explaining how they works and why.
His attitude isn't worthing the effort to reply.

You can try some service doing what you want and see how they behave.
For example many of them (if not all of them) give you a time window to send the required amount.
Most of the time it's not important that the transaction is confirmed but it has to be sent in that time frame window so it can be seen in nodes memory pool.
When the transaction is found in memory pool, these services entry in a "confirming transaction" phase, where the order isn't confirmed yet until the transaction is included in the blockchain.
Some services accept the order once it has one confirmation, other that play more on the safe side wait 6 confirmations, it's up to you and to your risk profile.
Waiting full confirmation time (6 confirmations) of course mean the end user has to wait more time to have it's order accepted so it's a worse user experience.
Note that if you aim to automatically move sent BTC somewhere else you could technically do that even before the transaction is fully confirmed, in case you want to convert btc to fiat as you get the payment, sending btc to an exhange or what
You still have to consider refunds problem, not sure the effort is worth not using a 3d party service. Consider for example an user that sends you money after the time window, it's up to you to handle it (if accept anyway the order or don't consider the payment as valid)
If it's not valid, you may want to request some more fund to the user, so you need a support effort, in some case the user want a cashback so you have to send funds back to him (and probably not at the same address the money came from).
There is more to talk about but already this is something that should make you think about pros and cons of DIY solutions

I don't consider third-party payment processors.

if you gave the -1 then tell why, because I explained how a solution you try to build usually works and what are the difficulty you have to deal with, that's not worthing the -1.
When I said "you can try" of course mean as an user, so pay using other services.
I gave you something to think about and you aren't polite at all.
Other answers says same thing about using a time window.


text:
In Bitcoin, what happens if there is no viable nonce?
I'm assuming SHA is perfectly uniform.
In bitcoin, there are $2^{32}$ possible inputs per block, which are mapped to $2^{256}$ possible outputs. So there is a $1/2^{224}$ chance that any randomly picked 256-bit string is a possible output hash of one of the possible nonce values. So that means there are $2^{32}$ possible output 256-bit strings. In other words, a 1-to-1 mapping from nonce to output is very likely.
The $2^{32}$ possible outputs are distributed uniformly. So that means half of them have a 0 in the first bit, and the other half have a 1. That means there are $2^{31}$ possible outputs with a 0 in the first bit. Each leading 0 bit reduces the number possible outputs by half. So with 76 leading zero bits (the current difficulty), there's a $1/2^{44}$ chance that there exists a acceptable nonce.
Another way to see it is that there is a $1/2^{76}$ chance that any nonce is accepted. But there are $2^{32}$ possible nonce values. So the probability that none of those nonces are acceptable would be $(1-1/2^{76})^{2^{32}}$ which equals $1/2^{44}$.
Either way you look at it, there's an extremely small chance that any 32-bit nonce will work.
So what happens if there are no acceptable nonces?

related: https://bitcoin.stackexchange.com/q/96434/5406, https://bitcoin.stackexchange.com/q/22978/5406

It's important to note that the block hash is over the entire block header, which contains:

Block Version
Nonce
Previous block hash
Timestamp
Merkle Root
nBits

Of these, only the nBits and previous block hash are fixed - all of the others can be manipulated to alter the hashed data at will.
Once all 32 bits of the nonce value have been exhausted (which happens extremely fast on ASICs), miners will simply alter the timestamp, block version, or merkle root (by altering the coinbase transaction or changing their list of selected transactions/their ordering), allowing them to try a new block header with the entire nonce space again.
These alterations are repeated until some combination of the above produces a valid block hash.


text:
What determines BTC's wallet size in bytes?
Does wallet.dat contain every address that I created?  Even if I didn't get any coins from it?
To be clear, suppose I run bitcoin-qt in Linux, and, in the GUI, I click on Receive then click on Create new receiving address:

At this point, no coins are received.  Will this immediately generate a new public-private key pair?   How was this public-private key generated?
Is this new key pair stored in wallet.dat even before me receiving any payments?
I receive coins on that address.  Will this affect the size of wallet.dat?

Basically I'm concerned on the size of wallet.dat as I keep creating new receiving addresses.
What determines the size of wallet.dat?  It's about 1.4 MB now.  What made it so?  What will make it change?
This is a graph showing how wallet.dat's size increases as I keep adding new addresses:

Looks pretty linear to me with a slope of 1135.0361445783133 bytes per address.  I wonder why is this?  Is it because wallet.dat is storing a whole new public-private key pair per address?  Or what is happening?
I then delted all those addresses, but  wallet.dat's size didn't reduce.  In fact it even increased!

Does wallet.dat contain every address that I created?  Even if I didn't get any coins from it?

Yes

To be clear, suppose I run bitcoin-qt in Linux, and, in the GUI, I click on Receive then click on Create new receiving address:

At this point, no coins are received.  Will this immediately generate a new public-private key pair?

Yes. Well, not quite, but in essence, yes. Bitcoin Core pre-generates 1000 keys in a structure known as the keypool. When you request a new address, one of those pre-generated keys is returned to you and another one is generated to replace it in the keypool. This replacement generation can be deferred to a later time, if, for example, your wallet is locked.

How was this public-private key generated?

Depending on when you created your wallet, either randomly, or with BIP 32. Newly created wallets with modern versions of Bitcoin Core will use BIP 32. BIP 32 is a deterministic way to generate keys from a randomly generated seed. Bitcoin Core randomly generates the seed and derives the actual private keys from it using BIP 32.

Is this new key pair stored in wallet.dat even before me receiving any payments?

Yes

I receive coins on that address.  Will this affect the size of wallet.dat?

Yes. When you receive a transaction, that transaction is added to the wallet and this will increase the size of the wallet.dat.

Basically I'm concerned on the size of wallet.dat as I keep creating new receiving addresses.
What determines the size of wallet.dat?  It's about 1.4 MB now.  What made it so?  What will make it change?

The size is largely determined by the number of addresses you have requested already, the size of the keypool, and the number of transactions that you have, both incoming and outgoing.

Looks pretty linear to me with a slope of 1135.0361445783133 bytes per address.  I wonder why is this?  Is it because wallet.dat is storing a whole new public-private key pair per address?  Or what is happening?

Yes.
If your wallet is unencrypted, each new keypair that is generated will add at least 388 bytes.
If your wallet is encrypted, each new keypair will add at least 120 bytes. This size difference is because encrypted private keys are encoded more efficiently than unencrypted private keys.

I then delted all those addresses, but  wallet.dat's size didn't reduce.  In fact it even increased!

Bitcoin Core does not allow you to delete addresses. However you "deleted" them, it was likely just hiding them.

If you want a smaller wallet, then you should create a new encrypted wallet. Note that this means creating a new wallet and choosing the option to make it encrypted. Creating a new wallet and then encrypting it after the fact will create extra keys that are never used and just take up space.

Thanks.  Extra questions:  (1) will that newly encrypted wallet contain coins in the big wallet that I used in the past?  (2) Mathematically, why should each wallet have a public-private key pair for each receiving address?  Can't we have a single public-private key pair proves its ownership of all receiving addresses?  This way, a wallet will have a single public-private key pair, and it can scan the entire block chain and discover all coins that belongs to it.  This way the wallet will not grow bigger over use.  Any reason this is not done?

New wallets are independent of other wallets. They will not contain anything from any othre wallet. 2) A single keypair does not have multiple addresses. In order to have multiple addresses, you must have multiple keypairs. Reusing addresses is not advised due to the privacy risks of doing so. The wallet size is really not a factor until you get into the tens of thousands of transactions.

Is the wallet size a problem for stores that sell in BTC? I guess they have millions of transactions every year?

Businesses generally don't use Bitcoin Core for their wallet because it is harder to integrate it for processing payments. It also does not work well with extremely large wallets. Such businesses generally either use a service provider (who has custom software) or a software geared towards business use such as BTCPayServer.


text:
Why doesn't BTC reward miners for confirmations, too?
Currently as far as I know when a miner discovers enough 0s, he
broadcasts his solution to the network in order to win the coins.
While, he broadcasts his solution (which gave him the 0s), he also
verifies some transactions.
When miner verifies transactions, the gives priority to the transaction
that pays the highest confirmation fee.
As far as I understand, when the miner verifies transactions that do not
pay any confirmation fees, the miner doesn't get any rewards for doing so.
In such a case, the miner has absolutely no reason to care to verify it.
If the miner verifies such a fee-less transaction, he does it purely
because he is just a kind person, but no monetary incentives for this act.
My question is: why doesn't the BTC protocol define the BTC reward
function as a function of the solves 0s and as a function of number of
confirmations?
Specifically, I propose this reward function:
btc_reward = ZEROS_DISCOVER_REWARD
for transaction in confirmations:
    already_has_n_confirms = get_confirms_num(transaction)
    confirm_reward_rate += L / (1 + E**(K*already_has_n_confirms)
    btc_reward += confirm_reward_rate * CONFIRM_REWARD
    btc_reward += confirmation_fee # could be zero, and miners would still
                                   # have incentives to confirm, because
                                   # the btc network still rewards by
    other means.

where L, E, K and CONFIRM_REWARD are variables that need to be
tuned to adjust BTC's inflation/deflation targets (similar to like how
ZEROS_DISCOVER_REWARD is defined).
Of course this is just a suggestion for funrction with an exponential decay
as a function of number of confirmations a transaction already has.  E.g.
transactions with no confirmations are in a more disperate situation to get
some confirmation that other transactions that have, say, 10 confirmation
salready.
This way, miners will have a monetary incentive to confirm all transactions
even those that pay no confirmation fees, which will effectively reduce
the resistance against trade in the BTC world, and make BTC even more
attractive.
At the same time, people who are in a hurry can still put
their fees to get their confirmations faster.  But at least, those who are
engaging in a low-cost economy that is sensitive to fees at least have the
liberty of having a free monetary system.
Any thoughts on why this isn't done?

There seems to be a misconception in this question: once a transaction is included in a block, each subsequent blocks does indeed give it "additional confirmations". The way the question is worded, I understand it to imply that miners must otherwise choose to add additional confirmations to already-confirmed transactions-- but this is not the case.

@chytrik - Oh right.  Thanks a lot for pointing this out.  Yes I did indeed have this misconception.  My whole idea above is in part meaningless, and in part a bug.

I'm not 100% sure I've understood your suggestion, in part because you've used some non-standard terminology.
But it looks like this is actually two suggestions rolled into one.
The first is a mechanism to incentivize miners to include transactions which have little or no fee.
That is a bug, not a feature, for two reasons:

Including transactions in the blockchain is costly. Every transaction needs to be processed not only by every node that operates now, but every fully validating node that will ever start operating in the future. The more transactions there are, the harder it is to run a node, and the less decentralized the system is.
This is why we don't want people to have the opportunity to spam the network with transactions of low economic value (due to either negligence or malice). If someone wants to have their transaction included, they have to pay for the privilege. That's why there is a limit on the block size, and users compete with fees on the right to enter the block.
Low-value payments is what we have the Lightning Network for.

A core principle of Bitcoin is to have a known monetary policy. Every reward obtained by a miner has to come from somewhere. Either from the pre-agreed inflation schedule for Bitcoin, or from already existing coins paid by users as fees. You are suggesting that miners should be paid above and beyond the inflation schedule and the user fees. Where will the money come from?
This problem is not completely insurmountable - but it's not really a simple matter of tuning a few parameters, and it does complicate the issue.

Your suggestions also seems to hint at the possibility that fees for a transaction will not be just given to the miner who includes it in a block, but rather divided between that miner and future miners who built on that block. This is similar to what I suggested here. But this is not really effective enough to be worth the trouble.


text:
Add inputs and outputs to a transaction signed with sighash SINGLE | ANYONECANPAY
I created a transaction with one input and one output, and signed it using sighash SINGLE | ANYONECANPAY.
Can I add further inputs and outputs with another wallet using bitcoin-cli?


text:
Zero Day BlockChain Timezone Exploit
Couple weeks ago, a new Blockchain exploit was found by a hacker named: Zer0dayxploit
unfortunately, i am not a tech person, but it seems you can earn abt 500$ a day with this exploit!
He wrote a paper about this exploit, u can find it here:
Exploit paper
Can some explain to me how this works?
Regards

The method described has absolutely nothing to do with Bitcoin or blockchain exploits. It appears to be exploiting a badly designed payment system, which allows a user to unilaterally cancel a payment by altering the timezone.
This leads the payment processor to think too much time has elapsed (many payment processors impose a time limit by which a deposit must be made to avoid price fluctuations and other issues). Per normal procedure for an expired invoice, any payment is refunded to the user.
The site mentioned in the link appears to credit the user regardless of whether an invoice is expired or not. This is entirely the fault of a poor system design/integration between the payment processor and the integrating website, and exploits absolutely nothing in the Bitcoin protocol, node software, or wallet implementations.
It's basically the equivalent of you selling me something for $100 on the condition that I pay you within 10 minutes, and cancelling our transaction because I showed you the time on my phone (which I can change as I want to) which indicates more than 10 minutes has passed. Then, you refund me $100 if I pay you (since you think the transaction is cancelled), but your accountant considers it complete and ships out the goods anyways.


text:
How do I create a wallet with a 24-word phrase?
How do I create a wallet with a 24-word phrase instead of a 12-word phrase? I have used a couple software wallets such as Coinbase wallet and Exodus wallet which associate the wallet with a 12-word phrase. Basically, what software wallet can I use that is associated with a 24-word phrase?

Why do you want to do this?

@Anonymous I do not feel 12 word wallets are safe enough


text:
How can the segwit witness data be "off-chain"? What does it really mean?
I have several questions regarding the segwit witness data. My current understanding is as follows.
Before segwit, the witness data was part of the input that the user had to provide so that they could spend an UTXO. The witness data is the digital signature or any other solution that allows an UTXO to be spent. The input was not comprised only of the witness data, but the witness data could be a large part of the input.
Thus, with segwit, the witness data was separated from the rest of the input. More specifically, the witness data is now "off-chain". This made the input much lighter and, in turns, it made spending an UTXO cheaper and faster to process.
My questions are:

Is my understanding above correct?

What do we mean when we say that the witness data is "off-chain"? If it's not part of the blockchain, where does it reside? Does it mean that nodes process witness data differently from the rest of the input data?

While I understand that the input itself is now lighter, the user still has to provide the witness data in order to spend the UTXO. Wouldn't the witness data need to be relayed alongside the rest of the input so that nodes can make sure that the transactions are valid? How can there be a gain of efficiency?

No, that's not accurate. Witness data is on-chain, inputs have a similar byte length as before (they are just weighed differently), and the transaction throughput is increased because segwit is a defacto blocksize increase.

Thus, with segwit, the witness data was separated from the rest of the input. More specifically, the witness data is now "off-chain". This made the input much lighter and, in turns, it made spending an UTXO cheaper and faster to process.

This is a common misunderstanding perpetuated by an abundance of (sometimes deliberately) confusing descriptions of how segwit works.
A transaction is not complete without the proof that it was authorized by the owner of the spent funds. As such, the witness is explicitly part of a "complete transaction". What segwit did was to segregate the witness (read "signature") out of the input script and move it to the "witness section" of the transaction. The witness section is at the same hierarchical level as the inputs and outputs.
The witness section is excluded when calculating the transaction id (txid), but it is part of the transaction, and used to calculate the witness transaction id (wtxid). While the merkle root in the blockheader commits to the txids of the included transactions, each segwit block additionally commits to a merkle tree of the transactions' wtxids. In conclusion, the witnesses are a) part of the transaction, b) part of the blockchain, c) necessary to fully validate the blockchain.
Segwit replaced the blocksize limit with a blockweight limit. The blocksize was based on the raw byte length of transactions and capped at 1,000,000 bytes. The blockweight limit is capped at 4,000,000 weight units, where weight is calculated by counting witness bytes with a factor of one, and non-witness bytes with a factor of 4. This happens to result in an equivalent limit if a block only includes transactions without witness data.
The actual transaction data of a segwit input compared to a non-segwit input is only marginally smaller. It is the discount of witness data that allows blocks to exceed the previous blocksize limit, making segwit an effective blocksize increase with the biggest block to date having 2,422,858 bytes (but 3,993,379 weight units).
Segwit transactions and blocks are made forward compatible to pre-segwit nodes. Segwit nodes will strip the witness data before relaying the data to pre-segwit nodes. The stripped transactions and blocks are non-standard but valid according to the pre-segwit protocol rules, and thus pre-segwit nodes can follow the blockchain and converge on the same UTXO set.
Note that pre-segwit nodes have not been "fully validating nodes" since segwit was activated on August 24th 2017 as they do not unilaterally enforce all consensus rules of the Bitcoin protocol.

Thanks; this is much clearer to me, now.

Just raising the blocksize limit to 4 MB would have not been forward compatible and old nodes would have been forked off.


text:
Compatibility questions regarding Native Segwit addresses
I have a question regarding Native Segwit addresses. I understand that those addresses are more efficient and that you save on fees when you send BTC from them. However, does it matter which type of address (legacy, segwit, Native Segwit) the recipient uses? Will I get the same fee reduction benefits no matter what?
Also, I often read that many wallets don't properly support Native Segwit addresses. My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?

Sending bitcoins means to lock funds to a specific output script. The output script determines how the funds can later be spent. E.g. if funds were sent to a P2WPKH (Pay to Witness Public Key Hash) address, they can later be spent using a P2WPKH input script. If funds were sent to a P2PKH (Pay to Public Key Hash) address, they have to be spent using a P2PKH input script instead.
The (native segwit) P2WPKH input script has less weight than the P2PKH input script, so receiving funds to P2WPKH addresses will save you fees when you later spend those funds. The output scripts for both are similar in size.

Funds of any type of input can be assigned to outputs of any type in a transaction. You can even mix: spending a native segwit and a non-segwit input, and sending to a non-segwit and a native segwit output in one transaction works fine.
However, as you say, some wallets may not support sending to native segwit addresses. In that case, the receiver should fall back to providing a backwards compatible P2SH-wrapped segwit address which is still cheaper than non-segwit but can be sent to by almost all wallets. You can track native segwit adoption on Bitcoin Optech's Compatibility Matrix or whensegwit.com.

My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?

Correct. A wallet that does not know how to interpret native segwit addresses would not be able to spend funds received from a native segwit address. This is not a problem in practice, because the receiver provides the spender with the invoice address they want to receive the funds to. The receivers wallet will not generate a native segwit address, when it is unaware of native segwit.