Jonathan Toomim [ARCHIVE] on Nostr: š Original date posted:2015-12-26 š Original message:On Dec 26, 2015, at 3:16 ...
š
Original date posted:2015-12-26
š Original message:On Dec 26, 2015, at 3:16 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> I am generally not interested in a system where we rely on miners to make that judgement call to fork off nodes that don't pay attention and/or disagree with the change. This is not because I don't trust them, but because I believe one of the principle values of the system is that its consensus system should be hard to change.
>
I'm not proposing that we rely on miners' assessments of full node counts. I'm simply proposing that they serve as an extra layer of safety.
For the users that don't pay attention, I don't think the miners should be the sole parties to make that judgment call. That's why I suggested the grace period. I think that 1 or 2 months more than enough time for a business or active bitcoin user to download a new version of the software. I think that 1 or 2 months after a majority of nodes and miners have upgraded is more than more than enough time. For non-active businesses and users, there is no risk from the hard fork. If you're not transacting, you can't be defrauded.
Nodes that disagree with the change are welcome to continue to run the old version and watch the small fork if they so choose. Their numbers should be small if indeed this is an uncontroversial hardfork, but they won't be zero, and that's fine. The software supports this (except for peer discovery, which can get a little bit tricky in hardfork scenarios for the minority fork). Miners have no ethical obligation to protect individuals who choose not to follow consensus.
I think that use of the Alert System https://en.bitcoin.it/wiki/Alert_system would be justified in the weeks preceding the hard fork. Maybe we can create an "Upgrade now!" message that the new version would ignore, and set it to broadcast forever to all old nodes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/f3f84eab/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/f3f84eab/attachment.sig>;
š Original message:On Dec 26, 2015, at 3:16 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> I am generally not interested in a system where we rely on miners to make that judgement call to fork off nodes that don't pay attention and/or disagree with the change. This is not because I don't trust them, but because I believe one of the principle values of the system is that its consensus system should be hard to change.
>
I'm not proposing that we rely on miners' assessments of full node counts. I'm simply proposing that they serve as an extra layer of safety.
For the users that don't pay attention, I don't think the miners should be the sole parties to make that judgment call. That's why I suggested the grace period. I think that 1 or 2 months more than enough time for a business or active bitcoin user to download a new version of the software. I think that 1 or 2 months after a majority of nodes and miners have upgraded is more than more than enough time. For non-active businesses and users, there is no risk from the hard fork. If you're not transacting, you can't be defrauded.
Nodes that disagree with the change are welcome to continue to run the old version and watch the small fork if they so choose. Their numbers should be small if indeed this is an uncontroversial hardfork, but they won't be zero, and that's fine. The software supports this (except for peer discovery, which can get a little bit tricky in hardfork scenarios for the minority fork). Miners have no ethical obligation to protect individuals who choose not to follow consensus.
I think that use of the Alert System https://en.bitcoin.it/wiki/Alert_system would be justified in the weeks preceding the hard fork. Maybe we can create an "Upgrade now!" message that the new version would ignore, and set it to broadcast forever to all old nodes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/f3f84eab/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/f3f84eab/attachment.sig>;