I guess they just call "getblocktemplate".

1. If block_time > last_block_time+1200, then difficulty=1
2. Otherwise, difficulty=network_diff

Note that every miner can control "block_time", because it is just what is put in block header. By default, Bitcoin Core gives you the earliest time (based on the current time, the MTP rule, and the timewarp 600 seconds rule). But: you can put some later timestamp there, to trigger "difficulty=1" condition.

There are only two options: the network difficulty, and the minimal difficulty. If you want to get the network difficulty, then just check the latest block, where it was adjusted.
But, miners are not calculating "0x1913e3b7" for every block. They can do it just once per 2016 blocks.

https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L14
See? This "CalculateNextWorkRequired" function is called only every 2016 blocks. In all other cases, the code is just copy-pasting "nBits" from the nearest block header, which contained the real network difficulty.

Well, if you have for example 336 ASIC-mined blocks, and 1680 CPU-mined blocks, when you explore the latest 2016 blocks, then having 336 blocks with 216M gives you the same chainwork, as 2016 blocks, mined with 36M. Because during difficulty adjustments, all that is counted, is just "how fast the last 2016 blocks were mined", and not "how many hashes were needed to do that".

Exactly. Initially, you have a network with all ASICs, where 100% blocks are honestly mined. Then, when CPU miners abuse 20 minutes rule, it means 2016 blocks are produced faster, than they would be in 100% ASIC world. So, the difficulty is increased, and in the next two weeks, ASICs can produce even less blocks. And that situation keeps repeating, as long as other limits are not reached. And then, the difficulty put in ASIC blocks no longer reflect, what they can mine during 10 minutes.

Just use "getblocktemplate", and check, which value is displayed there. Now, I don't use "getdifficulty", in the same way, as I don't use Bitcoin Core's fee estimations.

Well, the network difficulty was supposed to change once per 2016 blocks (two weeks). Test networks broke that assumption, so if some website assumed that, then it can treat "difficulty=1" incorrectly. The best way is to check "chainwork" instead.

If you have more than 80% blocks, mined with the minimal difficulty, then the consequence is that the difficulty, declared in block headers, is measured not as "the difficulty per 10 minutes", but rather "the difficulty per hour" instead. So, if you see "testnet4_diff=6000", then you should read it as something like "testnet4_diff_per_10_minutes=1000" instead.

Think about it in that way: you start from some honest network, where 100% blocks are mined by ASICs. You can see 2016 blocks with real difficulty, per two weeks. If CPU miners can join it, and mine half of the blocks, then you have 1008 CPU blocks and 1008 ASIC blocks per week. Then, the difficulty is doubled. And then, you have 504 ASIC blocks (because of unfairly raised difficulty) and 1008 CPU blocks in the next week, so the next time, the difficulty is raised again. And so on, and so on. Until reaching an equilibrium, which seems to be something around 1/6th of blocks, mined by ASICs. So, instead of having "the difficulty per 10 minutes", you have "the difficulty per hour" instead. And the main rules, which are stopping the difficulty from raising infinitely, are just Median Time Past on the last 11 blocks (strong consensus rule), and 2 hours rule (de-facto standard, non-consensus rule).

If you want to get accurate values, then look at chainwork. It can tell you, how many hashes were needed, to make the chain.

It will not. Because it will be a hard-fork, leading to just another altcoin.

However, you don't need changes in supply. All you need, is just changing proportions. So, you can have a subnetwork, which will use different amounts, and it can work on top of Bitcoin, as long, as you can make it backward-compatible, and represent on-chain amounts correctly.

For example: Lightning Network introduced millisatoshis. Every on-chain satoshi is converted into 1000 millisatoshis, and then, it is converted back from 1000 millisatoshis, into a single satoshi. However, there are no technical barriers, which would stop people from introducing non-linear dependencies, where you could have 21 billion coins limit, and where it could be possible to create more coins, out of thin air, which would exist only in a particular L2. So, for now, we have a constant 1:1000 peg. But: it is possible to make "a different tail supply L2 network", which will have different rules.

Minimal on-chain fees are set into 1 sat/vB as a de-facto standard. It was not changed for a long time, and it seems, that it will not change in the future. Assuming 4 MvB fully filled blocks, it means getting at least 0.04 BTC per block in fees. So, after next halvings, the basic block reward will go below 0.04 BTC, but fee rules may be left unchanged. Then, is 0.04 BTC per block not enough, if the basic block reward will be lower than that?

Some people underestimate changes like full-RBF. If you have two on-chain transactions, where one is spending coins from the other, and you have a chain of unconfirmed transactions, then you can batch them, and increase feerate, without adding new coins. If you have one transaction taking 1 kvB, and another transaction taking another 1 kvB, then by batching both transactions, the batched version could take for example 1.5 kvB, which would also bump fees, so miners would have an incentive, to include batched version instead.

I think sooner or later, we would need something like "batched mempool explorer", where instead of seeing, that "we have 650 MB transactions waiting", people could see for example "we have 400 MB transactions waiting, if all of them will be batched".

Why do you think, that "fee rates" is the barrier? For example, I sold almost all of my BTCs, because of new KYC/AML rules, being enforced since 30 December 2024. I used BTC in 2019-2024, sometimes fees were higher, sometimes lower. But usually, it was not a big issue to use Bitcoin.

Also, I tried LTC for a while, when fees were higher on BTC, but finally, it turned out, that if I would just stick with BTC instead, then it would be much more profitable for me, even if I would pay higher fees, because of that.

It is good, that fees are stopping some users from pushing Ordinals on-chain. It is by design. And more batching should be also implemented, to let regular transactions compete with Ordinals, by using optimizations like cut-through.

People will try it anyway. However, fortunately, burning coins is easier, than making them out of thin air. Which means, that people should be ready to burn coins, if tail supply supporters will somehow produce too much. And fortunately, making it mandatory to burn everything, which will be overprinted, is a valid soft-fork.

You don't need 100% network support, to locally increase the supply.

This will not happen, because then, it would be possible to push more on-chain spam, without making it easier, to push more regular transactions.

Also, Ordinals blocked any block size increase proposal for a while. And "quantum resistant addresses" will block it even further.

That "something" is just "3.5". The choice of base point doesn't matter, if you can halve a point G, then you can halve every other point, in exactly the same way.

For example:
If you take "3.5*G", and double it, then you will get "7*G". If you want to halve a point, you can just multiply it by "1/2", which is equal to 0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1 in secp256k1.

More than that: not only you can halve a point, but you can also get "one third", "one fifth", and "1/x" for any x-value, in range from 1 to 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140.

For example:
And then, if you try to multiply 034C7FF4F2BA8603998339C8E42675CEAC23EF2E9623FDB260B24B1C944A2EA1A9 by three, you will get G, as a result.

To better understand it, you can try some smaller elliptic curve, for example where "p=79, n=67, base=(1,18)". Then, it will be easier to understand, that "1/2=34" in case of this smaller curve, in exactly the same way, as "1/2=7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1" in case of secp256k1. Because "34*2=68=67+1". And that's how you can calculate the inversion: if you multiply "1/x" by "x", then you should get exactly "1", if you compute it modulo "n". It is that simple.

Not always, but it is usually the case. Some exceptions exist, for example: https://mempool.space/block/0000000000000000000169070f8f0650ed43a83e1b22b99542c216c5933682ce

No, it is from few hundreds of bytes, up to 4 MB. Another example: https://mempool.space/block/0000000000000000000515e202c8ae73c8155fc472422d7593af87aa74f2cf3d

No. The legacy 1 MB part determines it. The number of possible created or consumed UTXOs remains unchanged, no matter if Segwit is enabled or not. And if Segwit would allow 1 GB witness, then still, UTXO creation and consumption would be still limited into this 1 MB legacy part.

However, if a single UTXO would handle more than a single user, then yes, you will have more "transactions", even if they would be represented on-chain as a single "transaction".

Well, anyone can create a block template. So, even if you have no mining equipment, then by having just a CPU, and some full node, you can create a block template, and check, which transactions can go to which blocks.

And this is what sites like mempool.space do: they have their own mempool, with all waiting transactions, and then they guess, which block will contain which transaction, based on transaction fee, and transaction size.

No, they are also mined. However, all signet blocks are signed, which means, that only developers can mine them. Of course, you can make your own signet, and then it depends, what challenge will you put as "signet challenge", which will then be required in every coinbase transaction.

So, signet is just "testnet with restricted coinbase", where you have to sign your block, before you start mining.

Yes.

But: if you use default settings, then probably not all keys are hardened. And the last keys are probably non-hardened. You can compare it with my example. You should get the same results, even if no wallet is loaded:
Which means, that if you put your results from "listdescriptors" here, then you can check, if it works for your keys. For deriving keys, you need only "tpub" (testnet master public keys), because "tprv" (testnet master private keys) are needed only for spending.

Well, I always manually pick all inputs and outputs. Also because Core wallet usually gives too huge fee estimates, or pick UTXOs differently, than I want. But: in case of automating things, I would probably batch as many things, as possible, which means collecting all withdrawal requests, and handling them every sometimes (once per 6 hours, once per day, or something similar). It is also possible to offer faster processing, but then, fees will naturally be higher, because then, transactions are not batched, if you send coins to a single user.

I remember, when as a customer, I paid for example only 80 satoshis, when my withdrawal was batched in a group of hundreds of users, and when mempools were below 4vMB, and accepted 1 sat/vB fees. As a single user, if I would handle it manually, I would probably pay at least 110 satoshis, if not more. So: batching is the way to go, if customers are not in a hurry.

Yes.

They are similar, but they just use a little bit different descriptors. You import them in a similar way, as regular ones, just put a different path here (as far as I remember, replacing "0" with "1" in derivation path, should do the trick).

This is regular address:
This is change address:
As you can see, they are similar:

In case of descriptor wallets, you don't have to "pre-generate" anything. As long as you have non-hardened derivation, and you know the master public key, you can derive public keys from that.
One important thing: compromising the master public key, and a child private key, will compromise all private keys, derived from this particular public key. But: if you never reveal those private keys, you shouldn't worry about that.

As shown above, if you know the descriptor, then you can derive keys from any range. But: if you call "getnewaddress", then it will be marked as "used", so the next call to "getnewaddress" will give you the next one in the queue.

I don't know. But usually, I just do things manually, by using "createrawtransaction", and then "signrawtransactionwithwallet", to control everything.

Yes, things are getting more and more complex. In the past, you could just stick with P2PK, and not worry too much about it. And there was also just "generate" command, which was enough to mine some blocks, without connecting to any mining pool. But: as more people are jumping into the crypto world, it will be more and more complex, because they will create new systems, new layers, and sooner or later, you won't even have a single UTXO per user, because it would be too expensive, to do that on-chain (and then, you would need another API, to join and split many keys and signatures into single addresses and coins, and to handle multi-user transaction, just moving a single coin, from one UTXO to another).

Z tego powodu sprzedałem jakieś 99.9% BTC, które miałem. Jakąś drobnicę zostawiłem w ramach testów, bo może się to przydać, żeby zapuścić jakąś transakcję w sieci, ale zasadniczo, to KYC/AML oznacza, że będę musiał pokazywać dowód w bitomatach, a tego nie mogę zaakceptować.

How? If you have a valid signature, then both transactions are valid: "Alice->Bob" and "Alice->Charlie". Both signatures are correct, because Alice has the private key, and can create as many alternative versions, as she wants. And if you don't have a blockchain, and you don't want to have a trusted third party, then how do you want to decide, which version is correct?

It doesn't solve that problem either. For example, I sold 99.9% of my BTCs, because of new KYC/AML regulations, since 2025. I still have some coins, just to play with them, if needed, and Bitcoin is still a very interesting project, from the programming perspective, but it will be harder and harder to use it in practice, without having your ID checked by someone.

The problem, which is really solved, is just a double spending problem. If you have "Alice->Bob" and "Alice->Charlie" transaction, then blockchain can tell you, which one is valid, and which one was supported by the hashrate majority. And that's it. There's not that much beyond Byzantine Generals Problem, really (by the way: if you want to execute an example, described by Satoshi, where each General has a computer, then you can use OP_SIZE on DER signature, and lock it into a shared public key, for a given group of Generals, and then, the fastest General can create a transaction, which will claim the whole pot, and will be first broadcasted to the Bitcoin network).

We are getting there, but not because of Bitcoin. Recently, the "magic box, that can do everything" is Artificial Intelligence. Blockchain-based ideas will soon hit their limits, if people will find out, that transactions have fees, and if you do a lot of computations, without batching anything, then you have to pay a lot of money for doing that. Also, AI-based models will hit a different limits, when people will notice, that "AI programmed by AI" is not the best way to do things, and can lead to more and more dumb models, which will just turn everything into some kind of echo chamber, where the same data will be just processed over and over again, without adding anything creative.

Fake news will never be removed, because if some alternative version of the reality is logical, and could happen in theory, then it is hard to falsify it, if you don't have enough data. If you have "Alice->Bob" genuine transaction, and "Alice->Mallory" fake transaction, then both can have valid signatures, and the news saying that "Mallory received coins from Alice" is called "fake news", only because the "hashrate majority" decided to do so. And because all AI models have their limits, and their models are simplified and optimized, to give answers fast enough, there will be always some room for "fake news". Because AI can predict your age, based on your age, with 99% accuracy (and there is always 1% left for fake answers, just because that's how AI models are trained, and that's what prevents them from "overfitting", when you introduce a penalty for producing "too complex solutions").

Just apply those changes: https://bitcointalk.org/index.php?topic=5496494.msg64205870#msg64205870

Then, you will produce valid blocks locally. Getting it globally confirmed depends on your luck (if you propagate the block faster than other nodes, and if ASICs won't reorg it).

Of course, because in this way, you can get the most coins, out of the system, by using consensus rules in your favor. Because blocks with minimal difficulty are easy to mine, and push the timestamps forward, so that ASIC blocks can bring back the time to the past, and then, you can mine blocks with the same timestamps, over and over again (which is exactly, what you can observe, if you just look at block timestamps only).

So, people are just maximizing their profits. I estimate the equilibrium is somewhere around 1/6th blocks, mined by ASICs, which means around 83% CPU-mined blocks (which you can easily challenge with any CPU, as long as ASICs won't reorg them).

Most likely, this chain is just invalid, or only matches some weird altcoin, with fake timestamps.

More hints for "2012 or later": https://bitcointalk.org/index.php?topic=5512858.msg64627051#msg64627051

Why not? You can for example detect, if something is P2PK, and then handle it. And in all other cases, you can just assume it as valid. Then, it will be compatible with the rest of the network, just like a downgraded soft-fork. That's why old nodes have no Taproot or Segwit, and can still follow the same chain. And you can do that too, and throw away the whole Script implementation, then hardcode just some patterns for P2PK, and implement only ECDSA, and nothing else.

Your model is too simple. Let's prove, that Satoshi participated in your message:
Joined parts should not be used directly as a proof, by checking just your public key. You should instead hash all public keys, and put it into R-value, and then prove it, by revealing a commitment. In other case, you can prove, that anyone was a part of your multisig.

Even in that case, the public key is valid. Which means, that there is a matching private key, which can be used, to sign those coins, and move them. But fortunately, the Genesis Block is unspendable, so even if you know the key, you cannot move those coins. But still: you can move all coins, which were deposited later into this P2PK, or into matching P2PKH.

There are only traces of extraNonce, pointing out, that some miner produced a lot of blocks. It doesn't have to be Satoshi, and the estimation of 20k blocks is also covered with a huge assumption, that a single miner own all chunks of nonces (which may be incorrect, because every time, when extraNonce starts again from zero, there could be another miner, with similar mining power).

Some of them moved, but then, they are excluded from the pattern. For example: http://satoshiblocks.info/

We have blocks from 0 to 14 with one extraNonce line, and people assume, that Satoshi mined them. But: block number 9 and 12 are explicitly excluded from the pattern, because those coins were spent.

And then, we have blocks from 15 to 25, forming another extraNonce line. And people assume, that if the first line was mined by Satoshi, then the second line also was.

When it comes to addition and subtraction, then you can apply that to any two public keys. However, if you have multiplication and division, then you can only multiply or divide a public key by a private key. You cannot divide or multiply two public keys alone, here is why: https://bitcointalk.org/index.php?topic=5460766.0

So, I guess the way forward for you, would be to test everything on a small elliptic curve, where you can brute force everything. And then, switch to a little bit bigger one. And so on, and so forth. Example parameters: https://bitcointalk.org/index.php?topic=5459153.0

Sending to new Segwit addresses was always standard. However, spending from them is non-standard. Older example: https://mempool.space/pl/address/bc1sw50qgdz25j

And then, when a new address type will be officially introduced, it will be harder, because old clients wouldn't allow sending to them. For example: if you have pre-Taproot client, it can still send coins into Taproot, as long as it has Segwit implementation. The same with recently added anchors: https://mempool.space/address/bc1pfeessrawgf

And also, there are reasonable limits, for example you cannot have a Segwit address with more than 40 bytes, so it is two times smaller than OP_RETURN limit (so, if anyone would want to spam, then that person would abuse OP_RETURN anyway).