Hacker News Reader

Comment by chromaton | Hacker News Reader

What does that get you?

it gets me paid in a timely fashion, without human emotion from either party mucking things up. isn't that the goal?

traditional: send PDF quote, go back and forth on quoted terms and cost 1..n times, wait for signed PO, call 1..n times reminding them to sign the PO, eventually get signed PO, do work, (at this point client is your BFF and calls you every 5 minutes asking if the work is done yet!), deliver product/service, get at least 100 bug reports on things that differ from the original approved spec/quote but should have been "implied", fix "bugs", send PDF invoice 1..n times, call buyer to remind them to pay invoice 1..n times, get runaround and sent to various accounting people most of whom are on vacation 1..n times, finally get told check is in mail 1..n times, wait 30 days per cycle, sacrifice chicken, call back and find that check was never sent and invoice is lost so repeat steps again, finally check arrives, deposit check in bank

eth: seller defines contract in solidity with various Oraclized callbacks for spec acceptance, delivery of work product(s), final acceptance test execution, and various failure modes that return eth back to the buyer's wallet if necessary, buyer funds contract with eth, acceptance events (e.g. signed PDFs in dropbox, or some git commit, etc) triggers payment to seller's eth wallet, OR on failure cases returns money back to the buyer's wallet

lots of hand wavy stuff here but since we're just discussing ideas...so, in all sincerity, what does this not get you that you are looking for?

EDIT: fix typo

That sounds like all the same problems with defining a "traditional" contract, except now when things go wrong you have to explain what ETH is in civil court, hope the volatility of ETH doesn't make things weird, and also hope your solidity contracts don't include bugs that let people steal your money (or if they do contain bugs, hope you have enough clout to cause a hard fork).

Well I would argue it has all the same goals and steps of a traditional contract, but automated and electronic. Your points are all valid today...but I recall similar points about e-commerce and e-banking circa 1999. I can hardly be considered a blockchain fanboy (I own precisely 1.0 ETH for experimentation only). But I do sense that the problems you mention can and will be solved by someone or several someones with enough time and money since there are real pain points here. Maybe 5 years, or 15. But I think our kids will find this post in the 2020s in their AR equipped Waymo and laugh at how we did things now.

And the lawyers I know personally love to litigate new things in civil court. Like robbing banks, that's where the money is!

I sell physical products, so an Etherium contract can't check that. Same with most non-computer services.

Still, I could see this working with custom software services if you were able to write a smart contract that can test every aspect of the software to the level of detail you need. Good luck.

Physical products? Do they still make those!! ;)

Agreed, I feel your pain. I would think this is only initially a solution for specific use cases, SaaS being one of them...and luckily the one I do. And in a highly regulated, safety critical sector, where testing every aspect of the software to not only the level I need, but to the level the regulators demand, is what it takes.

That said, a contract doesn't necessarily imply perfect precision. You can still deliver to vague specs and ambiguous goals and still get paid, so long as you encode something that both parties agree to. I have signed many paper and e-sign contracts that resulted in money transfer the traditional way for software that never did exactly what I expected, but eventually everyone was happy. I paid or got paid.

As to your specific use case, sure, the customer has to be electronic enabled in some way. Lots of hand waving here in the spirit of ideation... but when I was in India last, for example, even in the villages outside the urban centers, most small shop owners and vendors had mobile phones. I presume similar in all corners of the world these days, but certainly wherever HN is read. So if I am selling a physical widget, why can't my smart eth app send you a smart contract quote/invoice, you approve the details and shipping, and then fund the eth contract. Payment proceeds based on 1) physical placement of the widget in the hands of my bicycle courier who also has a smart phone and snaps a photo of the widget that gets uploaded for to the "oracle" app, fulfilling my end of the bargain, and 2) the physical delivery of the widget to your chaat stand where you send a photo of the delivered widget to the app before the courier signs off.

Would that not work, even for a physical good?

Reply on news.ycombinator.com