📅 Original date posted:2022-03-19
📝 Original message:On Wed, Mar 16, 2022 at 7:54 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> 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.
>
> <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220319/9f946703/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 23:05:19
in reply to nevent1q…dlgt
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 23:05:19Event JSON
{
"id": "0b2a8401c96735c9bea71a8327ead3150dbff4579cfb0b32d0d1e65c7657d6bc",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686179119,
"kind": 1,
"tags": [
[
"e",
"17a237ce59197bc5ffad96769beec5209b19830977cb935d9412190ad411e7e9",
"",
"root"
],
[
"e",
"39bc393e09cbfd4d9ac32ba1158956f307e27f73cd2c829636b88f36316730a0",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2022-03-19\n📝 Original message:On Wed, Mar 16, 2022 at 7:54 AM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e My point is that in the past we were willing to discuss the complicated\n\u003e crypto math around cross-input sigagg in order to save bytes, so it seems\n\u003e to me that cross-input compression of puzzles/solutions at least merits a\n\u003e discussion, since it would require a lot less heavy crypto math, and *also*\n\u003e save bytes.\n\u003e\n\nWhen using BLS signatures all that math is much simpler. You use a single\naggregated signature and always aggregate everything all the time.\n\nI think there are two costs here:\n\u003e\n\u003e * Cost of bytes to transmit over the network.\n\u003e * Cost of CPU load.\n\u003e\n\nThere are three potential costs: CPU, bytes, and making outputs. In Chia\nit's balanced so that the costs to a standard transaction in all three\nbuckets are roughly the same. In Bitcoin the three are implicitly tied to\neach other by design which makes vbytes work okayish for Bitcoin Script as\nit exists today.\n\n\n\u003e It seems to me that lisp-generating-lisp compression would reduce the cost\n\u003e of bytes transmitted, but increase the CPU load (first the metaprogram\n\u003e runs, and *then* the produced program runs).\n\u003e\n\nNah, CPU costs are dominated by signatures. Simple operations like applying\nsome parameters to a template don't add much.\n\n\n\u003e Not being a mathist, I have absolutely no idea, but: at least as I\n\u003e understood from the original mimblewimble.txt from Voldemort, BLS\n\u003e signatures had an additional assumption, which I *think* means\n\u003e \"theoretically less secure than SECP256K1 Schnorr / ECDSA\".\n\u003e Is my understanding correct?\n\u003e And if so, how theoretical would that be?\n\u003e\n\nIt includes some an extra cryptographic assumption but it's extremely\ntheoretical, having more to do with guessing what size of group provides\ncomparable security in number of bits than whether the whole approach is in\nquestion. BLS12-381 is fairly conservative.\n\n\n\u003e\n\u003e PTLC signatures have the very nice property of being indistinguishable\n\u003e from non-PTLC signatures to anyone without the adaptor, and I think\n\u003e privacy-by-default should be what we encourage.\n\u003e\n\nYou do lose out on that when you aggregate.\n\n\n\u003e \u003e I'm not sure that a \"covenant language implementation\" would necessarily\n\u003e \u003e be \"that\" complicated. And if so, having a DSL for covenants could,\n\u003e \u003e at least in theory, make for a much simpler implementation of\n\u003e \u003e ANYPREVOUT/CTV/TLUV/EVICT/etc than doing it directly in C++, which\n\u003e \u003e might mean those things are less likely to have \"weird surprises\" rather\n\u003e \u003e than more.\n\u003e\n\u003e \u003crant\u003e\n\u003e DSLs?\n\u003e Domain-specific languages?\n\u003e\n\nBitcoin Script is already a domain specific language, and the point of\nadding in a lisp-family language would be to make it so that covenants and\ncapabilities can be implemented in the same language as is used for regular\ncoin scripting. The idea is to get off the treadmill of soft forking in\nlanguage features every time new functionality is wanted and make it\npossible to implement all that on chain.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220319/9f946703/attachment.html\u003e",
"sig": "64837dfa3ed7fe0c65daf06fd5ed8ea66c2c50e5b65a778b73f595becb0cda1b9fa1480ae6d9aaad9bb72b0248c0502d08df60c1d280668b2835dca42890d4f2"
}