📅 Original date posted:2022-01-21
📝 Original message:On Fri, Jan 21, 2022 at 9:32 AM Billy Tetrud <billy.tetrud at gmail.com> wrote:
> > Bitcoin doesn't have a strong single concept of a 'parent'
>
> I'm using the term "parent" loosely in context here to mean a relationship
> where an input has constraints applied to an output (or outputs).
>
Yes and I'm using it more specifically to mean a single parent because the
tricks for implementing capabilities I'm talking about don't work if you
don't have a way of talking about 'my parent' as an unambiguously defined
single UTXO.
>
> > verify the secure hash chain from its parent to itself so that it
> knows what the parent looked like
>
> I guess I just don't understand why you would want to do it this way.
>
The idea here is to optimize for adding as little to the UXTO model as
possible and doing everything with Bitcoin script additions. Some optional
mappings of inputs to outputs in a transaction seem to be necessary but
beyond that the current model can remain unchanged.
> If you send to an address that has such a reverse-looking script, you
> could brick funds that came from the wrong parent. With the reverse
> mechanism, the transaction creating the child, you can prevent this from
> happening by defining the transaction creating such a child as invalid
> unless the child matches the covenant in the parent.
>
If you want to pay to a singleton you don't do it by paying to some
scriptpubkey which represents that singleton, you pay to a scriptpubkey
which says 'I can be spent in any transaction which includes singleton X'
and it does the validation of that other UTXO being the current incarnation
of the singleton using the capabilities validation tricks I mentioned
before.
>
> > "you can only point back so far" leads to transactions becoming invalid,
> which is something we've always strictly avoided because it can result in
> huge problems during reorgs
>
> I'm surprised to hear you say that. I have tried to learn why valid
> transactions that can become invalid is seen as such a problem. I've been
> unsuccessful in finding much information about this. I tried to document
> the full extent of my understanding in my proposal here
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#reorg-safety>; where
> I actually have a quote from you where you said you don't think this is a
> valid concern. Did something change your mind? Or did I misinterpret you?
> What am I missing from that section I linked to?
>
It can be made so that if it goes past the time when the backpointer works
then the transaction is still valid but its vbytes goes up because the
referenced string needs to be repeated on the chain.
I too am a bit on the fence about whether strict transaction
monotinicity is absolutely necessary. The most plausible violation of it to
add would be some kind of max height/age condition to go with the current
min height/age restrictions. What scares me about that isn't so much the
ability to replay reorgs getting messed up (those can be derailed by double
spends anyway) but that either an intentional DOS or just a spike in
transaction fees could cause a deadline to be passed and something to be
bricked for completely technical reasons having nothing to do with its
intended logic. The same type of functionality can be hacked by having an
allowed spend whose only condition is a min height/age so that if the time
has passed as long as someone isn't asleep at the wheel the transaction
will switch to a new state which disallows whatever it is that was supposed
to be disallowed at that time.
Since there isn't any compelling bit of functionality which needs to
violate monotinicity to be implemented I don't see any need to call for an
end to it as a principle. It certainly makes mempool logic a lot simpler
and more reliable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220121/84c724d7/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 23:02:29
in reply to nevent1q…xnxw
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 23:02:29Event JSON
{
"id": "d87a14dc9df33c0c0ccb743c26b8415de69e22334855d4a5754f7167bf2a09b5",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686178949,
"kind": 1,
"tags": [
[
"e",
"b885bce1123fefabbd84ad0100dc6003ebaae7fc96e346098557cee9e5366a76",
"",
"root"
],
[
"e",
"ef5055c964970c30095a59044b7de2abfacd4ef6b5e687b123b9033c4df16ec0",
"",
"reply"
],
[
"p",
"3030ec2d70259fdd55ba8e063740c139c3daaa618f86e3fae34cebcb73c742ba"
]
],
"content": "📅 Original date posted:2022-01-21\n📝 Original message:On Fri, Jan 21, 2022 at 9:32 AM Billy Tetrud \u003cbilly.tetrud at gmail.com\u003e wrote:\n\n\u003e \u003e Bitcoin doesn't have a strong single concept of a 'parent'\n\u003e\n\u003e I'm using the term \"parent\" loosely in context here to mean a relationship\n\u003e where an input has constraints applied to an output (or outputs).\n\u003e\n\nYes and I'm using it more specifically to mean a single parent because the\ntricks for implementing capabilities I'm talking about don't work if you\ndon't have a way of talking about 'my parent' as an unambiguously defined\nsingle UTXO.\n\n\n\u003e\n\u003e \u003e verify the secure hash chain from its parent to itself so that it\n\u003e knows what the parent looked like\n\u003e\n\u003e I guess I just don't understand why you would want to do it this way.\n\u003e\n\nThe idea here is to optimize for adding as little to the UXTO model as\npossible and doing everything with Bitcoin script additions. Some optional\nmappings of inputs to outputs in a transaction seem to be necessary but\nbeyond that the current model can remain unchanged.\n\n\n\u003e If you send to an address that has such a reverse-looking script, you\n\u003e could brick funds that came from the wrong parent. With the reverse\n\u003e mechanism, the transaction creating the child, you can prevent this from\n\u003e happening by defining the transaction creating such a child as invalid\n\u003e unless the child matches the covenant in the parent.\n\u003e\n\nIf you want to pay to a singleton you don't do it by paying to some\nscriptpubkey which represents that singleton, you pay to a scriptpubkey\nwhich says 'I can be spent in any transaction which includes singleton X'\nand it does the validation of that other UTXO being the current incarnation\nof the singleton using the capabilities validation tricks I mentioned\nbefore.\n\n\n\u003e\n\u003e \u003e \"you can only point back so far\" leads to transactions becoming invalid,\n\u003e which is something we've always strictly avoided because it can result in\n\u003e huge problems during reorgs\n\u003e\n\u003e I'm surprised to hear you say that. I have tried to learn why valid\n\u003e transactions that can become invalid is seen as such a problem. I've been\n\u003e unsuccessful in finding much information about this. I tried to document\n\u003e the full extent of my understanding in my proposal here\n\u003e \u003chttps://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#reorg-safety\u003e where\n\u003e I actually have a quote from you where you said you don't think this is a\n\u003e valid concern. Did something change your mind? Or did I misinterpret you?\n\u003e What am I missing from that section I linked to?\n\u003e\n\nIt can be made so that if it goes past the time when the backpointer works\nthen the transaction is still valid but its vbytes goes up because the\nreferenced string needs to be repeated on the chain.\n\nI too am a bit on the fence about whether strict transaction\nmonotinicity is absolutely necessary. The most plausible violation of it to\nadd would be some kind of max height/age condition to go with the current\nmin height/age restrictions. What scares me about that isn't so much the\nability to replay reorgs getting messed up (those can be derailed by double\nspends anyway) but that either an intentional DOS or just a spike in\ntransaction fees could cause a deadline to be passed and something to be\nbricked for completely technical reasons having nothing to do with its\nintended logic. The same type of functionality can be hacked by having an\nallowed spend whose only condition is a min height/age so that if the time\nhas passed as long as someone isn't asleep at the wheel the transaction\nwill switch to a new state which disallows whatever it is that was supposed\nto be disallowed at that time.\n\nSince there isn't any compelling bit of functionality which needs to\nviolate monotinicity to be implemented I don't see any need to call for an\nend to it as a principle. It certainly makes mempool logic a lot simpler\nand more reliable.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220121/84c724d7/attachment.html\u003e",
"sig": "3cf287c3fd400d9a2ffb137e41d41b85060ee2b68e593dd865607fac3098bdfac94688ba478db1bf50ffe5caf7355074a4875f7644186e99b75ac768190f65c2"
}