Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-30 📝 Original message:On Thu, Jul 30, 2015 at ...
📅 Original date posted:2015-07-30
📝 Original message:On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille at gmail.com>
> So what do you think the scalability road map should look like? Should we
> wait to hard fork until Blockstream Elements is ready for deploying on the
> main network, and then have One Grand Hardfork that introduces all the
> scalability work you guys have been working on (like Segregated Witness and
> Lightning)?
Apparently lightning doesn't require Segregated Witnesses: cltv and
rcltv may be enough (although I'm not up to date to the latest
designs). I definitely don't think we should wait to have SW ready to
be deployable in Bitcoin to have other hardforks. I think we should
have an uncontroversial hardfork as soon as possible, if anything, to
set a precedent and show the world that hardforks are possible in
Bitcoin, see https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#code
> Or is the plan to avoid controversy by people voluntarily moving their
> bitcoin to a sidechain where all this scaling-up innovation happens?
Any scaling up innovation that happens in sidechains can be adopted by
Bitcoin too.
In fact, some of those changes (like op_maturity/rcltv/scv) are needed
in Bitcoin for a fully p2p Bitcoin sidechain to be even possible.
I really think lightning should be possible in Bitcoin main (and not
just sidechains) as soon as possible.
> And any plan that requires inventing brand-new technology is going to be
> riskier than scaling up what we already have and understand, which is why I
> think it is worthwhile to scale up what we have IN ADDITION TO working on
> great projects like Segregated Witness and Lightning.
Not necessarily. How are older payment channels designs (different
from lightning) that don't even require cltv riskier than a hardfork?
In any case, yes, both things are kind of orthogonal and we can work
on both (and more) at the same time.
📝 Original message:On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille at gmail.com>
> So what do you think the scalability road map should look like? Should we
> wait to hard fork until Blockstream Elements is ready for deploying on the
> main network, and then have One Grand Hardfork that introduces all the
> scalability work you guys have been working on (like Segregated Witness and
> Lightning)?
Apparently lightning doesn't require Segregated Witnesses: cltv and
rcltv may be enough (although I'm not up to date to the latest
designs). I definitely don't think we should wait to have SW ready to
be deployable in Bitcoin to have other hardforks. I think we should
have an uncontroversial hardfork as soon as possible, if anything, to
set a precedent and show the world that hardforks are possible in
Bitcoin, see https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#code
> Or is the plan to avoid controversy by people voluntarily moving their
> bitcoin to a sidechain where all this scaling-up innovation happens?
Any scaling up innovation that happens in sidechains can be adopted by
Bitcoin too.
In fact, some of those changes (like op_maturity/rcltv/scv) are needed
in Bitcoin for a fully p2p Bitcoin sidechain to be even possible.
I really think lightning should be possible in Bitcoin main (and not
just sidechains) as soon as possible.
> And any plan that requires inventing brand-new technology is going to be
> riskier than scaling up what we already have and understand, which is why I
> think it is worthwhile to scale up what we have IN ADDITION TO working on
> great projects like Segregated Witness and Lightning.
Not necessarily. How are older payment channels designs (different
from lightning) that don't even require cltv riskier than a hardfork?
In any case, yes, both things are kind of orthogonal and we can work
on both (and more) at the same time.