Re: [bitcoin-dev] Block size following technological growth

On Mon, Aug 10, 2015 at 12:28 PM, Jorge Timón wrote: > I would just like that there was an attempt to automatically > estimate those risks before taking those risks. > I agree. > My main point about fees is that minimum mining fees rising above zero > (theri current level) is not necessarily a

Re: [bitcoin-dev] Block size following technological growth

On Fri, Aug 7, 2015 at 1:09 AM, Elliot Olds wrote: > On Wed, Aug 5, 2015 at 6:26 PM, Jorge Timón wrote: > I agree with you that decentralization is the most important feature of > Bitcoin, but I also think we need to think probabilistically and concretely > about when risks to decentralization ar

Re: [bitcoin-dev] Block size following technological growth

On Wed, Aug 5, 2015 at 6:26 PM, Jorge Timón wrote: > > > Given that for any non-absurdly-big size some transactions will > eventually be priced out, and that the consensus rule serves for > limiting mining centralization (and more indirectly centralization in > general) and not about trying to set

Re: [bitcoin-dev] Block size following technological growth

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 6 August 2015 10:21:54 GMT-04:00, Gavin Andresen via bitcoin-dev wrote: >On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille > >wrote: > >> But you seem to consider that a bad thing. Maybe saying that you're >> claiming that this equals Bitcoin fai

Re: [bitcoin-dev] Block size following technological growth

Really, thanks again for replying and not getting mad when I get your thoughts wrong. I believe that I've learned more about your position on the subject today than in months of discussion and blogs (that's not a critique to your blog post, it's just that they didn't answer to some questions that I

Re: [bitcoin-dev] Block size following technological growth

On Aug 6, 2015 9:42 PM, "Gavin Andresen via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: 2. The "market minimum fee" should be determined by the market. It should not be up to us to decide "when is a good time." I partially agree. The community should decide what risks it is willin

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 1:15 PM, Jorge Timón wrote: > So I reformulate the question: > > 1) If "not now", when will it be a good time to let the "market > minimum fee for miners to mine a transaction" rise above zero? Two answers: 1. If you are willing to wait an infinite amount of time, I thin

Re: [bitcoin-dev] Block size following technological growth

First of all, thank you very much for answering the questions, and apologies for not having formulated them properly (fortunately that's not an irreparable mistake). On Thu, Aug 6, 2015 at 6:03 PM, Gavin Andresen wrote: > On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón wrote: >> >> 1) If "not now"

Re: [bitcoin-dev] Block size following technological growth

On 8/6/2015 7:53 AM, Pieter Wuille via bitcoin-dev wrote: > > So if we would have 8 MB blocks, and there is a sudden influx of users > (or settlement systems, who serve much more users) who want to pay > high fees (let's say 20 transactions per second) making the block > chain inaccessible for low

Re: [bitcoin-dev] Block size following technological growth

Whilst 1mb to 8mb might seem irrelevant from a pure computer science perspective payment demand is not really infinite, at least not if by "payment" we mean something resembling how current Bitcoin users use the network. If we define "payment" to mean the kind of thing that Bitcoin users and enthu

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón wrote: > 1) If "not now" when will it be a good time to let fees rise above zero? > Fees are already above zero. See http://gavinandresen.ninja/the-myth-of-not-full-blocks > 2) When will you consider a size to be too dangerous for centralization? >

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen wrote: > On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón > wrote: >> >> This is a much more reasonable position. I wish this had been starting >> point of this discussion instead of "the block size limit must be >> increased as soon as possible or bitcoi

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 4:21 PM, Gavin Andresen wrote: > On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille > wrote: > >> But you seem to consider that a bad thing. Maybe saying that you're >> claiming that this equals Bitcoin failing is an exaggeration, but you do >> believe that evolving towards an

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille wrote: > But you seem to consider that a bad thing. Maybe saying that you're > claiming that this equals Bitcoin failing is an exaggeration, but you do > believe that evolving towards an ecosystem where there is competition for > block space is a bad

Re: [bitcoin-dev] Block size following technological growth

On Thu, Aug 6, 2015 at 3:40 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> This is a much more reasonable position. I wish this had been starting >> point of thi

Re: [bitcoin-dev] Block size following technological growth

On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón < bitcoin-dev@lists.linuxfoundation.org> wrote: > This is a much more reasonable position. I wish this had been starting > point of this discussion instead of "the block size limit must be > increased as soon as possible or bitcoin will fail". > It REAL

Re: [bitcoin-dev] Block size following technological growth

On Wed, Aug 5, 2015 at 9:29 AM, Elliot Olds wrote: > On Tue, Aug 4, 2015 at 4:59 AM, Jorge Timón > wrote: >> >> Also I don't think "hitting the limit" must be necessarily harmful and >> if it is, I don't understand why hitting it at 1MB will be more >> harmful than hitting it at 2MB, 8MB or 8GB.

Re: [bitcoin-dev] Block size following technological growth

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 4 August 2015 11:12:36 PM AEST, Gavin Andresen via bitcoin-dev wrote: >On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I would say that things already demonstrately got terrib

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 4:59 AM, Jorge Timón < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Also I don't think "hitting the limit" must be necessarily harmful and > if it is, I don't understand why hitting it at 1MB will be more > harmful than hitting it at 2MB, 8MB or 8GB. I don't think mere

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 3:28 PM, Hector Chu wrote: > On 4 August 2015 at 14:13, Jorge Timón wrote: >> >> 2) It doesn't matter who is to blame about the current centralization: >> the fact remains that the blocksize maximum is the only** consensus >> rule to limit mining centralization. > > > Repea

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 9:12 AM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I would say that things already demonstrately got terrible. The mini

Re: [bitcoin-dev] Block size following technological growth

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2015 08:12 PM, Gavin Andresen via bitcoin-dev wrote: > On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev > > wrote: > > I would say that things already demonstrately got terrible.

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 3:12 PM, Gavin Andresen wrote: > On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I would say that things already demonstrately got terrible. The mining >> landscape is very centralized, with apparently a m

Re: [bitcoin-dev] Block size following technological growth

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2015 08:28 PM, Hector Chu via bitcoin-dev wrote: > On 4 August 2015 at 14:13, Jorge Timón > wrote: > > 2) It doesn't matter who is to blame about the current > centralization: the fact remains that the blocksize ma

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 2:19 PM, Hector Chu wrote: > On 4 August 2015 at 12:59, Jorge Timón wrote: >> >> That is not my position. Again, I don't know what the right blocksize >> for the short term is (I don't think anybody does). > > You have no position (i.e. neutral). In other words, keeping the

Re: [bitcoin-dev] Block size following technological growth

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2015 07:19 PM, Hector Chu via bitcoin-dev wrote: > On 4 August 2015 at 12:59, Jorge Timón > wrote: > So if you say 8, I must ask, why not 9? Why 9 MB is not safe for > mining centralization but 8 MB is? > > > 8M

Re: [bitcoin-dev] Block size following technological growth

On 4 August 2015 at 14:13, Jorge Timón wrote: > 2) It doesn't matter who is to blame about the current centralization: > the fact remains that the blocksize maximum is the only** consensus > rule to limit mining centralization. > Repeating a claim ad-nauseum doesn't make it necessarily true. A b

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 1:34 PM, Hector Chu wrote: > Things apparently aren't bad enough to prevent the majority from clamoring > for larger blocks. Nobody is preventing anyone from claiming anything. Some developers are encouraging users to ask for bigger blocks. Others don't want to impose conse

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I would say that things already demonstrately got terrible. The mining > landscape is very centralized, with apparently a majority depending on > agreements to trust each other's announc

Re: [bitcoin-dev] Block size following technological growth

On 4 August 2015 at 12:59, Jorge Timón wrote: > That is not my position. Again, I don't know what the right blocksize > for the short term is (I don't think anybody does). > You have no position (i.e. neutral). In other words, keeping the existing limit. > Therefore how the change can affect m

Re: [bitcoin-dev] Block size following technological growth

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2015 06:34 PM, Hector Chu via bitcoin-dev wrote: > Things apparently aren't bad enough to prevent the majority from > clamoring for larger blocks. > > If the majority agreed that things had got worse till this point, > and that this was t

Re: [bitcoin-dev] Block size following technological growth

On Tue, Aug 4, 2015 at 1:04 PM, Hector Chu wrote: > Mike's position is that he wants the block size limit to eventually be > removed. That is of course an extreme view. I prefer to wait and let him talk by himself. > Meanwhile, your view that the > block size should be artificially constrained b

Re: [bitcoin-dev] Block size following technological growth

Things apparently aren't bad enough to prevent the majority from clamoring for larger blocks. If the majority agreed that things had got worse till this point, and that this was to be blamed on the block size, they would be campaigning for the other direction. Even yourselves aren't asking for a r

Re: [bitcoin-dev] Block size following technological growth

I would say that things already demonstrately got terrible. The mining landscape is very centralized, with apparently a majority depending on agreements to trust each other's announced blocks without validation. Full node count is at its historically lowest value in years, and outsourcing of full v

Re: [bitcoin-dev] Block size following technological growth

Mike's position is that he wants the block size limit to eventually be removed. That is of course an extreme view. Meanwhile, your view that the block size should be artificially constrained below the organic growth curve (in a way that will penalize a majority of existing and future users) lies at

Re: [bitcoin-dev] Block size following technological growth

On Fri, Jul 31, 2015 at 4:58 PM, Mike Hearn wrote: >> How more users or more nodes can bring more miners, or more importantly, >> improve mining decentralization? > > > Because the bigger the ecosystem is the more interest there is in taking > part? As explained by Venzen, this is a non-sequitur.

Re: [bitcoin-dev] Block size following technological growth

On Thu, Jul 30, 2015 at 12:20:30PM -0400, Gavin Andresen wrote: > On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev > > Some things are not included yet, such as a testnet whose size runs ahead > > of the main chain, and the inclusion of Gavin's more accurate sigop > > checking after

Re: [bitcoin-dev] Block size following technological growth

On Fri, Jul 31, 2015 at 7:58 AM, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > But it is easier to find common ground with others by compromising. Is 8mb > better than no limit? I don't know and I don't care much: > People seeing statements like this might imagine

Re: [bitcoin-dev] Block size following technological growth

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/31/2015 09:58 PM, Mike Hearn via bitcoin-dev wrote: > How more users or more nodes can bring more miners, or more > importantly, improve mining decentralization? > > > Because the bigger the ecosystem is the more interest there is in > taking

Re: [bitcoin-dev] Block size following technological growth

> > How more users or more nodes can bring more miners, or more importantly, > improve mining decentralization? > Because the bigger the ecosystem is the more interest there is in taking part? I mean, I guess I don't know how to answer your question. When Bitcoin was new it had almost no users an

Re: [bitcoin-dev] Block size following technological growth

On Fri, Jul 31, 2015 at 7:15 AM, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > He is not saying that. Whatever the reasons for centralization are, it >> is obvious that increasing the size won't help. >> > > It's not obvious. Quite possibly bigger blocks == more use

Re: [bitcoin-dev] Block size following technological growth

On Fri, Jul 31, 2015 at 2:15 PM, Mike Hearn wrote: > Hey Jorge, > >> He is not saying that. Whatever the reasons for centralization are, it >> is obvious that increasing the size won't help. > > > It's not obvious. Quite possibly bigger blocks == more users == more nodes > and more miners. How mo

Re: [bitcoin-dev] Block size following technological growth

> Quite possibly bigger blocks == more users == more nodes and more miners. I agree and would say that this is the only prediction of bitcoin's future we can be absolutely sure of: more users equals more decentralization as long as the cost of running a node is not prohibitively high. It's incred

Re: [bitcoin-dev] Block size following technological growth

Hey Jorge, He is not saying that. Whatever the reasons for centralization are, it > is obvious that increasing the size won't help. > It's not obvious. Quite possibly bigger blocks == more users == more nodes and more miners. To repeat: it's not obvious to me at all that everything wrong with Bi

Re: [bitcoin-dev] Block size following technological growth

On Fri, Jul 31, 2015 at 12:16 PM, Mike Hearn via bitcoin-dev wrote: >> Well, centralization of mining is already terrible. I see no reason why we >> should encourage making it worse. > > I see constant assertions that node count, mining centralisation, developers > not using Bitcoin Core in their

Re: [bitcoin-dev] Block size following technological growth

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Hearn, I might be a nobody to you, but you know i talk with skill, so let me tell this Friday... On 07/31/2015 05:16 PM, Mike Hearn via bitcoin-dev wrote: > I agree with Gavin You would, of course. > Bitcoin can support a large scale and it mu

Re: [bitcoin-dev] Block size following technological growth

I agree with Gavin - whilst it's great that a Blockstream employee has finally made a realistic proposal (i.e. not "let's all use Lightning") - this BIP is virtually the same as keeping the 1mb cap. > Well, centralization of mining is already terrible. I see no reason why we > should encourage mak

Re: [bitcoin-dev] Block size following technological growth

On Thursday 30. July 2015 16.25.02 Pieter Wuille via bitcoin-dev wrote: > Hello all, > > here is a proposal for long-term scalability I've been working on: > https://gist.github.com/sipa/c65665fc360ca7a176a6 > > Some things are not included yet, such as a testnet whose size runs ahead > of the ma

Re: [bitcoin-dev] Block size following technological growth

Gavin, Pieter, Mark, Gary, can we move the median time discussion to its own thread? http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html I really don't want to fill this thread with that discussion. On Thu, Jul 30, 2015 at 7:51 PM, Jorge Timón wrote: > On Thu, Jul 30, 20

Re: [bitcoin-dev] Block size following technological growth

On Thu, Jul 30, 2015 at 6:36 PM, Venzen Khaosan wrote: > I just had a look your existing Size N testnet code > https://github.com/bitcoin/bitcoin/pull/6382 > and i'll set up a node over the weekend and post its address in that > PR's conversation. Do you or anyone else already have a node running?

Re: [bitcoin-dev] Block size following technological growth

On Thu, Jul 30, 2015 at 6:20 PM, Gavin Andresen via bitcoin-dev wrote: > On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev > wrote: > So we'd get to 2MB blocks in the year 2021. I think that is much too > conservative When considering "too conservative" options, let's not forget th

Re: [bitcoin-dev] Block size following technological growth

The median is used here because that is the consensus rule -- a block cannot have a timestamp older than the median time of the last 11 blocks. By linking the changeover to this rule we avoid perverse incentives about miners lying in their timestamps, or the threshold being crossed, then reverted,

Re: [bitcoin-dev] Block size following technological growth

On 30 July 2015 at 16:12, Jorge Timón wrote: > 1) Unlike previous blocksize hardfork proposals, this uses median time > instead of block.nTime for activation. I like that more but my > preference is still using height for everything. But that discussion > is not specific to this proposal, so it's

Re: [bitcoin-dev] Block size following technological growth

On Jul 30, 2015 6:20 PM, "Gavin Andresen" wrote: > > On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Some things are not included yet, such as a testnet whose size runs ahead of the main chain, and the inclusion of Gavin's more

Re: [bitcoin-dev] Block size following technological growth

That's what is nice about proposals, they are constructive and help move the conversation forward! On 30 July 2015 at 18:20, Gavin Andresen via bitcoin-dev wrote: > Specific comments: > > So we'd get to 2MB blocks in the year 2021. I think that is much too > conservative, and the most likely effe

Re: [bitcoin-dev] Block size following technological growth

I fully expect that new layers will someday allow us to facilitate higher transaction volumes, though I'm concerned about the current state of the network and the fact that there are no concrete timelines for the rollout of aforementioned high volume networks. As for reasoning behind why users wil

Re: [bitcoin-dev] Block size following technological growth

On Thu, Jul 30, 2015 at 12:20 PM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So we'd get to 2MB blocks in the year 2021. I think that is much too > conservative, and the most likely effect of being that conservative is that > the main blockchain becomes a sett

Re: [bitcoin-dev] Block size following technological growth

On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Stated differently, if the cost or contention of using the network rises > to the point of excluding the average user from making transactions, then > they probably aren't going to care

Re: [bitcoin-dev] Block size following technological growth

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2015 10:12 PM, Jorge Timón via bitcoin-dev wrote: [snip] > But even if I'm the only one that considers a "technological > de-growth" possible, I don't think is wise to rely on pseudo-laws > like Moore's or Nielsen’s so-called "laws". Steali

Re: [bitcoin-dev] Block size following technological growth

I find it to be an admirable goal to try to keep node operation costs low and accessible to the average user. On the other hand, if we are able to keep the resource requirements of nodes at the level of, say, whatever the latest Raspberry Pi model on a residential Internet connection can handle, I'

Re: [bitcoin-dev] Block size following technological growth

On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Some things are not included yet, such as a testnet whose size runs ahead > of the main chain, and the inclusion of Gavin's more accurate sigop > checking after the hard fork. > > Com

Re: [bitcoin-dev] Block size following technological growth

1) Unlike previous blocksize hardfork proposals, this uses median time instead of block.nTime for activation. I like that more but my preference is still using height for everything. But that discussion is not specific to this proposal, so it's better if we discuss that for all of them here: http:/

Re: [bitcoin-dev] Block size following technological growth

What, if any, methods would be used for miners to communicate their upgrade? Greg On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello all, > > here is a proposal for long-term scalability I've been working on: > https://gist.git

[bitcoin-dev] Block size following technological growth

Hello all, here is a proposal for long-term scalability I've been working on: https://gist.github.com/sipa/c65665fc360ca7a176a6 Some things are not included yet, such as a testnet whose size runs ahead of the main chain, and the inclusion of Gavin's more accurate sigop checking after the hard for