4 ms·

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

by 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.)

by rlucas 8y ago

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.)