Bryan Bishop [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-06 📝 Original message:On Sat, Feb 6, 2016 at ...
📅 Original date posted:2016-02-06
📝 Original message:On Sat, Feb 6, 2016 at 9:37 AM, Gavin Andresen wrote:
> Responding to "28 days is not long enough" :
>
Gavin,
Thank you for the emails. Bitcoin Core has been working with the Bitcoin
ecosystem on developing and now testing a new capacity increasing feature
called segregated witness (segwit). Segregated witness is a voluntary,
mutually backwards-compatible capacity upgrade for the Bitcoin system.
Many, many hundreds of millions of dollars of Bitcoin value have flowed
through soft-forked upgrades to the Bitcoin system, representing upgrades
from across the entire ecosystem and the entire Bitcoin network, over
multiple years including BIP 12, BIP 16, BIP 17, BIP 30, BIP 34, BIP 42,
BIP 62, BIP 65, BIP 66, etc. So that’s the context from which I have been
approaching your hard-fork ideas for the past year.
Benefits of segregated witness
https://bitcoincore.org/en/2016/01/26/segwit-benefits/
Ecosystem buy-in and support for segregated witness continues to grow:
https://bitcoincore.org/en/segwit_adoption/
There is also a segwit testnet which everyone is encouraged to investigate
and develop against-- companies love them some testing, after all:
https://bitcoincore.org/en/2016/01/21/launch_segwit_testnet/
A plan for Bitcoin Core capacity increases was put forward and can be found
here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
With respect, the question should not be "is 28 days enough time for anyone
to roll out new binaries", it's instead a question of "how long does it
take someone to agree to upgrade to these new incompatible rules".
If Bitcoin users don't want to upgrade to incompatible rules right now, why
would they agree when 10% of the hashpower is setting some flag in a block?
Why would they change their minds at 20%? 90%? I am not saying here that
hard-forks should never be attempted, although we need as an ecosystem to
develop much more rigor and a more data-driven approach, and while that
might be hard to define exactly, as was once said by regulators, “I know it
when I see it”. Companies in the financial sector give a year or more
before deprecating old APIs even after the new one has been up and running
concurrently and well proven, and would not shut off their old one in order
to get adoption of the new one.
Are we OK with some percent of the Bitcoin ecosystem not agreeing with the
existing rules? What would that mean? Are you willing to maintain two
separate networks, and if not, would you please document this in your BIP?
Deprecation timeline and emergency procedures?? Should we include
rationalizations for not using a new address prefix? In the event of a
partial hard-fork where two chains exist, wouldn't it make more sense to
have the new chain use a new address prefix? Using a new address prefix
could conceivably serve to minimize the impact of what almost looks like an
intentionally constructed y2k-bug type of event for the ecosystem.
I suspect that soft-fork upgrades have in the past tolerated _less_ rigor
around planning because voluntary soft-fork upgrading does not
intentionally break backwards-compatibility. Over time I expect that even
soft-fork upgrades will have much more planning, but again, it seems that
incompatible changes require much more rigor. If the sky is truly falling
according to your pronouncements, then there are millions if not billions
of dollars of value on the line which are being risked from lack of
engineering rigor without a well documented procedure, and suggesting that
we agree on that "next time" is not going to create the results that meet
your or anyone else’s desire. Much more, we need to signal to the broader
ecosystem and world that we are serious, mature and ready for business.
Regarding your request for definitions about soft-hard forks and
generalized soft-forks, you can find some definitions over here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012172.html
About hard-forks you may be interested in reading and internalizing,
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki
This was an interesting exploration of soft-forks and hard-forks:
https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
On the security of soft-forks
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
Are soft-forks misnamed?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011266.html
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160206/3017ee42/attachment-0001.html>;
📝 Original message:On Sat, Feb 6, 2016 at 9:37 AM, Gavin Andresen wrote:
> Responding to "28 days is not long enough" :
>
Gavin,
Thank you for the emails. Bitcoin Core has been working with the Bitcoin
ecosystem on developing and now testing a new capacity increasing feature
called segregated witness (segwit). Segregated witness is a voluntary,
mutually backwards-compatible capacity upgrade for the Bitcoin system.
Many, many hundreds of millions of dollars of Bitcoin value have flowed
through soft-forked upgrades to the Bitcoin system, representing upgrades
from across the entire ecosystem and the entire Bitcoin network, over
multiple years including BIP 12, BIP 16, BIP 17, BIP 30, BIP 34, BIP 42,
BIP 62, BIP 65, BIP 66, etc. So that’s the context from which I have been
approaching your hard-fork ideas for the past year.
Benefits of segregated witness
https://bitcoincore.org/en/2016/01/26/segwit-benefits/
Ecosystem buy-in and support for segregated witness continues to grow:
https://bitcoincore.org/en/segwit_adoption/
There is also a segwit testnet which everyone is encouraged to investigate
and develop against-- companies love them some testing, after all:
https://bitcoincore.org/en/2016/01/21/launch_segwit_testnet/
A plan for Bitcoin Core capacity increases was put forward and can be found
here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
With respect, the question should not be "is 28 days enough time for anyone
to roll out new binaries", it's instead a question of "how long does it
take someone to agree to upgrade to these new incompatible rules".
If Bitcoin users don't want to upgrade to incompatible rules right now, why
would they agree when 10% of the hashpower is setting some flag in a block?
Why would they change their minds at 20%? 90%? I am not saying here that
hard-forks should never be attempted, although we need as an ecosystem to
develop much more rigor and a more data-driven approach, and while that
might be hard to define exactly, as was once said by regulators, “I know it
when I see it”. Companies in the financial sector give a year or more
before deprecating old APIs even after the new one has been up and running
concurrently and well proven, and would not shut off their old one in order
to get adoption of the new one.
Are we OK with some percent of the Bitcoin ecosystem not agreeing with the
existing rules? What would that mean? Are you willing to maintain two
separate networks, and if not, would you please document this in your BIP?
Deprecation timeline and emergency procedures?? Should we include
rationalizations for not using a new address prefix? In the event of a
partial hard-fork where two chains exist, wouldn't it make more sense to
have the new chain use a new address prefix? Using a new address prefix
could conceivably serve to minimize the impact of what almost looks like an
intentionally constructed y2k-bug type of event for the ecosystem.
I suspect that soft-fork upgrades have in the past tolerated _less_ rigor
around planning because voluntary soft-fork upgrading does not
intentionally break backwards-compatibility. Over time I expect that even
soft-fork upgrades will have much more planning, but again, it seems that
incompatible changes require much more rigor. If the sky is truly falling
according to your pronouncements, then there are millions if not billions
of dollars of value on the line which are being risked from lack of
engineering rigor without a well documented procedure, and suggesting that
we agree on that "next time" is not going to create the results that meet
your or anyone else’s desire. Much more, we need to signal to the broader
ecosystem and world that we are serious, mature and ready for business.
Regarding your request for definitions about soft-hard forks and
generalized soft-forks, you can find some definitions over here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012172.html
About hard-forks you may be interested in reading and internalizing,
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki
This was an interesting exploration of soft-forks and hard-forks:
https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
On the security of soft-forks
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
Are soft-forks misnamed?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011266.html
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160206/3017ee42/attachment-0001.html>;