On Thu, Feb 17, 2022 at 9:27 AM Anthony Towns wrote:
>
> I guess that's all partly dependent on thinking that, TXHASH isn't
> great for tx introspection (especially without CAT) and, (without tx
> introspection and decent math opcodes), DLCs already provide all the
> interesting oracle behaviour
On Mon, Feb 07, 2022 at 09:16:10PM -0500, Russell O'Connor via bitcoin-dev
wrote:
> > > For more complex interactions, I was imagining combining this TXHASH
> > > proposal with CAT and/or rolling SHA256 opcodes.
> Indeed, and we really want something that can be programmed at redemption
> time.
On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell
wrote:
> Jeremy Rubin writes:
> > Hi Rusty,
> >
> > Please see my post in the other email thread
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
> >
> > The differences in this regard are several, and worth
Jeremy Rubin writes:
> Hi Rusty,
>
> Please see my post in the other email thread
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
>
> The differences in this regard are several, and worth understanding beyond
> "you can iterate CTV". I'd note a few clear
On Tue, Feb 15, 2022 at 1:57 PM Jeremy Rubin
wrote:
> Hi Rusty,
>
> Please see my post in the other email thread
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
>
> The differences in this regard are several, and worth understanding beyond
> "you can iterate
Hi Rusty,
Please see my post in the other email thread
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
The differences in this regard are several, and worth understanding beyond
"you can iterate CTV". I'd note a few clear examples for showing that "CTV
is just
Jeremy Rubin writes:
> Rusty,
>
> Note that this sort of design introduces recursive covenants similarly to
> how I described above.
>
> Whether that is an issue or not precluding this sort of design or not, I
> defer to others.
Good point!
But I think it's a distinction without meaning: AFAICT
Rusty,
Note that this sort of design introduces recursive covenants similarly to
how I described above.
Whether that is an issue or not precluding this sort of design or not, I
defer to others.
Best,
Jeremy
On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev <
Russell O'Connor via bitcoin-dev writes:
> Given the overlap in functionality between CTV and ANYPREVOUT, I think it
> makes sense to decompose their operations into their constituent pieces and
> reassemble their behaviour programmatically. To this end, I'd like to
> instead propose OP_TXHASH
On Mon, Jan 31, 2022 at 8:16 PM Anthony Towns wrote:
> On Fri, Jan 28, 2022 at 08:56:25AM -0500, Russell O'Connor via bitcoin-dev
> wrote:
> > >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> > For more complex interactions, I was imagining combining this
On Thu, Jan 27, 2022 at 07:18:54PM -0500, James O'Beirne via bitcoin-dev wrote:
> > I don't think implementing a CTV opcode that we expect to largely be
> > obsoleted by a TXHASH at a later date is yielding good value from a soft
> > fork process.
> Caching for something
> like TXHASH looks to me
The hash would normally also cover the hash flags in use, and would be
different in those two cases.
But yes, it seems at the last minute I did include a suggestion to disable
covering the flag themselves in the hash and appear to have accidentally
allowed for recursive covenants (a common
Perhaps there is some misunderstanding. TXHASH + CSFSV doesn't allow for
complex or recursive covenants. Typically CAT is needed, at minimum, to
create those sorts of things. TXHASH still amounts to deploying a
non-recursive covenant construction.
This seems false to me.
txhash txhash
On Fri, Jan 28, 2022 at 10:14 AM James O'Beirne
wrote:
> > Technical debt isn't a measure of weight of transactions.
>
> Sorry, my original sentence was a little unclear. I meant to say that the
> notion that CTV is just a subpar waypoint en route to a more general
> covenant system may not be
I probably need to reset it -- I ran into some issues with the IBD latch
bug IIRC and had difficulty producing new blocks.
I sent funds as a manual faucet to at least one person... not aware of
anyone else finding use for the signet. In part this is due to the fact
that in order to run a signet,
> Technical debt isn't a measure of weight of transactions.
Sorry, my original sentence was a little unclear. I meant to say that the
notion that CTV is just a subpar waypoint en route to a more general
covenant system may not be accurate if it is a more efficient way (in terms
of
On Fri, Jan 28, 2022 at 01:14:07PM +, Michael Folkson via bitcoin-dev wrote:
> There is not even a custom signet with CTV (as far as I know)
https://twitter.com/jeremyrubin/status/1339699281192656897
signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne
wrote:
> > I don't think implementing a CTV opcode that we expect to largely be
> obsoleted by a TXHASH at a later date is yielding good value from a soft
> fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it).
>
On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns wrote:
> > An Alternative Proposal::
> > ...
>
> > For similar reasons, TXHASH is not amenable to extending the set of
> txflags
> > at a later date.
>
> > I believe the difficulties with upgrading TXHASH can be mitigated by
> > designing a robust
> Even if we were to adopt something like TXHASH, how long is it going to take
> to develop, test, and release? My guess is "a while" - in the meantime, users
> of Bitcoin are without a vault strategy that doesn't require either
> presigning transactions with ephemeral keys (operationally
> I don't think implementing a CTV opcode that we expect to largely be
obsoleted by a TXHASH at a later date is yielding good value from a soft
fork process.
This presumes the eventual adoption of TXHASH (or something like it).
You're presenting a novel idea that, as far as I know, hasn't had
On Wed, Jan 26, 2022 at 12:20:10PM -0500, Russell O'Connor via bitcoin-dev
wrote:
> Recapping the relationship between CTV and ANYPREVOUT::
> While this is a pretty neat feature,
> something that ANYPREVOUT cannot mimic, the main application for it is
> listed as using congestion control to fund
I am sensitive to technical debt and soft fork processes, and I don't
believe I'm unordinary particular about these issues. Once implemented,
opcodes must be supported and maintained indefinitely. Some opcodes are
easier to maintain than others. These particular opcodes involve caching
of hash
What if OP_TXHASH is a no op except for the purpose of emulating CTV and
APO?
On Wed, Jan 26, 2022 at 5:16 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Russell,
>
> Thanks for this email, it's great to see this approach described.
>
> A few preliminary notes of
Hi Russell,
Thanks for this email, it's great to see this approach described.
A few preliminary notes of feedback:
1) a Verify approach can be made to work for OP_TXHASH (even with CTV
as-is) E.g., suppose a semantic added for a single byte stack[-1] sighash
flag to read the hash at stack[-2],
Recapping the relationship between CTV and ANYPREVOUT::
It is known that there is a significant amount of overlap in the
applications that are enabled by the CTV and ANYPREVOUT proposals despite
the fact that their primary applications (congestion control for CTV and
eltoo lightning channels for
26 matches
Mail list logo
