MIME-Version: 1.0
In-Reply-To: <4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
	<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
	<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
	<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
	<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
	<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
	<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
	<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
	<0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
	<CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
	<4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
From: Lucas Clemente Vella <lvella@gmail.com>
Date: Thu, 13 Jul 2017 20:19:12 -0300
Message-ID: <CAGCathxswTnEVtAkVmTr+udu_A2V+r4PXeHxkZSLV4uzDDEqPw@mail.gmail.com>
To: Dan Libby <dan@osc.co.cr>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045f798c49e9ab05543b2a1c"
Subject: Re: [bitcoin-dev] how to disable segwit in my build?
Precedence: list

--f403045f798c49e9ab05543b2a1c
Content-Type: text/plain; charset="UTF-8"

2017-07-13 18:58 GMT-03:00 Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

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

From your perspective, the P2WPKH will look like a anyone-can-spend
transaction, thus, valid no matter who is spending. So, you would be
basically leaving the security of segwit transactions to those who actually
are interested in and using them. If your fork becomes popular, it would
decrease the security of Segwit transactions to something akin to the
security model of the Drivechain currently being discussed: only those
particularly interested in that particular sidechain (and segwit witness
could be loosely categorized into a sidechain) will be responsible to
prevent others from stealing funds from the anyone-can-spend transactions.

-- 
Lucas Clemente Vella
lvella@gmail.com

--f403045f798c49e9ab05543b2a1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-07-13 18:58 GMT-03:00 Dan Libby via bitcoin-dev <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt;</span>:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
If I understand correctly, my node will accept the incoming tx inputs<br>
but obviously will not perform any segwit related validation, thus those<br=
>
inputs are not fully validated.=C2=A0 I don&#39;t yet understand how my nod=
e<br>
thinks they are valid at all given that it does not understand P2WPKH<br>
address format, so either it doesn&#39;t need to, or P2WPKH is somehow<br>
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&#39;d be happy t=
o<br>
read that.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">From your perspecti=
ve, the P2WPKH will look like a anyone-can-spend transaction, thus, valid n=
o matter who is spending. So, you would be basically leaving the security o=
f segwit transactions to those who actually are interested in and using the=
m. If your fork becomes popular, it would decrease the security of Segwit t=
ransactions to something akin to the security model of the Drivechain curre=
ntly being discussed: only those particularly interested in that particular=
 sidechain (and segwit witness could be loosely categorized into a sidechai=
n) will be responsible to prevent others from stealing funds from the anyon=
e-can-spend transactions.<br></div><div class=3D"gmail_extra"><br>-- <br><d=
iv class=3D"gmail_signature">Lucas Clemente Vella<br><a href=3D"mailto:lvel=
la@gmail.com" target=3D"_blank">lvella@gmail.com</a></div>
</div></div>

--f403045f798c49e9ab05543b2a1c--