[bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

[bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

[ZmnSCPxj]

 (N > 2) Multiparticipant Offchain Mechanisms

Introduction 
============

The blockchain layer of Bitcoin provides an excellent non-interactivity:
users can go offline, then come online, synchronize, and broadcast
transactions to the mempool.
Always-online miners then get the transactions and add them to blocks,
thereby confirming them. 

There are two important properties here: 

* Users do not need to be persistently online, only online when they
  need to create and send a transaction.
* Miners only dictate transaction ordering (i.e. which of two
  conflicting transactions "comes first" and the second one is thus
  invalid), and do ***not*** have custody of any user funds at all.

Both properties are difficult to achieve for offchain mechanisms like
2-participant Lightning channels.
But without these two properties, the requirement to be interative
and thus always online creates additional friction in the use of the
technology.  
             
When we move on from 2-participant offchain mechanisms ("channels")
and towards N > 2, the interactivity problem is exacerbated.
Generally, it is not possible to advance the state of an offchain
mechanism that uses N-of-N signing without all users being online
simultaneously.

In this writeup, I present a new role that N-of-N offchain mechanisms
can include.
This role, the actuary role, is similar to the role of miners on the
blockchain: they have high uptime (so users can connect to them to
send a transaction "for confirmation") and they only decide
transaction ordeering and do ***not*** have custody of the coins.

Required Softforks
------------------

To enable the actuary role I propose here, we need to have two
softforks:

* `SIGHASH_ANYPREVOUT`
* `OP_CHECKSEPARATEDSIG`
  - Instead of accepting `(R, s)` signature as a single stack item,
    this accepts `s` and `R` as two separate stack items.

I expect that neither is significantly controversial.
Neither seems to modify miner incentives, and thus isolates the
new role away from actual miners.

I will describe later how both are used by the proposed mechanism.

Actuaries In An N-of-N Offchain Mechanism
=========================================

Mechanisms like Decker-Wattenhofer, Poon-Dryja, and
Decker-Russell-Osuntokun ("eltoo") can have an N-of-N signatory
set.
I will not discuss them deeply, other than to note that
Decker-Russell-Osuntokun requires `SIGHAH_ANYPREVOUT`, supports
N > 2 (unlike Poon-Dryja), and does not require significant
number of transactions with varaible relative locktimes in the
unilateral close case (unlike Decker-Wattenhofer).

Using an N-of-N signatory set provides te following important
advantage:

* It is a consensus, not a democracy: everyone needs to agree.
  - Thus, even a majority cannot force you to move funds you
    own against your will.
    The other side of "not your keys, not your coins" is
    "your keys, your coins": if your key is necessary
    because you are one of the N signatories, then funds inside
    the mechanism are *your coins* and thus ***not*** custodial.

The drawback of N-of-N signatories is that **all** N participants
need to come together to sign a new state of the mechanism.
If one of the N participants is offline, this stalls the protocol.

An Offchain "Mempool"
---------------------

At any time, an offchain mechanism such as Decker-Russell-Osuntokun
will have a "current state", the latest set of transaction outputs
that, if you unilateral close at that point, will be instantiated
onchain.

Thus, we can consider that the state of the mechanism is a set of
pairs of Bitcoin SCRIPT and number of satoshis.

These are instantiated as *actual* transaction outputs on some
transaction that can be pushed onchain in a unilateral close
situation.

Suppose there are N (N > 2) participants in an offchain mechanism.

Now suppose that one of the participants owns some funds in a
simple single-sig contract in the current state of the offchain
mechanism.
Suppose that participant ("A") wants to send money to another
participant ("B").
Then participant A can "just" create an ordinary Bitcoin
transaction that spends the appropriate transaction output from
the current state, and sends money to participant B.

    current state               +--------+--------------+
    ---------+-----------+      |        |      A2      | (change output)
             |     A     | ---> |        +--------------+
             +-----------+      |        |      B2      |
             |     B     |      +--------+--------------+
             +-----------+
             |     C     |
    ---------+-----------+

Now, B can "accept" this transaction is real, but ***only*** if
B trusts A to not double-spend.
Participant A can still construct a different transaction that
spends that output but does ***not*** give any funds to
participant B.

Thus, this transaction is "unconfirmed", or in other words,
would be in a "mempool" waiting to be confirmed.

How do we "confirm" this transaction?

In order to confirm this transaction, we apply the transaction
to the current state of the mechanism: it is an atomic operation
that deletes transaction output A and insersts two transaction
outputs A2 and B2.
This results in a new state.
Then, all the participants (A, B, and C) need to sign off on the
new state and invalidate the current state, replacing the current
state to the new state.

By moving to the new state, we effectively "cut through" the
transactions that were in the "mempool" of the offchain mechanism.
The cut-through transactions can then be forgotten forever, and
more importantly ***do not have to be published to anyone***.
Even a third party trying to validate the state of the offchain
mechanism does **not** need to know about such old transactions
that were already cut through.
This is an important scaling property.

Now, as mentioned above, the problem is that the N participants
need to be online in order to advance the state and perform the
cut-through.
If one of the participants is offline, then none of the "mempool"
transactions can confirm.

So the question I raise now is: can we create a new role, an
actuary, that is able to "confirm" transactions (i.e. indicate
that a transction output has been spent by a specific
transaction, and thus a conflicting transaction is no longer
valid), but is otherwise unable to spend the funds (i.e.
non-custodial)?

K-of-N Non-Solution
-------------------

A common proposal is to have a federation of k-of-n that is
trusted by participants.

That way, even if some of the signatories are offline, the
mechanism is "robust" in the sense that the state can still
advance, and in-"mempool" transactions get "confirmed".

The problem with this is that this is blatantly custodial.
***Any*** k-of-n mechanism ***MUST*** be custodial, as you
cannot be sure that the k participants are actually not
owned by a single participant which can now spend all your
precious precious funds.

Thus, this writeup completely rejects any k-of-n solution
for state updates.
We require that:

* State updates are always signed N-of-N by all involved
  participants.
* Somehow we want to have a smaller threshold to *commit*
  to having individual transactions in the *next* state,
  and to reject double-spends of inputs to transactions
  that have been committed.

Actuary Role
------------

Let us now define what we want the actuary role to be able
to do and **NOT** do:

* The actuary is able to select exactly one transaction
  that spends a transaction output, i.e. it enforces
  against double-spend.
* The actuary is **NOT** able to spend funds unilaterally
  by itslf, or with cooperation with participants that
  do not otherwise have signing authorization for a
  transaction output.
* The actuary is **NOT** able to hostage funds, i.e. if
  it stops responding, any single one participant can
  drop the mechanism onchain and get actury-confirmed
  (i.e. before the actuary stops responding) transactions
  confirmed onchain, and thus able to recover their
  funds.

### Ensuring Single-Spend

We can have the actuary indicate that it has selected a
transaction by also requiring that the actuary sign that
transaction.

We thus want to prevent the actuary from signing for the
same output, but a different transaction.

What we can do is to add the actuary to the contract that
controls the funds, but with the condition that the
actuary signature has a specific `R`.

As we know, `R` reuse --- creating a new signature for a
different message but the same `R` --- will leak the
private key.

The actuary can be forced to put up an onchain bond.
The bond can be spent using the private key of the actuary.
If the actuary signs a transaction once, with a fixed `R`,
then its private key is still safe.

However, if the actuary signs one transaction that spends
some transaction output, and then signs a different
transaction that spends the same transaction output, both
signatures need to use the same fixed `R`.
Because of the `R` reuse, this lets anyone who expected
one transaction to be confirmed, but finds that the other
one was confirmed, to derive the secret key of the
actuary from the two signatures, and then slash the bond
of the actuary.

Thus, we need an `OP_CHECKSEPARATEDSIG` opcode.
This takes three stack items, instead of two: `s`,
`R`, and the public key.

Then, an actual transaction output can indicate a specific
`R` in a SCRIPT that includes `OP_CHECKSEPARATEDSIG`.
This forces a specific `R` to be used, and thus requires
the actuary to only sign once.
This then enforces single-spend.

### Ensuring Non-Custodial

This is simple: By ensuring that the onchain funding
transaction output, which backs the entire mechanism, is
an N-of-N of all participants, we can ensure that the
actuary cannot spend the funds.

Thus, by using N-of-N of all participants, we have
consensus, and thus it is unnecessary for any participant
to trust anyone else: they do not need to trust the
actuary, or a quorum of signatories.

As noted, this has the drawback that all N participants
now need to sign off on each updtae of the offchain
mechanism.

However, the actuary serves a role:

* While a new state is not yet signed off on by all
  participants, it can sign individual transactions to
  "confirm" them, with the assurance that they cannot
  assist a double-spend since if they assist a
  double-spend they lose their bond.
* Participants can go online and offline at any time,
  and the actuary can solicit and store their signatures
  for to-be-next state.
  Once it has solicited a complete N-of-N set for the
  to-be-next state, it can then declare a new state and
  hand the complete signature set to participants the
  next time they come online.

These reduce the onlineness requirement on participants.

### Ensuring Non-hostage

We want the following property:
If the actuary stops responding, then the participants
can decide to drop the mechanism onchain, and recover
their funds despite the actuary disappearing.

Thus, the actuary cannot hostage the funds by refusing
to confirm transactions: if the actuary refuses to
confirm transactions, the participants can drop the
mechanism onchain and just use the blockchain layer.
This would suck, but the actuary still cannot hostage
the funds held by the participants: the participants
have a way to escape the mechanism.

Crucially, we want the property that if we have some
transactions that spend outputs from the current
state, that were previously signed off by the actuary
(i.e. "confirmed"), then when we drop onchain, we can
drop those transactions onchain as well, with the
assurance that other participants cannot replace them
with an alternate version.

To implement this, the SCRIPT of all outputs hosted
inside the offchain mechanism are "infected" with
`(sign-only-once(M) || CSV) && C`, where
`M` is the actuary pubkey, `sign-only-once(M)` means
that we enforce `R` reuse so that the actuary cannot
sign the same output with different transactions
(and thus ensure single-spend), and `C` is the
"base", uninfected contract.

For example, a hashlocked timelocked contract from A
to B would have a "base" contract of:

    (B && preimage(hash)) || (A && CLTV)

And would have an "infected" contract of:

    (sign-only-once(M) && CSV) && ((B && preimage(hash)) || (A && CLTV))

For Taproot tapleaves, all tapleaves need to be infected.
In addition, the `sign-only-once(M)` needs to use the same
`R` for all tapleaves as well, so that signing for one
branch cannot be used for another branch.
The pointlocked branch cannot be used, but given current
plans for `SIGHASH_ANYPREVOUT`, you need to sign
`SIGHASH_ANYPREVOUT` because the actual transaction that
gets confirmed can have a different transaction ID due to
the Decker-Russell-Osuntokun.

If the actaury stops responding, participants can
publish the most recent state, as well as transactions
that were "confirmed" by the actuary.
Crucially, the transactions confirmed by the actuary
have a time advantage, because they are signed by the
actuary and we have a logical OR with the CSV;
unconfirmed transactions need to wait for the CSV
relative timeout before they can be confirmed onchain.
Thus, if before it disappeared, the actuary signed some
transactions and thus "confirmed" them, the participants
can also confirm them onchain, and it is significantly
less likely that another version of those transactions
can get confirmed onchain in that situation.
Thus, participants can rely on the "confirmation" of
the actuary.

Worked Example
==============

Let us copy the initial state above, where there are three
participants, A B C.
In the below, M is the actuary, and the "M" here includes a
fixed `R` nonce, to ensure that M can only sign once, and if
M signs multiple times, it risks losing its bonded coins.

    current state
    ---------+-------------+
             |(M||CSV) && A|
             +-------------+
             |(M||CSV) && B|
             +-------------+
             |(M||CSV) && C|
    ---------+-------------+

In the above, the "base" contracts are simple single-signature
`A` / `B` / `C` conracts.

While we show only `M`, in fact each `M` requirement also
enforces single-spend for `M`.
Each output also has a different `R` that is issused by the
actuary.

(for example, each participant can give the base contract
serialization to the actuary, who then HMACs it with its own
private key to generate a `r` then does `R = r * G`, so that
the actuary does not need to remember the exact `R` each time,
only whether it signed for a particular contract-amount pair.)

Suppose that A decides to send some money to B.
It creates a transaction spending the `A` output and creates
two new outputs:

    current state                  +--------+----------------+
    ---------+-------------+       |        | (M||CSV) && A2 |
             |(M||CSV) && A| ----> |    A   +----------------+
             +-------------+       |        | (M||CSV) && B2 |
             |(M||CSV) && B|       +--------+----------------+
             +-------------+
             |(M||CSV) && C|
    ---------+-------------+

In the above the `A` in the input side of the new transaction
indicates a signature from participant A, fulfilling the base
contract `A`.

As the transaction is only signed by `A`, it is not yet
confirmed.
If the mechanism is dropped onchain, the participants must
wait for the CSV timeout before it can be confirmed onchain,
which reflects the fact that the transaction, inside the
offchain mechanism, was not yet confirmed at this point.

Now, suppose that participant A wants B to be assured that
A will not double-spend the transaction.
Then A solicits a single-spend signature from the actuary,
getting a signature M:

    current state                  +--------+----------------+
    ---------+-------------+       |        | (M||CSV) && A2 |
             |(M||CSV) && A| ----> |  M,A   +----------------+
             +-------------+       |        | (M||CSV) && B2 |
             |(M||CSV) && B|       +--------+----------------+
             +-------------+
             |(M||CSV) && C|
    ---------+-------------+

The above is now a confirmed transaction.

Suppose at this point the offchain mechanism is dropped
onchain.
In that case, it is now immediately possible to also confirm
the above transaction.

Suppose that A tries to double-spend the transaction by signing
another transaction spending the `A` output, but giving all of
it to a new output `A3`.
Because of the single-spend signature requirement, the actuary
cannot safely sign this alternative version without losing its
bonded amount.

    current state                  +--------+----------------+
    ---------+-------------+       |        | (M||CSV) && A2 |
             |(M||CSV) && A| -+--> |  M,A   +----------------+
             +-------------+  |    |        | (M||CSV) && B2 |
             |(M||CSV) && B|  |    +--------+----------------+
             +-------------+  |
             |(M||CSV) && C|  |    +--------+----------------+
    ---------+-------------+  +--> |    A   | (M||CSV) && A3 |
                                   +--------+----------------+

The transaction that is signed by the actuary M is the one that
can be confirmed onchain immediately as soon as the current
state transaction is confirmed, because the signature allows
skipping the CSV requirement.
However, the transaction that is signed only by participant A,
in an attempt to double-spend the transaction, will need to
wait out the CSV delay.
The actuary M will never sign this alternate transaction, as
`R` reuse will cause it to lose control of its private key and
allow slashing of its bond.

So, let us suppose that the actuary M decides to "cut through"
the trasnaction it signed.
The actuary M proposes to each of the participants to update
the state of the offchain mechanism.

    current state                  +--------+----------------+
    ---------+-------------+       |        | (M||CSV) && A2 |
             |(M||CSV) && A| ----> |  M,A   +----------------+
             +-------------+       |        | (M||CSV) && B2 |
             |(M||CSV) && B|       +--------+----------------+
             +-------------+
             |(M||CSV) && C|
    ---------+-------------+

    next state
    ---------+----------------+
             | (M||CSV) && A2 |
    ---------+----------------+
             | (M||CSV) && B2 |
    ---------+----------------+
             | (M||CSV) && B  |
    ---------+----------------+
             | (M||CSV) && C  |
    ---------+----------------+

It is not necessary for all the participants to come online
simultaneously just to sign the new state.
THe actuary can keep track of this new state on behalf of
the participants, as well as the total signatures of all the
N participants.

Each participant still must validate that the next state
contains the outputs they expect.
However, they do not need to validate ***all*** outputs.
For instance, participant C knows that it did not spend
any funds, and did not receive any funds; it only cares
that the next state still contains the `C` contract it
expects.
Participant A needs to validate the A2 and B2 exist,
while participant B needs to validate the B2 and B outputs.

***This is important as it reduces the bandwidth requirements
on the participants.***
It is not necessary for the participants to validate *all*
transactions, only that the participants validate the
existence of outputs it expects to have been confirmed by
the actaury.
This is an important scaling advantage over e.g. a sidechain,
where sidechain participants really ought to validate *all*
transactions in the sidechain, not just the set they care
about.

Unlike the sidechain case, every participant needs to sign
off on each state update.
This means that as long as each participant does minimal
protection of themselves, they can simply rely on the other
participants being selfishly checking for their own expected
outputs.

If the actuary tries to cheat and create a next state that
is not valid, then at least one participant will simply
refuse to sign the next state, and drop the current state
(and any transactions based on the current state) onchain.
Thus, the N-of-N signatory set becomes an important
optimization!

In the above example, the actuary actually faithfully
set the correct next state.
So eventually all the participants get to go online and
provide their signature shares, so that the mechanism
advances and the next state becomes the current state:

    current state
    ---------+----------------+
             | (M||CSV) && A2 |
    ---------+----------------+
             | (M||CSV) && B2 |
    ---------+----------------+
             | (M||CSV) && B  |
    ---------+----------------+
             | (M||CSV) && C  |
    ---------+----------------+

Against Custodiality
====================

I think that people who want to actually improve Bitcoin
MUST first strive as much as possible to ***avoid***
custodians.

Custodiality is easy.

Escaping custody once you are custodied is almost impossible.

Thus, it is important to ***avoid*** a custodial solution
in our designs for Bitcoin.

For example, Drivechains effectively makes miners the
custodians of sidechain coins.

Yes, there are incentives for miner custodians to not steal
the sidechain coins.

But far better to be able to say "it is not even possible for
the miner to steal the coins in this mechanism at all".

Do not give roles more rights than the minimum they absolute
need to do their work!
This is basic cybersecurity.

We MUST avoid giving miners more control over **any** blockchain
coins than what they already have.
Miners currently can censor, and it is difficult to remove that
ability without removing the ability to decide whether to confirm
some transaction or not, since it is not possible to prove that
you do not know a transaction.
But currently miners cannot outright steal any funds.

Giving more rights allows hackers who manage to take on the
miner role (e.g. because the miner has bad opsec, or the hacker
is the dictatorial warlord of the local government and has shot
the miner to death and taken over their mine) to attack the
system.
Then, any analysis that "but miner roles have an incentive to
not attack sidechains!" would not apply, as the hacker got the
miner role outside of the normal miner expected incentives;
the hacker incentives may not match the incentives of a "real"
miner.

Better if miners cannot attack at all, so that hackers that
invalidly gain their role cannot attack, either.

Similarly, the actuary role is given only the ability to decide
to confirm or not confirm transactions.
In particular the actuary role in this scheme is ***NOT***
given the ability to move funds without consent of the purported
owners of the value.

This requires consensus, i.e. N-of-N signatories.
However, the actuary is also overloaded so that it is the only
entity that needs to have high uptime.
Participants can drop online and offline, and the actuary
coordinates the creation of new states.

Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 27265 bytes --]

Hi Zeeman


> What we can do is to add the actuary to the contract that
> controls the funds, but with the condition that the
> actuary signature has a specific `R`.

> As we know, `R` reuse --- creating a new signature for a
> different message but the same `R` --- will leak the
> private key.

> The actuary can be forced to put up an onchain bond.
> The bond can be spent using the private key of the actuary.
> If the actuary signs a transaction once, with a fixed `R`,
> then its private key is still safe.

> However, if the actuary signs one transaction that spends
> some transaction output, and then signs a different
> transaction that spends the same transaction output, both
> signatures need to use the same fixed `R`.
> Because of the `R` reuse, this lets anyone who expected
> one transaction to be confirmed, but finds that the other
> one was confirmed, to derive the secret key of the
> actuary from the two signatures, and then slash the bond
> of the actuary.

From my understanding, if an off-chain state N1 with a negotiated group of
40 is halted in the middle of the actuary's R reveals due to the 40th
participant non-interactivity, there is no guarantee than a new off-chain
state N1' with a new negotiated group of 39 (from which evicted 40th's
output is absent) do not re-use R reveals on N1. So for the actuary bond
security,  I think the R reveal should only happen once all the group
participants have revealed their own signature. It sounds like some loose
interactivity is still assumed, i.e all the non-actuary participants must
be online at the same time, and lack of contribution is to blame as you
have a "flat" off-chain construction (i.e no layering of the promised
off-chain outputs in subgroups to lower novation interactivity).

More fundamentally, I think this actuarial system does not solve the
"multi-party off-chain state correction" problem as there is no guarantee
that the actuary does not slash the bond itself. And if the bond is guarded
by users' pubkeys, there is no guarantee that the user will cooperate after
the actuary equivocation is committed to sign a "fair" slashing transaction.

Best,
Antoine

Le sam. 9 sept. 2023 à 02:28, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

>  (N > 2) Multiparticipant Offchain Mechanisms
>
> Introduction
> ============
>
> The blockchain layer of Bitcoin provides an excellent non-interactivity:
> users can go offline, then come online, synchronize, and broadcast
> transactions to the mempool.
> Always-online miners then get the transactions and add them to blocks,
> thereby confirming them.
>
> There are two important properties here:
>
> * Users do not need to be persistently online, only online when they
>   need to create and send a transaction.
> * Miners only dictate transaction ordering (i.e. which of two
>   conflicting transactions "comes first" and the second one is thus
>   invalid), and do ***not*** have custody of any user funds at all.
>
> Both properties are difficult to achieve for offchain mechanisms like
> 2-participant Lightning channels.
> But without these two properties, the requirement to be interative
> and thus always online creates additional friction in the use of the
> technology.
>
> When we move on from 2-participant offchain mechanisms ("channels")
> and towards N > 2, the interactivity problem is exacerbated.
> Generally, it is not possible to advance the state of an offchain
> mechanism that uses N-of-N signing without all users being online
> simultaneously.
>
> In this writeup, I present a new role that N-of-N offchain mechanisms
> can include.
> This role, the actuary role, is similar to the role of miners on the
> blockchain: they have high uptime (so users can connect to them to
> send a transaction "for confirmation") and they only decide
> transaction ordeering and do ***not*** have custody of the coins.
>
> Required Softforks
> ------------------
>
> To enable the actuary role I propose here, we need to have two
> softforks:
>
> * `SIGHASH_ANYPREVOUT`
> * `OP_CHECKSEPARATEDSIG`
>   - Instead of accepting `(R, s)` signature as a single stack item,
>     this accepts `s` and `R` as two separate stack items.
>
> I expect that neither is significantly controversial.
> Neither seems to modify miner incentives, and thus isolates the
> new role away from actual miners.
>
> I will describe later how both are used by the proposed mechanism.
>
> Actuaries In An N-of-N Offchain Mechanism
> =========================================
>
> Mechanisms like Decker-Wattenhofer, Poon-Dryja, and
> Decker-Russell-Osuntokun ("eltoo") can have an N-of-N signatory
> set.
> I will not discuss them deeply, other than to note that
> Decker-Russell-Osuntokun requires `SIGHAH_ANYPREVOUT`, supports
> N > 2 (unlike Poon-Dryja), and does not require significant
> number of transactions with varaible relative locktimes in the
> unilateral close case (unlike Decker-Wattenhofer).
>
> Using an N-of-N signatory set provides te following important
> advantage:
>
> * It is a consensus, not a democracy: everyone needs to agree.
>   - Thus, even a majority cannot force you to move funds you
>     own against your will.
>     The other side of "not your keys, not your coins" is
>     "your keys, your coins": if your key is necessary
>     because you are one of the N signatories, then funds inside
>     the mechanism are *your coins* and thus ***not*** custodial.
>
> The drawback of N-of-N signatories is that **all** N participants
> need to come together to sign a new state of the mechanism.
> If one of the N participants is offline, this stalls the protocol.
>
> An Offchain "Mempool"
> ---------------------
>
> At any time, an offchain mechanism such as Decker-Russell-Osuntokun
> will have a "current state", the latest set of transaction outputs
> that, if you unilateral close at that point, will be instantiated
> onchain.
>
> Thus, we can consider that the state of the mechanism is a set of
> pairs of Bitcoin SCRIPT and number of satoshis.
>
> These are instantiated as *actual* transaction outputs on some
> transaction that can be pushed onchain in a unilateral close
> situation.
>
> Suppose there are N (N > 2) participants in an offchain mechanism.
>
> Now suppose that one of the participants owns some funds in a
> simple single-sig contract in the current state of the offchain
> mechanism.
> Suppose that participant ("A") wants to send money to another
> participant ("B").
> Then participant A can "just" create an ordinary Bitcoin
> transaction that spends the appropriate transaction output from
> the current state, and sends money to participant B.
>
>     current state               +--------+--------------+
>     ---------+-----------+      |        |      A2      | (change output)
>              |     A     | ---> |        +--------------+
>              +-----------+      |        |      B2      |
>              |     B     |      +--------+--------------+
>              +-----------+
>              |     C     |
>     ---------+-----------+
>
> Now, B can "accept" this transaction is real, but ***only*** if
> B trusts A to not double-spend.
> Participant A can still construct a different transaction that
> spends that output but does ***not*** give any funds to
> participant B.
>
> Thus, this transaction is "unconfirmed", or in other words,
> would be in a "mempool" waiting to be confirmed.
>
> How do we "confirm" this transaction?
>
> In order to confirm this transaction, we apply the transaction
> to the current state of the mechanism: it is an atomic operation
> that deletes transaction output A and insersts two transaction
> outputs A2 and B2.
> This results in a new state.
> Then, all the participants (A, B, and C) need to sign off on the
> new state and invalidate the current state, replacing the current
> state to the new state.
>
> By moving to the new state, we effectively "cut through" the
> transactions that were in the "mempool" of the offchain mechanism.
> The cut-through transactions can then be forgotten forever, and
> more importantly ***do not have to be published to anyone***.
> Even a third party trying to validate the state of the offchain
> mechanism does **not** need to know about such old transactions
> that were already cut through.
> This is an important scaling property.
>
> Now, as mentioned above, the problem is that the N participants
> need to be online in order to advance the state and perform the
> cut-through.
> If one of the participants is offline, then none of the "mempool"
> transactions can confirm.
>
> So the question I raise now is: can we create a new role, an
> actuary, that is able to "confirm" transactions (i.e. indicate
> that a transction output has been spent by a specific
> transaction, and thus a conflicting transaction is no longer
> valid), but is otherwise unable to spend the funds (i.e.
> non-custodial)?
>
> K-of-N Non-Solution
> -------------------
>
> A common proposal is to have a federation of k-of-n that is
> trusted by participants.
>
> That way, even if some of the signatories are offline, the
> mechanism is "robust" in the sense that the state can still
> advance, and in-"mempool" transactions get "confirmed".
>
> The problem with this is that this is blatantly custodial.
> ***Any*** k-of-n mechanism ***MUST*** be custodial, as you
> cannot be sure that the k participants are actually not
> owned by a single participant which can now spend all your
> precious precious funds.
>
> Thus, this writeup completely rejects any k-of-n solution
> for state updates.
> We require that:
>
> * State updates are always signed N-of-N by all involved
>   participants.
> * Somehow we want to have a smaller threshold to *commit*
>   to having individual transactions in the *next* state,
>   and to reject double-spends of inputs to transactions
>   that have been committed.
>
> Actuary Role
> ------------
>
> Let us now define what we want the actuary role to be able
> to do and **NOT** do:
>
> * The actuary is able to select exactly one transaction
>   that spends a transaction output, i.e. it enforces
>   against double-spend.
> * The actuary is **NOT** able to spend funds unilaterally
>   by itslf, or with cooperation with participants that
>   do not otherwise have signing authorization for a
>   transaction output.
> * The actuary is **NOT** able to hostage funds, i.e. if
>   it stops responding, any single one participant can
>   drop the mechanism onchain and get actury-confirmed
>   (i.e. before the actuary stops responding) transactions
>   confirmed onchain, and thus able to recover their
>   funds.
>
> ### Ensuring Single-Spend
>
> We can have the actuary indicate that it has selected a
> transaction by also requiring that the actuary sign that
> transaction.
>
> We thus want to prevent the actuary from signing for the
> same output, but a different transaction.
>
> What we can do is to add the actuary to the contract that
> controls the funds, but with the condition that the
> actuary signature has a specific `R`.
>
> As we know, `R` reuse --- creating a new signature for a
> different message but the same `R` --- will leak the
> private key.
>
> The actuary can be forced to put up an onchain bond.
> The bond can be spent using the private key of the actuary.
> If the actuary signs a transaction once, with a fixed `R`,
> then its private key is still safe.
>
> However, if the actuary signs one transaction that spends
> some transaction output, and then signs a different
> transaction that spends the same transaction output, both
> signatures need to use the same fixed `R`.
> Because of the `R` reuse, this lets anyone who expected
> one transaction to be confirmed, but finds that the other
> one was confirmed, to derive the secret key of the
> actuary from the two signatures, and then slash the bond
> of the actuary.
>
> Thus, we need an `OP_CHECKSEPARATEDSIG` opcode.
> This takes three stack items, instead of two: `s`,
> `R`, and the public key.
>
> Then, an actual transaction output can indicate a specific
> `R` in a SCRIPT that includes `OP_CHECKSEPARATEDSIG`.
> This forces a specific `R` to be used, and thus requires
> the actuary to only sign once.
> This then enforces single-spend.
>
> ### Ensuring Non-Custodial
>
> This is simple: By ensuring that the onchain funding
> transaction output, which backs the entire mechanism, is
> an N-of-N of all participants, we can ensure that the
> actuary cannot spend the funds.
>
> Thus, by using N-of-N of all participants, we have
> consensus, and thus it is unnecessary for any participant
> to trust anyone else: they do not need to trust the
> actuary, or a quorum of signatories.
>
> As noted, this has the drawback that all N participants
> now need to sign off on each updtae of the offchain
> mechanism.
>
> However, the actuary serves a role:
>
> * While a new state is not yet signed off on by all
>   participants, it can sign individual transactions to
>   "confirm" them, with the assurance that they cannot
>   assist a double-spend since if they assist a
>   double-spend they lose their bond.
> * Participants can go online and offline at any time,
>   and the actuary can solicit and store their signatures
>   for to-be-next state.
>   Once it has solicited a complete N-of-N set for the
>   to-be-next state, it can then declare a new state and
>   hand the complete signature set to participants the
>   next time they come online.
>
> These reduce the onlineness requirement on participants.
>
> ### Ensuring Non-hostage
>
> We want the following property:
> If the actuary stops responding, then the participants
> can decide to drop the mechanism onchain, and recover
> their funds despite the actuary disappearing.
>
> Thus, the actuary cannot hostage the funds by refusing
> to confirm transactions: if the actuary refuses to
> confirm transactions, the participants can drop the
> mechanism onchain and just use the blockchain layer.
> This would suck, but the actuary still cannot hostage
> the funds held by the participants: the participants
> have a way to escape the mechanism.
>
> Crucially, we want the property that if we have some
> transactions that spend outputs from the current
> state, that were previously signed off by the actuary
> (i.e. "confirmed"), then when we drop onchain, we can
> drop those transactions onchain as well, with the
> assurance that other participants cannot replace them
> with an alternate version.
>
> To implement this, the SCRIPT of all outputs hosted
> inside the offchain mechanism are "infected" with
> `(sign-only-once(M) || CSV) && C`, where
> `M` is the actuary pubkey, `sign-only-once(M)` means
> that we enforce `R` reuse so that the actuary cannot
> sign the same output with different transactions
> (and thus ensure single-spend), and `C` is the
> "base", uninfected contract.
>
> For example, a hashlocked timelocked contract from A
> to B would have a "base" contract of:
>
>     (B && preimage(hash)) || (A && CLTV)
>
> And would have an "infected" contract of:
>
>     (sign-only-once(M) && CSV) && ((B && preimage(hash)) || (A && CLTV))
>
> For Taproot tapleaves, all tapleaves need to be infected.
> In addition, the `sign-only-once(M)` needs to use the same
> `R` for all tapleaves as well, so that signing for one
> branch cannot be used for another branch.
> The pointlocked branch cannot be used, but given current
> plans for `SIGHASH_ANYPREVOUT`, you need to sign
> `SIGHASH_ANYPREVOUT` because the actual transaction that
> gets confirmed can have a different transaction ID due to
> the Decker-Russell-Osuntokun.
>
> If the actaury stops responding, participants can
> publish the most recent state, as well as transactions
> that were "confirmed" by the actuary.
> Crucially, the transactions confirmed by the actuary
> have a time advantage, because they are signed by the
> actuary and we have a logical OR with the CSV;
> unconfirmed transactions need to wait for the CSV
> relative timeout before they can be confirmed onchain.
> Thus, if before it disappeared, the actuary signed some
> transactions and thus "confirmed" them, the participants
> can also confirm them onchain, and it is significantly
> less likely that another version of those transactions
> can get confirmed onchain in that situation.
> Thus, participants can rely on the "confirmation" of
> the actuary.
>
> Worked Example
> ==============
>
> Let us copy the initial state above, where there are three
> participants, A B C.
> In the below, M is the actuary, and the "M" here includes a
> fixed `R` nonce, to ensure that M can only sign once, and if
> M signs multiple times, it risks losing its bonded coins.
>
>     current state
>     ---------+-------------+
>              |(M||CSV) && A|
>              +-------------+
>              |(M||CSV) && B|
>              +-------------+
>              |(M||CSV) && C|
>     ---------+-------------+
>
> In the above, the "base" contracts are simple single-signature
> `A` / `B` / `C` conracts.
>
> While we show only `M`, in fact each `M` requirement also
> enforces single-spend for `M`.
> Each output also has a different `R` that is issused by the
> actuary.
>
> (for example, each participant can give the base contract
> serialization to the actuary, who then HMACs it with its own
> private key to generate a `r` then does `R = r * G`, so that
> the actuary does not need to remember the exact `R` each time,
> only whether it signed for a particular contract-amount pair.)
>
> Suppose that A decides to send some money to B.
> It creates a transaction spending the `A` output and creates
> two new outputs:
>
>     current state                  +--------+----------------+
>     ---------+-------------+       |        | (M||CSV) && A2 |
>              |(M||CSV) && A| ----> |    A   +----------------+
>              +-------------+       |        | (M||CSV) && B2 |
>              |(M||CSV) && B|       +--------+----------------+
>              +-------------+
>              |(M||CSV) && C|
>     ---------+-------------+
>
> In the above the `A` in the input side of the new transaction
> indicates a signature from participant A, fulfilling the base
> contract `A`.
>
> As the transaction is only signed by `A`, it is not yet
> confirmed.
> If the mechanism is dropped onchain, the participants must
> wait for the CSV timeout before it can be confirmed onchain,
> which reflects the fact that the transaction, inside the
> offchain mechanism, was not yet confirmed at this point.
>
> Now, suppose that participant A wants B to be assured that
> A will not double-spend the transaction.
> Then A solicits a single-spend signature from the actuary,
> getting a signature M:
>
>     current state                  +--------+----------------+
>     ---------+-------------+       |        | (M||CSV) && A2 |
>              |(M||CSV) && A| ----> |  M,A   +----------------+
>              +-------------+       |        | (M||CSV) && B2 |
>              |(M||CSV) && B|       +--------+----------------+
>              +-------------+
>              |(M||CSV) && C|
>     ---------+-------------+
>
> The above is now a confirmed transaction.
>
> Suppose at this point the offchain mechanism is dropped
> onchain.
> In that case, it is now immediately possible to also confirm
> the above transaction.
>
> Suppose that A tries to double-spend the transaction by signing
> another transaction spending the `A` output, but giving all of
> it to a new output `A3`.
> Because of the single-spend signature requirement, the actuary
> cannot safely sign this alternative version without losing its
> bonded amount.
>
>     current state                  +--------+----------------+
>     ---------+-------------+       |        | (M||CSV) && A2 |
>              |(M||CSV) && A| -+--> |  M,A   +----------------+
>              +-------------+  |    |        | (M||CSV) && B2 |
>              |(M||CSV) && B|  |    +--------+----------------+
>              +-------------+  |
>              |(M||CSV) && C|  |    +--------+----------------+
>     ---------+-------------+  +--> |    A   | (M||CSV) && A3 |
>                                    +--------+----------------+
>
> The transaction that is signed by the actuary M is the one that
> can be confirmed onchain immediately as soon as the current
> state transaction is confirmed, because the signature allows
> skipping the CSV requirement.
> However, the transaction that is signed only by participant A,
> in an attempt to double-spend the transaction, will need to
> wait out the CSV delay.
> The actuary M will never sign this alternate transaction, as
> `R` reuse will cause it to lose control of its private key and
> allow slashing of its bond.
>
> So, let us suppose that the actuary M decides to "cut through"
> the trasnaction it signed.
> The actuary M proposes to each of the participants to update
> the state of the offchain mechanism.
>
>     current state                  +--------+----------------+
>     ---------+-------------+       |        | (M||CSV) && A2 |
>              |(M||CSV) && A| ----> |  M,A   +----------------+
>              +-------------+       |        | (M||CSV) && B2 |
>              |(M||CSV) && B|       +--------+----------------+
>              +-------------+
>              |(M||CSV) && C|
>     ---------+-------------+
>
>     next state
>     ---------+----------------+
>              | (M||CSV) && A2 |
>     ---------+----------------+
>              | (M||CSV) && B2 |
>     ---------+----------------+
>              | (M||CSV) && B  |
>     ---------+----------------+
>              | (M||CSV) && C  |
>     ---------+----------------+
>
> It is not necessary for all the participants to come online
> simultaneously just to sign the new state.
> THe actuary can keep track of this new state on behalf of
> the participants, as well as the total signatures of all the
> N participants.
>
> Each participant still must validate that the next state
> contains the outputs they expect.
> However, they do not need to validate ***all*** outputs.
> For instance, participant C knows that it did not spend
> any funds, and did not receive any funds; it only cares
> that the next state still contains the `C` contract it
> expects.
> Participant A needs to validate the A2 and B2 exist,
> while participant B needs to validate the B2 and B outputs.
>
> ***This is important as it reduces the bandwidth requirements
> on the participants.***
> It is not necessary for the participants to validate *all*
> transactions, only that the participants validate the
> existence of outputs it expects to have been confirmed by
> the actaury.
> This is an important scaling advantage over e.g. a sidechain,
> where sidechain participants really ought to validate *all*
> transactions in the sidechain, not just the set they care
> about.
>
> Unlike the sidechain case, every participant needs to sign
> off on each state update.
> This means that as long as each participant does minimal
> protection of themselves, they can simply rely on the other
> participants being selfishly checking for their own expected
> outputs.
>
> If the actuary tries to cheat and create a next state that
> is not valid, then at least one participant will simply
> refuse to sign the next state, and drop the current state
> (and any transactions based on the current state) onchain.
> Thus, the N-of-N signatory set becomes an important
> optimization!
>
> In the above example, the actuary actually faithfully
> set the correct next state.
> So eventually all the participants get to go online and
> provide their signature shares, so that the mechanism
> advances and the next state becomes the current state:
>
>     current state
>     ---------+----------------+
>              | (M||CSV) && A2 |
>     ---------+----------------+
>              | (M||CSV) && B2 |
>     ---------+----------------+
>              | (M||CSV) && B  |
>     ---------+----------------+
>              | (M||CSV) && C  |
>     ---------+----------------+
>
> Against Custodiality
> ====================
>
> I think that people who want to actually improve Bitcoin
> MUST first strive as much as possible to ***avoid***
> custodians.
>
> Custodiality is easy.
>
> Escaping custody once you are custodied is almost impossible.
>
> Thus, it is important to ***avoid*** a custodial solution
> in our designs for Bitcoin.
>
> For example, Drivechains effectively makes miners the
> custodians of sidechain coins.
>
> Yes, there are incentives for miner custodians to not steal
> the sidechain coins.
>
> But far better to be able to say "it is not even possible for
> the miner to steal the coins in this mechanism at all".
>
> Do not give roles more rights than the minimum they absolute
> need to do their work!
> This is basic cybersecurity.
>
> We MUST avoid giving miners more control over **any** blockchain
> coins than what they already have.
> Miners currently can censor, and it is difficult to remove that
> ability without removing the ability to decide whether to confirm
> some transaction or not, since it is not possible to prove that
> you do not know a transaction.
> But currently miners cannot outright steal any funds.
>
> Giving more rights allows hackers who manage to take on the
> miner role (e.g. because the miner has bad opsec, or the hacker
> is the dictatorial warlord of the local government and has shot
> the miner to death and taken over their mine) to attack the
> system.
> Then, any analysis that "but miner roles have an incentive to
> not attack sidechains!" would not apply, as the hacker got the
> miner role outside of the normal miner expected incentives;
> the hacker incentives may not match the incentives of a "real"
> miner.
>
> Better if miners cannot attack at all, so that hackers that
> invalidly gain their role cannot attack, either.
>
> Similarly, the actuary role is given only the ability to decide
> to confirm or not confirm transactions.
> In particular the actuary role in this scheme is ***NOT***
> given the ability to move funds without consent of the purported
> owners of the value.
>
> This requires consensus, i.e. N-of-N signatories.
> However, the actuary is also overloaded so that it is the only
> entity that needs to have high uptime.
> Participants can drop online and offline, and the actuary
> coordinates the creation of new states.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 30670 bytes --]

Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

[ZmnSCPxj]

Good morning Antoine,


> Hi Zeeman
> 
> > What we can do is to add the actuary to the contract that
> > controls the funds, but with the condition that the
> > actuary signature has a specific `R`.
> 
> > As we know, `R` reuse --- creating a new signature for a
> > different message but the same `R` --- will leak the
> > private key.
> 
> > The actuary can be forced to put up an onchain bond.
> > The bond can be spent using the private key of the actuary.
> > If the actuary signs a transaction once, with a fixed `R`,
> > then its private key is still safe.
> 
> > However, if the actuary signs one transaction that spends
> > some transaction output, and then signs a different
> > transaction that spends the same transaction output, both
> > signatures need to use the same fixed `R`.
> > Because of the `R` reuse, this lets anyone who expected
> > one transaction to be confirmed, but finds that the other
> > one was confirmed, to derive the secret key of the
> > actuary from the two signatures, and then slash the bond
> > of the actuary.
> 
> From my understanding, if an off-chain state N1 with a negotiated group of 40 is halted in the middle of the actuary's R reveals due to the 40th participant non-interactivity, there is no guarantee than a new off-chain state N1' with a new negotiated group of 39 (from which evicted 40th's output is absent) do not re-use R reveals on N1. So for the actuary bond security, I think the R reveal should only happen once all the group participants have revealed their own signature. It sounds like some loose interactivity is still assumed, i.e all the non-actuary participants must be online at the same time, and lack of contribution is to blame as you have a "flat" off-chain construction (i.e no layering of the promised off-chain outputs in subgroups to lower novation interactivity).

Yes, there is some loose interactivity assumed.

However:

* The actuary is always online and can gather signatures for the next state in parallel with signing new transactions on top of the next state.
  * This is why `SIGHASH_ANYPREVOUT` is needed, as the transactions on top of the next state might spend either the actual next state (if the next state is successfully signed), or the current state plus additional transactions (i.e. the transaction that move from current state to next state) (if the next state fails to get fully signed and the participants decide to give up on the next state getting signed).

> More fundamentally, I think this actuarial system does not solve the "multi-party off-chain state correction" problem as there is no guarantee that the actuary does not slash the bond itself. And if the bond is guarded by users' pubkeys, there is no guarantee that the user will cooperate after the actuary equivocation is committed to sign a "fair" slashing transaction.

Indeed.

One can consider that the participants other than the actuary would generate a single public key known by the participants.
But then only one sockpuppet of the actuary is needed to add to the participant set.

Basically, the big issue is that the actuary needs to bond a significant amount of funds to each participant, and that bond is not part of the funding of the construction.

Other ways of ensuring single-use can be replaced, if that is possible.
Do you know of any?

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

[David A. Harding]

On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Now, suppose that participant A wants B to be assured that
>A will not double-spend the transaction.
>Then A solicits a single-spend signature from the actuary,
>getting a signature M:
>
>    current state                  +--------+----------------+
>    ---------+-------------+       |        | (M||CSV) && A2 |
>             |(M||CSV) && A| ----> |  M,A   +----------------+
>             +-------------+       |        | (M||CSV) && B2 |
>             |(M||CSV) && B|       +--------+----------------+
>             +-------------+
>             |(M||CSV) && C|
>    ---------+-------------+
>
>The above is now a confirmed transaction.

Good morning, ZmnSCPxj.

What happens if A and M are both members of a group of thieves that control a moderate amount of hash rate?  Can A provide the "confirmed transaction" containing M's sign-only-once signature to B and then, sometime[1] before the CSV expiry, generate a block that contains A's and M's signature over a different transaction that does not pay B?  Either the same transaction or a different transaction in the block also spends M's fidelity bond to a new address exclusively controlled by M, preventing it from being spent by another party unless they reorg the block chain.

If the CSV is a significant amount of time in the future, as we would probably want it to be for efficiency, then the thieving group A and M are part of would not need to control a large amount of hash rate to have a high probability of being successful (and, if they were unsuccessful at the attempted theft, they might not even lose anything and their theft attempt would be invisible to anyone outside of their group).

If A is able to double spend back to herself funds that were previously intended to B, and if cut through transactions were created where B allocated those same funds to C, I think that the double spend invalidates the cut-through even if APO is used, so I think the entire mechanism collapses into reputational trust in M similar to the historic GreenAddress.it co-signing mechanim.

Thanks,

-Dave

[1] Including in the past, via a Finney attack or an extended Finney attack supported by selfish mining.  

Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

[ZmnSCPxj]

Good morning Dave,



Sent with Proton Mail secure email.

------- Original Message -------
On Monday, September 18th, 2023 at 12:12 AM, David A. Harding <dave@dtrt.org> wrote:


> 
> On September 8, 2023 3:27:38 PM HST, ZmnSCPxj via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> 
> > Now, suppose that participant A wants B to be assured that
> > A will not double-spend the transaction.
> > Then A solicits a single-spend signature from the actuary,
> > getting a signature M:
> > 
> > current state +--------+----------------+
> > ---------+-------------+ | | (M||CSV) && A2 |
> > |(M||CSV) && A| ----> | M,A +----------------+
> > +-------------+ | | (M||CSV) && B2 |
> > |(M||CSV) && B| +--------+----------------+
> > +-------------+
> > |(M||CSV) && C|
> > ---------+-------------+
> > 
> > The above is now a confirmed transaction.
> 
> 
> Good morning, ZmnSCPxj.
> 
> What happens if A and M are both members of a group of thieves that control a moderate amount of hash rate? Can A provide the "confirmed transaction" containing M's sign-only-once signature to B and then, sometime[1] before the CSV expiry, generate a block that contains A's and M's signature over a different transaction that does not pay B? Either the same transaction or a different transaction in the block also spends M's fidelity bond to a new address exclusively controlled by M, preventing it from being spent by another party unless they reorg the block chain.

Indeed, the fidelity bond of M would need to be separately locked to `(M && B) || (M && CSV(1 year))`, and the actuary would need to lock new funds before the end of the time period or else the participants would be justified in closing the mechanism with the latest state.

And of course the bond would have to be replicated for each participant `A`, `B`, `C`.... as well, reducing scalability.

If possible, I would like to point attention at developing alternatives to the "sign-only-once" mechanism.

Basically: the point is that we want a mechanism that allows the always-online party (the "actuary") to *only* select transactions, and not move coins otherwise.
This is the nearest I have managed to get, without dropping down to a proof-of-work blockchain.

As noted, in a proof-of-work blockchain, the miners (the always-online party of the blockchain) can only select transactions, and cannot authorize moves without consent of the owners.
That is what we would want to replicate somehow, to reduce interactivity requirements.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 5282 bytes --]

Hi Zeeman,

> Basically, the big issue is that the actuary needs to bond a significant
amount of funds to each participant, and that bond is not part of the
funding of the construction.
>
> Other ways of ensuring single-use can be replaced, if that is possible.
> Do you know of any?

As explained in the other post, if you wish to ensure lack of equivocation
of an off-chain state I think you're left between updating dynamically the
subgroup of balance keys *on-chain* (i.e use the blockchain as an
anti-double spend oracle) or ensure any equivocation can be punished as
soon as one party gains knowledge of two commitment signatures.

I think you can design a fraud proof system encumbering each channel
factory or pool balance by leveraging OP_CHECKSIGFROMSTACK and the spent
outpoint committed as a partial transaction template. However, the amount
of satoshis that should be locked in such fidelity bonds must be equal to
the counterparty initial balance multiplied by the remaining
counterparties, as one can cheat against every other party (assuming there
is no shared communication channel where equivocation can be observed).

E.g if your factory has 1000 participants and your balance is 10 000
satoshis, you *must* lock up 10 000 000 in fidelity bonds while only 1 /
1000th of the amount can be leveraged as off-chain contract or payment.

Of course pre-nominated coordinator reduces the burden from the full *flat*
fidelity bond, though it has to be weighed with coordinator unavailability
occurence where each participant has to withdraw his balance on-chain, and
bears the fee cost.

Best,
Antoine

Le mar. 12 sept. 2023 à 10:41, ZmnSCPxj <ZmnSCPxj@protonmail.com> a écrit :

> Good morning Antoine,
>
>
> > Hi Zeeman
> >
> > > What we can do is to add the actuary to the contract that
> > > controls the funds, but with the condition that the
> > > actuary signature has a specific `R`.
> >
> > > As we know, `R` reuse --- creating a new signature for a
> > > different message but the same `R` --- will leak the
> > > private key.
> >
> > > The actuary can be forced to put up an onchain bond.
> > > The bond can be spent using the private key of the actuary.
> > > If the actuary signs a transaction once, with a fixed `R`,
> > > then its private key is still safe.
> >
> > > However, if the actuary signs one transaction that spends
> > > some transaction output, and then signs a different
> > > transaction that spends the same transaction output, both
> > > signatures need to use the same fixed `R`.
> > > Because of the `R` reuse, this lets anyone who expected
> > > one transaction to be confirmed, but finds that the other
> > > one was confirmed, to derive the secret key of the
> > > actuary from the two signatures, and then slash the bond
> > > of the actuary.
> >
> > From my understanding, if an off-chain state N1 with a negotiated group
> of 40 is halted in the middle of the actuary's R reveals due to the 40th
> participant non-interactivity, there is no guarantee than a new off-chain
> state N1' with a new negotiated group of 39 (from which evicted 40th's
> output is absent) do not re-use R reveals on N1. So for the actuary bond
> security, I think the R reveal should only happen once all the group
> participants have revealed their own signature. It sounds like some loose
> interactivity is still assumed, i.e all the non-actuary participants must
> be online at the same time, and lack of contribution is to blame as you
> have a "flat" off-chain construction (i.e no layering of the promised
> off-chain outputs in subgroups to lower novation interactivity).
>
> Yes, there is some loose interactivity assumed.
>
> However:
>
> * The actuary is always online and can gather signatures for the next
> state in parallel with signing new transactions on top of the next state.
>   * This is why `SIGHASH_ANYPREVOUT` is needed, as the transactions on top
> of the next state might spend either the actual next state (if the next
> state is successfully signed), or the current state plus additional
> transactions (i.e. the transaction that move from current state to next
> state) (if the next state fails to get fully signed and the participants
> decide to give up on the next state getting signed).
>
> > More fundamentally, I think this actuarial system does not solve the
> "multi-party off-chain state correction" problem as there is no guarantee
> that the actuary does not slash the bond itself. And if the bond is guarded
> by users' pubkeys, there is no guarantee that the user will cooperate after
> the actuary equivocation is committed to sign a "fair" slashing transaction.
>
> Indeed.
>
> One can consider that the participants other than the actuary would
> generate a single public key known by the participants.
> But then only one sockpuppet of the actuary is needed to add to the
> participant set.
>
> Basically, the big issue is that the actuary needs to bond a significant
> amount of funds to each participant, and that bond is not part of the
> funding of the construction.
>
> Other ways of ensuring single-use can be replaced, if that is possible.
> Do you know of any?
>
> Regards,
> ZmnSCPxj
>

[-- Attachment #2: Type: text/html, Size: 5986 bytes --]

Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

[ZmnSCPxj]

Good morning list,

I have been thinking further on this with regards to BitVM.

By my initial analyses, it seems that BitVM *cannot* be used to improve this idea.

What we want is to be able to restrict the actuary to only signing for a particular spend exactly once.
The mechanism proposed in the original post is to force `R` reuse by fixing `R`.
This requires a change in Bitcoin consensus on top of `SIGHASH_ANYPREVOUT` (which is desirable not only for its enablement of Decker-Russell-Osuntokun, which is multiparticipant, but also makes it more convenient as we can make changes in the offchain mechanism state asynchronously with the participants and actuary signing off on new transactions; we can "lock" the next state to some set of transactions occurring, then have the actuary "confirm" new transactions by signing them, then have the signature still be valid on the new state due to `SIGHASH_ANYPREVOUT` ignoring the actual input transaction ID).

The best I have been able to come up with is to have a program that checks if two signatures sign different things but have the same public key.
If this program validates, then the actuary is known to have cheated and we can arrange for the actuary to lose funds if this program validates.
However, BitVM triggers on DIShonest execution of the program, so that program cannot be used as-is.
Honest execution of the program leads to the BitVM contract resolving via timeout.
I have tried to figure out some way to change the "polarity" of the logic so that the actuary is punished, but it requires that the actuary act as validator instead of prover (and the aggrieved participant who was expecting the actuary to not violate the sign-only-once is the prover, which makes little sense, as the participant can challenge the actuary and force it to put up funds, then neglect to actually prove anything and enter the default timeout case where the prover gets the funds --- it has to be the actuary in the prover position, only getting back its funds after a timeout).

The opposite of showing that there exists two signatures with different messages but the same public key is to show that there does not exist any other signatures with a different message but same public key.
If such a program were written, then it would be trivial to make that program pass by simply denying it an input of any other signature, and an actuary in prover position can always commit to an input that lacks the second signature it made.

The actuary can run a program *outside* of BitVM, so it is also pointless to have the signing algorithm be written in BitVM.

Finally, in the actuarial system, the actuary is supposed to provide *something* that would make a transaction be immediately confirmable, instead of after a timeout.
But in BitVM, the *something* that the prover provides that makes some transaction immediately confirmable is to provide a dishonest execution of a BitVM program; it is the timeout that is the honest execution of the BitVM program.
In addition, the actuary should be restricted so that it can only show this for *one* transaction, and not for any other transactions.
There are more possible dishonest executions of a BitVM program than just one, but only one honest execution, which is the opposite of what we want.

So, so far, I have not been able to figure out how to use BitVM to replace the current forced `R` reuse mechanism for preventing multiple times the actuary commits.


Regards,
ZmnSCPxj

Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

[AdamISZ]

Hi Antoine, Zman and list,

The whole line of thinking here is interesting but indeed my first question was "who does the penalty of the actuary go to?" and yeah, it seems we're still fairly stuck there.

re:

> However, the amount of satoshis that should be locked in such fidelity bonds must be equal to the counterparty initial balance multiplied by the remaining counterparties, as one can cheat against every other party (assuming there is no shared communication channel where equivocation can be observed). E.g if your factory has 1000 participants and your balance is 10 000 satoshis, you *must* lock up 10 000 000 in fidelity bonds while only 1 / 1000th of the amount can be leveraged as off-chain contract or payment.

.. just wanted to point out that I was able to address this in PathCoin [1]. I found a way to avoid the linear dependence of total fidelity bond on number of participants, but only under severe restriction: using CTV/covenant (not so severe), but also, fixing order of transfer (ultra severe!). i.e. a coin of 10k sats only needs a lock up of 10k + delta sats from each participant that spends it (if you don't spend it then of course you don't strictly need to lock up anything).

the mechanism is, whimsically, similar to a series of airlocks: each scriptPubKey looks like [(A and CLTV) OR (T_A and CTV)] -> [(B and CLTV) OR (H(B) and T_A and CTV)] -> [(C and CLTV) OR (H(C) and T_A and CTV)] -> ...

The arrows -> indicate what the CTV points to; T_A is a point corresponding to an adaptor t_A, so that a spend of the pathcoin to A reveals t_A, the privkey of T_A, and the H() terms are locks, so that, when B transfers the pathcoin to C, he also transfers the preimage of H(B), so that the second scriptPubKey above can be spent to the third immediately, because C knows the preimage of H(B) as well as t_A as per previous.

Clearly, in a more flexible design, this might not be super interesting, but perhaps it gives a clue on a direction forward.

I tried to look for "reuse pathcoin fidelity bonds/penalty bonds across different pathcoins in parallel or in series" ideas but I continually hit against the same character of problems as you describe here, either double spend problems, or collusion problems. Only the above ultra-simple fixed-path seems to be stable.

I do have a suspicion that APO can indeed be a big part of any solution to this thorny problem (haven't thought about it for a while).

[1] https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da

Cheers,
waxwing/AdamISZ



Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, 4 October 2023 at 20:12, Antoine Riard via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> Hi Zeeman,
> > Basically, the big issue is that the actuary needs to bond a significant amount of funds to each participant, and that bond is not part of the funding of the construction.
> >
> > Other ways of ensuring single-use can be replaced, if that is possible.
> > Do you know of any?
> 
> As explained in the other post, if you wish to ensure lack of equivocation of an off-chain state I think you're left between updating dynamically the subgroup of balance keys *on-chain* (i.e use the blockchain as an anti-double spend oracle) or ensure any equivocation can be punished as soon as one party gains knowledge of two commitment signatures.
> 
> I think you can design a fraud proof system encumbering each channel factory or pool balance by leveraging OP_CHECKSIGFROMSTACK and the spent outpoint committed as a partial transaction template. However, the amount of satoshis that should be locked in such fidelity bonds must be equal to the counterparty initial balance multiplied by the remaining counterparties, as one can cheat against every other party (assuming there is no shared communication channel where equivocation can be observed).
> 
> E.g if your factory has 1000 participants and your balance is 10 000 satoshis, you *must* lock up 10 000 000 in fidelity bonds while only 1 / 1000th of the amount can be leveraged as off-chain contract or payment.
> 
> Of course pre-nominated coordinator reduces the burden from the full *flat* fidelity bond, though it has to be weighed with coordinator unavailability occurence where each participant has to withdraw his balance on-chain, and bears the fee cost.
> 
> Best,
> Antoine
> 
> Le mar. 12 sept. 2023 à 10:41, ZmnSCPxj <ZmnSCPxj@protonmail.com> a écrit :
> 
> > Good morning Antoine,
> > 
> > 
> > > Hi Zeeman
> > >
> > > > What we can do is to add the actuary to the contract that
> > > > controls the funds, but with the condition that the
> > > > actuary signature has a specific `R`.
> > >
> > > > As we know, `R` reuse --- creating a new signature for a
> > > > different message but the same `R` --- will leak the
> > > > private key.
> > >
> > > > The actuary can be forced to put up an onchain bond.
> > > > The bond can be spent using the private key of the actuary.
> > > > If the actuary signs a transaction once, with a fixed `R`,
> > > > then its private key is still safe.
> > >
> > > > However, if the actuary signs one transaction that spends
> > > > some transaction output, and then signs a different
> > > > transaction that spends the same transaction output, both
> > > > signatures need to use the same fixed `R`.
> > > > Because of the `R` reuse, this lets anyone who expected
> > > > one transaction to be confirmed, but finds that the other
> > > > one was confirmed, to derive the secret key of the
> > > > actuary from the two signatures, and then slash the bond
> > > > of the actuary.
> > >
> > > From my understanding, if an off-chain state N1 with a negotiated group of 40 is halted in the middle of the actuary's R reveals due to the 40th participant non-interactivity, there is no guarantee than a new off-chain state N1' with a new negotiated group of 39 (from which evicted 40th's output is absent) do not re-use R reveals on N1. So for the actuary bond security, I think the R reveal should only happen once all the group participants have revealed their own signature. It sounds like some loose interactivity is still assumed, i.e all the non-actuary participants must be online at the same time, and lack of contribution is to blame as you have a "flat" off-chain construction (i.e no layering of the promised off-chain outputs in subgroups to lower novation interactivity).
> > 
> > Yes, there is some loose interactivity assumed.
> > 
> > However:
> > 
> > * The actuary is always online and can gather signatures for the next state in parallel with signing new transactions on top of the next state.
> > * This is why `SIGHASH_ANYPREVOUT` is needed, as the transactions on top of the next state might spend either the actual next state (if the next state is successfully signed), or the current state plus additional transactions (i.e. the transaction that move from current state to next state) (if the next state fails to get fully signed and the participants decide to give up on the next state getting signed).
> > 
> > > More fundamentally, I think this actuarial system does not solve the "multi-party off-chain state correction" problem as there is no guarantee that the actuary does not slash the bond itself. And if the bond is guarded by users' pubkeys, there is no guarantee that the user will cooperate after the actuary equivocation is committed to sign a "fair" slashing transaction.
> > 
> > Indeed.
> > 
> > One can consider that the participants other than the actuary would generate a single public key known by the participants.
> > But then only one sockpuppet of the actuary is needed to add to the participant set.
> > 
> > Basically, the big issue is that the actuary needs to bond a significant amount of funds to each participant, and that bond is not part of the funding of the construction.
> > 
> > Other ways of ensuring single-use can be replaced, if that is possible.
> > Do you know of any?
> > 
> > Regards,
> > ZmnSCPxj