đź“… Original date posted:2015-07-22
đź“ť Original message:> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists at coryfields.com> wrote:
>
> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>> FWIW, I had worked on something similar a while back:
>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>
>> 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. :)
>>
>
> Not sure if serious, so I'll assume you are :)
Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.
> Why? The idea in this case would be to allow the user to decide
> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
> runtime rather than the likely alternative of "./bitcoind" vs
> "./bitcoin-fork”.
That’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.
> Chain params may be identical other than the value of some future
> event (miner vote for example), in which case the configs would run
> identically until that point.
Yes, indeed - this would be a special case.
> If your concern is about nodes with different configs communicating
> with eachother, I'd like to reiterate: 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.
I do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.
> Cory
>
>> 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 --------------
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/aedc9049/attachment.sig>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 15:43:08
in reply to nevent1q…qa95
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 15:43:08Event JSON
{
"id": "1a03211589457e1851751d0f7e1f674abe29ffe828d625f681a0d6cb0b3b57db",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686152588,
"kind": 1,
"tags": [
[
"e",
"95a36d78d6bf18f4b8ede735f044f5cc9630ae9f0b1198d008835777ff84eede",
"",
"root"
],
[
"e",
"367963a99c60a53e124a78563f7c01a52127653bb5c79ea2999a90bd97dbeb17",
"",
"reply"
],
[
"p",
"28e91e249bc93012b85689043e5284a72bacd58ceabf2f4fb6a8873d12e39f7c"
]
],
"content": "📅 Original date posted:2015-07-22\n📝 Original message:\u003e On Jul 22, 2015, at 5:05 PM, Cory Fields \u003clists at coryfields.com\u003e wrote:\n\u003e \n\u003e On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\u003e\u003e FWIW, I had worked on something similar a while back:\n\u003e\u003e https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf\n\u003e\u003e \n\u003e\u003e I like the idea in principle…but we should require a new genesis block,\n\u003e\u003e different magic bytes, and a different network port at the very least. :)\n\u003e\u003e \n\u003e \n\u003e Not sure if serious, so I'll assume you are :)\n\nOnly being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.\n\n\u003e Why? The idea in this case would be to allow the user to decide\n\u003e between (say) \"./bitcoind -1mbchain\" and \"./bitcoind -2mbchain\" at\n\u003e runtime rather than the likely alternative of \"./bitcoind\" vs\n\u003e \"./bitcoin-fork”.\n\nThat’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.\n\n\u003e Chain params may be identical other than the value of some future\n\u003e event (miner vote for example), in which case the configs would run\n\u003e identically until that point.\n\nYes, indeed - this would be a special case.\n\n\u003e If your concern is about nodes with different configs communicating\n\u003e with eachother, I'd like to reiterate: the idea really is no different\n\u003e than suggesting that someone fork the codebase and implement their own\n\u003e changes, it just cuts out most of the work required.\n\nI do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.\n\n\u003e Cory\n\u003e \n\u003e\u003e On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e\u003e I'm not sure why Bitcoin Core and the rules and policies that it\n\u003e\u003e enforces are being conflated in this thread. There's nothing stopping\n\u003e\u003e us from adding the ability for the user to decide what their consensus\n\u003e\u003e parameters should be at runtime. In fact, that's already in use:\n\u003e\u003e ./bitcoind -testnet. As mentioned in another thread, the chain params\n\u003e\u003e could even come from a config file that the user could edit without\n\u003e\u003e touching the code.\n\u003e\u003e \n\u003e\u003e I realize that it'd be opening Pandora's Box, and likely met with very\n\u003e\u003e loud and reasonable arguments about the obvious terrible implications,\n\u003e\u003e but it's at least an alternative to the current status quo of Core's\n\u003e\u003e conflation with the consensus rules. The idea really is no different\n\u003e\u003e than suggesting that someone fork the codebase and implement their own\n\u003e\u003e changes, it just cuts out most of the work required.\n\u003e\u003e \n\u003e\u003e With that in place, consensus changes would be more about lobbying and\n\u003e\u003e coalitions, and less about pull requests.\n\u003e\u003e \n\u003e\u003e Cory\n\u003e\u003e \n\u003e\u003e On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e\u003e If the developers fail to reflect user consensus, the network will let us\n\u003e\u003e know.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e This is true with the caveat that there must be more than one option present\n\u003e\u003e for the network to show it's preference. If developers discourage anything\n\u003e\u003e that forks from the rules enforced by Bitcoin Core, they harm the network's\n\u003e\u003e ability to inform us of a failure to reflect user consensus.\n\u003e\u003e \n\u003e\u003e On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e\u003e I wouldn't go quite that far. The reality is somewhere in the middle, as\n\u003e\u003e Bryan Cheng noted in this thread:\n\u003e\u003e \n\u003e\u003e Quoting BC,\n\u003e\u003e \n\u003e\u003e Upgrading to a version of Bitcoin Core that is incompatible with your\n\u003e\u003e ideals is in no way a forced choice, as you have stated in your email;\n\u003e\u003e forks, alternative clients, or staying on an older version are all valid\n\u003e\u003e choices. If the majority of the network chooses not to endorse a specific\n\u003e\u003e change, then the majority of the network will continue to operate just fine\n\u003e\u003e without it, and properly structured consensus rules will pull the minority\n\u003e\u003e along as well.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e The developers propose a new version, by publishing a new release. The\n\u003e\u003e individual network nodes choose to accept or reject that.\n\u003e\u003e \n\u003e\u003e So I respectfully disagree with \"core devs don't control the network\" and\n\u003e\u003e \"core devs control the network\" both.\n\u003e\u003e \n\u003e\u003e There are checks-and-balances that make the system work. Consensus is most\n\u003e\u003e strongly measured by user actions after software release. If the developers\n\u003e\u003e fail to reflect user consensus, the network will let us know.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e\u003e Hi Pieter,\n\u003e\u003e \n\u003e\u003e I think a core area of disagreement is this:\n\u003e\u003e \n\u003e\u003e Bitcoin Core is not running the Bitcoin economy, and its developers have no\n\u003e\u003e authority to set its rules.\n\u003e\u003e \n\u003e\u003e In fact Bitcoin Core is running the Bitcoin economy, and its developers do\n\u003e\u003e have the authority to set its rules. This is enforced by the reality of\n\u003e\u003e ~100% market share and limited github commit access.\n\u003e\u003e \n\u003e\u003e You may not like this situation, but it is what it is. By refusing to make a\n\u003e\u003e release with different rules, people who disagree are faced with only two\n\u003e\u003e options:\n\u003e\u003e \n\u003e\u003e 1. Swallow it even if they hate it\n\u003e\u003e 2. Fork the project and fork the block chain with it (XT)\n\u003e\u003e \n\u003e\u003e There are no alternatives. People who object to (2) are inherently\n\u003e\u003e suggesting (1) is the only acceptable path, which not surprisingly, makes a\n\u003e\u003e lot of people very angry.\n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \n\u003e\u003e \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/aedc9049/attachment.sig\u003e",
"sig": "053dbcff3764a4c59d035c03e7a314b213d5ecba97478b82bcc05fc93e6976b65f100300e8ac4ceaf99019b4770f6e32ef91998234371e1e6518bfdaab94f268"
}