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 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
On Wed, May 6, 2015 at 11:12 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
Personally, I'm rather strongly against any commitment to a block size
increase in the near future.
Miners can already soft-fork to reduce the maximum block size. If 51% of
miners agree to a 250kB block size, then
For now, lets leave the discussion to JUST the block size increase. If
it helps - everyone should assume that their pet feature is included in
a hard fork or, if you prefer, that no other features are included in a
hard fork.
On 05/06/15 23:11, Matt Whitlock wrote:
I'm not so much opposed to a
Replies inline.
On 05/06/15 22:44, Tier Nolan wrote:
On Wed, May 6, 2015 at 11:12 PM, Matt Corallo bitcoin-l...@bluematt.me
mailto:bitcoin-l...@bluematt.me wrote:
Personally, I'm rather strongly against any commitment to a block size
increase in the near future.
-snip-
The question
On Wed, May 6, 2015 at 5:12 PM, Matt Corallo bitcoin-l...@bluematt.me wrote:
the maximum block size. However, there hasnt been any discussion on this
mailing list in several years as far as I can tell.
Well, there has been significant public discussion in #bitcoin-wizards
on irc.freenode.net
On 5/6/2015 3:12 PM, Matt Corallo wrote:
Long-term incentive compatibility requires
that there be some fee pressure, and that blocks be relatively
consistently full or very nearly full.
I think it's way too early to even consider a future era when the fiat
value of the block reward is no
I don’t really have a strong opinion on block size either…but if we’re going to
do a hard fork, let’s use this as an opportunity to create a good process for
hard forks (which we’ll inevitably need to do again in the future). The change
in block size is a very simple change that still allows us
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
The point of the hard block size limit is exactly because giving miners
free rule to do anything they like with their blocks would allow them to
do any number of crazy attacks. The incentives for miners to pick block
I don't have strong opinion @ block size topic.
But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (
https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All
developers of lightweight (blockchain-less) clients will adore you!
slush
On Thu, May 7, 2015 at 12:12
I'm not so much opposed to a block size increase as I am opposed to a hard
fork. My problem with a hard fork is that everyone and their brother wants to
seize the opportunity of a hard fork to insert their own pet feature, and such
a mad rush of lightly considered, obscure feature additions
On Wed, May 06, 2015 at 11:41:37PM +, Matt Corallo wrote:
Yes, but this does NOT make an actual policy. Note that the vast
majority of miners already apply their own patches to Bitcoin Core, so
applying one more is not all that hard. When blocks start to become
limited (ie there is any fee
On Wed, May 6, 2015 at 10:12 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote: Recently there has been a flurry of posts by Gavin at
http://gavinandresen.svbtle.com/ which advocate strongly for increasing
the maximum block size. However, there hasnt been any discussion on this
mailing list in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2015 03:49 AM, Peter Todd wrote:
I'm not sure if you've seen this, but a good paper on this topic
was published recently: The Economics of Bitcoin Transaction
Fees
..for some very strange definitions of good.
That paper may present valid
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 Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me
wrote:
Recently there has been a flurry of posts by Gavin at
http://gavinandresen.svbtle.com/ which advocate strongly for increasing
the maximum block size. However, there hasnt been any discussion on this
mailing list in
101 - 129 of 129 matches
Mail list logo
