[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-ml
Subject:    [Bitcoin-ml] Is there a need to preempt scaling issues with Bitcoin Cash/BCC now?
From:       will.madden () gmail ! com (Will M)
Date:       2017-11-13 17:50:55
Message-ID: 99e61725-5459-4078-ad4d-ddc28cbbb4a3 () Spark
[Download RAW message or body]

I understand EC pretty well, block acceptance depth, etc.

I think we should assume worst case, that most users and miners do not proactively \
?set? a limit for EC that is different than the default, and that this could become a \
way to control scaling, by refusing to change the default that ships with one or \
multiple implementations of BCC.

If we can set the default limit that ships with all clients to something that \
increases at a predetermined rate, this will prevent future blockades to scaling.

We shouldn?t hand wave this away as a non-issue. There is a very real, longer term \
risk that this will become ?contentious? when BCC becomes the dominant \
cryptocurrency.

On Nov 13, 2017, 10:48 AM -0700, Tom Harding via bitcoin-ml <bitcoin-ml at \
lists.linuxfoundation.org>, wrote:
> Hi Will, this is the situation as far as I know.
> BU relies on emergent consensus (EC). Miners and nodes signal their preferences and \
> enforce them through local rules. ABC has a static 8MB limit. There is a set of \
> open tasks to implement emergent consensus (EC). XT has an 8MB limit and implements \
> BIP100, a deterministic algorithm based on miner signals in the chain. \
> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki 
> To answer your questions directly,
> ? 1. Yes, you could do it. The result depends on network acceptance of your rules.
> ? 2. I wouldn't worry about implementation-specific limits like the 32MB message \
> size (except maybe as they affect any future deliberation of consensus changes). 
> 
> On 11/13/2017 7:03 AM, Will M via bitcoin-ml wrote:
> > BCC is taking off faster than most anticipated. That makes me concerned about any \
> > ?magic numbers? (even defaults) that could be leveraged to stop BCC from scaling \
> > on chain. 
> > Some concerns/questions:
> > 
> > 1. Could I sponsor a BCC dev. team, get lots of users, and then one day refuse to \
> > increase the default 8MB limit that ships with my client? Adjustable or \
> > otherwise, wouldn?t this have the same result as the 1MB limit does with bitcoin \
> > legacy today? 2. Is the 32MB message size limit still lurking out there in BCC, \
> > and could this become another blockade to scaling later on? 
> > How difficult would it be to increase the default limit settings that ship with \
> > the software at predetermined block heights now... just like BIP101/XT used to do \
> > with max_block_size? 
> > I would feel a lot better if the default limits on scaling increased ~40% per \
> > annum, conservatively under long term efficiency increases we?ve seen in \
> > broadband, storage, and processing. 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171113/79d4b085/attachment.html>



[prev in list] [next in list] [prev in thread] [next in thread]