Closed aszepieniec closed 7 months ago
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.
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).
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:
lock_script
is a nopcoins
dictionary contains 2 entries (k,v)
k
is the hash of the native (or other) coin typescript and v
is the total amount of paid-in capitalk
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:
Based on this understanding, I will refactor public scripts into public announcements.
Neptune has three types of scripts:
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: