From: AdamISZ <AdamISZ@protonmail•com>
To: Antoine Riard <antoine.riard@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms
Date: Tue, 31 Oct 2023 22:12:20 +0000 [thread overview]
Message-ID: <kUmZIImH6VJ8pd1WdqSJiWtNIIuKAI7ZxvUUH2_DPHOZofN1zcZK_mJXBSGlKQ2OoSevQIVBWcZkH1m1oFCrBDPdzkIE9UjxZLbQ-RvUJcU=@protonmail.com> (raw)
In-Reply-To: <CALZpt+FN4XeGD2Yh7pEUhuFtgMtNgbVKThFgF-fU9pD3sPnc2A@mail.gmail.com>
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
next prev parent reply other threads:[~2023-10-31 22:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-09 1:27 ZmnSCPxj
2023-09-11 6:02 ` Antoine Riard
2023-09-12 9:41 ` ZmnSCPxj
2023-10-05 2:12 ` Antoine Riard
2023-10-31 22:12 ` AdamISZ [this message]
2023-09-18 0:12 ` David A. Harding
2023-09-18 3:37 ` ZmnSCPxj
2023-10-15 13:36 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='kUmZIImH6VJ8pd1WdqSJiWtNIIuKAI7ZxvUUH2_DPHOZofN1zcZK_mJXBSGlKQ2OoSevQIVBWcZkH1m1oFCrBDPdzkIE9UjxZLbQ-RvUJcU=@protonmail.com' \
--to=adamisz@protonmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox