I agree. I put some more, to make the sum 100, and let's see, how OP will send them. Because I am honestly curious, where are those great posts, which are worth more attention.

I wonder, if it is possible to emulate OP_CHECKSIGFROMSTACK, by using a properly constructed OP_CHECKMULTISIG, for example as a 2-of-2 multisig, where two signatures are given, and the whole task is to find a single public key, which will unlock both, at the same time.

A typical OP_CHECKMULTISIG works like that:
However, what if we can do instead:
And then, we can be sure, that z-value is identical in both signatures, so we can pick (r,s) pairs in a way, where if someone will provide the proper public key, it will be an equivalent of signing a given message.
Of course, that kind of construction will reveal all private keys. However, by putting the proper (r,s) pairs, it may be possible to put publicly known values here, and just use it as a calculator, which will work as a some kind of "multiply and add a given 256-bit number, by those values". Normally, a regular OP_CHECKSIG would be sufficient here, but OP_CHECKMULTISIG has a nice property of enforcing identical z-value in all signatures.

Or: maybe 3-of-3 multisig, or something bigger is needed, to make a proper OP_CHECKSIGFROMSTACK?

No, because it would require different rules for testnets, and mainnet. In the mainnet, you have "satoshis per virtual byte" model, where 1 sat/vB is the bare minimum. It works well for the network, which is already 15 years old. But not so well for a brand new network, started from scratch. And many altcoins repeat the same mistake, by picking 1 sat/vB, and starting from zero coins, and then wondering, why they are getting a different outcome, than Bitcoin in 2009.

In general, testnets should not start from scratch. There is a difference between testnet and altcoin, we should do the former, not the latter. Testnet miners should not get 50 coins per block, when mainnet miners are getting 3.125 BTC plus fees. And more conditions should be more similar to the mainnet, than they really are. However, it is, what it is. The network was deployed, and we can only stick with some existing rules, and make simple changes, because it is too late for a brand new Genesis Block, for a brand new network model, and for a brand new rules. Testnet4 will succeed or fail, but the whole skeleton is already set in stone, and won't be changed. People will rather deploy testnet5, than fix testnet4, if there will be some bigger failure.

There is a command called "invalidateblock", often combined with "reconsiderblock". Usually, it is used in a scenario of re-validating a block (so there probably should be a single command, called "herewegoagainblock" or something). But miners can also abuse those commands, for forking a chain programmatically (which is a soft-fork).

So, no new commands are needed, it is all about re-using, what is already there. But so far, Garlo Nicon passed 9950 tBTC as fees, and it was not reorged. Maybe a bigger amount can be pushed in that way, we don't know yet.

However, cheating in a lottery is a double-edged sword: the traffic in testnet4 is quite low, so miners should be interested in getting new users on the board. And also, if users will abuse the lottery, for example by winning too many times, and using full-RBF, to replace lost bets with different transactions, then miners will stop running the lottery, and start claiming the full reward again.

Basically, that kind of lottery reminds me about a game of trust: https://ncase.me/trust/

And I wonder, how many things can be tested in that way. Can a no-fork sidechain run on testnet, without being wiped by dishonest users? Can some kind of lottery be deployed, without having 100% on miners' side, and 100% on users' side, but reaching a more natural equilibrium instead? There are many things, which can be tested (and which require producing your own coinbase transaction). As long as CPU mining test coins is possible, I am trying to test things, which require mining, also because I know, that when more competition will appear, then the opportunity to test those things could vanish again.

If you have a block, where all fees are below 1000 satoshis, then it means, that you basically have less than 1 kvB of data to confirm. Which simply means, that nobody is using the network at all. And then, it doesn't make any sense to run any kind of lottery, if nobody would receive those coins.

Also, another reason for the minimal amount, is to allow the winner to spend it. Imagine winning 110 satoshis. A miner could obviously send it, but how the user is supposed to make a non-standard transaction, when that user is not mining?

Another thing is that nobody stops you from counting 110 satoshis as a winning amount. But in this case, it should be batched, and for example if someone will win 10 times, then that player can receive 1100 satoshis once, instead of receiving dust amounts in every round.

Ideally, coins from the lottery would be accumulated on a single UTXO, and users would know, how to withdraw the amount they won, at any time. But we are not there yet, because the main network does not support batching things on that level, and forming such coinpools in a decentralized way.

1. By default, every user is losing, and all fees goes to miners. Which means, that any non-zero amount of lottery nodes is better for users, than no such nodes.
2. As long as testnet4 is in its infancy, transactions could be free, or almost free, and it won't be harmful. So, that kind of lottery is just some kind of workaround for "free transactions during the early stage". Processing all transactions for free is hard, because even though there are some nodes doing that, then users are not really using that feature. So, it is a way to reward at least some of them, to imitate the initial stage, where early adopters could get their transactions processed for free. Ideally, it could be handled as 1-of-N multisig on all public keys, but it would be too spammy, so it is reduced to a "winner takes all" scheme.

If you think about alternative implementation of a magic OP_LOTTERY opcode, handling the whole thing, then it is still not resistant to being manipulated by miners. Given enough incentive, a miner can try to drop some block, and mine an alternative version, if it could give a bigger reward in a lottery. It is similar to reorging a block with 10k tBTC fee: if you have some transaction, with some payment to the winner, and the miner can check, if he is winning or not, then that miner can try to game the system, by trying different inputs, as long as it is profitable.

But yes, when selecting the winner, any reasonable input can be used. The bare minimum is the client seed (first pubkey), and the server seed (second pubkey), connected with some kind of nonce (for example as a block number). Then, by mining a block with a hash of some public key, it is an equivalent of revealing some server seed. Which means, that in any later block, a client can specify nonce in the locktime field, and reveal some public key, when spending the transaction.

If some transaction is standard, and it is broadcasted to the whole network, then any non-lottery node can also include it, even if some lottery node will exclude it. And then, a winning bet will still be considered, because after reaching a single confirmation, all nodes will count a valid winning bet, as a valid winning bet. The transaction locktime will give us the nonce, the client seed will be revealed as the public key, and there will always be a chance to get a match, if not in this lottery client, then another.

Also, for that reason, sharing commitments in a P2P way is important, because in this way, we can avoid a situation, where every key is rewarded by half of the lottery nodes.

One reason is that the centralized website, from which I linked the provably fair model, is getting worse and worse, so there is some room, to make a decentralized alternative. Another reason is that testnet4 is in its infancy, and users are unnecessarily paying 1 sat/vB, instead of getting free transactions, or paying 0.01 tBTC, as it was, during the early stages of the mainnet.

And of course, another reason is that I mined more than enough testnet4 coins, so I think about a good use case for them. Or rather: a use case for transaction fees, which reached something around 0.03 tBTC in my case, and it is growing. Because when dealing with coins before the first halving, their amounts are so huge, that limiting all tests into 0.01 tBTC (as the smallest unit) is good enough for everything.

Also, I thought about models like "collect 0.01 tBTC in fees, and then release it to a single winner, picked from everyone, who contributed into that pot". However, I wonder, if it wouldn't take too many blocks to get there, so people can get impatient, if they will have to wait that long, for claiming their reward.

The problem of using complex scripts, like OP_LOTTERY, to introduce that kind of system in the first place.

For example, you have a famous HI-LO game (but not only that). Your deposit is your transaction fee, so everyone is playing, except for example miners, doing transactions in a range of 0-1 sat/vB.

An example of getting numbers in range 0-10000, to determine the result of some round: https://s3.amazonaws.com/roll-verifier/verify.html

If you would want to get it on-chain, you would need something, like an additional OP_LOTTERY opcode, which would return you a single number in range 0-10000, and then you would have some "OP_IF <winnerKey> OP_ELSE <minerKey> OP_ENDIF OP_CHECKSIG", to claim the reward.

For this purpose, all that is needed, is having a blockchain (which every full node has). Also, pruned nodes keep the last N blocks, so it should be sufficient for verification of the latest lottery rounds.

In general, verification is easy: you observe the chain, and you know, how many nodes are running the lottery, and how many are not supporting it. Then, you can make some statistics, and determine, how many coins should be sent to the users, to keep the lottery running. And as long as there are enough miners, willing to share their fees with the community, the lottery can run indefinitely, and encourage new users to participate in next rounds.

I thought for a long time, how to create a decentralized lottery system, which could work efficiently, without producing too many on-chain transactions, and executing complex on-chain scripts, like HMAC-SHA512.

The first thing we should note is that users are already putting their coins into the system, by paying their transaction fees. Which means, that lottery runner should not require any additional payments, because fees alone should be sufficient to collect all of them, and create an additional output in the coinbase transaction, paid to the winner.

In general, if we analyze the chain history, then for each block, we can easily grab all successfully validated signatures. This is our base for selecting the winner. Because you can't use a coin without exposing its pubkey, by checking all signatures, you will already know, that a given key is spendable, and it was successfully used to move some coins in the current block.

Then, we pick a single public key, no matter in which script type, and which context it was used. Different lottery runners can use different criteria for selecting the winner, because different nodes accept different transactions, some accept free transactions, some may put higher limit, like 10 sat/vB as a minimum, and so on. One winner per block is the highest load we could handle. And it probably should be even lower, like "one winner per N blocks", because lottery runner will obviously not have 100% hashrate domination.

After selecting the winner, we simply create 1-of-2 multisig, where one key is owned by the lottery runner, and another one belongs to the winning user. This is needed, because the default behaviour is to collect 100% transaction fees, which means, that the user lost his bet. Also, during the initial stage of the project, many users will probably be unaware, that they won anything, so there is a need to clean up on-chain UTXOs, if nobody will collect them for a long time.

Also, we should remember, that winning users should have the ability to move their coins. Which means, that if someone paid 110 satoshis for some transaction, and it was the only payment in a given block, then we should not split the coinbase into 50 tBTC for the miner, and 110 satoshis for the lottery. Which means, that there should be some minimal amount of fees, which triggers the lottery, for example set into 1000 satoshis. In other cases, users may end up with dust UTXOs, which they could never move, without some help from the miners.

Another important thing is to use a single pubkey, as a winner, instead of trying to reproduce an exact Script, which was used by a given user. This is needed to make sure, that people can easily spot "lottery vs non-lottery blocks", make sure, that the system is provably fair, and also to avoid huge fees, if someone would win by moving a coin out of 1-of-20 multisig.

When it comes to the exact Script types, then using 1-of-2 bare multisig sounds like a good option. However, it has many drawbacks. First, there are proposals, related to making them non-standard. Which means, that even though coinbase transactions are obviously non-standard, and spending them may be standard for a long time, then still, creating new bare multisig outputs will be considered as spamming, so it should not be used.

However, by avoiding bare multisig, it simply means, that lottery winners will be wrapped in some kind of hash. This is another reason for 1-of-2 multisig, because hashing will hide the fact, that someone won, and it will probably be needed to sweep the prize more often than not.

Another option is to use 1-of-2 Taproot output, where one key is in exposed key, and another is in the TapScript. However, many Taproot outputs are used for spamming, when spending by TapScript, so picking that path would probably create more spam, and we should not encourage that.

Which leaves us with the last option: a regular Segwit single-key address. It is the only case, where something is non-legacy (so it won't be made non-standard soon), and it has predictable transaction size (because a single signature is not a choice, like in Taproot, but a requirement). The drawback is, that it pushes us away from Schnorr signatures, and forces us to use DER encoding, but it is better, than being censored by some nodes, mistakenly marking our address as "maybe Ordinal".

All of that leads us to the final state of the lottery, from the perspective of on-chain observers: usually a single P2WPKH address, when the fees are below 1000 satoshis, and sometimes two P2WPKH addresses, one with the base amount of 50 tBTC, and another one with fees, sent to the 1-of-2 multisig of the winner, and the miner.

Then, the last question remains: how to convert 1-of-2 multisig into a single key? Well, by exploring concepts like Silent Payments, we can find answers. Simply, we take the winner's public key, and multiply it by miner's private key. In this way, we create a shared key, which can be computed only by the winner, and the miner. If we would send it directly into this key, we would achieve 2-of-2 multisig, so we are almost there.

The final modification is to apply SHA-256 on that public key, and use it as a private key. Then, we would have 1-of-2 multisig, but without any information, who spent those coins. Which leads us to yet another concept: Reality Keys.

Of course, the concept of Reality Keys mentions publishing two public keys, but here, we have a single key for the winner. So, how to solve it properly? Well, there is one important key, which is not that well-exposed: the R-value inside the signature. It is obligatory to put something here, when spending the coin, which means, that we can put either miner's R-value here, or winner's R-value.

To achieve that, we can consider building a commitment, as described here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-November/022176.html

As "data", we can use "<winnerSig> <winnerKey> OP_CHECKSIG". Then, any of two parties could release a commitment, but only the winner would have the proper key to create a valid commitment. Which means, that because of 1-of-2 multisig, a miner could potentially broadcast a commitment, containing winner's key, but still: only a winner would have the private key to make this commitment in the first place.

And this fact would be enough to count properly, how many rounds were won by miners, and how many were won by regular users. This is needed, because nodes could exchange those kinds of commitments in a P2P way, and use it as an indicator to pick the winner of the next round (for example by not selecting the same winner over and over again).

Not only that. It also means, that mining testnet3 is now less profitable, and switching into testnet4 is a better idea. But a short while before that, it was the opposite, when it was not certain, if testnet4 will be reorged or not. Now we know, that those, who consider 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 as a valid block, are simply mining coins, which will vanish, after upgraded ASICs will mine an alternative chain, on top of 0000000000000016be66ab39af9f97e1294080c94d0a34cc304e391794a481bd.

In general, we are about to see at least 360 blocks reorg, at the time of writing. I guess it could be 500 blocks reorg, or even 1000 blocks reorg, depending on how many people will mine blocks, when using some older version.

Release candidate for v28.0 already contains testnet4: https://groups.google.com/g/bitcoindev/c/EmAOO-Nbmzw

Is it testnet4 or testnet3?

Check closer, who is the owner of this address: https://mempool.space/testnet4/address/tb1qy65a0ltkaxpuwc22gx2zjehac8gpgppawrmpud

It is, but:
1. Some parties, like exchanges, often don't process them correctly, and don't associate those coins with your account.
2. You have to wait for coinbase maturity (100 blocks).

It indeed is. Also note, that testnet4 is still in its infancy. So, you can get your transaction confirmed even for free, as long as there is enough space in blocks. You can check your peers, maybe some of them accept free transactions?
So, if you spot a node with "minfeefilter" set to zero (or anything lower than 0.00001000), then you can try to send a cheaper (or free) transaction, and there is a chance, that you are connected to some CPU miner, who will confirm it for free.

For example, for testnet4, I have these settings:

Bitcoin Core. By the way: you don't need to "convert" anything, you can instead create a transaction, sending coins to the mainnet address, and then sign that transaction under testnet. Also, if you want to move those coins, then again: you can create a transaction under testnet, and sign it from your mainnet node. In this way, no conversions are needed.

Another benefit of doing that, is testing offline signing, which is a good habit in general.

Testing VIP status: https://mempool.space/testnet4/tx/7915aa3643266aeb102dca43841b797bf35a01d4e7de16b31a66f21f12497899

@vjudeu: Contract executed: https://mempool.space/testnet/tx/70f8a2d9e01f8603cc0301fe5b3b809c5a9acfc975a5f122393b1c900b977cba

As everyone can see, the recipient can simply publish some partially-signed transaction, and then the sender can do the rest, without any interaction.
Challenge for readers: repeat the same thing on testnet4. It is easier to get them, because each block will give you at least 50 new coins.

Meanwhile, Garlo Nicon mined more than 60 tBTC on his CPU: https://mempool.space/testnet/address/tb1qvy67actlsslmvwpjzk9hnx6jf04g5y26sz5crx

Currently, there are less and less ASIC miners, and the real time between blocks in testnet3 is now set to 20 minutes. Sometimes, some ASIC pops out, but it is rare.

Test coins are weird: some of them are free, some of them are burned. But it seems you got what you wanted anyway.

Oh, so the amount given by Jeff Garzik was wrong, and it was not 92233720368.54277039, but 92233720368.54275808. Now it matches:
And also, z-value of d76cb91081dc24b6417f4cb0fe49f8144f85129b871a8b50c3c36df496328353 matches too:
So that means R-value should have 02 prefix before getting truncated.

So, what are the exact values? Because I tried different combinations (including SIGHASH_ANYONECANPAY), and something is still wrong. If I understand correctly, in this case, that kind of sighash will not change anything (because there is only one input). Which means, we first put the previous output in the scriptSig, so we have this transaction:
And then, we append "a8000000", and apply SHA-256 on that, so we get this:
But: if we use this value to calculate the public key "z*G", then it will give us the wrong value.
And then, we finally have two options:
But if we use 0f74c87ba2a7fad26dc08f85229e546b87011858d08ee77d02f9b173d519b7ea calculated previously, it doesn't match any of those keys. Any ideas, where is the mistake?

What is the exact form of raw transaction from Value Overflow Incident? I tried to recreate it, but I guess I am doing something wrong.

Link to the topic: https://bitcointalk.org/index.php?topic=822.0

My attempt:
It seems that outputs are decoded properly, because the second address even exists on-chain: https://mempool.space/address/1542Dgx5EeurzHP8cT57fK6hBTQq2dgTEu

However, I am curious about scriptSig, because it is very strange. It has this weird "a8" ending, which sounds like invalid sighash. What is taken in that case? SIGHASH_ALL? Also, I don't know, how to make any message, which will hash into 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9. And then, what is the z-value, which is used to make this signature? What are the last four bytes, added to the transaction? Is it "01000000"? Or maybe "a8000000"? Or something else?

In case of the coinbase transaction, that was quite easy:
Also, merkle tree was quite easy to decode, because it is just a concatenation of both transaction hashes, with reversed bytes:
And, for completeness, the 80-byte block header:
I guess I did some mistake in calculating sighashes, but I don't know exactly, where it is.

All that is needed is just waiting. A user can write a transaction today, and it will be invalid. But if that user will wait a day, a month, or maybe even a year, then this transaction will finally be valid, because the amount will be increased over time.

If PIN will be the only protection, then what about bruteforcing it? In case of centralized systems, there is a limit of how many times you can try it. So, what does it mean in your system? Is it possible to attack random users, and block their accounts, just by endlessly trying invalid PINs on their accounts?

How to prove to the new users, that the system is honest? New nodes don't know, what was "first" or "second", because they can only download the history. And validators can sign both versions to maximize their profits.

Even in casinos, where you can earn 4% per year, just for holding funds, it is calculated at random time. Because in other case, it is possible to exploit the system, by depositing it "just before", and withdrawing "just after". Which means, that if your coin will be listed on any exchange, then users may just buy it "just before getting bonus coins", and then, use their bigger amounts, to withdraw them, and convert back into other coins, which are not printed out of thin air.

Also, the exact supply doesn't matter. But proportions do. Which means, if you for example double the amount of coins in circulation, then the exchange rate between your coin, and other altcoins, will just halve (or worse).

In decentralized systems, it is not possible to separate roles. Which means, if you are a Bitcoin miner, then you can also be a Bitcoin user at the same time (or even Bitcoin developer). And here, it is the same situation: if you create for example two separate programs, one for the validator, and one for the wallet, then nothing stops the user from running both on the same machine.

Ouch. That will crash the exchange rate between this coin, and a lot of altcoins.