public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ryan J Martin <rjmarti2@millersville.edu>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP
Date: Fri, 10 Feb 2017 04:10:15 +0000	[thread overview]
Message-ID: <127281C1AA02374F8AAD9EE04FAE878A02154E80BD@STUDMail1.muad.local> (raw)

"10% say literally never.  That seems like a significant disenfranchisement
and lack of consensus."

Certainly the poll results should be taken with a grain of salt and not a definitive answer or measure . 
However if we agree the poll has some worth (or even if not, then lets use it as hyptothetical): If we split it into two groups: those okay with a hardfork at some point > now, and those never okay with hardfork, that means there is 90% that agree a hardfork is acceptable in the future. That said, what threshold defines consensus then? 98%? 100%?       
 
Personally I think pursuing paths that maximize net social benefit in terms of cost surplus/burden is the best way to go since consensus is such an impossible to define, variable, case-by-case thing that doesn't always lead to the best choice.

-Ryan J. MArtin
 

________________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org [bitcoin-dev-bounces@lists.linuxfoundation.org] on behalf of bitcoin-dev-request@lists.linuxfoundation.org [bitcoin-dev-request@lists.linuxfoundation.org]
Sent: Thursday, February 09, 2017 7:00 AM
To: bitcoin-dev@lists.linuxfoundation.org
Subject: bitcoin-dev Digest, Vol 21, Issue 10

Send bitcoin-dev mailing list submissions to
        bitcoin-dev@lists.linuxfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
        bitcoin-dev-request@lists.linuxfoundation.org

You can reach the person managing the list at
        bitcoin-dev-owner@lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."


Today's Topics:

   1. Re: A Modified Version of Luke-jr's Block Size BIP (alp alp)


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

Message: 1
Date: Wed, 8 Feb 2017 08:44:52 -0600
From: alp alp <alp.bitcoin@gmail.com>
To: "t. khan" <teekhan42@gmail.com>,    Bitcoin Protocol Discussion
        <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size
        BIP
Message-ID:
        <CAMBsKS9OS2tA4bG-JG96XNZTiPyuq322Qu=fyJcZ1BtVj3TtxQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

10% say literally never.  That seems like a significant disenfranchisement
and lack of consensus.

On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170208/18d9cda5/attachment-0001.html>

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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


End of bitcoin-dev Digest, Vol 21, Issue 10
*******************************************


             reply	other threads:[~2017-02-10  4:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-10  4:10 Ryan J Martin [this message]
  -- strict thread matches above, loose matches on Subject: below --
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
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

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=127281C1AA02374F8AAD9EE04FAE878A02154E80BD@STUDMail1.muad.local \
    --to=rjmarti2@millersville.edu \
    --cc=bitcoin-dev@lists.linuxfoundation.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