Bram Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2022-01-20 📝 Original message:On Tue, Jan 18, 2022 at ...
📅 Original date posted:2022-01-20
📝 Original message:On Tue, Jan 18, 2022 at 6:25 PM Billy Tetrud <billy.tetrud at gmail.com> wrote:
> > 'assert that my parent has a scriptpubkey of X'... That way you can, for
> example, have a UTXO which only allows itself to be absorbed by a
> transaction also involving a UTXO with a particular capability
>
> I'm not sure I fully follow. I usually think about covenants as having the
> reverse form, that a parent would assert "my children must have a script of
> the form XYZ". Are you saying you want to be able to specify that a UTXO
> can only be spent if the resulting outputs of that transaction all share
> the same script? I see this page
> <https://chialisp.com/docs/puzzles/singletons/>; but i don't understand
> how those concepts relate to covenants.
>
Two concepts here. First of all Bitcoin doesn't have a strong single
concept of a 'parent', it just has transactions where all the parents lead
to all the children. For this sort of trickery to work more information
needs to be added to specify which of the inputs is the parent of each of
the outputs.
Second what in practice happens is that a coin can check what its own id
is, then verify the secure hash chain from its parent to itself so that it
knows what the parent looked like. For a Singleton it can then rely on the
fact that its ancestors enforced that they each only had one child to know
that it's the only descendant. In some sense this is like covenants which
point backwards in time although that information is already there in
principle because of the secure hash chain but hard to parse.
>
> > allow references to old blocks so code snippets can be pulled out of
> them
>
> Nodes currently aren't required to keep around the whole blockchain, but
> your proposal sounds like it would require them to. I think this could be
> pretty detrimental to future scalability. Monero, for example, has a
> situation where its UTXO set is the whole blockchain because you can't
> generally know what has been spent and what hasn't been. Allowing
> references to old blocks would pull in all this old block data into the
> UTXO set. So unless you're very careful about how or when you can reference
> old blocks, this could cause issues.
>
Don't full nodes by definition have to have the whole chain? This does make
pruned nodes difficult, but it could also have rules like you can only
point back so far.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220120/a3cb9768/attachment.html>;
📝 Original message:On Tue, Jan 18, 2022 at 6:25 PM Billy Tetrud <billy.tetrud at gmail.com> wrote:
> > 'assert that my parent has a scriptpubkey of X'... That way you can, for
> example, have a UTXO which only allows itself to be absorbed by a
> transaction also involving a UTXO with a particular capability
>
> I'm not sure I fully follow. I usually think about covenants as having the
> reverse form, that a parent would assert "my children must have a script of
> the form XYZ". Are you saying you want to be able to specify that a UTXO
> can only be spent if the resulting outputs of that transaction all share
> the same script? I see this page
> <https://chialisp.com/docs/puzzles/singletons/>; but i don't understand
> how those concepts relate to covenants.
>
Two concepts here. First of all Bitcoin doesn't have a strong single
concept of a 'parent', it just has transactions where all the parents lead
to all the children. For this sort of trickery to work more information
needs to be added to specify which of the inputs is the parent of each of
the outputs.
Second what in practice happens is that a coin can check what its own id
is, then verify the secure hash chain from its parent to itself so that it
knows what the parent looked like. For a Singleton it can then rely on the
fact that its ancestors enforced that they each only had one child to know
that it's the only descendant. In some sense this is like covenants which
point backwards in time although that information is already there in
principle because of the secure hash chain but hard to parse.
>
> > allow references to old blocks so code snippets can be pulled out of
> them
>
> Nodes currently aren't required to keep around the whole blockchain, but
> your proposal sounds like it would require them to. I think this could be
> pretty detrimental to future scalability. Monero, for example, has a
> situation where its UTXO set is the whole blockchain because you can't
> generally know what has been spent and what hasn't been. Allowing
> references to old blocks would pull in all this old block data into the
> UTXO set. So unless you're very careful about how or when you can reference
> old blocks, this could cause issues.
>
Don't full nodes by definition have to have the whole chain? This does make
pruned nodes difficult, but it could also have rules like you can only
point back so far.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220120/a3cb9768/attachment.html>;