Hi Peter,
> You make a good point that the commitment transaction also needs to be
included
> in my calculations. But you are incorrect about the size of them.
> With taproot and ephemeral anchors, a typical commitment transaction
would have
> a single-sig input (musig), two taproot outputs, and
Hi Peter,
Thanks for spending time thinking about RBF pinning and v3.
> Enter Mallory. His goal is to grief Alice by forcing her to spend more
money
than she intended...
> ...Thus the total fee of Mallory's package would have
> been 6.6 * 1/2.5 = 2.6x more than Alice's total fee, and to get her
(or if there is code already available) to see
> if it's robust against adversarial or unlucky situations ?
>
> > In fact, a package
> > of transactions may be announced using both Erlay and package relay.
> > After reconciliation, if the initiator would have announced a
>
Hi AJ,
Not going to comment on what Bitcoin Core's philosophy on mempol policy is
or should be. I want to note that I think this:
> It's also possible that this is something of a one time thing: full rbf
> has been controversial for ages, but widely liked by devs, and other
> attempts (eg making
new unconfirmed inputs, but the
>>> > ancestor feerate of the child must be at least as high as the ancestor
>>> > feerates of every transaction being replaced."
>>>
>>> Note, I think we would like this new RBF rule to also apply to single
>>>
Hi everyone,
I'm writing to propose a very simple set of mempool/transaction relay
policies intended to aid L2/contract protocols. I realized that
the previously proposed Package Mempool Accept package RBF [1]
had a few remaining problems after digging into the RBF logic more [2].
This additional
; package-relay regimes and just risk a little extra bandwidth in one
> direction or the other. If we solve the problem I brought up at the
> beginning (of de-duplicating package data across peers with a
> package-wtxid-commitment in the announcement), I think this is just some
> wasted pkg
Hi Eric, aj, all,
Sorry for the delayed response. @aj I'm including some paraphrased points
from our offline discussion (thanks).
> Other idea: what if you encode the parent txs as a short hash of the
wtxid (something like bip152 short ids? perhaps seeded per peer so
collisions will be different
ation level - instead of submitting each tx individually, we submit
each ancestor subset. Do you think any of these is sufficient? At least the
package properly propagates across nodes which are online when it is
broadcasted...
Best,
Gloria
On Wed, May 25, 2022 at 11:55 AM Anthony Towns wrote:
Hi aj,
> If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is
below fee floor while A+B and A+B+C+X are above fee floor you have the
problem though.
To clarify, in this situation, I'm imagining something like
A: 0 sat, 100vB
B: 1500 sat, 100vB
C: 0 sat, 100vB
X: 500 sat,
oria
On Mon, May 23, 2022 at 2:34 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, May 18, 2022 at 02:40:58PM -0400, Gloria Zhao via bitcoin-dev
> wrote:
> > > Does it make sense for these to be configurable, rather than implied
> &g
. It would reduce the
number of round trips, but I don’t think an extra round trip is that big of
a deal for transaction relay. Block relay, yes of course, but I don’t think
we care that much if it takes an extra second to send a transaction?
Best,
Gloria
On Tue, May 17, 2022 at 8:35 PM Anthony Tow
ned into unconfirmed, but those situations are
> extremely uncommon. The other rules are entirely under the control
> of the sender, which leads me to wonder if it's appropriate.
>
> Cheers,
> Greg
>
> On Tue, May 17, 2022 at 12:09 PM Gloria Zhao via bitcoin-dev <
> bitcoin-
Hi everybody,
I’m writing to propose a set of p2p protocol changes to enable package
relay, soliciting feedback on the design and approach. Here is a link
to the most up-to-date proposal:
https://github.com/bitcoin/bips/pull/1324
If you have concept or approach feedback, *please respond on the
uld have to be discussed, I
>> suspect a worst-case adversarial 3.33 minute delay would not be "too much".
>> Doing this could basically eliminate any risk of actual service denial via
>> replacement transactions.
>>
>> However, I do think that these DOS conc
Hi RBF friends,
Posting a summary of RBF discussions at coredev (mostly on transaction
relay rate-limiting), user-elected descendant limit as a short term
solution to unblock package RBF, and mining score, all open for feedback:
One big concept discussed was baking DoS protection into the p2p
at the
>>> lowest acceptable feerate then slowly increasing while still not reaching
>>> the top of the mempool. Same if it's time-based or block-based, no
>>> guarantee the replacement slot is honestly used by your counterparty.
>>>
>>> Further, an
Hi everyone,
This post discusses limitations of current Bitcoin Core RBF policy and
attempts to start a conversation about how we can improve it,
summarizing some ideas that have been discussed. Please reply if you
have any new input on issues to be solved and ideas for improvement!
Just in case
Hi Darosior and Ariard,
Thank you for your work looking into fee-bumping so thoroughly, and for
sharing your results. I agree about fee-bumping's importance in contract
security and feel that it's often under-prioritized. In general, what
you've described in this post, to me, is strong motivation
Hi Lisa,
Some background for people who are not familiar with mempool:
The mempool is a cache of unconfirmed transactions, designed in a way
to help miners efficiently pick the highest feerate packages to
include in new blocks. It stores more than a block's worth of
transactions because
already in
>>> the mempool. Therefore, to compute a correct RBF penalty replacement, the
>>> vsize of this transaction could be discarded lowering the cost of package
>>> RBF.
>>>
>>> If we keep a "safe" dedup mechanism (see my point above), I think t
a question regarding this rule, as your example 2C could be
>>>>> concerning for LN (unless I didn't understand it correctly).
>>>>>
>>>>> This also touches on the package RBF rule 5 ("The package cannot
>>>>> replace more than 100 mempo
limits
>>> and pay low fees (where A would be a commit tx in LN).
>>>
>>> We had to create the CPFP carve-out rule explicitly to work around
>>> this limitation, and I think it would be necessary for package RBF
>>> as well, because in such cases we do want
do.
>
> Is my concern justified? Is this something that we should dig into a
> bit deeper?
>
> Thanks,
> Bastien
>
> Le jeu. 16 sept. 2021 à 09:55, Gloria Zhao via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Hi there,
>>
>>
0 vbytes.
>
> Package A + B ancestor score is 10 sat/vb.
>
> D has a higher feerate/absolute fee than B.
>
> Package A + C + D ancestor score is ~ 3 sat/vb ((A's 1000 sats + C's 1000
> sats + D's 1500 sats) /
> A's 100 vb + C's 1000 vb + D's 100 vb)
>
> Overall, this is a revie
Hi there,
I'm writing to propose a set of mempool policy changes to enable package
validation (in preparation for package relay) in Bitcoin Core. These would
not
be consensus or P2P protocol changes. However, since mempool policy
significantly affects transaction propagation, I believe this is
Hi Antoine,
Thanks for initiating this! I'm interested in joining. Since I mostly live
in L1, my primary goal is to understand what simplest version of package
relay would be sufficient to support transaction relay assumptions made by
L2 applications. For example, if a parent + child package
27 matches
Mail list logo
