Chris Stewart [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-14 📝 Original message:>Criticizing 148 without ...
📅 Original date posted:2017-04-14
📝 Original message:>Criticizing 148 without suggesting a specific alternative leaves the
community in disarray.
I really disagree with this sentiment, you don't need to provide
alternatives to criticize a technical proposal. I don't like this "active
segwit at all costs" theme that has been going around the community. I am a
fan of segwit, but we shouldn't push things through in an unsafe manner.
>If 148 causes orphaning and a fork, I don't think such really matters in
the long term. The non-SegWit miners will probably just quickly give up
their orphans once they realize that money users like being able to have
non-mutable TX IDs. If they do create a long lasting branch... well that
is good too, I'd be happy to no longer have them in our community. Good
luck to them in creating a competitive money, so that we can all enjoy
lower transaction fees.
This seems like a lot of reckless hand waving to me.
Food for thought, why are we rejecting *all* blocks that do not signal
segwit? Can't we just reject blocks that *do not* signal segwit, but *do*
contain segwit transactions? It seems silly to me that if a miner mines a
block with all pre segwit txs to reject that block. Am I missing something
here?
-Chris
On Fri, Apr 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Gregory Maxwell,
>
> Criticizing 148 without suggesting a specific alternative leaves the
> community in disarray.
>
> I know you are emphasizing patience. But at the same time, with your
> patience we are allowing ourselves to get dicked for longer than necessary.
>
> I think that core could easily develop code that could create a
> solid/reliable date/height based activation to allow miners to create
> SegWit block candidates and having nodes fully verify them. Shaolinfry is
> the only person Ive seen actually make such a proposal:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-April/014049.html. His makes it so that SegWit default gets
> activated at the end of the BIP9 signalling timeframe instead of default
> leaving it non-activated.
>
> I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a
> Denial of Service, given that other activation methods are available.
> Someone just needs to code something up that is better that we can all use
> in a satisfying time frame. So far 148 is the most practical and reliable
> method I'm aware of.
>
> If 148 causes orphaning and a fork, I don't think such really matters in
> the long term. The non-SegWit miners will probably just quickly give up
> their orphans once they realize that money users like being able to have
> non-mutable TX IDs. If they do create a long lasting branch... well that
> is good too, I'd be happy to no longer have them in our community. Good
> luck to them in creating a competitive money, so that we can all enjoy
> lower transaction fees.
>
> SegWit has already undergone enough testing. It is time to activate it.
>
> Cheers,
> Praxeology Guy
>
> _______________________________________________
> 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/20170414/065e4fee/attachment.html>;
📝 Original message:>Criticizing 148 without suggesting a specific alternative leaves the
community in disarray.
I really disagree with this sentiment, you don't need to provide
alternatives to criticize a technical proposal. I don't like this "active
segwit at all costs" theme that has been going around the community. I am a
fan of segwit, but we shouldn't push things through in an unsafe manner.
>If 148 causes orphaning and a fork, I don't think such really matters in
the long term. The non-SegWit miners will probably just quickly give up
their orphans once they realize that money users like being able to have
non-mutable TX IDs. If they do create a long lasting branch... well that
is good too, I'd be happy to no longer have them in our community. Good
luck to them in creating a competitive money, so that we can all enjoy
lower transaction fees.
This seems like a lot of reckless hand waving to me.
Food for thought, why are we rejecting *all* blocks that do not signal
segwit? Can't we just reject blocks that *do not* signal segwit, but *do*
contain segwit transactions? It seems silly to me that if a miner mines a
block with all pre segwit txs to reject that block. Am I missing something
here?
-Chris
On Fri, Apr 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Gregory Maxwell,
>
> Criticizing 148 without suggesting a specific alternative leaves the
> community in disarray.
>
> I know you are emphasizing patience. But at the same time, with your
> patience we are allowing ourselves to get dicked for longer than necessary.
>
> I think that core could easily develop code that could create a
> solid/reliable date/height based activation to allow miners to create
> SegWit block candidates and having nodes fully verify them. Shaolinfry is
> the only person Ive seen actually make such a proposal:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-April/014049.html. His makes it so that SegWit default gets
> activated at the end of the BIP9 signalling timeframe instead of default
> leaving it non-activated.
>
> I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a
> Denial of Service, given that other activation methods are available.
> Someone just needs to code something up that is better that we can all use
> in a satisfying time frame. So far 148 is the most practical and reliable
> method I'm aware of.
>
> If 148 causes orphaning and a fork, I don't think such really matters in
> the long term. The non-SegWit miners will probably just quickly give up
> their orphans once they realize that money users like being able to have
> non-mutable TX IDs. If they do create a long lasting branch... well that
> is good too, I'd be happy to no longer have them in our community. Good
> luck to them in creating a competitive money, so that we can all enjoy
> lower transaction fees.
>
> SegWit has already undergone enough testing. It is time to activate it.
>
> Cheers,
> Praxeology Guy
>
> _______________________________________________
> 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/20170414/065e4fee/attachment.html>;