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
Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
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 encoding
in Poon-Dryja, which is encrypted so that normal unilateral closes do not
reveal how many updates occurred).
* Update transaction might have other inputs/outputs used to pay for onchain
fees.
* input:
* Funding transaction output
* witness: one of the following, depending on which participant initiated
the unilateral close:
* ` sign(MuSig(A normal, B normal, C normal),
SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_SINGLE)`
* ` sign(MuSig(A normal, B normal, C normal),
SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_SINGLE)`
* ` sign(MuSig(A normal, B normal, C
normal), SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_SINGLE)`
* comment: which witness script appears onchain depends on which
participant initiated the unilateral close.
* output:
* Internal Taproot Key: `MuSig(A normal, B normal, C normal)`
* Scripts:
* ` OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG`
* This is the "normal" unilateral path where the participant did not
steal any funds.
* `<500e6 + n + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG`
* This is the "litigation" path where the participant is proven to have
stolen funds by showing a litigation transaction with later `n` than the update
transaction.
* Friendly Settlement Transaction
* comment: This transaction completes a unilateral close attempt and
publishes all contracts transported in the channel without revocability
branches.
* `nSequence`: ``
* input:
* Update transaction output
* witness: `sign(MuSig(A normal, B normal, C normal),
SIGHASH_ANYPREVOUTANYSCRIPT)`
* outputs: unencumbered outputs for this state.
* Litigation Transaction
* comment: The appearance of this transaction onchain is taken as proof that
the unilateral close attempt is definitely a theft attempt.
It can only be broadcast and confirmed if and only if the unilateral close
Update Transaction has an `n` that is less than the latest agreed `n`.
* comment: A Litigation Transaction can be spent by another Litigation
Transaction with higher `n`.
The intent is to force the current state onchain, in order to punish the
thief using the *latest* state instead of punishing from old state.
* `nLockTime`: `500e6 + n`, where `n` is the update index for this Litigation
Transaction.
* comment: a Litigation Transaction with `n` cannot spend an Update
Transaction of same `n`, only `n - 1` or less.
* input:
* Update transaction output *OR* another Litigation Transaction output;
Update/Litigation tx has `n` less than this Litigation transaction.
* witness: `sign(MuSig(A lawyer, B lawyer, C lawyer),
SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_SINGLE)`
* output:
* Internal Taproot Key: `MuSig(A lawyer, B lawyer, C lawyer)`
* scripts:
*
Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
Good morning list, I had another realization about the use of punishment in a multiparticipant (n > 2) setting. And it has to do with contracts that have a sort of "shared ownership". Consider HTLC outputs. 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. Suppose we know that Alice cheated. Suppose also that Bob offered an HTLC to Alice with a hash whose preimage Alice secretly knows, and that Alice offered an HTLC to Charlie with a long future lock time with a hash that Alice secretly knows has a high probability that nobody knows the preimage. How should Bob and Charlie split the HTLCs? If we do not punish the HTLCs, then Alice can arrange such that most of her money is in HTLCs that she can recover, and thereby avoid punishment. If we *do* punish the HTLCs, we would have to make the Bob->Alice revocable only in favor of Bob, and make the Alice->Carol revocable only in favor of Charlie. This ties to constructions such as Channel Factories. 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. At the same time, channel factories allow arbitrary transport of funds between any participants inside the factory if all participants are online: if a channel is exhausted, but the paying participant has funds elsewhere, the paying participant can initiate a channel reorganization and move funds to the exhausted channel. Channel factories host channels. Channels are shared-ownership UTXOs, in much the same way that HTLCs are shared-ownership UTXOs. Thus, if we will use this construction to implement channel factories, channels inside the factory should be punished by transferring the funds to the other participant of the channel. However, things can get more complicated as the states inside the construction change over time. Let us return to the HTLC example. Suppose there exists an Alice->Bob HTLC in the old state that Alice the thief publishes, and that the entire value of the construction is in that HTLC. 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. It seems to me, that punishment systems can only work if one of the following are true: * 2 participants, which prevents channel factory scaling. * OR, no smart contracts (HTLCs or subchannels), which prevents channel factory scaling, **and** network/routing scaling. So I think that, in terms of multiparticipant constructions, non-punitive constructions are the only possible constructions. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
Good morning list, > witness: > "sig(A, hash_type=SINGLE|ANYPREVOUTANYSCRIPT|NONE) sig(P, hash_type=SINGLE)" > (Alice commitment signature) I realized that this would not work. Alice can simply sign `sig(A, hash_type=ALL)` instead at this stage, as she is the only signatory to the ` OP_CHECKSIGVERIFY` and nobody else can impose that she use the above `hash_type`. 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. You could use `MuSig(A, B, C)` instead and perform the MuSig signing ritual such that Alice is the last one to generate the final signature, but this massively complicates things as you need to perform `n` such rituals where `n` is the number of participants. I think a hash/preimage challenge would work better here. Each participant would reveal an identifying hash on channel opening, with a preimage only each participant knows. This is used to restrict which Taproot script they can use to perform a unilateral close, thus identifying which participant initiated the unilateral close (and if the unilateral close is to an old state, can be used to identify who should be punished). > > > Eltoo has been criticized to lower the cost for a malicious party to > > > test your monitoring of the chain. If we're able to reintroduce some > > > form of punishment without breaking transaction symmetry that would be > > > great. > > > > The primary advantage of Decker-Russell-Osuntokun is that it > > eliminates "toxic waste". > > By this we mean, older version of your channel database are "toxic" in > > that you, or someone who wants to attack you, can use it > > (accidentally in your case, deliberately in the attacker case), and > > then you will lose all funds in the channel. > > I'm pretty sure at this point that the toxic-waste problem is inherent > to punishment schemes, and anything we build on top of it would > reintroduce asymmetry, undoing a lot of the benefits that we gained with > eltoo. Then again, I personally don't think that punishments are such a > great idea in the first place (having been inadvertently punished myself > due to botched backups and similar things). I largely agree. > > Note that access to your channel database, without necessarily > > accessing your node private keys, is often easier. For example, > > C-Lightning stores channel data into an SQLITE database and exposes > > every transaction it makes to a `db_hook` that plugins can use to > > replicate the database elsewhere. If you were to use an > > insufficiently secured plugin to replicate your database, an attacker > > might be able to access your channel data, replicate your database, > > and use an older version to frame you for theft and make you lose all > > your channel funds. > > 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. Even a simple signing component that keeps a high-water > mark for the latest state and refuses to sign an older one would be > sufficient to guard against involuntary cheating. > > Nevertheless, there are quite a few damaging things an attacker can do > if he get hold of your DB, just not this one :-) Ah, I understand. > > Thus, Decker-Russell-Osuntokun removes the punitive consideration so > > that you being framed for theft does not lose all your funds, it > > merely closes your channels. > > Which is also not free: you are still paying on-chain fees for your > failed attempt to enforce an older state, and you still don't get the > desired effect, since the counterparty just overrides your attempt, > without returning your fees. Current Poon-Dryja requires a "reserve", a minimum amount that each participant must maintain in the channel. Though not fixed in the spec (each participant supposedly indicates the reserve they want from the other) all implementations I know of hardcode 1% of the channel total value as the reserve. This is the amount that can be used to punish a thief. 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). Thus, if the fee that is needed in Decker-Russell-Osuntokun is at or above 1% of the channel value, the fee lost would be larger than what a thief would risk under Poon-Dryja. Of course, an economically-maximizing thief would make channels of up to
Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
ZmnSCPxj via Lightning-dev writes: > Good morning Atoine, > > Thank you for your proposal. > >> Eltoo has been criticized to lower the cost for a malicious party to >> test your monitoring of the chain. If we're able to reintroduce some >> form of punishment without breaking transaction symmetry that would be great. > > The primary advantage of Decker-Russell-Osuntokun is that it > eliminates "toxic waste". > > By this we mean, older version of your channel database are "toxic" in > that you, ***or someone who wants to attack you***, can use it > (accidentally in your case, deliberately in the attacker case), and > then you will lose all funds in the channel. I'm pretty sure at this point that the toxic-waste problem is inherent to punishment schemes, and anything we build on top of it would reintroduce asymmetry, undoing a lot of the benefits that we gained with eltoo. Then again, I personally don't think that punishments are such a great idea in the first place (having been inadvertently punished myself due to botched backups and similar things). > Note that access to your channel database, without necessarily > accessing your node private keys, is often easier. For example, > C-Lightning stores channel data into an SQLITE database and exposes > every transaction it makes to a `db_hook` that plugins can use to > replicate the database elsewhere. If you were to use an > insufficiently secured plugin to replicate your database, an attacker > might be able to access your channel data, replicate your database, > and use an older version to frame you for theft and make you lose all > your channel funds. 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. Even a simple signing component that keeps a high-water mark for the latest state and refuses to sign an older one would be sufficient to guard against involuntary cheating. Nevertheless, there are quite a few damaging things an attacker can do if he get hold of your DB, just not this one :-) > Thus, Decker-Russell-Osuntokun removes the punitive consideration so > that you being framed for theft does not lose all your funds, it > merely closes your channels. Which is also not free: you are still paying on-chain fees for your failed attempt to enforce an older state, and you still don't get the desired effect, since the counterparty just overrides your attempt, without returning your fees. Cheers, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
Good morning Atoine, Thank you for your proposal. > Eltoo has been criticized to lower the cost for a malicious party to > test your monitoring of the chain. If we're able to reintroduce some > form of punishment without breaking transaction symmetry that would be great. The primary advantage of Decker-Russell-Osuntokun is that it eliminates "toxic waste". By this we mean, older version of your channel database are "toxic" in that you, ***or someone who wants to attack you***, can use it (accidentally in your case, deliberately in the attacker case), and then you will lose all funds in the channel. Note that access to your channel database, without necessarily accessing your node private keys, is often easier. For example, C-Lightning stores channel data into an SQLITE database and exposes every transaction it makes to a `db_hook` that plugins can use to replicate the database elsewhere. If you were to use an insufficiently secured plugin to replicate your database, an attacker might be able to access your channel data, replicate your database, and use an older version to frame you for theft and make you lose all your channel funds. Thus, Decker-Russell-Osuntokun removes the punitive consideration so that you being framed for theft does not lose all your funds, it merely closes your channels. However, it look to me that you attempt to fix the toxic waste issue, as you mention a "Mallory" later that attempts to frame Alice (possibly by broadcasting old state). On the other hand, it seems, there is no description of how Alice might go about protecting herself from Mallory. In particular, it seems to me that it would be trivial for Alice to avoid punishment by first creating a fake "Mallory", then taking whatever path would let Alice "off the hook" for a framing Mallory when at risk of getting caught, thus returning the "reduced cost for trying to steal channel funds". > > Transaction symmetry implies that we can't deduce from observing > txid which party broadcast a previous state. How to assign the > faulty broadcast to the right party to punish it in consequence ? > Thanks to taproot we have cheap witness asymmetry. > Witness asymmetry can be used as a way to force the broadcaster to reveal > a secret, and so committing thatn the transaction is the latest one. > > If the party misbehaves, we wish to use the revealed secret to punish > him on a second stage transaction. Doing so would be really insecure > in case of reorg or even mempool monitoring by enabling a replay attack > of your committed secret on a lower state update tx. i.e Mallory > would counterfeit being Alice, and so enable the use of a punishment tx > against an honest peer. > > To solve the assignment problem, we need to have per-update credentials, > a secret committed to a state number. You need a scheme were both your > highest credential can't be used against you while at the same time if some > attacker broadcast a transaction with a lower credential you are able to > punish him. > > How to make Bitcoin Script aware of a secret committed to > a lower state number ? To do so, we may use some SIGHASH magic, if you sign > two messages with the same key and we can be sure thatn the only difference > between > them is the nLocktime (encoding the state-number in eltoo), that means you > tried to breach the contract. Could a hash preimage be used instead, with revocation? We would require that the hash preimage be unique per-update, but the same technique used in current Poon-Dryja (Russell shachain) can be used to store the preimages of revoked states. > > Without access to arbitrary messages on the stack, the only messages we can > enforce signatures on are Bitcoin transactions. We force a party > broadcasting an Update tx to sign it with > SIGHASH_ANYPREVOUTSCRIPT|SIGHASH_NONE|SIGHASH_SINGLE. If someone can shows a > Litigation Tx with a higher state than the Update, we know that this one has > been revoked, and someone is cheating among channel parties. We enter in a > Litigation phase, the Settlement Tx will be encumbered by a Challenge Tx > against > which you will need to produce a signature with the same SIGHASH flags as the > Update Tx., > The only difference will be the nLocktime inherited from Litigation. > > Assume Alice is trying to cheat, now Bob can take the signature from her > broadcast Update tx > and Alice’s signature on the Challenge tx, pass it as witness to a script > verifying their validity > and identity. If their validity is true and identity is false, you can spend > with a Justice tx, > splitting Alice’s funds between the other parties. If validity is true and > identity is true, then the script should fail. After timelock expiration, if > no one has proven Alice misbehaved, > she can redeem her funds. > > Eltoo-Penalty Transaction Tree > == > > > Friendly Settlement Tx
[Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty
Hi all, Eltoo has been criticized to lower the cost for a malicious party to test your monitoring of the chain. If we're able to reintroduce some form of punishment without breaking transaction symmetry that would be great. Transaction symmetry implies that we can't deduce from observing txid which party broadcast a previous state. How to assign the faulty broadcast to the right party to punish it in consequence ? Thanks to taproot we have cheap witness asymmetry. Witness asymmetry can be used as a way to force the broadcaster to reveal a secret, and so committing thatn the transaction is the latest one. If the party misbehaves, we wish to use the revealed secret to punish him on a second stage transaction. Doing so would be really insecure in case of reorg or even mempool monitoring by enabling a replay attack of your committed secret on a lower state update tx. i.e Mallory would counterfeit being Alice, and so enable the use of a punishment tx against an honest peer. To solve the assignment problem, we need to have per-update credentials, a secret committed to a state number. You need a scheme were both your highest credential can't be used against you while at the same time if some attacker broadcast a transaction with a lower credential you are able to punish him. How to make Bitcoin Script aware of a secret committed to a lower state number ? To do so, we may use some SIGHASH magic, if you sign two messages with the same key and we can be sure thatn the only difference between them is the nLocktime (encoding the state-number in eltoo), that means you tried to breach the contract. Without access to arbitrary messages on the stack, the only messages we can enforce signatures on are Bitcoin transactions. We force a party broadcasting an Update tx to sign it with SIGHASH_ANYPREVOUTSCRIPT|SIGHASH_NONE|SIGHASH_SINGLE. If someone can shows a Litigation Tx with a higher state than the Update, we know that this one has been revoked, and someone is cheating among channel parties. We enter in a Litigation phase, the Settlement Tx will be encumbered by a Challenge Tx against which you will need to produce a signature with the same SIGHASH flags as the Update Tx., The only difference will be the nLocktime inherited from Litigation. Assume Alice is trying to cheat, now Bob can take the signature from her broadcast Update tx and Alice’s signature on the Challenge tx, pass it as witness to a script verifying their validity and identity. If their validity is true and identity is false, you can spend with a Justice tx, splitting Alice’s funds between the other parties. If validity is true and identity is true, then the script should fail. After timelock expiration, if no one has proven Alice misbehaved, she can redeem her funds. Eltoo-Penalty Transaction Tree == Friendly Settlement Tx Challenge Tx -- Justice Tx / / / / Funding-Output -- Update Tx -- Litigation Tx -- .. -- Hostile Settlement Tx -- Challenge Tx -- Justice Tx \ \ Challenge Tx -- Justice Tx Eltoo-Penalty Scripts (I've omitted chaperon signatures) FUNDING_OUTPUT: output 0: Q = P + tG P = muSig(A,B,C) scripts = [ "OP_1 CHECKSIGVERIFY CHECKSIGVERIFY" (Alice script path) "OP_1 CHECKSIGVERIFY CHECKSIGVERIFY" (Bob script path) "OP_1 CHECKSIGVERIFY CHECKSIGVERIFY" (Caroll script path) ] UPDATE TX: nLocktime: 500e6 + n output 0: P = muSig(A,B,C) scripts = [ "OP_1 CHECKSIGVERIFY" (friendly settlement script path) "OP_1 CHECKSGIVERIFY 500e6+n OP_CLTV OP_DROP" (litigation script path) witness: "sig(A, hash_type=SINGLE|ANYPREVOUTANYSCRIPT|NONE) sig(P, hash_type=SINGLE)" (Alice commitment signature) "sig(B, hash_type=SINGLE|ANYPREVOUTANYSCRIPT|NONE) sig(P, hash_type=SINGLE)" (Bob commitment signature) "sig(C, hash_type=SINGLE|ANYPREVOUTANYSCRIPT|NONE) sig(P, hash_type=SINGLE)" (Caroll commitment signature) LITIGATION TX: nLocktime: 500e6 + n nSequence: [delay] output 0: P = muSig(A,B,C) scripts = [ "OP_1 CHECKSIG" (litigation script path) "OP_1 CHECKSIGVERIFY" (hostile settlement script path) witness: "sig(P, hash_type=SINGLE|ANYPREVOUTANYSCRIPT) HOSTILE SETTLEMENT TX: nLocktime: 0 nSequence: [delay] output 0: (to_Alice) P = muSig(A,B,C) scripts = [ "OP_1 CHECHSIGVERIFY CHECKSIGVERIFY 500e6n OP_CLTV OP_DROP" (Alice challenge script path) ] output 1: (to_Bob) P = muSig(A,B,C) scripts = [ "OP_1 CHECHSIGVERIFY CHECKSIGVERIFY 500e6n OP_CLTV OP_DROP" (Bob challenge script path) ] output 2: (to_Caroll) P = muSig(A,B,C) scripts = [ "OP_1 CHECHSIGVERIFY CHECKSIGVERIFY 500e6n OP_CLTV OP_DROP" (Caroll challenge script path) ] output N (pending HTLCs) witness: "sig(P, hash_type=ALL) CHALLENGE TX: (Alice case) nLocktime: 500e6n nSequence: 0 output 0: P = muSig(A,B,C) scripts = [ "OP_1 CHECKSIGVERIFY
