On Fri, May 29, 2015 at 12:26 PM, Mike Hearn m...@plan99.net wrote:
IMO it's not even clear there needs to be a size limit at all. Currently
the 32mb message cap imposes one anyway
If the plan is a fix once and for all, then that should be changed too. It
could be set so that it is at least
By the time a hard fork can happen, I expect average block size will be
above 500K.
Yes, possibly.
Would you support a rule that was larger of 1MB or 2x average size ?
That is strictly better than the situation we're in today.
It is, but only by a trivial amount - hitting the limit is
If the plan is a fix once and for all, then that should be changed too.
It could be set so that it is at least some multiple of the max block size
allowed.
Well, but RAM is not infinite :-) Effectively what these caps are doing is
setting the minimum hardware requirements for running a
What do other people think?
If we can't come to an agreement soon, then I'll ask for help
reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
big increase now that grows over time so we may never have to go through
all this rancor and debate again.
I'll then ask for help
Are you really that pig headed that you are going to try and blow up the
entire system just to get your way? A bunch of ignorant redditors do not
make consensus, mercifully.
On 2015-05-29 12:39, Gavin Andresen wrote:
What do other people think?
If we can't come to an agreement soon, then
How is this being pigheaded? In my opinion, this is leadership. If
*something* isn't implemented soon, the network is going to have some real
problems, right at the
time when adoption is starting to accelerate. I've been seeing nothing but
navel-gazing and circlejerks on this issue for weeks
On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
But if there is still no consensus among developers but the bigger blocks
now movement is successful, I'll ask for help getting big miners to do the
same, and use the soft-fork block version voting mechanism to
Regarding Tier’s proposal: The lower security you mention for extended blocks
would delay, possibly forever, the larger blocks maximum block size that we
want for the entire network. That doesn’t sound like an optimal solution.
Regarding consensus for larger maximum block size, what we are
On Fri, May 29, 2015 at 5:39 PM, Raystonn . rayst...@hotmail.com wrote:
Regarding Tier’s proposal: The lower security you mention for extended
blocks would delay, possibly forever, the larger blocks maximum block size
that we want for the entire network. That doesn’t sound like an optimal
What about trying the dynamic scaling method within the 20MB range + 1 year
with a 40% increase of that cap? Until a way to dynamically scale is
found, the cap will only continue to be an issue. With 20 MB + 40% yoy,
we're either imposing an arbitrary cap later, or achieving less than great
DOS
miners would definitely be squeezing out transactions / putting pressure
to increase transaction fees
I'd just like to re-iterate that transactions getting squeezed out
(failure after a lengthy period of uncertainty) is a radical change from
the current behavior of the network. There are plenty
Matt brought this up on Twitter, I have no idea why I didn't respond weeks
ago (busy writing blog posts, probably):
On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
* Though there are many proposals floating around which could
significantly decrease block
On 05/29/15 22:36, Gavin Andresen wrote:
Matt brought this up on Twitter, I have no idea why I didn't respond
weeks ago (busy writing blog posts, probably):
On Thu, May 7, 2015 at 6:02 PM, Matt Corallo bitcoin-l...@bluematt.me
mailto:bitcoin-l...@bluematt.me wrote:
* Though
Hello. I am from F2Pool. We are currently mining the biggest blocks on
the network. So far top 100 biggest bitcoin blocks are all from us. We
do support bigger blocks and sooner rather than later. But we cannot
handle 20 MB blocks right now. I know most blocks would not be 20 MB
over night. But
I discussed the extension block idea on wizards a while back and it is
a way to soft-fork an opt-in block-size increase. Like everything
here there are pros and cons.
The security is better than Raylstonn inferred from Tier's explanation
I think.. It works as Tier described - there is an
On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen gavinandre...@gmail.com
wrote:
What do other people think?
If we can't come to an agreement soon, then I'll ask for help
reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
big increase now that grows over time so we may
On Fri, May 29, 2015 at 10:09 AM, Tier Nolan tier.no...@gmail.com wrote:
How do you intend to measure exchange/merchant acceptance?
Public statements saying we're running software that is ready for bigger
blocks.
And looking at the version (aka user-agent) strings of publicly reachable
nodes
The measure is miner consensus. How do you intend to measure
exchange/merchant acceptance?
Asking them.
In fact, we already have. I have been talking to well known people and CEOs
in the Bitcoin community for some time now. *All* of them support bigger
blocks, this includes:
- Every
On Fri, May 29, 2015 at 3:09 PM, Tier Nolan tier.no...@gmail.com wrote:
On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
But if there is still no consensus among developers but the bigger
blocks now movement is successful, I'll ask for help getting big miners
And looking at the version (aka user-agent) strings of publicly reachable
nodes on the network.
(e.g. see the count at https://getaddr.bitnodes.io/nodes/ )
Yeah, though FYI Luke informed me last week that I somehow managed to take
out the change to the user-agent string in Bitcoin XT,
20 matches
Mail list logo
