81 lines
3.2 KiB
HTML
81 lines
3.2 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE> [BLS-wg] Reverse BLS12-381
|
|
</TITLE>
|
|
<LINK REL="Index" HREF="/pipermail/bls-wg/2018/index.html" >
|
|
<LINK REL="made" HREF="mailto:bls-wg%40lists.zfnd.org?Subject=Re%3A%20%5BBLS-wg%5D%20Reverse%20BLS12-381&In-Reply-To=%3CCAHUJnBCmdXUONAbQ6U5f19x3iZG%2B59n0nSwYrDq33ZEKu0D_Rg%40mail.gmail.com%3E">
|
|
<META NAME="robots" CONTENT="index,nofollow">
|
|
<style type="text/css">
|
|
pre {
|
|
white-space: pre-wrap; /* css-2.1, curent FF, Opera, Safari */
|
|
}
|
|
</style>
|
|
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
|
|
|
<LINK REL="Next" HREF="000001.html">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#ffffff">
|
|
<H1>[BLS-wg] Reverse BLS12-381</H1>
|
|
<B>Bram Cohen</B>
|
|
<A HREF="mailto:bls-wg%40lists.zfnd.org?Subject=Re%3A%20%5BBLS-wg%5D%20Reverse%20BLS12-381&In-Reply-To=%3CCAHUJnBCmdXUONAbQ6U5f19x3iZG%2B59n0nSwYrDq33ZEKu0D_Rg%40mail.gmail.com%3E"
|
|
TITLE="[BLS-wg] Reverse BLS12-381">bram at chia.net
|
|
</A><BR>
|
|
<I>Fri Mar 16 18:41:59 EDT 2018</I>
|
|
<P><UL>
|
|
|
|
<LI>Next message (by thread): <A HREF="000001.html">[BLS-wg] Reverse BLS12-381
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#0">[ date ]</a>
|
|
<a href="thread.html#0">[ thread ]</a>
|
|
<a href="subject.html#0">[ subject ]</a>
|
|
<a href="author.html#0">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
<HR>
|
|
<!--beginarticle-->
|
|
<PRE>Hey everybody. We at Chia are working on a new cryptocurrency and are
|
|
planning on making BLS be the standard way all signatures are done in it
|
|
because we like the noninteractive aggregation and unique signatures
|
|
features.
|
|
|
|
To that end, we're implementing them using the Relic library based on
|
|
BLS12-381. Er, sort of. It turns out that BLS12-381 as defined has 96 byte
|
|
public keys and 48 byte signatures, on the theory that usually public keys
|
|
are published once and then used to sign many things. In cryptocurrencies
|
|
it's the opposite, where public keys are published once and used to sign a
|
|
fraction of one thing because signatures are aggregated. To that end we're
|
|
swapping the curves around, so the public keys are 48 bytes and the
|
|
signatures are 96 bytes.
|
|
|
|
Our implementation is meant to be mostly api compatible with Bitcoin's
|
|
Key.cpp except that we don't support non-compact signatures and don't have
|
|
salt. Features we have or are working on include basic verification,
|
|
aggregation, compact multisig, and SecureAllocator support, and maybe some
|
|
more things I don't remember off the top of my head. Eventually we plan to
|
|
swap out Relic for something constant time.
|
|
|
|
-Bram
|
|
</PRE>
|
|
|
|
<!--endarticle-->
|
|
<HR>
|
|
<P><UL>
|
|
<!--threads-->
|
|
|
|
<LI>Next message (by thread): <A HREF="000001.html">[BLS-wg] Reverse BLS12-381
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#0">[ date ]</a>
|
|
<a href="thread.html#0">[ thread ]</a>
|
|
<a href="subject.html#0">[ subject ]</a>
|
|
<a href="author.html#0">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
|
|
<hr>
|
|
<a href="/mailman/listinfo/bls-wg">More information about the bls-wg
|
|
mailing list</a><br>
|
|
</body></html>
|