12019-02-18T00:16:53 *** Dean_Guss has joined #bitcoin-core-dev
22019-02-18T00:18:40 *** schmidty has joined #bitcoin-core-dev
32019-02-18T00:22:04 *** pinheadmz has quit IRC
42019-02-18T00:23:40 *** schmidty has quit IRC
52019-02-18T00:28:52 *** pinheadmz has joined #bitcoin-core-dev
62019-02-18T00:32:48 *** ap4lmtree has quit IRC
72019-02-18T00:39:15 *** ap4lmtree has joined #bitcoin-core-dev
82019-02-18T00:44:00 *** spinza has quit IRC
92019-02-18T00:52:56 *** pinheadmz has quit IRC
102019-02-18T01:09:05 *** spinza has joined #bitcoin-core-dev
112019-02-18T01:10:12 *** Zenton has quit IRC
122019-02-18T01:15:55 *** zivl has joined #bitcoin-core-dev
132019-02-18T01:18:51 *** zhangzf has joined #bitcoin-core-dev
142019-02-18T01:23:29 *** Karyon has quit IRC
152019-02-18T01:24:01 *** rh0nj has quit IRC
162019-02-18T01:25:07 *** rh0nj has joined #bitcoin-core-dev
172019-02-18T01:29:43 *** schmidty has joined #bitcoin-core-dev
182019-02-18T01:34:27 *** schmidty has quit IRC
192019-02-18T01:34:53 *** dviola has quit IRC
202019-02-18T01:42:30 *** schmidty has joined #bitcoin-core-dev
212019-02-18T01:47:08 *** schmidty has quit IRC
222019-02-18T01:57:11 *** justanotheruser has joined #bitcoin-core-dev
232019-02-18T01:58:49 *** Karyon has joined #bitcoin-core-dev
242019-02-18T01:58:57 *** promag has quit IRC
252019-02-18T02:30:04 *** justanotheruser has quit IRC
262019-02-18T02:50:50 *** schmidty has joined #bitcoin-core-dev
272019-02-18T02:55:28 *** schmidty has quit IRC
282019-02-18T02:56:24 *** drexl has quit IRC
292019-02-18T03:00:14 <gmaxwell> luke-jr: as a compromise to your tor bundling thing-- what about the idea just of a seperate bundled download being available?
302019-02-18T03:00:57 <gmaxwell> Seems to me that would have some of the advantage without most of the downsides... and would help make a case for doing it more broadly?
312019-02-18T03:02:51 <echeveria> gmaxwell: I'm uncomfortable with increasing the number of people using Tor. as you pointed out the attack surface is greatly increased versus running bitcoind. depending how its configured this will result in people listening who wouldn't otherwise expect it.
322019-02-18T03:03:25 <echeveria> if the purpose *isn't* to listen on a HS by default, there's no increase in listening sockets. if it's the default configured this way, people will be listening when they never expected to be able to.
332019-02-18T03:04:15 <echeveria> if it requires configuration to have it listening, why bundle it at all?
342019-02-18T03:06:07 <echeveria> echo "apt install tor" > ./setup_hs.sh; chmod +x setup_hs.sh
352019-02-18T03:06:10 <echeveria> magic.
362019-02-18T03:09:15 *** StopAndDecrypt has quit IRC
372019-02-18T03:12:52 *** pinheadmz has joined #bitcoin-core-dev
382019-02-18T03:20:10 *** justanotheruser has joined #bitcoin-core-dev
392019-02-18T03:21:12 <gmaxwell> echeveria: bitcoind listens by default, if you want it not to listen you have to turn it off...
402019-02-18T03:21:45 <echeveria> gmaxwell: yeah, but most people are behind NAT at least on their home networks.
412019-02-18T03:22:02 <echeveria> so actually listening without configuration would be a surprise
422019-02-18T03:22:58 <gmaxwell> echeveria: like most other p2p software until two years ago bitcoind used upnp to automatically enable incoming connections.
432019-02-18T03:23:11 <gmaxwell> it only stopped because of the non-stop CVEs in the upnp software.
442019-02-18T03:24:16 <echeveria> gmaxwell: that's been gone for like, 2, 3 years right?
452019-02-18T03:25:42 <gmaxwell> yes, and its been a disaster that it's gone-- the end result is a massive shift towards listeners on VPSes, god knows what percentage of them are spys&sybils.
462019-02-18T03:28:09 <echeveria> I acknowledge there's been a shift in where peers are, but supplementing them with even more trivially sybil attacked HS peers is if anything more harmful.
472019-02-18T03:29:12 <gmaxwell> Adding more honest peers does not make any of that worse.
482019-02-18T03:30:02 <echeveria> if you're never making outgoing connections over Tor or HS, yeah.
492019-02-18T03:31:38 <echeveria> if the quality of peers on the network is a concern, perhaps the raise from 5 outgoing peers to 8 was too conservative. if the concern is the number, or availability of listening sockets, then there's probably a bit more of an engineering challenge there.
502019-02-18T03:32:52 <echeveria> (I've mentioned it before, but I'd like to see a separate "headers only" socket which you make as many connections to as possible, even hundreds of peers- but when I looked into actually doing that the engineering involved was ridiculous)
512019-02-18T03:33:57 <gmaxwell> echeveria: we'll soon be able to realistically handle many times the current number of peers with little cost.
522019-02-18T03:34:01 <gmaxwell> not just limited to headers.
532019-02-18T03:34:11 <gmaxwell> (well 'soon' relatively speaking)
542019-02-18T03:34:42 <echeveria> from using select()?
552019-02-18T03:34:52 <gmaxwell> no though we don't use select anymore.
562019-02-18T03:35:11 <gmaxwell> right now having more peers is a problem because of the extreme amount of bandwidth wasted by txn rumoring.
572019-02-18T03:35:28 <gmaxwell> but that'll be largely eliminated.
582019-02-18T03:41:28 <echeveria> right.
592019-02-18T03:42:10 <echeveria> I'm not saying peer quality isn't a concern, to be clear. there's lots which I can identify as crappy, which means there's a lot more that I'm not most likely.
602019-02-18T03:42:43 *** pinheadmz has quit IRC
612019-02-18T03:46:47 *** StopAndDecrypt has joined #bitcoin-core-dev
622019-02-18T03:52:36 *** bitcoin-git has joined #bitcoin-core-dev
632019-02-18T03:52:36 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #15433: Use a single wallet batch for UpgradeKeyMetadata (master...2019/02/wallet_key_upgrade_batch) https://github.com/bitcoin/bitcoin/pull/15433
642019-02-18T03:52:40 *** bitcoin-git has left #bitcoin-core-dev
652019-02-18T03:54:23 <aj> oh, whatever happened to supporting nat-pmp?
662019-02-18T03:54:54 <gmaxwell> sounds like a great idea. No one has done it.
672019-02-18T03:55:15 <aj> https://github.com/bitcoin/bitcoin/pull/12288 <-- there was a pr a while ago
682019-02-18T03:56:40 <echeveria> gmaxwell: perhaps ipv6 will save all.
692019-02-18T03:58:24 <gmaxwell> aj: ah, well-- see the history there.
702019-02-18T03:58:55 <gmaxwell> (I'm not quite sure it why it was subtreeing a library for a protocol that consists of "send a struct with a few fields filled out to the network", but there you go)
712019-02-18T04:00:48 <aj> getting the info to populate the fields is OS specific iirc, so using the library saves redoing all the windows/mac/linux code
722019-02-18T04:07:08 *** Karyon has quit IRC
732019-02-18T04:08:48 <gmaxwell> IIRC you need your local port and address, and such, which we already have.
742019-02-18T04:09:04 <gmaxwell> (as we need to stuff it into addr messages)
752019-02-18T04:11:34 <aj> hmm, i think you need the gw address too?
762019-02-18T04:12:33 <aj> ah, nat-pmp tells you your local port, but you need the gw address to send the query in the first place
772019-02-18T04:12:43 <aj> local addr, not local port
782019-02-18T04:13:21 <aj> ugh, not local addr, it tells you your external ipv4 address
792019-02-18T04:14:05 <gmaxwell> yes, it tells you the external info.
802019-02-18T04:15:01 <aj> but yeah, it's https://github.com/miniupnp/libnatpmp/blob/master/getgateway.c that's most of the code
812019-02-18T04:16:25 *** pinheadmz has joined #bitcoin-core-dev
822019-02-18T04:16:26 <gmaxwell> fair enough.
832019-02-18T04:18:36 <gmaxwell> aj: some context, the reason we don't have upnp anymore is that the miniupnp library's code which can only be described as obviously frightening. (XML parsing with a mixture C string functions and raw pointer throbbing, clearly written by someone whos never had their hand burned by doing that before), so I can only imagine that no one was really excited about taking a huge ball of code from
842019-02-18T04:18:36 <gmaxwell> miniupnp.
852019-02-18T04:19:23 <gmaxwell> perhaps the natpmp code is a lot better, no idea.
862019-02-18T04:19:26 <aj> yeah
872019-02-18T04:19:41 <aj> well, there's no xml which already counts as a lot better to me, but... yeah
882019-02-18T04:19:49 <gmaxwell> absolutely.
892019-02-18T04:26:14 *** DeanWeen has joined #bitcoin-core-dev
902019-02-18T04:26:15 *** DeanWeen has quit IRC
912019-02-18T04:26:34 *** DeanWeen has joined #bitcoin-core-dev
922019-02-18T04:28:37 *** Dean_Guss has quit IRC
932019-02-18T04:32:52 *** jarthur has joined #bitcoin-core-dev
942019-02-18T04:37:11 *** jarthur has quit IRC
952019-02-18T04:38:13 *** pinheadmz has quit IRC
962019-02-18T04:51:50 *** schmidty has joined #bitcoin-core-dev
972019-02-18T04:54:30 *** justanotheruser has quit IRC
982019-02-18T04:59:28 *** justanotheruser has joined #bitcoin-core-dev
992019-02-18T05:10:34 *** promag has joined #bitcoin-core-dev
1002019-02-18T05:14:23 *** rhavar has quit IRC
1012019-02-18T05:14:48 *** promag has quit IRC
1022019-02-18T05:43:23 *** schmidty has quit IRC
1032019-02-18T06:01:40 *** pinheadmz has joined #bitcoin-core-dev
1042019-02-18T06:04:40 *** OneFive has joined #bitcoin-core-dev
1052019-02-18T06:05:59 *** OneFive_ has joined #bitcoin-core-dev
1062019-02-18T06:09:41 *** OneFive has quit IRC
1072019-02-18T06:40:52 *** pinheadmz has quit IRC
1082019-02-18T06:48:31 <wumpus> luke-jr | wumpus: why would tor be illegal? <- because authoritarian politicians don't like it, probably because in unstable countries it has sometimes be used to plan uprisings and such, as in Egypt
1092019-02-18T06:49:23 <wumpus> (someone from Egypt once told me you could get in trouble for running Tor there, I don't know if it's still true, but where human lives are at stake it's kind of important to be careful)
1102019-02-18T06:49:37 *** lnostdal has quit IRC
1112019-02-18T06:51:34 <wumpus> and yes, some vps definitely kick you off for running tor, I've had to explain quite a few times I'm not running an exit node
1122019-02-18T06:52:22 *** lnostdal has joined #bitcoin-core-dev
1132019-02-18T07:02:35 *** StopAndDecrypt has quit IRC
1142019-02-18T07:03:17 <wumpus> also I've always believed the way forward would be to improve the bitcoin protocol itself; BIP150/151, Dandelion, as well as lightning onion routing
1152019-02-18T07:03:54 <wumpus> back in 2012 I'd probably have agreed with you to integrate Tor, but it seems overkill now
1162019-02-18T07:04:14 <wumpus> a heavy-handed, noisy measure
1172019-02-18T07:09:14 <wumpus> but yes as gmaxwell already says, it could be a separate bundle people could choose to download, I'm fine with that, but not as only option
1182019-02-18T07:10:38 <wumpus> and yes natpmp support would be good, who is going to pick up #12288 ?
1192019-02-18T07:10:40 <gribble> https://github.com/bitcoin/bitcoin/issues/12288 | [WIP][NET] Add NATPMP support. by annanay25 · Pull Request #12288 · bitcoin/bitcoin · GitHub
1202019-02-18T07:11:20 *** promag has joined #bitcoin-core-dev
1212019-02-18T07:14:52 <gmaxwell> probably tor usage provides the most value when part of the network does it...
1222019-02-18T07:15:53 *** promag has quit IRC
1232019-02-18T07:17:12 <wumpus> gmaxwell: how do you mean? you mean having tor part of the network code?
1242019-02-18T07:19:07 <wumpus> ohh I get it now, sorry
1252019-02-18T07:19:38 <wumpus> yes, I think even in general it's good to have part of the network on different transports
1262019-02-18T07:19:55 <wumpus> which reminds me I should pick up my new address message BIP again
1272019-02-18T07:20:47 <wumpus> c.f. https://gist.github.com/laanwj/4fe8470881d7b9499eedc48dc9ef1ad1
1282019-02-18T07:22:44 <gmaxwell> oops yep, thats it.-- effectively having seperate network topologies means that to knock everything out an attacker has to hit all of them.
1292019-02-18T07:39:11 *** promag has joined #bitcoin-core-dev
1302019-02-18T07:40:00 *** promag has quit IRC
1312019-02-18T07:40:12 *** promag has joined #bitcoin-core-dev
1322019-02-18T07:40:25 *** schmidty has joined #bitcoin-core-dev
1332019-02-18T07:43:02 *** promag has quit IRC
1342019-02-18T07:43:52 *** pinheadmz has joined #bitcoin-core-dev
1352019-02-18T07:57:04 <provoostenator> Tor hidden services avoid the need for true inbound connections. We could try to do something similar? Somehow have peers introduce eachother. Or does require keeping that introducing node in the loop?
1362019-02-18T08:00:26 <wumpus> I'm not sure I understand; doesn't one of the nodes have to be listening for the other to connect to it?
1372019-02-18T08:01:18 <wumpus> whether the nodes are on clearnet, tor, i2p, or another overlay network doesn't change that
1382019-02-18T08:01:27 <gmaxwell> provoostenator: not really.
1392019-02-18T08:02:34 <provoostenator> How does Tor avoid this problem?
1402019-02-18T08:02:50 <wumpus> they use relays and onion routing
1412019-02-18T08:03:49 <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.
1422019-02-18T08:04:29 <provoostenator> So who's doing the listening? A smaller number of tor nodes?
1432019-02-18T08:04:33 <wumpus> yes, exactly, they're indirectly connected through relays
1442019-02-18T08:04:55 <wumpus> routing your traffic over a relay would make zero sense for the bitcoin protocol as all the data is public
1452019-02-18T08:05:20 <wumpus> well okay there's the onion routing proposal for transactions, but besides that
1462019-02-18T08:05:33 <provoostenator> It could make sense for authentical (RPC like) stuff, which is what Luke was trying to solve.
1472019-02-18T08:05:40 <provoostenator> But it seems a bit heavy.
1482019-02-18T08:06:47 <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.
1492019-02-18T08:06:56 <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.
1502019-02-18T08:06:58 <wumpus> ( I mean, blocks and transactions *themselves* are relayed, there's no need to relay/bounce at the TCP level)
1512019-02-18T08:07:36 <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
1522019-02-18T08:07:47 <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.
1532019-02-18T08:08:29 <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.
1542019-02-18T08:08:38 <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.
1552019-02-18T08:08:42 <echeveria> (an eighth of the listening IPV4 nodes also have 8332 exposed, btw)
1562019-02-18T08:08:45 <wumpus> that's valid idea but it has nothing at all with bitoin P2P anymore
1572019-02-18T08:09:20 <provoostenator> wumpus: I tend to agree that remote control is a more generic internet problem that can be solved outside of Bitcoin.
1582019-02-18T08:09:21 <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)
1592019-02-18T08:09:39 <wumpus> remote control over bitcoin P2P? what?
1602019-02-18T08:09:43 <wumpus> i need coffee
1612019-02-18T08:09:52 <echeveria> gmaxwell: just have some central neutrino repo that you can add your own signatures to. done.
1622019-02-18T08:10:18 <gmaxwell> echeveria: right.
1632019-02-18T08:10:19 <echeveria> gmaxwell: block_header, signatures[]
1642019-02-18T08:10:25 <wumpus> provoostenator: definitely
1652019-02-18T08:10:42 <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.
1662019-02-18T08:11:15 <wumpus> r;
1672019-02-18T08:11:18 <provoostenator> That's on one extreme of light-weightness, you could do something more hybrid like gmaxwell says where the phone does more work.
1682019-02-18T08:11:21 <wumpus> provoostenator: so electrum, basically
1692019-02-18T08:11:29 <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.
1702019-02-18T08:11:41 <gmaxwell> echeveria: stop.
1712019-02-18T08:11:47 <gmaxwell> echeveria: wumpus already said we're not doing that.
1722019-02-18T08:11:51 <gmaxwell> you don't need to repeat.
1732019-02-18T08:11:52 <gmaxwell> Case made.
1742019-02-18T08:11:56 <echeveria> fine.
1752019-02-18T08:11:58 <gmaxwell> :)
1762019-02-18T08:12:15 <echeveria> sorry, this was mentioned to me out of band today as well.
1772019-02-18T08:12:36 <echeveria> I'd definitely like to see things like more p2p transports, don't let me detract from that.
1782019-02-18T08:13:34 <provoostenator> Funny how #11902 is tagged as "good first issue"
1792019-02-18T08:13:35 <gribble> https://github.com/bitcoin/bitcoin/issues/11902 | NAT-PMP port forwarding support · Issue #11902 · bitcoin/bitcoin · GitHub
1802019-02-18T08:13:39 <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"?
1812019-02-18T08:13:49 <gmaxwell> provoostenator: it is because you don't need to know essentially anything about bitcoin.
1822019-02-18T08:13:58 <gmaxwell> (something about _networking_ sure. :) )
1832019-02-18T08:14:22 <gmaxwell> good first issue doesn't mean good for newbies to development or something like that. :)
1842019-02-18T08:14:58 <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 :-)
1852019-02-18T08:15:23 *** mmgen has joined #bitcoin-core-dev
1862019-02-18T08:15:40 *** promag has joined #bitcoin-core-dev
1872019-02-18T08:15:59 <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.
1882019-02-18T08:16:06 <gmaxwell> Tor happens to solve (2) and (3).
1892019-02-18T08:16:15 <gmaxwell> though it's a blunt instrument.
1902019-02-18T08:17:55 <provoostenator> BIP 151 solves (3), but not (2).
1912019-02-18T08:19:31 <gmaxwell> technically BIP150 (or whatever replaces it... sipa and I really need to finish that)
1922019-02-18T08:20:04 *** promag has quit IRC
1932019-02-18T08:20:10 <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.
1942019-02-18T08:21:10 <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.
1952019-02-18T08:21:22 <provoostenator> Agreed, the combination of PMP/UPNP and ~BIP150 seems a more precise tool for this job.
1962019-02-18T08:22:36 <gmaxwell> Also if people want to improve things with tor there is a lot of stuff to do unrelated to bundling it.
1972019-02-18T08:22:37 <provoostenator> gmaxwell: now that we have descriptor support for importmulti, (1) is more doable, but it requires RPC access.
1982019-02-18T08:22:45 <gmaxwell> E.g. wumpus' work on a new addr message.
1992019-02-18T08:23:10 <gmaxwell> Or getting txn relay to preferentally relay through tor peers, to further frustrate tx forwarding spying.
2002019-02-18T08:24:32 <provoostenator> (but with RPC access you're right back to the remote control scenario)
2012019-02-18T08:25:10 <provoostenator> I think that as soon as you have trusted connection to your own node, you might as well just use it for everything.
2022019-02-18T08:25:27 <provoostenator> Except maybe holding private keys.
2032019-02-18T08:26:42 <gmaxwell> right.
2042019-02-18T08:27:21 <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. :)
2052019-02-18T08:28:37 <provoostenator> Which is where #10102 comes in
2062019-02-18T08:28:41 <gribble> https://github.com/bitcoin/bitcoin/issues/10102 | [experimental] Multiprocess bitcoin by ryanofsky · Pull Request #10102 · bitcoin/bitcoin · GitHub
2072019-02-18T08:29:45 <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.
2082019-02-18T08:30:51 <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.
2092019-02-18T08:31:53 <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"
2102019-02-18T08:33:19 *** jarthur has joined #bitcoin-core-dev
2112019-02-18T08:33:39 *** schmidty has quit IRC
2122019-02-18T08:36:58 *** jungly has joined #bitcoin-core-dev
2132019-02-18T08:37:27 *** jarthur has quit IRC
2142019-02-18T08:39:12 *** jb55 has quit IRC
2152019-02-18T08:39:52 *** jb55 has joined #bitcoin-core-dev
2162019-02-18T08:39:57 *** murrayn has quit IRC
2172019-02-18T08:40:40 *** murrayn has joined #bitcoin-core-dev
2182019-02-18T08:40:40 *** murrayn has joined #bitcoin-core-dev
2192019-02-18T08:45:15 *** notemurtas has joined #bitcoin-core-dev
2202019-02-18T08:54:13 *** notemurtas has quit IRC
2212019-02-18T09:01:09 *** notemurtas has joined #bitcoin-core-dev
2222019-02-18T09:13:20 *** elichai2 has joined #bitcoin-core-dev
2232019-02-18T09:13:22 *** timothy has joined #bitcoin-core-dev
2242019-02-18T09:15:50 *** notemurtas has quit IRC
2252019-02-18T09:33:18 *** jcorgan has quit IRC
2262019-02-18T09:34:28 *** irc_viewer_test has joined #bitcoin-core-dev
2272019-02-18T09:36:03 *** setpill has joined #bitcoin-core-dev
2282019-02-18T09:37:41 *** promag has joined #bitcoin-core-dev
2292019-02-18T09:41:58 *** promag has quit IRC
2302019-02-18T09:42:04 *** EagleTM has joined #bitcoin-core-dev
2312019-02-18T09:42:58 *** EagleTM has quit IRC
2322019-02-18T09:44:17 *** EagleTM has joined #bitcoin-core-dev
2332019-02-18T09:46:14 *** Zenton has joined #bitcoin-core-dev
2342019-02-18T09:53:54 *** bitcoin-git has joined #bitcoin-core-dev
2352019-02-18T09:53:54 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b72c787dc8f7...f5a623eb66c8
2362019-02-18T09:53:54 <bitcoin-git> bitcoin/master a083f75 Gregory Maxwell: Update assumevalid, minimumchainwork, and getchaintxstats to height 563378...
2372019-02-18T09:53:54 <bitcoin-git> bitcoin/master f5a623e Wladimir J. van der Laan: Merge #15429: Update assumevalid, minimumchainwork, and getchaintxstats to...
2382019-02-18T09:53:55 *** bitcoin-git has left #bitcoin-core-dev
2392019-02-18T09:54:45 *** bitcoin-git has joined #bitcoin-core-dev
2402019-02-18T09:54:45 <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
2412019-02-18T09:54:49 *** bitcoin-git has left #bitcoin-core-dev
2422019-02-18T09:55:09 <gmaxwell> Danke.
2432019-02-18T09:55:24 *** EagleTM has quit IRC
2442019-02-18T09:56:19 *** promag has joined #bitcoin-core-dev
2452019-02-18T09:57:05 <gmaxwell> fun fact, the new chainwork is 2x the old chainwork...
2462019-02-18T09:57:19 *** bitcoin-git has joined #bitcoin-core-dev
2472019-02-18T09:57:19 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f5a623eb66c8...29e82e460e19
2482019-02-18T09:57:20 <bitcoin-git> bitcoin/master 1435fab Pieter Wuille: Use RdSeed when available, and reduce RdRand load
2492019-02-18T09:57:21 <bitcoin-git> bitcoin/master 29e82e4 Wladimir J. van der Laan: Merge #15250: Use RdSeed when available, and reduce RdRand load
2502019-02-18T09:57:22 *** bitcoin-git has left #bitcoin-core-dev
2512019-02-18T09:57:25 <gmaxwell> \O/
2522019-02-18T09:58:00 *** bitcoin-git has joined #bitcoin-core-dev
2532019-02-18T09:58:00 <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
2542019-02-18T09:58:04 *** bitcoin-git has left #bitcoin-core-dev
2552019-02-18T10:00:32 <irc_viewer_test> gmaxwell: can you explain what it means for the chainwork to be 2x the old chainwork in simple terms?
2562019-02-18T10:00:45 <irc_viewer_test> gmaxwell: 2x more work is being done since when?
2572019-02-18T10:00:51 <gmaxwell> since ever
2582019-02-18T10:01:48 <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.
2592019-02-18T10:01:50 <gmaxwell> :)
2602019-02-18T10:03:25 *** kexkey has quit IRC
2612019-02-18T10:03:34 <irc_viewer_test> haha
2622019-02-18T10:03:37 <irc_viewer_test> :)
2632019-02-18T10:03:58 <irc_viewer_test> sorry
2642019-02-18T10:04:07 <wumpus> doubled old value would be 0x51045fde384612c6a6b521a ... yep, close enough
2652019-02-18T10:07:11 *** siom has joined #bitcoin-core-dev
2662019-02-18T10:24:52 *** harding has quit IRC
2672019-02-18T10:25:02 *** irc_viewer_test has quit IRC
2682019-02-18T10:31:05 *** schmidty has joined #bitcoin-core-dev
2692019-02-18T10:34:14 *** Guyver2 has joined #bitcoin-core-dev
2702019-02-18T10:38:23 *** spinza has quit IRC
2712019-02-18T10:41:52 *** notemurtas has joined #bitcoin-core-dev
2722019-02-18T10:47:07 *** harding has joined #bitcoin-core-dev
2732019-02-18T11:02:25 *** ap4lmtree has quit IRC
2742019-02-18T11:02:45 *** ap4lmtree has joined #bitcoin-core-dev
2752019-02-18T11:08:50 *** spinza has joined #bitcoin-core-dev
2762019-02-18T11:13:34 *** bitcoin-git has joined #bitcoin-core-dev
2772019-02-18T11:13:34 <bitcoin-git> [bitcoin] domob1812 opened pull request #15435: Add missing #include (master...fix-include) https://github.com/bitcoin/bitcoin/pull/15435
2782019-02-18T11:13:35 *** bitcoin-git has left #bitcoin-core-dev
2792019-02-18T11:19:14 *** Ethan_ has joined #bitcoin-core-dev
2802019-02-18T11:20:34 <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
2812019-02-18T11:20:58 <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.
2822019-02-18T11:21:16 <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.
2832019-02-18T11:21:31 <Ethan_> These hard forks could occur yearly or whenever is suitable to minimise disruptions.
2842019-02-18T11:21:57 <Ethan_> The standoff situation would be a rare occurrence as coins located at these addresses are unlikely to be targeted.
2852019-02-18T11:23:04 <meshcollider> Ethan_: not the place
2862019-02-18T11:23:16 <meshcollider> Try ##altcoin-dev
2872019-02-18T11:23:23 *** schmidty has quit IRC
2882019-02-18T11:25:09 *** schmidty has joined #bitcoin-core-dev
2892019-02-18T11:25:10 *** schmidty has joined #bitcoin-core-dev
2902019-02-18T11:26:19 *** Ethan_ has quit IRC
2912019-02-18T11:27:25 *** schmidty has joined #bitcoin-core-dev
2922019-02-18T11:29:14 *** AaronvanW has joined #bitcoin-core-dev
2932019-02-18T11:31:11 *** Aaronvan_ has joined #bitcoin-core-dev
2942019-02-18T11:32:08 *** schmidty has quit IRC
2952019-02-18T11:32:25 <wumpus> what an horrible idea
2962019-02-18T11:34:38 *** AaronvanW has quit IRC
2972019-02-18T11:37:26 *** schmidty has joined #bitcoin-core-dev
2982019-02-18T11:42:00 *** schmidty has quit IRC
2992019-02-18T11:42:10 *** notemurtas has quit IRC
3002019-02-18T11:44:24 *** notemurtas has joined #bitcoin-core-dev
3012019-02-18T11:58:48 *** shesek has quit IRC
3022019-02-18T12:05:42 *** zhangzf has quit IRC
3032019-02-18T12:08:47 <cjd> :D
3042019-02-18T12:16:54 *** schmidty has joined #bitcoin-core-dev
3052019-02-18T12:31:21 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3062019-02-18T12:33:25 *** notemurtas has quit IRC
3072019-02-18T12:54:21 *** promag has quit IRC
3082019-02-18T12:56:36 *** fanquake has joined #bitcoin-core-dev
3092019-02-18T12:58:05 *** Chris_Stewart_5 has quit IRC
3102019-02-18T12:59:18 *** promag has joined #bitcoin-core-dev
3112019-02-18T13:03:27 *** schmidty has quit IRC
3122019-02-18T13:06:57 *** drexl has joined #bitcoin-core-dev
3132019-02-18T13:10:28 *** crised has joined #bitcoin-core-dev
3142019-02-18T13:11:12 <crised> Where can I learn the basics of bitcoin from developer point of view?
3152019-02-18T13:16:12 *** promag has quit IRC
3162019-02-18T13:17:59 *** shesek has joined #bitcoin-core-dev
3172019-02-18T13:17:59 *** shesek has joined #bitcoin-core-dev
3182019-02-18T13:22:01 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3192019-02-18T13:27:06 *** zhangzf has joined #bitcoin-core-dev
3202019-02-18T13:32:09 *** mistergold has joined #bitcoin-core-dev
3212019-02-18T13:35:26 *** Chris_Stewart_5 has quit IRC
3222019-02-18T13:41:56 *** schmidty has joined #bitcoin-core-dev
3232019-02-18T13:42:58 *** zhangzf has quit IRC
3242019-02-18T13:43:34 *** zhangzf has joined #bitcoin-core-dev
3252019-02-18T13:46:14 *** schmidty has quit IRC
3262019-02-18T13:47:25 *** Guyver2 has quit IRC
3272019-02-18T13:54:48 *** OneFive_ has quit IRC
3282019-02-18T13:56:55 *** OneFive has joined #bitcoin-core-dev
3292019-02-18T14:02:01 *** Aaronvan_ is now known as AaronvanW
3302019-02-18T14:04:14 *** Guyver2 has joined #bitcoin-core-dev
3312019-02-18T14:05:34 *** m8tion has joined #bitcoin-core-dev
3322019-02-18T14:08:40 *** fanquake has quit IRC
3332019-02-18T14:11:47 <instagibbs> crised, #bitcoin-dev or #bitcoin for general development questions
3342019-02-18T14:17:36 *** promag has joined #bitcoin-core-dev
3352019-02-18T14:17:39 *** bitcoin-git has joined #bitcoin-core-dev
3362019-02-18T14:17:40 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/29e82e460e19...6ba3f1fdfd88
3372019-02-18T14:17:40 <bitcoin-git> bitcoin/master 6aaa0ab Gregory Sanders: Remove manual byte editing in wallet_tx_clone func test
3382019-02-18T14:17:41 <bitcoin-git> bitcoin/master 6ba3f1f MarcoFalke: Merge #15397: Remove manual byte editing in wallet_tx_clone func test
3392019-02-18T14:17:42 *** bitcoin-git has left #bitcoin-core-dev
3402019-02-18T14:18:27 *** bitcoin-git has joined #bitcoin-core-dev
3412019-02-18T14:18:27 <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
3422019-02-18T14:18:28 *** bitcoin-git has left #bitcoin-core-dev
3432019-02-18T14:24:23 <instagibbs> MarcoFalke, how is Travis letting through Python 3.5 if the .yml requests 3.4?
3442019-02-18T14:24:30 <instagibbs> (too late now, just asking)
3452019-02-18T14:35:31 *** cryptapus has quit IRC
3462019-02-18T14:36:29 *** schmidty has joined #bitcoin-core-dev
3472019-02-18T14:41:06 *** schmidty has quit IRC
3482019-02-18T14:43:10 <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
3492019-02-18T14:49:48 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3502019-02-18T14:50:47 *** cryptapus has joined #bitcoin-core-dev
3512019-02-18T14:52:02 *** zhangzf has quit IRC
3522019-02-18T14:54:43 *** spinza has quit IRC
3532019-02-18T14:56:31 <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 :/
3542019-02-18T14:59:13 *** zhangzf has joined #bitcoin-core-dev
3552019-02-18T15:01:22 *** spinza has joined #bitcoin-core-dev
3562019-02-18T15:02:21 *** schmidty has joined #bitcoin-core-dev
3572019-02-18T15:02:21 *** schmidty has joined #bitcoin-core-dev
3582019-02-18T15:04:46 *** zhangzf has quit IRC
3592019-02-18T15:33:50 *** bitcoin-git has joined #bitcoin-core-dev
3602019-02-18T15:33:51 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6ba3f1fdfd88...f78cd3dd5115
3612019-02-18T15:33:51 <bitcoin-git> bitcoin/master 5b76c31 Carl Dong: doc: Add separate productivity notes document
3622019-02-18T15:33:52 <bitcoin-git> bitcoin/master f78cd3d MarcoFalke: Merge #15348: doc: Add separate productivity notes document
3632019-02-18T15:33:54 *** bitcoin-git has left #bitcoin-core-dev
3642019-02-18T15:34:36 *** bitcoin-git has joined #bitcoin-core-dev
3652019-02-18T15:34:36 <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
3662019-02-18T15:34:47 *** bitcoin-git has left #bitcoin-core-dev
3672019-02-18T15:50:33 *** cryptapus has quit IRC
3682019-02-18T15:52:48 *** pinheadmz has joined #bitcoin-core-dev
3692019-02-18T15:52:59 *** EagleTM has joined #bitcoin-core-dev
3702019-02-18T15:53:04 *** kexkey has joined #bitcoin-core-dev
3712019-02-18T15:53:50 *** setpill has quit IRC
3722019-02-18T15:56:29 *** cryptapus has joined #bitcoin-core-dev
3732019-02-18T15:56:29 *** cryptapus has quit IRC
3742019-02-18T15:56:29 *** cryptapus has joined #bitcoin-core-dev
3752019-02-18T16:05:01 *** rockhouse1 has quit IRC
3762019-02-18T16:05:01 *** victorSN9 has quit IRC
3772019-02-18T16:09:24 *** schmidty has quit IRC
3782019-02-18T16:10:00 *** schmidty has joined #bitcoin-core-dev
3792019-02-18T16:10:00 *** schmidty has joined #bitcoin-core-dev
3802019-02-18T16:14:32 *** schmidty has quit IRC
3812019-02-18T16:23:55 *** booyah_ has joined #bitcoin-core-dev
3822019-02-18T16:24:05 <MarcoFalke> instagibbs: travis runs the functional tests on ubuntu xenial and bionic, they come with python3.5+
3832019-02-18T16:24:05 *** booyah has quit IRC
3842019-02-18T16:24:34 <promag> should loadwallet() eventually use gArgs?
3852019-02-18T16:25:16 <promag> either that it should use a different args or some flags should be reset after init?
3862019-02-18T16:26:26 *** EagleTM has quit IRC
3872019-02-18T16:28:19 *** kexkey has quit IRC
3882019-02-18T16:40:00 *** schmidty has joined #bitcoin-core-dev
3892019-02-18T16:40:00 *** schmidty has joined #bitcoin-core-dev
3902019-02-18T16:51:11 *** jungly has quit IRC
3912019-02-18T16:53:56 *** schmidty has quit IRC
3922019-02-18T16:54:59 *** promag has quit IRC
3932019-02-18T16:58:01 *** helo_ is now known as helo
3942019-02-18T17:02:40 *** AaronvanW has quit IRC
3952019-02-18T17:02:57 *** schmidty has joined #bitcoin-core-dev
3962019-02-18T17:04:06 *** AaronvanW has joined #bitcoin-core-dev
3972019-02-18T17:06:30 *** Aaronvan_ has joined #bitcoin-core-dev
3982019-02-18T17:08:30 *** schmidty has quit IRC
3992019-02-18T17:09:38 *** AaronvanW has quit IRC
4002019-02-18T17:24:50 *** schmidty has joined #bitcoin-core-dev
4012019-02-18T17:34:12 *** jarthur has joined #bitcoin-core-dev
4022019-02-18T17:38:38 *** owowo has quit IRC
4032019-02-18T17:41:20 *** fabianfabian has joined #bitcoin-core-dev
4042019-02-18T17:43:45 *** owowo has joined #bitcoin-core-dev
4052019-02-18T18:04:32 *** schmidty has quit IRC
4062019-02-18T18:09:54 *** StopAndDecrypt has joined #bitcoin-core-dev
4072019-02-18T18:17:45 *** promag has joined #bitcoin-core-dev
4082019-02-18T18:23:16 *** Chris_Stewart_5 has quit IRC
4092019-02-18T18:38:31 *** Zenton has quit IRC
4102019-02-18T18:38:48 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4112019-02-18T18:40:11 *** elichai2 has quit IRC
4122019-02-18T18:41:56 <promag> luke-jr: is #15428 wip or you'd like reviews?
4132019-02-18T18:41:57 <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
4142019-02-18T18:53:10 *** Chris_Stewart_5 has quit IRC
4152019-02-18T18:56:31 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4162019-02-18T19:01:35 *** schmidty has joined #bitcoin-core-dev
4172019-02-18T19:12:12 <luke-jr> promag: I guess I need to address the no-wallet issues before code review, but concept review is welcome
4182019-02-18T19:14:25 *** bitcoinEnthusias has joined #bitcoin-core-dev
4192019-02-18T19:14:39 <achow101> promag: are you working on a create wallet thing for the gui?
4202019-02-18T19:14:42 <bitcoinEnthusias> hey folks.... i
4212019-02-18T19:15:09 <promag> luke-jr: ok, will look into that
4222019-02-18T19:15:15 <promag> achow101: I was going to
4232019-02-18T19:15:37 <bitcoinEnthusias> hey folks.... i've got some noob questions concerning btc core development`, just out of interest. is this the right place to ask?
4242019-02-18T19:15:58 <jarthur> Probably, unless it's usage help.
4252019-02-18T19:16:02 <promag> a dialog, probably a wizard or with a advanced option, idk yet
4262019-02-18T19:16:32 <bitcoinEnthusias> is schnorr to be expected to be included in a main release 2019, what is the expected timeframe?
4272019-02-18T19:16:33 <promag> achow101: a drawing would be cool
4282019-02-18T19:16:54 <promag> achow101: for 0.19 right?
4292019-02-18T19:16:56 <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
4302019-02-18T19:17:19 <promag> achow101: ah right, start without wallet?
4312019-02-18T19:17:42 <achow101> yeah, start without the wallet, but gui users need to be able to make one
4322019-02-18T19:19:06 <promag> achow101: ok, btw, what would happen if you always start with -nowallet ?
4332019-02-18T19:19:43 <promag> always prompt for "start by creating a wallet?"?
4342019-02-18T19:19:51 <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.
4352019-02-18T19:20:02 <achow101> promag: i think so
4362019-02-18T19:20:18 <achow101> i don't think nowallet is an alias of disablewallet
4372019-02-18T19:21:04 *** OneFive_ has joined #bitcoin-core-dev
4382019-02-18T19:21:36 <promag> achow101: -nowallet results in not loading wallets
4392019-02-18T19:21:50 <promag> not the same as --disablewallet
4402019-02-18T19:21:57 <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?
4412019-02-18T19:22:14 <achow101> promag: right. so nowallet will become the default behavior
4422019-02-18T19:22:54 <bitcoinEnthusias> i think fees will rise again heavily if btc gains traction again
4432019-02-18T19:22:57 <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
4442019-02-18T19:22:58 <achow101> I'm thinking there's going to be something that saves the last loaded wallet and loads that on following starts
4452019-02-18T19:24:38 *** OneFive has quit IRC
4462019-02-18T19:26:18 <bitcoinEnthusias> @jarthur ah thx. i wonder why implementation/development is done in pyton and go while core is c++ :)
4472019-02-18T19:27:03 *** schmidty has quit IRC
4482019-02-18T19:27:05 <jarthur> bitcoinEnthusias: the BIPs are designed to be readable and reviewable, and Python tends to work well for that.
4492019-02-18T19:27:20 *** schmidty has joined #bitcoin-core-dev
4502019-02-18T19:27:32 <bitcoinEnthusias> i see
4512019-02-18T19:28:07 <bitcoinEnthusias> thx for the explanation
4522019-02-18T19:28:13 <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
4532019-02-18T19:28:29 <bitcoinEnthusias> erm.... reduction?
4542019-02-18T19:28:35 <bitcoinEnthusias> ok
4552019-02-18T19:30:36 <bitcoinEnthusias> thx for the answers!
4562019-02-18T19:31:47 <gmaxwell> luke-jr: I am beside myself at what appears to be straight up malicious misinformation from you.
4572019-02-18T19:32:34 <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.
4582019-02-18T19:32:58 <gmaxwell> Meanwhile there is a finished and widely reviewed bip on the schnorr signature scheme.
4592019-02-18T19:33:23 <luke-jr> gmaxwell: It's not clear to me what you're disagreeing with.
4602019-02-18T19:33:32 <gmaxwell> It's difficult for me to imagine how your answer to bitcoinEnthusias could have been _more_ misleading.
4612019-02-18T19:34:08 <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"
4622019-02-18T19:34:42 <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
4632019-02-18T19:35:28 <luke-jr> if you don't think my answers went into enough detail, feel free to elaborate
4642019-02-18T19:35:44 <luke-jr> if you positively disagree with them, please be more specific
4652019-02-18T19:38:25 <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.
4662019-02-18T19:41:34 <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).
4672019-02-18T19:43:53 <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!
4682019-02-18T19:44:00 <luke-jr> kinda self-contradicting there
4692019-02-18T19:47:13 <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
4702019-02-18T19:47:14 <gmaxwell> on it in the press).
4712019-02-18T19:47:27 *** bitcoinEnthusias has quit IRC
4722019-02-18T19:49:05 <luke-jr> gmaxwell: do you expect Schnorr in 2019? what about my statement on that was unreasonable?
4732019-02-18T19:49:31 <luke-jr> the topic of block size is a separate question, I don't know how you're mixing the two questions together
4742019-02-18T19:50:23 <luke-jr> and I'm sure if I dig through logs I can find at least two discussions as counter-examples
4752019-02-18T19:51:18 *** Skirmant has quit IRC
4762019-02-18T19:51:36 *** Skirmant has joined #bitcoin-core-dev
4772019-02-18T19:52:08 <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.
4782019-02-18T19:52:33 <luke-jr> gmaxwell: great, I don't see how my answers would suggest otherwise.
4792019-02-18T19:53:05 <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
4802019-02-18T19:56:46 <BlueMatt> (and very clearly neither has that level of support, so, seriously, stop spreading misinformation luke-jr)
4812019-02-18T19:58:08 *** jarthur_ has joined #bitcoin-core-dev
4822019-02-18T20:00:17 <luke-jr> never claimed any level of support; no misinformation has been cited
4832019-02-18T20:00:56 <gmaxwell> You are also responsible for the reasonable and expected beliefs your statements create, not just the fine rules lawyer reading of the words.
4842019-02-18T20:01:10 *** promag has quit IRC
4852019-02-18T20:01:21 <luke-jr> if you want to criticise what I actually said, fine, but making up strawmen is a waste of time
4862019-02-18T20:01:32 *** jarthur has quit IRC
4872019-02-18T20:01:48 <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.
4882019-02-18T20:02:04 <gmaxwell> I'm critizing the result, which you are responsible for.
4892019-02-18T20:02:55 <gmaxwell> You can't make carefully worded statements that mislead people and expect to not recieve complaint.
4902019-02-18T20:03:19 *** bitcoin-git has joined #bitcoin-core-dev
4912019-02-18T20:03:19 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15437: p2p: Remove remote debugging code (master...Mf1809-noBip61) https://github.com/bitcoin/bitcoin/pull/15437
4922019-02-18T20:03:20 *** bitcoin-git has left #bitcoin-core-dev
4932019-02-18T20:04:11 *** crised has quit IRC
4942019-02-18T20:08:15 *** promag has joined #bitcoin-core-dev
4952019-02-18T20:12:38 *** promag has quit IRC
4962019-02-18T20:16:44 *** schmidty has quit IRC
4972019-02-18T20:20:24 *** Jaamg has joined #bitcoin-core-dev
4982019-02-18T20:23:32 *** schmidty has joined #bitcoin-core-dev
4992019-02-18T20:25:35 *** jarthur_ is now known as jarthur
5002019-02-18T20:25:43 *** DeanWeen has quit IRC
5012019-02-18T20:26:16 *** kexkey has joined #bitcoin-core-dev
5022019-02-18T20:27:02 *** timothy has quit IRC
5032019-02-18T20:32:46 *** savil has quit IRC
5042019-02-18T20:36:51 *** jarthur has quit IRC
5052019-02-18T20:37:19 *** jarthur has joined #bitcoin-core-dev
5062019-02-18T20:39:39 *** bitcoin-git has joined #bitcoin-core-dev
5072019-02-18T20:39:39 <bitcoin-git> [bitcoin] MeshCollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f78cd3dd5115...904308dca3ff
5082019-02-18T20:39:39 <bitcoin-git> bitcoin/master 0bedcba Jonas Schnelli: Use a single wallet batch for UpgradeKeyMetadata
5092019-02-18T20:39:40 <bitcoin-git> bitcoin/master 904308d MeshCollider: Merge #15433: Use a single wallet batch for UpgradeKeyMetadata
5102019-02-18T20:39:51 *** bitcoin-git has left #bitcoin-core-dev
5112019-02-18T20:40:24 *** bitcoin-git has joined #bitcoin-core-dev
5122019-02-18T20:40:25 <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
5132019-02-18T20:40:25 *** bitcoin-git has left #bitcoin-core-dev
5142019-02-18T20:42:06 *** pinheadmz has quit IRC
5152019-02-18T20:52:44 *** OneFive_ has quit IRC
5162019-02-18T21:02:25 *** pinheadmz has joined #bitcoin-core-dev
5172019-02-18T21:10:59 <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)
5182019-02-18T21:11:48 *** schmidty has quit IRC
5192019-02-18T21:12:32 *** schmidty has joined #bitcoin-core-dev
5202019-02-18T21:13:54 *** palfun has joined #bitcoin-core-dev
5212019-02-18T21:14:19 <palfun> hey folks
5222019-02-18T21:16:07 <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
5232019-02-18T21:16:51 <achow101> palfun: doing things per arbitrary address is expensive and most people don't care about that
5242019-02-18T21:17:30 <palfun> isn't that how you implement clients/wallet software though?
5252019-02-18T21:17:35 <sipa> no
5262019-02-18T21:17:36 <palfun> or am I thinking about that the wrong way?
5272019-02-18T21:17:43 <sipa> i mean, you can
5282019-02-18T21:17:58 *** schmidty has quit IRC
5292019-02-18T21:18:11 <sipa> but it requires a fully indexed blockchain on the server
5302019-02-18T21:18:27 <sipa> (and then trusting that server to do it right)
5312019-02-18T21:18:39 *** Zenton has joined #bitcoin-core-dev
5322019-02-18T21:18:40 <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
5332019-02-18T21:18:43 <palfun> ah right, that makes sense
5342019-02-18T21:19:11 *** ap4lmtree has quit IRC
5352019-02-18T21:19:14 <palfun> wait, but, then how do bip32 wallet clients work? they need to scan large amounts of addresses for outputs/transaction history right?
5362019-02-18T21:19:40 <sipa> they go through history
5372019-02-18T21:19:58 <sipa> once, for all addresses combimed
5382019-02-18T21:20:30 <sipa> and only the part of the chain after the address was created
5392019-02-18T21:21:12 <palfun> "go through history" here meaning "look at *all* blocks, see if any transactions include one of our addresses", right?
5402019-02-18T21:21:47 *** jb55 has quit IRC
5412019-02-18T21:21:59 <sipa> yes
5422019-02-18T21:22:00 <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
5432019-02-18T21:22:28 *** Guyver2 has quit IRC
5442019-02-18T21:23:13 <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
5452019-02-18T21:23:26 <sipa> bip37 allows client-side filtering (it has severe privacy concerns, and is not advised), or client-side filtering (bip157, which is still new)
5462019-02-18T21:24:29 <luke-jr> you mean server-side for BIP37, right?
5472019-02-18T21:24:42 <sipa> oops, yes
5482019-02-18T21:24:50 <sipa> bip37 is server side filtering
5492019-02-18T21:25:05 <sipa> palfun: it's only way to be sure you're not being lied to
5502019-02-18T21:25:20 *** promag has joined #bitcoin-core-dev
5512019-02-18T21:25:27 <sipa> it's certainly not efficien
5522019-02-18T21:25:28 <sipa> *t
5532019-02-18T21:26:01 <palfun> ah cool, filters! but that's on the node protocol level, not the rpc one, right?
5542019-02-18T21:26:18 *** jb55 has joined #bitcoin-core-dev
5552019-02-18T21:26:31 <sipa> right
5562019-02-18T21:26:48 <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
5572019-02-18T21:26:56 <sipa> yes
5582019-02-18T21:27:01 <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
5592019-02-18T21:27:11 <sipa> and privacy
5602019-02-18T21:27:18 <luke-jr> palfun: you can implement simple wallet software still, check out importaddress
5612019-02-18T21:27:32 <luke-jr> sipa: well, if you use your own Electrum server, it should be fine for privacy, no?
5622019-02-18T21:28:12 <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"
5632019-02-18T21:28:31 <luke-jr> palfun: importaddress doesn't require the private key
5642019-02-18T21:28:43 <luke-jr> it just tells the node to track the address in question
5652019-02-18T21:28:55 <luke-jr> (and the key backing said address)
5662019-02-18T21:29:15 <palfun> ohh I see, so it just does the indexing for you, giving you the read-benefits of a fully in-node wallet
5672019-02-18T21:29:24 <luke-jr> yes
5682019-02-18T21:29:38 *** promag has quit IRC
5692019-02-18T21:30:26 <palfun> so for the bip32 case, you'd just feed it your first 20 addresses, see what turns up, and then proceed as appropriate
5702019-02-18T21:31:43 <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 (^:
5712019-02-18T21:31:54 <palfun> thanks luke-jr , sipa !
5722019-02-18T21:32:12 <belcher> read the source code of Electrum Personal Server because it does all that with rpc, so could be useful
5732019-02-18T21:32:34 <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
5742019-02-18T21:33:02 <luke-jr> belcher: oh, EPS doesn't actually build a full index?
5752019-02-18T21:33:06 <palfun> belcher: I thought Electrum used their own nodes for indexing etc? but that still goes over rpc? interesting, will take a look
5762019-02-18T21:33:10 <belcher> luke-jr nope
5772019-02-18T21:33:28 <luke-jr> belcher: interesting, good to know
5782019-02-18T21:33:30 <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
5792019-02-18T21:34:16 <luke-jr> belcher: does that mean it doesn't get your wallet's history?
5802019-02-18T21:34:18 <belcher> palfun there are many electrum server implementations, the one which builds all the indexes is called ElectrumX and its much more complicated
5812019-02-18T21:34:26 <belcher> luke-jr it does, bitcoin core's wallet has the history
5822019-02-18T21:34:26 <luke-jr> maybe we should take this to #bitcoin
5832019-02-18T21:34:53 <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?
5842019-02-18T21:35:04 * palfun should probably not care about the "import wallet" case
5852019-02-18T21:35:29 <luke-jr> palfun: there's various RPC options
5862019-02-18T21:36:34 <palfun> I've pulled up the docs now, I see it can do rescans yeah
5872019-02-18T21:39:24 <palfun> cool, this seems fairly doable again. thanks! (:
5882019-02-18T21:39:58 *** mmgen has quit IRC
5892019-02-18T21:42:46 *** schmidty has joined #bitcoin-core-dev
5902019-02-18T21:45:04 *** shesek has quit IRC
5912019-02-18T21:53:58 <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
5922019-02-18T21:56:27 *** ap4lmtree has joined #bitcoin-core-dev
5932019-02-18T21:58:05 <luke-jr> palfun: IIRC (but my memory is fuzzy on this), there are some features missing with just importaddress, but I forget what
5942019-02-18T22:00:00 <palfun> looks like importmulti is probably preferable in most real-world cases anyway?
5952019-02-18T22:00:19 <palfun> is it just me or is the documentation around these things a bit shallow? perhaps idk where to look
5962019-02-18T22:18:08 *** schmidty has quit IRC
5972019-02-18T22:22:05 *** fabianfabian has quit IRC
5982019-02-18T22:22:56 *** fabianfabian has joined #bitcoin-core-dev
5992019-02-18T22:26:17 *** pinheadmz has quit IRC
6002019-02-18T22:27:05 *** pinheadmz has joined #bitcoin-core-dev
6012019-02-18T22:30:29 *** Chris_Stewart_5 has quit IRC
6022019-02-18T22:57:55 *** spinza has quit IRC
6032019-02-18T23:03:49 *** spinza has joined #bitcoin-core-dev
6042019-02-18T23:05:07 *** fabianfabian has quit IRC
6052019-02-18T23:15:30 *** schmidty has joined #bitcoin-core-dev
6062019-02-18T23:15:40 *** dviola has joined #bitcoin-core-dev
6072019-02-18T23:19:59 *** zhangzf has joined #bitcoin-core-dev
6082019-02-18T23:23:46 *** zhangzf has quit IRC
6092019-02-18T23:24:25 *** DeanWeen has joined #bitcoin-core-dev
6102019-02-18T23:33:09 *** v8c9X has joined #bitcoin-core-dev
6112019-02-18T23:38:34 *** siom has quit IRC
6122019-02-18T23:53:57 <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
6132019-02-18T23:58:43 *** jarthur_ has joined #bitcoin-core-dev
6142019-02-18T23:59:08 *** schmidty has quit IRC