From: Billy Tetrud <billy.tetrud@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Bram Cohen <bram@chia•net>
Subject: Re: [bitcoin-dev] Covenants and capabilities in the UTXO model
Date: Fri, 21 Jan 2022 11:32:27 -0600 [thread overview]
Message-ID: <CAGpPWDYOJFkOdzkoq6XMB0Z9SEEP4nmdmcZDEZckWQL+BzPOZw@mail.gmail.com> (raw)
In-Reply-To: <YeoY12X1skxA8Lcy@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2817 bytes --]
> 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).
> 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. 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.
> "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?
On Thu, Jan 20, 2022 at 8:22 PM Peter Todd <pete@petertodd•org> wrote:
> On Thu, Jan 20, 2022 at 11:23:30AM -0800, Bram Cohen via bitcoin-dev wrote:
> > > 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.
>
> "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 with transactions being unable to be included in a
> new
> change. That's exactly why transaction expiry proposals have been shot down
> over and over again.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
[-- Attachment #2: Type: text/html, Size: 3613 bytes --]
next prev parent reply other threads:[~2022-01-21 17:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-31 23:22 Bram Cohen
2022-01-18 15:10 ` Billy Tetrud
2022-01-18 17:16 ` Bram Cohen
2022-01-19 2:24 ` Billy Tetrud
2022-01-20 19:23 ` Bram Cohen
2022-01-21 2:22 ` Peter Todd
2022-01-21 17:32 ` Billy Tetrud [this message]
2022-01-22 0:19 ` Bram Cohen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGpPWDYOJFkOdzkoq6XMB0Z9SEEP4nmdmcZDEZckWQL+BzPOZw@mail.gmail.com \
--to=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bram@chia$(echo .)net \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox