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 7A2EA957 for ; Tue, 9 May 2017 17:56:37 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B3A01D8 for ; Tue, 9 May 2017 17:56:36 +0000 (UTC) Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by mx.zohomail.com with SMTPS id 1494352592543758.1537345238635; Tue, 9 May 2017 10:56:32 -0700 (PDT) From: Johnson Lau Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_65CBB807-ADD2-4F85-94BA-25868159BF79" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 10 May 2017 01:56:28 +0800 In-Reply-To: <20170509005659.GA1902@gmail.com> To: Christopher Jeffrey References: <20170405174343.GA7180@gmail.com> <20170509005659.GA1902@gmail.com> X-Mailer: Apple Mail (2.3259) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:56:37 -0000 --Apple-Mail=_65CBB807-ADD2-4F85-94BA-25868159BF79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 wrote: >=20 > Johnson, >=20 > Yeah, I do still see the issue. I think there are still some = reasonable > ways to mitigate it. >=20 > 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. >=20 > 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. >=20 > [1] https://github.com/tothemoon-org/extension-blocks/pull/16 = >=20 --Apple-Mail=_65CBB807-ADD2-4F85-94BA-25868159BF79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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

= --Apple-Mail=_65CBB807-ADD2-4F85-94BA-25868159BF79--