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.