Salvatore Ingala [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-10 📝 Original message:Hi ZmnSCPxj, Bram, Peter, ...

📅 Original date posted:2022-11-10
📝 Original message:Hi ZmnSCPxj, Bram, Peter, David,

Thanks for all your comments; replies below.

On Tue, 8 Nov 2022 at 13:01, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Modulo bugs, operator error, misconfigurations, and other irrationalities
> of humans.
>

I agree that making footguns impossible is a much more difficult problem to
solve!

Rather than get taptree from the stack, just use the same taptree as in the
> revelation of the P2TR.
> This removes the need to include quining and similar techniques: just do
> the quining in the SCRIPT interpreter.
>

That's a possibility; I suspect it would be less efficient for many
contracts (in particular, when the total number of states in the FSM is
relatively large, but each of them has only few valid transitions). We
could always allow both variants.

Another reason I preferred to present it in this way is to show that it is
possible to limit the design to covenants where recursion is not allowed /
limited; I don't personally think recursion is bad at this time − but the
covenants (and the protocol for fraud challenges) do not require it in
order to be useful.

Anyway, I suggested some opcodes only as a sketch. I'm not knowledgeable
enough to suggest the best design, and maybe it will be easier to compare
several variants once we implement something on top.


On Wed, 9 Nov 2022 at 00:34, Bram Cohen <bram at chia.net> wrote:

> Hash chained covenants in general all have about the same plateau of
> functionality, which seems roughly reasonable to add to Bitcoin as it is
> today but suffer from being limited and hence likely only a stepping stone
> to greater functionality and unless whatever's put in now cleanly extends
> to supporting more in the future it's likely to turn into a legacy
> appendage which has to be supported. So my generic suggestion for this sort
> of thing is that it should be proposed along with a plan for how it could
> be extended to support full-blown covenants in the future.
>

I actually struggle to find constructions that are _not_ possible using
such covenants; do you have any concrete example?
That would be very interesting in order to correctly classify the
expressive power of UTXO+Script+covenants when compared to the
"Turing-complete"+stateful models.

Another probably unhelpful bit of feedback I have is that Bitcoin should
> probably be taking verkle trees seriously because those can have
> substantially lower size/cost/weight than merkle trees. That doesn't just
> apply to this proposal, but to Bitcoin in general, which doesn't seem to
> have any serious verkle tree proposals to date.
>

I am not an expert in Verkle trees, but I think the efficiency gain (if
any) is not that interesting for many of the applications I'm suggesting,
as most Merkle trees would be quite small.
Therefore, I agree with Peter that the additional complexity might not be
worth it at this time; if applications requiring large Merkle trees arise
in practice, Verkle trees could always be added in the future as an
optimization.

Moreover, Verkle trees, or even any risky/fancy cryptography, could be used
in layer-2 solutions enabled by the covenant, without impacting any funds
not locked in the covenant in case of disasters.


On Wed, 9 Nov 2022 at 13:07, Peter Todd <pete at petertodd.org> wrote:

> Particularly since even having merkle trees in Bitcoin
> is arguably a mistake: they allow for degenerate, weak, security modes
> like SPV
> that aren't clearly good for Bitcoin as a whole.
>

I disagree, as the title of this thread suggests! :)
Thanks to Merkle trees, we'll be able to keep layer 1 extremely light, so
everyone can run a full node − while all the complexity of fancy
constructions is pushed to the application layer.


On Thu, 10 Nov 2022 at 08:39, David A. Harding <dave at dtrt.org> wrote:

> > 1. Alice posts the statement “f(x) = y”.
> > 2. After a challenge period, if no challenge occurs, Alice is free to
> > continue and unlock the funds; the statement is true.
> > 3. At any time before the challenge period expires, Bob can start a
> > challenge: “actually, f(x) = z”.
>
> That looks to me very similar to Gregory Maxwell's script from[1]
>

Zero-Knowledge contingent payments do indeed solve the problem more
elegantly in the specific case where swapping Alice's knowledge for x with
a payment from Bob is the entire smart contract.

The covenant adds the ability to carry over some sort of state. For
example, imagine Alice and Bob want to play a game of chess, and the winner
takes all the money [*]. The "state" in the covenant would be the entire
chessboard, and a valid transition is a valid chess move. The covenant
enforces that the game proceeds according to the rules, by only allowing
correct updates to the "state".
Moreover, the parties participating to a covenant don't necessarily need to
be decided in advance, which is crucial for constructions like coinpool [1].

Note that no this does not require any fraud proof, as the rules of chess
are simple enough that each "transition" is a simple enough function. In
fact, many contracts might not require fraud proofs at all.

The point of the chapter on fraud proof is to prove that full generality in
expressive power (that is: any state transition you can think of) is
possible, as whenever a complex transition is required − one could instead
replace it with the optimistic protocol (Alice makes a claim,
counterparties can challenge if the claim is wrong). That allows to remove
any expensive computation from hitting the blockchain.

A particularly interesting example might be rollups (and similar
constructions). There, the 'state' represents a separate ledger, and a
transition takes the secondary ledger from a valid state to another valid
state, using a zero-knowledge proof. In validity rollups [2], the chain is
required to actually check the validity proof, which is a very expensive
operation (plus, the state-of-the-art requires additional cryptographic
assumptions in layer 1, as far as I understand). The covenant would allow
us[**] to implement optimistic rollups, where the rollup operator just
posts the new state and the proof, and other parties have time to challenge
it if the proof is wrong.

I hope this clarifies the role of fraud proofs in the construction.

Best,
Salvatore


[*] - I'm not suggesting using the bitcoin blockchain to play chess games,
but it is a convenient academic example :)
[**] - Pending someone more expert to double check that nothing is missing!

[1] - https://coinpool.dev
[2] - https://bitcoinrollups.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221110/34d9b720/attachment-0001.html>;