path: root/c7/4551e2cc10403629e4747f62e19504554feb76

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E4C13C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  9 Sep 2023 01:27:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id BB758405C5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  9 Sep 2023 01:27:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org BB758405C5
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=qQot2O6H
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.588
X-Spam-Level: 
X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, BITCOIN_OBFU_SUBJ=1, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FILL_THIS_FORM=0.001, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5,
 RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_LOAN=0.01]
 autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id F2PwlRioqYeG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  9 Sep 2023 01:27:53 +0000 (UTC)
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 7DB4D408C5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  9 Sep 2023 01:27:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7DB4D408C5
Date: Sat, 09 Sep 2023 01:27:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1694222868; x=1694482068;
 bh=4AUxVfLWWJbIJIzw4LiCiJJwM2BxpP9EvZi8suhveOk=;
 h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
 b=qQot2O6HSxTVqhcWHo8S9IjaDOIANgLF45Q0FGVIW888J9nmSun+WkmFJh/18jVl4
 3oQUPKiTBfmcHkTcR7OYcao9py20klHXCtBMF3ed+ah4Wj/8oVeCwd/v32325Oxnca
 h3kKd8oGk5VZHeEhEFyj48eENQBsAtWCcRc8IjqFLWMjFqqczZ1UIpX1Jr36sigedQ
 UMhlJr4BbbxKIsPtyO4Nac+O/qL3a6OEA9BhaNux8d5BKhRdIVvmhkt5Mmr3Ix0+Qf
 8K/AvcL/BMIKWPY5GIg8p57LEJLiOgfrAt0CBi0Lu0oBsF+1PpLkCo3Xov/bFv+pbt
 W0yg3fnnajAVw==
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <3G-PTmIOM96I32Sh_uJQqQlv8pf81bEbIvH9GNphyj0429Pan9dQEOez69bgrDzJunXaC9d2O5HWPmBQfQojo67mKQd7TOAljBFL3pI2Dbo=@protonmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N
	> 2) Multiparticipant Offchain Mechanisms
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Sep 2023 01:27:55 -0000

 (N > 2) Multiparticipant Offchain Mechanisms

Introduction=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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.=20

There are two important properties here:=20

* 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. =20
            =20
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 =3D 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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.