Good morning Bob, Would `SIGHASH_SINGLE` work? Commitment transactions have a single input but multiple outputs.
Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, December 2, 2018 11:08 PM, Bob McElrath <b...@mcelrath.org> wrote: > 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 Alice's output. This would > demotivate the two parties from picking apart the transaction and broadcasting > one of the two SIGHASH_SINGLE's in a Lightning transaction. > > Matt Corallo via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote: > > > (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 (a) predicting what the feerate required for > > timely confirmation will be at some (or, really, any) point in the future, > > or (b) utilizing CPFP and dependent transaction relay to allow parties to > > broadcast low-feerate transactions with children created at broadcast-time > > to increase the effective feerate. Ideally transactions could be constructed > > to allow for after-the-fact addition of inputs to increase fee without CPFP > > but it is not always possible to do so. > > Option (a) is rather obviously intractible, and implementation complexity > > has led to channel failures in lightning in practice (as both sides must > > agree on a reasonable-in-the-future feerate). Option (b) is a much more > > natural choice (assuming some form of as-yet-unimplemented package relay on > > the P2P network) but is made difficult due to complexity around RBF/CPFP > > anti-DoS rules. > > For example, if we take a simplified lightning design with pre-signed > > commitment transaction A with one 0-value anyone-can-spend output available > > for use as a CPFP output, a counterparty can prevent confirmation > > of/significantly increase the fee cost of confirming A by chaining a > > large-but-only-moderate-feerate transaction off of this anyone-can-spend > > output. This transaction, B, will have a large absolute fee while making the > > package (A, B) have a low-ish feerate, placing it solidly at the bottom of > > the mempool but without significant risk of it getting evicted during memory > > limiting. This large absolute fee forces a counterparty which wishes to have > > the commitment transaction confirm to increase on this absolute fee in order > > to meet RBF rules. > > For this reason (and many other similar attacks utilizing the package size > > limits), in discussing the security model around CPFP, we've generally > > considered it too-difficulty-to-prevent third parties which are able to > > spend an output of a transaction from delaying its confirmation, at least > > until/unless the prevailing feerates decline and some of the mempool backlog > > gets confirmed. > > You'll note, however, that this attack doesn't have to be permanent to work > > > > - Lightning's (and other contracting/payment channel systems') security > > model assumes the ability to get such commitment transactions confirmed > > in a > > timely manner, as otherwise HTLCs may time out and counterparties can > > claim > > the timeout-refund before we can claim the HTLC using the hash-preimage. > > > > > > 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 immediately spendable, one by each channel > > participant, allowing them to chain children off without allowng unrelated > > third-parties to chain children. Obviously this does not address the > > specific attack so we need a small tweak to the anti-DoS CPFP rules in > > Bitcoin Core/BIP 125: > > The last transaction which is added to a package of dependent transactions > > in the mempool must: > > > > - Have no more than one unconfirmed parent, > > - Be of size no greater than 1K in virtual size. > > (for implementation sanity, this would effectively reduce all mempool > > package size limits by 1 1K-virtual-size transaction, and the last > > would be > > "allowed to violate the limits" as long as it meets the above criteria). > > > > > > For contracting applications like lightning, this means that as long as the > > transaction we wish to confirm (in this case the commitment transaction) > > > > - Has only two immediately-spendable (ie non-CSV) outputs, > > - where each immediately-spendable output is only spendable by one > > counterparty, > > > > - and is no larger than MAX_PACKAGE_VIRTUAL_SIZE - 1001 Vsize, > > each counterparty will always be able to independantly CPFP the > > transaction > > in question. ie because if the "malicious" (ie transaction-delaying) > > party > > bradcasts A with a child, it can never meet the "last transaction" > > carve-out > > as its transaction cannot both meet the package limit and have only one > > unconfirmed ancestor. Thus, the non-delaying counterparty can always > > independently add its own CPFP transaction, increasing the (A, Tx2) > > package > > feerate and confirming A without having to concern themselves with the > > (A, > > Tx1) package. > > > > > > As an alternative proposal, at various points there have been discussions > > around solving the "RBF-pinning" problem by allowing transactors to mark > > their transactions as "likely-to-be-RBF'ed", which could enable a relay > > policy where children of such transactions would be rejected unless the > > resulting package would be "near the top of the mempool". This would > > theoretically imply such attacks are not possible to pull off consistently, > > as any "transaction-delaying" channel participant will have to place the > > package containing A at an effective feerate which makes confirmation to > > occur soon with some likelihood. It is, however, possible to pull off this > > attack with low probability in case of feerate spikes right after broadcast. > > Note that this clearly relies on some form of package relay, which comes > > with its own challenges, but I'll start a separate thread on that. > > See-also: lightning-dev thread about the changes to lightning spec required > > to incorporate this: > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001643.html > > Matt > > > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > !DSPAM:5c014daf168271726154759! > > -- > Cheers, Bob McElrath > > "For every complex problem, there is a solution that is simple, neat, and > wrong." > -- H. L. Mencken > > Lightning-dev mailing list > lightning-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
