В Wed, 23 Sep 2020 15:10:22 -0700
Jeremy via bitcoin-dev wrote:
> It's not particularly important that a transaction be in the same
> block once sponsored, it could also be in the last 100 blocks (the
> opposite of proposed change 3).
This will in effect enable "inverse timelock" mechanism for
Hi Suhas,
Thanks for your thoughtful response!
Overall I'll boil down my thoughts to the following:
If we can eventually come up with something clever at the user+policy layer
to emulate a sponsor like mechanism, I would still greatly prefer to expose
that sort of functionality directly and in
Hi,
I think the topic of how to improve transaction relay policy and fee
bumping is an important one that needs to be worked on, so I'm glad
this is a topic of discussion. However I am pretty skeptical of this
consensus change proposal:
The Sponsor Vector TXIDs must also be in the block the
Hello AC,
Yes that's a real issue. In the context of multi-party protocols, you may
pre-signed transactions with the feerate of _today_ and then only going to
be broadcast later with a feerate of _tomorrow_.
In that case the pre-signed feerate may be so low that the transaction
won't even
Not sure if I'm missing something, but I'm curious if (how) this will work if
the sponsored transaction's feerate is so low that it has been largely evicted
from mempools due to fee pressure, and is too low to be widely accepted when
re-broadcast? It seems to me that the following requirement
I think this is a worthy idea as the funding outpoint of any off-chain
protocols is an invariant known by participants. Thus by sponsoring an
outpoint you're requiring from network mempools to increase the feerate of
the package locally known without assuming about the concrete state as any
of
Responses Inline:
Would it make sense that, instead of sponsor vectors
> pointing to txids, they point to input outpoints? E.g.:
>
> 1. Alice and Bob open a channel with funding transaction 0123...cdef,
>output 0.
>
> 2. After a bunch of state updates, Alice unilaterally broadcasts a
>
On Sun, Sep 20, 2020 at 07:10:23PM -0400, Antoine Riard via bitcoin-dev wrote:
> As you mentioned, if the goal of the sponsor mechanism is to let any party
> drive a state N's first tx to completion, you still have the issue of
> concurrent states being pinned and thus non-observable for
Right, I was off the shot. Thanks for the explanation.
As you mentioned, if the goal of the sponsor mechanism is to let any party
drive a state N's first tx to completion, you still have the issue of
concurrent states being pinned and thus non-observable for sponsoring by an
honest party.
E.g,
Antoine,
Yes I think you're a bit confused on where the actual sponsor vector is. If
you have a transaction chain A->B->C and a sponsor S_A, S_A commits to txid
A and A is unaware of S.
W.r.t your other points, I fully agree that the 1-to-N sponsored case is
very compelling. The consensus rules
EDIT: I misunderstood the emplacement of the sponsor vector, please
disregard previous review :( Beyond where the convenient place should live,
which is still accurate I think.
> The
> Sponsor Vector TXIDs must also be
> in the block the transaction is validated in, with no restriction on
>
Hi Jeremy,
This is a really interesting proposal to widen the scope of fee mechanisms.
First, a wider point on what this proposal brings with regards to pinning,
to the best of my knowledge.
A pinning may have different vectors by exploiting a) mempools limits (e.g
descendants) or b) mempools
On Sat, Sep 19, 2020 at 09:30:56AM -0700, Jeremy wrote:
> Yup, I was aware of this limitation but I'm not sure how practical it is as
> an attack because it's quite expensive for the attacker.
It's cheap if:
1. You were planning to consolidate all those UTXOs at roughly that
feerate anyway.
Hi David!
Thanks for taking a look, and great question.
> Is this in the reference implementation?
It is indeed in the reference implementation. Please see
https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx#diff-24efdb00bfbe56b140fb006b562cc70bR741-R743
There is no
Hi Cory!
Thanks for taking a look. CC nopara as I think your questions are the same.
I think there are a few reason we won't see functionally worse privacy:
1. RBF/CPFP may require the use of an external to the original transaction
to pay sufficient fee.
2. RBF/CPFP may leak which address was
Wouldn't this enable a passive adversary listening the mempool to associate
unrelated TXO clusters to the same user?
On Sat, Sep 19, 2020, 15:38 David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev
On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:
> I'd like to share with you a draft proposal for a mechanism to replace
> CPFP and RBF for increasing fees on transactions in the mempool that
> should be more robust against attacks.
Interesting idea! This is going to take
Conceptually this is so simple and explicit it almost seems like an obvious
primitive.
Glossing over some of the design/policy decisions...
I wonder what the real-world privacy implications are due to the
dependencies now being encoded on-chain rather than requiring some effort
to watch the
Hi Bitcoin Devs,
I'd like to share with you a draft proposal for a mechanism to replace
CPFP and RBF for
increasing fees on transactions in the mempool that should be more
robust against attacks.
A reference implementation demonstrating these rules is available
19 matches
Mail list logo
