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 0D513C03 for ; Wed, 9 May 2018 20:19:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4881867F for ; Wed, 9 May 2018 20:19:48 +0000 (UTC) Received: from [10.8.0.103] (n219073055009.netvigator.com [219.73.55.9]) by mx.zohomail.com with SMTPS id 1525897176043815.9761773709108; Wed, 9 May 2018 13:19:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Johnson Lau In-Reply-To: <20180509192733.6aif4wapolbb5z7c@petertodd.org> Date: Thu, 10 May 2018 04:19:31 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4E64F59E-3367-4C4E-A9FB-48ED568BC2D3@xbt.hk> References: <87po25lmzs.fsf@rustcorp.com.au> <20180509192733.6aif4wapolbb5z7c@petertodd.org> To: Peter Todd X-Mailer: Apple Mail (2.3445.5.20) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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] Making OP_TRUE standard? 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, 09 May 2018 20:19:50 -0000 > On 10 May 2018, at 3:27 AM, Peter Todd wrote: >=20 > On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev = wrote: >> You should make a =E2=80=9C0 fee tx with exactly one OP_TRUE = output=E2=80=9D standard, but nothing else. This makes sure CPFP will = always be needed, so the OP_TRUE output won=E2=80=99t pollute the UTXO = set >>=20 >> Instead, would you consider to use ANYONECANPAY to sign the tx, so it = is possible add more inputs for fees? The total tx size is bigger than = the OP_TRUE approach, but you don=E2=80=99t need to ask for any protocol = change. >>=20 >> In long-term, I think the right way is to have a more flexible = SIGHASH system to allow people to add more inputs and outputs easily. >=20 > I don't think that will work, as a zero-fee tx won't get relayed even = with > CPFP, due to the fact that we haven't yet implemented package-based tx > relaying. >=20 > --=20 > https://petertodd.org 'peter'[:-1]@petertodd.org My only concern is UTXO pollution. There could be a =E2=80=9CCPFP = anchor=E2=80=9D softfork that outputs with empty scriptPubKey and 0 = value are spendable only in the same block. If not spent immediately, = they become invalid and are removed from UTXO. But I still think the = best solution is a more flexible SIGHASH system, which doesn=E2=80=99t = need CPFP at all.=