Secp256k1 · bitcoin-s

Help to get Bitcoin Elliptic Curve `secp256k1` added to Apple's newly open-sourced Swift-Crypto lib, to make iOS wallets safer and better.

Help to get Bitcoin Elliptic Curve `secp256k1` added to Apple's newly open-sourced Swift-Crypto lib, to make iOS wallets safer and better. submitted by Sajjon to Bitcoin [link] [comments]

Help getting Bitcoin/Ethereum Elliptic Curve `secp256k1` added to Apples newly open source Swift-Crypto lib, to make iOS wallets safer and better.

Help getting Bitcoin/Ethereum Elliptic Curve `secp256k1` added to Apples newly open source Swift-Crypto lib, to make iOS wallets safer and better. submitted by Sajjon to CryptoCurrency [link] [comments]

Help getting Bitcoin/Ethereum Elliptic Curve `secp256k1` added to Apples newly open source Swift-Crypto lib, to make iOS wallets safer and better.

Help getting Bitcoin/Ethereum Elliptic Curve `secp256k1` added to Apples newly open source Swift-Crypto lib, to make iOS wallets safer and better. submitted by scgco to GGCrypto [link] [comments]

RiB Newsletter #14 – Are We Smart (Contract) Yet?

We’re seeing a bunch of interesting Rust blockchain and crypto projects, so this month the “Interesting Things” section is loaded up with news, papers, and project links.
This month, Elrond, appeared on our radar with the launch of their mainnet. Although not written in Rust, it runs Rust smart contracts on its Arwen WASM VM, which itself is based on the Rust Wasmer VM. Along with NEAR, Nervos, and Enigma (and probably others), this continues an encouraging trend of blockchains enabling smart contracts in Rust. See the “Interesting Things” section for examples of Elrond’s Rust contracts.
Rust continues to be popular for research into zero-knowledge proofs, with Microsoft releasing Spartan, a zk-SNARK system without trusted setup.
In RiB news, we published a late one-year anniversary blog post. It has some reflection on the changes to, and growth of, RiB over the last year.
The Awesome Blockchain Rust project, which is maintained by Sun under the rust-in-blockchain GitHub org, has received a stream of updates recently, and is now published as the Awesome-RiB page on
It’s a pretty good resource for finding blockchain-related Rust projects, with links to many of the more prominent and mature projects noted in the RiB newsletter. It could use more eyes on it though.

Project Spotlight

Each month we like to shine a light on a notable Rust blockchain project. This month that project is… is an Ethereum & Celo library and wallet implementation, implemented as a port of the ethers.js library to Rust.
Ethereum client programming is usually done in JavaScript with either web3.js or ethers.js, with ethers.js being the newer of the two. These clients communicate to an Ethereum node, typically via JSON-RPC (or, when in the browser, via an “injected” client provider that follows EIP-1193, like MetaMask). then provides a strongly-typed alternative for writing software that interacts with the Ethereum network.
As of now it is only suited for non-browser use cases, but if you prefer hacking in Rust to JavaScript, as some of us surely do, it is worth looking into for your next Ethereum project.
The author of, Georgios Konstantopoulos, accepts donations to sponsor their work.
Note that there is also a Rust alternative to web3.js, rust-web3.

Interesting Things


Blog Posts



Podcasts and Videos

Read more:
submitted by Aimeedeer to rust [link] [comments]

Why quantum computers will be good for Bitcoin.

There is no doubt that bitcoins software will evolve to cope to the latest threat well before quantum computers can crack the already inherently secure nature of bitcoins code.
But how quickly can all the banking and other legacy financial software manage to upgrade in time?
No chance.
What do you think will happen to the price of bitcoin when no coiners start losing their bank account balances to quantum cyber attacks?
submitted by Pipdotcom to Bitcoin [link] [comments]

Reddcoin (RDD) 02/20 Progress Report - Core Wallet v3.1 Evolution & PoSV v2 - Commits & More Commits to v3.1! (Bitcoin Core 0.10, MacOS Catalina, QT Enhanced Speed and Security and more!)

Reddcoin (RDD) Core Dev Team Informal Progress Report, Feb 2020 - As any blockchain or software expert will confirm, the hardest part of making successful progress in blockchain and crypto is invisible to most users. As developers, the Reddcoin Core team relies on internal experts like John Nash, contributors offering their own code improvements to our repos (which we would love to see more of!) and especially upstream commits from experts working on open source projects like Bitcoin itself. We'd like tothank each and everyone who's hard work has contributed to this progress.
As part of Reddcoin's evolution, and in order to include required security fixes, speed improvements that are long overdue, the team has up to this point incorporated the following code commits since our last v3.0.1 public release. In attempting to solve the relatively minor font display issue with MacOS Catalina, we uncovered a complicated interweaving of updates between Reddcoin Core, QT software, MacOS SDK, Bitcoin Core and related libraries and dependencies that mandated we take a holistic approach to both solve the Catalina display problem, but in doing so, prepare a more streamlined overall build and test system, allowing the team to roll out more frequent and more secure updates in the future. And also to include some badly needed fixes in the current version of Core, which we have tentatively labeled Reddcoin Core Wallet v3.1.
Note: As indicated below, v3.1 is NOT YET AVAILABLE FOR DOWNLOAD BY PUBLIC. We wil advise when it is.
The new v3.1 version should be ready for internal QA and build testing by the end of this week, with luck, and will be turned over to the public shortly thereafter once testing has proven no unexpected issues have been introduced. We know the delay has been a bit extended for our ReddHead MacOS Catalina stakers, and we hope to have them all aboard soon. We have moved with all possible speed while attempting to incorproate all the required work, testing, and ensuring security and safety for our ReddHeads.
Which leads us to: PoSV v2 activation and the supermajority on Mainnet at the time of this writing has reached 5625/9000 blocks or 62.5%. We have progressed quite well and without any reported user issues since release, but we need all of the community to participate! This activation, much like the funding mechanisms currently being debated by BCH and others, and employed by DASH, will mean not only a catalyst for Reddcoin but ensure it's future by providing funding for the dev team. As a personal plea from the team, please help us support the PoSV v2 activation by staking your RDD, no matter how large or small your amount of stake.
Every block and every RDD counts, and if you don't know how, we'll teach you! Live chat is fun as well as providing tech support you can trust from devs and community ReddHead members. Join us today in staking and online and collect some RDD "rain" from users and devs alike!
If you're holding Reddcoin and not staking, or you haven't upgraded your v2.x wallet to v3.0.1 (current release), we need you to help achieve consensus and activate PoSV v2! For details, see the pinned message here or our website or medium channel. Upgrade is simple and takes moments; if you're nervous or unsure, we're here to help live in Telegram or Discord, as well as other chat programs. See our website for links.
Look for more updates shortly as our long-anticipated Reddcoin Payment Gateway and Merchant Services API come online with point-of-sale support, as we announce the cross-crypto-project Aussie firefighter fundraiser program, as well as a comprehensive update to our development roadmap and more.
Work has restarted on ReddID and multiple initiatives are underway to begin educating and sharing information about ReddID, what it is, and how to use it, as we approach a releasable ReddID product. We enthusiastically encourage anyone interested in working to bring these efforts to life, whether writers, UX/UI experts, big data analysts, graphic artists, coders, front-end, back-end, AI, DevOps, the Reddcoin Core dev team is growing, and there's more opportunity and work than ever!
Bring your talents to a community and dev team that truly appreciates it, and share the Reddcoin Love!
And now, lots of commits. As v3.1 is not yet quite ready for public release, these commits have not been pushed publicly, but in the interests of sharing progress transparently, and including our ReddHead community in the process, see below for mind-numbing technical detail of work accomplished.
e5c143404 - - 2014-08-07 - Ross Nicoll - Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope. *99a7dba2e - - 2014-08-15 - Cory Fields - tests: fix test-runner for osx. Closes ##4708 *8c667f1be - - 2014-08-15 - Cory Fields - build: add to the list of meta-depends *bcc1b2b2f - - 2014-08-15 - Cory Fields - depends: fix shasum on osx < 10.9 *54dac77d1 - - 2014-08-18 - Cory Fields - build: add option for reducing exports (v2) *6fb9611c0 - - 2014-08-16 - randy-waterhouse - build : fix CPPFLAGS for libbitcoin_cli *9958cc923 - - 2014-08-16 - randy-waterhouse - build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix. *342aa98ea - - 2014-08-07 - Cory Fields - build: fix automake warnings about the use of INCLUDES *46db8ad51 - - 2020-02-18 - John Nash - build: add build.h to the correct target *a24de1e4c - - 2014-11-26 - Pavel Janík - Use complete path to include bitcoin-config.h. *fd8f506e5 - - 2014-08-04 - Wladimir J. van der Laan - qt: Demote ReportInvalidCertificate message to qDebug *f12aaf3b1 - - 2020-02-17 - John Nash - build: QT5 compiled with fPIC require fPIC to be enabled, fPIE is not enough *7a991b37e - - 2014-08-12 - Wladimir J. van der Laan - build: check for sys/prctl.h in the proper way *2cfa63a48 - - 2014-08-11 - Wladimir J. van der Laan - build: Add mention of --disable-wallet to bdb48 error messages *9aa580f04 - - 2014-07-23 - Cory Fields - depends: add shared dependency builder *8853d4645 - - 2014-08-08 - Philip Kaufmann - [Qt] move SubstituteFonts() above ToolTipToRichTextFilter *0c98e21db - - 2014-08-02 - Ross Nicoll - URLs containing a / after the address no longer cause parsing errors. *7baa77731 - - 2014-08-07 - ntrgn - Fixes ignored qt 4.8 codecs path on windows when configuring with --with-qt-libdir *2a3df4617 - - 2014-08-06 - Cory Fields - qt: fix unicode character display on osx when building with 10.7 sdk *71a36303d - - 2014-08-04 - Cory Fields - build: fix race in 'make deploy' for windows *077295498 - - 2014-08-04 - Cory Fields - build: Fix 'make deploy' when binaries haven't been built yet *ffdcc4d7d - - 2014-08-04 - Cory Fields - build: hook up qt translations for static osx packaging *25a7e9c90 - - 2014-08-04 - Cory Fields - build: add --with-qt-translationdir to configure for use with static qt *11cfcef37 - - 2014-08-04 - Cory Fields - build: teach macdeploy the -translations-dir argument, for use with static qt *4c4ae35b1 - - 2014-07-23 - Cory Fields - build: Find the proper xcb/pcre dependencies *942e77dd2 - - 2014-08-06 - Cory Fields - build: silence mingw fpic warning spew *e73e2b834 - - 2014-06-27 - Huang Le - Use async name resolving to improve net thread responsiveness *c88e76e8e - - 2014-07-23 - Cory Fields - build: don't let libtool insert rpath into binaries *18e14e11c - - 2014-08-05 - ntrgn - build: Fix windows configure when using --with-qt-libdir *bb92d65c4 - - 2014-07-31 - Cory Fields - test: don't let the port number exceed the legal range *62b95290a - - 2014-06-18 - Cory Fields - test: redirect comparison tool output to stdout *cefe447e9 - - 2014-07-22 - Cory Fields - gitian: remove unneeded option after last commit *9347402ca - - 2014-07-21 - Cory Fields - build: fix broken boost chrono check on some platforms *c9ed039cf - - 2014-06-03 - Cory Fields - build: fix whitespace in pkg-config variable *3bcc5ad37 - - 2014-06-03 - Cory Fields - build: allow linux and osx to build against static qt5 *01a44ba90 - - 2014-07-17 - Cory Fields - build: silence false errors during make clean *d1fbf7ba2 - - 2014-07-08 - Cory Fields - build: fix win32 static linking after libtool merge *005ae2fa4 - - 2014-07-08 - Cory Fields - build: re-add AM_LDFLAGS where it's overridden *37043076d - - 2014-07-02 - Wladimir J. van der Laan - Fix the Qt5 build after d95ba75 *f3b4bbf40 - - 2014-07-01 - Wladimir J. van der Laan - qt: Change serious messages from qDebug to qWarning *f4706f753 - - 2014-07-01 - Wladimir J. van der Laan - qt: Log messages with type>QtDebugMsg as non-debug *98e85fa1f - - 2014-06-06 - Pieter Wuille - libsecp256k1 integration *5f1f2e226 - - 2020-02-17 - John Nash - Merge branch 'switch_verification_code' into Build *1f30416c9 - - 2014-02-07 - Pieter Wuille - Also switch the (unused) verification code to low-s instead of even-s. *1c093d55e - - 2014-06-06 - Cory Fields - secp256k1: Add build-side changes for libsecp256k1 *7f3114484 - - 2014-06-06 - Cory Fields - secp256k1: add libtool as a dependency *2531f9299 - - 2020-02-17 - John Nash - Move network-time related functions to timedata.cpp/h *d003e4c57 - - 2020-02-16 - John Nash - build: fix build weirdness after 54372482. *7035f5034 - - 2020-02-16 - John Nash - Add ::OUTPUT_SIZE *2a864c4d8 - - 2014-06-09 - Cory Fields - crypto: create a separate lib for crypto functions *03a4e4c70 - - 2014-06-09 - Cory Fields - crypto: explicitly check for byte read/write functions *a78462a2a - - 2014-06-09 - Cory Fields - build: move bitcoin-config.h to its own directory *a885721c4 - - 2014-05-31 - Pieter Wuille - Extend and move all crypto tests to crypto_tests.cpp *5f308f528 - - 2014-05-03 - Pieter Wuille - Move {Read,Write}{LE,BE}{32,64} to common.h and use builtins if possible *0161cc426 - - 2014-05-01 - Pieter Wuille - Add built-in RIPEMD-160 implementation *deefc27c0 - - 2014-04-28 - Pieter Wuille - Move crypto implementations to src/crypto/ *d6a12182b - - 2014-04-28 - Pieter Wuille - Add built-in SHA-1 implementation. *c3c4f9f2e - - 2014-04-27 - Pieter Wuille - Switch miner.cpp to use sha2 instead of OpenSSL. *b6ed6def9 - - 2014-04-28 - Pieter Wuille - Remove getwork() RPC call *0a09c1c60 - - 2014-04-26 - Pieter Wuille - Switch script.cpp and hash.cpp to use sha2.cpp instead of OpenSSL. *8ed091692 - - 2014-04-20 - Pieter Wuille - Add a built-in SHA256/SHA512 implementation. *0c4c99b3f - - 2014-06-21 - Philip Kaufmann - small cleanup in src/compat .h and .cpp *ab1369745 - - 2014-06-13 - Cory Fields - sanity: hook up sanity checks *f598c67e0 - - 2014-06-13 - Cory Fields - sanity: add libc/stdlib sanity checks *b241b3e13 - - 2014-06-13 - Cory Fields - sanity: autoconf check for sys/select.h *cad980a4f - - 2019-07-03 - John Nash - build: Add a top-level forwarding target for src/ objects *f4533ee1c - - 2019-07-03 - John Nash - build: qt: split locale resources. Fixes non-deterministic distcheck *4a0e46e76 - - 2019-06-29 - John Nash - build: fix version dependency *2f61699d9 - - 2019-06-29 - John Nash - build: quit abusing AMCPPFLAGS *99b60ba49 - - 2019-06-29 - John Nash - build: avoid the use of top and abs_ dir paths *c8f673d5d - - 2019-06-29 - John Nash - build: Tidy up file generation output *5318bce57 - - 2019-06-29 - John Nash - build: nuke Makefile.include from orbit *672a25349 - - 2019-06-29 - John Nash - build: add stub makefiles for easier subdir builds *562b7c5a6 - - 2020-02-08 - John Nash - build: delete old's *066120079 - - 2020-02-08 - John Nash - build: Switch to non-recursive make
Whew! No wonder it's taken the dev team a while! :)
TL;DR: Trying to fix MacOS Catalina font display led to requiring all kinds of work to migrate and evolve the Reddcoin Core software with Apple, Bitcoin and QT components. Lots of work done, v3.1 public release soon. Also other exciting things and ReddID back under active dev effort.
submitted by TechAdept to reddCoin [link] [comments]

Can a quantum computer be used for bitcoin mining?

This has been bothering me for a while.
I'm a newbie in computer science, and I just found out about Grover’s algorithm, which can only be implemented on a quantum computer. Supposedly it can achieve a quadratic speedup over a classical computer, brute-forcing a solution to a n-bit symmetric encryption key in 2^n/2 iterations.
This led me to think that, by utilizing a quantum computer or quantum simulator of about 40-qubits that runs Grover's algorithm, is it possible to mine bitcoins this way? The current difficulty of bitcoin mining is about 15,466,098,935,554 (approximately 2^44), which means that it would take about 2^44*2^32=2^76 SHA256 hashes before a valid block header hash is found.
However, by implementing Grover's algorithm, we would only need to sort through 2^76/2=2^38 hashes to discover a valid block header hash. A 38-qubit quantum computer should be sufficient in this case - which means the 40-qubit quantum computer should be more than enough to handle bitcoin mining.
Therefore - is it possible to use quantum computers to mine bitcoins this way? I'm not too familiar with quantum computers, so please correct me if I missed something.......
NOTE: I am NOT asking whether it is possible to use quantum computers to break the ECDSA secp256k1 algorithm, which would effectively allow anyone to steal bitcoins from wallets. I know that this would require much more than 40 qubits, and is definitely not happening in the near-future.
Rather, I'm asking about bitcoin mining, which is a much easier problem than trying to break ECDSA secp256k1.
submitted by Palpatine88888 to QuantumComputing [link] [comments]

MAAM #57 Monero Ask Anything Monday

Given the success of the previous MAAMs (see MAAM #1, MAAM #2, MAAM #3, MAAM #4, MAAM #5, MAAM #6, MAAM #7, MAAM #8, MAAM #9, MAAM #10, MAAM #11, MAAM #12, MAAM #13, MAAM #14, MAAM #15, MAAM #16, MAAM #17, MAAM #18, MAAM #19, MAAM #20, MAAM #21, MAAM #22, MAAM #23, MAAM #24, MAAM #25, MAAM #26, MAAM #27, MAAM #28, MAAM #29, MAAM #30, MAAM #31, MAAM #32, MAAM #33, MAAM #34, MAAM #35, MAAM #36, MAAM #37, MAAM #38, MAAM #39, MAAM #40, MAAM #41, MAAM #42, MAAM #43, MAAM #44, MAAM #45, MAAM #46, MAAM #47, MAAM #48, MAAM #49, MAAM #50, MAAM #51, MAAM #52, MAAM #53, MAAM #54, MAAM #55, MAAM #56), let's keep this rolling.
The principle is simple: ask anything you'd like to know about Monero, especially the dumb questions that you've been keeping for you every other days, may the community clarify it all!
Finally, credits to binaryFate for starting the concept!
submitted by dEBRUYNE_1 to Monero [link] [comments]

Threshold Signature Explained— Bringing Exciting Applications with TSS

Threshold Signature Explained— Bringing Exciting Applications with TSS
— A deep dive into threshold signature without mathematics by ARPA’s cryptographer Dr. Alex Su
Threshold signature is a distributed multi-party signature protocol that includes distributed key generation, signature, and verification algorithms.
In recent years, with the rapid development of blockchain technology, signature algorithms have gained widespread attention in both academic research and real-world applications. Its properties like security, practicability, scalability, and decentralization of signature are pored through.
Due to the fact that blockchain and signature are closely connected, the development of signature algorithms and the introduction of new signature paradigms will directly affect the characteristics and efficiency of blockchain networks.
In addition, institutional and personal account key management requirements stimulated by distributed ledgers have also spawned many wallet applications, and this change has also affected traditional enterprises. No matter in the blockchain or traditional financial institutions, the threshold signature scheme can bring security and privacy improvement in various scenarios. As an emerging technology, threshold signatures are still under academic research and discussions, among which there are unverified security risks and practical problems.
This article will start from the technical rationale and discuss about cryptography and blockchain. Then we will compare multi-party computation and threshold signature before discussing the pros and cons of different paradigms of signature. In the end, there will be a list of use cases of threshold signature. So that, the reader may quickly learn about the threshold signature.
I. Cryptography in Daily Life
Before introducing threshold signatures, let’s get a general understanding of cryptography. How does cryptography protect digital information? How to create an identity in the digital world? At the very beginning, people want secure storage and transmission. After one creates a key, he can use symmetric encryption to store secrets. If two people have the same key, they can achieve secure transmission between them. Like, the king encrypts a command and the general decrypts it with the corresponding key.
But when two people do not have a safe channel to use, how can they create a shared key? So, the key exchange protocol came into being. Analogously, if the king issues an order to all the people in the digital world, how can everyone proves that the sentence originated from the king? As such, the digital signature protocol was invented. Both protocols are based on public key cryptography, or asymmetric cryptographic algorithms.

“Tiger Rune” is a troop deployment tool used by ancient emperor’s, made of bronze or gold tokens in the shape of a tiger, split in half, half of which is given to the general and the other half is saved by the emperor. Only when two tiger amulets are combined and used at the same time, will the amulet holder get the right to dispatch troops.
Symmetric and asymmetric encryption constitute the main components of modern cryptography. They both have three fixed parts: key generation, encryption, and decryption. Here, we focus on digital signature protocols. The key generation process generates a pair of associated keys: the public key and the private key. The public key is open to everyone, and the private key represents the identity and is only revealed to the owner. Whoever owns the private key has the identity represented by the key. The encryption algorithm, or signature algorithm, takes the private key as input and generate a signature on a piece of information. The decryption algorithm, or signature verification algorithm, uses public keys to verify the validity of the signature and the correctness of the information.
II. Signature in the Blockchain
Looking back on blockchain, it uses consensus algorithm to construct distributed books, and signature provides identity information for blockchain. All the transaction information on the blockchain is identified by the signature of the transaction initiator. The blockchain can verify the signature according to specific rules to check the transaction validity, all thanks to the immutability and verifiability of the signature.
For cryptography, the blockchain is more than using signature protocol, or that the consensus algorithm based on Proof-of-Work uses a hash function. Blockchain builds an infrastructure layer of consensus and transaction through. On top of that, the novel cryptographic protocols such as secure multi-party computation, zero-knowledge proof, homomorphic encryption thrives. For example, secure multi-party computation, which is naturally adapted to distributed networks, can build secure data transfer and machine learning platforms on the blockchain. The special nature of zero-knowledge proof provides feasibility for verifiable anonymous transactions. The combination of these cutting-edge cryptographic protocols and blockchain technology will drive the development of the digital world in the next decade, leading to secure data sharing, privacy protection, or more applications now unimaginable.
III. Secure Multi-party Computation and Threshold Signature
After introducing how digital signature protocol affects our lives, and how to help the blockchain build identities and record transactions, we will mention secure multi-party computation (MPC), from where we can see how threshold signatures achieve decentralization. For more about MPC, please refer to our previous posts which detailed the technical background and application scenarios.
MPC, by definition, is a secure computation that several participants jointly execute. Security here means that, in one computation, all participants provide their own private input, and can obtain results from the calculation. It is not possible to get any private information entered by other parties. In 1982, when Prof. Yao proposed the concept of MPC, he gave an example called the “Millionaires Problem” — two millionaires who want to know who is richer than the other without telling the true amount of assets. Specifically, the secure multiparty computation would care about the following properties:
  • Privacy: Any participant cannot obtain any private input of other participants, except for information that can be inferred from the computation results.
  • Correctness and verifiability: The computation should ensure correct execution, and the legitimacy and correctness of this process should be verifiable by participants or third parties.
  • Fairness or robustness: All parties involved in the calculation, if not agreed in advance, should be able to obtain the computation results at the same time or cannot obtain the results.
Supposing we use secure multi-party computation to make a digital signature in a general sense, we will proceed as follows:
  • Key generation phase: all future participants will be involved together to do two things: 1) each involved party generates a secret private key; 2) The public key is calculated according to the sequence of private keys.
  • Signature phase: Participants joining in a certain signature use their own private keys as private inputs, and the information to be signed as a public input to perform a joint signature operation to obtain a signature. In this process, the privacy of secure multi-party computing ensures the security of private keys. The correctness and robustness guarantee the unforgeability of the signature and everyone can all get signatures.
  • Verification phase: Use the public key corresponding to the transaction to verify the signature as traditional algorithm. There is no “secret input” during the verification, this means that the verification can be performed without multi-party computation, which will become an advantage of multi-party computation type distributed signature.
The signature protocol constructed on the idea of ​​secure multiparty computing is the threshold signature. It should be noted that we have omitted some details, because secure multiparty computing is actually a collective name for a type of cryptographic protocol. For different security assumptions and threshold settings, there are different construction methods. Therefore, the threshold signatures of different settings will also have distinctive properties, this article will not explain each setting, but the comparative result with other signature schemes will be introduced in the next section.
IV. Single Signature, Multi-Signature and Threshold Signature
Besides the threshold signature, what other methods can we choose?
Bitcoin at the beginning, uses single signature which allocates each account with one private key. The message signed by this key is considered legitimate. Later, in order to avoid single point of failure, or introduce account management by multiple people, Bitcoin provides a multi-signature function. Multi-signature can be simply understood as each account owner signs successively and post all signatures to the chain. Then signatures are verified in order on the chain. When certain conditions are met, the transaction is legitimate. This method achieves a multiple private keys control purpose.
So, what’s the difference between multi-signature and threshold signature?
Several constraints of multi-signature are:
  1. The access structure is not flexible. If an account’s access structure is given, that is, which private keys can complete a legal signature, this structure cannot be adjusted at a later stage. For example, a participant withdraws, or a new involved party needs to change the access structure. If you must change, you need to complete the initial setup process again, which will change the public key and account address as well.
  2. Less efficiency. The first is that the verification on chain consumes power of all nodes, and therefore requires a processing fee. The verification of multiple signatures is equivalent to multiple single signatures. The second is performance. The verification obviously takes more time.
  3. Requirements of smart contract support and algorithm adaptation that varies from chain to chain. Because multi-sig is not naturally supported. Due to the possible vulnerabilities in smart contracts, this support is considered risky.
  4. No anonymity, this is not able to be trivially called disadvantage or advantage, because anonymity is required for specific conditions. Anonymity here means that multi-signature directly exposes all participating signers of the transaction.
Correspondingly, the threshold signature has the following features:
  1. The access structure is flexible. Through an additional multi-party computation, the existing private key sequence can be expanded to assign private keys to new participants. This process will not expose the old and newly generated private key, nor will it change the public key and account address.
  2. It provides more efficiency. For the chain, the signature generated by the threshold signature is not different from a single signature, which means the following improvements : a) The verification is the same as the single signature, and needs no additional fee; b ) the information of the signer is invisible, because for other nodes, the information is decrypted with the same public key; c) No smart contract on chain is needed to provide additional support.
In addition to the above discussion, there is a distributed signature scheme supported by Shamir secret sharing. Secret sharing algorithm has a long history which is used to slice information storage and perform error correction information. From the underlying algorithm of secure computation to the error correction of the disc. This technology has always played an important role, but the main problem is that when used in a signature protocol, Shamir secret sharing needs to recover the master private key.
As for multiple signatures or threshold signature, the master private key has never been reconstructed, even if it is in memory or cache. this short-term reconstruction is not tolerable for vital accounts.
V. Limitations
Just like other secure multi-party computation protocols, the introduction of other participants makes security model different with traditional point-to-point encrypted transmission. The problem of conspiracy and malicious participants were not taken into account in algorithms before. The behavior of physical entities cannot be restricted, and perpetrators are introduced into participating groups.
Therefore, multi-party cryptographic protocols cannot obtain the security strength as before. Effort is needed to develop threshold signature applications, integrate existing infrastructure, and test the true strength of threshold signature scheme.
VI. Scenarios
1. Key Management
The use of threshold signature in key management system can achieve a more flexible administration, such as ARPA’s enterprise key management API. One can use the access structure to design authorization pattern for users with different priorities. In addition, for the entry of new entities, the threshold signature can quickly refresh the key. This operation can also be performed periodically to level up the difficulty of hacking multiple private keys at the same time. Finally, for the verifier, the threshold signature is not different from the traditional signature, so it is compatible with old equipments and reduces the update cost. ARPA enterprise key management modules already support Elliptic Curve Digital Signature Scheme secp256k1 and ed25519 parameters. In the future, it will be compatible with more parameters.
2. Crypto Wallet
Wallets based on threshold signature are more secure because the private key doesn’t need to be rebuilt. Also, without all signatures posted publicly, anonymity can be achieved. Compared to the multi-signature, threshold signature needs less transaction fees. Similar to key management applications, the administration of digital asset accounts can also be more flexible. Furthermore, threshold signature wallet can support various blockchains that do not natively support multi-signature, which reduces the risk of smart contracts bugs.


This article describes why people need the threshold signature, and what inspiring properties it may bring. One can see that threshold signature has higher security, more flexible control, more efficient verification process. In fact, different signature technologies have different application scenarios, such as aggregate signatures not mentioned in the article, and BLS-based multi-signature. At the same time, readers are also welcomed to read more about secure multi-party computation. Secure computation is the holy grail of cryptographic protocols. It can accomplish much more than the application of threshold signatures. In the near future, secure computation will solve more specific application questions in the digital world.

About Author

Dr. Alex Su works for ARPA as the cryptography researcher. He got his Bachelor’s degree in Electronic Engineering and Ph.D. in Cryptography from Tsinghua University. Dr. Su’s research interests include multi-party computation and post-quantum cryptography implementation and acceleration.

About ARPA

ARPA is committed to providing secure data transfer solutions based on cryptographic operations for businesses and individuals.
The ARPA secure multi-party computing network can be used as a protocol layer to implement privacy computing capabilities for public chains, and it enables developers to build efficient, secure, and data-protected business applications on private smart contracts. Enterprise and personal data can, therefore, be analyzed securely on the ARPA computing network without fear of exposing the data to any third party.
ARPA’s multi-party computing technology supports secure data markets, precision marketing, credit score calculations, and even the safe realization of personal data.
ARPA’s core team is international, with PhDs in cryptography from Tsinghua University, experienced systems engineers from Google, Uber, Amazon, Huawei and Mitsubishi, blockchain experts from the University of Tokyo, AIG, and the World Bank. We also have hired data scientists from CircleUp, as well as financial and data professionals from Fosun and Fidelity Investments.
For more information about ARPA, or to join our team, please contact us at [email protected].
Learn about ARPA’s recent official news:
Telegram (English):
Telegram (Việt Nam):
Telegram (Russian):
Telegram (Indonesian):
Telegram (Thai):
Telegram (Philippines):
Telegram (Turkish):
Korean Chats: (Kakao) & (Telegram, new)
Twitter: u/arpaofficial
submitted by arpaofficial to u/arpaofficial [link] [comments]

Upcoming Updates to Bitcoin Consensus

Price and Libra posts are shit boring, so let's focus on a technical topic for a change.
Let me start by presenting a few of the upcoming Bitcoin consensus changes.
(as these are consensus changes and not P2P changes it does not include erlay or dandelion)
Let's hope the community strongly supports these upcoming updates!


The sexy new signing algo.




A provably-secure way for a group of n participants to form an aggregate pubkey and signature. Creating their group pubkey does not require their coordination other than getting individual pubkeys from each participant, but creating their signature does require all participants to be online near-simultaneously.




Hiding a Bitcoin SCRIPT inside a pubkey, letting you sign with the pubkey without revealing the SCRIPT, or reveal the SCRIPT without signing with the pubkey.




Encode each possible branch of a Bitcoin contract separately, and only require revelation of the exact branch taken, without revealing any of the other branches. One of the Taproot script versions will be used to denote a MAST construction. If the contract has only one branch then MAST does not add more overhead.



submitted by almkglor to Bitcoin [link] [comments]

How to apply sensible submodule namespaces?

I've written a library Secp256k1 which contains several modules,
When someone imports my library, i.e., require secp256k1, they also get access to the modules not named Secp256k1, for example:

import secp256k1

require "secp256k1"

everything starts with a random number

private_key = Secp256k1.new_private_key

private keys in bitcoin's wallet import format

wif = Bitcoin.wif_from_private private_key, "80" ```
I am wondering, is there any sensible way to have namespaces for submodules?
For example: Secp256k1::Bitcoin.wif_from_private priv instead of referencing Bitcoin directly? I'm asking because maybe other libraries also reference such a namespace and I want clarity for developers using this library.
I'm currently refactoring the library and wondering what's the best practice is to arrange the modules exposed by the library.
submitted by q9fm to crystal_programming [link] [comments]

Bitcoin Verde v1.1.0 : Schnorr Signatures

For those unacquainted:
Bitcoin Verde is an indexing full-node, written from the ground up in Java. Bitcoin Verde comes with a block explorer, and a stratum mining pool. While we consider v1.1.0 still a beta release, our public node ( has been stable since January.
Bitcoin Verde is the first to write a Schnorr Signature verification algorithm for Java (using Pieter Wuille's specification) ; if others implementations or wallets need to use our implementation as a reference, it can be located here. Verde's Schnorr implementation has been tested against the same suite of tests as ABC's (Test file located here). We intend to submit a pull request to Bouncy Castle sometime in the future.
Things that are new this release:
Similar to our previous release, Bitcoin Verde is very likely incompatible with Windows. Furthermore, it's an indexing node, and because of that will have more system requirements than a traditional node due to database indexes and the inherent underlying database structure. Our fully synced node is currently using 615G disk space, and 21G of memory. Bitcoin Verde can be configured to run with far less memory, with a minimum around 2G. (Disable UTXO caching, disable TX Bloom Filter, set max database memory to ~1.5G). We highly recommend running BV on an SSD or M2. Traditional HDD drives are awful at random reads, and the last attempted initial-block-download we performed on an HDD took about 2+ weeks to complete.
If you have any problems with your node, please reach out to us at [email protected]. We'd be happy to help and troubleshoot problems. Alternatively, you can report bugs or issues to our github.
We've been diligently working on a mobile wallet based on the Bitcoin Verde codebase. We hope to provide a more modern replacement for bitcoinj, while also supporting SLP tokens. We are also ensuring all Bitcoin Verde SPV code can be transpiled to Objective-C (with Swift Bindings) for use on iOS. Finally, Bitcoin Verde is experimenting with a new message to improve the initial synchronization of SPV wallets called addrblocks, which will greatly improve the ability to validate SLP tokens. Additionally/alternatively, we have been looking at supporting BIP-157 for a more privacy-oriented way to achieve near-instant SPV synchronization; we look forward to sharing these thoughts in the near future.
Again, thank you to the XT team for your support. Another thank you for the ABC team for welcoming us into your conversations, and for helping us understand some of the nuanced aspects of this HF.
To install/upgrade your nodes, clone/pull master at, and reference the README under Installing/Upgrading.
submitted by FerriestaPatronum to btc [link] [comments]

Committed bloom filters for improved wallet performance and SPV security

submitted by supermari0 to Bitcoin [link] [comments]

Fresh Bitcoin Cash Implementation

Fresh Bitcoin Cash Implementation
I have been working on a fresh Bitcoin Cash full node implementation (and an Android wallet). You can find the code at It is all written by me and uses only C++ standard libraries and Pieter Wuille's secp256k1 implementation. It is still in early development and needs a lot of tests written and does not implement all consensus rules. I would love to get some feedback.
It is highly multi-threaded including block validation. Here are some block validation statistics from a recent initial block download.
Block Validation Statistics

This data was gathered during an initial block download in which all blocks above 540288 were fully validated. This includes the blocks from the recent BCH stress test (Sept 1). The times are the time spent validating and adding a block to the chain, not including periodic transaction output set saves.
The machine it is running on is running Ubuntu 18.04. The CPU is an AMD Phenom(tm) II X4 945 Processor (4 core 3 GHz). It has 8 GiB of memory (2 x 4 GiB) DIMM DDR Synchronous 1333 MHz (0.8 ns).
submitted by KarlTheProgrammer to Bitcoincash [link] [comments]

Snowblossom (SNOW)

Snowblossom (SNOW)

Very interesting coin. Only at ~750k marketcap. Only being traded on a single exchange (qtrade). Seems to be completely under the radar, nearly no posts on reddit about it made so far.
Completely at ground floor with no marketing yet. Main developer has been working on Bitcoin projects and crypto since before 2012 (was the main developer for Satoshi Dice).
Clean, Original Code. Custom POW. UTXO Built into Blocks Headers. Truly ASIC, Miner Centralization, and Quantum Tough. No Premining.
Aggressive IO based PoW with large deterministic files should be very hard to ASIC in any sort of cost effective way. Increasing file size as hashrate increases means large SSDs and NVMEs will likely remain a competitve mining option.
Quantum Tough. It is estimated that a 256-bit elliptic curve (like bitcoin uses) could be broken by a quantum computer with about 1600 qubits. SnowBlossom has a QHard mode which does a 3-of-3 multisig (secp256k1, RSA 8192, DSTU 4145) which increases the required qubits to the 16,000 range.
UTXO root in block header. Allows giving provable results to light clients, such as browser based wallets and mobile apps.
Current supply: 2,113,650 out of a max of 21,000,000 (same mining curve as Bitcoin).
They also just released an Android wallet, and there is a lot of other stuff happening with the project. What does everyone here think?
submitted by Santalol to CryptoMoonShots [link] [comments]

Notes from Ethereum Core Devs Meeting #31 [1/12/18]

The next core dev meeting will be this Friday, January 26, 2018. The agenda and live stream link are located here.

Ethereum Core Devs Meeting 31 Notes

Meeting Date/Time: Friday 01/12/18 at 14:00 UTC

Meeting Duration: 1.5 hours

GitHub Agenda Page

Audio/Video of the meeting

Reddit thread


  1. Testing Updates.
  2. Yellow paper update.
  3. EWASM update + update on the following related EIPs. a. EVM 2.0 - b. Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN - c. Subroutines and Static Jumps for the EVM -
  4. Stateless client development.
  5. Add ECADD and ECMUL precompiles for secp256k1 - [See this blog post for context].
  6. Introduce miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined).
  7. Creating a relay network of nodes to mitigate issues described here and other transaction propagation issues.
  8. Fork release management/Constantinople.
  9. Client updates.
  10. Other non-agenda issues.


Video starts at [4:36].

[4:56] 1. Testing Updates

No updates.

[5:27] 2. Yellow paper update.

Gavin put the Yellow Paper under the Creative Commons Free Culture License CC-BY-SA. Yoichi and Nick Savers have been making progress handling the Yellow Paper PRs. There is still the somewhat unresolved issue of what should define the "formal standard" of Ethereum and should an update to the Yellow Paper or another specification be required for every new EIP. This can be discussed in more detail in future meetings when there is greater attendance.

[7:43] 3. EWASM update + update on the following related EIPs.

[7:55] General update

Ewasm contributors are currently meeting in person together in Lisbon. EWASM EIPs listed in the subpoints are not up to date and can be disregarded. People should use the repo. The design has been pretty much speced out in the last year. During the design phase there were 2 implementations done in parallel: Javascript and C++ (which can be integrated in cpp-ethereum and geth). Issues have been faced in building out EWASM including struggling with implementing synchronous code in Javascript/browser. Idea was to move to an asynchronous model. Currently there is not a full decision on using synchronous vs asynchronous, but we are leaning towards synchronous implementation in C++ to run a testnet in cpp-ethereum that can run pure Web Assembly contracts. Metering contract in Web Assembly is on the to-do list and doesn't rely on sync/async decision. Likely will take week to come to a decision on sync vs async. More technical discussion and a funny anecdote involving the asynchronous vs synchronous decision and the affects of the recent Spectre/Meltdown attacks start at [12:07].

[15:08] a. EVM 2.0 -

Martin Becze will be closing this EIP. It is outdated.

[15:28] b. Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN -

This doesn't have to do with EWASM, it has to do with adding extra opcodes in the current EVM. It is an upgrade to EVM 1.0 which is not needed if we skip straight to EWASM.

[16:47] c. Subroutines and Static Jumps for the EVM -

Greg has been working with Seed (Gitter tag) who is writing an ELM formalization of the EIP. Greg says that there is no formal social process for deciding things like EVM 1.5 implementation so he is not sure if/when it would be implemented. Greg has been working on cleaning up the proposal for those who want to use it. Greg has some ideas around an EVM 3.0 that pulls everything together with transpilation that he hasn't started working on yet and is not sure if he will.

[20:14] 4. Stateless client development.

Piper left some comments about some development of a stateless client for sharding, but it is very early. Alexey had a blog post describing stateless clients he may re-approach later.

[21:46] 5. Add ECADD and ECMUL pre-compiles for secp256k1 - [See this blog post for context].

This topic was brought up months ago with mixed commentary. Christian R. says that ECADD and ECMUL were never intended to be used for general purpose cryptography, but rather it was suppose to be used in conjunction with the pairing pre-compiles for a specific curve that is pairing friendly. Christian says that in the past it has been discussed that there must be a very compelling reason for adding a pre-compile to Ethereum. Silur mentioned that the Monero research team is working on a new ring signature (still unnamed) that can be viewed in the Monero repository. The EWASM team may run some tests to compare native running of the pre-compiles vs EWASM. Adding a new pre-compile would only give a constant speed-up or reduction in cost, but if we achieve the same thing in new virtual machine it will give us a constant speed-up for every conceivable routine and allows for building other schemes like Casper and TrueBit. This is easier with Web Assembly because we can use existing C code. For the moment it looks like focusing energy on adding these proposed pre-compiles would not be worth it compared to just waiting for the next VM (likely EWASM) which will allow far more speed-ups across all computational routines.

[37:00] 6. Introduce miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined).

[Note: I tried my best to cover what was discussed here, but I am not an expert in Ethereum transactions. If you find a mistake please point it out to me. Thanks!] Agenda item brought up to get people's opinion on this topic. Currently in Ethereum there are transactions that are stuck in the mempool for a long time because of the way transaction ordering per account is handled. The nonce of a transaction must be greater than the previous mined transactions (or equal if you are trying to replace a transaction). For example you can't process transaction #27 before transaction #26 has been mined. Many of the stuck transactions are dependent on other transactions that pay a much smaller fee, but are not being mined. It seems people inadvertently send an initial transaction with too small of a fee and then more transactions at a higher nonce with a much higher fee that cannot be processed until the first small fee transaction is processed. Alexey wondered if this may pose an attack vector or if we would get a benefit from implementing "child pays for parent" like Bitcoin does. Peter explained even if you define the max amount of gas your transaction could potentially consume, there is no guarantee it will use that much and we won't know until the transaction is processed (the only guarantee is that 21,000 gas will be consumed - a plain ether transfer). The attack vector example would be someone pushing a transaction that truly consumes 3,000,000 gas and attach a transaction fee of 1 wei and then push another TX that claims to consume 3,000,000 gas but with a transaction fee of 1000gwei. From the outside it looks like I can both can be executed for profit from the miner's perspective, but in reality the 2nd transaction will be processed first and the 1st tx will be long running and indirectly punish the miner. Alexey was concerned about the mempool filling up and impact on clients due to the way nonces are handled. Peter clarified that transactions in the mempool in the go ethereum client only maintains the top 4,000 most expensive transactions. If your cheap transaction gets evicted, the expensive transactions you stacked on top of it get evicted as well because they are no longer executable due to the nonce.

[42:21] 7. Creating a relay network of nodes to mitigate issues described here and other transaction propagation issues.

A relay network in general is a group of peers and/or miners who use a peer list to quickly connect to a group of known peers before connecting to (or instead of connecting to) random peers using network discovery. Alexey conjectured that this may create a powerful ring of network players who can share transactions very quickly and hurt the little guys on the outside (hurting the idea of this being a mesh network of peers). Clarifications were made about the issues involving transaction propagation issues with nodes with high transaction throughput such as Infura and Bittrex. Clients suddenly stop pushing transactions or cannot keep up with the blockchain when they are pushing out so many transactions. Hudson will work towards exploring this issue more and connecting the people with the issues with the devs.

[49:45] 8. Fork release management/Constantinople.

Hudson will be working on writing up a starting plan to discuss potential release management issues. BitsBeTripping sent Hudson some good material about project management that he will review and bring to the next meeting. We need to start discussing Constantinople sooner rather than later.

[52:55] 9. Client updates.

10. Other non-agenda items

[1:05:42] Question: Will we see any scaling improvements from Constantinople?

Answer is no because it potentially includes the first steps of the Casper consensus protocol and some account abstraction EIPs, but both of those do not alleviate scaling issues. Sharding would alleviate some of the issues. We are currently mostly bound by database and processing speed due to the database. Short term there are a lot of client improvements that can be accomplished to improve disk I/O, but long term things like sharding will be necessary. The Eth Research site has a lot of interesting threads about sharding including merkle tree formats to be used and ideas around asynchronous accumulators

[1:09:57] Decision process for EIPs?

Needs to be improved. Hudson and others will work on updating EIP #1 and other improvements in Q1. Nick Savers has been added as an EIP editor. Yoichi has been added as an editor. Both are doing a great job.


Alex Beregszaszi (EWASM/Solidity/ethereumJS), Alex Van de Sande (Mist/Ethereum Wallet), Alexey Akhunov (Turbo Geth), Ben Edgington (Consensys/Pegasys), Casey Detrio (Volunteer), Christian Reitwiessner (cpp-ethereum/Solidity), Daniel Ellison (Consensys/LLL), Greg Colvin (EVM), Hudson Jameson (Ethereum Foundation), Hugo de la Cruz (ethereumJS/EWASM), Jake Lang (EWASM), Jared Wasinger (ethereumJS/EWASM), Martin Becze (EWASM), Mikhail Kalinin (Harmony), Paweł Bylica (cpp-ethereum/EWASM), Péter Szilágyi (geth), Silur (ethereumJS / EWASM)
submitted by Souptacular to ethereum [link] [comments]

Did you know that LISK uses Schnorr signature-based Ed25519 scheme which is more secure, much faster, more scalable than secp256k1 which is used by Bitcoin, Ethereum, Stratis

Schnorr signatures have been praised by Bitcoin developers for a while Adam Back admitted it was more secure
And it is much faster (scalable for verifying hundred thousands of transactions per second)
DJB and friends claim that with their ed25519 curve (the "ed" is for Edwards) and careful implementation they can do batch verification of 70,000+ signatures per second on a cheap quad-core Intel Westmere chip, which is now several generations old. Given advances in CPUs over time, it seems likely that in the very near future the cited software will be capable of verifying many hundreds of thousands of signatures per second even if you keep the core count constant. But core counts are not constant - it seems likely that in 10 years or so 24-32 core chips will be standard even on consumer desktops. At that point a million signatures per second or more doesn't sound unreasonable.
Gavin Andresen, the former Bitcoin Chief Scientist want to support it in Bitcoin
Bitcoin developers discussed to include it
However, it is still in wishlist
Ed25519 is used in Tahoe-FS, one of most respected crypto project
LISK is IoT friendly
The good feature of Schnorr signature is that by design it does not require lot of computations on the signer side. Therefore, you can use it even on a computationally weak platform (think of a smart card or RFID), or on a platform with no hardware support for multiple precision arithmetic.
Advantages of Schnorr signatures
According to David Harding, Schnorr signatures can bring many benefits
Smaller multisig transactions
Slightly smaller for all transactions
Plausible deniability for multisig
Plausible deniability of authorized parties using a third-party organizer (which doesn't need to be trusted with private keys), it's possible to prevent signers from knowing whether their private key is part of the set of signing keys.
Theoretical better security properties: Also, the ed25519 page linked above describes several ways it is resistant to side-channel attacks, which can allow hardware wallets to operate safely in less secure environments.
Faster signature verification: it likely takes fewer CPU cycles to verify an ed25519 Schnorr signature than a secp256k1 ECDSA signature.
Multi-crypto multisig: with two (slightly) different cryptosystems to choose from, high-security users can create 2-of-2 multisig pubkey scripts that require both ECDSA and Schnorr signatures, so their bitcoins can't be stolen if only one cryptosystem is broken.
Scalable multisig transactions
The magic of Schnorr signatures is most evident in their ability to aggregate signatures from multiple inputs into a single one to be validated for every individual transactions. The scaling implications of this are obvious: aggregation allows for non-trivial savings in terms of transmission, validation & storage for every peer on the network. The chart below illustrates the historical impact a switch to Schnorr signatures would have had in terms of space savings on the blockchain. (Alex B.) Infamous malleability is non-issue in LISK Provably no inherent signature malleability, while ECDSA has a known malleability, and lacks a proof that no other forms exist. Note that Witness Segregation already makes signature malleability not result in transaction malleability, however.
Bitcoin has malleability bugs
submitted by Corinne1992 to CryptoCurrency [link] [comments]

How to install any QT-Wallet on the Raspberry Pi / Pi3B+

Hello and welcome to my first tutorial. Today I will show you how to install almost any QT-wallet on the RaspberryPi. I hope this tutorial will help you. I use the BankSocietyCoin in this tutorial, you can change it also to your fav. Coin.

Install Raspbian , *Buster produced a lot of failures on my system while compiling Wallets*
(my version: )
Run the following commands:

Change Swap Size of the Rasp:

sudo nano /etc/dphys-swapfile
change to CONF_SWAPSIZE=2048
press: ctrl o Enter and ctrl x
enable the swap file with its new size:
sudo dphys-swapfile setup
sudo dphys-swapfile swapon
Install Required Dependencies:

apt-get update
sudo apt-get install git build-essential libtool autotools-dev autoconf pkg-config libssl-dev libcrypto++-dev libevent-dev libminiupnpc-dev libgmp-dev libboost-all-dev devscripts libdb++-dev libsodium-dev
sudo apt-get install libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler libcrypto++-dev libminiupnpc-dev qt5-default
Install bitcoin PPA files for the compiling process:

cd /etc/apt/sources.list.d/
sudo nano bitcoin.list
paste to following line:
deb-src artful main
press: ctrl o Enter and ctrl x
sudo apt-key adv --keyserver hkp:// --recv C70EF1F0305A1ADB9986DBD8D46F45428842CE5E
sudo apt-get update
Install working libssl:

cd && sudo apt-get remove libssl-dev
sudo nano /etc/apt/sources.list
change stretch to jessie
press: ctrl o Enter and ctrl x
sudo apt-get update
sudo apt-get install libssl-dev
sudo apt-mark hold libssl-dev
sudo apt-mark hold libssl1.0.0
sudo nano /etc/apt/sources.list
Change jessie" back to stretch
press: ctrl o Enter and ctrl x
sudo apt-get update

Compile and Install BerkeleyDB 4.8.30 :

sudo tar -xzvf db-4.8.30.NC.tar.gz
cd db-4.8.30.NC/build_unix
sudo ../dist/configure --enable-cxx
sudo make
sudo make install
export CPATH="/uslocal/BerkeleyDB.4.8/include"
export LIBRARY_PATH="/uslocal/BerkeleyDB.4.8/lib"

The wallet:

(my way) mkdir wallets , cd wallets
git clone
cd BankSocietyCoin
chmod 755 src/leveldb/build_detect_platform
chmod 755 src/secp256k1/
cd src/
make -f makefile.unix
* for qt wallet*
cd ..
edit society.conf in .society

Have fun!
for a Beer - Donations ;)
BTC - 1HpGF4wMzztpJ4KT4o2ySFvnLJ4gCoYaV5
LTC - LS22MgY9G4KbaKhkR5dFi995MbcQhuyDXW
ETH - 0x6b5EdC3e58Fd84a40aa942964690adA91C398075
TRX - TKBpktt5QQ9WV57QjonQrGr1vmKLCVQBL6

13.07.2019 DennisHilk

if error (makefile.unix:200: obj/rpcclient.o] appears)
[This first step is necessary because you will get linking errors if you don't remove the old Boost library]
sudo apt remove --purge --auto-remove libboost-dev libboost-thread-dev libboost-system-dev libboost-atomic-dev libboost-regex-dev libboost-chrono-dev
mkdir boost
cd boost
tar xfz boost_1_64_0.tar.gz (can take rly long, dont worry)
cd boost_1_64_0/
./b2 stage threading=multi link=static --with-thread --with-system
sudo ./b2 install threading=multi link=static --with-thread --with-system
cd ../../
nano .bash_profile
export LIBS="-L/home/YOURS/boost/boost_1_64_0/stage/lib"
export CPPFLAGS="-I/home/YOURS/boost/boost_1_64_0"
cd society root
make clean
cd src
sudo make -f makefile.unix

(if bignum error)
sudo apt-get install libgmp-dev
or delete opensll and reinstall as above.
submitted by dennishilk to u/dennishilk [link] [comments]

Nutz and Boltz for computing Tezos ICO private keys for Betanet?

I'm tired of the lip service posting concerning some mythical software wallet that will convert one's ICO seed words, email address and account password into private Tezzie keys. There should be nothing mystical about the Tezos ICO key synthesis process. Can someone kindly point me to a few test vectors and details so I can independently code something that will make the conversion to double check results from other wallets as they emerge? I plan on using open source libbitcoin secp256k1, monero ed25519, and Keccak tools and code to make such a conversion. Who knows, I might even add pertinent details to update this important libbitcoin Wiki Table and provide a complementary example for Tezos.
submitted by greatskaht to tezos [link] [comments]

Can someone make or point me to the most basic of address generators?

I wish to have a script, code, or mathematical representation of the complete process whereas I may enter in some random private keys, detect invalid keys, then convert to public address. I have looked at a few different versions, but I'm trying to learn from the code and there are too many extra features for me to sift through. I am looking for the most basic of paper wallet generators so that I may study it and learn the math.
submitted by Lawsky to Bitcoin [link] [comments]


TERA is an open source and collaborative project. It means everyone can view and eventually modify its source code for hehis own needs. And it also means anyone is welcome to integrate its working community. The Tera community works to develop, deploy and maintain Tera nodes and decentralized applications that are part of the TERA Network.
The TERA technology serves the cryptocurrency concepts, trying to design a modern coins and contracts blockchain application : fast block generation, high transaction throughput and user-friendly application. It was officialy launched on 30th of June 2018 on the bitcointalk forum.
[Yuriy Ivanov](mailto:[email protected]) is the founder and core developer of the project. The Tera community is more familiar with the alias « vtools ».


In the aim to make this crypto currency project more friendly to end-users, some interesting innovations have been implemented in regards to the first generation of crpyto currency applications. The bitcoin and its thousands of child or fork, required a good level of IT skills in order to manage all the application chain from its own : from miners and its hardware, through stratum servers, proxies, to blockchain nodes. The Tera project intend to go one step further regarding crypto currency features integration into a single application : once installed, an efficient web application is available on localhost on port 8080. Then, any web browser supporting javascript may be able to access this application and to operate fully the Tera node.



The mining activity consist in calling a mathematical procedure we can’t predict the result before we run it. But we intend to obtain a very specific result, which usually consist in a certain number of 0 as the first chars before any random answer. If we found the nonce (a random object) combined with the transaction data and the coin algorithm that produce such result, we’ll have solve a transaction block and we’ll get a reward for that. Thanks to this work, the transaction listed in the block will be added to the blockchain and anyone will be able to check our work. That’s the concept of ‘proof of work’ allowing anyone to replay the mathematical procedure with the nonce discovered by the node that solved the block and to confirm block inclusion into the blockchain.


The Tera project is young. It will have to face the same problems is facing today the Bitcoin platform :
Any Crypto Currency Project with the goal its money and contracts to be used as any other historical money or service contract has to consider its political and ethical usage. Processes have to be imagined, designed and implemented in order to be able to fight against extortion, corruption and illegal activities threating crypto-currency development.



wallet, accounts, payments, mining, node settings and utilities, blockchain explorer and utilities…


d-app : forum, stock exchange, payment plugins for third party platform, …


Tera is entirely written in Java) over the NodeJS library as functional layer in order to take advantages of a robust and high level library designed to allow large and effective network node management.
The miner part is imported from an external repository and is written in C in order to get the best performances for this module.
Tera is actually officially supported on Linux and Windows.
If you start mining Tera thanks to this article, you can add my account 188131 as advisor to yours. On simple demand I’ll refund you half of the extra coins generated for advisors when you’ll solve blocks (@freddy#8516 on discord).


Mining Tera has one major design constraint : you need one public IP per Tera node or miner. Yet, you can easily mine it on a computer desktop at home. The mining algorithm has been designed in order to be GPU resistant. In order to mine Tera coin you’ll need a multi-core processor (2 minimum) and some RAM, between 1 and 4GB per process that will mine. The mining reward level depends of the « power » used to solve a block (Top Tera Miners).


There is two main cost centers in order to mine a crypto currency :
  1. the cost of the hardware and the energy required to make a huge amount of mathematical operations connected to the blockchain network through the Internet,
  2. the human cost in order to deploy, maintain and keep running miners and blockchain nodes.
As the speculation actually drives the value of crypto currencies, it is not possible to answer if the mining activity is profitable or not. Moreover, hardware, energy and human costs are not the same around the globe. To appreciate if mining a crypto currency is profitable we should take all indirect costs : nature cost (for hardware and energy production), human cost (coins and contracts usage, social rights of blockchain workers).

Original: https://freddy.linuxtribe.frecherche-et-developpement/blockchain-cryptocurrency-mining/tera-crypto-currency-project/
Author: Freddy Frouin, [email protected].
submitted by Terafoundation to u/Terafoundation [link] [comments]

Zcoin Dev Update 14 Feb 2019

Zcoin Dev Update 14 Feb 2019
Zcoin Electrum Light Wallet
  • Electrum light wallet rebase to 3.3.3 is released with much better performance and stability.
  • AMD miner, sgminer fixed crashing issues and increased speed for Vega
  • Made a new release.
  • To work on optimizing cpuminer
  • Discussion on algorithm to automatically determine which mints to use to meet a private spend request.
    • Originally decided to always pick the mints that are largest so that the private spend request could be met in the smallest amount of spends. However leads to many smaller mints.
    • Better approach is for the algorithm to calculate the least amount of Zerocoin transactions needed to meet a private spend request that also takes into accounts the re-minting of change. This is because mints are future spends.
  • Testnet for Sigma to be started soon
  • Some issues with secp256k1 library resolved
  • Plan to release Sigma with core features for testing end of February
  • Academic paper being rearranged to clearly separate
    • scheme
    • claimed security properties
    • proofs of the claimed properties.
  • This will assist in third party verification of claims
  • Ongoing discussion on whether to allow shielded to shielded transactions which sacrifices element of supply auditability. Leaning towards launching Lelantus without having this feature first.
  • Exploring alternative ways to cryptographically prove ‘shielded’ supply so that forging of zk proofs alone won’t be enough to cheat system.
  • Batching of bullet proofs work is almost complete and will have working code for this portion by end of week.
Core Upgrade (Bitcoin Core 0.17)
  • Code to be pushed to public repo in a few days and open for testing
  • Incomplete shutdown issue located
  • Issue where non-existent mints are showing been fixed
  • Settings page to include slider to adjust how many percent of coins should be kept as mints after startup.
  • Found weightage issue with Zerocoin spends where it is weighted 4x the size leading to only 3 spends fitting within a transaction.
  • New release by this weekend.
  • Hierarchical deterministic (HD) minting almost working simplifying wallet backup.
submitted by Muggles_XZC to zcoin [link] [comments]

Bitcoin Tutorial #13 ft. Python - Schlüssel generieren Introduction to Bitcoin with Yours Bitcoin, Lecture 3: Elliptic Curves Bitcoin Tutorial #24 - Script - Bitcoins Programmiersprache Why Isn’t BCH Way More Popular on the Dark Web Bitcoin Tutorial #12 - Der SECP256K1-Standard für Schlüssel

How I Hacked a Bitcoin Wallet: A Step By Step Guide. August 31, 2019 - by coineradmin. This is an old vulnerability but still is around. Not many bitcoin companies/wallets will re-use values these days when signing transactions, but people who are creating new copies of old coins and wallets generally don’t know about this vulnerability. While researching this, I discovered that a lot of ... Der Bereich der gültigen privaten Schlüssel wird vom secp256k1-ECDSA-Standard bestimmt, der von Bitcoin verwendet wird. Basis 58 WIf . Wenn wir jedoch private Schlüssel in Bitcoin darstellen, benutzen wir ein kürzeres Format, das als Brieftaschen-Importformat bekannt ist und einige Vorteile bietet. Das Wallet-Importformat ist kürzer und ... secp256k1 was almost never used before Bitcoin became popular, but it is now gaining in popularity due to its several nice properties. Most commonly-used curves have a random structure, but secp256k1 was constructed in a special non-random way which allows for especially efficient computation. As a result, it is often more than 30% faster than other curves if the implementation is sufficiently ... Libsecp256k1 is used to preform cryptographic operations on the secp256k1 curve. This is the curve that bitcoin uses. There is a signficant speedup when using this library compared to java crypto libraries like bouncy castle.. In bitcoin-s, we support native binaries for libsecp256k1. linux 32 bit; linux 64 bit The integer range of valid private keys is governed by the secp256k1 ECDSA standard used by Bitcoin. Site just generate a range of these integers in sequence, divide into pages and show on each page. Nobody store it and save it to database, because it should be biggest base on the world. You can find Private key in WIF (Wallet Import/Export Format) and compressed key. Bitcoin addresses in ...

[index] [25977] [41560] [21271] [11995] [2684] [7955] [8928] [18158] [28937] [20868]

Bitcoin Tutorial #13 ft. Python - Schlüssel generieren

In diesem Tutorial behandeln wir den Schlüsselstandard von Bitcoin. Früherer Zugang zu Tutorials, Abstimmungen, Live-Events und Downloads https:/... underlying MuSig with secp256k1-zkp https: ... Guarda y transfiere tus bitcoin más seguros con Samourai Wallet offline y Sentinel. - Duration: 22:13. BTC Andres 691 views. 22:13. Mix Play all Mix ... The third lecture covers elliptic curves and in particular secp256k1, the curve used by bitcoin. This curve is used for public keys and ECDSA, the digital signature algorithm of bitcoin. Wie du Bitcoins & Kryptowährungen richtig sichern kannst - Mein Wallet System 👊 - Duration: 6 ... Bitcoin Tutorial #12 - Der SECP256K1-Standard für Schlüssel - Duration: 6:46. The Morpheus ... Lots of wallets support it and Bitcoin Cash already has privacy tools today. In fact, while I’m sitting here, talking to you, my wallet is busy shuffling 56 additional Bitcoin Cash.”Although ...