1 2014-03-11 00:01:10 <Luke-Jr> amiller: thanks
2 2014-03-11 00:17:42 <rodrigo31> Hi?
3 2014-03-11 00:17:51 <sipa> Hi!
4 2014-03-11 00:18:14 <rodrigo31> :O someone said that i needed to have an account to talk here....
5 2014-03-11 00:18:18 <rodrigo31> lol
6 2014-03-11 00:19:30 <rodrigo31> I have a question. I'm trying to crate something that I call "bitcoin analysis tool" .
7 2014-03-11 00:19:51 <rodrigo31> and i need to go through all the blocks on the blockchain
8 2014-03-11 00:20:01 <rodrigo31> can i do that with bitcoind ?
9 2014-03-11 00:21:17 <Luke-Jr> rodrigo31: why bother?
10 2014-03-11 00:23:11 <rodrigo31> Luke-Jr: what? why? i could tell you something like because I want.....
11 2014-03-11 00:23:29 <airbreather> rodrigo31: tell us what you're trying to do, not how you're trying to do it
12 2014-03-11 00:24:43 <rodrigo31> I want to go throught all the blocks and analyse each one of them. I want to start from the first one and go until the last one.
13 2014-03-11 00:24:59 <sipa> you can call getblock <hash>
14 2014-03-11 00:25:59 <Luke-Jr> rodrigo31: analyze in what way?
15 2014-03-11 00:26:40 <airbreather> getblockhash <height> gives the hash, then getblock <hash> gives the json block.
16 2014-03-11 00:27:11 <airbreather> height 0 is the genesis block
17 2014-03-11 00:31:22 <rodrigo31> airbreather: Thanks, that way i can start from 0 until getinfo.blocks...
18 2014-03-11 00:31:44 <Luke-Jr> ACTION notes that is probably the slowest possible way
19 2014-03-11 00:32:38 <rodrigo31> Luke-Jr: do you know a faster way?
20 2014-03-11 00:33:43 <Luke-Jr> read the block files directly
21 2014-03-11 00:34:28 <espringe> Calling: 'getrawtransaction' on 11347 transactions (in a batched jsonrpc req) ... crashed bitcoind [without my system running out of memory]
22 2014-03-11 00:34:49 <espringe> Is that a bitcoin bug, or what's the sane limit I should do for batched requests?
23 2014-03-11 00:34:59 <rodrigo31> Luke-Jr: if you can point me a good link exaplaining how to do that...
24 2014-03-11 00:35:20 <rodrigo31> because i'm using a python library to interact with bitcoind...
25 2014-03-11 00:35:48 <rodrigo31> if i could read the block files probably it would be better
26 2014-03-11 00:36:41 <Luke-Jr> rodrigo31: https://en.bitcoin.it/wiki/Protocol_specification#block
27 2014-03-11 00:40:43 <rodrigo31> Luke-Jr: it looks harder for me... I will try the easy path first... :)
28 2014-03-11 00:40:56 <rodrigo31> Maybe I will learn from my erros :)
29 2014-03-11 00:43:04 <jgarzik> drat, espringe dropped off
30 2014-03-11 00:53:28 <raminnoodle> Is it possible to call the rpc command "sinelastblock" with a value of null or something in the string? On older clients I am able to pass in an empty string if its the first time im running sincelastblock however if I try on the new client it says cant find block and it only works if I dont pass any parameter at all
31 2014-03-11 00:55:13 <sipa> jgarzik: espringe?
32 2014-03-11 00:55:33 <raminnoodle> listSinceBlock*
33 2014-03-11 00:55:56 <jgarzik> sipa, <espringe> Calling: 'getrawtransaction' on 11347 transactions (in a batched jsonrpc req) ... crashed bitcoind [without my system running out of memory]
34 2014-03-11 00:56:43 <jgarzik> Though clearly that is a bad idea, I'm curious if it was an rlimit or something else that killed bitcoind
35 2014-03-11 01:00:10 <phantomcircuit> jgarzik, how did it crash?
36 2014-03-11 01:00:21 <phantomcircuit> anything in dmesg?
37 2014-03-11 01:00:25 <jgarzik> phantomcircuit, exactly!
38 2014-03-11 01:00:50 <phantomcircuit> if it was an rlimit i would expect there to be something in dmesg
39 2014-03-11 01:02:01 <jgarzik> I suppose I could try to reproduce, but I'm feeling lazy
40 2014-03-11 01:19:12 <rodrigo31> 22 seconds 100 blocks ... to slow?
41 2014-03-11 01:40:44 <ntio> do transactions have in them the previous address balance? Or the number of transfers out of that address?
42 2014-03-11 01:42:45 <gmaxwell> ntio: see topic
43 2014-03-11 01:42:59 <gmaxwell> also, there are no balances at all in the actual implementation of the bitcoin system
44 2014-03-11 01:44:17 <raminnoodle> am I crazy or am i really seeing negative confs? http://pastebin.com/ay4qz8fM
45 2014-03-11 01:54:56 <gmaxwell> thats not output from bitcoind ... what is that from?
46 2014-03-11 01:55:22 <gmaxwell> (bitcoind can give a -1 for conflicted transactions, but it tells you the conflicts.. it also won't display amounts like that)
47 2014-03-11 02:04:27 <MinerGirl> Hi, a little question, do you think doge is more profitable than 365Coin? im mining it a www.mingopool.com but im not sure. People say 1 365coin have value of 20 ~ 50 BTC cause only 1 total coin a day but, what do you think? And if you are mining at mingopool, do you know if is true that monthly bounty?Hi, a little question, do you think doge is more profitable than 365Coin? im mining it a www.mingopool.com but im not sure. People say
48 2014-03-11 02:08:05 <raminnoodle> gmaxwell: thats from blockchain.info bitcoind rpc
49 2014-03-11 02:08:18 <raminnoodle> i guess they just send confs as negatives..
50 2014-03-11 02:10:03 <gmaxwell> or they're busted...
51 2014-03-11 02:10:11 <gmaxwell> I sure hope they don't show them as negatives.
52 2014-03-11 02:10:26 <raminnoodle> lol.. iv sent two transactions and both of them are in the high 10s with negative sir
53 2014-03-11 02:24:02 <alex_fun> hello
54 2014-03-11 02:25:08 <alex_fun> how I can connect multiple gpu righs with cgiminer to remote rpc daemon on box 2? I done it already - server 2 ram 30 GB however some miners keep dropping off
55 2014-03-11 02:25:17 <alex_fun> saying dead - then coming up again
56 2014-03-11 02:25:49 <alex_fun> multiple rpd connections from the same username to daemon
57 2014-03-11 02:28:58 <alex_fun> also is there any plans to implement zerocoin?
58 2014-03-11 02:29:05 <alex_fun> or similar solution
59 2014-03-11 02:41:56 <warren> http://download1.rpmfusion.org/~warren/openssl/ Updated openssl packages for Fedora 19 and 20, GPG signed by me.
60 2014-03-11 02:43:46 <warren> If anyone wants Fedora 21 ask me.
61 2014-03-11 02:51:46 <gmaxwell> Anyone aware of any recent changes on master which would make the first getinfo call after a restart take 12 seconds for me?
62 2014-03-11 02:53:13 <gmaxwell> it's 100% repeatable for me, so I can bisect... but it would go faster if someone had a guess. :)
63 2014-03-11 04:10:55 <copumpkin> anyone run bitcoin stuff on ARM linux distros?
64 2014-03-11 04:11:11 <copumpkin> err, this probably isn't the best place to ask, sorry
65 2014-03-11 04:54:21 <gffdffd> WTF
66 2014-03-11 05:07:38 <saracen> 0.0000000000000000000000000000000000000000000000000000000000000000021146%
67 2014-03-11 05:07:44 <saracen> That's the percentage of keys found by people hitting directory.io altogether so far.
68 2014-03-11 05:08:19 <gmaxwell> lol
69 2014-03-11 05:08:31 <saracen> Maybe I should put a progress bar up, as I'm still being crawled by people that clearly don't realise what they're doing
70 2014-03-11 05:14:08 <ewust> I got to the end, and then it just gave me a blank page :(
71 2014-03-11 05:23:52 <cornfeedhobo> some of these addreses had coins at them
72 2014-03-11 05:30:02 <Barbossa> sorry, its very vague quest but I want to understand bitcoin code (https://github.com/bitcoin/bitcoin).....
73 2014-03-11 05:30:08 <Barbossa> sorry, its very vague quest but I want to understand bitcoin code (https://github.com/bitcoin/bitcoin).....
74 2014-03-11 05:30:49 <Barbossa> can anyone tell me about the source to understand it properly
75 2014-03-11 05:33:23 <SomeoneWeird> saracen, obviously it generates them on the fly?
76 2014-03-11 05:33:42 <SomeoneWeird> >_>
77 2014-03-11 05:39:04 <cornfeedhobo> SomeoneWeird: you think it would grow faster
78 2014-03-11 05:39:11 <cornfeedhobo> if its otf
79 2014-03-11 05:46:09 <saracen> SomeoneWeird: correct
80 2014-03-11 05:53:28 <JimmyCoin> Hi, for some reason my bitcoin qt wallet has sent out .5 btc without any fees attached and I have had zero confirms in almost 24 hours. How can I fix this?
81 2014-03-11 05:55:00 <gmaxwell> JimmyCoin: have you left it online during those 24 hours?
82 2014-03-11 05:55:13 <JimmyCoin> No I havent
83 2014-03-11 05:55:19 <gmaxwell> JimmyCoin: this should move to #bitcoin
84 2014-03-11 05:55:29 <JimmyCoin> Ok I am there thanks
85 2014-03-11 06:06:56 <petertodd> jgarzik: done that scriptSig increase and wound up fixing the CHECKMULTISIG dummy arg mutability issue in the process: https://github.com/bitcoin/bitcoin/pull/3843
86 2014-03-11 06:49:02 <gmaxwell> wumpus: I can't understand what substrata is saying.
87 2014-03-11 06:49:10 <gmaxwell> testnet=1 works just fine in my config... thats how I run testnet.
88 2014-03-11 06:49:27 <wumpus> hm I noticed in the GUI it doesn't work in the configuration file
89 2014-03-11 06:50:40 <wumpus> the initialization order was changed around a bit (it's actually difficult now that the datadirectory can be configured through a registry setting *which are seperate for testnet/mainnet*)
90 2014-03-11 06:50:46 <gmaxwell> I don't understand that. ... oh you're saying that bitcoin-qt won't take testnet=1 in the config file but bitcoind will?! hm I have indeed not tested the gui that way.
91 2014-03-11 06:50:56 <wumpus> right
92 2014-03-11 06:51:33 <gmaxwell> (I have tested the gui with testnet, but I've been starting it with it on the commandline)
93 2014-03-11 06:51:49 <wumpus> the gui parses the command line to determine testnet/regtest/mainnet, then determines based on that where to look for registry settings, and only then determines the data directory
94 2014-03-11 06:51:58 <wumpus> yeah on the command line it works fine, I always use that
95 2014-03-11 06:52:50 <wumpus> and from this data directory it derives the configuration file name, then parses the configuration... the 'choice of network' was made a long time ago then
96 2014-03-11 06:53:09 <wumpus> always fun those chicken and egg problems :-)
97 2014-03-11 06:55:05 <wumpus> but his (2) is stranger
98 2014-03-11 06:55:16 <wumpus> he had to move the testnet files to the datadir root? huh?
99 2014-03-11 06:55:35 <wumpus> I can't think of any case where that would be necessary
100 2014-03-11 07:03:48 <wallet42> P(dorian == Nakamoto) ?
101 2014-03-11 07:04:11 <wumpus> enough of the satoshi speculation already
102 2014-03-11 07:04:48 <wallet42> sry i was disconnected for about a week and im just catching up and i wanted to know what -dev thinks
103 2014-03-11 07:05:17 <SomeoneWeird> wallet42, offtopic
104 2014-03-11 07:05:33 <SomeoneWeird> wallet42, #bitcoin-satoshispeculation
105 2014-03-11 07:06:14 <wallet42> SomeoneWeird: sorry for being OT
106 2014-03-11 07:34:19 <storeaff> hi. have you used Armory fragmented backups?
107 2014-03-11 07:35:06 <cornfeedhobo> storeaff: #bitcoin
108 2014-03-11 08:22:50 <Gouou> hey guys, when using btc daemon (rpc) do you use "accounts"? i'm thinking of doing a tipping bot for some altcoin and was wondering it's worth using "accounts" or is it better to store them in my own database
109 2014-03-11 08:24:21 <michagogo> cloud|Gouou: no, don't use bitcoind's accounts
110 2014-03-11 08:24:37 <michagogo> cloud|Especially not for handling multiple peoples' money
111 2014-03-11 08:24:39 <cornfeedhobo> storeaff: oops, i thought i was in a different chan :3
112 2014-03-11 08:24:49 <wumpus> indeed, don't use accounts, build your own database-based system
113 2014-03-11 08:24:50 <Gouou> michagogo|cloud: performance issue or security issue?
114 2014-03-11 08:25:05 <wumpus> it's going to be deprecated/removed
115 2014-03-11 08:25:19 <michagogo> cloud|Gouou: I mean, you can use accounts, iff you can afford to lose that data at any time :-P
116 2014-03-11 08:25:21 <Gouou> wumpus: oh it makes sense to not to use them
117 2014-03-11 08:25:52 <michagogo> cloud|They're all kinds of broken and/or weird, depending on how you look at it
118 2014-03-11 08:26:18 <wumpus> and for a good reasons.. for one, the current implementation sucks and behaves surprising to many people, also everyone wants something else from an account system, also managing third-party deposits is outside the scope of the reference client
119 2014-03-11 08:26:27 <Gouou> michagogo|cloud: what's the best way for checking incoming transactions?
120 2014-03-11 08:27:06 <Gouou> listreceivedbyaddress with excluded empty, seems a little bit un efficient for me
121 2014-03-11 08:27:48 <michagogo> cloud|Gouou: see the "help" rpc
122 2014-03-11 08:28:09 <michagogo> cloud|I think there was one called listsinceblock which might be helpful
123 2014-03-11 08:28:22 <michagogo> cloud|Also, walletnotify is helpful
124 2014-03-11 08:28:48 <michagogo> cloud|It runs a command when a wallet transaction is received (and again when it confirms, iirc)
125 2014-03-11 08:29:25 <Gouou> michagogo|cloud: thanks man i will look into it
126 2014-03-11 08:30:25 <michagogo> cloud|Gouou: but I'm not completely familiar with all of the RPC calls, so definitely look at the list
127 2014-03-11 08:30:43 <michagogo> cloud|(The `help` rpc)
128 2014-03-11 08:30:51 <Gouou> \help rpc
129 2014-03-11 08:30:58 <Gouou> ffs :D nvm
130 2014-03-11 08:31:30 <michagogo> cloud|And then `help #{command}` will give you details about individual calls
131 2014-03-11 08:31:56 <michagogo> cloud|Oh, and I'd suggest using 0.9.0rc, since the help texts were redone since 0.8
132 2014-03-11 08:33:11 <jouke> wumpus: the account-system will be deprecated? :( eta?
133 2014-03-11 08:33:57 <wumpus> jouke: it will be removed in JSON API v2, along with a few other RPC changes, no eta yet
134 2014-03-11 08:34:44 <wumpus> see https://github.com/bitcoin/bitcoin/issues/3816 and https://github.com/bitcoin/bitcoin/pull/3759
135 2014-03-11 08:36:23 <jouke> tnx
136 2014-03-11 08:37:17 <wumpus> note that 'labeling' of receiving addresses will continue to exist, just the account balances and 'virtual transactions' (with 'move') are going away
137 2014-03-11 08:50:25 <gribble> Development of the Bitcoin; This is for discussion about the Bitcoin network and reference software between developers. | http://bitcoin.org/ https://en.bitcoin.it/wiki/ | This channel is logged: http://bitcoinstats.com/ | There is no from address | No altcoin/bc.i/mtgox/bitstamp support | tell us what you're trying to do, not how you're trying to do it | register to talk
138 2014-03-11 08:50:25 <michagogo> cloud|;;topic
139 2014-03-11 09:22:44 <michagogo> cloud|If we're going to have an rc3, can we have 0.9.0rc3-linux?
140 2014-03-11 09:54:04 <speed-> hey, maybe this is not question for here, but still any idea why my wallet can't connect anywhere, even tho I added like 30+ nodes? :/
141 2014-03-11 09:54:40 <speed-> always says 'No block source available'
142 2014-03-11 09:58:53 <speed-> ah nevermind :p
143 2014-03-11 09:59:01 <speed-> solved it, thanks anyway \o :)
144 2014-03-11 10:06:09 <michagogo> cloud|11:22:48 <michagogo|cloud> If we're going to have an rc3, can we have 0.9.0rc3-linux? <-- To clarify: contrast with 0.9.0rc3, compare to 0.9.0rc3-win
145 2014-03-11 10:08:20 <vegard> so for long periods of time (while doing the initial block chain download) the server seems to get stuck. it doesn't answer rpc requests and 'netstat' shows that incoming data from other nodes is stuck on the recvq
146 2014-03-11 10:09:10 <vegard> the log is full of (only) "UpdateTip: new best=..." messages while this is going on
147 2014-03-11 10:11:58 <wumpus> vegard: this is with 0.9?
148 2014-03-11 10:13:14 <vegard> v0.9.0rc2-17-gd33f69a
149 2014-03-11 10:20:32 <wumpus> ok IMO that warrants a github issue
150 2014-03-11 10:21:08 <vegard> I'll try to debug it :-)
151 2014-03-11 10:29:42 <vegard> it got stuck for like 35 minutes and finally started responding now after saying "ProcessBlock: ACCEPTED" in the log
152 2014-03-11 10:33:42 <vegard> guess it was just stuck on the cs_main lock taken in ProcessMessage() for received "block" messages
153 2014-03-11 10:46:00 <fanquake> ;;blocks
154 2014-03-11 10:46:01 <gribble> 290018
155 2014-03-11 10:58:14 <noone2014> hello
156 2014-03-11 10:59:56 <noone2014> I am new to IRC and I want to ask question about Multibit client. How may I do it?
157 2014-03-11 11:01:03 <wumpus> depends on the kind of question, this is a development channel, not tech support
158 2014-03-11 11:01:05 <t7> maybe search for a multibit channel or ask in #bitcoin
159 2014-03-11 11:10:53 <noone2014> this is a development question. I am trying to compile Miltibit on Windows (IDEA 13.0.2) and I am stuck with 2 test failures. Where can I look for explanations? Can I post errors here?
160 2014-03-11 11:12:15 <nkuttler> noone2014: ask in #multibit, this channel is for the reference software
161 2014-03-11 11:13:08 <noone2014> OK, thanks
162 2014-03-11 11:23:23 <lagarde_> !seen gavinandresen
163 2014-03-11 11:23:24 <gribble> gavinandresen was last seen in #bitcoin-dev 17 hours, 16 minutes, and 33 seconds ago: <gavinandresen> writing code that might be picked up by script-kiddies to disrupt parts of the network isn't particularly helpful
164 2014-03-11 12:02:20 <t7> gavinandresen hates full disclosure
165 2014-03-11 12:48:03 <lagarde_> !seen tysat
166 2014-03-11 12:48:04 <gribble> I have not seen tysat.
167 2014-03-11 15:38:44 <sipa> petertodd: are you sure you can fit a checkmultisig of 15 keys in 510 bytes?
168 2014-03-11 15:39:30 <sipa> OP_n + 15*(push 33 bytes) + OP_MULTICHECKSIG = 2 + 15*34 = 512
169 2014-03-11 15:44:36 <waxwing> sipa, I thought the limit was 520?
170 2014-03-11 15:44:58 <waxwing> btw I tried 8/15 and 14/15 today via Eligius; the first was OK, the second rejected
171 2014-03-11 15:46:18 <gavinandresen> waxwing: what is your use case for those? or are you just fooling around?
172 2014-03-11 15:46:34 <waxwing> voting pool type thing
173 2014-03-11 15:46:42 <waxwing> although 14/15 was really playing around
174 2014-03-11 15:47:23 <waxwing> is there a sigopcount issue? I only ask from scanning around the code
175 2014-03-11 15:51:05 <TD> wumpus: ping
176 2014-03-11 15:54:06 <wumpus> pong
177 2014-03-11 15:54:16 <sipa> waxwing: ugh, right :)
178 2014-03-11 15:55:10 <jgarzik> I continue to want to lib-ify Bitcoin Core C++ code, and use it in my own projects
179 2014-03-11 15:55:59 <TD> wumpus: what's your email address?
180 2014-03-11 15:56:13 <jgarzik> libbitcoin_common.a unfortunately fails to capture a lot of the useful code. You need libbitcoin_server.a too
181 2014-03-11 15:56:32 <wumpus> right, you'd have to change the split a bit
182 2014-03-11 15:56:45 <jgarzik> main.cpp is still too fat :)
183 2014-03-11 15:56:52 <sipa> jgarzik: it absolutely is
184 2014-03-11 15:57:00 <wumpus> agreed there
185 2014-03-11 15:57:15 <wumpus> TD: see pm
186 2014-03-11 15:57:16 <sipa> the largest problem imho is the very unclear separation between net/protocol and main
187 2014-03-11 15:57:22 <TD> yup thanks
188 2014-03-11 15:57:50 <sipa> the node-specific data structures are mostly accessed from main, which does the protocol handling
189 2014-03-11 15:57:56 <sipa> while they're defined in net
190 2014-03-11 15:58:11 <jgarzik> main.cpp is really The Thing That Glues Everything Together
191 2014-03-11 15:58:25 <wumpus> ideally, main shouldn't care about nodes at all, just the blockchain and blocks
192 2014-03-11 15:58:28 <sipa> i'm going to propose something controversial:
193 2014-03-11 15:58:32 <sipa> merge main and net
194 2014-03-11 15:58:44 <sipa> and then split validation from protocol handling
195 2014-03-11 15:58:49 <wumpus> make it fatter :)
196 2014-03-11 15:58:56 <jgarzik> main is really "handle P2P messages, resulting in a blockchain"
197 2014-03-11 15:58:57 <sipa> yes, but currently it's horrible
198 2014-03-11 15:59:05 <jgarzik> move all the useful helpers out of main
199 2014-03-11 15:59:09 <sipa> it seems to try to separate the two
200 2014-03-11 15:59:10 <jgarzik> keep core logic
201 2014-03-11 15:59:10 <sipa> but it does not
202 2014-03-11 15:59:11 <wumpus> yes, split validation from protocol handling
203 2014-03-11 15:59:28 <sipa> from the file names, you'd say that net is protocol handling and main is validation
204 2014-03-11 15:59:33 <sipa> and for the headers that is true
205 2014-03-11 15:59:37 <sipa> but not for the code
206 2014-03-11 15:59:39 <jgarzik> IMO the core core of main is ProcessMessage()... everything branches out from there
207 2014-03-11 15:59:50 <sipa> and SendMessages
208 2014-03-11 15:59:51 <wumpus> sipa: yes that gets me every time!
209 2014-03-11 15:59:53 <jgarzik> yes
210 2014-03-11 16:00:10 <sipa> so main is constantly locking net's mutexes
211 2014-03-11 16:00:11 <wumpus> I try to look up where a certain P2P message is handled and I look in net.cpp
212 2014-03-11 16:00:15 <sipa> which it would have no need for if it just has its own
213 2014-03-11 16:00:26 <sipa> i've tried to do that partially already
214 2014-03-11 16:00:33 <sipa> by adding CNodeState in main
215 2014-03-11 16:00:40 <sipa> which net is oblivious about
216 2014-03-11 16:00:53 <gmaxwell> before I start bisecting, anyone know why the first run of getinfo after a restart is taking my laptop 12 seconds?
217 2014-03-11 16:01:05 <gmaxwell> I believe this is a new behavior in master as of the last couple weeks.
218 2014-03-11 16:01:05 <sipa> imho, pretty much everything except raw p2p message handling should move from CNode to CNodeState
219 2014-03-11 16:01:15 <wumpus> gmaxwell: large wallet?
220 2014-03-11 16:01:31 <jgarzik> debug.log shows nothing? any keypool activity?
221 2014-03-11 16:01:35 <wumpus> in that case could be the vtxprev/spent removal change
222 2014-03-11 16:01:43 <gmaxwell> wumpus: not really large, 1300 transactions or so.
223 2014-03-11 16:02:07 <sipa> or maybe rather the try-to-recover-metadata-of-conflicts thing
224 2014-03-11 16:02:09 <jgarzik> gmaxwell, approx number of keys?
225 2014-03-11 16:02:14 <wumpus> apart from that I know of nothing that would make getinfo slower, we didn't add anything to it for long
226 2014-03-11 16:02:19 <gmaxwell> ah. point, okay I'll bisect, it's easy to test.
227 2014-03-11 16:02:33 <gmaxwell> I think I would have noticed if it were the conflicts stuff...
228 2014-03-11 16:02:42 <gmaxwell> (just because I was testing that pretty actively)
229 2014-03-11 16:03:28 <sipa> hmm, only the first time
230 2014-03-11 16:03:39 <sipa> gmaxwell: can you isolate it to computing the wallet balance?
231 2014-03-11 16:03:52 <sipa> so getbalance without getinfo should exhibit the same behaviour
232 2014-03-11 16:04:31 <tonikt> hi guys. i'm working on making multisig txs. can anyone please give me some clue what OP_0 is doing at the beginning of each sigscript that spends a P2SH output - what is it for?
233 2014-03-11 16:04:40 <sipa> tonikt: working around abug
234 2014-03-11 16:04:55 <sipa> checkmultisig pops off one element too many
235 2014-03-11 16:05:09 <jgarzik> I <heart> git bisect run my_script
236 2014-03-11 16:05:51 <tonikt> sipa: oh, ok - so it just must be there?
237 2014-03-11 16:06:00 <sipa> yes
238 2014-03-11 16:06:00 <tonikt> thx
239 2014-03-11 16:06:08 <jgarzik> tonikt, yes, for historical reasons (hysterical raisins)
240 2014-03-11 16:06:55 <tonikt> ok, got you. cheers
241 2014-03-11 16:07:13 <gmaxwell> sipa: yes, the getbalance is the slow thing.
242 2014-03-11 16:09:16 <sipa> gmaxwell: sounds like slow balance computation (perhaps because of the mempool checking?), which then gets cached
243 2014-03-11 16:09:34 <sipa> 12s is really quite ridiculous
244 2014-03-11 16:10:55 <gmaxwell> yea, and this wallet is not huge. I think there are 200 keys in it and 1200 transactions.
245 2014-03-11 16:11:25 <wumpus> but isn't the mempool empty at start?
246 2014-03-11 16:12:09 <sipa> it may make sense to try counting how many time some of the internal wallet methods are called during that call
247 2014-03-11 16:12:20 <sipa> perhaps there is some weird exponential behaviour
248 2014-03-11 16:12:32 <wumpus> yes this is one of the cases where a profiler is useful
249 2014-03-11 16:12:35 <gmaxwell> I could just profile it.
250 2014-03-11 16:12:48 <wbaw> can't you cache it?
251 2014-03-11 16:13:55 <wbaw> is it just the first time it's slow?
252 2014-03-11 16:14:06 <gmaxwell> it's just the first time.
253 2014-03-11 16:14:26 <sipa> the reason it's only slow the first time is exactly because after the first time is is cached (presumable)
254 2014-03-11 16:14:31 <jgarzik> easy enough to pre-cache in init
255 2014-03-11 16:14:42 <jgarzik> startup is slow as it is
256 2014-03-11 16:21:58 <waxwing> just to repeat from earlier, does anyone know why a 14/15 p2sh would not work? might there be an issue with sigopcount? or is that not relevant.
257 2014-03-11 16:22:52 <sipa> define "not work"
258 2014-03-11 16:24:10 <waxwing> rejected by Eligius
259 2014-03-11 16:24:41 <waxwing> it's non standard anyway because the scriptsig is too big
260 2014-03-11 16:24:59 <waxwing> I mentioned earlier 8/15 was ok
261 2014-03-11 16:26:30 <devrandom> waxwing: you can compile bitcoind yourself, turning off IsStandard and see if it's still rejected
262 2014-03-11 16:27:57 <waxwing> devrandom, hmm I guess that's true. Thanks for the suggestion. Was hoping it could be attacked by reasoning :)
263 2014-03-11 16:28:33 <sipa> i don't understand your question anymore
264 2014-03-11 16:28:33 <sipa> you ask why it gets rejected
265 2014-03-11 16:28:43 <sipa> but then give the answer yourself?
266 2014-03-11 16:29:17 <devrandom> I think waxwing is assuming that Eligius accepts all !IsStandard txs
267 2014-03-11 16:29:43 <devrandom> but it probably fails some other check or Eligius has some weaker IsStandard the the tx falls afoul of
268 2014-03-11 16:31:21 <waxwing> devrandom, yes i realised today that I must be hitting some other limit; I just wanted to know what that limit was
269 2014-03-11 16:31:33 <waxwing> so as to understand what the "hard" limits on P2SH size were
270 2014-03-11 16:31:43 <gmaxwell> you cannot have a redeemscript over 520 bytes.
271 2014-03-11 16:32:04 <waxwing> ok, but with compressed pubkeys it's under 520 with N=15
272 2014-03-11 16:32:23 <waxwing> hence 8/15 worked
273 2014-03-11 16:32:32 <gmaxwell> In any case, eligius has a bunch of its own anti-spam rules.
274 2014-03-11 16:32:47 <waxwing> right; I guess it's somewhat off topic in that it's Luke-Jr's own code
275 2014-03-11 16:33:17 <waxwing> my original question was though, if someone could help me understand what the sigop count limit is
276 2014-03-11 16:33:39 <waxwing> because it looked like that was one potential limit (although I really dont understand)
277 2014-03-11 16:33:42 <sipa> max 20k sigops in a block
278 2014-03-11 16:33:56 <gmaxwell> p2sh sigops are counted accurately though
279 2014-03-11 16:34:21 <waxwing> oh ok per block only in standard bitcoin? or per tx limit also?
280 2014-03-11 16:34:54 <gmaxwell> Thats a block validity rule
281 2014-03-11 16:36:20 <gmaxwell> god knows why the limit is 520. weird number.
282 2014-03-11 16:37:07 <waxwing> gmaxwell, petertodd has a pull request to change it for p2sh I think, he mentioned it yesterday
283 2014-03-11 16:37:39 <sipa> waxwing: it does not, and cannot
284 2014-03-11 16:39:03 <waxwing> sipa, i didn't get it, context please?
285 2014-03-11 16:39:27 <sipa> script data pushes are at most 520 bytes, that's a hard rule
286 2014-03-11 16:39:54 <sipa> petertodd's pullreq changes the maximum size of the scriptSig
287 2014-03-11 16:40:05 <sipa> not of the redeemScript
288 2014-03-11 16:40:09 <waxwing> oh i'm sorry, of course, i got it mixed up
289 2014-03-11 16:42:00 <gmaxwell> (I assume that the reason the limit is 520 because some encoding of a 4kbit rsa signature was that big... or something like that... lost to the mists of time)
290 2014-03-11 17:00:52 <Luke-Jr> michagogo|cloud: there's nothing broken/weird about accounts; they just don't work with B-Qt and require constant backups :P
291 2014-03-11 17:02:11 <sipa> they are useful for one particular purpose, but many assume they have properties they don't
292 2014-03-11 17:02:26 <sipa> in addition, they interact badly with labels, and indeed require constant backups
293 2014-03-11 17:02:46 <anton000> blockahin.info's dowwn?
294 2014-03-11 17:02:48 <sipa> it's just a problem that better solved in the layer on top of bitcoin
295 2014-03-11 17:03:03 <gmaxwell> just convering them to being tags/labels accomplishes 95% of what they're currently good for and avoids a bunch of code.
296 2014-03-11 17:03:05 <sipa> so it can be synchronized with application laye
297 2014-03-11 17:05:20 <Luke-Jr> should be fairly trivial to add it back as an external layer (proxy, even)
298 2014-03-11 17:06:52 <gmaxwell> yea and such a layer could do proper data replication so you don't have the backup issue.
299 2014-03-11 17:23:25 <melik> hi there everyone i apologize if this question has been asked a million times
300 2014-03-11 17:24:16 <melik> but 1) what is the best way to parse the blockchain? are there any good APIs we can use, or is it better to write code to manually do it
301 2014-03-11 17:38:55 <devrandom> I wrote a short article about hardware wallet security
302 2014-03-11 17:39:13 <devrandom> anybody up to reviewing? https://github.com/devrandom/btc-papers/blob/master/hardware-wallet-security.md
303 2014-03-11 17:39:31 <devrandom> *up for
304 2014-03-11 17:49:48 <gmaxwell> devrandom: needs work
305 2014-03-11 17:50:25 <gmaxwell> devrandom: I'm not currently aware of a way in ecdsa to eliminate the nonce channel securely while still allowing the signer to know what they're signing.
306 2014-03-11 17:50:59 <gmaxwell> I'd harassed wallet makers in the past to use determinstic dsa so that with auditing the problem reduces to the initial randomness.
307 2014-03-11 17:51:38 <gmaxwell> With schnorr signatures the signatures can be rerandomized (e.g. like a 2-of-2 threshold signature) in order to eliminate the subliminal channel.
308 2014-03-11 17:51:59 <gmaxwell> Maybe its possible with ECDSA but the only approach I'm aware of prevents the device from knowing what its signing. :(
309 2014-03-11 17:52:27 <gmaxwell> (which means you can't do things like have it give you a reliable display of the destination and value, largely mooting the advantage of the hardware)
310 2014-03-11 17:53:56 <devrandom> gmaxwell: looks like http://www.jofcis.com/publishedpapers/2011_7_4_1254_1261.pdf has a scheme to collaboratively choose a random signature k
311 2014-03-11 17:54:08 <devrandom> my scheme doesn't work actually, since it discloses k to Warden
312 2014-03-11 17:54:55 <gmaxwell> right, I'd just assumed you didn't mean that. :P
313 2014-03-11 17:55:01 <devrandom> hmm... need to look at that paper closer
314 2014-03-11 17:55:04 <gmaxwell> since that trivialy recovers the private key.
315 2014-03-11 17:55:29 <gmaxwell> it's irritating, this is trivial to solve with schnorr.
316 2014-03-11 18:01:24 <dhill> gavinandresen: would bitcoind be opposed to adding a license to their tests?
317 2014-03-11 18:02:27 <Luke-Jr> dhill: huh?
318 2014-03-11 18:03:28 <dhill> i'd like to use the same tests bitcoind does in my code
319 2014-03-11 18:03:47 <gmaxwell> dhill: I think we intend to have them licensed the same as the rest of the code, they just lacked the headers.
320 2014-03-11 18:03:47 <Luke-Jr> oh, MIT license not explicitly on those files
321 2014-03-11 18:03:50 <Luke-Jr> sigh
322 2014-03-11 18:04:20 <gmaxwell> dhill: Can you just open an issue? I believe it's pure oversight.
323 2014-03-11 18:04:24 <dhill> sure can
324 2014-03-11 18:04:35 <Luke-Jr> like 30 people need to sign off on it :x
325 2014-03-11 18:06:33 <gmaxwell> The tests? meh. 29 names in git blame on tests/*.cpp 7 in tests/data/*.json
326 2014-03-11 18:06:52 <sipa> let's do it
327 2014-03-11 18:06:55 <espringe> Does bitcoind's maxconnections affect the amount of rpcconnections ?
328 2014-03-11 18:06:59 <sipa> espringe: no
329 2014-03-11 18:07:09 <espringe> i.e. if bitcoind is using the maximium connections, it still lets rpc connections?
330 2014-03-11 18:07:16 <dhill> gmaxwell: #3848
331 2014-03-11 18:07:17 <sipa> espringe: they're completely independent
332 2014-03-11 18:07:18 <dhill> thanks
333 2014-03-11 18:07:40 <gmaxwell> (It's debatable that any request is really needed given the top level package licensing, but always better to make fewer assumptionsâ¦)
334 2014-03-11 18:07:56 <espringe> My bitcoind keeps rejecting rpc connections after its been running long enough. But the actual node is working fine
335 2014-03-11 18:08:00 <espringe> The only thing I can do is reset it
336 2014-03-11 18:08:13 <espringe> Nothing to do with memory, cpu or file descriptors
337 2014-03-11 18:10:13 <gmaxwell> CodeShark: gavinandresen: BlueMatt: sipa: petertodd: wumpus: grau: you are the only other people who git blame implicates for the json data. Please go ack https://github.com/bitcoin/bitcoin/issues/3848
338 2014-03-11 18:11:04 <CodeShark> huh?!
339 2014-03-11 18:11:08 <BlueMatt> gmaxwell: done
340 2014-03-11 18:11:14 <BlueMatt> CodeShark: just go post a copy of my comment there
341 2014-03-11 18:14:13 <Joric> does he assume you have to put a license in every folder
342 2014-03-11 18:14:36 <gmaxwell> sipa: you'd think that after seperately counting the json and test/ I would have correctly read dhill's message. (I read it as asking only about the json somehow)
343 2014-03-11 18:15:46 <gmaxwell> Joric: the normal practice is to include it on every file. There isn't any reason to believe you actually have to do this, though because its so common (and because e.g. debian's packaging guidelines require it) there is some potenntial that someone might have a different understanding, so its better to ask than risk any surprise drama.
344 2014-03-11 18:16:12 <dhill> i am specifically wanting to use the tests in hash_tests.cpp right now
345 2014-03-11 18:17:22 <gmaxwell> dhill: everything of interest in hash_tests.cpp is petertodd
346 2014-03-11 18:17:44 <gmaxwell> I think he's asleep or otherwise AFK at the moment.
347 2014-03-11 18:17:57 <gmaxwell> in any case, in a couple hours it should be mostly all sorted and we'll change it.
348 2014-03-11 18:18:08 <dhill> \o/
349 2014-03-11 18:18:48 <gmaxwell> dhill: please feel free to submit some pulls for more tests too. :) if you push tests in our direction it reduces the risk that any incompatiblities get introduced in the future. :)
350 2014-03-11 18:19:10 <dhill> well do
351 2014-03-11 18:21:10 <dhill> how long does a ban on an ip last
352 2014-03-11 18:21:55 <gmaxwell> dhill: 24 hours. It's configurable.
353 2014-03-11 18:22:29 <vegard> I created src/test/script_tests.cpp, do I need to comment on the github issue as well?
354 2014-03-11 18:22:39 <gmaxwell> mostly it's just to prevent obviously broken peers from wasting resources... e.g. sending you invalid signatures to grind with your cpu.
355 2014-03-11 18:22:46 <gmaxwell> vegard: please.
356 2014-03-11 18:24:32 <gmaxwell> td: you too, jgarzik as well go ack https://github.com/bitcoin/bitcoin/issues/3848 (I'll hunt wahtever straglers remain after we get most of it)
357 2014-03-11 18:28:01 <Emcy_> 0.9 soon?
358 2014-03-11 19:26:12 <michagogo> cloud|If it's possible (and I don't see why not, personally, but you may disagree) I'd like to get #3775 and #3806 merged in time for rc3...
359 2014-03-11 19:29:13 <ewust> gmaxwell: re: <@gmaxwell> devrandom: I'm not currently aware of a way in ecdsa to eliminate the nonce channel securely while still allowing the signer to know what they're signing.
360 2014-03-11 19:29:32 <ewust> why doesn't deterministic dsa solve that, and why does it need to be randomized?
361 2014-03-11 19:29:46 <gmaxwell> ewust: no it doesn't solve it at all.
362 2014-03-11 19:30:28 <gmaxwell> an observe cannot tell if your DSA was determinstic or not. (well at all is a bit strong, I think these devices should use determinstic dsa to be more auditable, but on a case by case basis it doesn't prevent the leak)
363 2014-03-11 19:31:17 <ewust> are you saying k = HMAC(device_secret, message)?
364 2014-03-11 19:31:45 <ewust> or is the problem that the device can't have device_secret?
365 2014-03-11 19:32:21 <michagogo> cloud|Question about deterministic dsa... (And this might be an idiotic question, sorry in advance)
366 2014-03-11 19:32:48 <gmaxwell> ewust: the device can have it nothing else can.
367 2014-03-11 19:33:00 <michagogo> cloud|The determinism is in the value that must be unique for signatures with the same key otherwise the key is revealed, right?
368 2014-03-11 19:33:32 <michagogo> cloud|Why not just have a counter and sign with 1, then 2, then 3, et cetera?
369 2014-03-11 19:33:49 <gmaxwell> michagogo|cloud: it must be unknown to everyone else.
370 2014-03-11 19:33:52 <ewust> michagogo|cloud: it also has to be secret (the k value)
371 2014-03-11 19:34:14 <michagogo> cloud|Ah
372 2014-03-11 19:34:42 <michagogo> cloud|I suspected it might be something like that :-P
373 2014-03-11 19:35:46 <ewust> gmaxwell: i'm not sure i understand how k = HMAC for hardware wallets doesn't solve the problem
374 2014-03-11 19:35:57 <ewust> perhaps i am thinking of the wrong problem :)
375 2014-03-11 19:38:03 <gmaxwell> ewust: maybe because you are not thinking of an adversarial model? (or you are desynced and have no idea what was being discussed there)
376 2014-03-11 19:38:23 <gmaxwell> If the device actually does what you specified you're fine. But you cannot tell if it did or didn't.
377 2014-03-11 19:39:23 <ewust> ah i see now, thanks
378 2014-03-11 19:46:35 <rodrigo31> Hi, i'm back!
379 2014-03-11 19:46:47 <rodrigo31> How much space does bitcoin blockchain uses?
380 2014-03-11 19:46:55 <rodrigo31> runing out of space here...
381 2014-03-11 19:52:09 <mikeche1en> 15gb? something like that
382 2014-03-11 19:53:44 <rodrigo31> 15GB? What?
383 2014-03-11 19:53:56 <rodrigo31> i Have 8 ... (used)
384 2014-03-11 19:54:50 <mikeche1en> well you are about halfway then
385 2014-03-11 19:55:35 <dexX7> more like 18-20
386 2014-03-11 20:03:16 <helo> 19G here