rich1.0npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4njumphttps://nostr.ae📅 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>