1 2014-11-13 06:26:43 <deego> Kudos to the developers for the sidechain paper and the new algorithm stuff. (And, I have to wonder if the current renewed interest is partly a result of these exciting developments.) Thanks!
  2 2014-11-13 06:50:14 <warren> Is anyone already working on BIP32 support for Core?
  3 2014-11-13 06:51:12 <justanotheruser> warren: I don't think so. AFAIK, some core devs are against integrating it.
  4 2014-11-13 06:51:48 <warren> oh?  are the reasons written anywhere?
  5 2014-11-13 06:52:04 <justanotheruser> warren: maybe in this channels logs.
  6 2014-11-13 06:52:38 <justanotheruser> The reason I've heard is that bitcoin core is supposed to be a stable reference client, not an unstable client packed with bells and whistles
  7 2014-11-13 06:53:07 <warren> I'm considering adding watch-only address support to https://github.com/slickage/baron
  8 2014-11-13 06:53:21 <warren> a very dumb way to do it would be to use importaddress on a pool of pre-generated addresses
  9 2014-11-13 06:53:40 <warren> a better way might be extended public keys
 10 2014-11-13 06:54:17 <warren> currently baron relies upon a live Bitcoin Core wallet (with private keys)
 11 2014-11-13 06:54:35 <warren> it only receives money so there's no need for it to have private keys
 12 2014-11-13 07:19:05 <wumpus> I'm not against adding features to the wallet, it's just that the first order of business should be to convert the wallet into a separate, SPV-based wallet
 13 2014-11-13 07:19:50 <wumpus> it should not be part of the core anymore
 14 2014-11-13 07:19:57 <warren> and it shouldn't use db4
 15 2014-11-13 07:20:01 <wumpus> we just can't maintain all that code
 16 2014-11-13 07:28:10 <wumpus> to be clear, I'd certainly not be opposed to integrating basic BIP32 support, which could be done without that much impact by changing the key generation function
 17 2014-11-13 07:31:57 <phantomcircuit> wumpus, requires a new record type
 18 2014-11-13 07:31:59 <phantomcircuit> do not want
 19 2014-11-13 07:32:37 <wumpus> (note that the low-level implementation is already there, see BIP32Hash and CKey::Derive)
 20 2014-11-13 07:44:56 <wumpus> it would make buckup policies a lot saner, if you forget to back up after 100 keys it's not catastrophic anymore
 21 2014-11-13 07:46:24 <phantomcircuit> wumpus, that reminds me
 22 2014-11-13 07:46:30 <phantomcircuit> the default shouldn't be 100 anymore
 23 2014-11-13 07:46:32 <phantomcircuit> that's just silly
 24 2014-11-13 07:46:51 <phantomcircuit> i have wallets with a million keys that are only marginally slow at startup
 25 2014-11-13 07:48:58 <wumpus> it's even easier to forget if the default is higher
 26 2014-11-13 07:50:19 <wumpus> I'd agree if the keypool generation was manual instead of automatic, so the the user is automatically reminded to make a backup... then again, bip32 would be better
 27 2014-11-13 07:56:28 <jonasschnelli> wumpus, do you know what's the status of BIP32? Even for HDWallets i think there must be a proper backup mechanism... the question for me is know, how we could ensure that the backups are encrypted
 28 2014-11-13 08:00:54 <wumpus> jonasschnelli: what do you mean? the backup mechanism wouldn't change, you'd still just copy the wallet or use "Backup wallet" from the menu
 29 2014-11-13 08:00:59 <wumpus> which you need to backup metadata
 30 2014-11-13 08:01:27 <wumpus> the only difference will be that you can still retrieve your funds if you restore an older backup
 31 2014-11-13 08:02:19 <wumpus> the default would be to 'fail less dangerously'
 32 2014-11-13 08:44:24 <jonasschnelli> is travis win32 broken? Or does anyone have a clue why this build (win32) fails: https://travis-ci.org/bitcoin/bitcoin/builds/40859367
 33 2014-11-13 08:45:08 <cfields> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/5268
 34 2014-11-13 08:46:01 <cfields> wumpus: ^^ ping and bump for your attention. PR's will likely be red and confusing until that's pulled/addressed
 35 2014-11-13 08:46:20 <jonasschnelli> cfields okay. thanks. can't ACK that because i can't test. But looks like this goes in anytime soon...
 36 2014-11-13 08:47:16 <cfields> jonasschnelli: understood and agreed. but as a data point, see here: https://travis-ci.org/bitcoin/bitcoin/pull_requests
 37 2014-11-13 08:47:20 <wumpus> cfields: do we really need to reduce paralellism? :(
 38 2014-11-13 08:47:29 <cfields> and note the green one (5268)
 39 2014-11-13 08:47:46 <wumpus> cfields: I mean all over the board; I'm fine with reducing it just for mingw
 40 2014-11-13 08:47:48 <cfields> wumpus: i've noticed that i have to do the exact same thing in gitian :\
 41 2014-11-13 08:48:28 <wumpus> or reduce paralellism for specific projects?
 42 2014-11-13 08:48:29 <cfields> wumpus: that's possible, i suppose. I could override for the mingw ones
 43 2014-11-13 08:48:37 <wumpus> (like building qt)
 44 2014-11-13 08:49:30 <cfields> wumpus: that's possible as well. but let's pick an easy one for now. either globally, or per-builder. then we can narrow down once we're working again
 45 2014-11-13 08:49:51 <cfields> (i'm not sure what changed, exactly. i suspect they probably changed some memory pooling or something)
 46 2014-11-13 08:50:52 <wumpus> cfields: agreed
 47 2014-11-13 08:51:25 <cfields> wumpus: i had the same thought about limiting it for qt, problem is that with gitian i usually see it happen with bitcoin itself
 48 2014-11-13 08:51:37 <cfields> so i'm not sure that would actually fix the problem
 49 2014-11-13 08:52:05 <wumpus> cfields: bitcoin also uses a lot of memory during build
 50 2014-11-13 08:52:49 <wumpus> if bitcoin itself is the problem I'm fine with reducing it all over the board, but if it is to fix a broken dependency build it would be a waste
 51 2014-11-13 08:53:31 <wumpus> especially for something rare like building qt...
 52 2014-11-13 08:54:07 <wumpus> BlueMatt was already talking about paying travis to give us moar power
 53 2014-11-13 08:54:10 <cfields> yea, seems the whole thing was triggered by a failed cache download, which happens very rarely, but it does happen
 54 2014-11-13 08:55:05 <cfields> i don't think we could get much more from 'em other than more paralellism... more jobs building at once
 55 2014-11-13 08:55:09 <cfields> i believe it's 4 atm
 56 2014-11-13 08:55:41 <cfields> but if that's desired, sure
 57 2014-11-13 08:56:10 <cfields> (trying to make the point that moar power wouldn't help here, it would only speed up the bleeding :)
 58 2014-11-13 08:56:22 <wumpus> well in my opinion travis is sufficiently fast now, but reducing parallelism would make it slower ofc
 59 2014-11-13 08:56:40 <wumpus> that's going in the wrong way :)
 60 2014-11-13 08:56:59 <cfields> wumpus: i'm not 100% sure about that either. apparently they designate "1.5 cores per builder"
 61 2014-11-13 08:57:06 <cfields> no clue where the 1.5 comes from
 62 2014-11-13 08:57:12 <wumpus> also.. maybe we should just work on optimizing our tests
 63 2014-11-13 08:57:21 <wumpus> do we have statistics on how much time is spent on building versus testing?
 64 2014-11-13 08:57:25 <cfields> -j3 was a number i pulled out of my ass. possible that -j2 or -j4 could've been quicker
 65 2014-11-13 08:58:00 <wumpus> cfields: right - in general they recommend using -jN+1 or -jN+2 where N is number of cores
 66 2014-11-13 08:58:14 <cfields> i think a good chunk of the time actually comes from spin-up. i have a simple PR with a dumb optim that may help there, but i'd like to wait til it's stable again before messing with it
 67 2014-11-13 08:58:30 <wumpus> (because gcc is i/o-bound for a large chunk of its runtime and that helps pipelining - HOWEVER that requires more memory)
 68 2014-11-13 08:58:55 <cfields> wumpus: right. not trying to argue away from more paralellism by any means. only saying that cranking it up to 11 might not do what we'd hope
 69 2014-11-13 08:59:13 <wumpus> cfields: hehehehe, agreed
 70 2014-11-13 08:59:17 <cfields> *parallelism
 71 2014-11-13 08:59:25 <cfields> i always forget where to stick the damn l's :)
 72 2014-11-13 09:00:42 <cfields> wumpus: so to get us back on track, before testing it some, would you prefer that i override and set -j2 for mingw only?
 73 2014-11-13 09:01:32 <wumpus> cfields: yes - if the problem is mingw only, let's make the workaround mingw only
 74 2014-11-13 09:01:34 <cfields> (and btw, the real fault here was the fact that we built twice, don't overlook that. a busted lib made it into the cache and poisoned the well. that one was 100% my fault and not travis)
 75 2014-11-13 09:01:58 <cfields> ok, will update the pr
 76 2014-11-13 09:03:00 <wumpus> hah, yes the first rule of optmization is to avoid doing unnecessary work, no amount of parallelism will help you there
 77 2014-11-13 09:06:09 <cfields> wumpus: heh, not that. the problem is that we had a bad lib stuck in the cache because after the compiler error, we ran "make" again, and it successfully built and installed
 78 2014-11-13 09:06:16 <cfields> (that's kinda crazy to me actually)
 79 2014-11-13 09:06:49 <wumpus> ... that doesn't sound like something you'd expect, no, but in the case of memory problems that indeed happens
 80 2014-11-13 09:06:56 <cfields> that was then cached. but that lib was busted and failed to link, causing future build errors for everything using the cached result
 81 2014-11-13 09:07:22 <wumpus> I suppose it should just bail out when it fails once, and not try another make
 82 2014-11-13 09:07:35 <cfields> i'm not sure whether i should be impressed or saddened by the tools. it either produced a completely valid and wrong .o, or ar didn't care about the busted .o and shoved it in anyway :)
 83 2014-11-13 09:11:32 <wumpus> well if it crashed while writing the .o, just a by-product of filesystems not being ACID, there's only so much you can do in a tool
 84 2014-11-13 09:18:14 <cfields> wumpus: i think that PR should set things straight. I need to head to bed, but I'll leave my phone volume up for personal mails. feel free. i really don't want to wake up to a chaos of failing PRs :\
 85 2014-11-13 09:18:40 <wumpus> ok, I'll merge it when it passes travis
 86 2014-11-13 09:19:16 <cfields> ok, i'll wait for that then
 87 2014-11-13 09:52:09 <cfields> wumpus: all green
 88 2014-11-13 09:54:12 <warren> when attempting to gitian build the osx 0.9.3, does anyone else see a ./configure loop many times?
 89 2014-11-13 09:54:15 <warren> /bin/bash ./config.status --recheck
 90 2014-11-13 09:54:15 <warren> make: Warning: File `Makefile.in' has modification time 0.1 s in the future
 91 2014-11-13 09:55:35 <cfields> warren: i believe that happened for 0.9.3, yes. should be gone in master after the upcoming rework
 92 2014-11-13 09:56:13 <warren> does it rely on random timing to escape the loop?
 93 2014-11-13 09:58:34 <cfields> i believe it's random timing that causes the loop, but that's a pretty pedantic answer. afaik, nobody had any noticeable problems building it.
 94 2014-11-13 10:06:51 <cfields> wumpus: thanks. nnite
 95 2014-11-13 10:06:58 <wumpus> cfields: nn
 96 2014-11-13 10:51:52 <elichai2> sipa, you know of any OP_CODES other than OP_RETURN that only *some* of the pools forbid?
 97 2014-11-13 12:13:36 <elichai2> Luke-Jr, here?
 98 2014-11-13 12:13:50 <elichai2> can anyone please help me understand this code? https://github.com/luke-jr/bitcoin/blob/spamfilter/src/main.cpp#L819
 99 2014-11-13 13:57:18 <jonasschnelli> is there a reason while bitcoind can't dump encrypted wallets?
100 2014-11-13 13:59:32 <sipa> jonasschnelli: yes, because it can't read the keys
101 2014-11-13 14:00:02 <sipa> the dump format is just a text file with private keys
102 2014-11-13 14:00:38 <jonasschnelli> sipa, yes. thats right. But there could be a dump (base64 or something like that) of the encrypted keydata?
103 2014-11-13 14:00:58 <sipa> that's pretty pointless for a format that's intended to be interoprable
104 2014-11-13 14:01:01 <jonasschnelli> i just think about a better format for encrypted wallets (as backup) as the BDB thing
105 2014-11-13 14:01:24 <sipa> yeah, i don't really have a good answer for this
106 2014-11-13 14:01:39 <sipa> as a backup that may be good, but i would hope that the dump format is more useful than that
107 2014-11-13 14:01:55 <sipa> for example it is compatible with bitcoin wallet for android right now, i believe
108 2014-11-13 14:02:20 <jonasschnelli> you could exchange it with other wallet-apps (requires to enter the master key while importing)?
109 2014-11-13 14:02:51 <sipa> jonasschnelli: the problem is that the encryption we're using is pretty application specific
110 2014-11-13 14:03:36 <jonasschnelli> okay, i see. So unencrypting would end up in a bitcoin-core like CCryptoKeyStore
111 2014-11-13 14:04:54 <jonasschnelli> sipa: so you would prefer having a AES256 (with the masterKey) encrypted dump?
112 2014-11-13 14:05:05 <jonasschnelli> (as backup)
113 2014-11-13 14:05:47 <sipa> i'm not sure what i prefer :)
114 2014-11-13 14:06:04 <sipa> needing to enter your passphrase to create a backup is pretty bad
115 2014-11-13 14:06:14 <jonasschnelli> me neither.. :)
116 2014-11-13 14:06:32 <sipa> on the other hand... whenever you actually use your wallet you're going to be entering the passphrase anyway
117 2014-11-13 14:06:51 <jonasschnelli> sipa: yes. entering passord for backup is useless. But: when your keyPools gets filled, the wallet is unencrypted.
118 2014-11-13 14:06:56 <sipa> indeed
119 2014-11-13 14:07:02 <sipa> which is exactly when you want to make a backup
120 2014-11-13 14:07:11 <wumpus> right
121 2014-11-13 14:08:02 <jonasschnelli> expect for upgrading bitcoind to a backup-capable version, there you probably like to make a backup at first start... (or a normal user could not understand why there is no backup after running and running biconid but never unlock/addaddress your wallet)
122 2014-11-13 14:08:02 <wumpus> what use would it be to encrypt the dump with the masterkey? the user doesn't know that
123 2014-11-13 14:08:49 <jonasschnelli> wumpus: when filling the keypool (adding a new address) he does enter his wallet encryption password... isn't that his masterKey?
124 2014-11-13 14:08:59 <sipa> no
125 2014-11-13 14:09:00 <wumpus> jonasschnelli: no
126 2014-11-13 14:09:01 <jonasschnelli> (i'm still try to understand the wallet-core)
127 2014-11-13 14:09:07 <sipa> the masterkey is encrypted using the passphrase
128 2014-11-13 14:09:08 <wumpus> the master key is encrypted with the wallet encryption password
129 2014-11-13 14:09:11 <wumpus> right
130 2014-11-13 14:09:22 <jonasschnelli> yes... right. okay. sorry for the shortcut. :)
131 2014-11-13 14:09:23 <sipa> and the actual address keys are encrypted using the master key
132 2014-11-13 14:09:37 <sipa> that allows changing the passphrase without reencrypting all keys
133 2014-11-13 14:09:55 <jonasschnelli> hmm..
134 2014-11-13 14:10:17 <sipa> you want to encrypt it with the passphrase... but with sufficient strengtening etc
135 2014-11-13 14:10:28 <sipa> the android wallet strengthening is terrible afaik
136 2014-11-13 14:11:03 <wumpus> right, not forget strengthening...
137 2014-11-13 14:11:54 <jonasschnelli> hmm... somehow it would be nice to async encrypt the wallet... encrypt with the pubKey only (like EVP_SEAL or something like that).
138 2014-11-13 14:12:33 <jonasschnelli> (i mean the wallet-backup-dumps)
139 2014-11-13 14:12:33 <wumpus> well - you still need the plain private keys, so you need the passphrease in any case
140 2014-11-13 14:12:59 <wumpus> key encryption was not designed with this in mind
141 2014-11-13 14:13:09 <sipa> we could design an ECIES-based scheme :)
142 2014-11-13 14:13:26 <sipa> you could derive a 'public passphrase key' from the passphrase once
143 2014-11-13 14:13:32 <sipa> and use that to encrypt with ECIES
144 2014-11-13 14:13:53 <sipa> which would then require the actual passphrase to derive the private passphrase key to do decryption
145 2014-11-13 14:13:57 <wumpus> wouldn't this all be much easier with deterministic wallets? you could just backup the key once
146 2014-11-13 14:14:08 <sipa> YES
147 2014-11-13 14:14:10 <wumpus> the metadata stuff isn't encrypted, so can be backed up
148 2014-11-13 14:14:15 <wumpus> without asking for anything
149 2014-11-13 14:14:27 <sipa> i should undust my bip32 patch :)
150 2014-11-13 14:14:33 <sipa> (unfinished, to be clear)
151 2014-11-13 14:14:40 <wumpus> yes!
152 2014-11-13 14:14:57 <jonasschnelli> has bip32 wallet proven to be the endusers choice?
153 2014-11-13 14:15:53 <wumpus> what does it need to prove?
154 2014-11-13 14:16:10 <sipa> deterministic wallets in general just have one disadvantage compared to random ones: they don't get "unstolen" over time
155 2014-11-13 14:16:41 <sipa> i don't think this weighs up against the benefits (one backup suffices, reproducability on different devices)
156 2014-11-13 14:17:06 <wumpus> still I feel like it would be a lot better than trying to hack the keypool based mechanism into being user friendly
157 2014-11-13 14:17:43 <wumpus> it could still support random keys for people that prefer them, but it's less convenient
158 2014-11-13 14:19:03 <jonasschnelli> Okay. Right. Backing up a hd wallet somehow doesn't make sense? You just need to keep your masterkey somewhere safe?
159 2014-11-13 14:19:23 <wumpus> you still want to backup for labels and payment requests etc
160 2014-11-13 14:19:44 <jonasschnelli> ah right.
161 2014-11-13 14:19:46 <wumpus> it just makes backups less critical with regard to losing funds
162 2014-11-13 14:19:59 <wumpus> btw: the dumpwallet format doesn't contain all our metadata
163 2014-11-13 14:20:45 <wumpus> it's not a full backup of the wallet state, at the moment
164 2014-11-13 14:20:48 <sipa> indeed, it's just a key backup
165 2014-11-13 14:20:51 <jonasschnelli> Yes. So i'm not sure if i should concentrate of backup the wallet.dat instead of the dump
166 2014-11-13 14:20:52 <sipa> not a full wallet backup
167 2014-11-13 14:21:00 <sipa> i want to get rid of wallet.dat
168 2014-11-13 14:21:02 <sipa> 3 years ago
169 2014-11-13 14:21:07 <jonasschnelli> :)
170 2014-11-13 14:21:21 <wumpus> agreed
171 2014-11-13 14:21:36 <jonasschnelli> is there no bit for a wallet interexchangable format?
172 2014-11-13 14:21:40 <jonasschnelli> bit=bip
173 2014-11-13 14:22:29 <wumpus> there just isn't much progress/focus on bitcoin core wallet, we're busy enough with the infrastucture
174 2014-11-13 14:23:53 <wumpus> jonasschnelli: people have tried, but even defining what a wallet is is difficult, let alone getting people to agree on it
175 2014-11-13 14:23:57 <jonasschnelli> yes. it looks like. Looks busy nowadays (especially when i check the amount of pull requests and issues)
176 2014-11-13 14:24:14 <wumpus> jonasschnelli: the closest we have is the keys-in-WIF format per line
177 2014-11-13 14:24:38 <jonasschnelli> which makes us come back to the dump format...
178 2014-11-13 14:24:40 <wumpus> ideally the wallet would be a seperate project with separate bug tracker
179 2014-11-13 14:24:42 <hearn> jonasschnelli: sadly not
180 2014-11-13 14:24:47 <hearn> jonasschnelli: some users don't like HD wallets, it turns out
181 2014-11-13 14:25:13 <jonasschnelli> hearn: maybe users see a risk behind the "mastery".
182 2014-11-13 14:25:20 <wumpus> hearn: what would change for the users?
183 2014-11-13 14:25:22 <jonasschnelli> "masterkey"
184 2014-11-13 14:25:35 <hearn> they don't like the fact that their address keeps changing
185 2014-11-13 14:25:40 <wumpus> except for the backup experience, possibly, nothing changs for the end users
186 2014-11-13 14:25:45 <hearn> and they dislike hiding the address from them, even more ....
187 2014-11-13 14:25:57 <wumpus> that happens in bitcoin core anyhow, so not a problem for us
188 2014-11-13 14:27:55 <wumpus> as with most security/privacy problems, address reuse will need a big scandal before people realize they shouldn't do it
189 2014-11-13 14:29:14 <jonasschnelli> I then will finish the wallet backup functions with just backing up the wallet.dat. The rest looks to much "in-move" for me.
190 2014-11-13 14:29:53 <sipa> wumpus: it probably needs a blockchain.info like site where you can enter a master pubkey, and it tells you your whole balance :(
191 2014-11-13 14:38:10 <hearn> i think it'll help once more wallets are exposing the words
192 2014-11-13 14:38:38 <hearn> the problem is people made the mental link "my address == my account" and get confused when that mental model is broken. replacing "my address" with "my words" will probably help
193 2014-11-13 14:38:53 <hearn> however the main wallet where this was observed to be an issue (on android) didn't implement wallet words yet
194 2014-11-13 14:39:44 <hearn> people very much like syncing wallets with each other as well, same reasons i guess - people associate money with themselves rather than their devices.
195 2014-11-13 14:40:44 <sipa> interesting
196 2014-11-13 14:43:36 <hearn> designing wallets is hard. a lot of users have very little or no understanding of how bitcoin works. but then you also have a vocal population of people who do, and feel that wallets should expose the guts to them as much as possible
197 2014-11-13 14:43:40 <hearn> it's hard to make both camps happy
198 2014-11-13 14:43:48 <hearn> bitcoin's future must ultimately lie with the first camp though
199 2014-11-13 14:52:24 <dgenr8> expose guts != expose guts by default or in main view
200 2014-11-13 14:52:49 <sipa> it's more a problem with adopting a model that is inherently incompatible
201 2014-11-13 14:54:49 <hearn> http://blogs.msdn.com/b/oldnewthing/archive/2003/07/28/54583.aspx
202 2014-11-13 14:55:55 <wumpus> jonasschnelli: "I then will finish the wallet backup functions with just backing up the wallet.dat" agreed
203 2014-11-13 14:56:10 <hearn> over time i guess we'll see wallets specialise, there will be wallets for bitcoin experts (bitcoin-qt is already rather like this) and wallets for people who just want to send money around
204 2014-11-13 14:56:12 <dgenr8> skill level is not fixed for a given user.  they progress.
205 2014-11-13 14:56:21 <wumpus> yes, bitcoin-qt is pretty much dev wallet
206 2014-11-13 14:56:46 <jonasschnelli> wumpus: okay. i make it now configurable to switch from wallet.dat to rpc like dumps.
207 2014-11-13 14:56:51 <hearn> yeah? so everyone who used a computer for ten years is an expert on how they work inside? nah, most users will never progress. they have better things to do than learn about how bitcoin works.
208 2014-11-13 14:57:24 <dgenr8> the novice-advanced slider is a bad design and straw man.  no reason not to be able to "drill in"
209 2014-11-13 14:59:00 <wumpus> dgenr8: it is realistic, though, for any kind of application there exist simple programs for casual users and advanced programs for people that specialize in it
210 2014-11-13 15:00:49 <wumpus> dgenr8: it's not a global novice-advanced slider, but one per specific subject area
211 2014-11-13 15:03:16 <dgenr8> that's better, the microsoft post contemplates global
212 2014-11-13 16:14:46 <hearn> sipa: did you ever write a patch to do utxo indexing by script?
213 2014-11-13 16:14:56 <hearn> i have a feeling the answer is yes but don't recall exactly
214 2014-11-13 16:32:08 <wumpus> hearn: https://github.com/bitcoin/bitcoin/pull/5048
215 2014-11-13 16:33:01 <Luke-Jr> wumpus: thoughts on restoring bitcoin/bitcoin in #bitcoin-commits ?
216 2014-11-13 16:33:47 <hearn> wumpus: thanks
217 2014-11-13 16:35:43 <wumpus> Luke-Jr: huh?
218 2014-11-13 16:36:00 <Luke-Jr> wumpus: it requires GitHub configuration
219 2014-11-13 16:36:10 <wumpus> (I don't know about the channel #bitcoin-commits, so am also not aware of any problems there)
220 2014-11-13 16:36:13 <Luke-Jr> hasn't worked since CIA.vc died
221 2014-11-13 16:36:31 <Luke-Jr> wumpus: it has commit messages for bitcoin projects
222 2014-11-13 16:36:38 <wumpus> ok
223 2014-11-13 16:37:05 <wumpus> what makes bitcoin/bitcoin different from other projects there?
224 2014-11-13 16:37:20 <Luke-Jr> wumpus: it's not there anymore :P
225 2014-11-13 16:37:37 <wumpus> oh, I suppose that needs some bot?
226 2014-11-13 16:37:44 <Luke-Jr> right
227 2014-11-13 16:38:16 <Luke-Jr> https://github.com/bitcoin/bitcoin/settings/hooks/new?service=irc
228 2014-11-13 16:38:29 <wumpus> I'm going to lock #5265, this is going in the wrong direction
229 2014-11-13 16:38:59 <Luke-Jr> ACK
230 2014-11-13 16:42:25 <Luke-Jr> wumpus: the channel is -n, so you can set Message w/o join
231 2014-11-13 16:45:26 <wumpus> should I set notice?
232 2014-11-13 16:46:00 <Luke-Jr> wumpus: prob not
233 2014-11-13 16:46:31 <wumpus> ok, added the hook
234 2014-11-13 16:46:34 <Luke-Jr> thanks
235 2014-11-13 16:46:56 <wumpus> I have not set nick, nickserv password and password, but I suppose github will use some default then
236 2014-11-13 16:47:14 <Luke-Jr> hopefully it has some shared bot
237 2014-11-13 16:52:06 <wumpus> merged something, let's see if it appears
238 2014-11-13 16:54:50 <wumpus> PSA: join #bitcoin-commits to be notified of commits to the bitcoin/bitcoin repository in real time
239 2014-11-13 17:42:06 <gavinandresen> Anybody have objections to a -regtest-only ‘setmocktime’ RPC command that sets the time returned by GetTime() ?  I’m planning on using it to generate blocks with specific timestamps, should also be useful for other testing
240 2014-11-13 17:45:27 <Happzz> i'll vote yes if you pay me
241 2014-11-13 17:48:28 <warren> gavinandresen: would time be frozen at that RPC set time?
242 2014-11-13 17:48:50 <gavinandresen> warren: yes, until you call setmocktime again (or call setmocktime 0)
243 2014-11-13 17:49:04 <warren> sounds good
244 2014-11-13 18:07:13 <jhns> when accepting connections in https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L837, it seems that it can happen that a inbound connections from a node is accepted, although already an outbound connection to this node exists. Is this intentional?
245 2014-11-13 18:12:19 <gmaxwell> jhns: yes, well known at least. It's harmless, and not easily avoided. (Consider cases when there are multiple hosts behind the same IP due to nat; or just multiple daemons on a single machine)
246 2014-11-13 18:17:01 <jhns> gmaxwell: okay, thanks... didn't think about nat
247 2014-11-13 18:41:20 <warren> Why does state.DoS() add to the nDoS level, but nDoS itself doesn't result in disconnect?
248 2014-11-13 18:46:35 <wumpus> warren: because the state itself cannot (and should not) disconnect anyone
249 2014-11-13 18:46:47 <wumpus> it's just a glorified return value
250 2014-11-13 18:47:13 <wumpus> the caller must take care of acting on it (or not)
251 2014-11-13 18:47:14 <warren> I mean, nothing after that actually reads the nDoS level
252 2014-11-13 18:47:59 <wumpus> DoS disconnects do happen
253 2014-11-13 18:48:30 <warren> for example "ProcessBlock() : block with too little proof-of-work"
254 2014-11-13 18:48:39 <warren> it doesn't in that case and many others
255 2014-11-13 18:49:02 <wumpus> ok...
256 2014-11-13 18:49:49 <warren> is it pointless to set the DoS level if you don't do anything with it?
257 2014-11-13 18:58:13 <warren> A better question is why ProcessMessage() checks the state and calls Misbehaving() for tx but not blocks.
258 2014-11-13 19:05:49 <hearn> warren: the anti-dos architecture in bitcoind needs a rethink, although the current set of rules do work in the sense that they do what they were designed to do.
259 2014-11-13 19:06:00 <hearn> warren: but it's rather ad hoc.
260 2014-11-13 19:29:53 <warren> hearn: ok, thank you
261 2014-11-13 19:32:44 <cfields> wumpus: ping
262 2014-11-13 19:33:08 <cfields> wumpus: i updated the scripterror PR to check the error status... https://github.com/theuni/bitcoin/commit/ddadf2d1ecc0d646ae83b06f275c15a5a7704573
263 2014-11-13 19:33:40 <cfields> wumpus: but i'm not sure if it makes sense to actually check the value, or just use it for ok/not ok, since that's what we'll be encouraging users to do
264 2014-11-13 19:34:19 <cfields> er.. not even that much. If verify fails, use it to find out why
265 2014-11-13 19:35:23 <cfields> i check the value in that commit, but I'm happy to switch it to just ok/nok if you'd prefer
266 2014-11-13 21:34:07 <BlueMatt> cfields: hmmmm....when doing ./configure --disable-ccache CXX=distcc CC=distcc the resulting Makefile uses ccache without distcc :(
267 2014-11-13 21:34:35 <cfields> hmm
268 2014-11-13 21:34:37 <BlueMatt> (it seems the thing that searches for gcc ignores the CC/CXX setting)
269 2014-11-13 21:35:53 <BlueMatt> ehh, wait, configure failed....wtf?
270 2014-11-13 21:37:10 <cfields> BlueMatt: seems to be working as-intended here...
271 2014-11-13 21:37:12 <cfields> ./configure --disable-ccache CXX=clang++
272 2014-11-13 21:37:18 <cfields> (i don't have distcc handy)
273 2014-11-13 21:39:42 <cfields> BlueMatt: don't you need something like CXX="distcc g++" ?
274 2014-11-13 21:40:02 <BlueMatt> cfields: not sure...currently configure is failing for no reason :(
275 2014-11-13 21:40:10 <BlueMatt> yea...wtf configure: error: No working boost sleep implementation found.
276 2014-11-13 21:40:27 <BlueMatt> Ive had that issue before
277 2014-11-13 21:40:43 <BlueMatt> ahh, actually, using distcc fails with that issue
278 2014-11-13 21:40:45 <cfields> yea, that's a trap that lots of stuff gets caught in
279 2014-11-13 21:41:31 <BlueMatt> can we remove the use of boost::sleep?
280 2014-11-13 21:42:46 <cfields> BlueMatt: can you paste your config.log ?
281 2014-11-13 21:46:04 <cfields> BlueMatt: actually, (i know nothing of distcc) can it actually link a file? or only be used in -c mode?
282 2014-11-13 21:47:45 <BlueMatt> sorry, yea, turns out that test is the one that blows up if you try to compile in C mode instead of C++
283 2014-11-13 21:48:05 <BlueMatt> anyway, yea, distcc is smart enough to push jobs remotely and keep jobs locally if it cant do it
284 2014-11-13 21:50:10 <cfields> BlueMatt: so all is good?
285 2014-11-13 21:50:59 <BlueMatt> appears so
286 2014-11-13 21:51:04 <BlueMatt> sorry to bug :)
287 2014-11-13 21:51:25 <helo> i just started having issues building... updated from automake 1.9 to 1.11 to fix
288 2014-11-13 21:51:36 <helo> (btw)
289 2014-11-13 21:51:54 <cfields> BlueMatt: np, good to know
290 2014-11-13 21:52:03 <cfields> helo: what problems?
291 2014-11-13 21:54:27 <helo> well, it started after updating to head a few days ago. was getting "/bin/bash: /obj is a directory" because MKDIR_P (among others) was evaluating as empty
292 2014-11-13 21:55:12 <helo> hadn't made any system changes on my end that i can point a finger at, but that doesn't mean it isn't my fault :)
293 2014-11-13 21:56:00 <cfields> ah, no, that was a change on our end
294 2014-11-13 21:56:11 <cfields> any chance you have a list of those that were missing?
295 2014-11-13 21:58:03 <helo> the mkdir error was stopping the build, so i didn't see anything else. but it was trying to access /obj, so i assume builddir was also empty
296 2014-11-13 21:59:18 <cfields> ok, thanks. i'll try with an older automake and revert those changes that break it
297 2014-11-13 23:27:41 <justanotheruser> anyone have a bitcoind.pro they'd like to share?
298 2014-11-13 23:29:33 <cfields> helo: hmm, you're sure it worked before you upgraded?
299 2014-11-13 23:29:41 <cfields> justanotheruser: iirc there's one in contrib/
300 2014-11-13 23:30:02 <justanotheruser> cfields: bitcoin-qt.pro
301 2014-11-13 23:30:58 <cfields> justanotheruser: i suppose i don't understand what you're looking for. not sure why you'd use a .pro for bitcoind
302 2014-11-13 23:31:39 <justanotheruser> cfields: to compile correctly within qtcreator
303 2014-11-13 23:31:51 <kanzure> i am not sure anyone is regularly compiling in qtcreator
304 2014-11-13 23:31:52 <sipa> why would you compile bitcoind with qt-creator?
305 2014-11-13 23:32:17 <justanotheruser> sipa: I thought it would be convenient...
306 2014-11-13 23:32:23 <phantomcircuit> ha
307 2014-11-13 23:32:25 <sipa> lol
308 2014-11-13 23:32:29 <cfields> justanotheruser: if you insist on it, you can install the autotools plugin and add the buildsteps for configure/make
309 2014-11-13 23:32:30 <kanzure> i would assume that most of the qt-related gui development has been blind, just by knowledge of available qt features.
310 2014-11-13 23:32:31 <justanotheruser> 4 votes that I'm dumb
311 2014-11-13 23:32:46 <sipa> justanotheruser: ./autogen.sh && ./configure && make