How to generate your very own Bitcoin private key

Thanks to all who submitted questions for Shiv Malik in the GAINS AMA yesterday, it was great to see so much interest in Data Unions! You can read the full transcript here:

Thanks to all who submitted questions for Shiv Malik in the GAINS AMA yesterday, it was great to see so much interest in Data Unions! You can read the full transcript here:

Gains x Streamr AMA Recap
Thanks to everyone in our community who attended the GAINS AMA yesterday with, Shiv Malik. We were excited to see that so many people attended and gladly overwhelmed by the amount of questions we got from you on Twitter and Telegram. We decided to do a little recap of the session for anyone who missed it, and to archive some points we haven’t previously discussed with our community. Happy reading and thanks to Alexandre and Henry for having us on their channel!
What is the project about in a few simple sentences?
At Streamr we are building a real-time network for tomorrow’s data economy. It’s a decentralized, peer-to-peer network which we are hoping will one day replace centralized message brokers like Amazon’s AWS services. On top of that one of the things I’m most excited about are Data Unions. With Data Unions anyone can join the data economy and start monetizing the data they already produce. Streamr’s Data Union framework provides a really easy way for devs to start building their own data unions and can also be easily integrated into any existing apps.
Okay, sounds interesting. Do you have a concrete example you could give us to make it easier to understand?
The best example of a Data Union is the first one that has been built out of our stack. It's called Swash and it's a browser plugin.
You can download it here:
And basically it helps you monetize the data you already generate (day in day out) as you browse the web. It's the sort of data that Google already knows about you. But this way, with Swash, you can actually monetize it yourself. The more people that join the union, the more powerful it becomes and the greater the rewards are for everyone as the data product sells to potential buyers.
Very interesting. What stage is the project/product at? It's live, right?
Yes. It's live. And the Data Union framework is in public beta. The Network is on course to be fully decentralized at some point next year.
How much can a regular person browsing the Internet expect to make for example?
So that's a great question. The answer is no one quite knows yet. We do know that this sort of data (consumer insights) is worth hundreds of millions and really isn't available in high quality. So With a union of a few million people, everyone could be getting 20-50 dollars a year. But it'll take a few years at least to realise that growth. Of course Swash is just one data union amongst many possible others (which are now starting to get built out on our platform!)
With Swash, I believe they now have 3,000 members. They need to get to 50,000 before they become really viable but they are yet to do any marketing. So all that is organic growth.
I assume the data is anonymized btw?
Yes. And there in fact a few privacy protecting tools Swash supplys to its users.
How does Swash compare to Brave?
So Brave really is about consent for people's attention and getting paid for that. They don't sell your data as such.
Swash can of course be a plugin with Brave and therefore you can make passive income browsing the internet. Whilst also then consenting to advertising if you so want to earn BAT.
Of course it's Streamr that is powering Swash. And we're looking at powering other DUs - say for example mobile applications.
The holy grail might be having already existing apps and platforms out there, integrating DU tech into their apps so people can consent (or not) to having their data sold - and then getting a cut of that revenue when it does sell.
The other thing to recognise is that the big tech companies monopolise data on a vast scale - data that we of course produce for them. That is stifling innovation.
Take for example a competitor map app. To effectively compete with Google maps or Waze, they need millions of users feeding real time data into it.
Without that - it's like Google maps used to be - static and a bit useless.
Right, so how do you convince these big tech companies that are producing these big apps to integrate with Streamr? Does it mean they wouldn't be able to monetize data as well on their end if it becomes more available through an aggregation of individuals?
If a map application does manage to scale to that level then inevitably Google buys them out - that's what happened with Waze.
But if you have a data union which bundles together the raw location data of millions of people then any application builder can come along and license that data for their app. This encourages all sorts of innovation and breaks the monopoly.
We're currently having conversations with Mobile Network operators to see if they want to pilot this new approach to data monetization. And that's what even more exciting. Just be explicit with users - do you want to sell your data? Okay, if yes, then which data point do you want to sell.
Then the mobile network operator (like T-mobile for example) then organises the sale of the data of those who consent and everyone gets a cut.
Streamr - in this example provides the backend to port and bundle the data, and also the token and payment rail for the payments.
So for big companies (mobile operators in this case), it's less logistics, handing over the implementation to you, and simply taking a cut?
It's a vision that we'll be able to talk more about more concretely in a few weeks time 😁
Compared to having to make sense of that data themselves (in the past) and selling it themselves
Sort of.
We provide the backened to port the data and the template smart contracts to distribute the payments.
They get to focus on finding buyers for the data and ensuring that the data that is being collected from the app is the kind of data that is valuable and useful to the world.
(Through our sister company TX, we also help build out the applications for them and ensure a smooth integration).
The other thing to add is that the reason why this vision is working, is that the current data economy is under attack. Not just from privacy laws such as GDPR, but also from Google shutting down cookies, bidstream data being investigated by the FTC (for example) and Apple making changes to IoS14 to make third party data sharing more explicit for users.
All this means that the only real places for thousands of multinationals to buy the sort of consumer insights they need to ensure good business decisions will be owned by Google/FB etc, or from SDKs or through this method - from overt, rich, consent from the consumer in return for a cut of the earnings.
A couple of questions to get a better feel about Streamr as a whole now and where it came from. How many people are in the team? For how long have you been working on Streamr?
We are around 35 people with one office in Zug, Switzerland and another one in Helsinki. But there are team members all over the globe, we’ve people in the US, Spain, the UK, Germany, Poland, Australia and Singapore. I joined Streamr back in 2017 during the ICO craze (but not for that reason!)
And did you raise funds so far? If so, how did you handle them? Are you planning to do any future raises?
We did an ICO back in Sept/Oct 2017 in which we raised around 30 Millions CHF. The funds give us enough runway for around five/six years to finalize our roadmap. We’ve also simultaneously opened up a sister company consultancy business, TX which helps enterprise clients implementing the Streamr stack. We've got no more plans to raise more!
What is the token use case? How did you make sure it captures the value of the ecosystem you're building
The token is used for payments on the Marketplace (such as for Data Union products for example) also for the broker nodes in the Network. ( we haven't talked much about the P2P network but it's our project's secret sauce).
The broker nodes will be paid in DATAcoin for providing bandwidth. We are currently working together with Blockscience on our tokeneconomics. We’ve just started the second phase in their consultancy process and will be soon able to share more on the Streamr Network’s tokeneconoimcs.
But if you want to summate the Network in a sentence or two - imagine the Bittorrent network being run by nodes who get paid to do so. Except that instead of passing around static files, it's realtime data streams.
That of course means it's really well suited for the IoT economy.
Well, let's continue with questions from Twitter and this one comes at the perfect time. Can Streamr Network be used to transfer data from IOT devices? Is the network bandwidth sufficient? How is it possible to monetize the received data from a huge number of IOT devices? From u/ EgorCypto
Yes, IoT devices are a perfect use case for the Network. When it comes to the network’s bandwidth and speed - the Streamr team just recently did extensive research to find out how well the network scales.
The result was that it is on par with centralized solutions. We ran experiments with network sizes between 32 to 2048 nodes and in the largest network of 2048 nodes, 99% of deliveries happened within 362 ms globally.
To put these results in context, PubNub, a centralized message brokering service, promises to deliver messages within 250 ms — and that’s a centralized service! So we're super happy with those results.
Here's a link to the paper:
While we're on the technical side, second question from Twitter: Can you be sure that valuable data is safe and not shared with service providers? Are you using any encryption methods? From u/ CryptoMatvey
Yes, the messages in the Network are encrypted. Currently all nodes are still run by the Streamr team. This will change in the Brubeck release - our last milestone on the roadmap - when end-to-end encryption is added. This release adds end-to-end encryption and automatic key exchange mechanisms, ensuring that node operators can not access any confidential data.
If BTW - you want to get very technical the encryption algorithms we are using are: AES (AES-256-CTR) for encryption of data payloads, RSA (PKCS #1) for securely exchanging the AES keys and ECDSA (secp256k1) for data signing (same as Bitcoin and Ethereum).
Last question from Twitter, less technical now :) In their AMA ad, they say that Streamr has three unions, Swash, Tracey and MyDiem. Why does Tracey help fisherfolk in the Philippines monetize their catch data? Do they only work with this country or do they plan to expand? From u/ alej_pacedo
So yes, Tracey is one of the first Data Unions on top of the Streamr stack. Currently we are working together with the WWF-Philippines and the UnionBank of the Philippines on doing a first pilot with local fishing communities in the Philippines.
WWF is interested in the catch data to protect wildlife and make sure that no overfishing happens. And at the same time the fisherfolk are incentivized to record their catch data by being able to access micro loans from banks, which in turn helps them make their business more profitable.
So far, we have lots of interest from other places in South East Asia which would like to use Tracey, too. In fact TX have already had explicit interest in building out the use cases in other countries and not just for sea-food tracking, but also for many other agricultural products.
(I think they had a call this week about a use case involving cows 😂)
I recall late last year, that the Streamr Data Union framework was launched into private beta, now public beta was recently released. What are the differences? Any added new features? By u/ Idee02
The main difference will be that the DU 2.0 release will be more reliable and also more transparent since the sidechain we are using for micropayments is also now based on blockchain consensus (PoA).
Are there plans in the pipeline for Streamr to focus on the consumer-facing products themselves or will the emphasis be on the further development of the underlying engine?by u/ Andromedamin
We're all about what's under the hood. We want third party devs to take on the challenge of building the consumer facing apps. We know it would be foolish to try and do it all!
As a project how do you consider the progress of the project to fully developed (in % of progress plz) by u/ Hash2T
We're about 60% through I reckon!
What tools does Streamr offer developers so that they can create their own DApps and monetize data?What is Streamr Architecture? How do the Ethereum blockchain and the Streamr network and Streamr Core applications interact? By u/ CryptoDurden
We'll be releasing the Data UNion framework in a few weeks from now and I think DApp builders will be impressed with what they find.
We all know that Blockchain has many disadvantages as well,
So why did Streamr choose blockchain as a combination for its technology?
What's your plan to merge Blockchain with your technologies to make it safer and more convenient for your users? By u/ noonecanstopme
So we're not a blockchain ourselves - that's important to note. The P2P network only uses BC tech for the payments. Why on earth for example would you want to store every single piece of info on a blockchain. You should only store what you want to store. And that should probably happen off chain.
So we think we got the mix right there.
What were the requirements needed for node setup ? by u/ John097
Good q - we're still working on that but those specs will be out in the next release.
How does the STREAMR team ensure good data is entered into the blockchain by participants? By u/ kartika84
Another great Q there! From the product buying end, this will be done by reputation. But ensuring the quality of the data as it passes through the network - if that is what you also mean - is all about getting the architecture right. In a decentralised network, that's not easy as data points in streams have to arrive in the right order. It's one of the biggest challenges but we think we're solving it in a really decentralised way.
What are the requirements for integrating applications with Data Union? What role does the DATA token play in this case? By u/ JP_Morgan_Chase
There are no specific requirements as such, just that your application needs to generate some kind of real-time data. Data Union members and administrators are both paid in DATA by data buyers coming from the Streamr marketplace.
Regarding security and legality, how does STREAMR guarantee that the data uploaded by a given user belongs to him and he can monetize and capitalize on it? By u/ kherrera22
So that's a sort of million dollar question for anyone involved in a digital industry. Within our system there are ways of ensuring that but in the end the negotiation of data licensing will still, in many ways be done human to human and via legal licenses rather than smart contracts. at least when it comes to sizeable data products. There are more answers to this but it's a long one!
Okay thank you all for all of those!
The AMA took place in the GAINS Telegram group 10/09/20. Answers by Shiv Malik.
submitted by thamilton5 to streamr [link] [comments]

Best General RenVM Questions of February 2020

Best General RenVM Questions of January 2020

\These questions are sourced directly from Telegram*
Q: Are all the projects listed in the Ren Alliance, the final set of members?
A: No, please do keep in mind this just our first round of partners, some larger orgs require a bit more DD (i.e our audit). We’ll release the final set of members when Mainnet goes live.

Q: How do projects join the Ren Alliance?
A: It’s simple, just fill out this application. It takes about five minutes, and all you need is your company’s logo files and your preferred area(s) of involvement. Joining the Alliance requires no binding commitments, only a desire to help bring cross-chain assets to DeFi.

Q: For example let's say there is a crypto index which contains 1 BTC and 1 ZEC. I have 1 BTC and 1 ZEC and I would like to “mint” this index token with RenVM. Will something like this possible in the future?
A: This is already possible today. RenVM allows you to mint renBTC and renZEC (and renBCH) on Ethereum. This result is an ERC20 like any other with the addition that when you burn it, you get real BTC and ZEC back.
Another nice feature is that you can directly call smart contracts when minting. This is not possible in any other system, and results in a very clean and simple user experience. People can make a BTC transaction followed by a ZEC transaction and with no other blockchain actions end up with their BTC and ZEC in your example system (your example system would have functions for accepting BTC and ZEC and when receiving both, it would output some kind of index token; exactly how it functions is up to how you want to implement your contract!)

Q: What blockchains does RenVM support?
A: RenVM can support any ECDSA based blockchain but we'll be starting with BTC, ZEC, and BCH. More info here:

Q: Another concern is chain rollback. In the case of MakerDAO getting hacked (unlikely, but not impossible), the Ethereum network could rollback just like with the DAO. (Unlikely, but not impossible). But what if the attacker already has deposited the hacked funds into RenVM and gotten a private coin?
A: A roll-back would still revert that state. Privacy on-chain != no state tracking something (just in a way that doesn’t reveal information). So reverts don’t really matter in that sense. They do matter in a broader sense: you have renBTC and you burn it for BTC, then Ethereum rolls back to when you had renBTC still. This is something the Ethereum community has to consider very carefully these days if they were to ever do such a revert. This is an ultimately unavoidable truth RE interoperability; you are compounding risks of the chains you are using. In general, this is why it’s always safer to keep your BTC on Bitcoin unless there is a specific reason you need it on Ethereum at any given point in time.

Q: If BTC can be transferred with zero confirmation how many transactions RenVM can handle?
A: RenVMs throughput isn’t affected by conf-less transactions. This is a service provided by L2 technology (like the 0Conf team, who are building exactly this!). This doesn’t affect RenVM directly, but it does have the pleasant impact that users won’t notice network congestion if it happens.

Q: Can you explain the over-collateralization security dynamic between tBTC and RenVM? Does this play into Maker using RenVM vs. tBTC to collaetize their CDP’s
A1: It’s not the over collateralization that’s the problem. It’s that to get $X BTC they need 1.5x $X ETH locked up in their protocol. What about other places that give better ETH returns? What about the fact that ETH doesn’t go up in price just because tBTC is used?
With REN, we are actually over collateralized (so they’re wrong that they are more secure in this regard). The big difference: BTC flowing through REN increases the value of the REN collateral, increasing the security, increasing the capacity of BTC that can flow through the system. It’s a positive feedback loop for capacity and security that simply doesn’t exist if you don’t use an isolated token.
A2: Maker wants to use BTC to collateralise Dai, because it diversifies risk and expands the possible Dai supply (by expanding possible collateral). If you use tBTC, then tBTC is collateralised by ETH so you actually become less efficient at minting Dai, and you don’t diversify risk because tBTC gets liquidated by ETH price movements.
You don’t want your network secured by collateral that has speculative value that is not correlated with the usage of the network. That makes things unstable.
If RenVM is being used, the value of REN increases, and the more RenVM can be used (and Darknodes get the positive upside of their bond increasing in value). This means by pumping lots of BTC into RenVM, you gain more capacity to pump more BTC into RenVM. This creates a positive feedback loop for the returns earned by Darknodes, the value of their bond, and overall/capacity security of the network.
Compare to tBTC: you are waiting for ETH to go up in value. It’s value, which does not correlate with the amount of BTC in the system, limits the AUM that the system can hold. You’re hoping it will go up independently of the usage of your network and if it doesn’t you’re out of luck. Network growth does not drive the ability for the network to grow. Your are also competing with the returns on ETH that other ecosystems allow you to get (why bond ETH in tBTC if you can get better returns on that ETH in other places; lending it or staking it in Eth2.0). (Btw: we’re doing research to get our collateralisation of REN to 150%. It’s already possible, and could be done today, but we are just seeing if we can make it safelivelier than the current best-in-class algorithms.)

Q: How do we define the value of L and R if we don't use oracle price feed?
A: It will be decided by the Darknodes. The best mechanism of doing this is still being decided upon. However, it won’t simply be taken from the current market price / third-party oracles as those are vulnerable to manipulation. Ultimately, the only valuation that matters is the Darknodes (because they’re the ones being potentially bribed).

Q: In my opinion, RenVM (and tBTC adoption bottleneck: 300% collateral ratio» this ratio is important for security and decentralization» to sustain this ratio we need significant fees to be imposed on Renbtc holders» example: if there was 100m$ Renbtc total supply then we need 300m$ ren locked in darknodes» if 3-5% fees paid for those 300m$ then we need to extract 9-15 million fees from the 100m renbtc» that equal 9-15% annual fees» of course it will be lower with the minting and burning fees but I don't think it will cover half of the total needed fees» the result with the current design there are still too much economic friction IMO.
A: The key thing to keep in mind is velocity. Not just TVL. Let’s take Kyber as an example: they have $4.9M AUM. But, they did $3.7M in trades in the last 24 hours. Over the year, that’s 275x their AUM.
So, if RenVM is holding $100M AUM, and achieves a volume multiplier of 200x then it gets $1M p/a in holding fees but $40M in minting/burning fees. This is all assuming the minimum fee as well (it rises as TVL approaches the limit). So RenVM would need a $300M market cap on $41M in revenue. That’s 13% p/a, assuming we don’t make the move to only 150% collateral. If we do move to that, then it’s almost 33% p/a.
RenVM is by far and away the best UX for instantly swapping BTC on DEXs (with no gas, and no confirmations). All of the interfaces we’re building and the tools we’re providing give people that native experience. This is precisely because high TVL is not what yields good returns and increases cap for the protocol.
Even systems like MakerDAO/Compound have people moving BTC in/out. Their AUM is by no means static. People are constantly opening/closing/liquidating positions and all of this is would create velocity through RenVM.

Q: How was ETHDenver?
A: ETHDenver was great, and very productive, confirmed a lot of our thoughts on what needs to be done but also gave us a good amount of exposure, so overall it was a positive for the team and RenVM.
submitted by RENProtocol to RenProject [link] [comments]

19 myths about Bitcoin

19 myths about Bitcoin
Let me clarify common misconceptions about Bitcoin.

Myth # 1. It's just something similar to other virtual currencies, nothing new

All other virtual currencies are controlled by their regulatory center.
This means that:

they can be printed on the subjective whims of the currency regulator;
they could be destroyed by an attack on this regulatory center.;
arbitrary rules can be imposed by the currency regulator.
Bitcoins, being initially a decentralized currency, solve all these problems.

Myth # 2. Bitcoins do not solve any problems that gold and/or Fiat money cannot solve

Unlike gold bitcoins:

easy to carry and store;
easy to authenticate.
Unlike Fiat money, bitcoins:

have predictable and decreasing emissions;
not controlled by any regulatory center.
Unlike Fiat electronic money, bitcoins:

can be anonymous (like cash);
there's no way the accounts can be frozen.

Myth # 3. Bitcoins are secured by CPU time

It is incorrect to say that bitcoins are secured by CPU time. When it is said that a currency is "secured" by something, it is meant to be centrally tied to something at the exchange rate. You can not exchange bitcoins for the computing power spent on their generation (it is too high). In this sense, bitcoins are not secured by anything. This is a self-valuable product. Think, unless gold is provided with something? No, it's just gold. It's the same with bitcoins.

Bitcoin currency is created with the use of processor power: the integrity of the block chain is protected from all sorts of attacks by the existence of a large computer network. That's it.

Myth # 4. Bitcoins are worthless because they are not secured by anything

Gold is not secured by anything, but is used and valued everywhere. See the previous myth.

Myth # 5. The value of bitcoins is based on how much electricity and processing power is required to generate them

This myth is an attempt to apply labor value theory to bitcoins, which is not applicable to them and is probably false. Just because something requires X resources to create doesn't mean that the final product will cost X. it can cost more or less X, depending on the usefulness to users.

In fact, there is a broken causal relationship (this applies to the above theory as a whole). The value of bitcoins is based on how valuable they are. If bitcoins rise in price, more people will try to generate them (because bitcoin generation becomes more profitable), this will increase the difficulty of generating, which in turn only leads to the difficulty of mining them. If bitcoins fall in price, then the reverse process occurs. These processes maintain a balance between the cost of generation and the cost of bitcoins generated.

Myth # 6. Bitcoins have no value of their own (unlike some other things)

Many things have their own value, but it is usually well below the market value of the thing. Consider gold: if it were not used as an inflation-resistant value, and used only for industrial purposes, it would not have today's value, since the industrial need for gold is much lower than it is available.

Historical value has helped establish some things as a means of exchange, but it is certainly not a necessary condition. Perhaps bitcoins will not be used as a raw material for industrial purposes, but they have many other useful qualities that are necessary for the means of exchange.

The value of bitcoins is determined solely by people's desire to trade them - supply and demand.

Myth # 7. Bitcoins are illegal because they are not a legal tender

Short answer: chickens are not a legal tender, but bartering with chickens is not illegal.

There are many currencies that are not legal tender. Currency, after all, is just a convenient unit of account. Although national laws may vary from country to country (you should definitely check the laws of your state), in General - trading with any commodity exchange, including digital goods (e.g.: bitcoins, virtual worlds second Life or WoW game currencies), is not illegal.

Myth # 8. Bitcoins are a form of domestic terrorism because they only harm the economic stability of the state and the state currency

Read the relevant Wikipedia article. Action will not be considered terrorism if it is not violent. Bitcoins are not imposed on anyone with violence, so they are not terrorism.

Also, bitcoins are not "internal". It's a worldwide product. Look at the auto-generated node map.

Myth # 9. Bitcoins will only facilitate tax evasion, which will lead to a possible fall of civilization

It's up to you whether you follow the laws of the country or face the consequences of breaking the laws.

Myth # 10. Bitcoins can print/mint everyone, therefore they're useless

To generate coins requires significant computing power, in addition, over time, all the coins will be generated.

Myth # 11. Bitcoins are useless because they are based on unverified / unproven cryptography

The Sha-256 and ECDSA algorithms that are used in the #Bitcoin program are well-known industrial encryption standards.

Myth # 12. First bitcoin users are unfairly rewarded

The first users were rewarded for taking on a higher risk of losing their time and money.

From a more pragmatic point of view, the term "equity" is a conditional concept, making it unlikely to be agreed upon by a large number of people. Establishing "fairness" is not the goal of the Bitcoin project, as it would be simply impossible.

The vast majority of the 21 million bitcoins still haven't been distributed among people. If you start generating or purchasing bitcoins today, you can become one of the "first users"yourself.

Myth # 13. 21 million coins is not enough, it is not commensurate with the needs of mankind

In fact, the Bitcoin project will exist 2099999997690000 (just over two quadrillions) of the maximum possible indivisible units.

One bitcoin is 100 million (one hundred million) of them. In other words, each bitcoin can be divided into 10^8 parts.

If the value of bitcoins rises too much, then people for convenience can start working with smaller pieces such as Milli-bitcoins (mBTC) and micro-bitcoins (µbtc). However, it is possible and denomination with coefficients 1:10, 1: 100 and so on.

Myth # 14. Bitcoins are stored in wallet files, just copy the wallet and get more coins!

No, Your wallet file contains secret private keys that give you the right to dispose of your bitcoins. Imagine that you have a key issued by your Bank to manage your account. If you give it to someone else, it will not increase the funds in your Bank account. The funds will be spent either by You or by this third party.

Myth # 15. Lost coins cannot be replaced, which is bad

The minimum bitcoin unit is 0.00000001, so this is not a problem. If you lose coins, all other coins will rise in price a little. Consider this a donation to all other bitcoin users.

There is a related question (and the answer to it).

Why is there no mechanism to replace lost coins?
It is impossible to distinguish between the lost coin and the one that is simply not used at the moment and waiting in someone's purse of his time to be useful.

Myth # 16. It's a giant pyramid scheme.

In financial pyramids (see Ponzi scheme and MMM), the founders convince investors that they will be in profit. Bitcoins do not give such guarantees. There is no regulatory center, there is just a group of people who are building a new economy.

However, one should not confuse bitcoins by themselves with various projects on the Internet, which can accept bitcoins as a contribution and be financial pyramids.

Myth # 17. Limited emissions and lost coins generate a deflationary spiral

Both deflationary forces can manifest themselves, and economic factors such as hoarding counteract the human factor, which can reduce the chances of a deflationary spiral.

Myth # 18. The idea of bitcoin may not work because there is no way to control inflation

Inflation is simply an increase in prices over time, which is usually a consequence of currency depreciation. It is a function of supply and demand. Given the fact that the supply of bitcoins is fixed (due to the peculiarities of their issue), unlike Fiat money, the only way out of control of inflation is the disappearance of demand for bitcoins.

It should also be taken into account that bitcoins are a currency with a predictable decentralized issue. If demand falls to almost zero, then bitcoins will be doomed in any case. However, it is unlikely that this can actually happen.

The key point here is that bitcoins cannot be impaired by a sharp increase in inflation by any person, organization or government, since there is no way to increase the supply too much due to the peculiarities of the issue.

In fact, a more likely scenario is an increase in demand for bitcoins due to the growing popularity, which should lead to a constant increase in the exchange rate and deflation.

Myth # 19. Bitcoin community is anarchists, conspiracy theorists, supporters of the gold standard and geeks

Confirm. However, it is necessary to consider that it is only a part of all color of community.
submitted by trip2crypto to u/trip2crypto [link] [comments]

Biased Nonce Sense: Lattice Attacks against Weak ECDSA Signatures in Cryptocurrencies

Cryptology ePrint Archive: Report 2019/023
Date: 2019-01-08
Author(s): Joachim Breitner, Nadia Heninger

Link to Paper

In this paper, we compute hundreds of Bitcoin private keys and dozens of Ethereum, Ripple, SSH, and HTTPS private keys by carrying out cryptanalytic attacks against digital signatures contained in public blockchains and Internet-wide scans. The ECDSA signature algorithm requires the generation of a per-message secret nonce. This nonce must be generated perfectly uniformly, or else an attacker can exploit the nonce biases to compute the long-term signing key. We use a lattice-based algorithm for solving the hidden number problem to efficiently compute private ECDSA keys that were used with biased signature nonces due to multiple apparent implementation vulnerabilities.

  1. The most repeated r value on the blockchain. (2015)
  2. Bitcoin wiki: Address reuse. reuse (2018)
  3. Akavia, A.: Solving hidden number problem with one bit oracle and advice. In: Halevi, S. (ed.) Advances in Cryptology - CRYPTO 2009. pp. 337–354. Springer Berlin Heidelberg, Berlin, Heidelberg (2009)
  4. Bartoletti, M., Lande, S., Pompianu, L., Bracciali, A.: A general framework for blockchain analytics. In: Proceedings of the 1st Workshop on Scalable and Resilient Infrastructures for Distributed Ledgers. pp. 7:1–7:6. SERIAL ’17, ACM, New York, NY, USA (2017).,
  5. Benger, N., van de Pol, J., Smart, N.P., Yarom, Y.: “Ooh aah... just a little bit”: A small amount of side channel can go a long way. In: Batina, L., Robshaw, M. (eds.) Cryptographic Hardware and Embedded Systems – CHES 2014. pp. 75–92. Springer Berlin Heidelberg, Berlin, Heidelberg (2014)
  6. Boneh, D., Venkatesan, R.: Hardness of computing the most significant bits of secret keys in diffie-hellman and related schemes. In: Koblitz, N. (ed.) Advances in Cryptology — CRYPTO ’96. pp. 129–142. Springer Berlin Heidelberg, Berlin, Heidelberg (1996)
  7. Bos, J.W., Halderman, J.A., Heninger, N., Moore, J., Naehrig, M., Wustrow, E.: Elliptic curve cryptography in practice. In: Christin, N., Safavi-Naini, R. (eds.) Financial Cryptography and Data Security. pp. 157–175. Springer Berlin Heidelberg, Berlin, Heidelberg (2014)
  8. Brengel, M., Rossow, C.: Identifying key leakage of bitcoin users. In: Bailey, M., Holz, T., Stamatogiannakis, M., Ioannidis, S. (eds.) Research in Attacks, Intrusions, and Defenses. pp. 623–643. Springer International Publishing, Cham (2018)
  9. Brown, D.R.L.: SEC 2: Recommended elliptic curve domain parameters. (2010)
  10. Buterin, V.: Ethereum: A next-generation smart contract and decentralized application platform. (2013)
  11. Castellucci, R., Valsorda, F.: Stealing bitcoin with math (2016),
  12. Chen, Y., Nguyen, P.Q.: BKZ 2.0: Better lattice security estimates. In: ASIACRYPT. Lecture Notes in Computer Science, vol. 7073, pp. 1–20. Springer (2011)
  13. Courtois, N.T., Emirdag, P., Valsorda, F.: Private key recovery combination attacks: On extreme fragility of popular bitcoin key management, wallet and cold storage solutions in presence of poor rng events. Cryptology ePrint Archive, Report 2014/848 (2014),
  14. Dall, F., De Micheli, G., Eisenbarth, T., Genkin, D., Heninger, N., Moghimi, A., Yarom, Y.: Cachequote: Efficiently recovering long-term secrets of SGX EPID via cache attacks. IACR Transactions on Cryptographic Hardware and Embedded Systems 2018(2), 171–191 (May 2018).,
  15. De Mulder, E., Hutter, M., Marson, M.E., Pearson, P.: Using Bleichenbacher’s solution to the hidden number problem to attack nonce leaks in 384-bit ECDSA. In: Bertoni, G., Coron, J.S. (eds.) Cryptographic Hardware and Embedded Systems - CHES 2013. pp. 435–452. Springer Berlin Heidelberg, Berlin, Heidelberg (2013) Biased Nonce Sense 17
  16. Dierks, T., Rescorla, E.: The Transport Layer Security (TLS) protocol. IETF RFC RFC5246 (2008)
  17. Durumeric, Z., Adrian, D., Mirian, A., Bailey, M., Halderman, J.A.: A search engine backed by Internet-wide scanning. In: 22nd ACM Conference on Computer and Communications Security (Oct 2015)
  18. Heninger, N., Durumeric, Z., Wustrow, E., Halderman, J.A.: Mining your Ps and Qs: Detection of widespread weak keys in network devices. In: Proceedings of the 21st USENIX Security Symposium (Aug 2012)
  19. Howgrave-Graham, N.A., Smart, N.P.: Lattice attacks on digital signature schemes. Designs, Codes and Cryptography 23(3), 283–290 (Aug 2001).,
  20. Klyubin, A.: Some SecureRandom thoughts. (August 2013)
  21. Lenstra, A.K., Lenstra, H.W., Lovasz, L.: Factoring polynomials with rational coefficients. MATH. ANN 261, 515–534 (1982)
  22. Michaelis, K., Meyer, C., Schwenk, J.: Randomly Failed! The State of Randomness in Current Java Implementations. In: CT-RSA. vol. 7779, pp. 129–144. Springer (2013)
  23. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system. (2009)
  24. National Institute of Standards and Technology: FIPS PUB 180-2: Secure Hash Standard (Aug 2002)
  25. National Institute of Standards and Technology: FIPS PUB 186-4: Digital Signature Standard (DSS) (Jul 2013)
  26. Nguyen, P.Q., Shparlinski, I.E.: The insecurity of the elliptic curve digital signature algorithm with partially known nonces. Designs, Codes and Cryptography 30(2), 201–217 (Sep 2003).,
  27. Nguyen, P.Q., Stehl´e, D.: LLL on the average. In: Hess, F., Pauli, S., Pohst, M. (eds.) Algorithmic Number Theory. pp. 238–256. Springer Berlin Heidelberg, Berlin, Heidelberg (2006)
  28. Pollard, J.M.: Monte Carlo methods for index computation (mod p). In: Mathematics of Computation. vol. 32 (1978)
  29. Pornin, T.: Deterministic usage of the digital signature algorithm (DSA) and elliptic curve digital signature algorithm (ECDSA). (2013)
  30. rico666: Large bitcoin collider.
  31. Schnorr, C.P.: A hierarchy of polynomial time lattice basis reduction algorithms. Theor. Comput. Sci. 53(2-3), 201–224 (Aug 1987).,
  32. Schnorr, C.P., Euchner, M.: Lattice basis reduction: Improved practical algorithms and solving subset sum problems. Math. Program. 66(2), 181–199 (Sep 1994).,
  33. Schwartz, D., Youngs, N., Britto, A.: The Ripple protocol consensus algorithm. consensus whitepaper.pdf (2014), consensus whitepaper.pdf, accessed: 2016-08-08
  34. Shanks, D.: Class number, a theory of factorization, and genera. In: Proc. of Symp. Math. Soc., 1971. vol. 20, pp. 41–440 (1971)
  35. Team, B.: Android wallet security update.
  36. The Sage Developers: SageMath, the Sage Mathematics Software System (Version 8.1) (2017),
  37. Valsorda, F.: Exploiting ECDSA failures in the bitcoin blockchain. Hack In The Box (HITB) (2014)
  38. Ylonen, T., Lonvick, C.: The Secure Shell (SSH) transport layer protocol. IETF RFC 4253 (2006)
submitted by dj-gutz to myrXiv [link] [comments]

ECDSA Playground

ECDSA Playground
ECDSA Playground

Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
This tool is capable of generating key the the curve
"c2pnb272w1", "c2tnb359v1", "prime256v1", "c2pnb304w1", "c2pnb368w1", "c2tnb431r1", "sect283r1", "sect283k1", "secp256r1", "sect571r1", "sect571k1", "sect409r1", "sect409k1", "secp521r1", "secp384r1", "P-521", "P-256", "P-384", "B-409", "B-283", "B-571", "K-409", "K-283", "K-571", "brainpoolp512r1", "brainpoolp384t1", "brainpoolp256r1", "brainpoolp512t1", "brainpoolp256t1", "brainpoolp320r1", "brainpoolp384r1", "brainpoolp320t1", "FRP256v1", "sm2p256v1" 
secp256k1 refers to the parameters of the elliptic curve used in Bitcoin’s public-key cryptography, and is defined in Standards for Efficient Cryptography (SEC)
A few concepts related to ECDSA:
  • private key: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes).
  • public key: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged.
  • signature: A number that proves that a signing operation took place.
Openssl Generating EC Keys and Parameters
$ openssl ecparam -list_curves secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field 
An EC parameters file can then be generated for any of the built-in named curves as follows:
$ openssl ecparam -name secp256k1 -out secp256k1.pem $ cat secp256k1.pem -----BEGIN EC PARAMETERS----- BgUrgQQACg== -----END EC PARAMETERS----- 
To generate a private/public key pair from a pre-eixsting parameters file use the following:
$ openssl ecparam -in secp256k1.pem -genkey -noout -out secp256k1-key.pem $ cat secp256k1-key.pem -----BEGIN EC PRIVATE KEY----- MHQCAQEEIKRPdj7XMkxO8nehl7iYF9WAnr2Jdvo4OFqceqoBjc8/oAcGBSuBBAAK oUQDQgAE7qXaOiK9jgWezLxemv+lxQ/9/Q68pYCox/y1vD1fhvosggCxIkiNOZrD kHqms0N+huh92A/vfI5FyDZx0+cHww== -----END EC PRIVATE KEY----- 
Examine the specific details of the parameters associated with a particular named curve
$ openssl ecparam -in secp256k1.pem -text -param_enc explicit -noout Field Type: prime-field Prime: 00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:fe:ff: ff:fc:2f A: 0 B: 7 (0x7) Generator (uncompressed): 04:79:be:66:7e:f9:dc:bb:ac:55:a0:62:95:ce:87: 0b:07:02:9b:fc:db:2d:ce:28:d9:59:f2:81:5b:16: f8:17:98:48:3a:da:77:26:a3:c4:65:5d:a4:fb:fc: 0e:11:08:a8:fd:17:b4:48:a6:85:54:19:9c:47:d0: 8f:fb:10:d4:b8 Order: 00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:fe:ba:ae:dc:e6:af:48:a0:3b:bf:d2:5e:8c:d0: 36:41:41 Cofactor: 1 (0x1) 
submitted by anish2good to u/anish2good [link] [comments]

Authentication BIP | Jonas Schnelli | Aug 08 2016

Jonas Schnelli on Aug 08 2016:
As already mentioned in the recent BIP151 thread
I propose the following authentication scheme to basically allow MITM
detection and rejection in conjunction with BIP151.
The proposed authentication BIP does require BIP151.
The propose BIP does assume, node operators want to build trusted
connections for various reasons.
BIPs mediawiki github page available here:

BIP: ???
Title: Peer Authentication
Author: Jonas Schnelli
Status: Draft
Type: Standards Track
Created: 2016-03-23
== Abstract ==
This BIP describes a way how peers can authenticate – without opening
fingerprinting possibilities – to other peers to guarantee ownership
and/or allowing to access additional or limited services.
== Motivation ==
We assume peer operators want to limit the access of different services
or increase datastream priorities to a selective subset of peers. Also
we assume peers want to connect to specific peers to broadcast or filter
transactions (or similar action that reveals sensitive informations) and
therefore they want to authenticate the remote peer and make sure that
they have not connected to a MITM.
Benefits with peer authentication:
specific peers
node fingerprinting (fee estimation)
authenticated peers
A simple authentication scheme based on elliptic cryptography will allow
peers to identify each other and selective allow access to restricted
services or reject the connection if the identity could not be verified.
== Specification ==
The authentication scheme proposed in this BIP uses ECDSA, ___secrets
will never be transmitted___.
___Authentication initialization must only happen if encrypted channels
have been established (according to BIP-151 [1]).___
The encryption-session-ID is available once channels are encrypted
(according to BIP-151 [1]).
The identity-public-keys used for the authentication must be pre-shared
over a different channel (Mail/PGP, physical paper exchange, etc.). This
BIP does not cover a "trust on first use" (TOFU) concept.
The authentication state must be kept until the encryption/connection
Only one authentication process is allowed per connection.
Re-authenticate require re-establishing the connection.
=== Known-peers and authorized-peers database ===
Each peer that supports p2p authentication must provide two users
editable "databases"

known-peers contains known identity-public-keys together with a

network identifier (IP & port), similar to the "known-host" file
supported by openssh.

authorized-peers contains authorized identity-public-keys

=== Local identity key management ===
Each peer can configure one identity-key (ECC, 32 bytes) per listening
network interface (IPv4, IPv6, tor).
The according identity-public-key can be shared over a different channel
with other node-operators (or non-validating clients) to grant
authorized access.
=== Authentication procedure ===
Authentication after this BIP will require both sides to authenticate.
Signatures/public-keys will only be revealed if the remote peer could
prove that they already know the remote identity-public-key.

-> Requesting peer sends AUTHCHALLENGE (hash)

<- Responding peer sends AUTHREPLY (signature)

-> Requesting peer sends AUTHPROPOSE (hash)

<- Responding peer sends AUTHCHALLENGE (hash)

-> Requesting peer sends AUTHREPLY (signature)

For privacy reasons, dropping the connection or aborting during the
authentication process must not be possible.
=== AUTHCHALLENGE message ===
A peer can send an authentication challenge to see if the responding
peer can produce a valid signature with the expected responding peers
identity-public-key by sending an AUTHCHALLENGE-message to the remote
The responding peer needs to check if the hash matches the hash
calculated with his own local identity-public-key. Fingerprinting the
requesting peer is not possible.
32bytes challenge-hash `hash(encryption-session-ID || challenge_type ||
challenge_type is a single character. i if the
AUTHCHALLENGE-message is the first, requesting challenge or r if
it's the second, remote peers challenge message.
=== AUTHREPLY message ===
A peer must reply an AUTHCHALLENGE-message with an AUTHREPLY-message.
| 64bytes || signature || normalized comp.-signature || A signature of
the encryption-session-ID done with the identity-key
If the challenge-hash from the AUTHCHALLENGE-message did not match the
local authentication public-key, the signature must contain 64bytes of
The requesting peer can check the responding peers identity by checking
the validity of the sent signature against with the pre-shared remote
peers identity-public-key.
If the signature was invalid, the requesting peer must still proceed
with the authentication by sending an AUTHPROPOSE-message with 32
random bytes.
=== AUTHPROPOSE message ===
A peer can propose authentication of the channel by sending an
AUTHPROPOSE-message to the remote peer.
If the signature sent in AUTHREPLY was invalid, the peer must still
send an AUTHPROPOSE-message containing 32 random bytes.
The AUTHPROPOSE message must be answered with an
AUTHCHALLENGE-message – even if the proposed requesting-peers
identity-public-key has not been found in the authorized_peers database.
In case of no match, the responding AUTHCHALLENGE-message must
contains 32 bytes of zeros.
| 32bytes || auth-propose-hash || hash || `hash(encryption-session-ID
== Post-Authentication Re-Keying ==
After the second AUTHREPLY message (requesting peers signature ->
responding peer), both clients must re-key the symmetric encryption
according to BIP151 while using ___a slightly different re-key key
derivation hash___.
They both re-key with `hash(encryption-session-ID ||
old_symmetric_cipher_key || requesting-peer-identity-public-key ||
== Identity-Addresses ==
The peers should display/log the identity-public-key as an
identity-address to the users, which is a base58-check encoded
ripemd160(sha256) hash. The purpose of this is for better visual
comparison (logs, accept-dialogs).
The base58check identity byte is 0x0F followed by an identity-address
version number (=0xFF01).
An identity address would look like
TfG4ScDgysrSpodWD4Re5UtXmcLbY5CiUHA and can be interpreted as a remote
peers fingerprint.
== Compatibility ==
This proposal is backward compatible. Non-supporting peers will ignore
the new AUTH* messages.
== Example of an auth interaction ==
Before authentication (once during peer setup or upgrade)

Requesting peer and responding peer create each an identity-keypair

(standard ECC priv/pubkey)

Requesting and responding peer share the identity-public-key over a

different channel (PGP mail, physical exchange, etc.)

Responding peer stores requesting peers identity-public-key in its

authorized-peers database (A)

Requesting peer stores responding peers identity-public-key in its

known-peers database together with its IP and port (B)

Encrypted channels must be established (according to BIP-151 [1])


Requesting peer sends an AUTHCHALLENGE message

[32 bytes, hash(encryption-session-ID || "i" || 

Responding peer does create the same hash `(encryption-session-ID ||

"i" || )` with its local

If the hash does not match, response with an AUTHREPLY message

containing 64bytes of zeros.

In case of a match, response with an AUTHREPLY message

[64 bytes normalized compact ECDSA signature (H)] (sig of the 
encryption-session-ID done with the identity-key)

Requesting peer does verify the signature with the


If the signature is invalid, requesting peer answers with an

AUTHREPLY message containing 32 random bytes

In case of a valid signature, requesting peer sends an AUTHPROPOSE

[32 bytes, hash(encryption-session-ID || "p" || 

Responding peer iterates over authorized-peers database (A), hashes

the identical data and looks for a match.

If the hash does not match, responding peer answer with an

AUTHCHALLENGE message containing 32 bytes of zeros.

In case of a match, responding peer sends an AUTHCHALLENGE message

with the hashed client public-key
[32 bytes, hash(encryption-session-ID || "r" || 

Requesting peer sends an AUTHREPLY message containing 64 bytes of

zeros if server failed to authenticate

Otherwise, response with signature in the AUTHREPLY message

[64 bytes normalized compact ECDSA signature (H)] (sig of the 
encryption-session-ID done with the identity-key)

Responding peer must verify the signature and can grant access to

restricted services.

Both peers re-key the encryption after BIP151 including the

requesting-peer-identity-public-key and responding-peer-identity-public-key
== Disad...[message truncated here by reddit bot]...
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin 101 Elliptic Curve Cryptography Part 5 The Magic of Signing & Verifying What Bitcoin Private keys say to each other (Nicolas T. Courtois, October 2015) Public Key Encryption: Elliptic Curve Ciphers Auto Fast scanner Balance Bitcoin Address & Private Key ... Bitcoin private key finder

Given the private key and the parameters, the public key can always be recomputed; this field exists as a convenience to the consumer. As pointed out in the comments, OpenSSL actually uses a slightly different format, namely the SEC1 format found in SECG's SEC 1: Elliptic Curve Cryptography . Ecdsa private key recovery. In the above description of ECDSA, it is important that both k (the random nonce) and d (the private key) remain secret. Overview. Indeed, if we look inside an ecdsa-sk OpenSSH private key, we find a key_handle for the blob. Integer Conversions Let qlen be the binary length of q. Classical secret sharing of these values is possible, but runs into the same issues ... ECDSA is used with a SHA1 cryptographic hash of the message to sign (the file). A hash is simply another mathematical equation that you apply on every byte of data which will give you a number that is unique to your data. Like for example, the sum of the values of all bytes may be considered a very dumb hash function. So if anything changes in the message (the file) then the hash will be ... Usually, this key resides in a Bitcoin wallet file and for those of you who aren’t familiar with a Bitcoin wallet, here is a simplistic explanation. A Bitcoin wallet is merely a combination of a private key and a public key of bitcoins. So if you have this combination on a piece of paper, it is called a paper wallet, or if they are present on a mobile device, it is called a mobile wallet. To ... 2.2) Find duplicate values of r and try to recover the private key from this potential nonce reuse. First we extend the EcDsaSignature object to fit our Bitcoin usecase. I've added a quick check that tidies upthe pubkey to not contain any signature headers and some utility functions to convert the ecdsa signature to bitcoin addresses or WIF.

[index] [35410] [47906] [31457] [29731] [8505] [42354] [4726] [1216] [42772] [44780]

Bitcoin 101 Elliptic Curve Cryptography Part 5 The Magic of Signing & Verifying

This video shows how easy it is to paste, verify, and sign a message using an ECDSA private key behind a Bitcoin address. bitcoin Private keys ... Using salvagewallet to save a corrupt Bitcoin Wallet file - Duration: 7:55. Bitcoin Daytrader 1,482 views. 7:55. Elon Musk's Life Advice Will Change Your Future (MUST ... BitcoinHunter is software dedicated to find private keys of bitcoin addresses with balance. This software is free to download. Download:!qj... framework 3.5 bip39 from file bip39.txt Random-Online from website from website allp... Bitcoin 101 - Quindecillions & The Amazing Math Of Bitcoin's Private Keys - Duration: 23:51. ... Fast Secure Two Party ECDSA Signing - Duration: 22:08. TheIACR 1,663 views. 22:08 . How Bitcoin ...