* 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
* Re: [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 2017-02-05 23:53 ` Andrew C 2017-02-06 18:19 ` t. khan 0 siblings, 2 replies; 16+ messages in thread From: Luke Dashjr @ 2017-02-05 23:02 UTC (permalink / raw) To: bitcoin-dev, Andrew C My BIP draft didn't make progress because the community opposes any block size increase hardfork ever. Your version doesn't address the current block size issues (ie, the blocks being too large). So you've retained the only certain- DOA parts of my proposal, and removed the most useful part... I'm not sure the point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sense to keep the BIP 9 deployment at all - either it gets consensus or it doesn't, but miners have no part in deployment of it. On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote: > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 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 18:19 ` t. khan 1 sibling, 1 reply; 16+ messages in thread From: Andrew C @ 2017-02-05 23:53 UTC (permalink / raw) To: Luke Dashjr, bitcoin-dev On 2/5/2017 6:02 PM, Luke Dashjr wrote: > My BIP draft didn't make progress because the community opposes any block size > increase hardfork ever. From what I have observed, it seems to be that people are more so opposed to a hard fork when there is a comparable soft fork available than simply opposed to any block size increase hard fork ever. From the various threads discussing your proposal, it seemed that many would favor it if it increased over 1 MB sooner or if it never even decreased in the first place. > Your version doesn't address the current block size > issues (ie, the blocks being too large). Many users are of the opposite opinion, that the block size is too small. I understand that the decrease is to allow the blockchain size to grow more slowly thereby allowing users to be more likely to run full nodes. Unfortunately, I think that we are way past the point of no return on that. The blockchain is already 100+ GB. Decreasing the block size is not going to make that any smaller and is not going to make it any less painful to run a full node. Given that in order to start up a new full node will still require downloading at least 100 GB of data, I don't think that decreasing the block size will better facilitate full node creation. Furthermore, the current trend with ISPs (at least in the US) is implementing data and bandwidth caps so users are still unlikely to start up new full nodes regardless of any changes that we can currently do. > So you've retained the only certain- > DOA parts of my proposal, and removed the most useful part... I'm not sure the > point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sense > to keep the BIP 9 deployment at all - either it gets consensus or it doesn't, > but miners have no part in deployment of it. Yes, I know deployment needs to be fixed. I was more proposing this for comment on the modified block size schedule. I just kept the deployment as it was originally. However, we could use a modified version of BIP 9 by using one of the top three bits and a longer locked-in period as a grace period for all users to upgrade. > > On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote: >> 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 >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <C5621135-FBC8-44E7-9EC0-AFDEEBB6031E@thomaslerin.io>]
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP [not found] ` <C5621135-FBC8-44E7-9EC0-AFDEEBB6031E@thomaslerin.io> @ 2017-02-06 21:00 ` Andrew C 0 siblings, 0 replies; 16+ messages in thread From: Andrew C @ 2017-02-06 21:00 UTC (permalink / raw) To: Thomas Kerin, bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 5724 bytes --] I looked at the discussions about the block size and about Luke-Jr's proposal on Reddit and Bitcointalk. From what I observed of all of the discussions is that few users are in favor of the status quo, and even fewer are in favor of decreasing the block size. The majority of users favored Segwit because it was a block size increase (that was a commonly used reason in support of it and in arguments about increasing the block size). Discussions about Luke-Jr's proposal indicated that many users disagreed with the decrease in block size and the time that it took to increase again to 1 MB. There was not only disagreement but explicit ridicule and mocking of that aspect of the proposal. On 2/6/2017 3:28 PM, Thomas Kerin wrote: > "Many users are of the opposite opinion, that the block size is too > small." - That is newspeak, the users can speak for themselves. > > From whom did you gather feedback from before you changed Luke-Jrs BIP? > > If people don't agree with the proposal, changing it an infinite > number of times light well lead to the same result. > > Have the users spoken, in their response to what Luke-Jr proposed? > > On 6 February 2017 00:53:03 CET, Andrew C via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > On 2/5/2017 6:02 PM, Luke Dashjr wrote: > > My BIP draft didn't make progress because the community > opposes any block size increase hardfork ever. > > From what I have observed, it seems to be that people are more so > opposed to a hard fork when there is a comparable soft fork available > than simply opposed to any block size increase hard fork ever. From the > various threads discussing your proposal, it seemed that many would > favor it if it increased over 1 MB sooner or if it never even decreased > in the first place. > > Your version doesn't address the current block size issues > (ie, the blocks being too large). > > Many users are of the opposite opinion, that the block size is too > small. I understand that the decrease is to allow the blockchain size to > grow more slowly thereby allowing users to be more likely to run full > nodes. Unfortunately, I think that we are way past the point of no > return on that. The blockchain is already 100+ GB. Decreasing the block > size is not going to make that any smaller and is not going to make it > any less painful to run a full node. Given that in order to start up a > new full node will still require downloading at least 100 GB of data, I > don't think that decreasing the block size will better facilitate full > node creation. Furthermore, the current trend with ISPs (at least in the > US) is implementing data and bandwidth caps so users are still unlikely > to start up new full nodes regardless of any changes that we can > currently do. > > So you've retained the only certain- DOA parts of my proposal, > and removed the most useful part... I'm not sure the point. > Also, your version is now EXCLUSIVELY a hardfork, so it makes > no sense to keep the BIP 9 deployment at all - either it gets > consensus or it doesn't, but miners have no part in deployment > of it. > > Yes, I know deployment needs to be fixed. I was more proposing this for > comment on the modified block size schedule. I just kept the deployment > as it was originally. However, we could use a modified version of BIP 9 > by using one of the top three bits and a longer locked-in period as a > grace period for all users to upgrade. > > On Sunday, February 05, 2017 9:50:26 PM Andrew C via > bitcoin-dev wrote: > > 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 > ------------------------------------------------------------------------ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > ------------------------------------------------------------------------ > > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. [-- Attachment #2: Type: text/html, Size: 6967 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 2017-02-05 23:02 ` Luke Dashjr 2017-02-05 23:53 ` Andrew C @ 2017-02-06 18:19 ` t. khan [not found] ` <201702061953.40774.luke@dashjr.org> 1 sibling, 1 reply; 16+ messages in thread From: t. khan @ 2017-02-06 18:19 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2730 bytes --] >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? >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. - t.k. On Sun, Feb 5, 2017 at 6:02 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > My BIP draft didn't make progress because the community opposes any block > size > increase hardfork ever. Your version doesn't address the current block size > issues (ie, the blocks being too large). So you've retained the only > certain- > DOA parts of my proposal, and removed the most useful part... I'm not sure > the > point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no > sense > to keep the BIP 9 deployment at all - either it gets consensus or it > doesn't, > but miners have no part in deployment of it. > > On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote: > > 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 > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 4235 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <201702061953.40774.luke@dashjr.org>]
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP [not found] ` <201702061953.40774.luke@dashjr.org> @ 2017-02-06 20:25 ` t. khan 2017-02-08 14:44 ` alp alp 0 siblings, 1 reply; 16+ messages in thread From: t. khan @ 2017-02-06 20:25 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 2017-02-06 20:25 ` t. khan @ 2017-02-08 14:44 ` alp alp 2017-02-08 15:51 ` Andrew Johnson 0 siblings, 1 reply; 16+ messages in thread From: alp alp @ 2017-02-08 14:44 UTC (permalink / raw) To: t. khan, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1859 bytes --] 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 > > [-- Attachment #2: Type: text/html, Size: 3567 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 2017-02-08 14:44 ` alp alp @ 2017-02-08 15:51 ` Andrew Johnson 2017-02-08 15:57 ` alp alp 0 siblings, 1 reply; 16+ messages in thread From: Andrew Johnson @ 2017-02-08 15:51 UTC (permalink / raw) To: alp alp, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2256 bytes --] 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@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@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 > > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists•linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 4648 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 2017-02-08 15:51 ` Andrew Johnson @ 2017-02-08 15:57 ` alp alp 2017-02-08 16:28 ` Andrew Johnson 0 siblings, 1 reply; 16+ messages in thread From: alp alp @ 2017-02-08 15:57 UTC (permalink / raw) To: Andrew Johnson; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2458 bytes --] 10% is not a tiny minority. On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83@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@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@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 >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > [-- Attachment #2: Type: text/html, Size: 5234 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 2017-02-08 15:57 ` alp alp @ 2017-02-08 16:28 ` Andrew Johnson 2017-02-08 18:16 ` alp alp 0 siblings, 1 reply; 16+ messages in thread From: Andrew Johnson @ 2017-02-08 16:28 UTC (permalink / raw) To: alp alp; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2858 bytes --] 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@gmail•com> wrote: > 10% is not a tiny minority. > > On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83@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@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@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 >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> [-- Attachment #2: Type: text/html, Size: 6055 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 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 0 siblings, 2 replies; 16+ messages in thread From: alp alp @ 2017-02-08 18:16 UTC (permalink / raw) To: Andrew Johnson; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3186 bytes --] 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@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@gmail•com> wrote: > 10% is not a tiny minority. > > On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83@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@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@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 >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> [-- Attachment #2: Type: text/html, Size: 6887 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 2017-02-08 18:16 ` alp alp @ 2017-02-08 19:53 ` t. khan 2017-02-08 19:56 ` Andrew Johnson 1 sibling, 0 replies; 16+ messages in thread From: t. khan @ 2017-02-08 19:53 UTC (permalink / raw) To: alp alp; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3693 bytes --] Even ignoring the obvious flaws of that poll, Andrew is still correct: you cannot reach 100% consensus. It's statistically impossible in any large group. Only the majority needs to consent, though what is considered a majority varies depending on the context (95%, 75%, 51%). Nowhere does it say "everyone needs to agree". On Wed, Feb 8, 2017 at 1:16 PM, alp alp <alp.bitcoin@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@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@gmail•com> wrote: > >> 10% is not a tiny minority. >> >> On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83@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@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@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 >>>> >>>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> > [-- Attachment #2: Type: text/html, Size: 7865 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 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 1 sibling, 1 reply; 16+ messages in thread From: Andrew Johnson @ 2017-02-08 19:56 UTC (permalink / raw) To: alp alp; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4332 bytes --] 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@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@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@gmail•com> wrote: > 10% is not a tiny minority. > > On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83@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@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@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 >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> [-- Attachment #2: Type: text/html, Size: 8759 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 2017-02-08 19:56 ` Andrew Johnson @ 2017-02-08 20:13 ` alp alp 2017-02-10 10:33 ` Btc Drak 0 siblings, 1 reply; 16+ messages in thread From: alp alp @ 2017-02-08 20:13 UTC (permalink / raw) To: Andrew Johnson; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 6127 bytes --] >Only the majority needs to consent, though what is considered a majority varies depending on the context (95%, 75%, 51%). Nowhere does it say "everyone needs to agree". There's a pretty huge gap between 90% and nearly 100%. 90% excluding 10% only 7 times results in only 48% of the original base. >If a small dissenting minority can block all forward progress then bitcoin is no longer interesting. Your definition of forward may be different than other users. >Is that really the bitcoin that you want to be a part of? Yes, I chose Bitcoin because it relies on a strictly held consensus mechanism and not one that changes on the whims of the majority. We have tens of dozens of political currencies for that. >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). The community has not agreed that it is needed at this time. Perhaps they will change their mind at some point in the future. We have also learned a great deal since the publication of the initial whitepaper, such as the unstable state without a backlog or subsidy. Fortunately, participation in this system is voluntary, and you are free to leave at any time. This seems to be venturing quite off topic, and perhaps would be better suited for the bitcoin-discuss list. On Wed, Feb 8, 2017 at 1:56 PM, Andrew Johnson <andrew.johnson83@gmail•com> wrote: > 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@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@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@gmail•com> wrote: > >> 10% is not a tiny minority. >> >> On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83@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@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@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 >>>> >>>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> > > [-- Attachment #2: Type: text/html, Size: 11860 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP 2017-02-08 20:13 ` alp alp @ 2017-02-10 10:33 ` Btc Drak 0 siblings, 0 replies; 16+ messages in thread From: Btc Drak @ 2017-02-10 10:33 UTC (permalink / raw) To: alp alp, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7434 bytes --] Agreed, this thread is venturing somewhat out of scope for the list. Please can we redirect philosophical discussion to another forum/list such as bitcoin-discuss, which can be found at https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss Repost of the bitcoin-dev posting guidelines are: - Posts must concern development of bitcoin protocol. - Posts should be technical or academic in nature. - Generally encouraged: patches, notification of pull requests, BIP proposals, academic paper announcements. And discussions that follow. - Generally discouraged: shower thoughts, wild speculation, jokes, +1s, non-technical bitcoin issues, rehashing settled topics without new data, moderation concerns. - Detailed patch discussion generally better on a GitHub PR. - Meta-discussion is better on bitcoin-discuss. On Wed, Feb 8, 2017 at 8:13 PM, alp alp via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > >Only the majority needs to consent, though what is considered a majority > varies depending on the context (95%, 75%, 51%). Nowhere does it say > "everyone needs to agree". > > There's a pretty huge gap between 90% and nearly 100%. 90% excluding 10% > only 7 times results in only 48% of the original base. > > >If a small dissenting minority can block all forward progress then > bitcoin is no longer interesting. > > Your definition of forward may be different than other users. > > >Is that really the bitcoin that you want to be a part of? > > Yes, I chose Bitcoin because it relies on a strictly held consensus > mechanism and not one that changes on the whims of the majority. We have > tens of dozens of political currencies for that. > > >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). > > The community has not agreed that it is needed at this time. Perhaps they > will change their mind at some point in the future. We have also learned a > great deal since the publication of the initial whitepaper, such as the > unstable state without a backlog or subsidy. Fortunately, participation in > this system is voluntary, and you are free to leave at any time. > > This seems to be venturing quite off topic, and perhaps would be better > suited for the bitcoin-discuss list. > > On Wed, Feb 8, 2017 at 1:56 PM, Andrew Johnson <andrew.johnson83@gmail•com > > wrote: > >> 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@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@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@gmail•com> wrote: >> >>> 10% is not a tiny minority. >>> >>> On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83@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@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@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 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists•linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>> >>>> >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 14053 bytes --] ^ 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