What is Nostr?
Andrew Johnson [ARCHIVE] /
npub1lf5…uul6
2023-06-07 17:56:06
in reply to nevent1q…w8j8

Andrew Johnson [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-08 📝 Original message:If a small dissenting ...

📅 Original date posted:2017-02-08
📝 Original message:If a small dissenting minority can block all forward progress then bitcoin
is no longer interesting. What an incredibly simple attack vector...

No need to break any cryptography, find a bug to exploit, build tens of
millions of dollars in mining hardware, spend lots of bitcoin on fees to
flood the network, or be clever or expend any valuable resources in any
way, shape, or form.

Just convince(or pay, if you do want to expend some resources) a few
people(or make up a few online personas) to staunchly refuse to accept
anything at all and the entire system is stuck in 2013(when we first
started widely discussing a blocksize increase seriously).

Is that really the bitcoin that you want to be a part of?

When the 1MB cap was implemented it was stated specifically that we could
increase it when we needed it. The white paper even talks about scaling to
huge capacity. Not sure where you got the idea that we all agreed to stay
at 1MB forever, I certainly didn't. It was never stated or implied that we
could change the coin cap later(please cite if I'm mistaken).


On Feb 8, 2017 12:16 PM, "alp alp" <alp.bitcoin at gmail.com> wrote:

Doing nothing is the rules we all agreed to. If those rules are to be
changed,nearly everyone will need to consent. The same rule applies to the
cap, we all agreed to 21m, and if someone wants to change that, nearly
everyone would need to agree.


On Feb 8, 2017 10:28 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
wrote:

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/eb653e44/attachment-0001.html>;
Author Public Key
npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6