public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Hampus Sjöberg" <hampus.sjoberg@gmail.com>
To: Federico Tenga <federicotenga@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] how to disable segwit in my build?
Date: Thu, 13 Jul 2017 15:39:40 +0200	[thread overview]
Message-ID: <CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com> (raw)
In-Reply-To: <CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]

> 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.

Greetings
Hampus

2017-07-13 15:11 GMT+02:00 Federico Tenga via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> Can you explain why you wish to do this?  It should have absolutely no
>> adverse impact on you-- if you don't use segwit, you don't use it-- it
>> may be the case that there is some confusion about the implications
>> that I could clear up for you... or suggest alternatives that might
>> achieve your goals.
>>
>
> 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3033 bytes --]

  reply	other threads:[~2017-07-13 13:39 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10 16:50 [bitcoin-dev] Updating the Scaling Roadmap Paul Sztorc
2017-07-11 16:03 ` Chris Stewart
2017-07-11 16:49   ` Adam Back
2017-07-11 20:01   ` Pieter Wuille
2017-07-11 20:36     ` Paul Sztorc
2017-07-11 21:40       ` Pieter Wuille
2017-07-11 22:49         ` Paul Sztorc
2017-07-11 21:16     ` CryptAxe
2017-07-11 20:18   ` Paul Sztorc
2017-07-11 21:31     ` Gregory Maxwell
2017-07-11 22:27       ` Paul Sztorc
2017-07-11 21:11 ` Gregory Maxwell
2017-07-11 21:40   ` Gregory Maxwell
2017-07-11 22:17   ` Paul Sztorc
2017-07-11 22:41     ` Tao Effect
2017-07-11 22:57       ` Paul Sztorc
2017-07-11 23:12         ` Tao Effect
2017-07-12  0:21           ` Paul Sztorc
2017-07-12  7:27             ` Jacob Eliosoff
2017-07-12 19:19           ` Chris Stewart
2017-07-12 19:24             ` Tao Effect
2017-07-12 19:34               ` Chris Stewart
2017-07-12 19:42                 ` Tao Effect
2017-07-12 19:54                   ` CryptAxe
2017-07-12 21:55                     ` Tao Effect
2017-07-12 22:07                       ` CryptAxe
2017-07-11 23:36     ` Bryan Bishop
2017-07-12  0:07     ` Gregory Maxwell
2017-07-12  1:40       ` Paul Sztorc
2017-07-12  2:48         ` Bryan Bishop
2017-07-12  3:33         ` Gregory Maxwell
2017-07-12  6:17           ` [bitcoin-dev] how to disable segwit in my build? Dan Libby
2017-07-13  1:04             ` Gregory Maxwell
2017-07-13 13:11               ` Federico Tenga
2017-07-13 13:39                 ` Hampus Sjöberg [this message]
2017-07-13 16:19                   ` Dan Libby
2017-07-13 16:35                     ` Jameson Lopp
2017-07-13 21:58                       ` Dan Libby
2017-07-13 22:50                         ` Hampus Sjöberg
2017-07-13 23:20                           ` Dan Libby
2017-07-14  8:52                             ` Hampus Sjöberg
2017-07-14  9:03                             ` Tier Nolan
2017-07-13 23:19                         ` Lucas Clemente Vella
2017-07-13 16:05               ` Dan Libby
2017-07-14 21:11               ` Troy Benjegerdes
2017-07-13  1:48             ` Anthony Towns
2017-07-13 16:13               ` Dan Libby
2017-07-12  1:22   ` [bitcoin-dev] Updating the Scaling Roadmap Karl Johan Alm
2017-07-12  9:37     ` Tom Zander
2017-07-12  9:02   ` Tom Zander
2017-07-11 23:28 ` Anthony Towns
2017-07-17 17:13 ` [bitcoin-dev] Updating the Scaling Roadmap [Update] Paul Sztorc
2017-07-17 18:49   ` Alex Morcos
2017-07-17 20:13     ` Paul Sztorc
2017-07-17 21:50     ` Peter Todd
     [not found]   ` <20170717214704.ksegcrdqf3zeslah@fedora-23-dvm>
2017-07-17 22:04     ` Paul Sztorc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com \
    --to=hampus.sjoberg@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=federicotenga@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox