public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP
@ 2017-02-10  4:10 Ryan J Martin
  0 siblings, 0 replies; 16+ messages in thread
From: Ryan J Martin @ 2017-02-10  4:10 UTC (permalink / raw)
  To: bitcoin-dev

"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
*******************************************


^ permalink raw reply	[flat|nested] 16+ messages in thread
* [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP
@ 2017-02-05 21:50 Andrew C
  2017-02-05 23:02 ` Luke Dashjr
  0 siblings, 1 reply; 16+ messages in thread
From: Andrew C @ 2017-02-05 21:50 UTC (permalink / raw)
  To: bitcoin-dev

Hello all,

Many people have expressed discontent with Luke-jr's proposed block size
BIP, in particular with the decrease in size that would occur if it were
to be activated prior to 2024.

I have decided to modify the proposal to instead begin the increase
steps at the current 1000000 byte limit. The increases and the time spam
of each increase will remain the same, just that the increase begins
from 1000000 bytes instead of 300000 bytes.

Furthermore, instead of a fixed schedule from a fixed point in time, the
increases will instead be calculated off of the MTP of the activation
block (the first block to be in the active state for this fork).

While this proposal shares many of the same issues with the one it
modifies, I hope that it will be slightly less controversial and can
allow us to move forward with scaling Bitcoin.

The full text of the proposal can be found at
https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.
My implementation of it is available at
https://github.com/achow101/bitcoin/tree/bip-blksize


Andrew



^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2017-02-10 10:34 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-10  4:10 [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP Ryan J Martin
  -- strict thread matches above, loose matches on Subject: below --
2017-02-05 21:50 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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox