Author Topic: A critique of paul's drivechain proposal (and parasite oracles)  (Read 2185 times)

MattGoldenberg

  • Guest
Hey Paul,

A couple of days ago took some time to respond to your drive chain video. The main critiques are :

1. You can't have permissionless innovation without permissionless implementation, because innovation requires interaction with the market.

2. The parasite contract attack can't succeed at bankrupting the real oracle, because it requires the real oracle to always get paid.

3. The type of trust you're talking about (trusting that the system won't fail) is different than the type of trust Ethereum is going for (trusting that people won't control the system for their own gains). Both types of trust can be created with blockchain technology, and neither is the "right way" to use the technology.

4. The voting mechanism for smart contracts is a fragile way to prevent feedback loops, because it's impossible to foresee all problems beforehand.  Furthermore, miners aren't chosen for their ability to foresee these problems, but instead for their computing power.

5. A permissionless smart contract system is antifragile because many defenses to feedback loops can be created, and over time only the good mechanisms will survive.

I go deeper into these arguments in my video here:
https://www.youtube.com/watch?v=qPyiVgRGeHk

Would love your thoughts!

Best,
MAtt

zack

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 384
    • View Profile
Re: A critique of paul's drivechain proposal (and parasite oracles)
« Reply #1 on: May 23, 2016, 06:41:29 pm »
1) This is true

2) "bankrupting" isn't the failure mode we are afraid of. We need to pay the oracle enough, or it will lie.
All the rep in the oracle is sell-able all the time. If you can win X amount of money by getting the oracle to lie, and it costs Y amount of money to buy up enough rep to make it lie, and X>Y, then the oracle could profitably lie.
If there is a separate blockchain with a large volume of trading in parasite contracts, then the person doing the attack could earn money on both blockchains.
It sounds like Crystal and Hivemind are vulnerable to altcoin parasite contracts in the same way. Read some of my posts about it.

4) I agree with the voting mechanism being fragile because it can't adapt. You are right, miners are selected for computational ability first. Ability to censor is secondary.

5) True. Permissionless implementation makes it much less fragile.
Ethereum style smart contracts is not how permissionless implementation will be standardized. Smart contracts belong in the channels. Storing state on-chain is unnecessary and expensive.

psztorc

  • Administrator
  • Sr. Member
  • *****
  • Posts: 464
    • View Profile
Re: A critique of paul's drivechain proposal (and parasite oracles)
« Reply #2 on: May 24, 2016, 01:44:49 am »
Cool. Thanks for engaging. I will watch it later tonight.

> 1. You can't have permissionless innovation without permissionless implementation, because innovation requires interaction with the market.

A good metaphor is starting your own business. Anyone can start their own business, yes. But you should not be able to barge into someone else's pharmaceutical research laboratory and take photos of everyone's notes, and whatnot.

> 2. The parasite contract attack can't succeed at bankrupting the real oracle, because it requires the real oracle to always get paid.

The parasite prevents the real oracle from scaling up -- it can only guard a small amount of value. So it will never truly be useful.

> 3. The type of trust you're talking about (trusting that the system won't fail) is different than the type of trust Ethereum is going for (trusting that people won't control the system for their own gains). Both types of trust can be created with blockchain technology, and neither is the "right way" to use the technology.

One kind of trust is cheap for a computer to create, and extremely useful. The other kind of trust is extraordinarily expensive for a computer to create, and trustlessness would marginally add almost no effectiveness. Each day, people eat in restaurants without paying...until the very end. Or they purchase something online, and pay upfront (and wait -with trust- for it to be shipped).

> 4. The voting mechanism for smart contracts is a fragile way to prevent feedback loops, because it's impossible to foresee all problems beforehand.  Furthermore, miners aren't chosen for their ability to foresee these problems, but instead for their computing power.

Oh, so you agree that there are problems? : )

Miners do not need to "foresee all problems". They merely need to listen carefully to developers complaints, and refuse to incorporate anything which does not get widespread developer support. Because this filter would work, probably no malicious developer will bother trying to write anything which is clearly problematic.

> 5. A permissionless smart contract system is antifragile because many defenses to feedback loops can be created, and over time only the good mechanisms will survive.

It is the reverse -- Taleb makes it very clear that there is a fractal structure: something can only be antifragile if it is made up of fragile pieces. So growth / complexity requires the ability to keep things removed (which will be harder for Ethereum than for Bitcoin Sidechains).
Nullius In Verba

MattGoldenberg

  • Guest
Re: A critique of paul's drivechain proposal (and parasite oracles)
« Reply #3 on: May 24, 2016, 06:21:23 pm »
    Thanks for the reply Zack.

2) "bankrupting" isn't the failure mode we are afraid of. We need to pay the oracle enough, or it will lie.
All the rep in the oracle is sell-able all the time. If you can win X amount of money by getting the oracle to lie, and it costs Y amount of money to buy up enough rep to make it lie, and X>Y, then the oracle could profitably lie.
If there is a separate blockchain with a large volume of trading in parasite contracts, then the person doing the attack could earn money on both blockchains.
It sounds like Crystal and Hivemind are vulnerable to altcoin parasite contracts in the same way. Read some of my posts about it.

This is a more nuanced argument than Paul made in the video - I assume he was simplifying in order to reach a broader audience.

I have a few thoughts on this, but they're a little all over the place.  Here are a few of them, and I'll have to think about this and get my thoughts in order before I can truly say one way or another whether this is a viable attack route:
  • The true oracle can actually charge exactly as much as it needs to prevent this attack.  It's profit's can't be undercut by a parasite contract, because the parasite depends in it getting paid, so it can charge enough to make entire industries enter into a smart contract to pay it.
  • If someone is gaining money from this attack, then there's someone else losing money on the other side of the attack.  This creates a bidding war for reputation in these types of attacks- those who stand to lose money from the truth vs. those who stand to gain.  Just like in a prediction market, this means that the cost of the attack gets driven up to where it will almost always be unprofitable.
  • Crystal has several mechanisms to make it incredibly expensive to sell and use reputation dishonestly.

    For instance, if someone buys reputation who obviously shouldn't have it (based on recommendation algorithms), then the community takes a significant cut of that reputation.

     In addition, bought reputation is "deactivated".   Deactivated reputation can't be used to make money *in contest* and is also influence limited based on HonestyPoints, a separate identity based reputation (based on a Sybil-resistant version of Eigentrust) that can't be traded.  The only way to reactivate reputation is to participate honestly in enough contests after the reputation is bought. If an account is caught being sold (instead of selling through the official channels) that account can be deactived and all it's reputation coins returned to the community.

    These types of protections of course don't make attack impossible, but they make it significantly more expensive to buy reputation dishonestly. This in turn turns the bidding war above in favor of people who plan to use the reputation honestly.

Quote
5) True. Permissionless implementation makes it much less fragile.
Ethereum style smart contracts is not how permissionless implementation will be standardized. Smart contracts belong in the channels. Storing state on-chain is unnecessary and expensive.
Just like bitcoin, I see on-chain smart contracts being used to settle disputes, whereas offchain channels are used in the day-to-day.  Crystal plans to implement the first version of this in the form of a "shadowchain", which is calculated offchain using a reputation system, and then only run onchain if somebody pays to check the results.

P.S. What is up with these Captchas? No idea what that last letter says.[/list]
« Last Edit: May 24, 2016, 06:23:02 pm by MattGoldenberg »

MattGoldenberg

  • Guest
Re: A critique of paul's drivechain proposal (and parasite oracles)
« Reply #4 on: May 24, 2016, 06:40:19 pm »
Thanks for the reply Paul.


A good metaphor is starting your own business. Anyone can start their own business, yes. But you should not be able to barge into someone else's pharmaceutical research laboratory and take photos of everyone's notes, and whatnot.


What I'm arguing is that you can't get the former without the latter.  In other words, people won't be able to start viable blockchain business without giving them access to everyone's laboratory.

Quote
The parasite prevents the real oracle from scaling up -- it can only guard a small amount of value. So it will never truly be useful.

Because the parasite oracle depends on the real oracle, the real oracle can charge as much as it wants.  They can force entire industries to make smart contracts that collectively pay for the information they need.


Quote
One kind of trust is cheap for a computer to create, and extremely useful. The other kind of trust is extraordinarily expensive for a computer to create, and trustlessness would marginally add almost no effectiveness. Each day, people eat in restaurants without paying...until the very end. Or they purchase something online, and pay upfront (and wait -with trust- for it to be shipped).
So I think there's still a misunderstanding here.  If you're still talking about restaurants, there's a fundamental disconnect.  The real target is companies and industries who can ABUSE brand and trust through economies of scale and aggregation of users.  Amazon does this to it's suppliers, Twitter did this to it's datafeed partners, Facebook does it to it's users, Uber is starting to do this as well.

The analogy I've used is how open source allowed Google to credibly commit to not treating its smartphone partners the same way Apple did with its iOS ecosystem. Google couldn't do the same thing with Google+ against Facebook, because while open source allows a company to commit to keeping its software beneficial to the ecosystem, it doesn't allow a company to credibly commit to keep it's data and user network beneficial.  It was impossible to credibly commit to doing that until Ethereum came along.  I can't do the argument justice in a forum post, but I go way in depth here: http://getcrystal.net/blog/index.php/2016/05/08/the-business-case-for-dapps-decentralization-as-a-strategy/

Quote
Oh, so you agree that there are problems? : )

Yes, this is the scariest part of permissionless smart contracts.

Quote
Miners do not need to "foresee all problems". They merely need to listen carefully to developers complaints, and refuse to incorporate anything which does not get widespread developer support. Because this filter would work, probably no malicious developer will bother trying to write anything which is clearly problematic.

So the miner judgement thing was just an aside - the real idea here was that no matter how good your forecasting is, it will fall EVENTUALLY to a black swan. Relying on prescreening for security is inherently a fragile system.

Quote
It is the reverse -- Taleb makes it very clear that there is a fractal structure: something can only be antifragile if it is made up of fragile pieces. So growth / complexity requires the ability to keep things removed (which will be harder for Ethereum than for Bitcoin Sidechains).

This of course is entirely dependent on how far you granularize "something". As a reductio-ad-absurdum, you could use this argument to say that as long as an economy has a single company that could fail, the entire economy is considered fragile. 

Instead, I think what matters here is the level of "walls" that different parts of an ecosystem have that prevent them from collapsing when other parts of the system collapse.  My point being, that with a permissionless system, we can test all sorts of different walls made of concrete, glass, mud, and air, some of which will essentially split the ecosystem into seperate fractal ecosystems.  Over time, we'll figure out which types of walls work, and which walls still give you interaction with the entire ecosystem WITHOUT exposure to the entire ecosystem's risk.
[/quote]
« Last Edit: May 24, 2016, 06:50:09 pm by MattGoldenberg »

psztorc

  • Administrator
  • Sr. Member
  • *****
  • Posts: 464
    • View Profile
Re: A critique of paul's drivechain proposal (and parasite oracles)
« Reply #5 on: May 24, 2016, 07:46:12 pm »
> What I'm arguing is that you can't get the former without the latter.  In other words, people won't be able to start viable blockchain business without giving them access to everyone's laboratory.

You may be right about that. I don't think you are, but you might be.

If you *are* right, however, it will just mean that no one ever starts a research laboratory. Instead, people will start something like a lemonade stand. The result will be that decentralized oracles are simply impossible for everyone.

An biological analogy would be that, if cells cannot be forced to cooperate, we will never have multi-cellular life. We will just have single-celled life.

> Because the parasite oracle depends on the real oracle, the real oracle can charge as much as it wants.  They can force entire industries to make smart contracts that collectively pay for the information they need.

The real oracle must work for free, if there exist any parasites. This is because the parasites can steal the labor of the real oracles, for free. So the equilibrium price is zero.

> The real target is companies and industries who can ABUSE brand and trust through economies of scale and aggregation of users.  Amazon does this to it's suppliers, Twitter did this to it's datafeed partners, Facebook does it to it's users, Uber is starting to do this as well.

All of these companies are considered incredibly successful. They delivered high quality products and services to users at unbelievably low costs and tremendous convenience. These companies gave people what *they* really wanted. You seem to want to give them something else, like Google+, which they really do not want.

I don't really understand your Android Phone analogy. Many iPhone owners "jailbroke" their phones to install new apps, and the Google Play store moderates for content (as do the individual developers who write apps). Apps are constrained, by the operating system of the phone, and by the user's choices...one reason for this, is specifically to prevent the apps from interfering with the phone's core infrastructure or with other apps.

> So the miner judgement thing was just an aside - the real idea here was that no matter how good your forecasting is, it will fall EVENTUALLY to a black swan. Relying on prescreening for security is inherently a fragile system.

No forecasting is "required". If there are unforeseen problems, the sidechain is closed down. Given that this closing-down is inevitable, it is simply more efficient to try to anticipate problems. It is also futile to attempt attacks.

> This of course is entirely dependent on how far you granularize "something". As a reductio-ad-absurdum, you could use this argument to say that as long as an economy has a single company that could fail, the entire economy is considered fragile. 

Don't you mean "antifragile"? If layer 6 is made of fragile units, layer 7 might be antifragile.

> Over time, we'll figure out which types of walls work, and which walls still give you interaction with the entire ecosystem WITHOUT exposure to the entire ecosystem's risk.

That is what I have already figured out. It didn't take that long. : )

Assuming that "Cryptocurrency" is the anti-fragile layer, that would imply that the individual crypto-currencies are the fragile layer. So, you are arguing that we should try this experiment of yours, allow it to potentially destroy Ethereum and Bitcoin, and then later start up a new 3rd thing "SztorcCoin" which follows my principles, and have it outcompete the failed Bitcoin and Ethereum.

I don't think that money works that way.

Instead, my vision is that sidechain-systems should be the competitors. Bitcoin's 21,000,000 coin units can compete with Ethereum's ~whatever Ether units. If you think that Bitcoin's sidechains aren't good, start up your own Alt-chain with better sidechains.
Nullius In Verba

MattGoldenberg

  • Guest
Re: A critique of paul's drivechain proposal (and parasite oracles)
« Reply #6 on: May 25, 2016, 04:21:58 pm »
>The real oracle must work for free, if there exist any parasites. This is because the parasites can steal the labor of the real oracles, for free. So the equilibrium price is zero.

Can you walk me step by step of an example of how this works?  In my mind it works like this

1. Oracle R(Real) and Oracle P(Parasite) advertise their services.
2. A company pays Oracle R to get it Data S.
3. Oracle R gets Data S
4. Oracle P steals Data S.
5. A company now pays Oracle P because it's advertising cheaper prices and has good reputation.
6. Oracle P doesn't have information to give and is revealed as a fraud.

I see no way for this game to have an equilibrium of Oracle R's price going to $0.  Oracle P can only make their move after Oracle R has gotten paid, and Oracle R gets to set the price at which it gets paid.  If their are multiple companies getting the same information, it can simply set the price such that many of those companies must pay it.  The only way that this game has an equilibrium of $0 for Oracle R s if you switch step 2 to after step 5.

>All of these companies are considered incredibly successful. They delivered high quality products and services to users at unbelievably low costs and tremendous convenience. These companies gave people what *they* really wanted. You seem to want to give them something else, like Google+, which they really do not want.

So firstly, a companies success isn't only dependent on how it pleases the users. The success of it's business model is dependent on many factors, like partnerships with companies in the ecosystem.  Even if there aren't benefits to the users (which I'll argue there are in a second), there can be benefits to the ecosystem as a whole (which indirectly end up benefitting users).

From a partnership perspective, one huge advantage early on is that companies can credibly can commit to not locking down their data.  This is going to be huge in the next few years as knowledge graph and facebook graph start bullying their partners in exchange for access to that data (Twitter has already done this).  Note that there's no way to compete with these companies due to their network effect, unless you can credibly commit to not doing the same thing if the ecosystem switches to you.

>I don't really understand your Android Phone analogy. Many iPhone owners "jailbroke" their phones to install new apps,
Yes, but at huge risk to ruining their phone, and with an automatic void of warranty.  What this shows is that users WANT this behavior, but Apple is doing everything in it's power to prevent it.

>and the Google Play store moderates for content (as do the individual developers who write apps).
There's a single checkbox in android to allow you to download non-android content, because the users want it. If there wasn't, someone would fork android and make a version that had it. Google would then lose its advantage in guiding the ecosystem, so it's in Google's interest to add this checkbox (in contract to Apple, which doesn't have this threat of a fork).

Likewise, the Google play store exists as a curation mechanism, but (this is the important part) because Android is open source, the curation choices it makes have to be beneficial to the users and ecosystem.  If not, it's trivial for a Partner like LG to make their own store, and quickly get everyone to switch over because they're more fair.

Because iPhone is closed source, there's not this threat, and they frequently make choices that benefit them as a company at detriment to the users or ecosystem.

>Apps are constrained, by the operating system of the phone, and by the user's choices...one reason for this, is specifically to prevent the apps from interfering with the phone's core infrastructure or with other apps.

Agreed.

But in the closed source case, another reason is to protect the companies business interests by using monopoly and aggregation advantages to make decisions that benefit that company. Because of these advantages, it's far to costly for users or partners to switch to another platform, UNLESS there's a guarantee that this new platform won't end up doing the same thing once they have the same advantages. Right now, there's way to make that guarantee t in the case of data monopolies and network effects, unless you have a system like Ethereum.  Again, this is hard to go through in a forum post, and I think the article I linked to above makes the case more thoroughly.

psztorc

  • Administrator
  • Sr. Member
  • *****
  • Posts: 464
    • View Profile
Re: A critique of paul's drivechain proposal (and parasite oracles)
« Reply #7 on: May 25, 2016, 07:36:01 pm »
Can you walk me step by step of an example of how this works?  In my mind it works like this

1. Oracle R(Real) and Oracle P(Parasite) advertise their services.
2. A company pays Oracle R to get it Data S.
3. Oracle R gets Data S
4. Oracle P steals Data S.
5. A company now pays Oracle P because it's advertising cheaper prices and has good reputation.
6. Oracle P doesn't have information to give and is revealed as a fraud.

I see no way for this game to have an equilibrium of Oracle R's price going to $0.  Oracle P can only make their move after Oracle R has gotten paid, and Oracle R gets to set the price at which it gets paid.  If their are multiple companies getting the same information, it can simply set the price such that many of those companies must pay it.  The only way that this game has an equilibrium of $0 for Oracle R s if you switch step 2 to after step 5.

> Oracle P can only make their move after Oracle R has gotten paid

Wrong. I can say, "Regardless of how many people sign up with Blue Oracle, I (the red oracle) will charge $X and copy the Blue Oracle's answers". You can, indeed, move step 2 to after step 5.


> So firstly, a companies success isn't only dependent on how it pleases the users.

Correct. A much better definition would be "provides a sufficient return on capital employed".

If we distinguish between "flow trust" (restaurant) and "level trust" (bank), my contention is *not* that eliminating the need for "flow trust" has no value. I merely contend [1] that it has very very little marginal value, and [2] the process of removing this trust is abhorrently expensive (given how difficult it is to write secure smart contracts).

Thus, the ROCE of such projects is overwhelmingly unlikely to be sufficient. The opportunity cost of the programming labor alone is relatively astronomical.
Nullius In Verba