1 2015-04-29 00:00:27 <phantomcircuit> michagogo, it's like physicals
2 2015-04-29 00:00:31 <phantomcircuit> assume a spherical cow
3 2015-04-29 00:00:47 <michagogo> Assume a what?
4 2015-04-29 00:01:09 <michagogo> ;;Google spherical cow
5 2015-04-29 00:01:09 <moa> he's not talking about your girlfriend
6 2015-04-29 00:01:10 <gribble> Spherical cow - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Spherical_cow>; spherical cow: a simple model: <http://www.physics.csbsju.edu/stats/WAPP2_cow.html>; What is up with the spherical cow? | WIRED: <http://www.wired.com/2011/02/what-is-up-with-the-spherical-cow/>
7 2015-04-29 00:01:29 <phantomcircuit> physics*
8 2015-04-29 00:01:30 <phantomcircuit> derp
9 2015-04-29 00:26:07 <phantomcircuit> sipa, ha dropping the dbcache size completely switched to io bound even with large blocks
10 2015-04-29 01:53:37 <Luke-Jr> ACTION wonders if the XOR'd DNS seed stuff has been tested/designed to work with DNS servers that filter non-WAN IP ranges
11 2015-04-29 04:35:22 <gmaxwell> Luke-Jr: at some point I'd suggested xoring only the last three octets.
12 2015-04-29 04:35:33 <gmaxwell> which would likely be enough generally.
13 2015-04-29 06:19:22 <jonasschnelli> Luke-Jr: i'm now working on a filter for private ranges after rfc6890
14 2015-04-29 06:20:16 <jonasschnelli> but maybe gmaxwell's proposal to only xor the last three octs would be sufficient.
15 2015-04-29 06:21:26 <jonasschnelli> xoring only the last tree octets could still xor a ip to a reserved range like (100.64.0.0/10)
16 2015-04-29 06:21:35 <jonasschnelli> or 169.254.0.0/16
17 2015-04-29 07:01:25 <wumpus> it appears DNS isn't a good seeding mechanism if obfuscation is desirable
18 2015-04-29 07:01:52 <wumpus> well maybe DNS - but another record type? so it's not interpreted at all by intermediates?
19 2015-04-29 07:03:27 <wumpus> 'encoding to non-blacklisted data of the same size' seems an impossible challenge, given that the blacklists are an unknown in the first place, this all seems kind of dirty and uncertain
20 2015-04-29 07:27:30 <jonasschnelli> wumpus: right. IMO the xored response is a failover mechanism.
21 2015-04-29 07:27:52 <wumpus> but why not use another record type?
22 2015-04-29 07:28:04 <wumpus> you can just encode arbitrary data into it
23 2015-04-29 07:28:53 <jonasschnelli> wumpus: right.. but i'm not sure if such records are getting relyed without issues.
24 2015-04-29 07:29:02 <wumpus> now it's getting obfuscated data semantically interpreted as addresses, that's asking for trouble
25 2015-04-29 07:29:44 <jonasschnelli> so you would prefer having the ip's in a encrypted TXT record...
26 2015-04-29 07:30:28 <wumpus> you cant be sure here whether it will be relied without issues either, if the idea is to avoid blacklists, blacklists can be arbitrary like 'forbid addresses from North Korea' to give a stupid example
27 2015-04-29 07:30:57 <wumpus> yes, for example
28 2015-04-29 07:32:11 <wumpus> may not even have to be encrypted
29 2015-04-29 07:33:03 <jonasschnelli> i think if there would be support for ips in txt records it should be signed at least to ensure nobody tempered it.
30 2015-04-29 07:33:17 <wumpus> why? there is no such validation now either
31 2015-04-29 07:33:59 <jonasschnelli> Right. But it would be a easy improvement. Just pass a base58 pubkey to the vSeed vector, quick check, done?
32 2015-04-29 07:34:36 <wumpus> what about DNSSEC?
33 2015-04-29 07:35:18 <jonasschnelli> yes. Was also mention this yesterday... will have a close look at DNSSEC
34 2015-04-29 07:35:21 <wumpus> firstly, I think that issue (authenticating the DNS seeds) is orthogonal to the blacklist-evasion issue, also do we have to handroll our own solution there?
35 2015-04-29 07:35:28 <wumpus> right
36 2015-04-29 07:36:40 <jonasschnelli> sipa also said yesterday there is already a seeding in the p2p. getaddr. The dns seed is only there to reach at least one qualified node?
37 2015-04-29 07:36:57 <wumpus> yes
38 2015-04-29 07:37:25 <wumpus> if the DNS seeds cannot be contacted, it has a list of built-in nodes that it can use as getaddr seed
39 2015-04-29 07:37:43 <jonasschnelli> maybe it totally over the top. :)
40 2015-04-29 07:37:59 <wumpus> ... and if that doesn't work the user can specify their own addnode
41 2015-04-29 07:38:04 <wumpus> yes, it's over the top
42 2015-04-29 07:38:18 <wumpus> no need to add even more fallbacks, at least :)
43 2015-04-29 07:38:19 <jonasschnelli> let's close it then to avoid risks
44 2015-04-29 07:38:43 <wumpus> well better to discuss it further first I think
45 2015-04-29 07:38:51 <jonasschnelli> at least it was a cool experiment. :)
46 2015-04-29 07:38:52 <jonasschnelli> okay.
47 2015-04-29 07:39:42 <jonasschnelli> i think if there are SPV clients with connection problems, they maybe have a lack of multiple dns seeds or a missing static ip node liste which is up to date.
48 2015-04-29 07:39:50 <wumpus> the idea behind obfuscation was to avoid the DNS seeds being blacklisted themselves
49 2015-04-29 07:40:02 <wumpus> (for dealing out addresses associated with malware)
50 2015-04-29 07:40:26 <wumpus> it's not so much a fallback for the nodes' seeding
51 2015-04-29 07:40:45 <wumpus> and my doubt is whether just XORing addresses will avoid that situation
52 2015-04-29 07:40:46 <jonasschnelli> a quick fix for that would be to allow random querydomainnames. Like x<rand(1000000)>.bitcoin.seed.xy
53 2015-04-29 07:41:27 <jonasschnelli> because sipas dns-seeder already allow * subdomains, this would be very easy to achive.
54 2015-04-29 07:41:31 <wumpus> it's less likely to xor a good host into a known malware IP, but nevertheless especially with IPv4 it's also not extremely unlikely
55 2015-04-29 07:41:33 <wumpus> right
56 2015-04-29 07:42:42 <wumpus> <jonasschnelli> i think if there are SPV clients with connection problems, they maybe have a lack of multiple dns seeds or a missing static ip node liste which is up to date. <- yes, SPV implementations lean too much on DNS seeding, that's well known
57 2015-04-29 07:42:43 <jonasschnelli> but because the blacklist behavior is unknown, i'm not sure if a NS at a.seed.com is blocked also means b.a.seed.com is blocked
58 2015-04-29 07:43:20 <wumpus> well the idea of dealing out obfuscating information is good, but my suggestion would be to use another data representation that is not nterpreted as an address in the first plae
59 2015-04-29 07:43:29 <wumpus> s/obfuscating/obfuscated
60 2015-04-29 07:43:57 <wumpus> if it's blocked I think the domain is completely blocked
61 2015-04-29 07:44:07 <jonasschnelli> but representing a ip in a different format is also obfuscating. But maybe much more save then xoring.
62 2015-04-29 07:44:48 <wumpus> yes, it is, but at least there is no chance to change good addresses into bad ones
63 2015-04-29 07:45:00 <jonasschnelli> indeed.
64 2015-04-29 07:45:24 <jonasschnelli> will check if txt records or DNSSec could be a choice.
65 2015-04-29 07:45:43 <wumpus> huh?
66 2015-04-29 07:45:55 <wumpus> 'txt records or DNSSec' those are different tools for different purposes
67 2015-04-29 07:46:03 <wumpus> I don't see the link
68 2015-04-29 07:46:27 <wumpus> or ... is DNSSec encrypted?
69 2015-04-29 07:46:29 <jonasschnelli> Right. But both could lead to a better seeding mechanism?
70 2015-04-29 07:46:32 <wumpus> I thought it's just authenticated
71 2015-04-29 07:46:55 <jonasschnelli> i first need to read myself through DNSSec. I expected it to be auth and enc.
72 2015-04-29 07:46:59 <wumpus> I don't think it provides any obfuscation of addresses
73 2015-04-29 07:47:05 <wumpus> requests still go through the ISP
74 2015-04-29 07:47:39 <jonasschnelli> right. It's not encrypted.
75 2015-04-29 07:48:10 <wumpus> effective end-to-end encryption would make caching impossible, that's certainly not what we'd want at least
76 2015-04-29 07:48:18 <jonasschnelli> Agreed.
77 2015-04-29 08:20:14 <NiceHash> hrm
78 2015-04-29 08:23:57 <NiceHash> someone here using their cloud mining or automatic trading? http://www.bitcoinmaxprofit.com
79 2015-04-29 08:33:46 <wumpus> NiceHash: not here
80 2015-04-29 08:41:20 <dc17523b13> another one bites the dust..
81 2015-04-29 09:18:36 <sipa> wumpus: typical resolving mechanisms don't really support fetching other record types, i think? you need specific dns libraries then
82 2015-04-29 09:19:21 <sipa> wumpus: if you can do that, just send an encrypted packet inside a txt response
83 2015-04-29 09:23:07 <wumpus> sipa: I'm not sure, yes that may be an issue...
84 2015-04-29 09:24:02 <Lluis2015> in the "https://github.com/bitcoin/bitcoin" README says testing and automated testing
85 2015-04-29 09:24:09 <Lluis2015> is encouraged
86 2015-04-29 09:24:33 <Lluis2015> But doesn't give further instructions
87 2015-04-29 09:24:50 <wumpus> "make check"
88 2015-04-29 09:24:53 <jonasschnelli> sipa: can i not just use 16 as TYPE and send the TXT record with RLENGTH=<strlen>, RDATA=<string>? Do i need a different library?
89 2015-04-29 09:25:36 <wumpus> that runs the most important part of the automated test suite, there are some loose tests in qa/rpc-tests that don't get involved by default as they take too long, but in specific changes it makes sense to run them
90 2015-04-29 09:25:38 <Lluis2015> wumpus: I did, from the "master" branch, no errors
91 2015-04-29 09:25:46 <wumpus> Lluis2015: great!
92 2015-04-29 09:26:29 <sipa> jonasschnelli: what library are you using?
93 2015-04-29 09:26:43 <wumpus> Lluis2015: as for more specific testing, it depends on the change that you want to test, how to try to find mistakes in it
94 2015-04-29 09:26:53 <sipa> jonasschnelli: i mean on the receiver side
95 2015-04-29 09:27:14 <sipa> jonasschnelli: bitcoin-seeder implements the dns protocol directly
96 2015-04-29 09:27:52 <sipa> jonasschnelli: but c name resolv libraries don't give you access to raw dns, only to "name resolving"
97 2015-04-29 09:28:25 <Lluis2015> wumpus: I understand that to test other's code I must get some information
98 2015-04-29 09:28:27 <jonasschnelli> sipa: Okay. That's why i tough i can just add TYPE_TXT enum with 16 and add a proper RDATA/LENGTH would be sufficient.
99 2015-04-29 09:28:40 <Lluis2015> wumpus: from a ticket or something
100 2015-04-29 09:28:49 <wumpus> Lluis2015: your question was extremely broad so my answer was too
101 2015-04-29 09:28:50 <sipa> jonasschnelli: on the dns server side it is trivial
102 2015-04-29 09:29:07 <Lluis2015> wumpus: never mind
103 2015-04-29 09:29:25 <wumpus> Lluis2015: what are you trying to do?
104 2015-04-29 09:29:39 <jonasschnelli> sipa: didn't looked at the client side. But right.
105 2015-04-29 09:29:39 <Lluis2015> just getting into it
106 2015-04-29 09:29:39 <sipa> jonasschnelli: but on the receiver side, i have no clue how to do ot without 1) reimplementing dns 2) guessing the user's local dns servers on different platforma
107 2015-04-29 09:29:56 <Lluis2015> if testers are needed, I will
108 2015-04-29 09:30:20 <wumpus> Lluis2015: in that case yes it makes sense to pick a ticket (pull request) that interests you and go test that and then report there on the results
109 2015-04-29 09:31:25 <Lluis2015> wumpus: thank you, I will
110 2015-04-29 09:31:37 <wumpus> sipa: right, would be a shame to have to add a new library dependency just for this specific case
111 2015-04-29 09:32:03 <sipa> wumpus: if we can't use dns, i would just use oneshot seeding
112 2015-04-29 09:32:06 <wumpus> (or even worse, implement deep parts of the DNS protocol in bitcoin core)
113 2015-04-29 09:32:12 <sipa> which is already used for tor
114 2015-04-29 09:32:33 <wumpus> sipa: yes, indeed
115 2015-04-29 09:32:38 <sipa> (connect briefly using p2p to a node, and do a getaddr)
116 2015-04-29 09:33:07 <wumpus> that's also done for plainnet if it doesn't get replies from DNS seeds
117 2015-04-29 09:33:17 <sipa> oh is it, ok
118 2015-04-29 09:33:50 <wumpus> so I'm not sure there is a problem at all, I thought what motivated the obfuscated results was to protect the DNS seeders *themselves* as from ISP viewpoint they can sometimes deal out say, malware addresses
119 2015-04-29 09:34:01 <sipa> wumpus: indeed
120 2015-04-29 09:34:16 <wumpus> the clients themselves are fine
121 2015-04-29 09:34:30 <sipa> clients using those isps are not
122 2015-04-29 09:34:40 <wumpus> at least bitcoin core; some SPV clients rely too much on the DNS seeds
123 2015-04-29 09:34:46 <wumpus> they are, they will find nodes
124 2015-04-29 09:35:00 <wumpus> that's why there is the embedded list of seeds, remember
125 2015-04-29 09:35:08 <sipa> oh, right, sure
126 2015-04-29 09:35:31 <sipa> i mean they get some degraded service by not being able to connect to the seeds
127 2015-04-29 09:36:00 <wumpus> possibly, although I'm not sure what the chance is that all the seeds would be blacklisted, there are multiple after all and they don't deal out the same addresses
128 2015-04-29 09:36:47 <sipa> if there is one well-reachable "evil" ip running a bitcoin nide, it is not unreasonsble that an isp will end up blocking all seeds
129 2015-04-29 09:36:55 <wumpus> in any case I'm afraid the XORing may make it worse; the XORed addresses could just as well happen to be forbidden for one reason or another
130 2015-04-29 09:37:17 <sipa> wumpus: that's why there is these 26 keys
131 2015-04-29 09:37:45 <wumpus> I don't think that will work; an ISP will likely block the entire domain, not just a subdomain
132 2015-04-29 09:37:51 <wumpus> (or at least the entire server)
133 2015-04-29 09:37:55 <sipa> ah
134 2015-04-29 09:37:56 <sipa> hmm
135 2015-04-29 09:38:05 <wumpus> (in the case of Luke-Jr it was just blackhole-routed)
136 2015-04-29 09:38:16 <sipa> that is a good argument
137 2015-04-29 09:38:24 <sipa> just a per-seed key would help
138 2015-04-29 09:38:41 <sipa> like mine would use another xor key than luke's
139 2015-04-29 09:38:46 <wumpus> yes
140 2015-04-29 09:38:52 <wumpus> it'd reduce the chance
141 2015-04-29 09:39:01 <wumpus> (of *all* seeds being banned)
142 2015-04-29 09:39:16 <sipa> anyway, i agree that this is becoming more and more a kludge
143 2015-04-29 09:39:33 <sipa> we can easily switch to oneshot instead...
144 2015-04-29 09:40:03 <wumpus> yes
145 2015-04-29 09:41:29 <sipa> maybe add authentication to the p2p protocol too, so you can be sure to reach the right seeds, and not be mitm'ed when connecting to addnodes
146 2015-04-29 09:42:29 <wumpus> add a MAC to P2P packets?
147 2015-04-29 09:42:49 <sipa> yes
148 2015-04-29 09:43:33 <wumpus> (after all, if authenticating just at connect time would be easy to MITM by changing the data after that)
149 2015-04-29 09:45:23 <sipa> one peer sends "hey, are you host key with salted hash X? here is an ephemeral ECDH key", other side ignores or sends "yes i am, here is my side of ECDH", and after that point the packet's checksums are macs derived from the ecdh key, instead of plain hashes
150 2015-04-29 09:45:25 <wumpus> in any case - the current DNS based peer-finding system is not authenticated either, so this would be a seperate issue
151 2015-04-29 09:45:34 <sipa> indeed, totally orthogonal
152 2015-04-29 09:46:11 <jgarzik> sipa, wumpus: The original version of DNS seeding that I wrote used SRV records http://en.wikipedia.org/wiki/SRV_record and a custom DNS server, https://github.com/jgarzik/dvdns Included authentication and other features
153 2015-04-29 09:46:16 <wumpus> on one hand I don't like moving towards authenticated seeds, it reduces the decentralization and makes the seeds even more seem like a trusted resource
154 2015-04-29 09:46:20 <jgarzik> A records & current system were much easier
155 2015-04-29 09:46:36 <jgarzik> No libraries, works everywhere -- but it was always Best Effort. ISPs could filter etc.
156 2015-04-29 09:46:57 <wumpus> jgarzik: right
157 2015-04-29 09:47:01 <jgarzik> It does not seem to hold lots of value to link in a new lib, just to add in this new obfuscated DNS seeding stuffs
158 2015-04-29 09:47:06 <jgarzik> its quickly getting complicated
159 2015-04-29 09:47:12 <wumpus> it's always *possible* to filter, but what we're trying to protect here is against inadvertent filtering
160 2015-04-29 09:47:16 <jgarzik> it's basically a brand new seeding protocol
161 2015-04-29 09:47:29 <sipa> wumpus: well the seeds are inherently trusted already - whether it is by virtue of ip addresses hardcoded in the software, or spv vkients relying directly on dns seed results
162 2015-04-29 09:47:49 <sipa> you can't bootstrap from absolutely nothing
163 2015-04-29 09:47:58 <wumpus> sipa: I know, but this further entrenches that
164 2015-04-29 09:48:02 <sipa> jgarzik: i was totally unaware of that
165 2015-04-29 09:48:17 <wumpus> jgarzik: I don't think I've seen that code either, before
166 2015-04-29 09:48:52 <jgarzik> XOR'ing A records is quite ugly. Just move to TXT, once you depart from real A records.
167 2015-04-29 09:48:59 <wumpus> jgarzik: but yes it'd basically be a new seeding protocol
168 2015-04-29 09:49:05 <wumpus> jgarzik: agreed re: that
169 2015-04-29 09:49:25 <sipa> wumpus: in any case, i think authentication is useful, and orthogonal to this
170 2015-04-29 09:49:39 <jgarzik> returning signed data would be a step up
171 2015-04-29 09:49:45 <wumpus> sipa: optional P2P authentication could be useful, yes
172 2015-04-29 09:49:48 <jgarzik> DNSSEC or TXT permits that
173 2015-04-29 09:49:59 <sipa> jgarzik: i mean using bitcoin p2p
174 2015-04-29 09:50:14 <wumpus> (also for completely different reasons, such as whitelisting)
175 2015-04-29 09:50:51 <sipa> dns has scaling advantages, but not much... you can still ddos the actual server itself
176 2015-04-29 09:51:00 <jgarzik> sipa, p2p auth would be... authenticated from first message of TCP session, or all the way through DNS seed results to P2P connection?
177 2015-04-29 09:51:09 <wumpus> dns also has privacy advantages
178 2015-04-29 09:51:15 <sipa> jgarzik: scroll up
179 2015-04-29 09:51:18 <wumpus> as not everyone queries the server directly
180 2015-04-29 09:51:24 <wumpus> but we're not talking about *replacing* DNS here
181 2015-04-29 09:51:30 <jgarzik> wumpus, +1
182 2015-04-29 09:51:36 <sipa> 6 minutes ago
183 2015-04-29 09:51:47 <sipa> yes, i like dns
184 2015-04-29 09:51:47 <wumpus> this is just a fallback for cases in which it doesn't work, right?
185 2015-04-29 09:52:06 <wumpus> in those -hopefully rare- cases it's fine to make a compromise
186 2015-04-29 09:53:53 <sipa> jgarzik: once you have p2p auth, you can also send host keys in addr packets, and be sure you're connecting to the peer another peer told you about; if the key changes, drop the addrman data
187 2015-04-29 09:55:37 <sipa> jgarzik: could be done as a tcp wrapper too, but i don't want to go reinvent ssl...
188 2015-04-29 09:57:18 <wumpus> alternatively could use a trivial seeding protocol: return a serialized, signed blob of addresses to everyone that connects on a certain TCP port
189 2015-04-29 09:57:48 <jgarzik> sipa, yeah that was proposed years ago... main issue is addr data is not validated/authenticated and pretty for an asshole node to scramble host keys then relay
190 2015-04-29 09:57:54 <wumpus> makes the server implementation easier too, if it's seed-specific there's not even a need to implement bitcoin P2P
191 2015-04-29 09:58:09 <jgarzik> *pretty easy
192 2015-04-29 09:58:40 <jgarzik> not saying that is a reason to avoid; just noting old arguments
193 2015-04-29 09:59:19 <jgarzik> wumpus, if you are able to connect to a TCP port, you don't need a seeding protocol, just getaddr
194 2015-04-29 09:59:53 <jgarzik> a seed is by definition some out-of-band mechanism
195 2015-04-29 09:59:59 <wumpus> jgarzik: sure, if the seed nodes run a P2P node
196 2015-04-29 10:00:23 <wumpus> (or do they already?)
197 2015-04-29 10:00:25 <jgarzik> wumpus, no I'm saying all P2P nodes already perform peer exchange
198 2015-04-29 10:00:30 <wumpus> if you're talking about the built-in seed list, sure
199 2015-04-29 10:00:37 <wumpus> jgarzik: obviously
200 2015-04-29 10:01:12 <jgarzik> wumpus, a trivial -custom- seeding protocol over TCP doesn't make sense, since we already do peer exchange
201 2015-04-29 10:01:27 <jgarzik> a seed protocol -must- be either hardcoded, or a popular protocol (DNS, HTTP, ...)
202 2015-04-29 10:01:37 <jgarzik> otherwise you just reinvent peer exchange
203 2015-04-29 10:01:58 <wumpus> you could hardcode the hosts to connec to using the simple custom seeding protocol
204 2015-04-29 10:02:18 <jgarzik> nod. though it seems pointless to avoid HTTP
205 2015-04-29 10:02:21 <wumpus> sure, you could use HTTP too, doesn't hearn do that, it was just the most simple way
206 2015-04-29 10:02:34 <wumpus> avoiding HTTP that's was not my point!
207 2015-04-29 10:02:46 <jgarzik> -any- custom seed protocol is pointless, is my point.
208 2015-04-29 10:03:03 <jgarzik> once you roll a custom TCP protocol, "trivial" is less trivial than HTTP.
209 2015-04-29 10:03:10 <wumpus> if you see it that way this whole discussino is pointless, we already have built-in seed nodes to connect though P2P
210 2015-04-29 10:03:31 <wumpus> I don't want to argue what is more trivial
211 2015-04-29 10:05:57 <sipa> jgarzik: hmm seeders do way way faster network crawling than p2p nodes
212 2015-04-29 10:06:19 <sipa> jgarzik: i'm sure they would take ages to discover new pieces of network graph
213 2015-04-29 10:06:21 <wumpus> if we keep the built-in seed nodes list up to date (let's remember to do that for 0.11), nodes that can't connect to DNS seeds have a working fallback and there's nothing to worry abut at all
214 2015-04-29 10:06:52 <sipa> of course, imho we ahould add peer rotation to bitcoin core
215 2015-04-29 10:07:20 <jgarzik> wumpus, +1
216 2015-04-29 10:07:35 <jgarzik> wumpus, would rather follow that logic, and keep DNS seeding simple
217 2015-04-29 10:07:44 <jgarzik> sipa, +1
218 2015-04-29 10:08:31 <jgarzik> IMO xor stuff just not needed, nor a custom seeding protocol
219 2015-04-29 10:08:47 <jgarzik> host keys would be nice down the road, but wants thinking through
220 2015-04-29 10:09:49 <jgarzik> "getextaddr" for CAddress v2
221 2015-04-29 10:10:10 <jgarzik> and updated "version" machinery etc.
222 2015-04-29 10:10:38 <sipa> yes
223 2015-04-29 10:14:29 <jonasschnelli> I agree with closing the xor stuff (also not extend it to support TXT records). If a (spv) client supports a recent static nodes list and multiple dns seed the connection to at least one node should be possible. Then getaddr there.
224 2015-04-29 10:15:12 <sipa> jonasschnelli: spv nodes don't want that, takes too long to get an actual connection
225 2015-04-29 10:17:09 <jonasschnelli> sipa: Okay. Didn't knew that. That's why the relay on DNS seed?
226 2015-04-29 10:17:16 <wumpus> it's still preferable to *not* getting a connection, in any case
227 2015-04-29 10:19:22 <jgarzik> jonasschnelli, yes bitcoinj SPV wallets rely heavily on DNS seeds. Turnover of nodes tends to imply lack of immediate connection otherwise
228 2015-04-29 10:19:37 <jgarzik> hueristics could be improved to change this (better addrman for bitcoinj)
229 2015-04-29 10:22:27 <jonasschnelli> Okay. But i guess if all dns seeds/queries are blocked, a SPV node should fallback to a recent static nodes liste to at least manage to getaddr from somewhere. It might take longer but at least it creates connection to the p2p
230 2015-04-29 10:25:09 <jgarzik> jonasschnelli, it should, yes
231 2015-04-29 10:25:33 <jgarzik> jonasschnelli, in practice...
232 2015-04-29 10:25:38 <jgarzik> slack
233 2015-04-29 11:20:53 <Luke-Jr> wumpus: the blackhole-routing seems to have been related to the crawler, not the DNS results
234 2015-04-29 11:29:35 <wumpus> Luke-Jr: okay
235 2015-04-29 11:36:08 <wumpus> then I confused your case with someone else's
236 2015-04-29 11:44:53 <wumpus> this adds a few script_invalid tests, seems an easy merge?: https://github.com/bitcoin/bitcoin/pull/6075
237 2015-04-29 13:05:31 <Luke-Jr> ACTION wonders whether DragonFlyBSD or TBC have more users.. <.<
238 2015-04-29 13:05:54 <timothy> I think Hurd
239 2015-04-29 13:06:36 <Luke-Jr> lol, pretty sure TBC beats Hurd+Bitcoin
240 2015-04-29 13:07:51 <sinetek2> what's TBC?
241 2015-04-29 13:08:10 <Luke-Jr> https://en.bitcoin.it/wiki/Tonal_Bitcoin
242 2015-04-29 13:08:18 <sinetek2> haha
243 2015-04-29 13:08:38 <sinetek2> for what it's worth i just tried convincing the dfly people bitcoin's code isn't total garbage
244 2015-04-29 13:08:43 <sinetek2> then gave up -_-
245 2015-04-29 13:09:06 <Luke-Jr> :|
246 2015-04-29 13:09:22 <sinetek2> it came up because of gcc5
247 2015-04-29 13:09:35 <Luke-Jr> sinetek2: fwiw, your bug closed because you pushed the branch with no commits not merged
248 2015-04-29 13:09:43 <sinetek2> eh fuck
249 2015-04-29 13:09:47 <sinetek2> i'm trying to fix it..
250 2015-04-29 13:09:58 <sinetek2> i was just very confused with git
251 2015-04-29 13:10:00 <Luke-Jr> I don't think there's any way to fix those :/
252 2015-04-29 13:10:04 <Luke-Jr> just have to open a new one
253 2015-04-29 13:12:05 <sinetek2> eh here we go. probably the most pointless PR in the history of bitcoin
254 2015-04-29 13:16:39 <sipa> jgarzik: seems the results from your dns seed are very outdated/unreliable
255 2015-04-29 13:50:51 <helo> not having libprotobuf disables bitcoin-qt, but then still attempts to build in qt/test/, and fails (because no libprotobuf)
256 2015-04-29 13:55:13 <sipa> helo: file an issue, please?
257 2015-04-29 13:55:36 <helo> sure
258 2015-04-29 13:56:02 <jonasschnelli> hmm... not sure. You need to have protobuffer installed.
259 2015-04-29 13:56:40 <jonasschnelli> For bitcoin-qt bip70 support
260 2015-04-29 13:56:40 <jonasschnelli> (sorry, just read you disabled)
261 2015-04-29 13:56:40 <jonasschnelli> yes. maybe create an issue. :)
262 2015-04-29 13:57:15 <jonasschnelli> helo: how did you disable it?
263 2015-04-29 13:57:39 <sipa> he did not
264 2015-04-29 13:57:50 <sipa> he just does not have proto instslled
265 2015-04-29 13:57:54 <sipa> and does not want qt
266 2015-04-29 13:58:11 <wumpus> sounds like a build system issue, it should not try to build the qt tests if not qt
267 2015-04-29 13:58:15 <sipa> however, the default behaviour seems to still try to build the qt tests in this case
268 2015-04-29 13:58:55 <wumpus> explicitly passing --without-gui probably works around it
269 2015-04-29 14:00:36 <sipa> i expwct ig to
270 2015-04-29 14:00:54 <sinetek2> QT_TESTS depends on --enable-tests only
271 2015-04-29 14:00:56 <sinetek2> from what i see
272 2015-04-29 14:01:56 <sinetek2> so in makefile.am, move the test inside the QT portion
273 2015-04-29 14:02:29 <sinetek2> or better yet, in config.ac add a check for QT
274 2015-04-29 14:05:40 <wumpus> there is a check for qt, but it apparently doesn't disable the tests
275 2015-04-29 14:06:32 <wumpus> well thinking of it, the test for qt *does* disable the qt tests, just the test for protobuf doesn't
276 2015-04-29 14:06:34 <sinetek2> yes, the qt test doesn't check for qt
277 2015-04-29 14:06:47 <sinetek2> hm
278 2015-04-29 14:06:57 <wumpus> why would the test check for qt? isn't that quite too late?
279 2015-04-29 14:07:42 <wumpus> it's likely a matter of adding one line in the right place in configureac
280 2015-04-29 14:09:58 <helo> (--without-gui does work around it)
281 2015-04-29 14:11:26 <wumpus> helo: https://github.com/bitcoin/bitcoin/pull/6082 should solve it too
282 2015-04-29 14:13:39 <helo> sipa: filed at https://github.com/bitcoin/bitcoin/issues/6083
283 2015-04-29 14:13:52 <wumpus> helo, you're too late, I just filed a fix already
284 2015-04-29 14:14:10 <sinetek2> :D
285 2015-04-29 14:14:13 <helo> 'sok
286 2015-04-29 14:30:14 <wumpus> heh, could have left the issue open until it the fix was tested and merged, in any case please verify that it actually works
287 2015-04-29 14:34:46 <sinetek2> grrrr
288 2015-04-29 14:34:59 <sinetek2> bitcoin master's ./configure stopped working here
289 2015-04-29 14:36:47 <wumpus> try at least re-doing ./autogen.sh
290 2015-04-29 14:37:42 <sinetek2> ./configure: 22298: Syntax error: word unexpected (expecting ")")
291 2015-04-29 14:37:47 <sinetek2> that's after a git clone
292 2015-04-29 14:37:58 <sinetek2> and autogen. seems to be qt5 mixup
293 2015-04-29 14:38:07 <sinetek2> I'll probe further, might just be my setup
294 2015-04-29 14:38:08 <wumpus> there are no recent changes to configure.ac or related files, so I expect the problem to be on your side
295 2015-04-29 14:38:17 <sinetek2> yeah precisely
296 2015-04-29 14:54:37 <helo> is it permissible for anyone to ACK a pull req if they've verified that it seems to function as intended?
297 2015-04-29 14:54:49 <sipa> yes
298 2015-04-29 14:56:17 <michagogo> sinetek2: could try git clean -dxf, as long as you haven't put any files in the repo that you want to keep
299 2015-04-29 14:56:28 <wumpus> helo: sure!
300 2015-04-29 14:58:06 <sinetek2> michagogo: it happens starting from a blank repo
301 2015-04-29 14:58:14 <sinetek2> blank state
302 2015-04-29 14:58:20 <sinetek2> i'm not sure, will debug later
303 2015-04-29 14:58:25 <sinetek2> sounds like QT5 mixup
304 2015-04-29 15:44:58 <jgarzik> sipa, yep, this is known, it is manually updated
305 2015-04-29 15:45:14 <jgarzik> sipa, slightly more frequently than the compiled in list ;p
306 2015-04-29 17:41:59 <esso> Does anyone think that Bitcoin-qt's UI/UX should be updated?
307 2015-04-29 17:42:27 <sipa> that's a pretty vague statement
308 2015-04-29 17:42:40 <sipa> if you have specific suggestions, feel free to post them as issues
309 2015-04-29 17:42:50 <sipa> or if you're willing to work on it, even better!
310 2015-04-29 17:50:03 <esso> sipa: I may put something together. Do you think I should post design issues under issues in github?
311 2015-04-29 17:51:12 <sipa> esso: if they're actual (usability) problems, sure
312 2015-04-29 17:51:39 <sipa> esso: if they're just wishlist things... they may get closed if nobody is interested in working on them
313 2015-04-29 17:53:31 <esso> sipa: That makes sense. I think I'm gonna dig into the user experience of Bitcoin-qt and see what I find. I feel like UX is something most devs miss.
314 2015-04-29 17:56:27 <sipa> esso: that is very likely to be true :)
315 2015-04-29 17:56:57 <sipa> esso: do you intend to work on that?
316 2015-04-29 17:57:14 <sipa> as in, actual coding?
317 2015-04-29 17:57:25 <esso> sipa: I do.
318 2015-04-29 17:57:32 <sipa> cool!
319 2015-04-29 17:58:16 <esso> sipa: Check for any UX issues on github in the next few days ;)
320 2015-04-29 17:58:41 <sipa> i should warn you that ui/wallet changes often don't get much attention (from maintainers, but also from users/esters), so they can take a long tike to be merged
321 2015-04-29 17:59:03 <sipa> esso: i get an email for every issue posted; i'm sure i'll notice
322 2015-04-29 18:01:05 <esso> sipa: Awesome! Just curious, but how do you do that?
323 2015-04-29 18:01:23 <sipa> you can surscribe to a repository
324 2015-04-29 18:01:40 <Luke-Jr> the "Watch" button thing
325 2015-04-29 18:02:24 <Luke-Jr> esso: I like the current UX (much more than Multibit, Electrum, Armory, etc), but I guess improvement is always possible
326 2015-04-29 18:02:58 <esso> Ah thanks
327 2015-04-29 18:03:04 <Luke-Jr> esso: can you do code changes, or just mockups?
328 2015-04-29 18:03:56 <esso> Luke-Jr: I should be able to do the code changes as the QT framework is pretty well documented, but I'll need to look into it a little further
329 2015-04-29 18:04:27 <esso> Also the first step will be to get the issues address before any code is touched
330 2015-04-29 19:01:59 <maraoz> do coinbase transaction input scripts have to be valid? I know there's a block height encoded in there, but does it respect the regular script encoding rules? (or can the miners include any arbitrary data?)
331 2015-04-29 19:15:29 <maraoz> I'm looking at 16451afed50dd7703f31057f72ad5e74673a7cda1434ad9bd2dcf4bf27f8be2a, which seems to have an invalid opcode at the fifth byte in the coinbase input script.
332 2015-04-29 19:16:48 <phantomcircuit> maraoz, coinbase input scripts are never evaluated as scripts
333 2015-04-29 19:17:14 <phantomcircuit> it's generally suggested that there be an OP_PUSH to avoid things being counted against the sigops limit
334 2015-04-29 19:17:21 <phantomcircuit> but they can be complete gibberish
335 2015-04-29 19:17:35 <phantomcircuit> the only restriction is that have to be < 100 bytes and contain the block height as a serialized scrpt
336 2015-04-29 19:19:13 <maraoz> phantomcircuit: ah, good to know, thanks! that transaction I mentioned seems to have tried to create a valid input script, but it actually attempts to push data of length > 0x4b without using an OP_PUSHDATA
337 2015-04-29 19:20:16 <phantomcircuit> maraoz, yeah that's a common bug
338 2015-04-29 19:20:32 <michagogo> heh
339 2015-04-29 19:20:32 <phantomcircuit> it's actually one i have in my own code which i cant be bothered to fix (yet)
340 2015-04-29 19:20:41 <michagogo> Wait, what?
341 2015-04-29 19:20:46 <phantomcircuit> it has roughly zero real world effect
342 2015-04-29 19:21:02 <michagogo> As in, the code just assumes that you can use any byte as a "push this many bytes"?
343 2015-04-29 19:21:02 <michagogo> heh
344 2015-04-29 19:21:11 <phantomcircuit> yeah
345 2015-04-29 19:21:20 <michagogo> That's mildly amusing
346 2015-04-29 19:21:34 <phantomcircuit> michagogo, worst case invalid coinbase input script consumes 97 sigops from the block limit of 20k
347 2015-04-29 19:21:46 <phantomcircuit> i have bigger fish to fry
348 2015-04-29 19:22:03 <michagogo> phantomcircuit: eh? Not if it's a lot of invalid multisig checks
349 2015-04-29 19:22:09 <michagogo> (unless you mean in your usecase)
350 2015-04-29 19:23:04 <phantomcircuit> michagogo, no since there needs to be something on the stack i think
351 2015-04-29 19:26:27 <maraoz> it only bothered me because many coinbase input scripts are valid, but some aren't. I was thinking it may have been a problem with the script parsing code I'm using
352 2015-04-29 19:29:20 <phantomcircuit> maraoz, it still might be
353 2015-04-29 19:29:35 <phantomcircuit> but yeah there are coinbase input scripts which if executed would fail
354 2015-04-29 19:47:39 <phantomcircuit> >.>
355 2015-04-29 19:47:49 <phantomcircuit> boost spirit doesn't know how to do unsigned int -> json
356 2015-04-29 19:48:04 <phantomcircuit> but does know how to do unsigned long -> json
357 2015-04-29 19:49:58 <maraoz> well... thank you very much for the help! :D
358 2015-04-29 21:00:28 <jgarzik> phantomcircuit, boost spirit is going away anyway
359 2015-04-29 21:03:56 <warren> jgarzik: in favor of what?
360 2015-04-29 21:04:46 <jgarzik> warren, https://github.com/bitcoin/bitcoin/tree/master/src/univalue
361 2015-04-29 21:16:01 <amiller> ive had a bitcoind node up for a few weeks
362 2015-04-29 21:16:11 <amiller> i want to look through my debug log and see who all i was connected to during that time
363 2015-04-29 21:16:23 <amiller> but that doesn't information seem to be available at all
364 2015-04-29 21:17:14 <helo> it's a feature
365 2015-04-29 21:17:22 <amiller> there are entries for the version messages, sending and receiving for each peer, but it only prints in the debug log what it thinks *my* ip is
366 2015-04-29 21:18:29 <helo> i think you can -logips
367 2015-04-29 21:19:06 <Luke-Jr> amiller: the point is to not be subpoena-able by default
368 2015-04-29 21:19:18 <amiller> jeez
369 2015-04-29 21:22:14 <warren> amiller: some things that were previously printed in the log circa 0.8 now require various -debug=something options too.
370 2015-04-29 21:22:20 <warren> like -debug=mempool
371 2015-04-29 21:25:34 <sipa> amiller: annoying, huh? :) yes, it's intentional
372 2015-04-29 23:50:57 <jgarzik> sipa, wumpus: now that new DNS seeds are coming into the mix, let's just delete xf2.org