[Cryptography] Keeping Malware from Using Security Hardware

[iang]

Hi Bear!

On 16/03/2025 21:57, Ray Dillinger wrote:

> On 3/5/25 16:56, Jon Callas wrote:
>
>> The comments you made on the DPRK heist are spot on, and I only add one thing. It's a feature of cryptocurrency that a transfer is irrevocable. Some people think it's desirable, some think it's undesirable, some think it's just the way things are, and a core facet of that heist is that it happened on a financial network with irrevocable transactions because that was a necessary component of the heist.
>
> It's a fundamental design flaw.
>
> Systems based on an append-only ledger cannot revoke a transaction
> without revoking all subsequent transactions, and cannot make a reversal
> transaction without introducing a representation for debt. And debt
> cannot be represented in an anonymous or pseudonymous system.  If you
> give someone the key to a txOut representing a negative amount of coins,
> but nobody can ever know who it is, they will simply never "spend" those
> negative coins.

I mostly agree. I think what you are saying is this:

1. Alice pays Mallory X.

2. Alice decides Mallory has stolen from her.

3. Alice therefore pays Mallory -X.

Those 2 transactions are sitting on the append only log and balance out (depending on how the verification phase of the center is conducted).

Then, your interpretation of the outcome is:

5! Mallory now has a debt with Alice for X?

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.

This is a job for dispute resolution. In real life world we do it mostly with courts.

Dispute resolution is clunky, and courts reflect that. There are alternatives, such as arbitration. One interesting thing about arbitration is that it is possible to set up a custom built system. Ie one built for a narrow context.

In the blockchain known as EOS, we did that. Created arbitration as dispute resolution as a first tier institution. Technically it worked, and issued some very few resolution orders (known as awards).

Politically it failed, as the blockchain world preferred instant and unrevocable transactions - not your keys, not your coins was the refrain. So the block producers changed the constitution to remove the clause to refer disputes to arbitration. End.

The point of this is that it is possible to do so - and going back to your other email, I would say the proof is in the pudding of court. Will the nymous identities stand up in court, reveal themselves and allow a fair trial of the facts? If so, then perhaps the nymous idea can survive, with the notable exception of court. Debts can emerge and be handled by the normal contract method.

If not, then no, and no sane person would trust it, nor allow debt to build up.

> I think the irrevocable append-only ledger is a good idea, but reversal
> transactions are necessary, and therefore a way to represent debt is
> necessary, and therefore a way to access user identity (or at least link
> other assets held by the same human user) is necessary.
>
> Bear

In short (and this was the literal analysis of EOS, being a blockchain for business) my claim is that you cannot do business unless you can hold the counterparty to account for eg debts incurred unfairly. And the test of that is - how do you take someone to dispute resolution?

And technically, that means being able to halt transactions, pending resolution. So I concur, lack of disputable transactions is a design flaw, if you're intending the chain to do business.

(And if not business, what use is it? Memes?)

iang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20250317/6d1a90f2/attachment.htm>