From jason.chavannes at gmail.com Tue Apr 3 15:50:09 2018 From: jason.chavannes at gmail.com (Jason Chavannes) Date: Tue, 3 Apr 2018 08:50:09 -0700 Subject: [Bitcoin-ml] BIP-133 should be removed from BCH Message-ID: FYI, I just published this post about why BIP-133 should be removed from BCH. https://jasonc.me/blog/bitcoin-bip-133-double-spends-bch The fee filter can be exploited to hide double spend transactions, compromising the security of 0-conf. Without a fee filter, however, there could be some concerns about spam attacks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.posen at gmail.com Tue Apr 3 17:55:24 2018 From: jim.posen at gmail.com (Jim Posen) Date: Tue, 3 Apr 2018 10:55:24 -0700 Subject: [Bitcoin-ml] Optimized Header Sync Message-ID: Cross post from bitcoin-dev. Based on some ideas that were thrown around in this thread (https://lists. linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015385.html), I have been working on a P2P extension that will allow faster header sync mechanisms. The one-sentence summary is that by encoding headers more efficiently (eg. omitting prev_hash) and downloading evenly spaced checkpoints throughout history (say every 1,000th) from all peers first, we could speed up header sync, which would be a huge improvement for light clients. Here is a draft of the BIP: https://github.com/jimpo/ bips/blob/headers-sync/headersv2.mediawiki. I'd love to hear any feedback people have. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grarpamp at gmail.com Fri Apr 6 10:04:34 2018 From: grarpamp at gmail.com (grarpamp) Date: Fri, 6 Apr 2018 06:04:34 -0400 Subject: [Bitcoin-ml] Strong Privacy / Survivability [ref: ZKP, was: Proof of Work] Message-ID: On Thu, Apr 5, 2018 at 7:26 AM, Natanael wrote via cryptography at metzdowd: > Zero-knowledge proofs (and other topics) Bitcoin BTC and subsequent coins, all of them until no more than ~2 years ago, rolled out with massive downgrade to how fiat cash / banking work... in that entire blockhain transaction history both exists, and is visible to all. Without so much as consent or notice or pemission by anyone or anything, anyone can divine and rummage significant of your history at will forever. Horrible downgrade. Yet such existance and visibility are not requirements to a functional currency. Only that UTXO set [1] are considered by the system to be valid, thus acceptable and trusted as future inputs. Not required are the privacy destroying, colorable arbitrary fungibility breaking, forever datamined, unneeded disk bloating, etc nature of this major feature downgrade to existing p2p / proxied fiat. Back then perhaps true ZK crypto privacy or any other cryptographically strong privacy method was unknown / unimplemented. You may think of more methods. However system software network design validating and keeping only the UTXOs was more than likely possible. Of course to keep rogues software from datamining... strong crypto way is still needed. And having that, then all participants will discard all spent records as inefficient, forever unvisable, dead weight. You must think up such designs. Today strong privacy is generally thought at least possible, and has two different approaches implemented and deployed in active networks competing live in the marketplace today. You must review methods and approaches in the research, and further consider of how to move beyond entry level scale and even tx types there. Generally in coins... is up to users to choose use enable or disable privacy capable coins by default, per-tx, or other basis. And to you to awaken, where others may fail, why such coins exist. Cypherpunk philosophy cannot survive in any coin that is non private or readily blockable... only when encoded in coins that are only / selectably private, running as / in fully encrypted and resistant networks, with DEXs, mining, etc all as part. Which means that non private cryptocurrencies will not survive any different than fiat central in long term. You may think of many reasons why. Survivability is from and of many things... including elements of such philosophy. Much can and must be improved and implemented there. [1] Basic ledger transfers, yet even as possible to multisig, operations, contracts, etc. From jim.posen at gmail.com Fri Apr 6 21:38:29 2018 From: jim.posen at gmail.com (Jim Posen) Date: Fri, 6 Apr 2018 14:38:29 -0700 Subject: [Bitcoin-ml] BLS Signatures Message-ID: I want to raise the idea of adding support for BLS signatures to the scripting language. The idea has been around for a while in the Bitcoin community, and I'm interested to see how people feel about the tradeoffs. For those not familiar, BLS signatures [1] were invented in 2004 by Dan Boneh, Ben Lynn, and Hovav Shacham and have a number of very nice properties. I'm probably not going to do them full justice, but they 1) are smaller than ECDSA signatures (48 bytes vs ~70-72 bytes DER-encoded for equivalent security targets) 2) are provably non-malleable 3) support non-interactive signature aggregation and 4) support unique threshold signatures. Point 3 is the most important, so I'll elaborate. Say there are N parties with different public keys providing signatures over different messages (the messages must be different though). So they each provide (Message_i, PubKey_i, and Sig_i), where the signatures are produced with their respective private keys. Anyone can then take all of the signatures and add them together to get a single, constant sized signature covering all pairs (Message_i, PubKey_i) simultaneously. What this means for Bitcoin is that all signatures in all inputs in all transactions in a block could be merged by the miner into a single 48 byte signature covering the entire block. This would allow for massive potential savings in block space. Another very interesting property of signature aggregation is that is allows for unlinking of inputs and outputs in a transaction through a construction called one-way aggregate signatures (OWAS) [2]. With some different sighash types, one could create secure transactions that can be merged by a third party into an aggregate transaction that obfuscates the linkability between inputs and outputs. Essentially, this is non-interactive CoinJoin. These signatures work using pairing-based cryptography [3], which is where the tradeoffs come in. Firstly, BLS signatures are defined over pairing-friendly elliptic curves, which Bitcoin's standard curve secp256k1 is not one of. So first, a different elliptic curve would have to be chosen and the best candidate I've heard of from research by the ZCash team is BLS12-381 [4], which has larger public keys. Secondly, signature verification is definitely slower than with secp256k1. On my machine the secp256k1 verification benchmarks show ~75 us per ECDSA verification with libsecp256k1 and ~7 ms per pairing operation with https://github.com/ebfull/pairing. Third, the signatures depend on stronger cryptographic assumptions than ECDSA (weaker assumptions in cryptography are preferred). That said, the additional assumptions have held up for decades at this point. What is the state of BLS usage in cryptocurrency today? Chia, the proof-of-space-time blockchain project by Bram Cohen, is planning to use BLS signatures in the scripting language and propose a BIP [5]. Dfinity is another project that is using BLS as a core part of their consensus algorithm, though I'm not sure about it's usage at the VM layer. Both of these teams are working on performance optimizations for BLS implementations [6]. In terms of deployment, this would require significant research into curve selection, performance, etc. Aside from that, I imagine the scope of changes outside the script interpreter is fairly limited. It'd probably be worth adding a new field to unconfirmed transaction and block structures. For a better primer on BLS signatures, see Benedikt Bunz's talk from Scaling Bitcoin 2017 [7]. Also for some newer research on public key aggregation (further space savings) see [8]. So... what do people think? [1] https://en.wikipedia.org/wiki/Boneh%E2%80%93Lynn%E2%80%93Shacham [2] https://download.wpsoftware.net/bitcoin/wizardry/horasyuanmouton-owas.pdf [3] https://en.wikipedia.org/wiki/Pairing-based_cryptography [4] https://blog.z.cash/new-snark-curve/ [5] https://twitter.com/bramcohen/status/972208962278797312 [6] https://dfinity.org/tech [7] https://www.youtube.com/watch?v=LDF8bOEqXt4&t=3h1m54s [8] https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonaldfyookball at outlook.com Fri Apr 6 23:12:36 2018 From: jonaldfyookball at outlook.com (Jonald Fyookball) Date: Fri, 6 Apr 2018 23:12:36 +0000 Subject: [Bitcoin-ml] BLS Signatures In-Reply-To: References: Message-ID: Ladies and gentlemen, these may finally be the droids we've been looking for, as far as a fungibility solution for Bitcoin Cash. I cannot overstate my enthusiasm for the One Way Aggregate Signatures (OWAS)! To grasp why this is so significant, one has to understand the current limitations that we're saddled with, and their consequences. Thus far, all joining protocols in Bitcoin (both BTC and BCH), including CashShuffle, have a hard time gaining momentum primarily because of a lack of network effect. Finding join partners is difficult when participation is low and requires coordination. Even as a protocol like CashShuffle gains usage, it will increasingly face DOS attacks. Those DOS attacks can be somewhat mitigated by blame protocols, but a motivated attacker could still cause significant disruption, which might provoke messy defensive measures (perhaps security deposits), or simply cause joined transactions to be unreliable or annoying to use. These things discourage widespread use and slow down adoption. Yet, widespread use of joined transactions is exactly what is required to create a high level of fungibility. When nearly everyone's transactions are jumbled, the concept of "taint" essentially becomes meaningless. The "non-interactive" property offered by OWAS is a game-changer. Traditional coinjoins use the ALL|ANYONECANPAY SIGHASH type, so that a user can sign for their input and all of the outputs. The key problem is that everyone involved in the transaction has to sign separately, and if any participant fails to sign, the transaction is invalid and must be constructed again with a different set of participants. The other SIGHASH types aren't helpful. NONE|ANYONECANPAY isn't useful since funds could be stolen (Alice would have no way to guarantee her output would be included), and SINGLE|ANYONECANPAY can't be used since the input would be linked to the output. Alternative implementations of traditional join schemes can be envisioned, but they all seem to run into the same basic constraints. For instance, what if instead of publishing inputs and then coordinating to attach outputs (as is done in CashShuffle), users publish outputs first and then sign various transaction sets with their inputs? This would allow for less coordination, but creates an even worse DOS attack vector, as an arbitrary number of fake outputs could be created without cost. The DREAM SCENARIO is that a user could create a single input, single output transaction, which we can think of as a "slice" of a soon-to-be larger transaction, and another party could combine this slice with other slices, all without the user having to re-sign the transaction after creating their slice. That seems to be impossible given the current set of SIGHASH types, because you have to sign for your own input separately along with all the outputs, and you don't know the other outputs without coordinating with the other participants. Even if we had some "cryptomagic" that could re-sign transactions on behalf of multiple users (which we don't have), we would still have to trust the mixing agent to protect anonymity, which is not only non-ideal, but precludes a distributed solution. Going a step farther, even if this mixing agent didn't know what it was signing (for example using blinded signatures), it would still need to be trusted with the anonymity because it could try various combinations and see what the finished transaction looks like after its published on a blockchain. Also, a blinded scheme would likely require creating a shared secret as a prerequisite step, introducing more coordination steps and friction. However, our desired "dream scenario" DOES seem to be achievable using OWAS if we're willing to slightly modify the protocol to allow a bit more flexibility in the transaction types. I'm not sure how invasive the changes need to be, but in order to get a true fungibility solution, it will probably be worth it. OWAS, within the context of a flexible transaction scheme, can meet our goals because the message digests being signed for can be combined in a multiplicative way, and therefore the inputs and outputs can appear in any order. It should also be noted that we cannot overestimate the negative impact of friction in the user experience (which OWAS would remove). All we have to do is look at the BTC community for proof. In the Bitcointalk thread where I believe the OWAS paper was first announced: https://bitcointalk.org/index.php?topic=290971.0 The only comments were from Socrates1024 and Greg Maxwell. Maxwell clearly understands the main benefit when he states "The OWAS removes the need for any bidirectional interaction or cooperation of the signing parties. A clear improvement for privacy". Yet he also dismisses it, saying "I believe a cryptographic approach is unnecessary". Given the almost zero progress the BTC community has made in actually achieving commonplace (let alone widespread) joined transactions, we can see that this belief was mistaken, at least if fungibility was the goal. But their loss can be our gain. Languishing, mostly unnoticed, these ideas come to our community awareness at a perfect time. It is an opportunity ripe for the picking. Finally, I think allowing users the unhindered ability to (optionally) join their transactions provides the perfect level of privacy and fungibility for Bitcoin Cash. If we go "too dark" like XMR, there will be greater hostility from governments and other entities under state and social pressure. Strategically, if our goal is worldwide adoption, that's an important consideration. In a world where joined transactions are commonplace, there is still a public ledger that can allow the flow of funds to be observed. There is still the ability to show the origin of funds. There is still the plausible deniability that is already present today (but to a slightly larger degree). One could even make the argument that illicit transactions are better able to be investigated, because criminals wouldn't go out of their way as often to using extra-ordinary means. And most importantly, fungibility is protected because taint is washed across the entire system, while those who desire even greater privacy always have additional options. ________________________________ From: bitcoin-ml-bounces at lists.linuxfoundation.org on behalf of Jim Posen via bitcoin-ml Sent: Friday, April 6, 2018 5:38 PM To: Bitcoin and related protocol coordination Subject: [Bitcoin-ml] BLS Signatures I want to raise the idea of adding support for BLS signatures to the scripting language. The idea has been around for a while in the Bitcoin community, and I'm interested to see how people feel about the tradeoffs. For those not familiar, BLS signatures [1] were invented in 2004 by Dan Boneh, Ben Lynn, and Hovav Shacham and have a number of very nice properties. I'm probably not going to do them full justice, but they 1) are smaller than ECDSA signatures (48 bytes vs ~70-72 bytes DER-encoded for equivalent security targets) 2) are provably non-malleable 3) support non-interactive signature aggregation and 4) support unique threshold signatures. Point 3 is the most important, so I'll elaborate. Say there are N parties with different public keys providing signatures over different messages (the messages must be different though). So they each provide (Message_i, PubKey_i, and Sig_i), where the signatures are produced with their respective private keys. Anyone can then take all of the signatures and add them together to get a single, constant sized signature covering all pairs (Message_i, PubKey_i) simultaneously. What this means for Bitcoin is that all signatures in all inputs in all transactions in a block could be merged by the miner into a single 48 byte signature covering the entire block. This would allow for massive potential savings in block space. Another very interesting property of signature aggregation is that is allows for unlinking of inputs and outputs in a transaction through a construction called one-way aggregate signatures (OWAS) [2]. With some different sighash types, one could create secure transactions that can be merged by a third party into an aggregate transaction that obfuscates the linkability between inputs and outputs. Essentially, this is non-interactive CoinJoin. These signatures work using pairing-based cryptography [3], which is where the tradeoffs come in. Firstly, BLS signatures are defined over pairing-friendly elliptic curves, which Bitcoin's standard curve secp256k1 is not one of. So first, a different elliptic curve would have to be chosen and the best candidate I've heard of from research by the ZCash team is BLS12-381 [4], which has larger public keys. Secondly, signature verification is definitely slower than with secp256k1. On my machine the secp256k1 verification benchmarks show ~75 us per ECDSA verification with libsecp256k1 and ~7 ms per pairing operation with https://github.com/ebfull/pairing. Third, the signatures depend on stronger cryptographic assumptions than ECDSA (weaker assumptions in cryptography are preferred). That said, the additional assumptions have held up for decades at this point. What is the state of BLS usage in cryptocurrency today? Chia, the proof-of-space-time blockchain project by Bram Cohen, is planning to use BLS signatures in the scripting language and propose a BIP [5]. Dfinity is another project that is using BLS as a core part of their consensus algorithm, though I'm not sure about it's usage at the VM layer. Both of these teams are working on performance optimizations for BLS implementations [6]. In terms of deployment, this would require significant research into curve selection, performance, etc. Aside from that, I imagine the scope of changes outside the script interpreter is fairly limited. It'd probably be worth adding a new field to unconfirmed transaction and block structures. For a better primer on BLS signatures, see Benedikt Bunz's talk from Scaling Bitcoin 2017 [7]. Also for some newer research on public key aggregation (further space savings) see [8]. So... what do people think? [1] https://en.wikipedia.org/wiki/Boneh%E2%80%93Lynn%E2%80%93Shacham [2] https://download.wpsoftware.net/bitcoin/wizardry/horasyuanmouton-owas.pdf [3] https://en.wikipedia.org/wiki/Pairing-based_cryptography [4] https://blog.z.cash/new-snark-curve/ [5] https://twitter.com/bramcohen/status/972208962278797312 [6] https://dfinity.org/tech [7] https://www.youtube.com/watch?v=LDF8bOEqXt4&t=3h1m54s [8] https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From grarpamp at gmail.com Sat Apr 7 05:29:22 2018 From: grarpamp at gmail.com (grarpamp) Date: Sat, 7 Apr 2018 01:29:22 -0400 Subject: [Bitcoin-ml] BLS Signatures In-Reply-To: References: Message-ID: On Fri, Apr 6, 2018 at 5:38 PM, Jim Posen via bitcoin-ml wrote: > Bitcoin's standard curve secp256k1 > a different elliptic curve would have to be chosen... ZCash... BLS12-381 [4] > Chia... Dfinity... BLS > In terms of deployment, this would require significant research into curve > selection, performance, etc. One reference on such research criteria to include is: http://safecurves.cr.yp.to/ > [4] https://blog.z.cash/new-snark-curve/ From tomas at bitcrust.org Mon Apr 9 13:56:37 2018 From: tomas at bitcrust.org (Tomas) Date: Mon, 09 Apr 2018 15:56:37 +0200 Subject: [Bitcoin-ml] BLS Signatures In-Reply-To: References: Message-ID: <1523282197.3375731.1331553264.30645D27@webmail.messagingengine.com> I agree this is a very promising path. It also seems such scheme would make interactive aggregation (Schnorr) irrelevant and would make transactions non-malleable. On Fri, Apr 6, 2018, at 23:38, Jim Posen via bitcoin-ml wrote: > > Secondly, signature verification is definitely slower than with > secp256k1. On my machine the secp256k1 verification benchmarks show > ~75 us per ECDSA verification with libsecp256k1 and ~7 ms per pairing > operation with https://github.com/ebfull/pairing. It's interesting to note that the primitive operations in the rust pairing library are also benching much slower than libsecp256k1 for the field of similar size (Fr), which indicates a lot of optimizations may be possible. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomh at thinlink.com Mon Apr 9 15:15:44 2018 From: tomh at thinlink.com (Tom Harding) Date: Mon, 9 Apr 2018 08:15:44 -0700 Subject: [Bitcoin-ml] BIP-133 should be removed from BCH In-Reply-To: References: Message-ID: <4b43c4ef-f090-bb62-b91b-6e4b12267a3f@thinlink.com> Your description of the danger of relying on 0-conf transactions that are subject to unreliable relay, especially when the pattern is predictable, is as clear as any I've seen. That said, removing the bip133 feefilter message support from Bitcoin Cash clients that support it would not lessen the danger.? The reason is that bip133 is just an optimization that attempts to keep other nodes informed of your fee limit -- it does not create the limit. It has always been possible to set your relay fee limit locally and, since 2015, limited mempool size can also create an effective fee limit, though right now the latter does not often come into play on the Bitcoin Cash network. Recently there has been increased attention on ways to improve 0-conf reliability which is really great. It's encouraging there is near universal agreement that it is worth improving and can be improved. On 4/3/2018 8:50 AM, Jason Chavannes via bitcoin-ml wrote: > FYI, I just published this post about why BIP-133 should be removed > from BCH. > > https://jasonc.me/blog/bitcoin-bip-133-double-spends-bch > > The fee filter can be exploited to hide double spend transactions, > compromising the security of 0-conf. > > Without a fee filter, however, there could be some concerns about spam > attacks. > From julian.smith at blockfreight.com Tue Apr 17 04:29:29 2018 From: julian.smith at blockfreight.com (Julian Smith) Date: Tue, 17 Apr 2018 14:29:29 +1000 Subject: [Bitcoin-ml] BLS Signatures In-Reply-To: <1523282197.3375731.1331553264.30645D27@webmail.messagingengine.com> References: <1523282197.3375731.1331553264.30645D27@webmail.messagingengine.com> Message-ID: At a high-level: Q. What is the likely timeline over which to select a BLS curve / implement? (30 days / 6 months / 1.5 years+) On Mon, Apr 9, 2018 at 11:56 PM, Tomas via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> wrote: > I agree this is a very promising path. It also seems such scheme would > make interactive aggregation (Schnorr) irrelevant and would make > transactions non-malleable. > > On Fri, Apr 6, 2018, at 23:38, Jim Posen via bitcoin-ml wrote: > > > Secondly, signature verification is definitely slower than with secp256k1. > On my machine the secp256k1 verification benchmarks show ~75 us per ECDSA > verification with libsecp256k1 and ~7 ms per pairing operation with > https://github.com/ebfull/pairing. > > > It's interesting to note that the primitive operations in the rust pairing > library are also benching much slower than libsecp256k1 for the field of > similar size (Fr), which indicates a lot of optimizations may be possible. > > Tomas > > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deadalnix at gmail.com Tue Apr 17 22:39:02 2018 From: deadalnix at gmail.com (=?UTF-8?Q?Amaury_S=C3=A9chet?=) Date: Tue, 17 Apr 2018 22:39:02 +0000 Subject: [Bitcoin-ml] BLS Signatures In-Reply-To: References: <1523282197.3375731.1331553264.30645D27@webmail.messagingengine.com> Message-ID: With the current talent pool, the timeline is never. Le mar. 17 avr. 2018 ? 06:29, Julian Smith via bitcoin-ml < bitcoin-ml at lists.linuxfoundation.org> a ?crit : > At a high-level: Q. What is the likely timeline over which to select a BLS > curve / implement? (30 days / 6 months / 1.5 years+) > > On Mon, Apr 9, 2018 at 11:56 PM, Tomas via bitcoin-ml < > bitcoin-ml at lists.linuxfoundation.org> wrote: > >> I agree this is a very promising path. It also seems such scheme would >> make interactive aggregation (Schnorr) irrelevant and would make >> transactions non-malleable. >> >> On Fri, Apr 6, 2018, at 23:38, Jim Posen via bitcoin-ml wrote: >> >> >> Secondly, signature verification is definitely slower than with >> secp256k1. On my machine the secp256k1 verification benchmarks show ~75 us >> per ECDSA verification with libsecp256k1 and ~7 ms per pairing operation >> with https://github.com/ebfull/pairing. >> >> >> It's interesting to note that the primitive operations in the rust >> pairing library are also benching much slower than libsecp256k1 for the >> field of similar size (Fr), which indicates a lot of optimizations may be >> possible. >> >> Tomas >> >> _______________________________________________ >> bitcoin-ml mailing list >> bitcoin-ml at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml >> >> > _______________________________________________ > bitcoin-ml mailing list > bitcoin-ml at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonaldfyookball at outlook.com Tue Apr 17 23:40:55 2018 From: jonaldfyookball at outlook.com (Jonald Fyookball) Date: Tue, 17 Apr 2018 23:40:55 +0000 Subject: [Bitcoin-ml] BLS Signatures In-Reply-To: References: <1523282197.3375731.1331553264.30645D27@webmail.messagingengine.com> , Message-ID: Cryptographers can be hired if necessary, but the community would have to decide that this is the direction to go in, as it would be a serious project. BLS is only a means to an end: I am hearing hints from certain people that non interactive joins are possible without a protocol change, but so far I have seen not seen any proposal. Amaury, do think it is possible to achieve a non interactive join without a protocol change? ________________________________ From: bitcoin-ml-bounces at lists.linuxfoundation.org on behalf of Amaury S?chet via bitcoin-ml Sent: Tuesday, April 17, 2018 6:39 PM To: Julian Smith; Bitcoin and related network protocol discussion Subject: Re: [Bitcoin-ml] BLS Signatures With the current talent pool, the timeline is never. Le mar. 17 avr. 2018 ? 06:29, Julian Smith via bitcoin-ml > a ?crit : At a high-level: Q. What is the likely timeline over which to select a BLS curve / implement? (30 days / 6 months / 1.5 years+) On Mon, Apr 9, 2018 at 11:56 PM, Tomas via bitcoin-ml > wrote: I agree this is a very promising path. It also seems such scheme would make interactive aggregation (Schnorr) irrelevant and would make transactions non-malleable. On Fri, Apr 6, 2018, at 23:38, Jim Posen via bitcoin-ml wrote: Secondly, signature verification is definitely slower than with secp256k1. On my machine the secp256k1 verification benchmarks show ~75 us per ECDSA verification with libsecp256k1 and ~7 ms per pairing operation with https://github.com/ebfull/pairing. It's interesting to note that the primitive operations in the rust pairing library are also benching much slower than libsecp256k1 for the field of similar size (Fr), which indicates a lot of optimizations may be possible. Tomas _______________________________________________ bitcoin-ml mailing list bitcoin-ml at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml _______________________________________________ bitcoin-ml mailing list bitcoin-ml at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-ml -------------- next part -------------- An HTML attachment was scrubbed... URL: