Topic: [PATCH] increase block size limit - page 3. (Read 89869 times)

They aren't ridiculous or indecipherable at all. In fact they are a very polite way of mocking many of the clueless opinions from non-technical folks.

I am so sick of reading MarkM's ridiculous stream-of-conciousness uncypherable posts.  Thank goodness there is an ignore button to the left. 

Okay how about making max block size a configuration file / commandline variable?

From then on, no hard fork of the code would be required to change it, only, potentially, a hard fork of the blockchain?

Shops can have signs on their doors warning customers about the actual setting that shop uses for max block size, and customers can choose higher size supporting shops if they feel confident risking their money in blockchain branches they think might end up with less hashing power behind them than forks adopting a more traditional / more conservative limit?

Customers would maybe prefer merchants whose limit is set so high only a few miners world wide can handle it thus that have lower hash power, plus their coins will still be safe back on the original size branch because no higher size block can ever move any original sized block chain's coins anywhere at all.

Merchants wanting to actually be able to receive real original coins on the real original chain will set their clients to not approve blocks larger than those of the original chain, the chain which established the damn things have any value at all in the first place.

Maybe we should make two forks right away, a double sized block and a half sized blocks chain, and see which chain's coins best retain or gain value?

The config file setting method of setting the max will at least get rid of all the "we have to fork the code" excuses / arguments, reducing it to each node's choice what value to put in its config file. Thus putting the power with the nodes, not with the developers. (Which might be a really really really crappy idea. "Eat shit! Half a million houseflies can't be wrong!")

-MarkM-

Blaming S.DICE is useless. That service alone currently pays more fees to the network than all other Bitcoin usage combined. As S.DICE grows, it will pay more and more fees. More with each and every new user. That is how it's supposed to be of course. The problem here is nothing else than a setting that is slowly but surely becoming a problem for overall Bitcoin usage.

If services such as S.DICE become even more commonplace, obviously we can't just raise the blocksize on their account alone. We can let the fees rise a bit and control it that way. This problem is not about S.DICE though, it's about overall Bitcoin adoption. Without S.DICE it would just take a bit longer, that however would change nothing.

Dust is by definition a transaction output (bitcoin) so small that it is economically worthless, and will probably sit around unspent.

The fee paid is irrelevant.

Satoshi Dice is currently paying 0.001 BTC in fees per transaction which translates into 0.03 USD per transaction. I would not call this "dust spam". What we have here is exponential growth pushing against a hard limit. This is a prescription for disaster. Arguing whether the disaster happens in four months or sixteen months is beside the point.

Here soon blockchain.info is going to roll soo fast you can not even see the transactions.

Exactly. We're not having these discussions too early at all, on the contrary. We will probably need 1 year of lead time for such a massive change, and indeed it is possible that we will be pushing the limit within 1 year. So this is no joke.

Isn't a huge huge amount of the increase in transactions so far attributed to what seems to be basically an app designed expressly for the purpose of artifically/frivolously spamming the blockchain with frivolous/trivial, even "dust spam", transactions?

If so it seems more to show desperation on the part of some bigger bigger bigger agenda than any real need. Especially the dust, that is pretty much an attack really, even if intended to highlight a problem existing with tiny value transactions so it can maybe be addressed.

-MarkM-

There are many theories of this. One of them is can Bitcoin continue to function without centralized control? By leaving us he in effect left Bitcoin leaderless and that is by design. This block size issue is likely to be the perfect test since the community has no choice but to implement a hard fork. If Bitcoin survives this it will come out way stronger, there is however also a significant chance that block size issue will turn Bitcoin into a failed experiment.  By the way I would not consider your post off topic at all.  

off-topic and I am sorry but I could not help myself. Why did satoshi ever stop posting visiting us?

http://blockchain.info/charts/n-transactions With a 10x increase in the number of transactions over the last year it is reasonable to say that we can reach the 1MB limit in well under a year. The point is that in order to roll out a hard fork one has to delay its implementation way into the future in order to avoid chaos in the network. It we reach the limit before anything is done it will be way too late and a massive loss in confidence will result.

Hmm Satoshi wrote that over two years ago and we still aren't actually close to needing it yet.

Still I guess it mostly depends on how many more years it is going to be before someone actually goes out there and signs up Walmart or President's Choice or A&P (are they still around?) or Sainsbury's or something and actually shows us a little of this vast flood of users they keep yelling is going to descend upon us any moment now.

So far it seems possible the volume of ranting about vast numbers of users coming at us is actually inversely proportional to the number of users the ranter actually has signed up lined up ready to bring aboard.

-MarkM-

It is time to revive this old thread since this should serve as a wakeup call to the Bitcoin community.

My question is this: What will happen first?
1) Bitcoin transaction volume increases by a factor of 4
2) Current Bitcoin clients become obsolete.

Only recently I learned about this block size limit.

I understand not putting any limit might allow flooding. On the other hand, the smaller your block, the faster it will propagate to network (I suppose.. or is there "I've got a block!" sort of message sent before the entire content of the block?), so miners do have an interest on not producing large blocks.

I'm very uncomfortable with this block size limit rule. This is a "protocol-rule" (not a "client-rule"), what makes it almost impossible to change once you have enough different softwares running the protocol. Take SMTP as an example... it's unchangeable.

I think we should schedule a large increase in the block size limit right now while the protocol rules are easier to change. Maybe even schedule an infinite series of increases, as we can't really predict how many transactions there will be 50 years from now.

Honestly, I'd like to get rid of such rule. I find it dangerous. But I can't think of an easy way to stop flooding without it, though.

I agree, especially since generators are both the source of blocks and "votes" in the network.  Since a block restriction would allow generators to charge higher transaction fees, they might "vote" against an increase in the max size in the future.

It seems unlikely to be a real problem though.

If we upgrade now, we don't have to convince as much people later if the bitcoin economy continues to grow.

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.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

You just described a whole-network upgrade.  I'd call that an incompatible change

The effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins:  convince the vast majority to upgrade.

No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.