Eric Lombrozo [ARCHIVE] on Nostr: đź“… Original date posted:2015-07-22 đź“ť Original message:FWIW, I had worked on ...
đź“… Original date posted:2015-07-22
đź“ť Original message:FWIW, I had worked on something similar a while back: https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf <https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/bitcoin.conf>;
I like the idea in principle…but we should require a new genesis block, different magic bytes, and a different network port at the very least. :)
> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
>
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>
> Cory
>
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> If the developers fail to reflect user consensus, the network will let us
>>> know.
>>
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference. If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>>
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I wouldn't go quite that far. The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>>
>> Quoting BC,
>>> Upgrading to a version of Bitcoin Core that is incompatible with your
>>> ideals is in no way a forced choice, as you have stated in your email;
>>> forks, alternative clients, or staying on an older version are all valid
>>> choices. If the majority of the network chooses not to endorse a specific
>>> change, then the majority of the network will continue to operate just fine
>>> without it, and properly structured consensus rules will pull the minority
>>> along as well.
>>
>> The developers propose a new version, by publishing a new release. The
>> individual network nodes choose to accept or reject that.
>>
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>>
>> There are checks-and-balances that make the system work. Consensus is most
>> strongly measured by user actions after software release. If the developers
>> fail to reflect user consensus, the network will let us know.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi Pieter,
>>
>> I think a core area of disagreement is this:
>>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>>
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have the authority to set its rules. This is enforced by the reality of
>> ~100% market share and limited github commit access.
>>
>> You may not like this situation, but it is what it is. By refusing to make a
>> release with different rules, people who disagree are faced with only two
>> options:
>>
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>>
>> There are no alternatives. People who object to (2) are inherently
>> suggesting (1) is the only acceptable path, which not surprisingly, makes a
>> lot of people very angry.
>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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/20150722/81ebd82e/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/81ebd82e/attachment.sig>;
đź“ť Original message:FWIW, I had worked on something similar a while back: https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf <https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/bitcoin.conf>;
I like the idea in principle…but we should require a new genesis block, different magic bytes, and a different network port at the very least. :)
> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
>
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>
> Cory
>
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> If the developers fail to reflect user consensus, the network will let us
>>> know.
>>
>> This is true with the caveat that there must be more than one option present
>> for the network to show it's preference. If developers discourage anything
>> that forks from the rules enforced by Bitcoin Core, they harm the network's
>> ability to inform us of a failure to reflect user consensus.
>>
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I wouldn't go quite that far. The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>>
>> Quoting BC,
>>> Upgrading to a version of Bitcoin Core that is incompatible with your
>>> ideals is in no way a forced choice, as you have stated in your email;
>>> forks, alternative clients, or staying on an older version are all valid
>>> choices. If the majority of the network chooses not to endorse a specific
>>> change, then the majority of the network will continue to operate just fine
>>> without it, and properly structured consensus rules will pull the minority
>>> along as well.
>>
>> The developers propose a new version, by publishing a new release. The
>> individual network nodes choose to accept or reject that.
>>
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>>
>> There are checks-and-balances that make the system work. Consensus is most
>> strongly measured by user actions after software release. If the developers
>> fail to reflect user consensus, the network will let us know.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi Pieter,
>>
>> I think a core area of disagreement is this:
>>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>>
>> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
>> have the authority to set its rules. This is enforced by the reality of
>> ~100% market share and limited github commit access.
>>
>> You may not like this situation, but it is what it is. By refusing to make a
>> release with different rules, people who disagree are faced with only two
>> options:
>>
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>>
>> There are no alternatives. People who object to (2) are inherently
>> suggesting (1) is the only acceptable path, which not surprisingly, makes a
>> lot of people very angry.
>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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/20150722/81ebd82e/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/81ebd82e/attachment.sig>;