summaryrefslogtreecommitdiff
path: root/69/ec3dd6d6a8fdc6432784ef9f04956f5f61269e
blob: 820f038fd2450fa8adad1b7b61462d71389b13a1 (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
Return-Path: <dan@osc.co.cr>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A672DB49
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Jul 2017 21:58:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.osc.co.cr (unknown [168.235.79.83])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2873D168
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Jul 2017 21:58:15 +0000 (UTC)
Received: from [192.168.2.3] (miner1 [71.94.45.245])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested) (Authenticated sender: danda)
	by mail.osc.co.cr (Postfix) with ESMTPSA id 7B4CD1F015
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Jul 2017 14:58:14 -0700 (PDT)
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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>
From: Dan Libby <dan@osc.co.cr>
Message-ID: <4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
Date: Thu, 13 Jul 2017 14:58:04 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
	Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE
	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 22:23:49 +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 21:58:15 -0000

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-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>     On 07/13/2017 06:39 AM, Hampus Sjöberg 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.

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!