Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
Good morning Antoine,
> Biggest gains with Eltoo are of course transaction symmetry and removing
> toxic waste. Reintroducing penalty on top of
> this shouldn't affect this two goals,
I agree with Christian that introducing penalty introduces toxic waste.
Inadvertent misuse of a backup of an old database will still result in
punishment.
Indeed, this is part of the toxic waste problem: operator error can lead to
loss of funds.
> > If a later Litigation Tx is used, than the Update Tx that was put onchain,
> > is the signature from the Update Tx valid on the same transaction where the
> > Challenge Tx is valid?
>
> Main idea of this scheme is to used Per-Update Commitment to solve the
> assignment problem in a safe way. What we need
> on a higher-level are messages tied to a specific party and committed to a
> given state number. If anyone can prove to the
> blockchain you have broadcast 2 messages with different state number it means
> you breach the contract.
>
> Now how to do that with Script ? Only messages interpreted by the blockchain
> are bitcoin transactions.
>
> If we follow Taproot current transaction digest algorithm, without sighash
> flags set, assuming we spend a taproot output
> we have the following hashed elements : epoch, hash_type, nVersion,
> nLockTime, sha_prevouts, sha_amounts,
> sha_sequences, sha_outputs, spend_type, input_index, sha_annex.
>
> If we use SIGHASH_ANYPREVOUTANYSCRIPT + SIGHASH_NONE, we get the following
> hashed elements :
> epoch, hash_type, nVersion, nLocktime, spend_type, amount, nSequence,
> sha_annex.
>
> If we force to sign 2 different transactions with these both sighashes
> against same pubkey, and assuming there are
> spending the same amount and nSequences are equals, we should get identical
> signatures. If they are not,
> the only difference element is the nLocktime.
>
> That could be a way to make script aware of committed per-party state number.
>
> Using this in a Eltoo-Penalty scheme, the Challenge tx script is encumbered
> by a branch where if you show up
> with 2 valid signatures but non-identical, that's a proof the challenged
> party has tried to cheat. Of course, I guess
> you need a bit of expansion on script primitives, like
> SIGHASH_ANYPREVOUTANYSCRIPTANYAMOUNT and
> an OP_CHECKSIG_WITH_STATE_NUMBER with following syntax
> OP_CSWSN
> and following semantic "verify this signature against this pubkey but first
> mask nLocktime of transaction with the
> second-to-top stack item". Because signatures need to be both valid on same
> transaction but they have committed
> to different nLocktime, Justice tx need to have a mutable nLocktime field at
> verification.
>
> I didn't think about the need of something like OP_CSWSN in first mail, some
> people pointed me the issue, so here
> the updated scripts.
This requires adding more at the base layer, which is much more strongly
contentious (at the Lightning layer you can arrange to use whatever
construction you want with your peer, and in general still be able to route,
except that with anything other than Poon-Dryja channels also have a minimum
CSV delay that needs to be considered by the source).
At what little I understand there is not much consensus yet at Bitcoin
blockchain layer to add *any* vsriant of `SIGHASH_NOINPUT` yet.
But now this construction requires, in addition to `SIGHASH_NOINPUT`:
* Pubkeys that require specific `SIGHASH` flags in their signature.
* A way to validate that a particular signature commits to a particular
`nLockTime`.
The only advantage this construction has on top of Poon-Dryja is the ability to
have 3 or more participants.
The disadvantages relative to Poon-Dryja are:
* A CSV restriction on routed HTLCs.
* Needs *much* more to be added to the blockchain, including 1 controversial
feature (admittedly has a reasonable chance of appearing in some form) and 2
completely new features (which will need to be very strongly reviewed in
bitcoin-dev and elsewhere first).
---
Now I believe you agree that channel factories are better:
> "I would argue that channel factories are better used than multiparticipant
> channels, as channel factories allow *some* limited transport of funds even
> if one participant is offline, whereas multiparticipant channels prevent
> *all* transport of funds as soon as any one participant is offline"
>
> I agree too
So let me counterpropose instead:
* Use Decker-Wattenhofer (mostly the multiple-stage decrementing `nSequence`
part, drop the duplex Spilman-like channels) or Decker-Russell-Osuntokun
("eltoo") at the Factory level.
* Do not allow participants to hold a singlesig output at the Factory level,
all states at this level should have only 2-of-2s that back channels.
* Use Poon-Dryja at the Channel level for all channels inside the factory.
This prevents thieves from *practically* stealing with old factory-level state,
since the funds are still in individual Poon-Dryja channels.
When you
Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
Hi ZmnSCPxj,
Awesome resume, it's better lay-out than I did myself !!
> Thus, I would like to thank you for your tolerance and continued
attention.
Personally, it's a pleasure to read your weird but always thoughtful
proposals in other threads :)
"We have identified two requirements:
1. We must identify which participant initiated the unilateral close
onchain.
We do so that if later, we find that the unilateral close was to an
older state, we can punish the participant that initiated the unilateral
close.
2. We must identify that a unilateral close was, in fact, to an older
state."
I think you have well-scoped the assignment problem. But it would add
another requirement :
3. Identity commitment must not be replayable or counterfeited by another
participant.
I thought to use unique preimage in a previous versions of my proposal but
it seems really unsafe due to reorgs and mempool snooping. If another
channel participant is able to take back your identity preimage and uses it
to spend with a lower state update tx you are know flagged as the
cheater. So we want preimage to be tied to a state number and best scheme
I've thought of is not using preimage but signatures.
May we build a commitment with preimage and state number without signatures
?
> * comment: we use the common key, and the requirement to provide the
Alice fingerprint preimage, *and* the requirement to enable RBF, to force
the output to be revoked to miners as fees: when the entire output is given
as fee, no higher RBF is possible.
* comment: outputs may become too tiny to care about if we
split up a tiny reserve between dozens of honest participants.
On the other side, giving back funds to participants let them cover back
the expenses to pay onchain fees for last state enforcement.
> * Add branches for revocation, where proof that one side attempted to
steal allows the other side to control the coin immediately.
Hmm that's the point we argue a lot, but by broadcasting a previous update,
if HTLC is Bob->Caroll, Bob didn't only try to rob Caroll
but potentially every others channel participants. Why they should get a
part of Bob funds as compensation ?
> It is safe to publish the revocation key if you publish only the latest
Update Transaction, as the latest Update Transaction cannot enable any
Litigation Transaction.
Exact, even if you're a honest participant you have to commit to a secret
or revocation key, because the blockchain can
only know after the nSequence expiration delay of the Friendly Settlement
transaction that you are honest.
Le lun. 15 juil. 2019 à 05:58, ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> a écrit :
> Good morning list,
>
> As usual, I am spamming the list for my amusement.
>
> Thus, I would like to thank you for your tolerance and continued attention.
>
>
>
> We have identified two requirements:
>
> 1. We must identify which participant initiated the unilateral close
> onchain.
> We do so that if later, we find that the unilateral close was to an
> older state, we can punish the participant that initiated the unilateral
> close.
> 2. We must identify that a unilateral close was, in fact, to an older
> state.
>
> Thus, I will counterpropose a construction similar to that originally
> proposed here, but with the weaknesses fixed and key details filled in.
> (while part of it is similar to the Decker-Russell-Osuntokun "eltoo", it
> is different enough that I would not suggest calling it "eltoo-penalty")
>
>
>
> On initiation, Alice, Bob, and Charlie indicate:
>
> * Alice/Bob/Charlie "fingerprint" hash/preimage.
> Alice/Bob/Charlie publish the fingerprint hashes, but keep the
> fingerprint preimages secret.
> * Alice/Bob/Charlie "normal" pubkey.
> * Alice/Bob/Charlie "lawyer" pubkey.
> * All participants indicate a `delay`, a number of blocks.
> Funds may be locked, in worst case, up to `2 * delay`.
>
> We also introduce a "common" key whose private key is known to all
> participants.
> For example, we can use a key whose private key is `SHA256("ZmnSCPxj is a
> human being and not any kind of AI")` as a consensus-accepted fact.
>
> We have the below transactions:
>
> * Funding transaction
> * inputs: unspecified
> * outputs:
> * change output(s): unspecified
> * funding output:
> * Internal Taproot Key: `P = MuSig(Alice normal pubkey, Bob normal
> pubkey, Charlie normal pubkey)`
> * Scripts:
> * `OP_1 OP_CHECKSIGVERIFY OP_HASH160
> OP_EQUALVERIFY`
> * `OP_1 OP_CHECKSIGVERIFY OP_HASH160
> OP_EQUALVERIFY`
> * `OP_1 OP_CHECKSIGVERIFY OP_HASH160
> OP_EQUALVERIFY`
>
> * Update Transaction
> * comment: this transaction initiates a unilateral close attempt.
> * comment: Updates have a "hidden" `n`, which is an "update" number
> incrementing from 0.
> This number could be encoded as `nLockTime` by using `500e6 + n`, but
> in principle does not need to be encoded there (we could use the current
Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
Hi ZmnSCPxj, > Just a minor correction here: your own commitment transactions are not > being signed until we want to release them. Therefore having access to > your DB doesn't give an attacker the ability to frame the user with an > old version, since that'd still require access to the keys to add our > own signature. Okay, do you plan to handover keys to the watchtower to be able to sign and broadcast local commitment transactions or are you thinking about another design like giving him signed commitment ? That's an area we still need to think more for rust-lightning too. > And this signature is intended to be used to identify Alice as the culprit, by also being used to sign for , but `SIGHASH_ALL` would strongly bind the signature to this particular transaction. Okay, you maybe also need a special pubkey type to force signatures to use a given SIGHASH. that's a lot of tricks but that could be a use-case for taproot introducing key types. > Now, an economically-maximizing thief would prefer to steal as much as possible, thus such a thief would initiate a channel, then send out funds until only 1% is left to the thief, then "freeze" the channel (fail all incoming HTLCs from this channel without bothering to check if they would succeed) until the participant is offline, then perform the theft attempt by using their initial commitment (the one where they own all the funds in the channel). I think it's quite dubious to base our reasoning on current network situation and from then say on-chain fees in Eltoo model are enough to deter attackers (or even lazy parties). Channels are going to increase in size and people are learning how they are structured. With more knowledge of timeout locks and deltas, attackers may try to game them, specially by exploiting others elements like mempool congestion or eclipse your onchain node. I see penalty as the price the attacker have to pay to test your onchain monitoring setup. If it's cheap and the probabilities to win are high, given he is able to trouble confirmation of your update tx, a rational attacker will try. "Still, a node could refuse incoming channel open requests for Decker-Russell-Osuntokun that are larger than 100 times the typical fee for a 1-input 1-output transaction, and still get similar protection to Poon-Dryja using the de facto standard 1% reserve" And maybe people are going to limit of their channels to stay in a multiple of onchain fees, but they may also refuse to open channel with unknown or "untrusted" parties. Relying on economical incentives is better than social ones. > Such outputs have shared ownership, as the offerer of the HTLC will be able to reclaim the money after the timelock, and the accepter of the HTLC will be able to reclaim the money before the timelock. Yes, I think a contract design principle is that we should enforce an order of claims between different channel participants. In a multiparty channel between Alice, Bob, Caroll and Dave, if Alice offered a HTLC to Bob and then cheats, if Bob come with a preimage to unlock the HTLC, his claim shouldn't be canceled by the punitive one raised by Bob, Caroll or Dave. "I would argue that channel factories are better used than multiparticipant channels, as channel factories allow *some* limited transport of funds even if one participant is offline, whereas multiparticipant channels prevent *all* transport of funds as soon as any one participant is offline" I agree too, with my current proposal I was just thinking in multiparty setup and not a 2-party one because it's far more adversarial. IMO, channel factories are a better design because I would say the "valuespace" is well isolated between participants.I.e if Alice has 1, Bob has 1, Caroll has 3, Alice shouldn't be able offer a HTLC worth 3 to Bob. It's more tricky to enforce on a multiparty channel rather than on a channel factory. > Let us consider what happens if Alice the thief performs the theft attempt during various states: > * Suppose the current state is that Charlie owns the entire funds of the channel right now. > Alice steals by publishing old state, but the old-state Alice->Bob HTLC is revocable only by Bob. > Thus the money (that rightfully belongs to Charlie) goes to Bob instead. > * Alice and Bob could be in cahoots, with Bob as the mastermind and Alice as the fall guy. > * Suppose we decide that the Alice->Bob HTLC is revocable split by Bob and Charlie. > Suppose the current state is that Bob owns the entire funds of the channel right now. > Alice steals by publishing old state, but the old-state Alice->Bob HTLC is revocable split by Bob and Charlie. > Thus the money (that rightfully belongs only to Bob) goes partly to Charlie instead. > * Alice and Charlie could be in cahoots, with Charlie as the mastermind and Alice as the fall guy. If a HTLC output is claimable by both a preimage + sig from a channel participant or MuSig from all channel participants to a punitive tx, the punitive tx may be
