Derek Atkins [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-31 📝 Original message: Hi Rusty, On Mon, ...
📅 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.
📝 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.