Andrew Johnson [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-08 📝 Original message:It is when you're talking ...
📅 Original date posted:2017-02-08
📝 Original message:It is when you're talking about making a choice and 6.3x more people prefer
something else. Doing nothing is a choice as well.
Put another way, if 10% supported increasing the 21M coin cap and 63% were
against, would you seriously consider doing it?
On Feb 8, 2017 9:57 AM, "alp alp" <alp.bitcoin at gmail.com> wrote:
> 10% is not a tiny minority.
>
> On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
> wrote:
>
>> You're never going to reach 100% agreement, and stifling the network
>> literally forever to please a tiny minority is daft.
>>
>> On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> 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 at lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at 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/4a68bd99/attachment-0001.html>;
📝 Original message:It is when you're talking about making a choice and 6.3x more people prefer
something else. Doing nothing is a choice as well.
Put another way, if 10% supported increasing the 21M coin cap and 63% were
against, would you seriously consider doing it?
On Feb 8, 2017 9:57 AM, "alp alp" <alp.bitcoin at gmail.com> wrote:
> 10% is not a tiny minority.
>
> On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
> wrote:
>
>> You're never going to reach 100% agreement, and stifling the network
>> literally forever to please a tiny minority is daft.
>>
>> On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> 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 at lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at 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/4a68bd99/attachment-0001.html>;