Post
Topic
Board Bitcoin Discussion
Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud)
by
Carlton Banks
on 20/09/2015, 18:17:50 UTC
Oxymorons to avoid:

  • "Bitcoin is great because it's decentralised, but only the core devs can be trusted to write code"
  • "Bitcoin is great because it's open source, but releasing a client to propose a fork means you're a dictator"
  • "Bitcoin is great because it's permissionless, but you can't use it to buy a cup of coffee"
  • "Bitcoin is great because only the economic majority can decide the rules of the network, but only when I personally agree with them, otherwise I'll dismiss it as an altcoin like a petulant child"

XT was rejected. Get over it, we'll be scaling up without BIP101 or XT. Go away.

There's nothing to "get over".  The points I've outlined above apply in all instances.  They aren't specific to XT.  Stop trying to portray every single comment on the forum as "XT vs Core" and making out like anyone who thinks we need a larger blocksize is some sort of XT fanatic who wants 800GB blocks tomorrow.  We're not all extremists.  Calm the shit down already.

Nonsense. The points above are themselves intended as a sleight against those that defended the present Core devs and their direction (and indecision), and in a addition you're using exactly the same strategy that:

a) You're accusing me of
b) That every single BIP101 shill (there must be dozens now) has employed since the start of this garbage

Exaggerating or caracicaturing the position of those who defended Core wildly. No one has been arguing for points 1, 2, or 3, and so none of them apply. Point 4 never happened; it's a fantasy.

In reality, the economic majority, as well as as every other part of the ecosystem apart from a handful of corporate funded bitcoin businesses, rejected your fantasy version of the "economic majority can decide the rules of the network" (because they were the actual economic majority) that "dismiss it as an altcoin like a petulant child". That's the extremity. That's the same BS distortion that actual unlimited blocksize fanatics have been exhibiting.


My preference is leaning more towards a dynamic limit:

Anyway, since some are determined to deflect away from technical proposals and throw silly memes around, we'll drag the topic back to one of merit.

The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain.  Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often, if needed.  One possible route is to take the best elements of BIP100 and BIP106.  BIP100 only considers what benefits the miners and not the users.  BIP106 only considers what benefits the users and not the miners.  So neither is particularly balanced on its own.  If we can find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes, then we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.

Code:
Miners vote by encoding ‘BV’+BlockSizeRequestValue into coinbase scriptSig to:
    raise blocksize limit by 12.5%,
    lower blocksize limit by 12.5%,
    or remain at current blocksize limit.  

This vote, however, only counts for half of the total vote and the other half is determined by algorithm based on network traffic:

If more than 50% of block's size, found in the first 1008 of the last difficulty period, is more than 90% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize +12.5%

Else if more than 90% of block's size, found in the first 1008 of the last difficulty period, is less than 50% MaxBlockSize
    Network votes for MaxBlockSize = MaxBlockSize -12.5%

Else
    Network votes for keeping the same MaxBlockSize

The 12.5% part is open to negotiation, some think 10% is more reasonable (i.e. BIP105).  If every 1008 blocks is too fast, we could (for example) increase that to 2016 blocks, approximately every two weeks.  Tweaks are inevitable, but I feel it's something that could work if it's not too complex to code.

Is that not reasonable?

No time to read it now, but yeah, welcome to 1 month ago with your "My preference is leaning more towards a dynamic limit"  Roll Eyes

As for BIP101, I honestly don't think it was the catastrophic, apocalyptic doomsday scenario you portray it to be.  

Again (actual real life head shake), who's the extremist?

Never said it, or anything like it. Total exaggeration of my actual position.