1 2014-05-11 02:30:00 <Gerendon> Looking for a proficient PHP coder for developing the back-end of a site interface. PM for more details.
2 2014-05-11 02:30:46 <teward> try craigslist
3 2014-05-11 02:30:57 <teward> or a job hunting site
4 2014-05-11 02:31:00 <Gerendon> It's bitcoin related
5 2014-05-11 02:31:24 <Gerendon> I'd rather find help here, I try not to be annoying but just list that here incase anyone is interested
6 2014-05-11 02:33:52 <Luke-Jr> Gerendon: does it help accomplish your goals if you get banned here for not following the rules?
7 2014-05-11 02:34:15 <Luke-Jr> if not, please be respectful of them
8 2014-05-11 02:34:45 <Gerendon> Luke-Jr I was told earlier this was allowed as long it's never spammed and I am respectful. I apologize to you then
9 2014-05-11 02:38:38 <justanotheruser> Gerendon: #bitcoin-otc
10 2014-05-11 02:40:16 <Gerendon> justanotheruser: thanks
11 2014-05-11 02:40:59 <akstunt600> Hey, im having a p2pool issue here and #p2pool is dead right now
12 2014-05-11 02:41:35 <akstunt600> I am no noob to p2pool, and have been mining on it for over a year
13 2014-05-11 02:41:45 <akstunt600> I have my own public pool http://liberty-miners.com
14 2014-05-11 02:42:11 <akstunt600> I made an identical pool for a friend of mine on EC2 AWS and it nothing but work restarts
15 2014-05-11 02:42:27 <akstunt600> Where my pool runs perfectly with many acceted shares
16 2014-05-11 02:42:41 <akstunt600> Both are same versions of p2pool and wallets daemons
17 2014-05-11 02:43:06 <akstunt600> My server is hosted at home however and is out performing the large ec2 instance with ease
18 2014-05-11 02:43:09 <akstunt600> What gives?
19 2014-05-11 02:44:56 <akstunt600> other instance on ec2 here http://54.85.60.102:9555/static/
20 2014-05-11 03:24:20 <owowo> !roulette
21 2014-05-11 03:24:21 <gribble> ACTION reloads and spins the chambers.
22 2014-05-11 03:24:43 <robonerd> !pingpong
23 2014-05-11 03:24:44 <gribble> Error: "pingpong" is not a valid command.
24 2014-05-11 03:24:49 <robonerd> hm
25 2014-05-11 03:31:12 <akstunt600> !roulette
26 2014-05-11 03:31:13 <gribble> ACTION reloads and spins the chambers.
27 2014-05-11 03:31:38 <akstunt600> hey that isnt how roulette is supposed to be coded
28 2014-05-11 03:31:48 <akstunt600> WTF, and no p2pool help
29 2014-05-11 03:31:51 <akstunt600> thanks guys
30 2014-05-11 03:32:52 <akstunt600> this pool has the same problems with the btc node btw
31 2014-05-11 03:33:01 <survic> akstunt600: it's not really the right channel for roulette or p2pool.
32 2014-05-11 03:33:17 <akstunt600> I know, those channels are dead and its quiet in here
33 2014-05-11 03:33:25 <akstunt600> So, i dont see the issue
34 2014-05-11 03:33:44 <akstunt600> Its as simple question are there issues running p2pool on ec2.
35 2014-05-11 03:34:13 <akstunt600> I know that many complain about iops on ec2... could that be my issue?
36 2014-05-11 03:34:39 <akstunt600> I have btc and 9 other nodes running on the instance
37 2014-05-11 03:34:50 <akstunt600> All had p2pool running
38 2014-05-11 03:35:08 <akstunt600> i reduced it to just btc ltc and doge and issues still persist
39 2014-05-11 03:35:29 <akstunt600> Has anyone has performance issues with btc nodes on ec2?
40 2014-05-11 03:36:06 <teward> it's an ec2, it's not built for BTC nodes.
41 2014-05-11 03:36:16 <akstunt600> Thanks, i figured
42 2014-05-11 03:36:26 <teward> you're always gonna see performance issues with EC2s on pretty much anything large like BTC nodes, IMO.
43 2014-05-11 03:40:31 <akstunt600> thanks a lot teward. I really appreciate it. Thats the only conclusion i was able to come up with
44 2014-05-11 03:41:08 <akstunt600> Ofc the ubuntu instance reports its running quickly im now going to bench it and see just how bad
45 2014-05-11 03:41:33 <akstunt600> Ughh what a pain. Im starting to think they are pretty over sunbscribed
46 2014-05-11 03:42:03 <survic> ec2 is pretty overpriced for what it is
47 2014-05-11 03:43:05 <akstunt600> Yeah, i always thought it was decently priced. Not any more. Digital ocean here i come. :-)
48 2014-05-11 03:43:17 <akstunt600> Thanks for your help too survic
49 2014-05-11 03:43:31 <survic> sorry I couldn't be more of it. best of luck.
50 2014-05-11 03:51:12 <akstunt600> I think you guys are spot on. iotop confirms
51 2014-05-11 03:51:17 <akstunt600> thanks
52 2014-05-11 03:57:00 <flound1129> akstunt600: you could try instance storage. It's supposed to be a little faster than the persistent storage
53 2014-05-11 03:57:11 <flound1129> only problem is, if the machine ever stops, it goes away
54 2014-05-11 03:58:00 <flound1129> but yeah DO is way better
55 2014-05-11 03:58:01 <flound1129> imo
56 2014-05-11 03:58:06 <flound1129> ssd ftw
57 2014-05-11 04:36:55 <akstunt600> thnks flound1129
58 2014-05-11 04:37:20 <akstunt600> I will give that a try before i decide to move over to digital ocean
59 2014-05-11 07:15:04 <michagogo> cloud|10:21:55 <gmaxwell> since when was 300000 a bitcoin interesting number of blocks? wake me at 420,000 <-- or 314159
60 2014-05-11 07:19:41 <ganjafarmer> question about debug.log. where it says log2_work=75.802945, does that number refer to the total expected number of hashes in the whole chain?
61 2014-05-11 07:25:57 <sipa> indeed
62 2014-05-11 07:28:52 <ganjafarmer> thanks
63 2014-05-11 07:31:42 <gribble> 65911349649659469496320
64 2014-05-11 07:31:42 <sipa> ;;calc 2**75.802945
65 2014-05-11 07:34:16 <ganjafarmer> that was 20,000 blocks ago too. im still syncing up.
66 2014-05-11 07:47:18 <michagogo> cloud|66 sextillion hashes? Wow.
67 2014-05-11 07:48:11 <michagogo> cloud|What's the equivalent difficulty?
68 2014-05-11 07:50:43 <sipa> no such thing
69 2014-05-11 07:51:04 <sipa> difficulty ~ hashes per second
70 2014-05-11 07:51:12 <sipa> work ~ hashes
71 2014-05-11 07:51:22 <CodeShark> difficulty is a normalized reciprocal
72 2014-05-11 07:51:31 <CodeShark> so there is a corresponding difficulty
73 2014-05-11 07:51:38 <sipa> eh no
74 2014-05-11 07:51:43 <sipa> it's the wrong unit
75 2014-05-11 07:52:22 <sipa> it's like asking how muvh water you can boil with 100W
76 2014-05-11 07:52:30 <CodeShark> or rather, difficulty only considers the expected number of hashes for a particular block
77 2014-05-11 07:52:34 <CodeShark> not the total for the entire chain
78 2014-05-11 07:52:47 <sipa> oh, per block
79 2014-05-11 07:53:05 <sipa> well, that doesn't make much sense, but you could calculate that
80 2014-05-11 07:54:12 <gribble> 6612850462695141376
81 2014-05-11 07:54:12 <sipa> ;;calc 2**78.52 * 65535 / 2**32
82 2014-05-11 07:54:46 <sipa> ^ what the difficulty would have to be to have the same amount of work as the entire chain in one block
83 2014-05-11 07:55:20 <sipa> ;;diff
84 2014-05-11 07:55:21 <gribble> 8.0008721359681635E9
85 2014-05-11 07:55:52 <gribble> Error: unexpected EOF while parsing (<string>, line 1)
86 2014-05-11 07:55:52 <sipa> ;;calc 2**78.52 * 65535 / 2**32 / [diff]
87 2014-05-11 07:56:02 <CodeShark> it would be more useful if we consider the difficulty of replacing the last n blocks
88 2014-05-11 07:56:34 <sipa> http://bitcoin.sipa.be/powdays-50k.png
89 2014-05-11 07:56:43 <sipa> that's a related notion
90 2014-05-11 07:57:12 <sipa> how much hashing at the current network speed it would need to do the same amount of work as the entire chain
91 2014-05-11 07:58:57 <CodeShark> when it drops presumably it's because a large amount of hashing power joins the network
92 2014-05-11 07:59:03 <CodeShark> suddenly
93 2014-05-11 07:59:38 <CodeShark> then if the hash rate remains constant, the graph slowly rises
94 2014-05-11 07:59:49 <CodeShark> linearly
95 2014-05-11 08:01:42 <CodeShark> the drop in that graph seems to be around the point of inflection of this graph: https://blockchain.info/charts/hash-rate?showDataPoints=false&show_header=true&daysAverageString=1×pan=&scale=1&address=
96 2014-05-11 08:02:09 <CodeShark> it's accelerating up until about november, then it decelerates
97 2014-05-11 08:02:21 <sipa> oh, that's just an artefact of using the maximum hashrate observed in a window
98 2014-05-11 08:02:30 <sipa> it's too variable otherwise
99 2014-05-11 08:04:08 <CodeShark> variable because of people joining and leaving? or because of the inherent variance and the fact we cannot really measure hashrate?
100 2014-05-11 08:04:14 <sipa> and do you really have tomrefer to b.i? :p
101 2014-05-11 08:04:29 <sipa> bitcoin.sipa.be has more accurate graphs :)
102 2014-05-11 08:04:55 <CodeShark> sorry - just did a quick search :p
103 2014-05-11 08:05:03 <CodeShark> you need to do some more search engine optimization
104 2014-05-11 08:05:20 <sipa> haha
105 2014-05-11 08:07:22 <CodeShark> anyhow, the dip is clearly the china incident :p
106 2014-05-11 08:11:48 <CodeShark> sipa, are you presenting anything at bitcoin 2014?
107 2014-05-11 08:11:52 <michagogo> cloud|sipa: right, let me rephrase -- what difficulty single block would 66 sextillion hashes be expected to produce?
108 2014-05-11 08:12:58 <CodeShark> michagogo|cloud: you mean, what's the expected value of the smallest hash if you were to do 66 sextillion hashes?
109 2014-05-11 08:13:09 <michagogo> cloud|I think so.
110 2014-05-11 08:16:07 <CodeShark> if N is the size of the space (2^256), the probability of getting a hash value larger than n for a single hash is (N-n)/N, right?
111 2014-05-11 08:16:53 <CodeShark> so the probability of not getting a hash smaller than n for k hashes is [(N-n)/N]^k
112 2014-05-11 08:17:19 <CodeShark> the probability of the smallest hash being n is therefore the complement
113 2014-05-11 08:17:28 <CodeShark> 1 - [(N-n)/N]^k
114 2014-05-11 08:18:23 <CodeShark> so sum [n: 0..N] n {1 - [(N-n)/N]^k}
115 2014-05-11 08:20:00 <CodeShark> or no, sorry :p
116 2014-05-11 08:20:36 <sipa> CodeShark: i'll be there, but not presenting
117 2014-05-11 08:20:54 <sipa> CodeShark: no, that's not the same thing
118 2014-05-11 08:21:15 <sipa> oh, wait
119 2014-05-11 08:21:30 <CodeShark> 1 - [(N-n)/N]^k is the probability of getting at least one hash smaller than n
120 2014-05-11 08:21:40 <CodeShark> out of k hashes
121 2014-05-11 08:23:14 <CodeShark> but we're actually after the probability of n being the smallest hash
122 2014-05-11 08:23:32 <CodeShark> or n-1, if you will
123 2014-05-11 08:23:48 <sipa> you're making it way too hard
124 2014-05-11 08:24:05 <sipa> work is defined as 2^256 / target
125 2014-05-11 08:24:28 <sipa> so you're expected to beat a target of 2^256 / 66 sextillion
126 2014-05-11 08:24:55 <CodeShark> oh, right :p
127 2014-05-11 08:24:58 <gribble> 1005712034946874112
128 2014-05-11 08:24:58 <sipa> ;;calc 2**75.802945 * 65535 / 2**32
129 2014-05-11 08:25:11 <sipa> ^- that difficulty corresponds to 66 sextillion
130 2014-05-11 08:25:19 <sipa> (though the total work now is already higher)
131 2014-05-11 09:07:04 <ganjafarmer> is there some way i can speed up my build process? i make a small change to main.cpp then run 'make' and it spends minutes re-building multiple objects.
132 2014-05-11 09:09:02 <sipa> not really, modularizing the source code is a slow but ongoing process
133 2014-05-11 09:09:48 <CodeShark> advice: do most of your work in separate source files and only add minimal hooks in files like main.h or main.cpp
134 2014-05-11 09:10:18 <CodeShark> editing main.h in particular is especially costly
135 2014-05-11 09:10:39 <benten> ganjafarmer: you could try to run your compiler on a faster machine it might cut down a bit.
136 2014-05-11 09:11:14 <ganjafarmer> is it normal that 'make' recompiles ALL objects even when i only touch main.cpp?
137 2014-05-11 09:11:27 <CodeShark> no
138 2014-05-11 09:11:27 <sipa> if you only touch main.cpp: no
139 2014-05-11 09:11:32 <sipa> if you touch main.h: yes
140 2014-05-11 09:11:38 <sipa> (not all, but many)
141 2014-05-11 09:12:09 <CodeShark> most of the stuff in main.h/main.cpp shouldn't be there and what should be there isn't :p
142 2014-05-11 09:12:15 <CodeShark> namely, int main
143 2014-05-11 09:12:25 <sipa> nobody disagrees about that
144 2014-05-11 09:13:23 <CodeShark> unfortunately, satoshi cultivated a style which largely consists of adding externs to main.h whenever you need a new global state variable
145 2014-05-11 09:14:13 <CodeShark> just moving these externs into separate source files would already go some ways in reducing the problem
146 2014-05-11 09:14:13 <sipa> he should have used a style that properly encapsulated things, and didn't need global variables in the first place
147 2014-05-11 09:14:46 <ganjafarmer> benten: unfortunately i'm building in a really slow vm :(
148 2014-05-11 09:15:09 <CodeShark> just saying, if you're going to use global variables, keep them in short source files that are easily compiled and linked against :p
149 2014-05-11 09:15:46 <CodeShark> don't stick them in the same source files that contain most of your core functionality
150 2014-05-11 09:16:31 <CodeShark> preferably as members of some singleton object
151 2014-05-11 09:17:24 <CodeShark> anyhow, I developed a defensive strategy against this when tweaking bitcoind after suffering much
152 2014-05-11 09:17:45 <CodeShark> it is based on avoiding touching main.h and main.cpp as much as possible :p
153 2014-05-11 09:18:28 <CodeShark> not only will it dramatically speed up your build times - it will make merging much simpler as well
154 2014-05-11 09:20:05 <CodeShark> a little bit of effort early on in creating a new source file and adding the includes will save you a bunch of agony as a result of being lazy and figuring everything already includes main.h anyhow
155 2014-05-11 11:32:11 <donvino> jg
156 2014-05-11 11:35:00 <jgarzik> donvino, ?
157 2014-05-11 11:35:56 <donvino> sorry. irc client messing with me
158 2014-05-11 13:34:24 <fastforward> Hi
159 2014-05-11 13:35:09 <fastforward> i'd appreciate some help please.
160 2014-05-11 13:35:25 <sipa> that's really hard without knowing what your problem is
161 2014-05-11 13:37:04 <fastforward> as i am not a developer, i am looking for a easy-way to setup a "automatic" transaction from Bitcoin-QT (bitcoind) wallet to another address. like a batchfile checking transactions on my wallet and "forward" to another wallet
162 2014-05-11 13:37:45 <fastforward> looking for quite some hours now, found many answers but i cannot "write" that myself
163 2014-05-11 13:39:20 <fastforward> can anyone help me pls with that or point me to a link, explaining in detail what to do?
164 2014-05-11 13:43:29 <fastforward> ...am i on the right channel for this? =) and how much of a btc bounty/reward would be needed to get this done?
165 2014-05-11 13:45:19 <fastforward> uhm.... okay :/ thanks.
166 2014-05-11 13:46:09 <shesek> fastforward, why do you need to forward transactions?
167 2014-05-11 13:46:14 <shesek> oh. he left.
168 2014-05-11 13:46:22 <jcorgan> off-topic anyway
169 2014-05-11 14:34:39 <michagogo> cloud|...fairly simple, though...
170 2014-05-11 14:36:46 <michagogo> cloud|Just a matter of a quick script that uses RPC and gets either balance or unspent outputs, and then creates a transaction to the other wallet
171 2014-05-11 14:37:50 <michagogo> cloud|(The real question is, why does he think he wants that)
172 2014-05-11 16:03:54 <lmf> where can I find bitcoin 0.8.99
173 2014-05-11 16:04:02 <lmf> the source code
174 2014-05-11 16:20:30 <survic> lmf: there is no 0.8.99, the ".99" just denotes that's non-release (from master)
175 2014-05-11 16:21:04 <lmf> survic: I am a bit confugsed with the seed node thing
176 2014-05-11 16:21:21 <lmf> I don't understand what few lines do, can you explain?
177 2014-05-11 16:21:43 <lmf> vSeeds.push_back
178 2014-05-11 16:21:59 <survic> lmf: possibly, if not me somebody else is sure to chime in later. best to link to the line on github.
179 2014-05-11 16:22:00 <lmf> chainparams.cpp line 143
180 2014-05-11 16:22:59 <lmf> https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L143
181 2014-05-11 16:23:31 <survic> those lines just definte the DNS seeds, special DNS servers which return valid bitcoin nodes in response.
182 2014-05-11 16:24:33 <lmf> ok so making an analogy, it is like the the trackers for torrents? that keep the addresses of all active nodes in the p2p network?
183 2014-05-11 16:25:41 <survic> not quite, they aren't needed unless the node connecting to them can't find anybody else to talk to. usually a node uses it's own database of addresses gained from asking other peers who they know about. the DNS seeds are a fallback position for a new node, or one that has just lost it's way.
184 2014-05-11 16:26:30 <lmf> and there are so many of them defined in case one of them fails?
185 2014-05-11 16:26:38 <survic> just above on line 21 is pnSeed[], IPv4 addresses of stable known nodes. this is a fallback for when the node knows no peers, and can't find anything useful from the defined DNS nodes.
186 2014-05-11 16:27:13 <survic> yes, the multiple nodes are just redundant. even if only one DNS seed returns one valid result, that's enough to bootstrap to the network and not need the seeds anymore.
187 2014-05-11 16:28:15 <lmf> so does lets say a different coin than bitcoin use different seed nodes?
188 2014-05-11 16:28:53 <lmf> like litecoin
189 2014-05-11 16:29:15 <survic> it must, otherwise it will just get useless results. bitcoin seed nodes only return data about bitcoin peers. I assume litecoin has it's own, though I haven't looked.
190 2014-05-11 16:30:46 <survic> yes, they have their own defined nodes, just not in the same location and Litecoin hasn't kept up with the upstream Bitcoin.
191 2014-05-11 16:30:53 <lmf> where can I find the source code for seed nodes, and can I potentially set one up and commit a change to the source code
192 2014-05-11 16:31:20 <survic> altcoin development is off topic for this channel.
193 2014-05-11 16:31:21 <sipa> you mean the static seed IPs, or the DNS seeds?
194 2014-05-11 16:31:27 <lmf> like vSeeds.push_back(CDNSSeedData("129.xxx.x.x.x", "129.xxx.x.x.x"));
195 2014-05-11 16:31:45 <sipa> some are just static DNS entries
196 2014-05-11 16:32:00 <lmf> yeah but they run a seed node server right?
197 2014-05-11 16:32:13 <sipa> no, those are just DNS entries
198 2014-05-11 16:32:25 <sipa> pointing to valid bitcoin node IPs
199 2014-05-11 16:32:42 <sipa> you can run special DNS software to automatically refresh what they point to
200 2014-05-11 16:32:48 <sipa> some dns seeds run that, but not all
201 2014-05-11 16:33:10 <lmf> ok so these DNS servers point at different IP every time I would ping them?
202 2014-05-11 16:33:15 <sipa> maybe
203 2014-05-11 16:33:16 <lmf> which is the IP of a valid node?
204 2014-05-11 16:33:26 <sipa> ?
205 2014-05-11 16:33:37 <sipa> you don't ping a DNS server, you do a lookup
206 2014-05-11 16:33:37 <survic> sipa: just a funny side note, Google has picked up on your seed node and now indexes websites that have a webserver and bitcoin daemon on the same IP address. you've a heap of weird stuff on your subdomains.
207 2014-05-11 16:33:46 <survic> ;; QUESTION SECTION
208 2014-05-11 16:33:48 <gribble> Error: "QUESTION" is not a valid command.
209 2014-05-11 16:33:49 <survic> ;seed.bitcoin.sipa.be. IN A
210 2014-05-11 16:33:51 <gribble> Error: "ANSWER" is not a valid command.
211 2014-05-11 16:33:51 <survic> ;; ANSWER SECTION:
212 2014-05-11 16:33:54 <survic> seed.bitcoin.sipa.be. 59 IN A 75.73.191.108
213 2014-05-11 16:34:07 <survic> crap. that didn't work how I intended.
214 2014-05-11 16:34:33 <survic> lmf: just 'dig seed.bitcoin.sipa.be' and you'll see how it's meant to look.
215 2014-05-11 16:34:40 <lmf> I see
216 2014-05-11 16:35:20 <lmf> these nodes in the network are active wallets or miners?
217 2014-05-11 16:35:27 <lmf> what is the difference between the two?
218 2014-05-11 16:35:39 <survic> there is no difference.
219 2014-05-11 16:35:56 <sipa> nodes are not wallets
220 2014-05-11 16:35:58 <survic> nodes are not wallets, nodes might be miners.
221 2014-05-11 16:36:03 <sipa> the reference client can function as both though
222 2014-05-11 16:36:26 <lmf> so wallets now, only read the block chain right?
223 2014-05-11 16:36:34 <lmf> what else could a node be?
224 2014-05-11 16:36:41 <sipa> a node is simply a node in the network
225 2014-05-11 16:36:55 <sipa> any entity using the p2p network to connect to other nodes
226 2014-05-11 16:37:01 <lmf> well how does someone join the network and become a node
227 2014-05-11 16:37:07 <lmf> for example, mining
228 2014-05-11 16:37:09 <survic> sipa: actually, one of the results for the seed subdomain of yours is a coin-stealing wallet :)
229 2014-05-11 16:37:21 <sipa> lmf: by running software that implements it
230 2014-05-11 16:37:35 <sipa> the reference client is one
231 2014-05-11 16:37:47 <lmf> sipa what other software do?
232 2014-05-11 16:37:48 <sipa> but there are lightweight wallets too that are not fully validating nodes
233 2014-05-11 16:37:58 <lmf> I see
234 2014-05-11 16:38:01 <sipa> or crawlers like the ones run by dns seeds are nodes too
235 2014-05-11 16:38:22 <lmf> so are miners nodes too?
236 2014-05-11 16:38:34 <sipa> miners need a full node to build blocks
237 2014-05-11 16:38:40 <survic> there's no distinction between a "miner" and a "node" really.
238 2014-05-11 16:38:47 <sipa> if you're talking about pool mining, it's the pool that runs the node
239 2014-05-11 16:38:54 <sipa> and the miner only hashes
240 2014-05-11 16:40:31 <lmf> sipa, assuming there are no DNS seed nodes, how would a node find other nodes
241 2014-05-11 16:40:42 <lmf> and no pnSeed
242 2014-05-11 16:40:53 <survic> lmf: like I said, it uses the hardcoded nodes just above the line you mentioned.
243 2014-05-11 16:41:04 <survic> if those fail, the node is isolated.
244 2014-05-11 16:41:19 <lmf> survic: the hardcoded nodes you mean pnSeed?
245 2014-05-11 16:41:37 <survic> yes
246 2014-05-11 16:42:08 <survic> if all three discovery mechanisms fail, there's no way of it finding peers.
247 2014-05-11 16:42:34 <lmf> survic: so the network is not fully decentralized right?
248 2014-05-11 16:42:39 <sipa> lmf: 1) by getting nodes specified through -addnode 2) by being told about them by other nodes 3) by reading them from its peer database 4) as a fallback, by using the ones in pnSeed
249 2014-05-11 16:42:55 <sipa> initial peer discovery can never be fully decentralized
250 2014-05-11 16:43:11 <survic> lmf: how else do you imagine it's going to work? short of crawling the whole IPv4 space to find peers.
251 2014-05-11 16:43:25 <sipa> don't forget about the IPv6 space!
252 2014-05-11 16:43:32 <sipa> and the Tor address space!
253 2014-05-11 16:43:40 <lmf> survic: That is what I thought, but many
254 2014-05-11 16:43:46 <survic> I'm not sure people would like it if we made IPv4/v6 scanners flooding the internet
255 2014-05-11 16:44:03 <lmf> Agree
256 2014-05-11 16:44:27 <survic> if you really want manual discovery, you just ask someone on IRC for a single node address to get you bootstrapped. past that point you rely on nobody else.
257 2014-05-11 16:46:17 <lmf> sipa: I found this https://github.com/sipa/bitcoin-seeder
258 2014-05-11 16:46:21 <lmf> is this a bitcoin seeder?
259 2014-05-11 16:46:31 <lmf> like a DNS server
260 2014-05-11 16:46:36 <sipa> that's a crawler + dns server, yes
261 2014-05-11 16:46:40 <sipa> the one i run
262 2014-05-11 16:48:07 <lmf> so if I was to run this on my computer and add my IP to the list of nodes in the bitcoin source code
263 2014-05-11 16:48:26 <lmf> I would actually help discover nodes?
264 2014-05-11 16:48:36 <sipa> yes
265 2014-05-11 16:48:54 <gmaxwell> Every node helps discover nodes.
266 2014-05-11 16:49:59 <lmf> sipa but what if this node, crawler was the first node. In that case where would it start crawling from
267 2014-05-11 16:50:49 <sipa> well it needs a starting point
268 2014-05-11 16:50:56 <iomn2l> gmaxwell is a dick
269 2014-05-11 16:51:08 <sipa> bitcoin-seeder just has other seeders hardcoded to find one
270 2014-05-11 16:51:24 <sipa> but that's not a problem: nodes themselves keep a database of known peers
271 2014-05-11 16:51:40 <sipa> the network itself manages that; all you need is an entry point
272 2014-05-11 16:51:50 <sipa> crawlers just speed things up a bit
273 2014-05-11 17:18:11 <Emzy> It is always talked about that you can't block bitcoin... But as I read hier: https://en.bitcoin.it/wiki/Network "Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. "
274 2014-05-11 17:18:51 <Emzy> It seems that china can block bitcoin like they block Tor. By simply block all IP-Adresses that are nodes.
275 2014-05-11 17:19:04 <Luke-Jr> Emzy: blocking bitcoin would be very trivial, at least today.
276 2014-05-11 17:19:12 <survic> Emzy: yes, on a clearnet view Bitcoin is trivial to block. just kill connections to port 8333 and you're done.
277 2014-05-11 17:19:34 <survic> do note that China struggles to block Tor.
278 2014-05-11 17:19:46 <andytoshi> ..and that you can run bitcoin over tor
279 2014-05-11 17:19:46 <Emzy> ok, so it has to go the same path as Tor...
280 2014-05-11 17:19:53 <Emzy> or just use tor
281 2014-05-11 17:20:05 <Luke-Jr> the latter
282 2014-05-11 17:20:13 <Emzy> survic: but with secred tor nodes.
283 2014-05-11 17:20:19 <Emzy> secret
284 2014-05-11 17:20:23 <Luke-Jr> Bitcoin does not aim to be unblockable.
285 2014-05-11 17:20:28 <Luke-Jr> that's a goal of the tor project
286 2014-05-11 17:20:53 <Luke-Jr> no reason to reinvent the wheel
287 2014-05-11 17:21:07 <survic> Emzy: the firewall of China is not really as bad as people say. VPN and Tor use in China is pretty universal. when you buy a PC in a store in china you select what evasion service you want to use.
288 2014-05-11 17:21:14 <Luke-Jr> especially since Bitcoin only functions in a non-hostile environment in any case
289 2014-05-11 17:21:24 <Luke-Jr> survic: lol!
290 2014-05-11 17:21:47 <Emzy> Luke-Jr: but it is often over simlifyed that you can't block bitcoin
291 2014-05-11 17:21:53 <Emcy_> no one ever worries that too much important stuff is reliant on tor?
292 2014-05-11 17:22:13 <survic> what relies on Tor?
293 2014-05-11 17:22:31 <sipa> it would be better if more important stuff relied on Tor!
294 2014-05-11 17:22:38 <sipa> that meant that blocking it would be harder
295 2014-05-11 17:22:41 <Luke-Jr> Emzy: to claim you can't block bitcoin is an outright lie IMO
296 2014-05-11 17:23:05 <Luke-Jr> Emzy: even if you couldn't block Bitcoin technically, you could easily block it socially
297 2014-05-11 17:23:06 <Emzy> ok
298 2014-05-11 17:23:11 <Emcy_> never claimed that?
299 2014-05-11 17:23:23 <Luke-Jr> also, Emcy_ and Emzy are confusing.
300 2014-05-11 17:23:24 <Emcy_> oh its that guy
301 2014-05-11 17:23:24 <Emzy> hi Emcy_ :)
302 2014-05-11 17:23:29 <Emcy_> lol
303 2014-05-11 17:23:36 <survic> oh wow, they're different people.
304 2014-05-11 17:23:40 <Luke-Jr> especially since my IRC client gives them the same colour
305 2014-05-11 17:23:40 <shesek> at least one of them has an "_", so its not the same length
306 2014-05-11 17:23:41 <Emzy> yes
307 2014-05-11 17:23:42 <survic> I didn't even notice, sorry.
308 2014-05-11 17:23:43 <sipa> i never knew :o
309 2014-05-11 17:24:20 <gmaxwell> it's pretty trivial to block bitcoin by itself, I dunno why someone would say that it wasn't.
310 2014-05-11 17:24:23 <Emcy_> wow am i that generic an irc person....
311 2014-05-11 17:24:38 <Luke-Jr> Emcy_: Emzy: maybe you ought to adopt a nick with your surname in it :P
312 2014-05-11 17:24:41 <survic> Emcy_: you're that IRC person that's very hard to tab complete
313 2014-05-11 17:24:53 <gmaxwell> blocking the software may not prevent you from using itâ but thats true of all internet services, due to the existance of circumvention tools.
314 2014-05-11 17:25:07 <Emzy> Luke-Jr: have that nick for over 10 years... so..
315 2014-05-11 17:25:11 <Luke-Jr> XD
316 2014-05-11 17:26:04 <Emcy_> he uses a z so he must be my evil universe alter ego
317 2014-05-11 17:26:55 <Emcy_> anyway, china could rub out bitcoin if it wanted to
318 2014-05-11 17:26:58 <Luke-Jr> z is evil?
319 2014-05-11 17:27:05 <Emcy_> its the US spelling
320 2014-05-11 17:27:06 <Emcy_> so yes
321 2014-05-11 17:27:08 <Luke-Jr> I took z to imply dozenal units
322 2014-05-11 17:27:26 <Emzy> gmaxwell: so after all the idea with the satelit is a good one.
323 2014-05-11 17:27:36 <Emzy> gmaxwell: to prevent blocking.
324 2014-05-11 17:27:37 <Luke-Jr> Emzy: it won't stop blocking
325 2014-05-11 17:27:51 <Emcy_> china is even kicking tors ass, really
326 2014-05-11 17:28:08 <Emcy_> they basically have to trade secret entry nodes on slips of paper
327 2014-05-11 17:28:28 <Emcy_> and encapsulate in https
328 2014-05-11 17:28:37 <Emzy> Emcy_: but that works.
329 2014-05-11 17:28:51 <Emcy_> doesnt work if you dont have a hookup
330 2014-05-11 17:29:00 <Emcy_> just like getting some nice burn
331 2014-05-11 17:29:37 <survic> Emcy_: how do you think peer discovery works with drug dealers?
332 2014-05-11 17:29:51 <shesek> Luke-Jr, it could... if equipment that could talk directly to the satellite were affordable and accessible to home users
333 2014-05-11 17:29:56 <Emcy_> "yo this my boy mike, he cool."
334 2014-05-11 17:29:58 <Emcy_> "aight"
335 2014-05-11 17:30:01 <shesek> which is currently not
336 2014-05-11 17:30:10 <Emzy> Luke-Jr: recieving the sattelit can't be blockt. the orher way can be blockt
337 2014-05-11 17:31:02 <Emcy_> shesek the sat is broadcast only
338 2014-05-11 17:31:02 <Emzy> s/blockt/blocked/
339 2014-05-11 17:31:05 <Emcy_> block hearders
340 2014-05-11 17:31:20 <Emcy_> its a cubesat for christ sake
341 2014-05-11 17:32:00 <Emcy_> dont expect telstar 1 or something
342 2014-05-11 17:32:09 <Luke-Jr> Emzy: if you can get hardware to receive from it.
343 2014-05-11 17:32:25 <Luke-Jr> Emzy: and again, even if you can TECHNICALLY get to bitcoin's network, you can't avoid social blocking
344 2014-05-11 17:32:41 <Emzy> sdr are $15 and everyware...
345 2014-05-11 17:32:59 <Luke-Jr> they are?
346 2014-05-11 17:33:10 <Luke-Jr> Emcy: noooooooooo
347 2014-05-11 17:33:16 <Emcy> trolol
348 2014-05-11 17:33:29 <Emcy> are we not different colours
349 2014-05-11 17:33:53 <michagogo> cloud|Emcy: your color didn't change
350 2014-05-11 17:33:59 <Emzy> Luke-Jr: dvb sticks work
351 2014-05-11 17:34:04 <michagogo> cloud|At least not here
352 2014-05-11 17:34:16 <michagogo> cloud|(With irccloud's algorithm)
353 2014-05-11 17:34:18 <Emcy> irc nick colours are client side
354 2014-05-11 17:34:26 <Luke-Jr> Emcy: nope, you and Emzy have the same colour
355 2014-05-11 17:34:52 <Emzy> I have them different.
356 2014-05-11 17:35:18 <Emzy> the nick collision is bad :(
357 2014-05-11 17:35:38 <Emcy> im not pulling a prince on this one guys....
358 2014-05-11 17:36:14 <Emcy> everythng is always easier if i just stop talking lol
359 2014-05-11 17:36:49 <michagogo> cloud|Emcy: I know that
360 2014-05-11 17:37:10 <michagogo> cloud|IRCCloud's algorithm has Emzy in pink
361 2014-05-11 17:37:26 <michagogo> cloud|And Emcy and Emcy_ both red
362 2014-05-11 17:41:48 <Emzy> another question. If I connect to a peer, I also send out the blockchain to the peer if he has less blockchain as I?
363 2014-05-11 17:42:41 <sipa> yes, though in practice that is unlikely
364 2014-05-11 17:42:47 <gmaxwell> Emzy: the peer may request blocks from you that it doesn't have. It's pull, not push.
365 2014-05-11 17:43:25 <Emzy> gmaxwell: ok
366 2014-05-11 17:43:31 <sipa> it's request-what-do-you-have, announce-what-you-have, ask-what-you-need, send-it
367 2014-05-11 17:43:34 <sipa> :)
368 2014-05-11 17:43:39 <Emzy> sipa: why unlikely?
369 2014-05-11 17:43:52 <michagogo> cloud|sipa: ask-for-what-you-need, you mean?
370 2014-05-11 17:44:02 <sipa> because nodes don't advertize themselves until they have caught up
371 2014-05-11 17:44:13 <sipa> michagogo|cloud: ").fixGrammar();
372 2014-05-11 17:44:14 <Emzy> sipa: ah, ok
373 2014-05-11 17:44:31 <michagogo> cloud|sipa: hm?
374 2014-05-11 17:44:44 <sipa> never mind; you're right
375 2014-05-11 17:44:49 <michagogo> cloud|ask-what-you-need implies asking, "what do you need?"
376 2014-05-11 17:46:14 <legerde> Greetings, I am trying to decode a transaction using json-rpc with bitcoind. how do I get from a ScriptSig to an account number?
377 2014-05-11 17:46:43 <Emzy> so we relay for the blockchain on nodes that can be connected..
378 2014-05-11 17:46:43 <legerde> Each scriptsig has a transaction id.. Do I need to chase that?
379 2014-05-11 17:46:47 <survic> what's an account number?
380 2014-05-11 17:47:08 <legerde> an address....
381 2014-05-11 17:47:23 <sipa> an address is a shorthand for a scriptPubKey
382 2014-05-11 17:47:38 <sipa> you can't reliably go from scriptSig to address
383 2014-05-11 17:47:48 <legerde> How do I convert between the two? If I have a scriptSig, can I get to an addres?
384 2014-05-11 17:48:03 <gmaxwell> legerde: What are you trying to accomplish?
385 2014-05-11 17:48:19 <legerde> Hmm... blockchain.info seems to do it: Im looking at this transaction with python to increase my understanding: https://blockchain.info/tx/11e1880ed3c9c864db91dfd28ab1fab97abaada033ace30e31902ada8e751545
386 2014-05-11 17:48:28 <survic> addresses are ultimately one way. you can go from pubkey to address but not address to pubkey.
387 2014-05-11 17:48:40 <legerde> It shows 6 addresses feeding 1 address.
388 2014-05-11 17:48:46 <sipa> blockchain.info confuses people by doing that
389 2014-05-11 17:48:55 <legerde> Hmm. ok
390 2014-05-11 17:48:59 <sipa> they show the address the consumed inputs were previously sent to
391 2014-05-11 17:49:08 <sipa> which is almost always useless information
392 2014-05-11 17:49:18 <sipa> unless you're the sender yourself
393 2014-05-11 17:49:34 <legerde> gmaxwell: I am trying to receive some bitcoin and then return the bitcoin in a second transaction
394 2014-05-11 17:49:41 <sipa> you cannot
395 2014-05-11 17:49:48 <sipa> if you need a refund address, ask for one
396 2014-05-11 17:49:59 <legerde> I am working on an automated situation.
397 2014-05-11 17:50:03 <sipa> bitcoin has no concept of "from addresses"
398 2014-05-11 17:50:15 <sipa> then automate asking for a refund address, or use the payment protocol
399 2014-05-11 17:50:43 <sipa> which has built-in transmission of refund addresses
400 2014-05-11 17:51:06 <survic> (sending BACK to a "from" address will cause the person to lose their money fairly often)
401 2014-05-11 17:51:24 <survic> not always, you can find cases where it won't, but it is not something you want to do.
402 2014-05-11 17:51:27 <legerde> Well.. .Let me be more explicit. :) Lets say I have a 50/50 bet system and someone makes a bet, then i want to pay out the winnings. Can that be automated from received transaction information?
403 2014-05-11 17:51:34 <sipa> no
404 2014-05-11 17:51:40 <sipa> not reliably
405 2014-05-11 17:51:42 <survic> no
406 2014-05-11 17:51:46 <legerde> :(
407 2014-05-11 17:51:54 <sipa> not without making assumptions about what software the sender is using
408 2014-05-11 17:52:09 <sipa> and it is not compatible with some future developments
409 2014-05-11 17:52:15 <tommygunner> check the topic :P
410 2014-05-11 17:52:34 <legerde> How does https://updown.bt/ do it?
411 2014-05-11 17:52:40 <Luke-Jr> legerde: only if "received transaction information" came over the payment protocol
412 2014-05-11 17:52:50 <OneMiner> v0.9.1.0-g026a939-beta (64-bit) doesn't seem to close properly. Windows 7 64 bit. I command the program to close and a small window pops up saying not to shut down until the box goes away, except it never does. This seems to happen every time.
413 2014-05-11 17:52:58 <survic> legerde: it probably guesses and loses people's money a lot of the time.
414 2014-05-11 17:53:04 <Luke-Jr> legerde: that's broken by design, and also inherently harmful to bitcoin; don't imitate it
415 2014-05-11 17:53:05 <sipa> by guessing, and unnecessarily restricting software people can use and making development harder by doing so
416 2014-05-11 17:53:28 <legerde> I see.. So I would need to explicitly ask for payout addresses.
417 2014-05-11 17:53:32 <petertodd> legerde: for instance, dark wallet does coinjoin by default on every transaction sent, which means you'll often be sent funds where the sender does not control some of the input private keys. similarly, if anyone on easy wallet or coinbase sends you funds
418 2014-05-11 17:53:54 <sipa> legerde: or use the payment protocol
419 2014-05-11 17:54:23 <sipa> petertodd: unfortunately, coinbase encourages that behaviour by keeping coins separate