Zarathustra
Well-Known Member
- Aug 28, 2015
- 1,439
- 3,797
Esp. the European city centers? I would prefer them:
https://en.wikipedia.org/wiki/List_of_cities_by_murder_rate
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
https://en.wikipedia.org/wiki/List_of_cities_by_murder_rate
For those who are optimistic about the internet being a panacea for free expression, let me quickly throw a wet blanket ...
@Zarathustra: I think you might have misunderstood me. Of course I would prefer them now as well - if you have to be in one. I just think that in the milder SHTF scenario that might be coming, they could become quite a bit more uncomfortable.
- Aug 19, 2015
- 511
- 803
@MarkBLundeberg I don't know much about you or what your motives are, but this forum has been online for almost 3 years, and it's done fine without the spread of hate or other inflammatory garbage towards ethnic groups or religions. We are a diverse group of people from all over the world united by a common interest. The video you quoted is made by a coward who hides behind a voice mask to methodically target a specific group of people. We don't do that here. Take it elsewhere.
deadalnix
Active Member
- Sep 18, 2016
- 115
- 196
I love how men's right and white rights are the 2 biggest subject of hate speech. You are a white man, how dare you think you have any right ?
Also, the rest of the video seems like your typical "It's the evil juices" kind of video. You could have linked the hate index orwellian shit directly.
- Aug 19, 2015
- 511
- 803
There is no censorship. If there is shitty behavior, anyone is free to call it out.
For me, what's surprising is that anyone would willingly sit through a 44 minute video on youtube. I'm sure they have some great content. I typically can only deal with either 2-3 minute videos about Cat's or lectures from members of the Blockchain World on new/past/current projects and development. Otherwise, for most of these other videos... if there isn't a transcript in text, LOL! \
As the meme goes, "Ain't Nobody got Time for that!" But seriously, how can you sit through a 10 minutes video, or worse 45 minutes, to explain something that could have been put into text composed of one or two paragraphs. Am I alone in not understanding youtube stuffs?
Meanwhile, how's everyone feeling about the MtGox liquidations? Ow.
As the meme goes, "Ain't Nobody got Time for that!" But seriously, how can you sit through a 10 minutes video, or worse 45 minutes, to explain something that could have been put into text composed of one or two paragraphs. Am I alone in not understanding youtube stuffs?
Meanwhile, how's everyone feeling about the MtGox liquidations? Ow.
A few thoughts on Bitcoin as "money only" vs. "money+"
1) The original opcodes seem to enable a lot of things besides just colored coins. Colored coins and ICOs are probably the least interesting and perhaps one of the most economics-changing and therefore risky. I think way too much focus has been out on colored coins, because they are simple to understand, when they seem to be perhaps 1% of what the opcodes under consideration allow (with or without op_group).
2) "Smart contracts" is a bit of a loaded term evoking legal structures and such. I suggest calling them "conditional transactions" or "conditional transaction structures." That may open up some new avenues of thought about how intimately connected to sound money some of the use cases could be.
2) Arguably, to be the best money requires frictionless use in all the applications that money is put to. Escrow, insurance, derivatives, prediction markets, etc. Sure we could just use the old-world trusted third parties for such things, with the rallying cry that we focus on sound money in order to "be the best at sound money," but it seems to me that the network effect of money is driven as much by these uses cases as it is by simple payments. Which leads to...
3) ...a general rule: any use case left behind that drives monetary network effects will be taken up by an altcoin or spinoff, which will leech away the monetary network effect of Bitcoin. For instance, if we have a sound money that requires trusted parties for crop insurance, and we have another sound money that can do crop insurance onchain, farmers may choose the latter because it saves them insurance costs and risks, and increases access (think unbanked African farmers hedging against catastrophic droughts).
I don't really mind of it's two separate spinoffs, BCH and BCH+, but I think the market is likely to converge on the latter, with the former as fallback in case something goes awry. No actually, the problem there is it could take a few years for something to warrant falling back to the simpler chain, but by then the market caps may be 100x different and the fallback will be a disaster.
Speculation about the future is part of what drives the monetary network effect, which is why altcoins that try to do more are such a threat. They can get inflated and then become the market cap leader and attract all the monetary network effect to themselves, sucking BCH hodlers dry. That said, I think Ethereum gets it wrong by trying to do everything in a VM onchain, when only certain aspects of a process need to be on the chain. It seems like few basic string operations in Bitcoin coupled with offchain computing and oracle sets can do a whole lot, maybe even all the important money-related things.
4) Secure, trustless, and frictionless holding and basic payment functions must be the priority as they underpin every other aspect of sound money, but unless the claim is that we will have our hands full for years with just ensuring the scaling and security of the holding and basic payment functions, there is some point - perhaps already reached for the near term - when development resources can be spent elsewhere, especially since many new devs are interested in these other applications.
If we cannot be sure that enabling the original opcodes (and possibly more) won't interfere with the basic Bitcoin as we know it, I'll be the first to reject them, but if we can be sure they are safe (technically and economically), what is the harm? Perhaps colored coins are a worry, but things like insurance, contracts for difference, etc. seem more like mandatory features of...
5) ...money for the new century. One reason "money" is the biggest use case is that the other applications are not smooth enough, require trust, etc. We should ask not what is the prize in the old world, but what is the prize in a cryptocurrency-enabled world? In that world, I think the prize is the whole enchilada. Everything sound money would be used for, not just holding and basic payments, but all those things that conditional payments enable.
In fact, it's not even clear to me that this isn't already the case in the old world, but just sort of hidden by various human arrangements and semantics. 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.
The Rubicon has been crossed. How can we really go back, and why would would we if it can be done securely without disrupting the base simple payment function? I think that is why these opcodes were included in the original Bitcoin code. I suspect Satoshi recognized that money is never just money; its moneyness depends on more than just the function we think of as moneyness; its network effects are driven by more than just holding and simple payments, so there is a natural encompassing of all payment-related things.
The bullshit ICO craze with its misguided Dentacoins and Cryptopuppies shouldn't be allowed to obscure that there really is an inextricable connection between sound money and sound insurance, sound assurance contracts, sound betting, etc. Yes, the meaning of "sound" differs somewhat in each case, but it always comes down to them being executed with sound money in a secure, trustless, and frictionless manner - rather than merely being executed with sound money in an insecure, trusted, cumbersome manner. Notice how quickly the advantages of sound money get eaten away if many of the big monetary-network-effect-driving use cases are not similarly "sound"?
Unfortunately, our competitors will not leave these uses cases on the table for us to take up at a leisurely pace. They will feign that they are "not money" while they sneak away use cases one by one that each hold a key to the grand monetary network effect.
1) The original opcodes seem to enable a lot of things besides just colored coins. Colored coins and ICOs are probably the least interesting and perhaps one of the most economics-changing and therefore risky. I think way too much focus has been out on colored coins, because they are simple to understand, when they seem to be perhaps 1% of what the opcodes under consideration allow (with or without op_group).
2) "Smart contracts" is a bit of a loaded term evoking legal structures and such. I suggest calling them "conditional transactions" or "conditional transaction structures." That may open up some new avenues of thought about how intimately connected to sound money some of the use cases could be.
2) Arguably, to be the best money requires frictionless use in all the applications that money is put to. Escrow, insurance, derivatives, prediction markets, etc. Sure we could just use the old-world trusted third parties for such things, with the rallying cry that we focus on sound money in order to "be the best at sound money," but it seems to me that the network effect of money is driven as much by these uses cases as it is by simple payments. Which leads to...
3) ...a general rule: any use case left behind that drives monetary network effects will be taken up by an altcoin or spinoff, which will leech away the monetary network effect of Bitcoin. For instance, if we have a sound money that requires trusted parties for crop insurance, and we have another sound money that can do crop insurance onchain, farmers may choose the latter because it saves them insurance costs and risks, and increases access (think unbanked African farmers hedging against catastrophic droughts).
I don't really mind of it's two separate spinoffs, BCH and BCH+, but I think the market is likely to converge on the latter, with the former as fallback in case something goes awry. No actually, the problem there is it could take a few years for something to warrant falling back to the simpler chain, but by then the market caps may be 100x different and the fallback will be a disaster.
Speculation about the future is part of what drives the monetary network effect, which is why altcoins that try to do more are such a threat. They can get inflated and then become the market cap leader and attract all the monetary network effect to themselves, sucking BCH hodlers dry. That said, I think Ethereum gets it wrong by trying to do everything in a VM onchain, when only certain aspects of a process need to be on the chain. It seems like few basic string operations in Bitcoin coupled with offchain computing and oracle sets can do a whole lot, maybe even all the important money-related things.
4) Secure, trustless, and frictionless holding and basic payment functions must be the priority as they underpin every other aspect of sound money, but unless the claim is that we will have our hands full for years with just ensuring the scaling and security of the holding and basic payment functions, there is some point - perhaps already reached for the near term - when development resources can be spent elsewhere, especially since many new devs are interested in these other applications.
If we cannot be sure that enabling the original opcodes (and possibly more) won't interfere with the basic Bitcoin as we know it, I'll be the first to reject them, but if we can be sure they are safe (technically and economically), what is the harm? Perhaps colored coins are a worry, but things like insurance, contracts for difference, etc. seem more like mandatory features of...
5) ...money for the new century. One reason "money" is the biggest use case is that the other applications are not smooth enough, require trust, etc. We should ask not what is the prize in the old world, but what is the prize in a cryptocurrency-enabled world? In that world, I think the prize is the whole enchilada. Everything sound money would be used for, not just holding and basic payments, but all those things that conditional payments enable.
In fact, it's not even clear to me that this isn't already the case in the old world, but just sort of hidden by various human arrangements and semantics. 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.
The Rubicon has been crossed. How can we really go back, and why would would we if it can be done securely without disrupting the base simple payment function? I think that is why these opcodes were included in the original Bitcoin code. I suspect Satoshi recognized that money is never just money; its moneyness depends on more than just the function we think of as moneyness; its network effects are driven by more than just holding and simple payments, so there is a natural encompassing of all payment-related things.
The bullshit ICO craze with its misguided Dentacoins and Cryptopuppies shouldn't be allowed to obscure that there really is an inextricable connection between sound money and sound insurance, sound assurance contracts, sound betting, etc. Yes, the meaning of "sound" differs somewhat in each case, but it always comes down to them being executed with sound money in a secure, trustless, and frictionless manner - rather than merely being executed with sound money in an insecure, trusted, cumbersome manner. Notice how quickly the advantages of sound money get eaten away if many of the big monetary-network-effect-driving use cases are not similarly "sound"?
Unfortunately, our competitors will not leave these uses cases on the table for us to take up at a leisurely pace. They will feign that they are "not money" while they sneak away use cases one by one that each hold a key to the grand monetary network effect.
Last edited:
Hi Bloomie, sorry if I gave the wrong impression --- I'm not advocating any hate and I agree that the forum should stay focussed on the topic of bitcoin / internet freedoms in general. If you like I can add a disclaimer every time I link to something uncomfortable like that. My intent is not to spread far right ideologies, rather, I monitor that sphere (and other fringe sectors like darknet markets) as I've noticed they tend to be on the bleeding edge of new developments in censorship and crackdowns.
Anyway my point in linking it is to show that "thought crime" style AIs are under development. Not only in the west -- we know this is also being done in China. Of course at first these will be targeted towards unpopular fringe groups, and they will be extremely successful in doing so. But once the tools are developed, nothing stops anyone from using these AIs to suppress more mainstream opinions. We have all been sold the idea that the internet is a free and open space, but unfortunately the current platforms are ripe targets for censorship, data mining, etc.
Cheers, -Mark
@Zangelbert Bingledack : I think there's a sweet spot that is likely met to a very high and sufficient degree by BCH as it is right now.
I disagree with your example of the farmer choosing BCH+ over BCH just because it allows him to do some things as on-chain contracts. II think the network effect of sound money without fancy contracts is strong enough to overcome the relatively minor burden of having a more complex insurance scheme, for example.
I also don't see BCH vs. BCH+ too soon, at least not with SHA256-backing of both and not with a POW change. I think there's a threshold for a coin split to be crossed, and I think this threshold is extremely high. The BTC/BCH split occurred to cordon off the toxic BTC environment and (long-term) neutralize the effort that went into the PR and brainwashing. Most importantly, the BTC vs. BCH split is along a functional vs. non-functional (again, long-term) axis.
Last but not least, 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
To be able to solve any upcoming issues without splits is also why I think going back to a 75% miner activation of features as many of initially intended would make sense.
I disagree with your example of the farmer choosing BCH+ over BCH just because it allows him to do some things as on-chain contracts. II think the network effect of sound money without fancy contracts is strong enough to overcome the relatively minor burden of having a more complex insurance scheme, for example.
I also don't see BCH vs. BCH+ too soon, at least not with SHA256-backing of both and not with a POW change. I think there's a threshold for a coin split to be crossed, and I think this threshold is extremely high. The BTC/BCH split occurred to cordon off the toxic BTC environment and (long-term) neutralize the effort that went into the PR and brainwashing. Most importantly, the BTC vs. BCH split is along a functional vs. non-functional (again, long-term) axis.
Last but not least, 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
To be able to solve any upcoming issues without splits is also why I think going back to a 75% miner activation of features as many of initially intended would make sense.
Otaci
Member
- Jul 26, 2017
- 74
- 384
Some possible use cases for the new opcodes that are proposed:
- Multi-party hash locks - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014375.html
- Simple Merkle Tree Verification - https://blockstream.com/2015/08/24/treesignatures.html
- Weak Hashes and Mini-Proof of Work - https://scalingbitcoin.org/stanford2017/Day1/SB2017_script_2_0.pdf
- Examination of parts of a byte array. e.g. Looking at the SIGHASH_FLAGS of a signature
- Deterministic Random Number Generation with OP_XOR - https://scalingbitcoin.org/stanford2017/Day1/SB2017_script_2_0.pdf
- Coin Toss in Script - http://www.cs.technion.ac.il/~idddo/cointossBitcoin.pdf
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.
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
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
Last edited:
Otaci
Member
- Jul 26, 2017
- 74
- 384
Well I wanted to maintain separation between the re-enabled opcodes and any other ones, so I didnt include this example in the above post, but here it is anyway. Its conceptual.
Use of OP_SPLIT with OP_DATASIGVERIFY:
If an exchange were to produce signed data such as “BCHUSD:20180228:120000:132500:119500:130000” (BCHUSD market, 28th February 2018, open 120000 USDcents/BCH, high 132500, low 119500, close 130000). OP_SPLIT would be used to extract values from this data for decision making, after verification of signatures. Example: confirm that the data is for the BCHUSD market, that the date is 2018-02-28, that the close value was greater than 125000.
These really are basic operations that can be used by many different advanced use cases.
@Zangelbert Bingledack :
But the weather is likely just one variable of many going into a typical insurance's calculation. Farming method, crop type, farmer's insurance history are likely a few others.
The Ethereum way is the extreme example: Write a huge, buggy contract that preferably includes a deep neural network, of course (such wow, such AI) on-chain to calculate the insurance's payout and wait for the farmer's insurance to be stolen by some 13 y.o. hacker who was just reading up on how to write Ether smart contracts.
Now, we already have a way for binary oracles to work in Bitcoin: Signature or non-signature of a transaction with a key.
So your above scenario would be to have the insurer sign the transaction for payout.
Trust in third parties is necessary in any case, whether it is the weather feeds or the insurer. Multi-sig allows to spread that trust to a sufficient number of selected third parties.
And these third parties could be automated to a high degree! If you prefer a highly automated approach with a detailed, digital contract, they can just run that kind of contract and then publish the solution as the oracle's answer in the form of an ordinary transaction onto the BCH main chain.
All the details would happen completely off-chain.
This is also exactly why I do not see much value in Ether: The on-chain busywork that is seen been everyone is only of interest to a select few in the end. And those select few can choose any level of automation with any number of oracles and computational complexity (or, alternatively and depending on the use-case: good, old-fashioned human judgment) to make their contracts, and do that off-chain.
Ether shifts the trust to oracles resulting in a kind of psycho trick that has the futurist and singularity crowd chanting "see, you don't have to trust anyone anymore". Yet you do. You still have to trust the oracles.
EDIT: Now that I think about it, maybe automated, "true trustworthy computation services" would be a thing for BCH: Specify a contract and run it off-chain, and create
on-chain transactions corresponding to the results. Standardize the language and environment used so it is easy to select the third parties you want to trust.
But the weather is likely just one variable of many going into a typical insurance's calculation. Farming method, crop type, farmer's insurance history are likely a few others.
The Ethereum way is the extreme example: Write a huge, buggy contract that preferably includes a deep neural network, of course (such wow, such AI) on-chain to calculate the insurance's payout and wait for the farmer's insurance to be stolen by some 13 y.o. hacker who was just reading up on how to write Ether smart contracts.
Now, we already have a way for binary oracles to work in Bitcoin: Signature or non-signature of a transaction with a key.
So your above scenario would be to have the insurer sign the transaction for payout.
Trust in third parties is necessary in any case, whether it is the weather feeds or the insurer. Multi-sig allows to spread that trust to a sufficient number of selected third parties.
And these third parties could be automated to a high degree! If you prefer a highly automated approach with a detailed, digital contract, they can just run that kind of contract and then publish the solution as the oracle's answer in the form of an ordinary transaction onto the BCH main chain.
All the details would happen completely off-chain.
This is also exactly why I do not see much value in Ether: The on-chain busywork that is seen been everyone is only of interest to a select few in the end. And those select few can choose any level of automation with any number of oracles and computational complexity (or, alternatively and depending on the use-case: good, old-fashioned human judgment) to make their contracts, and do that off-chain.
Ether shifts the trust to oracles resulting in a kind of psycho trick that has the futurist and singularity crowd chanting "see, you don't have to trust anyone anymore". Yet you do. You still have to trust the oracles.
EDIT: Now that I think about it, maybe automated, "true trustworthy computation services" would be a thing for BCH: Specify a contract and run it off-chain, and create
on-chain transactions corresponding to the results. Standardize the language and environment used so it is easy to select the third parties you want to trust.
Last edited:
KoKansei
Member
- Mar 5, 2016
- 49
- 360
This a bajillion times. Can I call this Bingledack's Law?
Also agree with this 100%. It is very heard for us to anticipate how exactly an emergent system like Bitcoin will develop, so it behooves us to provide very simple constituents for the market to work with.
As they say, six months is "an eternity in crypto." Speculation in crypto drives price more than most people would comfortably admit and ongoing "governance successes" (as perceived by the market) can also drive adoption. I agree that ultimately there may be many off-chain solutions that ultimately succeed, but if there is no harm, it may be wise to give the market a more flexible platform on which to work its magic.
Not really disagreeing, but I think one needs to be careful when identifying such cases. The above farmer example works already on BCH AFAICS.
Exactly my saying as well. While I am revisiting my thoughts on this, I think what one wants is just enough complexity on the Bitcoin script side of things that the entities providing services on top of Bitcoin can themselves build their contracts to then provide said services more smoothly.
Imagine the scenario above of "trustworthy computation services" (TCF).
Assume that the insurer and the farmer would agree to a highly detailed, complex, digital contract that involves neural networks and all kinds of bells and whistles. (The meta problem of trusting the contract implementation and implementers that Ethereum fights so badly and will fight in the future comes into play here as well, but let's assume it is still simple enough to be understood by all parties and so let's leave this other fundamental concern aside for a moment).
So they implement their contract on such TCFs. Assume that they agree to take the simple majority vote of a handful of TCFs that they contracted to execute their contract:
The contracting to execute the contract might have a little bit of complexity, and to not rely on "turtles all the way down", in other words, another third party that is contracted to judge on the contract, that kind of complexity needs to happen on chain.
So, for example, assuming one of the TCFs goes bankrupt and does not answer and publish their oracle anymore. Or, alternatively, takes too long to provide the answer. The on-chain contract should have provisions to deal with such a case, and Bitcoin Script enough expressive power to specify things like timeouts etc.
Another example would be that the TCFs do not agree on the outcome. The TCFs might want to punish the disagreeing minority as kind of a service-level-agreement and/or "quality seal" in their industry. Bitcoin script as-is would likely allow this as well (though I didn't do the math / details
Along similar lines: I actually think that LN, for better or worse, is another such example. It has dubious value on the customer end, but if you think about the problems involved on the LN service provider's side, the problems along the lines of "how do we make sure we're running LN smoothly" such as their penality systems etc. (which are complex already...) can only happen on-chain, as they fundamentally do not want to introduce a layer of trust beneath them. They might introduce themselves as a "slightly" trusted party (as some of us have argued), but LN would make even less sense if they'd start to dig themselves into´ "we trust on others to trust others" kind of "turtles all the way down" etheresque mind games and self-deception. As in that case, it would be clear as day that they are really just banks.
And I think the on-chain complexity of BCH should be raised only to the level to make the lives of such trusted providers to interact trustlessly with each other easier, not to create bells and whistles to put everything on chain.
Bitcoin provides just the trust anchors. Of course it needs to be capable enough for everyone to create such anchors freely (hence BCH, not BTC), and to build such anchors in all the various shapes and with all the various hooks that one might imagine are necessary for the products built using those anchors. But only anchors, not full boats (hence BCH, not ETH).
I think Vitalik Buterin either didn't understand this point when he built Ethereum, or he does but knows about the disease that is the love of complexity in large fractions of the nerd crowd and used that as the vehicle to get Eth marketed. I think he's young and smart but not wise yet, so it is likely the former. (And I suspect some of his backers might have been of the latter variant)
Yes, but with the above in mind. Complexity really is evil. All the stuff that is added to BCH needs to be supported for a damn long time. What would you say about building a TCF platform as an alternative to on-chain smart contracts for BCH?
KoKansei
Member
- Mar 5, 2016
- 49
- 360
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.
.
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.
Last edited:
@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.
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.
Last edited:
Latest threads
-
THE BEST CERTIFIED ETHICAL HACKER FOR HIRE IN USA HIRE ADWARE RECOVERY SPECIALIST
- LindaChristensen111
- 0 replies
-
HOW DIGITAL TECH GUARD RECOVERY PROTECTS YOUR DIGITAL ASSETS
- blackwellgretchen56
- 0 replies
-
ENSURING BITCOIN SAFETY WITH FUNDS RECLAIMER COMPANY EXPERT TEAM
- AliceKosh
- 0 replies
Members online
No members online now.