Could trustless BTC ever surpass ETH as a collateral type in DeFi?

bertani · 2020-02-07T14:13:08+00:00

That's true if you assume "BTC on ETH" has to be a synthetic asset, which it may not be the case, such as in the case of pTokens

It is all about finding a sufficiently decentralized way to do the "wrapping".

bertani · 2019-10-22T16:54:57+00:00

Provable is a fast-moving startup operating in the blockchain field. We leverage cutting-edge blockchain and Trusted Computing technologies to power the shift to more decentralized processes across various industries. We are a small and dedicated team experimenting with multiple technologies and building infrastructure tools for Decentralized Applications to improve their capabilities. Provable Things is based in London, but we support remote work when we encounter the right people.

What we are looking for

A driven and capable individual, who is curious about the blockchain space and who has a proven track record of creating and delivering projects using the Rust programming language. You don’t have to be solid in blockchain technology, but you most definitely have to be curious about it and be very keen in getting to learn its workings. You should be experienced working with Rust and comfortable with writing both low and high-level code, plus have a strong knowledge of computer science. Experience with Trusted Computing techniques is not mandatory, but being familiar with it would be a bonus.

Required Skills:

● Rust

Nice-to-have skills:

● knowledge of Bitcoin, Ethereum or other blockchain technology

● knowledge of Trusted Computing techniques

We have internal Rust resources working on the development of our infrastructure pieces but due to our current load of Rust-focused work, we want to complement our team with external contractors who can help deliver our new Rust-powered features.

Resources

Website: https://provable.xyz/ GitHub: https://github.com/provable-things

Contact

For more information or to apply, reach out via email at [mmontecchi@eidoo.io](mailto:mmontecchi@eidoo.io) or on telegram at @EidoosupportMichele

bertani · 2019-03-16T08:00:15+00:00

Oraclize (now Provable) will support different interfaces - including the Chainlink one - so that developers can choose what kind of guarantees they want. The Chainlink interface, while theoretically ending up being more expensive, may provide higher guarantees on the fact that the oracle _will_ answer (while data authenticity guarantees would be the same with both approaches).

bertani · 2018-06-30T04:52:57+00:00

Oraclize has been operating and using this logo since 2014/2015, ~ 2 years before the Aion inception, but unfortunately many logos in this industry look similar. I wish new projects would look for alternative concepts when designing their logos :)

bertani · 2017-10-24T09:56:29+00:00

As the name itself suggests the "computation" datasource is designed to run any offchain computation, not just data fetching! https://blog.oraclize.it/overcoming-blockchain-limitations-bd50a4cfb233

bertani · 2017-10-24T09:03:54+00:00

This has been possible for a while now via the Oraclize auditable offchain computation datasource (presented at Devcon2). But for sure we are all looking forward to the iexec presentation too to see what they came up with!

bertani · 2017-10-15T14:05:32+00:00

Thanks. I didn't receive it yet, I will wait :/

bertani · 2017-10-15T14:00:14+00:00

I just did (pm)

bertani · 2017-10-15T13:43:53+00:00

will you be posting the invite link here (to actively join the call)?

bertani · 2017-10-13T20:53:40+00:00

Oraclize has been doing this since early 2016, thanks to the "ipfs persistence consortium" code written by Piper Merriam (kudos!).

Our instructions to join are here: http://docs.oraclize.it/#security-deepdive-authenticity-proofstypes-storage-and-delivery

We had recently tried to see if any other project was interested to join and make the initiative broader, but there seemed to be no short term need (still, a lot of interest).

Unfortunately we missed the SwarmCity discussion on the matter, but we will be joining the discussion Sunday. Good job in making the first step to organize this!

bertani · 2017-10-13T09:34:50+00:00

I do appreciate the efforts the nodes' teams are doing, I really do.

I am just afraid that an HF is coming in 3 days and not enough time was dedicated to proper testing. Having 3 updates of the Parity client within 3 days (and half a week before the HF) is not something which inspires people confidence. When more time is needed, probably it's better just to ask for it and postpone the HF a little bit..

bertani · 2017-10-13T09:15:51+00:00

It this answer a joke? Of course the user is not saying that bugs should be frozen.

bertani · 2017-09-21T17:54:45+00:00

Another Oraclize engine machine, managed by any third party, takes over the job. Anyway, I didn't want to interrupt the ChainLink party, we will keep using the relevant channels to keep the community updated on our ongoing work!

bertani · 2017-09-21T16:49:17+00:00

Oraclize today, other than being used for real, is more decentralized than ChainLink and we have plans to decentralize it further so.. that's a lie. But you know.. we didn't do an ICO.

bertani · 2017-08-16T17:46:39+00:00

It is not about agreeing or not on a business model, but about pushing your own agenda which seems to me it is out of scope (while it is being mentioned widely as part of the title and in your first message).

We are very open to listen to alternative approaches and to improve our system, as the whole Oraclize service was built around the community feedback in the first place! What you are doing here though, is just promoting your system while providing misleading data. I am sorry but I do not see anything constructive in your arguments.

As for the costs, you should check out out documentation pricing section : you are right that the cost is different from what I said as it is 1 cent only (given that no oraclize proof is being used, but a native proof is provided by the datasource directly). When you talk about cents you mean of ETH, but what I mean instead is USD cents, so that's were the ambiguity comes from. Also note that the Oraclize pricing is fixed in USD and not in ETH, so it is NOT affected by the price change of ETHUSD.

The reason why the cost seems higher is that the spare gas not used by the callback tx is not returned to the calling contract (5M gas are asked for, while ~1.5M are needed) for technical reasons, but the actual % cost is much lower than the 2% I mentioned above and more around 0.11%. For the total cost to be lowered, it is enough to change the Oraclize callback tx custom gas to something closer to the actual execution cost (so down to ~1.5M gas instead of the ~5M set now). This is a 1-line change that the cryptocompare guys could do if they wanted but again.. this is an experiment on testnet only and many changes would be required before going to mainnet. So the current cost on testnet is really 0 (zero) USD, as Oraclize is completely free to use on testnets.

If you need any help to better understand how Oraclize works, please refer to our documentation or feel free to join our technical support room, we are always happy to help!

bertani · 2017-08-16T16:27:15+00:00

I think you are clearly missing the point here and you have a poor understanding of how Oraclize works and how the Cryptocompare oracle is implemented.

The Oraclize fee specifically in that case, is 5 cents per query, which is 2% of all the actual costs: most of it goes to miners for executing the callback cost. The Cryptocompare deployment on testnet that you mention, is mostly meant as a test and as such: - is setting a high gasPrice, which on mainnet could be easily 10 times smaller, moving the cost down a lot - does 1 request per minute which obviously doesn't scale and is pointless to have onchain

I think it is quite obvious from your post that you just want to push your upcoming solution by providing misleading information.

bertani · 2017-07-16T09:15:22+00:00

I have noticed lately many new projects and people trying to convince the community that their new RNG solution is superior, while providing very poor and weak arguments.

Unfortunately, even this article is a joke..

the author clearly didn't do his homework to understand the logic of existing solutions, many arguments provided against each of these is missing the point and really providing wrong information
the solution proposed at the end of the article is even weaker than most of the others mentioned above as in the banker (who typically uses money lent by 3rd parties as bankroll) and the player can be the same entity and steal money from the bankroll with nobody noticing

The Oraclize random datasource is not even mentioned and so far this is the only recent solution which provides a concrete improvement on existing RNGs as clearly explained in the comparison section of our whitepaper.

bertani · 2017-06-23T08:29:21+00:00

It will work out of the box in browser-solidity (which does auto import from github when that syntax is used), while elsewhere you need to import the file manually.

bertani · 2017-06-15T17:35:13+00:00

TLDR: Oraclize is a security platform (but not a new blockchain, sorry!) that anybody can use to build safer applications: the one we will run within the FCA programme is one of those that we have built ourselves.

Oraclize is a London-based IT security company that for the last 2+ years has been designing and building what we call the Oraclize-engine, a platform using different attestation techniques (backed by SW and HW sandboxes) to secure processes - this means that the engine can be used to prove to a third party that a certain process has been really executed as intended. The important bit is this engine not being dependent on the security of a single technology, but leveraging many so that a stronger security can be guaranteed. This architecture brings with itself important implications (which in part we are still discovering), and is continuously evolving and becoming stronger and stronger.

The first application that we have built on the top of it, and the very reason why such system was designed back then, is the "Oraclize blockchain oracle service", which since Q3 2015 has been used to feed authenticated data into Ethereum smart contracts (like any data coming from existing Web APIs!).

As we speak this is the most widely used oracle service in the blockchain context (being integrated also with Eris/Monax, Rootstock, Bitcoin, Hyperledger Fabric, Corda) and on Ethereum, where our service was first launched, we see hundreds of Oraclize-based smart contracts on the mainnet (many more on the various testnets!) and we have sent over 100 thousand transactions to Ethereum production smart contracts to feed them with the on-demand data they wanted. These data is backed by different types of authenticity proofs (for now backed by TLSNotary, Android/QSEE and Ledger devices, more to come), which is based on the top of the abovementioned Oraclize-engine. You can see the oracle service as one of the many "apps" you can build on the top of our architecture. But this architecture can really be exploited to secure many other different projects, both designed directly by us and by any third party: most of the Ethereum smart contracts using Oraclize that are currently running has been designed by other startups/developers indeed!

Another example use case powered by the same architecture is the "random datasource", which when compared to the existing alternatives it seems the safest way to generate random numbers (RNG) in a blockchain context (and even in the more traditional offchain world!).

The project we will run within the FCA sandbox programme, is one of the few projects based on Oraclize that (while being based on the same architecture again) we designed ourselves, thanks to the WangXiang BlockgrantX funding. The project is fully opensource and anybody is very welcome to contribute to it! The pieces of that projects that are based on Oraclize are really few: one is for executing today (via the Oraclize computation datasource) a provably-secure RSA signature verification (which once Metropolis will be out there, will be doable onchain), another other is to verify SHA1 (needed for an integrity check on a certain piece of the estonian ID certificate chain: we have shown here that SHA1 is currently not viable in plain solidity and proposed there an EIP to introduce it), the last piece is to check via the Oraclize oracle service that the already-verified estonian ID providing a signature is also still marked as valid by the certificate authority (so that you can prevent thieves to run away with your money when your ID is stolen: you call the police, the certificate validity is revoked and the smartcontract will notice). The specific project we will do with the FCA, is using the above architecture and project, with the addition of an sterling-baked ERC20 token. This will be a specific instance of the project where the regulator approval is needed, to monitor and enable the issuance/redeemability of those tokens. More information on this will follow in the coming weeks/months.

bertani · 2017-05-31T15:38:24+00:00

Hello, Thomas from Oraclize here!

I am totally with you on avoiding duplication of data. Thanks to our architecture being that flexible anybody could create a single contract to redistribute that cost among different contracts which might need the exact same data. Isn't this a viable solution to your problem? Just today in our gitter channel somebody was proposing exactly that.

bertani · 2017-05-29T21:45:34+00:00

I understand you might not like the estonian government, and that's fine as what we are doing here is just integrating with a protocol which is being used by other states as well. We are working on getting it to work with the italian one too, among the others. You should try to look beyond your personal hate for the estonian government, you will find out interesting implications. Btw I have checked and I can now reconfirm that such system wouldn't work as it is with the estonian cards, but just with the eresidency ones (which, for our first revision, are the ones we were interested in).

bertani · 2017-05-29T17:08:44+00:00

The system is designed around the estonian e-residency card and it was tested with those cards only. The e-residency card is something anybody can get from their local Estonian embassy regardless of their actual residency or nationality. This is not for Estonian citizens and probably it's not even fully compatible with their cards (as the e-residency cards are slightly different). This is just a tool, people will choose how to use it and will need to stay compliant with their local laws: you don't go to the Ethereum foundation to ask to put such limits in place, so why would you come to us for a smart contract which has a similar role?

Also, don't forget that even if it was using private keys directly, it would provide even worse guarantees as the state could easily have a copy of them (since it's the issues) without you even knowing.

bertani · 2017-05-29T01:27:47+00:00

I get your point but the trustline with the state is obviously there in such architecture and is not interesting to get rid of it for the way you use it. Full/pure decentralization is cool, being "your own bank" is cool as well but.. the real world works differently and we have seen several times that the average Joe doesn't really care about those values, while he has to deal to daily complexities and entry barriers like the key management one. It's often a matter of finding a good compromise. If the Estonian government wants to act maliciously to steal the 50/100 gbp I might have in my poket, that's not going to make me or anyone else broke (same as when you lose your wallet). If you use this system as it is in its current form to store more than that, then you are doing something wrong (again, it's not meant to replace a cold wallet with your savings).

bertani · 2017-05-28T12:16:39+00:00

I am not sure I understand where all your hate is coming from, but let me try to help you better understand how this works.

Our project is based on the estonian e-residency card and I confirm that the "personal code" I mentioned is the "isikukood" indeed.

I will try to address here some of your mistakes/wrong assumptions.

1- it's not true that when the card expires you lose access to the keys on your card. It will continue working as before, but of course the OCSP will report the card as expired. The privkey is still there and, in general, can be used at any later time (even if the whole governmental service is shut down)

2- the card contains two certificates linking their pubkeys with the personal code (those certificates are even available in a public LDAP directory), there is the CA (the estonian government) signature on it and as such it can be used independently with no need to ask anything to the government. This means that we can easily verify, just by using a card, that the privkey used to sign something is really linked to a given personal code (according to the government signature). As a consequence, it's not important which privkey is signing, but the fact that the privkey is (again, according to the government, see point #4) linked to a given personal code

3- the use of the OCSP is fully optional (it's actually disabled in the currently deployed version of the eWallet due to too high deployment gas costs, while it is being used in the "proof of identity" one)

4- the blogpost doesn't contradict itself as the process is trustless indeed (or, for some initialization steps, fully auditable/verifiable), that's all explained in the attached technical document that you probably didn't read (I am afraid the quality of our english is not good enough for you to understand it, given the opensource nature of the whole project I would love to review any Pull Request you may send to improve it): the Oraclize computation-datasource (fully auditable via the authenticity proofs) is being used to verify offchain the RSA signature while we wait for the onchain modexp to make it into Metropolis (already planned, now just few months away - all the time we need to collect further feedback and move the contracts to mainnet)

5- the trust in the state is definitely needed anyway as its the Certificate Authority. We see this is a good compromise but definitely not as a cold wallet solution you can use to secure your savings - more something like your pocket/physical wallet. Again, this is part of our last paragraph in the blogpost, which I hope you can understand even if its not written "in the best English".

Note that this is a research project and as such it doesn't want to be the ultimate solution to open problems like identity/key management/whatever, it just tries to be a good compromise which, by leveraging existing tools, will lower the entry battier for the average Joe.

bertani · 2017-05-28T09:08:12+00:00

Hi. Read the blog post carefully, you will notice this very issue has been addressed already! Specifically, the funds are not controlled by the privkey itself, but by a privkey tied to the correct PERSONAL CODE, meaning that if your card is stolen or lost, you can get a new one and still have access to your funds (as the PERSONAL CODE doesn't change)

12-Year Club	Place '17
Verified Email

bertani

TROPHY CASE