From: Johnson Lau <jl2012@xbt•hk>
To: Christopher Jeffrey <chjj@purse•io>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
Date: Wed, 10 May 2017 01:56:28 +0800 [thread overview]
Message-ID: <BBB06F5F-4AC4-4FFD-AD1C-5304140E56C6@xbt.hk> (raw)
In-Reply-To: <20170509005659.GA1902@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]
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>
>
[-- Attachment #2: Type: text/html, Size: 15564 bytes --]
next prev parent reply other threads:[~2017-05-09 17:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 18:03 Luke Dashjr
2017-04-04 18:35 ` Johnson Lau
2017-04-05 14:05 ` Olaoluwa Osuntokun
2017-04-05 15:37 ` Greg Sanders
2017-04-05 16:25 ` Joseph Poon
2017-04-05 17:04 ` Johnson Lau
2017-04-05 17:43 ` Christopher Jeffrey
2017-04-10 10:14 ` Johnson Lau
2017-05-09 0:56 ` Christopher Jeffrey
2017-05-09 17:56 ` Johnson Lau [this message]
2017-05-10 1:19 ` Christopher Jeffrey
2017-04-05 16:54 ` Christopher Jeffrey
2017-04-06 17:18 ` Luke Dashjr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BBB06F5F-4AC4-4FFD-AD1C-5304140E56C6@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=chjj@purse$(echo .)io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox