--- Log opened Wed Aug 25 00:00:50 2021
01:29 -!- babasancheti [~babasanch@43.249.232.30] has joined #bitcoin-core-pr-reviews
03:01 -!- livestradamus [~quassel@user/livestradamus] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
03:04 -!- babasancheti [~babasanch@43.249.232.30] has quit [Quit: Client closed]
03:05 -!- livestradamus [~quassel@user/livestradamus] has joined #bitcoin-core-pr-reviews
04:28 -!- blkncd [sid505676@2001:67c:2f08:5::7:b74c] has quit []
04:28 -!- blkncd [sid505676@id-505676.helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews
04:30 -!- josibake [sid509132@id-509132.brockwell.irccloud.com] has quit []
04:30 -!- josibake [sid509132@id-509132.helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews
05:05 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
05:35 -!- _aj_ [aj@cerulean.erisian.com.au] has quit [Changing host]
05:35 -!- _aj_ [aj@user/aj/x-5857768] has joined #bitcoin-core-pr-reviews
06:21 -!- b10c [uid500648@id-500648.charlton.irccloud.com] has joined #bitcoin-core-pr-reviews
08:19 -!- biteskola [~biteskola@184.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-pr-reviews
08:19 -!- biteskola is now known as aitorjs
08:22 -!- aitorjs [~biteskola@184.76.76.188.dynamic.jazztel.es] has quit [Client Quit]
08:22 -!- aitorjs [~aitorjs@184.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-pr-reviews
08:25 < jnewbery> Hi folks. We'll get started in about 90 minutes. Notes and questions are at https://bitcoincore.reviews/22665
09:10 -!- VzxPLnHqr [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has joined #bitcoin-core-pr-reviews
09:23 -!- dunxen [dunxen@gateway/vpn/protonvpn/dunxen] has joined #bitcoin-core-pr-reviews
09:38 -!- dunxen [dunxen@gateway/vpn/protonvpn/dunxen] has quit [Quit: Leaving...]
09:42 -!- raj [~raj_@103.77.139.219] has joined #bitcoin-core-pr-reviews
09:51 -!- chunkblob [~chunkblob@cpe-184-153-97-30.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews
09:59 -!- darius27 [~darius27@cpe-172-114-38-221.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
10:00 < glozow> hi
10:00 < b10c> hi
10:00 < raj> hello
10:00 < jnewbery> #startmeeting
10:00 < michaelfolkson> hi
10:01 < jnewbery> hi everyone! Feel free to say hi to let people know you're here (or not - lurking is also fine!)
10:01 < theStack> hi
10:01 < schmidty> howdy!
10:01 -!- Azorcode [~Azorcode@186-88-143-193.genericrev.cantv.net] has joined #bitcoin-core-pr-reviews
10:01 < glozow> yeehaw
10:01 < jnewbery> Today we're going to be looking at RBF and specifically PR 22665. Notes and questions are here: https://bitcoincore.reviews/22665
10:02 < emzy> hi
10:02 < jnewbery> Is anyone here for the first time?
10:02 < Azorcode> Hello Everyone
10:02 < merkle_noob[m]> Hi everyone.
10:03 < jnewbery> Alright, let's start with an easy question. Who had time to review the PR and notes/questions? (y/n)
10:03 < raj> y
10:03 < glozow> y
10:03 < michaelfolkson> ~0.5
10:03 < emzy> n only read the notes.
10:03 < theStack> 0.5y
10:04 < b10c> notes only
10:04 < schmidty> y
10:04 -!- aitorjs [~aitorjs@184.76.76.188.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
10:04 < jnewbery> any initial thoughts? Concept ACK/NACK?
10:05 < glozow> concept ACK because it’s unhelpful to report bip125-replacability when actually replacability is different
10:05 < glozow> rn you could be getting bip125-replaceable when actually it’s not
10:05 < raj> Seems like backward to me. Instead of fixing rpc reporting we should fix the behavior? But I guess we would get to the question. 
10:05 < michaelfolkson> I guess doing something about the "CVE" is the Concept ACK. And then the Approach ACK is which of the two PRs. If so it is a Concept ACK
10:05 < glozow> i disagree with that, although it seems counterintuitive
10:06 < glozow> in this case, bip125 was written to document the code, and it had this inaccuracy
10:06 < glozow> (afaik)
10:06 < raj> glozow, it is counterintuitive, would love to know more.. 
10:06 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
10:07 < michaelfolkson> There are a few discussions to be had on this one. If BIPs are being used by other implementations and Core code doesn't follow the BIP...
10:07 < jnewbery> this ties nicely with the next question: There’s an alternative PR 22698 which implements the inherited signaling as documented in BIP125. Which of the two approaches do you prefer? Why?
10:07 < jnewbery> (https://github.com/bitcoin/bitcoin/pull/22698)
10:07 -!- observer74 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
10:09 < raj> I would prefer to fix the behavior and follow BIP125, but thats just me.  
10:09 < jnewbery> it sounds like glozow prefers the approach in 22665. Anyone agree/disagree?
10:09 < jnewbery> raj: why do you think a BIP is important in this case?
10:09 < glozow> i don't think "following" the BIP that simply misdocumented the code should be a goal
10:10 < glozow> if we determine inherited signaling is a better policy, then that would make sense
10:10 < raj> jnewbery, Its not that the BIP is specifically important. But the ancestor inheritance seems like a logical thing to have. 
10:11 < glozow> would love to discuss this, why is inherited signaling better?
10:11 < jnewbery> raj: can you explain why inherited signaling is a logical thing to have?
10:11 < raj> Also there can be downstream wallets that depends on the BIP described behavior for their operation. Either directly on core, or via their own implementation. 
10:11 -!- chunkblob [~chunkblob@cpe-184-153-97-30.nyc.res.rr.com] has quit [Quit: Client closed]
10:11 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
10:12 < raj> jnewbery, because if I have an ancestor replaceable by fee, I would expect replacing it would also replace the descendants. Thus descendants naturally inherits the replacement.   
10:14 < michaelfolkson> ^ Personally agree
10:14 < darius27> if BIP 125 was merged, doesn't it mean it was decided at that point that that was the more desired behavior? And it seems like it was unintentional that bitcoin core did not implement this behavior. So yeah i would have thought it would make sense to implement BIP 125 instead
10:14 < glozow> that's a good point, thinking of replaceability as "this transaction could be evicted due to RBF"
10:15 < raj> Ya and this PR would tag such descendant replaceablity as "false". Which could be very confusing. 
10:16 < jnewbery> darius27: no, the wording in BIP125 was intended to be documentation of the behavior in Bitcoin Core. If anything, this is a docs bug
10:16 < darius27> jnewbery ah i see. Separately though, I agree with the points raj made
10:17 < michaelfolkson> jnewbery: Was that intention documented? Or have the BIP authors said that?
10:17 < jnewbery> michaelfolkson: yes
10:17 < jnewbery> https://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-03-18.59.log.html#l-147
10:18 < raj> jnewbery, but doesn't the fact that replaceability inheritance documented in the BIP irrespective of code behavior, makes that it a more intuitive behavior? One could equally argue that the code missed a behavior which is logical?  
10:19 < glozow> you can also think of replaceability as "can these transaction's inputs be re-spent in an RBF transaction"
10:19 < jnewbery> I think it's worth reviewing the discussion in https://github.com/bitcoin/bitcoin/pull/7222, which added the bip125-replaceable field to the wallet RPCs. It's a little subtle, but I think there are definitely arguments against saying that the descendant of a bip125-replaceable is itself replaceable
10:20 < theStack> side-question: are there any other cases of bitcoin improvements where the BIP was following/documenting the implementation, rather than the other way round?
10:20 < glozow> the question of "can this transaction be evicted from the mempool" is always yes
10:20 < raj> glozow, in that case doesn't this PR breaks that definition too? I would get "false" for transaction whose inputs are indeed RBF replaceable.  
10:20 < glozow> raj: you do? :O
10:20 < michaelfolkson> From scanning that IRC conversation log I think the BIP authors just agree to write a BIP after the code has been written rather than state they will write a BIP to document what the code does
10:21 < jnewbery> if the descendant's bip125-signalling ancestor is confirmed, then the descendant suddenly becomes non-replaceable
10:21 < glozow> michaelfolkson: uhhh but what else would they be writing the BIP about?
10:22 < michaelfolkson> Well in a world with multiple implementations that is the point of the BIPs. It isn't documentation of Core entirely (although it is hopefully that as well)
10:23 < jnewbery> theStack: I think often the BIP will be written in parallel with the implementation. There's often an "implementation" section of the BIP that links to an (unmerged) branch
10:23 < raj> glozow, let me know if i have it wrong, if I have a descendant with RBF disables, but have one of its ancestor RBF enables, replacing that ancestor would remove the descendant from mempool. Yet when I query its RBF status, I would get false. Isn't that correct?  
10:24 < jnewbery> raj: that's true, but the ancestor could also be conflicted and removed from the mempool, along with all of its descendants, regardless of whether they're signaling replaceability
10:24 < glozow> raj: so you have transactions A -> B where A is parent, B is child
10:24 < glozow> you're saying A is signaling RBF, B isn't
10:24 < glozow> but A is replaced -> B is evicted
10:24 < michaelfolkson> If another implementation comes along and implements it according to the BIP, it is a little awkward to say "Oh sorry you should have ignored the BIP and just copied what Core did"
10:24 < glozow> is that right?
10:24 < glozow> and B's RBF status is false, even though it could get evicted due to A being replaced
10:25 < jnewbery> remember that replaceability is simply a local policy. Miners or other nodes can decide what policy they have for replaceability, which may be BIP125, or something completely different
10:25 < glozow> right. and there's another world where A is mined without B. then B is no longer inheriting RBF from anybody, so it goes back to being false
10:26 < glozow> i don't think "maybe evicted due to RBF" and "may be replaced using RBF" are the same thing
10:26 < raj> On BIPS: I don't thinks BIPs are (or should) be written to document code behavior. BIPS are suppose to be standards that other parts of the industry can follow knowing that it will not make any breaking behavior change. Which is violated in this case.  
10:26 < jnewbery> I think it's unusual that a BIP was written for a local mempool policy. I agree that it should be documented, but a BIP doesn't seem like the right place for it. Implementers should be free to update their policy at any time, without reference to BIPs (again, those policies should be well documented)
10:26 < theStack> jnewbery: yes, i can remember seeing an implementation section some BIPs. i just thought that there is a rather strict rule that the BIP has to be merged first
10:27 -!- observer74 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Ping timeout: 250 seconds]
10:27 < sipa> BIPs are simply means of publishing ideas
10:27 < jnewbery> theStack: For consensus changes or P2P protocol changes, I'd agree - the specification (BIP) should be finalized before the code is merged into Bitcoin Core
10:27 < sipa> having a BIP merged helps, because it gives an unambiguous way of referring to that idea
10:28 < sipa> but that is all it does
10:28 < sipa> it's not an indication of quality
10:28 < sipa> or community acceptance
10:28 < raj> glozow, yes, that was what I was referring. 
10:28 < darius27> jnewbery - RE "I think it's unusual that a BIP was written for a local mempool policy".  Isn't this similar to having BIPs for standardness rules? Or am i missing something
10:28 < MarcoFalke> all of this will go away with full-rbf anyway (hides)
10:29 < glozow> sipa: do you think we should try to make any parts of mempool policy universal across the network?
10:29 -!- effexzi [uid474242@id-474242.charlton.irccloud.com] has joined #bitcoin-core-pr-reviews
10:29 < sipa> glozow: can we? :)
10:30 < michaelfolkson> sipa: I think that kind of perspective cripples the value of the BIPs personally. Why bother with them? Alternative implementations should just look at Core code as the BIPs are unreliable
10:30 < jnewbery> sipa: I think "an unambigous way of referring to that idea" is more useful when the idea is probably going to be mostly fixed (ie consensus or p2p protocol). For a policy, it's much more likely that implementers will make future changes in the implementation, in which case the BIP can potentially become more harmful than useful.
10:30 < sipa> michaelfolkson: i completely disagree
10:30 < sipa> michaelfolkson: other implementations should do what they think is right
10:30 < jnewbery> darius27: I'm not aware of any other BIPs for standardness/policy
10:30 < michaelfolkson> sipa: For BIPs on consensus and policy?
10:31 < glozow> sipa: e.g. RBF signaling, since wallets might take that into consideration when choosing nSequence numbers
10:31 < sipa> in particular, i don't think there is any problem with other implementations implementing BIP125 as-is, if they feel that's the right approach
10:31 < sipa> michaelfolkson: there are plenty of other BIPs i think are bad ideas
10:32 < sipa> the issue here is bitcoin core claiming it implementing bip125, not the fact that bip125 exists
10:32 < sipa> (i have no opinion on whether bitcoin core's policy or bip125 is a better one)
10:32 < raj> sipa, if a BIP is accepted, it should not be considered in general a bad idea right? Otherwise the BIP process is unreliable.  
10:32 < sipa> raj: *wrong*
10:32 < sipa> BIPs are for publishing ideas
10:33 < sipa> not for approving them
10:33 < sipa> sorry, there is no authority who can decide thos
10:33 < michaelfolkson> Lightning is a very different world (not one dominant implementation) but they seem to take greater care with their BOLTs and have a different perspective on what they are attempting to achieve
10:34 < sipa> that works with a small ecosystem with just 3 implementations :)
10:34 < raj> sipa, But there are BIPs at different status. Some are accepted some are drafts, some are rejected. Can a accepted BIP (an implemented) become a bad idea?  
10:34 < michaelfolkson> sipa: 6 last time I checked ;)
10:34 < MarcoFalke> raj: This is explained in BIP 2
10:34 < sipa> raj: accepted just means it's in use in multiple implementations afaik
10:34 < MarcoFalke> Any idea (that is loosely related to Bitcoin and is technically sound) can be written down as a BIP
10:35 < jnewbery> raj: there's nothing official about any of the BIPs. You can open a PR against the BIP respository and as long as it meets a minimum quality standard (in terms of formatting, etc, not whether it's a good idea), then it should get merged eventually: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-editor-responsibilities--workflow
10:35 -!- observer74 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
10:35 < darius27> jnewbery interesting, i didn't realize standardness/policy rules did not have BIPs. Thanks!
10:35 < jnewbery> This is very interesting discussion, but I'm going to suggest we move on to some more technical details of the PR :)
10:35 < michaelfolkson> "technically sound" needs an authority. I think this is a discussion for another day. This PR is only partly about BIPs
10:35 < jnewbery> Prior to this PR, there was a Chain interface member function isRBFOptIn(). This PR changes the caller to use SignalsOptInRBF() instead. Why is SignalsOptInRBF() a free function and not a member of the Chain interface class?
10:36 < jnewbery> and more generally, why is there a Chain interface class?
10:36 < raj> jnewbery, yes and there are BIPS that are marked FINAL. BIP125 is one such. What does that mean in this case? 
10:37 < sipa> i'm not all that happy personally about the status of BIPs; apart from consensus bips for which there is an objective determination of "in use", it seems the bip status mostly reflects whether the author took the time to update ot
10:37 < michaelfolkson> I'm trying to arrange a couple of meetings on the BIP process raj. Whenever I manage it come along ;)
10:38 < glozow> `isRBFOptIn` needs mempool, `SignalsOptInRBF` ust needs to look at the transaction
10:38 < michaelfolkson> But we should park it for now I think
10:38 < raj> michaelfolkson, agreed.  
10:38 < jnewbery> sipa: glozow: that's right. So what does that have to do with the Chain interface?
10:38 < jnewbery> sorry, not sipa, just glozow!
10:41 < jnewbery> ok, so the Chain interface is used by the wallet to access the blockchain and mempool state: https://github.com/bitcoin/bitcoin/blob/4fc15d15667d9d9c4fb5515ce73c05b4596298ec/src/interfaces/README.md#L5
10:41 < jnewbery> if we're considering a transaction's unconfirmed ancestors, then we need mempool state, so the wallet needs to go through the Chain interface
10:42 < jnewbery> if we're _just_ looking at the nSequence fields in the transaction itself, then we don't need any context, so we can just call a utility function
10:42 < jnewbery> Does that make sense to everybody?
10:42 < glozow> jnewbery: ya
10:42 < michaelfolkson> Yup
10:43 < jnewbery> ok, next question. Before this PR, the bip125-replaceable field could be yes, no, or unknown. The new replaceable field can only be true or false. Why is it never set to unknown?
10:43 < glozow> that reminds me i had question, what's rpc/server? is it server as in, for node stuff?
10:43 < glozow> i assumed stuff was moving so that wallet rpc could use it
10:43 < raj> jnewbery, yes. Can't we then have that function as a member of CTransaction? Since every transaction will have such an attribute? 
10:44 < jnewbery> raj: I think the idea is to keep CTransaction as mostly a struct. You can use an external function to interpret the meaning of the struct
10:44 < glozow> unknown was when we couldn't look at mempool ancestors, but now it doesn't matter
10:44 < raj> jnewbery, because we are not checking mempool any more. So the attribute is either true or false.  
10:45 < jnewbery> especially for something like bip125 replacebility, it's really not a property of the CTransaction, but rather how we decide to interpret the CTransaction
10:46 < jnewbery> glozow: I think rpc/server is code for running on the node. rpc/util may also be run in the bitcoin-cli client. I'm a bit rusty on that though
10:47 < raj> jnewbery, hmm, makes sense.
10:47 < jnewbery> I think maybe rpc/server is not accessible to the wallet, which is why the deprecated function needed to be moved to rpc/util
10:48 < jnewbery> Which leads us nicely to the next question. What is the IsDeprecatedRPCEnabled() function used for? Why does this PR move that function from rpc/server to rpc/util? Describe the process for deprecating RPC methods and fields. Why do we deprecate in this way?
10:50 < glozow> makes sense
10:50 < raj> jnewbery, it checks a list of strings to find deprecated methods. If a method is found in the list, then only corresponding functions are called and results are displayed (with an warning that it has been deprecated). Which gives a nice non breaking interface for downstream users to adopt the breaking changes.   
10:51 < jnewbery> raj: yes. So why don't we just remove the fields immediately? Whay benefits are there to deprecating over multiple releases?
10:51 < raj> jnewbery, to reduce catastrophe? :D
10:52 < michaelfolkson> So third party applications have time to migrate off relying on them
10:52 < jnewbery> michaelfolkson: right
10:53 < jnewbery> ok, final question. Do you agree that we should use a deprecation process to change the name from bip125-replaceable to replaceable? Why don’t we just update the value that is returned in bip125-replaceable?
10:53 < raj> downstream folks would get time to upgrade, and still have old methods available to use for time.  
10:53 -!- aitorjs [~aitorjs@184.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-pr-reviews
10:53 < raj> jnewbery, as its not following BIP125 anyway, so the name change makes sense to me. 
10:55 < darius27> would it also be bad/confusing to keep the name of the field the same while changing its behavior?
10:55 < jnewbery> I think we may also want to add a note to https://github.com/bitcoin/bitcoin/blob/4fc15d15667d9d9c4fb5515ce73c05b4596298ec/doc/bips.md#L35 that we don't implement BIP125 exactly according to the spec
10:55 < jnewbery> darius27: yes. I agree!
10:55 < jnewbery> ok, 5 minutes left. Any final questions before we wrap up?
10:56 < michaelfolkson> We didn't (really) discuss the alternative PR but I think long term we go with the superior solution (assuming we can get consensus on what the superior solution is). And if that means changing the code and/or the BIP we do that
10:56 < michaelfolkson> I'm in the raj camp and think the BIP actually outlines the superior solution. If it didn't we should change the BIP
10:57 < jnewbery> michaelfolkson: we discussed the two different approaches for the first half hour
10:57 < raj> jnewbery, is this PR gets merged, would that mean BIP125 also needs to be updated (going with the logic that its code behavior documentation)? 
10:57 < michaelfolkson> jnewbery: Right but some of the answers to these questions are dependent on which approach/PR you go with
10:58 < michaelfolkson> For both a rename seems necessary
10:58 < jnewbery> raj: I'm not sure. As sipa says, BIPs are just there to document ideas. BIP125 remains unchanged as an idea whatever we decide to implement in Bitcoin Core.
10:58 < sipa> BIP125 is a name given to an idea; bitcoin core does not implement that idea; the solution is either documenting that bitcoin core does not implement bip125, or perhaps writing another BIP that does (if people feel that idea is BIP-worthy). Under no circumstances can BIP125 be changed to suddenly mean something else
10:58 < sipa> there are many other BIPs that Bitcoin Core doesn't implement
10:58 < michaelfolkson> Ok that's fine. So if in raj camp there should be a new BIP
10:59 < sipa> if it were in draft status, and still subject to change, that'd be different, but changing BIP125 now is both impossible (per BIP2) and would be extremely confusing
11:00 < michaelfolkson> If in glozow camp should there be new BIP?
11:00 < michaelfolkson> For what Core has implemented?
11:00 < sipa> i'm not convinced this sort of policies need a BIP in the first place
11:00 < jnewbery> I don't think a new BIP is necessary - as long as Bitcoin Core clearly documents its policy, that's enough. There's no reason it should be in the BIPs repository.
11:00 < michaelfolkson> Ok
11:01 < jnewbery> michaelfolkson: please stop trying to put people in "camps"
11:01 < raj> Is there any reason why we don't wanna have RBF inheritance?  
11:01 < jnewbery> ok, that's time. Thanks everyone!
11:01 < emzy> Thank you jnewbery
11:01 < jnewbery> #endmeeting
11:01 < sipa> raj: i personally have no opinion on that
11:01 < glozow> thanks jnewbery
11:01 < raj> thanks jnewbery, it was a good discussion. 
11:02 < glozow> where's a good place to document policy?
11:02 < michaelfolkson> jnewbery: Just shorthand for a viewpoint
11:02 < svav> Thanks
11:02 < b10c> thanks, enjoyed the discussion
11:02 < michaelfolkson> I could have said Core vs BIPs but that would have been more incendiary I think
11:02 < jnewbery> glozow: https://github.com/bitcoin-core/bitcoin-devwiki/wiki
11:03 < darius27> Thanks jnewbery and everyone else! This was super interesting and educational session. For the record I also think inherited signaling makes sense. My impression is the benefit of RBF is a kind of soft protection to make it harder for a transaction you're expecting to receive to disappear, rather than whether another tx will spend the same input.
11:03 < glozow> ah yes
11:04 < michaelfolkson> Thanks jnewbery!
11:06 < merkle_noob[m]> Thanks jnewbery and everyone. Learnt a lot, as usual...
11:06 < michaelfolkson> We didn't get onto whether this is a CVE or not. That was the other can of worms :)
11:09 -!- observer74 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Quit: Connection closed]
11:09 < sipa> something is a CVE when someone files it as a CVE :)
11:13 < michaelfolkson> Is there a CVE authority who accepts it as a CVE? :facepalm: Authority turtles all the way down
11:13 < sipa> yes, but the requirement isn't that it's serious or so
11:13 < sipa> you just request a number
11:13 < sipa> like BIPs, they're just a way of uniquely referring to an idea
11:13 < sipa> and in the case of CVEs, a possibly not-fully-disclosed idea
11:14 < michaelfolkson> There are lots of very low quality CVEs? Next to nonsense?
11:14 < michaelfolkson> Not that any BIPs are next to nonsense (I think/hope)
11:14 -!- Azorcode [~Azorcode@186-88-143-193.genericrev.cantv.net] has quit [Quit: Connection closed]
11:15 < sipa> i don't think there are any very low quality/nonsense BIPs (the editing process should prevent that), but there are some that i personally think are very bad ideas
11:16 < sipa> and to be clear, i don't think this is a problem
11:16 < sipa> i just wish people would stop thinking "having a BIP number assigned == good/community acceptance/encouraged/..."
11:17 -!- Henrik [~textual@84.212.107.177] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
11:18 < michaelfolkson> It means it has met a certain bar. On the flipside I wish people would stop thinking that having zero bar wouldn't result in an absolute mess. Most of the obviously crazy ideas didn't get BIP numbers over the years
11:18 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds]
11:19 < sipa> right, but the bar is editorial: has the idea/writeup followed the process
11:19 < sipa> not: is the idea good
11:19 < michaelfolkson> So where's the proof of stake BIP? Or the increase block reward BIP?
11:19 < michaelfolkson> We avoided them somehow
11:20 < pinheadmz> michaelfolkson unoffiically BIP 248 ;-)
11:20 < pinheadmz> PoS BIPs die on the mailing list all the time
11:20 < michaelfolkson> The obviously terrible ideas didn't get numbers. It is fine that some bad ideas got numbers, you often can't tell if it definitely isn't a good idea at the time
11:30 < michaelfolkson> I think the bar for the quality of the idea and getting a number has held up well. The quality of the BIP after getting a number not as well. I think that's a side effect of the perspective that a BIP isn't reliable and is just outdated Core documentation
11:30 < sipa> i can't comprehend where you get that
11:31 < sipa> BIPs aren't documenting Bitcoin Core's behavior
11:31 < sipa> tons of BIPs aren't even ever implemented in Bitcoin Core, and many aren't even intended to ever be implemented by it
11:31 < michaelfolkson> Earlier in the PR review club that view was expressed (I think)
11:32 < michaelfolkson> It is hard, there's lot of subtlety that many people (including me) don't quite understand
11:32 < sipa> i think BIP125 is a bit of an exception, in that people thought the policy implemented at the time was sufficiently useful to document it as a standard
11:33 < sipa> and a mistake was made in doing that
11:33 < sipa> but that doesn't make BIP125 a description of Bitcoin Core's behavior or documentation of it
11:33 < sipa> it's a description of an idea people thought was valuable
11:34 < michaelfolkson> Ok. Makes sense, thanks
12:05 -!- VzxPLnHqr [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has quit [Remote host closed the connection]
12:05 -!- VzxPLnHqr [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has joined #bitcoin-core-pr-reviews
12:06 -!- aitorjs [~aitorjs@184.76.76.188.dynamic.jazztel.es] has quit [Ping timeout: 250 seconds]
12:10 -!- darius27 [~darius27@cpe-172-114-38-221.socal.res.rr.com] has quit [Quit: Ping timeout (120 seconds)]
12:12 -!- raj [~raj_@103.77.139.219] has quit [Quit: Leaving]
12:17 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
12:18 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
12:43 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
13:05 < muhblockchain> michaelfolkson: this rule can be memorized by an easy mnemonic
13:05 < muhblockchain> "even shitty ideas like roger ver's bitpay's https-payment-thing, can get a BIP number"
13:05 < muhblockchain> ok not really a mnemonic, but it works ;)
13:08 -!- meshcollider [meshcollid@user/meshcollider] has quit [Remote host closed the connection]
13:27 -!- aitorjs [~aitorjs@184.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-pr-reviews
13:29 -!- effexzi [uid474242@id-474242.charlton.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:31 -!- meshcollider [meshcollid@jujube.ircnow.org] has joined #bitcoin-core-pr-reviews
14:36 -!- meshcollider [meshcollid@jujube.ircnow.org] has quit [Changing host]
14:36 -!- meshcollider [meshcollid@user/meshcollider] has joined #bitcoin-core-pr-reviews
14:42 -!- aitorjs [~aitorjs@184.76.76.188.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
15:33 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
15:35 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
16:24 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
16:25 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
16:47 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
16:48 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 244 seconds]
18:05 -!- b10c [uid500648@id-500648.charlton.irccloud.com] has quit [Quit: Connection closed for inactivity]
19:39 < harding> Hi.  Sorry I wasn't here for the meeting; as the person who made the mistake which led to this mess, I see I could've clarified a few things.  BIP125 fails to do what its authors and reviewers set out to accomplish, which is *clearly* document the behavior of Bitcoin Core surrounding opt-in RBF.  I think saying that it describes different behavior than what Bitcoin Core implemented misses an important point: my description of a 
19:39 < harding> misunderstanding of that behavior passed review by the person who wrote that code (Peter Todd) and one of the highly capable reviewers of that code (Suhas Daftuar).  I haven't talked to either of them about how that happened in detail, but I think that if you look at the BIP125 bullet point about inherited signaling and BIP125 rule 1, the description isn't as much directly wrong as it is *ambiguous*.  It *is* possible to replace the 
19:39 < harding> child of an unconfirmed parent in Bitcoin Core today---just replace the parent first.  That's what the code comment I misinterpreted described and my guess is that, when petertodd and sdaftuar reviewed my garbeled interpretation, they fit that text into their existing understanding of the code.  It seems that everyone else has read the text in the way I intended (which was counterfactual), but I think the real problem with BIP125 is the
19:39 < harding>  ambiguity, not the fact that most people read it as descrbing something different than what Bitcoin Core implemented.  If I had writen the text a little bit clearer, I'm sure either Pete or Suhas would've detected my error back in 2015 and I could instead today be hiding with MarcoFalke while interjecting pleas for full RBF.
21:21 -!- VzxPLnHqr [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has quit [Remote host closed the connection]
21:21 -!- VzxPLnHqr [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has joined #bitcoin-core-pr-reviews
21:28 -!- VzxPLnHqr [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has quit [Remote host closed the connection]
21:29 -!- VzxPLnHqr_ [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has joined #bitcoin-core-pr-reviews
21:35 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 250 seconds]
21:48 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
21:56 -!- Netsplit *.net <-> *.split quits: ghost43_, hex17or
22:04 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
22:06 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #bitcoin-core-pr-reviews
22:09 -!- VzxPLnHqr_ [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has quit [Ping timeout: 252 seconds]
22:34 -!- DeanGuss [~dean@user/deanguss] has quit [Ping timeout: 268 seconds]
23:10 -!- raj [~raj_@103.77.139.233] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Aug 26 00:00:49 2021