Open chjj opened 7 years ago
I'm pretty sure LN no longer requires SIGHASH_NOINPUT, but maybe someone else can advise better?
@afk11, segwit gave LN the malleability fix it needed, but LN can still benefit from SIGHASH_NOINPUT for easier outsourcing of blockchain monitoring. A third party can create a penalty transaction on your behalf, assuming you give them a half-created transaction and a signature ahead of time.
Explained here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html
However, it is very useful for LN if there is a certain level of outsourcibility for transactions without this 3rd party taking on onerous costs. In LN, there is a dispute resolution period established to prevent the counterparty from attesting an incorrect channel state (represented by broadcasting a timelocked transaction). In other words, if someone in a channel broadcasts an incorrect state, the output can be redeemed by a 3rd party (but this 3rd party is not a custodian, since the output goes to the other party in the channel).
There may be other use cases for LN I'm not aware of. @josephpoon or @Roasbeef would be able to fill in the blanks better than I can.
This is something I've considered for a while. I've been thinking about it more frequently for the past week or two: mainchain segwit adds a few benefits to extblk. The exclusion of mainchain segwit wasn't a very conscious technical decision initially. It was just the simplest path for the code at the time, and less complexity. I think this decision should be reexamined technically for this reason.
I've revised some major parts of the specification, mostly pertaining to how entrance into and exits from the extension block behave. The new behavior is similar to Johnson's 2017 proposal. Listing changes and potential benefits here.
Changes
Consensus
0xaa21a9ef
to0x45424c4b
(ascii: EBLK). This is to avoid confusion.P2P
getdata
inv type is used with the witness bit.getdata
witness bit.Policy
Other considerations / Todo
flags
bit set to1
(implementations must now track this). This gives an easy non-contextual check for which chain the transaction is in, which has nice implications for wallets and protocols like compact block relay. Note that the flags byte is malleable in the mempool. I also don't think the flag byte was intended to be used this way, but rather for future serialization changes.I have a preliminary reference implementation here: https://github.com/bcoin-org/bcoin-extension-blocks/tree/extblk-sw2. Everything outlined above is more or less present, but the code still needs some work and more tests.
If consider this route, I think we can have extnet2 up in a reasonable amount of time to play around with this.
Opening it up for discussion. Thoughts?
cc @gasteve @josephpoon