Refactor: Public Script --> Public Announcement

[aszepieniec]

Neptune has three types of scripts:

• lock scripts, which capture the policy under which a UTXO can be spent;
• type scripts, which capture the evolution rules of state-carrying UTXOs;
• public scripts, which are attached to transactions as opposed to UTXOs.

The point of public scripts (as was understood at the time the white paper was written) is to mediate disputes. For instance, to close a lightning channel unilaterally, the closer needs to provide (by means of public script) cryptographic data that would allow the counterparty to contest the closure if it were malicious.

However, while data broadcasting is certainly a necessary feature, it is by no means clear that public computation is also. If it turns out that data boardcasting suffices, then we should drop the program part of the public scripts and rename the notion and structs to variants of "announcement" instead.

Questions:

1. How could lightning channels work, in more detail, assuming only public announcements are available and not public scripts?
2. Is there a meaningful more complex overlay protocol that requires public scripts and for which public announcements do not suffice?

[dan-da]

Is there a meaningful more complex overlay protocol that requires public scripts and for which public announcements do not suffice?

I'm not sure that question can be answered, as it may require predicting the future.

I would think though that if announcments is a string field of adequate length, then most any future script could be serialized into it.

If it turns out that data boardcasting suffices, then we should drop the program part of the public scripts and rename the notion and structs to variants of "announcement" instead.

Does this conclusion necessarily follow? What is the cost of keeping the computation aspect, even if not presently used? If there is little or no cost vs an announcements field and public_scripts is more future-proof, then an argument could be made to keep it.

[aszepieniec]

What is the cost of keeping the computation aspect, even if not presently used? If there is little or no cost vs an announcements field and public_scripts is more future-proof, then an argument could be made to keep it.

Public scripts are a denial of service vector. In contrast to type scripts and lock scripts, the user does not prove the script's correct execution. Miners (and more generally, anyone who maintains a mempool) need to execute it in order to determine if the transaction is valid. Even small programs can hide expansive complexity, so if they naïvel execute the script, it risks consuming all of their resources. Clever miners and mempool managers will limit the available resources and reject valid transactions whose public scripts exceed their bounds. This natural countermeasure undermines not just the point of public computation (as some valid transactions can still be rejected) but also the point of public service announcements (as some are rejected).

[aszepieniec]

I spent some thought on this question and my conclusion is that the computation aspect of public scripts can be entirely subsumed by type scripts, provided that their data broadcast aspect remains. Here is how it could work for Lightning channels.

To fund a channel, parties pay into a single UTXO with the following properties:

• the lock_script is a nop
• the coins dictionary contains 2 entries (k,v)
  1. where k is the hash of the native (or other) coin typescript and v is the total amount of paid-in capital
  2. where k is the hash of a special executor type script and v is the empty string.

Recall that a UTXO can only be spent if all lock scripts and all type scripts halt gracefully. The inputs to these programs is always the transaction kernel MAST hash. In particular, this input can be used to authenticate a nondeterministic guess about what the public announcement might entail and this information can activate a particular logic branch.

In the case of the Lightning channel UTXO, the lock script is a nop and so it trivially halts gracefully. The native (or other) coin type script halts gracefully if the amounts make sense (no inflation and all outputs are positive). The executor type script halts gracefully under one of several conditions:

1. Mutual close. Both parties sign off on the transaction. The script verifies two signatures on the kernel MAST hash.
2. Unilateral close with unresponsive peer. The script guesses and authenticates the public announcement and then (a) verifies A's signature (which is part of the public announcement) on the transaction kernel-without-announcements; (b) verifies B's signature on the balance of coins sent to A's control and B's control respectively; (c) verifies that the successor UTXO for A matches with a template that includes a timeout period and that guarantees that B is in possession of all information needed to dispute it in case the closed balance is not up-to-date.
3. Close due to interrupted Lightning transaction. The script guesses and authenticates the public announcement and then (a) verifies A's and B's signatures on the preimage puzzle and on the, (b) verifies that the puzzle solution contained in the public announcement constitutes a valid solution, (c) verifies that the successor UTXO for A matches with a template that includes a timeout period and that guarantees that B is in possession of all information needed to dispute it in case the closed balance is not up-to-date.

Based on this understanding, I will refactor public scripts into public announcements.