ECDSA bitFlyer USA

[ANN] RustCrypto: `k256` and `p256` v0.2.0: pure Rust secp256k1 and NIST P-256 ECDH and ECDSA (no_std/embedded-friendly)

Announcing v0.4.0 releases of these RustCrypto elliptic curve crates:
(see also ecdsa v0.7 and p384 v0.3)
The major notable new features in these releases are:

Elliptic Curve Diffie-Hellman

Key exchange protocol which establishes a shared secret between two parties.

Elliptic Curve Digital Signature Algorithm

Pervasively used public-key scheme for authenticating messages.

Notes on this release

These crates contain experimental pure Rust implementations of scalafield arithmetic for the respective elliptic curves (secp256k1, NIST P-256). These implementations are new, unaudited, and haven't received much public scrutiny. We have explicitly labeled them as being at a "USE AT YOUR OWN RISK" level of maturity.
That said, these implementations utilize the best modern practices for this class of elliptic curves (complete projective formulas providing constant time scalar multiplication).
In particular:
This release has been a cross-functional effort, with contributions from some of the best Rust elliptic curve cryptography experts. I'd like to thank everyone who's contributed, and hope that these crates are useful, especially for embedded cryptography and cryptocurrency use cases.
EDIT: the version in the title is incorrect. The correct version is v0.4.0, unfortunately the title cannot be edited.
submitted by bascule to rust [link] [comments]

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

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

Anyswap - A completely decentralized swap exchange the supports all your coins

Hello crypto enthusiasts,
After the recent run up of DEFI products and massive price movements, I’ve come across an innovative product with tremendous upside potential. If you have used Uniswap in the past, and are bound to only swapping Ethereum with Ethereum based tokens, a pressing problem arises... ‘How come I can’t use my Bitcoin, XRP, Litecoin, etc. to make the swap? Why do I have to trade into Ether, to gain access to these tokens?’
Enter Anyswap...
Anyswap
Anyswap is the first completely decentralized swap exchange that will allow you to use any coin or tokens (ECDSA and EDDSA as signature algorithms - 98% of all blockchains) with one another. No third party risk.
The ANY token issued is a governance token, which will allow voting rights for holders to choose which coins will be listed next. No ICO, no fund raising, no airdrop, no premine. Get em while there hot.
Mark your calendar... July 20th 2020, ANY token will be available for purchase. Join their telegram group for more info Anyswap TG
Thanks for listening. And to the mooooon 🚀🚀🚀
submitted by g_marc to CryptoMoonShots [link] [comments]

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

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

Gains x Streamr AMA Recap

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

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]

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

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

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

tBTC an erc20 wrapped version of BTC, like erc20 wBTC; but is trustless and does not require a centralised party to mint wrapped btc like wBTC

I found this article on /Ethereum though it didnt go into the specs of how this works:
https://np.reddit.com/ethereum/comments/ftqdna/bitcoin_to_ethereum_bridge_raises_77_million_in/
https://decrypt.co/24336/bitcoin-to-ethereum-bridge-raises-7-7-million-in-token-sale?utm_source=reddit&utm_medium=social&utm_campaign=sm
as the article says wrapped bitcoin has been done before e.g. wBTC but wBTC requires a centralised party to mint wBTC from BTC held by this party; making it out of the question as its centralised.
did some digging there is a whitepaper , but i wanted more details on the tBTC implementation.
I went on their github and looked at the readme on some projects; found a few interesting things, though not an entire explanation.
https://github.com/keep-network/tbtc
tBTC is a trustlessly Bitcoin-backed ERC-20 token.
The goal of the project is to provide a stronger 2-way peg than federated sidechains like Liquid, expanding use cases possible via today’s Bitcoin network, while bringing superior money to other chains.
This repo contains the Solidity smart contracts and specification.
https://github.com/keep-network/tbtc
tbtc.js provides JS bindings to the tBTC system. The tBTC system is a bonded, multi-federated peg made up of many deposits backed by single-use BTC wallets to enable their value’s corresponding usage on the Ethereum chain, primarily through the minting of a TBTC ERC20 token whose supply is guaranteed to be backed by at least 1 BTC per TBTC in circulation.
finally this is the best:
https://tbtc.network/developers/tbtc-technical-system-overview
here is the first few pargarphs
2020-04-01 tBTC incorporates novel design features that carry important implications for users. This piece explains four of these: TDT receipts, multiple lot sizes, Keep's random beacon, and threshold signatures.
TBTC Deposit Token (TDT) The TBTC Deposit Token (TDT) is a non-fungible token that is minted when a user requests a deposit. A TDT is a non-fungible ERC-721 token that serves as a counterpart to TBTC. It represents a claim to a deposit's underlying UTXO on the Bitcoin blockchain.
TBTC deposits can be locked or unlocked. A locked deposit can only be redeemed by the deposit owner with the corresponding TDT. Each TDT is unique to the deposit that mints it and carries the exclusive right for up to a 6 month term to redeem the deposit.
also this paragraph addresses creating wallets with the created tokens
Random Beacon for Signer Selection
The Keep network requires a trusted source of randomness to select tBTC signers. This takes the form of a BLS Threshold Relay.
When a request comes in to create a signing group, the tBTC system uses a random seed from a secure decentralized random beacon to randomly select signing group members from the eligible pool of signers. These signers coordinate a distributed key generation protocol that results in a public ECDSA key for the group, which is used to produce a wallet address that is then published to the host chain. This completes the signer selection phase.
my take away from this is that by using side chains that a trustless, not fedeared like liquid bitcoin sidechains sold by blockstream. it uses NFT erc-721 tokens as representation of the bitccoin UTXO from the bitcoin blockchain, store it in a wallet and mint it into tBTC. given this is all smart contracts generating wallets and minting the tBTC, it does away with the need of a centralised party to provide the funds of BTC to create a wrapped erc20 version on ethereum and so should be trustles.
perhaps erc20 token trading is the way to go forward. just requires wrapping of exisitng tokens. this looks promising for DeXs and DeFi if it happens.
also opens the possibiliy of multicollateral Dai (MCD) using tBTC in addition to eth and BAT. though personally i think btc should not be used in MCD.
any thoughts on this? or if my understanding is off.
thanks
edit: got some more info from px403
I talked to James a bit about tBTC in Osaka, so I have a vague idea of how it works, so I might be able to explain it in a somewhat coherent way.
Basically, the magic here is they reimplemented Bitcoin's SPV as an Ethereum smart contract, effectively letting them query the current state of the Bitcoin network, including validity of payments, directly in contract. Using this, they built an auction system where people can at any time claim ETH by paying BTC, or claim BTC by paying ETH. By design the spread is wide, so this isn't actually intended to be a high volume exchange, but what you do get is a pretty good price oracle.
From the price oracle, I think there were doing some Maker style CDPs or something, where people could lock up their BTC on the Bitcoin network to redeem tBTC, and any of the locked BTC could be reclaimed by burning tBTC or something.
Sorry it's not a complete picture of what's going on, but I think that's the general gist of what they're doing.
submitted by Neophyte- to CryptoTechnology [link] [comments]

Introduction to The Quantum Resistant Ledger

Overview
Introduction
Quantum computers, which have at times been dismissed as a physical impossibility, have gone from the realm of "if" to the realm of "when" over the last decade.
QRL was early to recognize the threat quantum computers posed, not just to data security of the world, but blockchain as well. In response, we created a fully open source (MIT)[1], independently audited[2,3], blockchain platform[4,5], secure against even an attack from quantum computers[6].
With security as a foundation, we've developed a feature rich platform with things like notarization[7], multisig transactions[8], and an Ephemeral Messaging System[9]. This is all done with performance[10] in mind to handle volumes expected of any enterprise-grade blockchain. Future developments include Smart Contracts, and PoS.
QRL is backed by the research of individuals, organizations and institutions, with citations from several[11]. We are commited to the scientific philosophy to development with 3 open research grants[12].
Sources
  1. MIT License: https://github.com/theQRL/QRL/blob/masteLICENSE
  2. X41 D-Sec: https://github.com/theQRL/audits/blob/masteX41-theQRL-Review-2018-Final-Report.pdf
  3. red4sec: https://medium.com/the-quantum-resistant-ledgered4sec-security-audit-563ecfe04c75
  4. API: https://api.theqrl.org/
  5. Documentation: https://docs.thqrl.org/
  6. XMSS: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208-draft.pdf
  7. Notarisation: https://docs.theqrl.org/tools/notarisation/
  8. Multisig Transactions: https://medium.com/the-quantum-resistant-ledgethe-qrl-bromine-hardfork-a-look-inside-2eed61ea90fd#3065
  9. Ephemeral Messaging System: https://github.com/theQRL/ephemeral/blob/masteEMS_whitepaper_v1.pdf
  10. QRL Technical: Weeks 36-37: https://medium.com/the-quantum-resistant-ledgeqrl-63813234ef23
  11. Citations: https://theqrl.org/research/#s:citations
  12. Research Grants: https://theqrl.org/research/grants/
Wallets
Web
Mobile
Desktop (binary)
QRL Markets
An up to date list can be found at https://theqrl.org/markets/
Official lines of communication
Is blockchain really at risk of Quantum Computing?
In short, it's not a matter of if, but when quantum computing is capable of breaking ECDSA P-256 (what Bitcoin, Ethereum and most blockchain projects use). We've put together a site called Frequently Asked Quantum Questions which has plenty of sources and should answer many of your questions: https://faqq.info/.
Worth a read is a multipart series put together by one of our community members, QRCollector.
submitted by mc_schmitt to QRL [link] [comments]

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

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

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

1. What is Bitcoin (BTC)?

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

2. Bitcoin’s core features

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

Unspent Transaction Output (UTXO) model

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

Nakamoto consensus

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

The blockchain

Block production

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

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

Block time and mining difficulty

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

What are orphan blocks?

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

3. Bitcoin’s additional features

Segregated Witness (SegWit)

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

Lightning Network

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

Schnorr Signature upgrade proposal

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

4. Economics and supply distribution

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

Technical: Upcoming Improvements to Lightning Network

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

"eltoo" Decker-Russell-Osuntokun

Yeah the exciting new Lightning Network channel update protocol!

Advantages

Myths

Disadvantages

Multipart payments / AMP

Splitting up large payments into smaller parts!

Details

Advantages

Disadvantages

Payment points / scalars

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

Advantages

Disadvantages

Pay-for-data

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

Advantages

Disadvantages

Stuckless payments

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

Advantages

Disadvantages

Non-custodial escrow over Lightning

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

Advantages

Disadvantages

Payment decorrelation

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

Advantages

Disadvantages

submitted by almkglor to Bitcoin [link] [comments]

Best General RenVM Questions of March 2020

Best General RenVM Questions of March 2020

\These questions are sourced directly from Telegram*

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

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

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

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

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

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

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

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

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

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

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

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

You can call you a Bitcoiner if you know/can explain these terms...

03/Jan/2009
10 Minutes
10,000 BTC Pizza
2016 Blocks
21 Million
210,000 Blocks
51% Attack
Address
Altcoin
Antonopoulos
Asic
Asic Boost
Base58
Batching
Bech32
Bit
Bitcoin Cash
Bitcoin Improvement Proposal (BIP)
Bitcoin SV
Bitmain
Block
Block height
Block reward
Blockchain
Blockexplorer
Bloom Filter
Brain Wallet
Buidl
Change Address
Child pays for parent (CPFP)
Coinbase (not the exchange)
CoinJoin
Coinmarketcap (CMC)
Colored Coin
Confirmation
Consensus
Custodial Wallet
Craig Wright
David Kleinman
Difficulty
Difficulty adjustment
Difficulty Target
Dogecoin
Dorian Nakamoto
Double spend
Elliptic Curve Digital Signature Algorithm (ECDSA)
Ethereum
Faketoshi
Fork
Full Node
Gavin Andresen
Genesis Block
Getting goxed
Halving
Hard Fork
Hardware Wallet
Hash
Hashing
Hierarchical Deterministic (HD) Wallet
Hodl
Hot Wallet
Initial Coin Offering (ICO)
Initial Exchange Offering (IEO)
Ledger
Light Node
Lightning
Litecoin
Locktime
Mainnet
Malleability
Master Private Key
Master Public Key
Master Seed
mBTC
Mempool
Merkle Tree
Mining
Mining Farm
Mining Pool
Mixing
MtGox
Multisig
Nonce
Not your keys,...
Opcode
Orphan block
P2PKH
P2SH
Paper Wallet
Peers
Pieter Wuille
Premining
Private key
Proof of Stake (PoS)
Proof of Work (PoW)
Pruning
Public key
Pump'n'Dump
Replace by Fee (RBF)
Ripemd160
Roger Ver
sat
Satoshi Nakamoto
Schnorr Signatures
Script
Segregated Witness (Segwit)
Sha256
Shitcoin
Sidechain
Signature
Signing
Simplified Payment Verification (SPV)
Smart Contract
Soft Fork
Stratum
Syncing
Testnet
Transaction
Transaction Fees
TransactionId (Txid)
Trezor
User Activated Soft Fork (UASF)
Utxo
Wallet Import Format (WIF)
Watch-Only Address
Whitepaper
List obviously not complete. Suggestions appreciated.
Refs:
https://bitcoin.org/en/developer-glossary https://en.bitcoin.it/wiki/Main_Page https://www.youtube.com/channel/UCgo7FCCPuylVk4luP3JAgVw https://www.youtube.com/useaantonop
submitted by PolaT1x to Bitcoin [link] [comments]

Words from the founders of ABCardO

The family of public-key cryptosystems, a fundamental breakthrough in modern cryptography in the late 1970s, has increasingly become a part of our communication networks over the last three decades. The Internet and other communication systems rely principally on the Diffie-Hellman key exchange, RSA encryption, and digital signatures using DSA, ECDSA, or related algorithms. The security of these cryptosystems depends on the difficulty of number theory problems such as Integer Factorization and the Discrete Log Problem. In 1994, Peter Shor showed that quantum computers could solve each of these problems in polynomial time, thus rendering the security of all cryptosystems based on such assumptions impotent. In the academic world, this new science bears the moniker Post-Quantum Cryptography (PQC).
In August 2015, the National Security Agency (NSA) published an online announcement stating a plans to transition to quantum-resistant algorithms. In December 2016, the National Institute of Standards and Technology (NIST) announced a call for proposals of quantum resistant algorithms with a deadline of November 30th 2017.
In light of the threat that quantum computers pose to cryptosystems such as RSA and ECC, the once-distant need to develop and deploy quantum-resistant technologies is quickly becoming a reality. Cryptocurrencies like Bitcoin are new financial instruments which are created to make financial transactions more efficient, cheaper, and decentralized. Their fundamental building blocks are cryptographic algorithms such as ECC digital signatures which are used to perform various functions to ensure the integrity and security of the whole system. However, the use of ECC signatures and other similar cryptographic algorithms means that quantum computing could pose a fatal threat to the security of existing cryptocurrencies, which deploy number theory-based public key cryptosystems extensively.
The mission of the ABCMint Foundation is to successfully develop quantum-resistant blockchain technology. We also look to promote and support fundamental research for quantum computing technology and post-quantum algorithms.
submitted by prelude406 to ABCardO_PQC [link] [comments]

PHP CashID library now available without the full node dependency.

The “official” CashID library requires a full bitcoin node to validate incoming signatures. I’ve refactored the code quite extensively and removed that dependency in exchange for a ECDSA library.
Please offer any suggestions, bugs, and constructive criticism you feel you need to share.
https://packagist.org/packages/beakerboy/cashid-library
submitted by TheRealBeakerboy to btc [link] [comments]

Part 6. (Last part) I'm writing a series about blockchain tech and possible future security risks. Failing shortcuts in an attempt to accomplish Quantum Resistance

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
Part 5, Why BTC is vulnerable for quantum attacks sooner than you would think.

Failing shortcuts in an attempt to accomplish Quantum Resistance
Content:
Hashing public keys
“Instant” transactions
FIFO
Standardized fees
Multicast
Timestamped transactions
Change my mind: If a project doesn't use a Quantum Resistant signature scheme, it is not 100% Quantum Resistant.
Here are some of the claims regarding Quantum Resistance without the use of a quantum resistant signature scheme that I have come across so far. For every claim, I give arguments to substantiate why these claims are incorrect.
“We only have public keys in hashed form published. Even quantum computers can't reverse the Hash, so no one can use those public keys to derive the private key. That's why we are quantum resistant.” This is incorrect.
This example has been explained in the previous article. To summarize: Hashed public keys can be used as an address for deposits. Deposits do not need signature authentication. Alternatively, withdrawals do need signature authentication. To authenticate a signature, the public key will always need to be made public in full, original form. As a necessary requirement, the full public key would be needed to spend coins. Therefore the public key will be included in the transaction.
The most famous blockchain to use hashed public keys is Bitcoin. Transactions can be hijacked during the period a user sends a transaction from his or her device to the blockchain and the moment a transaction is confirmed. For example: during Bitcoins 10 minute blockchain, the full public keys can be obtained to find private keys and forge transactions. Page 8, point 3 Hashing public keys does have advantages: they are smaller than the original public keys. So it does save space on the blockchain. It doesn't give you Quantum Resistance however. That is a misconception.
“Besides having only hashed public keys on the blockchain, we also have instant transactions. So there is no time to hijack a transaction and to obtain the public key fast enough to forge a transaction. That's why we are quantum resistant.” This is incorrect and impossible.
There is no such thing as instant transactions. A zero second blocktime for example is a claim that can’t be made. Period. Furthermore, transactions are collected in pools before they are added to a block that is going to be processed. The time it takes for miners to add them to a new block before processing that block depends on the amount of transactions a blockchain needs to process at a certain moment. When a blockchain operates within its maximum capacity (the maximum amount of transactions that a blockchain can process per second), the adding of transactions from the pool will go quite swiftly, but still not instantaneously.
However, when there is high transaction density, transactions can be stuck in the pool for a while. During this period the transactions are published and the full public keys can be obtained. Just as with the previous hijacking example, a transaction can be forged in that period of time. It can be done when the blockchain functions normally, and whenever the maximum capacity is exceeded, the window of opportunity grows for hackers.
Besides the risk that rush hours would bring by extending the time to work with the public key and forge transactions, there are network based attacks that could serve the same purpose: slow the confirmation time and create a bigger window to forge transactions. These types are attacks where the attacker targets the network instead of the sender of the transaction: Performing a DDoS attack or BGP routing attack or NSA Quantum Insert attack on a peer-to-peer network would be hard. But when provided with an opportunity to earn 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 recipe 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.
This specific example seems to be fixed now, but it most definitely shows there is a risk of other variations to be created. Keep in mind, before this variation of attack was known, the common opinion was that it was impossible. With little incentive to create such an attack, it might take a while until another one is developed. But when the possession of full public keys equals the possibility to forge transactions, all of a sudden billions are at stake.
“Besides only using hashed public keys as addresses, we use the First In First Out (FIFO) mechanism. This solves the forged transaction issue, as they will not be confirmed before the original transactions. That's why we are quantum resistant.” This is incorrect.
There is another period where the public key is openly available: the moment where a transaction is sent from the users device to the nodes on the blockchain network. The sent transaction can be delayed or totally blocked from arriving to the blockchain network. While this happens the attacker can obtain the public key. This is a man-in-the-middle (MITM) attack. A MITM is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. No transaction is 100% safe from a MITM attack. This type of attack isn’t commonly known amongst average usergroups due to the fact communication is done either encrypted or by the use of private- public key cryptography. Therefore, at this point of time MITM attacks are not an issue, because the information in transactions is useless for hackers. To emphasize the point made: a MITM attack can be done at this point of time to your transactions. But the information obtained by a hacker is useless because he can not break the cryptography. The encryption and private- public key cryptography is safe at this point of time. ECDSA and RSA can not be broken yet. But in the era of quantum computers the problem is clear: an attacker can obtain the public key and create enough time to forge a transaction which will be sent to the blockchain and arrive there first without the network having any way of knowing the transaction is forged. By doing this before the transaction reaches the blockchain, FIFO will be useless. The original transaction will be delayed or blocked from reaching the blockchain. The forged transaction will be admitted to the network first. And First In First Out will actually help the forged transaction to be confirmed before the original.
“Besides having only hashed public keys, we use small standardized fees. Forged transactions will not be able to use higher fees to get prioritized and confirmed before the original transactions, thus when the forged transaction will try to confirm the address is already empty. This is why we are quantum resistant.” This is incorrect.
The same arguments apply as with the FIFO system. The attack can be done before the original transaction reaches the network. Thus the forged transaction will still be handled first no matter the fee hight.
“Besides the above, we use multicast so all nodes receive the transaction at the same time. That's why we are quantum resistant.” This is incorrect.
Multicast is useless against a MITM attack when the attacker is close enough to the source.
“Besides the above, we number all our transactions and authenticate nodes so the user always knows who he's talking to. That's why we are quantum resistant.” This is incorrect.
Besides the fact that you’re working towards a centralized system if only verified people can become nodes. And besides the fact that also verified nodes can go bad and work with hackers. (Which would be useless if quantum resistant signature schemes would be implemented because a node or a hacker would have no use for quantum resistant public keys and signatures.) There are various ways of impersonating either side of a communication channel. IP-spoofing, ARP-spoofing, DSN-spoofing etc. All a hacker needs is time and position. Time can be created in several ways as explained above. All the information in the transaction an original user sends is valid. When a transaction is hijacked and the communication between the user and the rest of the network is blocked, a hacker can copy that information to his own transaction while using a forged signature. The only real effective defense against MITM attacks can be done on router or server-side by a strong encryption between the client and the server (Which in this case would be quantum resistant encryption, but then again you could just as well use a quantum resistant signature scheme.), or you use server authentication but then you would need that to be quantum resistant too. There is no serious protection against MITM attacks when the encryption of the data and the authentication of a server can be broken by quantum computers.
Only quantum resistant signature schemes will secure blockchain to quantum hacks. Every blockchain will need their users to communicate their public key to the blockchain to authenticate signatures and make transactions. There will always be ways to obtain those keys while being communicated and to stretch the period where these keys can be used to forge transactions. Once you have, you can move funds to your own address, a bitcoin mixer, Monero, or some other privacy coin.
Conclusion
There is only one way to currently achieve Quantum Resistance: by making sure the public key can be made public without any risks, as is done now in the pre-quantum period and as Satoshi has designed blockchain. Thus by the use of quantum resistant signature schemes. The rest is all a patchwork of risk mitigation and delaying strategies; they make it slightly harder to obtain a public key and forge a transaction but not impossible.
Addition
And then there is quite often this strategy of postponing quantum resistant signature schemes
“Instead of ECDSA with 256 bit keys we will just use 384 bit keys. And after that 521 bit keys, and then RSA 4096 keys, so we will ride it out for a while. No worries we don’t need to think about quantum resistant signature schemes for a long time.” This is highly inefficient, and creates more problems than it solves.
Besides the fact that this doesn’t make a project quantum resistant, it is nothing but postponing the switch to quantum resistant signatures, it is not a solution. Going from 256 bit keys to 384 bit keys would mean a quantum computer with ~ 3484 qubits instead of ~ 2330 qubits could break the signature scheme. That is not even double and postpones the problem either half a year or one year, depending which estimate you take. (Doubling of qubits every year, or every two years). It does however have the same problems as a real solution and is just as much work. (Changing the code, upgrading the blockchain, finding consensus amongst the nodes, upgrading all supporting systems, hoping the exchanges all go along with the new upgrade and migrate their coins, heaving all users migrate their coins.) And then quite soon after that, they'll have to go at it again. What they will do next? Go for 512 bit curves? Same issues. It's just patchworks and just as much hassle, but then over and over again for every “upgrade” from 384 to 521 etc.
And every upgrade the signatures get bigger, and closer to the quantum resistant signature sizes and thus the advantage you have over blockchains with quantum resistant signature schemes gets smaller. While the quantum resistant blockchains are just steady going and their users aren’t bothered with all the hassle. At the same time the users of the blockchain that is constantly upgrading to a bigger key size, keep on needing to migrate their coins to the new and upgraded addresses to stay safe.
submitted by QRCollector to CryptoTechnology [link] [comments]

Best General RenVM Questions | August 2019

Best General RenVM Questions of August 2019

These questions are sourced directly from Telegram, other monthly FAQ can be found here: https://docs.renproject.io/darknodes/community/monthly-community-faq
Q: So RenVM is essentially a BFT protocol (with 1/3 malicious nodes) that does ECDSA threshold key generation and signing? Is that right?
A: Yes, that's exactly what we have! We are exploring getting this to 1/2 and are confident it is possible, but the current implementation on Testnet is 1/3. Just today we also pushed an update that doubled the speed (and halved the bandwidth) of the sMPC signing algorithm.

Q: Have any tests been done on the speed of Interoperability?
A: The Testnet demo is live and open to the public, have a play with it and let us know about your experience (including speed). We have done some preliminary profiling; numbers look good so far. Fast enough for a single shard to keep up with Bitcoin.
The next version of RZL sMPC is under development and will introduce pre-computations that significantly increase the peak performance of RenVM from 10 TPS to over 100 TPS (these numbers are based on our initial conservative estimates).

Q: Currently, we see a quick performance of the swaps. When migrating to the mainnet (considering there will be real mainnet of say 250 Darknodes and real BTC, ETH, etc.) will it affect the speed?
A: Speed is a complex issue when it comes to RenVM. I'll try and break it down:
The biggest concern for speed is that RenVM needs to wait for a transaction to be confirmed on one chain before shifting the tokens to another chain. When working with Bitcoin this can take hours. -So latency is unavoidable (think of latency as how long a tunnel is) -So what about throughput (how wide the tunnel is)?
First, how to solve the latency problem. Well, we cannot actually solve it because we cannot change Bitcoin. But we can work around it by using "Universal Interoperability." In this model, a third party takes on the confirmation risk. While RenVM waits for the confirmation of a transaction on Bitcoin, the third party steps in and fulfills the Ethereum side of the transaction with BTC that has already been shifted previously. When the Bitcoin transaction is finally confirmed, the third party is refunded using the newly shifted BTC. This means the third party is taking on risk (the Bitcoin transaction may be shuffled away), so they charge a fee to cover this + their services. This means that the shift can be almost instant, and the only thing we need to worry about is throughput.
We believe we can get 10 TPS throughput, which is more than Bitcoin, so throughput isn't a problem (we only need to be as fast as Bitcoin). For other chains that are faster, we can introduce multiple shards. If one shard can do 10 TPS, then 10 shards can do 100 TPS.
I've described this process with Bitcoin, but it works for any pair of chains. Also, the third party cannot be guaranteed to step in (maybe they don't want to take the risk today) but if they do not, then the transaction will still go through but just at the slower speed. If the third party does step in, they're guaranteed to be refunded. So the introduction of "Universal Interoperability" does not introduce any central trust into the system.

Q: So Universal Interoperability is a partially centralized thing?
A: No because any third party can step in and provide the service. Further, the processes involved are all handled by smart contracts.

Q: Has there been a discussion of security in terms of sharding? Getting 1/3 stake and compromising a shard is obviously much easier than compromising the network, what's everyone's thoughts on that?
A: Yes there has; once you move to a sharding model, the risk of an attacker gaining control of a shard becomes a probabilistic problem rather than an absolute one (for example if you're sampling with replacement, in theory, a single attacker can corrupt the whole network).
Let's say an attacker owns enough of the network to have a 2^-1 chance of corrupting a shard (expected time to attack = ~2 days). If you are using a 20/20 multi-sig, where each shard controls one signature, then the chance of corrupting enough shards becomes 2^-20 (expected time to attack = ~2800 years).
In line with this example, the shard could be around N=24 (which would have a corruption chance of ~0.56) so each shard can be very fast (and shards would be running in parallel). Obviously we want to avoid multisigs (they're expensive and not all blockchains can support them) but this is mostly an example of the larger concept: requiring multiple shards to work together.

Q: Just got curious if the bug-fixing and developing has been overwhelming since the release of testnet? How do you feel it's been so far?
A: I wouldn't say overwhelming. It's definitely keeping us busy. Finding bugs and fixing them is actually very satisfying work; it reduces stress by increasing confidence, and this helps improve motivation and productivity.
It's also good to be able to revisit parts of the system and go about perfecting them. Often in software development, there is the adage "never optimize early". Well, the time has finally come to optimize (not just performance, but design, safety, etc.). Everyone wants the thing they build to be perfect, and being able to make that the focus is an awesome feeling.

Q: Is there a reason for having private repos?
A: It's important for the success of the network to maintain a competitive advantage, and important to avoid "day zero" bugs from people that find them but don't report (in the hopes to take advantage). We'll be getting the code (and our maths) reviewed and audited, and probably show it to first adopting groups so they can verify it themselves, and as Mainnet grows we will open-source everything, along with a Transperency Plan that outlines when and how repos will be open-sourced.

Q: My Darknodes still show the old command center. How do I view them on the new one?
A: The new Command Center is for RenVM specifically (and it's only viewable on RenVM Testnet); once we switch Darknodes over to the RenVM network, they will utilize the new Command Center.
To play around with it, put your MetaMask on Kovan Test Network. A video that a community member created can be found here: https://twitter.com/RenIsLyfe/status/1166091169853579265?s=20

Q: Digital Ocean (DO) sent me a message saying my VPS would be down for maintenance, is this an issue?
A: Nope, this is just part and parcel of using a VPS. From time to time, they need to do maintenance. They will inform you if you need to take action.
This is a real-world example of why it's crazy to expect a decentralized network to have all participants online all the time, and why you cannot "incentivize" being online by punishing being offline. It's unavoidable even when there are entire expert teams with years of experience on the job. The more nodes you have, the more likely any one of them is to experience an issue like this at any one time.
Your REN is not at risk if your Darknode does go offline. It is also unlikely that a Darknode that is offline due to these kinds of circumstances will remain offline long enough to be forced out of the network.

Q: Will the community darknodes be partaking in the RenVM Testnet, or are you using your own nodes to test it out, or is it a gradual deploy?
A: The team has about 24 Testnet Darknodes that power it. We may open these Testnet nodes up to a few groups in the Working Group, but no public participation of Testnet Darknodes will be pursued at this time.

Q: A couple of questions for the team: 1) Bonded REN value informs how much value can be securely shifted through RenVM at any given time. If bonded value drops below the threshold, are there any risks beyond incentive to collude which arise? is there any liquidation risk ala TBTCsigners? 2) Does RenVM enforce any time floors/ceilings on shifting/locking tokens? I assume anything like that would be enforced by a third party like Compound?
A: 1. There are collusion risks but we plan to mitigate this by having Darknodes able to "tell on each other" so if you are colluding with someone that you don't trust 100% you risk losing your bond so attacks only really make sense if you own all the colluding Darknodes (which, by definition, isn't really collusion it's buying up a bunch of REN). There is no liquidation risk. This is one key reason why we bond using REN, not another token; the "value of REN" is tied only to the use of RenVM. The safety of RenVM is predicated on the use of RenVM. RenVM is used = RenVM is safe
  1. No time ceilings. We've been having discussions about how to keep Darknode well incentivized to maintain long-term deposits, but (a) most of RenVM's UX is built around handling the native token, not a wrapped version of it (how is a BTC maxi going to get a hold of ETH to use their ERC20 BTC?), and (b) payments will be paid out over time to RenVM not instantly so this creates a more stable income for the Darknodes instead of large but infrequent lumps of pay, (c) we got another trick up our sleeve that I'll be adding to the GitHub any day now, (d) if you have ideas about how to incentive Darknodes to maintain BTC that is being deposited long-term, please feel free to let us know!

Q: Has there been a pattern established where third-parties could pay the gas for the eth transactions needed during shifting? For instance, would it be straightforward for an app dev to pay the gas for the user but add a small additional fee onto the RenVM transaction? They would pay the gas in ETH for the user in exchange for that value collected in BTC or zBTC?
A: This is going to be very straightforward for devs. We are designing examples as we speak to set the standard for doing this and therefore make integration as easy as possible.

Q: Can a RenVM gateway addresses be reused? As in if a user creates a gateway address for 0.1 BTC, can they send exactly 0.1 BTC that address, mint zBTC, and then repeat that process again without creating a new gateway?
A: Currently no, a gateway can only be used once; but we are in the process of creating that feature and it should be ready within the next month or so.

Q: What’s the best way to set up a Darknode if I only have Microsoft?
A: We do not formally support a Windows CLI as of right now, but we are adding Windows CLI support prior to Mainnet, so please do stay tuned.
submitted by RENProtocol to RenProject [link] [comments]

Bitcoin Cash Hard Fork 15 May 2019 | Know Everything About Upcoming BCH Fork

Bitcoin Cash Hard Fork 15 May 2019 | Know Everything About Upcoming BCH Fork

https://preview.redd.it/idsupgh4k7y21.png?width=1500&format=png&auto=webp&s=0a00b768fdbad52a99bfb7f041c79e109d2b1c44
The price of Bitcoin Cash (BCH) surged dramatically once the news of the upcoming Bitcoin Cash fork came out. BCH broke over 300 USD with an increase of 13% as the news of Schnorr upgrade broke the internet and the crypto space. Schnorr upgrade was initially being proposed by Peter Wuille, the Blockstream co-founder. The Bitcoin Cash community has voted for the Schnorr upgrade unlike their criticism on the past discussions on Lightning, Segregated Witnesses (SegWit) and other technologies.
The Bitcoin Cash hard fork date scheduled is on May 15, 2019. Before that, a testnet has already been launched, which will help the developers test before the official launch. You can track the BCH hard fork time here, where you can find Bitcoin Cash hard fork countdown.
Alysssa Hertig tweeted from CoinDesk that this change is going to be phenomenal, and is widely supported by the community members:

Let us understand what difference would it make to the BCH fork 2019 after the Schnorr Upgrade:

Cryptographically, to prove that you own Bitcoin and in order to send funds to others, you “sign” with a private key, which as of now, uses Elliptic Curve Digital Signature Algorithm (ECDSA) scheme which lacked scalability and privacy features. But Schnorr signatures will be able to verify several signatures at once, which is way faster than even verifying one signature eight times, which in turn will improve scalability and privacy, wherein there would be certain anonymity. Schnorr signatures will aggregate the signatures, public keys and messages of multiple transactions into one, enabling faster transactions.
Read More - https://coinswitch.co/news/bitcoin-cash-hard-fork-15-may-2019-know-everything-about-upcoming-bch-fork
submitted by perky_coder to coinswitch [link] [comments]

Every computer is the Bitcoin computer

Bitcoin doesn't require any special hardware, as it can be used on any device which can do computations. To make a Bitcoin transaction you need to create a ECDSA signature, which is just math, something which all computers do well. You can do it both on resource-constrained like smart cards (think SIM cards) and on large servers alike.
The idea that you need a special Bitcoin computer to use Bitcoin is outright harmful, as it limits your choices and dupes you into buying overpriced proprietary hardware which gives the vendor more control of what you can and cannot do. This is very much against the spirit of Bitcoin which can thrive only as an open system.
So yeah, that thing 21 inc is trying to sell makes no sense, whatsoever.
But a lot of people think that "there might be something in it", let me go through the theories of why this device makes sense:
  1. "It is a dev kit!". Let me guess, you aren't a programmer. Or if you're a programmer, you're a shitty programmer and should be ashamed of yourself. You do not need any dev kit for Bitcoin, all you need is open source software (and, maybe, some internet services, optionally). When I wanted to try to do something Bitcoin related back in 2011, all I needed was to download bitcoind and install it on my $10/month VPS. Then I looked through RPC API call list and made a Bitcoin-settled futures exchange. The whole thing took me only a week. I didn't need to pay $400 for a devkit. Learning how to work with bitcoind took less than a day. There are hundreds of Bitcoin companies and thousands of hobbyist working on Bitcoin projects, none of them needed any sort of a dev kit.
  2. "It is useful because it has APIs and pre-installed software!" No, see above. If needed, pre-installed software can be delivered in a form of a virtual machine (e.g. VirtualBox, VMware, etc), no need for a physical device.
  3. "It is useful because it comes with a micropayment service/API". Nope. These things can be done in software, no need for custom hardware. Obviously, a micropayment system can be more widely adopted when it is open. If it is tied to custom hardware (which I doubt) then you have a vendor lock-in which is exactly the thing we're trying to avoid with Bitcoin.
  4. "it comes with pre-installed marketplace". So what, we have marketplaces such as OpenBazaar. If there are useful features in the 21 inc's marketplace we can replicated them in open source software.
  5. "It's convenient for users!" Are you saying that a $400 device which you need to be connected to a laptop is more convenient than a service which can run in a browser?
  6. "It might offer better security". We already have devices such as Trezor which can protect bitcoins from unsecure operating system. Trezor costs much less than $400 and is actually useful. Even though it was done by a small company without much capital.
  7. "It can be used for applications like a reputation system, etc." When telecom companies wanted an ability to differentiate between users, they created smartcard-based SIM cards. This technology is many decades old. Using Bitcoin for a reputation system is a bad idea, as it is not designed for that. If device holds 1000 satoshi to give it an identity weight, a guy who has 1 bitcoin can impersonate 10000 such devices. It just not going to work.
  8. "A constant stream of bitcoins it mines is convenient for users." User has to pay for this device, he might as well just buy bitcoins. If it is necessary for bitcoins to be attached to hardware, this can be done using a tiny dongle which costs less than $1 to manufacture, or a smart card.
  9. "But this device got backed by VCs and large companies, there must be something to it, we are just too stupid to comprehend its greatness". Well...
There is, indeed, a very simple explanation of this device's existnce: Balaji's reality distortion field. He is a prominent VC, so it was relatively easy to convince others that it's a worthy idea. The big vision behind it -- the financial network of devices -- is actually great. And then there is a question of execution. A guy like Balaji is supposed to be an expert in assessing feasibility of execution. So, as we can guess, investors trusted him. As many VCs tell, they invest in people. They cannot examine nitty-gritty technical details, but just look at skills, track record, etc.
So the fact that it got large investments and generates a lot of hype doesn't mean much, there was a plenty of such companies during dotcom boom.
It's quite like :CueCat. As we now know, an ability to scan a printed code and open a web page which it points to is very useful, a lot of people use QR codes, they are ubiquitous. This was exactly the vision behind CueCat. But it was implemented as a dedicated hardware device, not as a smartphone app, as there were no smartphones at that time. So after a lot of hype and aggressive marketing the company failed, but just few years later their vision became realized in QR reader apps.
Hardware becomes increasingly irrelevant. As Mark Andreessen, Balaji's partner, [once said], software is eating the world. Solving problems which can be solved software using custom hardware is just silly.
Balaji talks about internet-of-things applications where devices mine bitcoins and use them to buy services they need to function. Well, in the end, user pays for that, as he pays for physical chips and electricity. It would be more efficient for him to pay directly than to use this mining-based scheme. And it's possible to do so using software. E.g. imagine you have a lot of smart devices which use external services in your home. It would be nice if you can just aggregate the bill and pay it off automatically, say $2/month. Why only $2? Well, if there is a device consuming $20/month, it needs some serious mining abilities, so it will cost much more than $20 in electricity bills...
Maybe 21 inc will eventually pivot into purely software solutions, they have a lot of money to play with. But the current generation of devices they make just makes no sense, whatsoever, and people who try to find something useful in them just waste their time.
EDIT: One plausible case for using custom hardware is a possibility of off-chain microtransactions using trusted hardware. Not unlike MintChip conceptually. But size of the device as well as its price is puzzling in this case, as this can be implemented (and was already implemented) in smart card form factor.
submitted by killerstorm to Bitcoin [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]

Ren | All-In-One

Ren

What is Ren? Ren is an open protocol that enables the permissionless transfer of value between any blockchain. Ren's core product, RenVM, brings interoperability to decentralized finance (DeFi).
What makes RenVM unique is that it does everything in secret using zero-knowledge proofs over an sMPC based protocol that the team has pioneered. The state, inputs, and outputs of all programs that RenVM runs are kept hidden from everyone, including the Darknodes that power it.
This allows RenVM to securely manage (ECDSA) private keys on different blockchains, making it possible to shift tokens between these blockchains in a trustless, permissionless, and decentralized way (i.e interoperability).
Technically speaking RenVM is a byzantine fault-tolerant protocol (with 1/3 malicious nodes) that does ECDSA threshold key generation and signing via sMPC. RenVM is not a product or an application in and of itself but is a network (and an accompanying SDK) that allows developers to bring interoperability to their DeFi applications.
Ren was founded in 2017 and is headquartered in Singapore.

RenVM Mainnet Is Live! 🎉

https://medium.com/renproject/renvm-mainnet-release-98cac4c6fa8e

RenBridge (dapp)| Mint BTC, BCH, and ZEC on Ethereum

https://bridge.renproject.io/

Official Resources
Darknodes
Darknodes are the physical machines that power RenVM, where every machine contributes CPU time for compute power and its disk space for storage. These are that machines that form the P2P decentralized network (not a blockchain) that cooperate to run secret multiparty computations. It is important to note that programs executing on RenVM are hidden from the Darknodes that run the virtual machine.
This guide will walk you through the installation of your Darknode. Before you begin, make sure that you have a MacOS, Windows, or Ubuntu machine available (i.e. home computer) and 100,000 REN.
Guides: How to set up a Darknode
The Team
Ren Linkedin Page
Investors
General Updates | Blog
2020 Development & Ecosystem Updates
Podcasts & Youtube videos | Chronological Order
REN Exchanges
REN Token Details
FAQ
What happened to the Republic Protocol?
Republic Protocol was rebranded to Ren to reflect the project’s evolution towards interoperability (i.e. RenVM). Old posts and discussions can be found on the Republic Protocol Reddit

Closing Thoughts

We truly appreciate our community, and this cannot be said enough. The level of technical understanding and subsequent assistance provided to our newcomers, speaks to the expertise and positivity in the community, and we couldn’t be more thankful.
We look forward to collaborating with everyone as we make our next steps forward towards building a cross-chain DeFi ecosystem. If you are interested in working directly with the Ren Team we are always looking for developers so please do reach out via the below email.
Need help or want to partner? [[email protected]](mailto:[email protected])
submitted by RENProtocol to RenProject [link] [comments]

Elliptic Curve Cryptography Tutorial - Understanding ECC ... Elliptic Curve Digital Signature Algorithm (ECDSA) (Money Button Documentation Series) Bitcoin 101 Elliptic Curve Cryptography Part 5 The Magic of Signing & Verifying Bitcoin ECDSA- Elliptic curve Digital Signature Elliptic Curve Arithmetic and Bitcoin  Nathan Dalaklis

Eric Rykwalder is a software engineer and one of Chain.com s founders. Here, he gives an overview of the mathematical foundations of the bitcoin protocol. One reason bitcoin can be confusing for beginners is that the technology behind it redefines the concept of ownership. To own something in the traditional sense, be As early as 2011, Bitcoin developer Hal Finney pointed out on Bitcointalk that the endomorphism feature of secp256k1 could be used to accelerate the signature verification of the ECDSA [2], Finney ... I wrote a couple of algorithms that perform the ECDSA and also the verification. So I used my algorithm and the RPC call for signing and I got a couple of questions. Since we have the ephemeral pr... Stack Exchange Network. Stack Exchange network consists of 177 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge ... One of its main supporters is the cryptocurrency system Bitcoin which uses an elliptic curve scheme for their digital signatures. Smaller key size, a more efficient implementation than the RSA system, and a similar level of security make elliptic curve cry . trending; Ecdsa Bitcoin Bitcoin . Ecdsa Bitcoin . Mar 30, 2018 DTN Staff. twitter. pinterest. google plus. facebook. Ecdsa Security In ... ECDSA cryptographic signature library (pure python) ... It includes the 256-bit curve secp256k1 used by Bitcoin. There is also support for the regular (non-twisted) variants of Brainpool curves from 160 to 512 bits. The "short names" of those curves are: brainpoolP160r1, brainpoolP192r1, brainpoolP224r1, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1. No other curves are ...

[index] [27184] [1571] [14429] [35964] [44414] [19212] [23887] [44594] [49375] [34510]

Elliptic Curve Cryptography Tutorial - Understanding ECC ...

John Wagnon discusses the basics and benefits of Elliptic Curve Cryptography (ECC) in this episode of Lightboard Lessons. Check out this article on DevCentra... Jimmy Song explains the basics of cryptography that serves as a foundation for Bitcoin transactions. This course provides in-depth coverage of Elliptic Curve Digital Signature Algorithm (ECDSA ... Getting the ECDSA Z Value from a Bitcoin Single Input Transaction ... Public key cryptography - Diffie-Hellman Key Exchange (full version) - Duration: 8:38. Art of the Problem 691,915 views. 8:38 ... Elliptic Curve Digital Signature Algorithm ECDSA Part 10 Cryptography Crashcourse - Duration: 35:32. Dr. Julian Hosp - Bitcoin, Aktien, Gold und Co. 5,803 views Learn more advanced front-end and full-stack development at: https://www.fullstackacademy.com Elliptic Curve Cryptography (ECC) is a type of public key crypt...

#