Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

[Russell O'Connor via bitcoin-dev]

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 is someone else has consumed network
> > > bandwidth that should be paid for with fees. What you're trying to do
> is
> > > replace a transaction without paying those fees, which is identical to
> > > what an
> > > attacker is trying to do, and thus any such scheme will be as
> vulnerable to
> > > attack as not having that protection in the first place.
> > >
> > > ...which does give you an out: maybe the attack isn't important enough
> to
> > > matter. :)
> > >
> >
> > Thanks, that makes sense.
> >
> > I still think it is worthwhile pursuing this proposed change in RBF
> policy
> > as it would seem that the current policy is problematic in practice today
> > where participants are just performing normal transactions and are not
> > trying to attack each other.
>
> 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 relaxing anti-DoS protections.
>

I'm not suggesting removing the anti-DoS protections.  I'm suggesting that
replaced transaction require a fee increase of at least the min-fee-rate
times the size of all the transactions being ejected (in addition to the
other proposed requirements).


> Equally, how often are normal users who aren't attacking each other
> creating
> issues anyway? You can always have your wallet code just skip use of RBF
>
replacements in the event that someone does spend an unconfirmed output that
> you sent them; how often does this actually happen in practice?


Just ask rhavar.  It happens regularly.

Not many wallets let you spend unconfirmed outputs that you didn't create.
>

The problem is with institutional wallets sweeping incoming payments.  It
seems that in practice they are happy to sweep unconfirmed outputs.

Setting all of the above aside for a moment.  We need to understand that
rational miners are going to prefer to transactions with higher package fee
rates regardless of whatever your personal preferred RBF policy is.  If we
do not bring the RBF policy to alignment with what is economically
rational, then miners are going to change their own policies anyways,
probably all in slightly different ways.  It behooves everyone to develop a
reasonable standard RBF policy, that is still robust against possible DoS
vectors, and aligns with miner incentives, so that all participants know
what behaviour they can reasonably expect.  It is simply a bonus that this
change in RBF policy also partially mitigates the problem of pinned
transactions.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

[Peter Todd via bitcoin-dev]

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 be paid for with fees. What you're trying to do is
> > replace a transaction without paying those fees, which is identical to
> > what an
> > attacker is trying to do, and thus any such scheme will be as vulnerable to
> > attack as not having that protection in the first place.
> >
> > ...which does give you an out: maybe the attack isn't important enough to
> > matter. :)
> >
> 
> Thanks, that makes sense.
> 
> I still think it is worthwhile pursuing this proposed change in RBF policy
> as it would seem that the current policy is problematic in practice today
> where participants are just performing normal transactions and are not
> trying to attack each other.

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 relaxing anti-DoS protections.

Equally, how often are normal users who aren't attacking each other creating
issues anyway? You can always have your wallet code just skip use of RBF
replacements in the event that someone does spend an unconfirmed output that
you sent them; how often does this actually happen in practice? Not many
wallets let you spend unconfirmed outputs that you didn't create.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.

[Russell O'Connor via bitcoin-dev]

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 new transaction whose fee rate exceeds the package fee
> rate
> > of the original transaction (and ensuring that the fee increase covers
> the
> > size of the transactions being ejected)?  Is your concern only about the
> > ability to computing and track the package fee rate for transactions
> within
> > the mempool or is there some other issue you foresee?
>
> 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 be paid for with fees. What you're trying to do is
> replace a transaction without paying those fees, which is identical to
> what an
> attacker is trying to do, and thus any such scheme will be as vulnerable to
> attack as not having that protection in the first place.
>
> ...which does give you an out: maybe the attack isn't important enough to
> matter. :)
>

Thanks, that makes sense.

I still think it is worthwhile pursuing this proposed change in RBF policy
as it would seem that the current policy is problematic in practice today
where participants are just performing normal transactions and are not
trying to attack each other.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Reserved nversion bits in blockheader - stratum mining.configure

[Jan Čapek via bitcoin-dev]

Hello,

Our reasoning for coming up with a new method for miner configuration
was stated here: https://github.com/slushpool/stratumprotocol/issues/1

It is primarily the determinism of expecting the response. That is
the reason why we chose a new method mining.configure instead of an
existing mining.capabilities that was not being very well documented or
used.


On Wed, 7 Mar 2018 14:43:11 + Luke Dashjr via bitcoin-dev
 wrote:

> Why are you posting this obsolete draft? You've already received
> review in private, and been given useful suggestions. There's even a
> shared Google Doc with the current draft:
> 
> 
> https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9TV9LRqvStak/edit?usp=sharing
> 
> Again:
> 
> * This is no different from what Timo and Sergio proposed years ago,
> and as such should be based on their work instead of outright
> not-invented-here respecification. The current draft integrates their
> work while not trying to steal credit for it (they are included as
> primary authors).
> 
> * The specification should be complete, including updates for GBT and
> the Stratum mining protocol. These are included in the current draft.
> 
> Additionally, it is not appropriate to begin using a draft BIP on
> mainnet before any discussion or consensus has been reached. Doing so
> seems quite malicious, in fact. I hope DragonMint miners can still
> operate using the *current* Bitcoin protocol.
> 
> Luke
> 
> 
> On Wednesday 07 March 2018 8:19:57 AM Btc Drak via bitcoin-dev wrote:
> > Hi,
> > 
> > The following proposal reduces the number of version-bits that can
> > be used for parallel soft-fork signalling, reserving 16 bits for
> > non-specific use. This would reduce the number of parallel
> > soft-fork activations using versionbits to from 29 to 13 and
> > prevent node software from emitting false warnings about unknown
> > signalling bits under the versionbits signalling system (BIP8/9). I
> > chose the upper bits of the nVersion, because looking at the
> > versionbits implementation in the most widely deployed node
> > software, it is easier to implement than say annexing the lower 2
> > bytes of the field.
> > 
> > The scope of the BIP is deliberately limited to reserving bits for
> > general use without specifying specific uses for each bit, although
> > there have previously been various discussions of some use-cases of
> > nVersion bits including version-rolling AsicBoost[1], and nonce
> > rolling to reduce CPU load on mining controllers because
> > ntime-rolling can only be done for short periods otherwise it could
> > have negative side effects distorting time. However, specific use
> > cases are not important for this BIP.
> > 
> > I am reviving discussion on this topic now, specifically, because
> > the new DragonMint miner uses version-rolling AsicBoost on
> > mainnet[2]. It is important to bring up so node software can adapt
> > the versionbits warning system to prevent false positives. This BIP
> > has the added advantage that when a new use for bits is found,
> > mining manufacturers can play in the designated area without
> > causing disruption or inconvenience (as unfortuntely, the use of
> > version-rolling will cause until BIP8/9 warning systems are
> > adapted). I appologise for the inconvenience in advance, but this
> > is the unfortunate result of restraints while negotiating to get
> > the patent opened[3] and licensed defensively[4] in the first place.
> > 
> > I believe there was a similar proposal[5] made some years ago,
> > before the advent of BIP9. This proposal differs in that it's
> > primary purpose is to remove bits from the versionbits soft-fork
> > activation system and earmark 16 bits for general use without
> > allocating fixed uses for each bit. The BIP cites a couple of
> > usecases for good measure, but they are just informational
> > examples, not part of a specification laid down. For this reason,
> > there no is mention of the version-rolling Stratum extension[6]
> > specifics within the BIP text other than a reference to the
> > specification itself.
> > 
> > Refs:
> > 
> > [1] https://arxiv.org/pdf/1604.00575.pdf
> > [2]
> > https://halongmining.com/blog/2018/03/07/dragonmint-btc-miner-uses-version->
> > rolling-asicboost/ [3]
> > https://www.asicboost.com/single-post/2018/03/01/opening-asicboost-for-defe
> > nsive-use/ [4] https://blockchaindpl.org/ [5]
> > https://github.com/BlockheaderNonce2/bitcoin/wiki [6]
> > http://stratumprotocol.org/stratum-extensions
> > 
> > 
> >   BIP: ?
> >   Title: Reserved nversion bits in blockheader
> >   Author: BtcDrak 
> >   Comments-Summary: No comments yet.
> >   Comments-URI:
> > https://github.com/bitcoin/bips/wiki/Comments:BIP- Status: Draft
> >   Type: Informational
> >   Created: 2018-03-01
> >   License: BSD-3-Clause
> >CC0-1.0
> > 
> > 
> > ==Abstract==
> > 
> > This BIP reserves 16 bits of the block header