Topic: [Aug 2022] Mempool empty! Use this opportunity to Consolidate your small inputs! - page 9. (Read 88277 times)

Except that you should always expect that the blocks will be filled. In the worst, spammers will fill it with garbage. May I remind you that spammers currently pay for highest priority? I'm pretty sure there will still be around if they can spam for free.

Doesn't work that way. If a spammer sees they can fill blocks with movies, expect movies on-chain. We've already seen this on BSV, and we all know what is its demand.

You've misunderstood the assignment. There's a supply too in demand and supply, not only demand. If you're doubling the block size every four years, transaction fees will drop a lot. When mempool weighs less than the block size, miners are incentivized to even confirm 0.01 sat/vb. For your math to apply, demand (for on-chain volume) needs to double every four years.

As I said it before, make up your mind!
If the on chain volume doesn't escalate and grow by 2x every time you will NOT have 1GB blocks!
If the chain volume doesn't grow one bit from now you will not have even 2 MB blocks, since unless I have lived in a different reality having the maximum limit at 1MB didn't make all blocks at least 1MB, it made them at most 1MB!

So again, your fear is irrational, since if you say there will be no volume for that then there will be no big blocks either!

As for sustainability, the fee in reward right now is 9%, you only need 10x demand to completely override the block reward which will not be gone tomorrow. If you don't think on-chain demand will be x10 times more in 25 years then you don't have to worry about the fate of Bitcoin anymore since it's pretty obvious what that would be! But again it's a funny contradiction
- you don't expect 10x more people to pay 3$ for a tx
- you expect people to pay $30 for a tx
Yup! 

That's my definition of scaling as well, but I was more concerned about the linear growth. What's your opinion about growing linearly?

Responding to your mail:
Alright. In the present epoch, it's 16. In the subsequent epoch, it's 32, then 64, then 128, and so on. Do you understand that the on-chain volume doesn't escalate at the same pace, ensuring the system's sustainability? What's your plan for 25 years ahead, when the block size surpasses 1 GB, there's no competition in the fee market, and Bitcoin inevitably comes to an end?

Just to make things clear!
Stompix himself, in his great wisdom wanted the block doubling since before the last having, and when I said doubling I meant that it would have been already doubled by now and we would be looking in the future for another one, so 4MB or a maximum theoretically size of 16.
So I never advocated for a sudden increase of xxx1000 times now, I said it's possible and all the technical mumbo jumbo about the capacity that would restrain it is bs , but I never was that radical in it!

Things like:


Just a tiny reminder this is no longer 2013, and a server 2Gbit/s guaranteed line is 99$ per month.
So how about we talk in 2024 prices and capacities, not a decade ago things, deal  

But again this is turning funny, first we had no need for bigger blocks as bigger blocks are empty over at bch and bsv, then we have 100GB blocks of full transactions because...majik..., I swear, and I mentioned a hundred times already why can't you guys be constant on your scenarios?

Oh, and back to the main topic...
Bad weekend for consolidations! 
 

Yes, for example here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019988.html

As you can see, I wrote about commitments long time ago, and today, I still think they are better than legacy OP_RETURNs, but instead of creating a separate output, they can be moved into R-value of the signature, then it is even better, because then it can be used on every address type.

Well, everyone can post on the mailing list. The main difference is that you have to wait some time for publication, so your post is not visible immediately, but is first read by some human, and then manually accepted. But besides that, it is similar to forums, and it doesn't matter that much, because many times I write some posts on disk, and they are sitting there, unpublished, and wait for future input. If after some days or weeks, they are still good enough to be published, then they are released.

By the way, in the current queue, I have some notes about RIPEMD-160 (and how it is related to SHA-1 or other hash functions), but I have to implement it from scratch, to write properly about it. And I guess Garlo Nicon is thinking about DLEQ, for example in the context of secp160k1. But all of that is work in progress.

In general, yes, but it depends, how things are internally wired. A lot of optimizations are based on parallelism, and if you have to do some sequential hashing, then it equally hurts all full nodes. Which means, that if some transaction is complex, then not only it is a bottleneck for mining pools, but it is also a bottleneck for non-mining nodes, used to propagate transactions in the network.

Some good video about x86 internal assembly, and why we are doomed to stick with some problems for years, even if we switch to another architecture: https://www.youtube.com/watch?v=xCBrtopAG80 (by the way, I expect sooner or later, the Script will be also splitted into smaller parts, like micro-ops, and it will be possible to deal with them more directly than today, so maybe the cost would not be measured in "satoshis per bytes").

But on other hand, a node already verify all transaction on it's mempool. So when the node receive new block, the node only need to verify few TX not in their block and other block data. And it's worth to mention usage of CPU instruction (such as SSE2) also somewhat allow more scaling.

It is true that the rest of the mining pools can trivially notice that the attacker is trying to make them run late, and ignore validating his block deliberately, because it's not worth the effort  / risk. Currently, no mining pool software does that, but it might be updated if there's need to.

Sounds like a bad strategy regardless. If it's mined on top of the attacker's block, then it depends on the attacker's block validity (trusting instead of verifying). If it ignores attacker's block, and mines at the same height, then there's no reason not to include highest paying transactions, since it competes with the attacker.

Would this megabyte type of transaction be propagated normally? I think it is non-standard.

Also, vjudeu, I'd appreciate if you could spare your two cents on the previous block size debate. Bigger block size arguments doesn't sound like that bad (anymore). This kind of attack is what still discourages the arbitrary block size increase, in my mind (apart from political conflicts which will, without doubt, arise). I think you support small block size, because I'd read you in the bitcoin-dev mailing list, and you're all small blockers there, IIRC.

I highly respect the endless hours you've spent, discussing on that mailing list. I think you can enlighten us.  

Very insightful post... I guess we'll need a graphene TeraHertz CPU for proper verification scaling.

Different pools will do different things. The attacker will know in advance, that "yes, this block is correct" or "no, it abuses sigops limit, or any other quirky rule". And during those 12 minutes, different pools may apply different strategies. One strategy is to mine a block with just the coinbase transaction, and nothing else. But: on top of which block it should be mined?

An honest miner can decide to mine on top of what is already validated. But then, there is a risk, that this "12 minutes block" is not an attack. Maybe all of those transactions were flying in mempools, and some mining pool just included all of them, without having any evil plan in mind? But then, how to quickly check all rules, without performing full block validation?

It depends. Mining a block with some coinbase transaction, and nothing else, would be always valid, if the previous block is valid. Which means, that mining pools can mine on top of attacker's block, and then they will keep validating it.

Some example of sigops limit violation: https://bitcointalksearch.org/topic/m.62014494

And then, imagine that you know in advance, that some mining pools use some kind of simplified block validation, and they don't check every rule (to get a better performace, because of using outdated custom software, or for whatever reason). Then, you may broadcast for example a lot of 1-of-3 multisig transactions into the network on purpose, and wait for other pools to grab them, and mine a new block. Then, you have 80k sigops limit, but some of their blocks may accidentally have 80,003. And there are more quirky rules to exploit.

Also, if you broadcast transactions, which are valid, but can become invalid in a particular context, then you can always say later: "See? Those transactions are valid, because they are included in other blocks, we did nothing wrong!".

What happens during those 12 minutes? I'd expect the mining pools to continue mining for that block, and chances are they'll find a new block within 12 minutes. Once that happens, they can stop verifying the attacker's block, and the attacker risks having his block replaced.

That's the attack I was looking for but couldn't find. Thanks, garlonicon! As I understand it, this attack requires dedicating a little less than 1 MB of block space to execute. Currently, it is very expensive, but if the block size limit is 16 MB, a mining pool attacker could always fill a quarter of their block with these transactions. This would force the rest of the network to spend more than 12 minutes verifying them, effectively giving the attacker 12 minutes to mine alone.

Is that perhaps one of the best arguments in favor of a small block size? I see that it can practically only be resolved if we start implementing even more severe exclusions in the Script, but I'm not sure if it could be trivially resolved otherwise.

In a way, it's a flaw of the way Bitcoin works: miners have a financial incentive to keep transaction fees high, even if that reduces Bitcoin's usability.

There is one problem with that approach: verification. Sending the whole chain is not a problem. But verifying still is. And what is the bottleneck of verification? For example CPU speed, which depends on frequency:

2011-09-13: Maximum Speed | AMD FX Processor Takes Guinness World Record

2022-12-21: First 9 GHz CPU (overclocked Intel 13900K)

See? Humans are still struggling with reaching 8-9 GHz, and you need a liquid nitrogen to maintain that value. And more than a decade ago, the situation was pretty much the same. So, the CPU speed is not "doubled" every year. Instead, you have just more and more cores, and you have for example 64-core processor, instead of having 2-core or 4-core.

Which means that yes, you can download 100 GB, maybe even more. But is the whole system really trustless, if you have no chance of verifying that data, and you have to trust, that all of them are correct? Imagine that you can download the whole chain very quickly, but it is not verified. What then?

Also note, that if something can be done in parallel, then yes, you can use 64-core processor, and execute 64 different things at the same time. However, many steps during validation are sequential. The whole chain is a sequence of blocks. The whole block is a sequence of transactions (and their order does matter, if one output is an input in another transaction in the same block). The hashing of legacy transactions is sequential (also in cases like bare multisig, which has O(n^2) complexity for no reason).

So yes, you can have 64-core processor with 4 GHz each, but a single core with 256 GHz would allow much more scaling. And this is one of the reasons, why we don't have bigger blocks. The progress in validation time is just not sufficient to increase it much further.

Miners is another obstacle I completely overlooked. By rising the block size to 16 MB, you need to convince them that this will be more beneficial for their pockets, which is very debatable. At the moment, a simple wave of Ordinals can rise their block fees income by 100%.

You need to convince them that on-chain transaction volume will eventually increase by orders of magnitude compared to before, but none of us can responsibly make that promise. No one can be held accountable for the potential shortcomings.

Miners are in charge of creating new blocks, every user is in charge of which consensus rules they accept. Of course, without miners that means there are no new blocks.
It's kinda sad the "one computer, one vote" thing can't work.

Are you sure about that?

Because even serious bugs early on were fixed with a soft fork.

But this isn't ETH where Vitalik's team controls the network... SHA-256 miners are in charge of the BTC network, so good luck trying to convince them.

That was a softfork. When you invalidate a currently valid rule, it's a softfork, and in this case, you invalidate blocks with size > 1 MB. However, a few years after this, a hardfork emerged.

Any decision taken by Satoshi was unquestionably followed, because... it was Satoshi. It's good that we don't have that source of influence anymore.

It still is surrounded by loads of controversy. First things first, what's the ideal block size increase? We're agreeing on the 16 MB limit, but stompix wants it to double on every halving. Another one might think 16 MB is still very small. I can already predict that the hardfork will end up just like Bitcoin Cash; uncertainty on the ideal adjustment will encourage people to stick with the tested, conservative 4 MB.

I want to remind you, at this point, that before Bitcoin Cash, there were Bitcoin developers who supported big blocks. The fact that they split a long time ago highlights how unlikely it is for the current small block developers to suddenly change their minds.

Isn't it more likely they use dollars or other coins for that? I don't expect real Bitcoin owners to exchange it for a made-up centralized token, but especially Binance tries really hard to make people withdraw their own made-up tokens instead of Bitcoin.

Yeah, "wrapped" coin is definitely more popular. But either way, you still need one Bitcoin on-chain TX in order to send your Bitcoin to exchange/other service, to obtain the "wrapped" coin.


Most straightforward option would be increasing witness discount from 4 to 16. But without making Ordinal or other TX which use OP_FALSE OP_IF ... OP_ENDIF non-standard, it'll just make cost to spam on Bitcoin blockchain even cheaper.

I don't think a softfork can do this, but then again, when the limit was lowered, it must have been a hardfork too. Except for back then there wasn't much controversy about it.

That was 7 years ago, surrounded by loads of contoversy, and promoted by some people with their own agenda. I don't think it's right to use that failure to keep blocks the same size for eternity. I don't think a proper change, coming from the Bitcoin Core devs, that actually improves Bitcoin's future will be rejected.