--- Log opened Tue Jul 30 00:00:25 2019
00:00 -!- peleion [~jeff@76.73.148.34] has joined #bitcoin-core-dev
00:02 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-qrzynwjvjlhfuiid] has quit [Quit: Connection closed for inactivity]
00:12 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Ping timeout: 260 seconds]
00:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:15 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 244 seconds]
00:16 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]
00:21 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
00:26 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 272 seconds]
00:27 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev
00:29 -!- kljasdfvv [~flack@p200300D46F0E7800BD1623C9AACFDA2A.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:39 -!- rex4539 [~rex4539@2a02:587:3514:c700:ec2d:b821:585:58bd] has quit [Ping timeout: 276 seconds]
00:53 -!- jungly [~quassel@79.8.200.97] has joined #bitcoin-core-dev
00:59 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:00 -!- laptop500 [~laptop@host81-147-158-108.range81-147.btcentralplus.com] has joined #bitcoin-core-dev
01:04 -!- niska [~niska@static.38.6.217.95.clients.your-server.de] has quit [Quit: Leaving]
01:11 -!- niska [~niska@static.38.6.217.95.clients.your-server.de] has joined #bitcoin-core-dev
01:30 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
01:30 < fanquake> achow101: In https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Wallet-Class-Structure-Changes#cwallet-changes, can you explain "These may all be the same ScriptPubKeyManager or different."? Reading through I got the impression that legacy/p2sh/bech would each be in separate ScriptPubKeyManagers.
01:31 < fanquake> Is/would there any benefit to keeping them siloed ?
01:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:32 < bitcoin-git> [bitcoin] meshcollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/33894612c0de...ff57fb457892
01:32 < bitcoin-git> bitcoin/master 914923d Peter Bushnell: Add setting as known type
01:32 < bitcoin-git> bitcoin/master ff57fb4 MeshCollider: Merge #15709: wallet: Do not add "setting" key as unknown
01:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:32 < bitcoin-git> [bitcoin] meshcollider merged pull request #15709: wallet: Do not add "setting" key as unknown (master...walletdb-settings) https://github.com/bitcoin/bitcoin/pull/15709
01:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:36 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ff57fb457892...53b5a4f7eca9
01:36 < bitcoin-git> bitcoin/master e0324c3 Aaron Clauson: Updated python command in readme so it will work on systems that have both...
01:36 < bitcoin-git> bitcoin/master 53b5a4f fanquake: Merge #16483: doc: update Python command in msvc readme
01:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:36 < meshcollider> fanquake: for example, if you have an old wallet, the legacy wallet structure is wrapped as a scriptpubkeymanager, and all address types would point to it
01:36 -!- kcalvinalvin [~calvin@104.143.95.18] has quit [Remote host closed the connection]
01:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:36 < bitcoin-git> [bitcoin] fanquake merged pull request #16483: doc: update Python command in msvc readme (master...update_msvc_readme) https://github.com/bitcoin/bitcoin/pull/16483
01:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:39 < fanquake> meshcollider: right, cheers
01:41 < meshcollider> fanquake: in a pure descriptor wallet you would probably have 6 separate scriptpubkeymanagers though yes
01:45 < meshcollider> if you have a wpkh() descriptor for your bech32 addresses it wouldnt make sense for the legacy output type to point to that for example
01:46 -!- kristapsk___ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
01:46 < fanquake> meshcollider: 👍
01:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
01:48 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 260 seconds]
02:00 -!- keyboardsurfer [~keyboards@89.249.74.218] has quit []
02:09 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:12 -!- victorSN [~victorSN@unaffiliated/victorsn] has quit [Ping timeout: 244 seconds]
02:15 -!- victorSN [~victorSN@unaffiliated/victorsn] has joined #bitcoin-core-dev
02:15 -!- espadrine [~espadrine@89.249.74.218] has joined #bitcoin-core-dev
02:18 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
02:23 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Ping timeout: 272 seconds]
02:40 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection]
02:40 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
02:55 -!- guest69 [ab06f39a@171.6.243.154] has quit [Remote host closed the connection]
03:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:07 < bitcoin-git> [bitcoin] practicalswift closed pull request #16312: tests: Reduce memory usage by 0.5 GB when compiling script_tests.cpp (master...fix-absurd-memory-usage-when-compiling-script_build) https://github.com/bitcoin/bitcoin/pull/16312
03:07 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:56 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
03:56 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
04:06 < jonasschnelli> sipa, BlueMatt: I'm unsure about the fixed 4byte message string. We would "waste" 3 bytes on each inv compared to the short-id approach. I don't expect much collisions with a space of 256-12 possible short-IDs.
04:07 -!- lightlike [~lightlike@2001:16b8:570a:4d00:1d9c:8999:1ecb:6cb4] has joined #bitcoin-core-dev
04:07 < jonasschnelli> New commands that are not broadly used on the network could still use a string,.... and only get a short ID after some time (to avoid collisions).
04:08 < jonasschnelli> What we could do, instead, of using the value 1-12 for string based message commands, ... we could use value 0 as an indicator for a 4 byte string base command.
04:09 < jonasschnelli> (compared to the fixed 4 bytes command it would be +1 byte)
04:09 < jonasschnelli> The argument, "but parsing variable length!" I don't buy that completely,.. because one needs to deal with vlen anyways
04:10 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
04:11 < jonasschnelli> you need to verify the MAC tag therefore deserializing,... so one needs to read the whole content of the stream anyways. Maybe I don't see the point, but messages are vlen anyway.
04:11 < jonasschnelli> Skipping a message needs one to read the "header" (in v2 case the command ID/name)
04:11 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev
04:17 -!- anemous [~yaaic@58.81-167-146.customer.lyse.net] has joined #bitcoin-core-dev
04:17 -!- brianhoffman_ [~brianhoff@pool-173-66-215-91.washdc.fios.verizon.net] has joined #bitcoin-core-dev
04:19 -!- Sentineo [~Undefined@unaffiliated/sentineo] has quit [Ping timeout: 272 seconds]
04:20 -!- Sentineo [~Undefined@unaffiliated/sentineo] has joined #bitcoin-core-dev
04:20 -!- brianhoffman [~brianhoff@pool-173-66-215-91.washdc.fios.verizon.net] has quit [Ping timeout: 272 seconds]
04:20 -!- brianhoffman_ is now known as brianhoffman
04:31 -!- anemous [~yaaic@58.81-167-146.customer.lyse.net] has quit [Ping timeout: 258 seconds]
04:36 -!- anemous [~yaaic@58.81-167-146.customer.lyse.net] has joined #bitcoin-core-dev
04:37 -!- jungly [~quassel@79.8.200.97] has quit [Ping timeout: 245 seconds]
04:38 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #bitcoin-core-dev
04:38 < jonasschnelli> Is it just me or does travis hang while fetching the pull request page? https://travis-ci.org/bitcoin/bitcoin/pull_requests
04:39 < jonasschnelli> idles forever at my end
04:51 -!- anemous [~yaaic@58.81-167-146.customer.lyse.net] has quit [Ping timeout: 244 seconds]
04:55 -!- jonatack [d598a155@213.152.161.85] has joined #bitcoin-core-dev
05:00 -!- espadrine [~espadrine@89.249.74.218] has quit []
05:04 -!- Mister_X1 [~Mister_X@184.75.223.219] has joined #bitcoin-core-dev
05:04 < fanquake> jonasschnelli: loading ok for me here.
05:15 < jonasschnelli> fanquake: maybe a local browser issue then
05:15 < jonasschnelli> jup.
05:30 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-xteahamwfzjrztgc] has joined #bitcoin-core-dev
06:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:43 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/53b5a4f7eca9...bd35ec36f5d6
06:43 < bitcoin-git> bitcoin/master 29ee4c4 Daniel Kraft: Specify AM_CPPFLAGS for ZMQ.
06:43 < bitcoin-git> bitcoin/master bd35ec3 Wladimir J. van der Laan: Merge #16434: build: Specify AM_CPPFLAGS for ZMQ
06:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:44 < bitcoin-git> [bitcoin] laanwj merged pull request #16434: build: Specify AM_CPPFLAGS for ZMQ (master...zmq-cppflags) https://github.com/bitcoin/bitcoin/pull/16434
06:44 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:49 < stevenroose> sipa, achow: importpubkey ought to recognize p2shwpkh addresses, right?
06:49 < stevenroose> ah nvm
06:50 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
06:50 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
06:53 -!- michagogo [uid14316@wikia/Michagogo] has quit [Quit: Connection closed for inactivity]
07:12 < elichai2> I finished with the descriptors but I'm trying to figure out `IsSolvable` right now. and i'm not sure how does taproot fit in the SigningProvider API. the first thing oviously to check is to convert the point to P2PK and check if it can sign for that key. but if it can't I need to somhow be able to reconstruct the tree out of the signing provider. I'm thinking of adding it as a member, but is it okay that there
07:12 < elichai2> might be duplicate scripts between that tree and the `scripts` map? or maybe I should store there a tree to `CScriptID` and then get the right scripts through that map and try to solve for all the possible leafs(and the first that return true i'll return true)
07:17 < elichai2> hmm and even if I have the correct tweak I need to find the correct internal key, and I guess brute forcing the tweak against all the pubkeys in the map isn't a good solution heh
07:21 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 260 seconds]
07:25 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-core-dev
07:32 < elichai2> so I can negate the tweak and add it to the taproot key to get the internal key. cool
07:34 -!- spinza [~spin@102.132.245.16] has quit [Ping timeout: 248 seconds]
07:38 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
07:39 < BlueMatt> jonasschnelli: I really hope we're not so starved for bandwidth that we can't afford 3 extra bytes
07:39 < BlueMatt> and if we are, we can just have more things in each inv, no?
07:42 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
07:44 < jonasschnelli> BlueMatt: What does afford means in that context? :-) We can afford it, but It's more a question of waste/optimizing.
07:45 < jonasschnelli> BlueMatt: bundling inv's.. sure. Not always possible.
07:45 < BlueMatt> over-optimizing is the root of all evil :p
07:45 < jonasschnelli> Sure. But I think we are in an acceptable range of optimizing.
07:46 < BlueMatt> I mean if we're in a place where we can't bundle invs, then we have low tx traffic, and we can afford a few more bytes per message without anyone caring about the bw usage
07:46 < BlueMatt> if we're not, we can bundle more
07:46 < BlueMatt> I just dont really think an extra 3 bytes on a 32 byte thing to send really has much cost
07:47 < BlueMatt> in exchange for a constant length header
07:47 < BlueMatt> which is way easier to deal with
07:48 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
07:49 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
07:50 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
07:50 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
07:51 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
07:54 < sipa> jonasschnelli: i don't care much about variable length either, but it seems a sticking point for BlueMatt 
07:55 < sipa> jonasschnelli: but also just diminishing returns; there is a 16 byte MAC per message; maybe saving 8 bytes per message matters, but saving 3 more is quickly becoming negligable for all but the shortest messages
07:56 < sipa> elichai2: IsSolvable meams "you know enough to sign under all conditions, if you had the private keys"
07:57 < sipa> elichai2: taproot descriptors would always be solvable
07:57 -!- roconnor [~roconnor@host-45-58-217-32.dyn.295.ca] has joined #bitcoin-core-dev
07:57 < elichai2> i'm talking about a different `IsSolvable` haha
07:57 < elichai2> in sign.cpp
07:57 < elichai2> (the one that's used in descriptors_test.cpp )
07:57 < sipa> oh, i see
07:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:59 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bd35ec36f5d6...74f1a27f2f45
07:59 < bitcoin-git> bitcoin/master 0c78e49 practicalswift: tests: Switch one of the Travis jobs to an unsigned char environment (-fun...
07:59 < bitcoin-git> bitcoin/master 74f1a27 Wladimir J. van der Laan: Merge #15134: tests: Switch one of the Travis jobs to an unsigned char env...
07:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:59 < bitcoin-git> [bitcoin] laanwj merged pull request #15134: tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (master...unsigned-char) https://github.com/bitcoin/bitcoin/pull/15134
07:59 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:59 < sipa> elichai2: the concept of solvable there needs to go away i think
07:59 < sipa> elichai2: it captures whether you're able to estimate fees
08:00 -!- Mister_X1 [~Mister_X@184.75.223.219] has quit []
08:00 < elichai2> wait what. I thought it checks if you have the right script+private key
08:00 < elichai2> like, it literally tries to produce a signature
08:02 < jonasschnelli> BlueMatt, sipa: sorry... was on the phone. BlueMatt: what are the benefits of a constant length "header"?
08:02 -!- reardencode [~reardenco@shrugged.reardencode.com] has quit [Ping timeout: 252 seconds]
08:02 < jonasschnelli> Also, V2's "header" is the encrypted length & MAC TAG
08:03 -!- lliehu1 [~lliehu@184.75.223.219] has joined #bitcoin-core-dev
08:04 < jonasschnelli> A 32byte field for defining the message type seems very large for the message variety we are expecting in the next years.
08:04 < jonasschnelli> I also don't fully buy into the anit-collision argument
08:05 < jonasschnelli> Maybe if we consider collisions be a thing in the future, we could say short-ID tables are bound to a certain net-protocol version?
08:06 < sipa> elichai2: it basically checks if you can sign with a dummysigner (which doesn't need private keys)
08:06 < sipa> elichai2: you shouldn't need taproot specific logic; just signing logix
08:08 < emilengler> How does bitcoin-qt detects when Ctrl-L was pressed? I can't find something like a QShortcut or a QAction
08:08 -!- reardencode [~reardenco@shrugged.reardencode.com] has joined #bitcoin-core-dev
08:08 < elichai2> sipa: yeah but to "try" you sign with the dummy signature I need to convert it to something it knows. it calls `ProduceSignature` which does things like: https://github.com/bitcoin/bitcoin/blob/master/src/script/sign.cpp#L213
08:10 < jonasschnelli> [16:46:57]  <BlueMatt>	in exchange for a constant length header [...] which is way easier to deal with
08:10 < jonasschnelli> ^^^ can you elaborate a bit more on this?
08:10 < elichai2> so I need to "try" producing signatures for the scripts, right? because I can't asusme it's using a dummy signer and will return true for whatever pubkey. so I need to try with the internal key as P2PK and then with each script until `SignStep` returns true
08:11 < jonasschnelli> You have a raw packet on the stream [3 bytes encrypted length] + [ ? encrypted payload ] + [ 16 bytes MAC]
08:11 < jonasschnelli> (varlen already)
08:11 < jonasschnelli> you check the mac and decrypt
08:12 < jonasschnelli> then "deserialize" the message ([ ? payload]), where the header is actually the message command (which is varlen compared to the 24byte V1 headers)
08:13 -!- reardencode [~reardenco@shrugged.reardencode.com] has quit [Client Quit]
08:13 < phantomcircuit> jonasschnelli, it's infinitely easier to parse a constant length header than a variable length one
08:13 < jonasschnelli> phantomcircuit: easier in what context?
08:14 < jonasschnelli> I mean the message that follows has very likely also variable length fields
08:14 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]
08:15 < sipa> elichai2: yes, you need taproot signing logic
08:15 < sipa> if you have that, IsSolvable will work automatically
08:15 -!- davterra [~none@69.161.195.101] has quit [Remote host closed the connection]
08:17 -!- reardencode [~reardenco@shrugged.reardencode.com] has joined #bitcoin-core-dev
08:18 < elichai2> great. so i'll add a map of taproot trees to `FlatSigningProvider` and recalc the internal key by negation, Thanks :)
08:19 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
08:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:20 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #16493: test: Bump rpc_timeout in feature_dbcrash (master...1907-testRpcTimeoutBump) https://github.com/bitcoin/bitcoin/pull/16493
08:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:26 < sipa> elichai2: i'd add TaprootPath entries to SigningProvider (with a map from keyid, or from pubkey, unsure), one for each spending path
08:27 < sipa> elichai2: for key paths, it would contain the tweak and the pubkey it's derived from
08:27 < sipa> elichai2: for script paths it would contain leaf version, script, and Merkle path
08:28 < sipa> the advantage is that this approach works evenn when you don't know all scripts
08:28 < elichai2> hmm so you're suggesting to split it to paths in the first place for the situation that you don't know all the paths
08:28 < sipa> right
08:28 < elichai2> although i'll argue that you shouldn't be able to sign for an address that you don't know all the paths for
08:28 < sipa> i don't
08:29 < elichai2> because that mean you might not really "own" the coins
08:29 < sipa> there is a difference between treating a coin as yours, and participating in signing
08:30 < sipa> the descriptor side of things will always have the whole tree, and is used for determining what is yours
08:30 < elichai2> and in the end of the path do you think it should be a CScript or a CScriptID to the map of scripts that is already that (and probably will already have those scripts because i'm using descriptors for the leafs so ExpandHelper will fill it up)
08:30 < elichai2> sipa: right
08:30 < sipa> i think it can be CScript
08:30 < elichai2> even with the redundancy?
08:31 < sipa> the scripts shouldn't be in the normal script map i think
08:31 < sipa> as they're distinct anyway
08:31 < sipa> as in: they ought to be a distinct namespace, because taproot scripts have different semantics 
08:32 < hugohn> sipa: wouldn't that complicate the new IsMine() logic, which is now just a look up in the "regular" scripts map?
08:32 < elichai2> sipa: but if I have `tap(key, [p2k(...), p2kh(...)])` I want to use the PKDescriptor and PKHDescriptor descriptors
08:33 < elichai2> and in the end it's still `OP_CHECKSIG`
08:34 -!- kljasdfvv [~flack@p200300D46F0E7800BD1623C9AACFDA2A.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
08:35 < sipa> hugohn: the IsMine logic will just be descriptors
08:35 < sipa> in no way should taproot stuff influence the old legacy IsMine code
08:36 < sipa> elichai2: ok, so?
08:37 < sipa> elichai2: expanding a PK descriptor gives you a script; inside a taproot descriptor you put that in the tree rather than directly in the script map
08:37 < hugohn> yeah I mean for native descriptor wallets, not the legacy ones. i.e., DescriptorScriptPubKeyMan::IsMine() . That will have to change if we add tapscripts to a different map, no?
08:38 < sipa> hugohn: no
08:38 < elichai2> I just realized that when I'm expanding I use `MakeScripts` on the subdescriptors and not`ExpandHelper` so it wouldn't automatically get added to the FlatSigningProvider
08:38 < sipa> hugohn: there is a map of scriptPubKeys
08:39 < sipa> hugohn: that is not the same map as the mapScripts in signing providers
08:39 < elichai2> makes sense. so the ExpandHelper could also generate all the possible script paths and add them to the provider
08:39 < sipa> right, or the taproot specific code does that
08:40 < elichai2> right
08:41 < elichai2> btw, I see that your code right now hard codes `0xc0` in the consensus code, and it doesn't compose it in a way. I'm thinking if it's worth the effort to really add a leaf version already or do the same (which isn't good in engineering stand point but not sure if it's worth the effort assuming that other parts hard code it)
08:42 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has joined #bitcoin-core-dev
08:42 < sipa> elichai2: i think it makes sense that descripts for now only support tapscript v0
08:43 < sipa> *descriptors
08:43 < sipa> i think for psbt extensions we do want to support encoding other tapscript versions
08:43 < elichai2> 👍 yeah. probably won't see a new tapscript version for a while haha
08:46 < hugohn> sipa: you're right I got those 2 mixed up, oops. So it's the `LookupHelper` for SigningProvider that will have to change to account for tapscripts, IsMine won't.
08:46 < sipa> hugohn: i don't think the descriptor wallet code will need to change at all
08:47 < sipa> hugohn: taproot descriptors will still be populating the list of scriptPubKeys to watch for
08:47 < sipa> the mapScripts/taproot tree elichai2 and i were talking about is for internal scripts, not scriptPubKeys
08:48 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
08:48 < elichai2> yep. the scriptPubKey is the easiest part.
08:48 < phantomcircuit> jonasschnelli, it means you can just copy the a buffer into the fields without much real logic
08:52 < sipa> jonasschnelli: well for new message types they can be selected to not collide with existing ones
08:52 < hugohn> sipa: right descriptor part won't change, but the Signing Provider will need to change, right? as it involves looking up for things to sign which include internal scripts?
08:52 -!- afigs [6c4337c3@108-67-55-195.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-core-dev
08:52 < sipa> hugohn: signingprovider will get extra fields yes
08:52 < sipa> but they should 't really interact with descriptor wallets
08:53 < sipa> jonasschnelli: but it also supports "uncoordinated new messages" because until there are 1000s of message types, the chance for collisions will be negligae
08:53 < elichai2> phantomcircuit: bitcoin core already uses variables sizes for everything.
08:55 < sipa> elichai2: i think BlueMatt's comment is mostly for the sake of other implementations
08:55 < jonasschnelli> phantomcircuit: I get the point. But in out context and with the V2 encryption packet that is already vlen this point has little weight IMO
08:56 < elichai2> oh. but they will need to implement the variable size type/functions anyway for the rest of the stuff in bitcoin. so why not use the same type we use everywhere?
08:56 < BlueMatt> elichai2: we actually dont for the headers
08:56 < sipa> jonasschnelli: i'm personally perfectly fine with the approach you suggested, but given BlueMatt's criticism i found this idea of just shortening the field perhaps a useful middle grou d
08:56 < jonasschnelli> Yes. I think in general it's an acceptable idea... but...
08:56 < elichai2> BlueMatt: oh really? ok. sorry, I don't know much about the p2p layer so i'll remove myself from this conversation ha
08:57 < BlueMatt> jonasschnelli: the header is not, no? and its a different layer - net vs protocol/net_processing deserialization
08:57 < BlueMatt> the net code isnt aware of what the message contains, or how to deserialize it
08:57 < BlueMatt> and it is dead simple
08:58 < BlueMatt> but, honestly, I dont think its *really* worth it. I find variable length headers distasteful given the million and one issues that have existed in implementing them, but if you really, really want to save 3 bytes, I'm not gonna argue for them
08:58 < jonasschnelli> In current v2: the headers is the short-ID where ID 1-12 is a varlen string message-command
08:58 < BlueMatt> dont think endlessly debating it is really worth it, that is
08:58 < BlueMatt> right, yes, I was under the impression that was the only variable length in the message header/the part that net has to deal with
08:59  * BlueMatt -> lunch
08:59 < sipa> well, the payload is also variable size, obviously
08:59 < jonasschnelli> BlueMatt: From a design perspective, I dislike variable length headers as much as you do. But I think in our case its fine and the complexity it adds is near 0.
08:59 < jonasschnelli> sipa: excactly.
09:00 < BlueMatt> the compexity it adds is, however, non-0, and the cost it removes *is* 0 :p
09:00 < hugohn> sipa: descriptors do depend on the Signing Providers to expand their cache, so they interact somewhat? (which was my bug yesterday). But descriptors don't need to know how SPs generate the cache (and therefore won't need to change at all for Taproot to work).
09:00 < jonasschnelli> BlueMatt: I disagree. :)
09:00 < sipa> hugohn: yes, descriptors very much interact with signingproviders
09:00 < sipa> hugohn: but the wallet code shouldn't
09:00 < jonasschnelli> That's why I'd like to hear what the "non-0 complexity" is,.. why a vlen headers adds complexity in our case (not in a general case)
09:00 < jonasschnelli> BlueMatt: ^
09:01 < hugohn> sipa: right. ok it's clear to me now. thanks!
09:01 < sipa> jonasschnelli: actually one issue about the variable length header scares me a bit, namely tha6 the encryption is designed to hide message types
09:02 < sipa> though i need to read up on the openssl chacha/poly1305 design to understand it better
09:03 < jonasschnelli> sipa: Yeah, that's maybe a point. Though, in most cases, you'll never ever use variable length messages.
09:03 < jonasschnelli> BIP324 defines short ids (single byte command) for every message.
09:04 < jonasschnelli> New messages could do the same,...
09:04 < sipa> jonasschnelli: there may be coordination issues there
09:04 < jonasschnelli> using string based message commands is more for extensions that don't want to deal with short IDs
09:04 < jonasschnelli> sipa: eventually,... but as long as all new message types come with a short ID, I don't think there is.
09:04 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
09:05 < jonasschnelli> The fallback to string base commands is unused in the ideal case
09:05 < jonasschnelli> except a fork-coin adds shit messages and don't bother with adding a short ID
09:05 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
09:06 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
09:06 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
09:06 < phantomcircuit> jonasschnelli, it means you can have a simple bent pipe that isn't doing decryption but does understand the headers
09:07 < jonasschnelli> And I do think 3 bytes matter. Especially if we know that almost 50% of our messages. are <=64bytes.
09:07 < jonasschnelli> Which results that 3bytes may be 5%.
09:07 < jonasschnelli> (BTCFlood though)
09:08 < jonasschnelli> phantomcircuit: ehm?
09:08 < jonasschnelli> If you don't understand decryption, you won't be able to read the payload length and therefore would never come to the point where a fix length header would matter? Not?
09:09 -!- pinheadmz_ [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz_]
09:09 < sipa> jonasschnelli: let me think think things through the next days
09:09 < sipa> hugohn: yw
09:10 < jonasschnelli> sipa:  Sure. Thanks for digging in!
09:10 < jonasschnelli> phantomcircuit: https://bitcoinbuilds.org/v2.png
09:10 -!- afigs [6c4337c3@108-67-55-195.lightspeed.irvnca.sbcglobal.net] has quit [Remote host closed the connection]
09:11  * jonasschnelli break
09:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:12 < bitcoin-git> [bitcoin] promag opened pull request #16494: wallet: Drop support to serialize OldKey (master...2019-07-drop-oldkey-serialize) https://github.com/bitcoin/bitcoin/pull/16494
09:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:12 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Remote host closed the connection]
09:17 < phantomcircuit> jonasschnelli, the length is encrypted?
09:17 < jonasschnelli> jup
09:17 < phantomcircuit> i guess that makes sense
09:17 < phantomcircuit> shrug
09:20 < BlueMatt> jonasschnelli: to answer your question, in a general case, the way you write a network layer (eg the way bitcoin core does it today) is step 1) read message header, step 2) check stuff about the header, step 3) allocate buffer for the size it told you, step 4) read message. this keeps things nice and simple, you dont have much allocation complexity and you avoid most buffer overflow issues if you misallocate in your network stack. 
09:20 < BlueMatt> hence my (strongly-held) view that variable-length, when it is reasonably avoidable, is always bad protocol design. obviously there are tradeoffs, but more lines of code that allocate and then read into a buffer in async networking have been the source of such a huge number of buffer overflow vulns over the years....
09:20 < BlueMatt> in this case its not as much an issue cause at least its only twice
09:20 < BlueMatt> so, again, not worth endless debate around it, I'm happy to not care anymore.
09:21 < BlueMatt> just answering your question of why
09:21 -!- wbnns [sid105317@21/bitcoin/binns] has quit [Ping timeout: 245 seconds]
09:21 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
09:22 -!- mariorz [sid490@gateway/web/irccloud.com/x-jiasvlzkmpjzvyvf] has quit [Ping timeout: 250 seconds]
09:22 < jonasschnelli> thanks! i totaly agree with all of your point... but... we deal with inner messages (decrypted)
09:23 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 258 seconds]
09:23 < jonasschnelli> the buffer is allocated and the data has ben read regardless of a fix length header or not (in our case of encrypted messages)
09:23 < sipa> jonasschnelli: the 'encrypted length' field covers the sum of message type and payload, or not?
09:24 < sipa> (i think it should)
09:24 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-sushiwratbaioyzc] has quit [Ping timeout: 264 seconds]
09:24 -!- fjahr [uid374480@gateway/web/irccloud.com/x-wbzyczhsyyayfsfl] has quit [Ping timeout: 252 seconds]
09:25 < jonasschnelli> the payload of a encrypted packet is [message command short ID + message payload]
09:25 < jonasschnelli> so the encrypted length is on the network layer
09:25 < sipa> ok, so the encrypted length is the length of the encrypted payload, not just the message payload?
09:25 < jonasschnelli> yes
09:25 -!- pinheadmz [~matthewzi@157-131-78-37.fiber.dynamic.sonic.net] has joined #bitcoin-core-dev
09:26 < BlueMatt> jonasschnelli: I'm not sure you read my point? my pont was that most protocols have variable length bodies, but those are handled at a different level than the constant-length header.
09:26 -!- fjahr [sid374480@gateway/web/irccloud.com/x-oqglxdehtfmjfnno] has joined #bitcoin-core-dev
09:26 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-sxymofhxqeywchwu] has joined #bitcoin-core-dev
09:26 -!- wbnns [sid105317@21/bitcoin/binns] has joined #bitcoin-core-dev
09:27 < sipa> BlueMatt: right, but here it is still a fixed length header + variable length message; the command is just the first few bytes of that variable length message
09:27 < sipa> so there are no additional variable length buffers or so involved
09:28 < sipa> just a decision where the command ends and where the message payload begins
09:28 < jonasschnelli> yes.
09:28 -!- mariorz [sid490@gateway/web/irccloud.com/x-uwcyjnlcmvbijhqt] has joined #bitcoin-core-dev
09:28 < jonasschnelli> eventually the v2 header is the 3 byte payload length
09:28 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has quit [Remote host closed the connection]
09:29 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has joined #bitcoin-core-dev
09:29 < jonasschnelli> I see all the design points. but I don't think there are practical costs for a variable length message command in v2
09:30 < jonasschnelli> (though I hope I'm right)
09:30 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has quit [Read error: Connection reset by peer]
09:30 < sipa> jonasschnelli: so... either you're going to make the decision between splitting the command from payload on the fly (before you've validated the MAC) or you do it afterwards
09:30 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has joined #bitcoin-core-dev
09:31 < sipa> if you do it on the fly there is a risk of creating a decryption oracle (not saying there is... but running any code based on decrypted but unauthenticated data is a red flag)
09:31 < sipa> if you do it afterwards, it'll may hard to avoid a copy
09:32 < jonasschnelli> I see...
09:32 < sipa> with fixed command size you could split on the fly without that risk
09:32 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
09:32 < jonasschnelli> hmm?
09:32 < sipa> it'd just be "first 3 bytes go here, other bytes go there"
09:32 < sipa> without looking at what those bytes are
09:32 < sipa> (3 or 4 or whatever)
09:32 < jonasschnelli> I see
09:33 < sipa> there actually is another solution: putting the information on variable length command or not in the length field
09:33 < sipa> but that's... even less conventional
09:33 < jonasschnelli> so.. your saying, before we decrypt, we place the 4 byte command string into a buffer and the payload
09:34 < sipa> if decryption is in-place, sure
09:34 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
09:34 < jonasschnelli> then decrypt the fix length command and not needing to deal with buffers anymore
09:34 < jonasschnelli> I think this is a valid point
09:34 < sipa> let me write things in pseudocode
09:34 < promag> hi, make on depends/ gives "./google/protobuf/stubs/common.h:38:10: fatal error: 'assert.h' file not found" .. hints?
09:35 < jonasschnelli> though, we could optimize of that case and avoid a copy if the message command is a 1byte short ID
09:35 < jonasschnelli> and if not, we do a copy.
09:35 < sipa> jonasschnelli: copy should always be avoidable
09:35 < jonasschnelli> yes.
09:36 -!- mariorz [sid490@gateway/web/irccloud.com/x-uwcyjnlcmvbijhqt] has quit [Ping timeout: 250 seconds]
09:36 < phantomcircuit> sipa, putting the mac after the data is just asking for implementers to decrypt the payload before checking the mac
09:36 < jonasschnelli> I need to go through the code...
09:36 < phantomcircuit> (although i do understand it being after makes it easier to stream data out)
09:36 < sipa> phantomcircuit: but it's also the only option if you want to avoid a copy
09:37 < phantomcircuit> sipa, uh why
09:37 < phantomcircuit> wait a copy on the sender or a copy on the receivers side?
09:37 < sipa> phantomcircuit: you'd need to buffer the unencrypted data when sending
09:37 -!- digi_james [sid281632@gateway/web/irccloud.com/x-qpxlupgtzyxjzgwp] has quit [Ping timeout: 258 seconds]
09:38 < sipa> or the encrypted data, also possible
09:38 < phantomcircuit> sipa, it's probably getting buffered anyways but in smaller pieces
09:38 < sipa> maybe
09:38 -!- digi_james [sid281632@gateway/web/irccloud.com/x-hcjqmmywqumzjqio] has joined #bitcoin-core-dev
09:39 -!- mariorz [sid490@gateway/web/irccloud.com/x-kmdxysmvzfdsdcfw] has joined #bitcoin-core-dev
09:39 < phantomcircuit> either way objects being serialized are going to be copied into a buffer
09:39 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
09:39 < sipa> sure, but putting MAC first means an additional buffering either way on top of whatever else is being done
09:39 < phantomcircuit> but there's no easy way as of now i think to serialize directly into the buffer you're going to use for the send() call
09:40 < sipa> ok, fair, put otherwise: you're going to need to go over your data twice
09:40 -!- behradkhodayar [~behrad@178.131.220.230] has joined #bitcoin-core-dev
09:42 < phantomcircuit> i think right now you'd do something like, serialize a bunch of stuff into a buffer forming an unencrypted message, copy chunks for chacha20 and mac, then send the chunk and the mac after you've processed all the chunks
09:42 -!- anemous [~yaaic@cm-84.212.241.10.getinternet.no] has joined #bitcoin-core-dev
09:42 -!- behrad_khodayar [~behrad@178.131.220.230] has joined #bitcoin-core-dev
09:42 -!- behrad_khodayar [~behrad@178.131.220.230] has quit [Remote host closed the connection]
09:42 < phantomcircuit> but if you just do the chacha20 encryption of the buffer with the unencrypted message in place you can easily calculate the mac before without a copy
09:43 < sipa> the mac is computed over the encrypted data
09:43 < phantomcircuit> yeah that's what i said
09:43 < sipa> so you can do one pass of encrypting-in-place + mac, send mac, and then go back over your encrypted data and send it out
09:43 < sipa> if the mac goes last, you can interleave encryption and sending
09:44 < phantomcircuit> yeah but you cant deallocate anything anyways so it's just a very small latency win
09:44 < sipa> for large messages it may matter, but agree it's a small point
09:44 < phantomcircuit> as long as it's very clear you cant decrypt things before checking the mac im sure it's fine... but doing so is going to look like a performance/latency win to a naive implementer
09:45 < phantomcircuit> i mean our largest message is like 2MB right?
09:45 < sipa> well you very much can decrypt before checking mac
09:45 < sipa> you just can't use the data before doing so
09:45 < phantomcircuit> chacha20 + mac over 2MB on even an rpi3 is going to be basically instant
09:45 < sipa> or can't make any decision that the other party can observe based on that decrypted data even
09:46 < phantomcircuit> right
09:47 < phantomcircuit> i cant see that being an issue in most languages... but things that are very very "async" might try to decrypt, consume and calculate the mac in parallel
09:47 < sipa> phantomcircuit: 7.5 ms on a RK3399 ARM64 CPU to decrypt/auth 1MB of data
09:47 < sipa> that's not nothing
09:48 < sipa> the poly1305 code can be optimized more, though
09:48 < jonasschnelli> sipa: I don't think we need to copy
09:48 -!- davterra [~none@209.58.190.248] has joined #bitcoin-core-dev
09:49 < jonasschnelli> We have a. CDataStream where the encrypted payload sits. Then we decrypt that "buffer" with ChaCha (after the MAC check). We read the eventually variable length command from that now decrypted CDataStream,...  then directly deserialize from that CDataStream
09:49 < sipa> jonasschnelli: yeah, that's fair
09:50 < jonasschnelli> Looking at the (old) V2 code,... I think there is no copy involved
09:51 < sipa> it'd be nice to be able to decrypt on the fly though, so if you have a slow CPU + slow network, the message is already mostly decrypted by the time the last part of the packet arrives
09:51 < jonasschnelli> So the variable length message command is more or less part of the message (which is vlen anyways)
09:51 -!- behradkhodayar [~behrad@178.131.220.230] has quit [Ping timeout: 245 seconds]
09:51 < sipa> and you can, and it's probably fine... just a bit scary
09:51 < jonasschnelli> sipa: decrypting on the fly is orthogonal to the fixed length command string, right?
09:52 < sipa> ah i see, with that CDataStream trick it is
09:52 < sipa> you effectively leave the command inside the CDataStream you give to the net processing code, but with the offset placed after it
09:52 < jonasschnelli> yes
09:52 < sipa> yup, agree
09:53 < jonasschnelli> Also, the important part of "on the fly" is probably precomputing the ChaCha20 stream up a a certain "cache" size.
09:53 < jonasschnelli> We then eventually only do xors in the network code
09:54 < sipa> heh, good point
09:54 < sipa> ok, i agree that the ability to decode on the fly isn't an argument against variable length commands
09:55 < jonasschnelli> The remaining question is whether the variable length command increases message type detectability
09:56 < sipa> not if the encrypted length covers the command as well
09:56 < jonasschnelli> Yes. It does. So I also think it's not an agrument.
09:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:57 < jonasschnelli> Which makes me again think saving 3 bytes is worth the variable length command
09:58 < sipa> i like the perspective of "the command is just the first bytes of the message payload, and we detect the command after allocating/receiving/decrypting/authenticating the whole payload"
09:58 < jonasschnelli> Maybe one could think passing a CDataStream to the next layer with a pointer not pointing the the buffer start is ugly stuff
09:58 < jonasschnelli> sipa: Yes. I think that definition clears up things
09:58 < sipa> so i'm fine with whatever
09:59 < jonasschnelli> Somehow I care about those 3 bytes... maybe wrongly. 
09:59 < sipa> including BlueMatt's suggestion earlier of only supporting 1-byte and 12-byte commands
09:59 < jonasschnelli> Though there is a yes/no wether a V2 inv is larger than a V1 inv.
10:00 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Remote host closed the connection]
10:00 < jonasschnelli> though with a 4 bytes fixed length command. It would still be 1 bytes smaller then V1.
10:01 < jonasschnelli> *than V1*
10:02 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
10:06 -!- profmac [~ProfMac@2001:470:1f0f:226:b0d7:2a6e:1d81:17ec] has quit [Ping timeout: 250 seconds]
10:07 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 245 seconds]
10:10 -!- profmac [~ProfMac@2001:470:1f0f:226:287b:524f:a939:ffc6] has joined #bitcoin-core-dev
10:11 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
10:11 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
10:25 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
10:49 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Quit: Leaving]
10:51 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
10:55 -!- captjakk [~captjakk@c-24-72-155-6.ni.gigamonster.net] has quit [Remote host closed the connection]
10:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
10:56 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #16497: gui: Generate bech32 addresses by default (take 2, fixup) (master...1907-guiBech32Take2) https://github.com/bitcoin/bitcoin/pull/16497
10:56 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
10:59 < sipa> gleb: have you seen the discussion last thursday on changes to wallet rebroadcasting? i wonder if you have any thoughts on interaction with erlay
10:59 -!- behradkhodayar [~behrad@178.131.220.230] has joined #bitcoin-core-dev
11:00 -!- lliehu1 [~lliehu@184.75.223.219] has quit []
11:03 -!- pinheadmz [~matthewzi@157-131-78-37.fiber.dynamic.sonic.net] has quit [Quit: pinheadmz]
11:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:03 < bitcoin-git> [bitcoin] TheBlueMatt reopened pull request #16323:  Call ProcessNewBlock() asynchronously (master...2019-07-background-pnb) https://github.com/bitcoin/bitcoin/pull/16323
11:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:04 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev
11:04 -!- MarconM [~MarconM@139.28.218.198] has joined #bitcoin-core-dev
11:05 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
11:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:05 < bitcoin-git> [bitcoin] TheBlueMatt reopened pull request #16324: Get cs_main out of the critical path in ProcessMessages (master...2019-07-peerstate-initial-moves) https://github.com/bitcoin/bitcoin/pull/16324
11:05 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:07 -!- behradkhodayar [~behrad@178.131.220.230] has quit [Ping timeout: 244 seconds]
11:10 < BlueMatt> ^ seeking concept review :)
11:10 < BlueMatt> also seeking ibd benchmarks from multiple peers....(jamesob :p)
11:12 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
11:14 -!- jarthur [~jarthur@207.114.244.5] has quit [Remote host closed the connection]
11:15 -!- pinheadmz [~matthewzi@207.189.24.161] has joined #bitcoin-core-dev
11:15 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
11:17 -!- anemous [~yaaic@cm-84.212.241.10.getinternet.no] has quit [Read error: Connection reset by peer]
11:18 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
11:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 248 seconds]
11:22 < gleb> sipa: I think it would work right away by just applying the same reasoning and looking at it as if the transaction was new
11:23 < sipa> gleb: but if different nodes had inconsistent rebroadcasting rules (or even randomization in whether/when to try rebroadcasting), erlay would suffer
11:25 < gleb> Oops, you are right, it would announce already known transactions potentially.
11:45 < gleb> There would be 2 kinds of nodes: those which have it in the mempool and those which don't. For the latter we can't do anything — we can only apply the default protocol (flooding/erlay) (unless we pass a flag along with a tx, but we're not gonna do this)
11:45 < gleb> For the former — I guess according to the rebroadcast reasoning they won't re-relay anything if it's received from somewhere (only if their own timer triggers).
11:46 < gleb> So the question is really how we should act at the node which triggers rebroadcast. 
11:46 < sipa> an alternative to rebroadcasting is of course mempool (full mempool, not relay) reconciliation...
11:48 < gleb> Which is essentially just batching rebroadcasts over an hour or whatever.
11:49 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
11:54 -!- jarthur [~jarthur@207.114.244.5] has quit [Remote host closed the connection]
11:56 < gleb> Yeah, I think exchanging sketches of rebroadcasts every hour or so might work. It's really mempool reconciliation done right (no point to reconcile obviously known to both parties fresh txs or low-fee garbage)
11:57 < gleb> I'm not sure estimation would work that well as in Erlay —  I can't tell how often rebroadcasts would happen and how different the rules will be and all that.
11:58 < sipa> it can be orthogonal of course; post-erlay the rebroadcasts can just stay normal invs too
11:59 < sipa> though if their bandwidth is considerable, we'll want a reconciliation based solution, whether by integrating into erlay, or by having a separate independent reconciliation step for rebroadcasts
12:01 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
12:02 -!- anemous [~yaaic@cm-84.212.241.10.getinternet.no] has joined #bitcoin-core-dev
12:10 < gleb> Yeah. I think we can't do much if rebroadcast uses regular invs though, as I explained above w.r.t 2 kinds of nodes. Anything coming to my mind about "integrating into erlay" is really complicated separate things.
12:10 < gleb> So in this case if Erlay's estimation formula adjusts to this stuff we're good, otherwise we might loose a bit of efficiency.
12:10 < gleb> In the case of regular inv rebroadcast *
12:12 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #bitcoin-core-dev
12:12 -!- reallll is now known as belcher
12:14 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:17 -!- davex_ [~user@45.74.60.141] has quit [Ping timeout: 245 seconds]
12:21 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
12:23 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:28 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
12:32 < phantomcircuit> BlueMatt, it's 10% faster to skip the bip30 checks
12:33 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
12:34 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
12:34 < BlueMatt> hmm, fun.
12:37 < BlueMatt> phantomcircuit: well you at least need to fix sdaftuar's comment on the pr, but mostly I'm highly dubious of reorg conditions around the bip30 shit
12:37 < BlueMatt> if you write a test that tests shit like that, I'll be happy :p
12:44 -!- jarthur [~jarthur@207.114.244.5] has quit [Remote host closed the connection]
12:44 -!- roconnor [~roconnor@host-45-58-217-32.dyn.295.ca] has quit [Quit: Konversation terminated!]
12:45 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
12:53 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:54 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
12:57 < BlueMatt> fanquake: care2merge #16433
12:58 < gribble> https://github.com/bitcoin/bitcoin/issues/16433 | txmempool: Remove unused default value MemPoolRemovalReason::UNKNOWN by MarcoFalke · Pull Request #16433 · bitcoin/bitcoin · GitHub
12:59 < jonasschnelli> BlueMatt: hell.. It's 4am for poor fanquake. Let me have a look. :)
12:59 < BlueMatt> oh, ehh, bad timezone conversion, was thinking it was later than it was
12:59 < sipa> I thought fanquake lived in a timeless realm
12:59 < jonasschnelli> heh
12:59 < BlueMatt> whatever, its trivial
13:00 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
13:00 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #bitcoin-core-dev
13:01 < jimpo> BlueMatt: Thinking about https://github.com/bitcoin/bitcoin/pull/16442#discussion_r308429740 more (the BlockRequestAllowed comment), I think just checking the stop block might be OK
13:02 < jonasschnelli> BlueMatt: your utACK didn't end up in the commit merge message because you missed the commit hash :P
13:02 < BlueMatt> jonasschnelli: meh
13:02 < BlueMatt> its trivial enough I figured no one cared
13:02 < BlueMatt> jimpo: hmm? 
13:02 < jonasschnelli> somehow github-merge.py does
13:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:02 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/74f1a27f2f45...39763b75556b
13:02 < bitcoin-git> bitcoin/master 0000ff0 MarcoFalke: txmempool: Remove unused default value MemPoolRemovalReason::UNKNOWN
13:02 < bitcoin-git> bitcoin/master 39763b7 Jonas Schnelli: Merge #16433: txmempool: Remove unused default value MemPoolRemovalReason:...
13:02 -!- jarthur [~jarthur@207.114.244.5] has quit [Remote host closed the connection]
13:02 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:02 < BlueMatt> jonasschnelli: right, I mean no reason to need or care about anoher ack on something that trivial
13:03 < jonasschnelli> sure
13:03 < jimpo> I assume the concern is some pathological case where there's a stale chain where some of the early stale blocks are more than 1 month old but the latest blocks in the chain are less than 1 month old?
13:03 < BlueMatt> jimpo: right, thats why I was referencing
13:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:03 < bitcoin-git> [bitcoin] jonasschnelli merged pull request #16433: txmempool: Remove unused default value MemPoolRemovalReason::UNKNOWN (master...1907-txmempoolNoUnknownDefault) https://github.com/bitcoin/bitcoin/pull/16433
13:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:04 < BlueMatt> jimpo: ah, you're right
13:04 < jimpo> In that cause, it's plausible that the node has been online less than a month and synced up the earlier stale blocks since the chain is "active" in some sense
13:04 < BlueMatt> jimpo: yea, doesn't matter
13:04 < BlueMatt> no, specifically it doesnt matter cause it doesn't reveal information
13:04 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 246 seconds]
13:04 < BlueMatt> if you are BLOCK_VALID_SCRIPTS at the top of the fork, then you are clearly also BLOCK_VALID_SCRIPTS everywhere down the fork path
13:05 < BlueMatt> so hiding the fact that you have those blocks...welll...you're not hiding anything
13:05 < jimpo> well yes, that too
13:05 < jimpo> I mean, I still think having the BlockRequestAllowed check in addition to the BLOCK_VALID_SCRIPTS check is valuable
13:05 < jimpo> but just on the stop block should be fine
13:06 < BlueMatt> hmm? no my point with that comment was that BlockRequestAllowed already does the BLOCK_VALID_SCRIPTS check for you
13:06 < BlueMatt> so....no reason to call it again
13:06 < jimpo> yes, I agree with that
13:06 < jimpo> I am removing the redundant check
13:07 < jimpo> but it's still better to do the full BlockRequestAllowed check instead of just the BLOCK_VALID_SCRIPTS check
13:07 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
13:07 -!- farmerwampum [~farmerwam@184.75.209.66] has quit [Ping timeout: 244 seconds]
13:08 < BlueMatt> not just better, you must
13:08 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
13:08 -!- pinheadmz [~matthewzi@207.189.24.161] has quit [Read error: Connection reset by peer]
13:08 < jimpo> just to prevent fingerprinting, right? Or is there another reason?
13:08 < BlueMatt> right
13:08 < phantomcircuit> BlueMatt, either im missing something or this will cause reorg issues in exactly the same way an invalid script would
13:08 < phantomcircuit> except that it doesn't let a miner steal coins just destroy them
13:08 < phantomcircuit> so like
13:08 < phantomcircuit> why
13:08 < BlueMatt> phantomcircuit: ehhh, the cache flushing shit is....complicated
13:09 < BlueMatt> phantomcircuit: go read the comment(s) there, and then test it anyway :P
13:09 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
13:09 < phantomcircuit> BlueMatt, there's no cache flushing issues
13:09 < phantomcircuit> the BIP30 checks are literally always cache miss down to disk unless the blocks invalid
13:09 -!- pinheadmz [~matthewzi@36.177.181.107.wiredns.net] has joined #bitcoin-core-dev
13:10 < phantomcircuit> sdaftuar, did i read your comment right?
13:11 < jimpo> BlueMatt: To be clear, you agree that there's no need to additionally check BlockRequestAllowed on the start block right? Is your reasoning the same as mine?
13:11 < phantomcircuit> BlueMatt, oh and the 10% is probably the smallest improvement possible, an rpi with a spinning disk would almost certainly be more than 10%
13:11 < BlueMatt> jimpo: thats my understanding yes, not sure what your reasoning is
13:11 < BlueMatt> phantomcircuit: ah, right, sorry, I'm mis-thinking about this
13:12 -!- pinheadmz [~matthewzi@36.177.181.107.wiredns.net] has quit [Read error: Connection reset by peer]
13:13 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #bitcoin-core-dev
13:14 < phantomcircuit> BlueMatt, wait does leveldb do a bloomfilter lookup for key existence?
13:15 < sipa> yes
13:16 < phantomcircuit> so maybe it doesn't do a disk lookup and instead is just the cost of the bloomfilter that's being saved?
13:16 -!- pinheadmz [~matthewzi@192.154.196.7] has joined #bitcoin-core-dev
13:18 < sipa> yes
13:18 < sipa> and the bloomfilter is likely cached in ram
13:20 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
13:22 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
13:26 < jonasschnelli> #proposedmeetingtopic bitcoin-dev mailing list moderation
13:26 < BlueMatt> oh boy
13:26 < jonasschnelli> heh... don't fear
13:26 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
13:26 < jonasschnelli> It's just about ramping up more people so we can have actual debates without +48h lags
13:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:27 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #16264: policy: Add experimental -mempoolreplacement=full (off by default) (master...1906-policyFullRbf) https://github.com/bitcoin/bitcoin/pull/16264
13:27 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:37 < phantomcircuit> sipa, well it's most definitely faster without the 34m lookups at least
13:38 < phantomcircuit> it also made generating (very bad) data on leveldb Get calls vs dbcache easier
13:41 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
13:54 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev
14:00 -!- MarconM [~MarconM@139.28.218.198] has quit []
14:02 < emilengler> I don't get where the bitcoin-qt rpc console detecs when Ctrl-L is being pressed? With the help of the grep command I've only found the way how Ctrl-Q is being handled. Can someone tell me where I find it?
14:02 < fanquake> promag: it’ll be a missing SDK. Assuming your building for MacOS
14:03 -!- spake [~spake@141.98.101.133] has joined #bitcoin-core-dev
14:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:06 < bitcoin-git> [bitcoin] instagibbs opened pull request #16500: GetFee should round up to avoid undershooting feerate (master...fix_filter_mempool_mistmatch) https://github.com/bitcoin/bitcoin/pull/16500
14:06 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:10 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Remote host closed the connection]
14:12 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
14:14 -!- jarthur [~jarthur@207.114.244.5] has quit []
14:20 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
14:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:23 < bitcoin-git> [bitcoin] ronaldstoner opened pull request #16501: Update configure.ac to remove extra no in $use_tests (master...master) https://github.com/bitcoin/bitcoin/pull/16501
14:23 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:27 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
14:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:31 < bitcoin-git> [bitcoin] ronaldstoner closed pull request #16501: Update configure.ac to remove extra no in $use_tests (master...master) https://github.com/bitcoin/bitcoin/pull/16501
14:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:37 -!- rex4539 [~rex4539@2a02:587:3514:c700:d983:3b85:5de9:be2c] has joined #bitcoin-core-dev
14:38 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
14:38 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
14:45 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
14:49 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
14:51 -!- brianhoffman_ [~brianhoff@pool-173-66-215-91.washdc.fios.verizon.net] has joined #bitcoin-core-dev
14:53 -!- brianhoffman [~brianhoff@pool-173-66-215-91.washdc.fios.verizon.net] has quit [Ping timeout: 245 seconds]
14:53 -!- brianhoffman_ is now known as brianhoffman
14:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:53 < bitcoin-git> [bitcoin] promag opened pull request #16502: wallet: Drop unused OldKey (master...2019-07-drop-oldkey) https://github.com/bitcoin/bitcoin/pull/16502
14:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
14:54 < bitcoin-git> [bitcoin] promag closed pull request #16494: wallet: Drop support to serialize OldKey (master...2019-07-drop-oldkey-serialize) https://github.com/bitcoin/bitcoin/pull/16494
14:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
14:54 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
14:55 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
14:56 < promag> fanquake: which sdk?
14:59 < fanquake> promag: the macOS SDK. Are you building depends for a macOS HOST?
15:00 < promag> I'm on a mac, building for mac
15:01 < phantomcircuit> sdaftuar, sorry im confused i dont see how removing the bip30 check would prevent a reorg to a greater pow chain
15:02 < fanquake> Does the version of macOS you’re on have the correct SDK? Are you testing the tool chain update PR
15:02 -!- ercwl [~ercwl@82-183-6-234.customers.ownit.se] has joined #bitcoin-core-dev
15:03 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds]
15:04 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
15:04 < promag> fanquake: `xcrun --sdk macosx --show-sdk-path` gives /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
15:05 < fanquake> promag: oh, did you recently update your macOS or Xcode?
15:06 < promag> fanquake: nope, I don't recall doing it, at least recently
15:06 < promag> why?
15:08 < fanquake> In newer versions of Xcode some of the headers our depends packages rely on aren’t where they used to be, and there a a script you can run that’ll put them back. See this comment: https://github.com/bitcoin/bitcoin/pull/16392#issuecomment-515268092 and the one I’m referencing.
15:08 < fanquake> Otherwise unsure atm.
15:09 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Ping timeout: 268 seconds]
15:12 < promag> should it work if I have the previous sdk?
15:12 < promag> fanquake: ^
15:13 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
15:14 < fanquake> promag: no, in that PR it’ll be looking for the newer one. Thinking about that, we could drop the requirements.
15:15 < fanquake> Although, at least it’s easy to download and extract the new SDK on a mac.
15:25 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
15:26 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
15:27 -!- petezz4 [uid2429@gateway/web/irccloud.com/x-hepukvtphpiqeuld] has joined #bitcoin-core-dev
15:35 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 268 seconds]
15:39 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
15:40 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
15:41 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
15:45 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds]
15:46 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 246 seconds]
15:47 < phantomcircuit> BlueMatt, what am i missing
16:04 -!- justanotheruser [justanothe@gateway/vpn/nordvpn/justanotheruser] has quit [Ping timeout: 268 seconds]
16:08 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:08 < bitcoin-git> [bitcoin] ariard opened pull request #16503: Remove p2pEnabled from Chain interface (master...2019-07-remove-p2p-chain) https://github.com/bitcoin/bitcoin/pull/16503
16:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:12 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
16:14 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
16:15 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #bitcoin-core-dev
16:19 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 248 seconds]
16:24 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
16:25 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev
16:28 -!- ercwl [~ercwl@82-183-6-234.customers.ownit.se] has quit [Quit: ercwl]
16:28 -!- kristapsk___ is now known as kristapsk
16:29 -!- ercwl [~ercwl@82-183-6-234.customers.ownit.se] has joined #bitcoin-core-dev
16:29 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
16:29 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
16:29 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
16:30 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
16:37 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:51 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #bitcoin-core-dev
16:51 -!- astro [~astro@gateway/tor-sasl/astro] has quit [Ping timeout: 260 seconds]
16:52 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
16:53 -!- guest69 [ab06f39a@171.6.243.154] has joined #bitcoin-core-dev
16:55 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
16:55 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #bitcoin-core-dev
16:56 -!- astro [~astro@gateway/tor-sasl/astro] has joined #bitcoin-core-dev
16:57 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
17:00 -!- spake [~spake@141.98.101.133] has quit []
17:01 -!- laptop500 [~laptop@host81-147-158-108.range81-147.btcentralplus.com] has quit [Ping timeout: 248 seconds]
17:04 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
17:04 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
17:04 -!- gatox [~gatox@139.28.218.198] has joined #bitcoin-core-dev
17:12 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
17:12 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
17:13 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #bitcoin-core-dev
17:14 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Client Quit]
17:14 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
17:15 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Client Quit]
17:15 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
17:16 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Client Quit]
17:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:18 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 272 seconds]
17:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
17:18 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
17:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
17:25 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #bitcoin-core-dev
17:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
17:28 < bitcoin-git> [bitcoin] promag opened pull request #16504: doc: Add release note for the deprecated totalFee option of bumpfee (master...2019-07-release-notes-15996) https://github.com/bitcoin/bitcoin/pull/16504
17:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
17:34 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
17:35 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
17:35 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Client Quit]
17:37 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
17:37 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Client Quit]
17:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
17:53 -!- lightlike [~lightlike@2001:16b8:570a:4d00:1d9c:8999:1ecb:6cb4] has quit [Quit: Leaving]
17:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
18:01 -!- morcos_ [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
18:03 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
18:03 -!- morcos_ is now known as morcos
18:20 -!- rex4539 [~rex4539@2a02:587:3514:c700:d983:3b85:5de9:be2c] has quit [Ping timeout: 252 seconds]
18:20 -!- berndj [~berndj@197.242.93.82] has quit [Quit: ZNC - http://znc.in]
18:23 -!- berndj [~berndj@azna.co.za] has joined #bitcoin-core-dev
18:25 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
18:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:32 -!- petezz4 [uid2429@gateway/web/irccloud.com/x-hepukvtphpiqeuld] has quit [Quit: Connection closed for inactivity]
18:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
18:35 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
18:39 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
18:43 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 272 seconds]
18:46 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
18:50 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
18:51 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
18:55 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]
19:00 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-xteahamwfzjrztgc] has quit [Quit: Connection closed for inactivity]
19:01 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
19:02 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev
19:05 -!- ezegom [~ezegom@pool-100-38-14-2.nycmny.fios.verizon.net] has quit [Ping timeout: 245 seconds]
19:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
19:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
19:24 -!- tryphe_ is now known as tryphe
19:25 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
19:28 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
19:29 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has joined #bitcoin-core-dev
19:33 -!- captjakk [~captjakk@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 258 seconds]
19:40 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Ping timeout: 244 seconds]
19:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
19:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]
19:57 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]
19:59 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev
20:00 -!- gatox [~gatox@139.28.218.198] has quit []
20:00 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
20:04 -!- vostorga1 [~vostorga@89.249.74.218] has joined #bitcoin-core-dev
20:07 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
20:14 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Quit: skyikot]
20:14 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
20:15 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
20:15 -!- justanotheruser [justanothe@gateway/vpn/nordvpn/justanotheruser] has joined #bitcoin-core-dev
20:16 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
20:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
20:17 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Client Quit]
20:17 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
20:18 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Client Quit]
20:20 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
20:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
20:22 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Client Quit]
20:27 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
20:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
20:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds]
20:52 -!- schnerchi [~schnerchi@p57B830CA.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
20:55 -!- schnerch_ [~schnerchi@p5084AC20.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds]
21:01 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Remote host closed the connection]
21:02 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
21:06 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Ping timeout: 258 seconds]
21:12 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
21:13 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
21:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
21:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds]
21:31 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
21:34 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 248 seconds]
21:44 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
21:45 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
21:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
22:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]
22:06 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:06 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
22:09 -!- liberiga [~liberiga@gateway/tor-sasl/liberiga] has joined #bitcoin-core-dev
22:12 -!- _Sam-- [~greybits@unaffiliated/greybits] has quit [Read error: Connection reset by peer]
22:20 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Remote host closed the connection]
22:21 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 260 seconds]
22:21 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 260 seconds]
22:22 -!- Lauda [~quassel@95.216.196.120] has joined #bitcoin-core-dev
22:22 -!- Lauda [~quassel@95.216.196.120] has quit [Changing host]
22:22 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev
22:23 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev
22:28 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
22:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
22:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
22:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
22:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
22:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
23:00 -!- vostorga1 [~vostorga@89.249.74.218] has quit []
23:05 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Quit: skyikot]
23:10 -!- dlareg1 [~dlareg@185.103.96.147] has joined #bitcoin-core-dev
23:19 -!- kcalvinalvin [~calvin@104.143.95.18] has joined #bitcoin-core-dev
23:23 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
23:29 -!- liberiga [~liberiga@gateway/tor-sasl/liberiga] has quit [Ping timeout: 260 seconds]
23:56 -!- anemous [~yaaic@cm-84.212.241.10.getinternet.no] has quit [Read error: Connection reset by peer]
--- Log closed Wed Jul 31 00:00:25 2019