Re: [bitcoin-dev] Packaged Transaction Relay

[Eric Voskuil via bitcoin-dev]

> -Original Message-
> From: Anthony Towns 
> Subject: Re: [bitcoin-dev] Packaged Transaction Relay
> > > > > > Protocol cannot be defined on an ad-hoc basis as a "courtesy"
> > > > > BIPs are a courtesy in the first place.
> > > > I suppose if you felt that you were the authority then this would
> > > > be your perspective.
> > > You seem to think that I'm arguing courtesy is not a good thing, or
> > > that we couldn't use more of it?
> > That is neither what I said nor implied. You were clearly dismissing
> > the public process, not advocating for politeness.
> 
> And that is neither what I said nor implied, nor something I believe. If
you
> think courtesy is something that can be ignored in a public process, I
don't
> think you should expect much success.

"BIPs are a courtesy in the first place."

> If you'd like to actually participate in public standards development,
please
> feel free to make some technical comments on my proposals, or others, or
> make your own proposal, either here or on github, or heck, anywhere else.

"RE: [bitcoin-dev] Packaged Transaction Relay"

> I mean, that's what I'd suggest anyway; I'm not your boss. I promise to at
> least be entertainingly surprised if you make any progress with your
current
> approach though.

Grow up Anthony.

e

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] What has the Taproot Annex ever done for us ?

[Antoine Riard via bitcoin-dev]

Hi,

Recent advances in the development of Eltoo Lightning channels have
envisioned the usage of the Taproot annex as a transaction endpoint where
to store specific protocol payload. [0] Further, during the past years,
some use-cases such as SIGHASH_GROUP/SIGHASH_BUNDLE have been proposed that
would require an extension of transaction fields. [1]. While there is
already the nSequence field serving as an endpoint for enforcement of new
consensus
semantics, the 32 bits of space doesn't allow multiple semantics to be
enforced on a transaction in a composable way. [2]

The Taproot softfork paved the way by introducing the annex, a tagged
element part of any SegWit v1 spends: "a reserved space for future
extensions".

This proposal introduces a Type-Length-Value format for the annex field,
motivated by its backward-compatibility and parsing straightforwardness.

There are a WIP implementation and a BIP available:
https://github.com/bitcoin-inquisition/bitcoin/pull/9
https://github.com/bitcoin/bips/pull/1381

For now, the proposal is minimal, seeking feedback in the TLV format is an
interesting direction. More advanced design questions are also open, like
what policy/consensus rules should be envisioned to prevent DoS of any kind
and how to make the annex field accessible to Script programmers (e.g
PUSH_ANNEX_RECORD).

Few use-cases could be served by the annex.

Per-input lock-time: as of today absolute timelocks are enforced at the
transaction level preventing aggregation of timelocked inputs by a
non-coordinating set of signers.

Commitment to historical block hash: signing the block hash could prevent a
transaction to be replayed or fee snipped in case of persistent forks.

Group of inputs/outputs: a group of input-outputs could be bundled and
signed together to enable non-interactive fee-bumping batching of off-chain
protocols.

Vectors of scriptPubkeys/amounts: within an off-chain protocol, a set of
signers can commit a priori to individual withdrawal ability, of which the
aggregation is enforced by the Script interpreter. [3]

The described use-cases are more whiteboard ideas than anything. It would
be interesting to dig in the archives of the ML and other Bitcoin research
venues, if there are forgotten requests of transaction fields extensions.
>From my perspective, I would say there are years of R work, before the
annex can be considered ready for activation.

Detailing the annex format now could harmonize its usage by application
only leveraging policy-only enforcement of the field, without having
ulterior consensus validation nullifying or interfering with the use.

Cheers,
Antoine

[0]
https://github.com/instagibbs/bolts/blob/eltoo_draft/XX-eltoo-transactions.md
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
[2] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev