[Cryptography] Keeping Malware from Using Security Hardware

[Bill Stewart]

On 3/17/2025 9:55 AM, Ray Dillinger wrote:
> On 3/17/25 02:57, iang wrote:
>> If so, and please correct me if I'm misunderstanding, but I think 
>> there is an intervening step:
>>   4. The value X (of #1 and #3) is now /_in dispute_/.
>> That's because there are two possible final outcomes, simply put as:
>>   5.a Mallory is a crook and owes Alice X, and the transaction 3 is 
>> confirmed.
>>   5.b Mallory is a good guy, holds a valid contract for X, Alice has 
>> done bad, and the transaction 3 is revoked.
>> Both of those can be automatically validated by the blockchain in its 
>> verification phase. What can't be automatically determined easily in 
>> code is which of the two outcomes is the correct one.
>>
> True.  The whole thing is about dispute resolution, and that more or 
> less assumes that both parties take their claim to some court or 
> arbitrator whose authority they both accept.  

There were two classic cypherpunks approaches to this:
- For higher-value transactions with a well-defined way to verify 
compliance, an escrow service can approve the payment on completion or 
return it to the payer on non-completion. (Or, alternatively, can do a 
blow-out deal and abscond with everybody's escrowed money, of course.)

- For lower-value transactions, e.g. Bob ships Alice a baggie of oregano
or more likely doesn't actually ship anything,
Alice gives Bob a bad rating on SilkRoad Market,
and after a few bad ratings, nobody buys from Bob
(but they switch their business to "Dave", who is Bob in disguise),
and you hope that the market's transaction fees make it hard for bad 
guys to switch more often, in return for making it much much easier for 
sketchy guys to make more money from repeat business than absconding.

Neither one's super-reliable, but it worked well enough for Silk Road.