Author

Topic: Prematurely changing the 1MB transaction supply is a great idea ... (Read 1942 times)

legendary
Activity: 1204
Merit: 1028

Any time the debate doesn't seem to be going their way, the anti-forkers either close the thread (see "fork off"), or try to divert attention away with a new one that only has their side of the argument in focus and uses biased language like "prematurely". 

The thing they seem to keep forgetting is that no one is forcing them to have a 20MB limit.  They're more than welcome to keep the old 1MB limit.  That's the best part about a fork.  You get to choose. 

So please, anti-fork crowd, if you're reading this, stay on your old, limited chain.  We're going to leave you behind.  Bye!


Such big talk; so little action.

Have fun with RogerCoin.  Enjoy its propensity to self-destruct spontaneously and frequently.





After analyzing the situation, im convinced that everyone on /r/btc is either on a Roger Ver payday or on some sort of hallucinogen. Roger Ver hasn't delivered a sound argument since I have memory.

I was once a big blocker and rectified my position because I didn't understood the finer details and game theory involved within something that initially is as simple as changing a value.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.

Any time the debate doesn't seem to be going their way, the anti-forkers either close the thread (see "fork off"), or try to divert attention away with a new one that only has their side of the argument in focus and uses biased language like "prematurely". 

The thing they seem to keep forgetting is that no one is forcing them to have a 20MB limit.  They're more than welcome to keep the old 1MB limit.  That's the best part about a fork.  You get to choose. 

So please, anti-fork crowd, if you're reading this, stay on your old, limited chain.  We're going to leave you behind.  Bye!


Such big talk; so little action.

Have fun with RogerCoin.  Enjoy its propensity to self-destruct spontaneously and frequently.



legendary
Activity: 1106
Merit: 1026
Why not for the sake of caution start with a conservative number like 2, ...?

I really haven't made up my opinion on the whole topic, but one thing keeps repeating in my mind.. During the last great rise at the end of 2013, the soft block size limit of 250 kB/block of the Core default value was hit, which a majority of pools where using, with Eligius as one of the few exceptions, pushing blocks with 700+ kKB/block, if I recall correctly. This chart illustrates well where I'm getting:



What makes me wonder: the average block size increased significantly since then, but consider another, maybe even more explosive, adoption movement of 5-30x, triggered by some black swan event. What would happen?

I think there is much value of having this discussion, and seemingly crazy proposals, better much sooner than later, to be prepared for that moment.
full member
Activity: 209
Merit: 100
Over the long term we do need higher transaction fees in order to allow for total block rewards (including block subsidies) to remain consistent in terms of bitcoin to remain the same, or even decrease slightly. This ultimately means that the average block size when compared to the max block size needs to increase.

The 1MB limit is obviously too small over the long term, although it can potentially work over shorter periods of time until adoption actually increases. I would say that when we do increase the max block size, it would be best to increase it somewhat lower then 20x then what it is now
legendary
Activity: 1652
Merit: 1016
If we end up leaving the decision too late and the transactions start stacking up with no sign of the stack reducing, we will be in a crisis.
In a crisis situation, panic decisions could made which may not be the best solution.
I think we should take our time, and plan according whilst we are not in a crisis. In other words, now.
legendary
Activity: 1904
Merit: 1007
But what if they were?  Nobody knows, so we should gather enough data to make informed predictions and preparations.

Right now, there are so few full 1MB blocks that we have no idea how the system would react, especially to much larger ones.

Since you refuse to answer on the other topic I will ask here:

How long do we gather and analyze data after we get full 1MB blocks? 1 week? 1 month? 1 year? 5 years? How do we decide that we had enough data to analyze the issue?
newbie
Activity: 50
Merit: 0
Why do people think that because max block size 20Mb = ALL blocks will be 20Mb?


can someone please explain this?

Because some people are idiots or have their own agenda. It's that easy.

Nobody has said "ALL blocks will be 20Mb."

But what if they were?  Nobody knows, so we should gather enough data to make informed predictions and preparations.

Right now, there are so few full 1MB blocks that we have no idea how the system would react, especially to much larger ones.
[/quote]

If most 1MB blocks aren't full, to even act like all or most 20MB blocks would be full just shows how full of shit you are(or could be, I'm not calling you full of shit, don't take offense please). If most 1MB blocks aren't full, why not go to 10MB first? There is logic in code, so someone who knows bit about bitcoins code and the new 20MB code CAN predict how the fork to 20MB will react.

This isn't religion. This is very simply pretty predictable stuff.
hero member
Activity: 493
Merit: 500
Why do people think that because max block size 20Mb = ALL blocks will be 20Mb?
can someone please explain this?

They can't support their position through rational argument, and so resort to manufactured issues.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
Why do people think that because max block size 20Mb = ALL blocks will be 20Mb?


can someone please explain this?

Because some people are idiots or have their own agenda. It's that easy.

Nobody has said "ALL blocks will be 20Mb."

But what if they were?  Nobody knows, so we should gather enough data to make informed predictions and preparations.

Right now, there are so few full 1MB blocks that we have no idea how the system would react, especially to much larger ones.
legendary
Activity: 1904
Merit: 1007
...

Why do you revive this useless thread where nobody bothered to reply to you instead of discussing the issues on the 2 thread that are more active than this thread?

This is the reason why I call you a retard clown. You haven't bothered to answer to my questions that I have addressed to you here: https://bitcointalksearch.org/topic/m.10400874 but you revive this useless thread to try to impose your points. GOOD WORK! You brought A LOT of value to the subject!

Why do people think that because max block size 20Mb = ALL blocks will be 20Mb?


can someone please explain this?

Because some people are idiots or have their own agenda. It's that easy.
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
So, we are making new threads now, instead of posting replies in an already existing thread?

Any time the debate doesn't seem to be going their way, the anti-forkers either close the thread (see "fork off"), or try to divert attention away with a new one that only has their side of the argument in focus and uses biased language like "prematurely".  

The thing they seem to keep forgetting is that no one is forcing them to have a 20MB limit.  They're more than welcome to keep the old 1MB limit.  That's the best part about a fork.  You get to choose.  So please, anti-fork crowd, if you're reading this, stay on your old, limited chain.  We're going to leave you behind.  Bye!
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
Why do people think that because max block size 20Mb = ALL blocks will be 20Mb?


can someone please explain this?

Nobody has said "ALL blocks will be 20Mb."

But what if they were?  Nobody knows, but we should gather enough data to make informed predictions and preparations.

Right now, there are so few full 1MB blocks that we have no idea how the system would react, especially to much larger ones.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
"Prematurely" upgrading the limit doesn't do anything because the LIMIT doesn't affect the actual SIZE.

The limit is 1mb now, how many blocks ARE actually 1mb?

Upgrading the limit will prepare us for the future, but it will not hurt. It's stupid to wait to the last moment.

The low number of full blocks at present is exactly why the 20MB fork is premature.

It's stupid to rush things before having a chance to see how the system responds to full blocks.  Better to stress-test this experiment sooner than later.  If Bitcoin is a great success we may revisit full blocks in the future, but with less time and more pressure to prepare and react.

We can't prepare for the future without knowing the limits of the network, including the effects of semi-regular or even sustained full blocks.  We need to discover what/why/how parts start to degrade and/or break given heavy transaction load.

If you think 1MB samples would be of limited value, I might support experimenting with full blocks under a 5MB cap instead (provided the next block size fork is the final one).
hero member
Activity: 1328
Merit: 563
MintDice.com | TG: t.me/MintDice
Why do people think that because max block size 20Mb = ALL blocks will be 20Mb?


can someone please explain this?

for me i just didn't know until i asked. but im also not everyone.
hero member
Activity: 714
Merit: 500
So, we are making new threads now, instead of posting replies in an already existing thread?

The hard fork is coming. Deal with it. Outside of this forum, nobody cares. I haven't heard from any developer(you know, the people, who are actually doing something for Bitcoin and don't just spend their days on the forums complaining, that nobody makes thinks as they like them to be), who is against the fork.
sr. member
Activity: 434
Merit: 250
Why do people think that because max block size 20Mb = ALL blocks will be 20Mb?


can someone please explain this?
legendary
Activity: 1106
Merit: 1005
"Prematurely" upgrading the limit doesn't do anything because the LIMIT doesn't affect the actual SIZE.

That's like saying: "I'm not going to buy that sound system because the maximum volume is so high it would make me deaf if I turned it on"

Or: "I'm not going to buy that Ferrari, because the top speed of 350 km/h could get me killed"

You see? Just because a Ferrari CAN drive 350 km/h doesn't mean it HAS TO.

Just because the block size CAN be 20 mob doesn't mean it WILL.

The limit is 1mb now, how many blocks ARE actually 1mb?

Upgrading the limit will prepare us for the future, but it will not hurt. It's stupid to wait to the last moment.
legendary
Activity: 2674
Merit: 3000
Terminated.
We don't have to necessarily instantly jump to 20 MB, but the longer we wait the worse this mess will get.

How do you feel about my counterplan and proposed compromise?

First, we must wait and see how the infrastructure and ecosystem react/adapt to scarcity.   Without this crucial empirical data, we cannot make informed future decisions about ideal block sizing.  We cannot risk a civil war between BTC1 and BTC2 camps by forcing the issue prematurely (but if I were actually anti-BTC and pro-alt, I'd relish such a Great Schism).

Second, we must use the results of the experiment with 1MB scarcity to decide on a preliminary blocksize increase, to somewhere between 2MB and 10MB.

20MB blocks can then be considered, if and only if the community, pruning/compression mechanisms, and TOR/DSL are ready to support them.

As a compromise, I'll support an increase to 2MB ASAP, on the condition that we then maintain that limit until facts about market reaction to block real estate scarcity are ascertained.
Compromise? Gavin and the team don't have to compromise.
This is a ridiculous counter-plan if there is no way of raising the limit via a soft fork.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
The market has priced in the 1MB limit; the infrastructure and ecosystem are native to it.  It's part of the social contract.

Why 20MB, and why so soon?  Why not for the sake of caution start with a conservative number like 2, 5, or even 10?  

Or better yet, wait and see how the market reacts to the resource becoming scarce.  This is an unprecedented experiment, after all.  And we need data on which to make good future decisions.

God forbid the substitution effect help diversify the crypto market beyond being 85% centralized in BTC!

I support davout, Cypherdoc, and MP's 'digital gold' paradigm.  Bitcoin for the rich, Litecoin for the poor, Monero for the rest!

Bitcoin is the gold standard of crypto and its real estate must be priced accordingly.  It is the ultimate guardian of wealth preservation from force, not a penny for buying candy.

Any transaction less than 1 BTC is either spam or economic noise better conducted via an altcoin.  Crypto is the new money; Bitcoin is the new gold.

A Bitcoin transaction is much more like ride in a $5 million Lamborghini than a .1 cent screw.

Absent mini-blockchain adaptation or other means of pruning, is Gavin's Bloatcoin really what we need right now, as the already large full node footprint continues to hinder mass adaption?

Increasing maximum transactions is as much a form of dilution as changing the 21e6 coin figure to 42e7 would be.  

Cheapen the payment system and you axiomatically take the store of wealth with it.  Because intrinsic value.

The price of BTC has been falling for many months; we don't need controversial 20MB or Blockstream(tm) forks at this point.

I'll support a 20MB block fork in the future, if

-we wait to see how the market/infrastructure/ecosystem react/adapt to scarcity in (1MB) blocks
-then raise the limit to 2, 5, or 10 if widespead support exists
-then run out of room at 2/5/10 and widespead support exists for another increase
-and implement pruning
-and ensure TOR users are not cut off

In any case, we need a majority, not just a consensus, to approve and implement such hard forks.
Jump to: