1 2014-02-27 00:07:46 <HM2> any projects out there for making talking to bitcoind easier?
2 2014-02-27 00:08:06 <HM2> i toyed with a json rpc -> apache thrift bridge last year but couldn't be arsed to finish it
3 2014-02-27 00:12:43 <Persopolis> HM2: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) lots of links in that page
4 2014-02-27 00:35:59 <jgarzik> Should the mempool janitor print out TX hashes removed?
5 2014-02-27 00:36:16 <jgarzik> ACTION is leaning towards yes
6 2014-02-27 00:36:45 <gmaxwell> jgarzik: might be a kinda mild disk exhaustion dos attack. Certantly with debugging enabled.
7 2014-02-27 00:37:32 <jgarzik> gmaxwell, I think right now LogPrint("mempool",...) should not log by default
8 2014-02-27 00:39:02 <bitanarchy> what is the diff adjustment algo of dogecoin?
9 2014-02-27 00:39:28 <gmaxwell> bitanarchy: Questions that don't belong in this channel.
10 2014-02-27 00:40:33 <bitanarchy> well, doge has about the same hashing power as litecoin so I have to take a look at it 8D
11 2014-02-27 00:41:56 <gmaxwell> Another subject which does not belong in this channel.
12 2014-02-27 00:42:53 <bitanarchy> ok, excuse me
13 2014-02-27 01:03:41 <Imbue> hello
14 2014-02-27 01:04:10 <Imbue> what is the significance of the target adjustment period (~2000 blocks)? why is it not lower?
15 2014-02-27 01:04:19 <Imbue> rather why was 2000 chosen initially
16 2014-02-27 01:16:39 <Persopolis> Imbue - 2016 blocks @ avg 10mins is approx = 2 weeks
17 2014-02-27 01:17:57 <Persopolis> i believe the 2 weeks is the value chosen (suspect finger in the air) and 2016 calculated as ots equivalent
18 2014-02-27 01:52:58 <Imbue> connection dropped.
19 2014-02-27 01:53:16 <Imbue> Persepolis: I understand that it's about 2 weeks, but what's special about that?
20 2014-02-27 01:53:46 <Imbue> a lower period would be preferred in case of hashpower loss
21 2014-02-27 01:54:05 <Imbue> but too low means that someone can attack by turning on a lot of hashpower for a short period?
22 2014-02-27 01:54:25 <tlrobinson_> gmaxwell: btw is "proof of reserves" an adequate shorter name for your "prove-how-(non)-fractional-your-Bitcoin-reserves-are" scheme?
23 2014-02-27 01:55:46 <gmaxwell> tlrobinson_: sounds fine to me.
24 2014-02-27 02:23:29 <jgarzik> does anybody have a Tor address that I can -addnode?
25 2014-02-27 02:24:58 <dhill> sure
26 2014-02-27 02:25:29 <dhill> rfgkjihao2ymrr73.onion
27 2014-02-27 02:34:46 <dhill> that work for you?
28 2014-02-27 02:47:05 <midnightmagic> jgarzik: Yeah for sure.
29 2014-02-27 02:57:55 <cobordism> hello everyone
30 2014-02-27 02:59:04 <cobordism> I've just come over from #mtgox-chat. I'm curious about the theory that MTGox lost their coins due to an EC bug in their custom wallet software.
31 2014-02-27 02:59:18 <cobordism> also floated here: http://letstalkbitcoin.com/somethings-not-right-at-gox/
32 2014-02-27 02:59:43 <cobordism> I was wondering if someone here could explain the idea to me a little better.
33 2014-02-27 03:00:30 <kadoban> cobordism: guessing what bugs could exist in software that nobody-who's-talking has seen seems a little pointless
34 2014-02-27 03:00:35 <cobordism> I know transactions are signed using elliptic curve cryptography and that a receiving bitcoin address is essentially a public key to a private key.
35 2014-02-27 03:00:52 <cobordism> kadoban, I just wanted to understand what the suggestion was
36 2014-02-27 03:03:19 <cobordism> am I right in thinking: the suggestion/speculation is that they implemented the cryptography wrong, and that they then, subsequently, transferred coins to an address that they thought they had the keys to but didn't?
37 2014-02-27 03:08:28 <olalonde> Any core devs here https://github.com/olalonde/blind-solvency-proof? would it be OK for me to write a BIP for ? Would be interesting to standardize at least the verification algorithm and the data format for publishing trees / root node
38 2014-02-27 03:08:38 <olalonde> oops
39 2014-02-27 03:15:09 <Luke-Jr> olalonde: you don't need permission
40 2014-02-27 03:15:20 <Luke-Jr> olalonde: write it up, send a draft to the dev ML, and ask for a BIP to be assigned
41 2014-02-27 03:15:59 <gmaxwell> olalonde: make sure you specify it in a way that someone not coding in JS could be compatible. (e.g. don't have hidden serialization behavior)
42 2014-02-27 03:18:33 <viic> cobordism: I think the main point is that it seems impossible that Gox had 750k btc stolen via the malleability attacks, as their story goes ... but more likely they have lost access to their coins via key mismanagement or bugged software ... there are a few theories about the nature of such a bug and one of them involves a failure of deterministic wallet software, among others
43 2014-02-27 03:21:16 <cobordism> yes. I understand that. nobody believes that malleability could lead to 700k stolen (and certainly not unnoticed)
44 2014-02-27 03:21:25 <olalonde> Luke-Jr: gmaxwell: ok thanks
45 2014-02-27 03:38:57 <olalonde> gmaxwell: I like your nonce idea but wouldn't it be simpler instead of always assigning a "dummy" user with balance 0 and some random hash as the neighboor to real users?
46 2014-02-27 03:40:04 <olalonde> gmaxwell: that way your hash would simply be your plaintext username and it would be easier to verify that you are given a unique tree
47 2014-02-27 03:40:11 <gmaxwell> thats just a nonce too.
48 2014-02-27 03:40:23 <gmaxwell> How would it be easier to verify that you are given a unique tree??
49 2014-02-27 03:41:59 <olalonde> Hmm right
50 2014-02-27 03:42:30 <olalonde> I'm just thinking it would simplify the data format if we want it to be standard
51 2014-02-27 03:42:37 <gmaxwell> I think it's effectively the same thing, maybe it makes the implementation cleaner to do it one way vs another, though you double the size of the tree. and perhaps complicate a smarter encoder. but I think it's really the same, basically your penultimate node is the real leaf with just a funny encoding.
52 2014-02-27 03:43:06 <olalonde> right
53 2014-02-27 03:43:45 <gmaxwell> Would it? You define a leaf as H(username,value,nonce),value and then its just an ordinary tree with no must be 0 neighbor constraint.
54 2014-02-27 03:44:58 <olalonde> yeah i think i might go with that idea
55 2014-02-27 03:45:32 <olalonde> then when the verifier could still display your username , balance if the tree is in a standard data format with the 3 values clearly identified
56 2014-02-27 03:46:54 <olalonde> how big should the nonce be to be reasonably secure against someone trying to bruteforce the hash with known usernames for example?
57 2014-02-27 03:46:57 <gmaxwell> olalonde: to complicate your life slightly, someone suggested that it might be useful if you could also publish all the user proofs so they could be archived. e.g. useful to catch if your balance was temporarily stolen but then returned. So one way to achieve that is to just encrypt the whole users proof... then you could publish everything too, so someone may want to add that to the bip. I'm still mulling how useful that is... though ...
58 2014-02-27 03:47:03 <gmaxwell> ... it would just be an on-top-of thing and the scheme wouldn't otherwise change.
59 2014-02-27 03:47:34 <olalonde> ah that's interesting
60 2014-02-27 03:47:36 <gmaxwell> olalonde: I think you don't have to specify it, though I'd use 128 bits sort of by default.
61 2014-02-27 03:48:32 <olalonde> so you publish the proof tree in encrypted format and you publish your key if someone wants to audit you or something like that?
62 2014-02-27 03:49:09 <olalonde> ah I see what you mean
63 2014-02-27 03:49:25 <olalonde> each user should have an archive of their proofs .. for every day in the past 30 days for example?
64 2014-02-27 03:51:07 <olalonde> for now, i will work on the nonce issue
65 2014-02-27 03:53:10 <olalonde> and write some test :)
66 2014-02-27 04:24:47 <catcow> is it possible for the 0.8.5-beta client to generate an invalid address?
67 2014-02-27 05:04:03 <gmaxwell> catcow: generate how? invalid how? and regardlessâ the answer is almost certantly no.
68 2014-02-27 05:06:10 <catcow> well, i generated a new address in the client, copied it, pasted it to a friend, and he tried to send btc to it, and it failed the crc check
69 2014-02-27 05:06:29 <catcow> we both double checked ourselves, still didn't work
70 2014-02-27 05:06:41 <catcow> i then gave him an older address i had used, and it worked fine
71 2014-02-27 05:07:08 <catcow> but yea, i thought that would be the answer--a certain no--i just can't figure out where we went wrong...
72 2014-02-27 05:07:22 <gmaxwell> catcow: missed the last character in the copy and paste?
73 2014-02-27 05:07:47 <catcow> nope, i used the copy button instead of highlighting all the text, also checked it visually a couple times
74 2014-02-27 05:08:08 <catcow> i always note the first few chars and the last few chars when doing this to make sure nothing got chopped off
75 2014-02-27 05:08:16 <catcow> i wonder if my client is compromised somehow...
76 2014-02-27 05:11:17 <gmaxwell> well do you still have what you sent? you can ask your client to verify it for you.
77 2014-02-27 05:11:20 <gmaxwell> \
78 2014-02-27 05:11:37 <gmaxwell> e.g. open up the console and run validateaddress <Address>
79 2014-02-27 05:13:40 <nezZario> I'm just being nosey .. are you a dev andytoshi ?
80 2014-02-27 05:15:28 <andytoshi> nezZario: not really, no
81 2014-02-27 05:15:44 <andytoshi> nezZario: i know the code reasonably well, i have one commit
82 2014-02-27 05:15:47 <catcow> gmaxwell, checks okay when i do that. i'm off to bed, will troubleshoot more tomorrow. thanks for your help.
83 2014-02-27 05:22:57 <nezZario> andytoshi: well that's better than zero... sorry to be nosey .. just curious
84 2014-02-27 05:27:55 <andytoshi> nezZario: lol, that's fine, i pretend to be an authority on bitcoin often enough
85 2014-02-27 05:34:51 <jgarzik> usr/lib/x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
86 2014-02-27 05:34:52 <jgarzik> (.text+0x19): undefined reference to `dlopen'
87 2014-02-27 05:34:52 <jgarzik> (.text+0x2c): undefined reference to `dlsym'
88 2014-02-27 05:34:52 <jgarzik> (.text+0x37): undefined reference to `dlclose'
89 2014-02-27 05:34:52 <jgarzik> /usr/lib/x86_64-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
90 2014-02-27 05:35:21 <jgarzik> That's annoying. I cannot build bitcoind with -static, due to libcrypto. Everything else is happy, symbol-wise.
91 2014-02-27 05:35:36 <andytoshi> jgarzik: you can add -ldl to your LDFLAGS, i find i need to do that when compiling against my /usr/local ssl
92 2014-02-27 05:35:44 <andytoshi> oh, i see
93 2014-02-27 05:39:24 <jgarzik>
94 2014-02-27 05:39:24 <jgarzik> poe@boundary:~/repo/bitcoin/src$ ldd bitcoind
95 2014-02-27 05:39:24 <jgarzik> poe@boundary:~/repo/bitcoin/src$ ls -l bitcoind
96 2014-02-27 05:39:24 <jgarzik> -rwxr-xr-x 1 poe poe 6507576 Feb 27 05:39 bitcoind
97 2014-02-27 05:39:47 <jgarzik> after a bit of manual fiddling
98 2014-02-27 06:46:34 <wumpus> another way is to build openssl without dl support (that's what we do in gitian)
99 2014-02-27 07:27:08 <shaileshg> Hi, i m running bitcoind client using command line option -datadir=/data
100 2014-02-27 07:27:13 <shaileshg> $ bitcoind -datadir=/data/
101 2014-02-27 07:27:26 <shaileshg> however, it is giving me following error:
102 2014-02-27 07:27:31 <shaileshg> bitcoin in AppInit()
103 2014-02-27 07:27:31 <shaileshg> EXCEPTION: N5boost12interprocess22interprocess_exceptionE
104 2014-02-27 07:27:31 <shaileshg> No such file or directory
105 2014-02-27 07:27:36 <shaileshg> any idea why?
106 2014-02-27 07:28:14 <shaileshg> oh wait.. it might be coz of libprotobuf-dev
107 2014-02-27 07:28:16 <shaileshg> let me try
108 2014-02-27 07:45:39 <wumpus> what version of bitcoind?
109 2014-02-27 07:45:57 <wumpus> we haven't used boost::interprocess for ages
110 2014-02-27 07:47:25 <michagogo> cloud|inb43.24
111 2014-02-27 07:58:20 <shaileshg> wumpus: 80600
112 2014-02-27 08:02:07 <michagogo> cloud|shaileshg: where from?
113 2014-02-27 08:02:21 <michagogo> cloud|Release binaries, ppa, self built?
114 2014-02-27 08:02:27 <shaileshg> ppa
115 2014-02-27 08:02:56 <shaileshg> michagogo|cloud: still not solved
116 2014-02-27 08:03:25 <michagogo> cloud|shaileshg: protobuf probably has nothing to do with it
117 2014-02-27 08:03:42 <michagogo> cloud|0.8.6 doesn't use protobuf, that's in master for the payment protocol
118 2014-02-27 08:03:43 <shaileshg> michagogo|cloud: hmm. does bdb has to do anything with it?
119 2014-02-27 08:04:01 <michagogo> cloud|shaileshg: idk
120 2014-02-27 08:05:20 <wumpus> 0.8.6 certainly doesn't use boost interprocess
121 2014-02-27 08:05:48 <wumpus> do you maybe have some conflicting old version around?
122 2014-02-27 08:06:11 <shaileshg> wumpus: i don't think so.. can i confirm it anyhow.. m on ubuntu
123 2014-02-27 08:06:27 <wumpus> bitcoind -help ?
124 2014-02-27 08:06:48 <shaileshg> Bitcoin server starting..
125 2014-02-27 08:07:15 <wumpus> --help, sorry
126 2014-02-27 08:08:07 <wumpus> lol, -- as well as - is supported for all arguments except help
127 2014-02-27 08:08:21 <wumpus> I get it wrong every single time
128 2014-02-27 08:09:12 <shaileshg> wumpus: no conflicting version around..
129 2014-02-27 08:09:30 <shaileshg> Also, $ bitcoind -datadir=/data/ is the right way to tell path to data directory.. right?
130 2014-02-27 08:09:36 <wumpus> find / -name bitcoind ...
131 2014-02-27 08:09:42 <shaileshg> i have .conf file in .bitcoin/bitcoin.conf
132 2014-02-27 08:09:57 <wumpus> yes that is the right way to tell the data directory
133 2014-02-27 08:10:19 <wumpus> it won't use the conf file in ~/.bitcoin if you specify another data directory
134 2014-02-27 08:10:26 <wumpus> but the conf file in that directory
135 2014-02-27 08:10:54 <shaileshg> wumpus: oh
136 2014-02-27 08:11:15 <wumpus> you can, though, use -conf to specify using another configuration file
137 2014-02-27 08:11:22 <shaileshg> so .bitcoin/ would not be used at all? kinda useless then
138 2014-02-27 08:11:34 <wumpus> that's the point of -datadir
139 2014-02-27 08:11:36 <shaileshg> output of find / ...
140 2014-02-27 08:11:53 <shaileshg> etc/bash_completion.d/bitcoind
141 2014-02-27 08:11:53 <shaileshg> usr/bin/bitcoind
142 2014-02-27 08:11:53 <shaileshg> usr/share/doc/bitcoind
143 2014-02-27 08:11:53 <shaileshg> usr/share/lintian/overrides/bitcoind
144 2014-02-27 08:12:14 <wumpus> heh.
145 2014-02-27 08:12:32 <shaileshg> ?
146 2014-02-27 08:13:11 <shaileshg> looks like there is no other version around..
147 2014-02-27 08:13:13 <wumpus> no, it's funny that those distribution packages create links everwhere, but looks ok
148 2014-02-27 08:13:32 <shaileshg> heh..
149 2014-02-27 08:13:53 <wumpus> I really, really don't understand why you would get a boost interprocess error
150 2014-02-27 08:14:11 <shaileshg> or could try going with making from source
151 2014-02-27 08:14:23 <wumpus> oh. we use it for the file_lock on the data directory
152 2014-02-27 08:14:36 <wumpus> shaileshg: not necessary
153 2014-02-27 08:14:56 <shaileshg> wumpus: there was a issues raised here https://github.com/bitcoin/bitcoin/issues/3487
154 2014-02-27 08:15:53 <wumpus> are you pointing the datadir somewhere that doesn't exist or is not accessible?
155 2014-02-27 08:17:52 <shaileshg> i attached an ebs volume on aws.. mounted it to /data and pointing datadir to /data
156 2014-02-27 08:18:04 <shaileshg> haven't created any folder in datadir
157 2014-02-27 08:18:35 <wumpus> that's ok, you don't need to create a folder in your datadir
158 2014-02-27 08:18:50 <shaileshg> can go to /data location.. so i don't think its not accessible..
159 2014-02-27 08:19:12 <wumpus> so my hypothesis is: boost_interprocess cannot create a datadir lock file on your fancy file system
160 2014-02-27 08:19:26 <shaileshg> file system: ext4
161 2014-02-27 08:20:01 <wumpus> right...
162 2014-02-27 08:20:08 <wumpus> you can create files in that directory?
163 2014-02-27 08:21:13 <wumpus> I don't how the boost::interprocess::lock works internally, my guess it that it just creates a file and uses flock() on it
164 2014-02-27 08:21:45 <shaileshg> oh god.. can't create file / directory on that
165 2014-02-27 08:21:50 <shaileshg> need to fix it first
166 2014-02-27 08:22:16 <shaileshg> permission denied.. let me fix it and report then
167 2014-02-27 08:22:18 <shaileshg> :)
168 2014-02-27 08:26:05 <michagogo> cloud|shaileshg: *jamie hyneman voice* Well THERE'S your problem!
169 2014-02-27 08:26:41 <shaileshg> wumpus: yeah. That was the issue.
170 2014-02-27 08:26:47 <shaileshg> michagogo|cloud: :)
171 2014-02-27 08:27:28 <shaileshg> srsly.. didn't occurred to me to check permission to the newly mounted disk
172 2014-02-27 08:31:06 <olalonde> gmaxwell: do you think it would be interesting to include a timestamp in the leaf nodes?
173 2014-02-27 08:31:18 <shaileshg> wumpus: now i m running bitcoind with -datadir=/data, but querying for getblockcount etc is throwing me error saying it can't find bitcoin.conf file in ~/.bitcoin path..
174 2014-02-27 08:31:30 <olalonde> gmaxwell: that way the user could verify when is balance was read from the database
175 2014-02-27 08:31:34 <shaileshg> error: You must set rpcpassword=<password> in the configuration file:
176 2014-02-27 08:31:34 <shaileshg> /home/ubuntu/.bitcoin/bitcoin.conf
177 2014-02-27 08:31:40 <wumpus> you also need to specify the -datadir when you send commands
178 2014-02-27 08:31:52 <wumpus> otherwise it doesn't know what instance of bitcoind you want to send commands to
179 2014-02-27 08:32:18 <shaileshg> hmm..
180 2014-02-27 08:33:01 <wumpus> (or as said, you can use -conf to use an alternative configuration file that is not in your datadir)
181 2014-02-27 08:37:18 <shaileshg> wumpus: right
182 2014-02-27 08:37:26 <shaileshg> hmm
183 2014-02-27 10:24:03 <dexX7_> from the script wiki entry: "Due to a bug, one extra unused value is removed from the stack." for OP_CHECKMULTISIG.. is this the reason why a multisig input scriptsig looks like: 00 + push 71-73 byte + signature? and 00 is used as workaround for this "bug"?
184 2014-02-27 10:27:20 <TD> yeah
185 2014-02-27 10:28:14 <dexX7_> ah nice, thanks
186 2014-02-27 11:41:55 <anton000> hey guys... have a little question in scriptpubkey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
187 2014-02-27 11:43:05 <anton000> y is pubkeyhash = ripemd160(sha256(pub key)) ?
188 2014-02-27 11:46:52 <embicoin> is the custom -walletpath commit integrated on the newest master client?
189 2014-02-27 11:51:26 <wumpus> embicoin: no, there is no walletpath commit
190 2014-02-27 11:51:43 <wumpus> there is a -wallet=... argument but you can use it only to specify wallets inside the datadir
191 2014-02-27 11:52:21 <embicoin> wumpus: ok, thanks, just saw what old-c-programmer did hehe
192 2014-02-27 12:02:35 <wumpus> walletpath would be possible, but was not yet implemented, there are some practical issues, most people would like to wait with that until BerkeleyDB is no longer used
193 2014-02-27 12:06:44 <embicoin> wumpus: I agree with tat
194 2014-02-27 12:25:54 <uiop> ACTION performs his recurring endorsement of sqlite
195 2014-02-27 12:28:24 <embicoin> Maybe I am wrong but I find that nosql would fit better for the client needs...
196 2014-02-27 12:30:09 <embicoin> the problem now is that wallet.dat is strongly tied with old bdb versions ...
197 2014-02-27 12:30:21 <sipa> bdb is nosql-avant-la-lettre
198 2014-02-27 12:30:38 <sipa> it's just a key-value store
199 2014-02-27 12:32:46 <Apocalyptic> avant la lettre ?
200 2014-02-27 12:33:21 <sipa> "before that term existed"
201 2014-02-27 12:33:57 <Apocalyptic> oh I see
202 2014-02-27 12:34:11 <embicoin> wow then you mean that I am completely wrong? :P
203 2014-02-27 12:35:05 <sipa> no, i fully agree that nosql is the better choice here, but that has nothing to do with bdb or not (where i also fully agree that having a database layer that has poor compatibility features is a bad choice)
204 2014-02-27 12:36:09 <sipa> embicoin: we've been wanting to replace bdb for the wallet with a custom simple append-only key-value format
205 2014-02-27 12:36:27 <embicoin> ok thanks :D I just started with the insides of the client so I am very noob :P
206 2014-02-27 12:39:48 <embicoin> Another naive thought Is that satoshi liked those deps cos they were familiar to him, but he was not analysing the optimal needs at all, obviously he also couldn't measure the current size of project
207 2014-02-27 12:40:37 <wumpus> uiop: sqlite would have been better then berkelydb (at least it can be embedded easily), but we don't need a fully fangled database for the wallet at all
208 2014-02-27 12:42:33 <embicoin> well, I suppose we are still on early development stage so big improvements are coming I guess :P
209 2014-02-27 12:43:02 <sipa> embicoin: yeah, pretty sure satoshi just used what he knew
210 2014-02-27 12:43:04 <CodeShark> how far along is BIP0032 integration with Bitcoin-Qt?
211 2014-02-27 12:43:19 <sipa> i have a branch with most of it done
212 2014-02-27 12:43:25 <CodeShark> and is the plan to scrap the current random key generation scheme altogether?
213 2014-02-27 12:43:40 <sipa> certainly off by default
214 2014-02-27 12:43:58 <CodeShark> are there any plans for making use of the hierarchical features?
215 2014-02-27 12:44:20 <sipa> change addresses and public addresses separately, yes
216 2014-02-27 12:44:30 <sipa> separate accounts, maybe later
217 2014-02-27 12:45:02 <sipa> the accounts will be more for "i need a specific chain for specific use X"
218 2014-02-27 12:45:09 <sipa> recurring payments or something
219 2014-02-27 12:45:14 <sipa> or to put on a webserver
220 2014-02-27 12:45:27 <CodeShark> right
221 2014-02-27 12:45:35 <sipa> not really for sub-wallets
222 2014-02-27 12:45:46 <sipa> (which should just be separate wallets)
223 2014-02-27 12:46:27 <CodeShark> separate wallets could still be stored in a single file
224 2014-02-27 12:46:33 <CodeShark> and loaded all concurrently
225 2014-02-27 12:46:36 <sipa> true
226 2014-02-27 12:47:21 <CodeShark> I'm working on improving usability for account management
227 2014-02-27 12:47:33 <CodeShark> that's actually probably my #1 project for the next week or two
228 2014-02-27 12:48:09 <Traubert> I'm trying to build the github master on debian wheezy with libboost1.49-dev installed, and am running into: checking for exit in -lboost_system... no; configure: error: Could not link against boost_system !
229 2014-02-27 12:48:48 <CodeShark> Traubert: first check whether libboost_system.a or libboost_system.so are on your system
230 2014-02-27 12:49:01 <CodeShark> second make sure they are in the libpath
231 2014-02-27 12:49:13 <sipa> the name may be different
232 2014-02-27 12:49:14 <CodeShark> third make sure they are the same version as the headers in your include path
233 2014-02-27 12:49:27 <sipa> config.log may have more information
234 2014-02-27 12:49:54 <Traubert> good point, looks like I don't have anything boost-related in /lib at all, just the headers
235 2014-02-27 12:50:19 <sipa> /lib is for system libraries
236 2014-02-27 12:50:22 <sipa> check /usr/lib
237 2014-02-27 12:50:30 <CodeShark> or /usr/local/lib
238 2014-02-27 12:50:30 <Traubert> I meant /usr/lib
239 2014-02-27 12:50:54 <Traubert> looks like the debian packaged for the actual libs are libboost-*
240 2014-02-27 12:50:57 <Traubert> *packages
241 2014-02-27 12:51:10 <Traubert> thanks
242 2014-02-27 12:51:14 <CodeShark> np :)
243 2014-02-27 12:53:10 <CodeShark> sipa: any plans for multisig stuff in Bitcoin-Qt?
244 2014-02-27 12:53:32 <sipa> CodeShark: that'd be mostly UI stuff
245 2014-02-27 12:53:41 <sipa> ACTION doesn't know anything about that
246 2014-02-27 12:54:08 <CodeShark> well, not necessarily - you could also have a headless API wallet
247 2014-02-27 12:54:36 <sipa> anyway, i haven't spent time on that, and don't plan to
248 2014-02-27 12:55:43 <CodeShark> one thing I haven't really looked into too much, which I really should, is using secure buffers for private keys
249 2014-02-27 12:56:44 <CodeShark> if you allocate an std::vector<unsigned char> and make sure to zero it before freeing it, will that guarantee that at least the memory location no longer contains any trace of the data?
250 2014-02-27 12:57:19 <CodeShark> I mean, I suppose the rte could move the buffer around or do disk swaps and such
251 2014-02-27 12:58:13 <CodeShark> and it's really entirely up to the OS whether or not disk swaps or other processes somehow get access to that data
252 2014-02-27 12:59:39 <CodeShark> so I guess the question is how paranoid should we be about this? and how much effort is it worth to try to secure the buffer?
253 2014-02-27 12:59:53 <CodeShark> of course, ideally I'd like all signing to take place on dedicated hardware
254 2014-02-27 13:01:22 <sipa> we use a custom allocator
255 2014-02-27 13:01:29 <sipa> to wipe memory after freeing
256 2014-02-27 13:01:45 <sipa> and in some cases, to lock the memory pages they are in
257 2014-02-27 13:02:16 <sipa> that's certainly not water tight though
258 2014-02-27 13:02:31 <CodeShark> right, I'm wondering how much effort this is really worth
259 2014-02-27 13:02:51 <CodeShark> if someone has sufficient access to your machine to be able to exploit these things, chances are they can attack far simpler targets
260 2014-02-27 13:03:45 <CodeShark> keystrokes, bash history, etc...
261 2014-02-27 13:03:53 <sipa> yeah
262 2014-02-27 13:04:22 <sipa> and the zeroing/locking only happens for real key material, not for data passed through the UI for example
263 2014-02-27 13:06:34 <CodeShark> at the very least it's probably a good idea to zero the buffer before freeing, I suppose
264 2014-02-27 13:07:46 <CodeShark> oh well, I'll take a look at the custom allocators in bitcoind
265 2014-02-27 13:08:59 <CodeShark> does OPENSSL_cleanse do anything beyond just zeroing the buffer?
266 2014-02-27 13:10:50 <CodeShark> oh, I suppose OPENSSL maintains its own heap pool
267 2014-02-27 13:15:09 <olalonde> gmaxwell: wrote a Chrome extension for verification
268 2014-02-27 13:15:33 <olalonde> gmaxwell: https://github.com/olalonde/blproof-extension
269 2014-02-27 13:15:50 <olalonde> gmaxwell: and working with a gambling site to implement the scheme
270 2014-02-27 13:42:22 <dexX7_> how long does it take until unconfirmed transactions vanish?
271 2014-02-27 13:46:03 <wallet42> dexX7_: they dont
272 2014-02-27 13:46:13 <Esya> Guys, got a bit of a nasty debian problem right now
273 2014-02-27 13:46:20 <Esya> It's a network configuration issue
274 2014-02-27 13:46:31 <Esya> I'm willing to give a 0.25btc bounty to anyone who has the solution
275 2014-02-27 13:46:36 <Esya> If anyone is interested let me know
276 2014-02-27 13:46:37 <wallet42> dexX7_: only possibility is that it becomes invalid, if another TX gets mined that spents an input from the old one
277 2014-02-27 13:46:48 <dexX7_> wallet42: ?? can't be. i'm specificly talking about transactions with not enough fee.
278 2014-02-27 13:47:34 <dexX7_> and i'm unable to spend the inputs otherwise. all such transactions are rejected, not only by my client, but also if issued via blockchain.info/eligius push tx
279 2014-02-27 13:47:34 <wallet42> dexX7_: not enough relay fee => it will not broadcast trough the network
280 2014-02-27 13:48:08 <dexX7_> the attached fee was 0.0000072 BTC
281 2014-02-27 13:48:23 <wallet42> you only can wait
282 2014-02-27 13:48:41 <dexX7_> how long?
283 2014-02-27 13:48:50 <dexX7_> you said "they vanish never"
284 2014-02-27 13:49:09 <wallet42> no but eventually the priority is high enough
285 2014-02-27 13:49:25 <wallet42> and it will be mined within the "free tier"
286 2014-02-27 13:50:20 <wallet42> you might increase the priority, if you control one output and send it to another address with a higher fee attached.
287 2014-02-27 13:50:32 <wallet42> but im not sure if that always works
288 2014-02-27 13:50:55 <dexX7_> as said, such try is rejected
289 2014-02-27 13:51:22 <wallet42> txid?
290 2014-02-27 13:52:09 <dexX7_> https://blockchain.info/tx/1bcfc1ce94211b4d2eb119a8f9faba77db94cbb9549eed235250d450a3e9fae8
291 2014-02-27 13:52:56 <wallet42> do you control any outputs?
292 2014-02-27 13:53:16 <dexX7_> this is the first one.. i have a long chain of transactions, all based on the others before. handcrafted and send via sendrawtransaction
293 2014-02-27 13:53:17 <dexX7_> yes
294 2014-02-27 13:53:49 <wallet42> use one output and some other coins to create a followup transaction
295 2014-02-27 13:54:25 <dexX7_> sec
296 2014-02-27 13:54:29 <wallet42> add enough fee to pay for all
297 2014-02-27 13:54:34 <wallet42> previous transactions
298 2014-02-27 13:54:52 <dexX7_> should i use the last tx in the chain or the first one which is unconfirmed?
299 2014-02-27 13:55:31 <wallet42> the last unconfirmed
300 2014-02-27 13:55:42 <wallet42> and add MORE fee to that
301 2014-02-27 13:55:48 <wallet42> so it compensates for both
302 2014-02-27 13:56:11 <wallet42> the miner can get the fee for that one only, if he also mines the other one obviously
303 2014-02-27 13:56:24 <dexX7_> sec, i'll try that
304 2014-02-27 13:56:52 <wallet42> the miner will be happy if all txes get into one block, and he gets 0.1 millibit per 1000 bytes per transaction
305 2014-02-27 13:59:02 <andytoshi> wallet42: have you heard of this working? i thought miners were not so clever
306 2014-02-27 13:59:23 <wallet42> i'm not sure but its worth a try ;)
307 2014-02-27 13:59:36 <andytoshi> :P ok, it'd be wonderful if it does work
308 2014-02-27 13:59:48 <wallet42> yeah me too :P
309 2014-02-27 14:01:01 <wallet42> i think the follow up tx will have a high priority, so the miner will try to mine it, but he cant if he doesnt mine both
310 2014-02-27 14:01:22 <dexX7_> hmmm
311 2014-02-27 14:01:41 <dexX7_> unable to sign. and getrawtransaction txid returns: No information available about transaction (code -5)
312 2014-02-27 14:01:50 <dexX7_> it's still shown in the "transactions" tab though
313 2014-02-27 14:02:14 <NieSpieBoKopie> Hello fellas. I've got these errors while compiling linux wallet. Any ideas how to fix it?
314 2014-02-27 14:02:14 <NieSpieBoKopie> http://pastebin.com/wSGHga9L
315 2014-02-27 14:02:38 <wallet42> has the hash changed?
316 2014-02-27 14:03:17 <sipa> dexX7_: do you have -txindex enabled?
317 2014-02-27 14:03:36 <dexX7_> yes, i have
318 2014-02-27 14:04:12 <sipa> that must mean the transaction conflicts with the chain
319 2014-02-27 14:04:32 <wallet42> well i can to getrawtx on that one
320 2014-02-27 14:04:36 <wallet42> on my bitcoind
321 2014-02-27 14:05:06 <sipa> getrawtransaction queries the mempool and the blockchain
322 2014-02-27 14:05:11 <sipa> gettransaction queries the wallet
323 2014-02-27 14:05:49 <wallet42> "1bcfc1ce94211b4d2eb119a8f9faba77db94cbb9549eed235250d450a3e9fae8",
324 2014-02-27 14:05:49 <wallet42> bitcoind getrawmempool | grep 1bcfc1ce94211b4d2eb119a8f9faba77db94cbb9549eed235250d450a3e9fae8
325 2014-02-27 14:06:08 <dexX7_> the first unconfirmed tx was still "available". i used this one as input and it was sent
326 2014-02-27 14:06:37 <sipa> in 0.9, gettransaction will also report the raw transaction in hex
327 2014-02-27 14:06:40 <dexX7_> yea, 1bc is the first one
328 2014-02-27 14:07:13 <dexX7_> 761bdab1a451d645bf445043f1638abb164856bf05a2a9d658ce2582955161c2 was the last in chain
329 2014-02-27 14:07:28 <olalonde> does signmessage reveal the public key?
330 2014-02-27 14:08:46 <dexX7_> message + signature does
331 2014-02-27 14:10:29 <NieSpieBoKopie> Hello. Any ideas to fix these json errors? http://pastebin.com/JGjzXpux I can give some btc for helper.
332 2014-02-27 14:13:56 <olalonde> is there an online utility to do signmessages?
333 2014-02-27 14:14:37 <dexX7_> www.brainwallet.org
334 2014-02-27 14:14:51 <olalonde> dexX7_: thanks
335 2014-02-27 14:15:48 <olalonde> dexX7_: there's no "bitcoin-qt" signature type.. .any reason why? isnt that stuff standardized?
336 2014-02-27 14:17:16 <dexX7_> bitcoin-qt displayes and uses simply the signature. that's the line below the one with the address and on top of "-----END BITCOIN SIGNED MESSAGE-----"
337 2014-02-27 14:17:17 <olalonde> dexX7_: does sign message leak the public key?
338 2014-02-27 14:17:27 <olalonde> ok
339 2014-02-27 14:17:54 <dexX7_> if someone has the message and signature, then yes
340 2014-02-27 14:18:11 <olalonde> ok
341 2014-02-27 14:21:28 <dexX7_> well hm. i pushed the tx earlier locally and with blockchain.info. it's not found by bitcoind on another machine. not via gettransaction nor getrawmempool. https://blockchain.info/tx/1eccfa81f73ef06d3336f078bd31ac03198e928f6add1a07a08e0b344d599615
342 2014-02-27 14:39:40 <NieSpieBoKopie> I OFFER BTC BOUNTY FOR FIX THIS ERROR: http://pastebin.com/wSGHga9L
343 2014-02-27 14:50:08 <dexX7_> looks like it worked (7926bb2ba3dffa14586bc8c9cfc88432025c32e8e61a1c4eb34eed3286c7e631). one machine still returns a result for a tx that now should be invalid at the same time it also shows this one, but i guess as long as the tx is confirmed, all related low fee tx should be definitely invalid now. thanks wallet42
344 2014-02-27 14:50:47 <Joric> NieSpieBoKopie, call BasicValue( uint64_t value );
345 2014-02-27 14:56:14 <andytoshi> in fairness, the message+signature only gives you the public key if the signature is valid
346 2014-02-27 14:56:34 <andytoshi> otherwise it will give you a different public key, if everything else is well-formed you cannot make the distinction
347 2014-02-27 15:51:53 <OperatorSyn> Anyone here?
348 2014-02-27 15:52:00 <OperatorSyn> was BitcoinTalk ever called BitcoinForums
349 2014-02-27 15:55:50 <jgarzik> InsiderJoe, yes and no. bitcointalk.org was originally forum.bitcoin.org, and continues to be informally known as "the bitcoin forums"
350 2014-02-27 15:56:09 <jgarzik> InsiderJoe, anyway, that is a better question for #bitcoin
351 2014-02-27 16:06:13 <michagogo> cloud|Esya: What's the problem?
352 2014-02-27 16:06:36 <Esya> Hey michagogo|cloud !
353 2014-02-27 16:06:40 <Esya> It's been solved
354 2014-02-27 16:06:46 <Esya> Sorry :\
355 2014-02-27 16:06:57 <michagogo> cloud|Great
356 2014-02-27 16:31:29 <NieSpieBoKopie> Hello. Anyone? http://pastebin.com/wSGHga9L
357 2014-02-27 16:40:42 <wumpus> NieSpieBoKopie: maybe cast the value to (boost::uint64_t) before passing it to Value
358 2014-02-27 16:41:50 <wumpus> seems the definition of uint64_t and boost::uint64_t don't match exactly (one is long long unsigned the other just long unsigned), in which case C++ doesn't know what constructor variant to pick
359 2014-02-27 16:46:50 <sipa> wumpus: so why isn't this a problem in master for us?
360 2014-02-27 16:47:51 <wumpus> sipa: no clue!
361 2014-02-27 16:50:24 <wumpus> sipa: actually, we seem to be casting them to (boost::uint64_t)
362 2014-02-27 16:50:51 <wumpus> for example see GetNetworkHashPS in rpcmining.cpp
363 2014-02-27 17:26:38 <tlrobinson_> is this an accurate statement? In theory, given enough time (*very* long time), someone able to maintain 50.0000001% of hashing power could eventually rewrite the *entire* blockchain after the genesis block
364 2014-02-27 17:28:29 <helo> sure
365 2014-02-27 17:28:51 <helo> with emphasis on "in theory"
366 2014-02-27 17:29:37 <tlrobinson_> helo: yes of course :)
367 2014-02-27 17:56:47 <ionstorm> hearing some rumors from an associate i know in washington that Karpeles may be extradited to the US for prosecution, unsure any details unfortunately
368 2014-02-27 17:57:54 <tommygunner> will he an hero himself with his sword
369 2014-02-27 17:58:22 <dhill> also heard a rumor that Karpeles is Satoshi
370 2014-02-27 18:00:36 <ionstorm> satoshi? lol thats quite far fetched, Karpeles will pay for his crimes and missmanagement, and I highly doubt the bitcoin community will stand up for him
371 2014-02-27 18:00:46 <jgarzik> dhill, It's totally true. The first version of bitcoin was written in PHP.
372 2014-02-27 18:00:55 <dhill> in 3 days i heard
373 2014-02-27 18:01:09 <dhill> :P