Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9CB30483 for ; 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 ; Wed, 5 Apr 2017 17:44:24 +0000 (UTC) Received: by mail-pg0-f53.google.com with SMTP id 21so11492245pgg.1 for ; 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 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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) 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--