--- Day changed Mon Jul 01 2019
00:17 -!- harding [~harding@c-73-196-98-36.hsd1.nj.comcast.net] has quit [Quit: leaving]     
00:18 -!- harding [~harding@c-73-196-98-36.hsd1.nj.comcast.net] has joined #bitcoin-core-pr-reviews     
01:15 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 244 seconds]     
01:22 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
01:24 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews     
01:24 -!- TheRec [~toto@84-72-172-174.dclient.hispeed.ch] has quit [Changing host]     
01:24 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews     
01:35 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds]     
02:02 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews     
02:46 -!- shesek [~shesek@188.120.152.125] has joined #bitcoin-core-pr-reviews     
02:46 -!- shesek [~shesek@188.120.152.125] has quit [Changing host]     
02:46 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
04:32 -!- ir0nbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has quit [Ping timeout: 244 seconds]     
04:55 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]     
04:57 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews     
05:48 < digi_james> I posted a spill-over question from last week related to the carve-out SizeAncestorLimit if anybody is interested or can help me better understand this issue: https://github.com/bitcoin/bitcoin/pull/15681#discussion_r299023410
05:50 < digi_james> Also, posted some thoughts/questions related to this week's review on getdescriptor (RPC) tests if anybody has feedback or answers. https://github.com/bitcoin/bitcoin/pull/15443#issuecomment-507229039
05:50 < digi_james> *getdescriptorinfo
06:09 -!- ironbutt [~LiberLive@82.142.166.82] has joined #bitcoin-core-pr-reviews     
06:13 -!- ironbutt [~LiberLive@82.142.166.82] has quit [Ping timeout: 246 seconds]     
06:18 -!- nijak_ [nijak@gateway/vpn/mullvad/nijak] has joined #bitcoin-core-pr-reviews     
06:21 -!- nijak [~nijak@2604:2000:12c1:e144:1ca1:c079:1e2e:3bf1] has quit [Ping timeout: 264 seconds]     
06:57 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds]     
06:57 -!- hebasto_ [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews     
07:39 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]     
08:04 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
08:17 -!- pinheadmz [~matthewzi@208.69.41.101] has joined #bitcoin-core-pr-reviews     
08:37 -!- Elmore30Fisher [~Elmore30F@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-pr-reviews     
08:39 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-tqwbgfzzanxjikrj] has joined #bitcoin-core-pr-reviews     
08:44 -!- Elmore30Fisher [~Elmore30F@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 245 seconds]     
09:05 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]     
09:11 -!- pinheadmz [~matthewzi@208.69.41.101] has quit [Quit: pinheadmz]     
09:15 -!- pinheadmz [~matthewzi@208.69.41.101] has joined #bitcoin-core-pr-reviews     
09:15 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
09:40 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 260 seconds]     
09:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
10:16 -!- pinheadmz [~matthewzi@208.69.41.101] has quit [Quit: pinheadmz]     
10:18 -!- pinheadmz [~matthewzi@208.69.41.101] has joined #bitcoin-core-pr-reviews     
10:22 < harding> digi_james: I don't think I understand your carve-out question.  I see where the chain of txes including the carve-out is allowed to be up to 1,000,000 vbytes in size (before other checks limiting it instead to 10,000 vbytes (40k weight)).  However, this check only runs if the new transaction would cause the previous limits to be exceeded, so I don't think it affects the previous limits.
10:26 < digi_james> harding: Thx for your reply. I am unsure why the carve-out has the ancestor size limit lifted to 1M vbytes at all.
10:27 -!- pinheadmz [~matthewzi@208.69.41.101] has quit [Quit: pinheadmz]     
10:27 -!- pinheadmz [~matthewzi@207.189.24.145] has joined #bitcoin-core-pr-reviews     
10:30 < digi_james> I can only surmise that the carve-out tx has more vbytes to work with than alternative child chains, but unsure of the scenario where this is necessary ...
10:31 < harding> digi_james: it has to be higher than the previous check, at least by the 10k vbytes.  By setting it to a very high value, this allows the 10k vbyte amount to be adjusted in future commits without any further code changes.  (Personally, my prefered code style would be to set a constant with the 10k amount and then use that for the > comparison and then with addition over the previous limit.
10:45 < digi_james> Hm, I seem to be misunderstanding something about the limits. Why does the ancestor-size-limit for the carve-out child tx need to be increased? The ancestor-size-limit in question would apply to the parent+carveout_tx and the same limit would independently apply to txs in alternative child-chains, no?
10:45 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]     
10:47 < digi_james> From what I currently understand, it is the descendant limits which are preventing additional txs from spending the parent outs, not the ancestor limits ... so lifting those is necessary.
10:56 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
11:07 < harding> digi_james: I don't think the ancestor size limit matters for the LN usecase for carve-out, but it may matter for other applications where the transaction being bumped is, e.g., 100K
11:15 < digi_james> harding: Right, that was my conclusion as well. However, if the transaction being bumped is 100k, the (non-1M vbyte) descendent limit will immediately be hit and no children can be attached. In this case, only the carve-out would be "allowed", and it would seem like a race condition to whomever can first occupy the carve-out, no?
11:18 < digi_james> (assuming the ancestor limit size for the carve out is >100k, e.g. 1M)
11:39 < harding> digi_james: oh!  That's your concern.  Yeah, it's intentional that there be only one carve-out exception.
12:16 < digi_james> Yes, only one carve-out. I mean if we consider the situation where the tx to-be-bumped is 100k, and the descendent limit is 100k, no child tx can be broadcast to bump our parent, since the package limit has been reached. Except our carve-out tx. But given only 1 is allowed, it seems like a race condition, especially for an LN tx with two hooks for fee bumping, one for Alice and one for Bob.
13:30 < harding> digi_james: that's fair.  I think in the case of LN, they don't expect the tx-to-be-bumped to be anywhere near 100K, so it's not a problem because there will be two opportunities for bumping.
13:31 < harding> But it's a good point you raise.
13:32 < harding> If transaction's over x size only get a maximum of one fee bump even with a carve out, I think that should probably at least be documented somewheret.
13:32 < harding> somewhere*
13:59 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]     
13:59 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
14:10 < digi_james> harding: Thanks a lot for helping me tidy up my thinking on this. I will fix up my PR comment to reflect this and refer to your comment above.
14:14 < harding> digi_james: thanks for reviewing!
14:27 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
14:30 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
14:34 < digi_james> I think I understand why the ancestor-size-limit for the carve out was lifted to 1M. If a local (user) ancestor-size-limit is set too low, it can block a carve-out tx and subsequent propagation in the network. With ancestor_size_limit lifted to 1M vBytes and ancestor_count_limit=2 for the carve_out, no local user limits can interfere. Does this sound correct?
15:14 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection]     
15:33 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Quit: Quit]     
15:35 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-pr-reviews     
16:07 -!- hugohn [~textual@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
16:27 -!- pinheadmz [~matthewzi@207.189.24.145] has quit [Read error: Connection reset by peer]     
16:28 -!- pinheadmz [~matthewzi@208.69.41.101] has joined #bitcoin-core-pr-reviews     
16:41 -!- pinheadmz [~matthewzi@208.69.41.101] has quit [Quit: pinheadmz]     
16:42 -!- pinheadmz [~matthewzi@208.69.41.101] has joined #bitcoin-core-pr-reviews     
17:42 -!- pinheadmz [~matthewzi@208.69.41.101] has quit [Quit: pinheadmz]     
18:47 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
18:52 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds]     
19:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 260 seconds]     
19:49 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 260 seconds]     
19:49 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
19:49 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
20:18 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]     
20:18 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
20:55 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
21:02 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
21:06 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has quit [Client Quit]     
21:09 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
21:10 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]     
21:28 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-tqwbgfzzanxjikrj] has quit [Quit: Connection closed for inactivity]     
21:28 -!- hugohn [~textual@pool-71-167-27-172.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds]     
21:40 -!- pinheadmz [~matthewzi@209.209.238.165] has joined #bitcoin-core-pr-reviews     
22:19 -!- pinheadmz [~matthewzi@209.209.238.165] has quit [Quit: pinheadmz]     
22:31 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
22:44 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]     
22:45 -!- pinheadmz [~matthewzi@209.209.238.165] has joined #bitcoin-core-pr-reviews     
23:01 -!- pinheadmz [~matthewzi@209.209.238.165] has quit [Quit: pinheadmz]     
23:13 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews