Topic: Do miners really think destroying Bitcoin will make them rich? - page 6. (Read 7491 times)

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://bitcointalksearch.org/topic/ann-bitcoin-pow-upgrade-initiative-1833391

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.

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.

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.

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

It changes the rate of processing.

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

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?

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

Blocksize changes are nothing to do with scaling, David

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

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.

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.

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

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.

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


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

dunno

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

What's to stop them from invading the HF?

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?

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

Maybe even this guy couldn't have predicted the 51% attack would include such an elaborate social engineering component too.

The People's Republic of China are so desperate to protect their turf, they're willing to employ some seriously complex plausible deniability, not to mention an army of English speaking trolls. Anyone would think that the PRC aren't working alone here.... but that would be craaaazzzzzzzy talk, right? Surely the Chinese, American and/or the European establishment wouldn't be working together to kill Bitcoin, right? Right?