📅 Original date posted:2015-07-01
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Possibly relevant to this discussion (though old)
https://gist.github.com/gavinandresen/2355445 (last changed in 2012 I
think?)
and
https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork
(which cites gavin's gist shown above)
On 06/25/2015 05:42 PM, Milly Bitcoin wrote:
> That description makes sense. It also makes sense to separate out
> the hard fork from the soft fork process. Right now some people
> want to use the soft fork procedure for a hard fork simply because
> there is no other way to do it.
>
> I am under the impression that most users expect
> changes/improvements that would require a hard fork so I think some
> kind of process needs to be developed. Taking the responsibility
> off the shoulder of the core maintainer also makes sense. The hard
> fork issue is too much of a distraction for people trying to
> maintain the nuts and bolts of the underlying system.
>
> I saw a suggestion that regularly scheduled hard forks should be
> planned. That seems to make sense so you would have some sort of
> schedule where you would have cut off dates for hard-fork BIP
> submissions. That way you avoid the debates over whether there
> should be hard forks to what should be contained within the hard
> fork (if needed). It makes sense to follow the BIP process as
> close as possible. Possibly adding another step after "Dev
> acceptance" to include input from others such as
> merchants/exchanges/miners/users. It will only be an approximation
> of "decentralization" and the process won't be perfect but if you
> want to move forward then you need some way to do it.
>
> Russ
>
>
> On 6/25/2015 4:05 PM, Tier Nolan wrote:
>> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach
>> <mark at friedenbach.org <mailto:mark at friedenbach.org>> wrote:
>>
>> I'm sorry but this is absolutely not the case, Milly. The reason
>> that people get defensive is that we have a carefully
>> constructed process that does work (thank you very much!) and is
>> well documented.
>>
>>
>> There is no process for handling hard forks, which aren't bug
>> fixes.
>>
>> Soft forks have a defined process of something like
>>
>> - BIP proposal + discussion - Proposed code - Dev acceptance -
>> Release - Miner vote/acceptance
>>
>> The devs have a weak veto. If they refuse to move forward with
>> changes, miners could perform a soft fork on their own. They
>> don't want to do that, as it would be controversial and the devs
>> know the software better.
>>
>> The miner veto is stronger (for soft forks) but not absolute.
>> The devs could checkpoint/blacklist a chain if miners implemented
>> a fork that wasn't acceptable (assuming the community backed
>> them).
>>
>> When ASICs arrived, it was pointed out by some that the devs
>> could hit back if ASICs weren't made publicly available. If they
>> slightly tweaked the hashing algorithm, then current generation
>> of ASICs would be useless. The potential threat may have acted
>> as a disincentive for ASIC manufacturers to use the ASICs
>> themselves.
>>
>> Moving forward with agreement between all involved is the
>> recommended and desirable approach.
>>
>> Consensus between all parties is the goal but isn't absolutely
>> required. This escape valve is partly what makes consensus work.
>> If you dig your heels in, then the other side can bypass you, but
>> they have an incentive to try to convince you to compromise
>> first. The outcome is better if a middle ground can be found.
>>
>> Hard forks are different. The "checks and balances" of weak
>> vetoes are not present. This means that things can devolve from
>> consensus to mutual veto. Consensus ceases to be a goal and
>> becomes a requirement.
>>
>> This is partly a reflection of the nature of hard forks.
>> Everyone needs to upgrade. On the other hand, if most of the
>> various groups upgrade, then users of the legacy software would
>> have to upgrade or get left behind. If 5% of the users decided
>> not to upgrade, should they be allowed to demand that nobody else
>> does?
>>
>> There is clearly some kind of threshold that is reasonable.
>>
>> The fundamental problem is that there isn't agreement on what
>> the block size is. Is it equal in status to the 21 million BTC
>> limit?
>>
>> If Satoshi had said that 1MB was part of the definition of
>> Bitcoin, then I think people would accept it to the same extent
>> as they accept the 21 million coin limit. It might cause people
>> to leave the coin though.
>>
>> It was intended to be temporary, but people have realized that
>> it might be a good idea to keep it. In effect both sides could
>> argue that they should be considered the status quo.
>>
>> I wonder if a coin toss would be acceptable :). "Come to an
>> agreement or we decide by coin toss"
>>
>>
>> _______________________________________________ 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
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVlGrZAAoJEGxwq/inSG8C2wYH/3VZgzpbJrgprqNMDwWsMoxx
DFbgjQfOrHbVvAQebSlcH1FXPnzVZZSbxMlQAbDXr4lpREvMPQiomixCmkTTepob
zKhJu/bGYgLVqcXSDYuJTwCKgHfzTj02Q8D8ViFZdsPOHLIuhcAAq+KgioUHH+Ps
v2kWA48ePTHVxqNd79S2CKjk5Gyo99YIMAjbQOuC6DbW/y1hNmQP7iQPn6UUe4pY
qyLLDa6ccKvJslq3chXGK/alhGHZ5lyEYZY43qiL9cBEgqEn6kHC5gveqQxvXMvj
rOoZbAKCAc9GdlhUplRt5MhF35FTFvbaBTAq07/95Xo4C8DIhmXesHgmPtc1OqI=
=n7Pa
-----END PGP SIGNATURE-----
odinn [ARCHIVE] /
npub1xv…5j2ga
2023-06-07 15:41:26
in reply to nevent1q…p3za
Author Public Key
npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2gaPublished at
2023-06-07 15:41:26Event JSON
{
"id": "e571b76252083bfdcd65ba4768cdd1ec21edc805658b14f2b668f6c0298002ff",
"pubkey": "33228a8ed797b24e872fc0257c1515fc9bca74c0b230dcbb7d3d2bd38fd97ed7",
"created_at": 1686152486,
"kind": 1,
"tags": [
[
"e",
"ebdaee1968dde7061683852164527a744cf5f8f48cff4e0b28fc896b32ae42a8",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-07-01\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nPossibly relevant to this discussion (though old)\n\nhttps://gist.github.com/gavinandresen/2355445 (last changed in 2012 I\nthink?)\n\nand\n\nhttps://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork\n(which cites gavin's gist shown above)\n\n\n\n\n\nOn 06/25/2015 05:42 PM, Milly Bitcoin wrote:\n\u003e That description makes sense. It also makes sense to separate out\n\u003e the hard fork from the soft fork process. Right now some people\n\u003e want to use the soft fork procedure for a hard fork simply because\n\u003e there is no other way to do it.\n\u003e \n\u003e I am under the impression that most users expect\n\u003e changes/improvements that would require a hard fork so I think some\n\u003e kind of process needs to be developed. Taking the responsibility\n\u003e off the shoulder of the core maintainer also makes sense. The hard\n\u003e fork issue is too much of a distraction for people trying to\n\u003e maintain the nuts and bolts of the underlying system.\n\u003e \n\u003e I saw a suggestion that regularly scheduled hard forks should be \n\u003e planned. That seems to make sense so you would have some sort of \n\u003e schedule where you would have cut off dates for hard-fork BIP \n\u003e submissions. That way you avoid the debates over whether there\n\u003e should be hard forks to what should be contained within the hard\n\u003e fork (if needed). It makes sense to follow the BIP process as\n\u003e close as possible. Possibly adding another step after \"Dev\n\u003e acceptance\" to include input from others such as\n\u003e merchants/exchanges/miners/users. It will only be an approximation\n\u003e of \"decentralization\" and the process won't be perfect but if you\n\u003e want to move forward then you need some way to do it.\n\u003e \n\u003e Russ\n\u003e \n\u003e \n\u003e On 6/25/2015 4:05 PM, Tier Nolan wrote:\n\u003e\u003e On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach \n\u003e\u003e \u003cmark at friedenbach.org \u003cmailto:mark at friedenbach.org\u003e\u003e wrote:\n\u003e\u003e \n\u003e\u003e I'm sorry but this is absolutely not the case, Milly. The reason \n\u003e\u003e that people get defensive is that we have a carefully\n\u003e\u003e constructed process that does work (thank you very much!) and is\n\u003e\u003e well documented.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e There is no process for handling hard forks, which aren't bug\n\u003e\u003e fixes.\n\u003e\u003e \n\u003e\u003e Soft forks have a defined process of something like\n\u003e\u003e \n\u003e\u003e - BIP proposal + discussion - Proposed code - Dev acceptance -\n\u003e\u003e Release - Miner vote/acceptance\n\u003e\u003e \n\u003e\u003e The devs have a weak veto. If they refuse to move forward with \n\u003e\u003e changes, miners could perform a soft fork on their own. They\n\u003e\u003e don't want to do that, as it would be controversial and the devs\n\u003e\u003e know the software better.\n\u003e\u003e \n\u003e\u003e The miner veto is stronger (for soft forks) but not absolute.\n\u003e\u003e The devs could checkpoint/blacklist a chain if miners implemented\n\u003e\u003e a fork that wasn't acceptable (assuming the community backed\n\u003e\u003e them).\n\u003e\u003e \n\u003e\u003e When ASICs arrived, it was pointed out by some that the devs\n\u003e\u003e could hit back if ASICs weren't made publicly available. If they\n\u003e\u003e slightly tweaked the hashing algorithm, then current generation\n\u003e\u003e of ASICs would be useless. The potential threat may have acted\n\u003e\u003e as a disincentive for ASIC manufacturers to use the ASICs\n\u003e\u003e themselves.\n\u003e\u003e \n\u003e\u003e Moving forward with agreement between all involved is the\n\u003e\u003e recommended and desirable approach.\n\u003e\u003e \n\u003e\u003e Consensus between all parties is the goal but isn't absolutely \n\u003e\u003e required. This escape valve is partly what makes consensus work.\n\u003e\u003e If you dig your heels in, then the other side can bypass you, but\n\u003e\u003e they have an incentive to try to convince you to compromise\n\u003e\u003e first. The outcome is better if a middle ground can be found.\n\u003e\u003e \n\u003e\u003e Hard forks are different. The \"checks and balances\" of weak\n\u003e\u003e vetoes are not present. This means that things can devolve from\n\u003e\u003e consensus to mutual veto. Consensus ceases to be a goal and\n\u003e\u003e becomes a requirement.\n\u003e\u003e \n\u003e\u003e This is partly a reflection of the nature of hard forks.\n\u003e\u003e Everyone needs to upgrade. On the other hand, if most of the\n\u003e\u003e various groups upgrade, then users of the legacy software would\n\u003e\u003e have to upgrade or get left behind. If 5% of the users decided\n\u003e\u003e not to upgrade, should they be allowed to demand that nobody else\n\u003e\u003e does?\n\u003e\u003e \n\u003e\u003e There is clearly some kind of threshold that is reasonable.\n\u003e\u003e \n\u003e\u003e The fundamental problem is that there isn't agreement on what\n\u003e\u003e the block size is. Is it equal in status to the 21 million BTC\n\u003e\u003e limit?\n\u003e\u003e \n\u003e\u003e If Satoshi had said that 1MB was part of the definition of\n\u003e\u003e Bitcoin, then I think people would accept it to the same extent\n\u003e\u003e as they accept the 21 million coin limit. It might cause people\n\u003e\u003e to leave the coin though.\n\u003e\u003e \n\u003e\u003e It was intended to be temporary, but people have realized that\n\u003e\u003e it might be a good idea to keep it. In effect both sides could\n\u003e\u003e argue that they should be considered the status quo.\n\u003e\u003e \n\u003e\u003e I wonder if a coin toss would be acceptable :). \"Come to an\n\u003e\u003e agreement or we decide by coin toss\"\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e _______________________________________________ bitcoin-dev\n\u003e\u003e mailing list bitcoin-dev at lists.linuxfoundation.org \n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ bitcoin-dev mailing\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n- -- \nhttp://abis.io ~\n\"a protocol concept to enable decentralization\nand expansion of a giving economy, and a new social good\"\nhttps://keybase.io/odinn\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVlGrZAAoJEGxwq/inSG8C2wYH/3VZgzpbJrgprqNMDwWsMoxx\nDFbgjQfOrHbVvAQebSlcH1FXPnzVZZSbxMlQAbDXr4lpREvMPQiomixCmkTTepob\nzKhJu/bGYgLVqcXSDYuJTwCKgHfzTj02Q8D8ViFZdsPOHLIuhcAAq+KgioUHH+Ps\nv2kWA48ePTHVxqNd79S2CKjk5Gyo99YIMAjbQOuC6DbW/y1hNmQP7iQPn6UUe4pY\nqyLLDa6ccKvJslq3chXGK/alhGHZ5lyEYZY43qiL9cBEgqEn6kHC5gveqQxvXMvj\nrOoZbAKCAc9GdlhUplRt5MhF35FTFvbaBTAq07/95Xo4C8DIhmXesHgmPtc1OqI=\n=n7Pa\n-----END PGP SIGNATURE-----",
"sig": "d16ab99cee27a8a97ef90a453614ea937733a330c088e31835383c825cc44ec18b9eace06f3e1f60053fe857a28ff2e020329b045881c475d7fec522f1f39a42"
}