--- Log opened Wed Sep 22 00:00:15 2021
00:40 -!- dunxen [~dunxen@gateway/tor-sasl/dunxen] has quit [Remote host closed the connection]
01:33 -!- Henrik [~textual@84.212.107.177] has joined #bitcoin-core-pr-reviews
08:42 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has quit [Ping timeout: 276 seconds]
08:44 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #bitcoin-core-pr-reviews
09:09 -!- pg2 [uid518209@id-518209.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
09:20 -!- Pastaa [~Pastaa@182.57.76.213] has joined #bitcoin-core-pr-reviews
09:29 -!- shoryak [~shoryak@223.227.74.40] has joined #bitcoin-core-pr-reviews
09:46 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:49 -!- kexkey [~kexkey@static-198-54-132-91.cust.tzulo.com] has joined #bitcoin-core-pr-reviews
09:50 -!- ziggie [~ziggie@user/ziggie] has joined #bitcoin-core-pr-reviews
09:54 -!- lightlike [~lightlike@user/lightlike] has joined #bitcoin-core-pr-reviews
09:58 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:58 -!- dunxen [~dunxen@gateway/tor-sasl/dunxen] has joined #bitcoin-core-pr-reviews
10:00 < glozow> #startmeeting
10:00 < jnewbery> hi!
10:00 < ziggie> hi
10:00 < dunxen> hi!
10:00 < glozow> hello friends! welcome to PR review club!
10:00 < willcl_ark> hellooo
10:00 < dunxen> yay, policy!
10:00 < glozow> we’re looking at https://github.com/bitcoin/bitcoin/pull/22871 today
10:00 < lightlike> hi
10:00 < shoryak> hii
10:01 < glozow> did anyone get a chance to review the PR? y/n
10:01 < jeremyrubin> gm
10:01 < svav> hi
10:01 < ziggie> n
10:01 < jeremyrubin> y
10:01 < lightlike> y
10:01 < dunxen> not in depth
10:01 < willcl_ark> y
10:02 < glozow> o! is it anyone’s first time btw? :)
10:02 < ziggie> yes mine
10:02 < shoryak> yes mine first time 
10:02 -!- rockslide [~rockslide@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
10:02 < jnewbery> welcome ziggie! welcome shoryak!
10:02 < glozow> OOO welcome ziggie and shoryak!!
10:03 < jeremyrubin> 👋 shoryak
10:03 < glozow> https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/ i might also link this blog post which was written by the PR author
10:03 -!- nodejsjs [~nodejsjs@ip5f5bd6dd.dynamic.kabel-deutschland.de] has joined #bitcoin-core-pr-reviews
10:03 < svav> To the new guys, how did you find out about PR club?
10:03 < jnewbery> feel free to ask questions any time. There are some tips on attending your first review club meeting here: https://bitcoincore.reviews/your-first-meeting :)
10:03 < jeremyrubin> note the blog post is out of date to the PR w.r.t. the solution
10:03 < schmidty> hi
10:04 < glozow> and i also have some notes here: https://bitcoincore.reviews/22871
10:04 -!- Azorcode [~Azorcode@186-88-147-33.genericrev.cantv.net] has joined #bitcoin-core-pr-reviews
10:04 < glozow> okie dokie: Can anyone who reviewed the PR summarize the changes being proposed?
10:04 < Azorcode> Hello everyone 
10:04 -!- Sachin [~Sachin@216.15.60.10] has joined #bitcoin-core-pr-reviews
10:05 < willcl_ark> We want to modify mempool acceptance so that un-upgraded nodes from the future might not accidentally create consensus-invalid blocks using transactions that entered their mempool
10:06 < glozow> willcl_ark: yes! to be more specific though, what consensus rule(s) would these un-upgraded nodes be missing?
10:07 < svav> NOP - SOmething Op Code what does the N stand for?
10:07 < willcl_ark> If we tightened the rules (with a soft fork), then they would still blindly accept future-invalid transactions as valid
10:07 < dunxen> consensus rules around the unused bits of nSequence?
10:08 < willcl_ark> NOP = No Operation to me :)
10:08 -!- Zero-1729 [~Zero-1729@102.91.5.138] has joined #bitcoin-core-pr-reviews
10:08 < sipa> https://en.wikipedia.org/wiki/NOP_(code)
10:08 < lightlike> they could use OP_CSV in combination with the disablelocktime flag freely, thinking it does nothing, while the upgraded nodes enforce some new consensus rules
10:08 -!- Zero-1729 [~Zero-1729@102.91.5.138] has quit [Client Quit]
10:08 < glozow> lightlike: exactly!
10:09 -!- Zero-1729 [~Zero-1729@102.91.5.138] has joined #bitcoin-core-pr-reviews
10:09 < jeremyrubin> yep that's one part; the PR also does another thing too
10:09 < Sachin> Could it also be that the nSequence triggers other rules as well? 
10:09 < jeremyrubin> yep!
10:10 < glozow> yes, we should highlight that this is for nSequence numbers and for arguments to OP_CSV
10:10 < ziggie> so are we going to declare some transactions as non-standard with this PR ?
10:11 < glozow> ziggie: correct, it means transactions that set the locktime disable flag are now non-standard
10:11 < glozow> (with the changes in this PR, i mean)
10:11 < ziggie> glozow thanks 
10:11 < glozow> quick conceptual question: What is the difference between policy and consensus rules?
10:12 < willcl_ark> So it's the case that currently people can pass (or store) arbitrary data for CSV, as long as they've disable it, and it just gets OP_NOP-ed (and they use the data for their own purpose)?
10:12 -!- Guest7230 [~Guest72@148.69.98.142] has joined #bitcoin-core-pr-reviews
10:12 -!- Zero-1729 [~Zero-1729@102.91.5.138] has quit [Client Quit]
10:12 -!- Zero-1729 [~Zero-1729@102.91.5.138] has joined #bitcoin-core-pr-reviews
10:12 < shoryak> is policy for mempool acceptance and consensus for block acceptance ?
10:13 < jeremyrubin> it's actually a bit worse than that willcl_ark
10:13 < Sachin> willcl_ark I believe that is what this PR implements. It should've been the case before 
10:13 -!- Zero-1729 [~Zero-1729@102.91.5.138] has quit [Client Quit]
10:13 < jeremyrubin> it's that any data that is not defined to be interpreted in the CSV argument or nSequence (which are, tho similar, very different fields) are uninterpreted
10:13 < dunxen> policy is around what we accept into our mempool and propagate through the network, some policy invalid txs might still be consensus valid (unless some future soft fork makes that not the case)
10:14 < willcl_ark> ah
10:14 < ziggie> willcl_ark so a clever/aother way of doing a OP_RETRUN?
10:14 < jeremyrubin> doesn't really matter if disabled/enabled, but disabled is a wide set of ones with no rules
10:14 < glozow> shoryak: dunxen: correcto! policy is only applied to unconfirmed transactions we're evaluating for our mempool. and policy is strictly stricter than consensus.
10:15 < willcl_ark> It's a nice model though, to have a stricter mempool which you "know" you can freely select only valid transactions from when constructing a block.
10:15 < jeremyrubin> ziggie yeah, the Lightning Network currently does this using the nSequence (not CSV arg) field
10:15 < glozow> next question: Why do we discourage the usage of upgradable NOPs in policy? How is this implemented?
10:15 < ziggie> policy = declare a tx as standard, consensus= declare tx as valid ?
10:16 < jeremyrubin> ziggie https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#commitment-transaction
10:17 < Sachin> To protect users from potentially creating transactions that are later restricted by a softfork, making them harder (or impossible) to spend 
10:17 < lightlike> is the term "policy" only used in the context of tx acceptance? Or could it be used for anything that is our own business and doesn't violate consensus, e.g. p2p stuff etc.?
10:18 < michaelfolkson> hi
10:18 < willcl_ark> +1 Sachin
10:18 < jeremyrubin> Sachin are there other users who would have issues other than spenders?
10:19 < glozow> lightlike: do you mean like, if we have policies that aren't about transaction validation?
10:20 < willcl_ark> I also associate "policy" with my local node settings, which might be configurable to some degree whilst still remaining consensus-valid. Although, as most nodes run the same (default) policy rules, if you want your tx to be propagated then you want your policy to match others' policies too
10:20 < glozow> we have limits on the number of ancestor/descendants transactions can have in our mempool, which is policy but not necessarily related to the tx itself
10:20 < lightlike> i don't know, we have many local rules that are similar, i was just asking if they would be called policy, or whether that term is usually reserved for mempool acceptance issues
10:21 < glozow> we sometimes configure our node with transaction rules that aren't really policy-related, like our wallet maximum fee
10:21 -!- sanket_cell [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews
10:21 < Sachin> jeremyrubin I guess receivers could unknowingly receive to a script that they dont fully understand? 
10:21 < glozow> i also wouldn't consider something like "i will only keep 100 orphan transactions" policy
10:21 < jeremyrubin> Sachin well not quite, if you make your own addresses 
10:22 < jeremyrubin> think about how the issue would effect miners
10:22 < lightlike> jeremyrubin: also miners that have not upgraded might mine blocks that are seen as invalid by upgraded nodes and therefore not accepted
10:22 < jeremyrubin> lightlike yep! you got it
10:22 < Sachin> Ah, thank you 
10:23 -!- Azorcode [~Azorcode@186-88-147-33.genericrev.cantv.net] has quit [Ping timeout: 260 seconds]
10:23 < glozow> good answers :)
10:24 < glozow> ok let's now go over some pros and cons of this PR, for the sake of deciding whether we want to "concpet ack" it
10:24 < willcl_ark> Would it be fair to say that a lot of policy rules are local anti-DOS measures?
10:24 < michaelfolkson> Customary Suhas StackExchange link share: https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c
10:24 < glozow> What are some reasons to discourage use of the locktime disable flag in policy? What are some reasons NOT to discourage use of the locktime disable flag in policy?
10:25 < glozow> willcl_ark: yes, a lot of them are
10:25 < Sachin> willcl_ark many, but some are also for protecting users and making soft forks safer
10:25 < Sachin>  and miners
10:25 < willcl_ark> (except the ones we are discussing today!)
10:25 < michaelfolkson> From Core's perspective policy is defined here: https://github.com/bitcoin/bitcoin/tree/master/src/policy
10:25 < jeremyrubin> glozow i think it makes sense to talk about the nSequence and CSV commits seprately in terms of pro/con
10:25 < willcl_ark> right
10:25 < sipa> michaelfolkson: not solely
10:25 < michaelfolkson> But as a user I guess you could broaden the definition of policy
10:25 < michaelfolkson> sipa: Oh cool
10:26 < glozow> i recently also came across this explanation of policy: https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a#policy (the rest of the document is an interest read too)
10:27 < michaelfolkson> Looks good :)
10:27 < glozow> jeremyrubin: fair enough, i'll rephrase. We have 4 questions to talk about: what are the pros/cons of discouraging the use of the locktime disable flag in nSequence/CSV args?
10:28 < jeremyrubin> 🙏
10:29 < dunxen> i saw that lightning uses the disable bit and some unused bits for encoding the commitment number, so that would prevent commitment transactions being broadcast?
10:29 < lightlike> a con would be some people out there already using it for something. this seems to be the case for the nSequence/lightning?
10:30 < glozow> dunxen: indeed. discouraging something in policy means that Bitcoin Core nodes will not relay them, so we have to be careful not to exclude entire applications' transactions if they rely on being able to use nSequence as they please
10:31 < Sachin> Would this pr truly prevent commitment txs from being broadcast? or only commitment Txs which use CSV
10:32 < svav>  What is Bitcoin locktime please?
10:33 < ziggie> svav makes a transaction not valid until a specific time in the future is reached
10:33 < willcl_ark> I think of sanket1729's questions posted before the meeting by jeremy at this point? Whilst the interpreter changes seem logical, do we really envision further overloading these OP codes with more rules in the future?
10:33 < svav> Thanks ziggie!
10:34 < glozow> svav: "locktime" generally refers to spending conditions that are like "this UTXO cannot be spent until X time in the future"
10:34 < jeremyrubin> svav confusingly there's a concept of a 'lock time' and a nLockTime, which is a specific kind of 'lock time'
10:34 < jeremyrubin> always good to clarify which one is being discussed
10:34 < glozow> CSV is for relative locktime, so the time constraint is based on the time/#blocks between the time the UTXO is confirmed and when it's spent
10:34 < ziggie> so we have to be very conscious in the feature, introducing something like BIP 68, allowing something to be disabled? 
10:34 < ziggie> *future
10:35 < lightlike> I also didn't understand the effect on the lightnig network: would this PR basically shut down the LN in its current form, could there be some exceptions for the specific LN use case?
10:35 < ziggie> because people will use it for their own purposes, and nobody knows I they will  
10:35 < michaelfolkson> Sachin: Commitment transactions only go onchain if close isn't cooperative. Otherwise a simple 2-of-2
10:35 < jeremyrubin> ziggie i would go as far as to say if we can't make this policy change now, we can never use these bits ever again in the future 
10:35 < jeremyrubin> (for a consensus purpose)
10:36 < jeremyrubin> the PR has no impact on the lightning network, does anyone know why
10:36 < michaelfolkson> (I think... doubting myself now). So only affects uncooperative closes and justice transactions
10:36 < glozow> jeremyrubin: i disagree with that. we can still use these bits in the future, gated on a different nVersion number, which doesn't have the "not discouraged in policy" problem
10:36 < jeremyrubin> glozow i don't think that's true actually
10:37 < glozow> michaelfolkson: to me, it seems _more_ dangerous for Bitcoin Core tx relay policy to only impact non-cooperative Lightning Network closes
10:38 < glozow> or just in general, tx relay being inconsistent like that
10:38 < jeremyrubin> the pr has no effect on lightning network closes?
10:38 < michaelfolkson> glozow: Well yeah those are the ones which are most important. Cooperative closes aren't emergency or time pressured
10:38 < glozow> this might be a good time to bring in sanket's suggested question: Does it make sense to change something for an unplanned upgrade?
10:39 < sipa> 13:35:44 < jeremyrubin> ziggie i would go as far as to say if we can't make this policy change now, we can never use these bits ever again in the future
10:39 < sipa> i don't understand this
10:40 < sipa> why can't the policy change be made when a use for the bits is being rolled out?
10:40 < jeremyrubin> So there are a couple reasons
10:40 < michaelfolkson> glozow: Upgradeability is a nice to have if there are no downsides (even if you can't imagine what the upgrade will be). But there does appear to be downsides with this
10:41 < jeremyrubin> A) When you make an upgrade in the future, you want un-upgraded mining nodes to not accept invalid txns to the mempool
10:41 < michaelfolkson> I personally can't imagine what the future upgrade would be here (though interested in ideas)
10:41 < sipa> jeremyrubin: sure, it'd need to time - but consensus changes take time anyway
10:41 < jeremyrubin> so in order for that to be the case, you want the tightening of rules to occur far in the past so that there's plenty of upgrade time
10:42 < jeremyrubin> The longer you wait, the more likely it is that more metadata use cases proliferate too, so it's better to make expectations clearer
10:42 < glozow> indeed, this is a very tight restriction on our tx relay policy. i don't think the downsides are even very clear right now; efforts should be made to understand whether applications are relying on an assumption that they can use the 31st bit of nSequence
10:42 < jeremyrubin> W.r.t. TX Version, it's not a sound upgrade path for the reasons i laid out here https://github.com/bitcoin/bitcoin/pull/22871#issuecomment-915709410
10:42 < willcl_ark> But that could boil down to "because we didn't do this 5 years ago we can't do that now", right?
10:42 < dunxen> i'm struggling to see what was changed so this PR does not affect unilateral closes on lightning
10:43 < jeremyrubin> Essentially, you can't really control for tx version at the script level (IMO) to fix this.
10:43 < jeremyrubin> dunxen https://github.com/bitcoin/bitcoin/blob/e8eab747192bd330e67bff1222bb851bc515b134/src/policy/policy.cpp
10:44 < jeremyrubin> see         case CTxIn::SEQUENCE_ROOT_TYPE::UNCHECKED_METADATA
10:45 < jeremyrubin> that exempts the LN's bolt defined use case of 0x80-------- nSequences as being just metadata with no meaning for consensus 
10:45 < sipa> jeremyrubin: hmm, and couldn't a different opcode be used instead?
10:45 < glozow> it also seems like an abstraction violation to force our policy code to enumerate the types of LN sequences...
10:45 < sipa> (a new OP_CSV2, say)
10:45 < michaelfolkson> willcl_ark: I think if there was a proposed upgrade in future that people wanted the fact that this change wasn't done 5 years ago wouldn't impact it. Of course it would take longer than if we did the change now (but we don't know what the upgrade would be now if it ever arrives)
10:46 < jeremyrubin> glozow well we already have policy exemptions for LN in the mempool, this is similar. any app can use the seq metadata field
10:46 < glozow> are there other applications that use nSequence? have we observed 0 usage of the disable locktime flag for a few years?
10:46 < jeremyrubin> sipa a new CSV opcode would work; but i also think the impacts on the CSV arg are lesser than the nSequence field
10:47 < jeremyrubin> I think the nSequence field semantics as it pertains to v1 CSV have to be fixed given that v1 CSV is tx.nVersion >= 2
10:47 < sipa> jeremyrubin: right, but for the nSequence field, new semantics can be introduced with tx version
10:47 < sipa> ?
10:47 < jeremyrubin> nope I do not think so
10:47 < jeremyrubin> since it would allow stealing funds prematurely from a csv were the semantics to change
10:47 < glozow> jeremyrubin: could you explain why, for the nSequence field specifically, it wouldn't be sufficient to gate on a new nVersion number?
10:48 < jeremyrubin> Yes
10:48 < jeremyrubin> Imagine that *today* i create an output which is IF <2 years> CSV <backuip> Checksig ELSE <normal> Checksig ENDIF
10:48 < glozow> ok since we're running low on time, next question for the review clubbies is: Do you think this change (discouragement of setting the most significant bit) should be applied to nSequence numbers, CSV values, both, or neither? Why?
10:48 < lightlike> has someone done analysis of the blockchain if (and with which values) nSequence is currently used?
10:49 < jeremyrubin> and then you switch to tx.nVersion 3 
10:49 < jeremyrubin> my output is spendable in tx.nVersion 3
10:49 < jeremyrubin> and if nVersion 3 undefines the CSV semantics as they were prior
10:49 < jeremyrubin> then you'd trigger backup prematurely
10:49 < glozow> lightlike: good question. I would also feel much more comfortable reasoning about this PR if there was such an analysis done
10:49 < jeremyrubin> so whatever new semantic for CSV exists in nversion 3 has to be compatible with old scripts
10:50 < jeremyrubin> you could do something like nVersion 3 must only be segwit v2 (not v1, v0) and that might work? But that hurts fungibility
10:51 < Sachin> jeremyrubin Sorry to backtrack but I don't understand why this doesnt affect LN commitment txs 
10:51 < jeremyrubin> Sachin LN commitment txns specifically use 0x80 prefixed sequence numbers
10:51 < glozow> why wouldn't a new semantic for CSV scripts be compatible with old scripts?
10:51 < jeremyrubin> the PR applies no rules when the top bits are exactly 0x80
10:51 < Sachin> ah, thank you
10:52 < jeremyrubin> because if an old output could be spent in tx.nVersion 3 with different semantics, it would disrupt the timing of that old output
10:52 < michaelfolkson> Meh not convinced on the fungibility hurt, every SegWit version introduces new rules that supposedly hurt fungibility (of course they do when they are first introduced but that's the cost of a new SegWit version)
10:53 < jeremyrubin> michaelfolkson it's different, you're talking about fungibility from privacy v.s. cospendable fungibility
10:53 < jeremyrubin> one is much worse than the other
10:53 < michaelfolkson> Hmm ok
10:53 < jeremyrubin> glozow so the backup clause could either be made available prematurely or too late (or never) under tx.nVersion 3
10:53 < glozow> cospendability? you mean spending a "old CSV" and "new CSV" in the same tx?
10:54 < jeremyrubin> nope, it would be any pre segwit v2 (not v1, v0) output in the same tx as new (maybe could limit to leaf versions in v1)
10:54 < jeremyrubin> too late is fine, never is fine (just use tx nversion 2), but too early breaks the spec
10:56 < jeremyrubin> it maybe makes it more intuitive to think about it like "could we define signatures as always being valid in tx.nVersion 3?"
10:56 < jeremyrubin> we cannot do that, because then any miner could mine a block stealing all the coins\
10:57 < jeremyrubin> we need to preserve some semantics across tx version for output types.
10:57 < jeremyrubin> and nSequence and CSV arg are a part of that, or else it may premit theft
10:57 -!- nodejsjs [~nodejsjs@ip5f5bd6dd.dynamic.kabel-deutschland.de] has quit [Ping timeout: 252 seconds]
10:58 < glozow> afaik the current CSV semantics allow any nversion >=2
10:58 < jeremyrubin> yep; that's part of why this problem exists
10:58 < dunxen> glozow: i think i'd need to look at this more closely before I have an answer for your last question haha
10:59 < jeremyrubin> i think harding thought it was just nVersion == 2
11:00 < jeremyrubin> but because it's >= 2, the rules need to stay largely the same on all future versions unless we do the tx.nVersion blocks inputs that are not segwit v2 or newer or something
11:00 < glozow> haha no problem. i hope people have some food for thought around how to reason about this PR conceptually
11:00 < lightlike> so you think it was a mistake not to just use nVersion=2?
11:01 < glozow> given that BIP68 uses nVersion >= 2, i'd say there isn't really a problem with having an "old CSV" input inside a transaction with version 3
11:01 < jeremyrubin> well there isn't if you don't change nSequence semantics :)
11:01 < jeremyrubin> but that's the crux of this, which is preserving upgradability 
11:02 < glozow> looks like we're out of time - the final 2 questions are around the approach of the PR, since it requires a lot of unit tests to be loosened
11:02 < glozow> they are left as exercise to the reader i guess :P
11:02 < glozow> #endmeeting
11:02 < jeremyrubin> i have to bounce, but i can answer any follow ups later today, just tag me
11:02 < lightlike> thanks glozow!
11:02 < michaelfolkson> Thanks glozow jeremyrubin, nice work
11:02 < dunxen> thank you glozow and jeremyrubin!
11:02 < willcl_ark> thanks glozow
11:02 < svav> Thanks
11:03 < ziggie> cool thanks for the answers , will look in this PR more closely 
11:03 < shoryak> thanks glozow and jeremyrubin 
11:03 < shiza> Sorry what does CSV stand for in the context of this meeting? Check Signature Verify?
11:04 < ziggie> Check Sequence Verify
11:04 < shiza> Thanks!
11:05 < willcl_ark> shiza: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
11:05 < svav> Would be great if the acronyms could be defined in the meeting notes, but appreciate it's more effort
11:05 -!- Pastaa [~Pastaa@182.57.76.213] has quit [Quit: Connection closed]
11:05 < willcl_ark> Also see often-related BIP 68: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
11:06 -!- Sachin [~Sachin@216.15.60.10] has quit [Quit: Connection closed]
11:06 < shiza> It's I just landed here.
11:07 < michaelfolkson> The Optech topics page acts as somewhat of a glossary https://bitcoinops.org/en/topics/
11:08 < michaelfolkson> And the timelocks topics page needs a contribution :) https://bitcoinops.org/en/topics/timelocks/
11:11 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:34 < jeremyrubin> ok i have another couple minutes if anyone has any other followups
11:35 -!- koolazer [~koo@user/koolazer] has quit [Ping timeout: 252 seconds]
11:51 -!- provoostenator [~quassel@user/provoostenator] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
11:52 -!- ziggie [~ziggie@user/ziggie] has quit [Quit: Client closed]
11:53 -!- provoostenator [~quassel@user/provoostenator] has joined #bitcoin-core-pr-reviews
12:07 -!- rockslide [~rockslide@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews []
12:13 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:32 -!- Guest7230 [~Guest72@148.69.98.142] has quit [Quit: Connection closed]
12:50 -!- shoryak [~shoryak@223.227.74.40] has quit [Quit: Connection closed]
13:19 < harding> jeremyrubin: sorry I didn't followup on the mailing list.  I've forgotten most of the details, but I think the point I was trying to make was that we can change (make more strict) the semantics in nVersion >= 3 and be assured that those txes won't be relayed by old software.
13:27 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection]
13:28 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #bitcoin-core-pr-reviews
14:14 -!- ziggie [~ziggie@user/ziggie] has joined #bitcoin-core-pr-reviews
15:21 -!- lightlike [~lightlike@user/lightlike] has quit [Quit: Leaving]
16:38 -!- ziggie [~ziggie@user/ziggie] has quit [Ping timeout: 256 seconds]
16:46 -!- ziggie [~ziggie@user/ziggie] has joined #bitcoin-core-pr-reviews
17:02 -!- ziggie [~ziggie@user/ziggie] has quit [Ping timeout: 256 seconds]
17:49 -!- commmon [~common@096-033-221-075.res.spectrum.com] has joined #bitcoin-core-pr-reviews
17:53 -!- common [~common@096-033-221-075.res.spectrum.com] has quit [Ping timeout: 252 seconds]
18:17 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
18:19 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
21:56 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
22:08 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
22:28 -!- jonatack [jonatack@user/jonatack] has quit [Ping timeout: 264 seconds]
22:35 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 246 seconds]
22:37 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
22:43 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Ping timeout: 252 seconds]
22:45 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
22:57 -!- commmon [~common@096-033-221-075.res.spectrum.com] has quit [Remote host closed the connection]
22:58 -!- commmon [~common@096-033-221-075.res.spectrum.com] has joined #bitcoin-core-pr-reviews
23:58 -!- ziggie [~ziggie@user/ziggie] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Sep 23 00:00:16 2021