1 2014-04-13 00:00:28 <warren> eh, making a PR to make them all 0.9.1.99
  2 2014-04-13 00:03:15 <warren> ls
  3 2014-04-13 00:06:43 <GAit> gmaxwell: in my experience hand writing the mnemonics is painful and error prone. Both 12 and 24, although 24 is double the pain and double the error rate :) There's issues with some printers as they keep copies making it also non viable generally IMHO. In my view some hardware device with nfc can backup to an nfc card and then be used.
  4 2014-04-13 00:08:51 <gmaxwell> sipa: so one argument I have against your otherwise awesome scheme is that there is no polynomial time decoder for near misses. If instead we use an error correcting code as the 'checksum' then there is a fast decoder to find likely matches.
  5 2014-04-13 00:12:42 <warren> https://github.com/bitcoin/bitcoin/pull/4049  Please make the versions consistent and manually apply a matching tag.
  6 2014-04-13 00:13:35 <gmaxwell> I really don't like that.
  7 2014-04-13 00:13:45 <warren> like what?
  8 2014-04-13 00:14:11 <warren> If you build from master right now, it calls itself "0.9.2rc2-hash"
  9 2014-04-13 00:14:17 <warren> I mean
 10 2014-04-13 00:14:20 <warren> 0.9.0rc2-hash
 11 2014-04-13 00:14:22 <gmaxwell> adding incorrect tags to github because you find the automatically generated IDs confusing.
 12 2014-04-13 00:14:38 <gmaxwell> it should bee called tag-commits-hash, no?
 13 2014-04-13 00:15:05 <warren> I'm making nightly gitian builds directly from master. without a new tag those builds will call itself 0.9.0rc2-hash"
 14 2014-04-13 00:15:09 <sipa> maybe we need to have better automatically generated version strings
 15 2014-04-13 00:15:19 <warren> sure, come up with something better
 16 2014-04-13 00:15:23 <warren> meanwhile this commit works
 17 2014-04-13 00:15:33 <sipa> as this does come up frequently, and even if unambiguous (because of the number of commits), it is certainly confusing
 18 2014-04-13 00:15:42 <rnicoll> quick aside; do I take it the position on UI for multisig is more or less whenever someone/I write it?
 19 2014-04-13 00:16:16 <warren> sipa: do you have something better in mind?
 20 2014-04-13 00:16:50 <sipa> if we're going to consistency tag pre-release version numbers in clientversion.h, we could just use <version from clientversion>-commits-hash
 21 2014-04-13 00:17:09 <warren> I agree, who came up with latest git tag?
 22 2014-04-13 00:17:24 <gmaxwell> it's a norm in autotagging git projects.
 23 2014-04-13 00:17:39 <gmaxwell> it's what git calls the release with describe.
 24 2014-04-13 00:17:42 <sipa> it's what 'git describe' does
 25 2014-04-13 00:17:43 <gmaxwell> s/release/commit/
 26 2014-04-13 00:18:03 <gmaxwell> 'this tag, plus this many commits, at hash x
 27 2014-04-13 00:18:07 <warren> ok, do we want to depart from git describe?
 28 2014-04-13 00:18:36 <sipa> if we plan to consistently put pre-release version numbers in clientversion.h, i say yes
 29 2014-04-13 00:18:54 <warren> git describe is quite handy looking
 30 2014-04-13 00:19:00 <gmaxwell> whatever we do it should not involve adding extra tags. :) so long as it doesn't do that and it allows identifying the specific code in question I don't care.
 31 2014-04-13 00:30:31 <warren> gmaxwell: can we at least update the clientversion.h?
 32 2014-04-13 00:31:38 <sipa> warren: ack clientversion.h update
 33 2014-04-13 03:15:10 <daemon> hey all from: https://en.bitcoin.it/wiki/Protocol_specification '4
 34 2014-04-13 03:15:32 <daemon> or is the wiki page the documentation base
 35 2014-04-13 07:50:20 <Guest56534> hum
 36 2014-04-13 07:50:31 <jgarzik_> I wonder if p2pool works over Tor
 37 2014-04-13 07:51:45 <vetch> probably not optimally, you'd inevitably end up with a much higher stale rate
 38 2014-04-13 07:52:28 <vetch> with the 30 second block time most of your shares would end up stale due to latency
 39 2014-04-13 07:52:41 <vetch> most, read an unacceptably high percentage
 40 2014-04-13 07:56:43 <sipa> which - if you don't run bitcoin itself over tor - doesn't change expected payout
 41 2014-04-13 07:56:48 <sipa> just variance
 42 2014-04-13 07:57:52 <vetch> if your local stale p2pool shares are very high you would get a lower payout, wouldn't you?
 43 2014-04-13 07:58:06 <sipa> no
 44 2014-04-13 07:58:31 <sipa> a stale p2pool share can still be a valid bitcoin block
 45 2014-04-13 07:58:57 <vetch> but a stale p2pool share won't pay out to you, so you lose income but the p2pool as a whole doesn't
 46 2014-04-13 07:59:26 <sipa> yes it does payout to you, as the paying is done by bitcoin
 47 2014-04-13 07:59:57 <vetch> if you don't have a valid share in the main p2pool chain, you don't get a p2pool payout when p2pool solves a block
 48 2014-04-13 08:00:14 <sipa> hmm
 49 2014-04-13 08:00:20 <sipa> right
 50 2014-04-13 08:00:25 <warren> jgarzik_: ping
 51 2014-04-13 08:00:50 <jgarzik_> warren, pong
 52 2014-04-13 08:00:55 <vetch> so mining over p2pool would get you comparatively lower payouts, but the p2pool network itself wouldn't be affected.
 53 2014-04-13 08:01:08 <sipa> vetch: you're right
 54 2014-04-13 08:02:54 <jgarzik_> I always thought p2pool should increase that 30 seconds to something longer
 55 2014-04-13 08:03:05 <gmaxwell> jgarzik_: it was 10 seconds and it was increased to 30 seconds.
 56 2014-04-13 08:04:08 <vetch> jgarzik_: if it's too high you end up with impossibly difficult shares and massive variance as a result
 57 2014-04-13 08:04:55 <gmaxwell> vetch: I get about 98% efficiency when running over tor, FWIW.
 58 2014-04-13 08:05:05 <vetch> even now the p2pool share difficulty is 508,000. if the pool was a bigger portion of the network it would be in the tens millions.
 59 2014-04-13 08:05:06 <gmaxwell> (running p2pool over tor)
 60 2014-04-13 08:05:22 <vetch> gmaxwell: that's better than I would have expected, tor latencies are usually in seconds.
 61 2014-04-13 08:05:37 <jgarzik_> gmaxwell, well that answers the original question, thanks :)
 62 2014-04-13 08:05:42 <vetch> exiting connections I mean.
 63 2014-04-13 08:06:07 <jgarzik_> Running bitcoind over Tor, it always seems to connect to non-onion nodes
 64 2014-04-13 08:06:20 <jgarzik_> never seems to discover .onion on its own, here, without addnode.
 65 2014-04-13 08:06:27 <vetch> onlynet=tor
 66 2014-04-13 08:06:30 <gmaxwell> vetch: my laptop bitcoin node has 8 tor peers right now, only one of them has a rtt over 1.1 seconds.
 67 2014-04-13 08:06:53 <vetch> gmaxwell: are they internally routed or exiting though?
 68 2014-04-13 08:07:01 <jgarzik_> Is there a risk in talking to outside nodes over Tor?
 69 2014-04-13 08:07:02 <gmaxwell> jgarzik_: if it can connect to non-tor nodes it will only connect to one onion node because it regard all onion as the same network group.
 70 2014-04-13 08:07:08 <jgarzik_> I don't want to turn that off...
 71 2014-04-13 08:07:24 <gmaxwell> although if you enable inbound other onion nodes will connect in.
 72 2014-04-13 08:07:31 <vetch> jgarzik_: not really, it's just heavier on the tor network and likely slower.
 73 2014-04-13 08:07:36 <jgarzik_> I am happy to have exit nodes talk to non-onion P2P nodes
 74 2014-04-13 08:07:46 <gmaxwell> vetch: internally, of course.
 75 2014-04-13 08:08:09 <vetch> gmaxwell: yeah, I think if they were exiting the round trip time would be 3s+
 76 2014-04-13 08:08:20 <gmaxwell> jgarzik_: exit nodes can dork with the traffic but there isn't any major risk beyond just being on an insecured network generally.
 77 2014-04-13 08:08:23 <jgarzik_> So I suppose it boils down to:   bitcoind should prefer more .onion nodes
 78 2014-04-13 08:08:24 <jgarzik_> :)
 79 2014-04-13 08:08:38 <gmaxwell> vetch: maybe, but it doesn't matter because why would you talk to exited nodes? :P
 80 2014-04-13 08:08:56 <gmaxwell> jgarzik_: we don't have any way to resist sybils on onion right now. Kind of an annoying wart.
 81 2014-04-13 08:09:15 <gmaxwell> at least IP addresses are somewhat limited supply, but people can make as many keys as they want.
 82 2014-04-13 08:09:21 <vetch> gmaxwell: bitcoind has to really be coerced into using onion nodes. unless you addnode it doesn't give a crap and talks to ipv4 peers.
 83 2014-04-13 08:09:51 <gmaxwell> vetch: outbound it will connect to at most one unless you set onlynet.
 84 2014-04-13 08:10:09 <vetch> because of sybil issues?
 85 2014-04-13 08:10:41 <gmaxwell> vetch: we try to only connect to one host per netgroup (/16 for ipv4). Onion is seen as one netgroup (because one person with an address generator could be all the tor nodes).
 86 2014-04-13 08:10:56 <vetch> oh right, yep that makes sense.
 87 2014-04-13 08:10:58 <gmaxwell> It's not treated specially though, it's just how the netgroups are defined.
 88 2014-04-13 08:12:23 <gmaxwell> once we get some peer rotation we could probably relax that netgroup limit so that it just preferred having netgroup diversity but didn't force it.
 89 2014-04-13 08:12:42 <gmaxwell> e.g. drop redundant netgroups first.
 90 2014-04-13 08:13:41 <gmaxwell> interesting, my inbound seems to be broken
 91 2014-04-13 08:14:29 <warren> I'm submitting a pull request to change regtest's address versions
 92 2014-04-13 08:15:11 <gmaxwell> warren: why?
 93 2014-04-13 08:15:46 <gmaxwell> warren: you'll break pulltester, are you also going to submit patches to fix it?
 94 2014-04-13 08:16:23 <warren> damn
 95 2014-04-13 08:16:27 <sipa> gmaxwell: i think the onion space is divided into 4 "net groups"
 96 2014-04-13 08:16:27 <warren> I guess I will need to
 97 2014-04-13 08:16:29 <sipa> gmaxwell: not one
 98 2014-04-13 08:16:33 <warren> jgarzik_: crap, pulltester uses it
 99 2014-04-13 08:16:55 <gmaxwell> warren: thats what the feature is intended for.
100 2014-04-13 08:17:20 <jgarzik_> alas
101 2014-04-13 08:17:36 <jgarzik_> makes it more difficult to deduce network from address version
102 2014-04-13 08:17:49 <warren> jgarzik_: so uh... if we're going to make bitcore/insight support regtest we need to change a bunch of stuff
103 2014-04-13 08:17:50 <jgarzik_> regtest has different pchMessageStart but not address versions
104 2014-04-13 08:18:27 <sipa> regtest isn't really intended to be used for more than direct testing
105 2014-04-13 08:18:27 <warren> oops
106 2014-04-13 08:18:41 <jgarzik_> meh...  recompiling openssl is for the birds.  goodbye fedora.
107 2014-04-13 08:19:05 <sipa> i don't object to a separate address space for regtest, but it seems like you really want testnet?
108 2014-04-13 08:19:10 <gmaxwell> Lets merge sipa's ecc code. :)
109 2014-04-13 08:19:20 <jgarzik_> +1
110 2014-04-13 08:19:21 <warren> now?
111 2014-04-13 08:19:37 <vetch> now that's a pull I'll be testing.
112 2014-04-13 08:19:39 <jgarzik_> the plan was always to merge default-disabled at first IIUC
113 2014-04-13 08:19:45 <sipa> jgarzik_: indeed
114 2014-04-13 08:19:54 <sipa> and i don't expect the default to be changed quickly
115 2014-04-13 08:20:03 <jgarzik_> but it sure would be nice on Fedora...
116 2014-04-13 08:20:07 <gmaxwell> merging it now will make life much easier on fedora. :P
117 2014-04-13 08:20:19 <warren> DO IT
118 2014-04-13 08:22:04 <gmaxwell> I guess it'll use the git subdohicky stuff that the leveldb uses?
119 2014-04-13 08:22:12 <sipa> yup
120 2014-04-13 08:22:14 <jgarzik_> needs configure integration
121 2014-04-13 08:22:23 <sipa> jgarzik_: already worked on that
122 2014-04-13 08:22:25 <jgarzik_> (and autotools does support sub-configure)
123 2014-04-13 08:22:40 <sipa> jgarzik_: but there's an ugly bug with CFLAGS not being passed or something
124 2014-04-13 08:22:47 <sipa> which coryfields was going to look into
125 2014-04-13 08:23:01 <sipa> i have the bitcoin side of the code ready
126 2014-04-13 08:23:36 <jgarzik_> another option is direct integration
127 2014-04-13 08:24:01 <sipa> ?
128 2014-04-13 08:24:15 <gmaxwell> autotools directly may be less work to get right.
129 2014-04-13 08:24:26 <sipa> you mean without its own configure? preferably not
130 2014-04-13 08:24:34 <jgarzik_> sipa, updating bitcoin's configure.ac, without a separate sub-configure
131 2014-04-13 08:24:36 <sipa> it needs to detect gmp/openssl/yasm/...
132 2014-04-13 08:24:41 <gmaxwell> Though secp256k1 doesn't have an utterly trivial configure due to arm.
133 2014-04-13 08:24:43 <gmaxwell> er asm
134 2014-04-13 08:24:47 <jgarzik_> multiple configures is more complicated
135 2014-04-13 08:25:11 <sipa> yes, but i like to keep libsecp256k1 as a separately-usable library
136 2014-04-13 08:25:16 <jgarzik_> sipa, so?  :)  worst case it pointlessly slows down peoples configure by a second or two
137 2014-04-13 08:25:24 <warren> can't you have two configure's?
138 2014-04-13 08:25:31 <maaku> better to have its own configure so as to be separately-usable
139 2014-04-13 08:25:50 <gmaxwell> sipa: it can be seperately usable but still use one configure. e.g. just not using the nested one in bitcoin, though thats two things to maintain.
140 2014-04-13 08:25:52 <sipa> it needs to have its own configure, and i prefer not to need to duplicate that logic in bitcoin's
141 2014-04-13 08:26:00 <gmaxwell> right.
142 2014-04-13 08:26:01 <jgarzik_> yes.  ideal == more complicated.  direct == easier to debug and get working correctly.
143 2014-04-13 08:26:18 <gmaxwell> how does leveldb work?
144 2014-04-13 08:26:36 <gmaxwell> (however it works, it works well enough that have no idea how it works— always a good sign)
145 2014-04-13 08:26:39 <maaku> implementing --with-secp256k1=... isn't that complicated, no?
146 2014-04-13 08:27:00 <maaku> i've done that for other projects, and I presume that's already implemented for leveldb
147 2014-04-13 08:27:12 <jgarzik_> 
ACTION goes to look and see what can be done in parallel

148 2014-04-13 08:27:22 <jgarzik_> perhaps can have cake & eat too
149 2014-04-13 08:27:49 <sipa> jgarzik_: go look at my libsecp branch
150 2014-04-13 08:28:18 <sipa> it doesn't have the bitcoin integration (which is in the secp256k1 branch, and outdated), but there's a configure problem there still (which cory was going to look at soon)
151 2014-04-13 08:28:40 <jcorgan> please make sure libsecp256k1 can support vpath build, we dont want two things to have to go back and later fix when we want that
152 2014-04-13 08:29:02 <gmaxwell> other fun projects: go find the last openssl bignum code in bitcoin so we'll be able to build without it. :P
153 2014-04-13 08:29:47 <gmaxwell> oh there may be none left with the base58 and script changes.
154 2014-04-13 08:29:53 <jgarzik_> I don't see anything in secp/Makefile.am that prevents a higher level configure.ac/Makefile stack from directly referencing it.  The lib can have its own configure.ac, which is ignored when a higher level configure.ac is used.
155 2014-04-13 08:30:28 <gmaxwell> oh the difficulty stuff.
156 2014-04-13 08:30:52 <jgarzik_> gmaxwell, last time you mentioned that it was concluded that you inevitably need -some- bignum implementation of some sort, always?
157 2014-04-13 08:31:18 <gmaxwell> jgarzik_: a uint256 is fine for difficulty.
158 2014-04-13 08:31:49 <gmaxwell> jgarzik_: the asm detection stuff could be moved into an m4 file and invoked from the top configure.ac too so that stuff wouldn't even need to be duplicated.
159 2014-04-13 08:32:12 <warren> gmaxwell: eh, what to do about PP?
160 2014-04-13 08:32:22 <jgarzik_> I also messed around with having separate types for uint256 uses versus opaque-hash uses
161 2014-04-13 08:32:36 <gmaxwell> warren: no-openssl builds would be daemon only. No biggie, and a nice first step.
162 2014-04-13 08:32:46 <jgarzik_> gmaxwell, indeed
163 2014-04-13 08:33:21 <gmaxwell> warren: requires turning off the rpcssl, and while I'd really strongly prefer that we promote stunnel for that, I don't think we're going to rip out that functionality right away.
164 2014-04-13 08:33:58 <vetch> does *anybody* use rpcssl?
165 2014-04-13 08:34:14 <vetch> the only use case for it sounds foolish.
166 2014-04-13 08:34:25 <netg_> hu?
167 2014-04-13 08:34:45 <gmaxwell> people have used it in the past. I don't know if it's widely used. It's not an unreasonable thing to use on a lan, for example.
168 2014-04-13 08:34:57 <dizko> would my bitcoind data files (other than wallet) become corrupted by doing something like an rsync while the daemon is running?  if so is ther any way to imrpove this (ie getting only certain files)
169 2014-04-13 08:35:02 <gmaxwell> And arguably better than having no cryptographic security on the rpc in that case... except for the cruddyness of TLS.
170 2014-04-13 08:35:22 <jgarzik_> well:  rpcssl is foolish.  http basic auth is foolish.  rpc password timing defense code is foolish.
171 2014-04-13 08:35:26 <jgarzik_> fools rush in.
172 2014-04-13 08:35:30 <gmaxwell> dizko: you absolutely cannot successfully copy a running node. It's improved completely by shutting down first. :)
173 2014-04-13 08:35:45 <vetch> gmaxwell: surely a tunnel would be a lot better solution. you've most certainly got a shell on the same box anyway.
174 2014-04-13 08:36:05 <jgarzik_> vetch, tunnel == more pieces to setup, more pieces to break.
175 2014-04-13 08:36:11 <dizko> gmaxwell, unfortunate.  im running my production daemon into memory...be nice not to have to run a separate system to keep periodic blockchain backups
176 2014-04-13 08:36:23 <jgarzik_> again better && more complicated go hand in hand.
177 2014-04-13 08:36:45 <vetch> jgarzik_: rpcssl on an exposed port = more attack surface
178 2014-04-13 08:37:01 <jgarzik_> vetch, yes, see "...foolish" in scrollback
179 2014-04-13 08:37:18 <vetch> jgarzik_: apologies.
180 2014-04-13 08:38:26 <warren> jgarzik_: what should we do about regtest and bitcore/insight?
181 2014-04-13 08:38:31 <gmaxwell> vetch: I don't think there is any real disagreement on what ideal is, but ideal is complicated. Builtin crypto is a nice improvement, but sadly tls is pretty much a bigger attack surface than the entire bitcoin protocol. So I've never personally considered it a good tradeoff. (I like stunnel better because it at least puts it in another process)
182 2014-04-13 08:38:52 <dizko> gmaxwell: is there anything in the roadmap like an option to use way more memory?  seems cheaper to throw memory at it than faster disk i/o
183 2014-04-13 08:38:57 <dizko> considering its not -that big-
184 2014-04-13 08:39:25 <warren> how does "more memory" help?
185 2014-04-13 08:39:45 <dizko> well, i need to confirm, but i think im still i/o bound despite being on ssd
186 2014-04-13 08:40:11 <vetch> dizko: presumably if you've enough there's nothing stopping you putting the whole datadir in memory if you're not using the wallet.
187 2014-04-13 08:40:13 <dizko> unless there are only a couple of active threads scalable in bitcoind?   it uses about 2 cores, and 100% of the disk io
188 2014-04-13 08:40:21 <netg_> imho pointless discussion, because there are (and will be more in future) enough valid use cases for rpcssl
189 2014-04-13 08:40:50 <dizko> vetch: yea thats my plan, i was just looking for a more elegant way to keep the on-dick cache of the blockchain more available vs maintaining a separate system to make a bootstrap
190 2014-04-13 08:40:59 <vetch> netg_: like what exactly? every use case can be solved with external software.
191 2014-04-13 08:41:24 <dizko> haha on dick-cache is a sweet typo
192 2014-04-13 08:41:44 <vetch> dizko: you realise that the block files are append-only right? it's not often that you're going to be touching them
193 2014-04-13 08:42:21 <jgarzik_> warren, I don't know about you, but I'm going eat some ice cream and pretend I'm still on vacation until Monday.
194 2014-04-13 08:42:26 <dizko> vetch: yea so i was thinking i could even symlink some back to disk, if i could have a script that periodically did an rsync
195 2014-04-13 08:42:28 <SomeoneWeird> dizko, muscle memory? ;_;
196 2014-04-13 08:42:38 <dizko> i suppose shutting down is an option but i have an always-on service, i really dislike that option
197 2014-04-13 08:42:53 <warren> jgarzik_: I wish I could eat ice cream.
198 2014-04-13 08:43:05 <warren> instead I'im working on nightly builds, openssl and jekyll
199 2014-04-13 08:43:32 <netg_> it adds a layer of security and config possibilities, some admins wanna/will use in their setups
200 2014-04-13 08:43:36 <vetch> dizko: there's probably a ridiculously complex and fragile solution there, keeping all but the most recent block files on disk and the rest in a ramdisk. seems unlikely that you'd be running into performance issues on an SDD anyway.
201 2014-04-13 08:43:58 <dizko> 872374272 Apr 13 08:30 wallet.dat
202 2014-04-13 08:44:02 <dizko> this is probably where my problem lies
203 2014-04-13 08:44:05 <netg_> obvious only make sense if u run and need many distributed nodes
204 2014-04-13 08:44:18 <vetch> dizko: time to retire that wallet.dat.
205 2014-04-13 08:44:37 <dizko> i run a service that uses fixed addresses (i know i know)
206 2014-04-13 08:44:59 <dizko> but yea i may change them at some point...just a customer service problem
207 2014-04-13 08:45:15 <vetch> dizko: shard them into individual wallets?
208 2014-04-13 08:45:19 <dizko> i have some ideas on how to scale it out and use less of the addresses in each wallet
209 2014-04-13 08:45:22 <dizko> right
210 2014-04-13 08:45:45 <dizko> but really since they're fixed and i have the private keys safely stored, i can lose the wallet
211 2014-04-13 08:45:54 <dizko> so long as i had a healthyish recent backup
212 2014-04-13 08:46:05 <dizko> as recent as possible, dont want to wait an hour to catch up
213 2014-04-13 08:46:33 <dizko> so putting it in memory is probably cost effective.   hell maybe i just put the wallet in memory
214 2014-04-13 08:47:03 <dizko> i need more detailed profiling to undersatnd which files the io is going to
215 2014-04-13 08:47:14 <dizko> need a solaris build so i can use dtrace
216 2014-04-13 08:48:31 <vetch> dizko: wallet in memory sounds disastrous. non persistent storage and private keys is bad bad bad.
217 2014-04-13 08:48:42 <dizko> no no, i have all the private keys
218 2014-04-13 08:48:47 <dizko> i really only use the fixed addresses
219 2014-04-13 08:48:48 <vetch> change addresses.
220 2014-04-13 08:48:50 <dizko> even my change is fixed
221 2014-04-13 08:49:00 <vetch> right.
222 2014-04-13 08:49:08 <dizko> so really, i can lose the wallet no problem
223 2014-04-13 08:49:16 <dizko> its the blockchain thats more annoying to catch up to
224 2014-04-13 08:49:29 <dizko> even if its just a few days old it takes too long
225 2014-04-13 08:50:15 <vetch> it's really just demonstrating that the reference client really, really isn't meant to scale
226 2014-04-13 08:50:41 <dizko> sure no doubt.  my friend was helping to build a v2 of the site and he's using bits of proof (he's a java guy)
227 2014-04-13 08:50:50 <dizko> if youre writing raw transactions anyway
228 2014-04-13 08:50:55 <dizko> may as well just take control of it all
229 2014-04-13 08:52:21 <dizko> anyway ive been sysadmin type person for big stupid companies enough to have come up with plenty of nonideal infrastructure solutions to make up for imperfect software
230 2014-04-13 08:52:39 <dizko> so just looking for the right way to improve the situation without changing the app just yet
231 2014-04-13 09:05:55 <michagogo> cloud|I heard someone mention the other day that GitHub has a pull tester that's integrated with it, with badges on PR pages to indicate status, etc
232 2014-04-13 09:06:15 <michagogo> cloud|Does anyone know anything about it, and why we're not using it?
233 2014-04-13 09:38:51 <wumpus> it doesn't have a pull tester of itsemf, but it's possible to integrate github with a CI
234 2014-04-13 09:39:07 <wumpus> as to why we're not using it, for the usual reason, no one has bothered to do it :-)
235 2014-04-13 09:40:49 <wumpus> the current pulltester works very well imo, most urgent change would be to upgrade its build environment, adding badges and such on github would be mildly useful ofcourse
236 2014-04-13 09:55:20 <dizko> is there a perforamnce hit in runing with txindex?
237 2014-04-13 09:58:49 <Luke-Jr> yes
238 2014-04-13 09:59:09 <Luke-Jr> it's unavoidable; to write to disk takes time
239 2014-04-13 09:59:31 <Luke-Jr> the question is whether it's too significant for you
240 2014-04-13 10:07:47 <dizko> Luke-Jr: also unavoidable for my app.   im just trying to understand how best to give it what it needs where it needs it
241 2014-04-13 13:03:42 <Fedorix> hello, can someone tell me the difference between the bitcoin ecdsa and the standard ecdsa that is used in openssl
242 2014-04-13 13:03:53 <Fedorix> i cant really figure out how the public key relates to the standard one
243 2014-04-13 13:05:18 <vetch> I did say this in #bitcoin, but alright. for compressed keys we only give one coordinate and note the sign of the other. ultimately the public key is 33 bytes rather than 65.
244 2014-04-13 13:05:55 <Fedorix> so its not the full coordinate unlike the original?
245 2014-04-13 13:06:07 <vetch> same information, different expression, ultimately different bitcoin address.
246 2014-04-13 13:06:58 <vetch> just X and the sign of Y rather then the full coordinates.
247 2014-04-13 13:08:23 <vetch> Fedorix: I should point out that compressed keys are the default in anything sane. there's no reason not to use them.
248 2014-04-13 13:09:46 <Fedorix> https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses
249 2014-04-13 13:09:57 <Fedorix> here it says both coordinates(x,y) lay in the public key
250 2014-04-13 13:10:18 <c0rw1n> argh, they are computable from the public key
251 2014-04-13 13:10:32 <vetch> for an uncompressed key that would be true. for a compressed key only X is present.
252 2014-04-13 13:11:16 <Fedorix> ic, and we know a key is uncompressed if it has that famous "1" standing infront of it
253 2014-04-13 13:11:34 <vetch> nope. both compressed and uncompressed keys have the same hashed format.
254 2014-04-13 13:11:36 <Fedorix> like "16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM" would be a great example of an uncompressed key
255 2014-04-13 13:11:59 <vetch> there's no way of telling if an address is compressed or uncompressed by looking at it.
256 2014-04-13 13:12:15 <Fedorix> darn
257 2014-04-13 13:12:19 <vetch> if there's a spend you can tell by the length of the private key (33 or 65 bytes), but if there's no spends you don't know.
258 2014-04-13 13:12:27 <vetch> length of the public key rather.
259 2014-04-13 13:13:52 <vetch> Fedorix: private keys in the base58/WIF format do have a bit to designate if the private key is to be compressed or not, but that's a different thing altogether.
260 2014-04-13 13:27:34 <shesek> a byte, not a bit