Hi Joost,
> Hopefully this further raises awareness of the on-chain ephemeral
signature backup functionality that the annex uniquely enables.
>From my perspective, if vault applications can be made more robust by
on-chain backing up of ephemeral signatures, this can be rational to make
the annex
Hi all,
On Sat, Jun 10, 2023 at 9:43 AM Joost Jager wrote:
> However, the primary advantage I see in the annex is that its data isn't
> included in the calculation of the txid or a potential parent commit
> transaction's txid (for inscriptions). I've explained this at [1]. This
> feature makes
Hi Antoine,
On Sun, Jun 18, 2023 at 10:32 PM Antoine Riard
wrote:
> > * Opt-in annex (every input must commit to an annex even if its is
> empty) -> make sure existing multi-party protocols remain unaffected
>
> By requiring every input to commit to an annex even if it is empty, do you
> mean
Hi Greg,
> Going to need a citation for this.
Sorry for the confusion, this was in reply to Joost's point on "Opt-in
annex (every input must commit to an annex even if its is empty) -> make
sure existing multi-party protocols remain unaffected"
What is unclear to me is if we're talking about
Hi all,
> * Opt-in annex (every input must commit to an annex even if its is empty)
-> make sure existing multi-party protocols remain unaffected
By requiring every input to commit to an annex even if it is empty, do you
mean rejecting a transaction where the minimal annex with its 0x50 tag is
Hi Antoine,
> If I understand correctly, this would require modifying current Taproot
support on the Lightning-side, where all P2TR spends must add an annex and
commit to it in the BIP341 signature digest.
huh?
Going to need a citation for this.
People should really not be building protocols
Hi Joost,
I haven't thought a ton about the specific TLV format, but that seems like
a reasonable place to start as it shouldn't unduly
impact current users, and is pretty simple from an accounting perspective.
It also can be further relaxed in the future if we so decide by using max
tx size
Hi Greg,
On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders wrote:
> > Would it then still be necessary to restrict the annex to a maximum size?
>
> I think it's worth thinking about to protect the opt-in users, and can
> also be used for other anti-pinning efforts(though clearly not sufficient
> by
Hi Greg,
Getting back to this:
Another solution could be to make annex usage "opt-in"
> by requiring all inputs to commit to an annex to be relay-standard. In
> this case, you've opted into a possible
> vector, but at least current usage patterns wouldn't be unduly affected.
>
Ignoring the
Hi Joost,
> Ignoring the argument that policy may provide a false sense of security
This may take longer form arguments than I'm willing to make on this
thread, but I think this only true in a shallower sense that we cannot know
for sure that anything will be confirmed quickly. When crafting
On Tue, Jun 13, 2023 at 10:51 AM David A. Harding wrote:
> > I am really looking for a bitcoin-native solution to leverage
> > bitcoin's robustness and security properties.
>
> I understand. I would briefly point out that there are other advantages
> to not storing a signature for an ephemeral
On 2023-06-11 09:25, Joost Jager wrote:
Isn't it the case that that op-dropped partial signature for the
ephemeral key isn't committed to and thus can be modified by anyone
before it is mined
That's correct; I hadn't thought of that, sorry.
I am really looking for a bitcoin-native solution
> Regarding the potential payload extension attack, I believe that the
changes proposed in the [3] to allow tx replacement by smaller witness
would provide a viable solution?
The only plausible case I could see moving forward is replacing the
transaction to a form that has *no* annex or
Hi Joost,
> However, the primary advantage I see in the annex is that its data isn't
included in the calculation of the txid or a potential parent commit
transaction's txid (for inscriptions). I've explained this at [1]. This
> feature makes the annex a powerful tool for applications that would
Hi Dave,
On Sun, Jun 11, 2023 at 12:10 AM David A. Harding wrote:
> 3. When paying the script in #2, Alice chooses the scriptpath spend from
> #1 and pushes a serialized partial signature for the ephemeral key
> from #2 onto the stack, where it's immediately dropped by the
>
On 2023-06-09 21:43, Joost Jager via bitcoin-dev wrote:
The most critical application in this category, for me, involves
time-locked vaults.
[...]
Backing up the ephemeral signatures of the pre-signed transactions on
the blockchain itself is an excellent way to ensure that the vault can
always
Hi Antoine,
On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard
wrote:
> From a taproot annex design perspective, I think this could be very
> valuable if you have a list of unstructured data use-cases you're thinking
> about ?
>
The annex's list of unstructured data use-cases includes existing data
Hi Joost,
Thanks for detailing why a '0' as free-form, without any additional
constraints offers valuable engineering properties as of today.
>From a taproot annex design perspective, I think this could be very
valuable if you have a list of unstructured data use-cases you're thinking
about ? As
Hi,
In the proposal below, any annex that begins with `0x00` is defined as
free-form. This isn't the most efficient format though because there is
always one byte lost on signalling. In a future where unstructured annex
data turns out to be the predominant use case, this may be relevant. Also
for
On Sat, Jun 03, 2023 at 11:14:27AM +0200, Joost Jager via bitcoin-dev wrote:
> Depending on policy to mitigate this annex malleability vector could
> mislead developers into believing their transactions are immune to
> replacement, when in fact they might not be. This potential misalignment
>
On Sat, Jun 3, 2023 at 2:43 PM Greg Sanders wrote:
> No in this case the txid is identical. Only the wtxid is malleated, with
> annex data stuffed to max transaction size.
>
This doesn't sound incentive compatible? While gathering context, I did
find
>
> > Depending on policy to mitigate this annex malleability vector could
> mislead developers into believing their transactions are immune to
> replacement, when in fact they might not be.
>
> The issue I'm talking about is where someone's transaction is denied entry
> into the mempool entirely
No in this case the txid is identical. Only the wtxid is malleated, with
annex data stuffed to max transaction size.
Cheers,
Greg
On Sat, Jun 3, 2023, 8:36 AM Joost Jager wrote:
> > Depending on policy to mitigate this annex malleability vector could
>> mislead developers into believing their
> I think this avoidance of a circular reference is also why LN-Symmetry
uses the annex?
The annex trick specifically is used to force the publication of the
missing piece of the control block corresponding to the new taproot output.
This is to maintain the node's O(1) state while also keeping
HI Greg,
On Sat, Jun 3, 2023 at 3:14 AM Greg Sanders wrote:
> Attempting to summarize the linked PR:
>
> I think the biggest remaining issue to this kind of idea, which is why I
> didn't propose it for mainnet,
> is the fact that BIP341/342 signature hashes do not cover *other* inputs'
> annex
On Sat, Jun 3, 2023 at 9:49 AM Joost Jager wrote:
> The removal of the need for a commitment transaction also enables the
> inclusion of data within a single transaction that relies on its own
> transaction identifier (txid). This is possible because the txid
> calculation does not incorporate
Hi David,
On Sat, Jun 3, 2023 at 3:08 AM David A. Harding wrote:
> Out of curiosity, what features and benefits are available today? I
> know Greg Sanders wants to use annex data with LN-Symmetry[1], but
> that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you
> mention that
Hello Joost, David,
Thanks for the link to my ln-symmetry draft David. I'd also be curious as
to the usage you have in
mind Joost.
It's probably helpful to cite the most recent discussions on the topic,
which is probably
https://github.com/bitcoin-inquisition/bitcoin/pull/22 , where
On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:
the benefits of making the annex available in a
non-structured form are both evident and immediate. By allowing
developers to utilize the taproot annex without delay, we can take
advantage of its features today,
Hi Joost,
Out of
Hi,
As it stands, the taproot annex is consensus valid but non-standard. The
conversations around standardization seem to be leaning towards the
adoption of a flexible Type-Length-Value (TLV) format [1]. There's no doubt
that this approach has considerable potential. However, settling on an
exact
30 matches
Mail list logo
