Well, you already sent a donation to someone else, who is working in the same group as me. So, that simply means, if you didn't recognize our donation address, then it means, that our network didn't propagate to search engines yet. But I thought this particular address is already indexed. If it is not, then it means, that search engines are not that fast, or that they are worse at indexing text-based content.

Because there are a few groups of developers, and it is funny, if people want to for example send donations, or became merit sources, and they pick posts, written from different accounts, but controlled by the same group.

Because usually, people are trying to reward different groups, and pick posts, that are more or less disconnected, to make everything more "fair".

However, in practice, there are not that many users, which can produce a good content. So, even if some people are trying to merit someone else, or reward other people, after some time, people from our group are rewarded anyway, just because many different forum users like our content; and sometimes, there is nothing better.

So, it would be funny, if you would send next donations to the next members of our group. And maybe it is a good idea, to send my content to some other posters, so they will publish it, and receive more merits and more donations? Because now, I can clearly see, that a single source is sending its content through different groups, so many great posts are published from different places, but they use the same stylometry tools (and it is even more funny, when some people think, that all of that is produced by a single individual; especially if you know them more, and saw, how strongly some developers disagreed in some topics).

So far so good. Being mentioned in 20% quoted posts of some merit source applications is quite a good achievement, I would say. And now, if we are going to occupy around 20% of your donation list, when you will spend more time in Development & Technical Discussion, that would be funny.

To achieve that, AI would need to know, how to count. Now, not only existing AI models don't know, how to compute SHA-256 (not to mention double SHA-256), but they fail at simple counting.

Ask AI model to count from one to one million. Let us know, when you will succeed. Because it often looks like that: https://www.facebook.com/reel/1138880084809988

Maybe this one will ring a bell: https://mempool.space/address/bc1qfgrajdtd49cy20hejervlqx2sndlwwpfrlz7jj

It doesn't matter, because doing it as a hard-fork is a bad idea. So, if anyone will try to do that, then it will be just yet another altcoin.

I don't know, why developers with that much experience think, that it can be done only as a hard-fork. It is quite easy to notice, that it can be done as a no-fork (not even a soft-fork), because any node, at any time, can always say "I don't have it", when asked about any block or transaction. And then, ZK-proofs can be provided in a different P2P message, for new nodes, which could handle it correctly.

I don't understand, why people do need any "multisig committee" at all. Because if you have ZK-proofs, then you can enable them for all transactions. There is no need to pick, which transaction should went through ZK-proof, and which one shouldn't. If the end goal is to make it easier to process the chain, then everything should be treated with ZK-proofs, because it is better to speedup everything, and not only some portion of the chain, and keep the rest slower, and handled in old, plaintext way.

But they can. It can be a no-fork. For example: some nodes are storing transactions in compressed form. And they didn't fork the chain to get there. If you can compress and decompress any transaction on-the-fly, then you can stay compatible with the protocol.

Also, refusing to provide a transaction or a block in plaintext, is a similar thing, as when you seed a torrent file. If one peer doesn't have it, then another peer will. The only problem is when nobody has it, but in case of payments, it could simply mean, that nobody needs it, and then that single coin can become unspendable in practice (and can be easily made spendable again, if anyone will find that data later).

So, the better approach is to push all transactions through ZK-proofs, no matter if they are payments or not.

It is not. Even when we run out of timestamps in 2106, then it could be also solved with a soft-fork. In that case, old nodes could see for example constantly reorged chain, while new nodes could see it smoothly going forward. But old and new nodes can live in the same network, if needed.

It doesn't, because it is in the coinbase input instead. The meaning of OP_RETURN was different then, because you could spend anything with "OP_TRUE OP_RETURN".

Also, no consensus rule forces you to store the content of the Genesis Block, because it is unspendable. You can just keep its hash, if you want to, or stick to the 80-byte header, if you want to be safe. But the content of transaction 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b can be entirely removed, and you will end up in the same chain, as long as your node wouldn't allow changing the first block from 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f to anything else.

Because the first transaction is unspendable, so it is never stored in the UTXO set in the first place. You need it only to prove, that the chain started in 2009, and not in 1970. But on the protocol level, the Genesis Block is hardcoded, so as long as SHA-256 is strong, you don't need to store it in your node.

It is clearly false, because otherwise, we wouldn't have any soft-forks. Also, in that case, we would have something more similar to BIP-17, instead of BIP-16. And then, instead of introducing any new opcodes, we would always wrap everything in the long chain of old ones.

Why not? For example: signet blocks have 1 MB max witness size, instead of 4 MB. Which means 250 kB legacy space in practice. And that change would be at least consistent with 300 kB blocks, proposed by Luke-Jr. So, if they would shrink blocks, it would be at least consistent. And fortunately, mining smaller blocks is a no-fork, because miners can mine even empty blocks, with only the coinbase transaction, if they want to. So, pools controlled by Luke-Jr, can decide to shrink blocks they produce, and contribute to the smaller total blockchain size.

Some people never learn. In case of a hard-fork, everyone knows, what to do. Then, the situation is the same, as it was during BTC and BCH: sell the coin you don't want, and buy the coin you want. Which means, that people can sell Luke-BTCs for BTCs, and move on. It is already tested, there were many Bitcoin copycats, this one won't be anything new, if it would be a hard-fork.

Hard-forks are not serious. If some hard-fork doesn't have 99.9% market support, then it can easily fail. The "logical path" would be to handle a subset of the mainnet traffic, while still working on the same chain. Forcing censorship on everyone is going to hurt censors more, than the rest of the community. It is much better to convince people, to stay on the same chain, and handle only part of it, instead of forcing everyone to prune some data.

Also, the logical consequence is that some people would use Luke-BTCs, to push data inside private keys, and expose them through weak signatures. If that could work on Grin and Monero, then it could work on Luke-BTCs as well. And then, if everyone will see, that spammers can put their data even into Luke-BTCs, then the community will switch back to the original chain. And then, traders will do the rest, by bringing Luke-BTCs value to the similar levels, as BCH and BSV, or even below that.

Another thing is if Luke's chain will not have 51% hashrate support from double-SHA-256 hashers, then it would be ironic, if it would be attacked in a similar way, as CoiledCoin. Because mining Luke-BTCs and selling them for BTCs is something, that does not break any consensus rules. And if Luke-BTCs will be attacked in a similar way, as testnets were, then he will just taste his own medicine, by seeing his chain destroyed, or made unusable in a similar way, as some altcoins, which were attacked by him.

This is how AI works in practice.

Yes. Because an account, which is created today, or yesterday, is worth less, than something, which was created years ago. Also, it is then easier to abuse activity counter, because then, it is usually equal to the post counter.

There is "freeze coin" feature in Electrum. And you can do a similar thing in Bitcoin Core. For example:

You can just have a real wallet with some small amount.

They are called "test coins". You can pick testnet3, testnet4, signet, or regtest. The problem with testnets is that they are worth non-zero amounts, so they are no longer "fake". But yes, nothing stops you from using an altcoin, which would be based on Bitcoin, for example BCH, and pretend to believe, that "BCH is Bitcoin", and when you said "I have one Bitcoin", then you meant "1 BCH", instead of "1 BTC".

Yeah, many people forget, that we are here in a P2P world. If your only goal, is to see something in some block explorer, or a site like that, then it is easy. It is then only about making a web page, that could display you anything. It could even say, that you have more than 21 million coins, because why not.

That's why the simplest solution is to have a separate wallet with some small amount. And you can even use different units, like mBTC, or bits, or even count everything in satoshis, if you want to.

Yes, and send it through https://live.blockcypher.com/btc/pushtx/ because they can accept it, and display it, and even say, that it has something like 20% probability to be included in the next block, even if you timelock it to 10 years.

It is probably better to show a buggy block explorer, like the one linked above. But I guess there are more buggy ones, and another one can be made, if the operators of this specific one will decide to ever fix it.

This is hard to do, because adding opcodes (like OP_CLTV or OP_CSV) makes the whole thing Script-based, and not key-based. And if you alter a single bit in the output Script, then you will get a different address out of it.

But yes, if someone is using Script-based addresses, then "<lockConditions> OP_CODESEPARATOR <normalConditions>" is a good envelope to use, because then, you can pretend, that the output Script is set to just "<normalConditions>", and sign it properly.

I guess many people were scammed, by buying test coins, at the price of Bitcoin, or even bought BCH or BSV, thinking they are buying BTC.

Which means filtering literally all transactions. There are already settings for that, you can just receive new blocks, and stop relaying any transactions at all.

Not "may", but "will", because people can store data in their private keys, and use weak signatures, to allow going from public to private key (it would have spamming efficiency of around 1/3 in the worst case, which means wasting 3 MB of block space, to put 1 MB of any payload on-chain; and only non-spammers will process these 3 MB, because spammers can compute everything out of this 1 MB in deterministic way). And it works across all chains, including Grin and Monero.

Also, in case of Monero, it can be used to deanonymize some traffic, if you interact with other users. Then, some user could mix some UTXOs with your coins, and you can break someone else's privacy, if for example 19 out of 20 keys are weak. Then, it is quite clear, who sent what, and where, because all weak keys can be easily detected, and stripped, so the real payment can be revealed to everyone.

That's the main problem of spammers: they don't care about "private inscriptions", which are cheaper, and which are as hard to censor, as the regular payment is. Because if users would legitimately want to use Bitcoin to commit to some JPEGs, then they could do so in a better way, than by pushing easily-to-detect, non-consensus data. A single public key can commit to gigabytes, if users would want to. And Ordinals are possible even in a system, where only P2PK is allowed.

In general, you don't have to process anyone's transactions, except your own. As long as you can get external proof, that the chain is valid, and validate it properly, you can just sync the block headers, verify your own transactions, and if you have a proof, that the whole chain is correct, then your transactions also are, as long as they are just included in it.

Of course it can. Legacy nodes don't see blocks bigger than 1 MB. Segwit nodes don't see blocks bigger than 4 MB. But it is possible to make yet another soft-fork, where blocks would be unlimited, just like it is in BSV. It is only a matter of getting a hashrate majority on your side. Consensus is not protected from coordinated block size increase in any way, and Segwit can clearly show, how to deploy things like that in practice.

Not yet. But even today, when the size of the chain takes hundreds of GB, and where synchronizing a node can take weeks, many users decide to not run any node at all, and rely only on SPV wallet, or on block explorers, or even on exchanges, or contracts like CFD, which don't have to touch any real blockchain at all.

And it is very unlikely, that people will massively start running P2P nodes. It is much more likely, that they will pick more centralized solutions, just because they are more convenient. Only when people will start losing money, like it was in 2008, then they will switch to something better, when there will be no other choice.

Of course it is. If you have a lot of non-monetary transactions, and they pay higher fees, then they take place of regular transactions. You can confirm this transaction or that transaction, in a given block. You cannot confirm both, if there is not enough room in a block.

Also, if miners would decide, to send self-transfers with 100% transaction fees, then they could block all users from transacting, for arbitrary long period of time. As long as hashrate majority would get these coins back in fees, the protocol would work. And the same could happen, if hashrate majority would decide to produce only empty blocks, but then, it is obvious to everyone, that some attack is ongoing.

It is quite simple: if miners could change their policy, and nodes would follow miners, then it would mean, that miners can lift more and more limits, and nodes would always follow them. Which would turn miners into a position, where they could start making decisions about the protocol.

Because this is a new attack. Earlier, miners followed Bitcoin Core implementation, and what users wanted, to produce the most valuable coin. But now, some mining pools simply make their own rules, and if hashrate majority would follow, then it would cause node operators, and software developers, to lift next limits, and to give miners more power, than they should have.

The border is not yet known. What if miners would decide to activate a soft-fork, which would give them more coins through things like tail supply? Nobody knows yet, but I am pretty sure, that all possible limits will be tested in the future in practice. Some of them may lead to altcoins, many of them may die, or turn out to be irrelevant, but remember: attacks only get stronger. And people know enough, to not repeat the same mistakes, as BCH or BSV did.

Also note, that protocols like Ordinals, are built on top of BTC, instead of having their own chain. Because they know, that attacking the king of crypto, makes their buggy protocols and tokens worth more. So, I expect even more non-monetary transactions on-chain. Bitcoin will become a cloud storage, unless some users will decide to put some protections, and process only a subset of mainnet traffic. Otherwise, people will be spammed, until they give up.

There is no need to make any forks, to process less transactions, than the main chain is processing. It can be done without any forking.

To get the heaviest chain of block headers, you have to consume only 80-byte block headers. For everything else, you can use ZK proofs, or other things. You are never forced to store the content of transactions in plaintext. The only thing you have to know, is if a given block is valid, or not. And beyond that, you have to store your own transactions. But you don't have to process someone else's transactions, if you don't want to. There is no consensus rule, which would say so.

There is no need to "fork" anything. If miners would put "I hate Ordinals" in their coinbase transaction, or tweak some bit in block version, then it would never split the chain. The fork could happen only, if one group of nodes would react to a signal, by marking some block as "invalid". If both groups accept all blocks, then there is no fork, it is then only a meaningless statistics.

Miners always moderated it. If you have "Alice -> Bob" transaction, and "Alice -> Charlie" transaction, then miners decide, which one should be confirmed.

Also, nodes always moderated it, by enforcing "standardness rules", which also allows upgrading the protocol, without blocking anyone else's coins. When standardness rules will be lifted, then it will be harder to upgrade the protocol.

They have the authority, because they have a lot of hashrate, so they can produce a lot of Proof of Work. However, if users will be disappointed, then they can always pick a different chain as "valid", and move their coins to the system, which they want to use. And for that reason, miners can decide about a lot of things, but not about everything.

And when it comes to nodes, they can always moderate the traffic. More than that: they can provide different services. There are nodes, which don't relay any transactions at all, but they are still part of the network, because they accept blocks.

Any node can decide, which features are supported, and which are not. For example: P2P marketplace was supported in the past, but it was disabled in early release. The same with poker game, built into the client.

Yes, because if your transaction is mined by a pool with 1% hashrate, and censored by 99% of hashrate majority, then on average, you will wait at least 100 blocks, to see it confirmed.

Also, it is possible to accept a lot of transactions in relay mode, but include only a small subset of that in produced block templates. Because relay rules, and block creation rules, are separated.

I think relay rules will be more relaxed, and maybe even non-standard transactions will be relayed in the future. But block inclusion rules should be more strict. Because then, users could send a lot of things over P2P network, and a lot of these things can be used only for communication, related to making batched transactions. And then, users could send hundreds, or even thousands of transactions, and all of them could be relayed. Then, all of that traffic could be collected and processed by nodes. And then, the final, batched version, with the highest fees, could be taken by miners, and confirmed.

Also, P2P batching is actually used in practice, for example in signet faucets: https://mempool.space/signet/tx/2f4ffd821a1d81f27cc2b16c50c7105e8b25585fd0a68a80c70da35a62b99107

See "RBF Timeline", where the same transaction is bumped over and over again, until it is confirmed. In the same way, users could start sending transactions, and bump them by single satoshis each, and finally, it could reach 0.1 sat/vB, 1 sat/vB, 10 sat/vB, or any other meaningful fee rate, and serve many users, while also taking less on-chain bytes, than it would, if people would send it without any batching.

Mining pools started confirming these transactions, instead of blindly following Bitcoin Core.

If you have a block template, that you can get through "getblocktemplate", then it contains transactions, that are flying in different mempools. As long as this template is identical in most nodes, you have all transactions already validated, when the new block is mined. Then, verifying a given block is very fast.

However, if some mining pool produces a block, which contains transactions, that were never broadcasted before, then nodes have to download these transactions, and verify them, to know, if a block is valid or not.

And this is the main reason, why developers decided to lift more limits. Because they are already lifted by mining pools. So, keeping them does not change anything, and only makes everything slightly slower, if some node actively rejects some transactions, and they are later downloaded again, when a new block is produced.

Which also means, that there is a new attack, that can be done, and that cannot be easily stopped: miners could decide to produce 4 MB blocks, with self-transfers, which would be costly to validate, and which would break any standardness rules, while also being valid, when it comes to consensus rules. And then, if miners will keep breaking next limits, then developers will keep lifting them. And then, the end result would be a chain, where only consensus rules are enforced, and there is no longer any concept of "non-standard transaction", so there is no obvious way to make new soft-forks, without burning someone's coins.

The whole cryptography is built on top of that assumption. Caesar cipher was also great in the past, as well as Enigma was, not that long time ago. And now, we have computers, so these old ciphers are obsolete.

And the same is true with ECDSA: if one randomly generated key is weak, then all of them are, which are based on the same entropy. Which means, that if you have some legacy wallet, then you also have "HD wallet" in practice, just the input to that wallet is more complex, and it has more bits of entropy, than just some 128-bit or 256-bit seed. But still: it is technically possible to target old wallets, by guessing their entropy. It is impractical now, but can be practical in the future.

Because what happens, when you want to get a random key from a legacy wallet? Your device just grabs some entropy from your Operating System, and then it is often hashed through SHA-256, or processed in other similar way, and then, you have a private key out of it. And what happens, when your OS entropy is too low? Well, then your keys are weak. But they are never "random". They are always based on "something". Even if you flip a coin, or roll a dice, then still, it is not a fully "random" input. It has just bigger entropy, than needed, but all of that, is always simplified to a single 256-bit private key, which always have at most 128-bit security, no matter what you use to generate it.

Which means, that HD wallets are not "weaker". They can only capture your "entropy generator" into something manageable. But if you would replace it with an algorithm, which would take things, that are captured by your OS, then guess what: you will get the same private keys! You can always take some old wallet, even with 0.1.0 version, and run it in some environment, where it will always produce the same keys. It is just a matter of your OS entropy.

Also, while in HD wallets, you need that strong entropy only once, in legacy wallets, you need it every time, when you generate a new key. Which means, that if you have a single, strong HD key, then the whole wallet is strong. But if an attacker can compromise your entropy only for a while, then in legacy wallet, some of your keys could be weak. And if you are unlucky, and you will sweep everything to a weak key, then all of that is gone (while in HD wallet, even if your OS entropy would be weak for a moment, then because of deterministic signatures, the client will never ask the system about entropy, once you fill it with a single, strong seed).

If your choice is to pay higher fees, enable transaction malleability, and quadratic hashing, then it is your choice. You will just pay higher fees, for making transactions, which are harder to process. Because huge Segwit transaction can be processed faster, than a huge legacy transaction. We could lift transaction size limit, if the whole content would be hashed only once, no matter what Script would be used. But because of FindAndDelete implementation, it cannot be done.

Fortunately, if you use P2PKH, then your blocks would be at least smaller. But when 160-bit hash collisions will be there, then you will be forced to upgrade to something else anyway (we have chainwork around 2^96 for double SHA-256, collisions in RIPEMD-160 require 2^80 hashes, so they may be practical, if there will be enough incentive).

1. If someone has some old wallet, then that person usually also can see some old transactions, even if it is SPV wallet.
2. If new coins were sent in the meantime, then without syncing the node, the owner does not know, if he received anything at all. Because online sites like block explorers can lie. And if the owner would sync even some SPV wallet, then he would get transactions in plaintext.

That would happen only in case of "walletless" people, who just trust, that block explorers, and other online sites, are telling the truth. But in that case, they could be easily robbed anyway, because if a given block explorer would display some fake SHA-256 hash, and that would be signed with the real keys, then coins could be easily stolen in many cases, because a valid signature for a fake transaction, could be used in other contexts, to trigger some unexpected conditions.

It is inevitable. If you count, how many pruned nodes are there, and compare it with the number of "nodeless" users, then I think the majority is not running any node at all. A lot of users are using SPV wallets, many users use exchanges, and never touch any on-chain coins, and now, more and more users are trading things like CFDs, where they don't have to touch any crypto, and where everything can be fake.

Also, if you think about it, and count, how many UTXOs can be created and consumed per block, then you will notice, that if Bitcoin would be adopted globally, then one UTXO per user is not a realistic scenario. It is very likely, that if people would want to globally use Bitcoin, then there would be thousands, millions, or more users, committed to a single UTXO. Which also means, that regular users would need many SPV-like merkle trees, to locate their coins on-chain. Now, LN assumes two users per UTXO, but this number is quite low, and it is not enough to onboard everyone.

It is very unlikely, that any soft-fork will be "reverted". All Segwit nodes will mark such block as "invalid", if coins will be moved without any signatures. Also, if breaking rules would be so easy, then what about P2PK? You can also use "anyonecanspend attack vector" here, and move any coins anywhere, without any signatures. Because if you would have a client, which would allow always spending any coins, then it would be compatible with the current chain. You can start a node, disable the whole Script, make all coins spendable, and you will sync it to the chain tip, without any problems.

More than that: what about "Value Overflow Incident attack vector"? Because that fix was also a soft-fork. You can have a client, which would allow producing coins out of thin air, and it will also successfully sync the whole chain, up to the current chain tip. Are you still worried, that this fix will also be "reverted"?

Why? If soft-forks could be easily "reverted", then any rules could be "lifted", by using exactly the same attack vector. For example: what about 21 million coins limit? If you would have a client, where there would be no halvings, and the basic block reward would be set to 50 coins forever, then guess what: it would sync the whole chain without any problems. Because the reward, claimed by miner, can be always smaller. It cannot be bigger, but coins can be burned, and miners could always decide to burn all new coins and fees in the coinbase transaction. So, a node, which would enforce no halvings, would land on the same chain, just because hashrate majority enforces "soft-forked halvings".

Then, demonstrate me a practical attack on some HD wallet. Show me, how to get 900 BTC from the puzzle.

Wrong. If you make an empty wallet, then it is empty. It contains only keys, which you manually import. If there are no descriptors, which automatically can be used to make new addresses, then if you try to make a new address, it won't work. For example:
See? Commands like "getnewaddress" can work, if the wallet knows, how to make a new address. But if it doesn't, then it only stores the things you put there, without adding anything new.

Existing keys are imported, so you can see them in "listdescriptors". But if there are just single keys or addresses, then the wallet does not know, how to make new addresses, so you will have to decide about it manually, generate new keys manually, import them manually, and decide, how they should be handled.

If you start from an empty wallet, then there are no seeds. You don't have to use public keys in a descriptor wallet. You can even use keyless puzzles, if you want to.

Empty wallet is a non-HD wallet. No new addresses are automatically generated in a deterministic way, if you don't let the wallet know, how to do that.

If you use "listdescriptors true", then you can dump the content on a paper, and later import it through "importdescriptors". And you can have only WIF keys, without any HD keys, if you want to. Or even keyless addresses, if you need them.

You can do that, key-by-key, from WIF. What else do you need?

Yeah, and it is still present, because you can still use legacy addresses. It could be fully eliminated, if legacy addresses would be obsolete, would be fully unsafe, and as easy to move as OP_TRUE is, and then, they could be made non-standard (not "invalid", because of the past timelocked transactions; as long as there are any legacy UTXOs, they cannot be fully invalidated).

Then tell me, should it have P2PK? Because in the Genesis Block, and in many blocks after it, coins were sent to public keys, not addresses.

Of course, because every HD wallet is in practice a single key, that is expanded in deterministic way. And if you somehow break that key, then you will access everything. But good luck with that. The famous puzzle from transaction 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15 also used HD wallet.

And more than that: public keys from 161-bit to 256-bit range were revealed. Many private keys with lower ranges, up to 70-bit, are known. So what? Over 900 BTC is waiting for you, so just break a single key, and grab them all. Hmm, you don't know how? Well, maybe because it is not so easy, to compromise a HD wallet. So, don't worry too much about HD wallet security. This challenge can prove you, that HD wallets can be safe, otherwise you would sweep all of that instantly, if you would know some weakness.

But they are supported. You can have a descriptor wallet, and load each and every key from WIF manually. So, what exactly is your problem?

What if you receive merits after sending coins? Or what if a different post will be merited instead, just to bypass the rules? The receiver would need to put you on a merit blacklist, to be fully safe.

Merit trading is discouraged, but cannot be easily detected in practice.

Of course it would be. But the default option is to "do nothing", so expect that option to be deployed, unless someone will propose something else.

If some transaction has enough information, that it is accepted in a block, then what else is needed, if it is flying in mempools?

It is hard to put limits back, when they are lifted. Nobody would accept that, for the same reason, why nobody would rise minimal fees from 0.1 sat/vB into 1 sat/vB or 10 sat/vB.

Introducing standardness rules was easy during early days, because there were not so many nodes. But now, if non-standard transactions will be widely included, then in practice, we would need a new way of upgrading things (fortunately, there are some, but they are unused, because it is easier to increase Segwit version, at least for now).

It is not a question, if UTXO set will explode. The only question is "when?".

Yes, so aware users should be prepared for that now, by saving more things than just their private keys in their backups. And unaware users will of course suffer. And then, only spammers can be blamed, because they are pushing us to the world, where accepting UTXO proofs is inevitable, when there is too much spam.

Being your own bank comes with some responsibility. Users should watch quantum progress, users should keep their transaction data somewhere, users should not use too far in the future locktimes, to not risk their funds being burned forever, and so on. That is a price you have to pay for P2P transactions: that you have to care about consensus rules, and the current state of the network.

It can be turned into 2/3, or something around 1/2 in practice, if signatures would be weak, but if they would also carry some data. For example: 128-bit signatures are weak. You can have the first half of the signature, which would just make it weak, and inform about the order, and the second half can carry some data. Then, by using lattice attacks, private keys can be easily recovered, so you can read everything.

If a given elliptic curve would be fully broken, you would reach 2/3 spamming efficiency, where for every 96 bytes of consensus data, 64 bytes would be taken by the payload, and 32 bytes would just make things tick under ECDSA. But in practice, under lattice attacks, I expect the spamming factor to be closer to something like 1/2, because you have to leak some bits somehow, to make going from public to private key easy enough, so your data could be read by anyone.

And then, spamming efficiency of 2/3 is just the same as in Bitcoin with P2PK, and nothing else. But 1/2 spamming efficiency, or even 1/3, is something practical. I guess some spammers would happily waste 3 MB of MW blockchain space, just to publish 1 MB of data in it.