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 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
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 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
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
>
> > 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
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
> The white paper describing the proposal can be found here:
> https://github.com/LNP-BP/layer1/
Some questions about the Bitcoin PoW anchoring:
What if a miner spends the current miner single-use-seal while
creating a commitment, but makes the PMT only partially available, or
entirely
Hi John,
Thank you for the question. We have discussed this case in the paper, second
paragraph of the “Bitcoin PoW Anchoring” Section:
> If a party spends current miner single-use-seal without creating a commitment
> - or committing to a header without sufficient PoW, such closing is
>
Hi Maxim,
> In this regard, I’d like to propose the following:
>
> 1. The bitcoin-dev mail list must have a clear moderation (or
> pre-publication peer-review policy). It can be proposed and discussed in this
> mail list and, upon agreement, must become public and obligatory.
> 2. Bryan
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
>
11 matches
Mail list logo
