public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "t. khan" <teekhan42@gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP
Date: Mon, 6 Feb 2017 15:25:13 -0500	[thread overview]
Message-ID: <CAGCNRJo3zM2kYePPw-=JpMQWtn_M1Eg=SpShC_z-d-_Nv6KqcQ@mail.gmail.com> (raw)
In-Reply-To: <201702061953.40774.luke@dashjr.org>

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

On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke@dashjr.org> wrote:

> On Monday, February 06, 2017 6:19:43 PM you wrote:
> > >My BIP draft didn't make progress because the community opposes any
> block
> > >size increase hardfork ever.
> >
> > Luke, how do you know the community opposes that? Specifically, how did
> you
> > come to this conclusion?
>
> http://www.strawpoll.me/12228388/r


That poll shows 63% of votes want a larger than 1 MB block by this summer.
How do you go from that to "the community opposes any block increase ever"?
It shows the exact opposite of that.


> > >Your version doesn't address the current block size
> > >issues (ie, the blocks being too large).
> >
> > Why do you think blocks are "too large"? Please cite some evidence. I've
> > asked this before and you ignored it, but an answer would be helpful to
> the
> > discussion.
>
> Full node count is far below the safe minimum of 85% of economic activity.
>

Is this causing a problem now? If so, what?


> Typically reasons given for people not using full nodes themselves come
> down
> to the high resource requirements caused by the block size.


The reason people stop running nodes is because there's no incentive to
counteract the resource costs. Attempting to solve this by making blocks
*smaller* is like curing a disease by killing the patient. (Incentivizing
full node operation would fix that problem.)

- t.k.

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

  parent reply	other threads:[~2017-02-06 20:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-05 21:50 [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP Andrew C
2017-02-05 23:02 ` Luke Dashjr
2017-02-05 23:53   ` Andrew C
     [not found]     ` <C5621135-FBC8-44E7-9EC0-AFDEEBB6031E@thomaslerin.io>
2017-02-06 21:00       ` Andrew C
2017-02-06 18:19   ` t. khan
     [not found]     ` <201702061953.40774.luke@dashjr.org>
2017-02-06 20:25       ` t. khan [this message]
2017-02-08 14:44         ` alp alp
2017-02-08 15:51           ` Andrew Johnson
2017-02-08 15:57             ` alp alp
2017-02-08 16:28               ` Andrew Johnson
2017-02-08 18:16                 ` alp alp
2017-02-08 19:53                   ` t. khan
2017-02-08 19:56                   ` Andrew Johnson
2017-02-08 20:13                     ` alp alp
2017-02-10 10:33                       ` Btc Drak
2017-02-10  4:10 Ryan J Martin

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='CAGCNRJo3zM2kYePPw-=JpMQWtn_M1Eg=SpShC_z-d-_Nv6KqcQ@mail.gmail.com' \
    --to=teekhan42@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.org \
    /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