📅 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>;
Chris Stewart [ARCHIVE] /
npub1u0…dnn03
2023-06-07 18:00:03
in reply to nevent1q…pp25
Author Public Key
npub1u03cz099kt69z9awg232rjvlt34azukpzkkvy5uqv64dj9j5fqtshdnn03Published at
2023-06-07 18:00:03Event JSON
{
"id": "9d1fdc93005cbf09156dd9726f4f15324c30646b17a6743afeec4dca3f0e793f",
"pubkey": "e3e3813ca5b2f45117ae42a2a1c99f5c6bd172c115acc2538066aad916544817",
"created_at": 1686160803,
"kind": 1,
"tags": [
[
"e",
"5d1e64c970da07b0178aa4b0869114a6c0b54023e99bc79f83d180601afc646b",
"",
"root"
],
[
"e",
"5ca30595180b41a282bd0c1e67a5562a6f199ad2bcd3d968658dffbcf0d17e08",
"",
"reply"
],
[
"p",
"b8acca17a6f74c77cd8a4899846d99012d1b52082a01a2d2753fcb0c6669a60b"
]
],
"content": "📅 Original date posted:2017-04-14\n📝 Original message:\u003eCriticizing 148 without suggesting a specific alternative leaves the\ncommunity in disarray.\n\nI really disagree with this sentiment, you don't need to provide\nalternatives to criticize a technical proposal. I don't like this \"active\nsegwit at all costs\" theme that has been going around the community. I am a\nfan of segwit, but we shouldn't push things through in an unsafe manner.\n\n\u003eIf 148 causes orphaning and a fork, I don't think such really matters in\nthe long term. The non-SegWit miners will probably just quickly give up\ntheir orphans once they realize that money users like being able to have\nnon-mutable TX IDs. If they do create a long lasting branch... well that\nis good too, I'd be happy to no longer have them in our community. Good\nluck to them in creating a competitive money, so that we can all enjoy\nlower transaction fees.\n\nThis seems like a lot of reckless hand waving to me.\n\nFood for thought, why are we rejecting *all* blocks that do not signal\nsegwit? Can't we just reject blocks that *do not* signal segwit, but *do*\ncontain segwit transactions? It seems silly to me that if a miner mines a\nblock with all pre segwit txs to reject that block. Am I missing something\nhere?\n\n-Chris\n\nOn Fri, Apr 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Gregory Maxwell,\n\u003e\n\u003e Criticizing 148 without suggesting a specific alternative leaves the\n\u003e community in disarray.\n\u003e\n\u003e I know you are emphasizing patience. But at the same time, with your\n\u003e patience we are allowing ourselves to get dicked for longer than necessary.\n\u003e\n\u003e I think that core could easily develop code that could create a\n\u003e solid/reliable date/height based activation to allow miners to create\n\u003e SegWit block candidates and having nodes fully verify them. Shaolinfry is\n\u003e the only person Ive seen actually make such a proposal:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/\n\u003e 2017-April/014049.html. His makes it so that SegWit default gets\n\u003e activated at the end of the BIP9 signalling timeframe instead of default\n\u003e leaving it non-activated.\n\u003e\n\u003e I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a\n\u003e Denial of Service, given that other activation methods are available.\n\u003e Someone just needs to code something up that is better that we can all use\n\u003e in a satisfying time frame. So far 148 is the most practical and reliable\n\u003e method I'm aware of.\n\u003e\n\u003e If 148 causes orphaning and a fork, I don't think such really matters in\n\u003e the long term. The non-SegWit miners will probably just quickly give up\n\u003e their orphans once they realize that money users like being able to have\n\u003e non-mutable TX IDs. If they do create a long lasting branch... well that\n\u003e is good too, I'd be happy to no longer have them in our community. Good\n\u003e luck to them in creating a competitive money, so that we can all enjoy\n\u003e lower transaction fees.\n\u003e\n\u003e SegWit has already undergone enough testing. It is time to activate it.\n\u003e\n\u003e Cheers,\n\u003e Praxeology Guy\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170414/065e4fee/attachment.html\u003e",
"sig": "0d0a8b24b31d0bccea9ad9a0cd8833eb1f0ac08e2a94377ab9ce3b85949f9410797d88eeefb89b123c5fb23cea9ef48448f326b665f8a4cc98c8b3fc8ff345d1"
}