1 2013-10-29 00:00:19 <sipa> but only target out of them are valid
2 2013-10-29 00:00:19 <sipa> the distribution within those target is still uniform
3 2013-10-29 00:01:01 <gribble> 195.457647398
4 2013-10-29 00:01:01 <sipa> ;;calc log(2**256 / (2**48 / 65535) / 390928788)/log(2)
5 2013-10-29 00:01:54 <phantomcircuit> gmaxwell, the issue with that function is there is polling logic combined with event driven io
6 2013-10-29 00:01:54 <sipa> ;;calc exp(log(2) * (log(2**256 / (2**48 / 65535) / 390928788)/log(2) - 73.28945))
7 2013-10-29 00:01:55 <gribble> 5974367490971483215902803190370795520
8 2013-10-29 00:02:11 <phantomcircuit> gmaxwell, it should all be refactored.. just uh.. later
9 2013-10-29 00:02:13 <sipa> ^ that many times the number of hashes the bitcoin network has performed in its history
10 2013-10-29 00:02:20 <sipa> to hit one hash == target
11 2013-10-29 00:02:44 <gribble> 122.168197398
12 2013-10-29 00:02:44 <phantomcircuit> ;;calc log(5974367490971483215902803190370795520)/log(2)
13 2013-10-29 00:02:57 <sipa> melvster: so i'll bet you 10 BTC that there is no hash == target :)
14 2013-10-29 00:03:03 <sipa> (i haven't checked)
15 2013-10-29 00:03:04 <phantomcircuit> so 2^61
16 2013-10-29 00:03:11 <melvster> sipa: you offering odds?
17 2013-10-29 00:03:28 <phantomcircuit> melvster, the odds are ~ 1/2^61
18 2013-10-29 00:03:33 <sipa> phantomcircuit: huh?
19 2013-10-29 00:03:44 <phantomcircuit> sipa, birthday attack
20 2013-10-29 00:03:51 <sipa> what does that have to do with it
21 2013-10-29 00:03:55 <sipa> this is not a collision problem
22 2013-10-29 00:03:59 <sipa> it's first preimage
23 2013-10-29 00:04:02 <phantomcircuit> oh right
24 2013-10-29 00:04:03 <phantomcircuit> derp
25 2013-10-29 00:04:08 <phantomcircuit> so 1/2**122
26 2013-10-29 00:04:10 <phantomcircuit> ish
27 2013-10-29 00:04:17 <sipa> yep
28 2013-10-29 00:04:18 <phantomcircuit> give or take a few hundred trillion
29 2013-10-29 00:04:20 <sipa> actually more
30 2013-10-29 00:04:26 <sipa> as with lower difficulty, it was even harder
31 2013-10-29 00:05:08 <sipa> hmm, for an individual block
32 2013-10-29 00:05:37 <sipa> which corresponds to 2^256/target hashes
33 2013-10-29 00:06:18 <sipa> meh
34 2013-10-29 00:06:20 <sipa> ACTION too tired
35 2013-10-29 00:06:21 <melvster> sipa: ill bet you 1 millibit if you offer me 1000-1 ... i havent checked
36 2013-10-29 00:06:36 <melvster> but think of this
37 2013-10-29 00:06:50 <melvster> you need from 256 bits the first say, 50 to be 0
38 2013-10-29 00:06:55 <phantomcircuit> melvster, you're offering him 1000:1 on a 2^122:1 bet?
39 2013-10-29 00:06:56 <phantomcircuit> lol
40 2013-10-29 00:07:09 <lianj> ^^
41 2013-10-29 00:07:21 <melvster> all results that hit 50 zeros, the next bit is either a 1 or a 0
42 2013-10-29 00:07:25 <melvster> with 50 50 chance
43 2013-10-29 00:07:31 <sipa> yes
44 2013-10-29 00:07:40 <sipa> we've taken that into account already :)
45 2013-10-29 00:07:47 <melvster> oh ok
46 2013-10-29 00:07:48 <gmaxwell> normally a bit is either 0 or a 1. ... :P
47 2013-10-29 00:08:21 <sipa> melvster: the output of the hash function is a uniformly random number between 0 and 2^256-1
48 2013-10-29 00:08:28 <sipa> melvster: but only those <= target are valid
49 2013-10-29 00:08:34 <sipa> how many possible hashes are that?
50 2013-10-29 00:08:47 <melvster> i only care about the first bit after the target
51 2013-10-29 00:08:53 <melvster> i dont care about all others
52 2013-10-29 00:09:00 <sipa> you're not careful!
53 2013-10-29 00:09:02 <phantomcircuit> melvster, then you dont understand what <= means
54 2013-10-29 00:09:13 <melvster> well ... yes im just reading up ...
55 2013-10-29 00:09:23 <sipa> melvster: really, just try to answer my question
56 2013-10-29 00:09:34 <melvster> ok so it seems target is a range ...
57 2013-10-29 00:09:42 <sipa> target is a number
58 2013-10-29 00:09:49 <melvster> sipa: sorry im still learning, just working it out
59 2013-10-29 00:09:55 <sipa> an integer between 0 and 2^256-1
60 2013-10-29 00:10:07 <sipa> how many integers are there between 0 and target?
61 2013-10-29 00:10:20 <sipa> (inclusive)
62 2013-10-29 00:10:24 <gmaxwell> oh oh I know I know
63 2013-10-29 00:10:30 <sipa> sssssh
64 2013-10-29 00:10:34 <phantomcircuit> lol
65 2013-10-29 00:10:39 <sipa> (super super secure ssh)
66 2013-10-29 00:10:59 <melvster> hmm not sure about target, but it will be roughly 2^32 * difficulty
67 2013-10-29 00:11:08 <sipa> melvster: you're looking too far
68 2013-10-29 00:11:15 <sipa> melvster: how many integers are there between 0 and 10?
69 2013-10-29 00:11:22 <melvster> inclusive?
70 2013-10-29 00:11:24 <sipa> yes
71 2013-10-29 00:11:36 <melvster> 11 if you include 0 and 10
72 2013-10-29 00:11:38 <sipa> correct
73 2013-10-29 00:11:47 <sipa> now how many integers are there between 0 and target?
74 2013-10-29 00:12:07 <melvster> this i dont know ... im currently reading the wiki page that defines target ..
75 2013-10-29 00:12:17 <sipa> target is just a number
76 2013-10-29 00:12:28 <sipa> it doesn't matter how it is defined
77 2013-10-29 00:12:38 <melvster> so then it will be target
78 2013-10-29 00:12:39 <sipa> there are target+1 integers between 0 and target
79 2013-10-29 00:12:45 <melvster> or target+1
80 2013-10-29 00:12:50 <melvster> inclusive
81 2013-10-29 00:12:50 <sipa> yup
82 2013-10-29 00:12:51 <melvster> right
83 2013-10-29 00:12:52 <lianj> \o/
84 2013-10-29 00:13:09 <melvster> ahhhh
85 2013-10-29 00:13:11 <melvster> i get it now
86 2013-10-29 00:13:20 <sipa> so, we're looking at all outputs of this hash function which are between 0 and target
87 2013-10-29 00:13:33 <sipa> is there any of these numbers which has a higher chance of being hit than another?
88 2013-10-29 00:14:37 <melvster> i guess not
89 2013-10-29 00:14:40 <sipa> indeed not
90 2013-10-29 00:15:02 <sipa> the output of the hash function is uniformly distributed, and we're just cutting away the part > target
91 2013-10-29 00:15:27 <sipa> so, what we end up with is a number uniformly distributed between 0 and target
92 2013-10-29 00:15:31 <melvster> sipa: thanks makes total sense ... sorry for being slow
93 2013-10-29 00:15:31 <sipa> what is the chance for hitting 0?
94 2013-10-29 00:15:39 <melvster> 1 / target
95 2013-10-29 00:15:43 <melvster> +1
96 2013-10-29 00:15:44 <sipa> almost :)
97 2013-10-29 00:15:56 <sipa> what is the chance for hitting target?
98 2013-10-29 00:16:00 <melvster> same
99 2013-10-29 00:16:03 <sipa> yup
100 2013-10-29 00:16:45 <melvster> got it ... it would be the same as taking a random number modulo target
101 2013-10-29 00:16:45 <sipa> so every block has a chance of 1 / (target + 1) of having a hash equal to its target
102 2013-10-29 00:16:52 <sipa> _almost_
103 2013-10-29 00:16:54 <melvster> lol
104 2013-10-29 00:16:56 <melvster> +1
105 2013-10-29 00:17:21 <sipa> melvster: let's say you have a random number in the range 0-99
106 2013-10-29 00:17:37 <melvster> yes i get it :)
107 2013-10-29 00:17:39 <sipa> and you're doing it modulo 30
108 2013-10-29 00:17:48 <sipa> what is the chance for hitting 0?
109 2013-10-29 00:18:12 <melvster> all the same 1/30
110 2013-10-29 00:18:17 <sipa> nope
111 2013-10-29 00:18:26 <melvster> ohhh
112 2013-10-29 00:18:31 <sipa> give me each case that leads to 0
113 2013-10-29 00:18:38 <melvster> 90-99 have a bigger chance
114 2013-10-29 00:18:43 <melvster> i mean
115 2013-10-29 00:18:53 <melvster> 0-9 have a slightly higher chance
116 2013-10-29 00:19:06 <sipa> correct
117 2013-10-29 00:19:08 <sipa> how much?
118 2013-10-29 00:19:20 <melvster> 4:3
119 2013-10-29 00:19:26 <melvster> so about 33% more
120 2013-10-29 00:19:29 <sipa> yup
121 2013-10-29 00:20:04 <sipa> however, this only occurs significantly when the modulus is close to the range
122 2013-10-29 00:20:19 <melvster> yes
123 2013-10-29 00:20:22 <sipa> but cutting away values results always in a uniform result
124 2013-10-29 00:20:39 <sipa> while for modulo, you need the modulus to be a divisor of the range
125 2013-10-29 00:21:47 <melvster> right thanks, now to translate this into javascript ...
126 2013-10-29 00:23:38 <melvster> sipa: however you did make an assumption that the winning hashes are random ... a miner with OCD might only submit results of a certain pattern :)
127 2013-10-29 00:24:18 <sipa> this would be a poor miner
128 2013-10-29 00:24:20 <sipa> literally
129 2013-10-29 01:06:13 <gmaxwell> hm, I didn't think we were banning for this:
130 2013-10-29 01:06:14 <gmaxwell> 2013-10-26 17:13:52 ERROR: CheckTransaction() : vin empty
131 2013-10-29 01:06:14 <gmaxwell> 2013-10-26 17:13:52 ERROR: CTxMemPool::accept() : CheckTransaction failed
132 2013-10-29 01:06:15 <gmaxwell> 2013-10-26 17:13:52 Misbehaving: bitcoinnz4ijlbqc.onion:8333 (90 -> 100) DISCONNECTING
133 2013-10-29 01:08:38 <sipa> gmaxwell: otherwise we'd likely never have heard about the problem
134 2013-10-29 01:09:18 <sipa> and we should ban for it, it's an unambiguously invalid transaction
135 2013-10-29 01:09:31 <warren> sipa: I'm integrating watchonly with Coin Control...
136 2013-10-29 01:09:45 <warren> COutput(const CWalletTx *txIn, int iIn, int nDepthIn, bool fSpendableIn)
137 2013-10-29 01:10:03 <warren> Coin Control uses the previous version of this function which lacks the bool fSpendableIn
138 2013-10-29 01:10:14 <gmaxwell> sipa: ah well I do take my logs from time to time and grep -v out all the boring stuff.
139 2013-10-29 01:11:08 <warren> hmm
140 2013-10-29 01:29:43 <_alp_> test
141 2013-10-29 01:30:11 <_alp_> Anyone use intellij idea with protobuf?
142 2013-10-29 01:35:52 <melvster> is this formula for calculating target correct for both version 1 and 2?
143 2013-10-29 01:35:56 <melvster> 0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000
144 2013-10-29 01:36:07 <melvster> as per https://en.bitcoin.it/wiki/Difficulty
145 2013-10-29 01:36:27 <maaku> melvster: difficulty doesn't change between versions
146 2013-10-29 01:36:45 <melvster> maaku: thx i seem to have a couple of 0s more than i thought
147 2013-10-29 01:36:48 <melvster> ACTION debugging
148 2013-10-29 01:37:18 <melvster> 0x1b - 3 // that;s correct?
149 2013-10-29 01:38:46 <melvster> oh maybe it's right
150 2013-10-29 01:38:54 <melvster> could be this whole uniform distribution thing
151 2013-10-29 01:47:21 <warren> sipa: for watchonly outputs, should I exclude them entirely from the coincontroldialog or display them but greyed out, not selectable?
152 2013-10-29 01:47:56 <warren> anyone else have an opinion?
153 2013-10-29 01:50:20 <_alp_> Is it useful to display it non-selectable?
154 2013-10-29 01:50:25 <_alp_> or more confusing
155 2013-10-29 01:50:40 <warren> dunno
156 2013-10-29 01:50:44 <warren> it already shows up as part of the balance
157 2013-10-29 01:51:51 <_alp_> Could you use it to construct an offline tx?
158 2013-10-29 01:53:31 <warren> The coincontroldialog wouldn't be useful for that.
159 2013-10-29 01:56:55 <Luke-Jr> warren: whatever you go with, it should be consistent with other unspendable coins (generation < 100 blocks)
160 2013-10-29 01:57:01 <Luke-Jr> warren: right now that means don't show it at all
161 2013-10-29 01:57:17 <Luke-Jr> warren: it doesn't really make sense for the watchonly stuff though!
162 2013-10-29 01:57:32 <Luke-Jr> since that's address-based, and shouldn't involve the output side of things
163 2013-10-29 01:58:01 <Luke-Jr> watchonly should just be showing recieves adding up to some total
164 2013-10-29 01:58:02 <warren> Luke-Jr: not my decision, I'm just implementing something and people can decide otherwise
165 2013-10-29 01:58:12 <Luke-Jr> warren: I mean it's logically nonsensical
166 2013-10-29 01:58:17 <warren> excluding it from the selector seems wise
167 2013-10-29 01:58:23 <Luke-Jr> addresses don't have outputs
168 2013-10-29 01:58:32 <warren> Luke-Jr: right now coincontrol thinks it does =)
169 2013-10-29 01:58:41 <Luke-Jr> warren: sounds like a bug in the watchonly patch
170 2013-10-29 01:58:54 <Luke-Jr> when the coins the address received are spent, is it showign that too?
171 2013-10-29 01:59:23 <warren> no
172 2013-10-29 01:59:37 <Luke-Jr> hm, odd
173 2013-10-29 01:59:45 <Luke-Jr> maybe just a watchonly+coincontrol conflict
174 2013-10-29 02:00:09 <warren> yea, htey were never tested together
175 2013-10-29 02:00:18 <warren> I'm thinking of the best way to exclude the watchonly outputs
176 2013-10-29 02:00:37 <Luke-Jr> probably right
177 2013-10-29 02:00:46 <warren> btw, please ACK Coin Control, it's pretty much done
178 2013-10-29 02:00:52 <warren> please review
179 2013-10-29 02:01:43 <warren> AvailableCoins() already excludes immature
180 2013-10-29 02:01:44 <warren> continue;
181 2013-10-29 02:01:44 <warren> if (pcoin->IsCoinBase() && pcoin->GetBlocksToMaturity() > 0)
182 2013-10-29 02:02:06 <Luke-Jr> didn't I already?
183 2013-10-29 02:02:21 <warren> but AvailableCoins() is literally "available", which is a superset of spendable
184 2013-10-29 02:03:26 <warren> coincontroldialog doesn't even use AvailableCoins at all
185 2013-10-29 02:04:54 <Luke-Jr> Available = spendable..
186 2013-10-29 02:05:01 <warren> not according to watchonly
187 2013-10-29 02:05:10 <warren> if you have a problem with that, comment there
188 2013-10-29 02:05:34 <Luke-Jr> the current watchonly PR is just a hack in any case, not something for serious merge consideration
189 2013-10-29 02:05:35 <warren> IsMine() has three states
190 2013-10-29 02:05:42 <warren> really?
191 2013-10-29 02:05:47 <Luke-Jr> ..yes
192 2013-10-29 02:06:11 <Luke-Jr> there are no valid use cases covered by the current watchonly PR
193 2013-10-29 02:06:40 <Luke-Jr> I'm sure we'll have watchonly at some point, but not in this form..
194 2013-10-29 02:06:45 <warren> write that if you think so
195 2013-10-29 02:06:48 <warren> it seems pretty complete to me
196 2013-10-29 02:07:13 <warren> write a substantive reason though
197 2013-10-29 02:07:16 <Luke-Jr> already did
198 2013-10-29 02:27:56 <warren> I'm actually stuck.
199 2013-10-29 02:28:54 <warren> https://github.com/bitcoin/bitcoin/pull/2343/files Coin Control uses getOutputs() to populate the outputs. The watchonly outpoints are included in those outputs.
200 2013-10-29 02:29:41 <warren> https://github.com/sipa/bitcoin/commit/22b7d09218d2cb177ab6b91747af43c1833bceec but I can't figure out how to use either variant of IsMine() (in src/script.cpp) on an outpoint
201 2013-10-29 02:31:28 <warren> There is no CTxDestination or CScript for just an address
202 2013-10-29 02:40:30 <melvster> what's the difference between version 1 and version 2 in the header?
203 2013-10-29 02:49:57 <Luke-Jr> melvster: v2 blocks have the height in the coinbase
204 2013-10-29 02:50:37 <melvster> Luke-Jr: oh that's a cool feature, do you know why that is?
205 2013-10-29 02:50:39 <warren> I might have figured it out...
206 2013-10-29 02:53:06 <melvster> ah ha BIP 34 - block version 2, height in coinbase
207 2013-10-29 02:53:08 <Luke-Jr> melvster: forces generation transactions to be unique
208 2013-10-29 02:53:24 <Luke-Jr> melvster: before, you could have two transactions with the same txid
209 2013-10-29 02:53:28 <Luke-Jr> which created bugs
210 2013-10-29 04:00:48 <warren> I figured out how to fix this ... AvailableCoins needs another parameter.
211 2013-10-29 04:07:22 <Ascendion> ;;blocks
212 2013-10-29 04:07:24 <gribble> 266645
213 2013-10-29 04:10:09 <BlueMatt> ACTION ponders generic "txdb lookup" rules in blocktester that call getrawtransaction rpcs to check rpc server and allow arbitrary txdb inspection
214 2013-10-29 04:11:07 <gmaxwell> BlueMatt: kinda lame to make it less blackbox, as that makes it less useful for testing third party implementations.
215 2013-10-29 04:11:18 <gmaxwell> It's superior, where possible, to test for those things by spending them.
216 2013-10-29 04:11:50 <BlueMatt> gmaxwell: the goal is mostly to test rpc support as well, its really to provide an excuse to bloat the thing into a full-feature bitcoind tester
217 2013-10-29 04:12:06 <BlueMatt> but by making the rule checker for inspect-txdb pluggable any implementation could do whatever calls they need to do so
218 2013-10-29 04:12:34 <gmaxwell> If you do go that route please make sure its optional, making it less useful for testing compliance with other implementations would be a major loss, and hardly worth the improvement for bitcoind alone.
219 2013-10-29 04:12:52 <BlueMatt> default checker can ofc be "looks good"
220 2013-10-29 04:13:09 <gmaxwell> fine enough. :)
221 2013-10-29 04:13:10 <BlueMatt> or maybe Ill just add 100 new tests
222 2013-10-29 04:13:29 <BlueMatt> ACTION has ~hour to kill waiting for dd to finish
223 2013-10-29 04:15:08 <warren> - COutput(const CWalletTx *txIn, int iIn, int nDepthIn)
224 2013-10-29 04:15:09 <warren> + COutput(const CWalletTx *txIn, int iIn, int nDepthIn, bool fSpendableIn)
225 2013-10-29 04:15:27 <warren> sipa: I'm curious what is the purpose of this additional parameter? None of your code actually uses it.
226 2013-10-29 04:16:16 <warren> sipa: it might be more useful as a tri-state enum, but even then it is redundant in the context of coin control, unless you have some other plan for it.
227 2013-10-29 05:17:13 <BlueMatt> gmaxwell/sipa: for the lazy: block-tester now magically pulls in all the transactions/scripts in src/data/{tx,script}_{invalid,valid}.json and reorgs on/off of those blocks :)
228 2013-10-29 05:17:20 <BlueMatt> now you have no excuse for not adding tests
229 2013-10-29 05:17:44 <BlueMatt> well, ok, its manual and requires jar-regeneration, but at least its a start
230 2013-10-29 05:24:43 <dobry-den> I just sent all my peers (dotimes [_ 1000000] (send-message :ping)) and got 1000000 pongs from each one
231 2013-10-29 05:28:25 <Krellan> dobry-den: Nice
232 2013-10-29 05:29:35 <dobry-den> 100,000*
233 2013-10-29 05:31:35 <dobry-den> i added a few orders of magnitude but lost ssh connection to my server as they were ponging
234 2013-10-29 05:45:54 <Krellan> dobry-den: just doing a lot of flood pinging for testing?
235 2013-10-29 05:47:45 <Krellan> dobry-den: see any "pong" messages in the debug log?
236 2013-10-29 05:49:24 <weex> sipa: i tried building the watchonly wallet on ubuntu 12.04 server as per coinpunk and in "./configure --without-qt" i get "configure: error: Could not link against boost_thread-mt !"
237 2013-10-29 05:50:24 <weex> do i need to build boost 1.54 manually or should it work with whatever ubuntu supplied or is it some other problem?
238 2013-10-29 05:52:02 <dobry-den> Krellan: I've been tracking down Satoshi client behavior to emulate it in my own client.
239 2013-10-29 05:52:13 <dobry-den> I'm not so sure I will emulate this feature, though.
240 2013-10-29 05:54:22 <Krellan> dobry-den: I made the patch that gets ping/pong to measure the ping time
241 2013-10-29 05:55:10 <Krellan> It only remembers 1 nonce per peer, though, so if you flood ping, you will see a lot of nonce mismatches, but that's normal, because you're getting ahead of the peer.
242 2013-10-29 05:55:19 <Krellan> Haven't tried sending out 1M pings in a row, though.
243 2013-10-29 05:58:25 <BlueMattBot> Project Bitcoin build #432: STILL FAILING in 3 hr 59 min: http://jenkins.bluematt.me/job/Bitcoin/432/
244 2013-10-29 06:09:55 <warren> Does bitcoind know how to handle multi-homed hosts?
245 2013-10-29 06:10:42 <dobry-den> Krellan: are you saying it's supposed to be rate-limited?
246 2013-10-29 06:12:46 <dobry-den> my own node is almost autonomous so i will start barraging it with junk data soon to see how i can get it to fail
247 2013-10-29 06:12:50 <Krellan> dobry-den: I was curious if it had any side effects when pinging that fast. At first I thought about rate limits but that would just complicate the implementation and prevent people from doing interesting things.
248 2013-10-29 06:13:36 <Krellan> Nice. Hopefully your node was not the node that was giving me truncated pong replies, or always pong replying with 0 (no matter what the ping nonce was).
249 2013-10-29 06:18:07 <dobry-den> haha, ive neglected to even implement pong yet
250 2013-10-29 06:18:44 <dobry-den> which was actually what i was doing - see what kind of rate-limiting there is
251 2013-10-29 06:19:25 <warren> https://github.com/bitcoin/bitcoin/pull/2839 btw, does this work for anyone? doesn't work for me.
252 2013-10-29 06:25:36 <Krellan> I figured rate-limiting ping wouldn't really be effective, because if somebody wanted to DoS, they could just spam another message instead.
253 2013-10-29 06:26:11 <dobry-den> Well, god forbid you send a :version message outside the handshake because that will instaflg you as a lowly outlaw
254 2013-10-29 06:26:57 <dobry-den> But you're right
255 2013-10-29 06:27:01 <Krellan> well that's an obvious bug in a protocol implementation.
256 2013-10-29 06:28:00 <Krellan> rate limiting, on the other hand, gets fuzzy: is other side trying to DoS you, or did other side just get lagged for a few seconds so now you're getting all his backed-up traffic all at once and it looks like a flood?
257 2013-10-29 06:28:30 <dobry-den> How about a high upper-bound then just as a sanity check?
258 2013-10-29 06:28:30 <Krellan> see what I mean? :)
259 2013-10-29 06:29:44 <dobry-den> I like that extraneous version message gets me a slap on the wrist. Law and order
260 2013-10-29 06:30:23 <Krellan> How would one determine what upper bound is reasonable? That's hard. Also probably better to rate-limit at the firewall/traffic shaping layer, not at Bitcoin layer.
261 2013-10-29 06:31:00 <Krellan> I made sure that ping/pong would be confined to same peer only (so it couldn't be used to amplify traffic to other peers). However, if somebody got into your RPC, they could command pings really fast,
262 2013-10-29 06:31:09 <Krellan> but if somebody's getting into your RPC, you have bigger problems to worry about than just ping.
263 2013-10-29 06:31:27 <dobry-den> i'm not worried about the official client
264 2013-10-29 06:32:08 <Krellan> Alternative clients are a good thing, I think. Avoid a software monoculture.
265 2013-10-29 06:34:03 <gmaxwell> Krellan: there are only a few thousand stable full nodes, there is very little risk of a "monoculture" of bitcoind/bitcoin-qt anymore.
266 2013-10-29 06:34:22 <dobry-den> gmaxwell: wow, really?
267 2013-10-29 06:35:02 <gmaxwell> s/stable/stable and reachable/ to be clear.
268 2013-10-29 06:35:37 <gmaxwell> (obviously you can't count the ones you can't connect to, and there are a large but unknown number of those)
269 2013-10-29 06:35:55 <gmaxwell> (but, you know, since you can't connect to them, they're also less consequential for the network)
270 2013-10-29 06:36:15 <Krellan> Good point.
271 2013-10-29 06:38:22 <dobry-den> that's not very many nodes to dos
272 2013-10-29 06:39:50 <Krellan> Other than blockchain.info, are there other services that attempt to walk the entire p2p network and count all nodes?
273 2013-10-29 06:40:14 <dobry-den> that's actually what i'm working on personally
274 2013-10-29 06:40:38 <Krellan> http://blockchain.info/connected-nodes
275 2013-10-29 06:40:49 <Krellan> cool, would be useful to visualize.
276 2013-10-29 06:58:29 <warren> my bitcoin -testnet is failing to find any peers
277 2013-10-29 06:59:01 <petertodd> warren: hmm... that's bad, testnet-seed.bitcoin.petertodd.org doesn't resolve for me...
278 2013-10-29 06:59:14 <warren> petertodd: blame whoever owns that domain
279 2013-10-29 06:59:28 <petertodd> petertodd: go fix your testnet seed
280 2013-10-29 06:59:31 <petertodd> oh wait...
281 2013-10-29 07:00:39 <warren> hmm, never seen this before
282 2013-10-29 07:00:40 <warren> InvalidChainFound: current best=00000000df41ce12e452e598926692eaac6bf78416d6022d421a98cd769bb92c height=545 log2_work=41.092779 date=2012-05-25 17:13:50
283 2013-10-29 07:00:40 <warren> InvalidChainFound: invalid block=000000002eeb8e439cf935518b3dfdc48f5c36459adc1c6924a6bf9bb57f6ce1 height=20545 log2_work=48.558875 date=2012-08-19 01:06:37
284 2013-10-29 07:00:40 <warren> InvalidChainFound: Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.
285 2013-10-29 07:00:40 <warren> received block 000000002eeb8e439cf935518b3dfdc48f5c36459adc1c6924a6bf9bb57f6ce1
286 2013-10-29 07:00:43 <warren> ProcessBlock: ACCEPTED
287 2013-10-29 07:00:55 <petertodd> on testnet?
288 2013-10-29 07:00:59 <warren> yes
289 2013-10-29 07:01:02 <petertodd> hmm
290 2013-10-29 07:01:29 <warren> what does that mean?
291 2013-10-29 07:01:56 <petertodd> 545 is the checkpoint
292 2013-10-29 07:10:53 <warren> 0.8.5 vanilla has the same invalid chain errors
293 2013-10-29 07:11:06 <warren> does this mean my data is corrupted?
294 2013-10-29 07:12:06 <michagogo> cloud|<warren> Does bitcoind know how to handle multi-homed hosts?
295 2013-10-29 07:12:07 <petertodd> hmm... could be
296 2013-10-29 07:12:35 <michagogo> cloud|I know it does dual-stack tor/ipv4
297 2013-10-29 07:12:35 <warren> reindex seems to have fixed it
298 2013-10-29 07:13:02 <michagogo> cloud|I don't know if it handles multiple ipv4 addresses the same way
299 2013-10-29 07:13:22 <warren> I'm guessing it accepts incoming connections to any
300 2013-10-29 07:13:54 <michagogo> cloud|If your multiple homes are directly internet-reachable, maybe if you add externalip= lines for each of your connections
301 2013-10-29 07:14:01 <petertodd> try this please: dig @testnet-seed-ns2.bitcoin.petertodd.org testnet-seed.bitcoin.petertodd.org
302 2013-10-29 07:14:10 <petertodd> are multiple IP's being returned?
303 2013-10-29 07:14:58 <michagogo> cloud|My conf has externalip=myhiddenservice.onion and discover=1, but I suspect that may not work as well for multihomed
304 2013-10-29 07:15:10 <warren> petertodd: http://pastebin.com/facBPgGw
305 2013-10-29 07:15:23 <michagogo> cloud|Since afaik it doesn't try to discover on each network interface
306 2013-10-29 07:15:23 <petertodd> cool
307 2013-10-29 07:16:07 <warren> michagogo|cloud: https://github.com/bitcoin/bitcoin/pull/3088 review and test this to improve discover=1
308 2013-10-29 07:16:45 <warren> anyone have a heavily used testnet address? I want to test a mixed watchonly and real address wallet.
309 2013-10-29 07:17:19 <warren> http://testnet.mojocoin.com/ someone has been emptying the testnet faucet ...
310 2013-10-29 07:18:36 <jmd> From where can I get some testnet bitcoins ?
311 2013-10-29 07:21:22 <petertodd> also, please try: dig @testnet-seed-ns1.bitcoin.petertodd.org testnet-seed.bitcoin.petertodd.org
312 2013-10-29 07:24:44 <michagogo> cloud|warren: at the moment, I can't really test anything -- my computer is being repaired
313 2013-10-29 07:24:51 <michagogo> cloud|:-/
314 2013-10-29 07:27:16 <michagogo> cloud|(Also, a while back I think there was some bot that drained the faucet [the one that now requires a captcha] -- if you find that address, it should have a lot of traffic)
315 2013-10-29 07:29:34 <jmd> Captchas never work for me.
316 2013-10-29 07:30:38 <jmd> The problem is, that with most browsers, to see the capture image, you invalidate it.
317 2013-10-29 07:36:22 <petertodd> again: could someone please try dig @testnet-seed-ns1.bitcoin.petertodd.org testnet-seed.bitcoin.petertodd.org on your machine
318 2013-10-29 07:36:45 <warren> hmm, that testnet faucet failed to send me coins
319 2013-10-29 07:36:50 <warren> anyone have any testnet coins?
320 2013-10-29 07:37:57 <petertodd> warren: run dig again for me and I'll look. (it's a different NS than last time)
321 2013-10-29 07:39:47 <warren> http://pastebin.com/uX7aFuaH
322 2013-10-29 07:40:41 <petertodd> warren: gah, I'm getting something different - I wonder if my ISP is doing something with DNS?
323 2013-10-29 07:41:04 <petertodd> as for coins, looking through my wallets...
324 2013-10-29 07:41:42 <warren> petertodd: if you find testnet coins, I could use a hundred dust coins
325 2013-10-29 07:42:01 <petertodd> warren: cool, found some, addr to send too?
326 2013-10-29 07:42:50 <warren> petertodd: mmeRfyNguZj52H46buEYUqCiSkxZgyg8u9
327 2013-10-29 07:43:00 <warren> send a ton of dust please
328 2013-10-29 07:43:08 <petertodd> warren: sure, like 0.0001?
329 2013-10-29 07:43:12 <warren> whatever
330 2013-10-29 07:43:16 <petertodd> one sec...
331 2013-10-29 07:43:44 <warren> anyone available to do gitian builds?
332 2013-10-29 07:54:17 <petertodd> warren: waiting on a block to send the dust
333 2013-10-29 07:54:42 <warren> petertodd: odd, I didn't see any zero conf
334 2013-10-29 07:55:11 <warren> 21:54:55
335 2013-10-29 07:55:12 <warren> 
336 2013-10-29 07:55:12 <warren> 21:54:55
337 2013-10-29 07:55:12 <warren> getnetworkhashps
338 2013-10-29 07:55:13 <warren> 5840525364
339 2013-10-29 07:55:25 <petertodd> warren: nah, I screwed up when I transferred it from somewhere else, waiting for the tx to get mined so I can respend it
340 2013-10-29 07:56:17 <warren> It's CONFUSING to have watchonly and real addresses in hte same wallet, but it seems to work.
341 2013-10-29 08:00:42 <jmd> How can I delete an account/address ?
342 2013-10-29 08:03:57 <petertodd> warren: 640e22b5ddee1f6d2d701e37877027221ba5b36027634a2e3c3ee1569b4aa179
343 2013-10-29 08:04:13 <petertodd> 10,000 single satoshi outputs
344 2013-10-29 08:05:00 <petertodd> warren: ha, lol, although because it's > 250k you'll have to mine the block yourself...
345 2013-10-29 08:05:25 <petertodd> I meant to do 1000 and added a zero :(
346 2013-10-29 08:06:40 <petertodd> one sec, lemme mine that...
347 2013-10-29 08:07:09 <warren> petertodd: I have no hashpower at all =)
348 2013-10-29 08:12:22 <petertodd> oh interesting, getblocktemplate returns the wrong difficulty for testnet... (ignores 20 minutes rule)
349 2013-10-29 08:13:05 <michagogo> cloud|petertodd: Huh?
350 2013-10-29 08:13:26 <michagogo> cloud|I haven't found that to be the case.
351 2013-10-29 08:13:51 <jgarzik> petertodd, well... the difficulty hasn't changed after 20 minutes
352 2013-10-29 08:14:01 <jgarzik> petertodd, we just permit an off-difficulty block to be mined
353 2013-10-29 08:14:18 <petertodd> right, well, somehow or another bfgminer needs to know to send diff 1.0 shares then
354 2013-10-29 08:15:28 <petertodd> ah, already known: https://github.com/luke-jr/bfgminer/issues/247
355 2013-10-29 08:18:34 <warren> hmm
356 2013-10-29 08:18:45 <warren> when I build bitcoin-qt with leveldb-1.13 it takes forever for the qt window to pop up
357 2013-10-29 08:18:53 <warren> remove downgrade leveldb and it works fine
358 2013-10-29 08:20:00 <michagogo> cloud|petertodd: actually, that doesn't work
359 2013-10-29 08:20:10 <michagogo> cloud|Because it's the block timestamp that matters
360 2013-10-29 08:20:22 <petertodd> michagogo|cloud: I know, it's been more than 20 minutes too
361 2013-10-29 08:20:29 <michagogo> cloud|There *is* an actual bug, though
362 2013-10-29 08:21:00 <michagogo> cloud|That being that when it hits the 20 minute mark it doesn't go down to diff 1
363 2013-10-29 08:21:18 <petertodd> michagogo|cloud: ? getdifficulty is returning 1 for me
364 2013-10-29 08:22:49 <petertodd> oh, actualy I'm getting the opposite problem: getdifficulty is stuck at 1
365 2013-10-29 08:23:52 <michagogo> cloud|petertodd: that's not "difficulty to mine at"
366 2013-10-29 08:24:00 <petertodd> ?
367 2013-10-29 08:24:01 <michagogo> cloud|That's actually "difficulty of the last block
368 2013-10-29 08:24:03 <michagogo> cloud|"
369 2013-10-29 08:24:13 <petertodd> that's not very useful...
370 2013-10-29 08:24:24 <petertodd> I could swear it used to be difficulty to mine at
371 2013-10-29 08:24:34 <michagogo> cloud|Yeah, I found that out myself a few months ago when I wanted to mine a block to test
372 2013-10-29 08:24:44 <petertodd> odd, I wonder what changed
373 2013-10-29 08:25:01 <michagogo> cloud|petertodd: if you want to see what diff to mine at, you need to gbt and look at target/nbits
374 2013-10-29 08:26:11 <petertodd> huh, go figure, I guess I'm wrong: GetDifficulty() hasn't changed for a year
375 2013-10-29 08:28:41 <petertodd> Well, in any case, testnet4 should include a captcha algorithm, so you can mine a diff 1.0 block by solving a captcha...
376 2013-10-29 08:28:57 <petertodd> heh, or maybe a bitcoin proof-of-sacrifice :/
377 2013-10-29 08:29:01 <michagogo> cloud|petertodd: lol
378 2013-10-29 08:29:16 <petertodd> how the !@#$ is the diff 18.8k!
379 2013-10-29 08:29:27 <michagogo> cloud|petertodd: there's already regtest for that :-P
380 2013-10-29 08:29:35 <petertodd> and why can't we have replace-by-fee to make it trivial to double-spend my mistaken overlarge tx?
381 2013-10-29 08:29:39 <petertodd> gah
382 2013-10-29 08:29:55 <michagogo> cloud|petertodd: some ***hole pointed a ton of hashpower at it
383 2013-10-29 08:30:13 <adam3us> btw i ws thinking in the past (about captcha/proof of work) that it might be possible to create a non-interactive human pow
384 2013-10-29 08:30:25 <petertodd> adam3us: lol, really?
385 2013-10-29 08:31:02 <adam3us> your computer fairly creates a problem that it can see would be hard but cant solve itself without the help of a human coprocessor
386 2013-10-29 08:31:22 <adam3us> and yet a computer can cheaply verify is somethign that only a human could've found
387 2013-10-29 08:31:59 <adam3us> eg something like a fairly chosen (hash of random number) visual shortest path or something computers find hard to do
388 2013-10-29 08:32:31 <adam3us> but because its non-interactive there is no scope for computers to fake them
389 2013-10-29 08:32:53 <adam3us> you could attach them to emails, mine a coin using human brain treadmill etc
390 2013-10-29 08:34:07 <petertodd> right
391 2013-10-29 08:34:31 <petertodd> make a coin out of it and you've got the biggest reward ever to break a captcha...
392 2013-10-29 08:34:56 <petertodd> warren: there's some dust for you
393 2013-10-29 08:35:42 <warren> petertodd: uneconomical!
394 2013-10-29 08:35:59 <petertodd> warren: oh, the single satoshi dust?
395 2013-10-29 08:36:07 <petertodd> warren: lol, you want bigger dust?
396 2013-10-29 08:36:34 <adam3us> yep.. the hard part is to make it secure (captchas are idiotic losing game to 0.01% successful OCR, and most OCR of is 99%) and to make it validatable by a computer .. eg the computer cant find good shortest path but it can measure the human shortest path and be impressed at how short it is
397 2013-10-29 08:37:33 <adam3us> tough to make that usefully secure so I didnt work on it further but its an interesting what if .. reverse hashcash, the human does the proof
398 2013-10-29 08:38:08 <petertodd> adam3us: bitmessage would be an interesting application for sure - they can afford to change algorithms relatively often too
399 2013-10-29 08:38:15 <michagogo> cloud|adam3us: but how can it verify that there isn't a shorter path?
400 2013-10-29 08:38:50 <adam3us> indeed it cant find shortest paths; but maybe it can statistically understand that this is an impressively short path given the scene complexity
401 2013-10-29 08:39:04 <adam3us> eg it can try it self using a shortest path algorithm for a short while and do far worse
402 2013-10-29 08:40:29 <adam3us> anyway humans are very efficient at finding heuristic but not quite optimal shortest paths; its not clear that it is inherently hard - eg the cpus in puny satnavs can find some heuristic shortest path with limited effort given the puny arm cpu or whatever is in them and the need for a < 1min result
403 2013-10-29 08:40:44 <adam3us> an actual optimal shortest path is hard
404 2013-10-29 08:41:41 <adam3us> but then humans arent good at finding them either; i did wonder if it might be possible to construct a randomly generated scene with an algorithmically known shortest path length, without the software generating the scene knowing the path
405 2013-10-29 08:58:22 <sipa> Krellan: the dns seeds also crawl the network
406 2013-10-29 08:58:52 <sipa> warren: really? are you sure it is leveldb 1.13 causing a slowdown and not your disk cache?
407 2013-10-29 08:59:43 <warren> sipa: I was wrong
408 2013-10-29 08:59:52 <warren> sipa: I have notes on watchonly, slight revision
409 2013-10-29 09:00:51 <sipa> warren: i did test #2839; in what way does it not work?
410 2013-10-29 09:01:33 <warren> is that bannode?
411 2013-10-29 09:01:42 <warren> it gets listed in the ban list but doesn't disconnect it
412 2013-10-29 09:02:10 <sipa> weex: you may need to install some extra packages yes
413 2013-10-29 09:03:10 <sipa> BlueMatt: nice! (tx/script valid/invalid)
414 2013-10-29 09:03:52 <petertodd> sipa, BlueMatt: ?
415 2013-10-29 09:07:28 <sipa> warren: huh? fSpendable should be used in coin selection
416 2013-10-29 09:09:15 <warren> sipa: I tried hard to use it, it is available too late
417 2013-10-29 09:09:31 <warren> sipa: perhaps you can think of a better way to integrate it than I came up with
418 2013-10-29 09:09:49 <warren> sipa: https://github.com/litecoin-project/bitcoinomg/commits/bitcoin-omg-0.8
419 2013-10-29 09:09:52 <sipa> warren: greying out unspendable coins would be cool
420 2013-10-29 09:10:14 <warren> sipa: I got some feedback on that and people didn't like it, it would also require a lot more work in Coin Control for no real benefit.
421 2013-10-29 09:11:02 <sipa> ok
422 2013-10-29 09:11:52 <sipa> i do think being able to see coins assigned to watchonly addresses is useful though
423 2013-10-29 09:12:05 <sipa> but you should probably be able to disable it
424 2013-10-29 09:12:09 <warren> is that really the job of coin control?
425 2013-10-29 09:12:56 <sipa> imho the purpose of coin control is breaking the wallet abstraction
426 2013-10-29 09:13:17 <sipa> giving transparency into how bitcoin at a lower level works
427 2013-10-29 09:14:10 <sipa> the intended purpose of coin control (individually managing coins) imho is micromanagement and not that useful as such (or better: if there is a need for that, we need higher-level solutions to deal with that)
428 2013-10-29 09:14:46 <warren> the current design in walletmodel.cpp would need significant refactoring to use fSpendable
429 2013-10-29 09:14:54 <sipa> multiwallet e.g. can do what most people want to do with coin control in an easier way (preventing linkage)
430 2013-10-29 09:15:12 <sipa> really? is it more than passing through the boolean?
431 2013-10-29 09:15:26 <sipa> i have no clue about gui code, but can't imagine it's hard
432 2013-10-29 09:15:49 <warren> I dug through it for hours trying to figure out how to make it use fSpendable
433 2013-10-29 09:16:07 <warren> the simplest code change to make it work was to add a boolean to AvailableCoins() to filter out the watchonly
434 2013-10-29 09:16:35 <warren> sipa: right now we have two well tested and working patches that aren't designed together, let's merge both, then look at refactoring them together.
435 2013-10-29 09:16:48 <warren> Coin Control could be refactored to perform better
436 2013-10-29 09:18:07 <sipa> if it changes performance, it's not a refactor :)
437 2013-10-29 09:18:29 <warren> right .... rewrite
438 2013-10-29 09:18:36 <sipa> warren: does.coin control deal with locked coins?
439 2013-10-29 09:18:40 <warren> sipa: yes
440 2013-10-29 09:18:45 <warren> just not optimally
441 2013-10-29 09:18:49 <warren> the entire thing isn't optimal
442 2013-10-29 09:18:52 <sipa> so expose watxhonly coins as locked in it
443 2013-10-29 09:18:56 <warren> it works very stably though
444 2013-10-29 09:19:12 <warren> sipa: it took forever to get to this point, it works great today, let's improve it after merge?
445 2013-10-29 09:19:40 <sipa> sure
446 2013-10-29 09:20:27 <warren> Coin Control has the most eyeballs right now, let's merge that, then perhaps add my patch to watchonly
447 2013-10-29 09:21:18 <sipa> merging coin co trol is up to wumpus
448 2013-10-29 09:21:37 <sipa> i think i acked the changes to core a long time ago
449 2013-10-29 09:21:56 <warren> the recent changes were polish
450 2013-10-29 09:22:08 <warren> and getting rid of duplicate values that can be derived from elsewhere
451 2013-10-29 09:22:13 <warren> and wrong timezone display
452 2013-10-29 10:04:54 <swulf--> ;;tslb
453 2013-10-29 10:04:58 <gribble> Time since last block: 24 minutes and 35 seconds
454 2013-10-29 10:05:01 <swulf--> geez
455 2013-10-29 10:11:26 <swulf--> maybe all the miners have decided to give up mining
456 2013-10-29 11:19:12 <stonecoldpat> silly question - with the proof of work - the difficulty is the number of zeros that need to be found - and the zeros is part of the ascii string like 000000000000000179df812dd55d61d488b6b1218dc57f02af78c05cddf5321c and not the binary of it?
457 2013-10-29 11:19:32 <TD> no. difficulty is whether the hash when treated as an integer is lower than the target integer
458 2013-10-29 11:20:14 <TD> ACTION -> lunch
459 2013-10-29 11:24:22 <bitnumus> Whats planned for handling the size of the change?
460 2013-10-29 11:24:24 <bitnumus> chain*
461 2013-10-29 11:38:24 <sipa> bitnumus: ?
462 2013-10-29 11:40:06 <sipa> stonecoldpat: the difficulty is the ratio between the maximum target (0x00000000FFFF0000000000...) and the actual target
463 2013-10-29 11:40:22 <sipa> stonecoldpat: and a block's has needs to be below the actual target to be valid
464 2013-10-29 11:44:32 <bitnumus> sipa, i'm looking to run bitcoind on a small device, because the SPV clients aren't yet stable enough
465 2013-10-29 11:44:56 <bitnumus> so just wondering if there are any plans for an 'official SPV' client, or if there are plans in the future to handle the size of the chain a different way
466 2013-10-29 11:44:56 <sipa> what is the contrained resource?
467 2013-10-29 11:45:05 <sipa> yes, block pruning is planned
468 2013-10-29 11:45:12 <bitnumus> flash memory on a small device basically
469 2013-10-29 11:45:12 <sipa> probably not for 0.9 though
470 2013-10-29 11:45:31 <sipa> something like a few hundred MiB storage should suffice
471 2013-10-29 11:45:40 <sipa> (for now)
472 2013-10-29 11:45:42 <bitnumus> <sipa> something like a few hundred MiB storage should suffice < in the future?
473 2013-10-29 11:45:47 <Apocalyptic> bitnumus, these day you can buy a quite decent flash storage device
474 2013-10-29 11:45:49 <sipa> yes, when block pruning is implemented
475 2013-10-29 11:45:57 <bitnumus> that would be great :D
476 2013-10-29 11:46:15 <bitnumus> Apocalyptic, need a 32gb, its not that cheap when you are trying to keep costs down
477 2013-10-29 11:51:28 <stonecoldpat> is that along the right lines?
478 2013-10-29 11:51:28 <stonecoldpat> sipa/td: I'm having a little read about it now - so if the hash was abc, we convert abc to binary (011000010110001001100011) then to an int (6382179) - if the max target was 1,000,000,000 and the current target is 1,000,000 then (max target)1,000,000,000 / (current target)1,000,000 = (difficulty) 1000..... so 1000 is the 'difficulty' and this block is invalid as 6,382,179 > 1,000,000....
479 2013-10-29 11:52:04 <stonecoldpat> I only ask as i've been trying to do a bit of reading about how it all works - and i assumed the difficulty was the number of zeros (and a colleague thought it was the number of zeros in the binary)
480 2013-10-29 11:54:42 <sipa> stonecoldpat: correct
481 2013-10-29 11:54:55 <sipa> except target and max target and hash output are 256 bits
482 2013-10-29 11:55:12 <sipa> so much larger numbers
483 2013-10-29 11:55:45 <sipa> ;;calc 2**256 / (2**48 / 65535)
484 2013-10-29 11:55:48 <gribble> 26959535291011309493156476344723991336010898738574164086137773096960
485 2013-10-29 11:55:56 <sipa> ^ actual max target
486 2013-10-29 11:57:13 <stonecoldpat> awesome, thank you. hoping someday to write a clear guide on how it all works, at the moment its quite hard to figure out how it works (hoping from one page to the next)
487 2013-10-29 13:14:02 <skinnkavaj> Wow Bitcoin Oh My God looks nice
488 2013-10-29 13:14:09 <skinnkavaj> https://bitcointalk.org/index.php?topic=320695
489 2013-10-29 13:16:02 <TD> given the name i was expecting more
490 2013-10-29 13:16:46 <skinnkavaj> TD: I am so scared that one bug or failuare and this bitcoin dead.
491 2013-10-29 13:17:23 <skinnkavaj> As long as development continue bugs will continue to happen
492 2013-10-29 13:17:40 <MC1984_> wow
493 2013-10-29 13:17:42 <MC1984_> such fork
494 2013-10-29 13:17:42 <skinnkavaj> Maybe just FUD, but I am scared
495 2013-10-29 13:17:47 <MC1984_> so open source
496 2013-10-29 13:17:48 <MC1984_> wow
497 2013-10-29 13:18:34 <skinnkavaj> coblee's getnetworkhashps
498 2013-10-29 13:18:35 <skinnkavaj> What is this?
499 2013-10-29 13:18:39 <MC1984_> bitcoin cant simply be forked like a normal OSS project
500 2013-10-29 13:19:03 <MC1984_> its unusual in that each instance isnt really an instance, its an integral part of the whole
501 2013-10-29 13:19:05 <helo> of course it can ;)
502 2013-10-29 13:19:37 <MC1984_> well it can but the potential for unforeseen consequences is high to put it mildly
503 2013-10-29 13:20:24 <helo> bitcoin institutes a weird kind of control over its userbase (the whole world, really)
504 2013-10-29 13:21:02 <MC1984_> control?
505 2013-10-29 13:22:05 <helo> it's this massive behemoth that sustains itself with our greed and enthusiasm
506 2013-10-29 13:24:35 <MC1984_> wut
507 2013-10-29 13:24:46 <MC1984_> bitcoin is not eve online
508 2013-10-29 13:27:20 <kjj> very similar, actually. at least so far
509 2013-10-29 13:27:37 <helo> it's quite a game, definitely
510 2013-10-29 13:27:40 <kjj> in eve, the payment button is labelled "Donate", just like in bitcoin
511 2013-10-29 13:27:50 <Apocalyptic> :)
512 2013-10-29 13:28:17 <kjj> the payment protocol will change that, somewhat
513 2013-10-29 14:41:36 <dobry-den> Is there an official stance on client-level rate-limiting for inbound messages?
514 2013-10-29 14:41:46 <dobry-den> I notice that some messages are rate-limited
515 2013-10-29 15:01:35 <HM2> why would rate limiting inbound messages make sense?
516 2013-10-29 15:01:40 <HM2> replies for sure
517 2013-10-29 15:02:13 <sipa> for relay of spammy transactions, there is rate-limiting
518 2013-10-29 15:02:22 <sipa> that is not rate-limiting the P2P connection itself
519 2013-10-29 15:11:14 <dobry-den> HM2: it's not my domain, but i didn't expect to be able to flood nodes with ping messages
520 2013-10-29 15:11:21 <dobry-den> for example
521 2013-10-29 15:11:35 <dobry-den> i would've expected perhaps a misbehave flag to get thrown at some point
522 2013-10-29 15:12:30 <sipa> we certainly need some resource limitation at some point
523 2013-10-29 15:12:53 <sipa> but measuring cpu/memory/io bandwidth/network bandwidth per peer are not that trivial
524 2013-10-29 15:15:59 <HM2> sipa, you could always fork() for every connection :P
525 2013-10-29 15:16:09 <sipa> eh, no
526 2013-10-29 15:16:18 <sipa> there is a shared data structure
527 2013-10-29 15:19:01 <dobry-den> i'll be doing some robustness checks on the node i'm developing, which i also run against my Satoshi node. so i'll try to advance the discussion when i get there.
528 2013-10-29 15:55:42 <Luke-Jr> petertodd: michagogo|cloud: sorry, I don't think BFGMiner should go out of its way to try to fudge a timestamp and ignore a target just to abuse a testnet-specific rule :p
529 2013-10-29 15:56:10 <michagogo> cloud|Luke-Jr: yeah, I see where you're coming from
530 2013-10-29 15:56:26 <michagogo> cloud|There is, however, a bug relating to the testnet 20 minute rule
531 2013-10-29 15:56:52 <michagogo> cloud|ACTION isn't sure whether he put the details of the bug in the comment he made earlier
532 2013-10-29 15:56:59 <michagogo> cloud|Did I explain it there?
533 2013-10-29 15:57:08 <sipa> no idea; i think it's well known?
534 2013-10-29 15:57:37 <Luke-Jr> michagogo|cloud: templates from bitcoind never expire, so BFGMiner has no reason to request a new one
535 2013-10-29 15:58:01 <michagogo> cloud|Luke-Jr: it does if you give it the command-line parameter to do so
536 2013-10-29 15:58:06 <Luke-Jr> michagogo|cloud: unless you manually set expiry or whatever option it is documented in README under solo mining
537 2013-10-29 15:58:21 <michagogo> cloud|Basically, the bug is this
538 2013-10-29 15:58:26 <Luke-Jr> but it makes better sense to just merge the longpolling PR
539 2013-10-29 15:58:58 <michagogo> cloud|When running with whatever the flag is to expire the work, when it gets a template with regular diff
540 2013-10-29 15:59:20 <michagogo> cloud|And next time it checks, it gets a template with min diff
541 2013-10-29 15:59:30 <michagogo> cloud|It doesn't handle that correctly
542 2013-10-29 15:59:43 <michagogo> cloud|(Or at least it didn't as of 4 months ago)
543 2013-10-29 16:00:00 <sipa> does getblocktemplate have an expiration field?
544 2013-10-29 16:00:37 <michagogo> cloud|There are 2 places in the interface that show diff, and only one of them gets updated, and it keeps using the high value for mining
545 2013-10-29 16:07:05 <Luke-Jr> sipa: it does, but bitcoind shouldn't use it
546 2013-10-29 16:07:17 <sipa> it could, for testnet :)
547 2013-10-29 16:07:46 <Luke-Jr> sipa: but it wouldn't be valid
548 2013-10-29 16:07:59 <Luke-Jr> the block doesn't expire :P
549 2013-10-29 16:08:22 <sipa> after 20 minutes pass, the current work does become invalid
550 2013-10-29 16:08:26 <Luke-Jr> no?
551 2013-10-29 16:08:34 <Luke-Jr> bitcoind would still accept it
552 2013-10-29 16:09:14 <sipa> really?
553 2013-10-29 16:09:23 <Luke-Jr> ye
554 2013-10-29 16:09:58 <sipa> does the nBits in such a block get reset?
555 2013-10-29 16:10:08 <sipa> or just the implicit target
556 2013-10-29 16:10:22 <Luke-Jr> just implicit
557 2013-10-29 16:10:24 <Luke-Jr> I think
558 2013-10-29 16:10:31 <Luke-Jr> either way, it's based on the block timestamp
559 2013-10-29 16:10:51 <sipa> ah right, of course
560 2013-10-29 16:16:36 <michagogo> cloud|"<sipa> after 20 minutes pass, the current work does become invalid" <-- er, what?
561 2013-10-29 16:16:52 <sipa> i was wrong
562 2013-10-29 16:23:02 <EasyAt> Hm, so I did a big nono and sent from the same wallet using 2 different nodes. It appears as if 1 node generated a new keypool. I lost access to the wallet with the new keypool. I had previously lumped all my coins into 1 output which was then sent to the new keypool. Is there something I don't know about to generate this keypool from the older backup?
563 2013-10-29 16:23:50 <tcatm> If you're talking about bitcoin-qt that's not possible.
564 2013-10-29 16:24:10 <EasyAt> I thought so, darn
565 2013-10-29 16:24:54 <tcatm> You might be able to merge both wallets
566 2013-10-29 16:25:15 <EasyAt> I don't have access to the wallet with the new keypool :\
567 2013-10-29 16:25:58 <EasyAt> deterministic wallets can't come faster
568 2013-10-29 16:26:20 <tcatm> Did you sent only a single transaction?
569 2013-10-29 16:26:42 <EasyAt> Maybe 1 or 2
570 2013-10-29 16:26:59 <EasyAt> It was just perfect timeing for the keypool to refill
571 2013-10-29 16:27:17 <tcatm> The keypool must have been much larger than that so your backup should contain the new addresses.
572 2013-10-29 16:27:33 <EasyAt> Oh, I've sent hundreds from that wallet
573 2013-10-29 16:27:48 <EasyAt> But only 1 or 2 between the backups
574 2013-10-29 16:27:55 <sipa> hmm
575 2013-10-29 16:28:19 <sipa> wait, did you send a transaction from one instance, while not having seen a transaction from the other yet?
576 2013-10-29 16:29:19 <EasyAt> No, I started my wallet on a second machine. Did a TX or 2. The second node was up to date on all transactions
577 2013-10-29 16:29:57 <EasyAt> I did a -salvagewallet on a copy of the backup
578 2013-10-29 16:30:04 <EasyAt> Didn't find anything
579 2013-10-29 16:32:30 <EasyAt> Though, I'm not really sure what a -salvage would have found
580 2013-10-29 16:34:58 <EasyAt> I'm curious, why dod the reference client use a new seed when generating the next key pool. Wouldn't it be just as easy to use the seed that generated the first pool?
581 2013-10-29 16:35:05 <EasyAt> s/dod/does
582 2013-10-29 16:37:09 <sipa> EasyAt: there is no "seed"
583 2013-10-29 16:37:18 <sipa> it's just filled with random keys
584 2013-10-29 16:37:28 <EasyAt> Ah
585 2013-10-29 16:37:36 <EasyAt> Okay, ty
586 2013-10-29 16:39:14 <sipa> once deterministic wallets are implemented, you'll have determinism :)
587 2013-10-29 16:50:56 <melvster> when modeling the genesis block, the previousHash is described as 0000... but more accurate would be to say there was no previousBlockHas
588 2013-10-29 16:50:58 <melvster> h
589 2013-10-29 16:51:12 <melvster> is that right?
590 2013-10-29 16:51:18 <sipa> yes
591 2013-10-29 16:51:22 <michagogo> cloud|melvster: corex
592 2013-10-29 16:51:23 <michagogo> cloud|Uh
593 2013-10-29 16:51:27 <michagogo> cloud|Correct*
594 2013-10-29 16:51:30 <melvster> thx
595 2013-10-29 16:52:01 <melvster> i guess there's more than one genesis block, e.g. the test nets
596 2013-10-29 16:52:08 <melvster> but different chains
597 2013-10-29 16:52:28 <melvster> otherwise 0000 would be the parent of all
598 2013-10-29 16:53:01 <melvster> what came before genesis lol, the big bang?
599 2013-10-29 16:54:33 <helo> a big mess :(
600 2013-10-29 16:54:36 <lianj> the assumption that sha256(sha256(block_header) will hopefully never return 0x0*34
601 2013-10-29 16:54:40 <lianj> *32
602 2013-10-29 16:55:01 <melvster> or any other hash
603 2013-10-29 16:55:11 <melvster> then you'd get one big circle
604 2013-10-29 16:55:19 <melvster> maybe even a longest chain ...
605 2013-10-29 16:55:39 <sipa> blocks still have their height inside
606 2013-10-29 16:55:48 <sipa> so a loop wouldn't be valid
607 2013-10-29 16:55:52 <sipa> even if the hashes match
608 2013-10-29 16:55:58 <melvster> only version 2 blocks right?
609 2013-10-29 16:55:58 <sipa> though i think many other things would break
610 2013-10-29 16:56:01 <sipa> indeed
611 2013-10-29 16:56:37 <MC1984_> genesis block was handmade right
612 2013-10-29 16:56:47 <melvster> yes
613 2013-10-29 16:56:48 <MC1984_> not mined
614 2013-10-29 16:56:54 <melvster> ummm
615 2013-10-29 16:56:57 <melvster> mined too?
616 2013-10-29 16:57:00 <lianj> ofc
617 2013-10-29 16:57:05 <jakov> it was mined in the sense that a computer found the right nonce
618 2013-10-29 16:57:21 <MC1984_> but there was no previous hash
619 2013-10-29 16:57:30 <michagogo> cloud|MC1984_: right
620 2013-10-29 16:57:40 <michagogo> cloud|It's hard coded into the source code
621 2013-10-29 16:57:41 <melvster> Computed hash OK
622 2013-10-29 16:57:42 <melvster> 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
623 2013-10-29 16:57:42 <melvster> 0000001d00ff0000000000000000000000000000000000000000000000000000
624 2013-10-29 16:57:42 <melvster> Checking Target is Bigger than computed hash OK
625 2013-10-29 16:57:51 <melvster> you'll see the hash has a ton of 0's
626 2013-10-29 16:57:56 <melvster> more than needed for the target
627 2013-10-29 16:58:23 <melvster> my guess is that satoshi started it on new year and left it running 3 days for jan 3 release
628 2013-10-29 16:58:25 <sipa> the mainnet genesis is actually PoW-valid
629 2013-10-29 16:58:37 <michagogo> cloud|Note that the number of hashes doesn't actually matter
630 2013-10-29 16:58:48 <michagogo> cloud|Um, the number of zeroes
631 2013-10-29 16:58:52 <melvster> like in 3 days is all souls day when the bitcoin paper will be 5 years old ... most mathematicians are strangely superstitious
632 2013-10-29 16:59:24 <MC1984_> because numbers do some creepy things
633 2013-10-29 16:59:34 <michagogo> cloud|What matters is integer comparison: the block hash must <= the target
634 2013-10-29 16:59:41 <melvster> but its very rare to see 4 zeros more than the target
635 2013-10-29 17:00:02 <sipa> melvster: in hex?
636 2013-10-29 17:00:06 <melvster> yes
637 2013-10-29 17:00:20 <sipa> every 65k blocks :)
638 2013-10-29 17:02:07 <TD> sipa: bitcoind always prints the hash of any tx it rejects, right
639 2013-10-29 17:02:21 <melvster> i think satoshi wanted to give it a good mine for the first one ... of course the whole nbits to difficulty calculation could have been cusomizable you subtract 3 from the leading 2 hex digits it could have been hard coded to 5 at some point
640 2013-10-29 17:03:03 <lianj> melvster: no, irrelevant
641 2013-10-29 17:03:28 <melvster> i mean to calculate difficulty 1
642 2013-10-29 17:03:56 <melvster> in any case the hash in the genesis block is abnormally hard
643 2013-10-29 17:04:27 <lianj> irrelevant for the chain that followed and just luck
644 2013-10-29 17:05:17 <petertodd> lianj: the timestamps between genesis and the next block vary by a week; chances are satoshi wanted to do last minute checks and just left his miner running
645 2013-10-29 17:05:17 <skinnkavaj> https://bitcointalk.org/index.php?topic=320634.msg3434765;boardseen#new
646 2013-10-29 17:06:22 <petertodd> lianj: I did the math once and the difficulty was about what you'd expect if he had enough hashing power to mine at diff 1 and did exactly that
647 2013-10-29 17:10:58 <lianj> petertodd: ah :)