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 t
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 re
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 argum
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 k
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
> interpre
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,
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
Hi,
Before starting, I would like to state that I do not necessarily support
the implementation of the idea I'm about to present, but I think it's worth
mentioning as it might inspire different use cases or provoke some debate.
I believe that out-of-band relay is a more preferable and efficient wa
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 https://github.com/bitcoin/bitcoin/pull/24007
>
> > 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 b
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 f
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 th
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 i
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
Hi David,
> A block template is an ordered list of raw transactions that can all be
> included in the next block (with some space reserved for a coinbase
> transaction). A full node can validate those transactions and calculate
> how much fee they pay. A Nostr relay can simply relay almost[1] a
Hi fd0,
> - Transactions could be encrypted when published as nostr events initially
> except size, fee rate and offer. This can be used by different clients to
> show them as external mempool with transactions sorted by fee rate without
> affecting privacy of users.
>
I don't think this will wo
Hi,
I write to get your thoughts on an alternative approach for Bitcoin
transaction relay, addressing some of the limitations in the current
peer-to-peer transaction relay system. To the best of my knowledge, the
credit for the original concept goes to Ben Carman. I felt it would be
beneficial to
18 matches
Mail list logo
