From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A9295C0032 for ; Sun, 15 Oct 2023 13:36:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 846F94050E for ; Sun, 15 Oct 2023 13:36:20 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 846F94050E Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=SOXTKq9B X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5TKusG0bHfk for ; Sun, 15 Oct 2023 13:36:19 +0000 (UTC) Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com [51.77.79.158]) by smtp4.osuosl.org (Postfix) with ESMTPS id 81C2B40069 for ; Sun, 15 Oct 2023 13:36:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 81C2B40069 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1697376970; x=1697636170; bh=aLNK9tGpEEtOj1Oda63joaR7DnK5vg9q7hnM52zadPc=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=SOXTKq9B42ql21dXqx6YDuU+ndYcN9pQgoxR922aor7RMQqTpIIZK2k1ZQI2HQz3V 7vsKxP8rVpko0vvii4YcEbFy6VMK4wtkAWujQvBm8+xV2wpyrPcB0Cd9uKyhTCA2I9 diYOxhMWoOnqYbTUV6OzKP7IbMGxstGsAqRqsltPPAL8iha0bo468nnqEQtTYR/f7j jy9Z+VWXX+H901Pl9cgTTEKv3daWb4CQKER6AExoM8QvJ05B+wHcxV2QepNJVFZgI3 jjyrt4a5gV5VVK9bTGXeeoL0GHHVf4qhx96ZYiMpwsLbUidlV6tKct68MgrWimk03t j1PslIN6oSGSQ== Date: Sun, 15 Oct 2023 13:36:00 +0000 To: Bitcoin Protocol Discussion From: ZmnSCPxj Message-ID: <6I7jG9PNNaWUZ8OnqAAQg0TJQ9PwGvD05iXYSOuN0XiezIJCChGlsxKZ30RwYfpeKlJyj7gB_rq1kPSR8UX6tOm-X7zanL_MXVrGEon3txc=@protonmail.com> In-Reply-To: References: <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: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2023 13:36:20 -0000 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 thi= s idea. What we want is to be able to restrict the actuary to only signing for a pa= rticular 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 ma= ke changes in the offchain mechanism state asynchronously with the particip= ants and actuary signing off on new transactions; we can "lock" the next st= ate 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 transa= ction 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 prog= ram cannot be used as-is. Honest execution of the program leads to the BitVM contract resolving via t= imeout. I have tried to figure out some way to change the "polarity" of the logic s= o that the actuary is punished, but it requires that the actuary act as val= idator instead of prover (and the aggrieved participant who was expecting t= he actuary to not violate the sign-only-once is the prover, which makes lit= tle 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 ti= meout 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 mes= sages but the same public key is to show that there does not exist any othe= r signatures with a different message but same public key. If such a program were written, then it would be trivial to make that progr= am pass by simply denying it an input of any other signature, and an actuar= y in prover position can always commit to an input that lacks the second si= gnature it made. The actuary can run a program *outside* of BitVM, so it is also pointless t= o have the signing algorithm be written in BitVM. Finally, in the actuarial system, the actuary is supposed to provide *somet= hing* 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 tran= saction immediately confirmable is to provide a dishonest execution of a Bi= tVM program; it is the timeout that is the honest execution of the BitVM pr= ogram. 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 o= ne, 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 ac= tuary commits. Regards, ZmnSCPxj