<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Bear!<br>
</p>
<div class="moz-cite-prefix">On 16/03/2025 21:57, Ray Dillinger
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fcdcbff8-37ff-4543-995f-d9b609a44993@sonic.net">
<pre wrap="" class="moz-quote-pre">
On 3/5/25 16:56, Jon Callas wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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.</pre>
</blockquote>
<p><br>
</p>
<p>I mostly agree. I think what you are saying is this:</p>
<p> 1. Alice pays Mallory X.</p>
<p> 2. Alice decides Mallory has stolen from her.</p>
<p> 3. Alice therefore pays Mallory -X.</p>
<p>Those 2 transactions are sitting on the append only log and
balance out (depending on how the verification phase of the center
is conducted).</p>
<p>Then, your interpretation of the outcome is:</p>
<p> 5! Mallory now has a debt with Alice for X?</p>
<p><br>
</p>
<p><br>
</p>
<p>If so, and please correct me if I'm misunderstanding, but I think
there is an intervening step:</p>
<p> 4. The value X (of #1 and #3) is now <i>_in dispute_</i>.</p>
<p>That's because there are two possible final outcomes, simply put
as:</p>
<p> 5.a Mallory is a crook and owes Alice X, and the transaction 3
is confirmed.</p>
<p> 5.b Mallory is a good guy, holds a valid contract for X, Alice
has done bad, and the transaction 3 is revoked.<br>
</p>
<p>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.</p>
<p><br>
</p>
<p><br>
</p>
<p>This is a job for dispute resolution. In real life world we do it
mostly with courts.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p><br>
</p>
<p><br>
</p>
<p>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.<br>
</p>
<p>If not, then no, and no sane person would trust it, nor allow
debt to build up.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:fcdcbff8-37ff-4543-995f-d9b609a44993@sonic.net">
<pre wrap="" class="moz-quote-pre">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
</pre>
</blockquote>
<p><br>
</p>
<p>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?</p>
<p>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.</p>
<p>(And if not business, what use is it? Memes?)<br>
</p>
<p><br>
</p>
<p>iang<br>
</p>
</body>
</html>