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 B07B6CB5 for ; Thu, 13 Jul 2017 22:50:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f195.google.com (mail-qt0-f195.google.com [209.85.216.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8392142 for ; Thu, 13 Jul 2017 22:50:33 +0000 (UTC) Received: by mail-qt0-f195.google.com with SMTP id v31so7948992qtb.3 for ; Thu, 13 Jul 2017 15:50:33 -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=msQLJpnu6vLSib4g0UY3YAUeOpOj4FjxBGzWBnGz1wk=; b=tdKGVrZ77u4zxRf/7u4SaksRXUQFq7f8waPwOY5seUXSCOo1wQixEM6JC0BYQpUw0j +LPf3pV0ixezI2nBy7m1F/1OURZx98mpVljFgJfVIlt5LMxoE7YICNHLX8ugB39ZQ5Mp gXJlJX49or56Yv+FvQC6QrWKgOucXQ+vIkr8sJ8Btl9LFQNiapCICfopqYGP1FLN1vLo 36+QeuL9h+eGGDsQpIz3rbSfBvI/ewx9czi5ZQshNSlKykcKttBC57rqQEWoNQoPGZyd Sm0jhbQiYphkQGhbEe7Ary1q8G4LFfuBAe29RVh/wMx4tM8d3MC/aBwrkpJH+V8EGXKH /dDA== 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=msQLJpnu6vLSib4g0UY3YAUeOpOj4FjxBGzWBnGz1wk=; b=J0oLbQFHhQ4BUY/MIsNE3rYsZpQ3ChdShcSlyL4mEZtvAhR6p7CH15O8qRGIur6Kmq 9O4w4mYhzHPbbP/qYMjVXiUij1ACnE0xXtT6aARB8x0W7nXZyFjIr58rpzSMUyr2WOmW 6RpMj0rRxirtfQAr0T8I1eK8DVAELAzp68syJEu8tR56x8YvqiXKXfVDUvqHW2AymfND HUqLZfVheGouwyA1c/xjlD6NHxKdEAPA57VjSjbROoTuP9hBJ+wEY3C5VyTPY3K9faxY PnS31l8oISSbOfINvwgnaHa26fQHajsODD2Ob2hT4Qdp3xJZgScby/hY67ONRGdwFIpl ZfTA== X-Gm-Message-State: AIVw112UY9h9yLLQx/I/NZXzskfrqfwSUTLtevWHUONiF+lbHDO+Cozu dXmKnJb74DB+AI/FzFik35Aa5tv5F+i+m3Aouw== X-Received: by 10.200.51.23 with SMTP id t23mr8761374qta.38.1499986232999; Thu, 13 Jul 2017 15:50:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.186.175 with HTTP; Thu, 13 Jul 2017 15:50:32 -0700 (PDT) In-Reply-To: <4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@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> <4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr> From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= Date: Fri, 14 Jul 2017 00:50:32 +0200 Message-ID: To: Dan Libby , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a114109f09603fe05543ac2b0" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no 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 23:35:25 +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 22:50:35 -0000 --001a114109f09603fe05543ac2b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I would like to understand it a bit better, as I think it applies equally to any pre-segwit node, yes? So let's say I am running 0.13.0 and someone sends me bitcoins to a P2PKH address, but that person previously received them to a P2WPKH address. Yes, this applies to all non-SegWit nodes. > If I understand correctly, my node will accept the incoming tx inputs but obviously will not perform any segwit related validation, thus those inputs are not fully validated. Yes. So you have two choices to be fully secure: 1. Validate using the new rules of the network (in other words, run a SegWit node) 2. Avoid any chain of transaction that contains a SegWit transaction > I don't yet understand how my node thinks they are valid at all given that it does not understand P2WPKH address format, so either it doesn't need to, or P2WPKH is somehow already valid. So how softforks often work is that you make the transaction appear to be always spendable for old nodes, regardless if it really was spendable or not. This will make sure it is a softfork, the update is backwards compatible. If it would be the other way around, if new rules that the node doesn't understand would always be invalid, it would be hardfork, which is what we're trying to avoid in the first place. > so if someone can point me towards a document that explains it I'd be happy to read that. See https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_com= patibility So the witness program is encoded in a new format that old nodes do not understand. This means that for old nodes, a number >0 will be put on the stack. When the script is done, it will be evaluated to true (because of >0) and be counted as a valid spend. https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also explains the new witness program more in detail (I left out some details in my explanation). Cheers Hampus 2017-07-13 23:58 GMT+02:00 Dan Libby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > On 07/13/2017 09:35 AM, Jameson Lopp wrote: > > > > > > On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev > > > > 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 tha= t > > > 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 y= ou > > > 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 wer= e > > at one point in time encumbered by a P2SH output. > > fair enough. This actually wasn't an area I'd considered much before > Hampus brought it up. > > I would like to understand it a bit better, as I think it applies > equally to any pre-segwit node, yes? So let's say I am running 0.13.0 > and someone sends me bitcoins to a P2PKH address, but that person > previously received them to a P2WPKH address. > > If I understand correctly, my node will accept the incoming tx inputs > but obviously will not perform any segwit related validation, thus those > inputs are not fully validated. I don't yet understand how my node > thinks they are valid at all given that it does not understand P2WPKH > address format, so either it doesn't need to, or P2WPKH is somehow > already valid. I know this has all been discussed in the past, so if > someone can point me towards a document that explains it I'd be happy to > read that. > > thanks! > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a114109f09603fe05543ac2b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I would like to understand it a bit better,= as I think it applies
equally to any pre-segwit node, yes?=C2=A0 =C2=A0So let's say I am runn= ing 0.13.0
and someone sends me bitcoins to a P2PKH address, but that person
previously received them to a P2WPKH address.

Yes, this applie= s to all non-SegWit nodes.

> If I understand correctly, my node w= ill accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those inputs are not fully validated.

Yes.
So you= have two choices to be fully secure:
1. Validate using the new rules of= the network (in other words, run a SegWit node)
2. Avoid any= chain of transaction that contains a SegWit transaction

= > I don't yet understand how my node
thinks they are valid at all given that it does not understand P2WPKH
address format, so either it doesn't need to, or P2WPKH is somehow
already valid.

So how softforks often work is that you m= ake the transaction appear to be always spendable for old nodes, regardless= if it really was spendable or not. This will make sure it is a softfork, t= he update is backwards compatible.
If it would be the other w= ay around, if new rules that the node doesn't understand would always b= e invalid, it would be hardfork, which is what we're trying to avoid in= the first place.

> so if
someone can point me towards a document that explains it I'd be happy t= o
read that.

See https://github.com/= bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_compatibility
<= /div>
So the witness program is encoded in a new format that old nodes = do not understand.
This means that for old nodes, a number &g= t;0 will be put on the stack. When the script is done, it will be evaluated= to true (because of >0) and be counted as a valid spend.
=
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also= explains the new witness program more in detail (I left out some details i= n my explanation).

Cheers
Hampus

2017-07-13 = 23:58 GMT+02:00 Dan Libby via bitcoin-dev <bitcoin-dev= @lists.linuxfoundation.org>:
On 07/13/2017 09:35 AM, Jameson Lopp wrote:
>
>
> On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> <bitcoin-d= ev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>>= ; wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 07/13/2017 06:39 AM, Hampus Sj=C3=B6berg via bit= coin-dev wrote:
>=C2=A0 =C2=A0 =C2=A0>> I believe that a good reason not to wish y= our node to be segwit
>=C2=A0 =C2=A0 =C2=A0> compliant is to avoid having to deal with the = extra bandwidth that
>=C2=A0 =C2=A0 =C2=A0> segwit could require.=C2=A0 =C2=A0Running a 0.= 14.2 node means being ok with >1MB
>=C2=A0 =C2=A0 =C2=A0> blocks, in case segwit is activated and widely= used. Users not
>=C2=A0 =C2=A0 =C2=A0> interested in segwit transactions may prefer t= o keep the cost of their
>=C2=A0 =C2=A0 =C2=A0> node lower.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> If the majority of the network decides to depl= oy SegWit, it would be in
>=C2=A0 =C2=A0 =C2=A0> your best interest to validate the SegWit tran= sactions, because you
>=C2=A0 =C2=A0 =C2=A0> might will be downgraded to near-SPV node vali= dation.
>=C2=A0 =C2=A0 =C2=A0> It would be okay to still run a "non-SegW= it" node if there's no SegWit
>=C2=A0 =C2=A0 =C2=A0> transactions in the chain of transactions for = your bitcoins, otherwise
>=C2=A0 =C2=A0 =C2=A0> you cannot fully verify the the ownership of y= our bitcoins.
>=C2=A0 =C2=A0 =C2=A0> I'm not sure the practicality of this in t= he long run, but it makes a
>=C2=A0 =C2=A0 =C2=A0> case for having an up-to-date non-SegWit node,= although I think it's a
>=C2=A0 =C2=A0 =C2=A0> bit of a stretch.
>
>=C2=A0 =C2=A0 =C2=A0Right.=C2=A0 Well, if I never upgrade to segwit, th= en there seems little
>=C2=A0 =C2=A0 =C2=A0(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 we= re
> at one point in time encumbered by a P2SH output.

fair enough.=C2=A0 This actually wasn't an area I'd consider= ed much before
Hampus brought it up.

I would like to understand it a bit better, as I think it applies
equally to any pre-segwit node, yes?=C2=A0 =C2=A0So let's say I am runn= ing 0.13.0
and someone sends me bitcoins to a P2PKH address, but that person
previously received them to a P2WPKH address.

If I understand correctly, my node will accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those inputs are not fully validated.=C2=A0 I don't yet understand how my nod= e
thinks they are valid at all given that it does not understand P2WPKH
address format, so either it doesn't need to, or P2WPKH is somehow
already valid.=C2=A0 I know this has all been discussed in the past, so if<= br> someone can point me towards a document that explains it I'd be happy t= o
read that.

thanks!
______________________________= _________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a114109f09603fe05543ac2b0--