path: root/bd/6a54f406ce6f1afcda7cbd4ac0a30b4dbadad2

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 9CB30483
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Apr 2017 17:44:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com [74.125.83.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F746130
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Apr 2017 17:44:24 +0000 (UTC)
Received: by mail-pg0-f53.google.com with SMTP id 21so11492245pgg.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 05 Apr 2017 10:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purse.io; s=google;
	h=date:from:to:subject:message-id:mail-followup-to:mime-version
	:content-disposition:in-reply-to:user-agent;
	bh=DmLvTTWnh7TIKWMVQe8waYoVU3u7kXOlztJkfYA4mt0=;
	b=hanbN6skm7IksTd5M5TWQZE07Oo+ydTlhld2u3dnsPPMIulFwUNVpskKAhYyYnede6
	S9iN+nqmRi830n6ddHPikfv9zNUW81nD/xW4gKYr9evL51IvnBB3RCvrBE6yZJtuJqu9
	M0WJVtVynfRtuobBranqrHOGIdag7ShZMeglk=
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:subject:message-id:mail-followup-to
	:mime-version:content-disposition:in-reply-to:user-agent;
	bh=DmLvTTWnh7TIKWMVQe8waYoVU3u7kXOlztJkfYA4mt0=;
	b=kl4PdHyM80hjJqi+44k8hb5BYNITM4DdoQ6JUJAI13YLGOWB0jpfn8leAiT0nIqoFp
	bftQyNLJ8RzbZolsCcrgKtGiCrPky8e9bDsJk6xo8MxH5xgygP64a5+dziKxy3cGMY/u
	4/XtG8Kh3RSrPyC3yCKiKMr7GuWfgG0hDGRPKWBgkF+xt0EtHhTYZcJeKUPESfKro9Xw
	5VQfwlwCfSSjEZ6IatVyne6gwOxOcBp5V3J5mrM8Boimyv3VQq3hdvhlR937d7e8ceBX
	sJeYoCJnZGVVHTA6w7dJe03RpRXUw9tsyvkXeQoaXqDnV/mssbz1NQWdxVzg0ZT1pF7V
	xSuA==
X-Gm-Message-State: AFeK/H2BOkseUJr3BW/COOzv1ZEX+xJ08+wCAsrN2WKQ3QveagFaLhaRw4MZ/ePDzI6Hng==
X-Received: by 10.98.103.75 with SMTP id b72mr30493716pfc.105.1491414263603;
	Wed, 05 Apr 2017 10:44:23 -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
	n67sm32193471pfk.44.2017.04.05.10.44.22
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 05 Apr 2017 10:44:22 -0700 (PDT)
Date: Wed, 5 Apr 2017 10:43:43 -0700
From: Christopher Jeffrey <chjj@purse.io>
To: jl2012@xbt.hk, bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20170405174343.GA7180@gmail.com>
Mail-Followup-To: jl2012@xbt.hk, bitcoin-dev@lists.linuxfoundation.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
In-Reply-To: <B15790EC-B298-4F6A-BEBF-AF8C3DA74EED@xbt.hk>
User-Agent: Mutt/1.8.0 (2017-02-23)
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FAKE_REPLY_C, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.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, 05 Apr 2017 17:44:25 -0000


--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Johnson,

Really appreciate the comments. I know this idea is your baby.

> so the authors don=E2=80=99t consider segwit as a consensus-layer solutio=
n to
> increase transaction throughput, or not think segwit is safe? But
> logically speaking if segwit is not safe, this BIP could only be
> worse. OTOH, segwit also obviously increases tx throughput, although
> it may not be as much as some people wish to have.

Segwit wasn't considered to be a part of that statement. It was
referring to the numerous hardfork proposals we've seen over the past
few years. Segwit is safe, but wouldn't be a comparable block size
increase to what ext. blocks could potentially offer.

> I think extension block in the proposed form actually breaks BIP141.
> It may say it activates segregated witness as a general idea, but not
> a specific proposal like BIP141

Agreed. Needs to be reworded as it currently stands. Though, I suppose
it would be possible to allow for compatibility with segwit in the
mainchain if we utilize your idea of using a separate wit. program
versions for the extension block. A slightly minor change to the spec,
just a big change to the reference impl. code. It is doable.

> This hits the biggest question I asked in my January post: do you want
> to allow direct exit payment to legacy addresses? As a block reorg
> will almost guarantee changing txid of the resolution tx, that will
> permanently invalidate all the child txs based on the resolution tx.
> This is a significant change to the current tx model. To fix this, you
> need to make exit outputs unspendable for up to 100 blocks. Doing
> this, however, will make legacy wallet users very confused as they do
> not anticipate funding being locked up for a long period of time. So
> you can=E2=80=99t let the money sent back to a legacy address directly, b=
ut
> sent to a new format address that only recognized by new wallet, which
> understands the lock up requirement. This way, however, introduces
> friction and some fungibility issues, and I=E2=80=99d expect people using
> cross chain atomic swap to exchange bitcoin and xbitcoin

Yes, this issue is probably the biggest edge case in the proposal.

I think there's two possible solutions:

First solution:

Like you said, add a maturity requirement for exiting outputs. Likely
lower than coinbase's 100 block requirement. To solve the issue of
non-upgraded wallets not being aware of this rule and spending early,
have upgraded mempool implementations accept/relay txs that contain
early spends of exits, but not mine them until they are mature. This way
non-upgraded wallets do not end up broadcasting transactions that are
considered invalid to the rest of the network.

Depending on how wallets handle reorgs, a non-upgraded wallet may put
reorg'd spend chains from exits back into an unconfirmed state, when in
reality they should probably delete them or mark them conflicted in some
way. This may be an acceptable compromise as the wallet will still see
the funds as unconfirmed when they really don't exist anymore, but maybe
unconfirmed is good enough. Users are pretty used to dropping
non-confirming txs from their wallet, and this is much better than
legacy wallets seeing there funds as confirmed when they could be
permanently reorged out at any moment.

Second solution:

Move all exiting outputs to the coinbase. This will enforce a 100 block
maturity requirement and non-upgraded wallets will be aware of this.

The first solution might require more implementation, but allows more
flexibility with the maturity requirement. The second solution is
possibly simpler, but sticks to a hard 100 block limit.

> 1. Is it acceptable to have massive txid malleability and transaction
> chain invalidation for every natural happening reorg?  Yes: the
> current spec is ok; No: next question (I=E2=80=99d say no)

Answered above.

> 2. Is locking up exit outputs the best way to deal with the problem?
> (I tried really hard to find a better solution but failed)

You've probably thought about this more than anyone, so I'd say yes, it
may be the only way. Painful, but necessary.

> 3. How long the lock-up period should be? Answer could be anywhere
> from 1 to 100

I imagine having something lower than 100 would be preferable to users,
maybe somewhere in the 5 to 15 range. A 15 block reorg on mainnet is
seriously unlikely unless something strange is happening. A 5 block
reorg is still pretty unlikely, but possible. The coinbase solution only
allows for 100 blocks though.

> 4. With a lock-up period, should it allow direct exit to legacy
> address? (I think it=E2=80=99s ok if the lock-up is short, like 1-2 block=
=2E But
> is that safe enough?)

I think so. Adding a kind of special address probably creates more
issues than it solves.

> 5. Due to the fungibility issues, it may need a new name for the
> tokens in the ext-block

I suppose the market will decide whether that's the case.

It's worth noting, if segwit is not activated on the mainchain, it
creates a much bigger incentive to use the extension block, and
potentially ensures that users will have less of a reason to exit.

--
Christopher Jeffrey (JJ) <chjjeffrey@gmail.com>
CTO & Bitcoin Menace, purse.io
https://github.com/chjj

--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEtLH2LbrAhOMz86BKiWKrneZma70FAljlLM8ACgkQiWKrneZm
a722dQf/SjTjDIcN84PsqWhjDwSnL+H/v5PJ3jG9xRpFmlXOZr+dYttX5DzGm5bq
TBMWOCb50ldtfGvFFCxrxxLOvDx4dJTjqFX+JSZZICAEEl00AWi6NKNMa/ZsMIF5
FM8JmGfum5Etnzle6vwLkSxx+opbcyCDYIPvduoiKUJtJbxXFkJaiSFJy0YFvMlQ
tPm5HUGIBepJ3yquI6pjZnOhJpZzfq5kwFbDo44Qg2H+cznD80OvvCCZlck6Lpsb
9Puyo89l2xGhlH+Ajz4TbDl0GBQAzfz+swP7juwLcUpygAgfT+vqcXGikWm1nLmk
nf0Il3Yc0WRLRH3Dvx1YQ/H+Ri1WOA==
=/1G3
-----END PGP SIGNATURE-----

--C7zPtVaVf+AK4Oqc--