summaryrefslogtreecommitdiff
path: root/c5/7b1e1bdb77ebce9477b7b719fc66b59d234723
blob: 8333388d1ee9ef81121d9ae19c3e5a98358b0da9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
Return-Path: <lvella@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3B29EB77
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Jul 2017 23:19:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com
	[209.85.215.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6965C142
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Jul 2017 23:19:34 +0000 (UTC)
Received: by mail-lf0-f47.google.com with SMTP id t72so45098024lff.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Jul 2017 16:19:34 -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=cVArfkwaDmmdmeCbpR3qwD0txYu1SDA95DTMIUi9HC0=;
	b=LT783fhSMsPxT7vwwUZvwya1vLzJ/J2VfPAEtsRepsXkqJBlpQ8eBzSN1LfaspGXN6
	oyuzmyzyX2DDoqD9l6oqwnEiftegn3YwySPIY3J6wGr7d3DmlALK+AHXxrwaZF4E0HRB
	gFYoYRR5u+DMGzORTqf3jT/trx0JPvsNbmVPAlUq88PMxWHpZKlqtb5KolA/SGm+hHsX
	wvfB7filUKlshnMAsL9xnkjbBZrTyyx+alFZjrDDVCcf6opw7tMrh4uZAfG5o1GQQRFt
	bHyK/P628OwZkR7KUWIY7IOBo2GLfZJiUBKGKs4+BSRbAM+1FnEvKAE60CzeZNoTUiiW
	yLKA==
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=cVArfkwaDmmdmeCbpR3qwD0txYu1SDA95DTMIUi9HC0=;
	b=Y35FhYLR/OWaVrKDMyinBo2TA8G4V3wihQFmOB8PTXxxT4d3/ITSymXCmYS0o7nkIX
	5rxD1XZpZ5LcBaame4kXIeTBDC7mzQd4kyJCKYubnx6ZqL3JYfdVNF6k9XTBTretNoG7
	4OtORq6uoXJ+EwG2DMLm3frFaGcJZHYKBDA3X1HwU2G0x5tnbFMnXMksRV657uEMOjXL
	gqK0Y0/NHCvUg4SinHQBtQNjNS8WltvrsTVp9vFzf59vRI6yGwVg5ju6qLtV7eEklr8x
	OWClcpBv75TvAhpoc0l0GqCpZpcrw+nXweMPC2kW+MBpsf/jIe7GvwUzmQtgIEWcoLbL
	Onjg==
X-Gm-Message-State: AIVw113ABQSMKcVzw578Uea6fPGDYLVi6dhWIceNvLAPjAEijzijsLv9
	1xxdCcDYhwocfOgcRVi+OQSdnP63cXXY
X-Received: by 10.46.70.9 with SMTP id t9mr2067149lja.40.1499987972838; Thu,
	13 Jul 2017 16:19:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.43.65 with HTTP; Thu, 13 Jul 2017 16:19:12 -0700 (PDT)
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"
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:36:40 +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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jul 2017 23:19:35 -0000

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