Bitcoin Private Key - BitcoinWiki

ECDSA In Bitcoin

Digital signatures are considered the foundation of online sovereignty. The advent of public-key cryptography in 1976 paved the way for the creation of a global communications tool – the Internet, and a completely new form of money – Bitcoin. Although the fundamental properties of public-key cryptography have not changed much since then, dozens of different open-source digital signature schemes are now available to cryptographers.

How ECDSA was incorporated into Bitcoin

When Satoshi Nakamoto, a mystical founder of the first crypto, started working on Bitcoin, one of the key points was to select the signature schemes for an open and public financial system. The requirements were clear. An algorithm should have been widely used, understandable, safe enough, easy, and, what is more important, open-sourced.
Of all the options available at that time, he chose the one that met these criteria: Elliptic Curve Digital Signature Algorithm, or ECDSA.
At that time, native support for ECDSA was provided in OpenSSL, an open set of encryption tools developed by experienced cipher banks in order to increase the confidentiality of online communications. Compared to other popular schemes, ECDSA had such advantages as:
These are extremely useful features for digital money. At the same time, it provides a proportional level of security: for example, a 256-bit ECDSA key has the same level of security as a 3072-bit RSA key (Rivest, Shamir и Adleman) with a significantly smaller key size.

Basic principles of ECDSA

ECDSA is a process that uses elliptic curves and finite fields to “sign” data in such a way that third parties can easily verify the authenticity of the signature, but the signer himself reserves the exclusive opportunity to create signatures. In the case of Bitcoin, the “data” that is signed is a transaction that transfers ownership of bitcoins.
ECDSA has two separate procedures for signing and verifying. Each procedure is an algorithm consisting of several arithmetic operations. The signature algorithm uses the private key, and the verification algorithm uses only the public key.
To use ECDSA, such protocol as Bitcoin must fix a set of parameters for the elliptic curve and its finite field, so that all users of the protocol know and apply these parameters. Otherwise, everyone will solve their own equations, which will not converge with each other, and they will never agree on anything.
For all these parameters, Bitcoin uses very, very large (well, awesomely incredibly huge) numbers. It is important. In fact, all practical applications of ECDSA use huge numbers. After all, the security of this algorithm relies on the fact that these values are too large to pick up a key with a simple brute force. The 384-bit ECDSA key is considered safe enough for the NSA's most secretive government service (USA).

Replacement of ECDSA

Thanks to the hard work done by Peter Wuille (a famous cryptography specialist) and his colleagues on an improved elliptical curve called secp256k1, Bitcoin's ECDSA has become even faster and more efficient. However, ECDSA still has some shortcomings, which can serve as a sufficient basis for its complete replacement. After several years of research and experimentation, a new signature scheme was established to increase the confidentiality and efficiency of Bitcoin transactions: Schnorr's digital signature scheme.
Schnorr's signature takes the process of using “keys” to a new level. It takes only 64 bytes when it gets into the block, which reduces the space occupied by transactions by 4%. Since transactions with the Schnorr signature are the same size, this makes it possible to pre-calculate the total size of the part of the block that contains such signatures. A preliminary calculation of the block size is the key to its safe increase in the future.
Keep up with the news of the crypto world at CoinJoy.io Follow us on Twitter and Medium. Subscribe to our YouTube channel. Join our Telegram channel. For any inquiries mail us at [[email protected]](mailto:[email protected]).
submitted by CoinjoyAssistant to btc [link] [comments]

ECDSA In Bitcoin

Digital signatures are considered the foundation of online sovereignty. The advent of public-key cryptography in 1976 paved the way for the creation of a global communications tool – the Internet, and a completely new form of money – Bitcoin. Although the fundamental properties of public-key cryptography have not changed much since then, dozens of different open-source digital signature schemes are now available to cryptographers.

How ECDSA was incorporated into Bitcoin

When Satoshi Nakamoto, a mystical founder of the first crypto, started working on Bitcoin, one of the key points was to select the signature schemes for an open and public financial system. The requirements were clear. An algorithm should have been widely used, understandable, safe enough, easy, and, what is more important, open-sourced.
Of all the options available at that time, he chose the one that met these criteria: Elliptic Curve Digital Signature Algorithm, or ECDSA.
At that time, native support for ECDSA was provided in OpenSSL, an open set of encryption tools developed by experienced cipher banks in order to increase the confidentiality of online communications. Compared to other popular schemes, ECDSA had such advantages as:
These are extremely useful features for digital money. At the same time, it provides a proportional level of security: for example, a 256-bit ECDSA key has the same level of security as a 3072-bit RSA key (Rivest, Shamir и Adleman) with a significantly smaller key size.

Basic principles of ECDSA

ECDSA is a process that uses elliptic curves and finite fields to “sign” data in such a way that third parties can easily verify the authenticity of the signature, but the signer himself reserves the exclusive opportunity to create signatures. In the case of Bitcoin, the “data” that is signed is a transaction that transfers ownership of bitcoins.
ECDSA has two separate procedures for signing and verifying. Each procedure is an algorithm consisting of several arithmetic operations. The signature algorithm uses the private key, and the verification algorithm uses only the public key.
To use ECDSA, such protocol as Bitcoin must fix a set of parameters for the elliptic curve and its finite field, so that all users of the protocol know and apply these parameters. Otherwise, everyone will solve their own equations, which will not converge with each other, and they will never agree on anything.
For all these parameters, Bitcoin uses very, very large (well, awesomely incredibly huge) numbers. It is important. In fact, all practical applications of ECDSA use huge numbers. After all, the security of this algorithm relies on the fact that these values are too large to pick up a key with a simple brute force. The 384-bit ECDSA key is considered safe enough for the NSA's most secretive government service (USA).

Replacement of ECDSA

Thanks to the hard work done by Peter Wuille (a famous cryptography specialist) and his colleagues on an improved elliptical curve called secp256k1, Bitcoin's ECDSA has become even faster and more efficient. However, ECDSA still has some shortcomings, which can serve as a sufficient basis for its complete replacement. After several years of research and experimentation, a new signature scheme was established to increase the confidentiality and efficiency of Bitcoin transactions: Schnorr's digital signature scheme.
Schnorr's signature takes the process of using “keys” to a new level. It takes only 64 bytes when it gets into the block, which reduces the space occupied by transactions by 4%. Since transactions with the Schnorr signature are the same size, this makes it possible to pre-calculate the total size of the part of the block that contains such signatures. A preliminary calculation of the block size is the key to its safe increase in the future.
Keep up with the news of the crypto world at CoinJoy.io Follow us on Twitter and Medium. Subscribe to our YouTube channel. Join our Telegram channel. For any inquiries mail us at [[email protected]](mailto:[email protected]).
submitted by CoinjoyAssistant to Bitcoin [link] [comments]

Can someone explain me the math to create and verify digital signature ?

submitted by amadeus82 to litecoin [link] [comments]

In response to ProofOfResearch's misleading article on NEO.

In response to ProofOfResearch's misleading article on NEO.
Yesterday, I was made aware of an article published by ProofOfResearch almost entirely based on a Reddit post that I had written a few months ago. About a month ago I was contacted by Randomshortdude (supposedly ProofOfResearch himself) asking for a permission to use the excerpts from the aforementioned post in his write-up about NEO. As an avid proponent of inclusivity and transparency, I gave a permission to use the contents of my post (the screenshots of the entire conversation will be added below), providing him with links to the Github repos and updating him on the fixes and improvements that have happened since the post had been published. Unknowingly, I continued to work on my projects while my post was being molded into a foundation for an entirely misleading and unfathomably unscientific article.
This post is going to consist of a list of excerpts from the article and the corresponding refutal for each of the listed excerpts.
"This is a semantic issue (example: $BTC having a 1 MB block size + 10 min block time limits TPS; no way around that) meaning that this is immutable"
Bitcoin doesn't have a 10 minute block time limit coded into the platform. The 10 minute average block production time is obtained via a difficulty adjustment formula that readjusts the difficulty of the underlying HashCash PoW algorithm every 2015 blocks (not 2016 due to a bug that was never fixed) based on the average block production time of the previous 2015 blocks.
"I’m not sure it’s even possible to change the digital signature of a protocol without a major hard fork, and there isn’t an alternative digital signature (that I think of), that would make this any more secure."
This excerpt is written in a reference to Point 2 of my Reddit post that criticizes the use of multisigs as a proof of the fact that a quorum (at least 2f + 1) replicas had signed the block hash. The use of multisig instead of signature batching via Schnorr's signatures doesn't affect the security of the nodes or the cryptographic standards used, however, the security of the network as a whole can be compromised due to the decreased number of full/light nodes operating increasing the likelihood of a spam attack being able to degrade the performance of the platform. Apart from that, a digital signature algorithm of the platform can be easily changed by adjusting the versioning of the block and transaction structures.
"Therefore, the consensus algo itself would need to be changed to amend this issue."
The consensus protocol works independently from the cryptographic standards of the platform, so a switch to a different elliptic curve or digital signature algorithm will have zero impact on the consensus algorithm.
"This, in itself, might be what stops $NEO from ever being able to truly scale."
While digital signature algorithms can vary in signing and verification speeds, the difference in the performance of the most popular signature schemes is small enough (except for BLS) to be considered to have a negligible impact on the efficiency of the consensus. As long the nodes are running on an efficient implementation, average network throughput is going continue to be the main bottleneck of the platform.
"Digital signatures are somewhat complex, but not incomprehensible if you really take the time to sit down and understand it. Once again though, it’s going to rely on an understanding of blockchain tech as well to know how this impacts the signing feature of a TX itself as well as pub key creation"
Digital signature algorithms play no role in public key creation as a public key is created simply by multiplying a 256-bit entropy (private key) by a generator (G).


A screenshot of a tweet used in the article.
Baffling. ed25519 DSA does not impact the efficiency of BFT and "blockchain" (whatever the hell that means in this context) as a result. Please also note that NEO does not use ed25519. NEO uses secp256r1 (as opposed to secp256k1 used by Bitcoin, which is a Koblitz curve) which is a NIST-recommended elliptic curve.
"Regular PoW algos are already designed to be Byzantine fault-tolerant already"
While being technically correct, the author dismisses the fact that BFT algorithms offer Byzantine fault-tolerance under rigid mathematical assumptions, in contrast to PoW algorithms which offer Byzantine fault-tolerance under probabilistic assumptions.
"Byzantine Fault Tolerance is not an issue though. It’s actually really useful but for private blockchains."
A common misconception about the use of BFT algorithms in "public" (the author meant permissioned/permission-less) blockchains. BFT algorithms are only required to retain the permissioned status during the agreement phase (meaning that the new candidates will have to wait until the next consensus round to be able to participate in the consensus) and can have a round robin algorithm implemented to select the next pool of validators.
"Of course, in a decentralized protocol — something like that is very hard to achieve."
The research paper quoted in the article examines the efficiency of Castro and Liskov's PBFT (Practical Byzantine Fault Tolerance) algorithm which is dissimilar from dBFT because PBFT doesn't require a primary change after every consensus round, which is impacts the performance in a decentralized network.
“At the other extreme, Hyperledger uses the classic PBFT protocol, which is communication bound: O(N²) where N is the number of nodes. PBFT can tolerate fewer than N/3 failures, and works in three phases in which nodes broadcast messages to each other. First, the pre-prepare phase selects a leader which chooses a value to commit. Next, the prepare phase broadcasts the value to be validated. Finally, the commit phase waits for more than two third of the nodes to confirm before announcing that the value is committed. PBFT has been shown to achieve liveness and safety properties in a partially asynchronous model [11], thus, unlike PoW, once the block is appended it is confirmed immediately. It can tolerate more failures than PoW (which is vulnerable to 25% attacks [26]). However, PBFT assumes that node identities are known, therefore it can only work in the permissioned settings. Additionally, the protocol is unlikely to be able to scale to the network size of Ethereum beacuse of its communication overhead.”
This statement will require a separate post to examine the real-world "permission-lessness" of PoW chains.
"NEO codebase is virtually abandoned."
neo-sharp? neo-go?
"This is purportedly in favor of $NEO 3.0, but there’s no GitHub for $NEO 3.0 (at least not any that I’ve found)"
https://github.com/neo-project/neo/pull/288.
"The idea of it being able to handle 1000 TPS has been thoroughly debunked and it is virtually impossible (probably entirely impossible) for $NEO to create a public blockchain based on DBFT (essentially POS+BFT semantically), that keeps the same encryption signatures (which are probably the only ones that will reliably serve the purpose of crypto where collision resistance must be all but a guarantee)."
dBFT cannot be equated to PoS + BFT as none of those are delegate-centered protocols. How was 1000 TPS thoroughly debunked? With the neo-sharp implementation and Akka being launched, I don't see a reason for dBFT to not be able to surpass 1,000 TPS during peak loads (not during sustained loads though). The excerpt about the collision resistance of "encryption signatures" (?) makes no sense to me.
Here are the promised screenshots of our conversation:
Screenshot 1

Screenshot 2

Screenshot 3
P.S. It is sad to see the so-called "researchers" attracting a mass following despite being clueless about the technology they are trying to review.

submitted by toghrulmaharramov to NEO [link] [comments]

How in Bitcoin to generate a public key from a private key manually. Step by step.

Done. Thanks, dmar198 !
__________________________________
How to generate a public key from a private key (EQUAL TO 1) manually (i.e. without coding in python or the like).
Step by step, ONLY using online converters, sites like https://www.rapidtables.com/convert/numbebinary-to-decimal.html or http://tomeko.net/online_tools/hex_to_file.php?lang=en )
___________________________
This question has already been blocked as an off-topic one and marked as "altcoin" category. WHY? It's about Bitcoin. Are the admins incompetent?
___________________________
Of course I have read the theory (wiki, “double and add” algorithm, Elliptic Curve secp256k1 and so on ). It does not help actually. Only on this reason I made this post.
I have a specific question ! -- the SIMPLEST CASE, private key =1. Without common words, just step by step instruction.
Please make it clear finally.
submitted by andrrpetr to Bitcoin [link] [comments]

I would like to share with you my current set of beliefs regarding Bitcoin.

I would like to share with you my current set of beliefs regarding Bitcoin. It’s up to you to believe it, take it at face value, refute it or discuss it below.
submitted by wisequote to btc [link] [comments]

How the core developers are working to further scale Bitcoin.

Following the implementation of Segwit, it's time to talk about Schnorr signatures and how they are going to aid in scaling Bitcoin. Segwit works by altering the composition of Bitcoin blocks. It moves the signature data to another part of the block, hence the name "Segregated Witness". Now that the signature data has been reorganized, Schnorr signatures can be applied to them, where they are signed at once rather than individually. According to coindesk, "Under the ECDSA scheme, each piece of a bitcoin transaction is signed individually, while with Schnorr signatures, all of this data can be signed once"[3].
What are Schnorr Signatures?
How is this going to change/improve Bitcoin?
How are these changes going to implemented?
How is the work coming along?
The meat and potatoes of the matter
The verification equation:
sG = R - H(R || P1 || C || m)P1 - H(R || P2 || C || m)P2 
The signature equation:
R = H(R || P1 || C || m)P1 + … + s*G 
Summations are fundamentally faster to compute on computers than multiplication. This is because each multiplication operation is the sum of the terms where the n is the number of terms. So 5 * 7 = 5 + 5 + 5 + 5 + 5 + 5 + 5 (or vice versa for 7). computers only have the capacity to perform two operations - addition and bitwise shifts. Algorithms that maximize the use of these operations are comparitively faster than algorithms that use multiplication, division, or modulus even when the time complexity of the two problems are equal. This is why "For 100000 keys, the speedup is approximately 8x"[1].
"And aggregation shrinks the transaction sizes by the amounts of inputs they have. In our paper, we went and ran numbers on the shrinkage based on existing transaction patterns, there was a 28% reduction based on the existing history"[1].
This is VERY SIGNIFICANT. The "aggregation shrinks the transaction sizes by the amounts of inputs they have"[1]. This means the "more inputs you have, the more you gain because you add a shared cost of paying for one signature"[1].
"Validation time regardless of how complex your script is. You just prove that the script existed, it is valid, and the hash. But anything that further complicates the structure of transaction. This helps fungibility, privacy, and bandwidth"[1].
What can you do to help?
Sources
[1] http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-06-signature-aggregation/
[2] https://github.com/bitcoin-core/secp256k1
[3] https://www.coindesk.com/just-segwit-bitcoin-core-already-working-new-scaling-upgrade/
Edit: Finally got formatting to work.
submitted by RussianHacker1011101 to Bitcoin [link] [comments]

Addresses for different coins derived from the same Private Key

As I know, Litecoin uses the same way of key pair creation as Bitcoin (with secp256k1). The only difference between their addresses is about prefix (starting with different char). If so, is that possible to generate two kind of cryptocurrency addresses with the same private key?
submitted by junzhli to litecoin [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
https://bitcointalk.org/index.php?topic=511074.msg5727641#msg5727641
And it is much faster (scalable for verifying hundred thousands of transactions per second)
https://bitcointalk.org/index.php?topic=103172.0
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
https://www.reddit.com/Bitcoin/comments/2jw5pm/im_gavin_andresen_chief_scientist_at_the_bitcoin/clfp3xj/
Bitcoin developers discussed to include it https://github.com/bitcoin-core/secp256k1/pull/212
However, it is still in wishlist https://en.bitcoin.it/wiki/Softfork_wishlist
Ed25519 is used in Tahoe-FS, one of most respected crypto project https://moderncrypto.org/mail-archive/curves/2014/000069.html
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.
https://bitcoin.stackexchange.com/questions/34288/what-are-the-implications-of-schnorr-signatures
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. https://www.elementsproject.org/elements/schnorr-signatures/
Bitcoin has malleability bugs
submitted by Corinne1992 to CryptoCurrency [link] [comments]

TERA CRYPTO CURRENCY PROJECT

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 ».

USER FRIENDLY APPLICATION

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.

MINING A CRYPTO CURRENCY

MINING CONCEPT

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.

POLITICAL AND ETHICAL CONSIDERATIONS

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.

FAST BLOCK GENERATION AND HIGH THROUGHPUT

CLASSIC CRYPTO CURRENCY FEATURES

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

DECENTRALIZED APP CATALOGUE

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

TECHNOLOGY DEPENDENCIES

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

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).

COST AND USAGE CONSIDERATIONS

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]

More technical/newbie posts, less memes, please

I'm lurking litecoin, bitcoin and similar subreddits for months now, and noticed they are now FILLED with unimportant, secondary stuff like memes, price speculations etc. The technology behind the actual thing is put aside.
I'm really excited about the crypto space and as a person with technical, but not cryptography background I'm in search of information. This subreddit is often cited as a good source of it, and you can actually find it at some point, but it is buried beneath a fuckton of unimportant, yet still massively upvoted stuff.
Why I think price speculation posts are unnecessary on this sub? Because 1. Three is litecoinmarkets for that 2. It's always the same posts all over again: when price is going up -> hype posts, brag posts, memes; when price is going down -> "just hodl" posts, "it's ok, we're still up X% this month" posts, "buy the dip" posts 3. Don't you think this platform can do better?
But really, if you believe this technology is revolutionary, that it will disrupt current models in financial and many other sectors, that IT IS THE FUTURE, that it is better than fiat money, why focus so much on the amount of that same fiat money which gets you 1 LTC/BTC? Why the memes, why don't we try to provide a platform that will help it's adoption by providing a constructive, informative environment?
The current situation is mostly hype, jumping-on-the-bandwagon, get-rich-quick investors. Though the growing investor number helps mainstream adoption and getting attention from the big players, not-enough-educated community isn't sustainable long term.
My suggestions on the types of posts which I would love to see upvoted and created more:
a) Technical background discussions. I would love to see more crypto experts discussing the technical issues litecoin currently faces, possible solutions and their respective arguments, already implemented solutions and why they were chosen. Things like why the secp256k1 elliptic curve, and not some other curve, how the private key -> public key conversion really works, how exactly nodes emit the transaction to the whole network, pros and cons of on-chain and off-chain scaling, lightning network, who are our core developers, stuff like that.
As we want our cryptocurrency to be a trustless solution, we need to share the information about the intricates of the system so that less people would just follow the system blindly.
Sure, bitcoin's official wiki is a nice resource as litecoin is largely based off of bitcoin, but it isn't a place for discussion and up-to-date litecoin/bitcoin differences are poorly documented (litecoin.info is down, forum.litecoin.net is down, litecointalk.io is down).
b) Newbie tips and tricks. A lot of newbies tap in the dark. They need services that are trusted and have a stable user base. They need to know what to expect from this whole journey, especially what are the possible downsides. They need tricks like Coinbase to GDAX migration for lower fees. And they shouldn't have to dig through the meme posts to find them.
c) Litecoin competitors. Who are we competing with? What do we do better? What can we do betterer :) ? What are our limitations, and what litecoin IS NOT?
TL;DR This platform has a great unused potential to help litecoin adoption and progress, yet somehow the unimportant stuff gets to the top. We can do better. Let's start now!
submitted by crodeer to litecoin [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 https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings#7-bitcoin-btc-bip-3944-technology-examples example for Tezos.
submitted by greatskaht to tezos [link] [comments]

Encrypt/Decrypt Message tool in Electron Cash

Encrypt/Decrypt Message tool in Electron Cash
Hi all, I have a question about the Encrypt/Decrypt Message tool in Electron Cash
I knew that I can use a public key to encrypt some plain text and decrypt with the corresponding private key

For example,
Public key: 03c8803b937bf4970fdcec5f43295c3adf4731aaa9287bd58612089480c096e8bd
message: hello-world-123
With the tool, I got the encrtyped text QklFMQKWrqTZYtpihiXAC/0HcPgZMlqoWxy3aREvX+jwKyAmMy93Y4uwz0bIDgQAu9A8RTv2SRy45mQOM5ryl7HiMr1NjVNNGAdKsv0+sMAq3IqV2g==
https://preview.redd.it/d19n3ff9yu421.png?width=1220&format=png&auto=webp&s=94e54f6f13a94c9fd333b87e7d8ef3c282b06ed0
When I click the "Encrypt" button again, I got a brand new encrypted text QklFMQMA0EA3pYj7FD1+TPh0qqUb6QmO6fr+qs58jvrBWND9hCA7EzQr68TpgBnLrq2Oj0n00YSYOdFnMxa52pve3JKDtsxEuLTL1+/ck2MDNcFp/g==
https://preview.redd.it/qyveey4qyu421.png?width=1220&format=png&auto=webp&s=e651d23357c1468576a962be46828517e65afc0a
This happens again and again, and I can decrypt all these different encrypted texts...

I knew that, Bitcoin and Bitcoin Cash
- use ECC, to be more specific, the secp256k1 curve, to generate public and private key pairs
- use ECDSA, aka Elliptic Curve Digital Signature Algorithm, to sign and verify messages
- did some google, the algorithm used in encrypt/decrypt text, has a name ECIES
Am I right?

For the encrypt and decrypt part, why the encrypted text changes every time...? What on earth happens inside this operation?

I also found a GitHub repository about the ECIES, it's from bitpay
https://github.com/bitpay/bitcore-ecies

But I am quite confused with its example
https://bitcore.io/api/ecies/
https://preview.redd.it/s3eobfp20v421.png?width=1514&format=png&auto=webp&s=3988dfdf00bae529e49aca36cd09adb22215326f
When we encrypt data, we should not need anyone's private keys, right?
If I wanna implement the encrypt/decrypt part, is there any libraries that I can use? Any recommendations?

Sorry to bother, but quite desire to know the truth.
Does anyone has an knowledge on this...? Thanks very much for helping and teaching me
submitted by aaron67_cc to electroncash [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
https://bitcointalk.org/index.php?topic=511074.msg5727641#msg5727641
And it is much faster (scalable for verifying hundred thousands of transactions per second)
https://bitcointalk.org/index.php?topic=103172.0
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 https://www.reddit.com/Bitcoin/comments/2jw5pm/im_gavin_andresen_chief_scientist_at_the_bitcoin/clfp3xj/
Bitcoin developers discussed to include it https://github.com/bitcoin-core/secp256k1/pull/212
However, it is still in wishlist https://en.bitcoin.it/wiki/Softfork_wishlist
Ed25519 is used in Tahoe-FS, one of most respected crypto project https://moderncrypto.org/mail-archive/curves/2014/000069.html
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
https://bitcoin.stackexchange.com/questions/34288/what-are-the-implications-of-schnorr-signatures
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. https://www.elementsproject.org/elements/schnorr-signatures/
Bitcoin has malleability bugs
submitted by pcdinh to Lisk [link] [comments]

Pentesterlab. ECDSA challenge

Hi there,

I am struggling with Pentesterlab challenge: https://pentesterlab.com/exercises/ecdsa

I'm wondering who can give some lights on how to resolve some steps in this challenge. You can read about similar challenge there - https://ropnroll.co.uk/2017/05/breaking-ecdsa/
I suppose I have problems with extracting (r,s) from ESDCA (SECP256k1) signature (here details - https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)

I even try to brute-force all possible (r,s) values but no luck. Every time I receive error 500.

def recover_key(c1, sig1, c2, sig2, r_len, s_len): n = SECP256k1.order cookies = {} for s_idx in range(s_len, s_len + 2): for r_idx in range(r_len, r_len + 2): s1 = string_to_number(sig1[0 - s_idx:]) s2 = string_to_number(sig2[0 - s_idx:]) # https://bitcoin.stackexchange.com/questions/58853/how-do-you-figure-out-the-r-and-s-out-of-a-signature-using-python r1 = string_to_number(sig1[0 - (s_idx + r_idx + 2):0 - (s_idx)]) r2 = string_to_number(sig2[0 - (s_idx + r_idx + 2):0 - (s_idx)]) z1 = string_to_number(sha2(c1)) z2 = string_to_number(sha2(c2)) # Find cryptographically secure random k = (((z1 - z2) % n) * inverse_mod((s1 - s2), n)) % n # k = len(login1) # Recover private key da1 = ((((s1 * k) % n) - z1) * inverse_mod(r1, n)) % n # da2 = ((((s2 * k) % n) - z2) * inverse_mod(r2, n)) % n # SECP256k1 is the Bitcoin elliptic curve sk = SigningKey.from_secret_exponent(da1, curve=SECP256k1, hashfunc=hashlib.sha256) # create the signature login_tgt = "admin" # Sign account login_hash = sha2(login_tgt) signature = sk.sign(login_hash, k=k) # Create signature key sig_dic_key = "r" + str(r_idx) + "s" + str(s_idx) try: # because who trusts python vk = sk.get_verifying_key() vk.verify(signature, login_hash) print(sig_dic_key, " - good signature") except BadSignatureError: print(sig_dic_key, " - BAD SIGNATURE") 

Its very interesting challenge and I want to break ECDSA finally.
Thanks in advance
submitted by unk1nd0n3 to webappsec [link] [comments]

Find Public Key

Given the equation K = k * G where K is the public key, G is the Generator point and k is the private key
G is constant based here
Let's take for example the private key 1
k = 0000000000000000000000000000000000000000000000000000000000000001 G = 0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
the public key is 0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
I'm quite confused how it resulted to the K value. Are there working implementation for the equation K = k * G? So I can follow how it derived the public key.
Or I am missing something here?
submitted by quin24 to Bitcoin [link] [comments]

Choice of base point G in secp256k1 elliptic curve

In the specification of secp256k1, it says recommended parameter for base point G in compressed form is 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 ( http://www.secg.org/sec2-v2.pdf#subsubsection.2.4.1 ).
However, on Bitcoin Wiki, it says this curve was chosen based on simplicity of parameter, avoiding potential backdoor.
https://en.bitcoin.it/wiki/Secp256k1
In what point of view is this parameter "simple" ? As any point on a curve can be a generator, I guess there could have been simpler alternatives for this curve.
Also, I am wondering if choosing a specific generator of a curve can be a backdoor (though I think is unlikely).
submitted by jkv71926 to cryptography [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-05)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, bitcoin.com and the bitcoin-discuss mailing list every week. I can't control what's being talking about in the meeting, if certain things come up I might not be able to post here because of "guidelines".
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Sigcache performance Performance goals for 0.12 transaction priority sigops flooding attack chain limits
Short topics/notes
Note: cfields, mcelrath and BlueMatt (and maybe more) missed the meeting because of daylight saving time.
Closing date for proposals for the scaling bitcoin workshop is the 9th.
Check to see if there are any other commits for the 0.11.2 RC. As soon as 6948 and 6825 are merged it seems good to go. We need to move fairly quick as there are already miners voting for CLTV (F2Pool). Also testnet is CLTV locked already and is constantly forking. 0.11.2 RC1 has been released as of today: https://bitcoin.org/bin/bitcoin-core-0.11.2/test/
Most of the mempool-limiting analysis assumed child-pays-for-parent, however that isn't ready for 0.12 yet, so we should think about possible abuses in context of the existing mining algorithm.
Because of time-constrains opt-in replace-by-fee has been deferred to next weeks meeting, but most people seem to want it in 0.12. sdaftuar makes a note that we need to make clear to users what they need to do if they don't want to accept opt-in transactions.
Sigcache performance
The signature cache, which is in place to increase performance (by not having to check the signature multiple times), and to mitigate some attacks currently has a default limit of 50 000 signatures. Sipa has a pull-request which proposes to: Change the limit from number of entries to megabytes Change the default to 40MB, which corresponds to 500 000 signatures Store salted hashes instead of full entries Remove entries that have been validated in a block
Sipa did benchmarks for various signature cache sizes on hitrate in blocks (how many of the cached signatures are in the block). The maximum sigcache size was 68MB, resulting in a 3% miss-rate. Some blocks though have extremely high miss rates (60%) while others have none. Likely caused by miners running different policies. Gmaxwell proposed to always run script verification for mempool transactions, even if these transactions get rejected into the mempool by the clients policy. The result of that is that even a 300MB sigcache size only gets down to 15% misses. So there's too much crap being relayed to keep any reasonable sized cache. Gmaxwell points out downsides to not checking any rejected transactions, namely: there are some DOS attacks possible, and you increase your misrate if you set a policy which is more restrictive than the typical network, which might result in a race to the bottom.
Sipa continues his work and seeks out other strategies
Performance goals for 0.12
Bitcoin-core 0.12 is scheduled for release December 1st.
Everybody likes to include secp256k1 ASAP, as it has a very large performance increase. Some people would like to include the sigcache pull-request, BIP30, modifyNewCoins and a createNewBlock rewrite if it's ready. Wumpus advises against merging last-minute performance improvements for 0.12.
Mentioned pull-requests should be reviewed, prioritizing CreateNewBlock
transaction priority
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which makes some transactions free.
Sipa thinks we should get rid of the current priority completely and replace it with a function that modifies fee or size of a transaction. There's a pull-request available that optimizes the current transaction priority, thereby avoiding the political debate that goes with changing the definition of transaction priority. Luke-jr thinks the old policy should remain possible.
Check to see if PR #6357 is safe and efficient enough.
sigops flooding attack
The number of ECDSA signature-checking operations or sigops is currently limited to 20 000 per block. This in order to prevent miners creating blocks that take ages to verify as those operations are time-consuming. You could however construct transactions that have a very high sigops count and since most miners don't take into account the sigops count they end up with very small blocks because the sigop limit is reached. This attack is described here.
Suggestion to take the number of sigops relative to the maximum blocksize into account with the total size. Meaning a 10k sigops transaction would currently be viewed as 500kB in size (for that single transaction, not towards the block). That suggestion would be easy to change in the mining code, but more invasive to try and plug that into everything that looks at feerate. This would also open up attacks on the mempool if these transactions are not evicted by mempool limiting. Luke-jr has a bytes-per-sigop limit, that filters out these attack transactions.
More analysis should be done, people seem fine with the general direction of fixing it.
chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
sdaftuar's analysis shows that 40% of blocks contain a chain that exceeds the proposed limits. Even a small bump doesn't make the problem go away. Possible sources of these chains: a service paying the fees on other transactions (child-pays-for-parent), an iOS wallet that gladly spends unconfirmed change. A business confirms they use child-pays-for-parent when they receive bitcoins from an unspent chain. It is possible that these long chains are delivered to miners directly, in which case they wouldn't be affected by the proposed relay limits (and by malleability). Since this is a problem that needs to be addressed, people seem fine with merging it anyway, communicating in advance to let businesses think about how this affects them.
Merge "Policy: Lower default limits for tx chains" Morcos will mail the developer mailing list after it's merged.
Participants
morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille jgarzik Jeff Garzik Luke-Jr Luke Dashjr phantomcircuit Patrick Strateman sdaftuar Suhas Daftuar btcdrak btcdrak jouke ??Jouke Hofman?? jtimon Jorge Timón jonasschnelli Jonas Schnelli 
Comic relief
20:01 wumpus #meetingend 20:01 wumpus #meetingstop 20:01 gmaxwell Thanks all. 20:01 btcdrak #exitmeeting 20:01 gmaxwell #nomeetingnonono 20:01 btcdrak #meedingexit 20:01 wumpus #endmeeting 20:01 lightningbot Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:01 btcdrak #rekt 
submitted by G1lius to Bitcoin [link] [comments]

MaxCoin Specifications. Important

Quick Technicals
Cryptography Tech Spec
MaxCoin uses the Keccak (SHA-3) hashing algorithm for its Proof-of-Work. Keccak was selected as an alternative to the NSA designed SHA256 after a 5-year long competition held by the NIST and will be seen increasingly as the algorithm used in banking and other secure applications. A single round of Keccak is used, resulting in a 256 bit hash.
We have also implemented a provably-secure signing algorithm, EC-Schnorr. Every existing cryptocurrency uses the ECDSA algorithm, as chosen by Satoshi; whilst ECDSA is in common use and is secure, EC-Schnorr is provably more secure and is currently being recommended over it (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport). Additionally, MaxCoin changes the elliptic curve utilised within the signing algorithms from a Koblitz curve, secp256k1, to a more secure psuedo-random one, secp256r1. The use of the latter curve is recommended almost universally - and the decision by Satoshi to use the former is one that is often queried in the Bitcoin world. One theory is that there are some speed advantages to using the Koblitz curve, but, the implementation used in Bitcoin (OpenSSL) does not make use of this optimisation and, thus, the result is reduced-security.
The cryptography choices within MaxCoin have been made to maximise security and, where possible, to minimise NSA influence. We have been advised throughout by the renowed cryptography expert Professor Nigel Smart (https://en.wikipedia.org/wiki/Nigel_Smart_(cryptographer)).
These changes also lay the foundation for some key features we're aiming to implement in MaxCoin over the coming months, so while they may currently appear uninteresting changes they pave the way for our future growth.
What do you mean by "Starting Algorithm"?
This is an issue of hardware miner resistance, such as ASICs. Keccak is the starting algorithm for MaxCoin and at this point in time no hardware miner currently exists. However, creating a Keccak ASIC is not impossible. Therefore, in order to protect against a hardware-miner future we are going to implement an "ASIC protection" feature into MaxCoin. This will work by allowing the blockchain to decide a new hashing algorithm for MaxCoin every x blocks. More specifically, the last authenticated transaction's hash is used to determine an integer and depending on this value an algorithm will be selected. This will mean hardware miners will find it difficult to create hardware in enough time to see profitable return. Purely for example, these could be:
x Algorithm 0 Keccak 1 Blake 2 Grostlx2 3 JH 4 Skein 5 Blake2 6 JH(Grostl) 7 Keccak+Blake
Difficulty & Distribution
MaxCoin will have a zero % premine, proven by the timestamps of the first blocks in a block explorer, and we have attempted to combat low-difficulty instamining with a fast retarget rate up until block 200. At block 200 the Kimoto Gravity Well implementation will take over the retargeting.
Mining is done via CPU at release (mining guides about to be released also on this subreddit), but a GPU miner will not be far away. We've seen some versions in the works already after we released CPUminer yesterday, and while we have not yet seen a working version, this is very unlikely to take long. We'll update all official channels with Keccak GPU miner once it is available. It's also worth noting that any GPU miner created will not work after the first algorithm switch takes place.
submitted by maxcoinproject to maxcoinproject [link] [comments]

I have a python script that doesn't return the correct result (missing 0's)

Below is the current code that I am using. It is to turn a Bitcoin private key into a long style Bitcoin public key. Step 1 of https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses#How_to_create_Bitcoin_Address
It works for the most part, about 8 to 10% of the time it returns a wrong result because 0's are missing at either the 3rd position of 67th position. Sometimes it is 1 or more 0s. I don't know why the python code is not displaying the results properly.
#! /usbin/env python import sys class Point(object): def __init__(self, _x, _y, _order = None): self.x, self.y, self.order = _x, _y, _order def calc(self, top, bottom, other_x): l = (top * inverse_mod(bottom)) % p x3 = (l * l - self.x - other_x) % p return Point(x3, (l * (self.x - x3) - self.y) % p) def double(self): if self == INFINITY: return INFINITY return self.calc(3 * self.x * self.x, 2 * self.y, self.x) def __add__(self, other): if other == INFINITY: return self if self == INFINITY: return other if self.x == other.x: if (self.y + other.y) % p == 0: return INFINITY return self.double() return self.calc(other.y - self.y, other.x - self.x, other.x) def __mul__(self, e): if self.order: e %= self.order if e == 0 or self == INFINITY: return INFINITY result, q = INFINITY, self while e: if e&1: result += q e, q = e >> 1, q.double() return result def __str__(self): if self == INFINITY: return "infinity" return "04%x%x" % (self.x, self.y) def inverse_mod(a): if a < 0 or a >= p: a = a % p c, d, uc, vc, ud, vd = a, p, 1, 0, 0, 1 while c: q, c, d = divmod(d, c) + (c,) uc, vc, ud, vd = ud - q*uc, vd - q*vc, uc, vc if ud > 0: return ud return ud + p p, INFINITY = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2FL, Point(None, None) # secp256k1 g = Point(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798L, 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8L, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141L) secret = int(sys.argv[1], 16) publickey = g * secret print '%s' % (publickey) 
Examples
#1 Returns 0488987467ceddee013b4fe07f726e9990a63930a7f81097ade4067123232084a2bfdc544db8434448f70b6cb42fe3d3c6c6da011c67885c7369a5de0384a450 #1 Should be 040088987467CEDDEE013B4FE07F726E9990A63930A7F81097ADE4067123232084A2BFDC544DB8434448F70B6CB42FE3D3C6C6DA011C67885C7369A5DE0384A450 
submitted by Myshakiness to learnpython [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-05)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
On a personal note: I really don't like the fact someone pm'ed me telling me "a majority of bitcoiners have moved to btc", it's not (yet) true and comes across as very spammy. This combined with the tin-foiled hat people-bashing which seems to be popular makes me almost not want to join this community. I hope this can become like bitcoin, but with the freedom to discuss and mention any topic, not a mindless crusade against bitcoin, theymos, blockstream, etc.
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Sigcache performance Performance goals for 0.12 transaction priority sigops flooding attack chain limits
Short topics/notes
Note: cfields, mcelrath and BlueMatt (and maybe more) missed the meeting because of daylight saving time.
Closing date for proposals for the scaling bitcoin workshop is the 9th.
Check to see if there are any other commits for the 0.11.2 RC. As soon as 6948 and 6825 are merged it seems good to go. We need to move fairly quick as there are already miners voting for CLTV (F2Pool). Also testnet is CLTV locked already and is constantly forking. 0.11.2 RC1 has been released as of today: https://bitcoin.org/bin/bitcoin-core-0.11.2/test/
Most of the mempool-limiting analysis assumed child-pays-for-parent, however that isn't ready for 0.12 yet, so we should think about possible abuses in context of the existing mining algorithm.
Because of time-constrains opt-in replace-by-fee has been deferred to next weeks meeting, but most people seem to want it in 0.12. sdaftuar makes a note that we need to make clear to users what they need to do if they don't want to accept opt-in transactions.
Sigcache performance
The signature cache, which is in place to increase performance (by not having to check the signature multiple times), and to mitigate some attacks currently has a default limit of 50 000 signatures. Sipa has a pull-request which proposes to: Change the limit from number of entries to megabytes Change the default to 40MB, which corresponds to 500 000 signatures Store salted hashes instead of full entries Remove entries that have been validated in a block
Sipa did benchmarks for various signature cache sizes on hitrate in blocks (how many of the cached signatures are in the block). The maximum sigcache size was 68MB, resulting in a 3% miss-rate. Some blocks though have extremely high miss rates (60%) while others have none. Likely caused by miners running different policies. Gmaxwell proposed to always run script verification for mempool transactions, even if these transactions get rejected into the mempool by the clients policy. The result of that is that even a 300MB sigcache size only gets down to 15% misses. So there's too much crap being relayed to keep any reasonable sized cache. Gmaxwell points out downsides to not checking any rejected transactions, namely: there are some DOS attacks possible, and you increase your misrate if you set a policy which is more restrictive than the typical network, which might result in a race to the bottom.
Sipa continues his work and seeks out other strategies
Performance goals for 0.12
Bitcoin-core 0.12 is scheduled for release December 1st.
Everybody likes to include secp256k1 ASAP, as it has a very large performance increase. Some people would like to include the sigcache pull-request, BIP30, modifyNewCoins and a createNewBlock rewrite if it's ready. Wumpus advises against merging last-minute performance improvements for 0.12.
Mentioned pull-requests should be reviewed, prioritizing CreateNewBlock
transaction priority
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which makes some transactions free.
Sipa thinks we should get rid of the current priority completely and replace it with a function that modifies fee or size of a transaction. There's a pull-request available that optimizes the current transaction priority, thereby avoiding the political debate that goes with changing the definition of transaction priority. Luke-jr thinks the old policy should remain possible.
Check to see if PR #6357 is safe and efficient enough.
sigops flooding attack
The number of ECDSA signature-checking operations or sigops is currently limited to 20 000 per block. This in order to prevent miners creating blocks that take ages to verify as those operations are time-consuming. You could however construct transactions that have a very high sigops count and since most miners don't take into account the sigops count they end up with very small blocks because the sigop limit is reached. This attack is described here.
Suggestion to take the number of sigops relative to the maximum blocksize into account with the total size. Meaning a 10k sigops transaction would currently be viewed as 500kB in size (for that single transaction, not towards the block). That suggestion would be easy to change in the mining code, but more invasive to try and plug that into everything that looks at feerate. This would also open up attacks on the mempool if these transactions are not evicted by mempool limiting. Luke-jr has a bytes-per-sigop limit, that filters out these attack transactions.
More analysis should be done, people seem fine with the general direction of fixing it.
chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
sdaftuar's analysis shows that 40% of blocks contain a chain that exceeds the proposed limits. Even a small bump doesn't make the problem go away. Possible sources of these chains: a service paying the fees on other transactions (child-pays-for-parent), an iOS wallet that gladly spends unconfirmed change. A business confirms they use child-pays-for-parent when they receive bitcoins from an unspent chain. It is possible that these long chains are delivered to miners directly, in which case they wouldn't be affected by the proposed relay limits (and by malleability). Since this is a problem that needs to be addressed, people seem fine with merging it anyway, communicating in advance to let businesses think about how this affects them.
Merge "Policy: Lower default limits for tx chains" Morcos will mail the developer mailing list after it's merged.
Participants
morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille jgarzik Jeff Garzik Luke-Jr Luke Dashjr phantomcircuit Patrick Strateman sdaftuar Suhas Daftuar btcdrak btcdrak jouke ??Jouke Hofman?? jtimon Jorge Timón jonasschnelli Jonas Schnelli 
Comic relief
20:01 wumpus #meetingend 20:01 wumpus #meetingstop 20:01 gmaxwell Thanks all. 20:01 btcdrak #exitmeeting 20:01 gmaxwell #nomeetingnonono 20:01 btcdrak #meedingexit 20:01 wumpus #endmeeting 20:01 lightningbot Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:01 btcdrak #rekt 
submitted by G1lius to btc [link] [comments]

How to generate a Private Address with your mind and other nice Bitcoin tricks!

Warning: Using anything but true randomness to generate your keys , always increases the risk of the key being guessed. (Which is still super extremely low if done properly).
This post has nothing to do with Brainwallet, but should be able to give you an insight to Bitcoin adresses and how easy it is to create your own key in an offline and software-less situation.
You can use this:
You could create a private address on the spot and share with the other party. Once at home you load it with Bitcoins and the other one can take them.
Now, generating the public address from the private key is something MUCH more difficult to do without software assistance. But still, knowing how to create a private key with little to no software assistance could prove useful.
Your private key is just a Random Number. Nothing fancy, nothing shiny and nothing special. Just a long-ass random number.
How long? It's got 256 digits in binary, which is a long string of 256 1's and 0's.
But the same number can also be expressed in just 64 digits if we do it in base 16 (hexadecimal). This hexadecimal number can also be imported by many of the current popular bitcoin applications such as armory, electrum or blockchain.info (haven't tried any others).
Once imported, the software will then, probably, convert that number to Base58 also called the "Wallet import Format". This is the format you're probably familiar with that starts with a 5 and that includes some security checks.
But we don't need to be able to create a base58 number. Just a 64 digits base 16 number, which is much easier and most applications will be able to import it.
Generate your own Private key:
You can either do it in your mind or find a random device with at least 16 outputs. Remember that the quality and security of the key depends on the randomness. But, while it is true that the human mind is biased when writing down random numbers, in the end this is no easier to guess than a good passphrase.
These are the random numbers you can choose from:
0 1 2 3 4 5 6 7 8 9 a b c d e f
Just treat the letters as if they were numbers and write down one random number, 64 times. At the end you'll have a 64 digit, hexadecimal, random or semi-random number.
Just import it, without spaces, to your favourite application and it will generate the public address for you. That's it! You're done!
As you can guess, this also means that "Funny" private keys such as:
777777777... (64 times) 314159265... (the number pi) 123456789... (a number succession)
Are very well possible and can be tried out! I would strongy advice against using them to hold any bitcoins, but it's interesting to keep those "Funny" addresses in mind.
Funfact: The number you've been "generating" is by far larger than the amount of atoms on the whole planet.
Generating private keys with /dev/random
If you're on a linux machine, then you have access to this great device called /dev/random. Most Bitcoin softwares use a different device called /dev/urandom (notice the extra u) to generate the addresses because it is faster. The "urandom" output is pseudorandom and not truly random... this allows it to be faster and output numbers at a much higher rate, but the randomness offered by /dev/random is much better. (Although it may take a few seconds to generate a key).
Write this command in a terminal:
od -An -N32 -x /dev/random
This should provide you with a 64 digit hexadecimal number which will work excellently as a random private key. (but you must remove the spaces).
Generating a Brainwallet offline Create your own brainwallet without using brainwallet.org.
echo -n "your passphrase" | shasum -a 256
The -n option removes the new line that "echo" usually appends and the | sign processes the output you wrote to the next command which will create a 256 bit long hash from it.
The hash will be in hexadecimal and, yes you guessed right, it will be 64 digits long.
This will, by the way, give you exactly the same private key as brainwallet.org, but can be used offline on a fresh booted live-cd without needing to connect to the internet, for example.
Finally, You must know, that for the keys to be accepted by Bitcoin software, they must be larger than 1 and smaller than FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141.
So, as long as you don't start with 31 consecutive F's when manually generating your key, it will be valid. More information about this.
I hope you like it! Credit also goes to Flatfly and DannyHamilton who helped me out on the Bitcointalk forums.
submitted by DanielTaylor to Bitcoin [link] [comments]

Bitcoin - Wiki Videos Bitcoin Tutorial #12 - Der SECP256K1-Standard für Schlüssel The Elliptic Curve Digital Signature Algorithm and raw transactions on Bitcoin Bitcoin 101 Elliptic Curve Cryptography Part 4 Generating the Public Key in Python ️ Satoshi's 21 #002: JoinMarket - YouTube

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. Bitcoin is a decentralized digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: transaction management and money issuance are carried out collectively by the network. The original Bitcoin software by Satoshi Nakamoto was released under the MIT license. . Most client software, derived or "from This library is intended to be the highest quality publicly available library for cryptography on the secp256k1 curve. However, the primary focus of its development has been for usage in the Bitcoin system and usage unlike Bitcoin's may be less well tested, verified, or suffer from a less well thought out interface. Bitcoin private key is a secret number that allows cryptocurrency to be spent. Every Bitcoin address has a matching private key, which is saved in the wallet file of the person who owns the balance. The private key is mathematically related to the address, and is designed so that the Bitcoin address can be calculated from the private key, but importantly, the same cannot be done in reverse. 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.

[index] [10634] [17906] [20864] [23953] [17423] [30099] [13505] [20481] [12531] [17898]

Bitcoin - Wiki Videos

If you've been wondering about the secp256k1 (arguably the most important piece of code in Bitcoin), well then this is the video for you. This is part 4 of our upcoming series on Elliptic Curves. Bitcoin is a cryptocurrency and a digital payment system invented by an unknown programmer or a group of programmers under the name Satoshi Nakamoto It was released as open source software in The s... The Of Bitcoin - Wikipedia Here are three actions to help you get started utilizing Bitcoin Money right now: A Bitcoin wallet is an app or program that enables you send and receive BCH. Wallets ... 3rd BIU Winter School on Cryptography: The basics of elliptic curves - Nigel Smart - Duration: 1:20:28. Bar-Ilan University - אוניברסיטת בר-אילן 6,028 views This time we'll dive into JoinMarket, which is a CoinJoin implementation aimed at improving the privacy and fungibility of Bitcoin transactions. It works by ...

Flag Counter