--- Day changed Thu Sep 22 2016 00:05 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev 00:06 -!- blaker [5513dbb6@gateway/web/freenode/ip.85.19.219.182] has joined #bitcoin-core-dev 00:08 < murch> gmaxwell: Re "selecting by taint": I've always been discounting that because I wouldn't be able to discern change and target outputs. I wouldn't get the behavior of one wallet, but rather incoming and outgoing payments from different users. You just made me realize that this might still be a useful dataset. Thanks 00:08 < cfields> jonasschnelli: oh, i might know 00:09 < cfields> jonasschnelli: as a kludgy test, try adding a convenience lib for the tool, containing most of the functions. Move main() to a separate file, and have that be the only source listed for bitcoin_wallet_tool_SOURCES. Then add the convenience lib to bitcoin_wallet_tool_LDADD 00:10 < jonasschnelli> cfields: Okay. I'll try that. 00:10 < cfields> jonasschnelli: see bitcoind as an example 00:10 < phantomcircuit> jonasschnelli: any idea why we're asseting that locks are held instead of acquiring the lock in cwallet? 00:11 < phantomcircuit> the locks recursive so it should be fine to just acquire it again 00:11 < cfields> jonasschnelli: i can play around with it tomorrow (later) if it's still not working 00:11 < jonasschnelli> phantomcircuit: Is there no overhead in acquiring the lock again? Couple of CPU ticks consumed? 00:11 < jonasschnelli> cfields: Okay. I may try to play with it... but I guess I will fail. :) But no hurry 00:12 < cfields> jonasschnelli: you should know by now that telling me "no hurry" guarantees it will never happen :) 00:12 < phantomcircuit> wumpus: any idea if it costs more to acquire an already held lock than asserting the lock is held? 00:12 < jonasschnelli> cfields: hurry up then! :) 00:13 < wumpus> phantomcircuit: asserting that the lock is held is only enabled when log debugging is enabled, so that is the cheaper option 00:13 < wumpus> it's really a sanity assertion 00:13 < cfields> also, asserting means that you're not depending on the recursive lock and may be able to rip it out at some point :) 00:28 -!- blaker [5513dbb6@gateway/web/freenode/ip.85.19.219.182] has quit [Quit: Page closed] 00:32 -!- AaronvanW [~ewout@145.15.244.31] has joined #bitcoin-core-dev 00:33 -!- AaronvanW [~ewout@145.15.244.31] has quit [Changing host] 00:33 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:39 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 00:39 -!- xinxi_ [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 00:42 -!- murch [~murch@p4FE3B008.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 00:47 -!- assder [~AndChat20@85.19.219.182] has joined #bitcoin-core-dev 00:51 -!- laurentmt [~Thunderbi@80.215.234.190] has joined #bitcoin-core-dev 00:52 -!- laurentmt [~Thunderbi@80.215.234.190] has quit [Client Quit] 00:52 < gmaxwell> murch: it would be approximate for sure. 00:53 < gmaxwell> but I think worth analizing. 00:54 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 00:56 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 00:58 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 00:59 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 01:01 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 01:04 < GitHub79> [bitcoin] jonasschnelli opened pull request #8788: [RPC] Give RPC commands more information about the RPC request (master...2016/09/rpc_container) https://github.com/bitcoin/bitcoin/pull/8788 01:07 < phantomcircuit> wumpus: hmm 01:07 < phantomcircuit> how expensive is it to acquire a lock when you already have it? 01:08 < phantomcircuit> should just be a thread local check 01:10 < jonasschnelli> phantomcircuit: Is there a reason for re-acquiring the lock? Why not acquire the lock from the caller instead in the called function? 01:10 < jonasschnelli> But meh,.. depends on your layering. 01:15 < luke-jr> even if we have recursive locks in some places, it's still not a good idea to use it recursively :/ 01:15 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has quit [Ping timeout: 255 seconds] 01:16 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has joined #bitcoin-core-dev 01:20 -!- assder [~AndChat20@85.19.219.182] has quit [Ping timeout: 276 seconds] 01:20 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 01:29 -!- Bootvis [bob@baltar.lan.endoria.net] has quit [Ping timeout: 244 seconds] 01:29 -!- Bootvis [bob@baltar.lan.endoria.net] has joined #bitcoin-core-dev 01:30 -!- DigiByteDev [~JT2@185.29.164.8] has quit [Ping timeout: 255 seconds] 01:32 < luke-jr> jonasschnelli: your travis failed 01:32 < jonasschnelli> Luke-Jr: thanks... looking.. 01:33 < jonasschnelli> It broke rest 01:34 < luke-jr> jonasschnelli: part of the reason I didn't like that approach FWIW, was that now we need to look up the user twice :p 01:34 < jonasschnelli> Luke-Jr: depends how you make the user<->wallet mapping.. 01:34 < jonasschnelli> But I think user-wallet-mapping is a different thing then RPC auth 01:35 < jonasschnelli> But I would prefer selecting the wallet based on the endpoint or something within the RPC request 01:35 < jonasschnelli> Selecting based on the -rpcuser makes it relatively complex to setup 01:35 < luke-jr> even if we do so, most likely users should be restricted to only some wallet(s) 01:36 < jonasschnelli> We could still do this... but multiwallet is probably simpler then multiwallet-multiuser 01:36 < luke-jr> we already have multiuser :p 01:36 < jonasschnelli> Yes. I meant simpler to not do mutliuser-multiwallet in the first step 01:37 -!- assder [~AndChat20@85.19.219.182] has joined #bitcoin-core-dev 01:37 < jonasschnelli> If we would select the wallet depending on the endpoint, we could just use something like bitcoin-cli --wallet= getbalance 01:37 < jonasschnelli> where the bitcoin-cli tools would use --wallet= to pass the request to / 01:38 < luke-jr> can do it with mu-mw already today - plus the code for it is written already *shrug* 01:38 < jonasschnelli> Yes. But what if you want to wallet with a single user? 01:38 < jonasschnelli> How would you select? 01:38 < luke-jr> can't with the current implementation 01:38 < jonasschnelli> *want two 01:38 < luke-jr> doing that is more complicated IMO 01:39 < jonasschnelli> I think its the more obvious use case (single user, multiple wallet= 01:39 < luke-jr> I'm all for /?wallet=, just don't think it's the ideal first-step 01:39 < luke-jr> since we already have multiuser and even with wallet-selection-by-endpoint would want to lock it down 01:39 < jonasschnelli> I'm also happy with /?wallet= ... AFAIK it's simpler to parse / 01:39 < jonasschnelli> or /wallet/ 01:40 < luke-jr> as I see it, endpoint wallet selection is an additional step beyond user permissions 01:41 < jonasschnelli> Yes. But I think we need to solve singleuser-multiwallet 01:41 < jonasschnelli> Either with ?wallet= in request or / 01:43 < btcdrak> luke-jr why ?wallet= 01:43 < luke-jr> btcdrak: doesn't step on REST stuff, and unlikely to conflict with future extensions 01:44 < btcdrak> well thats not how to build REST interface 01:44 < jonasschnelli> REST does not support wallet 01:47 < btcdrak> query strings in REST are considered a very poor practice 01:48 < jonasschnelli> query-string are in the same HTTP element (path) 01:48 < jonasschnelli> Modern designs mostly use // instead or ?= 01:49 < jonasschnelli> Parsing is simpler, browser support better AFAIK 01:53 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev 01:58 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 265 seconds] 01:58 < GitHub84> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7008e28136b5...26b370a93700 01:58 < GitHub84> bitcoin/master 482f852 Johnson Lau: Implement NULLDUMMY softfork 01:58 < GitHub84> bitcoin/master 26b370a Wladimir J. van der Laan: Merge #8636: Implement NULLDUMMY softfork (BIP147)... 01:58 < GitHub156> [bitcoin] laanwj closed pull request #8636: Implement NULLDUMMY softfork (BIP147) (master...nulldummy) https://github.com/bitcoin/bitcoin/pull/8636 01:59 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 01:59 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 02:06 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 02:10 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:12 < luke-jr> jonasschnelli: pretty sure that violates the URI RFCs :p 02:50 -!- DigiByteDev [~JT2@185.29.164.30] has joined #bitcoin-core-dev 02:53 -!- DigiByteDev [~JT2@185.29.164.30] has quit [Client Quit] 02:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds] 03:04 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 03:07 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 03:08 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 03:14 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 272 seconds] 03:20 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 03:22 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 03:44 < GitHub101> [bitcoin] MarcoFalke opened pull request #8789: [qa] pull-tester: Only print output when failed (master...Mf1609-qaPrintFailedOnly) https://github.com/bitcoin/bitcoin/pull/8789 03:52 < GitHub35> [bitcoin] MarcoFalke opened pull request #8790: [test] Remove redundant debug print in addrman_tests (master...Mf1609-testsDeletePrint) https://github.com/bitcoin/bitcoin/pull/8790 03:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 03:56 < btcdrak> Reminder of last weeks' action points before meeting tonight: review #8634 and #8499 and #8526 04:00 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 04:01 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 04:01 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 04:03 < GitHub99> [bitcoin] MarcoFalke opened pull request #8791: [travis] cross-mac: explicitly enable gui (master...Mf1609-travisGui) https://github.com/bitcoin/bitcoin/pull/8791 04:04 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:05 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 04:09 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 04:28 -!- JackH [~laptop@79-73-191-94.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 04:29 -!- assder [~AndChat20@85.19.219.182] has quit [Read error: Connection reset by peer] 04:29 -!- assder [~AndChat20@85.19.219.182] has joined #bitcoin-core-dev 04:49 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:5428:adc7:e421:30d2] has quit [Ping timeout: 265 seconds] 05:01 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:82f:b8ee:4de3:5cdd] has joined #bitcoin-core-dev 05:16 -!- murch [~murch@p4FE3B008.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 05:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:16 < jonasschnelli> Luke-Jr: why would that violate the URI RFC? 05:17 < jonasschnelli> IMO something like /wallet//getbalance would be perfectly fine. 05:17 < jonasschnelli> though the method in the URI would be against JSONRPC 05:18 < jonasschnelli> but speaking JSONRPC against different URI endpoints looks after a feasible design 05:20 -!- MrHodl [~fuc@95.211.205.141] has joined #bitcoin-core-dev 05:25 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 05:27 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 05:30 < wumpus> another day, another bunch of OpenSSL advisories https://www.openssl.org/news/secadv/20160922.txt 05:30 < jonasschnelli> *sigh* 05:31 < phantomcircuit> jonasschnelli: optimally cs_wallet would be private 05:31 < jonasschnelli> Happy that our p2p encryption plans and not based on SSL 05:31 < jonasschnelli> phantomcircuit: agree 05:31 < phantomcircuit> the only way for that to happen is for the public methods to acquire the lock 05:31 < jonasschnelli> I think its a bad design that cs_wallet can be (and will) accessed from the outside 05:31 < wumpus> yes, the lock should be private 05:33 < wumpus> "Operations in the DSA signing algorithm should run in constant time in order to avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations." happy we use secp256k1 instead 05:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 05:37 < sipa> wumpus: note that this is about DSA, not ECDSA 05:37 < wumpus> oh that's a different code path? I don't know openssl internals 05:38 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds] 05:38 < wumpus> I mean it's the same operation on a different group, but they probably made a parallel implementation, okay 05:40 < sipa> yeah, the ecdsa code is separate 05:40 < phantomcircuit> CWalletTx::InMempool 05:40 < phantomcircuit> wtf 05:41 < phantomcircuit> jonasschnelli: why 05:41 < phantomcircuit> WHYY 05:41 < wumpus> which doesn't mean they don't have the same bug there , just waiting to be found :) 05:41 < sipa> phantomcircuit: ? 05:41 < jonasschnelli> phantomcircuit: The current wallet logic need to know that 05:42 < phantomcircuit> sipa: abstraction violation to the max 05:42 < jonasschnelli> But I agree,... couping the wallet with the mempool is bad! 05:42 < wumpus> the wallet is allowed to communicate with the mempool in our case 05:42 < wumpus> this is used for some things such as showing conflicts 05:42 < sipa> phantomcircuit: we can't avoid that without breaking semantics 05:42 < wumpus> I mean: this is a full node wallet, you have the mempool information, why not use it 05:43 < sipa> it can be abstracted more cleanly (install a callback, etc), but functionally we need it, unfortunately 05:43 < jonasschnelli> Yes. But maybe not directly accessing the mempool object. :) 05:43 < wumpus> *the way* of communicating with the mempool may be wrong, that'sa another thing 05:43 < wumpus> right. 05:43 < jonasschnelli> We need to make this more flexible if we once like to have the hybrid SPV mode. 05:44 < jonasschnelli> Which is – sadly – probably far away from being implemented. :) 05:44 < sipa> we use the mempool as an estimation for whether a transaction may still confirm (and for example, refuse to spend unconfirmed output that is not in the mempool) 05:44 < wumpus> yes sure, it would need a fallback with the information missing . Like not show unconfirmed transactions at all. 05:45 < wumpus> that's essentially what is the case already during initial sync 05:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:47 -!- assder [~AndChat20@85.19.219.182] has quit [Read error: Connection reset by peer] 05:47 -!- AndChat|206976 [~AndChat20@85.19.219.182] has joined #bitcoin-core-dev 05:51 < wumpus> doesn't seem like any of the SSL issues are a serious problem for us 05:52 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 05:56 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 05:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 05:59 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 264 seconds] 06:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:02 -!- cryptapus_ is now known as cryptapus 06:15 < wumpus> I guess "SSL_peek() hang on empty record (CVE-2016-6305)" can apply to qt's usage of SSL, then again, the server hanging the connection isn't really that interesting 06:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 06:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:30 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-abfwlhknxypbpcsd] has quit [Quit: Connection closed for inactivity] 06:37 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 268 seconds] 06:41 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev 06:41 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 06:42 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ocldbgiruangxcno] has joined #bitcoin-core-dev 06:44 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 06:48 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev 06:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:52 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 06:54 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 07:04 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!] 07:04 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 07:14 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 07:15 < GitHub97> [bitcoin] paveljanik opened pull request #8793: Do not shadow in src/qt (master...20160922_Wshadow_qt) https://github.com/bitcoin/bitcoin/pull/8793 07:16 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 07:17 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 07:28 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 07:33 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 265 seconds] 07:41 < GitHub41> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/26b370a93700...2b514aa2eae6 07:41 < GitHub41> bitcoin/master b5ccded instagibbs: Comment on CConnman::nLocalServices meaning 07:41 < GitHub41> bitcoin/master 2b514aa Wladimir J. van der Laan: Merge #8785: Comment on CNode::nLocalServices meaning... 07:41 < GitHub82> [bitcoin] laanwj closed pull request #8785: Comment on CNode::nLocalServices meaning (master...nlocalservisme) https://github.com/bitcoin/bitcoin/pull/8785 07:42 < GitHub168> [bitcoin] paveljanik opened pull request #8794: Enable -Wshadow by default (master...20160922_Wshadow_enable) https://github.com/bitcoin/bitcoin/pull/8794 07:43 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 07:44 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 07:44 -!- AndChat|206976 [~AndChat20@85.19.219.182] has quit [Ping timeout: 240 seconds] 07:48 -!- AaronvanW [~ewout@88.128.80.65] has joined #bitcoin-core-dev 07:48 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 244 seconds] 07:48 -!- AaronvanW [~ewout@88.128.80.65] has quit [Changing host] 07:48 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 08:00 < wumpus> it really should be possible to un-approve pulls, right after pushing submit on #8793 I realized the mistake I made 08:00 < wumpus> it's not even possible to *edit* the approval message 08:00 < paveljanik> I think this functionality is not ready yet... 08:01 < paveljanik> There is no Preview on the approval message etc. 08:01 < wumpus> right, it's more of a public beta 08:02 < wumpus> maybe I should just stop using 'approve' 08:02 < paveljanik> we are all "testing rabbits" - is it the same in English? ;-) 08:02 < achow101> I think you're looking for "lab rats" 08:03 < wumpus> in english it's guinea pigs 08:03 < wumpus> or that 08:03 < wumpus> in dutch it's "proefkonijnen", "testing rabbits" 08:04 < instagibbs> lab rats works in english too :) also easier to spell 08:05 < paveljanik> :-) 08:06 < bsm117532> I think of lab rats as grad students who do the experimentation. Guinea pigs get experimented upon, as far as colloquial usage goes. ;-) 08:09 < GitHub162> [bitcoin] laudaa opened pull request #8795: [doc] Mention Gitian building script in documents. (master...master) https://github.com/bitcoin/bitcoin/pull/8795 08:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:10 < wumpus> paveljanik: curious, almost all of the functions that are changes change in the binary 08:10 < wumpus> looking at WalletModel::WalletModel now 08:12 -!- nickler [~nickler@185.12.46.130] has quit [Quit: leaving] 08:12 < paveljanik> interesting 08:13 < paveljanik> I still have to investigate's Marco's finding about reverselock's change changing the binary. It was only lock -> _lock... 08:13 < wumpus> looks like some ebp relative local variables change address, but I don't understand, it's really just a variable renaming 08:14 < paveljanik> but only in QT binary 08:14 < paveljanik> bitcoind untouched... 08:14 < wumpus> yes 08:14 < paveljanik> do we compile Qt somehow different? 08:14 < wumpus> I use the same build and comparison process that I use to cmpare bitcoind binaries 08:15 < wumpus> well qt has qrc passes 08:15 < wumpus> moc, I mean 08:16 < wumpus> which automatically generates some code for signal/slot dispatch, property setting, and such 08:16 < wumpus> that may be what happens here, I don't know 08:16 < wumpus> I'll check if this is restricted to consturctors 08:22 < wumpus> paveljanik: in the case of void WalletView::setClientModel(ClientModel *_clientModel) I think I know why: you haven't changed the latter two statements to refer to the new parameter name 08:22 < wumpus> paveljanik: they now refer to the memner variable 08:22 < wumpus> member* 08:22 < wumpus> same for WalletView::setWalletModel 08:23 < wumpus> the otherwise-empty constructors remain a mystery though 08:24 < paveljanik> will fix both... 08:26 < wumpus> ok let me know when you pushed then I'll redo the binaries check 08:26 < paveljanik> done 08:28 < wumpus> building 08:29 < paveljanik> coffee ;-) 08:36 < wumpus> good idea 08:36 < sipa> just had one 08:37 < paveljanik> Kenya AA Top Superstar - macchiato :-) 08:39 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 08:42 < wumpus> paveljanik: that worked, those two functions are gone from the list now - only constructors left 08:42 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds] 08:43 < wumpus> I'll just say this is fine, I don't have time to investigate the assembly and data in detail now, and I don't think this can be avoided 08:44 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 08:47 < paveljanik> wumpus, yes, thanks for investigation! 08:50 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 260 seconds] 08:51 < paveljanik> I'll double check the rest of the functions in the list 08:53 < paveljanik> Hmm, in WalletView::WalletView, I use platformStyle and not _ platformStyle... 08:54 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 08:54 < paveljanik> https://github.com/bitcoin/bitcoin/pull/8793/files#diff-0945de3e3345c5e5c9b39feef7843574R39 08:55 -!- AaronvanW [~ewout@88.128.80.65] has joined #bitcoin-core-dev 08:55 -!- AaronvanW [~ewout@88.128.80.65] has quit [Changing host] 08:55 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 08:56 -!- laurentmt [~Thunderbi@80.215.234.190] has joined #bitcoin-core-dev 08:56 -!- laurentmt [~Thunderbi@80.215.234.190] has quit [Client Quit] 09:00 < wumpus> paveljanik: yes, it looks like a similar thing 09:00 < wumpus> I've ruled out moc at least 09:00 < wumpus> compiled the file individually with gcc -S and still see the difference 09:04 < wumpus> paveljanik: this seems to make the differences in AddressBookPage::AddressBookPAge go away http://www.hastebin.com/jixoyufuxu.php 09:04 < paveljanik> I have to say I prefer the usage of member-initialized member variable to an argument in the body of the functions... 09:05 < wumpus> yes, I don't think it's an improvement 09:05 < wumpus> let's just leave it at this 09:05 < wumpus> it's explained 09:05 < paveljanik> well, but this means that binaries will be different :-( 09:06 < wumpus> yes, but we are capable of creating a patch that won't change the binaries, it's just ugly 09:06 < wumpus> +larger 09:06 < paveljanik> but its correct (QED) 09:07 < sipa> i think having a patch available to removes the differences is enough 09:07 < sipa> the changes are trivial anyway 09:07 < wumpus> well I've also reviewed the changes and they look ok, this is just qt anyhow and not consensus code 09:07 < wumpus> right sipa 09:07 < paveljanik> yup 09:11 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection] 09:13 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Read error: Connection reset by peer] 09:14 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 09:20 < JackH> Is there any reason to think that Bitcoin wont eventually be taken over in terms of usage by Ethereum (serious question) 09:20 < JackH> Since it seems as if it has become the darling of the current payments industry, despite its failures. The "best" or most "safe" solution does not always take the prize 09:21 < JackH> I am just thinking in terms of opening up Bitcoin, beside fixing malleability, if there is anything on the table? 09:21 < wumpus> #bitcoin 09:22 < JackH> #futureofbitcoin in here? (conceptually) 09:22 < JackH> ah shit 09:22 < JackH> I am not in wizards 09:22 < JackH> sorry 09:23 < JackH> this is akward... 09:23 < wumpus> wizards is about cryptography and moonmath, it's also not the place to discuss comparison to altcoins 09:29 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds] 09:30 -!- AaronvanW [~ewout@88.128.80.65] has joined #bitcoin-core-dev 09:31 -!- AaronvanW [~ewout@88.128.80.65] has quit [Changing host] 09:31 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 09:34 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer] 09:34 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 09:34 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 09:48 -!- xinxi [~xinxi@116.86.38.246] has quit [Quit: Leaving...] 10:10 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev 10:13 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds] 10:22 -!- achow101 [~achow101@129-2-207-18.student.umd.edu] has quit [Ping timeout: 240 seconds] 10:23 < haakonn> JackH: eth is the darling of the "blockchain industry", not the payments industry (what can you pay for with ethers?) 10:24 < haakonn> agh, sorry for the noise, thought this was #bitcoin 10:26 < helo> you had me convinced :P 10:26 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 10:29 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev 10:35 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 10:36 -!- achow101 [~achow101@129-2-207-18.student.umd.edu] has joined #bitcoin-core-dev 10:43 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has quit [Quit: MarcoFalke] 10:49 < instagibbs> when running make check is there a way to get a stack trace on failure 10:50 < instagibbs> error is happening in some helper function, and no useful info about when it's happening 10:52 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 10:52 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 10:54 < GitHub197> [bitcoin] jonnynewbs opened pull request #8796: [trivial] fix mempool comment (outdated by BIP125) (master...trivial_comment) https://github.com/bitcoin/bitcoin/pull/8796 10:59 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 10:59 < btcdrak> meeting time? 11:00 < instagibbs> in an hour? 11:00 < achow101> you're an hour early 11:00 < btcdrak> oh woops 11:13 -!- achow101 [~achow101@129-2-207-18.student.umd.edu] has quit [Quit: Leaving] 11:16 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 11:18 -!- achow101 [~achow101@129-2-207-18.student.umd.edu] has joined #bitcoin-core-dev 11:25 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has quit [Ping timeout: 240 seconds] 11:27 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has joined #bitcoin-core-dev 11:36 -!- gabridome [~gabridome@host188-15-dynamic.180-80-r.retail.telecomitalia.it] has joined #bitcoin-core-dev 11:45 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev 11:48 -!- CIS [uid41037@gateway/web/irccloud.com/x-eyveyiyyuvqhicck] has joined #bitcoin-core-dev 11:48 -!- CIS [uid41037@gateway/web/irccloud.com/x-eyveyiyyuvqhicck] has quit [Client Quit] 11:48 -!- CIS [uid41037@gateway/web/irccloud.com/x-kbfofbabtugpsssy] has joined #bitcoin-core-dev 11:52 -!- CIS is now known as cis 11:53 -!- gabridome [~gabridome@host188-15-dynamic.180-80-r.retail.telecomitalia.it] has quit [Ping timeout: 255 seconds] 11:58 < kanzure> btcdrak: i propose we deprecate timezones 11:58 < jcorgan> and DST 11:58 < btcdrak> yes 11:58 < achow101> kanzure: ask IANA 11:59 < murch> kanzure: Yes, let's all just use UTC all year long. 11:59 < btcdrak> achow101: more like ask Trump 11:59 < achow101> Hah! 11:59 < gmaxwell> shh. 11:59 < sipa> murch: another thing we should learn from icelanders 11:59 < cfields> here for meeting, but dog's pacing at the door. Back in ~5. 11:59 < gmaxwell> Don't start a big OT discussion right before the meeting. 11:59 < wumpus> #startmeeting 11:59 < lightningbot> Meeting started Thu Sep 22 18:59:48 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:59 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:59 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 11:59 < CodeShark> Here 11:59 < jonasschnelli> here 12:00 < btcdrak> jl2012 ping 12:00 < murch> hello 12:00 < sipa> pyng 12:00 < kanzure> hi. 12:00 < sdaftuar> hi 12:00 < wumpus> jl2012 probably won't be here this meeting 12:00 < paveljanik> peng 12:00 < michagogo> May show up in a bit - at dinner with my grandmother atm 12:00 < btcdrak> 01110000 01101001 01101110 01100111 12:01 < gmaxwell> our meeting is at an unfriendly time for our contributors in asia/au/nz/etc. Alas. 12:01 < wumpus> I may not join the meeting today but I suggest not to do https://github.com/bitcoin/bitcoin/pull/8654 in 0.13.1 12:01 < wumpus> It seems the risks is too much comparing with the benefit 12:01 < wumpus> yes what ever time you pick it's always unfriendly to someone 12:01 < btcdrak> I was discussing this with him yesterday. I also think it should be dropped. 12:02 < btcdrak> wumpus: we should find a time that is unfriendly to everyone :) 12:02 < wumpus> #topic Drop reuse sighash computations across evaluation #8654 from 0.13.1? 12:02 < gmaxwell> wumpus: wasn't a complaint, just reminding people of it. :) (and we can all make an effort to stand in for people who can't make it) 12:03 < wumpus> gmaxwell: something else we could do is have e.g. alternating times every week 12:03 < sipa> yes, i'm in favor of dropping it. i believed the advantages were larger first 12:03 < wumpus> but given that people already have a hard time being there intime for a meeting with a fixed time... :-) 12:04 < sipa> but it seems we'll need more changes anyway than we can tolerate for 0.13.1 12:04 -!- yep5555 [~holoirc@186-8-43-176-dynamic.movinet.com.uy] has joined #bitcoin-core-dev 12:04 < gmaxwell> So re: that PR. We can do it later. We've survived thus far without it. 12:04 < btcdrak> yes. 12:04 < wumpus> ok 12:04 < wumpus> removing 0.13.1 milestone from it 12:04 < petertodd> how much worse is the maximum O(n^2) time for segwit? my understanding is that w/o segwit in theory even dozens of minutes are possible anyway 12:05 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 12:05 < sipa> petertodd: the same 12:05 -!- Alina-malina is now known as Samsepiol 12:05 -!- Samsepiol is now known as Alina-malina 12:05 < petertodd> sipa: but can't you get more checksig ops w/ segwit? 12:05 < sipa> petertodd: as segwit inputs only hash the entire transaction at most once 12:05 < sipa> see bip143 12:06 < gmaxwell> petertodd: IIRC. this change is primarily fixing the non-segwit case. The plain hashcache in segwit already optimizes segwit so its basically solved under segwit. 12:06 < jtimon> hi 12:06 < sipa> petertodd: the worst case for a pure segwit-inputs transaction is around 6 ms per block 12:07 < gmaxwell> so the non-segwit cases are the worst case, but we have determined that exploiting some additional caching oppturnities radically reduces that worst case when coupled with a few inconsequential additional limits. 12:07 < petertodd> gmaxwell: ah right, because of how we changed SIGHASH_SINGLE behavior 12:07 < sipa> petertodd: all sighashing is changed in segwit 12:07 < petertodd> alright, I'm ACK to remove that for 0.13.1 12:07 < wumpus> great 12:07 < petertodd> sipa: well sure, but SIGHASH_SINGLE is changed in substance significantly :) 12:07 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 12:08 < gmaxwell> petertodd: right but the reason segwit doesn't have the n^2 blowup anymore is the general change so that the hashing work across inputs can be shared. 12:08 < sipa> petertodd: hmm? they're all changed in a very similar way, with the whole-transaction parts precomputed rather than inlined 12:09 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 12:09 < achow101> are #8634 and #8499 and #8526 ready for merge? 12:09 < wumpus> that's a new topic proposal achow101? 12:09 < achow101> just a question 12:10 < gmaxwell> related topic at least. 12:10 < btcdrak> well they were part of last week's homework 12:10 < wumpus> Add policy: null signature for failed CHECK(MULTI)SIG https://github.com/bitcoin/bitcoin/pull/8634 12:10 < wumpus> Check bad witness and implement several policy limits for segwit scripts https://github.com/bitcoin/bitcoin/pull/8499 12:11 < wumpus> Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH https://github.com/bitcoin/bitcoin/pull/8526 12:11 < CodeShark> The first and last commits for 8634 should be squashed together, have only done limited testing, but the code changes look good 12:12 < CodeShark> Still reviewing 8499 12:13 < wumpus> ok, anyone else with opinion about those pulls? 12:13 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 12:14 < gmaxwell> 8634 needs a squash. LGTM. 12:14 < sipa> 8499 is a blocker for 0.13.1 for sure 12:15 < achow101> wasn't it decided that 8393 was ready, or just about ready 12:15 < sdaftuar> fyi i'm just starting my review of 8499 now 12:15 < wumpus> looks like #8634 has quite a lot of (u)tACKs 12:15 < sdaftuar> (but don't let me hold thigns up!) 12:16 < wumpus> #action merge #8634 after squashing 12:16 < wumpus> 8499 is still very much in progress 12:17 < instagibbs> 8393 isn't that hard to review but only a couple people have given acks 12:17 < gmaxwell> reminder on milestone 22, https://github.com/bitcoin/bitcoin/milestone/22 (and if there are 0.13 things in that, which aren't tagged, make sure they get tagged) 12:19 < sipa> i'll address the latest nits in 8393 12:20 < wumpus> so anything between those that is ready for merge? 12:20 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 12:20 < btcdrak> We need a few more acks on 8526 but it looks harmless enough as is. 12:21 < wumpus> there seems to be disagreement on the RPC behavior change in Fix issue with conflicted mempool tx in listsinceblock https://github.com/bitcoin/bitcoin/pull/8757 12:21 < wumpus> this probably means it should be untagged for 0.13.1 12:21 < btcdrak> sipa: I think there are a couple of niggles on the BIP also https://github.com/bitcoin/bips/pull/423 12:21 < jonasschnelli> Yes. No need for 0.13.1 12:21 < sipa> btcdrak: yes, i'm aware 12:22 < wumpus> jonasschnelli: right, if we do that it should be something documented in the release notes of a major release 12:22 < jonasschnelli> ack 12:22 < jonasschnelli> People probably built apps on the "strange" listsinceblock behavior. 12:22 < wumpus> exactly 12:22 -!- gabridome [~gabridome@host188-15-dynamic.180-80-r.retail.telecomitalia.it] has joined #bitcoin-core-dev 12:23 < jonasschnelli> remved the 0.13.1 ms from 8757 12:23 < wumpus> okay that leaves four to go 12:23 < BlueMatt> wumpus: wait, we're unmarking compact blocks for 0.13.1? 12:23 < BlueMatt> (you just did) 12:23 < gmaxwell> re the listsince blocks The complaint is that conflicts are always shown and the proposed change made them never shown? 12:23 < btcdrak> regarding segwitcb, roasbeef's scripts are running spamming testnet. If there are any miners pointing hash at testnet, can they set "-blockmaxweight=4000000", leaving off any other related params so we get more bigger blocks. 12:23 < wumpus> BlueMatt: uh 12:23 < gmaxwell> BlueMatt: wat? 12:23 < BlueMatt> @laanwj laanwj removed this from the 0.13.1 milestone a minute ago 12:23 < instagibbs> er did someone remove the segwit cb? 12:23 < wumpus> that was a mistake 12:23 < BlueMatt> I assume that was accidental 12:24 < wumpus> please readd 12:24 < BlueMatt> #8393 12:24 < gmaxwell> unclick 12:24 < BlueMatt> ok, so 5 to go 12:24 < jonasschnelli> readded 12:24 < instagibbs> 4 PRs, one related issue 12:24 < sipa> you take one down, pass it around, 5 PR to g 12:25 * BlueMatt is not sure how to feel about #8526...it'll surely end up merged onto master before segwit activates...agree its nice to have things "clean from the start", but do we define clean as policy in 0.13.1 or policy on master/0.14? 12:25 < Chris_Stewart_5> exponential PR blow up 12:25 < btcdrak> There is also this nice project https://github.com/bitcoin/bitcoin/projects/5 12:25 < gmaxwell> if you just want the percentage to go up, feel free to add tags to closed prs that got backported but were never tagged 0.13.1... There are many. :P 12:26 < wumpus> yes good point btcdrak PSA: I've started using the new feature of github projects for tracking a few longer-running projects: https://github.com/bitcoin/bitcoin/projects 12:26 < BlueMatt> same with 8634 12:26 < paveljanik> wumpus, nice! 12:27 < BlueMatt> or, really, what about ignoring #8634 and #8526 and going to solicit feedback for segwit dates after the other ones are in, and then if they make it in before we get date consensus, then they go in, otherwise no 12:27 < gmaxwell> minor meta aside, is there any facility for backing up and retaining all this new github stuff? 12:27 < BlueMatt> gmaxwell: havent looked, but the github api has historically been very, very complete 12:27 < BlueMatt> so i ass-u-me so? 12:27 < wumpus> gmaxwell: that's iwilcox's department (but he's not here) 12:28 < wumpus> but yes I guess it's available on the API if you know where to look, or it will become available, as BlueMatt says 12:28 < gmaxwell> BlueMatt: 8526 when it goes SF could plausably conficate coins, so it's more important to have it non-standard from the getgo. 12:28 < gmaxwell> and 8634 is done but for a squash as far as I can tell. 12:29 < wumpus> already created an action for #8634, we're repeating ourselves 12:29 < BlueMatt> gmaxwell: I'm not sold on it needing to be in anything but master before release, but, ok, in any case, i'd propose we start looking for date-consensus after #8279 and #8499 are in 12:29 < btcdrak> gmaxwell: the github API supports all this new stuff https://developer.github.com/v3/repos/projects/ 12:29 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:29 < BlueMatt> (ie lets start looking for date consensus like...soon) 12:29 < achow101> like.. now? 12:30 < sipa> no, not now 12:30 < instagibbs> achow101: no, after critical updates are merged 12:30 < sipa> first know when we can possibly have a release 12:30 < BlueMatt> like...in a few days after the non-critical ones are merged 12:30 < btcdrak> BlueMatt: well we need #8393 merged too before we can be sure to set dates 12:30 < BlueMatt> btcdrak: sure, fine, #8393, #8279, and #8499, then dates? 12:30 < btcdrak> ack 12:30 < sdaftuar> i believe 8279 is sufficiently resolved for 0.13.1 12:31 < wumpus> let's try to finish those pulls this week then we can talk about the release next meeting 12:31 < gmaxwell> BlueMatt: do we know what the status of btcd's SW support is? 12:31 < BlueMatt> gmaxwell: thats part of soliciting consensus on dates :p 12:31 < btcdrak> ping roasbeef 12:31 < BlueMatt> (ie reaching out to non-bitcoin core people) 12:31 < gmaxwell> BlueMatt: well I've been doing that for a while. that doesn't have any binding on pending PRs. 12:31 < instagibbs> wumpus: ack 12:32 < wumpus> sdaftuar: ok, so let's remove that issue from the 0.13.1 milestone, but not close it 12:32 < sdaftuar> wumpus: sounds good to me 12:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 12:32 < sipa> wumpus: sounds good 12:32 < gmaxwell> btcd is the only active alt implementation that I'm aware of that didn't respond to my "when do you think you'll work on this" with a "only after it's locked in on the network". 12:34 < gmaxwell> BlueMatt: in any case, out of meeting lets try to work on a list of required actions for the activation. 12:35 < wumpus> makes sense to reach out to them then 12:35 < btcdrak> well in terms of wallet code and supporting libraries, there are many which are SW ready, or have it almost ready to go. 12:35 < gmaxwell> yes. 12:35 < petertodd> python-bitcoinlib has a fairly good pull-req for segwit 12:35 < wumpus> awesome 12:36 < gmaxwell> mining software was in a sad state last time I checked, but I know things have improved a lot. 12:37 < gmaxwell> in any case, many things to discuss there that don't need everyone. :) 12:37 < roasbeef> will be starting to finalize my segwit stuff for btcd starting tomorrow, have been busy with lightning stuff and getting btcd up-to-date with past recent soft-forks (CSV, etc) 12:37 < petertodd> roasbeef: +1 12:37 -!- JackH [~laptop@79-73-191-94.dynamic.dsl.as9105.com] has quit [Read error: Connection reset by peer] 12:37 < roasbeef> primarily need to improve the test coverage, and make changes like cost->weight and the nulldummy stuff 12:37 < gmaxwell> roasbeef: fantastic. 12:38 < cfields> i keep meaning to return to patching miners but getting distracted. Feel free to ponk me if there's some mining software that actually gets used that needs to be updated. 12:39 < achow101> armory is.. getting there. We're aiming for the release after the next to have full segwit support 12:39 < petertodd> achow101: thanks! 12:39 < gmaxwell> achow101: thats a good timeframe, really no one should be using it the instant it activates, except for testing. 12:40 < btcdrak> oh I didnt know you work on Armory achow101 +1 12:40 < CodeShark> my stuff is almost 100% segwit ready, just need merkle proofs for witnesses in filtered blocks or some better SPV solution 12:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 12:40 < petertodd> gmaxwell: I'll probably switch opentimestamps to use segwit, but that's a maximum loss of something like $20 :) 12:40 < gmaxwell> It's just good to hear that more things are almost read, as it's another angle of testing. 12:41 < Chris_St1> CodeShark: What BIP is that related to? 12:41 < CodeShark> We don't have a BIP yet, I don't think 12:41 < sipa> Chris_St1: that will need a new bip 12:42 < sipa> it's trivial (just combine bip37 with bip141 wtxids) 12:42 < Chris_St1> ok, gotcha. 12:42 < gmaxwell> Chris_St1: he wants something like the filtered block messages that provide witnesses too. (the opposite of what most SPV wallets do, but codeshark extracts participant data from witnesses) 12:42 < sipa> but it needs to be fleshed out... and i don't know how keen people are on extending bip37 further 12:43 < CodeShark> I'd prefer a replacement to bip37, but that's more involved 12:43 < Chris_St1> BIP37 is definitely a monster in terms of implementation... or atleast it was for me 12:43 < gmaxwell> We could probably do better. 12:43 < sipa> at least we could propose to drop some of the auto-inserting that causes false positive rate blowup 12:43 < petertodd> note that it's reasonable to ask for a full block even if you are a lite-client in many cases 12:44 < BlueMatt> CodeShark: uhhhhhhhhh, that sounds like a blocker 12:44 < gmaxwell> petertodd: Satoshi's vision. 12:44 < btcdrak> petertodd: such as? 12:44 < jtimon> I guess he means as a way to get more privacy? 12:44 < sipa> BlueMatt: how so? 12:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 12:45 < BlueMatt> it seems to me it is impossible to use the bloom-filtered connection stuff in segwit....I mean we can decide to not support it because its bad, but we need to actively decide that 12:45 < petertodd> no, I just mean that the data increase is relatively low 12:45 < gmaxwell> BlueMatt: wut? hell no. I am aware of no other SPV client than codeshark's that does _anything_ with the witness data right now. 12:45 < jtimon> no tevealing which txs you care about? just thinking out loud... 12:45 < sipa> BlueMatt: spv wallets shouldn't care about the witness data 12:45 < sipa> hell, it's an advantage that their bandwidth will drop 12:45 < petertodd> sipa: indeed, they can't verify that the witness is valid 12:46 < gmaxwell> BlueMatt: it works fine, you just don't get witnesses, which is an intentional and desirable outcome thats actually listed on the segwit advantage sheets. For the most part they can't do anything with the data. 12:46 < CodeShark> wallets that don't tell you who signed a multisig are incomplete ;) 12:46 < gmaxwell> There should be some option for those who want it, sure. Though they can also fetch the whole block, so its not a big deal even there. 12:46 < petertodd> CodeShark: well, that's an example where you can request a full block - not many wallets need to actually know that 12:46 < petertodd> CodeShark: as an example, I don't think GreenAddress will tell you who actually signed txs in a GA wallet 12:47 < CodeShark> it's critical for enterprise applications 12:47 < CodeShark> Accountability is important 12:47 < petertodd> CodeShark: enterprise can afford some extra bandwidth I'm sure :) 12:47 < achow101> I think we're getting OT 12:47 < petertodd> CodeShark: this isn't a blocker is all I'm saying 12:47 < CodeShark> we can revisit this after 0.13.1 12:47 < gmaxwell> It's also not news or an accident. 12:48 < wumpus> no one is considering it is a blocker except for BlueMatt 12:48 < petertodd> CodeShark: ack 12:48 < BlueMatt> gmaxwell: sure, I'm saying that you cant use segwit as an spv client 12:48 < sipa> BlueMatt: of course you can? 12:48 < gmaxwell> BlueMatt: thats not true. 12:49 < petertodd> BlueMatt: note how with segwit, your txids aren't malleable, therefore you can add the txids of outputs in your wallet to your bloom filter and be sure you'll know if they get spent 12:49 < BlueMatt> gmaxwell: however, in cases like a scripthash, you previously are able to see things that were to your public, or partially to your pubkey 12:49 < BlueMatt> which you might want to 12:49 < BlueMatt> petertodd: you already do that, the malleability doesnt help 12:49 < Chris_St1> May be a stupid question, but are we refering to 'blocker' in the context of blocking 0.13.1 or downloading a full block? 12:49 * BlueMatt isnt recalling exactly what the use-case was for scriptSig matching, but you now can no longer do that 12:49 < petertodd> BlueMatt: true, once confirmed 12:49 < wumpus> Chris_St1: I think it would be really ill-advices to add a blocker for 0.13.1 12:49 < jtimon> Chris_St1: the former 12:49 < petertodd> BlueMatt: I take back that comment 12:50 < petertodd> anyway, we can agree that anything fixing this is non-consensus, right? therefore it's not relevant for 0.13.1 12:50 < gmaxwell> BlueMatt: I carefully went through the code base of some three different wallets to confirm there were no complications there. Of course, it also does nothing to _existing_ software. 12:50 < BlueMatt> gmaxwell: i take back my comment, i no longer recall why we needed to match scriptSigs...maybe we didnt need to 12:51 < sipa> i think there was no reason for that, indeed 12:51 < BlueMatt> but it is the case that you lose this property of matching pubkeys which were used 12:51 < sipa> and if there is, we can still add it back 12:51 < BlueMatt> sipa: well, you might want it, but not a ton 12:51 < gmaxwell> which all works fine. And so even where there are things that want that data (which appear to be almost none of them), they can be accomidated later. The most common case (of not needing it) is already accomidated. And all existing things are unchanged as well. 12:51 < petertodd> I can imagine silly embedded consensus applications where it'd be useful... but supporting that is definitely not a priority 12:51 < wumpus> at this point we should be careful to only let critical problems block 0.13.1, not everything that would be nice for some applications 12:51 < Chris_St1> BlueMatt: Matching scriptSig constants in BIP37 right? 12:51 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 250 seconds] 12:52 < BlueMatt> wumpus: well, if it were the case that you couldnt match properly in segwit it would be bad, but it seems that you're fine 12:52 < wumpus> BIP37 can be extended, sure 12:52 < BlueMatt> Chris_St1: bip37 only ever matches constants 12:52 < wumpus> but that's not yet another reason to move forward the release 12:52 < BlueMatt> agreed 12:52 < achow101> topic proposal: alert system retirement 12:52 < gmaxwell> AFAICT the only 'utility' of that matching was degrading privacy by tainting the filter with FPs on extrainous data. :P 12:52 < instagibbs> 8 minutes left 12:52 < BlueMatt> we might fix this by throwing out bip37 and doing something not-batshit-insane, but thats an aside from the meeting 12:53 < BlueMatt> gmaxwell: yup 12:53 < gmaxwell> BlueMatt: yup. 12:53 < CodeShark> I want a good fairly secure quick sync solution. BIP37 sucks :p 12:53 < gmaxwell> second on achow101's topic. 12:53 < petertodd> CodeShark: sure, fiber-to-the-home :) 12:53 < CodeShark> But we'll do that after 0.13.1 12:53 < wumpus> #topic alert system retirement 12:53 < petertodd> gmaxwell: ack 12:54 < gmaxwell> Okay I sent out an email on this. Mostly well recieved (at least in public). I went and bludgenoned alt implementations into removing the alert key and only got mildly bloodied in the process. 12:54 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 12:54 < petertodd> gmaxwell: sounds like it's time to set dates 12:54 < gmaxwell> My view on the next steps: 12:54 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 12:54 < gmaxwell> (1) Create a bitcoincore.org or bitcoin.org announcement message. 12:55 < gmaxwell> (2) send a penulitmate alert with more polite text than the COMPROMISED message that directs people to it. 12:55 < gmaxwell> (3) much later, send final alert. 12:55 < wumpus> I'd say we send the final alert with the 0.14 release 12:55 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 12:55 < gmaxwell> (4) hardcode nodes to send the final alert to peers to overcome the lack of propagation. (just using the one or two lines of code needed to send a static message, not pulling back any alert code) 12:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:56 < wumpus> then include code in there to send it to old peers that connect, as gmaxwell says 12:56 < BlueMatt> gmaxwell: ACK 12:56 < BlueMatt> wumpus: ACK final alert with 0.14 12:56 < jtimon> ack 12:56 < achow101> ack 12:56 < petertodd> gmaxwell: and release the privkey for the alert key w/ the final alert? 12:56 < btcdrak> ack 12:57 < gmaxwell> I think we can do 1/2 in the next week. I'm not aware of any reason to delay, and there are propagation advantages to doing it earlier rather than later. 12:57 < sipa> i'd release the key later even 12:57 < petertodd> gmaxwell: ack 12:57 < instagibbs> make sure to sweep the funds people have sent to the key :P 12:57 -!- yep5555 [~holoirc@186-8-43-176-dynamic.movinet.com.uy] has quit [Ping timeout: 272 seconds] 12:57 < petertodd> instagibbs: ha 12:57 < roasbeef> btcd still has the code in place to parse the alert messages, but we simply drop-it-like-its-hot once recv of the message without any further processing (and have since early last year) 12:57 < BlueMatt> sipa: ack 12:57 < sipa> there may be alternate codebases that use the key who want to do something similar to (3) and (4) 12:58 < sipa> oh, wait 12:58 < sipa> they need the key for that 12:58 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services] 12:58 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev 12:58 < BlueMatt> 2 min 12:58 < instagibbs> any pressing topics 12:58 < wumpus> well after the final alert is sent, the key is only historical curiosity 12:58 < gmaxwell> okay, I'll send a message to the list. 12:58 < luke-jr> can the final alert match all clients? 12:58 -!- drizztbsd is now known as timothy 12:59 < wumpus> luke-jr: you mean the pre-final alert, and yes 12:59 < petertodd> wumpus: yeah, once that final alert is sent, I doubt releasing the key will do any harm 12:59 < gmaxwell> It cann't not match all clients. 12:59 < wumpus> gmaxwell: I think he means the penultimate alert 12:59 < wumpus> obviously the final alert matches all clients, at least those that still parse alerts 13:00 < gmaxwell> petertodd: if I can parition your network I can make your client show "Your bitcoin is outdated and vulnerable. You MUST download an update to continue. http://bitcoinscam.eu/" 13:00 < wumpus> gmaxwell: wasn't that the point in adding it to the client? 13:00 < gmaxwell> I was thinking of limiting the applicability of the penultimate alert to users of Bitcoin Core, open to suggestions. 13:00 < petertodd> gmaxwell: sure, but that'll have been after months of alert - I'm not worried there 13:00 < wumpus> it applies to everyone using the key, not just users of bitcoin core 13:00 < gmaxwell> in any case, can continue after, we should wrap the meeting. :) 13:00 < petertodd> gmaxwell: I'd be inclined to provide it to everyone - it's a warning that everyone will soon have a final alert 13:00 < instagibbs> ding ding 13:01 < btcdrak> ding ding ding 13:01 < wumpus> yes it's time 13:01 < wumpus> #endmeeting 13:01 < lightningbot> Meeting ended Thu Sep 22 20:01:03 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:01 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.html 13:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.txt 13:01 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-22-18.59.log.html 13:01 < sipa> bye 13:01 < wumpus> agree petertodd 13:01 < wumpus> this is not bitcoin core specific but everyone-that-embeds-that-pubkey specific 13:01 < Chris_Stewart_5> CodeShark: Did you have any concrete ideas for improving on BIP37? 13:01 < gmaxwell> petertodd: the reasoning I had for that thought is I think it should provide upgrade advice. And I don't want to give update advice to people who insist on running software I consider broken and dangerous. 13:02 < petertodd> gmaxwell: I think the upgrade advice can be general "whatever you are running, upgade" 13:02 < petertodd> gmaxwell: equally, it can just be a warning that you will soon see a final alert, as the alert system is being depreciated 13:02 < wumpus> yes, it can just be a warning about the alert 13:02 < wumpus> it doesn't really have to tell to upgrade 13:03 < wumpus> just make sure peopel are aware 13:03 < btcdrak> that's a good idea 13:03 < gmaxwell> Chris_Stewart_5: there is a proposal on the list for a replacement using commited filters. that coupled with a CB like getblocktxn that provides hashproofs would be the replacement. 13:03 < CodeShark> Chris_Stewart_5: proposals to put the filters in the blocks themselves seem at least slightly more promising 13:03 < gmaxwell> the commited filter thing can also be done without the commitment and still have the same security as BIP37 but without the consensus change. 13:05 < petertodd> gmaxwell: re: committed filter, you can make the consensus rule be it has to be a superset of what actually matches re: soft-forks 13:05 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services] 13:05 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev 13:05 < petertodd> gmaxwell: otherwise if we add another segwit-like thing we need a new filter 13:05 < gmaxwell> petertodd: bandwidth overhead in that however. 13:05 < gmaxwell> because then you have to send the filter between full nodes. yuck. 13:05 < CodeShark> UTXO commitments + getutxos would probably be the quickest sync option that isn't totally insecure 13:05 < instagibbs> is the bitcoin wiki down for others for the last few days? 13:05 < petertodd> gmaxwell: true, though wasn't it only a few KB? 13:05 -!- drizztbsd is now known as timothy 13:06 < CodeShark> Privacy issues are still a problem, though 13:06 < petertodd> CodeShark: I don't think we can reasonably implement UTXO commitments 13:07 < gmaxwell> there are also many other options for scanning, including ones that are private, like via PIR lookup. 13:07 < Chris_Stewart_5> Thanks gmaxwell, CodeShark, will read. 13:07 < petertodd> and it'd be good for some of those options to be implemented via central services first to prototype 13:08 < gmaxwell> the commited maps thing would let us do several non-commited revisions the only thing you lose without the commitment is security against censorship, which BIP37 has none of already. 13:09 < petertodd> and a central service can be audited easily enough to detect censorship (assuming clients connect anonymously) 13:09 < gmaxwell> petertodd: re-size it may be interesting to have several sizes, so clients could probe at the smallest and then only probe the larger if they have a hit... so perhaps they're larger than you might think. this would also all be unpredictable uncached validation. and 4kb would add about 1/3rd to a CB transmission. 13:09 < petertodd> or actually, commit to the contents of the filter, and then provide the filter 13:09 < petertodd> gmaxwell: true 13:09 < gmaxwell> petertodd: right you could talk to N hosts, and find that they all give the same commitment value. 13:10 < gmaxwell> without having to fetch the filter N times. 13:10 < gmaxwell> or even connect to one host and get a commitment signed by N parties. 13:10 < petertodd> gmaxwell: add a signature on the commitment and that should be enough 13:10 < gmaxwell> right. 13:11 < CodeShark> Thing is all these proposals significantly complicate client implementations 13:11 < petertodd> CodeShark: well, privacy is hard :) 13:11 < gmaxwell> checking a signature is not complex. :P 13:12 < gmaxwell> in any case, it's foolish to think we can design for forever in a single step; we must have incremental stepping stones. 13:12 < CodeShark> Ultimately, we need client implementations to be relatively simple or centralized API services will domimate 13:12 < CodeShark> *dominate 13:12 < petertodd> gmaxwell: I found it interesting how the Roughtime spec says that they will depreciate servers on a regular basis to force clients to keep up-to-date 13:13 < petertodd> CodeShark: well, if we don't do a good enough job, centralized API services may be better for privacy... I'd trust a centralized API over bloom filters 13:13 < CodeShark> or at the least we need some solid client-side libraries with multiple language bindings 13:14 < petertodd> CodeShark: does bloom filters even have that? :) 13:14 < petertodd> CodeShark: python-bitcoinlib *still* doesn't have a full bloom filter implementation - I've never had anyone interested in using it 13:14 < CodeShark> petertodd: only the true diehards even attempt to use bloom filters rather than, say, bc.i :p 13:15 < petertodd> CodeShark: indeed - python-bitcoinlib is likely used 99% of the time with a local copy of Bitcoin Core 13:15 < gmaxwell> bc.i has better privacy than bloomfilters, IMO. 13:16 < CodeShark> but it's still a single point of failure 13:16 < petertodd> CodeShark: then use the Electrum servers! :) 13:16 < CodeShark> Argh - lol 13:17 * petertodd runs two OpenTimestamps public calendar servers and thinks that's good enough. :) 13:17 -!- gabridome [~gabridome@host188-15-dynamic.180-80-r.retail.telecomitalia.it] has quit [Quit: gabridome] 13:17 < petertodd> CodeShark: honestly, I think Electrum would be interested in better privacy too - they've been open to discussing this in the past, and IIRC implemented prefix filters for that purpose 13:18 < CodeShark> I run multiple bitcoin core instances and reluctantly use bip37 13:18 < luke-jr> http://murch.one/wp-content/uploads/2016/09/CoinSelection.pdf 13:18 < CodeShark> I get around the privacy and censorship issues by running my own instances 13:19 < CodeShark> Electrum is just an additional dependency I don't want 13:24 < CodeShark> Hell, if I wanted to go that route I could probably write a much thinner custom server - or a custom build of bitcoin core, even 13:24 < luke-jr> if we merge script indexes, should probably do some p2p replacement for Electrum's protocol <.< 13:25 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 13:27 < CodeShark> fwiw I'd like to work with all interested parties, including the electrum folks, in figuring out a good long-term solution to this 13:28 < gmaxwell> The model that many application prefer where you have some random access query by address is inherently unscalable and probably lacks a non-centeralized future. 13:29 < CodeShark> Then perhaps we need a different application model as well 13:33 < morcos> cfields: what happened to: https://github.com/theuni/bitcoin/tree/copy-move ? 13:34 < CodeShark> it won't be simple to implement - but with the right abstractions it could be well-encapsulated, providing app developers with a reasonably simple model 13:35 < cfields> morcos: started there, and got side-tracked optimizing prevector. the top commit is probably good as-is, though it won't change much without making prevector movable. 13:36 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 13:36 < luke-jr> always annoying when people hear "I'm running Bitcoin Core" and their immediate reply is "you should switch to Electrum!" 13:37 < gmaxwell> more than a little frightening too. 13:38 < gmaxwell> wumpus: what happened with the work on SSE sha2 and asm for the CRC32? 13:39 < morcos> cfields: i've been using that commit in my benchmarks for a while.. and today while trying to update everything i left it out.. and i'm thinking that explains some inconsitencies. i'll confirm, but i think its worth getting in 13:39 < gmaxwell> wumpus: if you were disappointed at the fairly modest improvement, I expect it will be much better post the checkqueue changes. 13:40 < cfields> morcos: sure. If you'd like to double-down, I can give you a quick commit that just adds move to prevector. It should be quite significant if you're seeing a difference already 13:46 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 13:48 -!- cryptapus_afk is now known as cryptapus 13:50 < Chris_Stewart_5> Back when pay to public key and raw multisig were used on the network, how were addresses generated? Did you just hash the entire scriptPubKey? 13:51 < luke-jr> that was before addresses 13:51 < luke-jr> (and raw multisig was never common use) 13:52 < luke-jr> if you wanted to pay someone, you put in their IP and your client connected to them for a script 13:53 < Chris_Stewart_5> Interesting, I guess i'm conflating addresses and actually spending scriptPubKeys. 13:55 < Chris_Stewart_5> luke-jr: Was that functionality inside of Bitcoin Core? Inputing their ip address? 13:55 < luke-jr> Chris_Stewart_5: this was before Bitcoin Core's time, and also before my time :p 13:56 < luke-jr> Bitcoin started off with a wxWidgets Windows-only GUI client which was abandoned a long time ago 13:56 < Chris_Stewart_5> Haha fair enough, guess i'm getting more into history instead of development any way 13:59 < morcos> cfields: i'd love to double down, but will have to wait til tomorrow 14:01 < cfields> morcos: ok, will push there later. sanity checking now. 14:02 -!- cis [uid41037@gateway/web/irccloud.com/x-kbfofbabtugpsssy] has quit [Quit: Connection closed for inactivity] 14:05 -!- sokei [~sokei@95.215.44.99] has joined #bitcoin-core-dev 14:10 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-fxhzqwzfnzjxmgla] has quit [Quit: https://fnordserver.eu] 14:15 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 14:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 240 seconds] 14:17 -!- Guyver2_ is now known as Guyver2 14:25 -!- achow101 [~achow101@129-2-207-18.student.umd.edu] has quit [Changing host] 14:25 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev 14:30 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 255 seconds] 14:36 < luke-jr> FWIW, C++11 is de facto causing ABI issues on Gentoo (but probably not significant enough to regret the move) 14:37 -!- Netsplit *.net <-> *.split quits: jeremyrubin, mn3monic, jtimon, LeMiner, zxzzt, aspect_, owowo, PatBoy, CyrusV, zmanian__, (+19 more, use /NETSPLIT to show all of them) 14:37 -!- Netsplit *.net <-> *.split quits: BonyM1, rogerwilco, lclc, Ylbam, ryan-c, asoltys, ghtdak, Madars, andytoshi, morcos, (+10 more, use /NETSPLIT to show all of them) 14:37 -!- Netsplit *.net <-> *.split quits: [b__b], trippysalmon, waxwing, wolfspraul 14:37 < luke-jr> mostly due to GCC 4.9 vs 5 mixing it seems 14:38 -!- Netsplit over, joins: jtimon, aalex, jeremyrubin, zmanian__, jouke_, warren, CodeShark, Lightsword, zxzzt, blkdb (+5 more) 14:38 < sipa> i would expect to be the one distro that doesn't suffer from such issues :) 14:38 < sipa> *gentoo 14:39 -!- michagogo [uid14316@wikia/Michagogo] has quit [Max SendQ exceeded] 14:40 < luke-jr> sipa: tends to be the most likely to hit issues; binary distros just rebuild everything when ABIs change :p 14:40 -!- Netsplit over, joins: Ylbam, morcos, cfields, rogerwilco, waxwing, berndj, MrHodl, lesderid, ghtdak, trippysalmon (+5 more) 14:40 -!- Expanse [sid146237@gateway/web/irccloud.com/x-zfanrqteqjzwzwni] has quit [Ping timeout: 265 seconds] 14:40 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-otsenxlwizzbpiyc] has quit [Ping timeout: 252 seconds] 14:41 -!- Netsplit over, joins: midnightmagic, Chris_Stewart_5, mn3monic, jannes, dgenr8, owowo 14:41 -!- Netsplit over, joins: Magma 14:41 -!- Netsplit over, joins: gluytium, TD-Linux, PatBoy, bsm117532, LeMiner, d4de 14:42 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 14:42 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev 14:42 -!- andytoshi [~andytoshi@unaffiliated/andytoshi] has joined #bitcoin-core-dev 14:42 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev 14:42 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 14:42 -!- ryan-c [~ryan@znc.rya.nc] has joined #bitcoin-core-dev 14:42 -!- BonyM1 [~BonyM-I@ua-83-227-211-4.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev 14:42 -!- paracyst [paracyst@unaffiliated/paracyst] has joined #bitcoin-core-dev 14:47 -!- Expanse [sid146237@gateway/web/irccloud.com/x-ztardxtsjlbsdcbn] has joined #bitcoin-core-dev 14:49 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev 14:51 -!- Frederic94500 [4d808e1f@gateway/web/freenode/ip.77.128.142.31] has joined #bitcoin-core-dev 14:54 -!- Frederic94500 [4d808e1f@gateway/web/freenode/ip.77.128.142.31] has quit [Client Quit] 15:05 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-tigpcftaqerfvaro] has joined #bitcoin-core-dev 15:12 -!- limpkin [sid20909@gateway/web/irccloud.com/x-vnwxfwfpooobvzto] has joined #bitcoin-core-dev 15:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 15:16 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-oeopuvcnqstsenuo] has joined #bitcoin-core-dev 15:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 15:19 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 15:22 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 15:28 -!- cryptapus is now known as cryptapus_afk 15:36 -!- murch [~murch@p4FE3B008.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 15:43 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:44 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:46 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds] 15:55 < gmaxwell> Re PR #8661 is there a reason that this isn't getting merged? 15:58 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev [] 15:58 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 16:02 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-yydadntngxxxqgek] has joined #bitcoin-core-dev 16:16 -!- rogerwilco [~rogerwilc@195-230-63-194.adsl.highway.telekom.at] has quit [Ping timeout: 255 seconds] 16:17 -!- rogerwilco [~rogerwilc@195-230-41-107.adsl.highway.telekom.at] has joined #bitcoin-core-dev 16:23 -!- d4de [~d4de@156.212.134.80] has quit [Quit: Leaving] 16:39 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 16:41 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Client Quit] 16:42 -!- randy-waterhouse [~kiwigb@107.150.94.3] has joined #bitcoin-core-dev 16:43 -!- randy-waterhouse [~kiwigb@107.150.94.3] has quit [Changing host] 16:43 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 17:09 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 17:10 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 17:11 < GitHub44> [bitcoin] gmaxwell opened pull request #8800: Fetch w/o CB if mempool empty, don't use HB mode if blocks only. (master...no-hb-in-bo) https://github.com/bitcoin/bitcoin/pull/8800 17:12 < gmaxwell> hm. that allow edits thing defaults to on, so next time someone PRs their whole altcoin to our repo we could go and replace their code with bitcoin? :P "we upgraded your altcoin, enjoy!" 17:13 < luke-jr> lol 17:14 -!- stan_ [~stan@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 248 seconds] 17:14 < sipa> gmaxwell: only the PRed branch opens up 17:15 < sipa> ah, for that example that may be sufficient, actually... 17:22 < gmaxwell> yes, that was what I was thinking. 17:24 < sipa> we should see what happens if you PR to two projects at once 17:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 17:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 17:52 -!- stan_ [~stan@pool-72-69-136-169.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 17:54 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev 18:00 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 18:00 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 18:04 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 244 seconds] 18:04 -!- stan_ [~stan@pool-72-69-136-169.nycmny.fios.verizon.net] has quit [Remote host closed the connection] 18:16 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rcquzofiedjmsgct] has quit [Quit: Connection closed for inactivity] 18:20 -!- stan_ [~stan@pool-72-69-136-169.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 18:21 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev 18:34 -!- dermoth_ [~thomas@dial-216-221-46-111.mtl.aei.ca] has joined #bitcoin-core-dev 18:34 -!- dermoth [~thomas@dsl-216-221-54-208.mtl.contact.net] has quit [Disconnected by services] 18:34 -!- dermoth_ is now known as dermoth 18:37 -!- jchrome [~jchrome@sydnns0115w-047055195222.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 265 seconds] 18:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 18:40 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 19:11 -!- stan_ [~stan@pool-72-69-136-169.nycmny.fios.verizon.net] has quit [Remote host closed the connection] 19:26 -!- MrHodl [~fuc@95.211.205.141] has quit [] 19:28 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 19:38 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 255 seconds] 19:58 -!- randy-waterhouse [~kiwigb@150.242.131.38] has joined #bitcoin-core-dev 19:59 -!- randy-waterhouse [~kiwigb@150.242.131.38] has quit [Changing host] 19:59 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 20:19 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 20:19 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 20:37 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 265 seconds] 20:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:47 -!- xinxi_ [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 20:52 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 276 seconds] 20:55 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 255 seconds] 21:07 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 21:07 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev 21:11 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:48 -!- jon3ss [~name@bl11-114-194.dsl.telepac.pt] has joined #bitcoin-core-dev 21:58 < luke-jr> do we currently have a way to turn off NODE_NETWORK without enabling pruning? 22:00 < gmaxwell> no, why would we? 22:00 < luke-jr> so people don't IBD off me <.< 22:00 < gmaxwell> oh well set the upload limiter to a tiny number. :) 22:00 < gmaxwell> and you'll hang up on them when they do. 22:00 < luke-jr> yeah, I'd rather just not have them ask though 22:01 < luke-jr> otoh, I guess I have no reason to discourage light clients from connecting to me.. 22:01 < gmaxwell> fwiw, I found more bandwidth was being used by bitcoinj clients than ibding bitcoin core. 22:02 < luke-jr> O.o 22:02 < luke-jr> that's unexpected 22:12 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 22:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 22:18 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 265 seconds] 22:22 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Quit: ZNC 1.6.3 - http://znc.in] 22:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:22 -!- Alina-malina [~Alina-mal@37.157.216.188] has joined #bitcoin-core-dev 22:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:24 -!- Alina-malina [~Alina-mal@37.157.216.188] has quit [Changing host] 22:24 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 22:28 -!- rogerwilco [~rogerwilc@195-230-41-107.adsl.highway.telekom.at] has quit [Read error: Connection reset by peer] 22:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:40 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hzxhpfqrudwkvuqr] has joined #bitcoin-core-dev 22:45 -!- DigiByteDev [~JT2@185.29.164.102] has joined #bitcoin-core-dev 23:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:15 -!- DigiByteDev [~JT2@185.29.164.102] has quit [Quit: DigiByteDev] 23:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:43 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev