đź“… Original date posted:2018-05-09
đź“ť Original message:> 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.
If one has a "root" commitment with other nested descendent
multi-transaction contracts, then changing the txid of the root commitment
will invalidated all the nested multi tx contracts. In our specific case, we
have pre-signed 2-stage HTLC transaction which rely on a stable txid. As a
result, we can't use the ANYONECANPAY approach atm.
> 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.
Agreed, see the recent proposal to introduce SIGHASH_NOINPUT as a new
sighash type. IMO it presents an opportunity to introduce more flexible fine
grained sighash inclusion control.
-- Laolu
On Wed, May 9, 2018 at 11:12 AM Johnson Lau via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> 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.
>
>
>
> > On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Hi all,
> >
> > The largest problem we are having today with the lightning
> > protocol is trying to predict future fees. Eltoo solves this elegantly,
> > but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> > commitment transactions so that we use minimal fees and then use CPFP
> > (which can't be done at the moment due to CSV delays on outputs).
> >
> > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> > non-standard. Are there any reasons not to suggest such a policy
> > change?
> >
> > Thanks!
> > Rusty.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180509/e98eb0d4/attachment.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-07 18:11:56
in reply to nevent1q…3gkm
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-07 18:11:56Event JSON
{
"id": "0a0bcc8fa3d4a67e57f2d6e1dae2f8acf216a1cf8e57b9c505e0c9a4d49d2f45",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686161516,
"kind": 1,
"tags": [
[
"e",
"caee4e3828cad70a0aa9bfba9569480bc6157a528d4896eeab11f571613a9d97",
"",
"root"
],
[
"e",
"eeec3c20a2bf6fc4d4f999db1a7ec95224a2c5d3d3d1b94c32052f94800c5434",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2018-05-09\n📝 Original message:\u003e Instead, would you consider to use ANYONECANPAY to sign the tx, so it is\n\u003e possible add more inputs for fees? The total tx size is bigger than the\n\u003e OP_TRUE approach, but you don’t need to ask for any protocol change.\n\nIf one has a \"root\" commitment with other nested descendent\nmulti-transaction contracts, then changing the txid of the root commitment\nwill invalidated all the nested multi tx contracts. In our specific case, we\nhave pre-signed 2-stage HTLC transaction which rely on a stable txid. As a\nresult, we can't use the ANYONECANPAY approach atm.\n\n\u003e In long-term, I think the right way is to have a more flexible SIGHASH\n\u003e system to allow people to add more inputs and outputs easily.\n\nAgreed, see the recent proposal to introduce SIGHASH_NOINPUT as a new\nsighash type. IMO it presents an opportunity to introduce more flexible fine\ngrained sighash inclusion control.\n\n-- Laolu\n\n\nOn Wed, May 9, 2018 at 11:12 AM Johnson Lau via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e You should make a “0 fee tx with exactly one OP_TRUE output” standard, but\n\u003e nothing else. This makes sure CPFP will always be needed, so the OP_TRUE\n\u003e output won’t pollute the UTXO set\n\u003e\n\u003e Instead, would you consider to use ANYONECANPAY to sign the tx, so it is\n\u003e possible add more inputs for fees? The total tx size is bigger than the\n\u003e OP_TRUE approach, but you don’t need to ask for any protocol change.\n\u003e\n\u003e In long-term, I think the right way is to have a more flexible SIGHASH\n\u003e system to allow people to add more inputs and outputs easily.\n\u003e\n\u003e\n\u003e\n\u003e \u003e On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e Hi all,\n\u003e \u003e\n\u003e \u003e The largest problem we are having today with the lightning\n\u003e \u003e protocol is trying to predict future fees. Eltoo solves this elegantly,\n\u003e \u003e but meanwhile we would like to include a 546 satoshi OP_TRUE output in\n\u003e \u003e commitment transactions so that we use minimal fees and then use CPFP\n\u003e \u003e (which can't be done at the moment due to CSV delays on outputs).\n\u003e \u003e\n\u003e \u003e Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is\n\u003e \u003e non-standard. Are there any reasons not to suggest such a policy\n\u003e \u003e change?\n\u003e \u003e\n\u003e \u003e Thanks!\n\u003e \u003e Rusty.\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180509/e98eb0d4/attachment.html\u003e",
"sig": "5515ef337efdd7a47b1f366ad160124e062a0f28aede4ebcce9f7ca9d62a559408014ab98c68ca4825c0a4a3e6ea71e0853341c677a9a327e1fc58ebdabd29e2"
}