đź“… Original date posted:2018-05-09
đź“ť Original message: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>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 18:11:56
in reply to nevent1q…u8zy
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 18:11:56Event JSON
{
"id": "eeec3c20a2bf6fc4d4f999db1a7ec95224a2c5d3d3d1b94c32052f94800c5434",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686161516,
"kind": 1,
"tags": [
[
"e",
"caee4e3828cad70a0aa9bfba9569480bc6157a528d4896eeab11f571613a9d97",
"",
"root"
],
[
"e",
"705b5134917269921ce32445cd55e100f905d55d61e454409b6815acdbcf45a0",
"",
"reply"
],
[
"p",
"492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7"
]
],
"content": "📅 Original date posted:2018-05-09\n📝 Original message:On Thu, May 10, 2018 at 04:19:31AM +0800, Johnson Lau wrote:\n\u003e \n\u003e \n\u003e \u003e On 10 May 2018, at 3:27 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \u003e \n\u003e \u003e On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote:\n\u003e \u003e\u003e 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\n\u003e \u003e\u003e \n\u003e \u003e\u003e 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.\n\u003e \u003e\u003e \n\u003e \u003e\u003e 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.\n\u003e \u003e \n\u003e \u003e I don't think that will work, as a zero-fee tx won't get relayed even with\n\u003e \u003e CPFP, due to the fact that we haven't yet implemented package-based tx\n\u003e \u003e relaying.\n\u003e \u003e \n\u003e \u003e -- \n\u003e \u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e \n\u003e 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.\n\nI don't see any reason why UTXO pollution would be a special concern so long as\nthose outputs are subject to the same dust rules as any other output is.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 488 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180509/17714285/attachment.sig\u003e",
"sig": "d445ab1459bc7c267e90f5bbb00314ed7557adcf078a66be1d5e07e0a63ab9d0ddd7599c315995ac0b8ff4e79c4a1064e10a007912af13f98a12c465a1ac5f8d"
}