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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
