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
151
152
153
|
Return-Path: <chjj@purse.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B536C504
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 May 2017 01:19:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 254A31FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 May 2017 01:19:45 +0000 (UTC)
Received: by mail-pg0-f41.google.com with SMTP id 64so8183106pgb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 09 May 2017 18:19:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purse.io; s=google;
h=date:from:to:cc:subject:message-id:mail-followup-to:references
:mime-version:content-disposition:in-reply-to:user-agent;
bh=oXP9scUf8vkjuadTo5lxT5dPifzOnNQdle5Z/pdtcf4=;
b=aoSD+/1gImOGoyVCK869YGwsNiQGu2//Z2OW6sfAGd/seK1EhuO847J7nughAOER34
PBeadwz/YN9l9F3NWirR+bETbvkkdIUxZ2PAgQ/rPKfcfNyUG+MU8O1vmgIPC1wzOGMz
zqOAL7b82ZJvNxMz1bm3oweiAv4TL8HjFAbaE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id
:mail-followup-to:references:mime-version:content-disposition
:in-reply-to:user-agent;
bh=oXP9scUf8vkjuadTo5lxT5dPifzOnNQdle5Z/pdtcf4=;
b=il/bjSMa7I7lLeT5jQVRGBpBHcrRFRNzQsaUXCHFLrlnwARm/wHKwiDeNl+GfFuEh3
fYePPYs6q76eNwkSJZ1HAEz5fMbo7Gz5Ta+Zd/0qvVFyF1djEGfY7nP9HOxWSiLpdXmu
r3V0BgKmKogP30K1VCIoaeCq/f0NwzDB/ZEkDcc3pDn7fMGSOlE/g/ycZr7A1R/V5RhQ
bgcNc+ptG3qp1RyOpnbqf5dQpouOPXKyRhKEq6VzNRlmkEEvjdo0bz8i9HsnX+ySOwzY
8JbhnOYMlaz/0CURr1UQBDNs+8vLP9VB6D8uSFZOsen0QnAvPHJK1omA0IPA9OksX8/a
2aMw==
X-Gm-Message-State: AODbwcDzN0ulyTVi+4BKQUmAwHlTWhKIw6UR7T3pe+epr8vR6/VoshRn
ZyyfR76Cut6zog==
X-Received: by 10.98.160.74 with SMTP id r71mr3264021pfe.16.1494379184676;
Tue, 09 May 2017 18:19:44 -0700 (PDT)
Received: from gmail.com (96-82-67-198-static.hfc.comcastbusiness.net.
[96.82.67.198]) by smtp.gmail.com with ESMTPSA id
v62sm1839997pfv.44.2017.05.09.18.19.43
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Tue, 09 May 2017 18:19:43 -0700 (PDT)
Date: Tue, 9 May 2017 18:19:30 -0700
From: Christopher Jeffrey <chjj@purse.io>
To: Johnson Lau <jl2012@xbt.hk>
Message-ID: <20170510011930.GA14666@gmail.com>
Mail-Followup-To: Johnson Lau <jl2012@xbt.hk>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <20170405174343.GA7180@gmail.com>
<F322F899-8748-407D-884F-95EFBD3C7F99@xbt.hk>
<20170509005659.GA1902@gmail.com>
<BBB06F5F-4AC4-4FFD-AD1C-5304140E56C6@xbt.hk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV"
Content-Disposition: inline
In-Reply-To: <BBB06F5F-4AC4-4FFD-AD1C-5304140E56C6@xbt.hk>
User-Agent: Mutt/1.8.2 (2017-04-18)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU,
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
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
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: Wed, 10 May 2017 01:19:45 -0000
--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> To make it completely transparent to unupgraded wallets, the return outputs have to be sent to something that is non-standard today, i.e. not P2PK, P2PKH, P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH.
Johnson,
I feel that's not as much of an issue with v0 witness programs. Segwit
isn't activated yet, and segwit-capable wallets aren't as widely
deployed for production. Not to mention, they're all going to require
further development anyway: the address serialization for witness
programs only became a BIP this week. No segwit wallets should ever be
planning to receive money to naked witness programs right now, since
addresses are for it aren't even available.
I think we have the benefit of timing here. The state of segwit wallet
development incidentally creates a window of time where this maturity
rule can be implemented.
On Wed, May 10, 2017 at 01:56:28AM +0800, Johnson Lau wrote:
> To make it completely transparent to unupgraded wallets, the return outputs have to be sent to something that is non-standard today, i.e. not P2PK, P2PKH, P2SH, bare multi-sig, and (with BIP141) v0 P2WPKH and v0 P2WSH.
>
> Mainchain segwit is particularly important here, as that allows atomic swap between the bitcoin and xbitcoin. Only services with high liquidity (exchanges, payment processors) would need to occasionally settle between the chains.
>
>
> > On 9 May 2017, at 08:56, Christopher Jeffrey <chjj@purse.io> wrote:
> >
> > Johnson,
> >
> > Yeah, I do still see the issue. I think there are still some reasonable
> > ways to mitigate it.
> >
> > I've started revising the extension block specification/code to coexist
> > with mainchain segwit. I think the benefit of this is that we can
> > require exiting outputs to only be witness programs. Presumably segwit
> > wallets will be more likely to be aware of a new output maturity rule
> > (I've opened a PR[1] which describes this in greater detail). I think
> > this probably reduces the likelihood of the legacy wallet issue,
> > assuming most segwit-supporting wallets would implement this rule before
> > the activation of segwit.
> >
> > What's your opinion on whether this would have a great enough effect to
> > prevent the legacy wallet issue? I think switching to witness programs
> > only may be a good balance between fungibility and backward-compat,
> > probably better all around than creating a whole new
> > addr-type/wit-program just for exits.
> >
> > [1] https://github.com/tothemoon-org/extension-blocks/pull/16 <https://github.com/tothemoon-org/extension-blocks/pull/16>
> >
>
--
Christopher Jeffrey (JJ) <chjjeffrey@gmail.com>
CTO & Bitcoin Menace, purse.io
https://github.com/chjj
--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEtLH2LbrAhOMz86BKiWKrneZma70FAlkSaqIACgkQiWKrneZm
a71EJAgAmeMLug09RLsRw1hpF1v9JkjS9S3s/s7SrWLmgPc8zkgOqlEGt60TMKa2
NZjV000Dbc/C1sQhX7JyxncISY5qZYcxVx+fFM1zukdd7aH0WaThSGQx4u/4gj/u
Ss/mtjbjeIHe1bTWAILExEOrGRNaTfrl3v/bULAOUz3wjlEYS8HrfVf0+VuqglSx
SzMKWsRDGUH/IGcVAJYyEnQ/VeGMGGe/q4tH+x+LLMGhjQ//SkvbL/QrN3GZcFq9
rio6pC8XizmGqje/1HW+CyEuSo3LrfsLrntE9DukquilDysqRbCcsv2bXFN7Eo9n
6OmAYb/tpNQs6pYqRdz/T2xit3d4og==
=BKBF
-----END PGP SIGNATURE-----
--HcAYCG3uE/tztfnV--
|
