1 2014-04-25 00:02:18 <modyn> how long time should it take for make bitcoind on linux debian 7?
2 2014-04-25 00:10:43 <sipa> modyn: depends a lot on number of cpu cores (and hiw many you use), and how much ram you have
3 2014-04-25 00:10:48 <sipa> the os hardly matterd
4 2014-04-25 01:54:53 <Cray-on-> Join us at #bitember and suggest charities you'd like to see us donate to in next weeks donation frenzy
5 2014-04-25 01:56:00 <Cray-on-> We will donate all donations AND fees from our pools for 48 hours starting saturday next week! So come one in to #bitember
6 2014-04-25 02:05:18 <modyn> bitcoind getblockcount
7 2014-04-25 02:05:18 <modyn> error: server returned HTTP error 403
8 2014-04-25 02:05:21 <modyn> how do i fix this?
9 2014-04-25 06:46:30 <maaku> Cray-on-: donations to charities is nice but off-topic
10 2014-04-25 06:50:42 <mappum> does Bitcoin Core RPC start throttling after making lots of requests to it really fast? it seems to keep breaking after a while
11 2014-04-25 06:53:54 <sipa> no, but there could be problems resulting from opening and closing the many tcp connections for that
12 2014-04-25 06:54:12 <sipa> after how many requests are we talking?
13 2014-04-25 07:00:32 <mappum> a few thousand. but each one is multiple batched RPC calls
14 2014-04-25 07:01:05 <mappum> then after a while, a request will get a ECONNREFUSED
15 2014-04-25 07:05:54 <[Mr`X]> hello to all
16 2014-04-25 07:07:26 <wumpus> mappum: well there is a maximum number of incoming connections, or is each request waiting for the previous one to finish?
17 2014-04-25 07:07:57 <mappum> they are each waiting
18 2014-04-25 07:08:21 <wumpus> do the requests fail somehow? anything in debug.log?
19 2014-04-25 07:08:24 <[Mr`X]> i need some information there is somebody can help me please?
20 2014-04-25 07:08:46 <wumpus> [Mr`X]: don't ask to ask, just ask
21 2014-04-25 07:09:38 <wumpus> seems that this is a known issue : https://github.com/bitcoin/bitcoin/issues/2889
22 2014-04-25 07:10:09 <wumpus> or this: https://github.com/bitcoin/bitcoin/issues/3968
23 2014-04-25 07:10:48 <[Mr`X]> i mining from my laptop core i5 with windows with minerd
24 2014-04-25 07:10:50 <wumpus> but the latter happens 'if RPC requests get interrupted'
25 2014-04-25 07:11:10 <mappum> mine is the first one then
26 2014-04-25 07:11:22 <mappum> that issue was closed though
27 2014-04-25 07:11:26 <[Mr`X]> but after more time 3.40 khash/s accepted: 0/2207 (0.00%), 9.33 khash/s (booooo)
28 2014-04-25 07:11:34 <mappum> oh, on dogecoin
29 2014-04-25 07:11:42 <wumpus> no, it wasn't closed
30 2014-04-25 07:12:30 <[Mr`X]> what i wrong?
31 2014-04-25 07:16:43 <mappum> cool, looks like a small wait between requests fixes it
32 2014-04-25 08:40:23 <warren> sirk390: http://wtogami.blogspot.com/2013/05/openssl-with-ecdsa-for-fedora-18.html
33 2014-04-25 08:42:53 <Cocodude> Has anyone ever had an issue where bitcoind forgets to add a txn fee even though paytxfee here is set to 0.0001?
34 2014-04-25 09:19:06 <grau_> szia. meg semmi uj. dolgozom/
35 2014-04-25 10:57:27 <darsie> hey
36 2014-04-25 10:58:44 <darsie> How do I use bitcoin 0.9.1 with debian stable (7.4 "wheezy")?
37 2014-04-25 10:59:13 <darsie> bitcoin-qt: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by bitcoin-qt)
38 2014-04-25 11:02:12 <darsie> I have libc6-i686:i386 2.13-38+deb7u1
39 2014-04-25 11:03:06 <darsie> Am I meant to compile it?
40 2014-04-25 11:05:31 <SomeoneWeird> eugh, glibc
41 2014-04-25 11:05:32 <SomeoneWeird> ACTION sighs
42 2014-04-25 11:05:38 <darsie> Or install a newer glibc?
43 2014-04-25 11:06:24 <SomeoneWeird> you can't, really
44 2014-04-25 11:06:37 <darsie> can't install a newer glibc?
45 2014-04-25 11:06:39 <SomeoneWeird> i think unstable still has an outdate version
46 2014-04-25 11:06:52 <SomeoneWeird> https://bitcointalk.org/index.php?topic=522639.0
47 2014-04-25 11:07:15 <SomeoneWeird> oh, looks like unstable has the required (still old :p) version
48 2014-04-25 11:07:40 <SomeoneWeird> i'd be wary about doing that though, if glibc breaks... everything breaks
49 2014-04-25 11:08:12 <darsie> If I can compile it, could you do that, too, with the debian stable glibc and put that in your package?
50 2014-04-25 11:08:43 <darsie> Or do you require features of the new glibc?
51 2014-04-25 11:09:04 <SomeoneWeird> i'm not sure, i'm not a btc dev
52 2014-04-25 11:11:34 <darsie> the thread suggests installing packages from sid. I've done this kind of thing before and it broke my debian :(.
53 2014-04-25 11:12:13 <darsie> I'll try to compile, but IIRC that failed with 0.9.
54 2014-04-25 11:13:12 <sipa> darsie: compile it yourself, for now
55 2014-04-25 11:13:34 <sipa> 0.9.1 has static binaries for bitcoind, but for -qt that's not possible
56 2014-04-25 11:15:17 <darsie> build-unix.md says ./autogen.sh, but there is no ./autogen.sh.
57 2014-04-25 11:15:28 <sipa> yes there is...
58 2014-04-25 11:15:57 <darsie> must be hidden.
59 2014-04-25 11:15:57 <sipa> https://github.com/bitcoin/bitcoin/blob/master/autogen.sh
60 2014-04-25 11:16:24 <sipa> no
61 2014-04-25 11:16:32 <sipa> where are you looking?
62 2014-04-25 11:16:39 <darsie> Can't see it in here: https://bitcoin.org/bin/0.9.1/bitcoin-0.9.1-linux.tar.gz
63 2014-04-25 11:16:54 <sipa> that's the binary package
64 2014-04-25 11:16:58 <sipa> fetch the source from git
65 2014-04-25 11:17:01 <darsie> It has source, too.
66 2014-04-25 11:17:08 <darsie> ok
67 2014-04-25 11:17:33 <sipa> git clone github.com/bitcoin/bitcoin/git; git checkout v0.9.1
68 2014-04-25 11:17:41 <sipa> .git, not /git
69 2014-04-25 11:20:09 <darsie> there it is :)
70 2014-04-25 11:20:09 <darsie> thx
71 2014-04-25 11:20:42 <darsie> you also forgot http://
72 2014-04-25 11:21:21 <sipa> ok :)
73 2014-04-25 11:21:33 <darsie> Hmm, should I use https, so noone can tamper during download? :)
74 2014-04-25 11:22:28 <sipa> if you verify the git commit id you're safe
75 2014-04-25 11:23:05 <darsie> I did https
76 2014-04-25 11:24:33 <darsie> there we are again ... configure: error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore)
77 2014-04-25 11:24:45 <darsie> ahh, the switch ...
78 2014-04-25 11:25:03 <darsie> --with-incompatible-bdb
79 2014-04-25 11:25:11 <sipa> it's perfectly fine to use --with-incompatible-bdb, it just means you won't be able to use your wallet.dat file with release binaries
80 2014-04-25 11:25:46 <darsie> remember that ... configure: error: Could not link against boost_chrono-mt !
81 2014-04-25 11:32:48 <darsie> fixed: aptitude install libboost1.49-all-dev
82 2014-04-25 11:35:08 <darsie> Hmm, will I be able to use my old wallet?
83 2014-04-25 11:35:23 <sipa> yes
84 2014-04-25 11:35:43 <darsie> k
85 2014-04-25 11:35:44 <sipa> you just won't be able to use your wallet.dat file with release binaries anymore (which use bdb 4.8)
86 2014-04-25 11:36:00 <sipa> but you can manually downconvert them if that would be necessary
87 2014-04-25 11:36:08 <sipa> using db4.8_load
88 2014-04-25 11:36:32 <darsie> Or send my btc to the new clients wallet?
89 2014-04-25 11:36:49 <sipa> the client doesn't have a wallet
90 2014-04-25 11:36:54 <sipa> there's just a wallet.dat file which is yours
91 2014-04-25 11:37:05 <sipa> sure, you can create a new wallet, but there's no need for that
92 2014-04-25 11:37:44 <btcuser> Excuse me, how does the bitcoin-qt calculate the txfee in a transaction?
93 2014-04-25 11:37:44 <darsie> Yes. I mean, when I install a new client, it'll create a new wallet and then I can send my btc from the old client to the new wallet.
94 2014-04-25 11:38:54 <darsie> Read the source, Luke ;).
95 2014-04-25 11:39:22 <kaptah> I'm pretty sure Luke does read the source ;)
96 2014-04-25 11:40:27 <btcuser> who is Luke?
97 2014-04-25 11:40:43 <darsie> It's a pun on "Use the force, Luke." :)
98 2014-04-25 11:41:10 <darsie> But Luke-Jr is a major bitcoin dev, IMHO.
99 2014-04-25 11:43:13 <btcuser> a developer?
100 2014-04-25 11:43:18 <darsie> yes
101 2014-04-25 11:43:36 <darsie> Luke is Luke Skywalker from Star Wars.
102 2014-04-25 11:43:51 <btcuser> where is Luke?
103 2014-04-25 11:49:06 <btcuser> Is there a simple way to calculate the txfee through a programming language, such as php?
104 2014-04-25 11:50:04 <sipa> btcuser: if you construct the transaction yourself, sure; it's size_in_kilobyte * fee_per_kilobyte
105 2014-04-25 11:50:19 <sipa> the problem is that if you let bitcoind do it, you don't know the size in kilobyte in advance
106 2014-04-25 11:52:45 <btcuser> If I use bitcoin RPC "sendtoaddress" or "sendfrom", will the bitcoind calculate the txfee automatically?
107 2014-04-25 11:53:27 <darsie> Hmm ... didn't seem to build bitcoin-qt. "This will build bitcoin-qt as well if the dependencies are met." Does that mean I lack some qt stuff?
108 2014-04-25 11:54:43 <btcuser> No bitcoin-qt
109 2014-04-25 11:56:32 <btcuser> I hope to do a transaction platform. When a user make a sending request, it will call the sendtoaddress api auto.
110 2014-04-25 11:57:48 <darsie> I have libqt4-dev installed. What am I missing?
111 2014-04-25 11:58:10 <sipa> darsie: did it detect it?
112 2014-04-25 11:59:24 <wumpus> darsie: doc/build-unix.md should mention exactly which deps you need to install
113 2014-04-25 11:59:45 <btcuser> sipa, what does the size include ?
114 2014-04-25 11:59:45 <darsie> ahh ... configure: WARNING: libprotobuf not found; bitcoin-qt frontend will not be built
115 2014-04-25 11:59:59 <sipa> btcuser: the whole transaction
116 2014-04-25 12:00:29 <sipa> (sorry, i know that's a useless answer, but i can't explain the whole protocol here)
117 2014-04-25 12:00:51 <btcuser> darsie, you should install protobuf-2.3.0
118 2014-04-25 12:01:01 <btcuser> the version is 2.3
119 2014-04-25 12:01:19 <darsie> k
120 2014-04-25 12:02:00 <darsie> wumpus: The dependencies listed, are they the -qt dependencies, or also for bitcoind?
121 2014-04-25 12:03:09 <btcuser> sipa, how do I get the hole transaction data before I send bitcoins?
122 2014-04-25 12:03:39 <darsie> btcuser: aptitude install libprotobuf-dev installed libprotobuf-dev i386 2.4.1-3
123 2014-04-25 12:04:33 <sipa> btcuser: if you build the transaction yourself, you have the transaction before you send it
124 2014-04-25 12:04:45 <darsie> should I run autogen.sh after installing libprotobuf? make clean?
125 2014-04-25 12:04:54 <darsie> or just ./configure?
126 2014-04-25 12:04:54 <sipa> darsie: just configure again
127 2014-04-25 12:04:56 <darsie> k
128 2014-04-25 12:05:00 <sipa> btcuser: if you use any integrated wallet, it will do all at once, making it impossible to know in advance
129 2014-04-25 12:05:19 <runeks> sending funds to an OP_RETURN output would destroy said funds, right?
130 2014-04-25 12:05:26 <sipa> yes
131 2014-04-25 12:05:43 <wumpus> darsie: it lists them separately AFAIK
132 2014-04-25 12:05:47 <runeks> sipa: Is this a good way of doing proof-of-burn, without bloating the UTXO set?
133 2014-04-25 12:10:17 <btcuser> Does the parameter "amount" in "sendtoaddress" including txfee ?
134 2014-04-25 12:10:30 <sipa> no
135 2014-04-25 12:11:40 <btcuser> Is there any sending bitcoin's api including txfee?
136 2014-04-25 12:12:07 <sipa> createrawtransaction allows you to construct the entire transaction as you want
137 2014-04-25 12:12:39 <darsie> 'checking for PROTOBUF... yes' 'checking for protoc... no' 'configure: WARNING: PROTOC not found; bitcoin-qt frontend will not be built'
138 2014-04-25 12:13:08 <darsie> install libprotoc-dev?
139 2014-04-25 12:14:44 <darsie> nope, that didn't fix it.
140 2014-04-25 12:15:20 <btcuser> If you have install the libprotoc, I think the version is not reach the target.
141 2014-04-25 12:15:23 <sipa> from https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md:
142 2014-04-25 12:15:30 <sipa> To build with Qt 4 you need the following:
143 2014-04-25 12:15:31 <sipa> sudo apt-get install libqt4-dev libprotobuf-dev protobuf-compiler
144 2014-04-25 12:16:12 <wumpus> darsie: why don't you just follow the steps in the build-unixmd
145 2014-04-25 12:16:48 <wumpus> is it really necessary that we quote you from it?
146 2014-04-25 12:16:59 <darsie> sorry, reading it now more completely.
147 2014-04-25 12:18:04 <darsie> I suggest you supply a debian stable compatible binary ;).
148 2014-04-25 12:18:31 <wumpus> the nightly builds are debian stable compatible now, and the 0.9.1 came with .static executables that also work on debian stable
149 2014-04-25 12:18:38 <wumpus> so I'm not sure what more you're suggesting
150 2014-04-25 12:19:14 <darsie> one that doesn't say: bitcoin-qt: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by bitcoin-qt)
151 2014-04-25 12:20:04 <wumpus> and if this encourages people to try to build it themselves it's actually great
152 2014-04-25 12:20:08 <runeks> sipa: No comment on whether sending funds to an OP_RETURN output is preferable to sending them to an unredeemable hash160?
153 2014-04-25 12:20:39 <wumpus> runeks: sending to OP_RETURN is better, those can be pruned in the utxo set
154 2014-04-25 12:21:02 <runeks> wumpus: Cool! That's what I though. Thanks.
155 2014-04-25 12:23:10 <darsie> wumpus: Making everything yourself is kinda great, but most people have other priorities ...
156 2014-04-25 12:23:41 <wumpus> darsie: good for them, but for the project it's better if people build themselves, it encourages development
157 2014-04-25 12:25:52 <wumpus> darsie: I'm not saying that pre-build executables are bad, as I already said above the nightly builds work on debian stable (7.x), also bitcoin-qt
158 2014-04-25 12:28:11 <darsie> wumpus: Is it risky to use them? I mean, more than the releases?
159 2014-04-25 12:28:24 <sipa> yes
160 2014-04-25 12:28:30 <sipa> they are way less tested
161 2014-04-25 12:28:32 <wumpus> darsie: yes
162 2014-04-25 12:28:35 <darsie> k
163 2014-04-25 12:28:43 <wumpus> darsie: but if you're building master already, it's exactly the same
164 2014-04-25 12:29:03 <wumpus> darsie: if you're actually building a release tag from git, it's not
165 2014-04-25 12:29:36 <darsie> Hmm, I did git checkout v0.9.1
166 2014-04-25 12:30:01 <wumpus> just continue with that, then
167 2014-04-25 12:58:35 <btcuser> Can anyone tell me is there any solution to set the txfee through sending bitcoins in RPC?
168 2014-04-25 12:59:25 <btcuser> In command line I use sendtoaddress, it tell me that "This transaction requires a transaction fee of at least 0.0001 because of its amount".
169 2014-04-25 13:00:07 <sipa> you can set the txfee to what you like, but not below what your own bitcoind would drop because of DoS rules
170 2014-04-25 13:01:49 <darsie> Yay, bitcoin-qt 0.9.1-beta is running :)
171 2014-04-25 13:01:50 <darsie> thx
172 2014-04-25 13:03:09 <btcuser> when I use "settxfee 0.0001", and then "sendtoaddress xxx 0.001", it return that "Insufficient funds".
173 2014-04-25 13:03:33 <btcuser> But my wallet have enough bitcoins.
174 2014-04-25 13:04:29 <sipa> how much does it have?
175 2014-04-25 13:05:12 <sipa> the value passed to settxfee is per kilobyte
176 2014-04-25 13:05:25 <btcuser> I have 0.0998 in total
177 2014-04-25 13:05:45 <michagogo> cloud|Is it in many very tiny outputs, by any chance?
178 2014-04-25 13:05:48 <modyn> sipa: what should i set settxfee to? if i want to use 0.0001 fee for my transaction?
179 2014-04-25 13:06:06 <modyn> transactions
180 2014-04-25 13:06:10 <sipa> modyn: that depends on the size of the transaction
181 2014-04-25 13:06:19 <sipa> the fee per transaction is not relevant to the network
182 2014-04-25 13:06:23 <sipa> it's the fee per kilobyte
183 2014-04-25 13:06:40 <modyn> lol
184 2014-04-25 13:06:48 <modyn> i want 0.0001 no matter what :)
185 2014-04-25 13:06:50 <modyn> like always
186 2014-04-25 13:06:56 <modyn> simple transaction
187 2014-04-25 13:06:58 <sipa> that's not possible, and doesn't make sense
188 2014-04-25 13:07:12 <modyn> no it doesnt to me who wanna pay easy
189 2014-04-25 13:07:20 <modyn> so please tell me what to put in there
190 2014-04-25 13:07:35 <sipa> you can't; the setting is per kilobyte, as that is what matters
191 2014-04-25 13:07:48 <sipa> unless you contruct the transaction manually
192 2014-04-25 13:08:06 <modyn> ok so.. if i put settxfee 0.0001
193 2014-04-25 13:08:17 <modyn> and then send a normal transaction at 257 byte
194 2014-04-25 13:08:25 <modyn> how much fee it gonna take from me?
195 2014-04-25 13:08:26 <sipa> then it will use 0.0001 fee
196 2014-04-25 13:08:30 <modyn> oki
197 2014-04-25 13:08:39 <modyn> under 1 000 byte right?
198 2014-04-25 13:08:48 <darsie> bitcoin-qt just seriously hogs my computer :/.
199 2014-04-25 13:08:50 <modyn> it gonna use 0.0001
200 2014-04-25 13:08:52 <btcuser> how to calculate the transaction size?
201 2014-04-25 13:08:59 <sipa> btcuser: you can't
202 2014-04-25 13:09:11 <sipa> btcuser: it depends on the size of the coins in your wallet
203 2014-04-25 13:09:30 <modyn> :)
204 2014-04-25 13:09:30 <modyn> lol my bitcoins are 200 mb
205 2014-04-25 13:09:34 <sipa> so unless you build the transaction yourself, you can't know the size in advance
206 2014-04-25 13:09:37 <modyn> 0.1 bitcoins are 200 mb
207 2014-04-25 13:09:39 <modyn> imagine ?
208 2014-04-25 13:09:40 <modyn> :)
209 2014-04-25 13:09:44 <sipa> ?
210 2014-04-25 13:09:59 <modyn> is there any bitcoins that are 1 mb?
211 2014-04-25 13:10:07 <modyn> for 1 tranaction? sipa
212 2014-04-25 13:10:08 <modyn> ?
213 2014-04-25 13:10:09 <sipa> you mean transactions?
214 2014-04-25 13:10:14 <btcuser> how to build the transanction myself?
215 2014-04-25 13:10:15 <modyn> no 1 transaction
216 2014-04-25 13:10:36 <sipa> bin theory, transactions can be up to 999919 bytes
217 2014-04-25 13:10:56 <sipa> but i don't think anyone will relay above 50 or 100 kb or so
218 2014-04-25 13:11:35 <sipa> btcuser: using the raw transaction api, for example
219 2014-04-25 13:12:01 <darsie> bitcoin-qt 0.9.1-beta seems to be stuck processing block 269781
220 2014-04-25 13:12:09 <sipa> btcuser: that's not intended for end users; you'll need to learn the protocol details and experiment with it if you don't want to shoot yourself in the foot
221 2014-04-25 13:12:48 <sipa> darsie: just wait, it will normally recover when a new block is announced
222 2014-04-25 13:12:58 <darsie> ok
223 2014-04-25 13:15:30 <btcuser> Is it impossible to set suitable txfee through bitcoin RPC?
224 2014-04-25 13:15:42 <sipa> define suitable
225 2014-04-25 13:16:09 <sipa> there is a settxfee command, which sets the transaction fee per kilobyte for created transactions
226 2014-04-25 13:16:55 <btcuser> How do I know whether the txfee is suitable?
227 2014-04-25 13:17:05 <darsie> suitable: get the tx into the next (few) block(s) with high probability.
228 2014-04-25 13:18:40 <btcuser> I don't understand~
229 2014-04-25 13:18:45 <sipa> well what do you want to accomplish?
230 2014-04-25 13:19:55 <btcuser> I hope to call "sendtoaddress" in my program, how to set a suitable txfee ?
231 2014-04-25 13:20:09 <sipa> you haven't answered my question
232 2014-04-25 13:20:33 <btcuser> what do I want to accomplish?
233 2014-04-25 13:20:43 <sipa> yes?
234 2014-04-25 13:20:52 <sipa> you use the word 'suitable' but you don't say for what
235 2014-04-25 13:21:15 <btcuser> for sending bitcoins
236 2014-04-25 13:21:53 <sipa> bitcoind will generally not create transactions that have a too low fee to be accepted by the network, though the default may cause them to take a while before being picked up by miners
237 2014-04-25 13:22:06 <sipa> even if you set the fee to 0
238 2014-04-25 13:24:13 <btcuser> I do not set the fee to 0, but 0.0001
239 2014-04-25 13:25:17 <sipa> ok
240 2014-04-25 13:26:39 <btcuser> look at this http://pastebin.ca/2703169
241 2014-04-25 13:27:03 <btcuser> a part of program I wrote.
242 2014-04-25 13:27:21 <sipa> ok
243 2014-04-25 13:28:10 <btcuser> it return this: Insufficient funds
244 2014-04-25 13:28:42 <sipa> do you have unconfirmed incoming transactions?
245 2014-04-25 13:29:17 <btcuser> no
246 2014-04-25 13:29:32 <btcuser> all transaction has confirmed.
247 2014-04-25 13:29:52 <btcuser> and my wallet has 0.0988btc
248 2014-04-25 13:30:26 <sipa> what does: getbalance '*' 1
249 2014-04-25 13:30:28 <sipa> return?
250 2014-04-25 13:30:59 <btcuser> 0.09880000
251 2014-04-25 13:31:15 <sipa> how large are your inputs?
252 2014-04-25 13:31:40 <btcuser> where to see inputs?
253 2014-04-25 13:31:52 <sipa> how large are the typical amounts you received?
254 2014-04-25 13:31:58 <sipa> in listtransactions
255 2014-04-25 13:32:28 <btcuser> 0.09990000
256 2014-04-25 13:33:38 <btcuser> ...
257 2014-04-25 13:35:44 <btcuser> sipa?
258 2014-04-25 13:37:36 <darsie> blockchain.info shows 2 new block, and my bitcoin-qt 0.9.1 is still on block 269781.
259 2014-04-25 13:37:48 <darsie> resync?
260 2014-04-25 13:37:54 <darsie> for 3 days?
261 2014-04-25 13:39:38 <btcuser> my block is 297633
262 2014-04-25 13:40:36 <btcuser> darsie, do you know something about txfee?
263 2014-04-25 13:42:39 <darsie> a little
264 2014-04-25 13:43:34 <btcuser> do you know how to calculate the txfee?
265 2014-04-25 13:45:41 <btcuser> darsie, look at this:http://pastebin.ca/2703181
266 2014-04-25 13:46:04 <darsie> I don't.
267 2014-04-25 13:48:13 <michagogo> cloud|btcuser: what does getbalance retur?n
268 2014-04-25 13:49:02 <btcuser> your bitcoins amount.
269 2014-04-25 13:52:27 <Luke-Jr> btcuser: not possible, and off-topic here
270 2014-04-25 13:53:39 <btcuser> ok, sorry.
271 2014-04-25 13:55:06 <darsie> My freshly compiled bitcoin-qt 0.9.1 is stuck syncing at block 296781.
272 2014-04-25 13:56:16 <Luke-Jr> darsie: pastebin debug.log
273 2014-04-25 13:56:41 <darsie> ok. I'm restarting it currently.
274 2014-04-25 14:01:15 <darsie> Luke-Jr: http://paste.debian.net/95676/
275 2014-04-25 14:01:51 <michagogo> cloud|;;blocks
276 2014-04-25 14:01:52 <gribble> 297636
277 2014-04-25 14:02:02 <michagogo> cloud|darsie: you're synced
278 2014-04-25 14:02:22 <michagogo> cloud|Oh, wait a sec
279 2014-04-25 14:02:23 <Luke-Jr> darsie: truncated log is useless ; plus what michagogo|cloud said
280 2014-04-25 14:02:48 <michagogo> cloud|What's 2014-04-25 13:57:19 nBestHeight = 296781?
281 2014-04-25 14:02:58 <darsie> ok, I'll paste the complete file ...
282 2014-04-25 14:04:01 <Luke-Jr> darsie: the important part is the moment it received block 296782
283 2014-04-25 14:04:03 <darsie> Length of code is not allowed to exceed 150kB
284 2014-04-25 14:04:11 <Luke-Jr> darsie: use dropbox or osmething
285 2014-04-25 14:06:50 <michagogo> cloud|or use tail
286 2014-04-25 14:07:33 <michagogo> cloud|tail -c150000 debug.log | pastebinit
287 2014-04-25 14:07:53 <darsie> michagogo|cloud: darsie: truncated log is useless
288 2014-04-25 14:08:07 <darsie> Hope this works: https://www.dropbox.com/s/kkc82is2nc95wrz/debug.log
289 2014-04-25 14:08:09 <michagogo> cloud|darsie: not completely useless
290 2014-04-25 14:08:30 <darsie> Haven't used dropbox before.
291 2014-04-25 14:08:54 <michagogo> cloud|Hm, that doesn't allow in-browser viewing, only downloading :-/
292 2014-04-25 14:10:48 <michagogo> cloud|um
293 2014-04-25 14:10:50 <michagogo> cloud|2014-04-25 14:04:47 CheckForkWarningConditions: Warning: Large valid fork found
294 2014-04-25 14:10:51 <michagogo> cloud|Chain state database corruption likely
295 2014-04-25 14:10:51 <michagogo> cloud| forking the chain at height 296781 (0000000000000000652daf97ebe7a7880293e20e949dd972be3af1eac6238240)
296 2014-04-25 14:10:51 <michagogo> cloud| lasting to height 297637 (00000000000000002e6b49719cabf431f9c5abe93bcb61631942ce3b32b18ab0).
297 2014-04-25 14:11:02 <michagogo> cloud|;;blocks
298 2014-04-25 14:11:03 <gribble> 297637
299 2014-04-25 14:11:22 <michagogo> cloud|That line seems like it might have something to do with it
300 2014-04-25 14:12:10 <darsie> Here you can view it in browser: http://www.bksys.at/bernhard/temp/debug.log.txt
301 2014-04-25 14:12:25 <darsie> so, I do bitcoin-qt -rescan?
302 2014-04-25 14:12:39 <michagogo> cloud|-reindex, I think
303 2014-04-25 14:12:54 <darsie> another 3 days syncing ...
304 2014-04-25 14:13:46 <darsie> Guess I should have stopped it before I shutdown my computer yesterday.
305 2014-04-25 14:13:53 <michagogo> cloud|2014-04-22 00:39:33 InvalidChainFound: invalid block=00000000000000008527e0a80533ae25decbf7c132c166fb8db71856a39e719e height=297067 log2_work=78.136412 date=2014-04-22 00:39:22
306 2014-04-25 14:13:53 <michagogo> cloud|2014-04-22 00:39:33 received block 00000000000000008527e0a80533ae25decbf7c132c166fb8db71856a39e719e
307 2014-04-25 14:15:09 <michagogo> cloud|2014-04-22 00:47:47 InvalidChainFound: invalid block=000000000000000061fdc9bc6d861daa0f6713b269a7094f7bab8eee65c2a5b4 height=297068 log2_work=78.136542 date=2014-04-22 00:49:36
308 2014-04-25 14:15:09 <michagogo> cloud|2014-04-22 00:47:47 received block 000000000000000061fdc9bc6d861daa0f6713b269a70
309 2014-04-25 14:15:09 <michagogo> cloud|94f7bab8eee65c2a5b4
310 2014-04-25 14:15:14 <michagogo> cloud|etc
311 2014-04-25 14:15:23 <michagogo> cloud|And I just checked, those are the valid blocks at those heights
312 2014-04-25 14:15:41 <michagogo> cloud|darsie: Ah, yep, unclean shutdowns can cause database corruption
313 2014-04-25 14:16:08 <michagogo> cloud|(I managed to view it with $ curl 'https://dl.dropboxusercontent.com/s/kkc82is2nc95wrz/debug.log?dl=1&token_hash=AAFVLLsazMngL7xeXtOxXjUXihcMJs30t3pXioJbCaMgjg' | less )
314 2014-04-25 14:16:15 <darsie> Please make unclean shutdowns more stable.
315 2014-04-25 14:16:46 <michagogo> cloud|darsie: I don't actually know if this is the case, but you may need to take that up with the leveldb devs
316 2014-04-25 14:17:10 <darsie> ic
317 2014-04-25 17:33:26 <danneu> when connected to a pool over stratum and it sends "set_difficulty: 2", isn't worker difficulty then = 0x00000000ffff0000000000000000000000000000000000000000000000000000 / 2 ?
318 2014-04-25 17:33:36 <danneu> er, worker target*
319 2014-04-25 17:34:31 <Luke-Jr> danneu: yes
320 2014-04-25 17:34:42 <Luke-Jr> maybe not exactly
321 2014-04-25 17:35:14 <Luke-Jr> yeah, should be exact actually
322 2014-04-25 17:35:42 <Luke-Jr> otoh, there are many non-conformance pools with this
323 2014-04-25 17:35:50 <Luke-Jr> BTCGuild uses a non-truncated pdiff 1
324 2014-04-25 17:36:14 <Luke-Jr> so it's really 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
325 2014-04-25 17:36:34 <Luke-Jr> and various pools use Ldiff instead
326 2014-04-25 17:36:40 <danneu> Luke-Jr: Ah, I'm actually connecting to BTCGuild as I'm testing my [toy, for-fun] miner. That was my next question -- I gotcha
327 2014-04-25 17:37:49 <Luke-Jr> I'm tempted to make BFGMiner use pdiff as well, just to cover the least-common-denominator..
328 2014-04-25 17:37:51 <danneu> Also, this is probably dumb, but is the `set_difficulty` value in stratum in decimal or hex?
329 2014-04-25 17:38:01 <Luke-Jr> stratum is JSON, so decimal..
330 2014-04-25 17:38:10 <Luke-Jr> and not necessarily an integer
331 2014-04-25 17:38:43 <danneu> why does the use of json preclude a hex string?
332 2014-04-25 17:39:05 <Luke-Jr> it doesn't preclude strings at all, but Numbers are always decimal
333 2014-04-25 17:39:30 <danneu> oh, it's a number over the wire. i didn't even notice. thanks
334 2014-04-25 17:39:43 <Luke-Jr> lol
335 2014-04-25 17:45:24 <danneu> Luke-Jr: how can the worker-target calculation vary between pools using the stratum protocol?
336 2014-04-25 17:45:38 <Luke-Jr> danneu: ?
337 2014-04-25 17:46:11 <danneu> how would miners swap out stratum endpoints to different pools without knowing whether they need to {pdiff,bdiff,ldiff}/<set_difficulty>?
338 2014-04-25 17:46:22 <Luke-Jr> danneu: guesswork
339 2014-04-25 17:46:29 <danneu> wow, no shit
340 2014-04-25 18:00:26 <danneu> stratum's "spec" page explains that target is calculated against bdiff (0x00000000ffff00000...). why would a pool not comply?
341 2014-04-25 18:06:35 <Luke-Jr> danneu: in BTCGuild's case, because it's easier to check against pdiff (not sure why they set_difficulty integer though)
342 2014-04-25 18:06:59 <Luke-Jr> danneu: in scamcoin pools' case, because the people designing it are not thinking straight
343 2014-04-25 18:07:45 <Luke-Jr> danneu: also, BTCGuild had their "stratum" implementation *before* stratum was published, and only adjusted it slightly to use stratum's protocol instead of their own
344 2014-04-25 18:08:10 <Luke-Jr> really, mining protocols *should* just stick to a target
345 2014-04-25 18:09:33 <danneu> seems simpler had it been {set_target: <hex string>} instead
346 2014-04-25 18:10:25 <gmaxwell> What fun would it be if there weren't protocols that required floating point in their normative behavior?
347 2014-04-25 18:11:56 <Luke-Jr> danneu: exactly. that's why I used suggest_target instead of suggest_diff
348 2014-04-25 19:03:24 <mpescador> hello everybody, i've got a question about coinbase transactions
349 2014-04-25 19:05:45 <mpescador> does it always have to be the first input of the first transaction in a block, or can it be any input with a previous output hash of 0 (as long as there's only 1 of them)?
350 2014-04-25 19:06:03 <hearn> it has to be the first
351 2014-04-25 19:06:04 <danneu> first
352 2014-04-25 19:07:03 <mpescador> then does the previous output hash of the first input always need to be 0 or is that just a convention?
353 2014-04-25 19:08:18 <danneu> afaik it's arbitrary like its ntime
354 2014-04-25 19:09:28 <mpescador> ok thanks a lot
355 2014-04-25 19:13:29 <sipa> mpescador: the first transaction of a block must have exactly one txin, and ot must be 000...000:ffff
356 2014-04-25 19:14:52 <mpescador> and if it's not 000...000:ffff? will the block be rejected?
357 2014-04-25 19:15:07 <sipa> yes
358 2014-04-25 19:15:12 <mpescador> ok thanks
359 2014-04-25 20:06:36 <tyrick> I can't find my bootstrap.dat file in ./bitcoin
360 2014-04-25 20:06:54 <tyrick> Isn't it generated the first time you load the program?
361 2014-04-25 20:07:52 <sipa> no
362 2014-04-25 20:07:59 <sipa> you download it if you want to use it
363 2014-04-25 20:47:40 <olalonde> tyrick: you can generate a bootstrap.dat like this: cat *.blk > bootstrap.dat in the blocks directory
364 2014-04-25 20:51:18 <gmaxwell> olalonde: that will end up with orphans in it, so not quite the same.
365 2014-04-25 20:51:36 <gmaxwell> there is a script in contrib that extracts an orphanless bootstrap.
366 2014-04-25 20:51:55 <wumpus> also it may end up with the block files in the wrong order
367 2014-04-25 20:52:22 <olalonde> ok
368 2014-04-25 20:52:43 <wumpus> but yes the basic idea is just to concatenate them
369 2014-04-25 20:52:44 <olalonde> tyrick: what they said
370 2014-04-25 20:53:04 <olalonde> best way to get an answer in this chan is to say something wrong :)
371 2014-04-25 20:53:46 <sipa> wumpus: the order should be right
372 2014-04-25 20:54:07 <olalonde> all I know is that it worked for me last time I tried
373 2014-04-25 20:54:12 <gmaxwell> (we don't save orphans on disk)
374 2014-04-25 20:54:26 <gmaxwell> olalonde: it does work but it won't agree with one someone else made, and it won't be as small as it could be)
375 2014-04-25 20:54:32 <wumpus> sipa: how's that? shell globs don't guarantee any specific order AFAIK
376 2014-04-25 20:54:51 <gmaxwell> oh. :)
377 2014-04-25 20:57:46 <wumpus> hm, seemingly bash does sort alphabetically, that's strange, I've seen problems with gitian and filesystems that have different orderings
378 2014-04-25 21:01:28 <gmaxwell> Soâ apparently someone is TCP hijacking multiple of the largest Bitcoin pools in order to divert their hashpower for the attacker's profit. I'd warned some pools about this a few months ago after some ISP industry friends contacted me to ask about some address space hijacking they'd seen of an altcoin pool (they were wondering why someone would be motivated to hijack its address space).
379 2014-04-25 21:02:00 <gmaxwell> At the moment it appears that the attacker is just doing it for the coins income and isn't attempting to reorg the chain. (the work they're issuing agrees with my current best block)
380 2014-04-25 21:04:15 <gmaxwell> I note that P2Pool continues to be structurally immune to this attack (at least while motivated by stealing rewards or reorging the chain).
381 2014-04-25 21:05:03 <wumpus> interesting
382 2014-04-25 21:05:54 <gmaxwell> Prior attacks were based on address space hijacking, actual modality is unknown in this instance, may be compromised routers at a datacenter where multiple pool frontends are.
383 2014-04-25 21:05:55 <wumpus> what does TCP hijacking do?
384 2014-04-25 21:06:15 <wumpus> ah, they have to exploit routers
385 2014-04-25 21:06:19 <gmaxwell> wumpus: what they're doing here is intercepting the connections (somehow) and inserting a stratum redirect to a new address.
386 2014-04-25 21:06:37 <gmaxwell> so the miners then move over to mine at the new address.
387 2014-04-25 21:07:52 <wumpus> not having the miner side authenticate themselves is sort-of asking for this
388 2014-04-25 21:09:32 <helo> would anything bad happen if most pool miners just switched to p2pool?
389 2014-04-25 21:10:01 <belcher> miners would have to make an effort
390 2014-04-25 21:11:00 <wumpus> this attack was hypothesized a long time ago, but I suppose it wasn't done before (that we know of) because it's hard to execute
391 2014-04-25 21:11:03 <helo> there were some scalability concerns with p2pool at some point, not sure if they were addressed
392 2014-04-25 21:12:36 <wumpus> it's interesting how unlikely attacks suddenly become feasible if there's this much profit to be gained
393 2014-04-25 21:18:52 <gmaxwell> helo: I'm not aware of any scalability concerns that aren't just fud. it's all adaptiveâ it just ups the difficulty if there are more users, so the share rate stays constant.
394 2014-04-25 21:19:31 <gmaxwell> helo: if all the network used it the variance would be pretty high, but still actually lower than it is now (because now the variance is domainated by blockfinding)
395 2014-04-25 21:20:08 <danneu> does stratum really mix endianness in its messages?
396 2014-04-25 22:08:29 <petertodd> wumpus: unfortunately I'm not surprised to hear that no-one is using even SSL for this :(
397 2014-04-25 22:11:01 <petertodd> helo: keep in mind that at worst you don't have to have everyone mining on the same p2pool sharechain - you can always split it up into multiple p2pools
398 2014-04-25 22:11:58 <gmaxwell> petertodd: they have problems keeping their service online due to DOS attacks without a nice TLS target wrapping the protocol.
399 2014-04-25 22:12:39 <petertodd> helo: that said, p2pool miners earn less than well-run large pools, which is an unfortunate and inherent part of how bitcoin works. not that much less right now, we're talking a % or two at most, but larger blocksizes and merge-mining make that problem worse
400 2014-04-25 22:13:03 <petertodd> gmaxwell: surely cloudflare could fix that...
401 2014-04-25 22:14:25 <gmaxwell> cloudflare doesn't work right for non-browser clients, they do things like JS POW. (I suppose you can turn this off...) and yea, thats exactly what the ecosystem security needs, cloudflare controlling all the hashpower. :P
402 2014-04-25 22:14:39 <petertodd> heh, I knew you'd just love that suggestion
403 2014-04-25 22:17:32 <sipa> these mining pools just need scalable enterprise solutions
404 2014-04-25 22:17:52 <sipa> running on virtualized clusters... webscale!
405 2014-04-25 22:18:16 <sipa> is web 2.0 still a buzzword these days?
406 2014-04-25 22:18:51 <petertodd> sipa: only among the proletariat
407 2014-04-25 22:22:09 <gmaxwell> petertodd: reality isn't really much better, many of them are hosted on AWS already.
408 2014-04-25 22:22:49 <gmaxwell> (you it's a little less obvious as to where they're hosted because they use sacrificail frontends and redirect traffic to avoid some of the DOS attacks)
409 2014-04-25 22:25:21 <petertodd> interesting: SatoshiBONES doublespends itself: https://blockchain.info/tx/1830b54982a49850e59e1bcf6356e77faa40c1db315b76969189203b2314be2a https://blockchain.info/tx/c20e1849115b07736ed530762a958c828f2d70d3d847070627533adea66467cd
410 2014-04-25 22:25:27 <petertodd> must be a bug?
411 2014-04-25 22:26:53 <sipa> i have learnt to ignore sites with satoshi in their name
412 2014-04-25 22:27:33 <rodrigo31> Hey!
413 2014-04-25 22:27:56 <petertodd> sipa: heh, well there is something to be said there... does look like they're vulnerable to zeroconf tx replacement
414 2014-04-25 22:28:14 <rodrigo31> After 10 day here i will finaly quit my IRC client! ;)
415 2014-04-25 22:28:15 <petertodd> sipa: and, I mean the really trivial type enabled by differences in fee rules
416 2014-04-25 22:45:27 <midnightmagic> I had high hopes for the satoshi archive thingy but.. so much for that.
417 2014-04-25 23:03:12 <petertodd> satoshi archive?
418 2014-04-25 23:15:13 <jaekwon> is there some estimate on the total number of full nodes on the network?
419 2014-04-25 23:21:57 <gmaxwell> jaekwon: there isn't really any way to measure it, you can measure the reachable ones though and you get a number around 8000.
420 2014-04-25 23:23:08 <gmaxwell> so greater than that but almost certantly less than 100k. (if there were much more than 100k the 8000 reachable nodes would be constantly full and people would have problem getting connections).
421 2014-04-25 23:24:08 <jaekwon> thank you. i suppose there are more miners than that though, simply mining via pools, not connected as a node.
422 2014-04-25 23:25:14 <sipa> their number is irrelevant to the network
423 2014-04-25 23:39:40 <jaekwon> sipa: yes.
424 2014-04-25 23:40:42 <jaekwon> i'm just measuring the number of people who go through the trouble of setting up a miner at all.
425 2014-04-25 23:42:59 <maaku> sipa gmaxwell: ah, I remember why I thought it more elegant to leave coinbase outputs out of the utxo tree - that way you don't need to remember the coinbase flag
426 2014-04-25 23:43:26 <sipa> maaku: alternative: don't store the coinbase flag or the height, but only the height at which the output becomes spendable
427 2014-04-25 23:43:57 <maaku> sipa: i like that...
428 2014-04-25 23:44:05 <sipa> (which does screw up confirmation counts for coinbases...)
429 2014-04-25 23:47:04 <gmaxwell> they're kind of inaccurate now though.
430 2014-04-25 23:49:31 <maaku> well maturity vs confirmations are different things
431 2014-04-25 23:50:20 <maaku> also, storing height+maturity might be semantically confusing when other types of immaturity are added, e.g. quieting periods
432 2014-04-25 23:50:51 <maaku> modifying the utxo to account for that would be a hard-fork, assuming utxo tree commitment validation rules are added first
433 2014-04-25 23:50:55 <gmaxwell> but all the network cares about is when its valid.
434 2014-04-25 23:51:28 <gmaxwell> though I always assumed any quieting would be done via script and not by a txo property.
435 2014-04-25 23:51:52 <gmaxwell> esp since quieting without another spend pathways is, I think, mostly pointless.
436 2014-04-25 23:52:53 <maaku> gmaxwell: yes I'm favoring that approach, but I know BlueMatt for example preferred a transaction-template approach which i think means quieting wouldn't be done in script
437 2014-04-25 23:53:33 <gmaxwell> it could still be done in script and yet be a template approach.
438 2014-04-25 23:53:37 <maaku> well i guess it just depends on how you look at it, the information would be there so long as the peg is confined to a single output
439 2014-04-25 23:55:18 <maaku> for now, which do you think is cleaner, nMaturityHeight or nHeight + fCoinbase?
440 2014-04-25 23:56:45 <gmaxwell> maturity is cleaner but I think you need to do the latter if it's ever to support things like scripts reading the height off.
441 2014-04-25 23:57:04 <gmaxwell> unless you think those things could sanely tolerate it being 100 greater for coinbases.
442 2014-04-25 23:58:01 <maaku> very good point
443 2014-04-25 23:58:16 <maaku> also it could much with hardfork serialization changes (which are sensitive to nVersion+nHeight)
444 2014-04-25 23:58:20 <maaku> *muck