How does ECDSA work in Bitcoin. ECDSA (‘Elliptical Curve ...

Technical: Confidential Transactions and Their Implementation Tradeoffs

As requested by estradata here: https://old.reddit.com/Bitcoin/comments/iylou9/what_are_some_of_the_latest_innovations_in_the/g6heez1/
It is a general issue that crops up at the extremes of cryptography, with quantum breaks being just one of the extremes of (classical) cryptography.

Computational vs Information-Theoretic

The dichotomy is between computationally infeasible vs informationally-theoretic infeasible. Basically:
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.

Commitments

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

Homomorphic Commitments

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.

Pedersen Commitments

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[0] + r[1]. This is trivial, you just select a new random r[0] and then compute r[1] = r - r[0], it's just basic algebra.
Then you create a transaction consuming the input (a <*> H) <+> (r <*> G) and outputs (b <*> H) <+> (r[0] <*> G) and (c <*> H) <+> (r[1] <*> G). You know that a = b + c, and r = r[0] + r[1], 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[0] <*> G) <+> (c <*> H) <+> (r[1] <*> 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.

Computational Binding, Information-Theoretic Hiding

Like all commitments, Pedersen Commitments are binding and hiding.
However, there are really two kinds of commitments:
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:
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.

Conclusion

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.
submitted by almkglor to Bitcoin [link] [comments]

Ceterum censeo: In some yet undefined future - the halving must be removed. The question is not: if, but when (and how)

Bitcoin's mining ecosystem is saturated. Period.
The ASIC race has weakened as it has moved closer to the technological limits - achieving some kind of fragile balance. The best proof of this is Bitmain's search for new areas (vide: AI research)
After more than a decade, we are smarter than Satoshi at least in one area - we have the knowledge acquired over these more than ten years ...
"Bitcoin should have had a 0.1% or 1% monetary inflation tax to pay for security." (Peter Todd): https://www.google.com/search?q=peter+todd+inflation
If someone cannot accept the inevitability of this right now - let him think if he would change his mind while he sees the consecutive halvings - after which the network hashrate drops half by half - and does not return to the previous level, ever... (I suppose we can see that process in 4 years already...)
And the trigger could be like this (of course after general consensus):
That would be an "organoleptic" determination of the optimal inflation rate for the Bitcoin network - and there is simply no better way to determine it. Just don't belive such simplification, when is hard to find an optimum for something - the ultimate solution is zero. It's not.
Remember, that Bitcoin is not an entity detached from the reality. There are various limitations, e.g. nanometer-based technological processes limitations, there is a finite amount of cheap energy that can be obtained on a global scale, etc.) Bitcoin functions in certain realities - whether we like it or not.
Sooner or later the situation described above will get us. It is worth to be prepared mentally for it - and not to start another war, but rather discuss it calmly. If, for example, 90% of the community considers that something is necessary for the development of bitcoin - such a change will take place.
For example, the theoretical exchange of ECDSA due to the threat of quantum computers - acceptance would take place at an express rate. It will be similar in this matter. Just it shouldn't be too late for corrective action.
The small inflation rate, decreasing continuosly and slowly but never to zero, and last but not least: determined by reality - seems to be the most proper measure in this case.
Ceterum censeo...
EDIT: If:
a) tx fees are able to keep miners mining - perfect
b) miners are pushed out by consecutive halvings - not perfect
What I proposed is unbiased way for checking that (bitcoin ecosystem overall health):
if(current_network_hashrate < network_hashrate_4_years_ago) {
do_something();
}
else do_nothing();
submitted by jk_14r to Bitcoin [link] [comments]

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

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 the GAINS Telegram group 10/09/20. Answers by Shiv Malik.
submitted by thamilton5 to streamr [link] [comments]

08-13 21:45 - 'Building the Infrastructure for the Future Decentralized Financial Market, Coinbase Included HBTC.Com Debut DeFi Project - Nest Protocol' (self.Bitcoin) by /u/Nest_Fan removed from /r/Bitcoin within 24-34min

'''
As the world’s leading regulatory compliant digital asset exchange, Coinbase sets one of the most stringent requirements for digital asset listing which includes technical evaluation of projects, legal and risk analysis, market supply and demand analysis, and crypto-economics. Coinbase holds a strong reputation in the digital asset industry, and thus the “Coinbase Standard” is considered as the industry benchmark for other digital asset projects, and the market has even seen the “Coinbase effect”.
On July 25 2020, Coinbase quietly launched the pricing chart of a decentralized oracle project, NEST Protocol (NEST), into its portal. Although Coinbase has yet to announce the inclusion of the project in its evaluation list, it represents a keen interest in the DeFi sector, and particularly in the DeFi price oracle projects.
NEST Protocol is the rising star in the decentralized price oracle sector
Decentralized financial services offered by the current mainstream DeFi platforms such as MakerDAO, Compound, dYdX, etc. rely heavily on the market data provided by the oracle projects. Oracle projects act as reliable information sources to feed these price data to other DeFi Projects, connecting the price data from the centralized world to the DeFi space. As such, the price oracle is an integral part of the decentralized financial services infrastructure.
Traditionally, the price oracle collects data from different platforms and feeds these data points to the DeFi space to create data reference points to enable them to function properly. However, many problems currently exist in the DeFi space, for example, blockchain network congestion, malicious attacks, wild market fluctuations, and other factors that may cause the data given by the price oracle to deviate from the true market data. These ultimately cause users to trade on wrong information in the DeFi space and increases such transaction costs.
Decentralized finance requires a fast, secure, and reliable price oracle. The birth of the decentralized price oracle is the embodiment of the blockchain industry’s thinking, and the current market projects offering decentralized price oracle services which includes NEST Protocol, Chainlink, Band Protocol, Tellor, Witness, Oraclize, and many others.
The innovation of NEST-Price is that every data point has been agreed upon by market validators, in line with the blockchain consensus mechanism. NEST-Price synchronizes the off-chain price in a highly decentralized manner, creating real and valid price data on-chain. This is the unique differentiator between NEST-Price and other price oracles.
Compared with other price oracle projects, NEST also has other features and advantages, such as the proposed peer-to-peer quotation matching as well as its unique verifier verification structure, making NEST more resilient to malicious attacks, resulting in a more decentralized network, and it’s on-chain prices closer to the fair market price. All of this has resulted in the NEST Protocol becoming a rising star in the DeFi price oracle sector. HBTC.com selects high-quality projects to list and partnering with NEST to promote the development of DeFi ecosystem
During the selection of quality assets, exchanges like [HBTC.com]1 and Coinbase adhere to the principle of a rigorous selection of assets from different projects to enable a proper range of digital assets. At the same time, in order to solve existing pain points in the digital asset industry, which currently lacks a market-making management solution, HBTC.com also has launched its own “coin listing crowdsourcing [liquidity initiative]2 “, redefining the exchange market making model.
HBTC.com, through its coin listing strategy, effectively reduces the problem of low liquidity in the early stages of high-quality projects, ensuring the smoothness of the user experience, and achieves a win-win situation for traders, the community, and the respective trading platform. These initiatives, coupled with reliable user protection and a responsible attitude, have earned a positive reputation among users.
Since its inception, the HBTC.com exchange has been committed to the discovery of both quality and promising digital asset projects. At a time when DeFi is growing rapidly, HBTC.com has a unique perspective for the decentralized price oracle sector and has prioritized NEST as a premium partner to debut the project alongside with its global branding upgrade. In addition, HBTC.com has [100% proof of reserves]3 for traders to validate the existence of assets via the Merkle tree, which brings transparency to the extreme.
In May 2020, NEST token delivered a 883.29% of return, at its peak, after its global debut on HBTC.com. At present, HBTC Exchange addresses holding NEST token accounts in a total of 141 million, ranked first in the overall network. At the same time, the HBTC Exchange network exclusively releases NEST staking mining and data show that NEST 24-hour turnover has reached $20.4 million.
Post-listing of the NEST token, HBTC.com has also listed DeFi projects such as DF, OKS, NEST, SWTH, JST, NVT, and other DeFi projects with market potential; some projects have achieved astonishing performance in the secondary market.
HBTC.com’s path to DeFi: developing public chains to prepare for the future ecosystem breakout.
In terms of the DeFi product and ecosystem infrastructure, HBTC has deployed HBTC Chain since launched in 2018, an infrastructure designed for decentralized finance and DeFi business with patented Bluehelix decentralized cross-chain clearing and custody technology.
The HBTC Chain is the DeFi ecosystem infrastructure that the team has spent a significant amount of effort to build. It is based on decentralization and community consensus and integrates cryptography and blockchain technologies to support decentralized association-based governance capabilities at the technical level. Based on decentralized key management, combining various cryptography tools including ECDSA, commitment, zero-knowledge proof, and multi-party computation, It implements the distributed private key generation and signature for cross-chain assets among all validators. On top of that, this technology can realize light-weight and non-intrusive cross-chain asset custody. On the clearing layer, HBTC Chain employs BHPOS consensus and horizontal sharding mechanisms to achieve high-performing transaction clearing, and implementation of OpenDex protocol to help the development of the DeFi ecosystem.
In addition, with the success experience of Bluehelix Cloud SaaS and white label solutions and the HBTC Brokerage system, HBTC’s public chain also innovatively supports CEX+DEX mixed matchmaking model and OpenDex protocol and proposes the three-tier node system which consists of standard node + consensus node + core node. This structure provides HBTC public chain certain advantages in terms of performance and cross-chain transactions. Users can easily establish a DEX with OpenDex protocol at nearly zero cost, and all DEX will share the liquidity and support customized user interface and trading parameters. The trading experience can be completely comparable to centralized spot exchanges.
With the launch of its test network, it is now possible to develop various DeFi applications on the HBTC public chain, such as decentralized swap, so that private keys are not controlled by any party; no KYC, which can prevent personal information leakage; and asset security through the setting of invalidation, cancellation of transactions and other functions, cross-chain asset mappings, such as the ability to issue cross-chain cBTC or other chain tokens, fully decentralized asset mapping contracts, and 100% reserves.
Conclusion
In the past few months, the DeFi market has been extremely active, the price of DeFi tokens has been rising, and a new round of competition with the centralized exchanges has started. HBTC Chain relies on the powerful technology of Bluehelix and [HBTC.com]1 , giving all public chains the ability to interconnect, and put into both DeFi and SaaS levels. Undoubtedly, as one of the first exchanges to build the DeFi ecosystem, HBTC is leading the breakout in the current DeFi craze and has now become the first choice of users to engage with quality DeFi projects.

From BITCOIN news([[link]6 )
'''
Building the Infrastructure for the Future Decentralized Financial Market, Coinbase Included HBTC.Com Debut DeFi Project - Nest Protocol
Go1dfish undelete link
unreddit undelete link
Author: Nest_Fan
1: *btc*com/ 2: m*diu**com/hbt***ficia*/hbt*-launches-ba**liquidi*y***owd*unding-li*ti*g-plan-redefine-t*e*exch*nge-*i*tin**m*d*l***6*58f*f1d* 3: hbtc.ze**e*k*co*/hc/*n-us/a**icles/3***46287754-HBT*-10*-*ro***of*Reserve 4: hb*c.co*/ 5: n*ws.bitcoin.c*m*bu*ld*ng-t**-infr***ructur*-f*r-the*fut*re*decen**ali**d-*inanc*a*-market-coi**as*-*ncluded-h*t*-*o*-*ebut-de**-p*oject-n*st-**otocol* 6: n**s.bit*oin*com/building-th*-infrast*u*ture*for-t*e-fut****decen**a**zed**inancia*-m*rket-coinbase-**c*uded-*b*c-c***deb***defi-**oject-*est**r**ocol/]^^5
Unknown links are censored to prevent spreading illicit content.
submitted by removalbot to removalbot [link] [comments]

ECDSA In Bitcoin

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

How ECDSA was incorporated into Bitcoin

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

Basic principles of ECDSA

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

Replacement of ECDSA

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

ECDSA In Bitcoin

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

How ECDSA was incorporated into Bitcoin

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

Basic principles of ECDSA

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

Replacement of ECDSA

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

Google and NASA have reached quantum supremacy in a year collaboration. What does it mean for future blockchain security?

As can be read in this article. Although quantum supremacy simply means that at least 1 specific problem has been proven to be solved by a quantum computer that can't be solved (in a realistic timeframe) by any existing classical computer, it is a very important milestone. Many have been skeptical on crossing this milestone at all.
Supremacy does not mean that current cryptography is at risk tomorrow. It does however prove quantum computing is real, and has advantage over classical computers in certain tasks as has always been thought. For blockchain this means that in the future, Shor's algorithm could be used to break ECDSA, the signature scheme that is used in most blockchain. This signature scheme can be upgraded to a quantum resistant signature scheme. It does come with specific challenges though. As opposed to banks, websites, government systems, email services etc, blockchain is decentralized. That makes the following challenges exclusive blockchain challenges:
Consider the full analysis on this subject here
Blockchains that implement quantum resistance from the very beginning, from genesis block, will not face these challenges. See for example QRL which has launched over a year ago.
submitted by QRCollector to CryptoCurrency [link] [comments]

Bitcoin (BTC)A Peer-to-Peer Electronic Cash System.

Bitcoin (BTC)A Peer-to-Peer Electronic Cash System.
  • Bitcoin (BTC) is a peer-to-peer cryptocurrency that aims to function as a means of exchange that is independent of any central authority. BTC can be transferred electronically in a secure, verifiable, and immutable way.
  • Launched in 2009, BTC is the first virtual currency to solve the double-spending issue by timestamping transactions before broadcasting them to all of the nodes in the Bitcoin network. The Bitcoin Protocol offered a solution to the Byzantine Generals’ Problem with a blockchain network structure, a notion first created by Stuart Haber and W. Scott Stornetta in 1991.
  • Bitcoin’s whitepaper was published pseudonymously in 2008 by an individual, or a group, with the pseudonym “Satoshi Nakamoto”, whose underlying identity has still not been verified.
  • The Bitcoin protocol uses an SHA-256d-based Proof-of-Work (PoW) algorithm to reach network consensus. Its network has a target block time of 10 minutes and a maximum supply of 21 million tokens, with a decaying token emission rate. To prevent fluctuation of the block time, the network’s block difficulty is re-adjusted through an algorithm based on the past 2016 block times.
  • With a block size limit capped at 1 megabyte, the Bitcoin Protocol has supported both the Lightning Network, a second-layer infrastructure for payment channels, and Segregated Witness, a soft-fork to increase the number of transactions on a block, as solutions to network scalability.

https://preview.redd.it/s2gmpmeze3151.png?width=256&format=png&auto=webp&s=9759910dd3c4a15b83f55b827d1899fb2fdd3de1

1. What is Bitcoin (BTC)?

  • Bitcoin is a peer-to-peer cryptocurrency that aims to function as a means of exchange and is independent of any central authority. Bitcoins are transferred electronically in a secure, verifiable, and immutable way.
  • Network validators, whom are often referred to as miners, participate in the SHA-256d-based Proof-of-Work consensus mechanism to determine the next global state of the blockchain.
  • The Bitcoin protocol has a target block time of 10 minutes, and a maximum supply of 21 million tokens. The only way new bitcoins can be produced is when a block producer generates a new valid block.
  • The protocol has a token emission rate that halves every 210,000 blocks, or approximately every 4 years.
  • Unlike public blockchain infrastructures supporting the development of decentralized applications (Ethereum), the Bitcoin protocol is primarily used only for payments, and has only very limited support for smart contract-like functionalities (Bitcoin “Script” is mostly used to create certain conditions before bitcoins are used to be spent).

2. Bitcoin’s core features

For a more beginner’s introduction to Bitcoin, please visit Binance Academy’s guide to Bitcoin.

Unspent Transaction Output (UTXO) model

A UTXO transaction works like cash payment between two parties: Alice gives money to Bob and receives change (i.e., unspent amount). In comparison, blockchains like Ethereum rely on the account model.
https://preview.redd.it/t1j6anf8f3151.png?width=1601&format=png&auto=webp&s=33bd141d8f2136a6f32739c8cdc7aae2e04cbc47

Nakamoto consensus

In the Bitcoin network, anyone can join the network and become a bookkeeping service provider i.e., a validator. All validators are allowed in the race to become the block producer for the next block, yet only the first to complete a computationally heavy task will win. This feature is called Proof of Work (PoW).
The probability of any single validator to finish the task first is equal to the percentage of the total network computation power, or hash power, the validator has. For instance, a validator with 5% of the total network computation power will have a 5% chance of completing the task first, and therefore becoming the next block producer.
Since anyone can join the race, competition is prone to increase. In the early days, Bitcoin mining was mostly done by personal computer CPUs.
As of today, Bitcoin validators, or miners, have opted for dedicated and more powerful devices such as machines based on Application-Specific Integrated Circuit (“ASIC”).
Proof of Work secures the network as block producers must have spent resources external to the network (i.e., money to pay electricity), and can provide proof to other participants that they did so.
With various miners competing for block rewards, it becomes difficult for one single malicious party to gain network majority (defined as more than 51% of the network’s hash power in the Nakamoto consensus mechanism). The ability to rearrange transactions via 51% attacks indicates another feature of the Nakamoto consensus: the finality of transactions is only probabilistic.
Once a block is produced, it is then propagated by the block producer to all other validators to check on the validity of all transactions in that block. The block producer will receive rewards in the network’s native currency (i.e., bitcoin) as all validators approve the block and update their ledgers.

The blockchain

Block production

The Bitcoin protocol utilizes the Merkle tree data structure in order to organize hashes of numerous individual transactions into each block. This concept is named after Ralph Merkle, who patented it in 1979.
With the use of a Merkle tree, though each block might contain thousands of transactions, it will have the ability to combine all of their hashes and condense them into one, allowing efficient and secure verification of this group of transactions. This single hash called is a Merkle root, which is stored in the Block Header of a block. The Block Header also stores other meta information of a block, such as a hash of the previous Block Header, which enables blocks to be associated in a chain-like structure (hence the name “blockchain”).
An illustration of block production in the Bitcoin Protocol is demonstrated below.

https://preview.redd.it/m6texxicf3151.png?width=1591&format=png&auto=webp&s=f4253304912ed8370948b9c524e08fef28f1c78d

Block time and mining difficulty

Block time is the period required to create the next block in a network. As mentioned above, the node who solves the computationally intensive task will be allowed to produce the next block. Therefore, block time is directly correlated to the amount of time it takes for a node to find a solution to the task. The Bitcoin protocol sets a target block time of 10 minutes, and attempts to achieve this by introducing a variable named mining difficulty.
Mining difficulty refers to how difficult it is for the node to solve the computationally intensive task. If the network sets a high difficulty for the task, while miners have low computational power, which is often referred to as “hashrate”, it would statistically take longer for the nodes to get an answer for the task. If the difficulty is low, but miners have rather strong computational power, statistically, some nodes will be able to solve the task quickly.
Therefore, the 10 minute target block time is achieved by constantly and automatically adjusting the mining difficulty according to how much computational power there is amongst the nodes. The average block time of the network is evaluated after a certain number of blocks, and if it is greater than the expected block time, the difficulty level will decrease; if it is less than the expected block time, the difficulty level will increase.

What are orphan blocks?

In a PoW blockchain network, if the block time is too low, it would increase the likelihood of nodes producingorphan blocks, for which they would receive no reward. Orphan blocks are produced by nodes who solved the task but did not broadcast their results to the whole network the quickest due to network latency.
It takes time for a message to travel through a network, and it is entirely possible for 2 nodes to complete the task and start to broadcast their results to the network at roughly the same time, while one’s messages are received by all other nodes earlier as the node has low latency.
Imagine there is a network latency of 1 minute and a target block time of 2 minutes. A node could solve the task in around 1 minute but his message would take 1 minute to reach the rest of the nodes that are still working on the solution. While his message travels through the network, all the work done by all other nodes during that 1 minute, even if these nodes also complete the task, would go to waste. In this case, 50% of the computational power contributed to the network is wasted.
The percentage of wasted computational power would proportionally decrease if the mining difficulty were higher, as it would statistically take longer for miners to complete the task. In other words, if the mining difficulty, and therefore targeted block time is low, miners with powerful and often centralized mining facilities would get a higher chance of becoming the block producer, while the participation of weaker miners would become in vain. This introduces possible centralization and weakens the overall security of the network.
However, given a limited amount of transactions that can be stored in a block, making the block time too longwould decrease the number of transactions the network can process per second, negatively affecting network scalability.

3. Bitcoin’s additional features

Segregated Witness (SegWit)

Segregated Witness, often abbreviated as SegWit, is a protocol upgrade proposal that went live in August 2017.
SegWit separates witness signatures from transaction-related data. Witness signatures in legacy Bitcoin blocks often take more than 50% of the block size. By removing witness signatures from the transaction block, this protocol upgrade effectively increases the number of transactions that can be stored in a single block, enabling the network to handle more transactions per second. As a result, SegWit increases the scalability of Nakamoto consensus-based blockchain networks like Bitcoin and Litecoin.
SegWit also makes transactions cheaper. Since transaction fees are derived from how much data is being processed by the block producer, the more transactions that can be stored in a 1MB block, the cheaper individual transactions become.
https://preview.redd.it/depya70mf3151.png?width=1601&format=png&auto=webp&s=a6499aa2131fbf347f8ffd812930b2f7d66be48e
The legacy Bitcoin block has a block size limit of 1 megabyte, and any change on the block size would require a network hard-fork. On August 1st 2017, the first hard-fork occurred, leading to the creation of Bitcoin Cash (“BCH”), which introduced an 8 megabyte block size limit.
Conversely, Segregated Witness was a soft-fork: it never changed the transaction block size limit of the network. Instead, it added an extended block with an upper limit of 3 megabytes, which contains solely witness signatures, to the 1 megabyte block that contains only transaction data. This new block type can be processed even by nodes that have not completed the SegWit protocol upgrade.
Furthermore, the separation of witness signatures from transaction data solves the malleability issue with the original Bitcoin protocol. Without Segregated Witness, these signatures could be altered before the block is validated by miners. Indeed, alterations can be done in such a way that if the system does a mathematical check, the signature would still be valid. However, since the values in the signature are changed, the two signatures would create vastly different hash values.
For instance, if a witness signature states “6,” it has a mathematical value of 6, and would create a hash value of 12345. However, if the witness signature were changed to “06”, it would maintain a mathematical value of 6 while creating a (faulty) hash value of 67890.
Since the mathematical values are the same, the altered signature remains a valid signature. This would create a bookkeeping issue, as transactions in Nakamoto consensus-based blockchain networks are documented with these hash values, or transaction IDs. Effectively, one can alter a transaction ID to a new one, and the new ID can still be valid.
This can create many issues, as illustrated in the below example:
  1. Alice sends Bob 1 BTC, and Bob sends Merchant Carol this 1 BTC for some goods.
  2. Bob sends Carols this 1 BTC, while the transaction from Alice to Bob is not yet validated. Carol sees this incoming transaction of 1 BTC to him, and immediately ships goods to B.
  3. At the moment, the transaction from Alice to Bob is still not confirmed by the network, and Bob can change the witness signature, therefore changing this transaction ID from 12345 to 67890.
  4. Now Carol will not receive his 1 BTC, as the network looks for transaction 12345 to ensure that Bob’s wallet balance is valid.
  5. As this particular transaction ID changed from 12345 to 67890, the transaction from Bob to Carol will fail, and Bob will get his goods while still holding his BTC.
With the Segregated Witness upgrade, such instances can not happen again. This is because the witness signatures are moved outside of the transaction block into an extended block, and altering the witness signature won’t affect the transaction ID.
Since the transaction malleability issue is fixed, Segregated Witness also enables the proper functioning of second-layer scalability solutions on the Bitcoin protocol, such as the Lightning Network.

Lightning Network

Lightning Network is a second-layer micropayment solution for scalability.
Specifically, Lightning Network aims to enable near-instant and low-cost payments between merchants and customers that wish to use bitcoins.
Lightning Network was conceptualized in a whitepaper by Joseph Poon and Thaddeus Dryja in 2015. Since then, it has been implemented by multiple companies. The most prominent of them include Blockstream, Lightning Labs, and ACINQ.
A list of curated resources relevant to Lightning Network can be found here.
In the Lightning Network, if a customer wishes to transact with a merchant, both of them need to open a payment channel, which operates off the Bitcoin blockchain (i.e., off-chain vs. on-chain). None of the transaction details from this payment channel are recorded on the blockchain, and only when the channel is closed will the end result of both party’s wallet balances be updated to the blockchain. The blockchain only serves as a settlement layer for Lightning transactions.
Since all transactions done via the payment channel are conducted independently of the Nakamoto consensus, both parties involved in transactions do not need to wait for network confirmation on transactions. Instead, transacting parties would pay transaction fees to Bitcoin miners only when they decide to close the channel.
https://preview.redd.it/cy56icarf3151.png?width=1601&format=png&auto=webp&s=b239a63c6a87ec6cc1b18ce2cbd0355f8831c3a8
One limitation to the Lightning Network is that it requires a person to be online to receive transactions attributing towards him. Another limitation in user experience could be that one needs to lock up some funds every time he wishes to open a payment channel, and is only able to use that fund within the channel.
However, this does not mean he needs to create new channels every time he wishes to transact with a different person on the Lightning Network. If Alice wants to send money to Carol, but they do not have a payment channel open, they can ask Bob, who has payment channels open to both Alice and Carol, to help make that transaction. Alice will be able to send funds to Bob, and Bob to Carol. Hence, the number of “payment hubs” (i.e., Bob in the previous example) correlates with both the convenience and the usability of the Lightning Network for real-world applications.

Schnorr Signature upgrade proposal

Elliptic Curve Digital Signature Algorithm (“ECDSA”) signatures are used to sign transactions on the Bitcoin blockchain.
https://preview.redd.it/hjeqe4l7g3151.png?width=1601&format=png&auto=webp&s=8014fb08fe62ac4d91645499bc0c7e1c04c5d7c4
However, many developers now advocate for replacing ECDSA with Schnorr Signature. Once Schnorr Signatures are implemented, multiple parties can collaborate in producing a signature that is valid for the sum of their public keys.
This would primarily be beneficial for network scalability. When multiple addresses were to conduct transactions to a single address, each transaction would require their own signature. With Schnorr Signature, all these signatures would be combined into one. As a result, the network would be able to store more transactions in a single block.
https://preview.redd.it/axg3wayag3151.png?width=1601&format=png&auto=webp&s=93d958fa6b0e623caa82ca71fe457b4daa88c71e
The reduced size in signatures implies a reduced cost on transaction fees. The group of senders can split the transaction fees for that one group signature, instead of paying for one personal signature individually.
Schnorr Signature also improves network privacy and token fungibility. A third-party observer will not be able to detect if a user is sending a multi-signature transaction, since the signature will be in the same format as a single-signature transaction.

4. Economics and supply distribution

The Bitcoin protocol utilizes the Nakamoto consensus, and nodes validate blocks via Proof-of-Work mining. The bitcoin token was not pre-mined, and has a maximum supply of 21 million. The initial reward for a block was 50 BTC per block. Block mining rewards halve every 210,000 blocks. Since the average time for block production on the blockchain is 10 minutes, it implies that the block reward halving events will approximately take place every 4 years.
As of May 12th 2020, the block mining rewards are 6.25 BTC per block. Transaction fees also represent a minor revenue stream for miners.
submitted by D-platform to u/D-platform [link] [comments]

Technical: Upcoming Improvements to Lightning Network

Price? Who gives a shit about price when Lightning Network development is a lot more interesting?????
One thing about LN is that because there's no need for consensus before implementing things, figuring out the status of things is quite a bit more difficult than on Bitcoin. In one hand it lets larger groups of people work on improving LN faster without having to coordinate so much. On the other hand it leads to some fragmentation of the LN space, with compatibility problems occasionally coming up.
The below is just a smattering sample of LN stuff I personally find interesting. There's a bunch of other stuff, like splice and dual-funding, that I won't cover --- post is long enough as-is, and besides, some of the below aren't as well-known.
Anyway.....

"eltoo" Decker-Russell-Osuntokun

Yeah the exciting new Lightning Network channel update protocol!

Advantages

Myths

Disadvantages

Multipart payments / AMP

Splitting up large payments into smaller parts!

Details

Advantages

Disadvantages

Payment points / scalars

Using the magic of elliptic curve homomorphism for fun and Lightning Network profits!
Basically, currently on Lightning an invoice has a payment hash, and the receiver reveals a payment preimage which, when inputted to SHA256, returns the given payment hash.
Instead of using payment hashes and preimages, just replace them with payment points and scalars. An invoice will now contain a payment point, and the receiver reveals a payment scalar (private key) which, when multiplied with the standard generator point G on secp256k1, returns the given payment point.
This is basically Scriptless Script usage on Lightning, instead of HTLCs we have Scriptless Script Pointlocked Timelocked Contracts (PTLCs).

Advantages

Disadvantages

Pay-for-data

Ensuring that payers cannot access data or other digital goods without proof of having paid the provider.
In a nutshell: the payment preimage used as a proof-of-payment is the decryption key of the data. The provider gives the encrypted data, and issues an invoice. The buyer of the data then has to pay over Lightning in order to learn the decryption key, with the decryption key being the payment preimage.

Advantages

Disadvantages

Stuckless payments

No more payments getting stuck somewhere in the Lightning network without knowing whether the payee will ever get paid!
(that's actually a bit overmuch claim, payments still can get stuck, but what "stuckless" really enables is that we can now safely run another parallel payment attempt until any one of the payment attempts get through).
Basically, by using the ability to add points together, the payer can enforce that the payee can only claim the funds if it knows two pieces of information:
  1. The payment scalar corresponding to the payment point in the invoice signed by the payee.
  2. An "acknowledgment" scalar provided by the payer to the payee via another communication path.
This allows the payer to make multiple payment attempts in parallel, unlike the current situation where we must wait for an attempt to fail before trying another route. The payer only needs to ensure it generates different acknowledgment scalars for each payment attempt.
Then, if at least one of the payment attempts reaches the payee, the payee can then acquire the acknowledgment scalar from the payer. Then the payee can acquire the payment. If the payee attempts to acquire multiple acknowledgment scalars for the same payment, the payer just gives out one and then tells the payee "LOL don't try to scam me", so the payee can only acquire a single acknowledgment scalar, meaning it can only claim a payment once; it can't claim multiple parallel payments.

Advantages

Disadvantages

Non-custodial escrow over Lightning

The "acknowledgment" scalar used in stuckless can be reused here.
The acknowledgment scalar is derived as an ECDH shared secret between the payer and the escrow service. On arrival of payment to the payee, the payee queries the escrow to determine if the acknowledgment point is from a scalar that the escrow can derive using ECDH with the payer, plus a hash of the contract terms of the trade (for example, to transfer some goods in exchange for Lightning payment). Once the payee gets confirmation from the escrow that the acknowledgment scalar is known by the escrow, the payee performs the trade, then asks the payer to provide the acknowledgment scalar once the trade completes.
If the payer refuses to give the acknowledgment scalar even though the payee has given over the goods to be traded, then the payee contacts the escrow again, reveals the contract terms text, and requests to be paid. If the escrow finds in favor of the payee (i.e. it determines the goods have arrived at the payer as per the contract text) then it gives the acknowledgment scalar to the payee.

Advantages

Disadvantages

Payment decorrelation

Because elliptic curve points can be added (unlike hashes), for every forwarding node, we an add a "blinding" point / scalar. This prevents multiple forwarding nodes from discovering that they have been on the same payment route. This is unlike the current payment hash + preimage, where the same hash is used along the route.
In fact, the acknowledgment scalar we use in stuckless and escrow can simply be the sum of each blinding scalar used at each forwarding node.

Advantages

Disadvantages

submitted by almkglor to Bitcoin [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: https://github.com/renproject/ren/wiki/Supported-Blockchains

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]

Best General RenVM Questions of March 2020

Best General RenVM Questions of March 2020

\These questions are sourced directly from Telegram*

Q: How do I shutdown my Chaosnet Darknode? A: Please follow these directions: https://docs.renproject.io/chaosnet/chaosnet-darknode/untitled-3

Q: Can I run a Chaosnet Darknode and Mainnet Darknode at the same time (on the same computer). A: No, if you want to do that you’ll have to run them on separate computers.

Q: You mentioned DCEP in your latest piece and "12 App Ideas", but it's going to run on a centralized private network. The Bank of England also just released a report on how they're thinking about their CBDC and DLT/centralization, and stress that a DLT could add resilience, but there's also no reason a currency couldn't be more centralized. The Block reported that other central banks (like the EU and Singapore) are considering third-party chains like Corda. Can you comment on which CBDC designs may or may not be compatible with RZL? You previously said "RZL sMPC provides ECDSA signatures because that’s what it is used by Ethereum, Bitcoin, etc. Whatever solution they come up with, will be the solution that RZL has to be upgraded to use (the whole point of RenVM is not to tell other chains how to do things, and still provide interop; this means waiting on them to define their solution and then working with that)." So, what does centralization mean for RZL, and how can we think about compatibility between these designs on the technical side?
A: The topic of centralisation in interoperability comes down to the compounding effect of using multiple networks. Put another way “you’re only as decentralised as your most centralised component”. While there are nuances to this, the core idea rings true.
RenVM can be used to interoperate many different kinds of chains (anything using ECDSA, or naturally supporting lively threshold signatures) is a candidate to be included in RenVM. However, a centralised currency that has been bridged to a decentralised chain is not decentralised. The centralised entity that controls the currency might say “nothing transferred to/from this other chain will be honoured”. That’s a risk that you take with centralised currencies (take a look at the T&Cs for USDC for example).
The benefit of RenVM in these instances is to become a standard. Short-term, RenVM brings interoperability to some core chains. Medium-term, it expands that to other more interesting chains based on community demands. Long-term, it becomes the standard for how to implement interop. For example: you create a new chain and don’t worry about interop explicitly because you know RenVM will have your back. For centralised currencies this is still advantageous, because the issuing entity only has to manage one chain (theirs) but can still get their currency onto other chains/ecosystems.
From a technical perspective, the Darknodes just have to be willing to adopt the chain/currency.

Q: dApps will have their own risk tolerances for centralized assets. Eg USDC was a bigger deal for MakerDAO than Uniswap. If CBDC liquidity were suddenly bridgeable, some dApps would be more eager to adopt it than others - even despite the risks - because they provide native liquidity and can be used to store/hedge in it without cashing it out. My question is more technical as it relates to RenVM as the "Universal Stablecoin Converter". You sound convinced that RenVM can bridge Libra, DCEP, maybe other CBDCs in the future, but I'm skeptical how RenVM works with account-based currencies. (1) Are we even sure of DCEP's underlying design and whether it or other CBDCs even plan to use digital signatures? And (2) wouldn't RenVM need a KYC-approved account to even get an address on these chains? It seems like DCEP would have to go through a Chinese Circle, who would just issue an ERC20.
A: As far as underlying blockchain technology goes (eg the maths of it) I don’t see there being any issues. Until we know more about whether or not KYCd addresses are required (and if they are, how they work), then I can’t specifically comment on that. However, it is more than possible not to require RenVM to be KYCd (just like you can’t “KYC Ethereum”) and instead move that requirement to addresses on the host blockchain (eg KYC Ethereum addresses for receiving the cross-chain asset). Whether this happens or not would ultimately be up to whether the issuer wanted interoperability to be possible.

Q: In that scenario, how would RenVM even receive the funds to be transferred to the KYC'd Ethereum address? For Alice to send DCEP to Bob's KYC'd Ethereum address, RenVM would need a DCEP address of its own, no?
A: Again, this is impossible to say for certain without knowing the implementation of the origin chain. You could whitelist known RenVM scripts (by looking at their form, like RenVM itself does on Bitcoin). But mostly likely, these systems will have some level of smart contract capabilities and this allows very flexible control. You can just whitelist the smart contract address that RenVM watches for cross-chain events. In origin chains with smart contracts, the smart contract holds the funds (and the keys the smart contract uses to authorise spends are handled as business logic). So there isn’t really a “RenVM public address” in the same sense that there is in Bitcoin.
Q: The disbonding period for Darknodes seem long, what happens if there is a bug?
A: It’s actually good for the network to have a long disbonding period in the face of a bug. If people were able to panic sell, then not only would the bug cause potential security issues, but so too would a mass exodus of Darknodes from the network.
Having time to fix the bug means that Darknodes may as well stick around and continue securing the network as best they can. Because their REN is at stake (as you put it) they’re incentivised to take any of the recommended actions and update their nodes as necessary.
This is also why it’s critical for the Greycore to exist in the early days of the network and why we are rolling out SubZero the way that we are. If such a bug becomes apparent (more likely in the early days than the later days), then the Greycore has a chance to react to it (the specifics of which would of course depend on the specifics of the bug). This becomes harder and slower as the network becomes more decentralised over time.
Not mcap, but the price of bonded Ren. Furthermore, the price will be determined by how much fees darknodes have collected. BTW, loongy could you unveil based on what profits ratio/apr the price will be calculated?
This is up to the Darknodes to governance softly. This means there isn’t a need for an explicit oracle. Darknodes assess L vs R individually and vote to increase fees to drive L down and drive R up. L is driven down by continue fees, whereas R is driven up by minting/burning fees.

Q: How do you think renvm would perform on a day like today when even cexs are stretched. Would the system be able to keep up?
A: This will really depend on the number of shards that RenVM is operating. Shards operate in parallel so more shards = more processing power.

Q: The main limiting factor is the speed of the underlying chain, rather than RenVM?
A: That’s generally the case. Bitcoin peaks at about 7 TPS so as long as we are faster than this, any extra TPS is “wasted”. And you actually don’t want to be faster than you have to be. This lets you drop hardware requirements, and lowering the cost of running a Darknode. This has two nice effects: (a) being an operator generates more profit because costs are lower, and (b) it’s more accessible to more people because it’s a little cheaper to get started (albeit this is minor).

Q: Just getting caught up on governance, but what about: unbonded REN = 1 vote, bonded REN = (1 vote + time_served). That'd be > decentralization of Darknodes alone, an added incentive to be registered, and counter exchanges wielding too much control.
A: You could also have different decaying rates. For example, assuming that REN holders have to vote by “backing” the vote of Darknodes:
Let X be the amount of REN used to voted, backed behind a Darknode and bonded for T time.
Let Y be the amount of time a Darknode has been active for.
Voting power of the Darknode could = Sqrt(Y) * Log(X + T)
Log(1,000,000,000) = ~21 so if you had every REN bonded behind you, your voting power would only be 21x the voting power of other nodes. This would force whales to either run Darknodes for a while and contribute actively to the ecosystem (or lock up their REN for an extended period for addition voting power), and would force exchanges to spread their voting out over many different nodes (giving power back to those running nodes). Obviously the exchange could just run lots of Darknodes, but they would have to do this over a long period of time (not feasible, because people need to be able to withdraw their REN).

Q: Like having superdelegates, i.e, nodes trusted by the community with higher voting power? Maybe like council nodes
A: Well, this is essentially what the Greycore is. Darknodes that have been voted in by the community to act as a secondary signature on everything. (And, interestingly enough, you could vote out all members to remove the core entirely.)

Q: Think the expensive ren is a security feature as well. So, doubt this would impact security potentially? I don’t know. I wouldn’t vote to cut my earnings by 40% for example lol
A: It can lead to centralisation over time though. If 100K REN becomes prohibitively expensive, then you will only see people running Darknodes that can afford a large upfront capital investment. In the mid/long-term this can have adverse effects on the trust in the system. It’s important that people “external” to the system (non-Darknodes) can get themselves into the system. Allowing non-Darknodes to have some governance (even if it’s not overall things) would be critical to this.

Q: That darknode option sounds very interesting although it could get more centralized as the price of 100k Ren rises.For instance dark nodes may not want to vote to lower the threshold from 100k to 50k once Ren gets too expensive.
A: A great point. And one of the reasons it would be ideal to be able to alter those parameters without just the Darknodes voting. Otherwise, you definitely risk long-term centralisation.

Q: BTC is deposited into a native BTC address, but who controls this address (where/how is this address’s private key stored)?
A: This is precisely the magic behind RenVM. RenVM uses an MPC algorithm to generate the controlling private key. No one ever sees this private key, and no one can sign things with it without consensus from everyone else.
submitted by RENProtocol to RenProject [link] [comments]

Best General RenVM Questions of January 2020

Best General RenVM Questions of January 2020

‌*These questions are sourced directly from Telegram
Q: When you say RenVM is Trustless, Permissionless, and Decentralized, what does that actually mean?
A: Trustless = RenVM is a virtual machine (a network of nodes, that do computations), this means if you ask RenVM to trade an asset via smart contract logic, it will. No trusted intermediary that holds assets or that you need to rely on. Because RenVM is a decentralized network and computes verified information in a secure environment, no single party can prevent users from sending funds in, withdrawing deposited funds, or computing information needed for updating outside ledgers. RenVM is an agnostic and autonomous virtual broker that holds your digital assets as they move between blockchains.
Permissionless = RenVM is an open protocol; meaning anyone can use RenVM and any project can build with RenVM. You don't need anyone's permission, just plug RenVM into your dApp and you have interoperability.
Decentralized = The nodes that power RenVM ( Darknodes) are scattered throughout the world. RenVM has a peak capacity of up to 10,000 Darknodes (due to REN’s token economics). Realistically, there will probably be 100 - 500 Darknodes run in the initial Mainnet phases, ample decentralized nonetheless.

Q: Okay, so how can you prove this?
A: The publication of our audit results will help prove the trustlessness piece; permissionless and decentralized can be proven today.
Permissionless = https://github.com/renproject/ren-js
Decentralized = https://chaosnet.renproject.io/

Q: How does Ren sMPC work? Sharmir's secret sharing? TSS?
A: There is some confusion here that keeps arising so I will do my best to clarify.TL;DR: *SSS is just data. It’s what you do with the data that matters. RenVM uses sMPC on SSS to create TSS for ECDSA keys.*SSS and TSS aren’t fundamental different things. It’s kind of like asking: do you use numbers, or equations? Equations often (but not always) use numbers or at some point involve numbers.
SSS by itself is just a way of representing secret data (like numbers). sMPC is how to generate and work with that data (like equations). One of the things you can do with that work is produce a form of TSS (this is what RenVM does).
However, TSS is slightly different because it can also be done *without* SSS and sMPC. For example, BLS signatures don’t use SSS or sMPC but they are still a form of TSS.
So, we say that RenVM uses SSS+sMPC because this is more specific than just saying TSS (and you can also do more with SSS+sMPC than just TSS). Specifically, all viable forms of turning ECDSA (a scheme that isn’t naturally threshold based) into a TSS needs SSS+sMPC.
People often get confused about RenVM and claim “SSS can’t be used to sign transactions without making the private key whole again”. That’s a strange statement and shows a fundamental misunderstanding about what SSS is.
To come back to our analogy, it’s like saying “numbers can’t be used to write a book”. That’s kind of true in a direct sense, but there are plenty of ways to encode a book as numbers and then it’s up to how you interpret (how you *use*) those numbers. This is exactly how this text I’m writing is appearing on your screen right now.
SSS is just secret data. It doesn’t make sense to say that SSS *functions*. RenVM is what does the functioning. RenVM *uses* the SSSs to represent private keys. But these are generated and used and destroyed as part of sMPC. The keys are never whole at any point.

Q: Thanks for the explanation. Based on my understanding of SSS, a trusted dealer does need to briefly put the key together. Is this not the case?
A: Remember, SSS is just the representation of a secret. How you get from the secret to its representation is something else. There are many ways to do it. The simplest way is to have a “dealer” that knows the secret and gives out the shares. But, there are other ways. For example: we all act as dealers, and all give each other shares of our individual secret. If there are N of us, we now each have N shares (one from every person). Then we all individually add up the shares that we have. We now each have a share of a “global” secret that no one actually knows. We know this global secret is the sum of everyone’s individual secrets, but unless you know every individual’s secret you cannot know the global secret (even though you have all just collectively generates shares for it). This is an example of an sMPC generation of a random number with collusion resistance against all-but-one adversaries.

Q: If you borrow Ren, you can profit from the opposite Ren gain. That means you could profit from breaking the network and from falling Ren price (because breaking the network, would cause Ren price to drop) (lower amount to be repaid, when the bond gets slashed)
A: Yes, this is why it’s important there has a large number of Darknodes before moving to full decentralisation (large borrowing becomes harder). We’re exploring a few other options too, that should help prevent these kinds of issues.

Q: What are RenVM’s Security and Liveliness parameters?
A: These are discussed in detail in our Wiki, please check it out here: https://github.com/renproject/ren/wiki/Safety-and-Liveliness#analysis

Q: What are the next blockchain under consideration for RenVM?
A: These can be found here: https://github.com/renproject/ren/wiki/Supported-Blockchains

Q: I've just read that Aztec is going to be live this month and currently tests txs with third parties. Are you going to participate in early access or you just more focused on bringing Ren to Subzero stage?
A: At this stage, our entire focus is on Mainnet SubZero. But, we will definitely be following up on integrating with AZTEC once everything is out and stable.

Q: So how does RenVM compare to tBTC, Thorchain, WBTC, etc..?
A: An easy way to think about it is..RenVM’s functionality is a combination of tBTC (+ WBTC by extension), and Thorchain’s (proposed) capabilities... All wrapped into one. Just depends on what the end-user application wants to do with it.

Q1: What are the core technical/security differences between RenVM and tBTC?A1: The algorithm used by tBTC faults if even one node goes offline at the wrong moment (and the whole “keep” of nodes can be penalised for this). RenVM can survive 1/3rd going offline at any point at any time. Advantage for tBTC is that collusion is harder, disadvantage is obviously availability and permissionlessness is lower.
tBTC an only mint/burn lots of 1 BTC and requires an on-Ethereum SPV relay for Bitcoin headers (and for any other chain it adds). No real advantage trade-off IMO.
tBTC has a liquidation mechanism that means nodes can have their bond liquidated because of ETH/BTC price ratio. Advantage means users can get 1 BTC worth of ETH. Disadvantage is it means tBTC is kind of a synthetic: needs a price feed, needs liquid markets for liquidation, users must accept exposure to ETH even if they only hold tBTC, nodes must stay collateralized or lose lots of ETH. RenVM doesn’t have this, and instead uses fees to prevent becoming under-collateralized. This requires a mature market, and assumed Darknodes will value their REN bonds fairly (based on revenue, not necessarily what they can sell it for at current —potentially manipulated—market value). That can be an advantage or disadvantage depending on how you feel.
tBTC focuses more on the idea of a tokenized version of BTC that feels like an ERC20 to the user (and is). RenVM focuses more on letting the user interact with DeFi and use real BTC and real Bitcoin transactions to do so (still an ERC20 under the hood, but the UX is more fluid and integrated). Advantage of tBTC is that it’s probably easier to understand and that might mean better overall experience, disadvantage really comes back to that 1 BTC limit and the need for a more clunky minting/burning experience that might mean worse overall experience. Too early to tell, different projects taking different bets.
tBTC supports BTC (I think they have ZEC these days too). RenVM supports BTC, BCH, and ZEC (docs discuss Matic, XRP, and LTC).
Q2: This are my assumed differences between tBTC and RenVM, are they correct? Some key comparisons:
-Both are vulnerable to oracle attacks
-REN federation failure results in loss or theft of all funds
-tBTC failures tend to result in frothy markets, but holders of tBTC are made whole
-REN quorum rotation is new crypto, and relies on honest deletion of old key shares
-tBTC rotates micro-quorums regularly without relying on honest deletion
-tBTC relies on an SPV relay
-REN relies on federation honesty to fill the relay's purpose
-Both are brittle to deep reorgs, so expanding to weaker chains like ZEC is not clearly a good idea
-REN may see total system failure as the result of a deep reorg, as it changes federation incentives significantly
-tBTC may accidentally punish some honest micro-federations as the result of a deep reorg
-REN generally has much more interaction between incentive models, as everything is mixed into the same pot.
-tBTC is a large collection of small incentive models, while REN is a single complex incentive model
A2: To correct some points:
The oracle situation is different with RenVM, because the fee model is what determines the value of REN with respect to the cross-chain asset. This is the asset is what is used to pay the fee, so no external pricing is needed for it (because you only care about the ratio between REN and the cross-chain asset).
RenVM does rotate quorums regularly, in fact more regularly than in tBTC (although there are micro-quorums, each deposit doesn’t get rotated as far as I know and sticks around for up to 6 months). This rotation involves rotations of the keys too, so it does not rely on honest deletion of key shares.
Federated views of blockchains are easier to expand to support deep re-orgs (just get the nodes to wait for more blocks for that chain). SPV requires longer proofs which begins to scale more poorly.
Not sure what you mean by “one big pot”, but there are multiple quorums so the failure of one is isolated from the failures of others. For example, if there are 10 shards supporting BTC and one of them fails, then this is equivalent to a sudden 10% fee being applied. Harsh, yes, but not total failure of the whole system (and doesn’t affect other assets).
Would be interesting what RenVM would look like with lots more shards that are smaller. Failure becomes much more isolated and affects the overall network less.
Further, the amount of tBTC you can mint is dependent on people who are long ETH and prefer locking it up in Keep for earning a smallish fee instead of putting it in Compound or leveraging with dydx. tBTC is competing for liquidity while RenVM isn't.

Q: I understand correctly RenVM (sMPC) can get up to a 50% security threshold, can you tell me more?
A: The best you can theoretically do with sMPC is 50-67% of the total value of REN used to bond Darknodes (RenVM will eventually work up to 50% and won’t go for 67% because we care about liveliness just as much as safety). As an example, if there’s $1M of REN currently locked up in bonded Darknodes you could have up to $500K of tokens shifted through RenVM at any one specific moment. You could do more than that in daily volume, but at any one moment this is the limit.Beyond this limit, you can still remain secure but you cannot assume that players are going to be acting to maximize their profit. Under this limit, a colluding group of adversaries has no incentive to subvert safety/liveliness properties because the cost to attack roughly outweighs the gain. Beyond this limit, you need to assume that players are behaving out of commitment to the network (not necessarily a bad assumption, but definitely weaker than the maximizing profits assumption).

Q: Why is using ETH as collateral for RenVM a bad idea?
A: Using ETH as collateral in this kind of system (like having to deposit say 20 ETH for a bond) would not make any sense because the collateral value would then fluctuate independently of what kind of value RenVM is providing. The REN token on the other hand directly correlates with the usage of RenVM which makes bonding with REN much more appropriate. DAI as a bond would not work as well because then you can't limit attackers with enough funds to launch as many darknodes as they want until they can attack the network. REN is limited in supply and therefore makes it harder to get enough of it without the price shooting up (making it much more expensive to attack as they would lose their bonds as well).
A major advantage of Ren's specific usage of sMPC is that security can be regulated economically. All value (that's being interopped at least) passing through RenVM has explicit value. The network can self-regulate to ensure an attack is never worth it.

Q: Given the fee model proposal/ceiling, might be a liquidity issue with renBTC. More demand than possible supply?A: I don’t think so. As renBTC is minted, the fees being earned by Darknodes go up, and therefore the value of REN goes up. Imagine that the demand is so great that the amount of renBTC is pushing close to 100% of the limit. This is a very loud and clear message to the Darknodes that they’re going to be earning good fees and that demand is high. Almost by definition, this means REN is worth more.
Profits of the Darknodes, and therefore security of the network, is based solely on the use of the network (this is what you want because your network does not make or break on things outside the systems control). In a system like tBTC there are liquidity issues because you need to convince ETH holders to bond ETH and this is an external problem. Maybe ETH is pumping irrespective of tBTC use and people begin leaving tBTC to sell their ETH. Or, that ETH is dumping, and so tBTC nodes are either liquidated or all their profits are eaten by the fact that they have to be long on ETH (and tBTC holders cannot get their BTC back in this case). Feels real bad man.

Q: I’m still wondering which asset people will choose: tbtc or renBTC? I’m assuming the fact that all tbtc is backed by eth + btc might make some people more comfortable with it.
A: Maybe :) personally I’d rather know that my renBTC can always be turned back into BTC, and that my transactions will always go through. I also think there are many BTC holders that would rather not have to “believe in ETH” as an externality just to maximize use of their BTC.

Q: How does the liquidation mechanism work? Can any party, including non-nodes act as liquidators? There needs to be a price feed for liquidation and to determine the minting fee - where does this price feed come from?
A: RenVM does not have a liquidation mechanism.
Q: I don’t understand how the price feeds for minting fees make sense. You are saying that the inputs for the fee curve depend on the amount of fees derived by the system. This is circular in a sense?
A: By evaluating the REN based on the income you can get from bonding it and working. The only thing that drives REN value is the fact that REN can be bonded to allow work to be done to earn revenue. So any price feed (however you define it) is eventually rooted in the fees earned.

Q: Who’s doing RenVM’s Security Audit?
A: ChainSecurity | https://chainsecurity.com/

Q: Can you explain RenVM’s proposed fee model?
A: The proposed fee model can be found here: https://github.com/renproject/ren/wiki/Safety-and-Liveliness#fees

Q: Can you explain in more detail the difference between "execution" and "powering P2P Network". I think that these functions are somehow overlapping? Can you define in more detail what is "execution" and "powering P2P Network"? You also said that at later stages semi-core might still exist "as a secondary signature on everything (this can mathematically only increase security, because the fully decentralised signature is still needed)". What power will this secondary signature have?
A: By execution we specifically mean signing things with the secret ECDSA keys. The P2P network is how every node communicates with every other node. The semi-core doesn’t have any “special powers”. If it stays, it would literally just be a second signature required (as opposed to the one signature required right now).
This cannot affect safety, because the first signature is still required. Any attack you wanted to do would still have to succeed against the “normal” part of the network. This can affect liveliness, because the semi-core could decide not to sign. However, the semi-core follows the same rules as normal shards. The signature is tolerant to 1/3rd for both safety/liveliness. So, 1/3rd+ would have to decide to not sign.
Members of the semi-core would be there under governance from the rest of our ecosystem. The idea is that members would be chosen for their external value. We’ve discussed in-depth the idea of L<3. But, if RenVM is used in MakerDAO, Compound, dYdX, Kyber, etc. it would be desirable to capture the value of these ecosystems too, not just the value of REN bonded. The semi-core as a second signature is a way to do this.
Imagine if the members for those projects, because those projects want to help secure renBTC, because it’s used in their ecosystems. There is a very strong incentive for them to behave honestly. To attack RenVM you first have to attack the Darknodes “as per usual” (the current design), and then somehow convince 1/3rd of these projects to act dishonestly and collapse their own ecosystems and their own reputations. This is a very difficult thing to do.
Worth reminding: the draft for this proposal isn’t finished. It would be great for everyone to give us their thoughts on GitHub when it is proposed, so we can keep a persistent record.

Q: Which method or equation is used to calculate REN value based on fees? I'm interested in how REN value is calculated as well, to maintain the L < 3 ratio?
A: We haven’t finalized this yet. But, at this stage, the plan is to have a smart contract that is controlled by the Darknodes. We want to wait to see how SubZero and Zero go before committing to a specific formulation, as this will give us a chance to bootstrap the network and field inputs from the Darknodes owners after the earnings they can make have become more apparent.
submitted by RENProtocol to RenProject [link] [comments]

Upcoming Updates to Bitcoin Consensus

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

Schnorr

The sexy new signing algo.

Advantages

Disadvantages

MuSig

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

Advantages

Disadvantages

Taproot

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

Advantages

Disadvantages

MAST

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

Advantages

Disadvantages

submitted by almkglor to Bitcoin [link] [comments]

Bitcoin’s Security and Hash Rate Explained

Bitcoin’s Security and Hash Rate Explained
As the Bitcoin hash rate reaches new all-time highs, there’s never been a better time to discuss blockchain security and its relation to the hashing power and the Proof of Work (PoW) that feed the network. The Bitcoin system is based on a form of decentralized trust, heavily relying on cryptography. This makes its blockchain highly secure and able to be used for financial transactions and other operations requiring a trustless ledger.
Far from popular belief, cryptography dates back to thousands of years ago. The same root of the word encryption — crypt — comes from the Greek word ‘kryptos’, meaning hidden or secret. Indeed, humans have always wanted to keep some information private. The Assyrians, the Chinese, the Romans, and the Greeks, they all tried over the centuries to conceal some information like trade deals or manufacturing secrets by using symbols or ciphers carved in stone or leather. In 1900 BC, Egyptians used hieroglyphics and experts often refer to them as the first example of cryptography.
Back to our days, Bitcoin uses cryptographic technologies such as:
  1. Cryptographic hash functions (i.e. SHA-256 and RIPEMD-160)
  2. Public Key Cryptography (i.e. ECDSA — the Elliptic Curve Digital Signature Algorithm)
While Public Key Cryptography, bitcoin addresses, and digital signatures are used to provide ownership of bitcoins, the SHA-256 hash function is used to verify data and block integrity and to establish the chronological order of the blockchain. A cryptographic hash function is a mathematical function that verifies the integrity of data by transforming it into a unique unidentifiable code.
Here is a graphic example to make things more clear:

– Extract from the MOOC (Massive Open Online Course) in Digital Currencies at the University of Nicosia.
Furthermore, hash functions are used as part of the PoW algorithm, which is a prominent part of the Bitcoin mining algorithm and this is what is of more interest to understand the security of the network. Mining creates new bitcoins in each block, almost like a central bank printing new money and creates trust by ensuring that transactions are confirmed only when enough computational power is devoted to the block that contains them. More blocks mean more computation, which means more trust.
With PoW, miners compete against each other to complete transactions on the network and get rewarded. Basically they need to solve a complicated mathematical puzzle and a possibility to easily prove the solution. The more hashing power, the higher the chance to resolve the puzzle and therefore perform the proof of work. In more simple words, bitcoins exist thanks to a peer to peer network that helps validate transactions in the ledger and provides enough trust to avoid that a third party is involved in the process. It also exists because miners give it life by resolving that computational puzzle, through the mining reward incentive they are receiving.
For more info, contact Block.co directly or email at [email protected].
Tel +357 70007828
Get the latest from Block.co, like and follow us on social media:
✔️Facebook
✔️LinkedIn
✔️Twitter
✔️YouTube
✔️Medium
✔️Instagram
✔️Telegram
✔️Reddit
✔️GitHub
submitted by BlockDotCo to u/BlockDotCo [link] [comments]

Bitcoin ECDSA- Elliptic curve Digital Signature Bitcoin 101 Elliptic Curve Cryptography Part 5 The Magic of Signing & Verifying Math Behind Bitcoin and Elliptic Curve Cryptography ... [New! Update] BTC Privatekey Finder With Python 3.0+ ECDSA ... Bitcoin Signature Tool for Decentralized Services Market

Descrtiption [] Key and signature-size comparison to DSA []. As with elliptic-curve cryptography in general, the bit size of the public key believed to be needed for ECDSA is about twice the size of the security level, in bits. For example, at a security level of 80 bits (meaning an attacker requires a maximum of about 2 80 operations to find the private key) the size of an ECDSA public key ... Bitcoin ecdsa example, online forex trading Software Plattform uk, geld verdienen mit domains After we explained in details how the ECDSA signature algorithm works, now let's demonstrate it in practice with code examples.. In this example, we shall use the pycoin Python package, which implements the ECDSA signature algorithm with the curve secp256k1 (used in the Bitcoin cryptography), as well as many other functionalities related to the Bitcoin blockchain: The following are 30 code examples for showing how to use ecdsa.SECP256k1(). These examples are extracted from open source projects. You can vote up the ones you like or vote down the ones you don't like, and go to the original project or source file by following the links above each example. You may check out the related API usage on the sidebar. You may also want to check out all available ... ECDSA (‘Elliptical Curve Digital Signature Algorithm’) is the cryptography behind private and public keys used in Bitcoin. It consists of combining the math behind finite fields and elliptic ...

[index] [3733] [24391] [15006] [23802] [31082] [1772] [2032] [19506] [3156] [12731]

Bitcoin ECDSA- Elliptic curve Digital Signature

#bitcoinPrivatekey #hotvideo #Bitcoin Python code Bib39 for finder bitcoin privatekey Buy it -- https://satoshidisk.com/pay/C8qYXr Contact Email kritcharatme... Welcome to WBN's Bitcoin 101 Blackboard Series -- a full beginner to expert course in bitcoin. Please like, subscribe, comment or even drop a little jangly in our bitcoin tip jar ... Elliptic Curve Digital Signature Algorithm ECDSA Part 10 Cryptography Crashcourse - Duration: 35:32. Dr. Julian Hosp - Bitcoin, Aktien, Gold und Co. 5,803 views Elliptic curve cryptography is the backbone behind bitcoin technology and other crypto currencies, especially when it comes to to protecting your digital ass... Getting the ECDSA Z Value from a Bitcoin Single Input Transaction - Duration: 6:43. seanwasere ytbe 6,214 views. 6:43. 2018-01-07; Electrum PGP signature verification instructions - Duration: 20 ...

#