From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C0463AF0 for ; Thu, 13 Jul 2017 16:35:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4F7FF175 for ; Thu, 13 Jul 2017 16:35:47 +0000 (UTC) Received: by mail-oi0-f48.google.com with SMTP id x187so50658387oig.3 for ; Thu, 13 Jul 2017 09:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=IOwMgUviVm4eeyq6VY2pfhayMXVBRE7M1FsWuKYVy0I=; b=dQnVa6yHYTvPuJzi0Bc1LCQq8veLF5YcWtL1AU+N/TSwKXMTAaEpkNP5AXu1wbjnGG WYoOnRilPqGRnaYjlFyjtzC+KtR8YgYWNAskzdOnuiW7004mLWFrt6FfF7eUcjcTrDI4 f31GqVdYY4AxL3Gw4sGfQdnKagMlJfagxYEEDNO37HYPWkWPg+gQpc9eRViJZ41FodYy t4mCXS99OnyDhTeE1/aKLY1uq1Phy2asQgg+HG26P78/ohnEqPJ15Jouht2uqFGjiYxH pMTXR2o5szNf+pQBXlKEBr026Y66QI/k5+faLs+iNlnE1kZ17nKeqfQCjtF/bYTqKAkk 1cag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=IOwMgUviVm4eeyq6VY2pfhayMXVBRE7M1FsWuKYVy0I=; b=JzXh/UgGBrWmWBkUwKUGuvlSKVkRfhWjwq9W4tUyY+zVHSI9SagKywJAcGC/oWJPnq gUuc3gcjzlavg8+3x4FSWdG3MU2BjFgKTt3zJuWC9Yyq2bJAGbn4xS6pkO+5n7Ma4D9I E53PCoKD1HFfpmkOdC/Q9rXt7qvODvWJz4stlxBJ1gRRlSW5ou+19w38lO/wEQpoAvRN /zuOKKLxQczdwPmQsxDTgYCEkKHL1HxccfI1mOd/1rHPts+BEyqDATWQjjabCK+NOHNw /gfFZelLJgc+u1glP51yHsdQn6uE7RWjG6ofOgorQbFUgNVXGq0nEISLzciudh6wv3qG a3ZA== X-Gm-Message-State: AIVw112u3GYeaMwitvCaLEeL5uYBeLyx6W+YCY4Ex7xA6Z3QVA9hsh6v WOPjfrMBJG/rLE6t8Z1K25gF6nFwqA== X-Received: by 10.202.88.69 with SMTP id m66mr2766256oib.204.1499963746673; Thu, 13 Jul 2017 09:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.175.76 with HTTP; Thu, 13 Jul 2017 09:35:46 -0700 (PDT) In-Reply-To: <0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr> References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> <001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com> <03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr> <0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr> From: Jameson Lopp Date: Thu, 13 Jul 2017 12:35:46 -0400 Message-ID: To: Dan Libby , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a113d37c84be8f905543586f5" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 13 Jul 2017 17:00:00 +0000 Subject: Re: [bitcoin-dev] how to disable segwit in my build? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 16:35:47 -0000 --001a113d37c84be8f905543586f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 07/13/2017 06:39 AM, Hampus Sj=C3=B6berg 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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113d37c84be8f905543586f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On 07/13/2017 06:39 AM, Ha= mpus Sj=C3=B6berg 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.=C2=A0 =C2=A0Running 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 i= n
> 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&#= 39;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 make= s a
> case for having an up-to-date non-SegWit node, although I think it'= ;s a
> bit of a stretch.

Right.=C2=A0 Well, if I never upgrade to segwit, then there seems li= ttle
(zero?) risk of having any segwit tx in my tx chain.


If you mean you wish to avoid receivin= g UTXOs that have value that was at one point previously encumbered by a Se= gWit output then no, you can't avoid that. No more than you can current= ly avoid receiving BTC that were at one point in time encumbered by a P2SH = output.
=C2=A0
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.=C2=A0 more just somethin= g of
an experiment.
______________________________= _________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a113d37c84be8f905543586f5--