> So the sha256 of the span of the group doesn't commit to start and end
> -- it just serializes a vector, so commits to the number of elements,
> the order, and the elements themselves.
Gotcha wasn't clear to me that the new state pair isn't committed as part
of the annex.
Have been confused by
On Fri, Jul 09, 2021 at 09:19:45AM -0400, Antoine Riard via bitcoin-dev wrote:
> > The easy way to avoid O(n^2) behaviour in (3) is to disallow partial
> > overlaps. So let's treat the tx as being distinct bundles of x-inputs
> > and y-outputs, and we'll use the annex for grouping, since that is
>
On Thu, May 27, 2021 at 04:14:13PM -0400, Antoine Riard via bitcoin-dev
wrote:
> This overhead could be smoothed even further in the future with more
advanced
> sighash malleability flags like SIGHASH_IOMAP, allowing transaction
signers to
> commit to a map of inputs/outputs [2]. In the context of
On Thu, May 27, 2021 at 04:14:13PM -0400, Antoine Riard via bitcoin-dev wrote:
> This overhead could be smoothed even further in the future with more advanced
> sighash malleability flags like SIGHASH_IOMAP, allowing transaction signers to
> commit to a map of inputs/outputs [2]. In the context of
On Tue, 15 Jun 2021 at 10:59, Lloyd Fournier wrote:
>
>
> On Tue, 15 Jun 2021 at 02:47, Antoine Riard
> wrote:
>
>> > This makes a lot of sense as it matches the semantics of what we are
>> trying
>> to achieve: allow the owner of an output (whether an individual or group)
>> to reduce that
On Tue, 15 Jun 2021 at 02:47, Antoine Riard wrote:
> > This makes a lot of sense as it matches the semantics of what we are
> trying
> to achieve: allow the owner of an output (whether an individual or group)
> to reduce that output's value to pay a higher fee.
>
> Note, I think you're still
Thanks for this analysis of a sponsor-like mechanism.
For sure, "watchtower friendly" and "post hoc" are really good point
towards sponsorship, at least other proposals are struggling with
watchtower support, at least in way where your watchtower policy doesn't
leak to your counterparties (which
> This makes a lot of sense as it matches the semantics of what we are
trying
to achieve: allow the owner of an output (whether an individual or group)
to reduce that output's value to pay a higher fee.
Note, I think you're still struggling with some trust issue that anchor
upgrade is at least
The API of a sponsor-like mechanism is close to ideal in my opinion:
- compatible with non malleable transactions
- 0 overhead if fees accurately estimated
- watchtower friendly
- post hoc, requires minimal 'protocol awareness'
- friendly with most mempool eviction policies, not much new required
On Fri, 11 Jun 2021 at 07:45, Antoine Riard wrote:
> Hi Lloyd,
>
> Thanks for this tx mutation proposal extending the scope of fee-bumping
> techniques. IIUC, the serves as a pointer to increase the
> output amount by value to recover the recompute the transaction hash
> against which the
> Note, I think that the tx mutation proposal relies on interactivity in the
> worst-case scenario where a counterparty wants to increase its fee-bumping
> output from the contract balance. This interactivity may lure a counterparty
> to alway lock the worst-case fee-bumping reserve in the
Hi Lloyd,
Thanks for this tx mutation proposal extending the scope of fee-bumping
techniques. IIUC, the serves as a pointer to increase the
output amount by value to recover the recompute the transaction hash
against which the original signature is valid ?
Let's do a quick analysis of this
> So something like
`or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))` with each `or`
in their own leaf? I think it works, but only if the keys `A`, `B`, `C` are
"hot", as in available to the
fee-bumper. For Revault it means introducing a key for each watchtower in
the vaults descriptors,
Hi,
Another thing to consider when comparing these two techniques is anti-fee
sniping protection. If you are going to feebump directly
your revocation transaction by adding inputs to it, the nLockTime has already
been signed in advance. Therefore your are sponsoring
a transaction that could be
Hi Antione,
Thanks for bringing up this important topic. I think there might be another
class of solutions over input based, CPFP and sponsorship. I'll call them
tx mutation schemes. The idea is that you can set a key that can increase
the fee by lowering a particular output after the tx is
> Oh yes, I should have mentioned this pinning vector. The witnessScript I've
> in mind to make secure that type of chain of transactions would be one MuSig
> key for all contract participants, where signature are committed with
> SIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one pubkey per participant
> Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just
attach an output paying immediately to me, and construct a tx chain
spending it). We are using ACP | ALL for Revault,
> which is the reason why we need a well laid-out pool of fee-bumping UTXOs
(as you need to consume them
Hi,
> ## Input-Based
>
> I think input-based fee-bumping has been less studied as fee-bumping
> primitive for L2s [1]. One variant of input-based fee-bumping usable today is
> the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability flags.
> If the transaction is the latest stage
Hi,
This post is pursuing a wider discussion around better fee-bumping
strategies for second-layer protocols. It draws out a comparison between
input-based and CPFP fee-bumping techniques, and their apparent trade-offs
in terms of onchain footprint, tx-relay bandwidth rebroadcast, batching
19 matches
Mail list logo
