path: root/11/8e6a2db0fee18205e76344da8b4e32826be78b

Return-Path: <bram@chia.net>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A0D0EC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Mar 2022 17:34:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8F53A4090F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Mar 2022 17:34:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=chia.net
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 VaXmN1LbZlfa
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Mar 2022 17:34:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com
 [IPv6:2a00:1450:4864:20::22d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 889EC408E8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Mar 2022 17:34:47 +0000 (UTC)
Received: by mail-lj1-x22d.google.com with SMTP id r22so15022684ljd.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Mar 2022 10:34:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=76pm3T2EdxAOOJ/wJwbktVhayTIG5jT4ApmOlB03vAs=;
 b=mjQPqCna8LIY17Zx7JC3OHk8f4IUR84sQOE2lCu+IYGLuB6gMlw4ozhpOLr4X7MXgd
 B20SFyFuB4t8rM53m6SiBk5ghSTf00PY8w1xOAD57qlAzPnqrOfzslHqCL1Eg+i1I3cW
 PqETB9lKHka/VAgVjqou6+IKy1C0ahPaQOOcEqwo6bhY7LaskfVQzApSxtW52JwJFzbQ
 lF/2HkaHyYVeoiGTVAOMlviWq8r9Fi38AWLr41MR+I8Uls8RW1YiaQLh0ILSJUJdJhPh
 LCfXqreR64/xHWIqa8Cw/zebEEcK/2eC2Rm7TNk/40m3362Xq66NUQG14G/q9x5mtZiM
 qStQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=76pm3T2EdxAOOJ/wJwbktVhayTIG5jT4ApmOlB03vAs=;
 b=kqOJfkdrJEEZppFeurV2b2dCfoN5K0lPOrfaU2hAkwaj7dJ6tTvCGRJkK/m4GCj5Rl
 s+Mir+4orvDRxvI9h2wpP5S+nlmqXiK6F3ZDs1YyAmAU3FQW+/YD7q2i6Podlr8vSOEA
 HOm8Pbw0TeXUC9A8wgd1Sy7qN1uMhBfeKR8eEABiJYTb5+PZJ6Zxf9sP8RgQeP/3T2wP
 vvLkLm5EubBE+4Vx62lpIiqou2hhkI4LA4WG1jTd8IGlYRjKipeFt2ilRMah0RKXfY7+
 HhVKrFDRpC389U3CKNXviegm0xM78HRWrgt97swCCVzcvJoUaQO3R+TS1xCAuAfUFMdg
 /aAw==
X-Gm-Message-State: AOAM53363AxsUdnIY7ivE0SY13gYwaHUWWfLlK2umq5JKI9KarjL7N8D
 hCIUs4aAIb/dA3FrLjArrLoXmq6E3WmQJwwr622wSQ==
X-Google-Smtp-Source: ABdhPJzrU8dW9uE4429qsTPyBzc6OcPFr8LIeGX4ZdJdWjKSnSBJg9OPS7X2sZ2bam7Rj99it1JneZUsrqFzUl2Ky7U=
X-Received: by 2002:a2e:7d05:0:b0:247:ed41:690d with SMTP id
 y5-20020a2e7d05000000b00247ed41690dmr9978543ljc.92.1647711285448; Sat, 19 Mar
 2022 10:34:45 -0700 (PDT)
MIME-Version: 1.0
References: <20220311044645.GB7597@erisian.com.au>
 <L7tNMIZp05o7FReQe8l-TjBDkuqbdby8Rk92X_BXEl7Hp5B7eAa-oyS0wMPDvLec03sJ7Q_yoW6ker0LS8k8VPXEHRhObF3EdB6zpLNZxRo=@protonmail.com>
In-Reply-To: <L7tNMIZp05o7FReQe8l-TjBDkuqbdby8Rk92X_BXEl7Hp5B7eAa-oyS0wMPDvLec03sJ7Q_yoW6ker0LS8k8VPXEHRhObF3EdB6zpLNZxRo=@protonmail.com>
From: Bram Cohen <bram@chia.net>
Date: Sat, 19 Mar 2022 10:34:34 -0700
Message-ID: <CAHUJnBA57N=_yYb_MdchpBSGCVGVbnaRjMRCTj48UwVqMeWVVQ@mail.gmail.com>
To: ZmnSCPxj <zmnscpxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000dca33205da95ad04"
X-Mailman-Approved-At: Sat, 19 Mar 2022 19:25:17 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Mar 2022 17:34:48 -0000

--000000000000dca33205da95ad04
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 16, 2022 at 7:54 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> My point is that in the past we were willing to discuss the complicated
> crypto math around cross-input sigagg in order to save bytes, so it seems
> to me that cross-input compression of puzzles/solutions at least merits a
> discussion, since it would require a lot less heavy crypto math, and *also*
> save bytes.
>

When using BLS signatures all that math is much simpler. You use a single
aggregated signature and always aggregate everything all the time.

I think there are two costs here:
>
> * Cost of bytes to transmit over the network.
> * Cost of CPU load.
>

There are three potential costs: CPU, bytes, and making outputs. In Chia
it's balanced so that the costs to a standard transaction in all three
buckets are roughly the same. In Bitcoin the three are implicitly tied to
each other by design which makes vbytes work okayish for Bitcoin Script as
it exists today.


> It seems to me that lisp-generating-lisp compression would reduce the cost
> of bytes transmitted, but increase the CPU load (first the metaprogram
> runs, and *then* the produced program runs).
>

Nah, CPU costs are dominated by signatures. Simple operations like applying
some parameters to a template don't add much.


> Not being a mathist, I have absolutely no idea, but: at least as I
> understood from the original mimblewimble.txt from Voldemort, BLS
> signatures had an additional assumption, which I *think* means
> "theoretically less secure than SECP256K1 Schnorr / ECDSA".
> Is my understanding correct?
> And if so, how theoretical would that be?
>

It includes some an extra cryptographic assumption but it's extremely
theoretical, having more to do with guessing what size of group provides
comparable security in number of bits than whether the whole approach is in
question. BLS12-381 is fairly conservative.


>
> PTLC signatures have the very nice property of being indistinguishable
> from non-PTLC signatures to anyone without the adaptor, and I think
> privacy-by-default should be what we encourage.
>

You do lose out on that when you aggregate.


> > I'm not sure that a "covenant language implementation" would necessarily
> > be "that" complicated. And if so, having a DSL for covenants could,
> > at least in theory, make for a much simpler implementation of
> > ANYPREVOUT/CTV/TLUV/EVICT/etc than doing it directly in C++, which
> > might mean those things are less likely to have "weird surprises" rather
> > than more.
>
> <rant>
> DSLs?
> Domain-specific languages?
>

Bitcoin Script is already a domain specific language, and the point of
adding in a lisp-family language would be to make it so that covenants and
capabilities can be implemented in the same language as is used for regular
coin scripting. The idea is to get off the treadmill of soft forking in
language features every time new functionality is wanted and make it
possible to implement all that on chain.

--000000000000dca33205da95ad04
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Mar 16, 2022 at 7:54 AM ZmnSCPxj =
&lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&=
gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">My point is that in the past we were willing to discu=
ss the complicated crypto math around cross-input sigagg in order to save b=
ytes, so it seems to me that cross-input compression of puzzles/solutions a=
t least merits a discussion, since it would require a lot less heavy crypto=
 math, and *also* save bytes.<br></blockquote><div><br></div><div>When usin=
g BLS signatures all that math is much simpler. You use a single aggregated=
 signature and always aggregate everything all the time.</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">I think there are two c=
osts here:<br>
<br>
* Cost of bytes to transmit over the network.<br>
* Cost of CPU load.<br></blockquote><div><br></div><div>There are three pot=
ential costs: CPU, bytes, and making outputs. In Chia it&#39;s balanced so =
that the costs to a standard transaction in all three buckets are roughly t=
he same. In Bitcoin the three are implicitly tied to each other by design w=
hich makes vbytes work okayish for Bitcoin Script as it exists today.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It seems=
 to me that lisp-generating-lisp compression would reduce the cost of bytes=
 transmitted, but increase the CPU load (first the metaprogram runs, and *t=
hen* the produced program runs).<br></blockquote><div><br></div><div>Nah, C=
PU costs are dominated by signatures. Simple operations like applying some =
parameters to a template don&#39;t add much.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Not being a mathist, I have absol=
utely no idea, but: at least as I understood from the original mimblewimble=
.txt from Voldemort, BLS signatures had an additional assumption, which I *=
think* means &quot;theoretically less secure than SECP256K1 Schnorr / ECDSA=
&quot;.<br>
Is my understanding correct?<br>
And if so, how theoretical would that be?<br></blockquote><div><br>It inclu=
des some an extra cryptographic assumption but it&#39;s extremely theoretic=
al, having more to do with guessing what size of group provides comparable =
security in number of bits than whether the whole approach is in question. =
BLS12-381 is fairly conservative.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
PTLC signatures have the very nice property of being indistinguishable from=
 non-PTLC signatures to anyone without the adaptor, and I think privacy-by-=
default should be what we encourage.<br></blockquote><div><br></div><div>Yo=
u do lose out on that when you aggregate.</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">&gt; I&#39;m not sure that a &quot;c=
ovenant language implementation&quot; would necessarily<br>
&gt; be &quot;that&quot; complicated. And if so, having a DSL for covenants=
 could,<br>
&gt; at least in theory, make for a much simpler implementation of<br>
&gt; ANYPREVOUT/CTV/TLUV/EVICT/etc than doing it directly in C++, which<br>
&gt; might mean those things are less likely to have &quot;weird surprises&=
quot; rather<br>
&gt; than more.<br>
<br>
&lt;rant&gt;<br>
DSLs?<br>
Domain-specific languages?<br></blockquote><div><br></div><div>Bitcoin Scri=
pt is already a domain specific language, and the point of adding in a lisp=
-family language would be to make it so that covenants and capabilities can=
 be implemented in the same language as is used for regular coin scripting.=
 The idea is to get off the treadmill of soft forking in language features =
every time new functionality is wanted and make it possible to implement al=
l that on chain.</div><div>=C2=A0</div></div></div>

--000000000000dca33205da95ad04--