From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C5714C002D for ; Fri, 3 Jun 2022 14:31:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id B565582AB9 for ; Fri, 3 Jun 2022 14:31:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0WAdDdlfwsx for ; Fri, 3 Jun 2022 14:31:33 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by smtp1.osuosl.org (Postfix) with ESMTPS id DA2F78295A for ; Fri, 3 Jun 2022 14:31:32 +0000 (UTC) Received: by mail-lj1-x22c.google.com with SMTP id a23so8609206ljd.9 for ; Fri, 03 Jun 2022 07:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=FlNKzG/jrL4Je7vj/+3jFUFlQT09ZMe07Zp+N6k5rZk=; b=MfyvscERV7D2vVJ+7kjBxXe9UVonOXn9mXOKgpeVlY8iLIjmmolWD86OrrOM58BNED HsCIeEIQVWVoZ9kgTGTC3t83K5KHYR4TWbZBf73EyZSYyfKPafZgdVedm7snaJjUisR8 x5p61BP0NXJOTHOAdDXH1+4vSnp9iy6leozWT+i7Gpd+wIFk3BCJO1BfXqkIhtN7UjBe KAF8V/Ll0hrEHzldpxSJ+5sEbskie2sTzHy5jXF22uK7cb/zHOzO7y1UNUNB83gpjZcS FFAB+lWifUuUPCmbhpmIc8y5MViinOIp8w+fiobk4JjLqBo0ewPpct43cKwDbfpghs52 mw9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FlNKzG/jrL4Je7vj/+3jFUFlQT09ZMe07Zp+N6k5rZk=; b=F04mv3XONC5eWRPH5ViMU7NTKQ4qTDdk9VVsYBWziEA1xwSm0DZpxzBFWihc2khhny vjdH1HqggPulao5XQKD1FAFYcb6SCUBkzSVk8D69eq1DWRkdgXM2RICV9bKestwMM1No l/b4gUa1xxHbTrDLvd2gU/FeAS63F0hFEjRgXd168QUqLRCrVMHfMv1MF/Lg51T/ByF6 OCQrS/DrO3iEAH7//YAX2vHfKY0Cpu/83JZ2Mi2kXlIgkFDHTmFuGHmKFc4Dn6qsdKOz +T+F9njKzSN6rAT15cYfPhg8PbccEO2ok3M1qE+uXK8v4R0wa5XNkcb8WjKTgpNA4TTz JUcg== X-Gm-Message-State: AOAM5324wmwzTga0wSYXmwpfIH8iK/WFCpSMdtv9BfVtRB/nqrs5N/hf WEQkyGWktozrwR3W/JqvIzXdZY6hf89AX3MVKLy9TKeqpwWQ X-Google-Smtp-Source: ABdhPJwkTzo5UNIg7YzGXqtFj4rjujm3O4uQkn0A2WPoyacQyBYW4DqxhYbZ6LR0BDhPsmnuCz01jVV6uLns/HrkTXI= X-Received: by 2002:a05:651c:1506:b0:255:4b71:9bd with SMTP id e6-20020a05651c150600b002554b7109bdmr17131367ljf.275.1654266690409; Fri, 03 Jun 2022 07:31:30 -0700 (PDT) MIME-Version: 1.0 From: Erik Aronesty Date: Fri, 3 Jun 2022 10:31:19 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000721a8e05e08bfa1f" X-Mailman-Approved-At: Fri, 03 Jun 2022 14:51:44 +0000 Subject: [bitcoin-dev] signature abstraction 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: Fri, 03 Jun 2022 14:31:33 -0000 --000000000000721a8e05e08bfa1f Content-Type: text/plain; charset="UTF-8" was thinking it might be possible to create a protocol for signatures where some bounded elliptic curve parameters are in the script, allowing the efficient verification of a broad range of elliptic curves schnorr signatures... rather than a fixed curve has anyone proposed this sort of thing before? seems like it could allow higher bitness, broad hsm compatibility, and a "decentralization and competitiveness" of security parameters for different environments would be useful to me, but not sure how many people care about this --000000000000721a8e05e08bfa1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
was thinking it might be possible to create a protocol for= signatures where some bounded elliptic curve parameters are in the script,= allowing the efficient verification of a broad range of elliptic curves sc= hnorr signatures... rather than a fixed curve

has anyone proposed th= is sort of thing before?

seems like it could allow highe= r bitness, broad hsm compatibility, and a "decentralization and compet= itiveness" of security parameters for different environments

would be useful to me, but not sure how many people care ab= out this

--000000000000721a8e05e08bfa1f--