Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

[David Thomson <david@artlery.com>]

[-- Attachment #1: Type: text/plain, Size: 4684 bytes --]

Gavin,

I saw this in your blog post:

"Miners producing up-version blocks is a coordination mechanism. Other coordination mechanisms are possible– there could be a centrally determined “flag day” or “flag block” when everybody (or almost everybody) agrees that a change will happen."

Can you describe this a bit more? How would either a "flag day" or "flag block" work as an alternative and why did you decide against them?

More thoughts and questions inline, thanks!

On Feb 6, 2016, at 12:45 PM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

>> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam@cypherspace.org> wrote:
>> 
>> It would probably be a good idea to have a security considerations
>> section
> 
> Containing what?  I'm not aware of any security considerations that are any different from any other consensus rules change.

Can you explain and justify why that is the case? It would be nice to see that rationale laid out more fully as to why it's no different.

> 
> (I can write a blog post summarizing our slack discussion of SPV security immediately after the first greater-than-1mb-block if you like).

I'm not familiar with the context of your slack discussion, but why would you wait to summarize that only after the first-greater-than-1mb-block?

> 
>  
>> , also, is there a list of which exchange, library, wallet,
>> pool, stats server, hardware etc you have tested this change against?
> 
> That testing is happening by the exchange, library, wallet, etc providers themselves. There is a list on the Classic home page:
> 
> https://bitcoinclassic.com/

Is there a way to provide more transparency and visibility into that process and level of readiness? Is there an expectation of certain levels of readiness here before certain other things happen? I was thinking it would be really useful to have a visual timeline of events associated with all of this. Maybe you could add that to one of your web pages?

>  
>> 
>> Do you have a rollback plan in the event the hard-fork triggers via
>> false voting as seemed to be prevalent during XT?  (Or rollback just
>> as contingency if something unforseen goes wrong).
> 
> The only voting in this BIP is done by the miners, and that cannot be faked.
> 
> Are you talking about people spinning up pseudo-full-nodes that fake the user-agent?
> 
> As I said, there are people who have said they will spin up thousands of full nodes to help prevent possible Sybil attacks which would become marginally easier to accomplish immediately after the first >1mb block was produced and full nodes that hadn't upgraded were left behind.
> 
> Would Blockstream be willing to help out by running a dozen or two extra full nodes?
> 
> I can't imagine any even-remotely-likely sequence of events that would require a rollback, can you be more specific about what you are imagining?  Miners suddenly getting cold feet?

Well that, but also past performance isn't an indication of future performance, necessarily. They might have gone out of business, to give one example. There is surely assumed self-interest, but I have also seen rumors floating around of this being used as an arbitrage opportunity. Would suck to imagine that ever happening, but since this seems like it's being managed on more handshake type of deals (or conversations), are there any legal documents backing those commitments up? Or is that definitely overkill?

Maybe it's worth documenting the full range of possible series of events and then their presumed level of unlikelihood? "What can go wrong will go wrong", "Black Swan" events, type of considerations. :) Often when people discuss unlikely things like crypto being broken, it's like, "Assuming processing power of x, increasing at a rate of x, and a known age of the universe of x, it would take a billion times the known length of the universe for that to happen".

Certainly not everything fits so easily into that framing, but it would be really helpful to see the "what could possibly go wrong" things fully enumerated.

Thanks!!

Dave

>  
>> How do you plan to monitor and manage security through the hard-fork?
> 
> I don't plan to monitor or manage anything; the Bitcoin network is self-monitoring and self-managing. Services like statoshi.infowill do the monitoring, and miners and people and businesses will manage the network, as they do every day.
> 
> -- 
> --
> Gavin Andresen
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 12129 bytes --]