[bitcoin-dev] Making OP_TRUE standard?

Peter Todd pete at petertodd.org
Wed May 9 20:59:14 UTC 2018


On Thu, May 10, 2018 at 04:19:31AM +0800, Johnson Lau wrote:
> 
> 
> > On 10 May 2018, at 3:27 AM, Peter Todd <pete at petertodd.org> wrote:
> > 
> > On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote:
> >> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set
> >> 
> >> 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’t need to ask for any protocol change.
> >> 
> >> 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.
> > 
> > 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.
> > 
> > -- 
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> 
> My only concern is UTXO pollution. There could be a “CPFP anchor” 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’t need CPFP at all.

I don't see any reason why UTXO pollution would be a special concern so long as
those outputs are subject to the same dust rules as any other output is.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180509/17714285/attachment.sig>


More information about the bitcoin-dev mailing list