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 A0D0EC000B for ; 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 ; 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 ; 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 ; Sat, 19 Mar 2022 17:34:47 +0000 (UTC) Received: by mail-lj1-x22d.google.com with SMTP id r22so15022684ljd.4 for ; 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> In-Reply-To: From: Bram Cohen Date: Sat, 19 Mar 2022 10:34:34 -0700 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000dca33205da95ad04" X-Mailman-Approved-At: Sat, 19 Mar 2022 19:25:17 +0000 Cc: Bitcoin Protocol Discussion , Anthony Towns 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. > > > 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
On Wed, Mar 16, 2022 at 7:54 AM ZmnSCPxj = <ZmnSCPxj@protonmail.com&= gt; wrote:
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.

When usin= g 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 c= osts here:

* Cost of bytes to transmit over the network.
* Cost of CPU load.

There are three pot= ential 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 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.
=
=C2=A0
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).

Nah, C= PU costs are dominated by signatures. Simple operations like applying some = parameters to a template don't add much.
=C2=A0
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 "theoretically less secure than SECP256K1 Schnorr / ECDSA= ".
Is my understanding correct?
And if so, how theoretical would that be?

It inclu= des some an extra cryptographic assumption but it'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.
=C2=A0

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.

Yo= u do lose out on that when you aggregate.
=C2=A0
> I'm not sure that a "c= ovenant 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&= quot; rather
> than more.

<rant>
DSLs?
Domain-specific languages?

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.
=C2=A0
--000000000000dca33205da95ad04--