📅 Original date posted:2017-07-13 📝 Original message:On Thu, Jul 13, 2017 at ...

Jameson Lopp [ARCHIVE] /

npub1ghg…kqmn

2023-06-07 18:04:26

in reply to nevent1q…peuc

📅 Original date posted:2017-07-13
📝 Original message:On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
> >> I believe that a good reason not to wish your node to be segwit
> > compliant is to avoid having to deal with the extra bandwidth that
> > segwit could require. Running a 0.14.2 node means being ok with >1MB
> > blocks, in case segwit is activated and widely used. Users not
> > interested in segwit transactions may prefer to keep the cost of their
> > node lower.
> >
> > If the majority of the network decides to deploy SegWit, it would be in
> > your best interest to validate the SegWit transactions, because you
> > might will be downgraded to near-SPV node validation.
> > It would be okay to still run a "non-SegWit" node if there's no SegWit
> > transactions in the chain of transactions for your bitcoins, otherwise
> > you cannot fully verify the the ownership of your bitcoins.
> > I'm not sure the practicality of this in the long run, but it makes a
> > case for having an up-to-date non-SegWit node, although I think it's a
> > bit of a stretch.
>
> Right. Well, if I never upgrade to segwit, then there seems little
> (zero?) risk of having any segwit tx in my tx chain.
>
>
If you mean you wish to avoid receiving UTXOs that have value that was at
one point previously encumbered by a SegWit output then no, you can't avoid
that. No more than you can currently avoid receiving BTC that were at one
point in time encumbered by a P2SH output.

> Thus this would be a way I could continue with a lower bandwidth cap and
> also keep my coins "untainted", so to speak.
>
> I'm not sure about it for the long run either. more just something of
> an experiment.
> _______________________________________________
> 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/20170713/406a3f3b/attachment.html>;

Author Public Key

npub1ghgfr3aumwuxwnwghywxpaejxpf6k9pjcnyg9lfdnztlu5pwa0ksyakqmn

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 18:04:26

Kind type

1 Short Text Note

Event JSON

{ "id": "307a85a3b4d73f6dca5849ece7edf6391843ad0b28e666dfc93a5e1837067a18", "pubkey": "45d091c7bcdbb8674dc8b91c60f7323053ab1432c4c882fd2d9897fe502eebed", "created_at": 1686161066, "kind": 1, "tags": [ [ "e", "c3417a9d5ad76947acf26c6783addd471ca3bcc5d3ed57deae65203b0eaf5238", "", "root" ], [ "e", "a76be4f4b92f548f7d4df711a4e57be8cbd5cfb52a8f77549ab54b6a666b27f8", "", "reply" ], [ "p", "bee276d1ae3341411bf36280d4da29fe701581dff23dcd2a5d7ac65535f7d8f9" ] ], "content": "📅 Original date posted:2017-07-13\n📝 Original message:On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:\n\u003e \u003e\u003e I believe that a good reason not to wish your node to be segwit\n\u003e \u003e compliant is to avoid having to deal with the extra bandwidth that\n\u003e \u003e segwit could require. Running a 0.14.2 node means being ok with \u003e1MB\n\u003e \u003e blocks, in case segwit is activated and widely used. Users not\n\u003e \u003e interested in segwit transactions may prefer to keep the cost of their\n\u003e \u003e node lower.\n\u003e \u003e\n\u003e \u003e If the majority of the network decides to deploy SegWit, it would be in\n\u003e \u003e your best interest to validate the SegWit transactions, because you\n\u003e \u003e might will be downgraded to near-SPV node validation.\n\u003e \u003e It would be okay to still run a \"non-SegWit\" node if there's no SegWit\n\u003e \u003e transactions in the chain of transactions for your bitcoins, otherwise\n\u003e \u003e you cannot fully verify the the ownership of your bitcoins.\n\u003e \u003e I'm not sure the practicality of this in the long run, but it makes a\n\u003e \u003e case for having an up-to-date non-SegWit node, although I think it's a\n\u003e \u003e bit of a stretch.\n\u003e\n\u003e Right. Well, if I never upgrade to segwit, then there seems little\n\u003e (zero?) risk of having any segwit tx in my tx chain.\n\u003e\n\u003e\nIf you mean you wish to avoid receiving UTXOs that have value that was at\none point previously encumbered by a SegWit output then no, you can't avoid\nthat. No more than you can currently avoid receiving BTC that were at one\npoint in time encumbered by a P2SH output.\n\n\n\u003e Thus this would be a way I could continue with a lower bandwidth cap and\n\u003e also keep my coins \"untainted\", so to speak.\n\u003e\n\u003e I'm not sure about it for the long run either. more just something of\n\u003e an experiment.\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170713/406a3f3b/attachment.html\u003e", "sig": "51ac8300e893847c3b1ffa673a5645e8a7b03ffb7fc6f213e53afa399db2285f959149b2f8de4ddd609c991a101db228f9f82b3ec55d1be7a1db00cf5b38b180" }