1 2014-12-29 00:24:52 <firelegend> In which file from the source is the code where a connection to other nodes is established and commands are exchanged?
  2 2014-12-29 00:26:48 <phantomcircuit> er
  3 2014-12-29 00:26:49 <phantomcircuit> 2014-12-29 00:26:07 ERROR: ReadBlockFromDisk : OpenBlockFile failed
  4 2014-12-29 00:26:54 <sipa> phantomcircuit: ungood
  5 2014-12-29 00:27:08 <sipa> firelegend: net.cpp establishes connections
  6 2014-12-29 00:27:25 <sipa> firelegend: it also processes commands, but invokes main.cpp ProcessMessages to do the actual work
  7 2014-12-29 00:27:35 <firelegend> Thank you.
  8 2014-12-29 00:28:58 <phantomcircuit> sipa, this is v0.10.0rc1 with one modification
  9 2014-12-29 00:29:33 <sipa> phantomcircuit: being?
 10 2014-12-29 00:29:34 <phantomcircuit> http://pastebin.com/raw.php?i=B98qkrFB
 11 2014-12-29 00:29:47 <sipa> ok, that shouldn't cause it
 12 2014-12-29 00:29:51 <sipa> what did you do to get that?
 13 2014-12-29 00:30:47 <phantomcircuit> oh
 14 2014-12-29 00:30:49 <phantomcircuit> maybe it's ok
 15 2014-12-29 00:30:58 <phantomcircuit> it's from trying to use the rest api with a bad block hash
 16 2014-12-29 00:31:29 <sipa> ooh
 17 2014-12-29 00:32:17 <phantomcircuit> hah
 18 2014-12-29 00:32:20 <phantomcircuit> that was a bit...
 19 2014-12-29 00:32:36 <phantomcircuit> it's also syncing slowly over wifi
 20 2014-12-29 00:32:44 <phantomcircuit> didn't put them together
 21 2014-12-29 01:14:25 <phantomcircuit> sipa, btw running this on wifi... on a plane
 22 2014-12-29 01:14:28 <phantomcircuit> it's still stalling
 23 2014-12-29 01:14:49 <phantomcircuit> is there someway to figure out if i've got all the headers, but not the blocks yet?
 24 2014-12-29 01:14:56 <sipa> getblockchaininfo
 25 2014-12-29 01:15:10 <sipa> it'll tell you the longest headers chain, and the longest block chain
 26 2014-12-29 01:15:17 <phantomcircuit>     "blocks" : 336194,
 27 2014-12-29 01:15:17 <phantomcircuit>     "headers" : 336398,
 28 2014-12-29 01:15:23 <sipa> close
 29 2014-12-29 01:16:02 <phantomcircuit> sipa, it's been at 194 for about ten minutes now
 30 2014-12-29 01:16:45 <phantomcircuit> im thinking this triggered some kind of traffic shaping
 31 2014-12-29 01:20:53 <phantomcircuit> sipa, switched to a single node -connect and magic fixed
 32 2014-12-29 01:21:00 <phantomcircuit> i guess it looks like bittorrent or something
 33 2014-12-29 01:21:06 <phantomcircuit> which i guess is good?
 34 2014-12-29 01:22:35 <sipa> phantomcircuit: should you be http://theoatmeal.com/comics/inflight_internet 'ing?
 35 2014-12-29 01:23:30 <phantomcircuit> sipa, heh
 36 2014-12-29 01:23:53 <phantomcircuit> only mentioned it because it's relevant to why that wouldn't be working
 37 2014-12-29 01:24:06 <phantomcircuit> im sure there's traffic shaping
 38 2014-12-29 02:20:09 <theymos>  Bitcoin Core should either sign the inputs that already exist in the transaction (if some of the inputs are "mine"), or else automatically select inputs to add and sign according to the BTC amount entered by the user (if none of the inputs are "mine"). (Maybe more cases than these two would be necessary.) This seems like an especially easy way to make CoinJoin and multisig more widespread, since th
 39 2014-12-29 02:20:09 <theymos> Currently it's possible to do multisig and CoinJoin with Bitcoin Core, but it's really inconvenient because you have to deal with raw transactions and manually select outputs using listunspent. I've been thinking that it might be a good idea to create a new address format for incomplete transactions (like the transactions output by createrawtransaction). If you try to send to one of these addresses,
 40 2014-12-29 02:20:09 <theymos> ird-party programs or websites would be able to just give users one of these incomplete transactions to sign instead of handling BTC themselves, expecting users to deal with raw transactions, or modifying Bitcoin Core to do CoinJoin or multisig itself. Has this idea already been thought about?
 41 2014-12-29 02:23:12 <Luke-Jr> doesn't sound worth the implementation cost when just implementing CoinJoin directly is possible, IMO
 42 2014-12-29 02:24:03 <sipa> theymos: there's work around adding a 'fundrawtransaction' which basically just does input coin selection for a given set of outputs
 43 2014-12-29 02:24:57 <jgarzik> sipa, Related: I want to add that to bitcoin-tx
 44 2014-12-29 02:25:16 <sipa> jgarzik: yup, that has been suggested too :)
 45 2014-12-29 02:25:27 <jgarzik> (since before 'fundrawtransaction' even existed)
 46 2014-12-29 02:25:43 <jgarzik> Months ago we talked about a 'buildrawtransaction' that worked at a higher level, including coin selection
 47 2014-12-29 02:25:43 <sipa> jgarzik: that there would be a wallet version in RPC (which uses the wallet's available outputs), and a -tx version where you give the list of available inputs
 48 2014-12-29 02:26:01 <sipa> right, fundrawtransaction is basically buildrawtransaction minus createrawtransaction
 49 2014-12-29 02:26:07 <jgarzik> createrawtransaction is very low level, and adding safety features can be more difficult than with a new rpc
 50 2014-12-29 02:26:09 <sipa> making them maximally independent
 51 2014-12-29 02:26:57 <sipa> so you use createrawtransaction to add the outputs (but no inputs), and then fundrawtransaction to add inputs and change
 52 2014-12-29 02:31:15 <jgarzik> sipa, ideally there is some point for safety checks, for too-large fees and such. hopefully fundrawtransaction can be the area for such checks?
 53 2014-12-29 02:31:32 <sipa> well you pass the fee explicitly to fundrawtransaction
 54 2014-12-29 02:32:04 <sipa> (i haven't actually looked at the patch TBH, i may be making incorrect assumptions)
 55 2014-12-29 02:32:40 <theymos> Ah, looks like you're already thinking about this. Cool! I think that an address format + GUI support for this sort of thing would be really useful. Luke-Jr: I feel like adding CoinJoin to Bitcoin in a way that the masses can easily use would be a lot more difficult than adding this, since you all (rightly) like to do things the right way. GUI support for something like fundrawtransaction would allo
 56 2014-12-29 02:32:42 <theymos> w third-party services to do CoinJoin (and other things) in a more "wrong" way, but quicker.
 57 2014-12-29 02:33:07 <sipa> the hard thing about CoinJoin is not the mixing, but the protocol and interaction with others
 58 2014-12-29 02:33:30 <theymos> Yeah. Are there any good proposals for decentralized CoinJoin matchmaking?
 59 2014-12-29 02:33:35 <sipa> no clue
 60 2014-12-29 02:33:41 <sipa> gmaxwell may know
 61 2014-12-29 02:35:35 <Luke-Jr> is the DarkWallet stuff "not good"?
 62 2014-12-29 02:35:42 <belcher> theymos im working on something
 63 2014-12-29 02:35:46 <belcher> sec
 64 2014-12-29 02:35:48 <sipa> 
ACTION .sleep(28000);

 65 2014-12-29 02:35:57 <belcher> this https://bitcointalk.org/index.php?topic=279249.msg9384411#msg9384411
 66 2014-12-29 02:36:11 <belcher> well, not decentralized
 67 2014-12-29 02:36:17 <belcher> but has the right incentives, probably
 68 2014-12-29 02:36:18 <Luke-Jr> sipa: this is an odd number to sleep
 69 2014-12-29 02:36:51 <sipa> you don't often sleep 7 hours, 46 minutes and 40 seconds?
 70 2014-12-29 02:37:01 <Luke-Jr> sipa: no, usually a multiple of 45 minutes is best
 71 2014-12-29 02:37:42 <theymos> Luke-Jr: DarkWallet is 100% centralized at the moment AFAIK. It relies on the Obelisk server to do matchmaking. So the Obelisk server can unmask everyone if it's evil.
 72 2014-12-29 02:37:52 <Luke-Jr> theymos: ah, nuts
 73 2014-12-29 02:38:00 <theymos> belcher: I'll check that out, thanks.
 74 2014-12-29 02:41:08 <theymos> belcher: I agree with your proposal entirely, and it's something that I've also thought about, but it doesn't address the issue of centralization.
 75 2014-12-29 02:41:36 <belcher> it could be done on a DHT at some point for the decentral
 76 2014-12-29 02:42:06 <belcher> though right im now coding it on an irc channel, open outcry trading pit style
 77 2014-12-29 02:42:20 <gmaxwell> sipa: instead of the point add taking a null for the scale, why not have two point add functions?
 78 2014-12-29 02:42:42 <sipa> gmaxwell: i didn't touch dettman's code :)
 79 2014-12-29 02:43:00 <gmaxwell> sipa: yes, but you've read it. Was there a reason to have a single function that I was missing?
 80 2014-12-29 02:43:07 <sipa> code duplication
 81 2014-12-29 02:43:33 <belcher> theymos also the centralization of irc doesnt allow the irc server to do much harm (eavesdrop), since you can encrypt end-to-end
 82 2014-12-29 02:43:38 <gmaxwell> also you did add a normalize.
 83 2014-12-29 02:43:52 <sipa> gmaxwell: yes, because tests failed otherwise :D
 84 2014-12-29 02:44:00 <belcher> but yes i agree, would be better without centralization
 85 2014-12-29 02:44:05 <theymos> belcher: The problem with more open networks is that an attacker could create so many identities that you're likely to do joins where all of your partners are the attacker. Then the attacker knows which outputs are yours. You somehow need to ensure that at least a handful of your CoinJoin partners are not working together.
 86 2014-12-29 02:44:13 <gmaxwell> belcher: a centeralized meeting place makes it possible for someone controlling it to make sure you only meet their clones.
 87 2014-12-29 02:45:04 <sipa> and if you already know and trust the peers you're going to communicate with (to make the analogy with irc + end-to-end encryption), you don't need a matchmaker anymore, only a broadcast channel
 88 2014-12-29 02:45:47 <belcher> gmaxwell you could check for that by trying to connect yourself, seeing if your other connection shows up (though how many people will do this? probably none)
 89 2014-12-29 02:45:55 <sipa> gmaxwell: anyway, there are plenty of cleanups possible; some things moved to utility functions, reused, some unused functions, ...
 90 2014-12-29 02:47:22 <belcher> theymos sybils are not free to create, since you need to own as many bitcoins as you want to coinjoin at once
 91 2014-12-29 02:47:41 <belcher> also sybils coinjoining still improve privacy against other sybils
 92 2014-12-29 02:48:16 <belcher> if bitcoiners are happy that mining power is proportional to cpu/asic power, i presume they might be happy with coinjoining power being proportional to bitcoin ownership
 93 2014-12-29 02:49:13 <belcher> err, sybils are 'free' to create but they have a cost, is what i meant
 94 2014-12-29 02:49:38 <gmaxwell> Yes, sure. It's just important to be clear on the tradeoffs. You'd said that the centeral server was harmless. It's not-- it's not so harmful as to make such a thing usless though.
 95 2014-12-29 02:49:56 <belcher> yes, ok
 96 2014-12-29 02:53:54 <theymos> belcher: Good point, though I'm not sure that the cost of the CoinJoin alone would be a huge barrier, since CoinJoined BTC can be immediately reused. I wonder if it would be helpful in an otherwise Sybil-vulnerable system to have all CoinJoin transactions somehow made unspendable for a while.
 97 2014-12-29 02:55:06 <belcher> i could be wrong, but i thought you need to wait at least one block because of tx malleability, otherwise you dont know which hash to make the input
 98 2014-12-29 03:04:26 <gmaxwell> malleabilty is more or less irrelevant there. You may not want to permit recently created txouts.
 99 2014-12-29 03:09:01 <belcher> why may i not? just to artificially increase the time that coinjoined btc is locked up
100 2014-12-29 03:09:30 <belcher> its possible to do, just program the default behavour of coinjoin-initiators to not initate if the other party's utxo is not already in a block
101 2014-12-29 03:11:32 <belcher> actually there is a slight incentive for users to reprogram and remove that restriction, reducing the time the btc is locked up would make the coinjoin fees lower, though its only slight since it doesnt benefit the individual coinjoin initiator
102 2014-12-29 03:11:41 <belcher> should be ok i reckon
103 2014-12-29 03:19:17 <Someguy123> does anyone here know why there is an "internal" and "external" account in BitcoinJS? https://github.com/bitcoinjs/bitcoinjs-lib/blob/master/src/wallet.js
104 2014-12-29 03:24:15 <Luke-Jr> Someguy123: internal = change
105 2014-12-29 03:25:25 <Luke-Jr> (I confirmed this in a matter of seconds by searching the code for "internal")
106 2014-12-29 03:25:41 <Someguy123> Luke-Jr: that's what I thought, but I was a little unsure
107 2014-12-29 03:26:13 <Luke-Jr> Someguy123: also see https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#The_default_wallet_layout
108 2014-12-29 03:44:27 <gmaxwell> belcher: what? locked up? huh? no.
109 2014-12-29 03:44:41 <gmaxwell> I mean you shouldn't join with immature inputs, because it increases the risk the transaction will be invalidated.
110 2014-12-29 03:44:50 <gmaxwell> And also because it creates a rate limit on a sybil attacker.
111 2014-12-29 03:45:41 <belcher> yep ok
112 2014-12-29 04:38:06 <s1w> Someguy123: also there's #bitcoinjs-dev with the lead devs in there :)
113 2014-12-29 04:38:40 <Someguy123> oh, awesome
114 2014-12-29 04:38:44 <Someguy123> thanks s1w
115 2014-12-29 08:03:06 <wumpus> sipa: feel free to post an announcement there, I've had no time to make one
116 2014-12-29 08:08:47 <jonasschnelli> Bitcoin XT, huh.. now it is getting distributed...
117 2014-12-29 08:21:58 <wumpus> interesting
118 2014-12-29 08:31:45 <jonasschnelli> the http seeder seams not to be a bad idea... lost of DNS anonymity of course, but maybe a more robust way of seeding.
119 2014-12-29 08:32:24 <wumpus> I don't recall any seeding problems in the first place
120 2014-12-29 08:34:33 <jonasschnelli> the service flag might be out of scope for a seeder, create unnecessary complexity. Should be done within a app IMO not within a seeder.
121 2014-12-29 08:34:41 <wumpus> anyhow it's nice that he does experimentation in his own branch, maybe he could show how this works better at some point
122 2014-12-29 08:35:28 <wumpus> it could also be used as a fallback, if the node can't contact DNS seeds it could try fetching a node list through http(s)
123 2014-12-29 08:36:56 <wumpus> anyhow I'm not worried there, it's not urgent, maybe more for phone-based SPV clients, those tend to have weirder networks
124 2014-12-29 08:37:37 <wumpus> jonasschnelli: well his whole point of this seems to be to advertise getutxo-supporting nodes
125 2014-12-29 08:38:09 <jonasschnelli> wumpus, yes. some lighthouse features...
126 2014-12-29 08:38:56 <jonasschnelli> wumpus, but IMO doesn't belog to a seeder. If the feature is not in the protocol, then it's not. Service-Bitmask might break up the p2p net in different "classes"
127 2014-12-29 08:40:18 <wumpus> jonasschnelli: well re: getutxo, we agree it should not be in the protocol in the first place, if he went through all this trouble he could just as well have made the program advertise a separate kind of 'SPV-advanced-query' service that doesn't go over the P2P network at all
128 2014-12-29 08:40:32 <wumpus> jonasschnelli: or even implemented the getutxo functionality on the seed http servers
129 2014-12-29 08:41:41 <jonasschnelli> wumpus, of test and deploy https://github.com/bitcoin/bitcoin/pull/5420
130 2014-12-29 08:41:46 <jonasschnelli> s/of/or
131 2014-12-29 08:42:19 <wumpus> sure
132 2014-12-29 08:49:43 <jonasschnelli> i think https://github.com/bitcoin/bitcoin/issues/5126 can be closed.
133 2014-12-29 08:50:56 <wumpus> thanks
134 2014-12-29 08:55:54 <jonasschnelli> also solved: https://github.com/bitcoin/bitcoin/issues/5250
135 2014-12-29 08:57:13 <jonasschnelli> solved: https://github.com/bitcoin/bitcoin/issues/3396
136 2014-12-29 08:58:18 <wumpus> hah
137 2014-12-29 08:59:12 <jonasschnelli> same for: https://github.com/bitcoin/bitcoin/issues/3182
138 2014-12-29 08:59:38 <wumpus> app nap is solved?
139 2014-12-29 08:59:57 <jonasschnelli> app nap IMO is not possible for bitcoind...
140 2014-12-29 09:00:09 <wumpus> yes but does it not happen anymore?
141 2014-12-29 09:00:38 <jonasschnelli> was disabled in #5041
142 2014-12-29 09:00:48 <wumpus> ok thanks :)
143 2014-12-29 09:01:24 <jonasschnelli> app nap could come back when there is a option to temp. suspend bitcoind's activity (like network toggle).
144 2014-12-29 09:01:33 <jonasschnelli> but this is another thing..
145 2014-12-29 09:02:32 <jonasschnelli> sloved: https://github.com/bitcoin/bitcoin/issues/3292
146 2014-12-29 09:03:16 <wumpus> good to close some issues once in a while :)
147 2014-12-29 09:04:07 <jonasschnelli> still 319 open. :)
148 2014-12-29 09:04:52 <fanquake> killing all the osx issues are we
149 2014-12-29 09:05:54 <jonasschnelli> my current close-issue-filter. :)
150 2014-12-29 09:06:02 <fanquake> as for app nap, I don’t think we’d be bringing it back unless we were going to introduce alot more osx specific code into the codebase, which I don’t think we want todo.
151 2014-12-29 09:06:15 <fanquake> heh my inbox is overflowing
152 2014-12-29 09:06:48 <wumpus> I'm currently more worried about the 6 pages of pull requests,  we could use some help with testing/review there
153 2014-12-29 09:07:05 <fanquake> #3399 could probably be closed too
154 2014-12-29 09:07:21 <wumpus> fanquake: agreed on the app nap, it just doesn't seem so important
155 2014-12-29 09:08:09 <wumpus> independently of OS options for e.g. limiting bandwidth, or bandwidth quotas for serving blocks, would be nice though
156 2014-12-29 09:08:46 <fanquake> #4596 Can be closed as well.
157 2014-12-29 09:10:10 <jonasschnelli> wumpus: the limiting bandwidth discussion was already hold wasn't it? Some people said it's more a router QoS thing.
158 2014-12-29 09:10:31 <wumpus> jonasschnelli: it was waiting for headers-first rollout
159 2014-12-29 09:11:23 <wumpus> after 0.10 is out and has some adoption, implementing bandwidth limiting would be OK, it will no longer get held up by a single slow node
160 2014-12-29 09:11:32 <jonasschnelli> fanquake, wumpus agree with "#4596 Can be closed as well."
161 2014-12-29 09:11:53 <jonasschnelli> same for 3399
162 2014-12-29 09:13:38 <fanquake> #5553 can also be closed
163 2014-12-29 09:17:29 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/5549 is a trivial merge
164 2014-12-29 09:18:25 <fanquake> heh how did that get miseed in #4603
165 2014-12-29 09:19:23 <jonasschnelli> fanquake, yes. Shouldn't raise that a warning while compiling?!
166 2014-12-29 09:38:56 <wumpus> it's a trivial merge but the repliers wonder whether that declaration is necessary at all as it compiles without
167 2014-12-29 09:39:06 <Luke-Jr> ThomasZ: FWIW, NACK isn't really appropriate for code-change requests
168 2014-12-29 09:40:05 <Luke-Jr> fanquake: your screenshots are of unmodified parts O.o
169 2014-12-29 09:40:17 <ThomasZ> Luke-Jr: Yeah, it should have been on the merge request, not the commit.  Github UI is new to me :)  At least I added a reason behind it, so the idea is clear, no?
170 2014-12-29 09:40:43 <Luke-Jr> ThomasZ: my point is that the merge request gets updated with changes; so just comment on what needs changing is best
171 2014-12-29 09:40:48 <Luke-Jr> yes, looking into them now
172 2014-12-29 09:41:01 <ThomasZ> ah ok
173 2014-12-29 09:41:13 <jonasschnelli> fanquake, you did the wrong screenshots: https://github.com/bitcoin/bitcoin/pull/5551#issuecomment-68243550
174 2014-12-29 09:41:14 <Luke-Jr> ThomasZ: do you have an example foreach? the Qt docs recommended I do it by emptying the list
175 2014-12-29 09:41:47 <ThomasZ> foreach (const QString &foo, myStringlist) { qDebug() << foo; }
176 2014-12-29 09:41:53 <jonasschnelli> fanquake, it's the unit selector in the statusbar at the very bottom
177 2014-12-29 09:42:01 <Luke-Jr> thanks
178 2014-12-29 09:42:20 <ThomasZ> Luke-Jr: in this case the const ref is not needed, I guess, since its an native type (enum) instead of a class.
179 2014-12-29 09:43:02 <Luke-Jr> ThomasZ: shrug, slightly more readable and nice to have for compiler checks
180 2014-12-29 09:43:31 <Luke-Jr> how is qMax cheaper btw? :o
181 2014-12-29 09:43:45 <jonasschnelli> wumpus, #5549: rename or remove the CheckWork() definition.
182 2014-12-29 09:44:28 <jonasschnelli> rename (merge the pull) would keep the (more or less) example code as it is.
183 2014-12-29 09:45:23 <wumpus> jonasschnelli: if the definition is not used externally it can be made static and removed from the .h file
184 2014-12-29 09:46:20 <Luke-Jr> ThomasZ: I think using QFontMetrics is premature optimisation with a risk (that the label may end up using a different font than expected for whatever reason)
185 2014-12-29 09:46:42 <ThomasZ> Luke-Jr: if the label ends up with a different font, your solution also won't work
186 2014-12-29 09:46:57 <Luke-Jr> ThomasZ: why not? it's actually using the label as the information source
187 2014-12-29 09:47:20 <Luke-Jr> or perhaps rather than a different font, a more likely risk is margins or padding
188 2014-12-29 09:47:38 <ThomasZ> at point n in time,  and if at point n+1 your font changes the information its no longer valid.
189 2014-12-29 09:47:50 <wumpus> maybe it's now clear why images were used; images also leave open the option to use e.g. symbols later
190 2014-12-29 09:47:53 <Luke-Jr> sure, I meant if it's different font from the start
191 2014-12-29 09:48:11 <ThomasZ> in Qt layouts have padding, the label doesn't.
192 2014-12-29 09:48:39 <Luke-Jr> wumpus: symbols should also be text ;)
193 2014-12-29 09:48:40 <ThomasZ> the 2 lines are functionally equivalent to doing a setText(), just with a shit-load of code not being used. Including a repaint.
194 2014-12-29 09:49:11 <Luke-Jr> ThomasZ: in the current version of Qt
195 2014-12-29 09:49:29 <ThomasZ> QLabel is end-of-life. Its behavior won't change.
196 2014-12-29 09:50:09 <wumpus> if a settext works, please just use a settext
197 2014-12-29 09:50:10 <ThomasZ> and also in the last 15 years of Qt, not just the current ;)
198 2014-12-29 09:50:26 <ThomasZ> setText has side effects
199 2014-12-29 09:50:53 <ThomasZ> Whats so hard copy-pasting the two lines I wrote to avoid your code being slow?
200 2014-12-29 09:51:28 <wumpus> BTW we *had* text labels for units at some point
201 2014-12-29 09:51:40 <Luke-Jr> wumpus: we did?
202 2014-12-29 09:51:42 <wumpus> anyone remember why this was switched to images in the first place?
203 2014-12-29 09:52:58 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/4466
204 2014-12-29 09:53:13 <ThomasZ> it didn't seem to do any max-width concept back then.
205 2014-12-29 09:53:16 <wumpus> wouldn't want to merge this to have the original concerns that spawned this back
206 2014-12-29 09:53:32 <ThomasZ> I defnitely prefer the non-images approach
207 2014-12-29 09:53:37 <jonasschnelli> 4466 was a bad merge... :)
208 2014-12-29 09:53:55 <Luke-Jr> wumpus: looks like it was a hack due to font sizing and positioning issues
209 2014-12-29 09:54:18 <wumpus> I don't care, I just don't want it to change every day :p
210 2014-12-29 09:55:10 <Luke-Jr> requesting cozz ACK it
211 2014-12-29 09:55:16 <wumpus> having an edit-war in the source code, especially for some silly issue, is unconstructive
212 2014-12-29 09:55:17 <wumpus> ok
213 2014-12-29 09:55:29 <Luke-Jr> wumpus: you are opposed to QFontMetrics, or just opposed to further debate over it?
214 2014-12-29 09:55:38 <wumpus> Luke-Jr: I'm not opposed to anything!
215 2014-12-29 09:55:48 <Luke-Jr> re [09:50:37] <wumpus> if a settext works, please just use a settext
216 2014-12-29 09:55:52 <wumpus> Luke-Jr: I think it makes sense if you do this to make it as fast as possible
217 2014-12-29 09:56:00 <ThomasZ> wumpus: I don't think this qualifies as an edit-war. :)  Just one solution (images) being good, this solution being better.
218 2014-12-29 09:56:10 <wumpus> Luke-Jr: if that doesn't create crazy code complexity, of course
219 2014-12-29 09:56:16 <Luke-Jr> it simplifies the code, actually
220 2014-12-29 09:56:30 <Luke-Jr> eg http://codepad.org/TJFBc8iX
221 2014-12-29 09:57:44 <Luke-Jr> I don't care strongly either way. wumpus, your call :p
222 2014-12-29 09:57:44 <wumpus> Luke-Jr: I was reacting to ThomasZ who said that it was effectively the same
223 2014-12-29 09:58:01 <wumpus> *if* everything else is equal, a simple settext call wins
224 2014-12-29 09:58:12 <ThomasZ> Luke-Jr: looks good
225 2014-12-29 09:58:25 <Luke-Jr> I have no doubt settext is slower - but it's executed once, so that's trivial
226 2014-12-29 09:58:44 <wumpus> Luke-Jr: looks good to me too
227 2014-12-29 09:59:37 <ThomasZ> wumpus: yeah, that was a bad choice of words on my end. setText has hundreds of lines of code, and creates a paint event. Only one of these lines of code we needed.
228 2014-12-29 09:59:50 <Luke-Jr> ok, pushed those changes
229 2014-12-29 10:00:26 <wumpus> ThomasZ: ok, in any case thanks for sharing your qt expertise
230 2014-12-29 10:07:52 <ThomasZ> np
231 2014-12-29 10:55:15 <ThomasZ> petertodd: that email made me lol
232 2014-12-29 12:13:48 <btcdrak> sorry in advance for my post to the dev list just now, but I feel I had to call hearn out.
233 2014-12-29 12:17:12 <gmaxwell> your message has shown up here, but I generally take it as a sign that I probably shouldn't send something if I feel I need to apologize for it.
234 2014-12-29 12:18:46 <Luke-Jr> ^
235 2014-12-29 12:19:54 <btcdrak> I dont feel the need to apologize for the content just that I would prefer the development list stick to technical discussions. Unfortunately it seems necessary to divert occasionally.
236 2014-12-29 12:22:25 <Luke-Jr> let's take this to #bitcoin ?
237 2014-12-29 12:23:02 <gmaxwell> Keep in mind that the list isn't full of idiots, and we see all the messages too. When it comes to opinions about other people we're all able to draw our own conclusions. 'calling out' just creates a circus and factionalism when some people who's opinions were on the border feel sympathy for someone who was attacked, so it's usually not productive. (I still haven't seen the message but...) I'd genera
238 2014-12-29 12:23:08 <gmaxwell> lly advise calling people out in private, if you must.
239 2014-12-29 14:37:57 <JWU42> for testing 0.10 - make more sense to upgrade from 0.9.3 or start fresh to "test" the newer features of headers first?
240 2014-12-29 14:40:39 <fanquake> luke-jr jonasschnelli Yea I noticed I screenshotted the wrong bits heh
241 2014-12-29 14:40:53 <fanquake> Looks like there’s plenty of the right screens there now though
242 2014-12-29 14:43:08 <wumpus> JWU42: both are worthwhile, the advantage of starting afresh is that you can just throw away the state if you want to go back to 0.9.3
243 2014-12-29 14:43:34 <wumpus> JWU42: ie, remember the block database downgrade warning in the release notes
244 2014-12-29 14:44:18 <fanquake> wumpus What’s the quickest full sync you’ve seen with headers first?
245 2014-12-29 14:44:31 <wumpus> fanquake: four hours or so
246 2014-12-29 14:57:26 <gmaxwell> fanquake: 2.5 hours here.
247 2014-12-29 14:58:34 <wumpus> even a reindex takes longer than that, here
248 2014-12-29 14:59:25 <helo> on a pretty unremarkable spinny disk 4-core i5 system, full network sync took 5.3h on friday
249 2014-12-29 14:59:31 <gmaxwell> 16gb/ 4x i7 @ 3.2ghz + ssd.
250 2014-12-29 15:03:19 <Luke-Jr> wumpus: reindex could potentially be slower, since you're reading and writing at the same time
251 2014-12-29 15:03:22 <JWU42> POS dedibox witha  via 1.6 GHz - i am guessing 12 hours
252 2014-12-29 15:03:53 <JWU42> trying to recall how to set a new datadir for the 0.10.0 install
253 2014-12-29 15:03:59 <gmaxwell> JWU42: IO speed matters a lot of vps/hosted things have networked storage, (sometimes even things branded as dedicated)
254 2014-12-29 15:04:07 <midnightmagic> 38 hours on a single-core 1.6GHz PPC and counting! :-D
255 2014-12-29 15:04:18 <JWU42> gmaxwell: yeah - the IO is even worse
256 2014-12-29 15:04:47 <gmaxwell> midnightmagic: lol my PPC host takes about 29 hours.
257 2014-12-29 15:04:51 <JWU42> midnightmagic: that is probably more accurate for mine
258 2014-12-29 15:04:57 <JWU42> oh well - time to get started
259 2014-12-29 15:05:19 <midnightmagic> well the network is stabilized now so hopefully i'll be having no more of those segfaults
260 2014-12-29 15:05:21 <Luke-Jr> dunno, did VIA ever make any half-decent CPUs? XD
261 2014-12-29 15:05:35 <midnightmagic> no, the K6 line were utter, utter trash.
262 2014-12-29 15:05:40 <Luke-Jr> at least G5s were good for their time
263 2014-12-29 15:06:02 <midnightmagic> PPC pound-for-pound for a long time were superior floating-point devices.
264 2014-12-29 15:09:51 <wumpus> Luke-Jr: well, reindex doesn't write blocks, but yes it's reading and writing at the same time
265 2014-12-29 15:11:06 <Luke-Jr> wumpus: just writing lets the OS put the data all together
266 2014-12-29 15:11:26 <Luke-Jr> but reindex might be reading from one spot, and have to write to a far-off spot
267 2014-12-29 15:11:38 <wumpus> true
268 2014-12-29 15:12:02 <wumpus> I suppose you could avoid that by having the blocks and the database on different media
269 2014-12-29 15:12:14 <Luke-Jr> maybe
270 2014-12-29 15:12:40 <Luke-Jr> I foresee if someone writes a guide/advice for that, n00bs will start using two partitions on the same drive :P
271 2014-12-29 15:12:53 <wumpus> hahaha
272 2014-12-29 15:13:32 <midnightmagic> readahead could, conceivably, be triggered more often in the event the data is clustered around itself more contiguously.
273 2014-12-29 15:23:31 <JWU42> if I specify a different -conf location for 0.10 will the datadir still tyr to default to ~/.bitcoin/ ?
274 2014-12-29 15:23:52 <helo> i would hope so
275 2014-12-29 15:24:00 <JWU42> I can't seem to specify the datadir properly when launching bitcoind (for 0.10.0)
276 2014-12-29 15:24:22 <JWU42> I'll try specifying the datadir in the .conf instead
277 2014-12-29 15:25:25 <gribble> Error: "lastseen" is not a valid command.
278 2014-12-29 15:25:25 <JackH> !lastseen jgarzik
279 2014-12-29 15:25:26 <wumpus> -conf does not influence -datadir
280 2014-12-29 15:25:28 <JackH> !help
281 2014-12-29 15:25:29 <gribble> The bot responds when you start a line with the ! character. A good starting point for exploring the bot is the !facts command. You can also visit the bot's website for a list of help topics and documentation: http://gribble.sourceforge.net/
282 2014-12-29 15:25:36 <helo> i set datadir in ~/.bitcoin/bitcoin.conf fwiw
283 2014-12-29 15:26:05 <Luke-Jr> JackH: /msg gribble seen #bitcoin-dev jgarzik
284 2014-12-29 15:26:25 <JackH> ah yes, pm so I dont spam the room up
285 2014-12-29 15:26:28 <JackH> thanks
286 2014-12-29 15:28:39 <wumpus> helo: that should work fine too, you can specify datadir in the configuration file unless you specify datadir on the command line
287 2014-12-29 15:30:43 <JWU42> something is fubar
288 2014-12-29 15:31:05 <JWU42> it won't load the .conf either from command line
289 2014-12-29 15:31:59 <JWU42> using a ~/. tries to load /home/user/.bitcoin/~/.bitcoinbeta/
290 2014-12-29 15:32:05 <JWU42> and specifying full path still errors about no rpcpassword (as if it isn't loading the .conf)
291 2014-12-29 15:32:12 <JWU42> weird
292 2014-12-29 15:33:20 <wumpus> don't use ~
293 2014-12-29 15:33:26 <wumpus> either specify the full path, or use $HOME
294 2014-12-29 15:33:47 <wumpus> (and that will only work on the command line, not in bitcoin.conf)
295 2014-12-29 15:34:21 <JWU42> even the full path isn't working
296 2014-12-29 15:34:25 <JackH> JWU42 try to "find / -name bitcoin.conf" and see what it returns
297 2014-12-29 15:36:18 <JWU42> oh crap
298 2014-12-29 15:36:20 <wumpus> JWU42: what is the exact command line that you are using?
299 2014-12-29 15:36:22 <JWU42> pebkac
300 2014-12-29 15:36:27 <wumpus> ok
301 2014-12-29 15:36:37 <JWU42> wrong username
302 2014-12-29 15:36:44 <JWU42> when doing full path
303 2014-12-29 15:36:45 <JWU42> heh
304 2014-12-29 16:23:21 <jgarzik> Glad to see hearn's Bitcoin-XT patchset
305 2014-12-29 16:23:51 <jgarzik> It's good to see competition and added testing of patches that people would like to propose for Bitcoin Core
306 2014-12-29 16:34:54 <sipa> does anyone know when BIP34 (block v2)'s 75 and 95% thresholds were crossed?
307 2014-12-29 16:35:30 <gmaxwell> sipa: going to hard code the rule to avoid the costly check for every block?
308 2014-12-29 16:35:44 <sipa> nope, updating http://bitcoin.stackexchange.com/questions/18851/what-bips-are-supported-by-the-standard-client-bitcoin-core/34213#34213
309 2014-12-29 16:35:51 <sipa> though that's a good idea too!
310 2014-12-29 16:37:35 <gmaxwell> I wonder if it was ever violated? e.g. maybe we can just enforce it for all v2 blocks, and enforce v2ness after the last v1 block
311 2014-12-29 17:14:50 <jgarzik> Odd bug report
312 2014-12-29 17:15:23 <jgarzik> On Windows, there is a claim that Bitcoin-QT handles URIs beginning with "m" correctly, but not ones beginning with "n"
313 2014-12-29 17:15:33 <jgarzik> w/ -testnet
314 2014-12-29 17:18:32 <wumpus> ok, strange, any example of an address that doesn't work?
315 2014-12-29 17:20:40 <jgarzik> Trying to get that...
316 2014-12-29 17:28:00 <wumpus> it did become stricter with checking but any valid testnet address should be fine
317 2014-12-29 17:28:55 <wumpus> I'm sure we don't even look at the first letter
318 2014-12-29 17:43:08 <proserpine-> why isn't watchonly working - importaddress "1CjPR7Z5ZSyWk6WtXvSFgkptmpoi4UM9BC" "" false -> getbalance "" 0 true -> 0.00000000
319 2014-12-29 17:44:00 <proserpine-> or should i rescan?
320 2014-12-29 17:44:03 <sipa> yes
321 2014-12-29 17:44:15 <sipa> typically, you import the address before handing it out to anyone
322 2014-12-29 17:44:21 <sipa> so you know there are no transactions to it yet
323 2014-12-29 17:44:33 <proserpine-> damnit... isn't there a faster way to get utxo set of an address?
324 2014-12-29 17:44:34 <sipa> if there may be existing transactions to it, you need to rescan
325 2014-12-29 17:44:37 <sipa> no
326 2014-12-29 17:45:01 <proserpine-> shit.. back to using 0.9.3 with getutxo patch
327 2014-12-29 17:45:03 <proserpine-> :(
328 2014-12-29 17:45:05 <sipa> heh
329 2014-12-29 17:45:14 <sipa> you can still use gettxout
330 2014-12-29 17:45:25 <sipa> if you know the txid
331 2014-12-29 17:45:31 <gmaxwell> getutxo doesn't do address lookup either.
332 2014-12-29 17:45:55 <proserpine-> if only getttxout worked with addresses
333 2014-12-29 17:46:07 <sipa> what is the use case?
334 2014-12-29 17:48:22 <sipa> proserpine-: if you just needs an address-indexed UTXO set (which doesn't work with unconfirmed transactions etc), there is a patch to add that directly
335 2014-12-29 17:49:11 <sipa> importaddress uses the wallet functionality, which is higher level, but provides full ledger history, total balance, coin selection, and works with unconfirmed transactions
336 2014-12-29 17:49:26 <sipa> the downside is that it only tracks; it doesn't index
337 2014-12-29 17:49:32 <proserpine-> right
338 2014-12-29 17:49:50 <proserpine-> i am using https://github.com/cozz/bitcoin/commit/7ab90446cc1f013f38e943056f04c5f1a36505de currently
339 2014-12-29 17:49:53 <proserpine-> works great
340 2014-12-29 17:50:10 <sipa> right, that's the patch i was referring to
341 2014-12-29 17:50:50 <gmaxwell> the cost of indexing all non-wallet txo is utterly enormous. e.g. takes the cost of running a node from 2 GB to closer to 35GB today. So, nothing that depends on this is going to be particularly scalable.
342 2014-12-29 17:51:12 <sipa> gmaxwell: address-indexed UTXO != address-indexed txindex
343 2014-12-29 17:52:02 <proserpine-> but both need to be enabled i think
344 2014-12-29 17:52:10 <gmaxwell> sipa: thats true, though you can't get your history from that.
345 2014-12-29 17:52:26 <sipa> proserpine-: i'm very strongly opposed to an address-indexed txindex
346 2014-12-29 17:52:27 <proserpine-> utxo is relatively small compared to full tx index tho
347 2014-12-29 17:52:58 <sipa> proserpine-: it's a "too easy" solution, so it's really attractive to build services on top of it, but it scales terribly
348 2014-12-29 17:53:02 <proserpine-> sipa: well its actually script indexed but meh
349 2014-12-29 17:53:38 <proserpine-> easier than waiting for a rescan to finish
350 2014-12-29 17:53:45 <proserpine-> i mean faster*
351 2014-12-29 17:53:53 <sipa> it depends on your use case
352 2014-12-29 17:54:07 <sipa> do you need transaction history, or just querying spentness?
353 2014-12-29 17:54:48 <sipa> and in any case, i don't believe it should be part of the bitcoin core codebase (but if there's a way to build indexing services on top of it, reusing part or all of the codebase, sure)
354 2014-12-29 18:07:04 <jonasschnelli> while checking sipas #5418: why does line 1057 not return/manupulate state.DoS() (line: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1057)
355 2014-12-29 18:09:26 <sipa> rejectinsanefee is only enabled for locally-created transactions
356 2014-12-29 18:09:37 <sipa> there's nothing bad about it, except for the sender who may be losing money
357 2014-12-29 18:10:13 <gmaxwell> Also, DOS must _never_ be granted against a node who may have just differences in state or local policy causing the relay.
358 2014-12-29 18:21:09 <cfields> gavinandresen / wumpus: looks like i missed the code-signing fun. Any surprises?
359 2014-12-29 18:31:48 <slick2>  /join #qt-creator
360 2014-12-29 18:42:32 <sipa> gmaxwell: indeed, we never switched back
361 2014-12-29 18:42:53 <sipa> the 75% treshold was reached since 224413, and the 95% treshold since 227931
362 2014-12-29 18:42:57 <sipa> 20 days in between
363 2014-12-29 18:43:36 <gmaxwell> were all blocks v2 in between the two?
364 2014-12-29 18:43:49 <gmaxwell> oh I should subtract.
365 2014-12-29 18:44:06 <gmaxwell> 3518 blocks, so yes, some must have been.
366 2014-12-29 18:44:21 <gmaxwell> must have been v1, rather.
367 2014-12-29 18:44:28 <sipa> the 75% treshold was exceeded for all blocks in between
368 2014-12-29 18:44:50 <gmaxwell> where was the last v1 block?
369 2014-12-29 18:45:08 <sipa> so the implementation can be simplified to "after 224431, enforce BIP34 for v2 blocks", "after 227931, enforce v2 blocks"
370 2014-12-29 18:45:38 <gmaxwell> or even just the latter: "after 227931, enforce v2 blocks and BIP34"
371 2014-12-29 18:48:35 <sipa> in testnet it's even easier: bip34 after 21066, v2 after 21111
372 2014-12-29 18:50:19 <sipa> and no switch back in between either
373 2014-12-29 18:50:21 <gmaxwell> why even bother with the two rules though? moving them both to one height is even simpler code.
374 2014-12-29 18:53:39 <sipa> ?
375 2014-12-29 18:53:58 <sipa> there are non-v2 blocks to which bip34 does not apply in between the two switchover points
376 2014-12-29 18:56:43 <jonasschnelli> the thing is more that AcceptToMemoryPool / fRejectInsaneFee check won't give back a appropriate response during sendrawtransaction
377 2014-12-29 18:56:50 <gmaxwell> sipa: sure, but why not just enforce everything at the higher point and none before.
378 2014-12-29 18:57:03 <sipa> gmaxwell: ha!
379 2014-12-29 18:57:20 <sipa> gmaxwell: too easy
380 2014-12-29 19:28:44 <michagogo> sipa: about that BIP stackexchange answer
381 2014-12-29 19:28:56 <michagogo> It seems weird to be to say "since v0.10.0rc1"
382 2014-12-29 19:29:07 <michagogo> You could also say "since v0.6.0rc1", for example
383 2014-12-29 19:29:28 <michagogo> seems weird to me*
384 2014-12-29 23:58:22 <michagogo> 20:21:38 <cfields> gavinandresen / wumpus: looks like i missed the code-signing fun. Any surprises?
385 2014-12-29 23:58:29 <michagogo> cfields: No, I don't think you did
386 2014-12-29 23:58:46 <cfields> michagogo: great, thanks
387 2014-12-29 23:58:47 <michagogo> I'm told Gavin just signed the os x build manually this time
388 2014-12-29 23:59:45 <cfields> ok