Jean-Pierre Rupp [ARCHIVE] on Nostr: 📅 Original date posted:2014-11-15 📝 Original message:Jean-Pierre Rupp from ...
📅 Original date posted:2014-11-15
📝 Original message:Jean-Pierre Rupp from Haskoin here.
I support a hard fork to fix consensus bugs. The Bitcoin protocol should eventually get to a state where it is documented in a clear and understandable fashion. Bugs are bugs, and are the enemy. We should not attempt to live with them. We should be opening a process of thoroughly documenting and reparing consensus bugs on a separate branch, and eventually schedule a hard fork.
There are two good things that will come out of that:
1. Known bugs will be gone, and
2. We will have a process in place to get rid of future bugs in eventual future hard forks.
We do not need to become paranoid about the ramifications of a hard fork, or how it will open the door for unwanted changes in the protocol. We are discussing about removing bugs, and bugs that could be used to exploit the network in ways that may not be immediately obvious.
There are 144 blocks generated per day by groups of miners that are mostly identified. It is not going to be a titanic task to get consensus from the main mining pools on fixing this at the mining level. We must address how the fixes for some of these bugs affect other types of software such as wallets. I can think that fixing the bug where OP_CHECKMULTISIG pops an extra value from the stash could be more traumatic, since it requires anything that creates and validates multi-signature transactions to change the way it works. Hardware wallets could be impacted. But most of the consensus bugs would not affect the way the vast majority of bitcoin transactions that are currently created. Therefore it should not be traumatic at all for users, but only really affect mining pools, who would only need to be convinced to upgrade their bitcoind well in advance, which seems to me that it is not an issue at all.
We should not compare doing a Bitcoin hard-fork with doing something like deploying IPv6 world-wide or enforcing TLS and SPF on every SMTP connection. We should not conflate Bitcoin with other network protocols. The Bitcoin protocol is actually relatively easy to upgrade at this point. Let's take advantage of this fact.
On 06/11/14 15:36, Justus Ranvier wrote:
> Because Bitcoin has a extra consensus requirements, requirements which
> are really rare in engineering, the necessity of fixing bugs is even
> greater.
--
Be Happy :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x310A8A5B.asc
Type: application/pgp-keys
Size: 4087 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141114/5d4c8096/attachment.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141114/5d4c8096/attachment.sig>;
📝 Original message:Jean-Pierre Rupp from Haskoin here.
I support a hard fork to fix consensus bugs. The Bitcoin protocol should eventually get to a state where it is documented in a clear and understandable fashion. Bugs are bugs, and are the enemy. We should not attempt to live with them. We should be opening a process of thoroughly documenting and reparing consensus bugs on a separate branch, and eventually schedule a hard fork.
There are two good things that will come out of that:
1. Known bugs will be gone, and
2. We will have a process in place to get rid of future bugs in eventual future hard forks.
We do not need to become paranoid about the ramifications of a hard fork, or how it will open the door for unwanted changes in the protocol. We are discussing about removing bugs, and bugs that could be used to exploit the network in ways that may not be immediately obvious.
There are 144 blocks generated per day by groups of miners that are mostly identified. It is not going to be a titanic task to get consensus from the main mining pools on fixing this at the mining level. We must address how the fixes for some of these bugs affect other types of software such as wallets. I can think that fixing the bug where OP_CHECKMULTISIG pops an extra value from the stash could be more traumatic, since it requires anything that creates and validates multi-signature transactions to change the way it works. Hardware wallets could be impacted. But most of the consensus bugs would not affect the way the vast majority of bitcoin transactions that are currently created. Therefore it should not be traumatic at all for users, but only really affect mining pools, who would only need to be convinced to upgrade their bitcoind well in advance, which seems to me that it is not an issue at all.
We should not compare doing a Bitcoin hard-fork with doing something like deploying IPv6 world-wide or enforcing TLS and SPF on every SMTP connection. We should not conflate Bitcoin with other network protocols. The Bitcoin protocol is actually relatively easy to upgrade at this point. Let's take advantage of this fact.
On 06/11/14 15:36, Justus Ranvier wrote:
> Because Bitcoin has a extra consensus requirements, requirements which
> are really rare in engineering, the necessity of fixing bugs is even
> greater.
--
Be Happy :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x310A8A5B.asc
Type: application/pgp-keys
Size: 4087 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141114/5d4c8096/attachment.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141114/5d4c8096/attachment.sig>;