1 2014-11-23 00:44:55 <trommy> evning all
2 2014-11-23 01:11:02 <ahmed_> is there any node.js devs here for hire? (only a few lines of code i need doing most likely) bitcoin related.
3 2014-11-23 01:12:06 <sipa> not here, please
4 2014-11-23 01:12:21 <ahmed_> no worries is there another chan i can ask?
5 2014-11-23 01:24:12 <tommygunner> -otc
6 2014-11-23 02:25:59 <Haitoman> Trying to understand BC blocks. When a valid hash is found and the block is submitted to the network, do all miners dump the block they are working on?
7 2014-11-23 02:33:26 <Luke-Jr> Haitoman: yep
8 2014-11-23 02:34:32 <Luke-Jr> Haitoman: keep in mind they "start over" trillions of times every second
9 2014-11-23 02:44:29 <Haitoman> Luke-Jr: Thanks...yes..I get that but does that mean a transaction can appear in several blocks over the space of 30mins?
10 2014-11-23 02:44:44 <Luke-Jr> Haitoman: only one of them
11 2014-11-23 02:45:52 <phantomcircuit> Haitoman, have you read the white paper?
12 2014-11-23 02:46:08 <phantomcircuit> also https://bitcoin.org/en/developer-guide
13 2014-11-23 03:08:53 <Haitoman> phantomcircuit: I think I have read everything. Just a few gaps in my understanding. Like is the block header's timestamp updated before each hash attempt? And if a miner accepts a txn into their block do they dump that block when another miner is successful?
14 2014-11-23 03:09:42 <phantomcircuit> Haitoman, when you say dump you mean discard, correct?
15 2014-11-23 03:10:55 <Luke-Jr> Haitoman: those are just implementation details, up to each person running a node
16 2014-11-23 03:11:05 <Luke-Jr> Haitoman: generally the timestamp is only updated once a second though
17 2014-11-23 03:14:48 <Luke-Jr> (my apologies if these things seem obvious - but I feel like they need to be explicit because they're not always assumed in practice)
18 2014-11-23 03:22:06 <Haitoman> phantomcircuit: Okay I'm intrigued when you say 'discard'. I'm struggling with how a transaction can only ever exist in one block if a node has the choice of 'discarding' their block.
19 2014-11-23 03:24:19 <phantomcircuit> Haitoman, everybody is free to do whatever they want; BUT you're only using bitcoin if you follow the same consensus rules as everybody else
20 2014-11-23 03:28:14 <jaromil> Haitoman: maybe you like reading http://people.xiph.org/~greg/decentralized-time.txt
21 2014-11-23 03:30:49 <gmaxwell> sipa: wrt 5316 what would you warn for? "using this may screw up your node" ? well perhaps we should hide the option in the rpc help.
22 2014-11-23 03:32:20 <gmaxwell> Haitoman: "dump the block they are working on" sounds like you may be suffering from a misunderstanding related to progress. There is no cumulative "work" in mining, billions of times a second you attempt a solution, every attempt is completely independant and unrelated to the others. If there is a new block on the network, you simply make your next attempt be an attempt at the block after that one.
23 2014-11-23 03:33:30 <phantomcircuit> yeah that
24 2014-11-23 03:33:36 <gmaxwell> Haitoman: a single blockchain can only have a transaction in it once, by the validity rules of the system enforced by every participant... but since there is no such thing as synchronicity in a distributed network, it's quite possible for the chain to have competing tips, though eventually only one will survive and be part of the eventual longest chain.
25 2014-11-23 03:34:09 <Luke-Jr> ACTION said that already :P
26 2014-11-23 03:34:44 <gmaxwell> (also, please take the bitcoin basics questions to #bitcoin)
27 2014-11-23 03:50:05 <Haitoman> Luke-Jr: phantomcircuit: I appreciate the explanation. I get all this. It is just the 'how' a node does not include the same transaction in another block that I am struggling with. Does a node explicitly check the previous block(s) when it accepts a txn for the block it is working on to ensure that it hasn't already been included in the blockchain. Where is this check done?
28 2014-11-23 03:50:43 <Luke-Jr> Haitoman: the node has a database of valid-and-existing UTXOs; if a transaction tries to spend UTXOs that don't exist, it is rejected
29 2014-11-23 03:50:57 <Luke-Jr> Haitoman: when the node processes a block that has a transaction spending a UTXO, it is deleted from the database
30 2014-11-23 03:51:06 <Luke-Jr> thus it wouldn't exist for future blocks/transactions to use
31 2014-11-23 03:52:10 <phantomcircuit> Haitoman, #bitcoin for future discussion
32 2014-11-23 04:00:03 <Haitoman> Luke-Jr: Ahhh..I see. So when a block is found and broadcast to the network each node updates its UTXO database. Thanks. Next question coming soon :)
33 2014-11-23 04:00:20 <Luke-Jr> Haitoman: in #bitcoin I hope
34 2014-11-23 04:03:48 <Haitoman> Luke-Jr: I tried but I got a 'by invitation only' response
35 2014-11-23 04:04:03 <Luke-Jr> Haitoman: sounds like a bug in your IRC client..
36 2014-11-23 04:04:12 <Luke-Jr> oh, maybe you need to register with NickServ
37 2014-11-23 04:08:00 <gmaxwell> wrt
38 2014-11-23 04:08:02 <gmaxwell> er wtf
39 2014-11-23 04:12:05 <Luke-Jr> yeah, dunno, +r seems to be nickserv-required, but it isn't set on #bitcoin
40 2014-11-23 04:12:21 <Luke-Jr> "join throttling" (+j) is - maybe related
41 2014-11-23 07:10:45 <gmaxwell> coryfields: something is wrong with the dependencies in master. ... upgraded a host from master a few weeks ago after a make clean, then ./autogen.sh ; ./configure ; and make is failing with No rule to make target `libsecp256k1.la'. Stop.
42 2014-11-23 07:11:43 <gmaxwell> oh foof. nevermind, false alarm. forgot this host had to be built with disable wallet, the configure was failing.
43 2014-11-23 08:27:37 <btcdrak> gmaxwell I had that error but it was because of a new dependency lib-gmp was missing
44 2014-11-23 08:28:15 <gmaxwell> It was just that I hadn't actually run configure... just because I needed a --disable-wallet on that host.
45 2014-11-23 08:29:04 <btcdrak> hehe :)
46 2014-11-23 08:51:10 <null> when trying to find the strongest chain, can i just sum(~targets) of each chain, or is it more complicated than that?
47 2014-11-23 08:54:20 <gmaxwell> assuming ~ is a reciprocal, thats all there is to it.
48 2014-11-23 08:54:49 <null> i was thinking of ~ as inverting, but reciprocal is fine, too
49 2014-11-23 08:54:51 <null> gmaxwell: thanks
50 2014-11-23 09:01:33 <null> bitwise inverting, that is; otherwise my sentence doesn't make a whole lot of sense :)
51 2014-11-23 09:27:46 <null> hum... can i just treat the compat target as a float? i can just find some articles on stackexchange on how to convert between the formats
52 2014-11-23 09:28:27 <sipa> 'compat' ?
53 2014-11-23 09:28:40 <Luke-Jr> null: it is a float.. of custom format. I'm not sure what you're asking.
54 2014-11-23 09:29:04 <sipa> to find the strongest chain you must compute sum(2^256/target(x) for every x in chain)
55 2014-11-23 09:29:19 <sipa> it's not bitwise inverting
56 2014-11-23 09:53:09 <null> sipa: i meant compact. i just read about how to convert between target and target in compact format. to me, the conversion is not intuitive, at least not without thinking about it :)
57 2014-11-23 09:54:03 <null> padding with zero seems okay, it's just padding the mantissa. but the prepending of eight zero bits if the first byte in base-256 is >0x7f confuses me
58 2014-11-23 09:54:34 <sipa> it's because the exponent is in powers of 256
59 2014-11-23 09:54:36 <sipa> not powers of 2
60 2014-11-23 09:54:50 <sipa> ah
61 2014-11-23 09:55:00 <sipa> no, that's because the highest bit of the mantissa is the sign bit
62 2014-11-23 09:55:31 <sipa> so you don't want the sign bit set, so you have to shift further
63 2014-11-23 09:55:53 <null> actually i think it might have something to do with the base being limited to [-126;127]
64 2014-11-23 09:56:08 <sipa> no, i just explained you
65 2014-11-23 09:56:13 <null> okay
66 2014-11-23 09:56:23 <sipa> 0xFFFFFF as mantissa is a negative number
67 2014-11-23 09:56:34 <sipa> so you have to use 0xFFFF and shift further
68 2014-11-23 09:56:57 <null> right! thanks
69 2014-11-23 09:57:40 <null> mh, actually the first bit is the sign bit, followed by the exponent and only then the mantissa
70 2014-11-23 09:57:54 <null> but it still makes sense
71 2014-11-23 09:58:23 <sipa> there's 8 bits of exponent, 1 bit of sign, 23 bits of mantissa
72 2014-11-23 09:59:47 <null> well, damn you wikipedia! :)
73 2014-11-23 10:14:48 <sipa> what does wikipedia have to do with it?
74 2014-11-23 10:16:38 <null> it says the first bit of the mantissa doesn't indicate the sign
75 2014-11-23 10:17:16 <null> instead there is an extra sign bit, 8 bits of exponent, and 23 bits of mantissa
76 2014-11-23 10:17:45 <null> and the sign bit is located at bit 0, not after 8 bits of exponent. at least if we're talking about ieee754
77 2014-11-23 10:18:32 <null> i got it
78 2014-11-23 10:19:14 <sipa> we're not talking about ieee754?
79 2014-11-23 10:19:22 <sipa> the compact encoding is something satoshi invented afaik
80 2014-11-23 10:19:41 <null> oh ok. so then it's not a native 'float'
81 2014-11-23 10:19:49 <sipa> no, certainly not
82 2014-11-23 10:19:58 <sipa> it's similar
83 2014-11-23 10:20:04 <sipa> but it's base 256, not base 2
84 2014-11-23 10:20:13 <null> but it still works as a native float, due to the quirk of prepending 0x00
85 2014-11-23 10:21:09 <sipa> 'works as' ?
86 2014-11-23 10:21:15 <sipa> i don't understand
87 2014-11-23 10:21:43 <sipa> https://github.com/bitcoin/bitcoin/blob/master/src/uint256.h#L308-320
88 2014-11-23 10:22:02 <sipa> it's a 32-bit floating point encoding, but not ieee 754
89 2014-11-23 10:22:25 <null> it can be interpreted as a ieee754 32-bit floating-point number and can be used in a semantically correct fashion
90 2014-11-23 10:22:38 <sipa> no
91 2014-11-23 10:22:52 <null> because, if satoshi designed the format, why would it have a sign anyway?
92 2014-11-23 10:22:57 <sipa> ask him
93 2014-11-23 10:23:34 <sipa> as i said: it uses base 256, not base 2; i don't see how it can be compatible with ieee 754
94 2014-11-23 10:23:39 <gmaxwell> null: it is not at all compatible, ... I cannot think of anything useful you could do treating those bits as a ieee754 number.
95 2014-11-23 10:24:10 <null> why 'no'? in ieee you have 1 sign bit, 8 bits of exponent, 23bits of mantissa. if in base-256 your first bit is 1, i.e. >0x7f, you shift it right and prepend 00, and adjust the exponent
96 2014-11-23 10:24:27 <null> because otherwise the leading 1 of the 24 bits of mantissa would bias the exponent
97 2014-11-23 10:26:33 <sipa> but the 8 bits of exponent in the compact format are in base 256, and encode a multiplied of something between 256^-3 and 256^252
98 2014-11-23 10:26:59 <bost> hi. I've got a problem killing my bitcoind process:
99 2014-11-23 10:27:03 <bost>
100 2014-11-23 10:27:03 <bost> 2150 /usr/bin/bitcoind -daemon
101 2014-11-23 10:27:03 <bost> pgrep --list-full bitcoind
102 2014-11-23 10:27:13 <sipa> the 8 bits of exponent in an ieee 754 are in base 2, and encode a multiplier of something between 2^-126 and 2^127
103 2014-11-23 10:27:16 <bost>
104 2014-11-23 10:27:16 <bost> bitcoind stop
105 2014-11-23 10:27:16 <bost> error: no response from server
106 2014-11-23 10:27:26 <sipa> try killalll bitcoind
107 2014-11-23 10:27:30 <sipa> it will shut down cleanly
108 2014-11-23 10:27:31 <null> i agree. and i will use the correct interpretation. but i still think that this is just a scaling. and maybe i could use ieee754 to compute the strongest chain :)
109 2014-11-23 10:27:51 <sipa> null: please don't
110 2014-11-23 10:28:03 <null> i won't :)
111 2014-11-23 10:28:06 <sipa> please don't use data types that have built-in rounding in consensus-critical code
112 2014-11-23 10:28:21 <gmaxwell> null: these decisions must be utterly bit identical or you will be wrong and exploitable on account of it.
113 2014-11-23 10:28:25 <sipa> and sure, it's "just some scaling", all floating point formats are essentially some form of scaling... that's all they do
114 2014-11-23 10:28:27 <bost> sipa: it does not help
115 2014-11-23 10:28:31 <bost> :(
116 2014-11-23 10:28:38 <gmaxwell> bost: kill -9 2150
117 2014-11-23 10:29:04 <bost> gmaxwell: that's what I don't want to do... I'd like to shut it down cleanly
118 2014-11-23 10:29:11 <sipa> it shouldn't matter
119 2014-11-23 10:29:22 <gmaxwell> sipa: Incidentally, I would never advise another to use killall for on solaris it does more precisely what the name suggests it may do.
120 2014-11-23 10:29:22 <sipa> if it doesn't react to RPC, there's already a problem
121 2014-11-23 10:29:32 <sipa> gmaxwell: ah!
122 2014-11-23 10:30:15 <gmaxwell> bost: if it's not responding it's wedged your recourse is to kill it with no mercy. Any idea what got it in that state? what version is it? any unusual load?
123 2014-11-23 10:31:33 <sipa> bost: also, in newer versions of bitcoin you'll have to use bitcoin-cli stop; not bitcoind stop
124 2014-11-23 10:31:47 <bost> gmaxwell: I autostart start bitcoind -daemon in my session.
125 2014-11-23 10:32:10 <bost> gmaxwell: and my laptop was off for about a week.
126 2014-11-23 10:33:24 <gmaxwell> coryfields: leveldb build is chatty like make V=1 ... is there a reason we're not shutting it up?
127 2014-11-23 10:33:29 <bost> gmaxwell: so yea it has to catch up with the block chain - so my load went to max. but that's acceptable.
128 2014-11-23 10:34:23 <gmaxwell> oh, was it merely busy and not actually unresponsive?
129 2014-11-23 10:34:33 <bost> gmaxwell: anyway I wanted to something else so at first I reniced it to +20 (min)
130 2014-11-23 10:35:05 <bost> gmaxwell: that didn't help so I did bitcoind stop. but that didn't stop it.
131 2014-11-23 10:35:43 <bost> gmaxwell: so I reniced it to 0 (normal) but even after that the bitcoind did not stop
132 2014-11-23 10:36:04 <bost> gmaxwell: for a couple of minutes.
133 2014-11-23 10:36:51 <bost> gmaxwell: so I tried kill 2150, and even killall bitcoind but that didn't work.
134 2014-11-23 10:37:43 <gmaxwell> bost: what version is this that you're running?
135 2014-11-23 10:37:46 <bost> gmaxwell: so I went here and asked you for help and re-tried kill and killall
136 2014-11-23 10:38:02 <bost> gmaxwell: fortunatelly it's terminated now.
137 2014-11-23 10:38:37 <bost> gmaxwell: wait a sec pls... I gotta start it again.
138 2014-11-23 10:39:09 <bost> gmaxwell: oh it takes ages
139 2014-11-23 10:39:59 <bost> gmaxwell: btw it was busy *and* unresponsive
140 2014-11-23 10:40:31 <bost> $ bitcoind getinfo | grep version
141 2014-11-23 10:40:31 <bost> "protocolversion" : 70002,
142 2014-11-23 10:40:31 <bost> "version" : 90300,
143 2014-11-23 10:40:31 <bost> "walletversion" : 60000,
144 2014-11-23 10:40:34 <bost>
145 2014-11-23 10:41:02 <gmaxwell> Well the version number is the first thing it emits in the debug.log and you can also run bitcoind -version
146 2014-11-23 10:41:23 <bost>
147 2014-11-23 10:41:23 <bost> $ bitcoind -version
148 2014-11-23 10:41:23 <bost> : Cannot obtain a lock on data directory /home/bost/.bitcoin. Bitcoin Core is probably already running.
149 2014-11-23 10:41:30 <gmaxwell> uh. 903... you shouldn't be able to rpc against with the bitcoind command by itself.
150 2014-11-23 10:52:30 <bost>
151 2014-11-23 10:52:30 <bost> $ aptitude show bitcoind | grep -i version
152 2014-11-23 10:52:30 <bost> gmaxwell: uff it took me a while but I've got it:
153 2014-11-23 10:52:30 <bost> Version: 0.9.3-trusty2
154 2014-11-23 10:52:31 <bost> gmaxwell: i think it's the latest... lemme check it.
155 2014-11-23 10:53:16 <bost> gmaxwell: yea 0.9.3 is the latest.
156 2014-11-23 10:54:28 <bost> gmaxwell: magically the bitcoind stop works now... uff uff
157 2014-11-23 10:54:37 <gmaxwell> sipa: did we not remove the ability to use bitcoind as a rpc client in 0.9?
158 2014-11-23 10:55:13 <sipa> null: also, a 32-bit ieee 754 float actually can't represent the numbers bitcoin uses as target; they're limited to (slightly less than) 2^128
159 2014-11-23 10:57:53 <null> sipa: i know. i just thought i might be able to use the value to distinguish among more/less difficult, which should work. but only on a per-block level, probably not on a per-chain level
160 2014-11-23 10:58:12 <null> but never mind. i'll be using the correct format
161 2014-11-23 10:58:12 <sipa> per-block is not useful
162 2014-11-23 10:58:22 <null> sipa: yeah, i know :)
163 2014-11-23 10:58:39 <sipa> gmaxwell: seems rpc sending through bitcoind still worked in 0.9.3
164 2014-11-23 10:59:06 <gmaxwell> sipa: ah, how time flies on master.
165 2014-11-23 11:01:19 <HM> hi gmaxwell.
166 2014-11-23 11:02:25 <sipa> gmaxwell: 0.9.0 branched off in januari...
167 2014-11-23 11:06:21 <gmaxwell> hm. why is getinfo yielding proxy: "" when it's quite clearly using the proxy= I have set in the conf?
168 2014-11-23 11:06:23 <bost> gmaxwell: sipa: 90300 stands for 0.9.3 ??? Uhg...
169 2014-11-23 11:06:45 <gmaxwell> bost: yes.
170 2014-11-23 11:07:01 <bost> gmaxwell: sipa: what kind of strange version numbering is that? :-(
171 2014-11-23 11:07:29 <gmaxwell> 09 03 00 with the leading 0 omitted.
172 2014-11-23 11:08:35 <bost> gmaxwell: sipa: but that's insane!!! how on earth should anyone know how many leading zeros do you use?
173 2014-11-23 11:09:03 <gmaxwell> its unambigious
174 2014-11-23 11:09:30 <gmaxwell> sipa: uh. something has broken the proxy handling it seems.
175 2014-11-23 11:10:51 <bost> gmaxwell: sipa: unambigious??? 1st leading 0 is omitted, 2nd is not... what about the 3rd one?
176 2014-11-23 11:11:25 <gmaxwell> bost: what are you going on about?
177 2014-11-23 11:12:07 <bost> gmaxwell: sipa: I'm ranting about version numbering!
178 2014-11-23 11:12:29 <gmaxwell> Please take it elsewhere since it seems to have no relationship to anything of substance.
179 2014-11-23 11:12:37 <bost> ACTION calm down man
180 2014-11-23 11:14:08 <bost> gmaxwell: sipa: well... where elsewhere if not here on -dev channel?
181 2014-11-23 11:14:25 <sipa> bost: it's a very common way of internally storing version numbers; you can also look in the log, in the -version output, in the about dialog, in the release notes, ... if you want it human-formatted
182 2014-11-23 11:15:29 <sipa> and it seems you did
183 2014-11-23 11:15:52 <bost> gmaxwell: sipa: I'm doing software for about 16 years and I can tell ya it is NOT.
184 2014-11-23 11:16:48 <bost> gmaxwell: sipa: btw bitcoind -version doesn't work:
185 2014-11-23 11:16:49 <bost> : Cannot obtain a lock on data directory /home/bost/.bitcoin. Bitcoin Core is probably already running.
186 2014-11-23 11:16:50 <bost>
187 2014-11-23 11:16:55 <sipa> use bitcoin-cli
188 2014-11-23 11:17:08 <bost>
189 2014-11-23 11:17:08 <bost> bitcoin-cli -version
190 2014-11-23 11:17:08 <bost> error: too few parameters
191 2014-11-23 11:17:16 <sipa> ah, that's good to know
192 2014-11-23 11:17:21 <bost> ehg???
193 2014-11-23 11:17:22 <sipa> we should support -version there
194 2014-11-23 11:17:24 <op_null> gmaxwell: I can't replicate that, I'm running master with a proxy set and it seems to be operating fine.
195 2014-11-23 11:17:31 <gmaxwell> sipa: we do.
196 2014-11-23 11:18:20 <bost>
197 2014-11-23 11:18:20 <bost> $ bitcoin-cli version
198 2014-11-23 11:18:20 <bost> error: {"code":-32601,"message":"Method not found"}
199 2014-11-23 11:18:20 <sipa> bost: the linux kernel for example uses a very similar version number scheme internally
200 2014-11-23 11:18:31 <bost>
201 2014-11-23 11:18:31 <bost> bitcoin-cli getversion
202 2014-11-23 11:18:31 <bost> error: {"code":-32601,"message":"Method not found"}
203 2014-11-23 11:18:40 <bost> nothing of that works...
204 2014-11-23 11:18:48 <sipa> that would be sending the command 'getversion' to a running bitcoind
205 2014-11-23 11:19:11 <gmaxwell> bost: it's fine in git master, presumably we fixed that in the nearly year since the branching there.
206 2014-11-23 11:19:26 <sipa> and bitcoin-cli -version is supported in the upcoming release; just not yet in the 0.9 branch it seems
207 2014-11-23 11:19:34 <sipa> sorry about that, but will be fixed soon :)
208 2014-11-23 11:19:59 <sipa> also, bitcoind -version works fine, even if bitcoind is already running
209 2014-11-23 11:20:04 <sipa> (in the master branch)
210 2014-11-23 11:20:41 <bost>
211 2014-11-23 11:20:41 <bost> 3.16.0-24-generic
212 2014-11-23 11:20:41 <bost> sipa: $ uname -r
213 2014-11-23 11:20:55 <sipa> i said internally
214 2014-11-23 11:21:28 <bost> sipa: I see here major/minor numbers clearly separated by the '.'
215 2014-11-23 11:21:37 <sipa> bost: i said internally
216 2014-11-23 11:21:56 <sipa> really, this is leading nowhere
217 2014-11-23 11:22:08 <bost> sipa: Ok. I'm stopping... sorry
218 2014-11-23 11:22:16 <sipa> the RPC returns the internal version number used to identify clients
219 2014-11-23 11:22:42 <sipa> if you want the version string, you can use -version (which up to 0.9 indeed didn't always seem to work, but that will be improved soon)
220 2014-11-23 11:24:37 <HM> gmaxwell, turns out there was an EC based SRP proposal by made to IEEE P1363 working group by the author of SRP-5 in 2001.
221 2014-11-23 11:25:11 <HM> gmaxwell, a naive transform of SRP-6a to an EC group is vulnerable to server impersonation and offline bruteforce
222 2014-11-23 11:25:13 <gmaxwell> op_null: https://github.com/bitcoin/bitcoin/pull/4327#issuecomment-64114615
223 2014-11-23 11:27:37 <op_null> gmaxwell: that explains why, I used a raw SOCKS proxy rather than anything with -onlynet. good catch.
224 2014-11-23 11:29:26 <gmaxwell> op_null: looks like I'm wrong about the name proxy, part at least, so it may just be cosmetic.
225 2014-11-23 11:31:29 <fanquake> If anyone has some testnet coins handy, I could use a few. Cheers in advance. mpihspoiEkKMtZRg8Lst3LX2TGPqTQEAqF
226 2014-11-23 11:35:44 <gmaxwell> op_null: https://github.com/bitcoin/bitcoin/issues/5355
227 2014-11-23 11:38:47 <op_null> gmaxwell: payment protocol connections leak" whoops.
228 2014-11-23 11:40:13 <gmaxwell> op_null: we probably need a systematic test plan for connection leaks.
229 2014-11-23 11:42:52 <op_null> as another test for travisci or something which can be done manually? I can see an easy way to do the latter.
230 2014-11-23 11:43:36 <gmaxwell> manually.
231 2014-11-23 11:43:47 <gmaxwell> I dunno how to usefully automate it.
232 2014-11-23 11:44:56 <op_null> you could probably do an automated system inside a virtual machine and record all of the network traffic, but that's pretty fragile.
233 2014-11-23 11:45:59 <gmaxwell> yea, I meant "without boiling the oceans." :)
234 2014-11-23 11:51:44 <op_null> yeah yeah. it's not an easy problem to solve because the failure modes aren't black and white.
235 2014-11-23 13:28:17 <sipa> gmaxwell: yeah just a "Only use the RPC if you know what you're doing" or something
236 2014-11-23 14:18:09 <JijoJohn> Dear experts, Newbie here. I'm planning to use could server from softlayer [ k2 series nvidia GPU cards], Could you suggest the OS and mining software
237 2014-11-23 14:18:19 <sipa> #bitcoin-mining please
238 2014-11-23 15:29:08 <phillipsjk> I thought of a use-case for the Blockchain data .torrent even after the 0.10 release. Bittorrent allows you to finely throttle the download speed to avoid saturating your Internet connection and disrupting low-latency services.
239 2014-11-23 15:29:42 <phillipsjk> Bitcoin by its nature seems to have very bursty data usage.
240 2014-11-23 15:31:06 <sipa> why is this specific to bittorrent?
241 2014-11-23 15:31:39 <sipa> after 0.10 is well deployed we can easily add throttling to bitcoin core too
242 2014-11-23 15:31:51 <kanzure> well you see, users don't understand how to limit their download rates, and isps are already throttling torrents for users automatically
243 2014-11-23 15:31:52 <op_null> phillipsjk: you can use QoS on your router to make sure your other traffic (SSH, HTTP) has higher priority than Bitcoin P2P. you don't need to worry about application level controls if you do this.
244 2014-11-23 15:32:40 <phillipsjk> QoS only really helps with outgoing traffic, not incoming traffic.
245 2014-11-23 15:33:29 <phillipsjk> sipa because Bittorrent is a mature application designed to download form many hosts at once.
246 2014-11-23 15:33:36 <runeks> petertodd: Shouldn't a headers message be deserialized into CBlockHeader(s) rather than CBlock(s)? https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/messages.py#L310
247 2014-11-23 15:34:13 <sipa> phillipsjk: yes, so?
248 2014-11-23 15:34:32 <op_null> what you are talking about (seeding blocks) is a very much upstream activity. most residential ADSL connections are asymmetric, so the upstream connections are the most restricted.
249 2014-11-23 15:34:53 <sipa> if downloading with bittorrent is more efficient, please use it
250 2014-11-23 15:35:17 <sipa> but i don't see what this has to do with throttling?
251 2014-11-23 15:36:20 <sipa> the reason bitcoin itself so far does not throttle outgoing bandwidth is because peers deal very badly with it, with the sync mechanism used until 0
252 2014-11-23 15:36:26 <sipa> 0.9.x
253 2014-11-23 15:36:55 <sipa> in 0.10 this is no longer a concern as thete is parallel block fetching
254 2014-11-23 15:37:31 <phillipsjk> I only bring it up because an alt-coin I installed yesterday (presumably with fewer transactions) was intermittently saturating my connection with what is assumed to be a single fast peer. Requests for blocks are much smaller than the actual blocks.
255 2014-11-23 15:38:19 <sipa> i'm still not clear what you are trying to say
256 2014-11-23 15:38:34 <sipa> is it about downstream or upstream throttling?
257 2014-11-23 15:39:02 <phillipsjk> It may be worthy of a note in the change log that downloading may now be fast enough to disrupt other internet users on a shared connection.
258 2014-11-23 15:39:02 <sipa> is it about initial download or normal block relay?
259 2014-11-23 15:39:16 <phillipsjk> initial download.
260 2014-11-23 15:39:21 <sipa> heh?
261 2014-11-23 15:39:38 <sipa> 0.10 downloads in parallel from all outgoing peers
262 2014-11-23 15:39:50 <sipa> earlier versions.synced from a single peer
263 2014-11-23 15:40:06 <sipa> the new.code should be much more friendly to peers
264 2014-11-23 15:40:50 <phillipsjk> I am talking about room-mates trying to play video games or making VOIP calls requiring low latency.
265 2014-11-23 15:41:06 <sipa> ok
266 2014-11-23 15:41:30 <sipa> but are you talking about downstream or upstream?
267 2014-11-23 15:41:39 <phillipsjk> downstream.
268 2014-11-23 15:41:54 <sipa> oh ok
269 2014-11-23 15:42:14 <sipa> we could easily add throttling for initial download
270 2014-11-23 15:43:57 <op_null> sipa: take it as a compliment, your headers first code is just too good.
271 2014-11-23 15:43:59 <phillipsjk> at 25Mbps a 1MB block will still take over 3 seconds.
272 2014-11-23 15:44:32 <phillipsjk> I was not actually testing with the headers code. Just a stupidly fast peer.
273 2014-11-23 15:44:49 <op_null> phillipsjk: you might want to check the math on that.
274 2014-11-23 15:45:17 <phillipsjk> 25/8
275 2014-11-23 15:45:51 <op_null> it would take 320 milliseconds, not 3 seconds.
276 2014-11-23 15:47:37 <phillipsjk> 25Megabits/s / 8 bytes/bit = 3.125 Megabytes/s -- OK, you are right.
277 2014-11-23 15:48:53 <phillipsjk> ACTION usually uses 10bit bytes to keep the math simple and conservative.
278 2014-11-23 15:50:49 <sipa> well throttling the download of a single block would slow down block propagation speed, which is pretty essential to the network
279 2014-11-23 15:51:18 <sipa> but during initial download it does not really matter
280 2014-11-23 15:55:17 <phillipsjk> throttling individual blocks would not work until the majority of node upgrade. Just limiting block requests is probably enough.
281 2014-11-23 15:59:18 <sipa> phillipsjk: are you talking upstream or downstream now?
282 2014-11-23 15:59:43 <sipa> downstream is trivial, as each node decides when to fetch which block from where
283 2014-11-23 15:59:48 <phillipsjk> Befopre a peer sends you a block, you have to request it, no?
284 2014-11-23 16:00:29 <sipa> upstream is harder as it would severely impact pre-0.10 nodes from downloading the chain
285 2014-11-23 16:00:37 <phillipsjk> I was responding to "throttling the download of a single block
286 2014-11-23 16:01:00 <phillipsjk> Upstream router QoS can kick-in.
287 2014-11-23 16:01:09 <sipa> throttling the download of a single incoming block is trivial too
288 2014-11-23 16:01:30 <sipa> but just a bad idea for block propagation through the network
289 2014-11-23 16:01:45 <op_null> blocks are like TCP, three stages. peer2 announces their new inventory, peer1 sends a request for the data if they want it, peer2 sends it back
290 2014-11-23 16:01:53 <phillipsjk> I assumed you get the whole block at once when requested.
291 2014-11-23 16:02:32 <sipa> yes but you can delay reading from the socket
292 2014-11-23 16:02:54 <sipa> which means transmission control kicks in, slowing down the sender
293 2014-11-23 16:04:00 <phillipsjk> Becuase more thna one TCP packet is used, IC.
294 2014-11-23 16:05:24 <sipa> tcp packets are 1.5 kilobytes typically
295 2014-11-23 16:05:47 <phillipsjk> ACTION is late for work
296 2014-11-23 16:05:57 <phillipsjk> Thanks for the chat.
297 2014-11-23 16:06:04 <sipa> yw!
298 2014-11-23 16:06:18 <sipa> thanks for bringing the topic up
299 2014-11-23 16:06:54 <sipa> i never realozed that someone would consider using available downstream bandwidth to receive blocks faster, a problem
300 2014-11-23 16:07:05 <sipa> *realized
301 2014-11-23 16:08:13 <phillipsjk> I didn't either 'til my room-mate complained. (but could not actually be sure their game was disrupted during the download.)
302 2014-11-23 16:08:48 <sipa> i have often heard requests to be able to throttle upstream
303 2014-11-23 16:09:10 <sipa> but that is hard until peers actually deal well with it
304 2014-11-23 16:09:24 <sipa> which will be after 0.10 is deployed
305 2014-11-23 16:38:19 <jgarzik> Indeed, you could throttle older blocks in theory. But given <0.10 's lack of peer switching, that would hurt them the most.
306 2014-11-23 16:49:20 <op_null> from observing people getting introduced to wallets with more than one address, there's some things that seem to confuse people a lot. first and foremost people think that they can't use an address once it has been hidden by the client.
307 2014-11-23 16:50:31 <op_null> Breadwallet has taken the design where they show a "receiving address" that is rotated into a new one as soon as it sees a transaction. you could call this ideal behaviour, but people seem to think that once it's been rotated the old address is lost and any further funds sent to it will be destroyed.
308 2014-11-23 16:50:59 <magichex> hi there just quick question
309 2014-11-23 16:51:16 <sipa> well ideally imho wallets should not show any aaddress or otger cryptographic material for human consumption at all
310 2014-11-23 16:51:19 <magichex> is it possible to get block reward from coin daemon via rpc json ?
311 2014-11-23 16:52:05 <op_null> the second thing is a bit of an odd one I wasn't expecting. people are super confused by the fact that they can't "check" if their money is still there using a block explorer. this one isn't something that can be solved, it's the normal thing where people freak out about change addresses, but magnified because they try to look at their old addresses and panic more.
312 2014-11-23 16:53:03 <op_null> sipa: of course not, but users seem to demand it as it gives them more "control", or something, though really that's not a positive thing to be happening at all.
313 2014-11-23 16:53:32 <sipa> indeed
314 2014-11-23 16:54:13 <op_null> in a way the second one is weird, it suggests that people trust a lookup on blockchain.info more than the number displayed in their wallet. really the one in their wallet should be absolute unless they expect to be on a side fork with a totally different reality.
315 2014-11-23 16:57:20 <op_null> I suppose if you are using an SPV wallet there's the risk that one of your peers lied to you and told you that you have less money than you thought. that's probably improved by wallets not doing their filtering just on one peer. I don't know if there's ever been a single case of a lying peer on the network though.