Even that part is unnecessary. In Bitcoin, we have UTXOs, which can hold zero satoshis. So, if that kind of system would just count any UTXOs, and would be deployed on top of Bitcoin, then people could artificially create a lot of outputs with zero satoshis, just to increase their chances of being selected.

But, there are bigger problems than just that: if everything is based only on signatures, and all coins are initially in the hands of the creator, then the chain of signatures can be always overwritten by the creator: in all Proof-of-Stake-like protocols, if you have 51% of coins, then you can rule the network forever.

In case of Proof of Work, having 51% here and now, means that you can only rule the network here and now. And that you have to keep spending your resources, as long as you want to keep the majority. But once someone is beaten by another miner, someone having 51% hashrate can lose its leading position. But in signature-based protocols, like Proof of Stake, signatures can be made without much effort, which means "once 51%, forever 51%" instead.

And in that case, if the network is going to be centralized anyway, and controlled by whoever will hold the premine, then why don't start with just Signet, and explicitly use something, which is based on Proof of Authority anyway?

And who can start that kind of chain of signatures? Are there all coins assigned to the creator, or do you start from a completely empty chain? If all coins are held by the creator, then how it is better than Ripple? And if there are no coins, then who signs the first one?

How to check, if a given transaction is fake or not? If there is "no blockchain", then there is "no persistent history of any kind". You can have one transaction, sending coins from Alice to Bob, and another transaction, sending them from Alice to Charlie. How do you know, which transaction is real, and which is fake, if both signatures are correct from ECDSA point of view? And if one group of cosigners can tell you one thing, and another group of cosigners can tell you the opposite thing, how do you know, who can be trusted? Remember: you rejected Proof of Work, so all signatures on all sides are equally good, which means, that nodes can be easily fooled.

Do you mean "signing a zero hash", "signing a one hash", or "not including any signature at all"? If you don't include any signature, then it is unknown, if someone decided to not sign anything, or if you simply missed that P2P message (and then, the system is not resistant to dropped messages). If you sign zero hash, then any coin can be moved anywhere. If you sign one hash (or anything constant), then it is not resistant to SIGHASH_SINGLE bug. So, how exactly "nothing" is signed? You take SHA-256 of an empty string?

There are many dead altcoins. If you don't have any brilliant idea, then your altcoin will follow the typical path of pump and dump, where early adopters first get everything they can, then your coin will be listed on any exchange, and reach its ATH, and then it will dump to the bottom, when everyone will sell it for BTC.

In case of Proof of Work, there are limits, for example one block per 10 minutes. If you have just signatures, without any Proof of Work, then there are no rate limits. Which means, that nodes can be endlessly flooded, by a lot of people, sending everything between themselves. And because there are no fees in your system, the cost of spamming the chain is literally zero.

In that case, why it is better than Ripple? And if it isn't, then why don't you just use Ripple instead?

Which one exactly?

I don't think it is the case. You can look at some statistics from Bitcoin or other chains, and see, that many times, you have multiple inputs and outputs. And of course, if your system will for example only allow a single input and output, and would form some kind of account-based system, then just multiple transactions would be used to achieve the same thing.

What if all of them are nonresponsive? And who decides, if someone was nonresponsive, or if it was an arbitrary decision of a given coin owner? If anyone can affect the randomness, just by changing the address, then people can do that endlessly, until they will get the cosigners they want, and your randomness could be easily bypassed by anyone in that case, and replaced by "address mining", just to pick the non-random cosigners.

Of course, as always, I encourage you to try your ideas, to write some code, to make some test version, and to test everything in practice. But as you can see, if you throw away some element, for example Proof of Work, then there are many consequences of doing just that, and I don't know, if you are aware of them.

Also, every system should have its constraints, and assumptions. For example: Proof of Work assumes, that the mining majority is in honest hands. In case of 51% attacks, the system works much worse than described in the whitepaper. So, what are your constraints? Having 51% of all cosigners?

Just run Signet: https://en.bitcoin.it/wiki/Signet

Only those, which are signed by signet miners.

You can do that in today's Script: just add OP_CHECKSIG, without any key, and then, a valid public key and signature will be required. Also, you can do "OP_CHECKSIG OP_CODESEPARATOR", if you want to sign exactly the same data as before, and remove this additional Script from the signed data.

If there are no fees, then what is the incentive to sign anything? If people have no reason to sign anyone's coins, then they can just stop doing that, and halt your network in this way.

Proof of Work is not going to disappear anytime soon. Quite the opposite: it is possible to require Proof of Work inside Script, by checking the size of the DER signature. And it can be splitted or merged with other sidechains: https://mempool.space/testnet4/tx/8397c2323e3fa099c15be68399346b2b3d223ef8e81e553242763e1a4c60771a

Also, you probably received that link at least once, but I will share it again: https://www.truthcoin.info/blog/pow-cheapest/

If you switch from Proof of Work into something else, then you will get just "hidden Proof of Work" instead, but you won't avoid it. For example: if coins are signed, then the size of the signature can act as a Proof of Work. And you will need to check things like that, for example to avoid flooding your network with a lot of fake transactions, signed by large group of signers, who can effortlessly flood your network, if there are no protections.

At the end of the day, no matter who will be selected, someone will be picked, as a cosigner. And then, that person can just sign fake transactions, or just reject to sign anything, and halt your network entirely, by making you unable to send any transaction at all.

Also, when your network will just start, then there will be just a few people interested in your system. And then, if you have for example 5 users, then it doesn't really matter, which one will be randomly picked.

Another thing is that you didn't understand, why Proof of Work is needed: you can run regtest, where every second hash is a valid block. Mining is ridiculously easy, almost nonexisting there. And if your idea would be good enough, then you could just run regtest publicly. So, why you wouldn't do that? Because making signatures is cheap. And where making a chain of signatures (even without any blocks) is cheap, then not only it can be easily produced, but also easily attacked.

So, by fighting with Proof of Work, and trying to remove it, you just open your network for "multiple history attack", where one group of nodes will sign one group of transactions, and another group of nodes will sign something completely different, and because of no mining, nobody would be able to tell, which history is the correct one.

Which could be never. When your network is small, then it can happen quite easily: if you have for example 5 nodes, then just 4 of them can decide: let's stop signing and see, what will happen. In case of Proof of Work, the network will still be pushed forward, because the remaining node can still keep mining new blocks. But in your network it is not the case, just because you removed Proof of Work entirely.

Change endianness. It is quite likely, that the author wanted to get nine nibbles, but mined it with the original SHA-256 endianness (because it is faster), and then, it was too late to change it after broadcasting.
See? Nine nibbles, which are turned into eight, when you change endianness after mining it.

Yes. Because in the long-term scenario, if you have to share the full chain history from 2009, up to today, instead of sharing a cryptographic proof, that all of such history is correct, then you discourage many people from joining the network in the first place, and from making new full nodes. Which means, that if the chain will grow over time, then if our ability to synchronize the chain wouldn't grow accordingly, then it would take more and more time, to sync the full chain. And that can affect decentralization, because that approach doesn't scale.

On-chain fees should be constantly high in the future, because otherwise, miners wouldn't have enough block reward to have enough incentive to keep mining the chain. As Paul Sztorc wrote in his Sidechain Vision, "Fee Revenues must rise". In practice, it doesn't mean, that the on-chain fee should be paid by a single user. You can have thousands, millions, or even more users, making their transactions on second layers, having all of that batched, and finally pushed on-chain, as a single transaction with high fee rate. If you want to scale seriously, you won't onboard everyone on-chain. Which means, that you will have a lot of users, making transactions only inside LN, only inside sidechains, or only inside other kinds of subnetworks, and all of that traffic should be batched, and confirmed on-chain. In this way, you can have thousands of users, paying a bunch of millisatoshis each, and have a single on-chain transaction, paying a bunch of satoshis, signed by all of them, and covering all of their needs in just a few kilobytes per batched transaction.

The current state of the mempool can show you, that a lot of traffic moved outside Bitcoin, which is why it could be bad in the long-term. Many people stopped using Bitcoin, just because of scaling issues. And if they won't be solved, then you will have only whales transacting on-chain, and all users will use centralized solutions, provided by those whales. And that's why decentralized second layers are needed, to not lock users into exchange-like or bank-like systems, where they have to trust, instead of verifying.

If by "complex algorithm" you mean SHA-256, then it is not so complex. In fact, many altcoins, which are based on Proof of Work, use much more complex algorithms. In general, the faster a given hash function is, the easier it is to run a non-mining node, SPV node, or any other user-based client (which means, that many "ASIC-resistant" altcoins are also "user-resistant", if their hash functions are too complex, because then, chain verification is more costly, than it should be, if for example checking 10k blocks is as hard, as mining a single block). And SHA-256 is not so complex: it is only a little bit of math, executed in a loop, and designed to rely on avalanche effect, on Merkle–Damgård construction, and on ARX model (Addition, Rotation, Xor, combined together). Some topic about hash function complexity, where SHA-1 is analyzed: https://bitcointalk.org/index.php?topic=5402178 (here, SHA-256 is very similar, there are different constants, and some math operations are changed here and there, but if you can understand SHA-1, then you should also understand SHA-256).

It is technically possible to make Proof of Work scripts. For example: "OP_SIZE 60 OP_LESSTHAN OP_VERIFY <pubkeyToBeBroken> OP_CHECKSIG". Instead of 60, different numbers can be used, to set a difficulty for moving a given coin. Which means, that even if the main chain stops, then still, a chain of unconfirmed transactions can still be protected by additional Proof of Work, chosen by users, and then, the chain of signatures can still move forward, even if Proof of Work won't be present in block headers, but in transaction scripts instead.

Currently, I don't know how to combine it with existing block headers, so it does not use Merged Mining, but future Script updates, like OP_CAT, can make it possible. But even in today's code, you can protect your scripts with additional Proof of Work, which means, that you can have a chain of unconfirmed transactions, that is hard enough to overwrite, even if ASIC miners are gone for whatever reason.

No. Bitcoin is not ruled by miners. And there are many good reasons, why everything shouldn't depend only on miners. For example: if all miners would decide, that instead of halvings, there should be doublings, and the basic block reward should explode from 50 BTC, up to 21 million coins per block, would you use that coin, even if it would be covered by a lot of Proof of Work?

As long as nobody will find any bug in the code, like it was during Value Overflow Incident, no honest nodes will ever accept some invalid transaction. If you have a lot of people, running similar, or at least compatible code, then they form a community, focused around a given coin. In case of disagreements, they are currently solved by miners, by telling you, which history is correct. But: each full node checks everything, so you cannot just send some completely invalid transaction, and expect it to be accepted by another party, if you don't know any serious bug in the code, which could allow such things.

So: if you have two or more valid alternative chains, then miners can tell you, which one is correct. But: they can only pick between equally valid ones. They cannot generate random bytes, and expect it to be accepted. Every signature should be valid, every script should follow consensus rules, and you can only confirm another alternative valid chain, which means, that attackers can probably focus on just reversing their own transactions, because it is the easiest attack vector, if you have all private keys for transactions you want to change.

Then, the chain will halt. And then, users will be forced to pick some software, which will allow them to transact. Which means, that collective effort to produce the next block, will eventually push the chain forward.

Basically, mining exodus will just expand the time of the block from 10 minutes, to something much longer, depending on how much the hashrate would drop. Which means, that if 50% of mining hashrate will be gone, then you will have just 20 minutes per block, but the chain will still move forward. Which means, that even if we would have 99% of hashrate gone, then you can still expect to see something around one block per day (because we have something around 144 blocks per day).

Every TapScript output uses SHA-256 internally, so if you keep using that, then it should be fine. If SHA-256 will ever be broken, then it can break everything, including Proof of Work, all ECDSA signatures, and also large parts of the Internet behind Bitcoin. Which means, that many things already rely on SHA-256, and you can do that too, because if the world will burn, then the security of your coins will be doomed anyway, if the attacker will be able to overwrite Proof of Work, which created your coins in the first place.

Of course, SHA-256 can be patched in a similar way, as SHA-1 was, by making a hardened version, which will protect it only from particular attack vectors.

Of course. But then, people willing to use Bitcoin as a P2P money will simply move to other subnetworks, while leaving on-chain spam, where it currently is. And then, you will have a choice: use the current client, and process all of that money-unrelated spam, or upgrade your client, and focus on monetary transactions.

So, it is only a matter of making enough people angry enough, to develop that kind of solutions. Satoshi was angry, because of fiat currencies, and that pushed him to make Bitcoin in the first place. If fiat currencies would be better, then Bitcoin wouldn't exist, because then, there would be no need to make it (which you can also read directly in the Genesis Block, how "second bailout" was literally the input to create Bitcoin).

And if NFT enthusiasts will abuse the chain more than they should, then some developers can be pushed to their limits, and make a money-only-based network, on top of Bitcoin, which would be designed, to explicitly exclude other use cases. Technically, it can be done, it is only a matter of pushing people enough, to start discussions, similar to what I linked, and bring changes like that into reality.

Also, as long as spammers are strong, such changes would be just optional. I don't want to force everyone to follow my rules, but note, that ideas like dropping UTXOs can come from developers as well. And in that case, they can make it mandatory, by turning them into soft-forks. And then, I don't know, what will be the end result, but I guess the optional path will be taken anyway, and just P2P money enthusiasts will move to their own subnetwork, where they will focus on money, and everyone else will use the official version, which would allow a lot of spam, and would have heavy requirements to run a node, if you compare it with other alternative, more spam-resistant clients.

For now, my plan is to still stick with Bitcoin Core, but as you can see, by pushing more spam on-chain, many people can be convinced to use a different implementation, or to run their own tools on top of Bitcoin Core (which is for example how Paul Sztorc wanted to introduce sidechains, by making his "Core Untouched Soft Fork" client). If there will be more spam, then such things will just happen more often, and some people will start using different implementations, to make Bitcoin usable with lower resource requirements, and fight with centralization pressure, made by spammers.

I already answered both questions: first, it is not true, that "nothing will stop" it. And second, I already shared a link, describing what could happen, if people will abuse the chain too much: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707

See? Here and now, every node have to process the whole UTXO set. But, things can be changed in future versions, and node operators can decide, that they don't want to store everything. Today, we have full archival nodes, and pruned nodes. Currently, you can bring around 600 GB of historical data into something like 10 GB of the UTXO set.

However, if there will be more and more spam, then the UTXO set can grow much faster than today. It can take 20 GB, 30 GB, and so on, and so forth, until reaching the point, where the size of historical data will be comparable with the size of the UTXO set, and then, pruning won't do anything good anymore, and will only block you from bringing new nodes to the network.

And then, node operators can decide to implement proposals like linked above, which would allow them to process the subset of the UTXO set, and stay compatible with the rest of the network. Which means, that if there will be too much spam, then it is possible, that it will make enough developers angry, to implement solutions, which will keep spammers away from money-based transactions.

For example: imagine that today, you can visit some block explorer, and it will show you some on-chain posted image. But if there will be too much spam, then imagine that future version could require users to store their own images locally instead, because new nodes could refuse to store non-consensus-related data at all, or even store any historical data at all, and require all users, who will want to move their coins, to provide more data during spending.

And then, if exploring the full history won't be that easy, as it is today, and if everyone will be forced to keep those things locally, or else such coins will be unspendable, then it will stop a lot of people from spamming, and only the most persistent ones will keep doing that. If people will find out, that Bitcoin is not a cloud storage, and you simply cannot be a leecher in this P2P network anymore, then old NFTs will simply behave like old torrents with no seeders.

So, the question is: do you want to push Bitcoin in that direction? Because if someone is pro-NFT, then that person should be aware, what could be a consequence of using Bitcoin for every blockchain-related thing, instead of focusing on payments. Simply, non-monetary use cases can be punished in the future, and then, the whole monetary activity can be moved into some subnetwork, while leaving mainchain people with a spammed chain, which is not used to move any coins anymore.

OP_RETURN is better, but it is still far from being the best way to handle it.

If new nodes will remove that data from their storages, and will keep only a proof, that a given coin is there, then users will have to provide not only signatures, but also public keys, when they will want to spend their coins. And if data converted into public keys leads to unknown or unspendable private keys, then such things would never be touched. And if less and less nodes will provide such data, then there will be less incentive to push them on-chain in the first place, when accessing historical transaction data will be harder than today, and if the effort of doing that will be shifted from nodes to users.

So, in general, it is the question, if some people want to make enough developers angry, to move dust expiry from theoretical discussion land into practice: https://delvingbitcoin.org/t/dust-expiry-clean-the-utxo-set-from-spam/1707

Something like that? https://mempool.space/tx/e67c7cef9c59167046bee99a961a4ca75137c5ed4b697b30dc6e752ff1d50ecc

In general, if you still have the same wallet, then you can sign messages from the old keys, even if coins are no longer there.

So, it is possible to for example sell coins in the past, and prove now, that you had them. But you should be careful, because even if it is "cool", then by correctly proving, that you had for example 10k coins, some people may want to attack you, if they will think, that you secretly still have a lot of money.

It is better, but far from sufficient in the long-term. And there are ways to timestamp any given data, without abusing Initial Blockchain Download. If users will abuse the chain too much, then just encouraging people to switch to OP_RETURN won't be sufficient, and then, there are more things, which can be done, for example by making more lightweight nodes, which would require less resources, and which would accept some proofs, instead of storing everything.

In general, I expect there will be some abuse, and some people will make a lot of unspendable outputs, no matter how often they will be encouraged to use OP_RETURN instead. And then, if it will be needed to make further changes, to stop the abuse, then they will be taken, when node runners will start running out of resources, and if there will be a need to encourage more people to run nodes. Because here and now, many people don't want to process over 600 GB, just to get the ability to share the chain, and introduce new nodes to the network. Which means, that if the chain will grow too much, then further actions will be needed, to keep the network decentralized enough, and to scale it properly.

You need that only in the current implementation. But it can be changed in the future, and it will change, if more people will want to do something with the problem of spamming the chain. Because here and now, the system is wide open to non-standard transactions, which will push a lot of data, and which will send coins from zero satoshis to zero satoshis, and every full node will be forced to process that Bitcoin-unrelated traffic. There is no UTXO set size limit, and there is no total chain size limit. And people don't have unlimited resources, so such things can be restricted in the future, to allow running full nodes by enough separated entities, and limit that kind of centralization pressure.

If you don't care about Initial Blockchain Download, then it is. But if you do, then in the current implementation, new nodes require downloading all data from 2009, up to today. As long as it is the case, there will be a problem with spamming the chain. It is technically possible to implement things in a way, where the exact data from OP_RETURN won't be needed to bring back new nodes to the network, but today, it is not yet implemented.

Yes, storing things in OP_RETURN is better, than storing them elsewhere. But still: committing to data, without pushing them on-chain, is even better. And as long as you have to download and process each and every OP_RETURN, to synchronize the chain, it is a problem, no matter how and where things are stored.

In general: being forced to process everything from 2009, up to today, is a problem, which will be more and more urgent, as more time will pass, no matter if blocks will be filled with regular transactions, or with just data pushes. And moving the responsibility to keep that data, from the network, to the user, is technically possible. Then, things could be pruned by all nodes, and users would need to provide more data, when spending their coins, instead of relying on nodes to keep the full history forever.

And of course, some people may want to not accept future upgrades, and still store and process everything. Of course they can. But as it will be more and more costly, the incentive to upgrade will grow, and eventually, people will do that, to not store terabytes of historical data in the future.

Yes. Related topic: https://groups.google.com/g/bitcoindev/c/iVLHJ1HWhoU

In general, people first thought about hard-forking existing testnet4, and implementing fixes on top of that. But: if testnet coins are traded, then the whole chain can be started from scratch as well. And if it makes writing code easier, and allows to remove some additional logic, like 20 minute minimal difficulty rule, then people are more willing to implement it like that.

Also, testnet5 with premined coins will probably be traded as well, so maybe the whole idea of testnets will be abandoned? Who knows? One way is to flood users with new testnets, to make new test coins equally worthless. Another option is to focus on signet or regtest, and remove testnet support completely from Bitcoin Core.

Yes. It may be changed in testnet5: https://bitcointalk.org/index.php?topic=5543921

The timewarp was fixed during difficulty adjustment. But mining blocks on CPU is still possible in testnet4.

Yes, different testnets have different rules. If there is enough content, then it can be splitted into several pages.

I think it is much simpler: people are worried, that there will be no human-written texts anymore. Now, if you want to talk with AI, then you can do it directly, and be sure, that no humans are involved. And if you want to talk with humans, then you can visit some forum, and be quite sure, that some particular members never used AI to write their posts, and are not planning to post AI-generated content as their own in the future. However, if AI usage will be allowed and promoted, then soon, you will have no humans to talk to. The Internet will be dead, and full of bots, willing to reply 24/7.

Not only that: the answer often seems to be correct, but is completely wrong. When I asked AI about Schoof–Elkies–Atkin algorithm, then first replies were more or less correct. But when I tried to get some real examples, and step-by-step calculations, then all of them were completely wrong, no matter how deep AI tried to analyze it.

Also, it is not that surprising, that some things are unsolvable by AI: if you have hundreds of humans, that wrote on forums in the past, that "this topic is hard", then you will get that kind of response from AI, instead of getting anything useful. Because the model was trained on some training data. And if there were a lot of texts like "just google it", or "this is too complicated", then this is exactly what you will get from AI, because it was trained just on that, and it cannot invent something on its own, if it was absent in the training data.

Another thing is that many AI models are currently much worse, than they were in 2022 or 2023. And the reason behind it is quite simple: in the past, we had a lot of humans, talking with AI bots, so AI was progressing very fast. But then, when people started feeding AI bots with AI-generated content, then we reached bots, talking with bots, and the quality dropped significantly.

By the way: many times it turned out, that by just creating a network, which pretends to use AI, and involving real humans instead, you can achieve much better answers in some cases. I wonder, how many experiments like that were performed during early stages of AI boom: because sometimes, some replies were really good, and looked like they were written by real humans. And now, for exactly the same prompts, no AI models can produce content with such quality anymore.

It is not a bug, it is a feature. If you use AI too much, then you start behaving like bots. And then, you may be detected as a bot, or have problems with CAPTCHAs.

AI can tell you everything you want to hear. It can give you a list of advantages of breaking hash functions. It can tell you that stealing content is a good thing. If your moral compass is AI-based, then it usually won't protect you from many mistakes: https://www.youtube.com/shorts/eVaj8YIS0bc

Does anyone know, how to reproduce Satoshi's seed, which was used to initialize his random number generator, when he tried to mine "bnNonce" in the prenet coinbase transaction in 2008?

Source code: https://bitcointalk.org/index.php?topic=382374.msg4108762#msg4108762
Here, we can see "695dbf0e" as "bnNonce". It is supposed to be random, but it is only some 32-bit number, so there are not so many values to check. And also, it comes from "BigNumber" library, which is also used for other purposes. So, is the same randomness used to generate the private key for "04 d451b0d7e567c615719a630b9f44632a0f34f5e7101f9942fe0b39996151cef1 0a809c443df2fab7cd7e58a3538cd8afd08ccfaa49b637de4b1b383f088ad131", or is it somehow separated? Because if it is connected, then potentially, this private key can be recovered.

Also, if the source of randomness is just some timestamp from 2008, then it could reveal, when exactly this public key was created.

It is defined by the maximum size of the block. See: https://mempool.space/tx/516c63376556d87c4779033327184ee00a08c4c14498e14673357ce4a791406b

So, in practice, it is something slightly below 1 MB. And if OP_RETURN is placed in unexecuted OP_IF branch, behind P2WSH, then it can take slightly less than 4 MB.

It would happen only when transaction size would exceed the maximum block size, or when OP_RETURN will be executed in witness space.

There are standardness rules. And it is set by default to 83 bytes, where one byte is taken by OP_RETURN, and two bytes are taken to declare the size of the stack push. And if you ignore Script decoding, then in practice, you can use one byte for OP_RETURN, and 82 bytes for anything.

There are three interesting constants used in "split_mix32" function: 0x9e3779b9, 0x21f0aaad and 0x735a2d97. I wonder, how exactly they were created. For the first one, I have some clue:
But for the rest, I have no idea.