--- Log opened Mon Feb 18 00:00:26 2019
--- Day changed Mon Feb 18 2019
00:00 < wumpus> I'm not sure I understand; doesn't one of the nodes have to be listening for the other to connect to it?
00:01 < wumpus> whether the nodes are on clearnet, tor, i2p, or another overlay network doesn't change that
00:01 < gmaxwell> provoostenator: not really.
00:02 < provoostenator> How does Tor avoid this problem?
00:02 < wumpus> they use relays and onion routing
00:03 < gmaxwell> tor is a tunneling protocol... and tor nodes are all listening.  you can connect to a HS running on a tor client behind a firewall because the client connects out to the tor network.
00:04 < provoostenator> So who's doing the listening? A smaller number of tor nodes?
00:04 < wumpus> yes, exactly, they're indirectly connected through relays
00:04 < wumpus> routing your traffic over a relay would make zero sense for the bitcoin protocol as all the data is public
00:05 < wumpus> well okay there's the onion routing proposal for transactions, but besides that
00:05 < provoostenator> It could make sense for authentical (RPC like) stuff, which is what Luke was trying to solve.
00:05 < provoostenator> But it seems a bit heavy.
00:06 < provoostenator> I mean it's kind of cool being able to connect to your own node from mobile without revealing the destination IP by going through a bunch a lightning hops, but Tor seems easier.
00:06 < echeveria> provoostenator: it's heavy, makes a crap tonne of noise about its usage, and has a large attack surface. it's exactly what you don't want. 
00:06 < wumpus> ( I mean, blocks and transactions *themselves* are relayed, there's no need to relay/bounce at the TCP level)
00:07 < wumpus> there's alrady no problem if you can't accept incoming connections, there's always someone who does listen that you an connect to
00:07 < gmaxwell> I guess what luke would want would be like getting your own node to sign headers then have some way of getting those headers from a public host.
00:08 < provoostenator> I think it's more about having a super light weight wallet on your phone that's really just a remote control for your node.
00:08 < gmaxwell> Which could be done, but ... it just seems kinda pointless to me. Luke's usecase is 99% conjecture... spv clients don't care about security beyond yolo hope no one attacks grade security, which is why they are spv lcients.
00:08 < echeveria> (an eighth of the listening IPV4 nodes also have 8332 exposed, btw) 
00:08 < wumpus> that's valid idea but it has nothing at all with bitoin P2P anymore
00:09 < provoostenator> wumpus: I tend to agree that remote control is a more generic internet problem that can be solved outside of Bitcoin.
00:09 < gmaxwell> provoostenator: not superlight weight but just an spv wallet which has security that is tracable to the security of your own node (which runs on some headless host of yours)
00:09 < wumpus> remote control over bitcoin P2P? what?
00:09 < wumpus> i need coffee
00:09 < echeveria> gmaxwell: just have some central neutrino repo that you can add your own signatures to. done.
00:10 < gmaxwell> echeveria: right. 
00:10 < echeveria> gmaxwell: block_header, signatures[]
00:10 < wumpus> provoostenator: definitely
00:10 < provoostenator> wumpus: you'd rely on your node at home (or wherever) to validate blocks, your phone has some private keys and wants to know the balance, so it just asks your node.
00:11 < wumpus> r;
00:11 < provoostenator> That's on one extreme of light-weightness, you could do something more hybrid like gmaxwell says where the phone does more work.
00:11 < wumpus> provoostenator: so electrum, basically
00:11 < echeveria> what I don't want to deal with is the bitcoin project being responsible for a bunch of people running outdated, vulnerable tor software that's doing nothing but harm them. include some scripts for setting this up in contrib/ if people really want it. I certainly do not. 
00:11 < gmaxwell> echeveria: stop.
00:11 < gmaxwell> echeveria: wumpus already said we're not doing that.
00:11 < gmaxwell> you don't need to repeat.
00:11 < gmaxwell> Case made.
00:11 < echeveria> fine. 
00:11 < gmaxwell> :)
00:12 < echeveria> sorry, this was mentioned to me out of band today as well. 
00:12 < echeveria> I'd definitely like to see things like more p2p transports, don't let me detract from that. 
00:13 < provoostenator> Funny how #11902 is tagged as "good first issue"
00:13 < gribble> https://github.com/bitcoin/bitcoin/issues/11902 | NAT-PMP port forwarding support · Issue #11902 · bitcoin/bitcoin · GitHub
00:13 < gmaxwell> take a step back.  I believe the history of this discussion is that luke told someone somewhere don't use wallet X  (some untrusted server SPV thing) because its insecure.  Then someone said something like "well obviously I'm not going to run bitcoin core on my phone so how should I solve this"?
00:13 < gmaxwell> provoostenator: it is because you don't need to know essentially anything about bitcoin.
00:13 < gmaxwell> (something about _networking_ sure. :) )
00:14 < gmaxwell> good first issue doesn't mean good for newbies to development or something like that. :)
00:14 < provoostenator> I know, but I don't think this is easy for anyone unfamiliar with the codebase either, but I could be wrong. Don't want to discourage someone from trying :-)
00:15 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has joined #bitcoin-core-dev
00:15 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
00:15 < gmaxwell> (continuing) and luke's response was run your favorite SPV phone wallet against your own node.  Which is good enough advice except (1) existing lite wallets (mostly) don't let you do that, (2) it's really hard to actually connect into your own node for most users. (3) you won't know for sure that you're connecting to your own node due to lack of auth.
00:16 < gmaxwell> Tor happens to solve (2) and (3).
00:16 < gmaxwell> though it's a blunt instrument.
00:17 < provoostenator> BIP 151 solves (3), but not (2).
00:19 < gmaxwell> technically BIP150 (or whatever replaces it... sipa and I really need to finish that)
00:20 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
00:20 < gmaxwell> (2) though can be substantially addressed through PMP/UPNP/etc.  the users least likely to know how to punch a hole themselves are most likely to have a nat box that does pmp/upnp.
00:21 < gmaxwell> though maybe I'm being cynical but I don't see (1) changing.  esp since we don't (and won't be) providing the kinds of crazy indexes that these wallets are written to need,  they still rely on some somewhat trusted server regardless.
00:21 < provoostenator> Agreed, the combination of PMP/UPNP and ~BIP150 seems a more precise tool for this job.
00:22 < gmaxwell> Also if people want to improve things with tor there is a lot of stuff to do unrelated to bundling it.
00:22 < provoostenator> gmaxwell: now that we have descriptor support for importmulti, (1) is more doable, but it requires RPC access.
00:22 < gmaxwell> E.g. wumpus' work on a new addr message.
00:23 < gmaxwell> Or getting txn relay to preferentally relay through tor peers, to further frustrate tx forwarding spying.
00:24 < provoostenator> (but with RPC access you're right back to the remote control scenario)
00:25 < provoostenator> I think that as soon as you have trusted connection to your own node, you might as well just use it for everything.
00:25 < provoostenator> Except maybe holding private keys.
00:26 < gmaxwell> right.
00:27 < gmaxwell> using bitcoin-cli over ssh is pretty dandy.   I assume thats what most people in here do, it's just not super gui-enduser friendly. :)
00:28 < provoostenator> Which is where #10102 comes in
00:28 < gribble> https://github.com/bitcoin/bitcoin/issues/10102 | [experimental] Multiprocess bitcoin by ryanofsky · Pull Request #10102 · bitcoin/bitcoin · GitHub
00:29 < provoostenator> With "some" additional modifications, as if that PR isn't big enough, you could just run QT on your phone and have it connect to a node+wallet instance over SSH anywhere.
00:30 < provoostenator> Or you run qt+wallet on the phone and connect to node process over SSH, but that would generate an insane amount of traffic the way the wallet currently scans for relevant transactions.
00:31 < provoostenator> IIUC currently the wallet tells the node "give me everything, I'll figure out what's relevant", rather than "here's what I care about, tell me what's relevant"
00:33 -!- jarthur [~jarthur@2605:6000:1019:41ab:b9e1:cef:8efc:51f6] has joined #bitcoin-core-dev
00:33 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 244 seconds]
00:36 -!- jungly [~quassel@79.8.200.97] has joined #bitcoin-core-dev
00:37 -!- jarthur [~jarthur@2605:6000:1019:41ab:b9e1:cef:8efc:51f6] has quit [Ping timeout: 250 seconds]
00:39 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 246 seconds]
00:39 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
00:39 -!- murrayn [~murrayn@unaffiliated/murrayn] has quit [Ping timeout: 258 seconds]
00:40 -!- murrayn [~murrayn@S0106f8a097f16608.ok.shawcable.net] has joined #bitcoin-core-dev
00:40 -!- murrayn [~murrayn@S0106f8a097f16608.ok.shawcable.net] has quit [Changing host]
00:40 -!- murrayn [~murrayn@unaffiliated/murrayn] has joined #bitcoin-core-dev
00:45 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has joined #bitcoin-core-dev
00:54 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has quit [Quit: notemurtas]
01:01 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has joined #bitcoin-core-dev
01:13 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-mnobvvpqrikjyzve] has joined #bitcoin-core-dev
01:13 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
01:15 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has quit [Quit: Leaving]
01:33 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 250 seconds]
01:34 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev
01:36 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
01:37 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
01:41 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]
01:42 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
01:42 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
01:44 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
01:46 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
01:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:53 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b72c787dc8f7...f5a623eb66c8
01:53 < bitcoin-git> bitcoin/master a083f75 Gregory Maxwell: Update assumevalid, minimumchainwork, and getchaintxstats to height 563378...
01:53 < bitcoin-git> bitcoin/master f5a623e Wladimir J. van der Laan: Merge #15429: Update assumevalid, minimumchainwork, and getchaintxstats to...
01:53 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:54 < bitcoin-git> [bitcoin] laanwj merged pull request #15429: Update assumevalid, minimumchainwork, and getchaintxstats to height 563378 (master...201902-assumevalid) https://github.com/bitcoin/bitcoin/pull/15429
01:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:55 < gmaxwell> Danke.
01:55 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds]
01:56 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
01:57 < gmaxwell> fun fact, the new chainwork is 2x the old chainwork...
01:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:57 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f5a623eb66c8...29e82e460e19
01:57 < bitcoin-git> bitcoin/master 1435fab Pieter Wuille: Use RdSeed when available, and reduce RdRand load
01:57 < bitcoin-git> bitcoin/master 29e82e4 Wladimir J. van der Laan: Merge #15250: Use RdSeed when available, and reduce RdRand load
01:57 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
01:57 < gmaxwell> \O/
01:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
01:58 < bitcoin-git> [bitcoin] laanwj merged pull request #15250: Use RdSeed when available, and reduce RdRand load (master...201901_rdseed) https://github.com/bitcoin/bitcoin/pull/15250
01:58 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:00 < irc_viewer_test> gmaxwell: can you explain what it means for the chainwork to be 2x the old chainwork in simple terms?
02:00 < irc_viewer_test> gmaxwell: 2x more work is being done since when?
02:00 < gmaxwell> since ever
02:01 < gmaxwell> Probably this is not the best channel for stuff that is interesting once converted to simple terms. Some fun facts are only fun to geeks.
02:01 < gmaxwell> :)
02:03 -!- kexkey [~kexkey@87.101.92.74] has quit [Read error: Connection reset by peer]
02:03 < irc_viewer_test> haha
02:03 < irc_viewer_test> :)
02:03 < irc_viewer_test> sorry
02:04 < wumpus> doubled old value would be 0x51045fde384612c6a6b521a ... yep, close enough
02:07 -!- siom [~siom@165.84.231.19] has joined #bitcoin-core-dev
02:24 -!- harding [~quassel@li1258-130.members.linode.com] has quit [Ping timeout: 250 seconds]
02:25 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test]
02:31 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
02:34 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:38 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
02:41 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has joined #bitcoin-core-dev
02:47 -!- harding [~quassel@li1258-130.members.linode.com] has joined #bitcoin-core-dev
03:02 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Remote host closed the connection]
03:02 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
03:08 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
03:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
03:13 < bitcoin-git> [bitcoin] domob1812 opened pull request #15435: Add missing #include (master...fix-include) https://github.com/bitcoin/bitcoin/pull/15435
03:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
03:19 -!- Ethan_ [c4343c35@gateway/web/freenode/ip.196.52.60.53] has joined #bitcoin-core-dev
03:20 < Ethan_> ‪New Crypto Security Concept:‬  Frozen Storage  Much like Cold Storage except coins are sent to a special address with a special prefix on them.  If private key is obtained by attacker who tries to spend them miners refuse to mine transaction from addresses with this prefix for specified time period. (i.e: 3 days give or take).  If a spend is detected by owner of coins they will be able to reverse the spend before the tim
03:20 < Ethan_> In a situation where a standoff occurs a hard fork update can be legally applied for and issued to the miners for a possible small fee to incentivise them to agree to the update.
03:21 < Ethan_> In a situation where a standoff occurs a hard fork update can be legally applied for and issued to the miners for a possible small fee to incentivise them to agree to the update.
03:21 < Ethan_> These hard forks could occur yearly or whenever is suitable to minimise disruptions.
03:21 < Ethan_> The standoff situation would be a rare occurrence as coins located at these addresses are unlikely to be targeted.
03:23 < meshcollider> Ethan_: not the place
03:23 < meshcollider> Try ##altcoin-dev
03:23 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 245 seconds]
03:25 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev
03:25 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has quit [Changing host]
03:25 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
03:26 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
03:26 -!- Ethan_ [c4343c35@gateway/web/freenode/ip.196.52.60.53] has quit [Ping timeout: 256 seconds]
03:27 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
03:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:31 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:32 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 255 seconds]
03:32 < wumpus> what an horrible idea
03:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
03:37 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
03:42 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 250 seconds]
03:42 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has quit [Remote host closed the connection]
03:44 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has joined #bitcoin-core-dev
03:58 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 272 seconds]
04:05 -!- zhangzf [~zhangzf@106.38.157.147] has quit [Remote host closed the connection]
04:08 < cjd> :D
04:16 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
04:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
04:33 -!- notemurtas [~notemurta@athedsl-315681.home.otenet.gr] has quit [Remote host closed the connection]
04:54 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
04:56 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
04:58 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
04:59 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev
05:03 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 246 seconds]
05:06 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev
05:10 -!- crised [~crised@186.67.181.203] has joined #bitcoin-core-dev
05:11 < crised> Where can I learn the basics of bitcoin from developer point of view?
05:16 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]
05:17 -!- shesek [~shesek@141.226.152.217] has joined #bitcoin-core-dev
05:17 -!- shesek [~shesek@141.226.152.217] has quit [Changing host]
05:17 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
05:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:27 -!- zhangzf [~zhangzf@223.72.98.45] has joined #bitcoin-core-dev
05:32 -!- mistergold [~mistergol@77.243.23.30] has joined #bitcoin-core-dev
05:32 -!- mistergold [~mistergol@77.243.23.30] has quit [Client Quit]
05:35 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
05:41 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
05:42 -!- zhangzf [~zhangzf@223.72.98.45] has quit [Remote host closed the connection]
05:43 -!- zhangzf [~zhangzf@223.72.64.114] has joined #bitcoin-core-dev
05:46 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 244 seconds]
05:47 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
05:54 -!- OneFive_ [~OneFive@cpc87991-haye25-2-0-cust817.17-4.cable.virginm.net] has quit [Quit: Leaving]
05:56 -!- OneFive [~OneFive@cpc87991-haye25-2-0-cust817.17-4.cable.virginm.net] has joined #bitcoin-core-dev
06:02 -!- Aaronvan_ is now known as AaronvanW
06:04 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:05 -!- m8tion [~user@2a01:e35:8bef:9310:100c:b6f0:1e34:944d] has joined #bitcoin-core-dev
06:08 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit []
06:11 < instagibbs> crised, #bitcoin-dev or #bitcoin for general development questions
06:17 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
06:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:17 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/29e82e460e19...6ba3f1fdfd88
06:17 < bitcoin-git> bitcoin/master 6aaa0ab Gregory Sanders: Remove manual byte editing in wallet_tx_clone func test
06:17 < bitcoin-git> bitcoin/master 6ba3f1f MarcoFalke: Merge #15397: Remove manual byte editing in wallet_tx_clone func test
06:17 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:18 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15397: Remove manual byte editing in wallet_tx_clone func test (master...wallet_clone_magic) https://github.com/bitcoin/bitcoin/pull/15397
06:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:24 < instagibbs> MarcoFalke, how is Travis letting through Python 3.5 if the .yml requests 3.4? 
06:24 < instagibbs> (too late now, just asking)
06:35 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
06:36 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
06:41 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 246 seconds]
06:43 < luke-jr> wumpus: BIP150/151 solve authentication when they're finally done, but I don't see any better solution for dynamic IPs and NAT traversal (when UPnP/NAT-PMP are unavailable).. at the end of the day, I'm not sure it makes sense to reinvent what already exists
06:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:50 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:52 -!- zhangzf [~zhangzf@223.72.64.114] has quit [Remote host closed the connection]
06:54 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
06:56 < luke-jr> I suppose it could be simpler to add an even more-centralised dynamic DNS/tunnel service, but that seems likely even more controversial :/
06:59 -!- zhangzf [~zhangzf@223.72.74.197] has joined #bitcoin-core-dev
07:01 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
07:02 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev
07:02 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has quit [Changing host]
07:02 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
07:04 -!- zhangzf [~zhangzf@223.72.74.197] has quit [Remote host closed the connection]
07:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:33 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6ba3f1fdfd88...f78cd3dd5115
07:33 < bitcoin-git> bitcoin/master 5b76c31 Carl Dong: doc: Add separate productivity notes document
07:33 < bitcoin-git> bitcoin/master f78cd3d MarcoFalke: Merge #15348: doc: Add separate productivity notes document
07:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
07:34 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15348: doc: Add separate productivity notes document (master...2019-02-productivity-md) https://github.com/bitcoin/bitcoin/pull/15348
07:34 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
07:50 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]
07:52 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:52 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
07:53 -!- kexkey [~kexkey@87.101.92.74] has joined #bitcoin-core-dev
07:53 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
07:56 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev
07:56 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]
07:56 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
08:05 -!- rockhouse1 [~rockhouse@unaffiliated/rockhouse] has quit [Remote host closed the connection]
08:05 -!- victorSN9 [~victorSN@unaffiliated/victorsn] has quit [Remote host closed the connection]
08:09 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
08:10 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev
08:10 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has quit [Changing host]
08:10 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
08:14 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 246 seconds]
08:23 -!- booyah_ [~bb@193.25.1.157] has joined #bitcoin-core-dev
08:24 < MarcoFalke> instagibbs: travis runs the functional tests on ubuntu xenial and bionic, they come with python3.5+
08:24 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]
08:24 < promag> should loadwallet() eventually use gArgs?
08:25 < promag> either that it should use a different args or some flags should be reset after init?
08:26 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 255 seconds]
08:28 -!- kexkey [~kexkey@87.101.92.74] has quit [Ping timeout: 246 seconds]
08:40 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev
08:40 -!- schmidty [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has quit [Changing host]
08:40 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
08:51 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection]
08:53 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
08:54 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
08:58 -!- helo_ is now known as helo
09:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds]
09:02 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
09:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
09:06 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
09:08 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 272 seconds]
09:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]
09:24 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
09:34 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
09:38 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 250 seconds]
09:41 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev
09:43 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
10:04 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 255 seconds]
10:09 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev
10:17 -!- promag [~promag@83.223.249.18] has joined #bitcoin-core-dev
10:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
10:38 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 246 seconds]
10:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:40 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-mnobvvpqrikjyzve] has quit [Quit: Connection closed for inactivity]
10:41 < promag> luke-jr: is #15428 wip or you'd like reviews?
10:41 < gribble> https://github.com/bitcoin/bitcoin/issues/15428 | GUI: Add Pairing tab with Tor onion address as copyable text and QR code by luke-jr · Pull Request #15428 · bitcoin/bitcoin · GitHub
10:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer]
10:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:01 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
11:12 < luke-jr> promag: I guess I need to address the no-wallet issues before code review, but concept review is welcome
11:14 -!- bitcoinEnthusias [bc657b2f@gateway/web/freenode/ip.188.101.123.47] has joined #bitcoin-core-dev
11:14 < achow101> promag: are you working on a create wallet thing for the gui?
11:14 < bitcoinEnthusias> hey folks.... i
11:15 < promag> luke-jr: ok, will look into that
11:15 < promag> achow101: I was going to
11:15 < bitcoinEnthusias> hey folks.... i've got some noob questions concerning btc core development`, just out of interest. is this the right place to ask?
11:15 < jarthur> Probably, unless it's usage help.
11:16 < promag> a dialog, probably a wizard or with a advanced option, idk yet
11:16 < bitcoinEnthusias> is schnorr to be expected to be included in a main release 2019, what is the expected timeframe?
11:16 < promag> achow101: a drawing would be cool
11:16 < promag> achow101: for 0.19 right?
11:16 < achow101> promag: if you haven't started yet, I'll take a stab at it. i need it for the getting rid of default wallet with I'm doing
11:17 < promag> achow101: ah right, start without wallet?
11:17 < achow101> yeah, start without the wallet, but gui users need to be able to make one
11:19 < promag> achow101: ok, btw, what would happen if you always start with -nowallet ?
11:19 < promag> always prompt for "start by creating a wallet?"?
11:19 < luke-jr> bitcoinEnthusias: the next possible opportunity for code to be added is October, and typically softforks are only enabled on minor releases, so I'd give it at least a month after that. it's not impossible, but if you mean activation, I would be very surprised if it was during 2019. I have no particular info on Schnorr specifically, just going from normal processes.
11:20 < achow101> promag: i think so
11:20 < achow101> i don't think nowallet is an alias of disablewallet
11:21 -!- OneFive_ [~OneFive@cpc87991-haye25-2-0-cust817.17-4.cable.virginm.net] has joined #bitcoin-core-dev
11:21 < promag> achow101: -nowallet results in not loading wallets
11:21 < promag> not the same as --disablewallet
11:21 < bitcoinEnthusias> ok. thx. another question, as fees are rising again (i know vulnerable topic): is a blocksize increase completely out of roadmap, or is sth. like this still concidered for later releases? 
11:22 < achow101> promag: right. so nowallet will become the default behavior
11:22 < bitcoinEnthusias> i think fees will rise again heavily if btc gains traction again
11:22 < jarthur> bitcoinEnthusias: on the protocol side, sipa has been organizing a BIP for Schnorr signatures. It hasn't officially been proposed yet, and typically an implementation would follow a proposal. https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki if you want to see the current state. bitcoin-dev mailing list a fine place to discuss the proposal
11:22 < achow101> I'm thinking there's going to be something that saves the last loaded wallet and loads that on following starts
11:24 -!- OneFive [~OneFive@cpc87991-haye25-2-0-cust817.17-4.cable.virginm.net] has quit [Ping timeout: 245 seconds]
11:26 < bitcoinEnthusias> @jarthur ah thx. i wonder why implementation/development is done in pyton and go while core is c++ :)
11:27 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
11:27 < jarthur> bitcoinEnthusias: the BIPs are designed to be readable and reviewable, and Python tends to work well for that.
11:27 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
11:27 < bitcoinEnthusias> i see
11:28 < bitcoinEnthusias> thx for the explanation
11:28 < luke-jr> bitcoinEnthusias: the only thing up for discussion at this time is a reduction in block sizes; take this topic to #bitcoin if you want to continue it
11:28 < bitcoinEnthusias> erm.... reduction?
11:28 < bitcoinEnthusias> ok
11:30 < bitcoinEnthusias> thx for the answers!
11:31 < gmaxwell> luke-jr: I am beside myself at what appears to be straight up malicious misinformation from you.
11:32 < gmaxwell> luke-jr: The only ongoing active thread on the mailing list is the discussion around segwit v1 schnorr signatures. Your absurd blocksize reduction proposal has never been even posted there.
11:32 < gmaxwell> Meanwhile there is a finished and widely reviewed bip on the schnorr signature scheme.
11:33 < luke-jr> gmaxwell: It's not clear to me what you're disagreeing with.
11:33 < gmaxwell> It's difficult for me to imagine how your answer to bitcoinEnthusias could have been _more_ misleading.
11:34 < gmaxwell> luke-jr: he asked about the status of some work, instead of telling him the status, you said the "the only thing up for discussion at this time is a reduction in block sizes"
11:34 < luke-jr> gmaxwell: he asked if it could be expected during 2019, so I gave an answer; then he asked about increasing block sizes, so I pointed out that was the opposite of what we needed
11:35 < luke-jr> if you don't think my answers went into enough detail, feel free to elaborate
11:35 < luke-jr> if you positively disagree with them, please be more specific
11:38 < gmaxwell> I don't agree that any reduction of block sizes is "up for discussion" in bitcoin core development. Quite the opposite: You have already been privately censured for creating drama in the press for annoucing some absurd reduction fait accompli when you hadn't even brought the subject up with other developers.
11:41 < luke-jr> nonsense. nothing has been announced, and it has been brought up, even though it's probably still too premature to make any serious action on. unlike increasing block sizes which is completely out of the question, there is an actual possibility of block size reduction (even if you think that possibility is small).
11:43 < luke-jr> ironically, you're now saying it's not up for discussion, and at the same time condemning that it supposed hasn't been brought up for discussion!
11:44 < luke-jr> kinda self-contradicting there
11:47 < gmaxwell> I'm saying your response is absurdly deceptive.  You say that the signature stuff isn't happening in 2019, yet there is one completed BIP and a lot of discussion but then say that a reduction is the only thing "up for discussion" when it hasn't in fact been discussed (other than people privately WTFing you when we heard about it for the first time via false claims that this project was working 
11:47 < gmaxwell> on it in the press).
11:47 -!- bitcoinEnthusias [bc657b2f@gateway/web/freenode/ip.188.101.123.47] has quit [Quit: Page closed]
11:49 < luke-jr> gmaxwell: do you expect Schnorr in 2019? what about my statement on that was unreasonable?
11:49 < luke-jr> the topic of block size is a separate question, I don't know how you're mixing the two questions together
11:50 < luke-jr> and I'm sure if I dig through logs I can find at least two discussions as counter-examples
11:51 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Excess Flood]
11:51 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has joined #bitcoin-core-dev
11:52 < gmaxwell> luke-jr: no idea, but it's radically ahead of any reduction proposal which as far as I can tell is agressively not supported by major contributors to this project.
11:52 < luke-jr> gmaxwell: great, I don't see how my answers would suggest otherwise.
11:53 < sipa> i think both of these things are offtopic here; proposals should be complete and discussed in the wider development space before they can be considered for inclusion in core
11:56 < BlueMatt> (and very clearly neither has that level of support, so, seriously, stop spreading misinformation luke-jr)
11:58 -!- jarthur_ [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
12:00 < luke-jr> never claimed any level of support; no misinformation has been cited
12:00 < gmaxwell> You are also responsible for the reasonable and expected beliefs your statements create, not just the fine rules lawyer reading of the words.
12:01 -!- promag [~promag@83.223.249.18] has quit [Remote host closed the connection]
12:01 < luke-jr> if you want to criticise what I actually said, fine, but making up strawmen is a waste of time
12:01 -!- jarthur [~jarthur@207.114.244.5] has quit [Ping timeout: 255 seconds]
12:01 < gmaxwell> If you don't want to be yelled at for misinforming people, then when someone asks about active proposal X don't respond that it'll be a long time then suggest your hardly discussed hobby horse in a way that makes it sound more present and realistic.
12:02 < gmaxwell> I'm critizing the result, which you are responsible for.
12:02 < gmaxwell> You can't make carefully worded statements that mislead people and expect to not recieve complaint.
12:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:03 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #15437: p2p: Remove remote debugging code (master...Mf1809-noBip61) https://github.com/bitcoin/bitcoin/pull/15437
12:03 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:04 -!- crised [~crised@186.67.181.203] has quit [Remote host closed the connection]
12:08 -!- promag [~promag@83.223.249.18] has joined #bitcoin-core-dev
12:12 -!- promag [~promag@83.223.249.18] has quit [Ping timeout: 258 seconds]
12:16 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
12:20 -!- Jaamg [jaamg@kapsi.fi] has joined #bitcoin-core-dev
12:23 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
12:25 -!- jarthur_ is now known as jarthur
12:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds]
12:26 -!- kexkey [~kexkey@87.101.92.74] has joined #bitcoin-core-dev
12:27 -!- timothy [~tredaelli@redhat/timothy] has quit [Remote host closed the connection]
12:32 -!- savil [savilmatri@gateway/shell/matrix.org/x-hexmgyhwerhbdauc] has quit [Quit: removing from IRC because user idle on matrix for 30+ days]
12:36 -!- jarthur [~jarthur@207.114.244.5] has quit [Remote host closed the connection]
12:37 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
12:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:39 < bitcoin-git> [bitcoin] MeshCollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f78cd3dd5115...904308dca3ff
12:39 < bitcoin-git> bitcoin/master 0bedcba Jonas Schnelli: Use a single wallet batch for UpgradeKeyMetadata
12:39 < bitcoin-git> bitcoin/master 904308d MeshCollider: Merge #15433: Use a single wallet batch for UpgradeKeyMetadata
12:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:40 < bitcoin-git> [bitcoin] MeshCollider merged pull request #15433: Use a single wallet batch for UpgradeKeyMetadata (master...2019/02/wallet_key_upgrade_batch) https://github.com/bitcoin/bitcoin/pull/15433
12:40 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:42 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
12:52 -!- OneFive_ [~OneFive@cpc87991-haye25-2-0-cust817.17-4.cable.virginm.net] has quit [Quit: Leaving]
13:02 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
13:10 < luke-jr> gmaxwell: I'm sorry that I was unclear, but I assure you it was not malice or carefully worded (I guess the lack of carefully wording is the real problem); what I meant was that *with regard to block size*, the only thing worth considering was a reduction - it wasn't intended to berate or address the earlier question about schnorr at all (and I would have expected from the context that was clear, but I guess not)
13:11 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Remote host closed the connection]
13:12 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
13:13 -!- palfun [4da54cc2@gateway/web/freenode/ip.77.165.76.194] has joined #bitcoin-core-dev
13:14 < palfun> hey folks
13:16 < palfun> what's the deal with the rpc wallet interfaces? I don't want to use node-side wallets, but it seems all nice affordances (ie "get unspent outputs") are only available on a per-wallet basis, rather than per-arbitrary-address
13:16 < achow101> palfun: doing things per arbitrary address is expensive and most people don't care about that
13:17 < palfun> isn't that how you implement clients/wallet software though?
13:17 < sipa> no
13:17 < palfun> or am I thinking about that the wrong way?
13:17 < sipa> i mean, you can
13:17 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 268 seconds]
13:18 < sipa> but it requires a fully indexed blockchain on the server
13:18 < sipa> (and then trusting that server to do it right)
13:18 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
13:18 < achow101> palfun: no. wallet software typically just scan the blockchain for things that pertain to that wallet. to have everything per arbitrary address means that you are maintaining a lot of extra data for addresses that you don't care about
13:18 < palfun> ah right, that makes sense
13:19 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Read error: Connection reset by peer]
13:19 < palfun> wait, but, then how do bip32 wallet clients work? they need to scan large amounts of addresses for outputs/transaction history right?
13:19 < sipa> they go through history
13:19 < sipa> once, for all addresses combimed
13:20 < sipa> and only the part of the chain after the address was created
13:21 < palfun> "go through history" here meaning "look at *all* blocks, see if any transactions include one of our addresses", right?
13:21 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.3]
13:22 < sipa> yes
13:22 < palfun> and I guess they then just keep an eye out for new blocks and write them down whenever "one of our addresses" is involved, like some sort of specialized light client
13:22 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:23 < palfun> is that really the best way to do wallet software, assuming you want to just hook up with rpc to an arbitrary node? that's... somewhat painful, you have to "catch up" constantly
13:23 < sipa> bip37 allows client-side filtering (it has severe privacy concerns, and is not advised), or client-side filtering (bip157, which is still new)
13:24 < luke-jr> you mean server-side for BIP37, right?
13:24 < sipa> oops, yes
13:24 < sipa> bip37 is server side filtering
13:25 < sipa> palfun: it's only way to be sure you're not being lied to
13:25 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
13:25 < sipa> it's certainly not efficien
13:25 < sipa> *t
13:26 < palfun> ah cool, filters! but that's on the node protocol level, not the rpc one, right?
13:26 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
13:26 < sipa> right
13:26 < palfun> I had imagined it'd be possible to "just like implement simple wallet software" by calling out over rpc, but that's starting to seem... impractical
13:26 < sipa> yes
13:27 < luke-jr> palfun: you could use something like Electrum Personal Server (I think? never used it myself) to build the indexes you want, but there are scalability concerns to relying on this
13:27 < sipa> and privacy
13:27 < luke-jr> palfun: you can implement simple wallet software still, check out importaddress
13:27 < luke-jr> sipa: well, if you use your own Electrum server, it should be fine for privacy, no?
13:28 < palfun> luke-jr: I'd rather not put private keys onto nodes, I know people feel bad about doing that. I'm really looking to just support the simplest case of "I have a node, now let me hook a wallet up"
13:28 < luke-jr> palfun: importaddress doesn't require the private key
13:28 < luke-jr> it just tells the node to track the address in question
13:28 < luke-jr> (and the key backing said address)
13:29 < palfun> ohh I see, so it just does the indexing for you, giving you the read-benefits of a fully in-node wallet
13:29 < luke-jr> yes
13:29 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Ping timeout: 245 seconds]
13:30 < palfun> so for the bip32 case, you'd just feed it your first 20 addresses, see what turns up, and then proceed as appropriate
13:31 < palfun> cool, I'll have to play around with this! I bet I'll be back for more questions once I get to actually wrangling inputs/outputs into transactions (^:
13:31 < palfun> thanks luke-jr , sipa !
13:32 < belcher> read the source code of Electrum Personal Server because it does all that with rpc, so could be useful
13:32 < luke-jr> palfun: well, you ideally want to track from the creation of the wallet; rescanning is slow and doesn't work with pruned nodes
13:33 < luke-jr> belcher: oh, EPS doesn't actually build a full index?
13:33 < palfun> belcher: I thought Electrum used their own nodes for indexing etc? but that still goes over rpc? interesting, will take a look
13:33 < belcher> luke-jr nope
13:33 < luke-jr> belcher: interesting, good to know
13:33 < belcher> its a wrapper around bitcoin core's wallet that speaks the electrum server protocol, so it has no extra indexes and is compatible with pruning etc
13:34 < luke-jr> belcher: does that mean it doesn't get your wallet's history?
13:34 < belcher> palfun there are many electrum server implementations, the one which builds all the indexes is called ElectrumX and its much more complicated
13:34 < belcher> luke-jr it does, bitcoin core's wallet has the history
13:34 < luke-jr> maybe we should take this to #bitcoin
13:34 < palfun> luke-jr: right, so importing "used" bip32 wallets will be slow to detect all previous usage. does that still get done automatically, do I kick that off, or do it manually?
13:35  * palfun should probably not care about the "import wallet" case
13:35 < luke-jr> palfun: there's various RPC options
13:36 < palfun> I've pulled up the docs now, I see it can do rescans yeah
13:39 < palfun> cool, this seems fairly doable again. thanks! (:
13:39 -!- mmgen [~mmgen@gateway/tor-sasl/mmgen] has quit [Quit: (https://github.com/mmgen) leaving]
13:42 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
13:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 246 seconds]
13:53 < palfun> is there a practical difference between importaddress and importpubkey? docs recommend using the latter if you can, but I'm not sure I understand why
13:56 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
13:58 < luke-jr> palfun: IIRC (but my memory is fuzzy on this), there are some features missing with just importaddress, but I forget what
14:00 < palfun> looks like importmulti is probably preferable in most real-world cases anyway?
14:00 < palfun> is it just me or is the documentation around these things a bit shallow? perhaps idk where to look
14:18 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 250 seconds]
14:22 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:22 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev
14:26 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
14:27 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
14:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds]
14:57 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
15:03 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
15:05 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: Textual IRC Client: www.textualapp.com]
15:15 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
15:15 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
15:19 -!- zhangzf [~zhangzf@223.72.55.70] has joined #bitcoin-core-dev
15:23 -!- zhangzf [~zhangzf@223.72.55.70] has quit [Remote host closed the connection]
15:24 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-dev
15:33 -!- v8c9X [~v8C16x3R@178.138.35.113] has joined #bitcoin-core-dev
15:38 -!- siom [~siom@165.84.231.19] has quit [Remote host closed the connection]
15:53 < meshcollider> palfun: youre probably right, the importing RPCs (esp importmulti) have had quite a few changes recently so not a great deal of documentation exists at the moment I guess
15:58 -!- jarthur_ [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
15:59 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 255 seconds]
16:02 -!- jarthur [~jarthur@207.114.244.5] has quit [Ping timeout: 246 seconds]
16:03 -!- jarthur_ [~jarthur@207.114.244.5] has quit [Ping timeout: 240 seconds]
16:11 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
16:16 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 258 seconds]
16:24 -!- shesek [~shesek@141.226.217.238] has joined #bitcoin-core-dev
16:24 -!- shesek [~shesek@141.226.217.238] has quit [Changing host]
16:24 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
16:33 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
16:33 -!- kexkey [~kexkey@87.101.92.74] has quit [Quit: Scaling pentatonically]
16:37 -!- audvonslack [~androirc@82.84.31.212] has joined #bitcoin-core-dev
16:38 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 246 seconds]
17:20 -!- zhangzf [~zhangzf@106.38.157.147] has joined #bitcoin-core-dev
17:23 -!- audvonslack [~androirc@82.84.31.212] has quit [Remote host closed the connection]
17:24 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
17:31 -!- IGHOR [~quassel@93.178.216.72] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.]
17:34 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev
17:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
17:46 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
17:51 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 245 seconds]
18:06 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
18:07 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit []
18:11 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 258 seconds]
18:14 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
18:19 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 250 seconds]
18:22 -!- m8tion [~user@2a01:e35:8bef:9310:100c:b6f0:1e34:944d] has quit [Remote host closed the connection]
18:25 < midnightmagic> ˆ/w 3
18:41 < sipa> agree.
18:43 < midnightmagic> :-)
18:49 -!- Madars [~null@unaffiliated/madars] has quit [Read error: Connection reset by peer]
19:10 -!- Madars [~null@unaffiliated/madars] has joined #bitcoin-core-dev
19:40 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl]
20:03 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3]
20:12 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
20:15 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
20:17 -!- kexkey [~kexkey@87.101.92.74] has joined #bitcoin-core-dev
20:24 -!- kexkey [~kexkey@87.101.92.74] has quit [Ping timeout: 246 seconds]
20:41 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
20:44 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
21:08 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 245 seconds]
21:15 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has quit [Remote host closed the connection]
22:11 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has quit [Quit: pinheadmz]
22:13 -!- pinheadmz [~matthewzi@c-76-102-227-220.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:26 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Ping timeout: 245 seconds]
23:05 -!- schmidty [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev
23:06 -!- ap4lmtree [ap4lmtree@unaffiliated/ap4lmtree] has joined #bitcoin-core-dev
23:15 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has joined #bitcoin-core-dev
23:24 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Ping timeout: 246 seconds]
23:30 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev
23:32 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
23:35 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
23:43 < provoostenator> promag: regarding create wallet UI, I created a really professional mockup :-) See slide 7-10: https://github.com/Sjors/presentations/blob/master/2019-02-08%20London%20-%20Advancing%20Bitcoin/2019-02%20London%20Advancing%20Bitcoin.pdf 
23:45 < provoostenator> Tl&dr it would be nice to have a dialog for wallet creation which check boxes for what we have now, i.e. "watch-only" and "blank", so that we can later expand that.
23:47 < provoostenator> In addition I think the same or a similar dialog can be used to recover wallets. Could be loading a wallet dump file, entering some descriptors or even bip39 phrases.
23:48 < provoostenator> Such a recovery also needs some room, e.g. we would could ask the earliest usage day for rescan purposes. We could even ask if the user knows a few random addresses, so we can guess the derivation paths, but that might be a bit too fancy. 
23:50 < provoostenator> For using existing hardware wallets I imagine the HWI scripts will give hints of what derivation paths to use, so the UI doesn't have to. Maybe some devices even know what date they were initialized.
23:52 -!- MyNickName6390 [d41a1bf9@gateway/web/freenode/ip.212.26.27.249] has joined #bitcoin-core-dev
23:53 -!- MyNickName6390 [d41a1bf9@gateway/web/freenode/ip.212.26.27.249] has quit [Client Quit]
23:53 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 255 seconds]
23:56 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
--- Log closed Tue Feb 19 00:00:53 2019