BIP100

[Hector Chu]

Since a majority of hash power is now signalling for BIP100, are there
contingencies to switch to it if Jeff brings out a patch?

What are the thoughts in general on this list about BIP100? Is it
better than BIP101?

[Hector Chu]

One more: would it be possible to implement both bips simultaneously?
Let the hash rate decide which one to trigger.

[gilles cadignan]

ahahaha les clauses du contrats de balotelli :

 Règle n°1 : interdiction de fumer.
 Règle n°2 : interdiction de boire trop d’alcool.
 Règle n°3 : interdiction d’aller en discothèque ou de fréquenter d’autres lieux nocturnes.
 Règle n°4 : interdiction de parler mal du Milan AC sur les réseaux sociaux.
 Règle n°5 : interdiction de porter une crête et de la teinter en rouge, en jaune ou en orange.
 Règle n°6 : interdiction d’arriver en retard aux entraînements.
 Règle n°7 : interdiction de s’habiller de manière incompatible avec le style du Milan AC.
 Règle n°8 : interdiction de prendre des positions ou de faire des déclarations qui pourraient nuire à l’image du Milan AC.
 Règle n°9 : interdiction de prendre des initiatives sans s’être mis d’accord auparavant avec le club.
 Règle n°10 : interdiction de ne pas se soumettre au régime alimentaire établi par le staff médical du club.

--
You received this message because you are subscribed to the Google Groups "bitcoin-xt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoin-xt+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gilles cadignan]

oops sorry for that, wrong thread

[Mike Hearn]

Hi Hector,

BIP 100 isn't currently implemented. I guess we'd put together some more concrete thoughts if and when it is coded up.

My initial thoughts are that I prefer BIP 101 because:

• The BIP 100 voting mechanism doesn't seem fully thought out. A majority of miners can always win any vote because they can just orphan blocks that contain votes for something they don't like. So the more complex approach doesn't seem really robust.
  
  
• But that'd require special code. If most miners just adopt the defaults, then it's possible for a minority of hash power to drag the block size down to nearly nothing. 
  
  It's quite common for miners to just accept whatever the defaults are, regardless of whether they make sense. That's why we still see 750kb blocks sometimes when the network is actually backlogged (XT fixes this).
  
  I think the reason is that miners, not unreasonable, assume the Bitcoin Core developers are selecting default behaviour in sensible ways. Alas it's not the case anymore, because they feel choosing opinionated defaults is "centralising". This is why the XT manifesto specifically states we will pick defaults as we think best.
  
  The BIP100 default is 1 megabyte. Thus by default miners would be voting for no change. However what we need is change!
  
  
• It gives miners additional power to modify the system for no obviously good reason beyond "some miners are saying they'd like more power". Miners are not the only stakeholders. Users, merchants, exchanges, etc matter too - if not more!
  
  The upper limit is meant to be a kind of DoS limit, to stop troll miners generating giant mega-blocks. It's not meant to be a stick that miners can use to beat important but voteless economic players.
  
  
• There's a risk that someone comes up with a business plan like this:   we will build a giant ASIC farm in the middle of a desert at the end of a piece of string and tin can (i.e. no bandwidth). This will be super cheap because of abundant land/solar/wind/whatever and the lack of bandwidth won't matter because we can just drag down the block size limit to ensure tiny blocks.
  
  This would of course hurt the entire ecosystem for their own short term benefit, but BIP 100 would let them do that with just a small amount of the overall hash power.
  
  Miners have just one job: order transactions by time. They shouldn't be doing anything else, and arguably, people already freak out about the concentration of power in the hands of big mining pools. BIP 100 would make this issue worse.
  

So these are my initial thoughts.

[Hector Chu]

Hi Mike,

Thanks for responding and writing this up. I agree with the arguments
that miner voting is an extra complication that is unwanted.

I guess things will remain as they are until the Scaling Bitcoin
conference next month (right in the midst of the flooding attacks
hah). Without representation of XT at the event, it seems ever more
likely that BIP100 will eventually need to be reckoned with.

[Mike Hearn]

Gavin is planning on going to the first workshop.

[Ryan Butler]

Mike, are you not attending?  If not, why not?  Is there too much animosity built up that you feel it would be counterproductive for you to be there?

[Paul Goldstein]

What are the thoughts in general on this list about BIP100? Is it
better than BIP101?

Doesn't BIP 100 open up the possibility of growing the blocksize a lot faster than BIP101? 

With BIP 100 you can go from 1MB to 32MB in about 12 months after the first increase to 2mb (2, wait 3 months, 4, wait 3 months, 8, wait 3 months 16, wait 3 months 32), right?. That's assuming the mining community aggressively voted that way. And maybe that is what they have in mind.

Also it makes everything a lot less predictable in the long term. In 1 year from now where will we be with BIP 100? Anywhere from 1mb to 32mb.

[Mike Hearn]

Mike, are you not attending?  If not, why not?  Is there too much animosity built up that you feel it would be counterproductive for you to be there?

Reasons are:

1. I'm already travelling to three difference conferences in the next 5 weeks and attending a fourth panel via Skype. I have neither the time nor energy to add another.
   
   
2. This workshop was arranged very recently and Montreal is a long way to go from Europe. So my travel plans were already made by then.
   
   
3. Gavin is going anyway and I trust him to say the same things I'd say.
   
   
4. The workshop website explicitly states there will be no debate, no decisions made and no discussion of governance. Debate leading to decisions about governance are exactly what is needed to resolve the current deadlock, so I am a little skeptical that these workshops will achieve much.
   
   
5. Whilst I'm sure some talks will be interesting and I'll probably watch a live stream or read the slides, we already know a lot about scaling Bitcoin. There seems to be an implicit assumption that we don't know what happens if we go beyond 1mb, to the extent that we need unspecified amounts of new research. In fact it's been tested, simulated and thought about quite a lot over the past years.

[Thomas Zander]

On Thursday 27. August 2015 19.27.10 Paul Goldstein wrote:
> > What are the thoughts in general on this list about BIP100? Is it
> > better than BIP101?
>
> Doesn't BIP 100 open up the possibility of growing the blocksize a lot
> faster than BIP101?

Its not the ending max blocksize that is the main difference, it is the moving
of power.
Give more power to the miners and be certain that the miners will centralize
more in order to tap that power.

So in the end BIP100 will be a very strong incentive to centralize more.

--
Thomas Zander

[Simon Bitcartel]

On Friday, August 28, 2015 at 7:17:14 AM UTC-7, zander wrote:

Its not the ending max blocksize that is the main difference, it is the moving  
of power.
Give more power to the miners and be certain that the miners will centralize
more in order to tap that power.

So in the end BIP100 will be a very strong incentive to centralize more.

Agreed.  BIP100 will give miners the power to increase or decrease the block size every three months, much like how central banks can fiddle with the interest rate every quarter.

Also, it doesn't seem to make sense for BIP100 to give miners the ability to decrease the block size limit, unless the intention is to give miners even more influence over transaction fees.

In the real world, if demand for a commodity or service falls, pipelines get turned off, optical fiber goes dark, cargo ships are mothballed... because there are real maintenance costs in carrying excess capacity.

However with Bitcoin, if transaction demand falls, miners can simply mine smaller blocks.  Given there is no penalty in producing blocks smaller than the block size limit, why allow miners to decrease the limit?