📅 Original date posted:2015-08-31
📝 Original message:
Hi Rusty,
On Mon, 2015-08-31 at 12:24 +0930, Rusty Russell wrote:
> Jeremy Rubin <jr at mit.edu> writes:
> > Negotiating & Committing Signatures
> > ============================
> >
> > In this proposal, I suggest the addition of new types of signature schemes
> > to Bitcoin, and running lightning over multi signature of the
> > variants to utilize the advantages of multiple signature schemes without
> > the drawbacks.
>
> Hi Jeremy,
>
> Such a hybrid would certainly be possible (though getting novel
> crypto into bitcoin is a large task).
>
> You refer to an "order or magnitude" increase in pubkey and signature
> sizes, but signatures of even 64k wouldn't make much logistical
> difference to the LN.
The AEDSA signatures are around 6000 bits, give or take. Due to the way
the algorithm works the signatures are not constant length (they have a
length distribution). As a result we tend to talk about "average
length" of signatures.
> Giant pubkeys might be a logistical issue, though
> using the bitcoin trick of referring to them via their RIPEMD160 should
> work there, too.
The AEDSA public keys are 344 bits long and are constant length. I'm
not sure if it's worth the time to perform a RIPEMD160 over 344 bits to
save 50%? But only you could answer that.
Yet even with these sizes we're seeing a tremendous verification
performance increase over ECDSA (on the order of 100-300x improvement)
with a smaller code footprint and reduced RAM usage, even on tiny, 8-bit
platforms like an 8051 or 16-bit platforms like an MSP430.
>
> Cheers,
> Rusty.
-derek
--
Derek Atkins
Chief Technology Officer
SecureRF Corporation
Office: 203.227.3151 x1343
Direct: 617.623.3745
Mobile: 617.290.5355
Email: DAtkins at SecureRF.com
This email message may contain confidential, proprietary and / or
legally privileged information and intended only for the use of the
intended recipient(s) and others specifically authorized. Any
disclosure, dissemination, copying, distribution or use of the
information contained in this email message, including any attachments,
to or by anyone other than the intended recipient is strictly
prohibited. If you received this in error, please immediately advise
the sender by reply email or at the telephone number above, and then
delete, shred, or otherwise dispose of this message.
Derek Atkins [ARCHIVE] /
npub1kp…pjsvk
2023-06-09 12:44:17
in reply to nevent1q…uzmh
Author Public Key
npub1kp9enqm06w6glydxuu7320zxjlxjdr2qe2w28qaexyzv2ff3qsnsvpjsvkSeen on
wss://relay.nostr.bandPublished at
2023-06-09 12:44:17Event JSON
{
"id": "988f1dedd3c9062dc318ee401f0100cd80094226915bd5cd3a5de1827032d05a",
"pubkey": "b04b99836fd3b48f91a6e73d153c4697cd268d40ca9ca383b93104c525310427",
"created_at": 1686314657,
"kind": 1,
"tags": [
[
"e",
"570e85b34e84913ab246c8ab51f051929625897255315460fe706bb5c6c8006e",
"",
"root"
],
[
"e",
"7daf6fa43894703e2a32d744af0836cd24af5102642aaf0fddb8a034a9f121de",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-08-31\n📝 Original message:\nHi Rusty,\n\nOn Mon, 2015-08-31 at 12:24 +0930, Rusty Russell wrote:\n\u003e Jeremy Rubin \u003cjr at mit.edu\u003e writes:\n\u003e \u003e Negotiating \u0026 Committing Signatures\n\u003e \u003e ============================\n\u003e \u003e\n\u003e \u003e In this proposal, I suggest the addition of new types of signature schemes\n\u003e \u003e to Bitcoin, and running lightning over multi signature of the\n\u003e \u003e variants to utilize the advantages of multiple signature schemes without\n\u003e \u003e the drawbacks.\n\u003e \n\u003e Hi Jeremy,\n\u003e \n\u003e Such a hybrid would certainly be possible (though getting novel\n\u003e crypto into bitcoin is a large task).\n\u003e \n\u003e You refer to an \"order or magnitude\" increase in pubkey and signature\n\u003e sizes, but signatures of even 64k wouldn't make much logistical\n\u003e difference to the LN. \n\nThe AEDSA signatures are around 6000 bits, give or take. Due to the way\nthe algorithm works the signatures are not constant length (they have a\nlength distribution). As a result we tend to talk about \"average\nlength\" of signatures.\n\n\u003e Giant pubkeys might be a logistical issue, though\n\u003e using the bitcoin trick of referring to them via their RIPEMD160 should\n\u003e work there, too.\n\nThe AEDSA public keys are 344 bits long and are constant length. I'm\nnot sure if it's worth the time to perform a RIPEMD160 over 344 bits to\nsave 50%? But only you could answer that.\n\nYet even with these sizes we're seeing a tremendous verification\nperformance increase over ECDSA (on the order of 100-300x improvement)\nwith a smaller code footprint and reduced RAM usage, even on tiny, 8-bit\nplatforms like an 8051 or 16-bit platforms like an MSP430.\n\n\u003e \n\u003e Cheers,\n\u003e Rusty.\n\n-derek\n\n-- \nDerek Atkins\nChief Technology Officer\nSecureRF Corporation\n\nOffice: 203.227.3151 x1343\nDirect: 617.623.3745\nMobile: 617.290.5355\nEmail: DAtkins at SecureRF.com\n\nThis email message may contain confidential, proprietary and / or\nlegally privileged information and intended only for the use of the\nintended recipient(s) and others specifically authorized. Any\ndisclosure, dissemination, copying, distribution or use of the\ninformation contained in this email message, including any attachments,\nto or by anyone other than the intended recipient is strictly\nprohibited. If you received this in error, please immediately advise\nthe sender by reply email or at the telephone number above, and then\ndelete, shred, or otherwise dispose of this message.",
"sig": "5b6eee2ec46327c1796734ba3492a44a322832a2d5fe7ddbecc0be63100a6bed864a5b66c40cc23d614b09da042fe96b0e5cacba15c4535358a965b502be56b2"
}