<div dir="ltr"><div><div><div><div>>Criticizing 148 without suggesting a specific alternative leaves the community in disarray.<br><br></div>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. <br><br>>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.<br><br></div>This seems like a lot of reckless hand waving to me. <br><br></div>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? <br><br></div>-Chris<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Gregory Maxwell,<br></div><div><br></div><div>Criticizing 148 without suggesting a specific alternative leaves the community in disarray.<br></div><div><br></div><div>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.<br></div><div> <br></div><div>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: <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014049.html" target="_blank">https://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-April/014049.html</a>. His makes it so that SegWit default gets activated at the end of the BIP9 signalling timeframe instead of default leaving it non-activated.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>SegWit has already undergone enough testing. It is time to activate it.<br></div><div><br></div><div>Cheers,<br></div><div>Praxeology Guy<br></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>