public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Raystonn ." <raystonn@hotmail.com>
To: "Gavin Andresen" <gavinandresen@gmail.com>,
	"Mike Hearn" <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
Date: Thu, 28 May 2015 10:39:29 -0700	[thread overview]
Message-ID: <COL131-DS24FC87C7C6622E23F5EF58CDCA0@phx.gbl> (raw)
In-Reply-To: <CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

I agree that developers should avoid imposing economic policy.  It is dangerous for Bitcoin and the core developers themselves to become such a central point of attack for those wishing to disrupt Bitcoin.  My opinion is these things are better left to a decentralized free market anyhow.


From: Gavin Andresen 
Sent: Thursday, May 28, 2015 10:19 AM
To: Mike Hearn 
Cc: Bitcoin Dev 
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

On Thu, May 28, 2015 at 1:05 PM, Mike Hearn <mike@plan99.net> wrote:

    Isn't that a step backwards, then? I see no reason for fee pressure to exist at the moment. All it's doing is turning away users for no purpose: mining isn't supported by fees, and the tiny fees we use right now seem to be good enough to stop penny flooding.


  Why not set the max size to be 20x the average size? Why 2x, given you just pointed out that'd result in blocks shrinking rather than growing.

Twenty is scary.

And two is a very neutral number: if 50% of hashpower want the max size to grow as fast as possible and 50% are dead-set opposed to any increase in max size, then half produce blocks 2 times as big, half produce empty blocks, and the max size doesn't change. If it was 20, then a small minority of miners could force a max size increase.  (if it is less than 2, then a minority of minors can force the block size down)


As for whether there "should" be fee pressure now or not: I have no opinion, besides "we should make block propagation faster so there is no technical reason for miners to produce tiny blocks." I don't think us developers should be deciding things like whether or not fees are too high, too low, .....

-- 

--
Gavin Andresen



--------------------------------------------------------------------------------
------------------------------------------------------------------------------



--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 3947 bytes --]

  parent reply	other threads:[~2015-05-28 17:40 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-08  7:20 [Bitcoin-development] Proposed alternatives to the 20MB step function Matt Whitlock
2015-05-08 10:15 ` Mike Hearn
2015-05-08 10:30 ` Clément Elbaz
2015-05-08 12:32   ` Joel Joonatan Kaartinen
2015-05-08 12:48     ` Matt Whitlock
2015-05-08 13:24       ` Matt Whitlock
2015-05-08 12:48     ` Gavin Andresen
2015-05-08 16:51     ` Peter Todd
2015-05-08 22:36       ` Joel Joonatan Kaartinen
2015-05-09 18:30         ` Peter Todd
2015-05-08 15:57 ` Alex Mizrahi
2015-05-08 16:55 ` Bryan Bishop
2015-05-08 20:33 ` Mark Friedenbach
2015-05-08 22:43   ` Aaron Voisine
2015-05-08 22:45     ` Mark Friedenbach
2015-05-08 23:15       ` Aaron Voisine
2015-05-08 23:58         ` Mark Friedenbach
2015-05-09  3:36   ` Gregory Maxwell
2015-05-09 11:58     ` Gavin Andresen
2015-05-09 13:49       ` Tier Nolan
2015-05-10 17:36     ` Owen Gunden
2015-05-10 18:10       ` Mark Friedenbach
2015-05-10 21:21     ` Gavin Andresen
2015-05-10 21:33       ` Gregory Maxwell
2015-05-10 21:56       ` Rob Golding
2015-05-13 10:43     ` Tier Nolan
2015-05-16  0:22       ` Rusty Russell
2015-05-16 11:09         ` Tier Nolan
2015-05-18  1:42           ` Rusty Russell
2015-05-19  8:59             ` Tier Nolan
2015-05-10 21:48   ` Thomas Voegtlin
2015-05-10 22:31     ` Mark Friedenbach
2015-05-10 23:11       ` Thomas Voegtlin
2015-05-28 15:53 ` Gavin Andresen
2015-05-28 17:05   ` Mike Hearn
2015-05-28 17:19     ` Gavin Andresen
2015-05-28 17:34       ` Mike Hearn
2015-05-28 18:23         ` Gavin Andresen
2015-05-29 11:26           ` Mike Hearn
2015-05-29 11:42             ` Tier Nolan
2015-05-29 11:57               ` Mike Hearn
2015-05-29 12:39                 ` Gavin Andresen
2015-05-29 14:00                   ` insecurity
2015-05-29 14:15                     ` Braun Brelin
2015-05-29 14:09                   ` Tier Nolan
2015-05-29 14:20                     ` Gavin Andresen
2015-05-29 14:22                       ` Mike Hearn
2015-05-29 14:21                     ` Mike Hearn
2015-05-29 14:22                     ` Tier Nolan
2015-05-29 16:39                       ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Raystonn .
2015-05-29 18:28                         ` Tier Nolan
2015-05-29 17:53                   ` [Bitcoin-development] Proposed alternatives to the 20MB step function Admin Istrator
2015-05-30  9:03                     ` Aaron Voisine
2015-06-01 11:30                       ` Ricardo Filipe
2015-06-01 11:46                         ` Marcel Jamin
2015-05-29 18:47                   ` Bryan Cheng
2015-05-30  1:36                     ` Cameron Garnham
2015-05-28 17:39       ` Raystonn . [this message]
2015-05-28 17:59         ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Pieter Wuille
2015-05-28 18:21           ` Gavin Andresen
2015-05-28 17:50       ` [Bitcoin-development] Proposed alternatives to the 20MB step function Peter Todd
2015-05-28 17:14   ` Thomas Voegtlin
2015-05-28 17:34   ` Pieter Wuille
2015-05-29 17:45   ` Aaron Voisine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=COL131-DS24FC87C7C6622E23F5EF58CDCA0@phx.gbl \
    --to=raystonn@hotmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gavinandresen@gmail.com \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox