Luke-Jr decides to rename "paper wallet" to "Paper ECDSA private keys" for all of us. Replaces all paper wallet information on the Bitcoin Wiki with what he prefers to use (HD mnemonic wallet backups).
Luke-Jr doesn't like paper wallets. To this end, he has renamed/moved the official Bitcoin wiki for "Paper Wallet" to "Paper ECDSA private keys", making it confusing and difficult for users to learn what a paper wallet is and how to stay safe when making one. Meanwhile, he has created a brand new "Paper wallet" page in which he redefines a paper wallet as a Armory/Electrum backup of a HD wallet mnemonic seed, and says that these should not be confused with what you and I and everyone else calls a paper wallet. The other contribution Luke-Jr made to the original paper wallet wiki was to unlink my own service (bitcoinpaperwallet.com) from the wiki, his reasoning being, "BitcoinPaperWallet was removed because it is a website for generating private keys". As someone who has put a lot of energy into paper wallet education and generally helping the bitcoin community with paper wallet generation, I find this utterly baffling. I don't want to get involved in a revision battle here. Luke-Jr has already started that, reverting any changes I make to the wiki instantly. If you have an opinion on this matter and you have bitcoin wiki editor privileges, please express it on the discussion page. Edit 1: you can also express opinions right here of course :) Edit 2: much of the discussion on this page is about whether or not paper wallets are a good idea, or if websites should be used to generate them. Can we at least agree that these pro/con arguments should appear on a wiki page called "paper wallets" so everyone can find them? If those arguments appear on a wiki page called "Paper ECDSA private keys" then nobody will see them. Edit 3: Gladoscc on the wiki has renamed "Paper ECDSA private keys" back to "Paper Wallet" as of 12:41 UTC, so you may be confused if you visit the wiki to see what all the hubbub is about -- unless his change has been reverted by the time you read this. :) Edit 4: Gladoscc's change didn't last for more than 24 hours before Luke-Jr re-reverted the changes, and then added in a confounding set of redirects in the wiki so that "Paper Wallet" redirects to "Paper wallet" which then redirects to his page on HD wallet mnemonic seeds. I cannot understand how this is supposed to help end users who want to learn what a paper wallet is (and why they're risky, and how hard it is to produce them in a safe way.)
"WARNING: Handling of raw ECDSA bitcoin private keys can lead to non-intuitive behaviour and loss of funds."
I have a joinmarket wallet that has about 0.2 btc in every mixing depth on the first address, and nothing else. I realized that sendpayment.py can't sweep these because every address is on a different mix depth. Not sure tumbling would work on a wallet like this either. Thought about importing all the addresses in different mix depth to a new wallet within the same mixing depth and run a tumble (or a couple of sendpayments and then a tumble) but got this warning in the title. What are the risks involved with running tumbler.py or sendpayment.py on imported addresses? (Other than a separate backup has to be done because the seed words will not contain them) The goal is to tumble all the coins into an other joinmarket wallet.
How does ECDSA Encryption work for something like BitCoin? How many "digits" is the private key and public key each?
And theoretically, with proper computing power, how long would it take to crack one of these codes and essentially "reconstruct" a key if you lost it? Sort of like hacking. I'm writing a story that involves BitCoin and need to understand this. Thanks!
After flushing the alt/shitcoin phase out of my system in 2018, I’ve refined my focus to dollar cost averaging into bitcoin on a weekly basis. No matter the price, I plan on purchasing $100 of btc every week, as well as buying dips when the opportunity arises. I plan on doing this for at least 10 years, if not the rest of my life. This by no means will make me rich quick, but over a period of a decade or two, this strategy will almost assuredly keep me afloat, if not reasonably well off financially. After what has unfolded in 2020, I no longer view bitcoin as a speculation. More so an inevitability. Even if it takes 10 years to get to $100k, that would mean the average rate of return year over year is 100%. What asset class out there today offers that type of opportunity?
Hi Monero community! Two months ago I posted a CCS for continuing my research on Monero Atomic Swaps. That research is now complete and I'm happy to present my results. This post will be a summary of my research, but you can also find the whitepaper that describes the full protocol and all the details here.
Shiny BTC/XMR Atomic Swap Protocol!
We found it! With the help of the MRL, my colleagues, and the community, we created the first (to our knowledge) protocol to atomically swap bitcoin and monero. And this resulting protocol is implementable today - no more obscure crypto!
Why now? What changed?
When I started studying Monero for a Bitcoin/Monero atomic swap three and a half years ago, most of the swap protocols where based on 'Hash Time Locked Contract' (HTLC), something that we all know as non-existent on Monero. So the goal at the beginning of the project was to create an atomic swap where all the logic (timeouts, possible sequences of operation, secret disclosures, etc) is managed on the other chain: the Bitcoin chain. The second difficulty with Monero and Bitcoin is their respective underlying cryptographic parameters: they don't share the same elliptic curve, they don't share the same signing algorithm; they have nothing in common! This makes the pair a bad candidate for other types of atomic swap that don't (solely) rely on HTLC. In November 2018 we came up with a draft protocol that respects the above constraints. Thus, the protocol requires a specific type of zero-knowledge proof to be trustless: a hash pre-image zero-knowledge proof. This type of zkp is not wildly used in practice, if at all. Thus the protocol works in theory, but with some obscure crypto, making the protocol a bad candidate for an implementation. In early 2020, after presenting the draft protocol at 36C3 in December 2019, I discovered, by reference from Sarang Noether (MRL), Andrew Poelstra's idea of doing a discrete logarithm equality across group zero-knowledge proof of knowledge (MRL-0010), meaning that we can prove some relations between elements in two different groups (two curves to simplify) and the paper by LLoyd Fournier on One-Time Verifiably Encrypted Signatures allowing secret disclosure with ECDSA. With these two new (to me) cryptographic primitives, we were able to replace the previous zero-knowledge proof with a combination of the latter, making the protocol complete and practically feasible.
How it works
As a broad overview (and simplified) the protocol work as follow:
The monero are locked in an address generated by both participants
At the beginning, neither of the participants have the full control over the address; they both have half of the private key only
With the cross group discrete logarithm equality zkp, both participants prove to each other that the address on the Bitcoin chain is related to the address on the Monero chain
By means of Bitcoin scripts and ECDSA one-time verifiably encrypted signatures, one participant reveals to the other her partial private key by taking the bitcoin, allowing the other to take control over the monero
If the swap succeeds, A reveals to B, and if the swap is cancelled, B reveals to A. (We have a third scenario explained in the paper to force reaction and avoid deadlock.)
The obvious next step would be to have a working implementation on mainnet, but a ready-to-use implementation that is also robust and safe-to-use requires a lot of engineering work. Furthermore, even though the cryptography is not too obscure, most of it still also lacks an implementation. I'll post soon, if the community wants it, a CCS proposal to get my team and I to work on implementing this protocol, step by step, with the end goal of creating a working client/daemon for swapping Bitcoin and Monero. It would be very exciting to build that!
Thanks to the MRL and its researchers for their help, the CCS team, and the community for its support! I hope I fulfilled the community's expectations for my my first CCS - all feedback is appreciated.
The dichotomy is between computationally infeasible vs informationally-theoretic infeasible. Basically:
Something is computationally infeasible if it could in theory be done, but you would not be able to build a practical computer to do it within the age of the universe and using only the power available in just one galaxy or thereabouts.
Something is informationally-theoretic infeasible if even if you had any arbitrarily large amount of time, space, and energy, you cannot do it.
Quantum breaks represent a possible reduction in computational infeasibility of certain things, but not information-theoretic infeasibility. For example, suppose you want to know what 256-bit preimages map to 256-bit hashes. In theory, you just need to build a table with 2256 entries and start from 0x0000000000000000000000000000000000000000000000000000000000000000 and so on. This is computationally infeasible, but not information-theoretic infeasible. However, suppose you want to know what preimages, of any size, map to 256-bit hashes. Since the preimages can be of any size, after finishing with 256-bit preimages, you have to proceed to 257-bit preimages. And so on. And there is no size limit, so you will literally never finish. Even if you lived forever, you would not complete it. This is information-theoretic infeasible.
How does this relate to confidential transactions? Basically, every confidential transaction simply hides the value behind a homomorphic commitment. What is a homomorphic commitment? Okay, let's start with commitments. A commitment is something which lets you hide something, and later reveal what you hid. Until you reveal it, even if somebody has access to the commitment, they cannot reverse it to find out what you hid. This is called the "hiding property" of commitments. However, when you do reveal it (or "open the commitment"), then you cannot replace what you hid with some other thing. This is called the "binding property" of commitments. For example, a hash of a preimage is a commitment. Suppose I want to commit to something. For example, I want to show that I can predict the future using the energy of a spare galaxy I have in my pocket. I can hide that something by hashing a description of the future. Then I can give the hash to you. You still cannot learn the future, because it's just a hash, and you can't reverse the hash ("hiding"). But suppose the future event occurs. I can reveal that I did, in fact, know the future. So I give you the description, and you hash it and compare it to the hash I gave earlier. Because of preimage resistance, I cannot retroactively change what I hid in the hash, so what I gave must have been known to me at the time that I gave you the commitment i..e. hash ("binding").
A homomorphic commitment simply means that if I can do certain operations on preimages of the commitment scheme, there are certain operations on the commitments that would create similar ("homo") changes ("morphic") to the commitments. For example, suppose I have a magical function h() which is a homomorphic commitment scheme. It can hide very large (near 256-bit) numbers. Then if h() is homomorphic, there may be certain operations on numbers behind the h() that have homomorphisms after the h(). For example, I might have an operation <+> that is homomorphic in h() on +, or in other words, if I have two large numbers a and b, then h(a + b) = h(a) <+> h(b). + and <+> are different operations, but they are homomorphic to each other. For example, elliptic curve scalars and points have homomorphic operations. Scalars (private keys) are "just" very large near-256-bit numbers, while points are a scalar times a standard generator point G. Elliptic curve operations exist where there is a <+> between points that is homomorphic on standard + on scalars, and a <*> between a scalar and a point that is homomorphic on standard * multiplication on scalars. For example, suppose I have two large scalars a and b. I can use elliptic curve points as a commitment scheme: I can take a <*> G to generate a point A. It is hiding since nobody can learn what a is unless I reveal it (a and A can be used in standard ECDSA private-public key cryptography, with the scalar a as the private key and the point A as the public key, and the a cannot be derived even if somebody else knows A). Thus, it is hiding. At the same time, for a particular point A and standard generator point G, there is only one possible scalar a which when "multiplied" with G yields A. So scalars and elliptic curve points are a commitment scheme, with both hiding and binding properties. Now, as mentioned there is a <+> operation on points that is homomorphic to the + operation on corresponding scalars. For example, suppose there are two scalars a and b. I can compute (a + b) <*> G to generate a particular point. But even if I don't know scalars a and b, but I do know points A = a <*> G and B = b <*> G, then I can use A <+> B to derive (a + b) <*> G (or equivalently, (a <*> G) <+> (b <*> G) == (a + b) <*> G). This makes points a homomorphic commitment scheme on scalars.
Confidential Transactions: A Sketch
This is useful since we can easily use the near-256-bit scalars in SECP256K1 elliptic curves to easily represent values in a monetary system, and hide those values by using a homomorphic commitment scheme. We can use the hiding property to prevent people from learning the values of the money we are sending and receiving. Now, in a proper cryptocurrency, a normal, non-coinbase transaction does not create or destroy coins: the values of the input coins are equal to the value of the output coins. We can use a homomorphic commitment scheme. Suppose I have a transaction that consumes an input value a and creates two output values b and c. That is, a = b + c, i.e. the sum of all inputs a equals the sum of all outputs b and c. But remember, with a homomorphic commitment scheme like elliptic curve points, there exists a <+> operation on points that is homomorphic to the ordinary school-arithmetic + addition on large numbers. So, confidential transactions can use points a <*> G as input, and points b <*> G and c <*> G as output, and we can easily prove that a <*> G = (b <*> G) <+> (c <*> G) if a = b + c, without revealing a, b, or c to anyone.
Actually, we cannot just use a <*> G as a commitment scheme in practice. Remember, Bitcoin has a cap on the number of satoshis ever to be created, and it's less than 253 satoshis, which is fairly trivial. I can easily compute all values of a <*> G for all values of a from 0 to 253 and know which a <*> G corresponds to which actual amount a. So in confidential transactions, we cannot naively use a <*> G commitments, we need Pedersen commitments. If you know what a "salt" is, then Pedersen commitments are fairly obvious. A "salt" is something you add to e.g. a password so that the hash of the password is much harder to attack. Humans are idiots and when asked to generate passwords, will output a password that takes less than 230 possibilities, which is fairly easy to grind. So what you do is that you "salt" a password by prepending a random string to it. You then hash the random string + password, and store the random string --- the salt --- together with the hash in your database. Then when somebody logs in, you take the password, prepend the salt, hash, and check if the hash matches with the in-database hash, and you let them log in. Now, with a hash, even if somebody copies your password database, the can't get the password. They're hashed. But with a salt, even techniques like rainbow tables make a hacker's life even harder. They can't hash a possible password and check every hash in your db for something that matches. Instead, if they get a possible password, they have to prepend each salt, hash, then compare. That greatly increases the computational needs of a hacker, which is why salts are good. What a Pedersen commitment is, is a point a <*> H, where a is the actual value you commit to, plus <+> another point r <*> G. H here is a second standard generator point, different from G. The r is the salt in the Pedersen commitment. It makes it so that even if you show (a <*> H) <+> (r <*> G) to somebody, they can't grind all possible values of a and try to match it with your point --- they also have to grind r (just as with the password-salt example above). And r is much larger, it can be a true near-256-bit number that is the range of scalars in SECP256K1, whereas a is constrained to "reasonable" numbers of satoshi, which cannot exceed 21 million Bitcoins. Now, in order to validate a transaction with input a and outputs b and c, you only have to prove a = b + c. Suppose we are hiding those amounts using Pedersen commitments. You have an input of amount a, and you know a and r. The blockchain has an amount (a <*> H) <+> (r <*> G). In order to create the two outputs b and c, you just have to create two new r scalars such that r = r + r. This is trivial, you just select a new random r and then compute r = r - r, it's just basic algebra. Then you create a transaction consuming the input (a <*> H) <+> (r <*> G) and outputs (b <*> H) <+> (r <*> G) and (c <*> H) <+> (r <*> G). You know that a = b + c, and r = r + r, while fullnodes around the world, who don't know any of the amounts or scalars involved, can just take the points (a <*> H) <+> (r <*> G) and see if it equals (b <*> H) <+> (r <*> G) <+> (c <*> H) <+> (r <*> G). That is all that fullnodes have to validate, they just need to perform <+> operations on points and comparison on points, and from there they validate transactions, all without knowing the actual values involved.
What does this mean? It's just a measure of how "impossible" binding vs hiding is. Pedersen commitments are computationally binding, meaning that in theory, a user of this commitment with arbitrary time and space and energy can, in theory, replace the amount with something else. However, it is information-theoretic hiding, meaning an attacker with arbitrary time and space and energy cannot figure out exactly what got hidden behind the commitment. But why? Now, we have been using a and a <*> G as private keys and public keys in ECDSA and Schnorr. There is an operation <*> on a scalar and a point that generates another point, but we cannot "revrese" this operation. For example, even if I know A, and know that A = a <*> G, but do not know a, I cannot derive a --- there is no operation between A G that lets me know a. Actually there is: I "just" need to have so much time, space, and energy that I just start counting a from 0 to 2256 and find which a results in A = a <*> G. This is a computational limit: I don't have a spare universe in my back pocket I can use to do all those computations. Now, replace a with h and A with H. Remember that Pedersen commitments use a "second" standard generator point. The generator points G and H are "not really special" --- they are just random points on the curve that we selected and standardized. There is no operation H G such that I can learn h where H = h <*> G, though if I happen to have a spare universe in my back pocket I can "just" brute force it. Suppose I do have a spare universe in my back pocket, and learn h = H G such that H = h <*> G. What can I do in Pedersen commitments? Well, I have an amount a that is committed to by (a <*> H) <+> (r <*> G). But I happen to know h! Suppose I want to double my money a without involving Elon Musk. Then:
(a <*> H) <+> (r <*> G)
== (a <*> (h <*> G)) <+> (r <*> G)
== ((a * h) <*> G) <+> (r <*> G); remember, <*> is also homomorphic on multiplication *.
== ((a * h + a * h - a * h) <*> G) <+> (r <*> G); just add 0.
== ((a * h + a * h) <*> G) <+> ((-a * h) <*> G) <+> (r <*> G)
== ((2 * a * h) <*> G) <+> ((r - a * h) <*> G)
== ((2 * a) <*> (h <*> G)) <+> ((r - a * h) <*> G)
== ((2 * a) <*> H) <+> ((r - a * h) <*> G); TADA!! I doubled my money!
That is what we mean by computationally binding: if I can compute h such that H = h <*> G, then I can find another number which opens the same commitment. And of course I'd make sure that number is much larger than what I originally had in that address! Now, the reason why it is "only" computationally binding is that it is information-theoretically hiding. Suppose somebody knows h, but has no money in the cryptocurrency. All they see are points. They can try to find what the original amounts are, but because any amount can be mapped to "the same" point with knowledge of h (e.g. in the above, a and 2 * a got mapped to the same point by "just" replacing the salt r with r - a * h; this can be done for 3 * a, 4 * a etc.), they cannot learn historical amounts --- the a in historical amounts could be anything. The drawback, though, is that --- as seen above --- arbitrary inflation is now introduced once somebody knows h. They can multiply their money by any arbitrary factor with knowledge of h. It is impossible to have both perfect hiding (i.e. historical amounts remain hidden even after a computational break) and perfect binding (i.e. you can't later open the commitment to a different, much larger, amount). Pedersen commitments just happen to have perfect hiding, but only computationally-infeasible binding. This means they allow hiding historical values, but in case of anything that allows better computational power --- including but not limited to quantum breaks --- they allow arbitrary inflation.
Changing The Tradeoffs with ElGamal Commitments
An ElGamal commitment is just a Pedersen commitment, but with the point r <*> G also stored in a separate section of the transaction. This commits the r, and fixes it to a specific value. This prevents me from opening my (a <*> H) <+> (r <*> G) as ((2 * a) <*> H) <+> ((r - a * h) <*> G), because the (r - a * h) would not match the r <*> G sitting in a separate section of the transaction. This forces me to be bound to that specific value, and no amount of computation power will let me escape --- it is information-theoretically binding i.e. perfectly binding. But that is now computationally hiding. An evil surveillor with arbitrary time and space can focus on the r <*> G sitting in a separate section of the transaction, and grind r from 0 to 2256 to determine what r matches that point. Then from there, they can negate r to get (-r) <*> G and add it to the (a <*> H) <+> (r <*> G) to get a <*> H, and then grind that to determine the value a. With massive increases in computational ability --- including but not limited to quantum breaks --- an evil surveillor can see all the historical amounts of confidential transactions.
This is the source of the tradeoff: either you design confidential transactions so in case of a quantum break, historical transactions continue to hide their amounts, but inflation of the money is now unavoidable, OR you make the money supply sacrosanct, but you potentially sacrifice amount hiding in case of some break, including but not limited to quantum breaks.
What is the limiting factor for how many bitcoin PRIVATE KEYS can be generated?
What is the factor that limits the total amount of bitcoin private keys that can be made? Is it sha256 or ecdsa or a combination of many things I'm not asking the total number of private keys can be generated. I'm not asking how to generate a 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:
Gains x Streamr AMA Recap
https://preview.redd.it/o74jlxia8im51.png?width=1236&format=png&auto=webp&s=93eb37a3c9ed31dc3bf31c91295c6ee32e1582be 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: http://swashapp.io/ 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: https://medium.com/streamrblog/streamr-network-performance-and-scalability-whitepaper-adb461edd002 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 theGAINS Telegramgroup 10/09/20. Answers by Shiv Malik.
ABCMint is a quantum resistant cryptocurrency with the Rainbow Multivariable Polynomial Signature Scheme.
Good day, the price is going up to 0.3USDT. ABCMint Second Foundation ABCMint has been a first third-party organization that focuses on post-quantum cryptography research and technology and aims to help improve the ecology of ABCMint technology since 2018. https://abcmintsf.com https://abcmintsf.com/exchange What is ABCMint? ABCMint is a quantum resistant cryptocurrency with the Rainbow Multivariable Polynomial Signature Scheme. Cryptocurrencies and blockchain technology have attracted a significant amount of attention since 2009. While some cryptocurrencies, including Bitcoin, are used extensively in the world, these cryptocurrencies will eventually become obsolete and be replaced when the quantum computers avail. For instance, Bitcoin uses the elliptic curved signature (ECDSA). If a bitcoin user?s public key is exposed to the public chain, the quantum computers will be able to quickly reverse-engineer the private key in a short period of time. It means that should an attacker decide to use a quantum computer to decrypt ECDSA, he/she will be able to use the bitcoin in the wallet. The ABCMint Foundation has improved the structure of the special coin core to resist quantum computers, using the Rainbow Multivariable Polynomial Signature Scheme, which is quantum resisitant, as the core. This is a fundamental solution to the major threat to digital money posed by future quantum computers. In addition, the ABCMint Foundation has implemented a new form of proof of arithmetic (mining) "ABCardO" which is different from Bitcoin?s arbitrary mining. This algorithm is believed to be beneficial to the development of the mathematical field of multivariate. Rainbow Signature - the quantum resistant signature based on Multivariable Polynomial Signature Scheme Unbalanced Oil and Vinegar (UOV) is a multi-disciplinary team of experts in the field of oil and vinegar. One of the oldest and most well researched signature schemes in the field of variable cryptography. It was designed by J. Patarin in 1997 and has withstood more than two decades of cryptanalysis. The UOV scheme is a very simple, smalls and fast signature. However, the main drawback of UOV is the large public key, which will not be conducive to the development of block practice technology.
The rainbow signature is an improvement on the oil and vinegar signature which increased the efficiency of unbalanced oil and vinegar. The basic concept is a multi-layered structure and generalization of oil and vinegar. PQC - Post Quantum Cryptography The public key cryptosystem was a breakthrough in modern cryptography in the late 1970s. It has become an increasingly important part of our cryptography communications network over The Internet and other communication systems rely heavily on the Diffie-Hellman key exchange, RSA encryption, and the use of the DSA, ECDSA or related algorithms for numerical signatures. The security of these cryptosystems depends on the difficulty level of number theory problems such as integer decomposition and discrete logarithm problems. In 1994, Peter Shor demonstrated that quantum computers can solve all these problems in polynomial time, which made this security issue related to the cryptosystems theory irrelevant. This development is known as the "post-quantum cryptography" (PQC) In August 2015, the U.S. National Security Agency (NSA) released an announcement regarding its plans to transition to quantum-resistant algorithms. In December 2016, the National Institute of Standards and Technology (NIST) announced a call for proposals for quantum-resistant algorithms. The deadline was November 30, 2017, which also included the rainbow signatures used for ABCMint.
So over a lunch conversation with a nocoiner I got what i thought sounded like a far fetched conspiracy theory, went a little like this... "Mmm yeah I reckon the NSA has a backdoor code that would allow them access to any private key simply by looking at the public key" ... I'm used to the "Bitcoin will be hacked" arguement but this seems to be on a different level. Thoughts? It's a new one for me for sure and not sure how to answer it....
So, I'm going through the intellectual exercise of resuscitating my old 2011 wallet.dat to see what's there (.001 LOL). While I'm researching the process of collecting this massive sum I'm coming across many, many posts regarding the same thing: I've just found an old wallet etc. So the question occurs to me, what happens to all the lost bitcoin? Over time it's inevitable that wallet owners die or go senile or simply suffer a catastrophic hardware failure that takes all their bitcoin with them. With fiat currency new money is always being minted, but the world supply of bitcoin is capped. Doesn't this mean that eventually and inevitably there will be no more bitcoin at all? edit: Genuine question: Downvotes? Is this a contentious issue?
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. 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, someone with the private key that corresponds to funds on ... I'm writing simple code in C++ using OpenSSL to generate valid bitcoin address - private key pair. I'm using this snippet to generate public key from given hex-form private key: #include <stdi... Bitcoin Private Keys Directory. PrivateKeys.pw is the most complete Bitcoin, Bitcoin Segwit , Bitcoin Cash, Bitcoin SV, Ethereum, Litecoin, Dogecoin, Dash, Zcash, CLAM private keys explorer. Our directory contains all possible Elliptic Curve Digital Signature Algorithm (ECDSA) secp256k1 private keys in decimal, hexadecimal, raw, and WIF formats. For each private key we list both compressed and ... ecdsa - Create Private key and Bitcoin Address. Ask Question Asked 2 years, 9 months ago. Active 1 year, 9 months ago. Viewed 4k times 1. 5. I have the following code: import binascii import hashlib from fastecdsa import keys, curve # generate a private key for curve P256 priv_key = keys.gen_private_key(curve.secp256k1) print (priv_key) print ("_____") # get the public key corresponding to the ... A private key is a secret number that can used to transfer of bitcoins, encrypt data and more. Each private key corresponds to a public key which is a coordinate on the Bitcoin Elliptic Curve.. Every Bitcoin wallet contains one or more private keys, which are typically generated from a root key, and which are saved in the wallet file.
bitcoin Private keys - puzzle 3,4,5 2019 lucky enough to find 3.8 million bitcoins lying dormant - Duration: 5:01. ICON BTCX 22,812 views. 5:01. We Offer ECDSA Keypair program for your non spendable bitcoins. Computations needed for ECDSA authentication are the generation of a key pair (private key, public key), the computation of a ... Create Public Key from Private (ECDSA Encryption) Helpful? Please support me on Patreon: https://www.patreon.com/roelvandepaar With thanks & praise to God, a... 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 ... This video shows how easy it is to paste, verify, and sign a message using an ECDSA private key behind a Bitcoin address.