--- Day changed Wed Jan 20 2021
00:20 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
00:40 -!- CubicEarth_ [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
00:40 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 256 seconds]     
01:06 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-xxyfbhfpwravtvho] has quit [Ping timeout: 272 seconds]     
01:07 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-cfpxvfoqzzaxcsfp] has joined #bitcoin-core-pr-reviews     
02:40 -!- prayank [~andr0irc@2409:4053:68f:6b63:746d:6ff5:16bd:7bce] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]     
02:40 -!- prayank [~andr0irc@2409:4053:68f:6b63:746d:6ff5:16bd:7bce] has joined #bitcoin-core-pr-reviews     
03:18 -!- Braxton36Marquar [~Braxton36@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:23 -!- Braxton36Marquar [~Braxton36@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]     
03:36 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
03:39 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]     
04:56 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews     
05:03 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has left #bitcoin-core-pr-reviews []     
05:33 -!- belcher_ is now known as belcher     
05:34 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 264 seconds]     
05:43 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
06:04 -!- harrigan- [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]     
06:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]     
06:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
06:09 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
06:24 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
06:34 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
06:36 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
06:45 -!- prayank [~andr0irc@2409:4053:68f:6b63:746d:6ff5:16bd:7bce] has quit [Read error: Connection reset by peer]     
07:01 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
07:16 -!- ecola [~3cola@95.175.17.147] has joined #bitcoin-core-pr-reviews     
07:32 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
07:33 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
07:59 < jonatack> Hey everyone, we'll get started in an hour ⏰ 🍰
08:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
08:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
08:01 < jonatack> If you have a signet node running and provide a signet address once we start, you can receive and send some signet txns using the new explicit fee rate feature
08:01 < jonatack> I'll be sending some for good answers 🏆
08:01 < jonatack> Here is an RPC command template you can use to send some signet coins to people from your signet node using the new fee_rate param (just add their address):
08:02 < pinheadmz> oh boy its raining sats! 💰
08:02 < jonatack> ./src/bitcoin-cli -signet -named sendtoaddress address="" amount=0.01 fee_rate=1
08:02 < jonatack> idea BLATANTLY ripped of from pinheadmz's signet session :)))
08:02 < pinheadmz> i stole the idea of sending bitcoin to people from satoshi ;-)
08:07 < jonatack> :)     
08:08 < jonatack> oh and feel free to ACK the PR, it's less than 40 lines of code (not counting the tests) and very accessible i think
08:17 -!- B [~B@172.58.173.146] has joined #bitcoin-core-pr-reviews     
08:17 -!- B is now known as Guest25917     
08:26 -!- Guest25917 [~B@172.58.173.146] has quit [Quit: E616 FA7221A1613E5B99206297966C06BB06 757B]     
08:26 < michaelfolkson> Wen do we hassle everyone to start supporting Signet? Wallets, block explorers etc
08:27 < emzy> Good question.
08:27 < pinheadmz> michaelfolkson start selling alpaca socks for signet coins, everyone will jump on board
08:27 < jonatack> good thing i still have some signet coins, because https://signetfaucet.com/ seems to be down
08:27 < michaelfolkson> I was thinking of hassling shesek with Esplora but thought I should get permission from the community to start the hassle campaign
08:28 < michaelfolkson> Needs consensus on when to start the hassle campaign
08:28 < jonatack> i honestly love using signet for local testing
08:28 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving]     
08:29 < jonatack> starts up so quickly, there's a real network and the steady block emission is nice
08:31 < _0x0ff> ah nice, i always assumed signet doesnt connects to any nodes and is just locally (never tried it before). I'll try to start a node for it this week
08:32 < jonatack> _0x0ff: yes, it even has tor v3 peers on it
08:32 < pinheadmz> jonatack I got 1000 sBTC from kalle after the signet review club, happy to help fund todays funny money party if you need
08:33 < _0x0ff> great! are there any caveats when testing features on signet compared to testnet? Is testing on testnet considered "more robust"?
08:33 < jonatack> pinheadmz: sure! i have like 10 so was going to send 0.25 amounts or something, but if you wanna send the rewards for good answers that can help me follow the convo
08:34 < michaelfolkson> Need to be more organized. Got Signet when building various PR branches but can't remember which
08:35 < _0x0ff> i won't be able to join today's review, didn't have time to review the pr, so just want to say thanks for organizing it jonatack, i'll do my best to join again next week.
08:35 < michaelfolkson> 0x0ff: Testnet has just become a massive pain. Barely any block reward, volatile block discovery time, huge chain for IBD
08:36 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
08:37 < _0x0ff> yea i figured - wanted to contribute by also running a node there but it doesn't seem worthile if you're not working on bitcoin somewhat regularly
08:37 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
08:37 < michaelfolkson> I'm not running a Signet node but I'd like to
08:39 < michaelfolkson> I'm betting on transaction fees in the hundreds of dollars at the peak of this bull cycle https://www.youtube.com/watch?v=TcKeQrxqlfU
08:40 < michaelfolkson> Dangerously close to price speculation
08:40 -!- norisgOG [~norisgOG@89.45.6.121] has joined #bitcoin-core-pr-reviews     
08:42 < michaelfolkson> I guess that's one thing Signet is missing. Full blocks and transaction fees
08:44 < jonatack> i just run all four chains on my laptop at the same time
08:44 < jonatack> restarting signet the most to test things
08:47 < wumpus> i haven't run a testnet node for ages
08:48 < wumpus> (i mean classic testnet, i do use regtest obviously and signet)
08:48 < michaelfolkson> Would a Signet administrator eg Kalle filling up Signet blocks with transactions be useful for testing fees on Signet?
08:48 < michaelfolkson> Did anyone ever do that on testnet deliberately?
08:49 < pinheadmz> michaelfolkson the "miner" could lower the blocksize limit drastically even
08:49 < michaelfolkson> pinheadmz: I guess but I think you generally want to keep the default Signet as close to mainnet as possible
08:49 < emzy> That's sounds less wastefull.
08:50 < michaelfolkson> You start making changes to Signet and it ends up not representing mainnet, creates edge cases etc
08:50 < michaelfolkson> Could definitely do it on a custom signet
08:51 < emzy> Agreed
08:52 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
08:52 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
08:55 -!- andozw [430576f9@67-5-118-249.spok.qwest.net] has joined #bitcoin-core-pr-reviews     
08:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]     
08:56 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
08:56 -!- vasild_ is now known as vasild     
08:56 -!- comfy [~comfy@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
08:57 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
08:58 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
08:59 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews     
09:00 -!- AnthonyRonning [627f50cb@098-127-080-203.res.spectrum.com] has joined #bitcoin-core-pr-reviews     
09:00 < jonatack> #startmeeting
09:00 < kanzure> hi     
09:00 < jnewbery> hi     
09:00 < murtyjones> hi     
09:00 < svav> hi     
09:00 < jonatack> Hi all! Welcome to this week's episode of the Bitcoin Core PR Review club. 🎉
09:00 < AnthonyRonning> hi     
09:00 < pinheadmz> hi     
09:00 < michaelfolkson> hi     
09:00 < jonatack> We usually start Bitcoin Core IRC meetings with a 'hi' to know who is here. Feel free to say hi! If you have a signet address, append it your "hi" to receive some sBTC (signet coins) for good answers. 🍰
09:00 < norisgOG> Hi     
09:00 < larryruane_> hi!     
09:00 < jonatack> This week, we're talking about PR #20564 "Check for non-representable CFeeRates (tx fees and policy, wallet, refactoring)" which is a bugfix and part of our ongoing migration of fee rates units from BTC/kvB to sat/vB units (by popular demand). 🚀
09:00 < glozow> hiya
09:00 < jonatack> Notes and questions are at https://bitcoincore.reviews/20546 ✨
09:00 < n3wBEEEE> hi     
09:01 < schmidty> howdy
09:01 < jonatack> pinheadz or I will send signet coins to people with good answers using the explicit fee rate feature. 🍰
09:01 < andozw> Hiiiii
09:01 < comfy> hi     
09:01 < thomasb06> hi     
09:01 < jonatack> Here is an RPC command template you can use to try sending coins to people (or to yourself) from your signet node using the new fee_rate param (just add their address):
09:01 < jonatack> ./src/bitcoin-cli -signet -named sendtoaddress address="" amount=0.01 fee_rate=1
09:01 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:01 < ccdle12> hi     
09:01 < jonatack> or to yourself if no one posts a signet address :)))
09:01 < michaelfolkson> Don't know where the private key is but here's mine: tb1qmmn6u4y9wv3jvwgktyw42nc5ql7t6shs0f2229
09:02 < michaelfolkson> Lesson: don't lose your Signet private key
09:02 < sunon> Hi!     
09:02 < AnthonyRonning> still need to set up a signet node
09:02 < jonatack> Anyone get a chance to read the notes and review the PR? y/n y/n
09:02 < AnthonyRonning> y     
09:02 < norisgOG> y     
09:02 < thomasb06> n     
09:02 < murtyjones> yes to notes, no to PR
09:02 < sishir> ^^     
09:03 < svav> y     
09:03 < n3wBEEEE> nn     
09:03 < sunon> y n     
09:03 < michaelfolkson> y / 0.3y
09:03 < jonatack> Great, let's get started!
09:03 < jonatack> 1. Explain the difference between BTC/kvB and sat/vB units. A fee rate of 1 BTC/kvB is equivalent to what fee rate in sat/vB?
09:03 < sishir> “difference between BTC/kvB and sat/vB units means that a transaction with a fee rate mistakenly calculated in BTC/kvB rather than sat/vB should raise an error due to the fee rate being set too low.”
09:03 < norisgOG> 100000 sats per byte
09:03 -!- goums [5a413cae@lfbn-lyo-1-1878-174.w90-65.abo.wanadoo.fr] has joined #bitcoin-core-pr-reviews     
09:03 < larryruane_> 100,000?
09:03 < emzy> hi     
09:03 < goums> hi     
09:03 < AnthonyRonning> 1 BTC/kvB = 100000 sat/vB
09:03 < emzy> n     
09:04 < sunon> 100k
09:04 < thomasb06> same
09:04 < jonatack> nice! sBTC to sishir norisgOG larryruane_  and AnthonyRonning (if you post an address)
09:04 < larryruane_> is one advantage avoiding messy floating point?
09:04 < jonatack> sunon: yes!
09:04 < jonatack> A sat/vB is 1e5 times larger than a BTC/kvB, so 1 BTC/kvB is equal to 100000 sat/vB.
09:04 < jnewbery> 1e5     
09:04 < larryruane_> tb1qc32gukwejqkyh7z3cyfafsg5spj0cd4hfml4rm
09:05 < michaelfolkson> 100 million sats in a Bitcoin. 1000 vB in a kvB
09:05 < jonatack> sBTC to jnewbery and sunon too
09:05 < jonatack> 2. What is the difference between an RPC *parameter* and an RPC *option*?
09:05 < thomasb06> a parameter is mandatory
09:05 < pinheadmz> 1 sBTC to larryruane_ !
09:05 < larryruane_> option is a boolean param?
09:05 < AnthonyRonning> parameters are required and options are optional
09:05 < murtyjones> required vs optional
09:06 < sishir> one is mandatory, the other is optional
09:06 < jonatack> interesting
09:06 < michaelfolkson> option has a dash before it, parameter doesn't
09:06 < jonatack> My answer was: An RPC parameter is a standalone input argument; an option is an argument inside the options JSON hash.
09:06 < jnewbery> I think the distinction is pretty pointless since we got named arguments a few releases ago
09:07 < michaelfolkson> Does this match standard Unix definitions? https://stackoverflow.com/questions/36495669/difference-between-terms-option-argument-and-parameter
09:07 < jnewbery> the options object doesn't benefit from the built-in type checking / help formatting that RPC parameters do
09:07 < jnewbery> and just make the call signature unnecessarily complex
09:08 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
09:08 < jonatack> i wonder if it was to allow avoiding positional param issues before we had named params
09:08 -!- effexzi [uid474242@gateway/web/irccloud.com/x-ftwsldpbuceseyxn] has joined #bitcoin-core-pr-reviews     
09:08 < jonatack> let's move on
09:08 < jonatack> (see bitcoin-cli help send for an example of both.)
09:08 < jonatack> 3. When making transactions, what fee practice does the ability to specify an explicit fee rate replace?
09:09 < AnthonyRonning> It replaces estimating fee based on desired confirmation target
09:09 < ccdle12> replaces the user of the fee estimator
09:09 < jonatack> Yes! Explicit fee rate is an alternative to using fee estimation with the conf_target and estimate_mode params/options, to allow Bitcoin Core to set the fee rate for you.
09:10 < jonatack> 4. Why is it too early to deprecate the `feeRate` (BTC/kvB) option in `fundrawtransaction` and `walletcreatefundedpsbt` to avoid confusion with `fee_rate` (sat/vB)?
09:10 < sishir>  https://github.com/bitcoin/bitcoin/pull/20483
09:10 < sishir> The estimatesmartfee is still in BTC/kB, so merging this would force all users to do the conversion themselves (or force to pass -deprecatedrpc).
09:10 < AnthonyRonning> There was already a feature freeze for 0.21 but it should now be considered okay for 22.0, right?
09:10 < michaelfolkson> What's the history on the fee estimator? I'm presuming that this is pretty similar to the fee estimators on other non-Core wallets?
09:10 < jonatack> sishir: correct!
09:11 -!- Benny84Hickle [~Benny84Hi@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
09:11 < jonatack> AnthonyRonning: all of the feerate changes were merged after the 0.21 FF given they were considered fixes to an open issue
09:12 < AnthonyRonning> ahh, gotcha. wasn't sure if some where merged in before.
09:12 -!- sepoyi [~ps@112.196.146.210] has joined #bitcoin-core-pr-reviews     
09:13 < jonatack> I proposed to deprecate feeRate but because people may use RPC estimatesmartfee to estimate the fee needed, but that RPC returns the fee rate in BTC/kvB and not in sat/vB, it was considered to early.
09:13 < svav> What is the difference between a virtual byte and a byte?
09:13 < jonatack> michaelfolkson: I don't know. I do like to be able to set the fee rate explicitly and use this feature most of the time.
09:14 < jonatack> svav: good question. anyone want to reply?
09:14 < michaelfolkson> svav: https://bitcoin.stackexchange.com/questions/89385/is-there-a-difference-between-bytes-and-virtual-bytes-vbytes
09:14 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 256 seconds]     
09:14 < ccdle12> svav: vbytes referes to the txs size in weight (segwit), bytes is simply the raw byte lenght of the tx
09:14 < thomasb06> vB is 1000 instead of 1024
09:15 < thomasb06> arg..
09:15 < michaelfolkson> Bytes are bytes. Virtual bytes are adjusted bytes based on SegWit adjustment
09:15 < sishir> svav vsize aka vytes is tx using weighted size under segwit rules
09:15 < sishir> * vbytes
09:15 < larryruane_> so a tx's size in vbytes is always greater-or-equal to its size in bytes?
09:16 < comfy> vB is a synthetic unit to estimate the byte load for transactions on the chain, post-segwit
09:16 < michaelfolkson> Lesser or equal larryruane_
09:16 < jonatack> have a look at https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
09:16 < sishir> I think vbytes is lesser
09:16 -!- pesi [~pesi@197.232.61.248] has joined #bitcoin-core-pr-reviews     
09:16 < norisgOG> thomasb06 I thought vbytes of a presegwit tx are equal to psot segwit therefore I think still both 1024 bytes
09:17 < norisgOG> but the meaning is diffrent
09:17 -!- Benny84Hickle [~Benny84Hi@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 272 seconds]     
09:17 < thomasb06> norisgOG: definitely
09:17 < sunon> Bit late but tb1qg0x546029q0ee3cuuvlx46anxrlsfkk5qy27eg
09:18 < jonatack> feel free to continue discussing while we keep moving
09:18 < jonatack> sunon: yay!
09:18 < jonatack> 5. A plan was made to complete the migration from BTC/kvB to sat/vB units. What is it? Does it make sense to you?
09:18 < jonatack> hint https://github.com/bitcoin/bitcoin/pull/20484#issuecomment-734786305
09:19 < AnthonyRonning> ah cool, i couldn't for the life of me figure out where the plan was
09:19 < michaelfolkson> I think so. Don't understand exactly why that ordering made the most sense but seems reasonable
09:19 < emzy> I think mostly user demand.
09:19 < sishir> Wallet demands as well
09:20 < jonatack> emzy: yes, dev pushback on not breaking user space
09:20 < pinheadmz> sunon 1 sBTC for u !
09:20 < jonatack> It seemed the best way to normalize and transition to sat/vB per user demand, protect users by not having feeRate/feerate in BTC/kvB and fee_rate in sat/vB in the same RPCs, and minimize the amount of breaking API changes.
09:20 < jonatack> 6. In the meantime, if users confuse fee_rate with feeRate when making a transaction or fee bumping, why is the risk of losing funds considered low enough to be temporarily acceptable?
09:21 < AnthonyRonning> because they get a nice fast confirmation :)
09:22 < michaelfolkson> This was the rationale that the user would underpay on fee when overpaying on the fee would be more of a concern. Right?
09:22 < murtyjones> i presume the wallet software would reject fees that are wildly high/low?
09:22 < svav> When instroducing new feerate variable, why not name it more differently from existing fee rate to avoid confusion?
09:22 < jonatack> note that we deliberately broke backward compatibility wrt fee_rate in RPC bumpfee
09:22 < larryruane_> because specifying the old units (BTC/kvB) results in a too-low fee when the actual units are sat/vB?
09:22 < emzy> I think it will be so high that there sould be a warning.
09:22 < norisgOG> users fee estimate is 1/100000 lower if he confuses both
09:23 < jonatack> svav: initially i named it fee_rate_sat_vb, but reviewers considered it best to use fee_rate and i agree
09:23 < larryruane_> there's been a worldwide shortage of underscores, we must conserve them!
09:23 < jonatack> Pretty good replies. Luckily, the 1e5 difference is large enough that any user confusion should be benign.
09:24 < jonatack> Specifying BTC/vkB (current value) in place of the new sat/vB would always be a much lower feerate. So it'd most likely be too low and error, or worst case lower than you intended and you can just bump it again to fix.
09:24 < AnthonyRonning> ahh i had that backwards
09:24 < jonatack> Or as Murch wrote, "In the worst case, someone is going to get upped to the minRelayTxFee silently and send at 1 sat/vB. Since RBF is on by default, they should be able to bump when they notice."
09:25 < svav> In your new code, could you code it so that the units are specified in a separate variable, in case you ever want to change units again?
09:25 < jonatack> Ok, let's move into the code
09:25 < jonatack> 7. What range of values is non-representable by CFeeRate? How does this PR resolve that? Is there a better approach?
09:25 < AnthonyRonning> 0 to 0.001, non inclusive. It checks if, after conversion, if the value is zero but the initial value was not zero. Checking for `> 0 && < 0.001` instead of allocating a `CFeeRate` could be another approach.
09:26 < jonatack> AnthonyRonning: correct!
09:26 < Murch> Hey, sorry, I had a conflicting meeting, but this one is totally down my alley ^^
09:27 < Murch> sishir: Yes, a transactions virtualsize is strictly smaller or equal to its raw byte size.
09:27 < jonatack> Murch: hi! yeah Murch was co-author and a major reviewer behind these changes
09:27 < Murch> norisgOG: there are 1000 bytes in a kB in Bitcoin :-/
09:28 < norisgOG> Murch thx
09:28 < jonatack> AnthonyRonning: which approach of the two would you use?
09:29 < sishir> Murch Thankyou
09:29 < AnthonyRonning> i typically would use the range check. Is there a reason why allocating `CFeeRate` is done here? Is there a hidden benefit i'm missing?
09:29 < AnthonyRonning> performance, or otherwise
09:30 < jonatack> AnthonyRonning: no, strangely enough I only thought of the first way
09:31 < AnthonyRonning> less use of magic numbers though, so there's a benefit there
09:31 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has quit [Quit: Connection closed]     
09:31 < jonatack> AnthonyRonning: thanks for the ideas.
09:31 < jonatack> 8. What is the Named Constructor Idiom?  Why does this PR use it?
09:32 < AnthonyRonning> A way to be more explicit about the object you are creating. This PR uses it by `CFeeRate::FromSatB` and `CFeeRate::FromBtcKb` .
09:32 < svav> To distinguish between the old charge units and the new ones.
09:32 < AnthonyRonning> never heard of that term before but i think that's the idea
09:33 < jonatack> Yes, several contributors found the current constructor confusing to use
09:33 < michaelfolkson> https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Constructor
09:33 < AnthonyRonning> I still see some places in code that use `CFeeRate(X, 1000)`, is there further refactoring that could be implemented to be consistent?
09:33 < AnthonyRonning> for instance, here https://github.com/jonatack/bitcoin/blob/ed414f6dd72c103b5ba9e17c6b6bd2bcc8548b5b/src/wallet/wallet.cpp#L3962
09:33 < jonatack> AnthonyRonning: yes
09:34 < jonatack> I found it in isocpp.org/wiki/faq/ctors#named-ctor-idiom by Stroustrup, Cline, Sutter and Alexandrescu. Its goal is to provide more intuitive and/or safer construction operations for users of your class.
09:35 < jonatack> AnthonyRonning: yes, good eye. I didn't change them all, maybe I should.
09:36 < jonatack> There are a few that cannot be changed, however, but most cases are covered by the named ctors
09:36 < jonatack> michaelfolkson: nice link, thanks
09:37 < jonatack> This PR uses the Named Constructor Idiom to encapsulate the confusing "pass COIN for sat/vB, 1000 for
09:37 < jonatack> BTC/kvB to the ctor" into CFeeRate itself, by popular demand as requested by several contributors. One example is at https://github.com/bitcoin/bitcoin/pull/20305#discussion_r519986635
09:37 < larryruane_> Seems like named constructors are nice when the argument list can't be used to distinguish between different forms of initializers (e.g. both take uint64_t but the units are different, as is the case here)... nice! I wasn't aware of this!
09:38 < jonatack> larryruane_: right! i like it too
09:39 < jonatack> Question: are you people concept ACK on using the IsZero() member function to replace CFeeRate() == 0 conditionals?
09:40 < jonatack> I found it curious to construct just to check for a zero CFeeRate
09:40 < AnthonyRonning> yeah i think it makes sense to me to be more explicit about it
09:40 < murtyjones> encapsulating code like that seems useful to me, for auditability if nothing else
09:41 -!- TechMiX [~techtux@ti0169q161-0269.bb.online.no] has joined #bitcoin-core-pr-reviews     
09:41 < jonatack> and there a quite a few of those in the codebase
09:41 < larryruane_> i like it too, it's like isNull
09:41 -!- TechMiX [~techtux@ti0169q161-0269.bb.online.no] has quit [Client Quit]     
09:42 < jonatack> 9. FeeRateFromValueInSatB calls another utility function named AmountFromValue. Why are there two AmountFromValue functions in the codebase (one in src/rpc/util.cpp and one in src/bitcoin-tx.cpp)?
09:42 -!- TechMiX [~techtux@ti0169q161-0269.bb.online.no] has joined #bitcoin-core-pr-reviews     
09:42 < jonatack> (thanks for the feedback!)
09:42 < AnthonyRonning> Because you can work with transactions through the RPC and the command line (from what i can tell), and `AmountFromValue` should always be used when inputing numerical values from the user.
09:42 -!- SurajUpadhyay [uid421192@gateway/web/irccloud.com/x-lxsueigafytgvkqo] has joined #bitcoin-core-pr-reviews     
09:43 < SurajUpadhyay> Is the meeting for today over ??
09:43 < jonatack> about question 9: when i needed to call AmountFromValue from src/bitcoin-cli.cpp, i found i needed to make a *third* copy of this function
09:44 < michaelfolkson> SurajUpadhyay: No, in progress
09:44 < jonatack> AnthonyRonning: right! but why are there two of them?
09:45 < AnthonyRonning> ah yeah, better question. I'm not sure, is there not a better place for utility functions to exist? Or are they slightly different, need to check again.
09:45 < jonatack> hint, look in test/lint/lint-circular-dependencies.sh
09:45 < larryruane_> i notice the exceptions they throw is different
09:46 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has quit [Read error: Connection reset by peer]     
09:46 -!- goums [5a413cae@lfbn-lyo-1-1878-174.w90-65.abo.wanadoo.fr] has quit [Ping timeout: 248 seconds]     
09:46 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
09:47 < jonatack> I couldn't pull it into bitcoin-cli.cpp without adding a circular dependency
09:47 < jonatack> "policy/fees -> txmempool -> policy/fees"
09:47 < jonatack> at least, that is my recollection, i could be wrong!
09:48 < Murch> Given that there are quite a few types of amounts in the codebase that have distinct ranges and shouldn't be easily added together, have there been more attempts to make classes for specific types of amounts?
09:48 < larryruane_> if this doesn't sidetrack the discussion too much (feel free to ignore), what's the reason we even check for circular dependencies? what goes wrong if we don't? there are exceptions anyway....
09:48 < murtyjones> i see. given that there's a manual linter, does C++ not do any kind of circularity checking when it compiles?
09:48 < michaelfolkson> I have same question larryruane_
09:48 < jonatack> larryruane_: i think we really really don't want more circular dependencies, but it requires some refactoring to remove them
09:49 < svav> How is a circular dependency introduced?
09:50 < jonatack> the current assumeUXTO PR adds one, for instance, but pulling things out of validation code isn't easy
09:51 < jonatack> svav: by code pulling in headers that link to each other, though that's not an official definition
09:52 -!- sepoyi [~ps@112.196.146.210] has quit []     
09:52 < michaelfolkson> And this bash script checks no new ones are introduced?
09:52 < jonatack> murtyjones: i'd have to look
09:52 < murtyjones> no biggie just curious.
09:52 < jonatack> michaelfolkson: yes, other than the permitted exceptions
09:53 < jonatack> in EXPECTED_CIRCULAR_DEPENDENCIES
09:53 < jonatack> if you add one and don't add it to that list, the CI fails
09:54 < michaelfolkson> I wouldn't describe that as linter/linting but heh
09:54 -!- pesi [~pesi@197.232.61.248] has quit [Ping timeout: 246 seconds]     
09:54 < jonatack> 10. What would be the best way to migrate the config option fee rate units in the from BTC/kvB to sat/vB?
09:54 < jonatack> ./src/bitcoind -help-debug | grep fee
09:55 < AnthonyRonning> i've seen other projects create a new variable. So an example could be `maxtxfeesat` instead of `maxtxfee`
09:55 < jonatack> will show you the config options
09:55 < AnthonyRonning> then deprecate the old one eventually
09:56 < jonatack> AnthonyRonning: one thing i've noticed is the older options often use "fee" both for an absolute fee and a fee rate
09:56 -!- pesi [~pesi@197.232.61.248] has joined #bitcoin-core-pr-reviews     
09:56 < jonatack> which helps for naming, e.g. RPC settxfee to setfeerate for the sat/vB version
09:56 < jonatack> or estimatesmartfee -> estimatefeerate
09:56 < michaelfolkson> Do you need to do the normal two version deprecating or can you just supply error messages and do it straight away?
09:57 < michaelfolkson> I guess you don't know
09:57 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
09:57 < michaelfolkson> So like a warning rather than an error message
09:57 < Murch> michaelfolkson: It's preferable not to break userspace
09:57 < jonatack> michaelfolkson: idk, we did simply remove a banscore config option in 0.21 without any deprecation period
09:57 < Murch> there are a lot of people running automated scripts against full nodes
09:58 < jonatack> we wouldn't have done that with the RPC API
09:58 < michaelfolkson> Right, good point Murch
09:58 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Ping timeout (120 seconds)]     
09:58 < AnthonyRonning> oh didn't notice that, yeah i see that now. It could have been better to be more explicit between the two in the first place, in retrospect
09:58 -!- AnthonyRonning [627f50cb@098-127-080-203.res.spectrum.com] has quit [Quit: Ping timeout (120 seconds)]     
09:58 < Murch> I mean, good practice is to test new versions first, but I know a lot of businesses just yolo upgrades
09:58 -!- AnthonyRonning [627f50cb@098-127-080-203.res.spectrum.com] has joined #bitcoin-core-pr-reviews     
09:58 < jonatack> I would imagine we'd have to add as AnthonyRonning suggests
09:58 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews     
09:58 < Murch> It would be fair to say that it's their fault, but still
09:59 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has quit [Quit: Connection closed]     
09:59 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has quit [Quit: Ping timeout (120 seconds)]     
09:59 < TechMiX> AnthonyRonning: sounds like a good idea to me
09:59 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
09:59 < AnthonyRonning> i think c-lightning and/or lnd had to introduce a new one for `msat`, and eventually deprecating `sat`
09:59 < jonatack> that makes sense to me
09:59 < Murch> AnthonyRonning: The downside with making parameter names even more explicit is that you're then stuck with that name even when the old one is long forgotten
10:00 < jonatack> That's time! Thanks everyone!
10:00 < jonatack> #endmeeting
10:00 < Murch> so it comes down to a trade-off between a shortterm confusion and a long term clunky name
10:00 < comfy> ty jonatack et al
10:00 < AnthonyRonning> Murch: yeah good point
10:00 < AnthonyRonning> thank you jonatack! And everyone else. Very informative.
10:00 < jnewbery> thanks jonatack!
10:00 < michaelfolkson> Great notes and sess jonatack. Thanks!
10:00 < thomasb06> thanks jonatack
10:00 < schmidty> thanks jonatack !
10:00 < emzy> Thank you jonatack
10:00 < ecola> thanks jonatack
10:00 < jnewbery> next week, glozow hosts. Notes and questions will be up this Friday
10:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
10:01 < jonatack> I learned some things from you all and see things to think more about, thanks!
10:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
10:01 < glozow> great notes as always jonatack, hard to follow u
10:01 < svav> Thanks jonatack
10:01 < norisgOG> thanks jonatack
10:02 < n3wBEEEE> thank you all - this was very i9nformative for me
10:02 -!- ecola [~3cola@95.175.17.147] has quit [Quit: Leaving]     
10:02 < jonatack> thanks pinheadmz for distributing the sBTC 💰
10:03 < Murch> sBTC?
10:03 < comfy> signet btc
10:03 < Murch> ah, thanks.
10:04 < comfy> np     
10:04 -!- n3wBEEEE [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has quit [Client Quit]     
10:04 < jonatack> 18:25 <svav> In your new code, could you code it so that the units are specified in a separate variable, in case you ever want to change units again?
10:04 < jonatack> svav: will think about that, thanks
10:04 < svav> ok     
10:05 < jonatack> so much i miss during the meeting and see afterward
10:05  * jonatack is not a multitasker
10:05 < michaelfolkson> I know you're the coin selection guru Murch. Who is the fee estimator guru? I guess I can go git blaming
10:06 -!- AnthonyRonning [627f50cb@098-127-080-203.res.spectrum.com] has quit [Quit: Connection closed]     
10:06 < michaelfolkson> Do wallets (Core and others) look at fees in their mempool to determine the fee that should be used or just fees on the transaction in the latest blocks?
10:07 < michaelfolkson> Never looked into fee estimation
10:07 < Murch> Alex Morcos
10:08 < Murch> https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
10:09 < michaelfolkson> Ah nice, thanks
10:10 < michaelfolkson> Does coin selection take into account to whether fees are high or low at the current time?
10:13 < comfy> fwiw I think fee rate estimation bleeds out of scope for bitcoin core, block space is a market good -- on which economic agents bid.  The course of action bitcoin node software can do is ensure the block-space market clears properly and thing else is speculation and game theory
10:15 < michaelfolkson> Bitcoin Core provides a wallet and hence fee rate estimation is in scope
10:16 < comfy> Writing an algo for fee estimation is on par with writing trading algo.  probably why alex's is so interested in it ;]
10:16 < michaelfolkson> You don't do the projecting market conditions bit, that is for certain
10:17 < comfy> "you" as in the wallet software?
10:17 -!- B [~B@172.58.173.146] has joined #bitcoin-core-pr-reviews     
10:17 < michaelfolkson> Like it wouldn't be in scope to attempt (if it is even possible) to project where fees will go in future. Just using current information to make an informed judgement
10:17 < comfy> I'd argue the wallet software is de facto projecting market conditions
10:17 -!- B is now known as Guest7705     
10:18 < comfy> Node: 140 sat/vB is a reasonable fee
10:18 < comfy> sounds like speculation to me
10:18 < michaelfolkson> Right but it is more the best estimate is the current mean
10:18 < michaelfolkson> Not I can see a bunch of whales coming to dump their Bitcoin and we need to raise our fee estimates
10:19 < comfy> my main point is, many people focus on "fixing" fee rate estimation over the years as if it's a CS problem when it's solely economic action
10:19 < michaelfolkson> Basic projection based on current data versus sophisticated projection (like the trading algos)
10:20 < michaelfolkson> Totally agree that to make it "sophisticated" it is an economics problem rather than a CS problem
10:21 -!- andozw [430576f9@67-5-118-249.spok.qwest.net] has quit [Quit: Connection closed]     
10:22 < comfy> Mempool: I'm 2 blocks deep
10:22 < comfy> 100 blocks worth of user txns: Hey node how much to get into the next block
10:22 < comfy> Node: oh um hmm 2 blocks deep, X feerate
10:22 < comfy> 100 blocks worth of user txns: oh cool /me dumps 100 blocks worth of txns
10:23 < michaelfolkson> Yeah I'd put that under basic and what I expected Core did (but as I said I've never looked into it)
10:23 < belcher> in the future if some miners are censoring transactions then fee estimation and checking the mempool wont be accurate anymore, because of that it seems fee bumping is the most future-proof
10:24 < comfy> double plus
10:24 < belcher> id often thought bitcoin wallets will probably evolve to all using precomputed RBF and nlocktimed transactions
10:24 < michaelfolkson> Fee bumping is a great tool. I don't think it is an either or though. You could have both.
10:25  * comfy flash backs to 90s ebay sniping
10:26 < Guest7705> Calculating a moving average over a default of 144 blocks
10:26 < michaelfolkson> Fee bumping from a good base estimate rather than fee bumping from a terrible starting point
10:27 < Guest7705> may be useful - and allowing the user to change the interval to something else for their own prefferences.
10:28 < comfy> whether or not the fee rate is terrible to begin with is influenced by how prevalent RBF is :]
10:28 < comfy> RBF is very very optimum "revealed preference" from the economic realm
10:29 -!- Guest7705 [~B@172.58.173.146] has quit [Remote host closed the connection]     
10:29 < michaelfolkson> Sounds like it is everyone flailing around in the dark to me ;)
10:29 < comfy> https://en.wikipedia.org/wiki/Revealed_preference
10:30 < comfy> transactions start out a minfeerate and then just keep upping their rate until they clear or hit their max fee bid
10:31 < michaelfolkson> "I want my transaction to be confirmed in next 6 blocks. It hasn't been confirmed in 5 blocks. Do I bump fee or wait? If I bump fee by how much?"
10:32 < michaelfolkson> Easier to answer if you know whether it is near top or bottom of the mempool
10:33 -!- pesi [~pesi@197.232.61.248] has quit [Ping timeout: 265 seconds]     
10:33 < comfy> yes, to which I'd say the node should be able to provide tailored information to the wallet about the mempool and block-occupying transaction
10:34 < michaelfolkson> Right
10:34 -!- pesi [~pesi@197.232.61.248] has joined #bitcoin-core-pr-reviews     
10:34 < comfy> I must leave, cheers!
10:34 -!- comfy [~comfy@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: comfy]     
10:34 < michaelfolkson> Motivation for more sophistication comes when fees start going back to 2017 levels
10:44 -!- TechMiX [~techtux@ti0169q161-0269.bb.online.no] has left #bitcoin-core-pr-reviews []     
10:46 < Murch> michaelfolkson: The Branch and Bound algorithm sort of does take the feerate into account, but not the Bitcoin Core Coin Selection in general
10:47 < michaelfolkson> Murch: What was the thinking behind taking it out of Core coin selection?
10:48 < michaelfolkson> I know you simplified it right after first iteration didn't work great. Was that just one of the simplifications?
10:48 < Murch> The problem with bumping to often is that it reveals information about what the payment outputs and what the change outputs are, or it grows the transaction in size.
10:49 < Murch> too     
10:49 < michaelfolkson> Good point
10:51 < michaelfolkson> On the former. How does the transaction grow in size if you RBF?
10:52 < michaelfolkson> Aren't you broadcasting the same transaction with an output that is slightly reduced in value (so more goes to the miner)?
11:02 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]     
11:03 < Murch> michaelfolkson: Right, either you reduce the value of the changeoutput, thusly revealing which one is the change output, or you add more inputs and outputs to increase the fee
11:04 < jonatack> ☕ Meeting log is up at https://bitcoincore.reviews/20546 ✨
11:05 < michaelfolkson> Murch: Ah gotcha. Assuming your original transaction size was minimized. Using different/more inputs and outputs could increase the transaction size for the RBF transaction
11:05 < michaelfolkson> Thanks jonatack
11:06 < jonatack> michaelfolkson: 👍
11:07 -!- pesi [~pesi@197.232.61.248] has quit [Read error: Connection reset by peer]     
11:08 -!- pesi [~pesi@197.232.61.248] has joined #bitcoin-core-pr-reviews     
11:10 < _0x0ff> anyone knows what resources are needed (suggested) for signet?
11:10 -!- pesi [~pesi@197.232.61.248] has quit [Read error: Connection reset by peer]     
11:11 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
11:12 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
11:12 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
11:13 < jonatack> _0x0ff: yes, see https://bitcoincore.reviews/18267
11:14 < michaelfolkson> https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-08-19-socratic-seminar-signet/
11:15 < michaelfolkson> https://pastebin.com/rAcXX9Tn
11:15 < Murch> michaelfolkson: Not sure what you mean with the "minimized". Assuming that you cannot change the payments, the only thing you can change is the change outputs, or add to the transaction.
11:16 -!- norisgOG [~norisgOG@89.45.6.121] has quit [Ping timeout: 240 seconds]     
11:17 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 265 seconds]     
11:17 < michaelfolkson> Murch: You cannot change who or how much you are paying them. But you can change the change output(s) and the inputs
11:17 < michaelfolkson> Assuming that at least one of the new inputs is taken from the old transaction
11:19 < michaelfolkson> You need the confirming of the RBF transaction to invalidate the transaction it is RBFing. So that needs a minimum of one input to be in both the original transaction and the RBF transaction
11:27 < Murch> Ah right, you could drop some inputs and replace them with others. That would effectively reveal a larger set of inputs to be owned by one party of course, though.
11:28 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
11:29 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
11:39 -!- jackk_Doe [~jackk@205.178.111.134] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
11:40 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-pr-reviews     
11:59 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
12:00 -!- jadi [~jadi@178.131.52.33] has quit [Read error: Connection reset by peer]     
12:04 < _0x0ff> thanks for the links
12:06 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 240 seconds]     
12:16 < shesek> michaelfolkson, supporting signet in esplora should be pretty straightforward, just need to get rust-bitcoin upgraded first. I recently did this for bitcoin wallet tracker, it has signet support on master since yesterday
12:19 -!- effexzi [uid474242@gateway/web/irccloud.com/x-ftwsldpbuceseyxn] has quit [Quit: Connection closed for inactivity]     
12:28 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
12:42 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
12:42 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
13:02 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
13:04 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
13:05 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
13:13 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
13:13 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]     
13:13 -!- vasild_ is now known as vasild     
13:21 -!- ctrlbreak_MAD [~ctrlbreak@159.2.165.130] has joined #bitcoin-core-pr-reviews     
13:24 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.165.130] has quit [Ping timeout: 272 seconds]     
13:32 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: ccdle12]     
13:35 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
13:36 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
14:07 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
14:08 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
14:39 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
14:44 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 256 seconds]     
15:26 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
15:27 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
15:58 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
15:59 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
16:16 -!- jessepos_ [~jp@2601:645:200:162f:edcb:662b:a209:afa] has joined #bitcoin-core-pr-reviews     
16:17 -!- jesseposner [~jp@2601:645:200:162f:129:157d:4d2b:a6f4] has quit [Ping timeout: 264 seconds]     
16:30 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
16:31 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
17:02 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
17:02 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
17:04 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]     
17:12 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
17:33 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
17:34 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
18:05 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
18:06 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
18:37 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
18:43 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 256 seconds]     
18:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
18:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
18:57 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Ping timeout: 272 seconds]     
19:12 -!- musdom [~Thunderbi@202.184.0.102] has joined #bitcoin-core-pr-reviews     
19:20 -!- jackk_Doe [~jackk@205.178.111.134] has joined #bitcoin-core-pr-reviews     
19:24 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
19:24 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
19:51 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds]     
19:57 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
19:58 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
20:17 -!- jackk_Doe [~jackk@205.178.111.134] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
20:29 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
20:35 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 265 seconds]     
20:39 -!- jackk_Doe [~jackk@205.178.111.134] has joined #bitcoin-core-pr-reviews     
20:50 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
20:51 -!- musdom1 [~Thunderbi@202.184.0.102] has joined #bitcoin-core-pr-reviews     
20:52 -!- musdom [~Thunderbi@202.184.0.102] has quit [Read error: Connection reset by peer]     
20:52 -!- musdom1 is now known as musdom     
20:53 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
20:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]     
20:56 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
20:56 -!- vasild_ is now known as vasild     
21:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
21:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
21:56 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
21:58 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
22:11 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-pr-reviews     
22:29 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
22:34 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 246 seconds]     
22:37 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds]     
22:40 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
23:19 -!- _0x0ff- [~potatoe@2001:bc8:47b0:123::1] has joined #bitcoin-core-pr-reviews     
23:22 -!- _0x0ff [~potatoe@unaffiliated/0x0ff/x-1210984] has quit [Ping timeout: 260 seconds]     
23:26 -!- _0x0ff- [~potatoe@2001:bc8:47b0:123::1] has quit [Quit: into the offlines]     
23:26 -!- _0x0ff [~potatoe@163.172.166.225] has joined #bitcoin-core-pr-reviews     
23:26 -!- _0x0ff [~potatoe@163.172.166.225] has quit [Changing host]     
23:26 -!- _0x0ff [~potatoe@unaffiliated/0x0ff/x-1210984] has joined #bitcoin-core-pr-reviews