From: Anthony Towns <aj@erisian•com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Bram Cohen <bram@chia•net>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
Date: Fri, 11 Mar 2022 14:46:45 +1000 [thread overview]
Message-ID: <20220311044645.GB7597@erisian.com.au> (raw)
In-Reply-To: <lMd2d3ntj6T-VfDDZ0SHn7cUdWWeFFWO3sHolPwMTdRyGUMRY8JwtICT0vbNy9PPg-u_inUplQ-OvB-wKvXNkEUB17pXBhA7ZDwu9vxiRx0=@protonmail.com> <NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>
On Tue, Mar 08, 2022 at 03:06:43AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> > > They're radically different approaches and
> > > it's hard to see how they mix. Everything in lisp is completely sandboxed,
> > > and that functionality is important to a lot of things, and it's really
> > > normal to be given a reveal of a scriptpubkey and be able to rely on your
> > > parsing of it.
> > The above prevents combining puzzles/solutions from multiple coin spends,
> > but I don't think that's very attractive in bitcoin's context, the way
> > it is for chia. I don't think it loses much else?
> 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.
Signature aggregation has a lot more maths and crypto involved than
reversible compression of puzzles/solutions. I was more meaning
cross-transaction relationships rather than cross-input ones though.
> > I /think/ the compression hook would be to allow you to have the puzzles
> > be (re)generated via another lisp program if that was more efficient
> > than just listing them out. But I assume it would be turtles, err,
> > lisp all the way down, no special C functions like with jets.
> Eh, you could use Common LISP or a recent-enough RnRS Scheme to write a cryptocurrency node software, so "special C function" seems to overprivilege C...
Jets are "special" in so far as they are costed differently at the
consensus level than the equivalent pure/jetless simplicity code that
they replace. Whether they're written in C or something else isn't the
important part.
By comparison, generating lisp code with lisp code in chia doesn't get
special treatment.
(You *could* also use jets in a way that doesn't impact consensus just
to make your node software more efficient in the normal case -- perhaps
via a JIT compiler that sees common expressions in the blockchain and
optimises them eg)
On Wed, Mar 09, 2022 at 02:30:34PM +0000, ZmnSCPxj via bitcoin-dev wrote:
> Do note that PTLCs remain more space-efficient though, so forget about HTLCs and just use PTLCs.
Note that PTLCs aren't really Chia-friendly, both because chia doesn't
have secp256k1 operations in the first place, but also because you can't
do a scriptless-script because the information you need to extract
is lost when signatures are non-interactively aggregated via BLS --
so that adds an expensive extra ECC operation rather than reusing an
op you're already paying for (scriptless script PTLCs) or just adding
a cheap hash operation (HTLCs).
(Pretty sure Chia could do (= PTLC (pubkey_for_exp PREIMAGE)) for
preimage reveal of BLS PTLCs, but that wouldn't be compatible with
bitcoin secp256k1 PTLCs. You could sha256 the PTLC to save a few bytes,
but I think given how much a sha256 opcode costs in Chia, that that
would actually be more expensive?)
None of that applies to a bitcoin implementation that doesn't switch to
BLS signatures though.
> > But if they're fully baked into the scriptpubkey then they're opted into by the recipient and there aren't any weird surprises.
> This is really what I kinda object to.
> Yes, "buyer beware", but consider that as the covenant complexity increases, the probability of bugs, intentional or not, sneaking in, increases as well.
> And a bug is really "a weird surprise" --- xref TheDAO incident.
Which is better: a bug in the complicated script code specified for
implementing eltoo in a BOLT; or a bug in the BIP/implementation of a
new sighash feature designed to make it easy to implement eltoo, that's
been soft-forked into consensus?
Seems to me, that it's always better to have the bug be at the wallet
level, since that can be fixed by upgrading individual wallet software.
> This makes me kinda wary of using such covenant features at all, and if stuff like `SIGHASH_ANYPREVOUT` or `OP_CHECKTEMPLATEVERIFY` are not added but must be reimplemented via a covenant feature, I would be saddened, as I now have to contend with the complexity of covenant features and carefully check that `SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` were implemented correctly.
> True I also still have to check the C++ source code if they are implemented directly as opcodes, but I can read C++ better than frikkin Bitcoin SCRIPT.
If OP_CHECKTEMPLATEVERIFY (etc) is implemented as a consensus update, you
probably want to review the C++ code even if you're not going to use it,
just to make sure consensus doesn't end up broken as a result. Whereas if
it's only used by other people's wallets, you might be able to ignore it
entirely (at least until it becomes so common that any bugs might allow
a significant fraction of BTC to be stolen/lost and indirectly cause a
systemic risk).
> Not to mention that I now have to review both the (more complicated due to more general) covenant feature implementation, *and* the implementation of `SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` in terms of the covenant feature.
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.
Cheers,
aj
next prev parent reply other threads:[~2022-03-11 4:46 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 ` 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
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 [this message]
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=20220311044645.GB7597@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bram@chia$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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