Thanks Darosior for your response.
I see now that APOAS (e.g. with ANYONECANPAY and/or SINGLE) and CTV (with less
restrictive templates) fall prey to the same trade-off between flexibility and
safety. So I retract my statement about that 'point in favour of OP_CTV'. It
would be nice to by-pass
Antoine,
One high level reason to not prefer APO is that it gets 'dangerously close'
to fully recursive covenants.
E.g., just by tweaking APO to use a Schnorr signature without PK
commitment, Pubkey Recovery would be possible, and fully recursive
covenants could be done.
Short of that type of mo
Hi Jacob,
I think you are a bit confused about how CTV and (tweaked) APO covenants
compare. Both would commit to the
same template, so one isn't "safer" than the other. Just more efficient in how
it commits to the template.
Replies on the specifics inline.
> While I agree with the arguments in
> If a QC is able overnight to spend a large fraction of the supply, your
coins in your super non-QC vulnerable-bare-CTV-covenant (that would
eventually become vulnerable when trying to use it) are worthless.[1]
I know this has been debated to death, but I really don't think this
argument is ver
> via `sha_sequences`
Since you cannot expect txid stability with >1 inputs either way[0], it
should be sufficient to commit just to the current input's
nSequence/scriptSig to get txid stability for single input transactions. I
chatted with Jeremy about this and he appears to agree.
Not committin
The proposed use case for the ANYSCRIPT part of APOAS explicitly doesn't
commit to amount, so I'd also assume it not be re-added or at least be able
to be opened out.
On Sat, Apr 30, 2022, 4:47 AM Nadav Ivgi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi darosior,
>
> It's i
Hi darosior,
It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY behaviour
and without covering the spent input index) has some interesting uses for
cases where the covenant only needs to restrict a single output (so useful
for e.g. vaults or spacechains, but not for batch channels o
Hi,
While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS in
lieu of CTV in the short-term (given the additional benefit of enabling Eltoo),
there's a point to add in favour of CTV (or similar) in the long-term beyond as
an optimisation.
With APOAS-based covenants, the si
Correction: thinking about this some more, you can't actually expect to
have a stable txid if you allow additional inputs at all...
So yes, amending BIP 118 to commit to sha_sequences (which indirectly also
commits to the number of inputs) as proposed in the OP should be sufficient
to get stable t
> This is *literally* what the post you are replying to is proposing to
solve.
I thought the changes mentioned in the OP (+ committing to the spent input
index) only solves the half-spend problem, but not the stable txids one?
There can be other inputs with a scriptSig, which doesn't get committe
Hi Shesek,
> 1. The resulting txids are not stable.
This is *literally* what the post you are replying to is proposing to solve.
> This property could be important for some of the proposed CTV use-cases, like
> channel factories.
Hmm? You can't have channel factories without Eltoo. (Well, you
Here's a summary of the trade-offs I see for using APO as a CTV alternative:
1. The resulting txids are not stable.
CTV commits to enough tx information such that given the txid:vout of the
covenant-encumbered output, you can predict the txid of the spending tx
permitted by CTV (and of the entire
I can't find all of my earlier references around this, I thought I made a
thread on it, but as a reminder, my thoughts for mild tweaks to APO that
make it a bit less hacky are as follows:
- Remove OP_1 key punning and replace it with OP_GENERATOR and
OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The
darosior via bitcoin-dev wrote:
> i doubt CTV is necessary nor sufficient for this
I would be interested to hear more on this.
Is it not necessary because you can exchange and store pre-signed
transactions instead?
What purpose is it not sufficient for? There are some vault designs out
there tha
darosior via bitcoin-dev wrote:
> CTV advocates have been presenting vaults as the flagship usecase.
Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's
Just a correction to my previous mail. Sorry for the non-attribution, i didn't
recall APO covenants had been discussed in the context of CTV.
> > a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV?
>
> I'm not aware of any specific to CTV. It's just that the fields covered in
Hi Richard,
> Sounds good to me. Although from an activation perspective it may not be
> either/or, both proposals do
compete for scarce reviewer time
Yes, of course. Let's say i was more interested in knowing if people who oppose
CTV would oppose
SIGHASH_ANYPREVOUT too. I think talking about a
ng, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
> Today's Topics:
>
> 1. ANYPREVOUT in place of CTV (darosior)
>
> --------------
>
> Message: 1
> Date: Fri
>
>
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
makes sense that byte-efficiency would be likely less important to vault
users vs lightning noninteractive channel users
>
> the meantime others will
Hi darosior,
Thanks for sharing your thoughts on this.
> I would like to know people's sentiment about doing (a very slightly tweaked
> version of) BIP118 in place of
> (or before doing) BIP119.
Sounds good to me. Although from an activation perspective it may not be
either/or, both proposals
gt; From: Luke Dashjr l...@dashjr.org
>
> To: bitcoin-dev@lists.linuxfoundation.org, darosior
> daros...@protonmail.com
>
> Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID: 202204221701.15307.l...@dashjr.org
>
> Content-Type: Text/Plain; charset="iso-8859-1&
Message: 1
> Date: Fri, 22 Apr 2022 11:11:41 +
> From: darosior daros...@protonmail.com
>
> To: Bitcoin Protocol Discussion
> bitcoin-dev@lists.linuxfoundation.org
>
> Subject: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID:
> p3P0m2_aNXd-4oYhFjCKJyI8zQ
There's no reason for before/after/in place. We have version bits specifically
so we can have multiple deployments in parallel.
But none of this ST nonsense, please. That alone is a reason to oppose it.
Luke
On Friday 22 April 2022 11:11:41 darosior via bitcoin-dev wrote:
> I would like to kno
Hi,
Richard Myers has an implementation of Eltoo using Bitcoin Core's functional
test framework:
https://github.com/remyers/bitcoin/blob/eltoo-anyprevout/test/functional/simulate_eltoo.py.
He blogged about it, too. https://yakshaver.org/2021/07/26/first.html
He seems to have something similar f
Good morning darosior,
Do you know if there is a working implementation of APO somewhere that people
can use to try out some of the proposed usecases? For example, it would be
great to see what eltoo would actually look like on an APO signet. Or to see
some working code for a vault using covena
I would like to know people's sentiment about doing (a very slightly tweaked
version of) BIP118 in place of
(or before doing) BIP119.
SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6
years. It presents proven and
implemented usecases, that are demanded and (please s
26 matches
Mail list logo
