From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B7BD9C087F for ; Mon, 2 Dec 2019 03:30:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id A17DF87C30 for ; Mon, 2 Dec 2019 03:30:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5py985IDked for ; Mon, 2 Dec 2019 03:30:54 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by hemlock.osuosl.org (Postfix) with ESMTPS id EEF6087C17 for ; Mon, 2 Dec 2019 03:30:53 +0000 (UTC) Received: by mail-io1-f54.google.com with SMTP id i11so38620269iol.13 for ; Sun, 01 Dec 2019 19:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jVruYOSmwEsatV8SbCdRxoizaIA/SmfEEayvLh8E50I=; b=eFT+4qY7NFGj+wi3S+2qjMzNhkG0Gxq/yL0k/NIvxbPm9kM/U/z1zP+PeF1CKc4FU2 dqIZLTl2H/FrrarIAA8qLBzQv5qGDWz4KBmoJS8fcYHTcu018r5x6qxLTB42b8KczUjF efqIr4Fh87o1LLveGlRjbdLUK6MTJ3r6v3wHlZ7oXS6p6BzxXmnaGfwREl3pf3QXjOlD Lt2/JYcYy+U2c0KwNpl62grNvlgBlVMne3iCsAzoyPN/mb3Embp3ByMJ2BQMsh8rp52A iRfedoucqZi6n2O5Wvz09LUerCkk16PoPjolGw2/2/y2eAIgASUxPAX9fayH1XZqZBOQ DYcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jVruYOSmwEsatV8SbCdRxoizaIA/SmfEEayvLh8E50I=; b=W2SxiBVLW8HOeh8VXcpWuLLg/30NeRIgk6fQCgYG3B9AvmVVbWTnO7UfSilvVSrX/h 4mG3J4kDn2kFfrSTgDRmv3VXfIf2MTGEshMpl25YMfZUBsrcUKokZYdvLX6QLLs8ClXJ ZWrX51SE+CkJnLBA0Cm9CO5oMUp9N0lxwqrcF8iqmOPuANk1tkVQO2pQg6++PyhNDAy0 7xdn+NFPnn8yEyujx20Nk5ah6UeQbQODnIUk8rmvPmS3iPaO3OAvyXODm133T6V0kufu HBUKQSpWbIJnYl5le8LiLXNtUiKnyiEqjl2I/RM/5T5XBuXD31OtZQTsSYB02oW2vyWA Jvdg== X-Gm-Message-State: APjAAAXNuu1vIXQ5kq3sQvLHmajlTF+o4VCXa3DjOOEecMYKnbTCpxWj a/KXHHdpV/scAR7Emu5uMU9FF3QL0DbSZYBTpFU= X-Google-Smtp-Source: APXvYqxkGDzMcbI/0JWWf0WHyeb7MN7N+R9hUgNI6+zjTAxVOSXNSMldyH+ceUTOU5WDmRxoufwtH61/Jz3iz+Z8nV8= X-Received: by 2002:a02:c787:: with SMTP id n7mr11950831jao.85.1575257453061; Sun, 01 Dec 2019 19:30:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lloyd Fournier Date: Mon, 2 Dec 2019 14:30:26 +1100 Message-ID: To: ZmnSCPxj Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Mon, 02 Dec 2019 04:59:54 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Composable MuSig 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: Mon, 02 Dec 2019 03:30:54 -0000 Hi ZmnSCPxj, > > Just a quick note: I think there is a way to commit to a point properly with Pedersen commitments. Consider the following: > > COM(X) = (y*G + z*H, y*G + X) where y and z are random and the opening is (y,z,X). This seems to be a unconditionally hiding and computationally binding homomorphic commitment scheme to a point based on the DL problem rather than DDH. > > So the Pedersen commitment commits to a tweak on `X`, which is revealed later so we can un-tweak `X`. > Am I correct in assuming that you propose to use `X` for the contribution to `R` for a participant? > How is it different from using ElGamal commitments? Yes. It's not significantly different. It is unconditionally hiding rather than binding (ElGamal is unconditionally binding). I just thought of it while reading your post so I mentioned it. The real question is what properties does the commitment scheme need to be appropriate for MuSig R coin tossing? In the security proof, the commitment hash is modelled as a random oracle rather than as an abstract commitment scheme. I wonder if any MuSig author has an opinion on whether the H_com interaction can be generalised to a commitment scheme with certain properties (e.g equivocal, extractable). By the looks of it, the random oracle is never explicitly programmed except with randomly generated values so maybe there is hope that a non ROM commitment scheme can do the job. I guess the reduction would then be to either breaking the discrete logarithm problem OR some property of the commitment scheme. Cheers, LL