1 2015-02-03 00:20:00 <Hasimir> is the github issues tracker the best place for a core qt ui feature request?
  2 2015-02-03 00:21:38 <sipa> Hasimir: yes
  3 2015-02-03 00:22:23 <Hasimir> cool, I'll make sure it doesn't already exist or is planned and then if not I'll add one ...
  4 2015-02-03 00:22:30 <sipa> what is the feature?
  5 2015-02-03 00:22:44 <Hasimir> being able to specify date format
  6 2015-02-03 00:22:56 <Hasimir> for those of us who aren't yanks ...
  7 2015-02-03 00:23:48 <sipa> doesn't it obey your internationalization settings?
  8 2015-02-03 00:23:51 <sipa> it should, afaik
  9 2015-02-03 00:24:41 <Hasimir> another thing to check before raising spurious requests  ;)
 10 2015-02-03 00:24:59 <Hasimir> which may or may not need to wait for the current blockchain resync
 11 2015-02-03 00:25:16 <phantomcircuit> earlz, the answer is that it depends on what you're looking to index
 12 2015-02-03 00:25:24 <Luke-Jr> 2015-02-03 00:10:54 here
 13 2015-02-03 00:25:27 <Hasimir> it's going off disc, won't take too long ...
 14 2015-02-03 00:28:10 <Hasimir> yeah, mine's got MM/DD/YY hh:mm:ss which is somewhat irritating ...
 15 2015-02-03 00:28:29 <Luke-Jr> Hasimir: I advise not using USA locales if you are not USAian
 16 2015-02-03 00:29:21 <phantomcircuit> earlz, postgresql + recursive CTE will probably cover 99% of interesting queries
 17 2015-02-03 00:29:34 <phantomcircuit> also be sure to use partial indexes
 18 2015-02-03 00:29:46 <phantomcircuit> no need to fully index random keys
 19 2015-02-03 00:29:56 <Hasimir> I could've sworn I'd set that properly, but it turns out the VM in question hasn't been (or got reset at some point)
 20 2015-02-03 00:30:02 <Hasimir> Luke-Jr, cheers
 21 2015-02-03 00:30:15 <Luke-Jr> ☺
 22 2015-02-03 00:37:23 <earlz> hmm
 23 2015-02-03 00:37:49 <earlz> partial indexes.. I'll have to look that up
 24 2015-02-03 00:38:00 <earlz> maybe my SQL-fu just isn't good enough heh
 25 2015-02-03 00:42:22 <phantomcircuit> earlz, it's simple, you create the index over only the first say, 16 bits of the key
 26 2015-02-03 06:27:22 <michagogo> jgarzik: you scared me there.
 27 2015-02-03 06:27:34 <michagogo> ("Bitcoin Book 'The Age of Cryptocurrency' Permanently Recorded on Blockchain")
 28 2015-02-03 06:47:05 <wumpus> kind of a marketing stunt
 29 2015-02-03 06:48:05 <michagogo> wumpus: yeah, but coindesk's headline made it look like they stuffed the whole book in there
 30 2015-02-03 06:48:35 <wumpus> of course it does, that garners more clicks
 31 2015-02-03 06:49:12 <wumpus> look how controversial!
 32 2015-02-03 06:51:04 <michagogo> Hm. On one hand, people might be more likely to change the defaults if they're not mentioned
 33 2015-02-03 06:51:19 <michagogo> OTOH, people might assume it's off-by-default
 34 2015-02-03 06:51:32 <michagogo> And/or come in here to bug us asking what the defaults are
 35 2015-02-03 06:52:03 <michagogo> (Re: #5740)
 36 2015-02-03 06:52:24 <wumpus> --help is your friend then
 37 2015-02-03 06:52:36 <wumpus> really, we should aspire for the release notes to be the documentation
 38 2015-02-03 06:52:40 <wumpus> should NOT
 39 2015-02-03 06:52:54 <michagogo> Wait, this is just the release notes
 40 2015-02-03 06:52:56 <michagogo> Oops.
 41 2015-02-03 06:53:14 <unicodesnowman> michagogo, how much does blockchain storage (via OP_HASH160) cost per KB?
 42 2015-02-03 06:53:17 <wumpus> if you want to write actual documentation on the other hands, you're very welcome to include defaults and such, although those tend to be hard to keep up to date with the code
 43 2015-02-03 06:53:34 <unicodesnowman> 0.0001 BTC per KB + 5460 satoshi per 20 bytes?
 44 2015-02-03 06:54:03 <michagogo> wumpus: yeah, sorry, must have been tired last night when I commented
 45 2015-02-03 06:54:15 <michagogo> For some reason I missed that this is just the release notes
 46 2015-02-03 06:56:52 <Luke-Jr> we do have a man page; would be neat if it could be autogenerated :P
 47 2015-02-03 06:57:15 <wumpus> also the man page shouldn't be under contrib/debian
 48 2015-02-03 06:57:52 <wumpus> under doc/ would make more sense, and even install it when make install?
 49 2015-02-03 06:58:58 <Luke-Jr> yes, would be an improvement. I'm not familiar with how to do manpages with autotools, however.
 50 2015-02-03 06:59:23 <wumpus> me neither, it was just an idea :)
 51 2015-02-03 06:59:28 <fanquake> apparently lit’s been out of date for 3 years now
 52 2015-02-03 06:59:50 <Luke-Jr> >_<
 53 2015-02-03 07:00:01 <fanquake> See #1040
 54 2015-02-03 07:00:12 <wumpus> it sometimes gets updated, but I'm sure there is some out of date stuff inthere, that's always the case for software documentation
 55 2015-02-03 07:00:46 <fanquake> I was going to take a look at updating it a while back, but don’t really have enough experience with them.
 56 2015-02-03 07:01:03 <fanquake> Better to leave it to someone who’s going to be using it.
 57 2015-02-03 07:01:11 <wumpus> unfortunately we can't stop the world for a few months to finally bring all documentation up to date
 58 2015-02-03 07:01:12 <Luke-Jr> (apparently nobody)
 59 2015-02-03 07:01:52 <wumpus> manpages is likely a quite rare skill these days
 60 2015-02-03 07:02:13 <wumpus> if only they were written in markdown :-)
 61 2015-02-03 07:02:16 <phantomcircuit> wumpus, it is but it's really not very complicated
 62 2015-02-03 07:02:37 <fanquake> wumpus then we’d have hundreds of experts to help us out :p
 63 2015-02-03 07:02:48 <phantomcircuit> er uh i wasn't volunteering
 64 2015-02-03 07:02:52 <wumpus> fanquake: exactly
 65 2015-02-03 07:02:54 <phantomcircuit> 
ACTION flees the scene of the manpage

 66 2015-02-03 07:03:26 <Luke-Jr> 
ACTION ties phantomcircuit to the manpage until it's up to date.

 67 2015-02-03 07:03:27 <wumpus> phantomcircuit: yes, you realize that saying something is not complicated is akin to volunteering, because it means you're the right person for the job :p
 68 2015-02-03 07:04:28 <fanquake> #5719 Can get some testing now that it’s been rebased.
 69 2015-02-03 07:05:09 <wumpus> Corrupted MAC on input. Disconnecting: Packet corrupt 2015-02-03 08:04:40,259 Connection lost  .. ssh is glitching on me, stop that MiTM attack please I'm trying to get work done
 70 2015-02-03 07:05:37 <wumpus> fanquake: ok, will take a look
 71 2015-02-03 07:05:57 <phantomcircuit> the debian ones look suspiciously like they were built with a wysiwyg
 72 2015-02-03 07:07:19 <phantomcircuit> wumpus, wifi?
 73 2015-02-03 07:07:20 <Luke-Jr> lol
 74 2015-02-03 07:08:14 <phantomcircuit> http://aaa-sec.com/nroffedit/
 75 2015-02-03 07:09:34 <wumpus> phantomcircuit: yes, it's simply due to corruption on the wifi network, but the error message is kind of worrying :)
 76 2015-02-03 07:10:10 <fanquake> #5739 is also pretty trivial
 77 2015-02-03 07:10:17 <phantomcircuit> wumpus, means you got supppper unlucky
 78 2015-02-03 07:10:33 <phantomcircuit> corrupt packet got past the 802.11 checksums
 79 2015-02-03 07:10:36 <phantomcircuit> and the tcp checksum
 80 2015-02-03 07:10:49 <phantomcircuit> that's probably on the order of 1:2^64
 81 2015-02-03 07:11:02 <Luke-Jr> phantomcircuit: or someone really is MITMing him
 82 2015-02-03 07:11:53 <phantomcircuit> but afaik you cant
 83 2015-02-03 07:11:53 <phantomcircuit> wumpus, i'd ask you to check what versions of 802.11 you're using
 84 2015-02-03 07:13:51 <wumpus> phantomcircuit: whoa, that makes me one unlucky bastard. It's ok, must be karma :)
 85 2015-02-03 07:14:38 <phantomcircuit> well
 86 2015-02-03 07:14:47 <phantomcircuit> the numerator is potentially also a large value
 87 2015-02-03 07:16:38 <gmaxwell> tcpchecksum is very weak.
 88 2015-02-03 07:17:00 <gmaxwell> it's 16 bits but really more like an 8 bit check for typical packet sizes.
 89 2015-02-03 07:17:10 <gmaxwell> Ethernet checksum is a quite strong 32 bit crc however.
 90 2015-02-03 07:17:33 <phantomcircuit> and then the wifi physical layer will have some sort of FEC and checksums
 91 2015-02-03 07:17:48 <phantomcircuit> but what that is depends on exactly which transport you've negotitated
 92 2015-02-03 07:18:55 <wumpus> indeed - the numerator is also a large value, I send quite a lot of data through it
 93 2015-02-03 07:21:04 <wumpus> phantomcircuit: but that's carefully hidden from us puny users, I suppose?
 94 2015-02-03 07:21:38 <phantomcircuit> wumpus, in theory you can figure it out with `iw` but in practice there's too many options and stuff to have any idea what the hells going on
 95 2015-02-03 07:24:51 <wumpus> yes, that's quite an extensive tool, naively typing 'iw info' on either the client or the router doesn't tell it at least
 96 2015-02-03 07:26:26 <b-itcoinssg> when a node receives a broadcasted tx for an artbitary address A, does it have to scan the entire blockchain to verify that the inputs have not already been spent? and if so, how come the cli does not provide an option to directly check balances of address that are not imported(private key).
 97 2015-02-03 07:27:20 <phantomcircuit> wumpus, iw dev wlan0 station info
 98 2015-02-03 07:27:33 <phantomcircuit> er wrong one
 99 2015-02-03 07:28:54 <phantomcircuit> wumpus, iw dev wlan0 link
100 2015-02-03 07:30:35 <phantomcircuit> wumpus, oh right
101 2015-02-03 07:30:45 <phantomcircuit> yeah there's a bunch of parameters that you can set but not read
102 2015-02-03 07:30:49 <phantomcircuit> forgot about that
103 2015-02-03 07:31:40 <wumpus> phantomcircuit: http://0bin.net/paste/v5bHrqHrbGaiCSSH#OLcR5PKnLhXYClM+AUguD4z0K+cir78-LCWxiQMddHt
104 2015-02-03 07:32:30 <phantomcircuit> wumpus, 802.11n
105 2015-02-03 07:33:04 <phantomcircuit> 64-QAM
106 2015-02-03 07:35:01 <phantomcircuit> wumpus, so yeah you're pretttty unlucky there
107 2015-02-03 07:36:12 <wumpus> thanks :) good to know
108 2015-02-03 07:36:58 <phantomcircuit> otoh you have a true 802.11n network reporting as 130mbps
109 2015-02-03 07:37:37 <phantomcircuit> heh
110 2015-02-03 07:37:41 <gmaxwell> b-itcoinssg: thats really a bitcoin101 question, no more on-topic than the modulation debate... in the future please take questions like that to #bitcoin, but the answer is that it does not; that would be insane and completely inefficient. It just has to check if the transactions particular input txids exist for spending in the system.
111 2015-02-03 07:46:17 <wumpus> b-itcoinssg: to find the 'balance for an address', you'd at most need to scan over the utxo set, the reason for a full rescan on import is that the wallet tries to get the full history of transactions involving a key, not just the unspent ones
112 2015-02-03 08:02:03 <b-itcoinssg> thank you
113 2015-02-03 08:02:19 <wumpus> a minimalistic wallet wouldn't need to retain (or scan for) transactions with fully-spent outputs at all, they are not necessary for spending
114 2015-02-03 08:06:07 <b-itcoinssg> ok
115 2015-02-03 08:06:19 <Luke-Jr> it would need to index the UTXO set by script, however, and it should probably be noted that the scriptPubKey is not in itself an address (although an address can be derived from it, the address's relationship is not "linked" to the UTXO created, thus talking about "from address" or "address balance" is nonsensical)
116 2015-02-03 08:08:18 <wumpus> it doesn't *need* that, it could just do a linear scan over the utxo set, an index is just an optimization
117 2015-02-03 08:08:47 <Luke-Jr> sure, but to perform reasonably
118 2015-02-03 08:08:54 <b-itcoinssg> thnx, I knew that part (about scriptPubKey and address and that "from address" is nonsensical), poor wording on my part
119 2015-02-03 08:09:17 <wumpus> for e.g. occasionally importing a key, scanning the utxo set would be lots faster than scanning the block chain
120 2015-02-03 08:09:43 <wumpus> not that importing keys is something to be encouraged anyway
121 2015-02-03 08:09:50 <Luke-Jr> yes, it'd be a handy way to do the sweep function ;)
122 2015-02-03 08:10:02 <wumpus> right
123 2015-02-03 08:10:56 <Luke-Jr> 
ACTION ponders how a sweep ought to handle multiple outputs to the same script

124 2015-02-03 08:11:28 <Luke-Jr> 1) include them all as inputs in a single tx, 2) create a dedicated tx for each of them, or 3) only grab the largest valued one
125 2015-02-03 08:11:53 <sipa> they're already provably linked
126 2015-02-03 08:11:56 <Luke-Jr> 3 seems "safest", but compared to 1 might result in spammy sweeping
127 2015-02-03 08:12:07 <sipa> it's more efficient to grab them all and combine them
128 2015-02-03 08:12:10 <Luke-Jr> sipa: yes, I'm thinking to avoid multiple signatures for security
129 2015-02-03 08:12:19 <wumpus> just grab them all in one go
130 2015-02-03 08:12:30 <wumpus> unless they're dust
131 2015-02-03 08:13:07 <wumpus> (ie, if it costs more in fees to add them to the transaction, don't bother)
132 2015-02-03 08:13:44 <Luke-Jr> hm, that prioritises the user over the UTXO set bloat
133 2015-02-03 08:15:03 <Luke-Jr> but NOT doing it makes a straightforward attack (send dust to addresses so they sweep away)
134 2015-02-03 08:15:44 <Luke-Jr> perhaps the real problem is not properly accounting for miners ignoring dust-cleanup in size
135 2015-02-03 08:16:50 <wumpus> heck: show a dialog with a list of checkboxes and let the user choose what to include in the transaction
136 2015-02-03 08:18:03 <Luke-Jr> that seems a bit much for something that shouldn't normally occur (multiple outputs with the same key)
137 2015-02-03 08:18:23 <Luke-Jr> (even as common as address reuse can be, I don't think I've seen it in the sweep-key scenario)
138 2015-02-03 08:21:20 <gmaxwell> Luke-Jr: priority credits dust cleanup by default...
139 2015-02-03 08:21:22 <wumpus> I agree. sweeping should just be sweeping, not pick-and-choose, otherwise people could be tempted to genius ideas like sweeping the same 'one time key' multiple times
140 2015-02-03 08:21:55 <wumpus> although, that's still possible of course, sweep, then send new coins to it, sweep again, blah :)
141 2015-02-03 08:28:45 <wumpus> 'this new gun automatically recognises your own feet and refuses to shoot at it'
142 2015-02-03 08:30:01 <gmaxwell> heh
143 2015-02-03 08:30:45 <b-itcoinssg> lol
144 2015-02-03 08:31:00 <Luke-Jr> 
ACTION pondering how to technically implement that

145 2015-02-03 08:33:20 <justanotheruser> gyroscope determining what angle it's pointed at
146 2015-02-03 08:33:35 <Luke-Jr> maybe it could use a super-sensitive microphone to figure distance from your heartbeat, and just not fire down within a foot
147 2015-02-03 08:34:30 <gmaxwell> obviously it should shine a powerful xray beam, and fingerprint the bone structure in your foot from the backscatter.
148 2015-02-03 08:34:44 <Luke-Jr> hah
149 2015-02-03 08:34:57 <Luke-Jr> but a bonus to heartbeat tracking, it could double as an aimbot!
150 2015-02-03 08:35:22 <Luke-Jr> "hits the heart, every time"
151 2015-02-03 08:36:45 <wumpus> gmaxwell: of course not, way to practical, it would first launch a long projecting arm, sample the DNA, and only shoot if it doesn't match your own
152 2015-02-03 08:38:02 <jonasschnelli> needs MAC tag: https://github.com/bitcoin/bitcoin/issues/5741, https://github.com/bitcoin/bitcoin/issues/5728
153 2015-02-03 08:38:19 <jonasschnelli> needs GUI tag: https://github.com/bitcoin/bitcoin/issues/5738, https://github.com/bitcoin/bitcoin/issues/5737
154 2015-02-03 08:38:33 <jonasschnelli> GUI+: https://github.com/bitcoin/bitcoin/issues/5725
155 2015-02-03 08:39:02 <b-itcoinssg> bullet proof shoes? deactivate firing if target closer than 1-3 feet using simple lazers :-P
156 2015-02-03 08:39:14 <jonasschnelli> this could get merged: https://github.com/bitcoin/bitcoin/pull/5729
157 2015-02-03 08:40:02 <jonasschnelli> needs also a GUI tag: https://github.com/bitcoin/bitcoin/issues/5722
158 2015-02-03 08:40:51 <wumpus> jonasschnelli: do we really need multiple 'mac compilation fails' issues, or could they be merged as duplicate?
159 2015-02-03 08:41:29 <jonasschnelli> wumpus, i don't care. :) i would close the second one and refer to the first one
160 2015-02-03 08:41:36 <paveljanik> wumpus, these are two different issues...
161 2015-02-03 08:41:48 <wumpus> I mean we get the point now, compilation on macosx fails
162 2015-02-03 08:42:02 <paveljanik> But I think the leveldb missing one is an user issue.
163 2015-02-03 08:42:33 <jonasschnelli> wumpus, i can't follow this issue. I did a fresh checkout after the readme and didn't ran into problems.
164 2015-02-03 08:45:28 <paveljanik> 5741 - user is doing something weird - building in a separate tree, missing leveldb directory - I'd close this...
165 2015-02-03 08:45:41 <Luke-Jr> b-itcoinssg: or maybe bullets that don't affect feet
166 2015-02-03 08:47:07 <Luke-Jr> wow, 5741 looks really crazy
167 2015-02-03 08:47:23 <paveljanik> 5728 - it is a Qt bug, workaround is known (and applied already in brew) and applies to both macports and Qt's original installer. So this can be closed as well IMO.
168 2015-02-03 08:47:38 <b-itcoinssg> Luke-Jr: lol, odor deterrent bullets
169 2015-02-03 08:48:27 <paveljanik> it would be nice to have some bot expanding e.g. #5728 to "Mac OS X compilation with qt5 (and qt4) fails"...
170 2015-02-03 08:48:48 <jonasschnelli> then someone should add a "UPSTREAM" tag to https://github.com/bitcoin/bitcoin/issues/5728
171 2015-02-03 08:48:53 <wumpus> Luke-Jr: all of the above, just include all the safety features we can think of, and more. We can't have any foot being shot ever again!
172 2015-02-03 08:50:30 <wumpus> yes, 5741 looks crazy
173 2015-02-03 08:51:56 <wumpus> in principle, github issues is not a help forum, if it's not clearly a buildsystem issue then it shouldn't be open
174 2015-02-03 08:52:11 <jonasschnelli> wumpus, agreed totally.
175 2015-02-03 08:53:52 <jonasschnelli> I mean if someone does manipulate tested installing paths, then he should be able to sort it out by himself or get help on a form, IRC, etc.
176 2015-02-03 08:54:19 <jonasschnelli> Or the issue tracker is getting a ask-everything portal
177 2015-02-03 08:54:36 <Luke-Jr> StackOverflow <.<
178 2015-02-03 08:54:40 <paveljanik> +1
179 2015-02-03 08:54:45 <Luke-Jr> or was it StackExchange? I forget
180 2015-02-03 08:55:21 <jonasschnelli> what ever stack but the help-me-building-issues should not hide important issues
181 2015-02-03 08:55:21 <wumpus> yes
182 2015-02-03 08:55:53 <wumpus> way too many issues already, and despite all the work put into it it only keeps growing :/
183 2015-02-03 08:56:50 <jonasschnelli> wumpus, slowly i understand the need for splitting things into multiple repositories.
184 2015-02-03 08:58:25 <wumpus> yeah... it's also too bad that github doesn't have more granular access control
185 2015-02-03 08:59:06 <paveljanik> maybe we can ask them for a role to "Allow adding labels"...
186 2015-02-03 08:59:12 <wumpus> there should be an option to give people access to labeling/closing issues without push access to the underlying repository
187 2015-02-03 08:59:19 <jonasschnelli> 
ACTION wonders if it makes sense that the RPC tests are connected to each other by mining one time into cache at the very beginning.

188 2015-02-03 08:59:20 <wumpus> paveljanik: I did ask for that
189 2015-02-03 08:59:44 <paveljanik> and the reply from them was?
190 2015-02-03 09:00:03 <wumpus> the usual, thanks for the idea we may take it into account but no guarantee
191 2015-02-03 09:00:43 <paveljanik> I'll ask them using my contacts there - do you have a ticket number?
192 2015-02-03 09:00:52 <wumpus> no
193 2015-02-03 09:01:25 <wumpus> but it probably helps if multiple people ask
194 2015-02-03 09:02:16 <wumpus> jonasschnelli: well that used to make sense, but I suppose regtest 'mining' has been optimized a lot since then
195 2015-02-03 09:02:38 <wumpus> jonasschnelli: but the only way to figure that out would be to benchmark
196 2015-02-03 09:03:05 <jonasschnelli> wumpus, i just hat the situation where a previous test did made the upcomming test fail because the prev. test spent all coins. This could somehow be dangerous.
197 2015-02-03 09:03:08 <wumpus> if there is substantial time win to caching the test's starting state we should definitely keep it
198 2015-02-03 09:03:15 <wumpus> jonasschnelli: eh that shouldn't happen!
199 2015-02-03 09:03:41 <wumpus> jonasschnelli: it should copy the starting state (after initial mining) not cache the eventual messed up state after the test
200 2015-02-03 09:03:42 <jonasschnelli> wumpus, but it happened. I have to dive in there... i assume there is no real uncaching, re-coping of the cache
201 2015-02-03 09:04:36 <wumpus> jonasschnelli: yes sdaftuar_ had the same problem at some point while testing BIP66, version 3 blocks somehow ended up in the cache
202 2015-02-03 09:05:13 <wumpus> so - if - there is now hardly any performance win from caching, may be better to disable it
203 2015-02-03 09:05:19 <jonasschnelli> wumpus, maybe i find time to look at this.
204 2015-02-03 09:06:15 <jonasschnelli> i think by disabling cache it might run in a timeout on the CI. All tests then mine 101 blocks. That would be +1010 blocks mining for every testrun.
205 2015-02-03 09:06:53 <wumpus> yes, but remember regtest mining is a very tight loop now, 100 blocks may be really fast
206 2015-02-03 09:07:16 <jonasschnelli> It's pretty fast. But i have no clue how many ticks we can/should use on travis.
207 2015-02-03 09:08:49 <wumpus> ok
208 2015-02-03 09:10:00 <wumpus> BlueMatt: haha "utACK non-test changes"
209 2015-02-03 09:10:50 <Luke-Jr> I interpreted that to mean the same as mine.
210 2015-02-03 09:14:13 <wumpus> yes, but it reads pretty funny
211 2015-02-03 09:15:25 <wumpus> (especially if you invert it; testing the test changes seems like the most straightforward)
212 2015-02-03 09:17:50 <xabbix> How does a critical vulnerability addressed in the bitcoin-core? If someone reported a critical bug and you apply a fix for it via the github repo, any node can be exploited until they update their software and the attacker has the source code change to know how to exploit it
213 2015-02-03 09:19:06 <wumpus> you'd report the vulnerability GPG-encrypted to one or more of the core developers, not through github issues
214 2015-02-03 09:19:29 <wumpus> (the bitcoin.org page should mention that somewhere, or at least used to)
215 2015-02-03 09:19:29 <xabbix> Yes, I'm referring to the fixing process, not the reporting part.
216 2015-02-03 09:19:59 <jonasschnelli> xabbix, see https://bitcoin.org/en/development (Responsible disclosure)
217 2015-02-03 09:20:35 <xabbix> I'm saying, if you fix a bug, people can see what you've fixed and use it to attack nodes
218 2015-02-03 09:20:38 <wumpus> well that's always the problem with software patching isn't it? the patch itself reveals the problem, there's whole companies analyzing code differences
219 2015-02-03 09:21:13 <xabbix> Yes I agree this is not really related to bitcoin specifically. Just wondering what happened in the past when you guys fixed these sort of bugs
220 2015-02-03 09:21:17 <xabbix> was it simply not exploited?
221 2015-02-03 09:21:25 <Luke-Jr> xabbix: sometimes you can hide a tree in a forest
222 2015-02-03 09:21:37 <wumpus> then again - if you don't know that something is a security fix, you may not even think about exploiting it
223 2015-02-03 09:21:41 <wumpus> exactly Luke-Jr
224 2015-02-03 09:22:05 <xabbix> so you coordinate between yourselves how to fix it in a way that would raise the least suspicion
225 2015-02-03 09:22:25 <Luke-Jr> why do you assume it needs coordination? :p
226 2015-02-03 09:22:40 <wumpus> between the developer and the reporter of the bug, at least
227 2015-02-03 09:22:41 <Luke-Jr> lots of bugs get fixed and only later do people realise there were security implications
228 2015-02-03 09:23:09 <xabbix> ok, cool..
229 2015-02-03 09:23:10 <xabbix> thanks
230 2015-02-03 09:40:06 <wumpus> let's tag rc4 today?
231 2015-02-03 09:40:45 <wumpus> weird - can anyone find the actual failure in the travis output of https://github.com/bitcoin/bitcoin/pull/5721?
232 2015-02-03 09:43:55 <jonasschnelli> wumpus, i had a look at it... did also a gitian build of 5721...
233 2015-02-03 09:44:54 <jonasschnelli> looks good IMO: https://bitcoin.jonasschnelli.ch/pulls/5721/build-linux.log
234 2015-02-03 09:44:58 <wumpus> I couldn't find any error in the output... then again, travis web page is extremely slow here so I may have missed something
235 2015-02-03 09:45:33 <jonasschnelli> wumpus, i just followed the last line ... it could be during the init.cpp shutdown
236 2015-02-03 09:45:51 <jonasschnelli> last reported line was: https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L141
237 2015-02-03 09:46:03 <jonasschnelli> and the PR did introduced a mutex
238 2015-02-03 09:46:50 <jonasschnelli> last reported line is "2015-01-28 20:27:11 Unlocked: cs_Shutdown  init.cpp:141"
239 2015-02-03 09:46:57 <jonasschnelli> then "make[2]: *** [check-local] Error 1"
240 2015-02-03 09:47:04 <wumpus> so an error from *make*?
241 2015-02-03 09:47:22 <jonasschnelli> from make check aka src/test/test_bitcoin
242 2015-02-03 09:47:35 <wumpus> anyhow, this warrants additional scrutiny, may not be ready for 0.10
243 2015-02-03 09:47:39 <wumpus> ah right
244 2015-02-03 09:47:45 <jonasschnelli> is looks like a crash during test_bitcoin
245 2015-02-03 09:48:24 <jonasschnelli> i would untag 0.10 #5721
246 2015-02-03 09:48:26 <wumpus> replacing e.g. a race condition by a deadlock is no way forward
247 2015-02-03 09:48:29 <wumpus> right
248 2015-02-03 09:48:43 <jonasschnelli> it's not blocking 0.10
249 2015-02-03 09:49:26 <wumpus> no, it shouldn't
250 2015-02-03 09:49:33 <wumpus> removed the milestone
251 2015-02-03 09:50:16 <Luke-Jr> 5729 maybe
252 2015-02-03 09:53:07 <wumpus> yeah why not
253 2015-02-03 09:53:47 <jonasschnelli> hmmm... i we are in rc4 stage? why adding features?
254 2015-02-03 09:54:03 <jonasschnelli> but 5729 is painless.
255 2015-02-03 09:54:06 <wumpus> features?
256 2015-02-03 09:54:35 <wumpus> it's not like someone is proposing merging autoprune or such :p
257 2015-02-03 09:54:36 <jonasschnelli> 5729 could be seen as feature. And nobody testes it with the 0.10 branch. The master is way ahead
258 2015-02-03 09:55:16 <jonasschnelli> but i assume it won't bring up any Qt-bug-chars-issue... :)
259 2015-02-03 09:55:31 <wumpus> well it's fixing a problem as well, not being able to show read-only amounts in different units
260 2015-02-03 09:55:53 <wumpus> just a matter of how you word it, and it's a trivial one-line GUI change, so we're not going to make a problem out of this
261 2015-02-03 09:56:40 <jonasschnelli> yes. i agree. On the other hand this is rc4 stage...
262 2015-02-03 09:57:40 <wumpus> ok, anything else?
263 2015-02-03 09:58:14 <wumpus> https://github.com/bitcoin/bitcoin/milestones/0.10.0 is clear
264 2015-02-03 09:59:09 <Luke-Jr> how about 4701
265 2015-02-03 09:59:22 <Luke-Jr> :P
266 2015-02-03 09:59:50 <jonasschnelli> :)
267 2015-02-03 10:02:45 <wumpus> lol
268 2015-02-03 11:15:13 <rubensayshi> does anyone know if I can find one of the main contributors of bitcoinjs-lib here on IRC? (Daniel Cousens, Wei Lu, JP Richardson and Kyle Drake)
269 2015-02-03 11:17:01 <jonasschnelli> Luke-Jr, wy did you once add the BDB Mock? (https://github.com/bitcoin/bitcoin/commit/148e107da6f3e0f477e773cc3a3cb882ff53dab4) was it because of performance or CI issues?
270 2015-02-03 11:17:29 <jonasschnelli> context: wallet (and also tests) modularization
271 2015-02-03 11:19:12 <wumpus> rubensayshi: no, no idea
272 2015-02-03 11:19:22 <unicodesnowman> rubensayshi, doubt it
273 2015-02-03 11:19:26 <unicodesnowman> try github pull issue.
274 2015-02-03 11:19:29 <wumpus> there's not much bitcoinjs talk in this channel at least
275 2015-02-03 11:19:36 <wumpus> but they may have their own channel
276 2015-02-03 11:19:57 <rubensayshi> yea, guess I'll go try another aproach, was hoping one of them might be lurking in this channel like many do :)
277 2015-02-03 11:21:17 <rubensayshi> oh there's a #bitcoinjs-dev, I tried all the variations i could think of #bitcoinjs-lib xD
278 2015-02-03 11:32:33 <unicodesnowman> Is there a way to force bitcoin core to make the change address the last address?
279 2015-02-03 11:32:36 <unicodesnowman> (an easy way)
280 2015-02-03 11:34:39 <unicodesnowman> I'm happy to recompile
281 2015-02-03 11:35:14 <jonasschnelli> unicodesnowman, why would you do this?
282 2015-02-03 11:36:42 <unicodesnowman> jonasschnelli, proofofexistance.com-styled service, the order of the outputs is ruined by the change output
283 2015-02-03 11:38:13 <jonasschnelli> so you are using createrawtransaction over RPC?
284 2015-02-03 11:39:24 <unicodesnowman> no, I'm using sendmany and encoding data in OP_HASH160
285 2015-02-03 11:40:13 <jonasschnelli> unicodesnowman, i assume you could change that on this line:
286 2015-02-03 11:40:14 <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/wallet.cpp#L1471
287 2015-02-03 11:40:43 <jonasschnelli> instead of txNew.vout.insert(position, newTxOut); use txNew.vout.push_back(newTxOut);
288 2015-02-03 11:40:43 <unicodesnowman> jonasschnelli, thanks so much :)
289 2015-02-03 11:40:55 <jonasschnelli> and rm L1471
290 2015-02-03 11:41:14 <jonasschnelli> happy compiling...
291 2015-02-03 12:02:34 <wumpus> unicodesnowman: no, I'm using sendmany and encoding data in OP_HASH160 <- why not OP_RETURN?
292 2015-02-03 13:32:39 <sdaftuar_> wumpus, jonasschnelli: i went through the logs when the travis failure for #5721 showed up, the java comparison tool fails with "bitcoind disconnected"
293 2015-02-03 13:34:35 <jgarzik> michagogo, heh
294 2015-02-03 13:34:54 <sdaftuar_> it was the job that had DEBUG_LOCKORDER on, hence the debug log shows all the lock acquires/releases -- that isn't related to the test failure
295 2015-02-03 13:36:31 <sdaftuar_> at any rate i was going to try making cfields' suggested change today which should bump travis again
296 2015-02-03 13:40:42 <jonasschnelli> sdaftuar_, Okay. Lets wait for fields.
297 2015-02-03 13:53:16 <ThomasV> the pypi AES package contains malware: https://pypi.python.org/pypi/aes/1.2
298 2015-02-03 13:53:24 <ThomasV> see what the aes.py file is doing
299 2015-02-03 13:55:37 <wumpus> bleh, too much crap on pypi, people should just use pycrypto for aes
300 2015-02-03 14:01:55 <xeroc> IUs anyone aware of a python snippet that recovers the ecc pubkey from a ecc signature?
301 2015-02-03 14:02:27 <wumpus> python-bitcoinlib probably has something in that regard
302 2015-02-03 14:03:01 <xeroc> thanks .. gonna take a look
303 2015-02-03 14:06:56 <jonasschnelli> supporting legacywallet and the new wallet format at the same time is a NIGHTMARE.
304 2015-02-03 14:09:01 <jonasschnelli> completion is around 50%, but i guess there is no big interest in reviewing pulls huge like this: https://github.com/bitcoin/bitcoin/pull/5686
305 2015-02-03 14:12:48 <wumpus> jonasschnelli: I'm sure there is interest if the new wallet brings all kind of fun new features
306 2015-02-03 14:13:33 <jonasschnelli> wumpus, yes. But moving everything in src/legacywallet and src/wallet is a very big changeset and could have some risks
307 2015-02-03 14:13:57 <jonasschnelli> wumpus, then the whole Qt parts need to decouple form CWallet / CWalletTX
308 2015-02-03 14:14:01 <wumpus> jonasschnelli: but will it have less risks than forcing everyone to migrate to the new wallet in one go?
309 2015-02-03 14:14:34 <wumpus> those are kind of the options - support both at the same time for a while, or cook this on a side branch until completely ready and migrate everyone
310 2015-02-03 14:14:51 <jonasschnelli> wumpus, both formats would have less risks. But there the risk is, that it will never flies because of missing reviews/testing.
311 2015-02-03 14:15:13 <wumpus> yes, the rpc part is quite straightforward, but the qt sounds like kind of a nightmare yes
312 2015-02-03 14:15:16 <jonasschnelli> flies/flys
313 2015-02-03 14:16:30 <wumpus> that is indeed a risk
314 2015-02-03 14:16:55 <jonasschnelli> wumpus, RPC: exmaple: validate_address, there is a #ifdef for ENABLE_WALLET where – if the wallet is enable – it will extend the json with some ISMINE things... for now i will just duplicate the method instead of signaling within the validate_address command. Otherwise it's getting really complex and will affect the legacy code to much imo
315 2015-02-03 14:17:05 <wumpus> but you knew that upfront, and that's the case no matter how this is done
316 2015-02-03 14:17:17 <wumpus> maybe you can do some prepratory pulls first?
317 2015-02-03 14:17:40 <jonasschnelli> wumpus, yes. I'm not disappointed when i have to throw away the whole changeset.
318 2015-02-03 14:17:54 <wumpus> that e.g. modularize things enough, move the old wallet already, and so on
319 2015-02-03 14:18:16 <wumpus> step by step, instead of one code drop
320 2015-02-03 14:18:24 <jonasschnelli> wumpus, the whole thing is really connected together, introducing a modularisation like mentioned in 3440 needs a big-changeset/clean cut
321 2015-02-03 14:19:13 <wumpus> ok was just meant as advice, I've found that it usually helps to get some changes in (e.g. for the bigendian work, it's still not been merged but the worst part has been merged, the current patch is easy to keep up to date)
322 2015-02-03 14:19:20 <jonasschnelli> it would be possible to introduce some rpc changes first, dynamic dispatch table, etc.
323 2015-02-03 14:19:59 <wumpus> even though effectively it didn't change anything yet, same for the RPC lock pushdown pull
324 2015-02-03 14:20:03 <wumpus> indeed!
325 2015-02-03 14:20:12 <jonasschnelli> yes. Maybe i have to produce some decouple PRs first
326 2015-02-03 14:21:00 <wumpus> I'm going to do the same for the RPC HTTP server change, first factor out the HTTP server from the rest of the RPC stuff, then make it replacable with evhttp-based implementation
327 2015-02-03 14:21:02 <jonasschnelli> okay. I'll try to slice out some independent changes and create PRs (one by one)
328 2015-02-03 14:21:26 <wumpus> ok great
329 2015-02-03 14:22:08 <jonasschnelli> the ENABLE_WALLET macro tend to be a modularization killer
330 2015-02-03 14:22:32 <wumpus> yes, it sucks
331 2015-02-03 14:22:38 <jonasschnelli> (but at least it points out the glued parts)
332 2015-02-03 14:24:50 <wumpus> right - making it possible to compile without-wallet mode identified the parts that touch the wallet
333 2015-02-03 14:25:54 <wumpus> for some RPCs e.g. getinfo it is really stupid, and we should get rid of the wallet-related information there at some point
334 2015-02-03 14:26:20 <wumpus> (well, let me phrase that differently, getinfo itself should go)
335 2015-02-03 14:27:35 <wumpus> also e.g. signtransaction implicitly uses the wallet, which will be something to think about
336 2015-02-03 14:27:58 <wumpus> for the new wallet I'd expect a wallet-specific signtranaction call
337 2015-02-03 14:29:48 <wumpus> the raw tx api signtransaction RPC can then be turned into a pure utility function
338 2015-02-03 14:30:20 <jonasschnelli> wumpus, signrawtransaction is painless with signaling because it only needs a KeyStore... so i added a NeedKeystoreForSigning signal.
339 2015-02-03 14:30:59 <jonasschnelli> but IMO it's more flexible and controllable if the rpc table can be overwritten with a new function.
340 2015-02-03 14:31:31 <jonasschnelli> without wallet, signrawtx does have no wallet related code, the wallet could overwrite this function by providing the whole function again including the wallet code.
341 2015-02-03 14:34:41 <rubensayshi> hmm, I guess there's no other way to know that a signature matches a pubKey without really verifying the signature using the pubKey and the hash it signed?
342 2015-02-03 14:40:40 <wumpus> jonasschnelli: but with multiwallet, you'd need a per-wallet call anyhow
343 2015-02-03 14:41:07 <wumpus> so having a global function with side effects really doesn't make sense anymore, for the new wallet
344 2015-02-03 14:42:04 <jonasschnelli> wumpus, because a reference of a empty CBasicKeystore will be passed through the connected signal instances, each wallet could add his keys to the keystore... which could end up in a security nightmare...
345 2015-02-03 14:42:10 <wumpus> there should be no need to overwrite functions for the new wallet; sure, for the legacy wallet you'd need some compatibility hook, until we drop that
346 2015-02-03 14:42:17 <wumpus> jonasschnelli: don't do that
347 2015-02-03 14:42:29 <wumpus> look up 'confused deputy problem' :)
348 2015-02-03 14:43:41 <jonasschnelli> yes. It's a bad design....
349 2015-02-03 14:43:50 <jonasschnelli> the magic of signratx lies in SignSignature(keystore, prevPubKey, mergedTx, i, nHashType);
350 2015-02-03 14:44:25 <jonasschnelli> so calling this somehow within every connected wallet unless tx is complete could do the job..
351 2015-02-03 14:45:09 <jonasschnelli> but multiwallet support should not mean, have multiple module connected to bitcoind.
352 2015-02-03 14:45:15 <wumpus> yes - so as said, you'd split it into a global 'signrawtransaction' function, which always has to be passed a keystore
353 2015-02-03 14:45:30 <jonasschnelli> I more see one module where within the code there could be support for multiple wallet objects (files)
354 2015-02-03 14:45:40 <wumpus> and a wallet function that applies to a specific wallet
355 2015-02-03 14:45:48 <wumpus> eg, wallet.signrawtransaction for example
356 2015-02-03 14:45:55 <wumpus> (wallet, bla, bla...)
357 2015-02-03 14:46:22 <jonasschnelli> the wallet specific function could be triggered by signaling. yes
358 2015-02-03 14:46:27 <wumpus> yes, of course, it'd be one 'module' that doesn't change my argument
359 2015-02-03 14:46:51 <wumpus> the newwallet module would register for the 'wallet.signrawtransaction' RPC call but not the global one
360 2015-02-03 14:47:23 <jonasschnelli> yes. or somehow replace the global one and allow a possibility to call the rewritten/super function
361 2015-02-03 14:47:42 <wumpus> that's the way it should have been from the beginning, and we now have an oppertunity to do it better, there should be (after legacywallet is removed) no RPC calls that have different functionality depending on whether wallet is enabled or not
362 2015-02-03 14:47:49 <wumpus> no, do not replace the global one
363 2015-02-03 14:47:58 <wumpus> the global one must become a pure utility function eventually
364 2015-02-03 14:48:15 <jonasschnelli> yes. Agreed.
365 2015-02-03 14:48:34 <wumpus> so sure, for legacywallet you'll have to temporarily introduce some ugly hook mechanism
366 2015-02-03 14:48:37 <wumpus> but not for the new wallet
367 2015-02-03 14:48:38 <jonasschnelli> But this would mean to have some interface within the global signrawtx call... signaling or a abstract module/wallet interface
368 2015-02-03 14:49:06 <jonasschnelli> what kind of interface would you see between global and module specific call?
369 2015-02-03 14:49:08 <wumpus> no, the global signtx RPC will not know anything about wallets, it will *always* want a keystore
370 2015-02-03 14:49:12 <wumpus> none
371 2015-02-03 14:49:21 <jonasschnelli> just request a keystone?
372 2015-02-03 14:49:25 <wumpus> yes
373 2015-02-03 14:49:35 <jonasschnelli> okay. this is like i have it now.
374 2015-02-03 14:49:46 <jonasschnelli> But what if there are multiple module who act as wallet?
375 2015-02-03 14:49:58 <jonasschnelli> merging keystores is a nogo
376 2015-02-03 14:50:05 <wumpus> so, as I said, 'signrawtransaction' should be a pure utility function, it knows nothing about wallets, has no side effects, and just uses the keystore that is passed to it
377 2015-02-03 14:50:33 <wumpus> the wallet specific signrawtransaction, as introduced with newwallet, will do a sign of a transaction with the specfied wallet, it can not be passed a keystore
378 2015-02-03 14:50:51 <wumpus> it will take an identifier which wallet to use
379 2015-02-03 14:51:14 <wumpus> so wallet_signrawtransaction 'myfirstwallet' '234234234....'
380 2015-02-03 14:51:32 <jonasschnelli> aha.. you would even expose the wallet_ to the user...
381 2015-02-03 14:51:36 <wumpus> of course
382 2015-02-03 14:51:47 <wumpus> yes, the wallet RPC calls should be in a separate namespace
383 2015-02-03 14:51:48 <jonasschnelli> i had the idea to keep the "signrawtransaction" call and fizzle around within the command
384 2015-02-03 14:51:50 <wumpus> no
385 2015-02-03 14:51:55 <jonasschnelli> right. That's better
386 2015-02-03 14:52:09 <wumpus> I've been tryiing to discourage you from that for the last ~10 minutes :p
387 2015-02-03 14:52:31 <jonasschnelli> so do the same for legacywallet? like legacywallet_signrawtransaction? This would probably break exiting apps who are consumers of the rpc?
388 2015-02-03 14:52:35 <wumpus> no
389 2015-02-03 14:52:42 <jonasschnelli> wumpus, sorry for my not understanding... :)
390 2015-02-03 14:52:42 <wumpus> for the legacywallet, wel'll have to keep the old interface for now
391 2015-02-03 14:52:48 <wumpus> but not for the new wallet
392 2015-02-03 14:53:05 <jonasschnelli> okay.... so having two signrawtx functions... yes. why not.
393 2015-02-03 14:53:07 <wumpus> so yes, for the legacy wallet you'll need some ugly hook mechanism to call the wallet if enabled
394 2015-02-03 14:53:23 <wumpus> until we drop that legacy wallet (plus its interface) and can get rid of that
395 2015-02-03 14:53:39 <jonasschnelli> wumpus, yes. i think i'll to the legacywallet still over a pmainWallet (global) var..
396 2015-02-03 14:53:43 <wumpus> yes
397 2015-02-03 14:53:45 <wumpus> just do that
398 2015-02-03 14:53:55 <wumpus> don't change the legacywallet unless where absolutely necessary
399 2015-02-03 14:54:14 <wumpus> the point is to keep it stable and as-is, and it is code that will be thrown away at some point anyway
400 2015-02-03 14:54:44 <wumpus> (so yes, you could even keep ENABLE_WALLET for it.)
401 2015-02-03 14:54:45 <jonasschnelli> the main refactoring must take happen between init.cpp and wallet.cpp
402 2015-02-03 14:55:18 <wumpus> or rename the ifdef to ENABLE_LEGACY_WALLET ;)
403 2015-02-03 14:55:26 <jonasschnelli> if the new wallet will be introduced as a module, the legacywallet needs also transition to the module interface which might end up by moving around lots of code
404 2015-02-03 14:55:52 <wumpus> moving code is not a problem
405 2015-02-03 14:55:56 <jonasschnelli> (and slightly rewriting)
406 2015-02-03 14:56:06 <wumpus> that's easy to review, but make sure you change it as little as possible
407 2015-02-03 14:56:26 <wumpus> a) people hate reviewing changes to the legacy wallet b) we do not want to introduce bugs in it
408 2015-02-03 14:56:29 <jonasschnelli> i tried, but init.cpp is glued with wallet.cpp and walletdb.cpp (even a little bit with db.cpp)
409 2015-02-03 14:56:48 <jonasschnelli> so the changeset of the decoupling should not be underestimated
410 2015-02-03 14:56:58 <wumpus> yes, init.cpp is the problem, so decoupling the initialization
411 2015-02-03 14:57:00 <jonasschnelli> okay. but let me try this.
412 2015-02-03 14:57:12 <wumpus> wallet.cpp and walletdb.cpp can just be moved as-is
413 2015-02-03 14:57:17 <wumpus> and so rpcwallet.cpp
414 2015-02-03 14:57:40 <wumpus> (although obviously you'll need the RPC registration stuff, so that it can register its methods...)
415 2015-02-03 14:57:48 <jonasschnelli> no... they need changes.
416 2015-02-03 14:57:55 <wumpus> why?
417 2015-02-03 14:58:16 <wumpus> sure, you need to move the initialisation code to them from init.cpp
418 2015-02-03 14:58:27 <jonasschnelli> there are direct walletdb calls from init which should be placed behind wallet.cpp... same for bdb.cpp
419 2015-02-03 14:58:28 <wumpus> eh, other way
420 2015-02-03 14:58:43 <jonasschnelli> of at least it should be within a new introduces module
421 2015-02-03 14:58:48 <wumpus> yes. as I say, the wallet init code should move from init.cpp to wallet.cpp
422 2015-02-03 14:58:59 <wumpus> so all the legacy wallet code is together
423 2015-02-03 14:59:17 <wumpus> db.cpp can also move to legacywallet, we don't need it anymore for the new wallet
424 2015-02-03 14:59:45 <jonasschnelli> i could see init.cpp <-> moduleSignals <-> CLegacyWallet inherited from CModuleInterface
425 2015-02-03 14:59:59 <wumpus> yes, for example
426 2015-02-03 15:00:05 <jonasschnelli> i did mostly of that already,... https://github.com/jonasschnelli/bitcoin/commit/708ab5f827ee7e93cb706a3a9eb65fddd896350c but don't review this!
427 2015-02-03 15:00:15 <jonasschnelli> its not ready yet
428 2015-02-03 15:00:54 <jonasschnelli> and theres also the classname problems.
429 2015-02-03 15:01:02 <wumpus> namespaces to the rescue
430 2015-02-03 15:02:12 <wumpus> just move all the legacy wallet stuff to legacywallet::, and the new wallet stuff in just wallet::
431 2015-02-03 15:02:22 <jonasschnelli> Yes. But there are connections to CReserveKey, CMerkleTx which needs to be doupled somehow. I started a wallet_common.cpp for the very basics (like a CReserveKey)
432 2015-02-03 15:02:33 <jonasschnelli> maybe the mining should also go to the legacywallet
433 2015-02-03 15:03:05 <wumpus> yes, maybe
434 2015-02-03 15:03:13 <jonasschnelli> But currently i have no idea of how to threat the Qt part... There are many connections to CWallet / CWalletTx
435 2015-02-03 15:03:14 <wumpus> I don't think there is consensus on getting rid of the internal miner
436 2015-02-03 15:03:20 <jonasschnelli> signaling might be a overkill there
437 2015-02-03 15:03:26 <wumpus> maybe make the legacy wallet RPC only?
438 2015-02-03 15:03:29 <jonasschnelli> maybe a abstract interface to ONE wallet could be a way.
439 2015-02-03 15:03:55 <jonasschnelli> wumpus, but does mining make sense without a wallet?
440 2015-02-03 15:04:01 <wumpus> e.g. for the GUI focus on the new wallet
441 2015-02-03 15:04:15 <jonasschnelli> so GUI incompatible with legacywallet?
442 2015-02-03 15:04:36 <wumpus> internal miner without wallet may be possible - just pass it an address?
443 2015-02-03 15:05:00 <wumpus> not worth the bother maybe
444 2015-02-03 15:05:41 <wumpus> you need something for the RPC tests though, having them depend on the wallet is fine
445 2015-02-03 15:05:48 <jonasschnelli> but it would be better if the Qt part could also talk with the module interface and abstract the wallet completely
446 2015-02-03 15:05:49 <jonasschnelli> wumpus, Miner: yes. Or like i did it in my big changeset by providing a signal to get a key for storing the mined coins.
447 2015-02-03 15:06:01 <wumpus> no, passing an address is dumb - you'd need a new address for every block, of course
448 2015-02-03 15:06:33 <wumpus> I wouldn't worry too much about that initially, indeed just couple it to the legacywallet, after all the RPC tsts will also depend on that for ow
449 2015-02-03 15:06:43 <jonasschnelli> wumpus, tests are no problems, i just moved them to src/legacywallet/tests/...
450 2015-02-03 15:07:12 <wumpus> I'm talking about the RPC tests
451 2015-02-03 15:07:13 <jonasschnelli> there must be rpc tests for the code, and for each wallet, independant
452 2015-02-03 15:07:19 <jonasschnelli> code/core
453 2015-02-03 15:07:39 <wumpus> well sure, but the non-wallet RPC tests require a wallet also right now
454 2015-02-03 15:07:56 <wumpus> if you get what I mean - they all need mining, and coins, etc