--- Day changed Wed Apr 14 2021 00:05 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews 00:11 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving] 01:04 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds] 01:06 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 01:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 01:14 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews 01:14 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 01:14 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 01:25 -!- musdom [~Thunderbi@202.186.69.84] has joined #bitcoin-core-pr-reviews 02:03 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 02:03 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 02:28 -!- TheRec_ [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 248 seconds] 02:28 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 02:28 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 02:28 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 03:24 -!- jadi [~jadi@37.98.3.133] has quit [Read error: Connection reset by peer] 03:24 -!- Vivian28Langosh [~Vivian28L@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:26 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 03:30 -!- Vivian28Langosh [~Vivian28L@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds] 03:51 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 04:23 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 04:24 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 04:43 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 05:48 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has joined #bitcoin-core-pr-reviews 05:48 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has quit [Client Quit] 06:09 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 06:27 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 252 seconds] 06:28 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 06:28 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 06:28 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 06:29 -!- belcher_ is now known as belcher 06:40 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 06:41 -!- Guest76589 is now known as davterra 06:42 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 06:52 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 06:52 -!- musdom [~Thunderbi@202.186.69.84] has quit [Ping timeout: 240 seconds] 06:53 -!- musdom [~Thunderbi@202.186.69.84] has joined #bitcoin-core-pr-reviews 06:56 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 268 seconds] 07:12 -!- OP_NOP_ [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews 07:12 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 07:14 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 07:16 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 268 seconds] 07:26 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 07:33 -!- OP_NOP_ [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Remote host closed the connection] 07:33 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews 07:37 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds] 07:38 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews 07:38 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:45 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 07:47 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 07:49 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has joined #bitcoin-core-pr-reviews 08:07 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has quit [Quit: Leaving.] 08:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 08:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 08:17 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 08:19 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 08:27 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has joined #bitcoin-core-pr-reviews 08:49 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has quit [Quit: Leaving.] 08:49 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 08:51 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 09:07 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:21 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has joined #bitcoin-core-pr-reviews 09:22 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 09:24 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has quit [Client Quit] 09:24 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 09:29 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has joined #bitcoin-core-pr-reviews 09:31 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has quit [Client Quit] 09:36 -!- lightlike [~lightlike@p200300c7ef169b008d78383155562f3b.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:46 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 09:46 -!- will__ [~will@dynamic-190-25-109-205.dynamic.etb.net.co] has joined #bitcoin-core-pr-reviews 09:47 -!- marqusat [~marqusat@185.107.57.4] has joined #bitcoin-core-pr-reviews 09:52 -!- will__ [~will@dynamic-190-25-109-205.dynamic.etb.net.co] has quit [Remote host closed the connection] 09:53 -!- will__ [~will@dynamic-190-25-109-205.dynamic.etb.net.co] has joined #bitcoin-core-pr-reviews 09:54 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 09:55 -!- cchrysos [88248599@136.36.133.153] has joined #bitcoin-core-pr-reviews 09:56 -!- cec [aedb0499@153.sub-174-219-4.myvzw.com] has joined #bitcoin-core-pr-reviews 09:59 -!- jadi [~jadi@37.98.3.133] has quit [Ping timeout: 240 seconds] 10:00 < larryruane_> #startmeeting 10:00 < _andrewtoth_> hi 10:00 < schmidty> hi 10:00 < larryruane_> Hello review clubbers! 10:00 < marqusat> hi 10:00 < will__> hi! 10:00 < jnewbery> hi! 10:00 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:00 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 10:01 < larryruane_> today we have: https://bitcoincore.reviews/14707 10:01 < larryruane_> is anyone here for the first time? 10:01 < lightlike> hi 10:01 < sishir> hi 10:01 < will__> yes, first time here 10:01 < svav> hi 10:01 < _andrewtoth_> thank you for taking an interest in my PR larryruane_ 10:01 < larryruane_> will__: welcome! 10:02 < glozow> hi 10:02 < larryruane_> _andrewtoth_: you're very welcome -- thank you for creating such a nice PR! 10:02 < larryruane_> ok, couple of hints if it's your first time, and reminders if it's not: all questions are welcome! Everyone is here to learn. 10:02 < emzy> hi 10:02 < larryruane_> and 2: you don't have to ask to ask. If you have a question, just go right ahead and ask. 10:02 < larryruane_> tips here: https://bitcoincore.reviews/your-first-meeting 10:03 < will__> thanks 10:03 < larryruane_> ok, who had time to review the PR this week? (y/n) 10:03 < marqusat> y 10:03 < sishir> y 10:03 < glozow> 0.8y 10:03 < emzy> n 10:03 < svav> y 10:03 < jnewbery> y 10:03 < larryruane_> glozow: spoken like a true engineer! 10:04 < larryruane_> Okay we've got a good group here. Let's start with a very basic concept (I'm pretty new to all this myself!): 10:04 < larryruane_> This is one of many PRs that modifies the RPC interface. Are such changes considered consensus changes? 10:04 < glozow> nope 10:04 < schmidty> Nah 10:04 < marqusat> nope 10:05 < larryruane_> How can you tell if a change affects consensus? 10:05 < glozow> you don't 🤔 until it affects consensus 10:05 < sishir> what does "breaking change" mean? 10:05 < _andrewtoth_> glozow: then shouldn't the previous answer be "maybe"? 10:06 < larryruane_> Here is something I think about, correct me if I'm wrong: Imagine a different client (not bitcoin core) -- would that client need this change? 10:06 < b10c> hi 10:06 < larryruane_> (to stay in consensus) 10:06 < glozow> _andrewtoth_: heh. 99.9% confidence in my "nope" 10:07 < glozow> perhaps would have lower confidence if it was touching other code 10:07 < marqusat> changes something in bitcoin/src/consensus/ in a way of what is considered valid? 10:07 < glozow> afaik it's not _supposed_ to change consensus 10:07 < larryruane_> glozow: that's right, okay, so changes in the RPC layer aren't consensus. 10:08 < lightlike> i'd say that it wouldn't need to implement any rpc layer at all to stay in consensus. 10:08 < larryruane_> With RPC changes, what are some considerations related to backward compatibility? 10:08 < larryruane_> lightlike: very good, I agree 10:08 < larryruane_> that is, what do we have to worry about when changing an RPC? 10:08 < glozow> should get the same results if you call the RPC on an older version of Bitcoin Core. I think this answers your question too sishir 10:09 < schmidty> Parameter ordering 10:09 < sishir> i see thank glozow 10:09 < marqusat> to not break the existing contract 10:09 < marqusat> input and expected output 10:10 < larryruane_> yes, all good answers... imagine a script on some user's system that no one knows how to maintain ... it would be bad to break that script, it may be very inconvenient for the user to fix it 10:10 < larryruane_> Okay, moving on (unless there's anything else?) 10:11 < larryruane_> BTW, For the newer people here, I just want to mention that this PR is different than other recently-reviewed PRs -- it's quite simple and you don't need a lot of background knowledge. So please speak up! You'll be glad you did :) 10:11 < larryruane_> There are 4 RPCs that are affected by this PR. They all have "receivedby" in their names 10:11 -!- cec [aedb0499@153.sub-174-219-4.myvzw.com] has quit [Quit: Connection closed] 10:12 < larryruane_> what major data structures do these RPCs access? 10:12 -!- cec [aedb0499@153.sub-174-219-4.myvzw.com] has joined #bitcoin-core-pr-reviews 10:12 < glozow> `mapWallet` 10:13 < will__> maybe too silly, but this 'coinbase' transactions are related to Coinbase company? or i'm missing the coinbase concept 10:13 < sishir> JSON array? 10:14 < marqusat> CWallet 10:14 < svav> will__ : A coinbase transaction is the first transaction in a block. It is a unique type of bitcoin transaction that can be created by a miner. The miners use it to collect the block reward for their work and any other transaction fees collected by the miner are also sent in this transaction. 10:14 < larryruane_> glozow: yes, can you give us a quick summary of `mapWallet`'s purpose? 10:14 < sishir> will__ coinbase tx is tx that miner receive as reward. Hence first tx in block 10:14 < will__> thanks! 10:15 < _andrewtoth_> will__: coinbase the company took its name after a concept introduced by bitcoin. similar to blockchain the company. 10:15 < jnewbery> larryruane_: Something that we try to do to help with backwards compatibility is make the return a JSON object (rather than a array, string, or number). That means that additional key-values can be added without breaking clients that are receiving the return object. 10:15 < glozow> larryruane_: honestly not sure, I haven't looked at the wallet code that much. It's a map from txid to `CWalletTx`, I assume it's all the transactions that the wallet is interested in, e.g. sent and received 10:15 < larryruane_> marqusat: `CWallet` is a class ... `mapWallet` contains a bunch of those, indexed by ... ? 10:16 < glozow> `mapWallet` is a member of `CWallet` iiuc 10:17 < svav> Why does a wallet need the four "receivedby" methods in the first place? 10:17 < larryruane_> glozow: yes, that's correct, I stated it wrong I think, there's one `CWallet` instance (or now can there be multiple?), and it contains a `mapWallet` 10:17 < larryruane_> svav: there is a concept of a label, can anyone explain what a label is? 10:18 < svav> Labels are short, easy-to-remember words for long, complicated wallet addresses. 10:18 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has joined #bitcoin-core-pr-reviews 10:18 < svav> The label for an external bitcoin address is a name that you can use to keep track of the different BTC addresses for your own use. It is not a mandatory field. 10:19 < svav> Right? 10:19 < larryruane_> svav: yes! and also for grouping -- you can place multiple addresses in a single label 10:19 < _andrewtoth_> I think the use of labels in the wallet has largely been deprecated or discouraged though, right? 10:19 < svav> OK, so why are the 4 methods needed by a wallet? 10:19 < larryruane_> so labels are why there are 4 "receivedby" rpcs instead of 2 (address and label variants) 10:20 < larryruane_> _andrewtoth_: good question! I don't know! 10:20 < glozow> I suppose the `get` vs `list` could have been a verbosity option 10:20 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has quit [Client Quit] 10:20 < larryruane_> the other "dimension" in the "receivedby" RPC set is the "get" versus the "list" variants 10:20 < svav> getreceivedbyaddress See https://developer.bitcoin.org/reference/rpc/getreceivedbyaddress.html 10:21 < svav> getreceivedbyaddress - Returns the total amount received by the given address in transactions with at least minconf confirmations. 10:22 < larryruane_> so the `get` versions return just a simple amount, not JSON (see jnewbery's comment above about newer RPCs preferring to return JSON -- these `get` are older RPCs) 10:22 < svav> Can someone attempt a basic summary of the reason for this Pull Request? Why is it needed? 10:22 < larryruane_> svav: yes .... ah you asked the next question, perfect! 10:23 < larryruane_> (just to finish the thought) the `list` variants return an array of JSON objects 10:23 < marqusat> larryruane: mapWallet returns a map of CWalletTx indexed by tx id 10:24 < _andrewtoth_> svav: consider I received a coinbase output to one of my addresses from mining a block 100 blocks ago, and I wanted to see the balance received by that address. The current behaviour of getreceivedbyaddress would not show the value of the coinbase output, causing me to wonder where my money is. 10:24 < sishir> I believe its cause the getreceivedbyaddress and listreceivedbyaddress do not include amount from coinbase tx so this PR adds them 10:24 < jonatack> hi (lurking) 10:24 < glozow> Including coinbase outputs in the `receivedby` RPCs. I think of it as somewhat of a bug fix, since there's no reason to filter _all_ coinbase outputs 10:24 < larryruane_> marqusat: yes exactly! the local variable when iterating this container is typically called `wtx` which stands for "wallet tx" (not "witness") 10:25 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 10:25 < larryruane_> good answers, everyone. Okay, now, next, what "technical difficulty" does including the coinbase in any RPC result introduce? 10:26 < sishir> whether to include immature tx or not 10:27 < marqusat> it's a behavior breaking change 10:27 < glozow> I believe there's some considerations wrt user expectations about the spendability of their outputs. the number of confirmations is usually only relevant for confidence that this coin is indeed going to stay in our wallet, but for coinbases, it also affects whether or not we can spend it 10:27 < svav> _andrewtoth_ : Under what circumstances would a coinbase output be received? Is this something just a successful miner receives? How does this affect the average Bitcoin user who has a wallet? 10:27 < glozow> and yeah, I'd be extremely confused as a user if I made two calls to `getreceivedby*` on different versions and got different answers 10:27 < larryruane_> marqusat: absolutely right, this is a change, as by default, the coinbase will be included, whereas it wasn't before. What did the PR author do to address this concern? 10:28 < marqusat> added a hidden configuration option to revert to the previous behavior 10:28 < larryruane_> sishir: right, immature coinbase is now an issue... what is immature coinbase, why is there such a concept? 10:28 < svav> Can someone define coinbase output and how it differs from a standard UTXO? 10:29 < larryruane_> marqusat: right, I believe the thinking is that although this is a change, it's one that most people won't mind ... but just in case someone does, there's an escape hatch (without having to recompile the client from source) 10:30 < jnewbery> svav: A coinbase output is an output from the coinbase transaction. The coinbase transaction is the first transaction in the block, which contains the miner's reward. It's the only type of transaction that doesn't have inputs 10:31 < marqusat> immature coinbase are funds that can be yet spent, require 101 confirmations 10:31 < sishir> For a coinbase tx to be spendable they have to be mature i.e. wait till 100 confirmations, I believe this is because lets say a block is orphaned before it gets 100 blocks deep into the chain, then only the miner is affected. 10:31 < _andrewtoth_> svav: In most cases yes, coinbase outputs are received by successful miners. Average Bitcoin users will likely not be affected by this bug, hence why I believe it has received little review. There are also cases like regtest where the wallet can receive coinbase outputs with generate RPCs, and for watchonly wallets that want to watch miner addresses. 10:31 < marqusat> The coinbase maturity concept exists so that impact of forks that may naturally briefly occur in the network doesn’t have an effect on spendability. 10:31 < glozow> a coinbase output looks identical to any other output though, so you'd need to see the transaction to identify that it's a coinbase (null input). that's why we store `fCoinbase` in coins? 10:32 < sishir> But why the number 100? Why not 6 confirmation like Bitcoin does with regular tx validation? 10:32 < larryruane_> why is it a _consensus rule_ that coinbase outputs aren't spendable for 100 blocks? 10:33 -!- cchrysos [88248599@136.36.133.153] has quit [Quit: Connection closed] 10:33 < larryruane_> how do coinbase outputs fundamentally differ from regular UTXOs? 10:34 < larryruane_> (just so we don't get too lost, all this ties back to the `include_immature` argument that this PR adds to these 4 RPCs) 10:34 < glozow> idk if there are any reasons other than forks https://bitcoin.stackexchange.com/questions/1991/what-is-the-block-maturation-time 10:35 -!- cchrysos [88248599@136.36.133.153] has joined #bitcoin-core-pr-reviews 10:35 < marqusat> it's a part of consensus because it affects the whole network and what is considered spendable atm 10:35 < glozow> larryruane_: just the 100 confs requirement. no other differences 10:36 < larryruane_> glozow: here is another similar link https://bitcoin.stackexchange.com/questions/20120/what-was-the-goal-of-creating-the-feature-of-immature-coins 10:36 < _andrewtoth_> a normal reorg can cause some txs to be unconfirmed again, but they will all still be valid and re-enter the mempool. If coinbase txs were spendable and there were many ancestors, then all those ancestor txs would become invalid in the reorg. 10:36 < larryruane_> _andrewtoth_: yes exactly! 10:36 < sishir> Coinbase outputs are very identical to normal tx, the only difference is that they have exactly 1 input which must be of a special form which is This txin's  0000...0000. 10:37 < _andrewtoth_> so the 100 block limit is protection against this 10:37 < glozow> s/ancestors/descendants? 10:37 < _andrewtoth_> glozow oops yes 10:37 < larryruane_> coinbase UTXOs are different because if there is a reorg, they may disappear ... a normal UTXO will likely appear in the reorged chain 10:38 -!- cguida [~Adium@2601:282:200:ae00:3dcc:eebe:8776:8907] has joined #bitcoin-core-pr-reviews 10:39 < lightlike> but whats the different treatment there? if normal transaction became invalid, their descendants would become invalid just the same - so why a special rule for coinbase transactions? 10:39 < lightlike> ah ok, thanks larryruane_ 10:39 < larryruane_> I think we're good on this point... so this is why the PR author (_andrewtoth_ ) has added the `include_immature`argument ... the default value is false, does that seem right? 10:40 < sishir> Yea it makes sense 10:40 < marqusat> It makes sense to have include_immature with default as false as that matches that by default minconf=1 so does not include funds from normal transactions which are not yet confirmed (spendable). 10:40 < larryruane_> (a UTXO _could_ become spent after a reorg, essentially a double-spend, but it's unlikely) 10:41 < glozow> i have gripes, I think the option should be `include_not_yet_spendable` 10:41 < Murch> hi 10:41 < svav> coinbase outputs are rewards for miners, and they might disappear if another chain surpasses the one the miner did. Hence, the coinbase output should not be spendable until 100 more blocks have passed, to ensure the miner's reward won't disappear, and to prevent the minder spending money that subsequently gets taken from them. Correct? 10:41 < larryruane_> hi Murch, welcome ... glozow that's a very interesting idea, in effect combine the two reasons 10:42 < _andrewtoth_> glozow: that does make sense to me 10:42 < glozow> hehe 10:43 < larryruane_> do we want to discuss glozow's idea here? or save it for the PR? I think it's definitely worth considering 10:43 < Murch> If new bitcoin got created with a block and were spendable immediately, reorgs would get extremely messy 10:44 < Murch> because not only would those funds disappear, but all descending txs would become invalid 10:44 < _andrewtoth_> glozow: if we had include_not_yet_spendable, then we would also have to include non-final txs if that option was set 10:44 < glozow> I don't mind either way, I'd prefer both minimum confirmations + spendability config 10:44 < glozow> _andrewtoth_: yeah. I think immature coinbases and non-final txs should be treated the same 10:45 < larryruane_> Also I recall reading somewhere that immediately spendable coinbase would make coins _nonfungible_ ... receivers would have a strong incentive to check whether they were being paid using (immature) coinbase or not 10:45 < glozow> i.e. "not spendable yet" 10:45 < glozow> and number of confirmations on the tx is a separate concern 10:45 < larryruane_> and some receivers (light clients?) may not even be able to do that 10:45 < jonatack> maybe look at the naming breakdown in rpc getbalances 10:45 < glozow> larryruane_: ohhh interesting 10:46 < Murch> why the maturation period is 100, I don't know, beyond it's sufficiently deep that a reorg is extremely unlikely 10:46 < sishir> Murch this was discussed a lil while ago. Follow up link https://bitcoin.stackexchange.com/questions/20120/what-was-the-goal-of-creating-the-feature-of-immature-coins 10:47 < glozow> teehee, Murch wrote that answer 10:47 < jonatack> sishir: look who replied to it 10:47 < glozow> We're phoning a friend 10:48 < sishir> oops 😅 10:48 < larryruane_> Great discussion, now if we're done with this subtopic, I did have one more thing to bring up... https://github.com/bitcoin/bitcoin/pull/14707#discussion_r613366384 10:48 < larryruane_> there I suggested refactoring some slightly complex logic so it's not nearly-duplicated ... 10:49 < larryruane_> General question, how should we decide when to refactor to eliminate redundant code, versus allowing the redundant code? 10:49 < glozow> Murch: do you know if the 100conf rule is older than UTXOSet? 10:49 < larryruane_> (BTW, if anyone would like to discuss earlier topics, please feel free!!) 10:50 < Murch> glozow: I think it was in the original relese 10:50 < Murch> *release 10:51 < jonatack> larryruane_: depends on if the code could use test coverage and complexity vs lines saved and the value of having a single point of truth, but personally i like smart, lean code but don't mind dumb verbose tests 10:51 < marqusat> larryruane_: https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) 10:53 < lightlike> Murch: definitely older than 2010, https://bitcointalk.org/index.php?topic=661.msg7293#msg7293 10:53 < larryruane_> Great points, TIL! I love your comment about verbose tests ... I once worked at a company that had a test framework that almost required a PhD to understand! Just to minimize test code. There's no reason to minimize test code, it must be understandable above all! 10:54 < jonatack> yes, because you don't have tests for the tests! (usually) 10:54 < larryruane_> exactly, oh, time's almost up, but you reminded me of one more question: 10:55 < larryruane_> this logic is somewhat complicated, but there are good tests included in this PR 10:55 < larryruane_> how can we test th tests? how can we make sure the tests are covering the various cases? 10:55 < marqusat> Code coverage. Additional way to “test the test” can be mutation testing. 10:55 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 10:56 < larryruane_> code coverage anaysis is great .. can you elaborate on mutation testing? 10:56 < jonatack> it's an automated version of manually changing the code and making sure the tests catch it 10:56 < marqusat> https://en.wikipedia.org/wiki/Mutation_testing 10:57 < Murch> lightlike: good find! 10:57 < larryruane_> perfect... I was going to say "break the code intentionally" but I didn't realize there are automated ways to do that! 10:57 < larryruane_> ok anything else? this has been super fun as my first time hosting, thank you all so much! 10:57 < marqusat> thank you! 10:58 < glozow> thanks larryruane_! 10:58 < _andrewtoth_> thanks larryruane_! 10:58 < lightlike> thank you! 10:58 < svav> Thanks 10:59 < jnewbery> thank you larryruane! Great meeting 10:59 < jnewbery> #endmeeting 10:59 < jonatack> thanks larryruane_ ! great job, looking forward to seeing you do this again 11:00 < larryruane_> thank you marqusat glozow _andrewtoth_ lightlike svav jnewbery Murch jonatack and anyone else I missed, TIL a lot! 11:00 -!- musdom [~Thunderbi@202.186.69.84] has quit [Ping timeout: 268 seconds] 11:00 -!- cchrysos [88248599@136.36.133.153] has quit [Quit: Connection closed] 11:00 < emzy> thank you larryruane_! 11:00 < schmidty> Thanks larryruane_ ! 11:01 * jonatack meeting log up in a few 11:01 -!- marqusat [~marqusat@185.107.57.4] has quit [Quit: Leaving] 11:01 < jonatack> ya'll can grab some popcorn and watch the drama in the other room ;) 11:04 < jarolrod> ^ lol 11:05 < jonatack> (looks like it made the price drop 😈) 11:05 -!- will__ [~will@dynamic-190-25-109-205.dynamic.etb.net.co] has quit [Remote host closed the connection] 11:10 < jnewbery> thanks jonatack! 11:15 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed] 11:18 < jonatack> Meeting log is up at https://bitcoincore.reviews/14707#meeting-log 🍰 11:21 -!- cec [aedb0499@153.sub-174-219-4.myvzw.com] has quit [Quit: Connection closed] 11:28 < jonatack> jnewbery: 🤙 11:55 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 11:57 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 12:05 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:08 -!- stortz [c8b9c69a@unaffiliated/stortz] has joined #bitcoin-core-pr-reviews 12:24 -!- will__ [~will@dynamic-190-25-109-205.dynamic.etb.net.co] has joined #bitcoin-core-pr-reviews 12:27 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 12:29 -!- will__ [~will@dynamic-190-25-109-205.dynamic.etb.net.co] has quit [Ping timeout: 265 seconds] 12:29 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 12:32 -!- stortz [c8b9c69a@unaffiliated/stortz] has quit [Quit: Connection closed] 12:32 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 12:34 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 13:00 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 13:01 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 13:32 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 13:34 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 14:04 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 14:06 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 14:06 -!- lightlike [~lightlike@p200300c7ef169b008d78383155562f3b.dip0.t-ipconnect.de] has quit [Quit: Leaving] 14:15 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 14:17 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 14:36 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 14:37 -!- musdom [~Thunderbi@202.186.69.84] has joined #bitcoin-core-pr-reviews 14:39 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 14:52 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Remote host closed the connection] 14:53 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-pr-reviews 15:09 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 15:11 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 15:28 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Read error: Connection reset by peer] 15:29 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 15:42 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 15:43 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 15:46 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds] 15:46 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 268 seconds] 15:48 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 15:50 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 16:14 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 16:16 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 16:46 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 16:47 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 17:19 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 17:21 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 17:52 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 17:53 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 18:06 -!- shaunapps [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews 18:16 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 18:17 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 18:18 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 18:22 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 18:23 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 18:24 -!- seven__ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Read error: Connection reset by peer] 18:24 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 18:26 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 18:34 -!- musdom [~Thunderbi@202.186.69.84] has quit [Quit: musdom] 18:34 -!- musdom1 [~Thunderbi@202.186.69.84] has joined #bitcoin-core-pr-reviews 18:36 -!- musdom1 is now known as musdom 18:38 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 18:56 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 18:58 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 19:29 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 19:34 -!- jadi [~jadi@37.98.3.133] has quit [Ping timeout: 265 seconds] 19:57 -!- shaunapps [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving] 20:07 -!- musdom [~Thunderbi@202.186.69.84] has quit [Ping timeout: 240 seconds] 20:19 -!- stortz [c8b9c69a@unaffiliated/stortz] has joined #bitcoin-core-pr-reviews 20:20 -!- musdom [~Thunderbi@202.186.69.84] has joined #bitcoin-core-pr-reviews 20:21 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 20:23 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 20:24 -!- musdom [~Thunderbi@202.186.69.84] has quit [Ping timeout: 240 seconds] 20:26 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds] 20:40 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 20:53 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 20:55 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 21:23 -!- gleb [~gleb@178.150.137.228] has quit [Ping timeout: 252 seconds] 21:26 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 21:27 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 21:58 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 22:17 -!- stortz [c8b9c69a@unaffiliated/stortz] has quit [Ping timeout: 240 seconds] 23:00 -!- jadi [~jadi@37.98.3.133] has quit [Remote host closed the connection] 23:00 -!- jadi [~jadi@37.98.3.133] has joined #bitcoin-core-pr-reviews 23:41 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews 23:41 -!- jakkoz [4ebca8ef@78.188.168.239] has joined #bitcoin-core-pr-reviews 23:42 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Remote host closed the connection] 23:42 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews 23:50 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 268 seconds] 23:51 -!- gleb [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews