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 D651D480 for ; Tue, 9 May 2017 00:57:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com [74.125.83.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED1CD12C for ; Tue, 9 May 2017 00:57:11 +0000 (UTC) Received: by mail-pg0-f47.google.com with SMTP id o3so43836594pgn.2 for ; Mon, 08 May 2017 17:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purse.io; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=D5IfxSHRAlUgGw5/qfzGXFMYQybeZaV8x/6tX4aytSk=; b=iiTyRQ+ra2o9yLrEzvmokN2uJ6IwC4dWX4SPizpV/31oKla1xyc9tnXCCi7nwKZECk HpouAqJBf4DT2Ya0Xu9nMhbqC1ld4mIgT7A2tMbxktud616qzmxNj+V4NwPBFKsOFgyP 1x3OzEe42MPppdxuMOmuto0U9nSdO4GyWUAGI= 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:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=D5IfxSHRAlUgGw5/qfzGXFMYQybeZaV8x/6tX4aytSk=; b=E/3pEpZANU2FeJbDKAd5Scx8y/ieFku4oBgKt+85XUX149FA+UsiJhmoayxnfICA2W X1AgbaDRLxtL6DR/k+7JqarSmROvRoi1smbGC18l5s6WUaUqfV9n3eykz8kDtVZNMHdv uwCcRXgpp8Op2l8n/UOyn4l/SHpPjOtten7z6eMaRg24q5r7vYj9uTs3T/Ro9SaCoq5c BDTBFZO6+p28aHBFfhpsHSVM5LJ8jxFxGL9fO9A5uXRh4skt9sPjXcIE8N/k5aSQ1SfC fBpj3jZl9663C3/RFEmYyknbrpfi8rLC0Viov6XVOmWovm3aNkI4A/cUaE5YiQ2R6a8V Wa5A== X-Gm-Message-State: AN3rC/6kRxOvcUrWFNYcn61Ka32UvPxQaR/gGuTWi5XFSv/RjQwaRNiX XxIEqQq875lSGInxgp0= X-Received: by 10.98.50.67 with SMTP id y64mr35044190pfy.117.1494291431398; Mon, 08 May 2017 17:57:11 -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 m18sm3426149pfj.108.2017.05.08.17.57.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 May 2017 17:57:10 -0700 (PDT) Date: Mon, 8 May 2017 17:56:59 -0700 From: Christopher Jeffrey To: Johnson Lau Message-ID: <20170509005659.GA1902@gmail.com> Mail-Followup-To: Johnson Lau , bitcoin-dev References: <20170405174343.GA7180@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 00:57:13 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 On Mon, Apr 10, 2017 at 06:14:36PM +0800, Johnson Lau wrote: > > > On 6 Apr 2017, at 01:43, Christopher Jeffrey wrote: > > > > > >> 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= , but > >> 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 us= ing > >> 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. > > This won=E2=80=99t solve the problem. Think about the following conversat= ion: > > Alice (not upgraded): Please pay 1 BTC to my address 1ALicExyz > Bob (upgraded): ok, paid, please check > > 10 minutes later > > Alice: received and confirmed, thanks! > > 5 minutes later: > > Carol (not upgraded): Please pay 0.5BTC to my address 3CaroLXXX > Alice: paid, please check > > 1 hour later: > > Carol: it=E2=80=99s not confirmed. Have you paid enough fees? > Alice: ok, I=E2=80=99ll RBF/CPFP it > > 2 hours later: > > Carol: it=E2=80=99s still not confirmed. > Alice: I have already paid double fees. Maybe the network is congested an= d I need to pay more=E2=80=A6.. > > Repeat until the lock up period ends. > > So this so-called =E2=80=9Csoftfork=E2=80=9D actually made non-upgraded w= allet totally unusable. If failed to meet the very important requirement of= a softfork: backward compatibility > > More discussion: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013985= =2Ehtml > > > > > > 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. > > This is also unacceptable. > > When someone says "Please pay 1 BTC to my address 1ALicExyz=E2=80=9D, no = one anticipates being paid by a coinbase output. Some exchanges like btc-e = explicitly reject coinbase payment. > > Such deterioration in user experience is unacceptable. It basically force= s everyone to upgrade, i.e. a hardfork with soft fork=E2=80=99s skin > > > > > > > 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 bl= ock. But > >> is that safe enough?) > > > > I think so. Adding a kind of special address probably creates more > > issues than it solves. > > > As I explained above, no legacy wallet would anticipate a lock up. If you= want to make a softfork, all burden of incompatibility must be taken by th= e upgraded system. Only allow exit to a new address guarantees that only up= graded wallet will see the locked-up tx: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/0134= 90.html > > > >> 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. > > > > I think it=E2=80=99s unacceptable if malleability is not fixed in main ch= ain, for 3 reasons: > > 1. a solution is *already* available and tested for > 1 year. > > 2. the deactivation design (which I think is an interesting idea) makes t= he ext block unsuitable for long-term storage of value. > > 3. LN over main chain allows instant exchange of main coin and xcoin with= out going through the ugly 2-way-peg process. > > > -- Christopher Jeffrey (JJ) CTO & Bitcoin Menace, purse.io https://github.com/chjj --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEtLH2LbrAhOMz86BKiWKrneZma70FAlkRE9oACgkQiWKrneZm a73ahggAjFWylouuYj2+7qoOiqQsYHG+RaAEHGz5y+bSOc4aHkDW4k1+xtgLRrbA 2k7nF4bWrXUdun8P4oZfwXJR+bI78tcARUfZRaAmBlEUtdSPhnNf9ednS2dDn3Z8 TLn/vND3k4y1j12Dy+2rWLxoGH/fHnn2Rf6YU/5cvOdUITuJanyjNSMr8LSsxVzk Z/W3VTnrvD9nnjUcgI+ljiIf21ft214JdKC+6igERLeAScCOtvlqlmFtK0crTQVK D3kuOo0BdLKMWXDEnM6wOyaCbmS6fNWjK1qB9ydt5JQtRsB2HWzghiVBpF0Jg1AI mcLQX3rD/460G7/pO/NVvu+Ay2e4MQ== =ErAo -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c--