[bitcoin-dev] Extension block proposal by Jeffrey et al

Johnson Lau jl2012 at xbt.hk
Tue May 9 17:56:28 UTC 2017


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170510/5dfbf5ba/attachment-0001.html>


More information about the bitcoin-dev mailing list