1 2015-04-16 03:12:55 <leakypat> Is testnet still having problems?
  2 2015-04-16 03:15:35 <gmaxwell> It wasn't having problems as far as I observed, there were a bunch of blocks because the difficulty dropped to 1... and some explorer things got confused.
  3 2015-04-16 03:16:11 <leakypat> Ah ok, thanks
  4 2015-04-16 03:22:34 <leakypat> Looks like I'm 16k blocks behind :0
  5 2015-04-16 11:31:51 <jonasschnelli> sipa: wouldn't add a bool flag (fXored) in CDNSSeedData be sufficient? Rexor the ips only from seeds where the xored flag over CDNSSeedData was set
  6 2015-04-16 11:32:30 <sipa> jonasschnelli: old clients won't understand it...
  7 2015-04-16 11:32:48 <sipa> sure, we could have completely separate seeds for the old and the new behaviour i guess
  8 2015-04-16 11:32:57 <jonasschnelli> but old clients would not have set the seeder-ip
  9 2015-04-16 11:33:08 <sipa> maybe i'm misunderstanding
 10 2015-04-16 11:34:00 <sipa> i mean: I run a seeder, i prefer to run only one, and i want to support both new clients (which can xor) and old clients (which can't)
 11 2015-04-16 11:34:22 <jonasschnelli> Right. That would be a dilemma.
 12 2015-04-16 11:34:43 <sipa> this could be done if the seeder software could offer to run on two different domain names, and the old clients would be configured to use the old domain name, and the new clients would use the new one with xored results
 13 2015-04-16 11:34:46 <jonasschnelli> Maybe adding something in the dns request to select the output tyhe?
 14 2015-04-16 11:34:56 <sipa> yes, the domain name!
 15 2015-04-16 11:35:01 <jonasschnelli> okay. :)
 16 2015-04-16 11:35:12 <sipa> what else is there in the request? :p
 17 2015-04-16 11:35:58 <jonasschnelli> Agreed. Will try to improve this.
 18 2015-04-16 11:41:14 <jonasschnelli> sipa: adding a -hXor argument to define the hostname for xored output?
 19 2015-04-16 11:41:41 <sipa> jonasschnelli: add as little as possible, preferably one character
 20 2015-04-16 11:41:53 <jonasschnelli> -x?
 21 2015-04-16 11:41:55 <sipa> jonasschnelli: as otherwise you effectively leave less space for responses
 22 2015-04-16 11:44:13 <ThomasV> bip70 mentions that "The trusted root authority MAY be included." if it is not, what is the standard way to find out which CA needs to be used, when verifying the chain
 23 2015-04-16 11:46:11 <ThomasV> do I need to match all Issuer subfields with the root CA's Subject subfields?
 24 2015-04-16 11:46:23 <ThomasV> or only the Common Name ?
 25 2015-04-16 11:46:36 <ThomasV> or something else..
 26 2015-04-16 11:46:42 <ThomasV> hearn: ^
 27 2015-04-16 11:48:34 <hearn> hello
 28 2015-04-16 11:48:38 <ThomasV> hi :)
 29 2015-04-16 11:48:49 <hearn> does it really say that? hm, i wonder why
 30 2015-04-16 11:48:55 <hearn> normally you'd not include the root
 31 2015-04-16 11:49:12 <hearn> each cert refers to its parent anyway so the root is useless, the local computer already has it
 32 2015-04-16 11:49:29 <ThomasV> yeah, but how do I find out which one it is?
 33 2015-04-16 11:49:32 <sipa> do you need to do that matching manually?
 34 2015-04-16 11:49:46 <hearn> your PKIX stack should do this for you
 35 2015-04-16 11:49:48 <sipa> i would expect you to give the library perhaps a certificate store, and ask it to verify a certificate
 36 2015-04-16 11:49:53 <hearn> i hope you are not implementing it all by hand!
 37 2015-04-16 11:50:24 <ThomasV> python does not have such a library
 38 2015-04-16 11:50:37 <ThomasV> yes, doing that by hand
 39 2015-04-16 11:50:52 <sipa> i think you're crazy
 40 2015-04-16 11:50:58 <hearn> huh?
 41 2015-04-16 11:51:10 <hearn> i am 99% sure python must have a way to do this
 42 2015-04-16 11:52:09 <hearn> or you could invoke openssl?
 43 2015-04-16 11:52:11 <sipa> there are a million things you can do wrong when implementing certificate verification
 44 2015-04-16 11:52:14 <hearn> the code in bitcoin core just uses openssl for this
 45 2015-04-16 11:52:24 <sipa> likely every implementation at least does a dozen things wrongs
 46 2015-04-16 11:52:38 <ThomasV> heh
 47 2015-04-16 11:52:45 <sipa> but trying to implement that yourself feels like ridiculously dangerous
 48 2015-04-16 11:52:56 <sipa> of course, i don't need to say much wrt reimplenting cryptographic code...
 49 2015-04-16 11:53:21 <hearn> well, it's not much dangerous imo as more, you are likely to encounter certs that don't work with your code. as there are a lot of weird things out there people might try to use
 50 2015-04-16 11:53:35 <ThomasV> so you don't know how that matching should be done?
 51 2015-04-16 11:54:03 <hearn> the PKIX spec says, iirc, that you do not match the issuer field against the parent CN like that. rather the intermediate cert refers to its parent with a serial number.
 52 2015-04-16 11:54:05 <hearn> let me check
 53 2015-04-16 11:54:30 <sipa> assuming python has a way to do https communication, it already knows how to verify certificates...
 54 2015-04-16 11:54:45 <hearn> or rather authority key identifier == subject key identifier
 55 2015-04-16 11:54:54 <hearn> sipa: it probably just calls out into a C library to do that
 56 2015-04-16 11:55:02 <ThomasV> sipa: it does, but that will not be usable with bip70
 57 2015-04-16 11:55:09 <hearn> python is so slow that a lot of stuff ends up being done in native code
 58 2015-04-16 11:55:33 <hearn> but i'd just delegate to openssl
 59 2015-04-16 11:55:42 <sipa> ThomasV: why not?
 60 2015-04-16 11:56:04 <ThomasV> sipa: it does not give you access to that
 61 2015-04-16 11:56:12 <sipa> ThomasV: i don't mean use https
 62 2015-04-16 11:56:23 <ThomasV> it only lets you wrap a socket with ssl
 63 2015-04-16 11:56:24 <sipa> i mean look at how the https code does verification
 64 2015-04-16 11:57:07 <ThomasV> sipa: https://docs.python.org/2/library/ssl.html
 65 2015-04-16 11:57:16 <ThomasV> that's all there is
 66 2015-04-16 11:57:28 <jonasschnelli> sipa: what do you think about it now: https://github.com/sipa/bitcoin-seeder/pull/24/files
 67 2015-04-16 11:58:25 <hearn> yeah i think you would need to just call out to openssl
 68 2015-04-16 11:58:27 <jonasschnelli> keys to short
 69 2015-04-16 11:58:30 <hearn> it's fortunately not a very complex bit of code
 70 2015-04-16 12:00:50 <ThomasV> <hearn> the PKIX spec says, iirc, that you do not match the issuer field against the parent CN like that. rather the intermediate cert refers to its parent with a serial number.
 71 2015-04-16 12:00:56 <ThomasV> ^ any ref to that?
 72 2015-04-16 12:01:23 <hearn> PKIX is a set of RFCs. i don't know them off heart.
 73 2015-04-16 12:01:33 <hearn> seriously - don't try and implement this stuff yourself.
 74 2015-04-16 12:01:45 <hearn> if python can't do it natively, call out to C and do it there.
 75 2015-04-16 12:01:58 <hearn> you will waste a lot of time and probably get it wrong, as the specs are very old and confusing unfortunately
 76 2015-04-16 12:03:37 <ThomasV> it's already done; only that part is missing
 77 2015-04-16 12:05:04 <Diablo-D3> http://millcomputing.com/topic/fork-2/
 78 2015-04-16 12:05:06 <Diablo-D3> <3
 79 2015-04-16 12:05:14 <sipa> does "done" mean tested, reviewed, ...?
 80 2015-04-16 12:05:28 <sipa> i think that's more work than the implementation
 81 2015-04-16 12:12:23 <ThomasV> hearn: https://www.v13.gr/blog/?p=293
 82 2015-04-16 13:17:49 <jtimon> is there an specific reason for bitcoin-cli not to use ui_interface.h that I'm missing?
 83 2015-04-16 13:20:24 <jtimon> mhmm, never mind
 84 2015-04-16 13:41:37 <wumpus> it's never part of the UI executable
 85 2015-04-16 15:47:34 <ola> Hi
 86 2015-04-16 15:55:46 <jtimon> wumpus I think this may be acceptable instead https://github.com/bitcoin/bitcoin/pull/6022
 87 2015-04-16 17:31:08 <wumpus> jtimon: I'm not sure I see the point
 88 2015-04-16 17:31:21 <wumpus> jtimon: without GUI there is no translation support
 89 2015-04-16 17:31:34 <wumpus> jtimon: so this makes no difference
 90 2015-04-16 17:32:29 <jtimon> well I guess some translation support could be given to bitcoin-cli without the gui, as you say in the comment I delete
 91 2015-04-16 17:33:26 <jtimon> but anyway, the point is being able to avoid repeating those strings in different files, and changing 3 files instead of one when you want to change the common arg strings
 92 2015-04-16 17:33:44 <jtimon> the files I mean are bitcoin-tx bitcoin-cli and init
 93 2015-04-16 17:33:45 <wumpus> *could* but do you plan on doing that? I think it'd require quite some effort, at least some extra scripting to convert from qt to e.g. gettext
 94 2015-04-16 17:34:13 <jtimon> I don't plan to do that, may interest is the other thing
 95 2015-04-16 17:34:16 <wumpus> the #define was just a quick hack to avoid removing all the _(
 96 2015-04-16 17:34:22 <jtimon> for DRY
 97 2015-04-16 17:35:23 <jtimon> yep, but in a function like GetParamsHelpMessages(), I need to use the real _(), for the cases where the translation is used
 98 2015-04-16 17:35:52 <wumpus> I'd kept the stuff in bitcoin-cli as separate as possible on purpose
 99 2015-04-16 17:35:55 <jtimon> and if I don't use the real one, I cannot call it in bitcoin-cli
100 2015-04-16 17:36:04 <jtimon> ok
101 2015-04-16 17:36:14 <wumpus> a bit of text duplication there isn't a big problem IMO
102 2015-04-16 17:36:28 <jtimon> does bitcoin-tx use the gui?
103 2015-04-16 17:36:32 <wumpus> no
104 2015-04-16 17:36:39 <wumpus> only bitcoin-qt uses the gui
105 2015-04-16 17:36:49 <jtimon> so we could do the same hack as in bitcoin-cli I guess
106 2015-04-16 17:37:10 <wumpus> yes
107 2015-04-16 17:37:34 <jtimon> mhmm, then the special case is actually init...
108 2015-04-16 17:37:35 <wumpus> don't get me wrong I don't see a big problem with #6022, but I think it's a bit unnecessary
109 2015-04-16 17:38:46 <wumpus> I vaguely remember that we had the translation stuff in util at some point
110 2015-04-16 17:39:21 <jtimon> well, I agree it's not a huge improvement, but there's many things (including bitcoin-tx) that are using ui_interface only for _(), and all of them were alreaady including util.h
111 2015-04-16 17:39:29 <wumpus> anyhow, if anyone intends to add translation support to the console programs at some point it'd make sense
112 2015-04-16 17:39:58 <wumpus> yes, using ui_interface for only _ is wrong if the code is never called by the GUI it doesn't need to use it
113 2015-04-16 17:40:16 <jtimon> well, that's not me for now, but this should make things easier for someone wanting do it later
114 2015-04-16 17:40:41 <wumpus> ok, fine with me then
115 2015-04-16 17:40:55 <jtimon> as said my main motivations are removing the ui_interface dependency in some places and DRY with the options descriptions
116 2015-04-16 17:41:37 <jtimon> I undesrtand if, like #5229, this is not a priority
117 2015-04-16 17:41:55 <wumpus> but there's not *that* much overlap between the options of bitcoin-cli and bitcoind
118 2015-04-16 17:42:27 <wumpus> whatever you do, please don't make a giant HelpMessage with all the options for all the utilties :)
119 2015-04-16 17:42:45 <wumpus> keep the non-common option descriptions in the utilities themselves
120 2015-04-16 17:43:50 <wumpus> (the HMM_BITCOIN_QT HMM_BITCOIND is already a hack - would have preferred if all the gui-specific stuff simply stayed in the GUI, but it was a great improvement from a global fIsGui flag)
121 2015-04-16 17:47:53 <jtimon> sure, I won't do that, only when I get something from init (like in chainparams in this case, or for policy-specific options), if they're in bitcoin-tx or bitcoin-cli I get them too
122 2015-04-16 17:49:02 <jtimon> mhmm, I just realized that the policy stuff may have less options for bitcoin-tx...anyway, the policy is stuff has been only for things that are only in init for now (in my branch)
123 2015-04-16 17:52:49 <jtimon> so wumpus, about #5968, do you think I should squash the newer commits?
124 2015-04-16 17:55:12 <jtimon> I mean, is that implied by your utACK ?
125 2015-04-16 18:10:21 <jtimon> I'm squashing
126 2015-04-16 19:19:00 <ParadoxBTC> does btcchina have a rest api?
127 2015-04-16 19:19:31 <ParadoxBTC> i cant seem to find the documentation for it
128 2015-04-16 19:21:16 <ParadoxBTC> nvm i found it
129 2015-04-16 19:26:36 <wumpus> jtimon: yes, squashing is fine; the only risky part of that commit is the code change in ContextualCheckBlockHeader with regard to checking the block versions. Also this interferes a bit with #5966, although that can't be merged yet anyhow as the pulltester seemingly tests the old logic
130 2015-04-16 19:27:18 <wumpus> jtimon: but visually the change looked ok to me
131 2015-04-16 19:28:24 <wumpus> (and the pulltester tests it, and it still passes, unlike #5966 :-)
132 2015-04-16 19:32:11 <jtimon> yep, the change in ContextualCheckBlockHeader was the only risky thing, but I think it was worth it for the history clarity to demand that extra review, even if it's risky, it's still quite trivial once you read it
133 2015-04-16 19:37:07 <phantomcircuit> is there an easy way to see if there are forks at the tip?
134 2015-04-16 19:37:28 <sipa> define fork at tip?
135 2015-04-16 19:37:34 <sipa> equal total pow?
136 2015-04-16 19:37:59 <sipa> yes, they should be in setblockindexcandidates or so
137 2015-04-16 19:38:08 <sipa> whatever it is called
138 2015-04-16 19:38:25 <sipa> actually, no
139 2015-04-16 19:38:45 <phantomcircuit> sipa, equal total pow yeah
140 2015-04-16 19:39:01 <phantomcircuit> makes something im working on 1000x simpler
141 2015-04-16 19:39:39 <sipa> we could make the definition of setblockindexcandidates weaker
142 2015-04-16 19:39:53 <sipa> and make it track more than just potential improvements
143 2015-04-16 19:40:04 <sipa> like forks up to X back
144 2015-04-16 19:43:05 <phantomcircuit> sipa, i guess i could just walk mapBlockIndex
145 2015-04-16 19:43:15 <phantomcircuit> this should be very infrequent
146 2015-04-16 19:43:21 <phantomcircuit> but that's nasty O(n) stuff
147 2015-04-16 19:47:46 <jtimon> wumpus #5966 doesn't seem hard to rebase,but I think it's still possible to maintain ContextualCheckBlockHeader constant in code size even after 1000 softforks, with Consensus::Params::.nLastSoftforkHeight and Consensus::Params::.nLastSoftforkHeightVersion or something
148 2015-04-16 19:48:08 <jtimon> anyway, I will think more about it and comment on the PR, thanks for pointing me to it