Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2014-10-05 📝 Original message:On Sun, Oct 5, 2014 at ...
📅 Original date posted:2014-10-05
📝 Original message:On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell <gmaxwell at gmail.com>
> I should point you to some of the tools that have been discussed in
> the past which are potentially helpful here:
Ah, I should also mention a somewhat more far out approach which helps
here as a side effect:
If transactions were using the BLS short signature scheme (a very
compact EC signature based on pairing cryptography) there is a scheme
so that you securely can aggregate the signatures from multiple
messages into a single signature (also has nice bandwidth properties)
and still verify it. It also works recursively, so aggregates can be
further aggregated.
A consequence of this is that you cannot remove a (set of)
signature(s) from the aggregate without knowing the (set of)
signature(s) by itself.
If the coinbase transaction also contains a signature and if some
non-trivial portion of fee paying users relayed their transaction
privately to miners it, then other miners would only learn of the
transaction in aggregated form. Without knowing the transaction by
itself they could not pull it out of a block separately from the
coinbase payment and add it to their own block in a fork.
(In general this provides several anti-censorship properties, since if
someone passed you an aggregate of several transactions you could only
accept or reject them as a group unless you knew the members
separately).
The use in aggregation can be done in a way which is purely additive
(e.g. in addition to regular DSA signatures), so even if the
cryptosystem is broken the only harm would be allowing
disaggregation... but unfortunately the pairing crypto is pretty slow
(verification takes a 0.5ms-ish pairing operation per transaction).
Published at
2023-06-07 15:26:16Event JSON
{
"id": "8ff910e8556c6332f915b517ae4b96a0d16c9d5f972d275286c20c6c1a72d8f8",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151576,
"kind": 1,
"tags": [
[
"e",
"590f9f3d77c6f5062e55d15ba45a9b74b0defc52c9a34a6bbe0fbacdb4f439c6",
"",
"root"
],
[
"e",
"d46e9d2b01d599d93a6c553b7182ad9249274968ea49d26ddc67a50aefdb06ea",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-10-05\n📝 Original message:On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e\n\u003e I should point you to some of the tools that have been discussed in\n\u003e the past which are potentially helpful here:\n\nAh, I should also mention a somewhat more far out approach which helps\nhere as a side effect:\n\nIf transactions were using the BLS short signature scheme (a very\ncompact EC signature based on pairing cryptography) there is a scheme\nso that you securely can aggregate the signatures from multiple\nmessages into a single signature (also has nice bandwidth properties)\nand still verify it. It also works recursively, so aggregates can be\nfurther aggregated.\n\nA consequence of this is that you cannot remove a (set of)\nsignature(s) from the aggregate without knowing the (set of)\nsignature(s) by itself.\n\nIf the coinbase transaction also contains a signature and if some\nnon-trivial portion of fee paying users relayed their transaction\nprivately to miners it, then other miners would only learn of the\ntransaction in aggregated form. Without knowing the transaction by\nitself they could not pull it out of a block separately from the\ncoinbase payment and add it to their own block in a fork.\n\n(In general this provides several anti-censorship properties, since if\nsomeone passed you an aggregate of several transactions you could only\naccept or reject them as a group unless you knew the members\nseparately).\n\nThe use in aggregation can be done in a way which is purely additive\n(e.g. in addition to regular DSA signatures), so even if the\ncryptosystem is broken the only harm would be allowing\ndisaggregation... but unfortunately the pairing crypto is pretty slow\n(verification takes a 0.5ms-ish pairing operation per transaction).",
"sig": "f72e1c360a20dead4e25871a57cfbc50ff1d320e712f358b26c0600f0cd7b45dcbc7767720f6043618e935330b960a64ce89891b00a4e5e1b449b71448736587"
}