public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Bram Cohen <bram@chia.net>
To: ZmnSCPxj <zmnscpxj@protonmail.com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
Date: Tue, 8 Mar 2022 19:07:51 -0800	[thread overview]
Message-ID: <CAHUJnBBduZA9KgcYwEG7Zn3qPrBpnCRWukQpPzJJjpb3S933Ag@mail.gmail.com> (raw)
In-Reply-To: <NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

>
> But cross-input signature aggregation is a nice-to-have we want for
> Bitcoin, and, to me, cross-input sigagg is not much different from
> cross-input puzzle/solution compression.
>

Cross-input signature aggregation has a lot of headaches unless you're
using BLS signatures, in which case you always aggregate everything all the
time because it can be done after the fact noninteractively. In that case
it makes sense to have a special aggregated signature which always comes
with a transaction or block. But it might be a bit much to bundle both lisp
and BLS support into one big glop.



>
> For example you might have multiple HTLCs, with mostly the same code
> except for details like who the acceptor and offerrer are, exact hash, and
> timelock, and you could claim multiple HTLCs in a single tx and feed the
> details separately but the code for the HTLC is common to all of the HTLCs.
> You do not even need to come from the same protocol if multiple protocols
> use the same code for implementing HTLC.
>

HTLCs, at least in Chia, have embarrassingly little code in them. Like, so
little that there's almost nothing to compress.


> This does not apply to current Bitcoin since we no longer accept a SCRIPT
> from the spender, we now have a witness stack.
>

My mental model of Bitcoin is to pretend that segwit was always there and
the separation of different sections of data is a semantic quibble.


> So this seems to be more like "do not write broken SCRIPTs"?
>

In general if people footgun that's their own fault. The resistance to
covenants and capabilities in the past has largely been around what would
happen if you had opt-out covenants which acted as riders and could monkey
around in later spends which were none of their business. But if they're
fully baked into the scriptpubkey then they're opted into by the recipient
and there aren't any weird surprises.

[-- Attachment #2: Type: text/html, Size: 2813 bytes --]

  reply	other threads:[~2022-03-09  3:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.30513.1646355894.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-03-07  6:26 ` [bitcoin-dev] bitcoin scripting and lisp Bram Cohen
2022-03-07 22:56   ` ZmnSCPxj
2022-03-09  2:24     ` Bram Cohen
2022-03-08  1:27   ` Anthony Towns
2022-03-08  3:06     ` ZmnSCPxj
2022-03-09  3:07       ` Bram Cohen [this message]
2022-03-09 14:30         ` ZmnSCPxj
2022-03-16  6:40           ` Bram Cohen
2022-03-16 15:09             ` ZmnSCPxj
2022-03-11  4:46       ` Anthony Towns
2022-03-16  6:52         ` Bram Cohen
2022-03-16 14:54         ` ZmnSCPxj
2022-03-19 17:34           ` Bram Cohen
2022-03-22 23:37           ` Anthony Towns
2022-03-09  2:54     ` Bram Cohen
2022-03-10  6:47       ` Anthony Towns
2022-03-16  6:45         ` Bram Cohen
2022-03-04  1:04 Anthony Towns
2022-03-04 23:10 ` ZmnSCPxj
     [not found]   ` <CAD5xwhiZx+dp46Gn23tQRKc5PgJHmaJ_HC-38VB5WdJjWVVc4g@mail.gmail.com>
2022-03-05 13:41     ` Jeremy Rubin
2022-03-05 20:10       ` Russell O'Connor
2022-03-05 23:20         ` ZmnSCPxj
2022-03-06  2:09           ` Russell O'Connor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHUJnBBduZA9KgcYwEG7Zn3qPrBpnCRWukQpPzJJjpb3S933Ag@mail.gmail.com \
    --to=bram@chia.net \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=zmnscpxj@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox