Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-07 📝 Original message:> > The appropriate method ...
📅 Original date posted:2015-05-07
📝 Original message:>
> The appropriate method of doing any fork, that we seem to have been
> following for a long time, is to get consensus here and on IRC and on
> github and *then* go pitch to the general public
So your concern is just about the ordering and process of things, and not
about the change itself?
I have witnessed many arguments in IRC about block sizes over the years.
There was another one just a few weeks ago. Pieter left the channel for his
own sanity. IRC is not a good medium for arriving at decisions on things -
many people can't afford to sit on IRC all day and conversations can be
hard to follow. Additionally, they tend to go circular.
That said, I don't know if you can draw a line between the "ins" and "outs"
like that. The general public is watching, commenting and deciding no
matter what. Might as well deal with that and debate in a format more
accessible to all.
> If, instead, there had been an intro on the list as "I think we should
> do the blocksize increase soon, what do people think?"
There have been many such discussions over time. On bitcointalk. On reddit.
On IRC. At developer conferences. Gavin already knew what many of the
objections would be, which is why he started answering them.
But alright. Let's say he should have started a thread. Thanks for starting
it for him.
Now, can we get this specific list of things we should do before we're
prepared?
> A specific credible alternative to what? Committing to blocksize
> increases tomorrow? Yes, doing more research into this and developing
> software around supporting larger block sizes so people feel comfortable
> doing it in six months.
Do you have a specific research suggestion? Gavin has run simulations
across the internet with modified full nodes that use 20mb blocks, using
real data from the block chain. They seem to suggest it works OK.
What software do you have in mind?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/76327a71/attachment.html>;
📝 Original message:>
> The appropriate method of doing any fork, that we seem to have been
> following for a long time, is to get consensus here and on IRC and on
> github and *then* go pitch to the general public
So your concern is just about the ordering and process of things, and not
about the change itself?
I have witnessed many arguments in IRC about block sizes over the years.
There was another one just a few weeks ago. Pieter left the channel for his
own sanity. IRC is not a good medium for arriving at decisions on things -
many people can't afford to sit on IRC all day and conversations can be
hard to follow. Additionally, they tend to go circular.
That said, I don't know if you can draw a line between the "ins" and "outs"
like that. The general public is watching, commenting and deciding no
matter what. Might as well deal with that and debate in a format more
accessible to all.
> If, instead, there had been an intro on the list as "I think we should
> do the blocksize increase soon, what do people think?"
There have been many such discussions over time. On bitcointalk. On reddit.
On IRC. At developer conferences. Gavin already knew what many of the
objections would be, which is why he started answering them.
But alright. Let's say he should have started a thread. Thanks for starting
it for him.
Now, can we get this specific list of things we should do before we're
prepared?
> A specific credible alternative to what? Committing to blocksize
> increases tomorrow? Yes, doing more research into this and developing
> software around supporting larger block sizes so people feel comfortable
> doing it in six months.
Do you have a specific research suggestion? Gavin has run simulations
across the internet with modified full nodes that use 20mb blocks, using
real data from the block chain. They seem to suggest it works OK.
What software do you have in mind?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/76327a71/attachment.html>;