Do miners really think destroying Bitcoin will make them rich?

[David Rabahy]

Scaling, in general, is a complex topic.  To thoroughly examine all aspects of the scaling of Bitcoin would involve a lot of work.

Often improving/replacing an algorithm can provide much more improvement than any other activity.  I always applaud/encourage/support efforts in this direction but realize they can take substantial time/investment especially as compared to just tweaking parameters.

If instead we try holding the algorithms pretty still (for now) while adjusting resources then maybe at least some progress can be made.

In terms of transaction rate (as opposed to any other measure), surely, at first, there would be some positive scaling (linear or not) increasing the current 1MB block size a little bit but eventually (as we continue to increase the size of the block) there could be/would be negative scaling.  Is anyone thinking/saying that a small block size increase would immediately *reduce* the transaction rate?  Does anyone think/say that a gigantic enough block won't lead to negative scaling?

Dismissing a reasonable amount of block size increase because gigantic enough blocks will scale negatively is misguided.

To me it seems like a pretty obvious tactic to cap the size of individual transactions to something like 1MB while increasing the block size.  Someone wanting a bigger transaction can just launch two or more transactions to effectively get the same work done.  Question: under SegWit are transaction sizes capped?

[1714782008]

1714782008

[1714782008]

1714782008

[1714782008]

1714782008

[David Rabahy]

couldn't we just HF away from a malicious monopoly?

What's to stop them from invading the HF?

[deisik]

Scaling, in general, is a complex topic.  To thoroughly examine all aspects of the scaling of Bitcoin would involve a lot of work.

Often improving/replacing an algorithm can provide much more improvement than any other activity.  I always applaud/encourage/support efforts in this direction but realize they can take substantial time/investment especially as compared to just tweaking parameters.

If instead we try holding the algorithms pretty still (for now) while adjusting resources then maybe at least some progress can be made.

In terms of transaction rate (as opposed to any other measure), surely, at first, there would be some positive scaling (linear or not) increasing the current 1MB block size a little bit but eventually (as we continue to increase the size of the block) there could be/would be negative scaling.  Is anyone thinking/saying that a small block size increase would immediately *reduce* the transaction rate?  Does anyone think/say that a gigantic enough block won't lead to negative scaling?

Why should it reduce the transaction rate at all?

It is often said (though I'm inclined to think that this is largely an erroneous opinion) that increasing the (small) size of the block would actually lead to an increase in the number of transactions processed per unit of time. I disagree with this point but people are still claiming that increasing the block size would lead to a wider adoption and thus to more transactions made. On the other hand, I don't quite understand why there should ever be a negative scaling (whatever you might mean by that). Basically, we are increasing the upper limit of the block size, but that doesn't mean that all blocks should necessarily be of that size. They will remain as big as the number of transactions included. For example, some miners deliberately choose to ignore all transactions and thus their blocks are tiny

[jonald_fyookball]

couldn't we just HF away from a malicious monopoly?

What's to stop them from invading the HF?

dunno

[Carlton Banks]

In terms of transaction rate (as opposed to any other measure), surely, at first, there would be some positive scaling (linear or not) increasing the current 1MB block size a little bit but eventually (as we continue to increase the size of the block) there could be/would be negative scaling.  Is anyone thinking/saying that a small block size increase would immediately *reduce* the transaction rate?  Does anyone think/say that a gigantic enough block won't lead to negative scaling?

You're conflating "scaling" with "increasing resource usage"


Both improve transaction capacity. But they're not the same.

[David Rabahy]

Obviously there are two transaction rates;

1) the rate at which transactions are presented to the system by users
2) the rate at which transactions are booked into blocks.

These are related over time -- if the first rate exceeds the second for a long enough period of time then a backlog will grow; queueing theory 101.  Try driving on a highway during rush hour.

Increasing the current block size of 1MB to say 2MB would roughly allow twice as many transactions to be booked into blocks thereby increasing the second rate.  Naturally we'd have to constrain the size of individual transactions to avoid problems with them.  Miners that don't fill a block up are missing out on fees.

Negative scaling just refers to a situation where increasing a resource/parameter decreases the processing rate.  In the case of Bitcoin, there is a block size which is "too" big.  A block that is too big would lead to some processing problem, e.g. excessive page faulting, etc., and so the second rate would actually drop lower.

[deisik]

Negative scaling just refers to a situation where increasing a resource/parameter decreases the processing rate.  In the case of Bitcoin, there is a block size which is "too" big.  A block that is too big would lead to some processing problem, e.g. excessive page faulting, etc., and so the second rate would actually drop lower

I don't think this is a valid argument

As I said in my previous post, the bigger block size doesn't set a requirement that all mined blocks should necessarily be of that size exactly. Obviously, they can be of smaller sizes since you fill them with the transactions that are pending confirmation and you don't wait until there are enough new transactions in the mempool to fill up the block (or fill the block with trailing zeroes). Even today you can see blocks of around 750k in size which corresponds to the former block size limit. And if someone aims for the upper limit and includes in the block he's found more transactions than his system is able to process, then he is basically shooting himself in the foot

[Carlton Banks]

Negative scaling just refers to a situation where increasing a resource/parameter decreases the processing rate.  In the case of Bitcoin, there is a block size which is "too" big.  A block that is too big would lead to some processing problem, e.g. excessive page faulting, etc., and so the second rate would actually drop lower.

Yes, improving the ability of the Bitcoin software to verify both transactions and blocks is a major purpose for Segwit's deployment (commonly referred to as "solving quadratic sighashing")

You're now conflating "scaling" with "processing blocks". They're not the same, even superficially.


There is no relationship between blocksize and scaling except a linear relationship, they're 1:1 at any value. Hence it's meaningless to talk about "scaling the blocksize" and other such expressions.

[David Rabahy]

True enough; a gigantic block size limit does not necessarily lead to negative scaling but it does make it possible.  If the block size limit is constrained to something reasonable then we can safely avoid negative scaling at the risk of building a backlog.

[Carlton Banks]

Blocksize changes are nothing to do with scaling, David

I don't know how I can make that any clearer

[David Rabahy]

Improving the algorithm is often/always? the better way to go but while we're waiting it is not unreasonable to tweak parameters.

[David Rabahy]

Blocksize changes are nothing to do with scaling, David

I don't know how I can make that any clearer

Seriously? Clearly we have a difference in definitions.  I am not talking about taking the scales off of a fish here.  I'm talking about the term scaling where we are talking about the processing rate changing.  An increase in the processing rate is positive scaling.  A decrease in the processing rate is negative scaling.  Scaling can be linear or non-linear.  Linear scaling simply means that we get a 1:1 change in the processing rate as we vary some parameter.  How are you using the term scaling?

Today we are pumping somewhere between 2-7 transactions per second through into blocks on average.  Anything that changes that rate ability is a scaling factor.  If the block size limit were increased from 1MB to 2MB then we would see roughly twice that number flowing through.  That's pretty much scaling in my book.  Even if it were sub-linear so that we got only 3-8 transactions per second through on average, that's still scaling up.  Yes, it would grow the size of the block chain faster but something has to give until a superior algorithm is deployed.

Block size limit changes have way more than nothing to do with scaling the transaction rate through.  If it has nothing to do with it then decreasing the limit wouldn't hurt, right?

[Carlton Banks]

Blocksize changes are nothing to do with scaling, David

I don't know how I can make that any clearer

Seriously? Clearly we have a difference in definitions.  I am not talking about taking the scales off of a fish here.  I'm talking about the term scaling where we are talking about the processing rate changing.  An increase in the processing rate is positive scaling.  A decrease in the processing rate is negative scaling.  Scaling can be linear or non-linear.  Linear scaling simply means that we get a 1:1 change in the processing rate as we vary some parameter.  How are you using the term scaling?

Explain how changing the relationship between transaction rate and blocksize from 1:1, to 1:1 changes the scale.

[David Rabahy]

It changes the rate of processing.

[David Rabahy]

What is the term you prefer to use for changing the rate of processing?

[David Rabahy]

This is way off point but just to pick nits; Since there is only one fixed size block header then the ratio of transactions to block size does scale even in your definition although granted it is a tiny amount and not worthy of this mighty discussion.

I think we misunderstand each other because we are using a different definitions of scaling.

Recognizing this will help future discussions.

[Victorycoin]

The miners are threatening these things, not doing them. Let's just see where their big-talk leads, besides, we already have effective ways to defend against these attacks anyway.

Evidently they only stopped short of carrying out their nefarious intentions, because the exchanges were able to put up a fight and made it quite clear that the world can always do without a best man! In the absence of that check, those miners were far gone on punching a hole on Bitcoin. Centralization of miners is a misnomer for Bitcoin, whose major selling point, is its decentralized nature.

[Carlton Banks]

In the absence of that check, those miners were far gone on punching a hole on Bitcoin. Centralization of miners is a misnomer for Bitcoin, whose major selling point, is its decentralized nature.

Agreed.

I think the PoW change is still important, because of the situation with the current ASIC miners. If they can behave so recklessly once, I have little confidence that they will not do so again.

I feel for the small miners in a way, but not that much. They're the ones actually subjugated by firms like Bitmain, as the highly gouged prices they pay to people like Bitmain (surely it's only Bitmain and Canaan still selling to allcomers these days) are what funded the oligopoly to begin with.

If the miners thought more carefully, they'd see that CPU mining would put the ability to compete against the Bitmain mentality back on the table. And PoW changes really should not be attempted in an emergency, it would be highly disruptive and cause a great deal of uncertainty (not to mention the knock-on consequences of all that).


I propose that an orderly, staged PoW change, implemented 5% gradations via a series of soft forks, would do alot to secure Bitcoin's future. It's not my actual proposal, but one that is being discussed in this thread: https://bitcointalk.org/index.php?topic=1833391.0

Not only would we decentralise mining from it's current cartel state, we could attract more users keen to compete in a fairer mining market. I see no downsides, executed diligently.

[Pattberry]

It is accurate to call what the miners do is to destroy the bitcoin. They are too greedy, so they come up with the idea of BU, because of that greed they are making the bitcoin die off. At present, the value of bitcoin is severely depreciated. While alt coins are growing and going up to an incredible level, most altcoins go up, but the bitcoin goes against it, it is dying, and the killer Dead bitcoin is the main miners. They are bad guys who just satisfy their greed and do not think about anyone.

It is true that BU will give more power to the miners but i am not certain that they want to destroy bitcoin,they just want more control over the entire process ,who would not like to like their fingers when they put their hands in honey pot,all the major miners has invested a huge amount of money and they want to have a sustainable profit on par with their investment and may be so is the reason they are siding with them.

[andyatcrux]

"Miners are semi-trusted & serve at will of users. Users have full rights of self-defense when preponderance of miners behaving insecurely."  - Nick Szabo

(a few hours ago)