--- Log opened Thu Apr 08 00:00:19 2021
00:00 -!- rny [~rny@gateway/tor-sasl/renlord] has quit [Remote host closed the connection]
00:01 -!- rny [~rny@gateway/tor-sasl/renlord] has joined #bitcoin-core-dev
00:03 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
00:03 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
00:05 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
00:05 -!- pox [~pox@gateway/tor-sasl/pox] has joined #bitcoin-core-dev
00:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:09 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2e9031f95d2b...6664211be2b6
00:09 < bitcoin-git> bitcoin/master 9044522 Russell Yanofsky: Drop JSONRPCRequest constructors after #21366
00:09 < bitcoin-git> bitcoin/master 6664211 MarcoFalke: Merge #21574: Drop JSONRPCRequest constructors after #21366
00:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
00:09 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21574: Drop JSONRPCRequest constructors after #21366 (master...pr/simpreq) https://github.com/bitcoin/bitcoin/pull/21574
00:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
00:09 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined #bitcoin-core-dev
00:14 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
00:15 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
00:32 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
00:32 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
00:37 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
00:39 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
00:57 -!- smartineng [~Icedove@88.135.18.171] has quit [Remote host closed the connection]
01:02 -!- asdlkfjwerpoicvx [~flack@p200300d46f16910003441aa5842571c4.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:10 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
01:11 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev
01:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
01:13 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:27 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
01:27 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
01:36 -!- jadi is now known as testtttt
01:36 -!- testtttt is now known as jadi
02:17 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
02:17 -!- d [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
02:18 -!- d is now known as Guest96212
02:18 -!- awesome_doge1 [~Thunderbi@118-160-55-228.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
02:18 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
02:19 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
02:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:28 < bitcoin-git> [bitcoin] MarcoFalke reopened pull request #21445: cirrus: Use SSD cluster for speedup (master...2103-ciSSD) https://github.com/bitcoin/bitcoin/pull/21445
02:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:09 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
03:10 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
03:10 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
03:11 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
03:16 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:16 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #19048: test: changing signature of wait_until(). (master...fixing-waituntil) https://github.com/bitcoin/bitcoin/pull/19048
03:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:18 -!- Stanford49Kuhic [~Stanford4@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-dev
03:29 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
03:29 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
03:36 -!- ctrlbreak_MAD [~ctrlbreak@159.2.165.130] has joined #bitcoin-core-dev
03:39 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has quit [Ping timeout: 246 seconds]
03:58 -!- Kiminuo [~Kiminuo@141.98.103.116] has joined #bitcoin-core-dev
03:59 -!- awesome_doge1 [~Thunderbi@118-160-55-228.dynamic-ip.hinet.net] has quit [Ping timeout: 268 seconds]
04:00 < Kiminuo> sdaftuar, Hi, is there a reason why lines L288 and L289 were not deleted in PR #12127 (https://github.com/bitcoin/bitcoin/pull/12127/files#diff-f4f454edbfa1a878a9d4ad4371611c6c2812b7c77d2bd01baa66606524b61f9eL290)? 
04:00 < gribble> https://github.com/bitcoin/bitcoin/issues/12127 | Remove unused mempool index by sdaftuar · Pull Request #12127 · bitcoin/bitcoin · GitHub
04:01 -!- ishaqm [~ishaqm@host-92-7-165-227.as43234.net] has joined #bitcoin-core-dev
04:04 -!- Stanford49Kuhic [~Stanford4@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]
04:07 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
04:08 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
04:18 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
04:19 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
04:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds]
04:34 -!- ishaqm [~ishaqm@host-92-7-165-227.as43234.net] has quit [Ping timeout: 252 seconds]
04:47 -!- smartineng [~Icedove@88.135.18.171] has joined #bitcoin-core-dev
05:04 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
05:04 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
05:33 -!- stevenroose [~steven@2001:19f0:6801:83a:8cb5:4b5c:210d:f98a] has quit [Remote host closed the connection]
05:34 -!- stevenroose [~steven@irc.roose.io] has joined #bitcoin-core-dev
05:52 -!- NiamhOnMars [~niamh@aaubervilliers-654-1-61-83.w86-218.abo.wanadoo.fr] has joined #bitcoin-core-dev
05:52 < NiamhOnMars> hi I was wondering why the original bitcoin code had some irc related code to join the #bitcoin IRC channel
05:54 < elichai2> NiamhOnMars: IIRC it was used to find other peers (before the dns seeding)
06:10 -!- Guest96212 is now known as davyerra
06:10 -!- davyerra is now known as davterra
06:12 -!- Kiminuo [~Kiminuo@141.98.103.116] has quit [Quit: Leaving]
06:17 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
06:18 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
06:37 < _flow_> that
06:48 -!- belcher_ is now known as belcher
06:49 -!- realname192 [~real@37.160.142.119] has joined #bitcoin-core-dev
06:52 -!- realname192 [~real@37.160.142.119] has quit [Client Quit]
06:56 -!- _flow_ is now known as flow
06:57 -!- realname192 [~real@37.160.142.119] has joined #bitcoin-core-dev
07:00 -!- realname192 [~real@37.160.142.119] has quit [Client Quit]
07:00 -!- realname192 [~real@37.160.142.119] has joined #bitcoin-core-dev
07:01 -!- realname192 [~real@37.160.142.119] has quit [Client Quit]
07:06 -!- roconnor [~roconnor@host-192.252-170-125.dyn.295.ca] has quit [Quit: Konversation terminated!]
07:20 -!- no_cluez [~no_cluez@185.204.1.185] has quit [Remote host closed the connection]
07:23 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
07:24 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
07:27 -!- de6df1re [~igloo@h184-60-25-110.mdtnwixa.dsl.dynamic.tds.net] has joined #bitcoin-core-dev
07:28 -!- de6df1re [~igloo@h184-60-25-110.mdtnwixa.dsl.dynamic.tds.net] has quit [Client Quit]
07:30 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
07:31 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
07:55 -!- kabaum [~kabaum@84.216.128.102] has joined #bitcoin-core-dev
08:03 -!- nihui [~nihui@139.28.218.148] has joined #bitcoin-core-dev
08:08 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-dev
08:08 -!- proofofkeags_ [~proofofke@97-118-239-55.hlrn.qwest.net] has quit [Ping timeout: 260 seconds]
08:28 -!- proofofkeags_ [~proofofke@205.209.28.54] has joined #bitcoin-core-dev
08:36 -!- ishaqm [~ishaqm@host-89-243-181-183.as13285.net] has joined #bitcoin-core-dev
08:50 -!- cguida [~Adium@205.209.28.54] has joined #bitcoin-core-dev
08:54 -!- cguida [~Adium@205.209.28.54] has quit [Client Quit]
08:54 -!- cguida [~Adium@205.209.28.54] has joined #bitcoin-core-dev
08:54 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving]
09:08 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
09:09 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
09:17 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.]
09:17 -!- asdlkfjwerpoicvx [~flack@p200300d46f16910003441aa5842571c4.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
09:25 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds]
09:25 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
09:27 -!- _joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has joined #bitcoin-core-dev
09:30 -!- joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has quit [Ping timeout: 260 seconds]
09:32 -!- cguida [~Adium@205.209.28.54] has joined #bitcoin-core-dev
09:32 -!- kabaum [~kabaum@84.216.128.102] has quit [Ping timeout: 240 seconds]
09:38 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Remote host closed the connection]
09:38 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev
09:47 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has joined #bitcoin-core-dev
09:47 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has quit [Remote host closed the connection]
09:53 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
09:58 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
09:59 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
10:01 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Remote host closed the connection]
10:02 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev
10:24 -!- jadi [~jadi@93.119.217.23] has quit [Ping timeout: 248 seconds]
10:24 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
10:36 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
10:36 -!- ishaqm [~ishaqm@host-89-243-181-183.as13285.net] has quit [Ping timeout: 248 seconds]
10:36 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
10:41 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
10:41 -!- kabaum [~kabaum@ua-84-216-128-102.bbcust.telenor.se] has joined #bitcoin-core-dev
10:42 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
10:46 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
10:48 -!- ishaqm [~ishaqm@host-89-243-181-183.as13285.net] has joined #bitcoin-core-dev
10:50 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
11:00 -!- lightlike [~lightlike@p200300c7ef15ae002d9e80bf7bee35d2.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
11:07 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
11:10 -!- _joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has quit [Ping timeout: 259 seconds]
11:11 -!- joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has joined #bitcoin-core-dev
11:23 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
11:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 265 seconds]
11:28 -!- lukedashjr is now known as luke-jr
11:28 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
11:29 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has joined #bitcoin-core-dev
11:46 -!- ishaqm [~ishaqm@host-89-243-181-183.as13285.net] has quit [Ping timeout: 265 seconds]
11:47 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
11:51 -!- ishaqm [~ishaqm@host-89-243-181-183.as13285.net] has joined #bitcoin-core-dev
11:57 < luke-jr> #proposedmeetingtopic attempts to use "dev muscle" to force MTP against community consensus of BIP8
12:01 < wumpus> #startmeeting
12:01 < jonasschnelli> hi
12:01 < sipsorcery> hi
12:01 < hebasto> hi
12:01 < wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
12:01 < wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
12:02 < jonatack> hi
12:02 < amiti> hi
12:02 < fjahr> hi
12:02 < jeremyrubin> hallo
12:02 < phantomcircuit> uhm hello
12:02 < achow101> hi
12:02 < jnewbery> hi
12:02 < luke-jr> hi
12:02 < wumpus> one proposed meeting topic: attempts to use "dev muscle" to force MTP against community consensus of BIP8 (luke-jr)
12:02 < wumpus> any last minute suggestions?
12:03 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:03 < wumpus> (as a reminder: you can propose a meeting topic with #proposedmeetingtopic <topic> at any time during the week)
12:03 < wumpus> #topic High priority for review
12:03 < core-meetingbot> topic: High priority for review
12:04 < wumpus> https://github.com/bitcoin/bitcoin/projects/8 has 11 blockers, 2 chasing concept ACK
12:04 < wumpus> anything to add, remove, or that is ready to merge?
12:04 < jonatack> #21392 seems closed, remove?
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
12:04 < wumpus> jonatack: looks like it
12:04 < jonatack> (not opining, just info)
12:04 < achow101> remove for now
12:05 < wumpus> should we add #21377 instead?
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
12:05 < luke-jr> replace with #19573
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/19573 | Replace unused BIP 9 logic with draft BIP 8 by luke-jr · Pull Request #19573 · bitcoin/bitcoin · GitHub
12:05 < luke-jr> #21377 is NACK
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
12:05 < achow101> We can add 21377 to hi prio
12:05 < luke-jr> it would be an abuse of position to merge 21377
12:06 < wumpus> ok never mind...
12:06 < wumpus> anything else?
12:06 < achow101> #17331 for me
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/17331 | Use effective values throughout coin selection by achow101 · Pull Request #17331 · bitcoin/bitcoin · GitHub
12:06 < jeremyrubin> +1 #21377 for high priority for review
12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
12:07 < wumpus> achow101: added
12:07 < jeremyrubin> I think irrespective of if it is merged, reviewing it is high priority 
12:08 < wumpus> in the end it's up to the author (ajtowns) if he wants it has high prio, but you're right that is separate from whether it can be merged or not
12:08 < jeremyrubin> he can ack adding it after the meeting, unclear if he's present
12:09 < wumpus> yes
12:09 < wumpus> that concludes high priority for review unless anyone else has suggstions
12:10 < wumpus> #topic Attempts to use "dev muscle" to force MTP against community consensus of BIP8 (luke-jr)
12:10 < core-meetingbot> topic: Attempts to use "dev muscle" to force MTP against community consensus of BIP8 (luke-jr)
12:10 < jonatack> #19521 freshly needs rebase but should be close to ready, it's been through a number of review rounds by provoostenator and i
12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/19521 | Coinstats Index by fjahr · Pull Request #19521 · bitcoin/bitcoin · GitHub
12:10 < luke-jr> I find it quite disturbing a few devs are attempting a NYA-like push to make consensus changes outright disregarding the community consensus around BIP 8.
12:10 < wumpus> jonatack: good to know!
12:11 < jeremyrubin> As the author behind the quoted "dev muscle", I would like to note that the context in which it was used was referring to sufficient resources to review and audit the corresponding PR
12:11 < luke-jr> and for no real apparent reason but to spite UASFers by reverting all the improvements made over 2017 - widely acknowledged as improvements until LOT=True began to move forward
12:12 < jeremyrubin> It is not in the context of devs muscling the community, which i think it has been represented to be in the setting of this topic
12:12 < jnewbery> As usual, luke-jr is misrepresenting
12:12 < luke-jr> no, I am not
12:12 < luke-jr> nor is that usual
12:13 < achow101> there is a person who has raised an unaddressed objection to BIP 8, therefore it does not have consensus
12:13 < luke-jr> jnewbery: I don't know what you have against me, but trolling liek that is unproductive and malicious.
12:14 < jeremyrubin> anyone is free to review the logs for relevent context http://gnusha.org/taproot-activation/2021-04-06.log
12:14 < jnewbery> at the very least you're misrepresenting the intent of jeremy's words
12:14 < luke-jr> achow101: even if that were true,  all but one person is still far more than this MTP nonsense
12:14 < jeremyrubin> i've also summarized from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018746.html
12:14 -!- proofofkeags_ [~proofofke@205.209.28.54] has quit [Ping timeout: 240 seconds]
12:14 < luke-jr> jnewbery: read the log
12:14 < jnewbery> I've read it, thanks
12:15 < achow101> at this time, 21377 is in a state where everyone except luke-jr is okay with it, and onlyu luke-jr has stated "no" and "nack" without providing any reasoning behind those statements
12:15 < achow101> simply asserting "no" and "nack" is not an objection
12:15 < jnewbery> achow101: +1
12:15 < luke-jr> achow101: that isn't true
12:16 < jeremyrubin> https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#conceptual-review
12:16 < luke-jr> there is practically no community support for 21377, just a handful of devs
12:16 < jeremyrubin> A NACK needs to include a rationale why the change is not worthwhile. NACKs without accompanying reasoning may be disregarded.
12:16 < luke-jr> and most of you acknowledge height is better
12:16 < achow101> luke-jr: so all of the people who participated in the meeting yesterday or all devs?
12:16 < achow101> *are
12:17 < luke-jr> achow101: I didn't say that, but it's far fewer than the consensus around BIP8
12:17 < luke-jr> not even comparable
12:17 < jeremyrubin> numerous ACKs on https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3695024 which is nonspecific to height or MTP
12:17 < luke-jr> the whole point of ST in the first place, was to be a neutral start between the simple disagreement on LOT
12:18 < luke-jr> throwing away the consensus on everything else defeats the point
12:18 < luke-jr> jeremyrubin: that gist was about height
12:18 < jnewbery> luke-jr: most people have stopped responding to your outlandish claims because there's almost no point. There's no evidence that your proposal has "community support"
12:18 < jeremyrubin> it was about harding's proposal https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html
12:19 < luke-jr> jnewbery: far more evidence than this MTP nonsense
12:19 < jeremyrubin> which says: " The idea can be implemented on top of either Bitcoin Core's existing BIP9 code or its proposed BIP8 patchset.[6]"
12:19 < jnewbery> you've had plenty of opportunity to make your case already. What exactly do you hope to achieve in this meeting by restating things you've claimed many times before in many previous meetings?
12:20 -!- owowo [~ovovo@2a02:29b8:dc01:597::1e] has joined #bitcoin-core-dev
12:20 -!- owowo [~ovovo@2a02:29b8:dc01:597::1e] has quit [Changing host]
12:20 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
12:20 -!- ovovo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 246 seconds]
12:21 < jeremyrubin> I'd also invite those unfamiliar to review a different community's operating procedure https://tools.ietf.org/html/rfc7282
12:22 < achow101> there have been a few people who pop in and nack 21377, however those nacks are always unsubstantiated and no response is provided upon asking for the motivation behind those nacks
12:22 < luke-jr> the problems with MTP are well-known and shouldn't need ot be repeated constantly
12:23 < jeremyrubin> I think aj and achow101 adressed them in a very elegent manner 
12:23 < jeremyrubin> so i do not beleive any of the past issues are unaddressed 
12:23 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev
12:23 < jeremyrubin> if you would like to contest the solutions as they are, you should review the current proposed changes and comment on that
12:24 -!- ishaqm [~ishaqm@host-89-243-181-183.as13285.net] has quit [Remote host closed the connection]
12:25 < luke-jr> hack after hack is not addressing issues. nor does it justify disregarding community consensus.
12:25 < achow101> luke-jr: you should repeat them in the context of this proposal specifically. Many contributors/reviewers may not be aware of them because either they occurred in a venue that they were not aware of, or they occurred at a time where they were not active participants in development.
12:26 < achow101> if they have already been stated in the context of the proposal being reviewed, then please link them
12:26 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
12:26 < jeremyrubin> further, there does seem to be a substantial body of agreeing devs on the approach put forward in 21377. so there can hardly be said to be consensus for any other approach either
12:26 < jnewbery> luke-jr: there is no evidence that your proposal has "community consensus"
12:27 < luke-jr> jnewbery: that is not true
12:27 < achow101> asserting it does not make it true or false
12:29 < jnewbery> luke-jr: I'll ask again: what is your aim for this meeting item? You've had a chance to raise your objections.
12:29 < achow101> "What can be asserted without evidence can also be dismissed without evidence."
12:29 < luke-jr> anyone involved in the community knows there is consensus around BIP8.
12:29 < jeremyrubin> I don't have anything else to add on this matter; I think it should be relatively clear what sort of communications would be required to raise a tangible objection to 21377. 
12:30 < aj> wumpus: (thanks for adding 21377 to hi pri)
12:30 < jeremyrubin> #proposedmeetingtopic meeting notes & timelines implied 
12:31 < luke-jr> wumpus: reminder to add #19573 too
12:31 < wumpus> #topic Meeting notes & timelines implied (jeremyrubin)
12:31 < core-meetingbot> topic: Meeting notes & timelines implied (jeremyrubin)
12:31 < gribble> https://github.com/bitcoin/bitcoin/issues/19573 | Replace unused BIP 9 logic with draft BIP 8 by luke-jr · Pull Request #19573 · bitcoin/bitcoin · GitHub
12:32 < wumpus> luke-jr: ok added
12:33 < wumpus> jeremyrubin: or was that a topic fo rnext week?
12:34 < wumpus> #endmeeting
12:34 < core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
12:34 < core-meetingbot> Meeting ended Thu Apr  8 19:34:35 2021 UTC.  
12:34 < core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-04-08-19.01.moin.txt
12:34 -!- jeremy_booted [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
12:35 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds]
12:36 < jnewbery> thanks wumpus!
12:38 -!- jeremy_booted [~jr@024-176-247-182.res.spectrum.com] has quit [Client Quit]
12:38 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
12:38 < jeremyrubin> Hi
12:38 < jeremyrubin> not sure if my previous messages made it through
12:39 < jeremyrubin> i got booted right after proposing a meeting topic and was unable to rejoin/reauth 
12:39 < aj> nothing after your meeting topic made it through, so wumpus ended the meeting
12:39 < jeremyrubin> wumpus: it was intended to be for today
12:39 -!- proofofkeags_ [~proofofke@205.209.28.54] has joined #bitcoin-core-dev
12:39 < jeremyrubin> aj: do you think it needs to be discussed today?
12:40 < jeremyrubin> or is next week sufficient?
12:40 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev
12:40 < aj> jeremyrubin: could just ask outside of the meeting? waiting 'til next week probably answers the question on its own though...
12:42 < jeremyrubin> I think more or less -- for those who are still reading -- the point is that the rough timeline from the 1st meeting still seems viable, so short of something unexpected that's probably what people are working towards
12:44 -!- kabaum [~kabaum@ua-84-216-128-102.bbcust.telenor.se] has quit [Ping timeout: 260 seconds]
12:44 < jnewbery> jeremyrubin: what is that timeline?
12:44 < jeremyrubin> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018715.html rough timeline is here
12:45 -!- kabaum [~kabaum@ua-84-216-128-102.bbcust.telenor.se] has joined #bitcoin-core-dev
12:45 < jeremyrubin> starttime is relatively flexible, as with endtime (nothing wrong with capturing signals earlier because min active height)
12:46 < jnewbery> thanks!
12:46 < jeremyrubin> the activation height should just be something around 707616, but the exact value doesn't matter that much
12:48 < jeremyrubin> (well, it does matter, we can pick whatever n*2016 looks like it will be near mid novemeber)
12:55 -!- smartineng [~Icedove@88.135.18.171] has quit [Quit: smartineng]
13:02 -!- kabaum [~kabaum@ua-84-216-128-102.bbcust.telenor.se] has quit [Ping timeout: 240 seconds]
13:05 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds]
13:08 -!- stortz [c8b9c69a@unaffiliated/stortz] has joined #bitcoin-core-dev
13:13 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
13:14 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
13:18 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
13:18 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
13:21 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
13:23 -!- outfawkesd__ [outfawkesd@gateway/vpn/privateinternetaccess/outfawkesd] has joined #bitcoin-core-dev
13:24 -!- Eric3 [~exeric3@mail.miners-zone.net] has joined #bitcoin-core-dev
13:25 -!- einyx [einyx@fsf/member/einyx] has joined #bitcoin-core-dev
13:26 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds]
13:26 -!- spinza [~spin@102.132.245.16] has quit [Ping timeout: 268 seconds]
13:26 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has quit [Read error: Connection reset by peer]
13:26 -!- ExEric3 [~exeric3@mail.miners-zone.net] has quit [Ping timeout: 268 seconds]
13:26 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has joined #bitcoin-core-dev
13:26 -!- outfawkesd_ [outfawkesd@gateway/vpn/privateinternetaccess/outfawkesd] has quit [Ping timeout: 268 seconds]
13:26 -!- Eliel [~jojkaart@163.172.153.251] has quit [Ping timeout: 268 seconds]
13:26 -!- einyx_ [einyx@fsf/member/einyx] has quit [Ping timeout: 268 seconds]
13:27 -!- Eliel [~jojkaart@163.172.153.251] has joined #bitcoin-core-dev
13:30 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
13:30 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
13:44 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
14:05 -!- Pablo1981 [~Pablo1981@156.146.62.55] has joined #bitcoin-core-dev
14:05 -!- Kati [~Pablo1981@156.146.62.47] has joined #bitcoin-core-dev
14:07 -!- Kati [~Pablo1981@156.146.62.47] has quit [Client Quit]
14:09 -!- Pablo1981 [~Pablo1981@156.146.62.55] has quit [Ping timeout: 260 seconds]
14:10 -!- nckx [~nckx@tobias.gr] has quit [Quit: Updating my Guix System — https://guix.gnu.org]
14:13 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
14:14 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
14:18 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
14:19 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
14:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:20 < bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/6664211be2b6...0c9597ce7db2
14:20 < bitcoin-git> bitcoin/master 84912d4 Carl Dong: build: Remove spaces from variable-printing rules
14:20 < bitcoin-git> bitcoin/master 44f6d4f Carl Dong: guix: Record precious directories and add guix-clean
14:20 < bitcoin-git> bitcoin/master 8f8b96f Carl Dong: guix: Update hint messages to mention guix-clean
14:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:21 < bitcoin-git> [bitcoin] laanwj merged pull request #21304: guix: Add guix-clean script + establish gc-root for container profiles (master...2021-02-guix-clean-script) https://github.com/bitcoin/bitcoin/pull/21304
14:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:22 -!- nckx [~nckx@tobias.gr] has joined #bitcoin-core-dev
14:29 -!- Guyver2_ [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:32 -!- cmirror [~cmirror@4.53.92.114] has quit [Quit: (Botdeath)]
14:33 < jeremyrubin> does testmempoolaccept handle the case of [A -> B, B->C, C->D] etc?
14:33 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
14:34 < jeremyrubin> or is each considered independently 
14:34 < glozow> jeremyrubin: what do you mean?
14:34 < jeremyrubin> (Not packages)
14:34 < glozow> are A, B, C, and D transactions?
14:34 < jeremyrubin> outputs
14:35 < jeremyrubin> like assuming A->B is testmempool accept = true
14:35 < glozow> what does A->B mean?
14:35 < jeremyrubin> can B->C be true?
14:35 < jeremyrubin> Some output A creates some output B
14:35 < jeremyrubin> can there be dependencies between the txs in the array
14:35 < glozow> yes
14:35 < glozow> with #20833 i mean
14:35 < gribble> https://github.com/bitcoin/bitcoin/issues/20833 | rpc/validation: enable packages through testmempoolaccept by glozow · Pull Request #20833 · bitcoin/bitcoin · GitHub
14:36 < jeremyrubin> packages is a different thing
14:36 < glozow> on master you can only submit 1 at a time
14:36 < jeremyrubin> that's considering CPFP
14:36 < jeremyrubin> 1. rawtxs          (json array, required) An array of hex strings of raw transactions.
14:36 < glozow> rawtxs can only have 1 tx on master
14:37 < jeremyrubin> ahh ok                    "Length must be one for now."
14:37 < luke-jr> jeremyrubin: how is this distinct from packages?
14:37 < jeremyrubin> packages is a superset of this
14:37 < luke-jr> ?
14:37 < jeremyrubin> I'm not interested in applying CPFP logic
14:38 < glozow> do you define packages as just an array of transactions?
14:38 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
14:38 < luke-jr> does 20833 do CPFP?
14:38 < sipa> cpfp is a transaction selection policy
14:38 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
14:38 < luke-jr> "the expectation is that the results returned from testmempoolaccept are identical to what you'd get from test-then-submitting each transaction individually, in that order"
14:38 < sipa> that's independent from menpool acxwptance policies
14:38 < luke-jr> 20833's description suggests it doesn't do CPFP logic
14:39 < glozow> CPFP happens after mempool submission
14:39 < jeremyrubin> testmempoolaccept can fail due to insufficient fee tho correct?
14:39 < sipa> cpfp doesn't apply to mempool accwptance
14:39 < luke-jr> jeremyrubin: yes
14:39 < sipa> jeremyrubin: tgat's where packages come in
14:39 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
14:39 < jeremyrubin> that's my point
14:40 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
14:40 < glozow> yes, but it's a small addition to make `testmempoolaccept` use the descendant feerate instead of base feerate
14:40 < luke-jr> …
14:40 < sipa> jeremyrubin: so i have no idea what you're asking about
14:40 < jeremyrubin> testmempoolaccept does check fees
14:40 < sipa> yes
14:40 < glozow> yes, obviously
14:40 < luke-jr> jeremyrubin: for each tx, individually
14:41 < sipa> for now
14:41 < jeremyrubin> well only one tx is allowed for now anyways
14:41 < glozow> testmempoolaccept only takes 1 transaction right now.
14:41 < luke-jr> sipa: if it does anything different later, it should be optional IMO
14:41 < glozow> are we talking about behavior or master or?
14:41 < jeremyrubin> so if I have A -> B paying 10000 feerate, i'm not worried about if it can go in or not
14:41 < jeremyrubin> based on fees
14:41 < luke-jr> I imagine the use case is, you want to submit A now, B later
14:41 < jeremyrubin> but I still want to test if B -> C is valid
14:41 < luke-jr> and not wait for B, for A to get confirmed
14:41 < glozow> yes
14:42 < jeremyrubin> so I'm trying to figure out how I can test the validity of a child transaction from a parent I don't want in the mempool
14:42 < jeremyrubin> i just want to test it
14:42 < luke-jr> jeremyrubin: using that PR
14:42 < glozow> then use 20833
14:42 < jeremyrubin> Ok, but there's no current way to do this?
14:42 < luke-jr> jeremyrubin: if you need to bypass fee checks, use Knots
14:43 < glozow> no, there isn't
14:43 < jeremyrubin> no the fees aren't important
14:43 < glozow> except to disconnect your node
14:43 < jeremyrubin> I'm asking about the dependency graph
14:43 < luke-jr> actually, I didn't get 20833 in Knots yet :/
14:43 < jeremyrubin> glozow: that's probably the best bet for now
14:43 < luke-jr> jeremyrubin: then 20833 is enough…?
14:43 < glozow> 20833 works with dependencies 
14:43 < jeremyrubin> 20833 would do it, I was just asking if there's something that works today that doesn't cover CPFP
14:44 < luke-jr> aha
14:44 < luke-jr> but 20833 does work today ;)
14:44 < glozow> :D
14:44 < glozow> needs review
14:44 < jeremyrubin> I'll take a look
14:44 < glozow> thanks!
14:44 < jeremyrubin> I understood 20833 to be focused on the CPFP issue
14:44 < jeremyrubin> but it's clear it's even more important now :)
14:45 < glozow> 🙏
14:46 < luke-jr> jeremyrubin: 20833 is explicitly not CPFP related
14:46 < jeremyrubin> does it apply CPFP rules?
14:47 < glozow> CPFP rules are applied during block template building
14:47 < glozow> i guess the answer to your question is no
14:47 < glozow> *not yet
14:48 < jeremyrubin> Ok, so the testmempoolaccept 20833 will fail if tx 0 of a chain pays low fee?
14:48 < glozow> yes, if the base feerate is too low, it will fail
14:48 < glozow> the fix for that is to just use descendant feerate instead, which I'm saving for a followup to 20833
14:49 < jeremyrubin> great, that answers my q
14:49 < glozow> cool!
14:49 < jeremyrubin> FWIW i think the way I define packages is cuts through the transaction graph which can be mined within a block
14:50 < jeremyrubin> so an array of txns is not a package nesc because there are arrays of txns which can't mine within a block (relative time locks, too many MB, etc)
14:50 < glozow> so if there are conflicts -> not a package?
14:50 < jeremyrubin> example?
14:50 < jeremyrubin> like [A -> B, A->C]?
14:50 < glozow> [A->B, A->C]
14:50 < glozow> yeah
14:51 < jeremyrubin> yeah I don't consider that a package?
14:51 < glozow> mm
14:51 < glozow> what about [B->C, A->B] ?
14:51 < jeremyrubin> well I think that depends on what your brackets mean
14:51 < glozow> i.e., does order matter?
14:52 < jeremyrubin> I think it would be wise to make sure that core only ever outputs packages in increasing ancestor order
14:52 < jeremyrubin> but that we should accept them in any order
14:52 < jeremyrubin> in particular, when mining you generate them in reverse order
14:53 < luke-jr> huh?
14:53 < Murch> hum?
14:53 < glozow> ?
14:53 < jeremyrubin> When you're mining you pick the thing with the best feerate and then take all the ancestors
14:53 < Murch> Nope
14:53 < jeremyrubin> and then later you sort them into ancestor order
14:53 -!- cmirror [~cmirror@4.53.92.114] has quit [Quit: (Botdeath)]
14:53 < Murch> Transactions must be sorted in topological order
14:53 < glozow> you pick by ancestor feerate, and you mine the ancestors first
14:53 < jeremyrubin> yeah you sort them after
14:54 < jeremyrubin> but the packages are visited reverse order
14:54 < Murch> You pick whole ancestor packages
14:54 < glozow> is that necessarily true? you could have parent with higher ancestor feerate than child, and you'd pick the parent first
14:54 < jeremyrubin> it is true -- you won't pick the child till later then 
14:54 < Murch> Yeah, but then the parent would have a higher ancestor feerate and take precendence by itself anyway
14:56 < jeremyrubin> https://github.com/bitcoin/bitcoin/blob/0c9597ce7db28f5272a69bf0fbb36ce6b2520566/src/miner.cpp#L404
14:58 < jeremyrubin> anyways it's not super important, once they're in the block they're in consensus order
14:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
14:59 < Murch> It groups each transaction with all of the transactions it depends on
14:59 < Murch> Then it picks the best of these ancestor packages per ancestorfeerate (i.e. the effective feerate of the whole package)
14:59 < Murch> then updates the mempool
15:01 < jeremyrubin> I don't see that in the code?
15:01 < jeremyrubin> Can you point me to a line
15:01 < jeremyrubin> What i see is:
15:01 < jeremyrubin> pick by ancestor score
15:02 < jeremyrubin> make sure the package fits
15:02 < Murch> Yeah, but transactions without ancestors are an ancestorpackage by themselves
15:02 < jeremyrubin> compute all the ancestors
15:02 < jeremyrubin> add them to the block in block sort order
15:03 < Murch> yes?
15:03 < Murch> But the "ancestorscore" is the effective feerate of a transaction with its ancestors
15:03 < glozow> before block assembly starts, the txns already know their ancestor fees and size. you just call `CalculateMempoolAncestors` to grab the mempool entries
15:04 < jeremyrubin> Yes, and the order those are visited in shows up in a reversed order
15:04 < jeremyrubin> this is relevent because the epoch memepool patches will literall put them in order of [B -> C, A->B]
15:05 -!- lightlike [~lightlike@p200300c7ef15ae002d9e80bf7bee35d2.dip0.t-ipconnect.de] has quit [Quit: Leaving]
15:05 < jeremyrubin> So gloria's question is, is [B->C, A->B] still a package, or must it be [A->B, B->C]
15:05 < jeremyrubin> my answer is diff algorithms will generate a package set in different orders
15:06 < jeremyrubin> so we should recognize any order they show up in
15:06 < glozow> i mean a package communicated between peers
15:06 < jeremyrubin> but that we should also be careful to pick a single order if we ever e.g. print them out
15:06 < glozow> that's what we'd be interested in formalizing the definition for
15:07 < jeremyrubin> it's a good question, there's a DoS argument for picking a defined order because it's O(n log n) to sort self-side v.s. O(n) to verify
15:07 < glozow> what's n?
15:07 < Murch> Number of txs?
15:07 < jeremyrubin> I think n is the number of inputs
15:08 < jeremyrubin> but maybe it's just # of txs, would need to draw out the actual dependency calculating algorithm
15:09 < glozow> no, it'd depend on number of inputs
15:09 < jeremyrubin> there's also a good question of if we should have a canonical ordering that a package must be in, more so than block order
15:09 < jeremyrubin> since blocks are not canonically ordered 
15:10 < Murch> Do you mean topologically ordered but with canonical order when there is multiple possibilities?
15:10 < jeremyrubin> correct
15:10 < jeremyrubin> e.g., input/vout order 
15:10 < glozow> it would matter if you had package IDs
15:11 < jeremyrubin> glozow: good point, should prolly make a canonical ordering then :)
15:11 < jeremyrubin> glozow: I'd say figure out if there's any algorithmic advantage for having the txns in a specific order on the receiving side
15:11 < glozow> i'd say require them to be ordered
15:11 < glozow> it's pretty easy to figure out if a package is ordered correctly
15:11 < Murch> Well, topological order would be nice, not sure whether it's worthwhile to further restrain it
15:11 < glozow> should be the sender's burden to sort them
15:11 < jeremyrubin> Murch: package IDs
15:12 < jeremyrubin> if you want them to be hashable you need a canonical order
15:12 < glozow> e.g. topological order (by # of ancestors within package), lexicographic by txid to break ties
15:12 < jeremyrubin> but glozow in theory it's not that bad, a dirty client can always send you crap
15:12 < glozow> if they send you crap, just reject it
15:12 < glozow> the package - maybe not the txs within it
15:13 < Murch> Why would we need package ids?
15:13 < jeremyrubin> Anyways that seems like an OK plan, maybe lexicographic by wtxid tho
15:13 < glozow> to announce packages/getdata
15:13 < Murch> mh
15:14 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
15:14 < Murch> Doesn't that mean that you could send a peer the same txs a bunch of times by generating each valid subset and announcing it as a separate package?
15:15 < jeremyrubin> Murch: correct, but you can ban peers which send you packages containing crap you already have I suppose?
15:15 < glozow> yeah
15:15 < jeremyrubin> You can also generate the subsets yourself and add their IDs to your bloom filter
15:15 -!- cmirror [~cmirror@4.53.92.114] has quit [Client Quit]
15:15 < jeremyrubin> altho idk if that's worth doing at all
15:15 < Murch> not if they send them from smal lto large
15:16 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
15:16 < Murch> I'd say, only allow connected graphs to be sent as packages
15:16 < jeremyrubin> I think that's already a contstraint 
15:16 < jeremyrubin> glozow: did you ever get the notes suhas and I put together last year about this stuff?
15:16 < Murch> AFAIU, that restraint has been losened?
15:16 < glozow> peers can already send you crap, so it's more about limiting how much time you spend looking at crap i think
15:17 < Murch> mh, good point
15:17 < jeremyrubin> glozow: I think it's important that packages as a concept are connected components
15:17 < glozow> jeremyrubin: which notes? I've seen a couple of his gists
15:17 < jeremyrubin> we can have metapackages that can be split into packages
15:17 < Murch> But at least they'd only send you announcements once so far and then wouldn't make you download the same transactions again and again?
15:17 -!- cmirror [~cmirror@4.53.92.114] has quit [Client Quit]
15:18 < jeremyrubin> but the notion of a package as a component is useful, and peers sneaking in unrelated crap to the component should be bannable IMO
15:19 < jeremyrubin> glozow: I'll try to find the notes
15:19 < glozow> i think the protocol for correctly-behaving senders would be to build packages as necessary
15:19 < glozow> and the receiver can try their best to distinguish between, e.g. an extra tx you already knew about and punishable garbage
15:20 < glozow> e.g. sender creates a package based on `filterinventoryknown` of their peers
15:20 < glozow> er, what's it called? the bloom filter for invs you've heard from the peer
15:21 < jeremyrubin> glozow: FWIW, make a hashtable with all txids ( O(n) ), scan all txns inputs against it (O(n)), count txns with all inputs not found
15:21 < jeremyrubin> I think that algorithm is O(n) and guarantees a single component
15:22 < jeremyrubin> no matter what order things are in
15:22 < Murch> I think that would still allow conflicting txs i.e. A and A' that both spend the same input?
15:24 < jeremyrubin> yep, that's still a component. conflict check can also be done either as a later part of validation or with a similar algorithm
15:24 < Murch> Right, would still be connected, but not a valid package
15:24 < glozow> you're doing this with transactions in your mempool you're relaying to peers right?
15:25 < jeremyrubin> a while ago i did some O(n) algorithm for this during block validation... but it was unpopular
15:25 < jeremyrubin> it turns out we do all the connection logic in blocks while hitting the utxo caches
15:25 < jeremyrubin> but you can context-free validate block tx connectivity 
15:26 < glozow> sure. why do you want to do that? check tx connectivity before you start looking at scripts?
15:26 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/14837
15:26 < jeremyrubin> it would let you parallelize better
15:27 < jeremyrubin> https://github.com/JeremyRubin/bitcoin/blob/0425c6409000aeb3270ba8f9c30d2746c5c5b784/src/validation.cpp#L3078-L3086
15:28 < glozow> you wouldn't even get to this part until after u verify the pow
15:29 < glozow> why would someone put duplicate inputs + do the pow just for you to verify a tiny bit slower?
15:33 -!- promag_ [~promag@188.250.84.129] has joined #bitcoin-core-dev
15:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
15:33 < bitcoin-git> [bitcoin] achow101 opened pull request #21640: [0.21] Introduce DeferredSignatureChecker and have SignatureExtractorClass subclass it (0.21...0.21-sig-ext) https://github.com/bitcoin/bitcoin/pull/21640
15:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
15:33 < jeremyrubin> Ah it's not just that, there are other things you can do when you check all these properties at once
15:34 < jeremyrubin> i can try to find the experimental branch if you're curious, but don't spend too much time since it seems like a dead end
15:35 < jeremyrubin> When you're doing https://github.com/bitcoin/bitcoin/blob/0c9597ce7db28f5272a69bf0fbb36ce6b2520566/src/validation.cpp#L2127
15:36 < jeremyrubin> you have to process txns in block order, so it's serial O(n)
15:36 < jeremyrubin> but if you do a small amount of pre-work (which is also O(n), but small c)
15:37 < jeremyrubin> then you can do the rest of the tx validation in parallel because you're not relying on the UpdateCoins calls being serial
15:37 < jeremyrubin> not a big deal, but the old PR might be interesting to you for 'algorithms to check properties of groups of txns'
15:38 < glozow> yeah it's interesting, thanks for sharing
16:02 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
16:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
16:07 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
16:23 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection]
16:23 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-dev
16:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
16:36 -!- jsjohns [bab3498d@186.179.73.141] has joined #bitcoin-core-dev
16:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
16:56 -!- proofofkeags_ [~proofofke@205.209.28.54] has quit [Ping timeout: 240 seconds]
16:57 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.]
16:57 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
16:59 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
17:08 -!- stortz [c8b9c69a@unaffiliated/stortz] has quit [Quit: Connection closed]
17:20 -!- stanstandard [~stanstand@ip68-104-2-250.lv.lv.cox.net] has joined #bitcoin-core-dev
17:21 -!- jsjohns [bab3498d@186.179.73.141] has quit [Quit: Connection closed]
17:21 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-dev
17:24 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
17:26 -!- promag [~promag@188.250.84.129] has quit [Remote host closed the connection]
17:27 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-dev
17:30 -!- jungly_ [~jungly@host-80-116-30-91.retail.telecomitalia.it] has joined #bitcoin-core-dev
17:31 -!- jungly [~jungly@host-82-49-151-254.retail.telecomitalia.it] has quit [Ping timeout: 248 seconds]
17:58 -!- nihui [~nihui@139.28.218.148] has quit [Remote host closed the connection]
18:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:51 < jeremyrubin> do we have an rpc to undo removeprunedfunds for unconfirmed txns?
18:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:54 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0c9597ce7db2...265a3a774b35
18:54 < bitcoin-git> bitcoin/master fa21239 MarcoFalke: cirrus: Use SSD cluster for speedup
18:54 < bitcoin-git> bitcoin/master 265a3a7 fanquake: Merge #21445: cirrus: Use SSD cluster for speedup
18:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
18:54 < bitcoin-git> [bitcoin] fanquake merged pull request #21445: cirrus: Use SSD cluster for speedup (master...2103-ciSSD) https://github.com/bitcoin/bitcoin/pull/21445
18:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
18:55 -!- btcquant [~textual@210006171071.ctinets.com] has joined #bitcoin-core-dev
19:01 < shesek> jeremyrubin, wouldn't sendrawtransaction effectively do the same?
19:04 < jeremyrubin> i think the wallet ignores it
19:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]
19:34 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-dev
19:38 -!- ron2 [~ron@178.239.168.171] has joined #bitcoin-core-dev
19:51 < achow101> jeremyrubin: importprunedfunds
20:05 -!- smctwo [~smctwo@bba597217.alshamil.net.ae] has quit [Remote host closed the connection]
20:12 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Quit: Leaving]
20:15 -!- DFBAFD [~stanstand@172.58.76.147] has joined #bitcoin-core-dev
20:18 -!- stanstandard [~stanstand@ip68-104-2-250.lv.lv.cox.net] has quit [Ping timeout: 252 seconds]
20:21 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
20:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
20:53 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
20:54 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
20:58 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Read error: Connection reset by peer]
20:58 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-dev
20:59 -!- DFBAFD [~stanstand@172.58.76.147] has left #bitcoin-core-dev []
21:04 < jeremyrubin> achow101: only works for mined txns
21:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
21:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
21:48 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Ping timeout: 240 seconds]
21:49 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
22:12 -!- jadi [~jadi@93.119.217.23] has joined #bitcoin-core-dev
22:27 -!- jadi [~jadi@93.119.217.23] has quit [Ping timeout: 260 seconds]
22:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:44 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/265a3a774b35...4ad83a9597e4
22:44 < bitcoin-git> bitcoin/master fa732bc MarcoFalke: test: Use compressed keys in TestChain100Setup
22:44 < bitcoin-git> bitcoin/master fa6183d MarcoFalke: test: Remove option to make TestChain100Setup non-deterministic
22:44 < bitcoin-git> bitcoin/master 4ad83a9 MarcoFalke: Merge #21592: test: Remove option to make TestChain100Setup non-determinis...
22:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
22:45 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #21592: test: Remove option to make TestChain100Setup non-deterministic (master...2104-testCleanup) https://github.com/bitcoin/bitcoin/pull/21592
22:45 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
22:53 -!- smartineng [~Icedove@88.135.18.171] has joined #bitcoin-core-dev
22:53 -!- smartineng [~Icedove@88.135.18.171] has quit [Excess Flood]
23:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
23:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:35 < bitcoin-git> [gui] hebasto opened pull request #275: Support runtime appearance adjustment on macOS (master...210409-dark) https://github.com/bitcoin-core/gui/pull/275
23:35 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
23:36 < bitcoin-git> [gui] hebasto closed pull request #274: [PoC] [do not merge]: Support runtime appearance adjustment on macOS (master...210407-dark-poc) https://github.com/bitcoin-core/gui/pull/274
23:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
23:56 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Read error: Connection reset by peer]
--- Log closed Fri Apr 09 00:00:20 2021