Ecdsa Private Key Java - oiqs.info-metall.it

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]

ABCMint is a quantum resistant cryptocurrency with the Rainbow Multivariable Polynomial Signature Scheme.

Good day, the price is going up to 0.3USDT.

ABCMint Second Foundation

ABCMint has been a first third-party organization that focuses on post-quantum cryptography research and technology and aims to help improve the ecology of ABCMint technology since 2018.


https://abcmintsf.com

https://abcmintsf.com/exchange


What is ABCMint?

ABCMint is a quantum resistant cryptocurrency with the Rainbow Multivariable Polynomial Signature Scheme.

Cryptocurrencies and blockchain technology have attracted a significant amount of attention since 2009. While some cryptocurrencies, including Bitcoin, are used extensively in the world, these cryptocurrencies will eventually become obsolete and be replaced when the quantum computers avail. For instance, Bitcoin uses the elliptic curved signature (ECDSA). If a bitcoin user?s public key is exposed to the public chain, the quantum computers will be able to quickly reverse-engineer the private key in a short period of time. It means that should an attacker decide to use a quantum computer to decrypt ECDSA, he/she will be able to use the bitcoin in the wallet.

The ABCMint Foundation has improved the structure of the special coin core to resist quantum computers, using the Rainbow Multivariable Polynomial Signature Scheme, which is quantum resisitant, as the core. This is a fundamental solution to the major threat to digital money posed by future quantum computers. In addition, the ABCMint Foundation has implemented a new form of proof of arithmetic (mining) "ABCardO" which is different from Bitcoin?s arbitrary mining. This algorithm is believed to be beneficial to the development of the mathematical field of multivariate.


Rainbow Signature - the quantum resistant signature based on Multivariable Polynomial Signature Scheme

Unbalanced Oil and Vinegar (UOV) is a multi-disciplinary team of experts in the field of oil and vinegar. One of the oldest and most well researched signature schemes in the field of variable cryptography. It was designed by J. Patarin in 1997 and has withstood more than two decades of cryptanalysis. The UOV scheme is a very simple, smalls and fast signature. However, the main drawback of UOV is the large public key, which will not be conducive to the development of block practice technology.

The rainbow signature is an improvement on the oil and vinegar signature which increased the efficiency of unbalanced oil and vinegar. The basic concept is a multi-layered structure and generalization of oil and vinegar.


PQC - Post Quantum Cryptography

The public key cryptosystem was a breakthrough in modern cryptography in the late 1970s. It has become an increasingly important part of our cryptography communications network over The Internet and other communication systems rely heavily on the Diffie-Hellman key exchange, RSA encryption, and the use of the DSA, ECDSA or related algorithms for numerical signatures. The security of these cryptosystems depends on the difficulty level of number theory problems such as integer decomposition and discrete logarithm problems. In 1994, Peter Shor demonstrated that quantum computers can solve all these problems in polynomial time, which made this security issue related to the cryptosystems theory irrelevant. This development is known as the "post-quantum cryptography" (PQC)

In August 2015, the U.S. National Security Agency (NSA) released an announcement regarding its plans to transition to quantum-resistant algorithms. In December 2016, the National Institute of Standards and Technology (NIST) announced a call for proposals for quantum-resistant algorithms. The deadline was November 30, 2017, which also included the rainbow signatures used for ABCMint.
submitted by WrapBeautiful to ABCMint [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]

Part 5. I'm writing a series about blockchain tech and possible future security risks. This is the fifth part of the series talking about an advanced vulnerability of BTC.

The previous parts will give you usefull basic blockchain knowledge and insights on quantum resistance vs blockchain that are not explained in this part.
Part 1, what makes blockchain reliable?
Part 2, The mathematical concepts Hashing and Public key cryptography.
Part 3, Quantum resistant blockchain vs Quantum computing.
Part 4A, The advantages of quantum resistance from genesis block, A
Part 4B, The advantages of quantum resistance from genesis block, A

Why BTC is vulnerable for quantum attacks sooner than you would think.
Content:
The BTC misconception: “Original public keys are not visible until you make a transaction, so BTC is quantum resistant.”
Already exposed public keys.
Hijacking transactions.
Hijacks during blocktime
Hijacks pre-blocktime.
MITM attacks

- Why BTC is vulnerable for quantum attacks sooner than you would think. -

Blockchain transactions are secured by public-private key cryptography. The keypairs used today will be at risk when quantum computers reach a certain critical level: Quantum computers can at a certain point of development, derive private keys from public keys. See for more sourced info on this subject in part 3. So if a public key can be obtained by an attacker, he can then use a quantum computer to find the private key. And as he has both the public key and the private key, he can control and send the funds to an address he owns.
Just to make sure there will be no misconceptions: When public-private key cryptography such as ECDSA and RSA can be broken by a quantum computer, this will be an issue for all blockchains who don't use quantum resistant cryptography. The reason this article is about BTC is because I take this paper as a reference point: https://arxiv.org/pdf/1710.10377.pdf Here they calculate an estimate when BTC will be at risk while taking the BTC blocktime as the window of opportunity.
The BTC misconception: “Original public keys are not visible until you make a transaction, so BTC is quantum resistant.”
In pretty much every discussion I've read and had on the subject, I notice that people are under the impression that BTC is quantum resistant as long as you use your address only once. BTC uses a hashed version of the public key as a send-to address. So in theory, all funds are registered on the chain on hashed public keys instead of to the full, original public keys, which means that the original public key is (again in theory) not public. Even a quantum computer can't derive the original public key from a hashed public key, therefore there is no risk that a quantum computer can derive the private key from the public key. If you make a transaction, however, the public key of the address you sent your funds from will be registered in full form in the blockchain. So if you were to only send part of your funds, leaving the rest on the old address, your remaining funds would be on a published public key, and therefore vulnerable to quantum attacks. So the workaround would be to transfer the remaining funds, within the same transaction, to a new address. In that way, your funds would be once again registered on the blockchain on a hashed public key instead of a full, original public key.
If you feel lost already because you are not very familiar with the tech behind blockchain, I will try to explain the above in a more familiar way:
You control your funds through your public- private key pair. Your funds are registered on your public key. And you can create transactions, which you need to sign to be valid. You can only create a signature if you have your private key. See it as your e-mail address (public key) and your password (Private key). Many people got your email address, but only you have your password. So the analogy is, that if you got your address and your password, then you can access your mail and send emails (Transactions). If the right quantum computer would be available, people could use that to calculate your password (private key), if they have your email address (public key).
Now, because BTC doesn’t show your full public key anywhere until you make a transaction. That sounds pretty safe. It means that your public key is private until you make a transaction. The only thing related to your public key that is public is the hash of your public key. Here is a short explanation of what a hash is: a hash is an outcome of an equation. Usually one-way hash functions are used, where you can not derive the original input from the output; but every time you use the same hash function on the same original input (For example IFUHE8392ISHF), you will always get the same output (For example G). That way you can have your coins on public key "IFUHE8392ISHF", while on the chain, they are registered on "G".
So your funds are registered on the blockchain on the "Hash" of the public key. The Hash of the public key is also your "email address" in this case. So you give "G" as your address to send BTC to.
As said before: since it is, even for a quantum computer, impossible to derive a public key from the Hash of a public key, your coins are safe for quantum computers as long as the public key is only registered in hashed form. The obvious safe method would be, never to reuse an address, and always make sure that when you make a payment, you send your remaining funds to a fresh new address. (There are wallets that can do this for you.) In theory, this would make BTC quantum resistant, if used correctly. This, however, is not as simple as it seems. Even though the above is correct, there is a way to get to your funds.
Already exposed public keys.
But before we get to that, there is another point that is often overlooked: Not only is the security of your personal BTC is important, but also the security of funds of other users. If others got hacked, the news of the hack itself and the reaction of the market to that news, would influence the marketprice. Or, if a big account like the Satoshi account were to be hacked and dumped, the dump itself, combined with the news of the hack, could be even worse. An individual does not have the control of other people’s actions. So even though one might make sure his public key is only registered in hashed form, others might not do so, or might no know their public key is exposed. There are several reasons why a substantial amount of addresses actually have exposed full public keys:
In total, about 36% of all BTC are on addresses with exposed public keys Of which about 20% is on lost addresses. and here
Hijacking transactions.
But even if you consider the above an acceptable risk, just because you yourself will make sure you never reuse an address, then still, the fact that only the hashed public key is published until you make a transaction is a false sense of security. It only works, if you never make a transaction. Why? Public keys are revealed while making a transaction, so transactions can be hijacked while being made.
Here it is important to understand two things:
1.) How is a transaction sent?
The owner has the private key and the public key and uses that to log into the secured environment, the wallet. This can be online or offline. Once he is in his wallet, he states how much he wants to send and to what address.
When he sends the transaction, it will be broadcasted to the blockchain network. But before the actual transaction will be sent, it is formed into a package, created by the wallet. This happens out of sight of the sender.
That package ends up carrying roughly the following info: the public key to point to the address where the funds will be coming from, the amount that will be transferred, the address the funds will be transferred to (depending on the blockchain this could be the hashed public key, or the original public key of the address the funds will be transferred to). This package also carries the most important thing: a signature, created by the wallet, derived from the private- public key combination. This signature proves to the miners that you are the rightful owner and you can send funds from that public key.
Then this package is sent out of the secure wallet environment to multiple nodes. The nodes don’t need to trust the sender or establish the sender’s "identity”, because the sender proofs he is the rightful owner by adding the signature that corresponds with the public key. And because the transaction is signed and contains no confidential information, private keys, or credentials, it can be publicly broadcast using any underlying network transport that is convenient. As long as the transaction can reach a node that will propagate it into the network, it doesn’t matter how it is transported to the first node.
2.) How is a transaction confirmed/ fulfilled and registered on the blockchain?
After the transaction is sent to the network, it is ready to be processed. The nodes have a bundle of transactions to verify and register on the next block. This is done during a period called the block time. In the case of BTC that is 10 minutes.
If we process the information written above, we will see that there are two moments where you can actually see the public key, while the transaction is not fulfilled and registered on the blockchain yet.
1: during the time the transaction is sent from the sender to the nodes
2: during the time the nodes verify the transaction. (The blocktime)
Hijacks during blocktime
This paper describes how you could hijack a transaction and make a new transaction of your own, using someone else’s address and send his coins to an address you own during moment 2: the time the nodes verify the transaction:
https://arxiv.org/pdf/1710.10377.pdf
"(Unprocessed transactions) After a transaction has been broadcast to the network, but before it is placed on the blockchain it is at risk from a quantum attack. If the secret key can be derived from the broadcast public key before the transaction is placed on the blockchain, then an attacker could use this secret key to broadcast a new transaction from the same address to his own address. If the attacker then ensures that this new transaction is placed on the blockchain first, then he can effectively steal all the bitcoin behind the original address." (Page 8, point 3.)
So this means that BTC obviously is not a quantum secure blockchain. Because as soon as you will touch your funds and use them for payment, or send them to another address, you will have to make a transaction and you risk a quantum attack.
Hijacks pre-blocktime.
The story doesn't end here. The paper doesn't describe the posibility of a pre-blocktime hijack.
So back to the paper: as explained, while making a transaction your public key is exposed for at least the transaction time. This transaction time is 10 minutes where your transaction is being confirmed during the 10 minute block time. That is the period where your public key is visible and where, as described in the paper, a transaction can be hijacked, and by using quantum computers, a forged transaction can be made. So the critical point is determined to be the moment where quantum computers can derive private keys from public keys within 10 minutes. Based on that 10 minute period, they calculate (estimate) how long it will take before QC's start forming a threat to BTC. (“ By our most optimistic estimates, as early as 2027 a quantum computer could exist that can break the elliptic curve signature scheme in less than 10 minutes, the block time used in Bitcoin.“ This is also shown in figure 4 on page 10 and later more in depth calculated in appendix C, where the pessimistic estimate is around 2037.) But you could extend that 10 minutes through network based attacks like DDoS, BGP routing attacks, NSA Quantum Insert, Eclipse attacks, MITM attacks or anything like that. (And I don’t mean you extend the block time by using a network based attack, but you extend the time you have access to the public key before the transaction is confirmed.) Bitcoin would be earlier at risk than calculated in this paper.
Also other Blockchains with way shorter block times imagine themselves safe for a longer period than BTC, but with this extension of the timeframe within which you can derive the private key, they too will be vulnerable way sooner.
Not so long ago an eclipse attack demonstrated it could have done the trick. and here Causing the blockchain to work over max capacity, means the transactions will be waiting to be added to a block for a longer time. This time needs to be added on the blocktime, expanding the period one would have time to derive the private key from the public key.
That seems to be fixed now, but it shows there are always new attacks possible and when the incentive is right (Like a few billion $ kind of right) these could be specifically designed for certain blockchains.
MITM attacks
An MITM attack could find the public key in the first moment the public key is exposed. (During the time the transaction is sent from the sender to the nodes) So these transactions that are sent to the network, contain public keys that you could intercept. So that means that if you intercept transactions (and with that the private keys) and simultaneously delay their arrival to the blockchain network, you create extra time to derive the private key from the public key using a quantum computer. When you done that, you send a transaction of your own before the original transaction has arrived and is confirmed and send funds from that stolen address to an address of your choosing. The result would be that you have an extra 10, 20, 30 minutes (or however long you can delay the original transactions), to derive the public key. This can be done without ever needing to mess with a blockchain network, because the attack happens outside the network. Therefore, slower quantum computers form a threat. Meaning that earlier models of quantum computers can form a threat than they assume now.
When MITM attacks and hijacking transactions will form a threat to BTC, other blockchains will be vulnerable to the same attacks, especially MITM attacks. There are ways to prevent hijacking after arrival at the nodes. I will elaborate on that in the next article. At this point of time, the pub key would be useless to an attacker due to the fact there is no quantum computer available now. Once a quantum computer of the right size is available, it becomes a problem. For quantum resistant blockchains this is differetn. MITM attacks and hijacking is useless to quantum resistant blockchains like QRL and Mochimo because these projects use quantum resistant keys.
submitted by QRCollector to CryptoTechnology [link] [comments]

Technical: Pay-to-contract and Sign-to-contract

What's this? I don't make a Technical post for a month and now BitPay is censoring the Hong Kong Free Press? Shit I'm sorry, it's all my fault for not posting a Technical post regularly!! Now posting one so that we have a censorship-free Bitcoin universe!
Pay-to-contract and sign-to-contract are actually cryptographic techniques to allow you to embed a commitment in a public key (pay-to-contract) or signature (sign-to-contract). This commitment can be revealed independently of the public key / signature without leaking your private key, and the existence of the commitment does not prevent you from using the public key / signature as a normal pubkey/signature for a normal digital signing algorithm.
Both techniques utilize elliptic curve homomorphism. Let's digress into that a little first.

Elliptic Curve Homomorphism

Let's get an oversimplified view of the maths involved first.
First, we have two "kinds" of things we can compute on.
  1. One kind is "scalars". These are just very large single numbers. Traditionally represented by small letters.
  2. The other kind is "points". These are just pairs of large numbers. Traditionally represented by large letters.
Now, an "Elliptic Curve" is just a special kind of curve with particular mathematical properties. I won't go into those properties, for the very reasonable reason that I don't actually understand them (I'm not a cryptographer, I only play one on reddit!).
If you have an Elliptic Curve, and require that all points you work with are on some Elliptic Curve, then you can do these operations.
  1. Add, subtract, multiply, and divide scalars. Remember, scalars are just very big numbers. So those basic mathematical operations still work on big numbers, they're just big numbers.
  2. "Multiply" a scalar by a point, resulting in a point. This is written as a * B, where a is the scalar and B is a point. This is not just multiplying the scalar to the point coordinates, this is some special Elliptic Curve thing that I don't understand either.
  3. "Add" two points together. This is written as A + B. Again, this is some special Elliptic Curve thing.
The important part is that if you have:
A = a * G B = b * G Q = A + B 
Then:
q = a + b Q = q * G 
That is, if you add together two points that were each derived from multiplying an arbitarry scalar with the same point (G in the above), you get the same result as adding the scalars together first, then multiplying their sum with the same point will yield the same number. Or:
a * G + b * G = (a + b) * G 
And because multiplication is just repeated addition, the same concept applies when multiplying:
a * (b * G) = (a * b) * G = (b * a) * G = b * (a * G) 
Something to note in particular is that there are few operations on points. One operation that's missing is "dividing" a point by a point to yield a scalar. That is, if you have:
A = a * G 
Then, if you know A but don't know the scalar a, you can't do the below:
a = A / G 
You can't get a even if you know both the points A and G.
In Elliptic Curve Cryptography, scalars are used as private keys, while points are used as public keys. This is particularly useful since if you have a private key (scalar), you can derive a public key (point) from it (by multiplying the scalar with a certain standard point, which we call the "generator point", traditionally G). But there is no reverse operation to get the private key from the public key.

Commitments

Let's have another mild digression.
Sometimes, you want to "commit' to something that you want to keep hidden for now. This is actually important in some games and so on. For example, if you are paying a game of Twenty Questions, one player must first write the object they are thinking of, then fold or hide it in such a way that what they wrote is not visible. Then, after the guessing player has asked twenty questions to narrow down what the object is and has revealed what he or she thinks the object being guessed was, the guessee reveals the object by unfodling and showing the paper.
The act of writing down commits you to the specific thing you wrote down. Folding the paper and/or hiding it, err, hides what you wrote down. Later, when you unfold the paper, you reveal your commitment.
The above is the analogy to the development of cryptographic commitments.
  1. First you select some thing --- it could be anything, a song, a random number, a promise to deliver products and services, the real identity of Satoshi Nakamoto.
  2. You commit to it by giving it as input to a one-way function. A one-way function is a function which allows you to get an output from an input, but after you perform that there is no way to reverse it and determine the original input knowing only the final output. Hash functions like SHA are traditionally used as one-way functions. As a one-way function, this hides your original input.
  3. You give the commitment (the output of the one-way function given your original input) to whoever wants you to commit.
  4. Later, when somebody demands to show what you committed to (for example after playing Twenty Questions), you reveal the commitment by giving the original input to the one-way function (i.e. the thing you selected in the first step, which was the thing you wanted to commit to).
  5. Whoever challenged you can verify your commitment by feeding your supposed original input to the same one-way function. If you honestly gave the correct input, then the challenger will get the output that you published above in step 3.

Salting

Now, sometimes there are only a few possible things you can select from. For example, instead of Twenty Questions you might be playing a Coin Toss Guess game.
What we'd do would be that, for example, I am the guesser and you the guessee. You select either "heads" or "tails" and put it in a commitment which you hand over to me. Then, I say "heads" or "tails" and have you reveal your commitment. If I guessed correctly I win, if not you win.
Unfortunately, if we were to just use a one-way function like an SHA hash function, it would be very trivial for me to win. All I would need to do would be to try passing "heads" and "tails" to the one-way function and see which one matches the commitment you gave me. Then I can very easily find out what your committed value was, winning the game consistently. In hacking, this can be made easier by making Rainbow Tables, and is precisely the technique used to derive passwords from password databases containing hashes of the passwords.
The way to solve this is to add a salt. This is basically just a large random number that we prepend (or append, order doesn't matter) to the actual value you want to commit to. This means that not only do I have to feed "heads" or "tails", I also have to guess the large random number (the salt). If the possible space of large random numbers is large enough, this prevents me from being able to peek at your committed data. The salt is sometimes called a blinding factor.

Pay-to-contract

Hiding commitments in pubkeys!
Pay-to-contract allows you to publish a public key, whose private key you can derive, while also being a cryptographic commitment. In particular, your private key is also used to derive a salt.
The key insight here is to realize that "one-way function" is not restricted to hash functions like SHA. The operation below is an example of a one-way function too:
h(a) = a * G 
This results in a point, but once the point (the output) is known, it is not possible to derive the input (the scalar a above). This is of course restricted to having the input be a scalar only, instead of an arbitrary-length message, but you can add a hash function (which can accept an arbitrary-length input) and then make its output (a fixed-length scalar) as the scalar to use.
First, pay-to-contract requires you to have a public and private keypair.
; p is private key P = p * G ; P is now public key 
Then, you have to select a contract. This is just any arbitrary message containing any arbitrary thing (it could be an object for Twenty Questions, or "heads" or "tails" for Coin Toss Guessing). Traditionally, this is symbolized as the small letter s.
In order to have a pay-to-contract public key, you need to compute the below from your public key P (called the internal public key; by analogy the private key p is the internal private key):
Q = P + h(P | s) * G 
"h()" is any convenient hash function, which takes anything of arbitrary length, and outputs a scalar, which you can multiply by G. The syntax "P | s" simply means that you are prepending the point P to the contract s.
The cute thing is that P serves as your salt. Any private key is just an arbitrary random scalar. Multiplying the private key by the generator results in an arbitrary-seeming point. That random point is now your salt, which makes this into a genuine bonafide hiding cryptographic commitment!
Now Q is a point, i.e. a public key. You might be interested in knowing its private key, a scalar. Suppose you postulate the existence of a scalar q such that:
 Q = q * G 
Then you can do the below:
 Q = P + h(P | s) * G Q = p * G + h(P | s) * G Q = (p + h(P | s)) * G 
Then we can conclude that:
 q = p + h(P | s) 
Of note is that somebody else cannot learn the private key q unless they already know the private key p. Knowing the internal public key P is not enough to learn the private key q. Thus, as long as you are the only one who knows the internal private key p, and you keep it secret, then only you can learn the private key q that can be used to sign with the public key Q (that is also a pay-to-contract commitment).
Now Q is supposed to be a commitment, and once somebody else knows Q, they can challenge you to reveal your committed value, the contract s. Revealing the pay-to-contract commitment is done by simply giving the internal public key P (which doubles as the salt) and the committed value contract s.
The challenger then simply computes:
P + h(P | s) * G 
And verifies that it matches the Q you gave before.
Some very important properties are:
  1. If you reveal first, then you still remain in sole control of the private key. This is because revelation only shows the internal public key and the contract, neither of which can be used to learn the internal private key. So you can reveal and sign in any order you want, without precluding the possibility of performing the other operation in the future.
  2. If you sign with the public key Q first, then you do not need to reveal the internal public key P or the contract s. You can compute q simply from the internal private key p and the contract s. You don't even need to pass those in to your signing algorithm, it could just be given the computed q and the message you want to sign!
  3. Anyone verifying your signature using the public key Q is unaware that it is also used as a cryptographic commitment.
Another property is going to blow your mind:
  1. You don't have to know the internal private key p in order to create a commitment pay-to-contract public key Q that commits to a contract s you select.
Remember:
Q = P + h(P | s) * G 
The above equation for Q does not require that you know the internal private key p. All you need to know is the internal public key P. Since public keys are often revealed publicly, you can use somebody else's public key as the internal public key in a pay-to-contract construction.
Of course, you can't sign for Q (you need to know p to compute the private key q) but this is sometimes an interesting use.
The original proposal for pay-to-contract was that a merchant would publish their public key, then a customer would "order" by writing the contract s with what they wanted to buy. Then, the customer would generate the public key Q (committing to s) using the merchant's public key as the internal public key P, then use that in a P2PKH or P2WPKH. Then the customer would reveal the contract s to the merchant, placing their order, and the merchant would now be able to claim the money.
Another general use for pay-to-contract include publishing a commitment on the blockchain without using an OP_RETURN output. Instead, you just move some of your funds to yourself, using your own public key as the internal public key, then selecting a contract s that commits or indicates what you want to anchor onchain. This should be the preferred technique rather than OP_RETURN. For example, colored coin implementations over Bitcoin usually used OP_RETURN, but the new RGB colored coin technique uses pay-to-contract instead, reducing onchain bloat.

Taproot

Pay-to-contract is also used in the nice new Taproot concept.
Briefly, taproot anchors a Merkle tree of scripts. The root of this tree is the contract s committed to. Then, you pay to a SegWit v1 public key, where the public key is the Q pay-to-contract commitment.
When spending a coin paying to a SegWit v1 output with a Taprooted commitment to a set of scripts s, you can do one of two things:
  1. Sign directly with the key. If you used Taproot, use the commitment private key q.
  2. Reveal the commitment, then select the script you want to execute in the Merkle tree of scripts (prove the Markle tree path to the script). Then satisfy the conditions of the script.
Taproot utilizes the characteristics of pay-to-contract:
  1. If you reveal first, then you still remain in sole control of the private key.
    • This is important if you take the Taproot path and reveal the commitment to the set of scripts s. If your transaction gets stalled on the mempool, others can know your commitment details. However, revealing the commitment will not reveal the internal private key p (which is needed to derive the commitment private key q), so nobody can RBF out your transaction by using the sign-directly path.
  2. If you sign with the public key Q first, then you do not need to reveal the internal public key P or the contract s.
    • This is important for privacy. If you are able to sign with the commitment public key, then that automatically hides the fact that you could have used an alternate script s instead of the key Q.
  3. Anyone verifying your signature using the public key Q is unaware that it is also used as a cryptographic commitment.
    • Again, privacy. Fullnodes will not know that you had the ability to use an alternate script path.
Taproot is intended to be deployed with the switch to Schnorr-based signatures in SegWit v1. In particular, Schnorr-based signatures have the following ability that ECDSA cannot do except with much more difficulty:
As public keys can, with Schnorr-based signatures, easily represent an n-of-n signing set, the internal public key P can also actually be a MuSig n-of-n signing set. This allows for a number of interesting protocols, which have a "good path" that will be private if that is taken, but still have fallbacks to ensure proper execution of the protocol and prevent attempts at subverting the protocol.

Escrow Under Taproot

Traditionally, escrow is done with a 2-of-3 multisignature script.
However, by use of Taproot and pay-to-contract, it's possible to get more privacy than traditional escrow services.
Suppose we have a buyer, a seller, and an escrow service. They have keypairs B = b * G, S = s * G, and E = e * G.
The buyer and seller then generate a Taproot output (which the buyer will pay to before the seller sends the product).
The Taproot itself uses an internal public key that is the 2-of-2 MuSig of B and S, i.e. MuSig(B, S). Then it commits to a pair of possible scripts:
  1. Release to a 2-of-2 MuSig of seller and escrow. This path is the "escrow sides with seller" path.
  2. Release to a 2-of-2 MuSig of buyer and escrow. This path is the "escrow sides with buyer" path.
Now of course, the escrow also needs to learn what the transaction was supposed to be about. So what we do is that the escrow key is actually used as the internal public key of another pay-to-contract, this time with the script s containing the details of the transaction. For example, if the buyer wants to buy some USD, the contract could be "Purchase of 50 pieces of United States Federal Reserve Green Historical Commemoration papers for 0.357 satoshis".
This takes advantage of the fact that the committer need not know the private key behind the public key being used in a pay-to-contract commitment. The actual transaction it is being used for is committed to onchain, because the public key published on the blockchain ultimately commits (via a taproot to a merkle tree to a script containing a MuSig of a public key modified with the committed contract) to the contract between the buyer and seller.
Thus, the cases are:
  1. Buyer and seller are satisfied, and cooperatively create a signature that spends the output to the seller.
    • The escrow service never learns it could have been an escrow. The details of their transaction remain hidden and private, so the buyer is never embarrassed over being so tacky as to waste their hard money buying USD.
  2. The buyer and seller disagree (the buyer denies having received the goods in proper quality).
    • They contact the escrow, and reveal the existence of the onchain contract, and provide the data needed to validate just what, exactly, the transaction was supposed to be about. This includes revealing the "Purchase of 50 pieces of United States Federal Reserve Green Historical Commemoration papers for 0.357 satoshis", as well as all the data needed to validate up to that level. The escrow then investigates the situation and then decides in favor of one or the other. It signs whatever transaction it decides (either giving it to the seller or buyer), and possibly also extracts an escrow fee.

Smart Contracts Unchained

Developed by ZmnSCPxj here: https://zmnscpxj.github.io/bitcoin/unchained.html
A logical extension of the above escrow case is to realize that the "contract" being given to the escrow service is simply some text that is interpreted by the escrow, and which is then executed by the escrow to determine where the funds should go.
Now, the language given in the previous escrow example is English. But nothing prevents the contract from being written in another language, including a machine-interpretable one.
Smart Contracts Unchained simply makes the escrow service an interpreter for some Smart Contract scripting language.
The cute thing is that there still remains an "everything good" path where the participants in the smart contract all agree on what the result is. In that case, with Taproot, there is no need to publish the smart contract --- only the participants know, and nobody else has to. This is an improvement in not only privacy, but also blockchain size --- the smart contract itself never has to be published onchain, only the commitment to it is (and that is embedded in a public key, which is necessary for basic security on the blockchain anyway!).

Sign-to-contract

Hiding commitments in signatures!
Sign-to-contract is something like the dual or inverse of pay-to-contract. Instead of hiding a commitment in the public key, it is hidden in the signature.
Sign-to-contract utilizes the fact that signatures need to have a random scalar r which is then published as the point R = r * G.
Similarly to pay-to-contract, we can have an internal random scalar p and internal point P that is used to compute R:
R = P + h(P | s) * G 
The corresponding random scalar r is:
r = p + h(P | s) 
The signing algorithm then uses the modified scalar r.
This is in fact just the same method of commitment as in pay-to-contract. The operations of committing and revealing are the same. The only difference is where the commitment is stored.
Importantly, however, is that you cannot take somebody else's signature and then create an alternate signature that commits to some s you select. This is in contrast with pay-to-contract, where you can take somebody else's public key and then create an alternate public key that commits to some s you select.
Sign-to-contract is somewhat newer as a concept than pay-to-contract. It seems there are not as many applications of pay-to-contract yet.

Uses

Sign-to-contract can be used, like pay-to-contract, to publish commitments onchain.
The difference is below:
  1. Signatures are attached to transaction inputs.
  2. Public keys are attached to transaction outputs.
One possible use is in a competitor to Open Timestamps. Open Timestamps currently uses OP_RETURN to commit to a Merkle Tree root of commitments aggregated by an Open Timestamps server.
Instead of using such an OP_RETURN, individual wallets can publish a timestamped commitment by making a self-paying transaction, embedding the commitment inside the signature for that transaction. Such a feature can be added to any individual wallet software. https://blog.eternitywall.com/2018/04/13/sign-to-contract/
This does not require any additional infrastructure (i.e. no aggregating servers like in Open Timestamps).

R Reuse Concerns

ECDSA and Schnorr-based signature schemes are vulnerable to something called "R reuse".
Basically, if the same R is used for different messages (transactions) with the same public key, a third party with both signatures can compute the private key.
This is concerning especially if the signing algorithm is executed in an environment with insufficient entropy. By complete accident, the environment might yield the same random scalar r in two different runs. Combined with address reuse (which implies public key reuse) this can leak the private key inadvertently.
For example, most hardware wallets will not have any kind of entropy at all.
The usual solution to this is, instead of selecting an arbitrary random r (which might be impossible in limited environments with no available entropy), is to hash the message and use the hash as the r.
This ensures that if the same public key is used again for a different message, then the random r is also different, preventing reuse at all.
Of course, if you are using sign-to-contract, then you can't use the above "best practice".
It seems to me plausible that computing the internal random scalar p using the hash of the message (transaction) should work, then add the commitment on top of that. However, I'm not an actual cryptographer, I just play one on Reddit. Maybe apoelstra or pwuille can explain in more detail.
Copyright 2019 Alan Manuel K. Gloria. Released under CC-BY.
submitted by almkglor to Bitcoin [link] [comments]

I decided to post this here as I saw some questions on the QRL discord.

Is elliptic curve cryptography quantum resistant?
No. Using a quantum computer, Shor's algorithm can be used to break Elliptic Curve Digital Signature Algorithm (ECDSA). Meaning: they can derive the private key from the public key. So if they got your public key, they got your private key, and they can empty your funds. https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_attacks https://eprint.iacr.org/2017/598.pdf
Why do people say that BTC is quantum resistant, while they use elliptic curve cryptography? (Here comes the idea from that never reusing a private key from elliptic curve cryptography (and public key since they form a pair) would be quantum resistant.)
Ok, just gonna start with the basics here. Your address, where you have your coins stalled, is locked by your public- private key pair. See it as your e-mail address (public key) and your password (Private key). Many people got your email address, but only you have your password. If you got your address and your password, then you can access your mail and send emails (Transactions). Now if there would be a quantum computer, people could use that to calculate your password/ private key, if they have your email address/ public key.
What is the case with BTC: they don't show your public key anywhere, untill you make a transaction. So your public key is private untill you make a transaction. How do they do that while your funds must be registered on the ledger? Wel, they only show the Hash of your public key (A hash is an outcome of an equation. Usually one-way hash functions are used, where you can not derive the original input from the output. But everytime you use the same hash function on the same original input (For example IFUHE8392ISHF), you will always get the same output (For example G). That way you can have your coins on public key IFUHE8392ISHF, while on the chain, they are on G.) So your funds are registered on the blockchain on the "Hash" of the public key. The Hash of the public key is also your "email address" in this case. So you give "G" as your address to send BTC to.
By the way, in the early days you could use your actual public key as your address. And miners would receive coins on their public key, not on the hashed public key. That is why all the Satoshi funds are vulnerable to quantum attacks even though these addresses have never been used to make transactions from. These public keys are already public instead of hashed. Also certain hard forks have exposed the public keys of unused addresses. So it's really a false sense of security that most people hang on to in the first place.
But it's actually a false sense of security over all.
Since it is impossible to derive a public key from the Hash of a public key, your coins are safe for quantum computers as long as you don't make any transaction. Now here follows the biggest misconseption: Pretty much everyone will think, great, so BTC is quantum secure! It's not that simple. Here it is important to understand two things:
1 How is a transaction sent? The owner has the private key and the public key and uses that to log into the secured environment, the wallet. This can be online or offline. Once he is in his wallet, he states how much he wants to send and to what address.
When he sends the transaction, it will be broadcasted to the blockchain network. But before the actual transaction that will be sent, it is formed into a package, created by the wallet. This happens out of sight of the sender.
That package ends up carrying roughly the following info: The public key to point to the address where the funds will be coming from, the amount that will be transferred, the public key of the address the funds will be transferred to.
Then this package caries the most important thing: a signature, created by the wallet, derived from the private- public key combination. This signature proves to the miners that you are the rightfull owner and you can send funds from that public key.
So this package is then sent out of the secure wallet environment to multiple nodes. The nodes don’t need to trust the sender or establish the sender’s "identity." And because the transaction is signed and contains no confidential information, private keys, or credentials, it can be publicly broadcast using any underlying network transport that is convenient. As long as the transaction can reach a node that will propagate it into the network, it doesn’t matter how it is transported to the first node.
2 How is a transaction confirmed/ fullfilled and registered on the blockchain?
After the transaction is sent to the network, it is ready to be processed. The nodes have a bundle of transactions to verify and register on the next block. This is done during a period called the block time. In the case of BTC that is 10 minutes.
If you comprehend the information written above, you can see that there are two moments where you can actually see the public key, while the transaction is not fullfilled and registered on the blockchain yet.
1: during the time the transaction is sent from the sender to the nodes
2: during the time the nodes verify the transaction.
This paper describes how you could hijack a transaction and make a new transaction of your own, using someone elses address to send his coins to an address you own during moment 2: the time the nodes verify the transaction:
https://arxiv.org/pdf/1710.10377.pdf
"(Unprocessed transactions) After a transaction has been broadcast to the network, but before it is placed on the blockchain it is at risk from a quantum attack. If the secret key can be derived from the broadcast public key before the transaction is placed on the blockchain, then an attacker could use this secret key to broadcast a new transaction from the same address to his own address. If the attacker then ensures that this new transaction is placed on the blockchain first, then he can effectively steal all the bitcoin behind the original address."
So this means that practically, you can't call BTC a quantum secure blockchain. Because as soon as you will touch your coins and use them for payment, or send them to another address, you will have to make a transaction and you risk a quantum attack.
Why would Nexus be any differtent?
If you ask the wrong person they will tell you "Nexus uses a combination of the Skein and Keccak algorithms which are the 2 recognized quantum resistant algorithms (keccal is used by the NSA) so instead of sha-256, Nexus has SK-1024 making it much harder to break." Which would be the same as saying BTC is quantum resistant because they use a Hashing function to hash the private key as long as no transaction is made.
No, this is their sollid try to be quantum resistant: Nexus states it's different because they have instant transactions (So there wouldn't be a period during which time the nodes verify the transaction. This period would be instant.) Also they use a particular order in which the miners verify transactions: First-In-First-Out (FIFO) (So even if instant is not instant after all, and you would be able to catch a public key and derive the private key, you would n't be able to have your transaction signed before the original one. The original one is first in line, and will therefore be confirmed first. Also for some reason Nexus has standardized fees which are burned after a transaction. So if FIFO wouldn't do the trick you would not be able to use a higher fee to get prioritized and get an earlyer confirmation.
So, during during the time the nodes verify the transaction, you would not be able to hijack a transaction. GREAT, you say? Yes, great-ish. Because there is still moment # 1: during the time the transaction is sent from the sender to the nodes. This is where network based attacks could do the trick:
There are network based attacks that can be used to delay or prevent transactions to reach nodes. In the mean time the transactions can be hijacked before they reach the nodes. And thus one could hijack the non quantum secure public keys (they are openly included in sent signed transactions) who then can be used to derive privatekeys before the original transaction is made. So this means that even if Nexus has instant transactions in FIFO order, it is totally useless, because the public key would be obtained by the attacker before they reach the nodes. Conclusion: Nexus is Nnot quantum resistant. You simply can't be without using a post quantum signature scheme.
Performing a DDoS attack or BGP routing attacks or NSA Quantum Insert attacks on a peer to peer newtork would be hard. But when provided with an opportunitiy to steal billions, hackers would find a way. For example:
https://bitcoinmagazine.com/articles/researchers-explore-eclipse-attacks-ethereum-blockchain/
For BTC:
https://eprint.iacr.org/2015/263.pdf
"An eclipse attack is a network-level attack on a blockchain, where an attacker essentially takes control of the peer-to-peer network, obscuring a node’s view of the blockchain."
That is exactly the receipe for what you would need to create extra time to find public keys and derive private keys from them. Then you could sign transactions of your own and confirm them before the originals do.
By the way, yes this seems to be fixed now, but it most definately shows it's possible. And there are other creative options. Either you stop tranasctions from the base to get out, while the sender thinks they're sent, or you blind the network and catch transactions there. There are always options, and they will be exploited when billions are at stake. The keys can also be hijacked when a transaction is sent from the users device to the blockchain network using a MITM attack. The result is the same as for network based attacks, only now you don't mess with the network itself. These attacks make it possible to 1) retrieve the original public key that is included in the transaction message. 2) Stop or delay the transaction message to arrive at the blockchain network. So, using a quantum computer, you could hijack transactions and create forged transactions, which you then send to the nodes to be confirmed before the nodes even receive the original transaction. There is nothing you could change to the Nexus network to prevent this. The only thing they can do is implement a quantum resistant signature scheme. They plan to do this in the future, like any other serious blockchain project. Yet Nexus is the only of these future quantum resistant projects to prematurely claim to be quantum resistant. There is only one way to get quantum resistancy: POST QUANTUM SIGNATURE SCHEMES. All the rest is just a shitty shortcut that won't work in the end.
(If you use this info on BTC, you will find that the 10 minutes blocktime that is used to estimate when BTC will be vulnerable for quantum attacks, can actually be more then 10 minutes if you catch the public key before the nodes receive them. This makes BTC vulnerable sooner thatn the 10 min blocktime would make you think.)
By the way, Nexus using FIFO and standadrized fees which are burned after the transaction comes with some huge downsides:
Why are WOTS+ signatures (and by extension XMSS) more quantum resistant?
First of all, this is where the top notch mathematicians work their magic. Cryptography is mostly maths. As Jackalyst puts it talking about post quantum signature schemes: "Having papers written and cryptographers review and discuss it to nauseating levels might not be important for butler, but it's really important with signature schemes and other cryptocraphic methods, as they're highly technical in nature."
If you don't believe in math, think about Einstein using math predicting things most coudldn't even emagine, let alone measure back then.
Then there is implementing it the right way into your blockchain without leaving any backdoors open.
So why is WOTS+ and by extension XMSS quantum resistant? Because math papers say so. With WOTS it would even take a quantum computer too much time to derive a private key from a public key. https://en.wikipedia.org/wiki/Hash-based_cryptography https://eprint.iacr.org/2011/484.pdf
What is WOTS+?
It's basiclally an optimized version of Lamport-signatures. WOTS+ (Winternitz one-time signature) is a hash-based, post-quantum signature scheme. So it's a post quantum signature scheme meant to be used once.
What are the risks of WOTS+?
Because each WOTS publishes some part of the private key, they rapidly become less secure as more signatures created by the same public/private key are published. The first signature won't have enough info to work with, but after two or three signatures you will be in trouble.
IOTA uses WOTS. Here's what the people over at the cryptography subreddit have to say about that:
https://www.reddit.com/crypto/comments/84c4ni/iota_signatures_private_keys_and_address_reuse/?utm_content=comments&utm_medium=user&utm_source=reddit&utm_name=u_QRCollector
With the article:
http://blog.lekkertech.net/blog/2018/03/07/iota-signatures/
Mochimo uses WOTS+. They kinda solved the problem: A transaction consists of a "Source Address", a "Destination Address" and a "Change Address". When you transact to a Destination Address, any remaining funds in your Source Address will move to the Change Address. To transact again, your Change Address then becomes your Source Address.
But what if someone already has your first address and is unaware of the fact you already send funds from that address? He might just send funds there. (I mean in a business environment this would make Mochimo highly impractical.) They need to solve that. Who knows, it's still a young project. But then again, for some reason they also use FIFO and fixed fees, so there I have the same objections as for Nexus.
How is XMSS different?
XMSS uses WOTS in a way that you can actually reuse your address. WOTS creates a quantum resistant one time signature and XMSS creates a tree of those signatures attached to one address so that the address can be reused for sending an asset.
submitted by QRCollector to QRL [link] [comments]

Peer-to-peer smart derivatives for any asset over any network!

Taurus0x Overview
Distributed off-chain / on-chain protocol powering smart derivatives from end to end, for any asset over any network.
Background of Taurus0x
Remember around September 2017 when the world lost its cool over Bitcoin prices? It was nearly an ideological war for many. It occurred to me to create an app for people to bid on Bitcoin prices, and I would connect that app to a smart contract to execute bids on the blockchain. It took me a long couple of weeks to figure out how many licenses I would need to acquire to run such a business in the United States. It became evident that market making is a huge undertaking and is better off decentralized in a an open-standard protocol to generate liquidity.
The protocol needed to be fully decentralized as a primary requirement. Why? because I believe in the philosophy of decentralization and creating fair market makers, governed by a public community. It is the right thing to do in order to create equal opportunity for consumers without centralized control and special privileges.
It comes at no surprise to anyone at this point that the vast majority of “ICOs” were empty promises. Real life utility was and is a necessity for any viable project. Transitioning from a centralized world to a tokenized and decentralized one cannot be abrupt. The protocol needed to support both worlds and allow for a free market outcome as far as adoption. Scalability-wise and as of today, Ethereum could not handle a real-time full DEX that could compete with advanced and well-known centralized exchanges. And quite frankly, maybe it’s not meant to. This is when the off-chain thinking started, especially after witnessing a couple of the most successful projects adopting this approach, like Lighting and 0xProject. The trade-off was the complexity of handling cryptographic communications without the help of the blockchain.
I had met my co-founder Brett Hayes at the time. I would need another 3 or 4 articles to explain Brett for you.
To the substance.
What is Asymmetrical Cryptography?
Asymmetrical cryptography is a form of cryptography that uses public and private key pairs. Each public key comes with its associated and unique private key. If you encrypt a piece of data with a private, only the associated public key may be used to decrypt the data. And vice versa.
If I send you a “hello” encrypted with my private key, and you try to decrypt it with my public key (which is no secret). If it decrypts fine, then you are positive that this “hello” came from me. This is what we call digital signatures.
The figure below is from Taurus0x whitepaper and describes the chosen digital signature algorithm (ECDSA).
https://preview.redd.it/n8kavgofbm211.png?width=1000&format=png&auto=webp&s=289695a17cd413b68105b249d615b82bae1fe1dc
What are Smart Derivatives?
Well, what are derivatives in the first place?
In the financial world, a derivative is a contract between two or more parties based upon an asset. Its price is determined by fluctuations in the underlying asset. The most common underlying assets include stocks, bonds, commodities, currencies, interest rates and market indexes. Futures contracts, forward contracts, options, swaps, cryptocurrency prices and warrants are common derivatives.
Smart Derivatives are smart contracts that behave like financial derivatives. They possess enough information and funds to allow for execution with guaranteed and trusted outcomes.
What is Taurus0x?
Taurus0x is a distributed off-chain / on-chain protocol powering smart derivatives from end to end. Taurus0x is both asset and network-agnostic. The philosophy is to also become blockchain-agnostic as more blockchains come to life.
Distributed = fully decentralized set of smart contracts and libraries.
Off-chain = ad-hoc protocol not limited to a blockchain.
On-chain= trusted outcome without intermediaries.
Asset-agnostic = supports any asset, not limited to cryptocurrency.
Network-agnostic = contracts can be transmitted over any network (email, text, twitter, facebook, pen and paper, etc.)
Who can use Taurus0x?
Taurus0x protocol is ultimately built to serve end consumers who trade derivative contracts. Participants may engage in a peer-to-peer derivative contracts among each other without the need for a house in the middle.
The Taurus0x team and advisory realize that the migration from a centralized world to a decentralized one cannot be abrupt, specifically in FinTech. Taurus0x is built to support existing business models as well as C2C peer-to-peer. Exchanges who want to take on the derivative market may use an open-source protocol without worrying about building a full backend to handle contract engagement and settlement. Taurus0x Exchanges would simply connect participants to each other, using matching algorithms.
Taurus0x intends to standardize derivative trading in an open way. Having more exchanges using the protocol allows for creating public and permission-ed pools to generate compounded liquidity of contracts. This helps smaller exchanges by lowering the entry-to-market barrier.
How does Taurus0x work?
The process is simple and straightforward. Implementation details are masked by the protocol making it very easy to build on top. The first 2 steps represent off-chain contract agreement, while 3 and 4 solidify and execute the contract on-chain.
1- Create
A producer creates a contract from any client using Taurus0x protocol, whether from an app, a website or a browser extension. The producer specifies a condition that is expected to happen sometime in the future. For example, I (the producer) might create a binary contract with the following condition:
Apple stock > $200 by July 1, 2018 with a premium of 10 TOKENs (any ERC20 token)
The contract will be automatically signed with my private key, which confirms that I created it. I can then share it (a long hexadecimal text) with anyone over any network I choose.
2- Sign
When the consumer receives the signed contract, they will be able to load it via any client using Taurus0x. If the consumer disagrees with the producer on the specified condition, they will go ahead and sign the contract with their private key. Back to our example above, the consumer would think that Apple stock will remain under $200 by July 1, 2018. Now that the we have collected both signatures, the contract is ready to get published on blockchain.
3- Publish
Anyone who possesses the MultiSig contract and its 2 signatures can go ahead and publish it to the Ethereum blockchain. That would most likely be either the producer, the consumer or a party like an exchange in the middle hosting off-chain orders. As soon as the contract is published, Taurus0x proxy (an open-source smart contract) will pull necessary funds from participating wallets into the newly created Smart Derivative. The funds will live in the derivative contract until successful execution.
4- Execute
If at any point before the contract expiration date the specified condition becomes true (i.e. Apple Stock > $200), the producer can go ahead and execute the derivative contract. The contract will calculate the outcome and transfer funds accordingly. In this binary derivative example, the producer will receive 20 TOKENs in their wallet upon executing the contract. If the expiration date comes and the producer had never successfully executed the contract, the consumer may execute it themselves and collect the 20 TOKENs.
This figure is from the Taurus0x whitepaper depicts the process:
https://preview.redd.it/vr2y9b8ibm211.png?width=1250&format=png&auto=webp&s=1b7a8144fe2a41116a4f64d7418d3dacb4f42fc5
Summary
Taurus0x is a highly versatile and modular protocol built using Ethereum-based smart contracts and wrapper JS libraries to bootstrap developer adoption. While Smart Derivatives are the first application of Taurus0x, it is worth noting that the protocol is not limited to cryptocurrencies or even derivatives for that matter. It is an ad-hoc and scalable contract management solution meant to guarantee trusted outcomes in the future based on conditions specified today. The semi off-chain nature of the protocol helps remediate Ethereum’s scalability limitations and makes it a viable product.
Finally, the plan for Taurus0x is to be governed by a Decentralized Autonomous Organization or DAO as outlined in the roadmap on https://taurus0x.com. This is an area of research and development as of today. Decentralization does not fulfill its purpose if governance remains centralized, therefore it is without compromise that Taurus0x follows a decentralized governance structure.
submitted by Taurus0x to Taurus0x [link] [comments]

InterValue: From Blockchain to Value Interconnect

https://preview.redd.it/k7ypmeqi1b611.jpg?width=1000&format=pjpg&auto=webp&s=187bbc2ead99a46ce258c5d2a15363637a9e393d
If not the sudden surge of the bitcoin, we may not know what the blockchain is, in other words, the bitcoin which exists almost ten years and was little known, then one day was mush rushed and let someone gets rich. Thus undoubtedly makes much concentration about the blockchain technology, people began to do research on it and found that the blockchain actually has the potential to change the world of the future. The speculators flocked to the blockchain, thus makes the situation that we familiar with.
Refer to the blockchain, most people just know little about it not the real gift at it. So even many people want to do research on it carefully but can not figure it. Thus we can see many people try to use lots of ways to give an explanation of the concept of a popular blockchain to netizens.
In a narrow sense, a blockchain is a chained data structure in which data blocks are sequentially connected in a time-ordered manner, and cryptography ensured non-falsifiable and unforgeable distributed ledgers.
Broadly speaking, blockchain technology is a completely new distributed infrastructure and computing paradigm that uses blockchain data structures to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to ensure data transmission and access, uses cryptography to secure data transmissions and access, and uses intelligent contracts composed of automated scripting code to program and manipulate data.
Blockchain technology is not only a fixed form that we familiar with, but it has passed many iterations since its beginning and is still undergoing continuous improvement and development.
01. Blockchain1.0: Cryptocurrency.
In early 2009, the Bitcoin network was officially launched. As a virtual currency system, the total amount of bitcoin is defined by network consensus protocol. No individual or institution can freely modify the supply and transaction records therein. The underlying technology of Bitcoin, the Blockchain, actually an extremely ingenious distributed shared ledger and peer-to-peer value transfer technology that has the potential to affect as much as the invention of double-entry bookkeeping.
02. Blockchain 2.0: Smart contracts.
Around 2014, industry community began to recognize the importance of Blockchain technology, and create a common technology platform to provide developers with BaaS (Blockchain as a service), which greatly improve the transaction speed, reduce resource consumption. Ethereum, the smart contract initiator, took the blockchain into the 2.0 era. The Blockchain 2.0 application incorporates the concept of “smart contracts” (using program algorithms instead of human execution contracts). This allows the blockchain to expand from the initial currency system to the registration and transfer of equity, claims and property rights, the trading and execution of securities and financial contracts, and even financial sectors such as gaming and anti-counterfeiting.
03. Blockchain 3.0: Blockchain technology application.
After 2015, with the rise of Blockchain 3.0 technology based on DAG data structures, such as Byteball and IOTA, Blockchain systems are more efficient, scalable, highly interoperable, and offer a better us experience than before. Applications of Blockchain gradually extend to healthcare,
IP copyright, education, and IOT. Broader applications such as sharing economy, communications, social management, charity, culture, and entertainment.
04. Blockchain 4.0: Blockchain ecosystem.
Recently, Blockchain 4.0 technology based on Hashgraph data structure has gradually attracted the attention of industry community. The consensus algorithm based on Hashgraph can achieve a qualitative growth in transaction throughput and scalability. The Blockchain will become the infrastructure of industry and form a consolidated ecosystem, which also changes people’s lifestyle extensively and profoundly.
05. From Blockchain to value interconnect
The Internet has realized that some information in the human society is transferred and shared on the Internet and creates information interconnect. The blockchain will realize the transfer and sharing of all information including all digital assets and real assets of the human society on the value-based Internet, creating value. interconnected. The realization of value interconnect, namely the realization of various underlying network protocols for value transmission networks, the construction of global value Internet, and the provision of basic networks for various types of value transmission applications, is the great vision of the InterValue project.
Key technologies in platform and features in Blockchain infrastructure are the topmost focus for InterValue. The features include the anonymous P2P protocols, a novel anti-quantum hash algorithm and a novel signature algorithm, a unique double-layer consensus and mining mechanism for transactional anonymous protection, a Turing complete smart contracts, etc. It uses fair distribution mechanism to support third-party asset distribution, cross-chain communications, multi-chain merging functions such as public chain, permissioned chain, consortium chain and mother forms fall into the practical application of the Blockchain 4.0 infrastructure.
In order to create a completely decentralized network value transmission ecosystem and completely open community ecosystem, InterValue has made significant improvements in all aspects of the blockchain infrastructure and has made breakthrough innovations at some levels.
Major technological innovation include:
  1. Consensus: we design an efficient and secure double-layer consensus mechanism consisting of HashNet consensus and BA-VRF (Byzantine Agreement based on Verifiable Random Function) consensus, which supports high transaction concurrency, fast confirmation and building eco-systems for different application scenarios.
  2. Crossing and merging chains, we adopt chain-relaying technology to solve the problems in crossing chains transaction and transparent operations among multiple chains, which not only can maintain the independence of crossing chains operation, but also reuses various functions of InterValue.
  3. Industrial application, we design lots of industrial common interfaces in form of JSON-RPC, satisfying diƈerent scenarios such as circulation payment data transmission, data search, and contract invocation.
  4. Smart contracts, we design Moses virtual machine (MVM) which supports declarative non-Turing complete contract as well as advanced Turing complete contract programmed in Moses language. MVM is able to access oƈ-Blockchain data conveniently and securely, and supports the issuance of third-party assets, which can be integrated into applications in terms of public, permissioned (private) or consortium (hybrid) Blockchain.
  5. Anti-quantum attack, new anti-quantum algorithms are devised, which replaces existing SHA series algorithm with the Keccak-512 hash algorithm, and replaces ECDSA signature algorithm with an integer lattice-based NTRUsign signature algorithm. These algorithms reduce the threat coming from development of quantum computing and gradual popularization of the quantum computer.
  6. Transaction anonymity, based on anonymity characteristics of cryptocurrency such as Monero and ZCash, zero-knowledge proof and ring signature are applied to transaction anonymity and privacy protection, which performs with high cost-effective ratio and excellent security to satisfy privacy requirements in different application scenarios.
  7. Underlying P2P network, combining the advantages of Tor-based anonymity and Blockchain-based distributed VPN, we design a novel anonymous P2P overlay network, including anonymous access method and encrypted communication protocol, which greatly enhances anonymity of nodes in the network and ensures that it’s hard to trace node address and to crack communication protocol.
  8. Ecological motivation, various token allocation methods are used, which support double-layer mining for incentives.
InterValue Key Features Design
In the world where InterValue is widely used, people can realize automatic payment, automatic evaluation, automatic preservation, and automatic judgment of legality in any behaviors and activities. People can choose whether or not their lifelong activities and activities are preserved. A virtual person who possesses the individual’s complete awareness and complete autonomous intelligence are born. After the people completely transfer the various assets in real life to the chain, the virtual person representing a personal social entity will be together with the individual assets, and will be kept on the chain forever. Evolution has continued to realize the virtual eternal life of human society, so that each participant can obtain a corresponding value manifestation and lead human beings to the world of value interconnect.
submitted by intervalue to u/intervalue [link] [comments]

Authentication BIP | Jonas Schnelli | Aug 08 2016

Jonas Schnelli on Aug 08 2016:
Hi
As already mentioned in the recent BIP151 thread
(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012826.html),
I propose the following authentication scheme to basically allow MITM
detection and rejection in conjunction with BIP151.
The proposed authentication BIP does require BIP151.
The propose BIP does assume, node operators want to build trusted
connections for various reasons.
BIPs mediawiki github page available here:
https://github.com/bitcoin/bips/compare/master...jonasschnelli:2016/07/auth_bip?expand=1

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

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

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

authorized-peers contains authorized identity-public-keys

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

-> Requesting peer sends AUTHCHALLENGE (hash)

<- Responding peer sends AUTHREPLY (signature)

-> Requesting peer sends AUTHPROPOSE (hash)

<- Responding peer sends AUTHCHALLENGE (hash)

-> Requesting peer sends AUTHREPLY (signature)

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

Requesting peer and responding peer create each an identity-keypair

(standard ECC priv/pubkey)

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

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

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

authorized-peers database (A)

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

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

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

Authentication

Requesting peer sends an AUTHCHALLENGE message

AUTHCHALLENGE:
[32 bytes, hash(encryption-session-ID || "i" || 
)]

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

"i" || )` with its local
identity-public-key

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

containing 64bytes of zeros.

In case of a match, response with an AUTHREPLY message

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

Requesting peer does verify the signature with the

remote-peers-identity-public-key

If the signature is invalid, requesting peer answers with an

AUTHREPLY message containing 32 random bytes

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

message
AUTHPROPOSE:
[32 bytes, hash(encryption-session-ID || "p" || 
)]

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

the identical data and looks for a match.

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

AUTHCHALLENGE message containing 32 bytes of zeros.

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

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

Requesting peer sends an AUTHREPLY message containing 64 bytes of

zeros if server failed to authenticate

Otherwise, response with signature in the AUTHREPLY message

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

Responding peer must verify the signature and can grant access to

restricted services.

Both peers re-key the encryption after BIP151 including the

requesting-peer-identity-public-key and responding-peer-identity-public-key
== Disad...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/012947.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Bitcoin 101 Elliptic Curve Cryptography Part 5 The Magic of Signing & Verifying Bitcoin Signature Tool for Decentralized Services Market Blockchain tutorial 11: Elliptic Curve key pair generation ... How to recover your Bitcoin private key-Facebook like @findBTC Public Key Encryption: Elliptic Curve Ciphers

In ECDSA a private key can be used to calculate the corresponding public key, and since a Bitcoin address is calculated from the public key, if you hold a private key securely you effectively have everything. The ECDSA private key in Bitcoin is just a very large random number consisting of 256 bits or 32 bytes or 64 hexadecimal digits. Nearly all 256-bit numbers can be valid private keys as ... A public Key and a private key is generated for user1. Now I want to use that private key to sign simple data and later verify using the public Key. I have tried using URSA node module which works fine with RSA keys generated through OpenSSL but isn't working with these two keys. Probably because these keys are not RSA, they are ECDSA keys. Example 10: Print out an ECDSA public key from its private key. The most commonly used types of key pairs are RSA and ECDSA and differ on the mathematical basis for the key pair generation which gives them some proper properties. The current public key for signatureKeyId is available in Google Pay Public Key. First Using public key we have sign data. p12) containing a private key and ... Bitcoin uses the ECDSA algorithm to produce the above-mentioned keys. The purpose of our work is to present some useful motifs for the domain parameters of base point (P) and the order (n) of the subgroup produced by it, while choosing the elliptic curve and the Galois field on which we formulate the algorithm, in order to obtain safer private keys. The results of the research are experimental ... Public Key Recovery from Extended ECDSA Signature. The range of valid private keys is governed by the secp256k1 ECDSA standard used by Bitcoin. Digitally sign a PDF file using a PKCS#11/Cryptoki device (for example, HSM, USB token or smart card). 509 Cert Public Key Algorithm: EC I've used the following private key :) Note: The key is converted to pkcs12 store with openssl pkcs12 -export -in ...

[index] [14508] [11069] [45544] [27561] [28296] [10112] [39006] [17697] [49683] [41047]

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

This video shows how easy it is to paste, verify, and sign a message using an ECDSA private key behind a Bitcoin address. bitcoin Private keys - puzzle 3,4,5 2019 lucky enough to find 3.8 million bitcoins lying dormant - Duration: 5:01. ICON BTCX 22,812 views. 5:01. Bitcoin 101 - Quindecillions & The Amazing Math Of Bitcoin's Private Keys - Duration: 23:51. ... Fast Secure Two Party ECDSA Signing - Duration: 22:08. TheIACR 1,663 views. 22:08 . How Bitcoin ... Elliptic Curve Digital Signature Algorithm ECDSA Part 10 Cryptography Crashcourse - Duration: 35:32. Dr. Julian Hosp - Bitcoin, Aktien, Gold und Co. 5,803 views This is part 11 of the Blockchain tutorial explaining how the generate a public private key using Elliptic Curve. In this video series different topics will ...

#