I've long thought about using SIGHASH_SINGLE, then either party can add inputs
to cover whatever fee they want on channel close and it doesn't have to be
pre-planned at setup.
For Lightning I think you'd want to cross-sign, e.g. Alice signs her input
and Bob's output, while Bob signs his input and
On Fri, Nov 30, 2018 at 9:50 AM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> To partially-address the CPFP security model considerations, a next step
> might involve tweaking Lightning's commitment transaction to have two
> small-value outputs which are immediatel
(cross-posted to both lists to make lightning-dev folks aware, please
take lightning-dev off CC when responding).
As I'm sure everyone is aware, Lightning (and other similar systems)
work by exchanging pre-signed transactions for future broadcast. Of
course in many cases this requires either (
Hmm, you may be correct that this doesn't (striclty speaking) imply a
change to the BIP 125 itself, though the high-level protocol here is
likely of interest to the list, as well as likely to generate feedback.
Note that in your example, output Z must be CSV-delayed (ie you cannot
construct a p
