Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

Hello Adam First of all, thank you for inventing hashcash, which is basically what bitcoin is! Some people have said that my proposal, subject line "Scaling Bitcoin with Subchains" is essentially the idea of blockchain extensions. Though, I think there is quite a difference between what I propose

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

First off, I am glad that the idea of dynamic block size adjustment is gaining some attention, in particular the model that I proposed. I wanted to take some time and explain some of the philosophy of how, and why, I proposed this this particular model. When Bitcoin was first made, there was a 32

Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

My fear now is too much unnecessary complexity.  More complex means brittle code, but also fewer programmers working on this, which is a risk. We shouldn't delay forever until every potential solution has been explored.  There's always going to be one more thing to explore. On 29 May 2015 5:16 pm,

Re: [Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

RE: soft-forking an "extension block": So... go for it, code it up. Implement it in the Bitcoin Core wallet. Then ask the various wallet developer how long it would take them to update their software to support something like this, and do some UI mockups of what the experience would look like for

[Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

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 extensi

Re: [Bitcoin-development] Block Size Increase Requirements

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 onl

Re: [Bitcoin-development] Block Size Increase Requirements

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 > wrote: > > > > * Though there are many pro

Re: [Bitcoin-development] Block Size Increase Requirements

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 wrote: > > > * Though there are many proposals floating around which could > significantly decrease block propagation latency, none of

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen 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 never have to go

Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

On Fri, May 29, 2015 at 5:39 PM, Raystonn . 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 > solution. > I do

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

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 p

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

> 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 plent

Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

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 seei

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

> > 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, p

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

On Fri, May 29, 2015 at 3:09 PM, Tier Nolan wrote: > > > On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen > 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 so

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

> > 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

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

On Fri, May 29, 2015 at 10:09 AM, Tier Nolan 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 on the network.

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

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 now.

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen 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 (hopefully) > get a maj

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

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

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

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 l

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

> > 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 B

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

On Fri, May 29, 2015 at 12:26 PM, Mike Hearn 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 some multiple

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

> > 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 li