/biz/ - Business & Finance

Cftc.gov

https://www.cftc.gov/sites/default/files/2018-11/LabCFTC_PrimerSmartContracts112718.pdf

https://www.isda.org/a/MhgME/Legal-Guidelines-for-Smart-Derivatives-Contracts-Introduction.pdf

>>13877931
Let me ask you this.

What happens when one of the banks or oracle services acts badly and stops replying/violates the protocol midway through - like after the first bank approves or has already deposited funds.

Timeouts, reclaims and deposits you say? What happens when bad actors start to abuse these features? It only takes one billion dollar fuck-up.

>>13878061
they're penalized in link you fucking moron

>>13878061

Valid concerns.
This is the added value of decentralization.
There are certainly bad actors and there is a lot of money involved here so it's a genuine concern.

If, however, the entities that currently provide these central points of potential (and realized) manipulation are running few of many oracle nodes, then the effort required to manipulate the values is much higher than it is currently.

>>13878061
This won't happen because Sergey won't let it happen.

>>13878091
So what happens when an honest mistake happens and they get penalized for nothing.

There are a million edge cases in trusted interaction and you can only ever mitigate.

>>13878110
based sergeyposter

>>13878060
One of the people that contributed to this research works with Corda and at R3.

Jason Rozovsky

>>13878126
An honest mistake is still a mistake. They'll lose some LINK big deal.

>>13878126
Your question is really in regards to how consensus will be reached among the data providers (oracles).

This will depend on the type of data.
If it's a bool, then take majority vote.
If it's an int, take the average.
Etc.
If there are nodes that are consistently outliers of the data and/or are late in reporting the data then penalize them and/or remove them from the pool.

>>13878191
So the penalty is a constant amount? It shouldn't be relative to the size of the potential loss? So it's worth it to act badly for high value deals, then.

Make it scale to the size of the deal, and you have another problem: Billion dollar deal, huge penalty, and a network outage causes one bank to reply late. Boom, just caused a million dollars of bad PR.

I'm just playing devil's advocate here - I want this to work just as much as you do - It's just a tall order and some could argue logistically impossible to lock down flawlessly. All you can do is mitigate and people need to realize they're asking for fairy dust - What we're going to be given is a series of best-effort mitigations that just have to work as-well and be cheaper than existing centralized solutions.

>>13878061
There's more than one oracle. It's a good first try though fudlet

>>13878280
Bitch I ain't fudding, pic related is on my desk right now.
Not talking about oracles anyway, talking about the protocol diagram involving three actors, one of which is a bank.

>>13878306
>typo
one of which is an oracle, my bad

>>13878306
>he balances a pyramid of link cubes and a watch on his laptop while shitposting
fucking why? how many times have you knocked those over

>>13878330
I have a long L-shaped desk by a window - those are behind me, never once bumped them down

>>13878306
Do you reach over the cubes to type or do you sit really high and reach down to the keyboard so your forearms don’t knock over the cubes?

>>13878253
Buddy, you should do some reading about these things before asking these questions. These are simpleton-tier questions, for low IQs. You think the guys running this business haven't already thought through all of this in detail and dictated exactly how it's going to function? The information exists, you don't have to be hypothesizing using your pea brain. Just go read and you'll understand.

>>13878306
You have good points.
Ignore the brainlets.

There will just about always be a weak link. Here it is the data providers that provide the data to the oracles.

There are quite a few cases where financial institutions manipulated rates of various products to make fuck loads of money.
Each time they were caught, they were fined a fraction of what they made.

With this proposed tech, the transparency is the big factor.
Ideally you would have multiple data providers and multiple oracles.
Once the oracles start to report bad data (or simply different data) a red flag goes up and you investigate.

There are more entities with more money on the line here in the proposed solution, so the motivation and *ability* to identify and fix the bad actors is much higher.

>>13878253
>>>13878191
>So the penalty is a constant amount? It shouldn't be relative to the size of the potential loss? So it's worth it to act badly for high value deals, then.
The penalty will vary for each contract you have with the oracle providers.
This is negotiated (via smart contract) in the SLA agreement(s)


>Make it scale to the size of the deal, and you have another problem: Billion dollar deal, huge penalty, and a network outage causes one bank to reply late. Boom, just caused a million dollars of bad PR.
You're correct. This is not a good situation.
To reduce this exposure, you'd want to pay for how ever much decentralization as you want/need. In your hypothetical, you'd want multiple data providers and multiple oracles.
Instead of lumping the penalty onto one entity, you're distributing it across potentially thousands of nodes and multiple data providers.

>I'm just playing devil's advocate here - I want this to work just as much as you do - It's just a tall order and some could argue logistically impossible to lock down flawlessly. All you can do is mitigate and people need to realize they're asking for fairy dust - What we're going to be given is a series of best-effort mitigations that just have to work as-well and be cheaper than existing centralized solutions.
This is correct.
The goal is not to remove ALL risk/exposure, simply make it better and cheaper than the current solution.

>>13878361
No they're on the wing of my table behind me and to my left - About 3-4 feet behind my elbow.

>>13878379
You're preaching to the choir man. You sound like you have blind faith in blockchain engineers whose field didn't even exist like 6 years ago. I've been coding sockets twice that long, kek.

The problem I'm outlining isn't even with blockchain, it's on the particular communication protocol they built using blockchain as the communication medium - centralized or decentralized, the issue is the same.

>>13878552
>centralized or decentralized, the issue is the same
And there are established and well known ways of mitigating them, but it's also quite well known that they aren't perfect.

>>13878409
>>13878501
Thank you for being civil, it just bugs me when shills can't fathom how I could be long oracle tech but also understand that it's not a perfect gift from heaven, so they assume I'm a degenerate shill like they are for a different project coming to FUD them, when I'm literally already long their project, lol.

but isn't there already smart contract derivatives ?

>>13878552
I thought you had arms with two elbows, I’m a little disappointed desu