1 2015-04-10 00:02:10 <Luke-Jr> moa: why wouldn't he? O.o
  2 2015-04-10 00:02:30 <Luke-Jr> ldelarosa: it's safe, provided your transaction itself is safe; it's not *reliable* though
  3 2015-04-10 00:03:38 <moa> Luke-Jr: he asked if he 'can'
  4 2015-04-10 00:03:54 <ldelarosa> I can't recreate it
  5 2015-04-10 00:04:13 <ldelarosa> It says "FEES INCORRECTLY STATED: unspents[0] script mismatch!"
  6 2015-04-10 00:11:11 <rgenito> any recommendations on how I can get this transaction movin?
  7 2015-04-10 00:11:13 <rgenito> https://blockchain.info/tx/8ad2cc0551ee0d3d663e55583ac23567cb6025bbc54338b9b4ac64e235753da3
  8 2015-04-10 00:11:21 <rgenito> it has been unconfirmed for a while... no fee -.-
  9 2015-04-10 00:16:52 <ldelarosa> I'm here
 10 2015-04-10 00:17:06 <Luke-Jr> ldelarosa: what says it? O.o
 11 2015-04-10 00:17:17 <Luke-Jr> rgenito: #bitcoin
 12 2015-04-10 00:17:30 <ldelarosa> Luke-Jr, It says "FEES INCORRECTLY STATED: unspents[0] script mismatch!"
 13 2015-04-10 00:17:43 <Luke-Jr> "it"
 14 2015-04-10 00:18:20 <ldelarosa> Yes whe trying to recreate the transaction this time with the network fee
 15 2015-04-10 00:18:26 <rgenito> thanks Luke-Jr
 16 2015-04-10 00:19:41 <Luke-Jr> ldelarosa: "recreate" with what?
 17 2015-04-10 00:20:10 <ldelarosa> Oh sorry my bad, I should give more info.
 18 2015-04-10 00:20:21 <ldelarosa> Luke-Jr, I'm using pycoin
 19 2015-04-10 00:21:03 <Luke-Jr> hm, never used pycoin for that myself. maybe someone else can chime in
 20 2015-04-10 00:23:03 <rgenito> Luke-Jr, i'm about to createrawtransaction for the first time
 21 2015-04-10 00:23:09 <rgenito> so maybe this will help ;D
 22 2015-04-10 00:23:22 <rgenito> but i'm thinkin ... i should probably at least have the latest bitcoind on here...
 23 2015-04-10 00:26:33 <cfields> gavinandresen: unping. See github comment.
 24 2015-04-10 00:26:46 <rgenito> creating a transaction with "createrawtransaction" for the first time....
 25 2015-04-10 00:26:53 <rgenito> ...are there risks with doing this? like in the old days?
 26 2015-04-10 00:27:03 <rgenito> i've just heard horror stories like 5 years ago...
 27 2015-04-10 00:30:09 <ldelarosa> It has already one confirmation
 28 2015-04-10 00:30:18 <ldelarosa> Network picked it up.
 29 2015-04-10 02:12:25 <romonster> Irssi 0.8.15 (20100403) - http://irssi.org/ end
 30 2015-04-10 02:12:44 <lewellyn> heh. :)
 31 2015-04-10 02:18:32 <romonster> jonasschnelli: I installed the app you linked but it won't run because it's unsigned
 32 2015-04-10 02:19:27 <lewellyn> romonster: right-click it with the control key held down and hit Open in the menu (with Control still held down)
 33 2015-04-10 05:18:34 <wumpus> ugh, how can #5957 make regtest mining slower?
 34 2015-04-10 05:19:13 <sipa> wumpus: i have 2 theories
 35 2015-04-10 05:19:39 <wumpus> going to revert it and keep just the RPC change
 36 2015-04-10 05:23:48 <wumpus> sipa: in ScanLoop it's checking for 16 zero bits
 37 2015-04-10 05:23:57 <sipa> indeed
 38 2015-04-10 05:23:59 <wumpus> sipa: for regtest it only requires 1 or so
 39 2015-04-10 05:24:12 <sipa> indeed
 40 2015-04-10 05:24:41 <sipa> but if you chsbge to only checking 8 bits, it's still slow
 41 2015-04-10 05:25:00 <wumpus> that's still too much
 42 2015-04-10 05:25:14 <sipa> yes
 43 2015-04-10 05:25:23 <wumpus> why check bits at all, and not just compare against the threshold value?
 44 2015-04-10 05:25:39 <sipa> yes, i have a branch that does that
 45 2015-04-10 05:25:49 <sipa> i'll benchmark
 46 2015-04-10 05:26:12 <wumpus> should be lots faster, heck, even in python one can generate regtest blocks almost instantly :)
 47 2015-04-10 05:26:14 <sipa> but i was addressing some of jtimon's nits too
 48 2015-04-10 05:28:04 <wumpus> ok
 49 2015-04-10 05:28:28 <sipa> anyway, iirc the 8-bit scan was still 2x slower than the original
 50 2015-04-10 05:28:52 <wumpus> it just doesn't make sense to check for 8 zeros, you'll check 128 times as much blocks
 51 2015-04-10 05:29:17 <sipa> agree
 52 2015-04-10 05:30:23 <sipa> but 128 hashes takes a fraction of a millisecond
 53 2015-04-10 05:30:27 <sipa> or should
 54 2015-04-10 05:31:06 <wumpus> I don't see the advantage of this to just a comparison, that's both easier to read and should be faster (at least in the regtest case)
 55 2015-04-10 05:31:17 <sipa> i agree
 56 2015-04-10 05:31:36 <wumpus> sure, 128 hashes should be fast, but if they're not needed, why
 57 2015-04-10 05:31:41 <sipa> i'm just trying to arguebwhy i on't expect that to fix the slowness
 58 2015-04-10 05:31:50 <wumpus> right
 59 2015-04-10 05:32:15 <sipa> sorry, phone typing
 60 2015-04-10 05:32:43 <gmaxwell> wumpus: it's useful to test something so you can test rejection.
 61 2015-04-10 05:33:01 <gmaxwell> oh sorry catching up.
 62 2015-04-10 05:33:06 <sipa> regtest still rejects half of the hashes
 63 2015-04-10 05:34:29 <wumpus> rejecting half should be enough, the final test is if the result will pass AcceptBlock
 64 2015-04-10 05:55:20 <wumpus> ah the old code for generate() was pretty just a simple loop checking the hash against the threshold as I expected
 65 2015-04-10 05:55:31 <sipa> indeed
 66 2015-04-10 05:55:59 <sipa> the new code includes some wallet interaction when a block is found
 67 2015-04-10 05:57:15 <wumpus> https://github.com/bitcoin/bitcoin/pull/5991 reverts the changes to the mining code, but adds 'generate' based on the old code, hopefully that will make travis happy
 68 2015-04-10 06:00:42 <jonasschnelli> romonster: yes. It's unsigned. You have to allow the app to start under OSX->Settings->Security
 69 2015-04-10 06:01:10 <romonster> I got it  :)
 70 2015-04-10 06:07:29 <jonasschnelli> Would it make sense to add signaling for rpc calls? A incomming rpc call could trigger a signal with a request-struct (more or less URI and Params) and a pass-by-ref stringbuffer (or a json Object) for the response?
 71 2015-04-10 06:07:57 <wumpus> that sounds like overkill
 72 2015-04-10 06:08:20 <wumpus> is there anything you can't do with the current dispatch table?
 73 2015-04-10 06:08:58 <jonasschnelli> i'd like to keep the wallets rpc calls registering withing wallet/* or even wallet/wallet.cpp
 74 2015-04-10 06:09:17 <jonasschnelli> and the dispatch tables reqWallet should also be removed once
 75 2015-04-10 06:09:26 <wumpus> it's fairly easy to add RPC call register/unregister calls to the current code
 76 2015-04-10 06:09:45 <sipa> reqWallet should go away, yes
 77 2015-04-10 06:10:05 <wumpus> yes, reqwallet should go away, but that's a seperate issue
 78 2015-04-10 06:10:28 <jonasschnelli> wumpus: i have a open PR for that: https://github.com/bitcoin/bitcoin/pull/5934
 79 2015-04-10 06:10:29 <wumpus> the new wallet RPCs would take a wallet ID
 80 2015-04-10 06:10:50 <jonasschnelli> but i'm not sure if this PR goes into the right direction
 81 2015-04-10 06:10:54 <wumpus> and look it up in a map or such
 82 2015-04-10 06:11:20 <wumpus> oh sorry
 83 2015-04-10 06:56:18 <jonasschnelli> wumpus, sipa: so removing reqWallet from rpcserver.cpp and doing a check withing rpcwallet.cpp functions would make more sense?
 84 2015-04-10 06:57:03 <wumpus> jonasschnelli: yes
 85 2015-04-10 06:57:19 <wumpus> I guess so; we've done the same for the locks
 86 2015-04-10 06:57:20 <jonasschnelli> okay... already started changing this.
 87 2015-04-10 06:57:38 <wumpus> pushed them down into the code instead of the dispatch mechanism
 88 2015-04-10 06:57:49 <jonasschnelli> then there also the issues with #ifdef ENABLE_WALLET within rpcrawtransactions
 89 2015-04-10 06:58:32 <jonasschnelli> i kinda dislike that signrawtransaction has one function for wallet and non-wallet signing.
 90 2015-04-10 06:58:37 <wumpus> (I only now notice that you're talking about reqWallet and not pwalletMain, heh)
 91 2015-04-10 06:59:05 <wumpus> jonasschnelli: yes it's ugly, should never have been the same RPC call at all for wallet and non-wallet functionality
 92 2015-04-10 06:59:12 <jonasschnelli> right... reqWallet is a subcontext of wallet/core decoupeling
 93 2015-04-10 07:00:12 <wumpus> it's extremely inconvenient that there are RPC calls that change behavior based on whether wallet is active or not, ideally we should get rid of them it's just that changing the API is such a bother
 94 2015-04-10 07:01:43 <jonasschnelli> wumpus: Agreed. For a new wallet i'd like to use "wallet_" as wallet rpc calls prefix
 95 2015-04-10 07:01:49 <wumpus> yes!
 96 2015-04-10 07:01:59 <jonasschnelli> so there could be a signrawtransaction and a wallet_signrawtransaction
 97 2015-04-10 07:02:12 <gmaxwell> bleh.
 98 2015-04-10 07:02:25 <gmaxwell> I agree that I hate the behavior changing.
 99 2015-04-10 07:02:26 <wumpus> putting the seperate functionality in seperate namespaces makes a lot of sense
100 2015-04-10 07:02:39 <gmaxwell> But y'all are just hell bent on making bitcoin useless from the CLI or what? :)
101 2015-04-10 07:02:45 <wumpus> gmaxwell: this will also be problematic for multiwallet
102 2015-04-10 07:03:20 <wumpus> gmaxwell: what makes it useless from the cli?!
103 2015-04-10 07:03:27 <wumpus> gmaxwell: the longer command?
104 2015-04-10 07:03:37 <jonasschnelli> gmaxwell: the plan is still to keep the (legacy)wallet. But the new wallet should have flexible arguments (as property list) as well as a "wallet_*" prefix
105 2015-04-10 07:03:38 <gmaxwell> It's an awful lot to type, prefacing almost everything with wallet.
106 2015-04-10 07:03:54 <jonasschnelli> gmaxwell: autocompletion? :)
107 2015-04-10 07:04:02 <wumpus> we could use a shorter prefix, or even built in the abbreviation into the bitcoin-cli utility
108 2015-04-10 07:04:35 <wumpus> eg. bitcoin-cli -w signrawtransaction
109 2015-04-10 07:04:49 <gmaxwell> I'd be fine with bitcoin-cli abbreviating things though, there is a "onramp loss" when the CLI cooresponds less to the rpc. E.g. you can't learn the software with the cli then translate that as directly into the RPC.
110 2015-04-10 07:04:52 <wumpus> or build yor own script that calls bitcoin-cli
111 2015-04-10 07:04:53 <jonasschnelli> or something like "wallet_sign" ... the "rawtransaction" part is kind of repetitive and useless.
112 2015-04-10 07:05:33 <gmaxwell> yea, the existing names area alread burdensome.
113 2015-04-10 07:05:36 <wumpus> there's ton of ways, but a bit of convenience should not be used as an argument against making the code better
114 2015-04-10 07:06:00 <wumpus> right, bitcoin-cli already isn't a very convenient interface
115 2015-04-10 07:06:16 <wumpus> I think some guy was working on a more user friendly cli at some point, no idea what happened with that
116 2015-04-10 07:06:25 <jonasschnelli> i still think having the legacywallet and the wallet in parallel allows significant not-RPC-API-compatible changes.
117 2015-04-10 07:06:44 <gmaxwell> wumpus: it's usable just not great.  Is adding string prefixes_ really the right way to namespace json rpc?
118 2015-04-10 07:06:56 <gmaxwell> (I'm clueless on conventions for json rpc, so thats not a loaded question)
119 2015-04-10 07:07:01 <wumpus> gmaxwell: i don't know! feel free to suggest abetter way to namespace
120 2015-04-10 07:07:21 <sipa> we could use s different url for the wallet rpcs
121 2015-04-10 07:07:25 <wumpus> gmaxwell: let's not entangle things here, I think it's good to namespace, I don't insist on a certain specific way
122 2015-04-10 07:07:32 <wumpus> sipa: yep
123 2015-04-10 07:08:13 <wumpus> sipa: that has been suggested too, or even using a different URL for different wallets (in case of multiwallet)
124 2015-04-10 07:08:15 <gmaxwell> yea, I think it should probably be different URLs, and the cli could just switch. And that also keeps the mapping between the cli and the rpc too; so if you know the cli you know the RPC, which I think is a good property.
125 2015-04-10 07:08:17 <jonasschnelli> sipa: this would be a nice idea. Could also help for the possibility to run the wallet more separately
126 2015-04-10 07:08:54 <jonasschnelli> bitcoin-cli -w could be a shortcut to the wallet RPC uri.
127 2015-04-10 07:09:11 <wumpus> jonasschnelli: indeed, it's also a preparation for moving it to a different process, in which case it'll have a different URI too
128 2015-04-10 07:09:17 <wumpus> jonasschnelli: good point
129 2015-04-10 07:11:24 <jonasschnelli> wumpus: i also read about your concerns about keeping all wtx in memory in case of scalability...
130 2015-04-10 07:12:38 <wumpus> jonasschnelli: right, keeping all transactions in memory puts a clear bound on scalability
131 2015-04-10 07:13:38 <wumpus> jonasschnelli: could be kicked down the road keeping an index/summary in memory and reading the data from disk when needed
132 2015-04-10 07:13:41 <jonasschnelli> wumpus: using leveldb as wallet database?
133 2015-04-10 07:13:45 <gmaxwell> wumpus: "as much scale as you have swap"? :P
134 2015-04-10 07:14:17 <wumpus> jonasschnelli: no, let's stick with the custom format
135 2015-04-10 07:14:38 <wumpus> jonasschnelli: we may move away from leveldb for the utxo database at some point
136 2015-04-10 07:14:53 <gmaxwell> 
ACTION twitches at "leveldb as wallet database" ooh the curruption it hurts

137 2015-04-10 07:14:56 <jonasschnelli> wumpus: okay. I think there still would be ways to avoid having all wtx in mem with the custom format.
138 2015-04-10 07:15:21 <wumpus> jonasschnelli: so if the wallet were to use it, it's another lead ball depenency that we have to keep forever like berkeleydb :/
139 2015-04-10 07:15:31 <gmaxwell> Just need to be careful to not go "can scale, but only if you have lots of ram" to "can't scale at all, because its too slow to be usable."
140 2015-04-10 07:15:51 <wumpus> obviously
141 2015-04-10 07:15:52 <jonasschnelli> gmaxwell: agreed.
142 2015-04-10 07:16:21 <gmaxwell> wumpus: there is a possiblity of a 'wallet index' that can always be rebuilt from the wallet thats only used for performance reasons; hard to keep such a think consistent though.
143 2015-04-10 07:16:35 <jonasschnelli> And you need to have a big big wallet if your exhaust you ram limits. Merchants are probably willing to implement their own backend.
144 2015-04-10 07:17:21 <gmaxwell> jonasschnelli: merchants are willing to do all kinds of things so long as they're horrifying. I think thats the actual law of nature.
145 2015-04-10 07:17:25 <gmaxwell> :)
146 2015-04-10 07:17:46 <jonasschnelli> i recently played around with a regtest 200'000 wtx wallet (1 vin, 1 vout std) and it turned out to be relatively fast and had a small cpu/mem footprint
147 2015-04-10 07:17:52 <midnightmagic> sounds related to the law of scamminess
148 2015-04-10 07:17:52 <wumpus> in any case, keeping every single transaction in memory should not be necessary for speed
149 2015-04-10 07:18:04 <gmaxwell> forcing people to go around reimplementing things isn't great for the ecosystem, to the extent that we can avoid it.  They inevitably get reimplemented by someone with limited domain specific knoweldge who is under time pressure.
150 2015-04-10 07:18:24 <sipa> keeping utxos as an independrbt wallrt data structure from trabsactions may help
151 2015-04-10 07:18:31 <wumpus> e.g. it makes no sense for an old wallet to say have 10 year old tranactions still around that you used to pay for coffee once
152 2015-04-10 07:18:35 <gmaxwell> jonasschnelli: yea, we work fine with tens of thousands of transactions; at least on big fast hosts.
153 2015-04-10 07:18:40 <wumpus> (well, on disk for archival of ourse, but not hot in memory)
154 2015-04-10 07:18:57 <jonasschnelli> wumpus: wallet pruning was closed? :)
155 2015-04-10 07:19:06 <wumpus> jonasschnelli: that deletes *from disk*
156 2015-04-10 07:19:18 <wumpus> my point is to not keep everything in memory
157 2015-04-10 07:19:19 <jonasschnelli> wumpus: ah you mean for the in-mem keeping... right. Agreed.
158 2015-04-10 07:19:26 <solatis> is this the right channel to ask questions if i have trouble figuring out the bitcoin core RPC interface?
159 2015-04-10 07:19:32 <wumpus> deleting old transactions from disk makes no sense
160 2015-04-10 07:20:00 <jonasschnelli> wumpus: yes maybe some fix balance values in over time or amount of wtx could make sense.
161 2015-04-10 07:20:16 <gmaxwell> solatis: #bitcoin is better for tech support.
162 2015-04-10 07:20:25 <wumpus> jonasschnelli: no need for that; you can keep the not fully spent transactions in memory
163 2015-04-10 07:20:28 <solatis> gmaxwell, ok
164 2015-04-10 07:20:40 <wumpus> jonasschnelli: (as sipa says)
165 2015-04-10 07:20:58 <jonasschnelli> Indeed.
166 2015-04-10 07:23:18 <wumpus> the most performance-critical part of the wallet is the output selection, so it makes sense to have the required data for that hot in memory
167 2015-04-10 07:24:15 <gmaxwell> outputs are small anyways, and if you have a huge number of those your behavior is also likely harming the network.
168 2015-04-10 07:25:28 <wumpus> but in performance on, say, listtransactions for old transactions it won't hurt a bit if it requires a few disk accesses
169 2015-04-10 07:27:20 <wumpus> large chance it will otherwise have been swapped out anyhow
170 2015-04-10 08:43:58 <pastday> hi,
171 2015-04-10 08:45:27 <pastday> anybody?
172 2015-04-10 08:45:49 <pastday> I have a very simple question, to you.
173 2015-04-10 08:47:34 <sipa> phantomcircuit: ask, don't ask to ask
174 2015-04-10 08:47:37 <sipa> eh, pastd
175 2015-04-10 08:47:44 <sipa> oh, he already left
176 2015-04-10 09:34:22 <jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/5503/files#r28132231 maybe i should change the code-comment that it's more clear that we are removing a dummy-signature only
177 2015-04-10 09:35:19 <wumpus> jonasschnelli: indeed, you could mention that in a comment, that you add a dummy signature to make a proper size estimate, then remove it again before returning it because it's a dummy
178 2015-04-10 09:35:32 <jonasschnelli> Agreed. Will add.
179 2015-04-10 09:37:17 <priidu> I've always wondered about the huge blank space in debug.log every time you start up a node
180 2015-04-10 09:37:32 <priidu> is there a particular reason why it's there?
181 2015-04-10 09:37:50 <sipa> priidu: so you can easily see the restart when scrolling quickly through it :)
182 2015-04-10 09:38:02 <priidu> ah, right
183 2015-04-10 09:38:14 <wumpus> right, it makes it easier to find restarts, it's not there just for artistic reasons :)
184 2015-04-10 09:38:28 <priidu> kind of thought so, and I suppose it's a good idea
185 2015-04-10 09:38:37 <wumpus> (although I think there's a bug that some things get logged *before* the empty space, like parameter interactions)
186 2015-04-10 09:38:43 <priidu> just made me wonder because it's 20 rows - seems quite a lot
187 2015-04-10 09:39:24 <priidu> but when your log is already pusing the MB range in size, i guess it can be really useful :
188 2015-04-10 09:39:27 <priidu> :)
189 2015-04-10 09:39:30 <wumpus> that's quite subjective, depending on your screen height
190 2015-04-10 09:40:13 <priidu> yep
191 2015-04-10 09:40:42 <wumpus> haha no need to worry about the size, those 20 \n's take less space than the average line
192 2015-04-10 09:40:53 <priidu> when to log gets large, something like 3 rows can be hard to notice when using the scrollbar
193 2015-04-10 09:40:59 <wumpus> yep
194 2015-04-10 09:41:01 <priidu> the log*
195 2015-04-10 09:57:10 <pastday> hi,
196 2015-04-10 09:57:46 <pastday> I have a question,
197 2015-04-10 09:57:53 <pastday> what options are there to Distinguish bitcoin and any other client
198 2015-04-10 09:58:51 <pastday> If I made other coin program, What I should change bitcoin source?
199 2015-04-10 10:12:46 <sipa> wumpus: aaargh, just found out why my code is so much slower
200 2015-04-10 10:12:53 <wumpus> do tell :)
201 2015-04-10 10:12:59 <sipa> wumpus: it fetches a new reservekey for every block, rather than reusing it
202 2015-04-10 10:13:08 <sipa> which takes f*cking 80ms per block
203 2015-04-10 10:13:23 <wumpus> wow, i wouldn't have expected that to be the bottleneck, interesting
204 2015-04-10 10:13:41 <wumpus> key generation is plenty slow that's true
205 2015-04-10 10:13:50 <sipa> key generation is very fast
206 2015-04-10 10:13:56 <sipa> wallet db writes are slow
207 2015-04-10 10:14:48 <jonasschnelli> hmm... i just started rewriting the miner to reduce pwalletMain interactions...
208 2015-04-10 10:14:50 <wumpus> ah yes I mean "key generation + wallet writes" are slow, I indeed never profiled which part is the slow part
209 2015-04-10 10:15:08 <sipa> jonasschnelli: ugh, you'll get conflicts with jtimon and me
210 2015-04-10 10:15:10 <wumpus> duh, it makes sense for it to be the database
211 2015-04-10 10:15:14 <jonasschnelli> and one drawback could be always call keepKey...
212 2015-04-10 10:15:25 <jonasschnelli> sipa: rebasing is fun. :)
213 2015-04-10 10:15:48 <jonasschnelli> sipa: i checked your commit and saw that my changes are more less on other lines
214 2015-04-10 10:16:15 <jonasschnelli> for now i just try to find a good way to decouple... will do it again after the merge of your PR
215 2015-04-10 10:17:03 <jtimon> I assume you're talking about conflicts with #4793 (although #5968 will also likely conflict)
216 2015-04-10 10:17:13 <Luke-Jr> [10:12:59] <sipa> wumpus: it fetches a new reservekey for every block, rather than reusing it <-- uh, it always has and should?
217 2015-04-10 10:17:27 <Luke-Jr> unless you mean for every hash
218 2015-04-10 10:18:34 <sipa> Luke-Jr: if you mine 100 blocks through the generate RPC call (=old regtest setgenerate true 100), they all use the same key
219 2015-04-10 10:18:36 <Luke-Jr> otoh, since it's just for testing, maybe key reuse is tolerable - but if the goal is to have it a reasonable reference for miners, not really
220 2015-04-10 10:18:42 <wumpus> Luke-Jr: the reference here would be the old code
221 2015-04-10 10:18:59 <wumpus> Luke-Jr: this is only about the regtest code
222 2015-04-10 10:19:07 <Luke-Jr> i c
223 2015-04-10 10:19:09 <sipa> Luke-Jr: getblocktemplate will always use a new key, as it should
224 2015-04-10 10:19:11 <jonasschnelli> hmm.... current master: setgenerate true 101  -> results in 18 blocks mined?
225 2015-04-10 10:19:11 <wumpus> the general mining code should indeed use a new key for every block
226 2015-04-10 10:19:21 <sipa> jonasschnelli: uh?
227 2015-04-10 10:19:24 <Luke-Jr> sipa: getblocktemplate doesn't use a key at all..
228 2015-04-10 10:19:31 <wumpus> jonasschnelli: no, that just enables generation with 101 threads
229 2015-04-10 10:19:37 <wumpus> jonasschnelli: use *generate*
230 2015-04-10 10:19:43 <sipa> Luke-Jr: oh, duh
231 2015-04-10 10:19:51 <jonasschnelli> okay. i'll misst that change somehow... :)
232 2015-04-10 10:20:00 <jonasschnelli> s/misst/missed
233 2015-04-10 10:20:18 <wumpus> I've been thinking of adding an error to setgenerate w/ regtest for the obvious cases where people use it in the old way
234 2015-04-10 10:20:44 <sipa> wumpus: let's just remove getgenerate/setgenerate :D
235 2015-04-10 10:20:52 <wumpus> sipa: fine with me too.
236 2015-04-10 10:21:09 <wumpus> sipa: ACK if we include a getblocktemplate-based reference miner :-)
237 2015-04-10 10:21:11 <sipa> that may cause some minor controversy... testnet etc
238 2015-04-10 10:21:16 <sipa> wumpus: yeah, indeed
239 2015-04-10 10:21:21 <sipa> we need a replacement
240 2015-04-10 10:21:23 <sipa> as reference
241 2015-04-10 10:21:42 <Luke-Jr> there are already references. no need to shove everything into one repo :/
242 2015-04-10 10:21:42 <wumpus> mining testnet is very sneaky, you need to cheat with timestamps
243 2015-04-10 10:21:54 <wumpus> (at least if you want to do CPU mining)
244 2015-04-10 10:23:24 <wumpus> the '20 minutes = difficulty 1' rule has caused the block timestamps to be pushed against the 'block in the future' limit
245 2015-04-10 10:23:40 <wumpus> so just enabling the builtin miner there won't do you any good either
246 2015-04-10 10:23:46 <jtimon> is there anything in #4793 that #5957 didn't had and it's blocking it somehow?
247 2015-04-10 10:24:06 <sipa> jonasschnelli: looking
248 2015-04-10 10:24:26 <wumpus> Luke-Jr: agreed
249 2015-04-10 10:24:53 <sipa> jtimon: ah, i've re-issued 5957 as 5993
250 2015-04-10 10:25:00 <sipa> as some things got reverted
251 2015-04-10 10:25:02 <wumpus> Luke-Jr: do you have a simple getblocktemplate-based CPU miner that we could refer to, then? that's both easy to read as source code and simple to set up
252 2015-04-10 10:25:36 <buZz> pooler's cpuminer?
253 2015-04-10 10:25:43 <Luke-Jr> wumpus: libblkmaker includes a 130-line example CPU miner that just calls out to libgcrypt for hashing
254 2015-04-10 10:26:10 <wumpus> Luke-Jr: right
255 2015-04-10 10:26:26 <jtimon> sipa, ok, looking
256 2015-04-10 10:26:57 <jonasschnelli> jtimon: i didn't find time to look at #4793, this should probably reviewed by someone else.
257 2015-04-10 10:27:17 <jtimon> it was reviewed and forgotten I'm afraid
258 2015-04-10 10:27:47 <Luke-Jr> https://github.com/bitcoin/libblkmaker/blob/master/example.c
259 2015-04-10 10:28:40 <wumpus> Luke-Jr: trying
260 2015-04-10 10:28:55 <wumpus> bleh configure: error: Could not find jansson library
261 2015-04-10 10:28:58 <Luke-Jr> (in other news: wtf, KDE is DoSing my DSL & mail server with a SYN flood)
262 2015-04-10 10:29:33 <Luke-Jr> wumpus: jansson is JSON, pretty typical for miners
263 2015-04-10 10:30:13 <wumpus> well fair enough it makes sense to need a JSON library if you're going to do this in C
264 2015-04-10 10:31:35 <wumpus> but we could make some self-contained repository though that makes this easy to set up
265 2015-04-10 10:33:04 <Luke-Jr> sure; although if someone just wants an easy CPU miner I think apt-get install bfgminer works
266 2015-04-10 10:34:04 <Luke-Jr> actually, that might have issues with the new block version
267 2015-04-10 10:34:36 <wumpus> oh this just creates a library, not an executable?
268 2015-04-10 10:34:49 <Luke-Jr> right, you need to compile example.c for executable
269 2015-04-10 10:34:57 <wumpus> is there a configure flag for that?
270 2015-04-10 10:35:34 <Luke-Jr> I don't believe so.. would need libgcrypt as a dependency to autogen if it did :/
271 2015-04-10 10:35:58 <Luke-Jr> 
ACTION grumbles about libgcrypt not using standard pkg-config stuff

272 2015-04-10 10:36:29 <wumpus> could cheat and just copy a sha256.h implementation  :-)
273 2015-04-10 10:36:53 <Luke-Jr> that'd be ugly. sooner go with libbase58's workaround
274 2015-04-10 10:37:24 <Luke-Jr> (configure scripts produced by systems without libgcrypt silently don't support the CLI tool)
275 2015-04-10 10:39:56 <jtimon> sipa: several nits on 5993...maybe it wouold be simpler for you to rebase on top of 4793 ?
276 2015-04-10 10:40:20 <jtimon> or squash it in one of your commits or something...
277 2015-04-10 10:40:30 <wumpus> in the meantime we could just disable setgenerate for regtest and make it give a message to use 'generate' instead
278 2015-04-10 10:40:57 <Luke-Jr> oh
279 2015-04-10 10:41:07 <Luke-Jr> wumpus: another possible shortcoming is that example.c doesn't do networking :p
280 2015-04-10 10:41:10 <wumpus> removing setgenerate/getgenerate completely will likely be too controversial
281 2015-04-10 10:41:19 <wumpus> although I like it
282 2015-04-10 10:41:29 <Luke-Jr> so maybe a fork of example.c adding that and a build system would be appropriate
283 2015-04-10 10:41:29 <wumpus> Luke-Jr: heh
284 2015-04-10 10:41:55 <Luke-Jr> can't be too many more lines of code to add a minimal libcurl call
285 2015-04-10 10:42:38 <wumpus> if performance isn't an issue we could just ship a python script, unfortunatetly it is, the probem with C is that you need a dependency for every little thing, much harder to make something self-contained
286 2015-04-10 10:43:03 <wumpus> (especially cross-platform :( )
287 2015-04-10 10:43:28 <Luke-Jr> I don't get why self-contained is important for this. Libraries are easy.
288 2015-04-10 10:43:45 <Luke-Jr> and it's just a reference - if people want a real miner they can just run BFGMiner O.o
289 2015-04-10 10:43:46 <sipa> in practice, libraries are not easy and add maintenance cost
290 2015-04-10 10:44:01 <sipa> more code also requires maintenance, but in the case of well-defined hash-function, i believe that is minimal
291 2015-04-10 10:45:53 <wumpus> yes my point is that C's standard library is so constrained, it's not so well suited to just make a proof of concept that does something and is self-explanatory, you either need to ship a shitload of extra code or use libraries from all over the place
292 2015-04-10 10:46:17 <wumpus> but I'm afraid python will be just too slow, even for mining at difficulty 1
293 2015-04-10 10:47:04 <Luke-Jr> even C is too slow, frankly
294 2015-04-10 10:47:05 <wumpus> (for creating regtest blocks it's fast enough, but that's like 2^31 times cheaper)
295 2015-04-10 10:47:25 <Luke-Jr> the difference between C mining and assembly mining is huge
296 2015-04-10 10:47:33 <wumpus> Luke-Jr: true, everything is relative.
297 2015-04-10 10:48:06 <wumpus> Luke-Jr: but say you have a testnet in a box setup and want to mine at difficulty 1, and it takes 60 minutes to find a block, that's kind of crappy :-)
298 2015-04-10 10:48:25 <Luke-Jr> re library costs… the only costs I see are user disk/memory; from my perspective there is no maintenance cost if it's pkg-config and commonly packaged ;)
299 2015-04-10 10:48:35 <wumpus> Luke-Jr: interface drift is one
300 2015-04-10 10:48:39 <Luke-Jr> wumpus: 60 minutes would be good
301 2015-04-10 10:48:59 <Luke-Jr> with a highly optimised CPU miner, you can expect 15 minutes. I doubt a pure C one can do 60 minutes.
302 2015-04-10 10:49:28 <wumpus> Luke-Jr: right, the numbers are likely off, but you get what I mean.
303 2015-04-10 10:49:59 <Luke-Jr> point being, I wouldn't recommend the same code be used for reference and testnet-mining because of this
304 2015-04-10 10:50:12 <wumpus> sure, okay
305 2015-04-10 11:17:47 <jtimon> sipa sorry I edited some of my comments which were wrong
306 2015-04-10 13:07:17 <btcphonesbiz__> samsung galaxy s6 and s6 edge now available with bitcoins at btcphones.biz
307 2015-04-10 14:39:07 <jtimon> my ugly proposal for to expose a VerfyBlockHeader in libconsensus is in https://github.com/bitcoin/bitcoin/pull/5995
308 2015-04-10 14:40:07 <jtimon> this is the ugly part https://github.com/jtimon/bitcoin/commit/0a37fee9e909f9b723319411948d8bd0e7c8c70e
309 2015-04-10 14:41:28 <jtimon> the whole thing will become more readable as some of the PR dependencies get merged
310 2015-04-10 15:26:39 <midnightmagic> I'm kind of thinking that committing the LXC signature rather than switching to the KVM to conform to the other builders might have a use on its own. i think i'm going to submit them even if they don't match the kvm-generated ones.
311 2015-04-10 18:02:05 <midnightmagic> :-o
312 2015-04-10 18:02:13 <midnightmagic> the LXC sigs match everyone else's for once.
313 2015-04-10 18:02:33 <midnightmagic> v0.10.1rc1 LXC gitian sigs match
314 2015-04-10 18:02:38 <midnightmagic> holy crap
315 2015-04-10 18:05:57 <midnightmagic> *-(  nope, they don't. nevermind.
316 2015-04-10 19:03:41 <cfields> jtimon: it's nitpicky, but imo using "params" to mean 2 things is going to get confusing. It's easy to understand once you're familiar, but "chainparams" vs "consusparams" would be much more readable imo
317 2015-04-10 19:04:42 <cfields> heh "consusparams". My brain quit part-way through, then resumed :)
318 2015-04-10 19:07:48 <jtimon> yeah, makes sense, I thought about that when I saw that theycould conflict with rpc's params
319 2015-04-10 19:08:03 <jtimon> but it's longer...
320 2015-04-10 19:08:31 <jtimon> anyway, yeah, I'll change it
321 2015-04-10 19:09:20 <jtimon> I just divided all the chainparams things required to delete the redundant getters in little independent PRs
322 2015-04-10 19:10:17 <jtimon> let me put the consensus_header branch in order and then I'll update them one by one
323 2015-04-10 19:15:24 <cfields> jtimon: main reason I say that is because I think several Consensus::Params will move to CChainParams as we continue nuke the Params() calls. That's going to make for some confusing code-review if they're named the same thing
324 2015-04-10 19:16:45 <jtimon> yep, you're right
325 2015-04-10 19:17:13 <jtimon> I mean, I thought about it for a second, but then continued and forgot about it
326 2015-04-10 19:17:51 <jtimon> but it's better that we change our PRs now than fixing it later