From: Peter R <peter_r@gmx.com>
To: Paul Sztorc <truthcoin@gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate
Date: Mon, 5 Oct 2015 10:33:55 -0700 [thread overview]
Message-ID: <5570C084-0C2D-4B79-A78E-B25699600EA9@gmx.com> (raw)
In-Reply-To: <5612ACF3.2080006@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]
Dear Bitcoin Development Community:
I would like to share my opinion that Mike is correct regarding the soft fork versus hard fork debate. I agree that CLTV should be done with a hard fork for the reasons that Mike has discussed several times in the past (mainly that a hard forks requires active consensus while a soft fork requires only indifference). I believe this is a controversial change and—if Core Dev believes that controversial changes to the consensus rules must not happen—then my interpretation is that CLTV should not happen in its current form.
I also agree with Mike that Core's requirement for unanimous consensus results in development grid lock and should be revisited. In my opinion, the idea that unanimity is required should be replaced with the idea that the longest chain composed of valid transactions is the correct chain. It shouldn’t matter really how the chain becomes the longest—only that it does.
I believe that a good way to return power to the bitcoin community is to foster mutiple forkwise-compatible implementations of the protocol. Each implementation could have its own governance model and design objectives and use techniques like BIP101’s 750/1000 signalling mechanism to activate changes that may be desirable to the community. If a super majority does not support the change, then it won’t be activated. I created an animated GIF that visualizes one possibility for how multiple protocol implementations might emerge over time:
https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_core_visualizing_the/ <https://www.reddit.com/r/bitcoinxt/comments/3nhq9t/deprecating_bitcoin_core_visualizing_the/>
Decentralizing development and supporting multiple forkwise-compatible implementations of the protocol is a worthwhile goal that will simultaneously make Bitcoin more robust and more responsive to the will of the market.
Nodes would express their acceptance of a block by mining on top of it. Consensus would be determined by the code we choose to run.
Best regards,
Peter
> On Oct 5, 2015, at 10:01 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On 10/5/2015 12:56 PM, Mike Hearn via bitcoin-dev wrote:
>>
>> As everyone in the Bitcoin community has been clearly told that
>> controversial changes to the consensus rules must not happen, it's
>> clear that CLTV cannot happen in its current form.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 3807 bytes --]
next prev parent reply other threads:[~2015-10-05 17:34 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 15:56 [bitcoin-dev] This thread is not about the soft/hard fork technical debate Sergio Demian Lerner
2015-10-05 16:39 ` NxtChg
2015-10-05 16:51 ` Luke Dashjr
2015-10-05 16:56 ` Mike Hearn
2015-10-05 17:01 ` Paul Sztorc
2015-10-05 17:33 ` Peter R [this message]
2015-10-05 17:56 ` NxtChg
2015-10-05 22:56 ` Btc Drak
2015-10-05 23:05 ` Milly Bitcoin
2015-10-05 17:35 ` Btc Drak
2015-10-06 18:23 ` Venzen Khaosan
2015-10-06 18:28 ` Venzen Khaosan
2015-10-06 19:34 ` naama.kates
2015-10-05 17:03 ` Btc Drak
2015-10-05 17:26 ` Tom Zander
2015-10-05 17:52 ` Btc Drak
2015-10-05 18:04 ` Gregory Maxwell
2015-10-05 18:33 ` Tom Zander
2015-10-05 18:50 ` NotMike Hearn
2015-10-05 17:33 ` s7r
2015-10-05 18:51 ` Tom Zander
2015-10-05 18:35 ` Gregory Maxwell
2015-10-05 19:13 ` Tom Zander
2015-10-05 19:41 ` Gregory Maxwell
2015-10-05 20:05 ` Steven Pine
2015-10-05 20:21 ` Milly Bitcoin
2015-10-06 7:17 ` cipher anthem
2015-10-06 7:20 ` Eric Lombrozo
2015-10-06 7:29 ` Marcel Jamin
2015-10-06 8:34 ` NotMike Hearn
2015-10-06 19:40 ` naama.kates
2015-10-05 20:28 ` Santino Napolitano
2015-10-05 20:35 ` Tom Zander
2015-10-05 20:54 ` Dave Scotese
2015-10-05 20:56 ` Gregory Maxwell
2015-10-05 21:08 ` Tom Zander
2015-10-05 21:16 ` Milly Bitcoin
2015-10-05 21:26 ` Gregory Maxwell
2015-10-06 7:14 ` Tom Zander
2015-10-05 21:27 ` Peter R
2015-10-05 21:30 ` Gregory Maxwell
2015-10-05 21:36 ` Milly Bitcoin
2015-10-05 21:37 ` Peter R
2015-10-06 1:37 ` Tom Harding
2015-10-06 3:20 ` Peter R
2015-10-06 3:39 ` Milly Bitcoin
2015-10-06 4:54 ` Luke Dashjr
2015-10-06 5:08 ` Milly Bitcoin
2015-10-06 5:49 ` Milly Bitcoin
2015-10-06 5:53 ` Luke Dashjr
2015-10-06 6:03 ` Milly Bitcoin
2015-10-06 22:14 ` phm
2015-10-06 5:07 ` NotMike Hearn
2015-10-06 5:33 ` Peter R
2015-10-05 19:36 ` Milly Bitcoin
2015-10-05 23:18 ` Eric Lombrozo
2015-10-06 17:28 ` Venzen Khaosan
2015-10-07 0:04 ` Sergio Demian Lerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5570C084-0C2D-4B79-A78E-B25699600EA9@gmx.com \
--to=peter_r@gmx.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=truthcoin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox