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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    Re: [bitcoin-dev] Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offcha
From:       AdamISZ via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date:       2023-10-31 22:12:20
Message-ID: kUmZIImH6VJ8pd1WdqSJiWtNIIuKAI7ZxvUUH2_DPHOZofN1zcZK_mJXBSGlKQ2OoSevQIVBWcZkH1m1oFCrBDPdzkIE9UjxZLbQ-RvUJcU= () protonmail ! com
[Download RAW message or body]

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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[prev in list] [next in list] [prev in thread] [next in thread] 