Hacker News Reader

Comment by _red | Hacker News Reader

Some of the use cases can be fairly simple (thus easier to see the value).

1. Me and You start a company together. We would like to split things 50/50. We setup an address such that when values are paid to it, half goes to you, half goes to me. Effectively we've created an "LLC with an Operating Agreement", but we aren't relying on political legal system / country to enforce. Enforcement is automatic and done by the network.

2. You want to setup a Trust for your kids. You create a contract that holds 10 Bitcoin / Etherum / etc. On the date Jan 1, 2035 the value of that address will be forwarded to your child's address. Again, we created a "Non-Revokable Trust" that is network enforced. No need for probate, courts, trustees, etc.

View on HN

> Me and You start a company together. We would like to split things 50/50. We setup an address such that when values are paid to it, half goes to you, half goes to me.

What is the real world use case for that, though? That seems like a contract that makes sense as long as you and I trust each other, which rather negates the purpose of a contract.

Some immediate issues that strike me:

* There's nothing to stop either of us offering the services of the company outside of that contract;

* There's no way to ensure that one of us isn't freeloading;

* If my wallet gets stolen you'll be paying half the earnings of the company to the hacker until the contract is somehow voided;

* Which raises the question of how can this contract get voided? Do either of us get to void it whenever we feel like it? What if I've lost my key? Do we potentially just have to live with the money being paid into hacked / unusable accounts forever?

So all you've really saved is the bother of dividing a number by two and doing bank transfers, in return for which you've gained significant operational burdens.

1- 50% of what? Revenue into the company or dividens/salary etc out of the company? if it's the latter, then, how do we make sure that you don't spend $500.000 for trash bins for the office? Do we have to make sure every decision goes through the network? (i.e. who is the authority to decide what is reasonable and what is blatant fraud if things go sour AND is it even possible to make sure that nothing possibly can go sour[I don't think so.]. So, fraud is possible, and in the case of fraud, -say; the network retroactively decides that something really constitutes a fraud, hence is a crime- who is the enforcer of the punishment[which is most likely to be physical: like prison sentence]?)

2- How do you make sure that your child doesn't sell it in 2025 and buys a Lambo? (which is a problem you don't have with regular Trusts AFAIK)

Parent gives you an answer that is scoped to "divide incoming by half and send the halves to given addresses" and you criticizing that the answer doesn't cover all scopes you can come up with?

Him: "This baker makes bread rolls". you: "What about dark bread? What about non-bread items? What's his broker?"

_Red gave two examples of Ethereum applications.

SeckimJohn quite quickly showed why neither work. The are some niche digital uses, but not the ones people often tout.

Ethereum contracts basically break down at the point they need to interact with the real world.

Well I'm entirely new to this and pretty blockchain sceptical but I don't think SeckimJohn showed why neither work, did he?

As I understand it each concern requires some kind of function/method which addresses it within the smart contract, right? So the real problem is that once you publish the contract you better make sure you haven't forgotten something important...

He didn't show that neither work, but the examples he did give were trivially bypassed and didn't seem "real world" at all.

For instance, I can't think of any corporate structures that splits income in half. Usually the money is run through the company and costs etc. are taken out first. So this isn't a real world example?

Right, the examples are just missing the step of "somehow make sure this isn't as bad an idea as it looks".

Basically both examples in order to work would need legal enforcement or guardianship outside of Ethereum.

Which they both need to work today anyway. So whats the point?

Until ether contracts can hold people to their word, are recognised by the judicial system (which wouldn't be able to effect it without some weird judge API), or is able to enforce some kind of judiciary process itsefl (SKYNET WARNING), they'll always break down at the physical barrier.

The only thing seckimjohn showed is that contracts, paper or "smart", are only as good as they're written. Since contracts such as _red gave, "we are friends, this is our company, we share the EBT equally", exist right now, it's a perfectly realistic use case for a smart contract. Hell, I'd even do that for a small project.

Smart contracts being fixed and errors being exploitable is a valid criticism but it's not the be-all-end-all argument for them to have no real world applications.

No its fundamental.

In the trust fund example, you cant stop the recipient trading their key or wallet early, as you have no way to verify the human holding it.

Unless you keep that access with some legal guardian. In which case your security still sits in the legal system, as it would if you just used a trust fund. So whats the point?

Again in the company example, it only works if you both observe that the coins mean shares in company. Which you can only really enforce with a legal agreement, but again, why not just have a legal agreement that says you split your share?

They completely breakdown at the physical barrier. Darknet markets only work because the seller doesnt control the market and has a deposit. But apart from that they can transact anonymously, that part has nothing to do with blockchain.

What's to stop someone from trading a normal trust fund away? The recipient can simply take out a loan with the trust as collateral.

how do you prove to the bank the non-existence of a clause that would void the trust if this is done(and noticed)?

the main point I tried to make above was this: in normal life there is the "human factor"; like, if you look at a situation, you can reasonably comment on whether it's a positive situation from an actor's perspective; whether the actors were engaging in fraudulent activity etc. In digital-only world, there is no such thing as "probable cause", "reasonable doubt" etc.

which makes the application of smart contracts to real life intractable(IMHO borderline impossible for complex situations for the near future[~10 years?]).

""smart", are only as good as they're written"

There are so many things that go into contracts that cannot be articulated in 'code' that this all hardly makes sense.

Employment contracts are long. Comp packages can be complex.

And we all live in countries with employment laws etc. that require these things anyhow.

I don't see any actual real-world cases for Eth contracts just yet.

> There are so many things that go into contracts that cannot be articulated in 'code' that this all hardly makes sense.

I think this is actually something I've been trying to articulate for a while now anytime smart contracts come up.

Legal contracts only specify the criteria and conditions surrounding a contract. Smart contracts must describe that PLUS all the very specific instructions on how to validate those criteria/conditions which adds a massive amount of complexity into the contract (and more potential for loopholes).

The earliest smart contracts will likely involve things that are relatively easy to verify, e.g. a bet that the price of ETH will be above X at Y date and time.

Ensuring that accurate, real-world data gets entered into the blockchain to enable broadly useful smart contracts is going to be an interesting area to monitor over the next few years.

Augur attempts to align people's incentives to accurately report on real world events, like political events (aka Oracles). Axa pays out on delayed flights with a new flight insurance product[1], from data gathered from public flight information, which triggers an automated payout.

[1] https://fizzy.axa/

"a bet that the price of ETH will be above X at Y date and time"

Not so fast. Who says 'what the price of ETH' is? There is no such thing as 'the price of ETH' - there are simply buyers and sellers each willing to sell and buy at different amounts.

You'd have to agree on a mechanism to agree on what that price even is.

And what about odd fluxuations? Market cheaters - i.e. getting a hold of a vast quantity of ETH just to jolt markets for a few hundred milliseconds just to jigger some contract?

As far as 'paying out on delayed flights' - that's a very cool idea, but I can't imagine why on earth it would be in ETH on a distributed ledger.

regarding number 2, the child would not have a way of selling that Ethereum before 2035.

Can't they just sell access to their address?

One way or another I'd rate the odds of their still having access to that address in 2035 as pretty low.

Realistically anything that requires people to have decent data management / opsec is going to fail for >99% of people.

They could but the buyer would not have assurance that they are the only one with the private key and therefore likely wouldn't do it.

They sell the proof of identity or authentication information that is used to associate a person with an Ethereum account to someone else, out of band. Ethereum only knows the address to send to, and has no idea who or what is behind it at the time.

If the beneficiary dies before 2035, their heirs will collect, for instance. It is pretty simple to do a TVM calculation to determine the current value of a future benefit, and without all that legal-system stuff that is being bypassed through use of smart contracts, the intent of the trust creator can be more easily bypassed.

" the child would not have a way of selling that Ethereum before 2035"

In 'no legal land' it would be easy enough to sell a bunch of 'locked until 2035' etherium - wrapped in another ether contract like a future or something. Much the same way lottery winners who get an annuity instead of a lump sum can then sell that annuity for a lump sum.

Those are both really interesting thanks.

I assume in case 2 Solidity language has some built-in mechanisms for ensuring that the current datetime is agreed across the whole network?

Yes, every block includes a timestamp so everyone is forced to agree, and nodes won't forward a block if the time is too inaccurate. Miners have some leeway to manipulate time a bit, so you wouldn't want to use the block's timestamp as a random seed for a lottery, but just using it as a coarse deadline works fine.

As DennisP said, yes there are mechanisms to ensure date is agreed upon.

Your question of "consensus" brings up other interesting points. I think an increasingly valuable service in a new smart-contract world will be to have an "Outcomes As A Service" arbiter. This would be a trusted 3rd party that publishes real-world outcomes in a method that can be accessed reliably via smart contracts.

Who will win the football game between Dallas and New Orleans on Nov 22, 2019? Who is winner of 2020 Presidential Election? etc....Essentially a service that you can tell them you want to track some real-world event and publish outcome for use in smart-contracts. Obviously this 3rd party would need to be transparent, have an open appeal process, be neutral and earning income not tied to outcome, etc.

What happens to gaming laws (and cities like Las Vegas), in a world where sports betting can be done with no middle-man needed?

Services like Oracleize already allow you to do something similar to this.

This is the main problem I see with smart contracts (Even with oracles?)...

How do the nodes running the code all get the same response from an external data source?

Even if they use a service such as oraclize if the contract calls https://api/query?param1 and it returns lets say the weather:

Node1 gets: 15.2c Node2 gets: 15.3c

We've already failed on consensus haven't we?

The nodes don't all separately query the source. Instead, someone queries the source and sends a transaction to the network, with the data and the source's signature. The transaction gets incorporated into a block, updates the state, and now everybody has the same data.

Interesting. So in the case of 1, I guess I could have a function in the contract called something like sellUserXStakeTo(userId Y), that would let me transfer my 50% ownership to another user Y. And that method would be secured to only accept being called by me, or by another contract written by me.

Then if a user Y did come along and wanted to buy my stake, we'd agree a price P, then I would write a second contract that said: If user Y pays user X amount P, then call sellUserXStakeTo(Y). Then, once I'd published it, user Y would verify it, then pay the money, secure in the knowledge that I could not alter or back out of the deal.

Out of interest, are there any examples of real "live" structures in place using those mechanisms?

Just a simple example, sort of: https://hodlethereum.com/

It will send back your ETH after a certain date. You can check the smart contract in the bottom left corner.

How about using smart contracts for prop betting

Reply on news.ycombinator.com