Btc Drak [ARCHIVE] on Nostr: đź“… Original date posted:2016-01-29 đź“ť Original message:Your proposal does not ...
đź“… Original date posted:2016-01-29
đź“ť Original message:Your proposal does not solve the issue related to Mike creating his own
fork. He created his own for because he had a non-consensus feature set
that Bitcoin Core disagreed with and he wanted. That is to be _encouraged_.
I also maintain my own Bitcoin fork with a specific (non-consensus) feature
for the same reason and I am perfectly happy with the arrangement, as are
my userbase.
Classification of BIPs is fine, I have no problem with that and I support
your BIP, but your proposition it would have stopped Mike from creating his
own distribution is false (nor desirable): it was down to a strong
differing of technical opinions between Mike and a dozen other developers
as well as node security concerns (which were proved correct).
On Fri, Jan 29, 2016 at 12:52 AM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Folks,
>
> I think the current situation with forks could have been avoided with a
> better process that can distinguish between different layers for bitcoin
> modification proposals.
>
> For instance, BIP64 was proposed by Mike Hearn, which does not affect the
> consensus layer at all. Many Core devs disliked the proposal and Mike had
> lots of pushback. Regardless of whether or not you agree with the merits of
> Mike’s ideas here, fact is having nodes that support BIP64 would not
> fundamentally break the Bitcoin network.
>
> This issue prompted Mike to break off from Core and create XT as the
> applications he was developing required BIP64 to work. With this split,
> Gavin found a new home for his big block ideas…and the two teamed up.
>
> We need to have a process that clearly distinguishes these different
> layers and allows much more freedom in the upper layers while requiring
> agreement at the consensus layer. Many of these fork proposals are actually
> conflating different features, only some of which would actually be
> consensus layer changes. When people proposing nonconsensus features get
> pushback from Core developers they feel rejected and are likely to team up
> with others trying to push for hard forks and the like.
>
> A while back I had submitted a BIP - BIP123 - that addresses this issue.
> I have updated it to include all the currently proposed and accepted BIPs
> and have submitted a PR: https://github.com/bitcoin/bips/pull/311
>
> I urge everyone to seriously consider getting this BIP accepted as a top
> priority before we get more projects all trying their hand at stuff and not
> understanding these critical distinctions.
>
>
> - Eric
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160129/cbfbca9f/attachment.html>;
đź“ť Original message:Your proposal does not solve the issue related to Mike creating his own
fork. He created his own for because he had a non-consensus feature set
that Bitcoin Core disagreed with and he wanted. That is to be _encouraged_.
I also maintain my own Bitcoin fork with a specific (non-consensus) feature
for the same reason and I am perfectly happy with the arrangement, as are
my userbase.
Classification of BIPs is fine, I have no problem with that and I support
your BIP, but your proposition it would have stopped Mike from creating his
own distribution is false (nor desirable): it was down to a strong
differing of technical opinions between Mike and a dozen other developers
as well as node security concerns (which were proved correct).
On Fri, Jan 29, 2016 at 12:52 AM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Folks,
>
> I think the current situation with forks could have been avoided with a
> better process that can distinguish between different layers for bitcoin
> modification proposals.
>
> For instance, BIP64 was proposed by Mike Hearn, which does not affect the
> consensus layer at all. Many Core devs disliked the proposal and Mike had
> lots of pushback. Regardless of whether or not you agree with the merits of
> Mike’s ideas here, fact is having nodes that support BIP64 would not
> fundamentally break the Bitcoin network.
>
> This issue prompted Mike to break off from Core and create XT as the
> applications he was developing required BIP64 to work. With this split,
> Gavin found a new home for his big block ideas…and the two teamed up.
>
> We need to have a process that clearly distinguishes these different
> layers and allows much more freedom in the upper layers while requiring
> agreement at the consensus layer. Many of these fork proposals are actually
> conflating different features, only some of which would actually be
> consensus layer changes. When people proposing nonconsensus features get
> pushback from Core developers they feel rejected and are likely to team up
> with others trying to push for hard forks and the like.
>
> A while back I had submitted a BIP - BIP123 - that addresses this issue.
> I have updated it to include all the currently proposed and accepted BIPs
> and have submitted a PR: https://github.com/bitcoin/bips/pull/311
>
> I urge everyone to seriously consider getting this BIP accepted as a top
> priority before we get more projects all trying their hand at stuff and not
> understanding these critical distinctions.
>
>
> - Eric
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160129/cbfbca9f/attachment.html>;