📅 Original date posted:2022-03-09
📝 Original message:On Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj <ZmnSCPxj at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220308/5137151d/attachment-0001.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 23:05:17
in reply to nevent1q…xmj3
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 23:05:17Event JSON
{
"id": "8cac139e746eb2a8788ab4f3c81fe620b06c000bfb3aa0abbaa7f2e3448b923b",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686179117,
"kind": 1,
"tags": [
[
"e",
"17a237ce59197bc5ffad96769beec5209b19830977cb935d9412190ad411e7e9",
"",
"root"
],
[
"e",
"10daa94cd2ff4ccdcc685e82b5b1c647114918c7ac11e9259a0278d8f32db25a",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2022-03-09\n📝 Original message:On Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e\n\u003e But cross-input signature aggregation is a nice-to-have we want for\n\u003e Bitcoin, and, to me, cross-input sigagg is not much different from\n\u003e cross-input puzzle/solution compression.\n\u003e\n\nCross-input signature aggregation has a lot of headaches unless you're\nusing BLS signatures, in which case you always aggregate everything all the\ntime because it can be done after the fact noninteractively. In that case\nit makes sense to have a special aggregated signature which always comes\nwith a transaction or block. But it might be a bit much to bundle both lisp\nand BLS support into one big glop.\n\n\n\n\u003e\n\u003e For example you might have multiple HTLCs, with mostly the same code\n\u003e except for details like who the acceptor and offerrer are, exact hash, and\n\u003e timelock, and you could claim multiple HTLCs in a single tx and feed the\n\u003e details separately but the code for the HTLC is common to all of the HTLCs.\n\u003e You do not even need to come from the same protocol if multiple protocols\n\u003e use the same code for implementing HTLC.\n\u003e\n\nHTLCs, at least in Chia, have embarrassingly little code in them. Like, so\nlittle that there's almost nothing to compress.\n\n\n\u003e This does not apply to current Bitcoin since we no longer accept a SCRIPT\n\u003e from the spender, we now have a witness stack.\n\u003e\n\nMy mental model of Bitcoin is to pretend that segwit was always there and\nthe separation of different sections of data is a semantic quibble.\n\n\n\u003e So this seems to be more like \"do not write broken SCRIPTs\"?\n\u003e\n\nIn general if people footgun that's their own fault. The resistance to\ncovenants and capabilities in the past has largely been around what would\nhappen if you had opt-out covenants which acted as riders and could monkey\naround in later spends which were none of their business. But if they're\nfully baked into the scriptpubkey then they're opted into by the recipient\nand there aren't any weird surprises.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220308/5137151d/attachment-0001.html\u003e",
"sig": "5520233cb50cb00d85b73cafb65b545b5c9fba70c5405135f753e62d8007d2f6727f1da1b8c7627976165335d5829020861443c89c6a7c9431caadde8d62468e"
}