3 ms·

> Trust is a new software primitive from which other components can be constructed. This kind of talk is extremely misleading. At the end of the day, we're sti

> Trust is a new software primitive from which other components can be constructed. This kind of talk is extremely misleading. At the end of the day, we're still people buying and selling goods and services from other people. The most blockchain can do is remove some types of middle-men (financial or otherwise), but the endpoints will always be human. Trust between humans will always be a requirement to buy and sell goods and services. Just like chatting with someone over an encrypted channel can't make you trust the person you're chatting with, only the channel itself. Perhaps blockchain's "killer app" is an automated escrow service. How exciting... :-/

rlucas 8y ago
It is not strictly true that endpoints and the locus of trust always have humans in the loop. (Where they do, of course, I agree that blockchain has much more limited "fit" as a solution.) However, in what I call "network-native resource transactions," namely, where the provision of the thing of value is computational and can be verified on the network (think: storage, compute, bandwidth, namespace resources like DNS), there are a large number of transactions where the performance of the counterparty can be shown with math. In those cases, of network-native resource transactions, the transaction itself can be the locus of trust, and the payment / settlement becomes the weak link. For this (admittedly somewhat narrow) set of uses, then, blockchain is really really useful because the payment / settlement trust problem can be done away with deterministically provided the resource transaction is verified.
- TimTheTinker 8y ago
  When would this be any more useful than having a credit card on file with whoever is providing the resource? ...or am I completely misunderstanding what you mean by “payment/settlement”?
  - rlucas 8y ago
    I think "payment/settlement" here is clear, but not the link to network-native resources. Let's imagine you have an auto-scaling application. You hit a big spike (like several orders of magnitude) and have the (cryptocurrency) resources to keep it running. Traditional vendors on invoice (or on credit card) would likely be loathe to just approve your monthly spend going from $500 to $500,000. You'd probably hit an interruption in service as the vendors protect themselves and underwrite to a higher credit limit. Having non-repudiable smart contracts that get the vendors paid automatically once the resources are verifiably transacted would eliminate that friction. (Plus, chargebacks, interchange, etc.) On the extreme other end of the scale, if your resource transactions were small and highly distributed, it would get very cumbersome and costly to verify and pay $500,000 in $1 increments. (Plus chargebacks, etc.) My point here is not the traditional one about credit card fees and frictions, though. It's specifically about the locus of trust. If you sell me an electric guitar on eBay, there are two big trust gaps: one is about me actually getting the guitar as described, and the other is you getting the money. The fact that the "money" happens to be transacted as bitcoin or whatever doesn't change the need for trust at the ends of the physical transaction. But if you are transacting network-native resources, smart contracts let you connect the payment settlement to the resource itself. Factor the primes out of this number and you get BTC 1.00. Transit these packets and you get so many ETH. It's because the resources exist on the same network in approximately real-time with the payment ledger that they can be verified automatically. Doesn't work for most kinds of commerce where verifying that the transaction is settled is a non-computational operation. (Are the goods arrived, merchantable and fit, as described, etc. etc. -- always you will need to be putting your locus of trust out in the physical world with reputational ties, personal trust, escrow agents, brokers / dealers, etc.)

rlucas 8y ago

It is not strictly true that endpoints and the locus of trust always have humans in the loop. (Where they do, of course, I agree that blockchain has much more limited "fit" as a solution.) However, in what I call "network-native resource transactions," namely, where the provision of the thing of value is computational and can be verified on the network (think: storage, compute, bandwidth, namespace resources like DNS), there are a large number of transactions where the performance of the counterparty can be shown with math. In those cases, of network-native resource transactions, the transaction itself can be the locus of trust, and the payment / settlement becomes the weak link. For this (admittedly somewhat narrow) set of uses, then, blockchain is really really useful because the payment / settlement trust problem can be done away with deterministically provided the resource transaction is verified.

TimTheTinker 8y ago
When would this be any more useful than having a credit card on file with whoever is providing the resource? ...or am I completely misunderstanding what you mean by “payment/settlement”?
- rlucas 8y ago
  I think "payment/settlement" here is clear, but not the link to network-native resources. Let's imagine you have an auto-scaling application. You hit a big spike (like several orders of magnitude) and have the (cryptocurrency) resources to keep it running. Traditional vendors on invoice (or on credit card) would likely be loathe to just approve your monthly spend going from $500 to $500,000. You'd probably hit an interruption in service as the vendors protect themselves and underwrite to a higher credit limit. Having non-repudiable smart contracts that get the vendors paid automatically once the resources are verifiably transacted would eliminate that friction. (Plus, chargebacks, interchange, etc.) On the extreme other end of the scale, if your resource transactions were small and highly distributed, it would get very cumbersome and costly to verify and pay $500,000 in $1 increments. (Plus chargebacks, etc.) My point here is not the traditional one about credit card fees and frictions, though. It's specifically about the locus of trust. If you sell me an electric guitar on eBay, there are two big trust gaps: one is about me actually getting the guitar as described, and the other is you getting the money. The fact that the "money" happens to be transacted as bitcoin or whatever doesn't change the need for trust at the ends of the physical transaction. But if you are transacting network-native resources, smart contracts let you connect the payment settlement to the resource itself. Factor the primes out of this number and you get BTC 1.00. Transit these packets and you get so many ETH. It's because the resources exist on the same network in approximately real-time with the payment ledger that they can be verified automatically. Doesn't work for most kinds of commerce where verifying that the transaction is settled is a non-computational operation. (Are the goods arrived, merchantable and fit, as described, etc. etc. -- always you will need to be putting your locus of trust out in the physical world with reputational ties, personal trust, escrow agents, brokers / dealers, etc.)