> Still, re-reading your initital post, I'm convinced that the weakening of the
> DoS protections is probably not a huge problem, so maybe lets try this in a
> release and see what happens.
Awesome! I very much agree. The relaxation of some of these DoS prevention
rules I think will really open u
On Thu, Mar 08, 2018 at 03:07:43PM -0500, Russell O'Connor wrote:
> On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd wrote:
> > But that's not a good argument: whether or not normal users are trying to
> > attack each other has nothing to do with whether or not you're opening up
> > an
> > attack by rel
On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd wrote:
> On Thu, Mar 08, 2018 at 10:39:46AM -0500, Russell O'Connor wrote:
> > On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd wrote:
> > > I mean, I think in general solving this problem is probably not
> possible.
> > > Basically, the fundamental problem
On Thu, Mar 08, 2018 at 10:39:46AM -0500, Russell O'Connor wrote:
> On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd wrote:
> > I mean, I think in general solving this problem is probably not possible.
> > Basically, the fundamental problem is someone else has consumed network
> > bandwidth that should
On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd wrote:
> On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote:
> > When you say that you don't think it is possible to solve, do you mean
> that
> > there is a specific problem with this proposal of replacing transactions
> > when offered a
On Tue, Feb 27, 2018 at 11:25:59AM -0500, Russell O'Connor wrote:
> On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote:
>
> >
> > Ah ok, I misunderstood and didn't realise you were talking about the case
> > where
> > Alice re-spends her unconfirmed payment. Unfortunately I don't think that
> > ca
On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote:
>
> Ah ok, I misunderstood and didn't realise you were talking about the case
> where
> Alice re-spends her unconfirmed payment. Unfortunately I don't think that
> case
> is possible to solve without putting some kind of restriction on spending
>
Yes.
On Wed, Feb 14, 2018 at 9:08 AM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote:
>
>> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
>> > Surely CPFP is already computing the package-fee
On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote:
> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
> > Surely CPFP is already computing the package-fee rates of mempool
> > transactions. That is the value we need to compute.
>
> True, maybe we can just reuse the CPFP calculat
On February 13, 2018 1:40 PM, Peter Todd wrote:
> Yeah, sorry, I just misread what scenario you guys were talking about. IIRC
> the
> term "pinned" may have even been invented by myself, as IIRC I noticed the
> issue when the RBF patch was being developed years ago. I don't think I had a
> sol
On Mon, Feb 12, 2018 at 06:23:12PM -0500, rha...@protonmail.com wrote:
>
> On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev
> wrote:
>
> > I don't actually see where the problem is here. First of all, suppose we
> > have a
> > transaction T_a that already pays Alice with a feerate suf
On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev
wrote:
> I don't actually see where the problem is here. First of all, suppose we have
> a
> transaction T_a that already pays Alice with a feerate sufficiently high that
> we expect it to get mined in the near future. If we want to pay
On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote:
> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
> > On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote:
> >
> > >
> > > I don't actually see where the problem is here. First of all, suppose
> we
> > > have a
> > > transaction
On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
> On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote:
>
> >
> > I don't actually see where the problem is here. First of all, suppose we
> > have a
> > transaction T_a that already pays Alice with a feerate sufficiently high
> > tha
On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote:
>
> I don't actually see where the problem is here. First of all, suppose we
> have a
> transaction T_a that already pays Alice with a feerate sufficiently high
> that
> we expect it to get mined in the near future. If we want to pay Bob, we
> ca
On Mon, Feb 12, 2018 at 10:52:30AM -0500, Russell O'Connor via bitcoin-dev
wrote:
> I think it is worth revisiting BIP 125's replace-by-fee policy for when to
> replace transactions.
>
> The current policy can be problematic. As noted earlier by Rhavar,
> sometimes one's transaction becomes pinne
Thank you very much for writing this up. It's worth noting that there can be
multiple roots for the transactions that are getting replaced.
So for rule 3, you probably want a feeRate >= the max "package fee rate" of all
replaced roots.
I am very happy with this proposal in general, as it's cl
I think it is worth revisiting BIP 125's replace-by-fee policy for when to
replace transactions.
The current policy can be problematic. As noted earlier by Rhavar,
sometimes one's transaction becomes pinned making it infeasible to fee bump
with RBF. This happens when one makes a normal payment to
18 matches
Mail list logo
