Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-17 📝 Original message:There are no good ...
📅 Original date posted:2015-12-17
📝 Original message:There are no good short-term scaling solutions...this is a very hard problem that necessarily requires a lot of out-of-the-box thinking, something 2015 has seen a LOT of...and I'm optimistic about the ideas presented thus far.
At least SW *is* a scaling solution (albeit most of the important benefits are long term). The issue of fee events has nothing to do with scaling - it has to do with economics...specifically whether we should be subsidizing transactions, who should pay the bill for it, etc. My own personal opinion is that increasing validation costs works against adoption, not for it...even if it artificially keeps fees low - and we'll have to deal with a fee event sooner or later anyhow. You may disagree with my opinion, but please, let's stop confounding the economic issues with actual scaling.
On December 16, 2015 6:21:22 PM PST, Jeff Garzik via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo
><lf-lists at mattcorallo.com>
>wrote:
>
>> A large part of your argument is that SW will take longer to deploy
>than a
>> hard fork, but I completely disagree. Though I do not agree with some
>> people claiming we can deploy SW significantly faster than a hard
>fork,
>> once the code is ready (probably a six month affair) we can get it
>deployed
>> very quickly. It's true the ecosystem may take some time to upgrade,
>but I
>> see that as a feature, not a bug - we can build up some fee pressure
>with
>> an immediate release valve available for people to use if they want
>to pay
>> fewer fees.
>>
>
>That's taking a big risk. "Build up some fee pressure" is essentially
>risking a Fee Event if uptake is slower than planned, or traffic is
>greater
>than expected.
>
>
>
>>
>> On the other hand, a hard fork, while simpler for the ecosystem to
>upgrade
>> to, is a 1-2 year affair (after the code is shipped, so at least
>1.5-2.5
>> from today if we all put off heads down and work). One thing that has
>> concerned me greatly through this whole debate is how quickly people
>seem
>> to think we can roll out a hard fork. Go look at the distribution of
>node
>> versions on the network today and work backwards to get nearly every
>node
>> upgraded... Even with a year between fork-version-release and
>> fork-activation, we'd still kill a bunch of nodes and instead of
>reducing
>> their security model, lead them to be outright robbed.
>>
>
>A hard fork will never achieve 100% There are many credible folks and
>estimates who feel a May hard fork is reasonable and doable.
>
>Further, hard forks restore the full trustless nature of the
>post-hard-fork
>nodes. Soft forks continually erode that. That's why SW should come
>via
>hard fork. The end result is more secure - 100% validation of witness
>transactions.
>
>If regular hard fork plans are proposed in public, many months in
>advance,
>there is plenty of time for the community to react. Hard forks create
>a
>more predictable market and environment for Users, and a more secure
>network.
>
>Further, even if you believe SW makes hard fork unnecessary, it is the
>responsible thing to code and communicate to users the plan for a Fee
>Event
>just in case SW uptake and extension block use does not match
>theoretical
>projections of SW proponents.
>
>Finally, SW does not eliminate and is orthogonal to Short Term Problem
>#1
>(orig. email - drift into ECE)
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/e2c4511c/attachment.html>;
📝 Original message:There are no good short-term scaling solutions...this is a very hard problem that necessarily requires a lot of out-of-the-box thinking, something 2015 has seen a LOT of...and I'm optimistic about the ideas presented thus far.
At least SW *is* a scaling solution (albeit most of the important benefits are long term). The issue of fee events has nothing to do with scaling - it has to do with economics...specifically whether we should be subsidizing transactions, who should pay the bill for it, etc. My own personal opinion is that increasing validation costs works against adoption, not for it...even if it artificially keeps fees low - and we'll have to deal with a fee event sooner or later anyhow. You may disagree with my opinion, but please, let's stop confounding the economic issues with actual scaling.
On December 16, 2015 6:21:22 PM PST, Jeff Garzik via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>On Wed, Dec 16, 2015 at 3:50 PM, Matt Corallo
><lf-lists at mattcorallo.com>
>wrote:
>
>> A large part of your argument is that SW will take longer to deploy
>than a
>> hard fork, but I completely disagree. Though I do not agree with some
>> people claiming we can deploy SW significantly faster than a hard
>fork,
>> once the code is ready (probably a six month affair) we can get it
>deployed
>> very quickly. It's true the ecosystem may take some time to upgrade,
>but I
>> see that as a feature, not a bug - we can build up some fee pressure
>with
>> an immediate release valve available for people to use if they want
>to pay
>> fewer fees.
>>
>
>That's taking a big risk. "Build up some fee pressure" is essentially
>risking a Fee Event if uptake is slower than planned, or traffic is
>greater
>than expected.
>
>
>
>>
>> On the other hand, a hard fork, while simpler for the ecosystem to
>upgrade
>> to, is a 1-2 year affair (after the code is shipped, so at least
>1.5-2.5
>> from today if we all put off heads down and work). One thing that has
>> concerned me greatly through this whole debate is how quickly people
>seem
>> to think we can roll out a hard fork. Go look at the distribution of
>node
>> versions on the network today and work backwards to get nearly every
>node
>> upgraded... Even with a year between fork-version-release and
>> fork-activation, we'd still kill a bunch of nodes and instead of
>reducing
>> their security model, lead them to be outright robbed.
>>
>
>A hard fork will never achieve 100% There are many credible folks and
>estimates who feel a May hard fork is reasonable and doable.
>
>Further, hard forks restore the full trustless nature of the
>post-hard-fork
>nodes. Soft forks continually erode that. That's why SW should come
>via
>hard fork. The end result is more secure - 100% validation of witness
>transactions.
>
>If regular hard fork plans are proposed in public, many months in
>advance,
>there is plenty of time for the community to react. Hard forks create
>a
>more predictable market and environment for Users, and a more secure
>network.
>
>Further, even if you believe SW makes hard fork unnecessary, it is the
>responsible thing to code and communicate to users the plan for a Fee
>Event
>just in case SW uptake and extension block use does not match
>theoretical
>projections of SW proponents.
>
>Finally, SW does not eliminate and is orthogonal to Short Term Problem
>#1
>(orig. email - drift into ECE)
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/e2c4511c/attachment.html>;