Gold collapsing. Bitcoin UP.

[79b79aa8]

it seems to me the details of the use-case are a little far-fecthed (the small farmer who never was banked or had significant savings, is financially naive but is about to start hedging). change the example to industrial farming (or with appropriate tweaks to any relatively advanced operation like industrial mining -- for ore or coin -- , or tourism, etc.) and you have a product.

in other words, i think it is more likely that use cases come from the developed economy and over time trickle down and slowly make more efficient the less developed one, than the other way around.

the killer use case for the less developed economies is what we've always known and still have not nailed, i.e, remittances. i want to send 50 USD worth of BCH to a cell phone number somewhere in the global south, and for the recipient to be able to instantly cash it in local currency at a convenience store. with total fees less than <1% paid on my end, so that instead of buying some forgettable dinner i just took care of my brother's rent for two weeks.

 

[AdrianX]

The question then becomes how do we know what will and will not "make the lives of such trusted providers to interact trustlessly with each other easier."

We don't, trusting the money to do a function needed in the economy is not the main reason we need those features. e.g. pulling data from an ITOT weather vane and using multisig in an insurance contract requires just as much trust as a trusted third party. It's a business opportunity trustless ness can come from an Open Transaction server. 8/10 is not a reliable data point. It is a target for a hacker or some vandal to go out there and tweak a weather vane internet feed.

You need business to go out there and maintain the weather vane with integrity. You need reputation on which to build trust. Money can just move the trust out of the economy, businesses and individuals working in the economy build trust and then sell it.

OP_CODES that allow reputation and decentralized identity verification will create the future we want. I like the idea of micro-crop insurance in Africa but I can't trust weather vane, I can trust a betting site that has a reputation tied to maintaining the weather vane and paying out bets.

Money can't solve that trust problem.

Bingledack's Law! I love it its quantifiably true but I suspect only at this stage in the adoption cycle. In the Technology Adoption Cycle, you have the innovators these are the consumers who overpay to be first and in business, they have highly experimental loads of failures.

In the Technology Adoption Cycle, only about 2-3% of your total market are innovators. It seems to me Bingledack's Law applies to this market segment.

The Crypto Space is full of innovators today most altcoins ICO's and ICO investors represent this category in the Bitcoin/ Crypto adoption cycle. Early Adopters are the key. These are the people who break social norms to use tech for its quantifiable utility. They trigger mass adoption.

I don't think Bingledack's Law will be as relevant in the early adopter's stage 3-15% of the global population as I think being everything to everyone is like monkey chasing sparkles in the sand.

That said I think the people in the Bitcoin BCH community have the right idea build utility. Go out and do a business that provides micro-crop insurance in BCH, I think its folly to design BCH to take work out of the economy.
[doublepost=1520626787][/doublepost]

The oracles for this already exist and already publish feeds into the public domain that are effectively "signed" by being on their website.

I'm not criticizing the concept just trying to illustrate that trust can't be moved out of the economy into the money system. The breakdown we see today is abused trust in money.

We need these to become as decentralized and trust free as Bitcoin today. these systems are fragile. People are not going to fix a hacked weather vane in Africa, not for many months. Not the BBC or the weather vain owner it's like the wild west out there. But some with a reputation in that community will put his life on the line to keep it up and running for a very low cost.

 

[awemany]

The question then becomes how do we know what will and will not "make the lives of such trusted providers to interact trustlessly with each other easier." Evolution, natural selection, the market, etc. need a matrix of stuff on which to work, so as long as there is no identifiable harm, it might be wise to support what the majority think of as "marginal use cases" just so that they have a chance in the selection pool.

But market evolution happens on the level of companies that are made up of thinking agents, not molecules following simple mechanical rules.

Those actors can (and will, and I think if you look around, are even doing this already) voice their concerns or ideas for opcodes that would help them to implement their products.

It is rather a marketplace of ideas.

And I think currently this is a healthy environment, even if somewhat heated at times (e.g. the OP_GROUP debate).

Ideally, the miners watch this and after careful consideration, implement what makes sense.

I generally agree that "complexity is evil," but bitcoin having a few vestigial organs in exchange for world domination will not bother me much more than my own body's appendix.

Fair enough.

@awemany

What I have in mind is much simpler than real crop insurance. It's just hedging, like buying/selling futures. In the farmer's case, it's merely a hedge against protracted drought. The insurer(s) typically would know nothing of the farmer; they'd simply see that someone is willing to take the other side of their bet (that the rainfall in a region will exceed a certain amount).

The oracles for this already exist and already publish feeds into the public domain that are effectively "signed" by being on their website. BBC Weather, weather.com, etc. For example this one for the weather in Manchester. The only change these existing oracles would need to make is to publish a version of these feeds that is signed in a format OP_DATASIGVERIFY understands. Similar to publishing the rainfall data in inches instead of just centimeters.

Fair enough. Maybe there should be a way for third parties to publish oracles, but not get involved in the process of signing transactions for anyone wanting to use said oracles.

But do we need OP_DATASIGVERIFY for this, or can the oracles communicate to us simply by publishing or non-publishing of certain data?

In other words, don't we have that functionality already? Can't an oracle simply create keys used in a multi sig output and then publish one vs. the other depending on the oracle's answer?

As there's no industry standard for "signed oracle outputs" yet, I don't think requiring the data in a special form is too high a burden.

Maybe one rather wants a library / API / service that would allow oracles to provide this information in an easy way and then auto-construct the necessary dependencies?

 

[theZerg]

@awemany, you are correct that with an oracle there is still trust. But we are narrowing the trust down to the absolute minimum required. And by doing so we are reducing the responsibilities, the regulation, and therefore additional fees associated with these types of transactions.

For example, the weather service is not the custodian of a huge insurance fund. If a hacker manages to crack the oracle-based weather service he can't simply steal all of the insurance money (like he could if he broke into an insurance company). The best he can do is take out a bunch of policies and then sign statements in his favor after cracking multiple weather oracles. He cannot touch the funds in policies already made, and likely his behavior (taking out weird policies anonymously) will trip some alarms.

Most if not all of this activity won't be anonymous anyway -- it's just that the resolution is convenient.

For example, I see OP_DATASIGVERIFY as extremely valuable for a much more prosaic reason: you and your buddy (or a stranger) could tap your phones together in a bar to make a bet on the outcome of a sports match -- and the winner will actually get paid instead of hearing the age-old "I'm out, I'll get it to you later". This is the sort of "killer app" that will drive installation of BCH wallets on phones and creating a virtuous feedback loop.

I don't agree that we have lots of time. There's a big land grab that goes on whenever a new class of technology comes along. Once you're using BCH and all your friends are too, its a pain to switch everyone over. Whichever blockchain first represents major stocks, bonds and currencies is going to be the one that everyone uses. We need to use our ability to hard fork to move decisively into these applications.

 

[Norway]

I just published an article on Yours about how Lightning Network introduce credit risk.

https://www.yours.org/content/how-lightning-network-introduce-credit-risk-30bfd41482b4

 

[theZerg]

5 miles of cars?

 

[Norway]

@theZerg
Was that comment for me? (5 miles of cars?)

I don't understand.

 

[MarkBLundeberg]

Good article @Norway... in defense of LN, it's worth noting these loans are guaranteed (no risk of default) so they can be issued at lower interest rates. But loans they are, nonetheless.

On the other hand, if a central node is not particularly rich then they will need to take out fiat loans in order to fund channels, along with "Put option" bitcoin futures to hedge against risks associated with bitcoin volatility. The cost of these securities will have to be passed on to users.

 

[Norway]

@MarkBLundeberg
Thanks! I believe i mention that the collateral is 100% in the article. So yes, the interest rates will be low, but still existing. And I agree that all the cost and risk in the system will be pushed to the users.

 

[Norway]

His BCH wallet lets him take out "crop insurance" for his local area, which under the hood involves placing a bet on monthly rainfall for July and August using OP_DATASIGVERIFY.

This insurance must trust Rainman who holds keys to describe the weather. Rainman is the oracle, and he tells the system if it was rain or not.

So, it's a centralized service. Rainman doesn't need blockchain scripting to provide his service. He might as well run a website where he sells insurance/derivatives for BCH.

 

[reina]

Hey, welcome to Yours, Stein : )
Thanks for your article.
I think LN is just a cover for banks in disguise. Who else has these very well-funded "nodes" to make channels with? The people that can part with those funds are banks and large businesses. Secondly, sending money with limitations doesn't make any sense: I have an amount to send, and i have to rely on someone else's forwarding capacity, which either limits the amounts i can send or forces me to make a channel with a bank node who will send my money via another bank node to a person with a channel at another bank? How is that different from traditional banking??

Can't tell anymore if its a bad idea made to destroy gullible people in the Bitcoin community and Bitcoin, or just a bad idea. It's not scaling, its just "Move these people who shout decentralisation to a platform that will have bank nodes, in the guise of decentralisation, because even when its right in front of their face they wont see it".

BCH continues as Bitcoin : )

 

[Zangelbert Bingledack]

@79b79aa8

I've been surprised to find out what impoverished people know about when their lives depend on it. I suspect that hedging is only not a basic concept for us because our lives don't depend on it. Also, most farmers would only be copying the idea from someone else as conventional wisdom. But the example is not necessarily a first use case, and it can easily be shifted to a small farm owner (not a subsistence farmer, a business owner) looking to expand his operation but needing to hedge against weather risks to justify the investment in hiring help, etc. Or hedge against price dips in the product, which could be done through futures if available for turnips or whatever, but conditional transactions if not. It expands the scope of what can be hedged greatly.

@AdrianX

Good point about weather stations/sensors getting tampered with by people trying to game the system. I think it will progress gradually: more bets lead to more hacks, which lead to more securing of the weather sensors (and more being set up) as they are more and more relied on as critical infrastructure.

I don't think BCH should try to be all things. Just the things that are connected with monetary network effect, direct uses of money. Programmable money that only sends to certain parties under certain conditions. That seems to cover every application I'm thinking of.

@awemany

The trouble I see with oracles having to sign off on each transaction specifically is it's a lot of work for the oracle and they probably have to charge for it, may be subject to regulations, and there would be a time delay while the parties to the bet waited to see if the oracle would approve. It gets worse if you use many oracles, especially if they charge. If they can just change the format in which they publish the data they already publish, it seems very easy. Assuming OP_DATASIGVERIFY is innocuous.

@Norway

We already have these weather record services and as far as I can tell they are relied upon to some extent for things like insurance claims and whatnot. Add that to the diversity of such services and their reputations compared with the sizes of the bets, and there seems a lot of room for win-win bets to take place with negligible risk of oracle shenanigans.

There's really no way to make information provision about the real world completely decentralized, other than to incentivize people to set up many sensors or witnesses of their own, getting micropayments though some kind of machine-to-machine system based on a reputation and identity. Maybe that's the real endgame here. In any case, the kinds of uses we're talking about here could drive development of such an oracle economy - if the reputations of these big firms aren't enough incentive to get at least a few of them to stay secure against hackers.

@theZerg

I think sports betting is another great one. Or even things like hedging against train/plane delay if you are risking missing an important engagement.

Whatever trust risks there may be with oracles, it is strictly safer and less centralized than relying on a central service to filter all the info itself. The principle is, "Make everything trustless that can be made trustless, and for everything else make the trusted entities highly redundant so there is never one or a few points of failure."

 

[Tom Zander]

I'm not against the other opcodes. I want them. However, compared to OP_DATASIGVERIFY and OP_GROUP, I just don't see them driving use cases which will make people jump up and install a bitcoin cash wallet on their phone.

I would agree that "smart contracts" are not a big reason to install a bitcoin (bch) wallet on your phone.

But at the same time I also don't think a phone based bitcoin wallet should be used for anything more than small payments. I don't advice anyone to carry more value in their phone than they carry cash in their wallet.

To me Bitcoin is a low-level protocol. Much like TCP-IP. One of the simplest things to build on top of TCP-ID is HTTP. The web. But much more complex stuff, like distributed filesystems and similar can be build on top of TCP-IP as well.
Compare that to Bitcoin and the simplest (and still most powerful) technology is peer to peer payments. But we can imagine many other things to be build on top of it too.

So, like telegram and keybase and other specialized apps exist that use TCP-IP, I expect many other specialized apps to start appearing for specilized Bitcoin applications. Simple example; time-stamping your thesis hash onto the blockchain.

Please remember that Bitcoin is a platform. Each new application build on top of it lifts all boats like in a rising tide. More usages means stronger networking effect.
Much like the TCP-IP stack is now included in all operating systems (that wasn't always the case), we want to move towards very mature Bitcoin implementations which can be used as a platform by many other usages, many apps and many merchant-solutions.

So, the goal to me is Bitcoin as a platform with a great set of (low level) opcodes. Implemented in some standard frameworks and dozens of applications on top of that for specialistic use-cases.

The next fight is about being the best framework. BitcoinJ for phone, Flowee for the desktop and server. But I am certain that companies like nchain want to ship their own and become more relevant and take the market that way.
Its a little discouraging to have nobody direct more than a glancing interestest in Flowee which is the ONLY actual framework that allows people to use full Bitcoin as a platform.

ps, the updated website is in testing, comments welcome. http://test.flowee.org

 

[witly]

OP_DATASIGVERIFY on its own already seems to enable many transformative use cases.

Scenario: A subsistence farmer with a $5 solar-powered feature phone that can use BCH, faces a problem. If the current drought continues into July and August (a 1 in 20 eventuality), two of his children will die of starvation.

His BCH wallet lets him take out "crop insurance" for his local area, which under the hood involves placing a bet on monthly rainfall for July and August using OP_DATASIGVERIFY.

The conditional transaction takes his input of X BCH and an insurer's input* of 18X BCH and sends all 19X BCH to him if at least 8 out of 10 of the cryptographically signed weather feeds specified in the transaction agree the total rainfall in July and August fell below a certain threshold, and sends the 19X BCH to the insurer otherwise.

The insurer has a small expected gain, and the farmer a small expected loss, but the farmer avoids the spiky eventuality where his children starve (he can take his gained 18X BCH to the market to buy enough food to feed his children). Hedging risk seems fundamental for a subsistence farmer, yet probably few if any subsistence farmers can get insured through any normal channel. Bets like this can likewise be used to hedge the risk of building a bigger farm so that the farmer can more safely build his way out of poverty.

This opens many new win-win transactions and is what I mean by money network effects being driven more than just holding and basic payments. We are accustomed to thinking of simple payment as more fundamental than insurance, but I suggest this is only because the inherent friction of trusting third parties makes it so. With that friction eliminated, is insurance any less fundamental than money? If PAY and HEDGE (or BET) are two buttons side by side in a simple wallet app, and they work equally securely and trustlessly, I think at least for those facing spiky risks like subsistence farmers these functions will be seen as equally fundamental, equally bound up in what constitutes sound money for them.

*I can't recall if there is already a way to have a tx with inputs from multiple parties in this way

Brilliant!

 

[reina]

Website is look good Tom! Pretty clear structure so far.
I've been very interested in Flowee conceptually, but sorry that I'm not a dev , so can't comment on the actual architecture, other than that I've been trying to understand and learn the gist of it from the info on your website.

As for carrying cash on phones or on their person: I think people already do carry huge digital amounts, via debit/credit cards, mobile bank app, etc. So at the very least, Bitcoin wallets are and need to be more secure, but tricky thing is, people are so used to leaving their money entrusted with someone else, that they don't think anything of forgetting their password. They think they can ring the bank or customer service to get it back.

In Bitcoin, it becomes the person's responsibility to write down either a password or seed, to a place they wont forget or lose, and also hidden from someone else, so it already becomes more hardcore in terms of requirements to what an average person is used to. I've also done the noob thing many years back when I either wrote down or memorised the password of a wallet hosted on blockchain.info, but at some point, i forgot what it was : (.

Part of the challenge designing for users totally new to a tech is about how to ease them into these new habits and new ways to operate when they are engrained with old habits. The balance between security and accessibility may come with some sacrifices in the interim, as they learn to use it from the "easier" way. Different apps and services can occupy space on a sliding scale of accessibility vs security, so that any user can enter into the ecosystem with their current set of skills and habits, and have a starting point to how they interact with bitcoin. (Third party hosting their wallet backup = less secure, but recoverable. Or straight to personal responsibility and responsible backup).

If we were looking for very fast adoption and network effect, I think working out very good use cases for microtransactions in countries with an average low income would be really effective. Designing solutions that are really easy for them to use and understand, for all ages, and creating need solutions that can help them do more with less money, and with less restrictions. In modern countries, i dont think there is actually a pressing "need", it becomes more like a 'nice to have', since the infrastructure for banking and purchasing is already quiet convenient and acceptable to the average person, and much of which is digitised. In less wealthy countries, i think getting the most value out of their cents and subcents would be very useful and would find a wide and enthusiastic audience, once it is established.

It would help these countries a lot for someone to be designing more streamlined and less wasteful solutions for them. I also read about the problems with moneylenders in impoverished countries, like loan sharks charging extreme interest rates, so there is a really pressing need for people to build their own wealth slowly and not resort to some shady services.

There is one page i saw where you can generate the hash of your document or file to add to BCH blockchain, from Scronty: http://vu.hn/Bitcoin Cash KronosData.html. I havent tried it, but assume it works

 

[witly]

@awemany

What I have in mind is much simpler than real crop insurance. It's just hedging, like buying/selling futures. In the farmer's case, it's merely a hedge against protracted drought. The insurer(s) typically would know nothing of the farmer; they'd simply see that someone is willing to take the other side of their bet (that the rainfall in a region will exceed a certain amount).

The oracles for this already exist and already publish feeds into the public domain that are effectively "signed" by being on their website. BBC Weather, weather.com, etc. For example this one for the weather in Manchester. The only change these existing oracles would need to make is to publish a version of these feeds that is signed in a format OP_DATASIGVERIFY understands. Similar to publishing the rainfall data in inches instead of just centimeters.

10 or 20 of these oracles, all major weather/news services, can be referenced in the transaction. To guard against the services going down or corruption at any one service, the condition can be set up such that 8 of 10 (or 15 of 20) of the feeds must match for the conditional transaction to be activated. The oracles get their reputation by publishing reliable data, so the odds of a bunch of these major services colluding to game a bet is near zero unless the bet is gigantic, and even in the case of a large bet the evidence would be easy to spot.

To perhaps state the obvious, security (and therefore trust) is always probabilistic, so simply increase the number of oracles until you are comfortable that there is in a practical sense no trust involved. The chance that the US government, the BBC, weather.com, RT, NBC, and five to fifteen other such services are all going to collude over any bet under millions of dollars is negligible.

Similar with exchanges publishing price data, thereby allowing hedging even if futures aren't specifically offered or aren't offered to the unbanked.

With the data in hand from freely available sources, the wallet of the winner of the payout simply pushes the tx and gets their payout from the locked coins. No trust or fancy stuff, beyond simply recognizing that the odds that many of these big oracle services will collude is tiny for the amounts dealt with. The oracles would generally have no idea their data is being used for this particular bet. They don't interact at all. They simply publish data for the same reasons they always have, and let people use it for whatever they want. Hopefully this also explains why it doesn't work in BCH as of yet. The oracles are not active deliberate participants in the particular bet.

Note that most of the action is offchain. Only the actual transactions to lock and then send the coins to the winner happen onchain. These transactions are not "contracts" as in the Ethereum paradigm, but merely conditional transaction structures. The chain doesn't get involved in the complexities of whatever use humans would put these conditional transactions to. It merely sends the coins where the transaction says they go, based on the data sigs referenced.

The way to get the oracles into the game is not letting them do it for free. We don't need weather.com etc to be the oracles, we need some middle companies to check whether the condition written in the contract is met or not. They will ask a fee for the service and they are chosen by both the insured and insurer so they better to act fairly. In this way the market will choose the most trustworthy and economic middle companies for various kinds of condition checks such as weather, accident etc. Everyone with capital can create insurance policies, and everyone can offer the middle man service to check various conditions involved in a policy.

This decentralized insurance ecosystem will create much more flexible and diverse insurance products at much cheaper price the traditional insurance companies (such a AXA) can not compete with.

 

[reina]

Kinda like https://byteball.org/, but for BCH : )

 

[Tom Zander]

just because I am arguing for being conservative doesn't mean I won't be dragged along towards a BCH becoming BCH+ variant. Lets just be slow and careful. No feature and opcode is urgent enough to not wait another 6months IMO

Slow and careful, hmm. But how would you feel if everyone went with the competition in the time you have no product on the market?

Next to that, what do you actually think you'll accomplish by waiting to roll out a solution for 6 months?

 

[satoshis_sockpuppet]

Slow and careful, hmm. But how would you feel if everyone went with the competition in the time you have no product on the market?

Next to that, what do you actually think you'll accomplish by waiting to roll out a solution for 6 months?

It's pretty easy to fuck up the one thing that makes your product so valuable, being good money.

Bitcoin Cash is the conservative plan for a worldwide currency. It shouldn't become a testbed for half-baked "solutions" and fancy tech stuff out of fear of the competition.


If anybody thinks, that Ethereum got that big because of smart contracts, they haven't been following the events in the last years very carefully.

Bitcoin would be at 90+ % marketcap share if Bip101 would have been deployed. Without new opcodes or anything.

 

[rocks]

A few thoughts on Bitcoin as "money only" vs. "money+"
.....
It seems a tad naive to simply imagine every bar of gold swapped out for a bitcoin in a vault, central banks carrying out Bitcoin swap agreements *with trust*, and so on, does it not? I suggest that to become the sound money of the world necessarily entails expanding the scope of the soundness of money. No longer is it sufficient for only holding and simple transfers to be sound (secure, trustless, and frictionless), but for all kinds of more complicated transfers to be sound as well.

Wish I could 'like' this post a hundred times, great summary. The problem with being "the best sound money" is it falls far short of our competition. And by competition I do not mean altcoins or ETH, but Federal Reserve Notes.

Federal reserve notes are a technological invention, yes this is how it was described when introduced a hundred years ago. And it was an accurate description because by moving from physical-based money to ledger-based money it was possible to integrate money with trusted smart contracts through a legal framework. Most people think the dollar is the world's reserve currency because the US has a superior military or economy, however this is not true, it is the US's superior legal system which makes the dollar valuable and the world's reserve asset.

Here is an example, consider a ship owner in the 1700s who needed to insure their shipment to protect against a full loss if the ship was attacked or destroyed. In major ports there existed insurers who ship owners could exchange a smaller number of physical coins for a large future promise. The problem however is there was nothing to protect the ship owner, they made an irrevocable transaction in exchange for a promise. If the insurer went bankrupt or disappeared there was no protection, the money was already transferred and gone. As you can imagine recovery rates were poor and ship owners obviously preferred to only transact with very established houses who could reasonably be trusted to not disappear, and they charged a premium for that.

The invention of federal reserve notes changed this. Now instead of exchanging physical money that could be walked off with, the ship owner and insurer could exchange ledger balances with the federal reserve (through their banks as the intermediary). On top of this these ledger balances were protected by an extensive legal framework where insurers now had to maintain enough money to cover potential payouts and they could not just withdraw and run off with their ledger entry. We take these arrangements for granted today, but they were a huge leap forward.

The problem of course is there now exists centralized control over money and the capability for the ledger owner to create new ledger entries out of thin air. This is the focus of sound money proponents for Bitcoin (which I am a part of) but it is important to understand that sound money and the ability to make payments is probably 1% of the dollar's total utility.

Cryto currencies will not compete with federal reserve notes until they at least reach the same level of functionality, and ethereum with it's focus on ICOs falls far short of the dollar in terms of functionality. This is why it is important to keep expanding Bitcoin towards a BCH+ concept.

I think your views of developing BCH based smart contracts by utilizing a trusted oracle is an excellent balance between integrating the base money unit with the contract but not requiring everyone else to process the contract. The blockchain is essentially used for storage where an oracle posts information and users can make references on that to unlock transactions.

There is A LOT that could be done with this model. For example, NASDAQ and NYSE post trusted financial information, this could be posted by an oracle using NASDAQ's own public cert and now stock market futures and options are available directly in BCH. That is powerful.

From a legal perspective it will be interesting how far this could go. The above example should legal, but what if I decided to be an anonymous oracle of college football? Now you could offer college football betting directly in BCH and there is NOTHING governments could do to stop it (well after we have zero knowledge transfers or something equivalent). Just that one example would drive tremendous value to the BCH chain and college football results would only require one MB of storage per year, which is a perfect trade off.

Anyway great concepts on how BCH smart contracts could be done. Need to think about this more....