Topic: [POLL] Is bigger block capacity still a taboo? - page 3. (Read 1730 times)

Many people keep bringing the results of this poll as a way of saying that the community is divided.

First off, bitcointalk polls receive anonymous responses from any account so don't take them too seriously.

But even as a pointer, I don't think it shows any division. If anything, these results show that the discussion has matured a lot since 2015 and the community has grown a lot:



The environment was very hostile in these years circa the "block size wars" because many had jumped on the opportunity to profit against BTC itself by forking off to their own coins and whatnot.
Long time has passed since then and most of these altcoins are no longer relevant. So to me this vote indicates progress.
If a sound solution to scaling was to be proposed now it would probably receive better level headed discussion.

Note the difference between being "bad" and being "non-scalable". It is only non-scalable, it doesn't mean it is bad, it only means you cannot call it "scaling", because it has exactly the same scale. Unless you think that 1:1 scale is something entirely different than 10:10 scale or 100:100 scale.

Why later, and why not now? Is compressing 4 MB somehow different than compressing 32 MB? In the end, if you want to talk about scaling, you will still express your compression in percentage, or in the number of total bytes used, if your initial size is constant.

Also note that signatures are easier to compress than arbitrary data, because you can add public keys, and it is cryptographically equivalent, while you cannot losslessly drop data chunks in the middle, because then you lose that data. Which means, Ordinals are hard to compress, while signatures are easier to compress. Which also means, regular signatures should be compressed, and Ordinals should be left as they are. In this way, regular users could get any way to defend themselves, when fees are too high.

There were many different reasons. You can read the mailing list, or read topics like that: https://bitcointalksearch.org/topic/drivechain-critiques-by-gmaxwell-revisited-maybe-you-changed-your-mind-5231460
Maybe I will add something more, is this is not enough, but maybe not in this topic.

By some of the mailing list participants, and code reviewers, of course. Also, I can look for more details, if you need them, but maybe not in this topic, because as you can see above, there were some other topics about sidechains, and they probably fit better.

Also, maybe "rejected" is a too strong word. Some people could argue, that they were "postponed" or "paused, and sent back to fix some points". It depends, who you ask, because this is how decentralization works: different people will tell you different things, and maybe a better way to say that is "those specific, and submitted BIPs, related to sidechains, failed to reach consensus (yet)".

I'll have to agree with vjudeu's definition of scaling, even though I'd endorse a block size increase which is based on a studied rationale.

Sure, but why is linear growth necessarily bad? You need a linearly grown basis to base your compression model later on.

What was the reasoning of this rejection? And by whom were they rejected?

Go on, give it a try. Or find somebody, who thinks in the same way, and encourage that person into coding it. Or maybe you already did it? If so, where can I download the client?

If you want to ask me the same question, then sidechains can be downloaded here: https://www.drivechain.info/
But because they were rejected as a soft-fork, I am trying to create something else.

Did I understand correctly that you are trying to refute that costs are measured in money? There is nothing much to comment on here.

"1 BTC is worth 1 BTC"
OK. Let's calculate in BTC. How many bitcoins do you currently need to rewrite the code? Let’s estimate it at 1000btc. I won't be much mistaken.  Total bitcoins are ~19 million.

Spend 0.0053% of system cost to scale the entire system by 10x. Is this a good scaling?

Testnet can handle exactly the same bytes, with exactly the same hardware, but those coins are worthless. Does it mean that we should take the current price of Bitcoin in dollars, and base our scalability on that? Because guess what: 1 BTC is worth 1 BTC. If you want to measure it "in monetary terms", then you have to use a price, relative to altcoins, or to fiat currencies (for example USD), or to goods and services you can buy with that (for example food). Is this what you want? Do you want to measure for example fees in dollars to decide, if the price is too high or not?

It's strange that you count the resources spent in bytes, in "virtual bytes". When all over the world, resources spent are usually assessed in monetary terms.

Now, thanks to the development of technology, a modern computer can process blocks of 10 MB in size without problems and without significant additional costs. (It's time to record this fact and not come back again)

And it turns out that simply by rewriting the code, we can increase the capabilities of the system, which is now valued at ~$700 billion, by 10 times. I repeat, just rewriting the code.

Evaluate the ratio of the results obtained to the resources spent. Isn't this ideal scaling?

Yes. I like that kind of approaching the problem, by the way.

Scaling is directly related with compression. If you can use the same resources to achieve more goals, then that thing is "scalable". So, if the size of the block is 1 MB, and your "scaling" is just "let's increase it into 4 MB", then it is not a scaling anymore. It is just a pure, linear growth. You increase numbers four times, so you can now handle 4x more traffic. But it is not scaling. Not at all.

Scaling is about resources. If you can handle 16x more traffic with only 4x bigger blocks, then this is somewhat scalable. But we can go even further: if you can handle 100x more traffic, or even 1000x more traffic with only 4x bigger blocks, then this has even better scalability.

Also, scaling is directly related to intelligence. You can read more about Hutter Prize, which was advertized by Garlo Nicon some time ago: http://prize.hutter1.net/

I will add a bonus question: how do you measure if your model is scalable or not? Write it as a function in big-O-notation, or anything you like. I support "constant-based scaling", which means O(1) scaling, which means leaving current resources as they are, and improving algorithms to build things on top of that, for example through commitments.

Is it because it would also depend on what that person's definition of "scaling" is?

I'm actually now very curious. What is your definition or idea of how scaling Bitcoin should actually be? Because we might not have a common definition/idea, and that's where the issues start.

It's not just for BlackHatCoiner. I want to know everyone's definition/idea about scaling.

1. If it is necessary, then why it is not included in the whitepaper?
2. You won't believe how many things can be coded with public keys only. Imagine that if you have a Schnorr signature, then you can add and multiply 256-bit numbers. This is enough to implement a lot of conditions.
3. There is no need to include Script in the first version. It can be added later if needed, exactly in the same way as Taproot was added: you can spend by P2PK, or spend by P2SH, and wrap all of that in a single address type. This is how Taproot works: you never know, if there is some huge Ordinal behind some P2TR address, or if there is just a public key, and nothing else. The same could happen with P2PK back then, there were no technical difficulties in implementing that.

This is the problem. As Garlo Nicon mentioned above, "you cannot beat something with nothing". So, if you don't know, how to write some code, then ask someone, who thinks like you, to do that. Or join some existing team. Because the best thing is when you figure out, that your ideas are already implemented, because then no additional work is needed, and you can just support the right team.

Then, I have another question: why Satoshi didn't make it gradually? Why it was not "double the size of the block every halving" or any other "gradually increase the size of the block"? Today, we even have BIPs for that! If people around 2017 thought about it before implementing Segwit, then why Satoshi didn't code it in that way, and just made it constant?

How do you define "very small"? Is it millisatoshi in Lightning Network, that is never enforced on-chain? Or is it microsatoshi, nanosatoshi, or even smaller unit? Been there, done that. I had some channels with a friend, when we used CPU mining (with Merged Mining) to pay each other the smallest amount we could, proportional to the amount of satoshis in the coinbase transaction, scaled down to the minimal difficulty we produced. So yes, you can send someone a millisatoshi, or even smaller unit, as long as both clients support that feature. But of course, it doesn't change the fact that to enforce it on-chain, you need to pay quite high on-chain fee. Which is why testnet, or some separate network, fits better for such purposes, because then you can use zero satoshis to have any on-chain representation, and to actually push your millisatoshis on-chain (or wrap them into a multisig, and enforce on-chain by using a proper Script).

Also note that you don't need LN to enforce such things. The minimal fees for routing any transaction is something you can change in your node settings. You can accept free transactions into your mempool, but then be prepared to deal with spam somehow. Guess what: even today, there are still transactions flying around, with fees below one satoshi per virtual byte. They are usually used by mining pools, but you can build anything on top of that, if you have two nodes, which accepts more transactions than usual. But of course, to enforce microtransactions on-chain, you need some computing power, similar to what centralized mining pools already have. Or, if you don't want that, then you can send a lot of cheap transactions, and then batch them, and broadcast into official network. If you use a proper Script, you can do that without any trust, see 2P-ECDSA and Homomorphic Encryption for more details.

This is quite simple: Satoshi could do some hard-fork then, because the network was small enough. In fact, the current version is not fully compatible with the first version, because there were some minor changes here and there, for example some P2P messages were changed to include checksum, and the longest chain rule was changed into the heaviest chain rule in a hard-fork way.

But even if you assume that Satoshi was pro-hard-fork, then I have another question: do you think that Satoshi would do some hard-fork today, and ignore the miners? I don't think so. Even if we have Segwit and Taproot, then still, cleaning it up doesn't mean ignoring the miners, or reverting the chain. What happened, is already set in stone. So, you can change the code to disable Segwit or Taproot, but you cannot overwrite the history. But good luck creating a proposal to roll-back those soft-forks, and make those coins spendable by anyone. It will simply not happen.

Technically, you can start with P2PK, and add a Script later. There are no technical problems with that approach, and also, in this case you end up with a single address type, which is P2PK, and this could be good for privacy, because then you don't know, if something is a public key, or a Script, until it is spent. And also, in this case, users can try non-standard scripts, without risking their money, because then they can always spend by public key, if their Script will turn out to be non-standard or unspendable.

It means "if fees will not be sufficient, then we can do something else to limit it further". If you think I just made it up from the thin air, then you can go to the link, and read the whole context. Also, again, as Garlo Nicon said, "you cannot beat something with nothing", which means if you think that my interpretation is wrong, then what is yours? Because your answer "I don't know" will not push us any further.

It is "forbidden" beyond 32 MiB, because he coded it in that way. And 32 MiB takes more than two bytes, which means you need at least four bytes, to handle it correctly. But guess what: he put 32 MiB as the limit, not 4 GiB.

You cannot handle 32 MiB with three bytes. It is 0x02000000. It needs at least four bytes.

I also have another question: if you think that Satoshi didn't care about the size, then why he introduced VarInt to compress things? Why he stored difficulty by using four bytes, instead of using 32 bytes to store the target explicitly, with arbitrary precision?

I can't get into the techinical details as i'm not educated in this . But , you can understand that at that time HDD's and broadband speed were not the same as today . Also the network was at it's infancy . Things changed since then .
I'll quote satoshi :

---

"Bitcoin isn't currently practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.  The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.
Bitcoin is practical for smaller transactions than are practical with existing payment methods.  Small enough to include what you might call the top of the micropayment range.  But it doesn't claim to be practical for arbitrarily small micropayments. "

"Quote from: theymos on October 03, 2010, 08:28:39 PM
Applying this patch will make you incompatible with other Bitcoin clients.

+1 theymos.  Don't use this patch, it'll make you incompatible with the network, to your own detriment.

We can phase in a change later if we get closer to needing it."

---

And for the backwards compatibility part that most believe should not change , the moment satoshi proposed

"It can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete. "

the road for hard forks open . If satoshi was against it , he wouldn't post such a thing , but would propose something in a backwards compatible way .

See? The answer was not "just use OP_PUSHDATA4, and upload it". The answer was "fees are needed to discourage that". And even more: "if fees will not be sufficient, then we can do something else to limit it further". That's what he said, as you can see above, and click on the link to the quote to confirm it.