Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3103DC013E for ; Thu, 5 Mar 2020 09:57:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 28A85869BA for ; Thu, 5 Mar 2020 09:57:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti9enpPHtewN for ; Thu, 5 Mar 2020 09:57:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by whitealder.osuosl.org (Postfix) with ESMTPS id 008DD81AD9 for ; Thu, 5 Mar 2020 09:57:21 +0000 (UTC) Received: by mail-io1-f43.google.com with SMTP id r15so5829082iog.0 for ; Thu, 05 Mar 2020 01:57:21 -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=WDubY35pJnl666GOeZARRGKu0TnrUAyBbcXe7IVqybA=; b=VbkDPJp5iBfoiBHd5XAABq+97cNi1uYoKhKeqqevdMdfaDwMYwpTrWwq1btQSC9l59 b5Xdbn9Tuz+9yeuakeUWjsPTVuvqbQVokvtDiBcFGCRMyjnfwEd/2V/iJc6lyKuRLpdS MFpgUnKAXbRWokGpjUf/J5W4sHna1yK1QvRaPwSouwQbSSRz+Zohg3F7aVNR6ladh7Ds /mNXNxwsxU1EIHaqnC/IXWxUeJEPxkCtmj9f1yo1bPp9+UR1jfyoVXtmttZa6Xl3iFYZ sI+I4M3c+7h3qSY069JTpP6G6eEF6glFEJn6qOiztkXmq58/OTzmcBGVHSFoac7vgtV+ f7qw== 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=WDubY35pJnl666GOeZARRGKu0TnrUAyBbcXe7IVqybA=; b=h56ZXGRDzhPex9JBdkyvaTGrmu12/kHnnvkIcrlIovbiu/Zw1LgmfoSn5E75cDjNpx 9F0maPMgbtzp9hjxApEIBr/FaqQbbC1xjVnVoOrfJamg6Lh/4pkLdERkzdl+fZLUl2Nw EYmX7UTw1bT4T6BkKz0fto9K+KwLoG4Pu9CqT32BNaS5tWYsgRzOWp4IjJ5OZw6UrsfR 9Olb3v+3gzngiuZ02xTLGogSHxoCmYjZKD7bb5J/u9CeKO1fiARu8GFwSsXHBQhQdHZf 8YXgKF5JtiNjUxj/r4mx9NwZ9Bi+UHsCJscwg64MM4Nddz+vNG7qT18H/TAtqr2xAA+s qHjQ== X-Gm-Message-State: ANhLgQ2iLDywKCv5KdENndoTQ2xr3jw/xDIoaopuXJ9YAJ7RKEKUYtjo 5MrDBtsyg03fJmyYF1XSNi+SDn6tMStdbmlDSNk= X-Google-Smtp-Source: ADFU+vtMs6qD7e5iDb6hhXKN0ofjUmZ97C/fTERtmOR3GQM/4lvRvICEe+rXLzp9ZbdPe0WPFMdKcTxrmZyvwyI1nnM= X-Received: by 2002:a6b:8fd8:: with SMTP id r207mr1011058iod.158.1583402241130; Thu, 05 Mar 2020 01:57:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lloyd Fournier Date: Thu, 5 Mar 2020 20:56:54 +1100 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="0000000000001e8c8705a0189062" X-Mailman-Approved-At: Thu, 05 Mar 2020 10:25:45 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Hash function requirements for Taproot 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: Thu, 05 Mar 2020 09:57:23 -0000 --0000000000001e8c8705a0189062 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I am uncertain what you mean here by "coin-tossing". > From the comparison to MuSig, I imagine it is an interactive key generation protocol like this: > * Everybody generates fresh keypairs. > * Everybody sends the hash of their pubkey to everyone else. > * After receiving a hash of pubkey from everyone else, everybody sends their pubkey to everyone else. > * They add all their pubkeys to generate the aggregate key (and if using Taproot, use it as the internal key). > Is that correct? Yes exactly. The reason it's called coin tossing is that the resulting key is guaranteed to be uniformly random (in the random oracle model at least), so it's like tossing a fair 2^256 sided coin. This is not true in MuSig for example, where the aggregate key is not guaranteed to be from a uniform distribution against a malicious party (but still secure as an aggregate key). > However, it can generally be pointed out that, before you put anything into an n-of-n, you would damn well sure want to have *some* assurance that you can get it out later. So in general you would need coordination and interaction anyway to arrange getting into an n-of-n in the first place. Right. Taking your example of a lightning channel, when you set it up I don't *think* there is a way to use the non-interactivity of MuSig to remove any rounds of communication to get to the starting state where there is a channel funding on-chain and both parties have a tx that spends from it which returns their funds. Doing coin tossing for the aggregate key as well as the aggregate nonce shouldn't lead to any extra rounds of communication. The downside of coin tossing is that it requires honest parties to sample their keys non-deterministically (or at least have a counter to avoid using the same key twice). > On the other hand, it would be best to have at least some minimum of privacy by always interacting over Tor and having a Tor .onion address, which has absolutely horrid latency because human beings cry when peeling onions. > So in general reducing the latency by reducing communication rounds is better in general. > Counter to this, assuming you use an n-of-n in an offchain protocol of some sort, the number of communication rounds to generate the aggregate key may be dwarfed by the total number of communication rounds to create signatures to update the offchain protocol. > Counter counter to this is that one plan for reducing communications rounds for creating signatures during offchain operation is to (haha) use a Taproot with an n-of-n internal key and a tapscript that has n `OP_CHECKSIG` operations, so that for normal operation you just toss individual signatures at each other but at termination of the offchain protocol you can do the heavy MuSig-style signing with the n-of-n aggregate key. Counter=C2=B3 to this is that, in the case of lightning, the aggregate key = for a PTLC does not need to be chosen at payment time. They channel members could simply use the "master" aggregate key they generated by coin tossing at the channel's inception and pseudorandomly randomise it every time they need a new joint key (so the keys do not look related to everyone else on the chain but you would effectively just be reusing the same public key). Having said that if there is some advantage to using MuSig in some particular case I wouldn't hesitate to use it in combination with Taproot. I don't think the new assumption that I think you have to make wrt to the hash function really weighs up against most design considerations. In general, it is probably worth considering whether your protocol actually benefits from the non-interactivity MuSig gives in the key generation stage. If it doesn't due to the fact that it doesn't make signing anymore non-interactive, then coin tossing might be the answer. LL --0000000000001e8c8705a0189062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= div>> I am uncertain what you mean here by "coin-tossing".
= > From the comparison to MuSig, I imagine it is an interactive key gener= ation protocol like this:

> * Everybody generates fresh keypairs.=
> * Everybody sends the hash of their pubkey to everyone else.
&g= t; * After receiving a hash of pubkey from everyone else, everybody sends t= heir pubkey to everyone else.
> * They add all their pubkeys to gener= ate the aggregate key (and if using Taproot, use it as the internal key).
> Is that correct?

Yes exactly. The reason it= 9;s called coin tossing is that the resulting key is guaranteed to be unifo= rmly=C2=A0random (in the random oracle model at least), so it's like to= ssing a fair 2^256 sided coin. This is not true in MuSig for example, where= the aggregate key is not guaranteed to be from a uniform distribution agai= nst=C2=A0a malicious party (but still secure as an aggregate key).

> However, it can generally be pointed out that, before= you put anything into an n-of-n, you would damn well sure want to have *so= me* assurance that you can get it out later. So in general you would need c= oordination and interaction anyway to arrange getting into an n-of-n in the= first place.

Right. Taking your example of a ligh= tning channel, when you set it up I don't *think* there is a way to use= the non-interactivity of MuSig to remove any rounds of communication to ge= t to the starting state where there is a channel funding on-chain and both = parties have a tx that spends from it which returns their funds. Doing coin= tossing for the aggregate key as well as the aggregate nonce shouldn't= lead to any extra rounds of communication. The downside of coin tossing is= that it requires honest parties to sample their keys non-deterministically= (or at least have a counter to avoid using the same key twice).=C2=A0

> On the other hand, it would be best to have at le= ast some minimum of privacy by always interacting over Tor and having a Tor= .onion address, which has absolutely horrid latency because human beings c= ry when peeling onions.
> So in general reducing the latency by reduc= ing communication rounds is better in general.
> Counter to this, ass= uming you use an n-of-n in an offchain protocol of some sort, the number of= communication rounds to generate the aggregate key may be dwarfed by the t= otal number of communication rounds to create signatures to update the offc= hain protocol.
> Counter counter to this is that one plan for reducin= g communications rounds for creating signatures during offchain operation i= s to (haha) use a Taproot with an n-of-n internal key and a tapscript that = has n `OP_CHECKSIG` operations, so that for normal operation you just toss = individual signatures at each other but at termination of the offchain prot= ocol you can do the heavy MuSig-style signing with the n-of-n aggregate key= .

Counter=C2=B3 to this is that, in the case of li= ghtning, the aggregate key for a PTLC does not need to be chosen at payment= time.=C2=A0 They channel members could simply use the "master" a= ggregate key they generated by coin tossing at the channel's inception = and pseudorandomly randomise it every time they need a new joint key (so th= e keys do not look related to everyone else on the chain but you would effe= ctively just be reusing the same public key).

Havi= ng said that if there is some advantage to using MuSig in some particular c= ase I wouldn't hesitate to use it in combination with Taproot. I don= 9;t think the new assumption that I think you have to make wrt to the hash = function really weighs up against most design considerations. In general, i= t is probably worth considering whether your protocol actually benefits fro= m the non-interactivity MuSig gives in the key generation stage. If it does= n't due to the fact that it doesn't make signing anymore non-intera= ctive, then coin tossing might be the answer.

LL
--0000000000001e8c8705a0189062--