Hey Matt,
OK, let's get started
However, there hasnt been any discussion on this
mailing list in several years as far as I can tell.
Probably because this list is not a good place for making progress or
reaching decisions. Those are triggered by pull requests (sometimes).
If you're
On Thu, May 07, 2015 at 12:59:13PM -0400, Gavin Andresen wrote:
Fee dynamics seems to come up over and over again in these discussions,
with lots of talk and theorizing.
I hope some data on what is happening with fees right now might help, so I
wrote another blog post (with graphs, which
The only answer to this that anyone with a clue should give is it
will very, very likely be able to support at least 1MB blocks roughly
every 10 minutes on average for the next eleven years, and it seems
likely that a block size increase of some form will happen at some point in
the next
On Thu, May 7, 2015 at 3:31 PM, Alan Reiner etothe...@gmail.com wrote:
(1) Blocks are essentially nearing full now. And by full he means
that the reliability of the network (from the average user perspective) is
about to be impacted in a very negative way
Er, to be economically precise,
On Thu, May 7, 2015 at 1:26 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
I think this is a huge issue. You've been wandering around telling
people that the blocksize will increase soon for months
I think the strongest thing I've ever said is:
There is consensus that the max block size
Instead of raising the block size to another static number like 20MB, can
we raise it dynamically?
Make the max block size something like:
pow(2, nHeight/10) * 1MB; //double every ~2 years
--
One dashboard for
Just to add to the noise, did you consider linear growth?
Unlike exponential growth, it approximates diminishing returns (i.e. tech
advances become slower with time). And unlike single step, it will give
people time to adapt to new realities.
E.g. 2 MB in 2016, 3 MB in 2017 and so on.
So in 20
On Thu, May 7, 2015 at 3:03 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
More generally, consider the situation we're in now. Gavin is going off
pitching this idea to the general public (which, I agree, is an
important step in pulling off a hardfork) while people who actually
study the
On 05/07/15 11:29, Mike Hearn wrote:
Can you please elaborate on what terrible things will happen if we
don't increase the block size by winter this year?
I was referring to winter next year. 0.12 isn't scheduled until the end
of the year, according to Wladimir. I explained where
Any proposal to switch to a new hardcorded value so we have time to
*really* figure out later what's next and all implications, is a road
to a gigantic issue later when we want to switch to that next.
Sure we would have more time to think about, research all
implications, simulate, discuss, etc.
It seems to me like some (maybe most) of the pressure is actually external
from companies that might release something that dramatically increases
adoption transaction rates (and that the data on historic rate of
adoption slumps is somewhat disconnected from their interests in a quick
roll-out)?
Can anyone opposed to this proposal articulate in plain english the worst
case scenario(s) if it goes ahead?
Some people in the conversation appear to be uncomfortable, perturbed,
defensive etc about the proposal . But I am not seeing specifics on why it
is not a feasible plan.
From: Mike
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 09:54 PM, Jeff Garzik wrote:
By the time we get to fee pressure, in your scenario, our network
node count is tiny and highly centralized.
Again, this assertion requires proof.
Simply saying things is not the same as them being true.
I have written up an explanation of what I think will happen if we run out
of capacity:
https://medium.com/@octskyward/crash-landing-f5cc19908e32
Looks like a solid description of what would happen.
I fail to see how this description wouldn't be applicable also to a
20MB-network in some
On Thu, May 7, 2015 at 6:43 PM, Mike Hearn m...@plan99.net wrote:
And I'll ask again. Do you have a *specific, credible alternative*?
Because so far I'm not seeing one.
I think you are rubbing against your own presupposition that people must
find and alternative right now. Quite a lot here do
I'm presuming that schedule is just an example, as you'd end up with
insanely large block sizes in a few years.
Absolutely, yes, an increase schedule is an option if people agree on
it, and I think the better option, as the current limit too low, but
jumping straight to a value big enough for
This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing full now. And by full he means
that the reliability
On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen gavinandre...@gmail.com wrote:
Fee dynamics seems to come up over and over again in these discussions, with
lots of talk and theorizing.
I hope some data on what is happening with fees right now might help, so I
wrote another blog post (with
I think you are rubbing against your own presupposition that people must
find and alternative right now. Quite a lot here do not believe there is
any urgency, nor that there is an immanent problem that has to be solved
before the sky falls in.
I have explained why I believe there is some
These statements may even be true, but they're no logical conclusions
even if they seem obvious to you.
I don't think those claims are strictly true, specially because they
involve predictions about what people will do.
But if they're true they require some proof or at least some explanation.
Can I just add my own support for this - as has been stated elsewhere in
this discussion, hard forks are difficult, and risky. The earlier we
have a decision, and the earlier the change goes into the code, the
easier that is.
Even if the decision was the actual block size change is fine to
On Thu, May 7, 2015 at 7:40 PM, Gavin Costin slashdevn...@hotmail.com
wrote:
Can anyone opposed to this proposal articulate in plain english the worst
case scenario(s) if it goes ahead?
Some people in the conversation appear to be uncomfortable, perturbed,
defensive etc about the proposal ….
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
On Thu, May 7, 2015 at 5:11 PM, Mike Hearn m...@plan99.net wrote:
Right now there is this nice warm fuzzy notion that decisions in Bitcoin
Core are made by consensus. Controversial changes are avoided. I am
trying to show you that this is just marketing.
Consensus is arrived when the people
Hi Matt,
I agree that starting discussion on how to approach this problem is
necessary and it's difficult taking positions without details on what is
being discussed.
A simple hard 20-megabyte increase will likely create perverse
incentives, perhaps a method can exist with some safe transition.
On 5/7/2015 12:54 PM, Jeff Garzik wrote:
In the short term, blocks are bursty, with some on 1 minute intervals,
some with 60 minute intervals. This does not change with larger blocks.
I'm pretty sure Alan meant that blocks are already filling up after long
inter-block intervals.
2)
On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote:
OK, so lets do that. I've seen a lot of I'm not entirely comfortable
with committing to this right now, but think we should eventually, but
not much I'd be comfortable with committing to this when I see X. In
the interest of
One of the suggestions to avoid the problem of fees going to zero is
assurance contracts. This lets users (perhaps large merchants or
exchanges) pay to support the network. If insufficient people pay for the
contract, then it fails.
Mike Hearn suggests one way of achieving it, but it doesn't
OK, so lets do that. I've seen a lot of I'm not entirely comfortable
with committing to this right now, but think we should eventually, but
not much I'd be comfortable with committing to this when I see X. In
the interest of ignoring debate and pushing people towards a consensus
at all costs, ( ;)
I am more fazed by PR 5288 and PR 5925 not getting merged in, than by this
thread. So, casting my ballot in favor of the block size increase. Clearly,
we're still rehearsing proper discourse, and that ain't gonna get fixed
here and now.
On Thu, May 7, 2015 at 9:29 PM, Matt Corallo
Having observed the customer support nightmare it tends to cause for a
small exchange service when 100% full blocks happen, I've been thinking
that the limit really should be dynamic and respond to demand and the
amount of fees offered. It just doesn't feel right when it takes ages to
burn through
Can you please elaborate on what terrible things will happen if we
don't increase the block size by winter this year?
I was referring to winter next year. 0.12 isn't scheduled until the end of
the year, according to Wladimir. I explained where this figure comes from
in this article:
On Thu, May 7, 2015 at 1:29 PM, Mike Hearn m...@plan99.net wrote:
I was referring to winter next year. 0.12 isn't scheduled until the end of
the year, according to Wladimir. I explained where this figure comes from in
this article:
On Thu, May 07, 2015 at 11:25:04AM +0200, Mike Hearn wrote:
Certainly a consensus in this kind of technical community should be a
basic requirement for any serious commitment to blocksize increase.
I'm afraid I have come to disagree. I no longer believe this community can
reach consensus
I'm mainly just an observer on this. I mostly agree with Pieter. Also, I
think the main reason why people like Gavin and Mike Hearn are trying to
rush this through is because they have some kind of apps that depend on
zero conf instant transactions, so this would of course require more
traffic on
On May 7, 2015 3:08 PM, Roy Badami r...@gnomon.org.uk wrote:
On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
I would not modify my node if the change introduced a perpetual 100 BTC
subsidy per block, even if 99% of miners went along with it.
Surely, in that scenario Bitcoin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
While being in the Bitcoin community for a long time, I haven't been
so directly involved in the development. However I wish to suggest a
different pre-hard-fork soft-fork approach:
Set a 'block size cap' in the similar same way as we set
Nicolas, can you think if there would be a problem with allowing blocks to be
created faster instead of increasing block size? So say if difficulty was
reduced to allow block creation every 2 minutes instead of 10 minutes, can you
think of any bad outcome from this (I know this is different to
On 5/7/2015 7:09 PM, Jeff Garzik wrote:
G proposed 20MB blocks, AFAIK - 140 tps
A proposed 100MB blocks - 700 tps
For ref,
Paypal is around 115 tps
VISA is around 2000 tps (perhaps 4000 tps peak)
I ask again: where do we want to go? This is the existential
question behind block size.
On Thu, May 7, 2015 at 9:40 PM, Tom Harding t...@thinlink.com wrote:
On 5/7/2015 12:54 PM, Jeff Garzik wrote:
2) Where do you want to go? Should bitcoin scale up to handle all the
world's coffees?
Alan was very clear. Right now, he wants to go exactly where Gavin's
concrete proposal
On Thu, May 07, 2015 at 03:31:46PM -0400, Alan Reiner wrote:
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they
On 5/7/2015 6:40 AM, Jorge Timón wrote:
Known: There's a major problem looming for miners at the next block reward
halving. Many are already in a bad place and without meaningful fees then
sans a 2x increase in the USD:BTC ratio then many will simply have to leave
the network, increasing
Well this is all very extreme circumstances, and you'd have to assume no
rational player with an interest in bitcoin would go there, but to play
your analysis forward: users are also not powerless at the extreme: they
could change the hash function rendering current deployed ASICs useless in
I have a lot more written down, a WIP; here are the highlights.
- The 1MB limit is an ancient anti-spam limit, and needs to go.
- The 1MB limit is economically entrenched at this point, and cannot be
removed at a whim.
- This is a major change to the economics of a $3.2B system. This change
On Thu, May 7, 2015 at 9:05 AM, Mike Hearn m...@plan99.net wrote:
Maybe you dislike that idea. It's so centralised. So let's say Gavin
commits his patch, because his authority is equal to all other committers.
Someone else rolls it back. Gavin sets up a cron job to keep committing the
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote:
Peter: your hypocrisy really is bottomless, isn't it? You constantly
claim to be a Righteous Defender of Privacy, but don't even hesitate before
publishing hacked private emails when it suits you.
Satoshi's hacker had no illusions
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson d...@hashingit.com wrote:
Known: There has been a steady trend towards the mean block size getting
larger. See
https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address=
Looking at
If his explanation was I will change my mind after we increase block
size, I guess the community should say then we will just ignore your
nack because it makes no sense.
Oh good! We can just kick anyone out of the consensus process if we think
they make no sense.
I guess that means me and
I would not modify my node if the change introduced a perpetual 100 BTC
subsidy per block, even if 99% of miners went along with it.
A hardfork is safe when 100% of (economically relevant) users upgrade. If
miners don't upgrade at that point, they just lose money.
This is why a
Executive Summary:
I explain the objectives that we should aim to reach agreement without
drama, controversy, and relief the core devs from the central banker role.
(As Jeff Garzik pointed out)
Knowing the objectives, I propose a solution based on the objectives that
can be agreed on tomorrow,
On 05/07/15 19:34, Mike Hearn wrote:
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
I'd love to have more discussion of exactly how a hard fork should be
implemented. I think it might actually be of some value to have rough
consensus on that before we get too bogged down with exactly what the
proposed hard fork should do. After all, how can we debate whether a
particular hard
In terms of miners, a strong supermajority is arguably sufficient, even 75%
would be enough.
The near total consensus required is merchants and users. If (almost) all
merchants and users updated and only 75% of the miners updated, then that
would give a successful hard-fork.
On the other hand,
On the other hand, if 99.99% of the miners updated and only 75% of
merchants and 75% of users updated, then that would be a serioud split of
the network.
But is that a plausible scenario? Certainly *if* the concensus rules
required a 99% supermajority of miners for the hard fork to go ahead,
On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
I would not modify my node if the change introduced a perpetual 100 BTC
subsidy per block, even if 99% of miners went along with it.
Surely, in that scenario Bitcoin is dead. If the fork you prefer has
only 1% of the hash power it
That strikes me as a dangerous path forward.
I don't actually think there is anything wrong with this: everybody
eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and
we're left with the status quo
What gives Bitcoin value aren't its technical merits but the fact that
people
What gives Bitcoin value aren't its technical merits but the fact that
people believe in it.
Much of the belief in Bitcoin is that it has a bright future. Certainly the
huge price spikes we've seen were not triggered by equally large spikes in
usage - it's speculation on that future.
I quite
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 05:04 PM, Jeff Garzik wrote:
heh - I tend to think people here want bitcoin to succeed. My
statement refers to picking winners and losers from within the
existing bitcoin community stakeholders.
Success is not a sufficiently
On Thu, May 7, 2015 at 11:12 AM, Mike Hearn m...@plan99.net wrote:
That's why I conclude the opposite - if there is no fork, then people's
confidence in Bitcoin will be seriously damaged.
Yes, that is a possibility.
If it's impossible to do something as trivial as removing a temporary
On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier justusranv...@riseup.net
wrote:
To be extremely specific: should Bitcoin development intenionally
limit the network's capabilities to leave room for other projects, or
should Bitcoin attempt to be the best system possible and let the
other
Dear list,
Apparently my emails are being marked as spam, despite being sent from
GMail's web interface. I've pinged our sysadmin. Thanks for letting
me know.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
On Thu, May 7, 2015 at 3:05 PM, Mike Hearn m...@plan99.net wrote:
Maybe you dislike that idea. It's so centralised. So let's say Gavin
commits his patch, because his authority is equal to all other committers.
Someone else rolls it back. Gavin sets up a cron job to keep committing the
On Thu, May 7, 2015 at 11:33 AM, Justus Ranvier justusranv...@riseup.net
wrote:
In summary, I asked a question neither you, nor Peter Todd, want to
answer and want to actively discourage people from even asking at all.
Incorrect; your question included built-in assumptions with which I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 05:47 PM, Jeff Garzik wrote:
Bitcoin needs to be the best it can be (Layer 1), but all solutions
cannot and should not be implemented at Layer 1.
I can provisionally agree with that statement as long as all
solutions cannot and should
In my personal opinion, this does make some sense to me, assuming I
understood Gavin.
I suppose it could be done with a new flag (like the P2SH flag) which
displays miner support for larger blocks. The new rules would apply when
a large majority of miners support the new rules by counting the
It is an argument against my admittedly vague definition of
non-controversial change.
If it's an argument against something you said, it's not a straw man, right
;)
Consensus has to be defined as agreement between a group of people. Who are
those people? If you don't know, it's impossible to
Dear list,
Apparently my emails are being marked as spam, despite being sent from
GMail's web interface. I've pinged our sysadmin.
It's a problem with the mailing list software, not your setup. BitPay could
disable the phishing protections but that seems like a poor solution. The
only real
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 03:35 PM, Jeff Garzik wrote:
Raising the block size limit then becomes a *human decision* to
favor some users over others, a *human decision* to prevent an
active and competitive free fee market developing at 1MB, a *human
decision*
On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen gavinandre...@gmail.com wrote:
I would very much like to find some concrete course of action that we can
come to consensus on. Some compromise so we can tell entrepreneurs THIS is
how much transaction volume the main Bitcoin blockchain will be able
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 04:04 PM, Jeff Garzik wrote:
- This is a major change to the economics of a $3.2B system. This
change picks winners and losers. There is attendant moral hazard.
This is exactly true.
There are a number of projects which aren't
On Thu, May 7, 2015 at 10:38 AM, Justus Ranvier justusranv...@riseup.net
wrote:
On 05/07/2015 04:04 PM, Jeff Garzik wrote:
- This is a major change to the economics of a $3.2B system. This
change picks winners and losers. There is attendant moral hazard.
This is exactly true.
There are
On Thu, May 07, 2015 at 05:13:34PM +0200, Justus Ranvier wrote:
On 05/07/2015 04:49 PM, Peter Todd wrote:
I think we'll find an basic assumption of civility to be more
productive, until proven otherwise. (e.g. NSA ties)
I'm not sure why you'd construe my post as having anything to do
100% agree, RE hard forks should be hard.
However, it is the paradox of growth, morale and adoption that bitcoin
might never reach the point where it is saturated expensive to the point
where larger blocks are demanded by 95%+... simply because people and
companies chose not to adopt bitcoin in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 04:49 PM, Peter Todd wrote:
I think we'll find an basic assumption of civility to be more
productive, until proven otherwise. (e.g. NSA ties)
I'm not sure why you'd construe my post as having anything to do with
accusations like
It is a trivial *code* change. It is not a trivial change to the
economics of a $3.2B system.
Hmm - again I'd argue the opposite.
Up until now Bitcoin has been unconstrained by the hard block size limit.
If we raise it, Bitcoin will continue to be unconstrained by it. That's the
default
On Thu, May 07, 2015 at 10:04:21AM -0400, Jeff Garzik wrote:
I have a lot more written down, a WIP; here are the highlights.
- The 1MB limit is an ancient anti-spam limit, and needs to go.
- The 1MB limit is economically entrenched at this point, and cannot be
removed at a whim.
- This
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote:
One thing is the Bitcoin core project where you could argue that the 5
committers decide (I don't know why Wladimir would have any more
authority than the others).
Because he is formally the maintainer.
I quite liked
On Thu, May 07, 2015 at 04:38:22PM +0200, Justus Ranvier wrote:
On 05/07/2015 04:04 PM, Jeff Garzik wrote:
- This is a major change to the economics of a $3.2B system. This
change picks winners and losers. There is attendant moral hazard.
This is exactly true.
There are a number of
For reference: the blog post that (re)-started this debate, and which links
to individual issues, is here:
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
In it, I asked people to email me objections I might have missed. I would
still appreciate it if people do that; it is impossible
On Thu, May 07, 2015 at 10:52:54AM -0400, Gavin Andresen wrote:
I AM considering contributing some version of the bigger blocksize-limit
hard-fork patch to the Bitcoin-Xt fork (probably target a hobbyist with a
fast Internet connection, and assume Nelson's law to increase over time),
and then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 03:27 PM, Jeff Garzik wrote:
On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier
justusranv...@riseup.net wrote:
To be extremely specific: should Bitcoin development
intenionally limit the network's capabilities to leave room for
If the worry about raising the block size will increase centralization,
could not one could imagine an application which rewarded decentralized
storage of block data? It could even be build aside or on top of the
existing bitcoin protocol.
See the Permacoin paper by Andrew Miller:
One thing to add is that perhaps in a future version of Bitcoin Core,
there could be an option for users to continue using the old consensus
rules, or an option to support the new rules (an option when they update
and an ability to change in the settings). Both types of user can
benefit from the
On Thu, May 7, 2015 at 6:11 PM, Mike Hearn m...@plan99.net wrote:
It is an argument against my admittedly vague definition of
non-controversial change.
If it's an argument against something you said, it's not a straw man, right
;)
Yes, but it was an argument against something I didn't said
Fee dynamics seems to come up over and over again in these discussions,
with lots of talk and theorizing.
I hope some data on what is happening with fees right now might help, so I
wrote another blog post (with graphs, which can't be done in a mailing list
post):
On Wed, May 06, 2015 at 10:12:14PM +, Matt Corallo wrote:
Personally, I'm rather strongly against any commitment to a block size
increase in the near future. Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very
On 7 May 2015, at 11:52, Jorge Timón jti...@jtimon.cc wrote:
On Thu, May 7, 2015 at 11:25 AM, Mike Hearn m...@plan99.net wrote:
I observed to Wladimir and Gavin in private that this timeline meant a
change to the block size was unlikely to get into 0.11, leaving only 0.12,
which would
On May 7, 2015, at 4:20 AM, Wladimir J. van der Laan laa...@gmail.com wrote:
For sake of brevity, this ignores the inherent practical and political issues
in scheduling a hardfork.
IMHO, these issues are the elephant in the room and the talk of block size
increases is just a distraction.
On Thu, May 07, 2015 at 01:29:44PM +0200, Mike Hearn wrote:
What if Gavin popped up right now and said he disagreed with every current
proposal, he disagreed with side chains too, and there would be no
consensus on any of them until the block size limit was raised.
Would you say, oh, OK,
On Thu, May 07, 2015 at 11:05:47AM +0930, Rusty Russell wrote:
Peter Todd p...@petertodd.org writes:
That said, if people have strong feelings about this, I would be willing
to make OP_CLTV work as follows:
nLockTime 1 OP_CLTV
Where the 1 selects absolute mode, and all others act
Peter Todd p...@petertodd.org writes:
That said, if people have strong feelings about this, I would be willing
to make OP_CLTV work as follows:
nLockTime 1 OP_CLTV
Where the 1 selects absolute mode, and all others act as OP_NOP's. A
future relative CLTV could then be a future soft-fork
On 05/07/15 14:52, Gavin Andresen wrote:
For reference: the blog post that (re)-started this debate, and which
links to individual issues, is here:
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
In it, I asked people to email me objections I might have missed. I
would still
On Thu, May 07, 2015 at 06:21:50PM +0200, Jorge Timón wrote:
On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
I would very much like to find some concrete course of action that we can
come to consensus on. Some compromise so we can tell entrepreneurs THIS is
93 matches
Mail list logo
