1 2014-08-21 02:14:15 <dgenr8> dsnrk: that article starts out "The average time it takes for a bitcoin transaction to be confirmed in the block chain is about 5 minutes (blocks are mined on average every 10 minutes)."
  2 2014-08-21 02:14:41 <dgenr8> dsnrk: apparently they think the block interval is distributed uniformly on (0,10)
  3 2014-08-21 02:17:56 <dgenr8> ACTION notes that introducing myriad snoop-nodes to find double-spends would not be necessary if double-spends were relayed
  4 2014-08-21 02:22:03 <dgenr8> chain.com: incredibly, the average time to next block is 10 minutes, no matter how long since the last block (assuming hashrate << 2^256 per 10 minutes ;))
  5 2014-08-21 02:24:25 <jgarzik> I think the all-time average is under 10 minutes, but it's been a while since I checked
  6 2014-08-21 02:24:31 <phantomcircuit> dgenr8, what article?
  7 2014-08-21 02:24:42 <phantomcircuit> jgarzik, it's about 9 minutes i think
  8 2014-08-21 02:25:02 <phantomcircuit> (it's certainly < 10)
  9 2014-08-21 02:26:24 <dgenr8> ah, add "stable hash rate" to the assumptions ... picky picky
 10 2014-08-21 02:26:49 <phantomcircuit> dgenr8, what article
 11 2014-08-21 02:27:43 <EasyAt> As hash rate has always increased I would assume that means blocktime has to be <10min
 12 2014-08-21 02:27:46 <EasyAt> (except that one time)
 13 2014-08-21 02:28:04 <phantomcircuit> someone should generate a histogram
 14 2014-08-21 02:28:08 <dgenr8> http://blog.chain.com/post/95226112991/chain-research-0-confirmation-transactions <- not endorsing this
 15 2014-08-21 02:28:08 <phantomcircuit> (that someone not being me)
 16 2014-08-21 02:29:46 <phantomcircuit> dgenr8, assuming 10 minute average block time his statement is correct
 17 2014-08-21 02:29:59 <phantomcircuit> (also assuming uniform distribution of new transactions)
 18 2014-08-21 02:30:25 <dgenr8> i just flipped 10 heads.  what is P(next one heads)?
 19 2014-08-21 02:31:10 <phantomcircuit> dgenr8, he isn't talking about the probability that your transaction will confirm within 5 minutes
 20 2014-08-21 02:31:20 <phantomcircuit> but rather the average overtime
 21 2014-08-21 02:32:00 <dgenr8> i think you should plot that histogram
 22 2014-08-21 02:32:04 <phantomcircuit> (language used is of course not precise in it's meaning, so im assuming he's not a total idiot)
 23 2014-08-21 02:33:05 <phantomcircuit> dgenr8, transaction at time t=0,1,2,3,4,5,6,7,8,9
 24 2014-08-21 02:33:12 <phantomcircuit> average time to confirmation = 5
 25 2014-08-21 02:33:43 <EasyAt> Time since block 0/total blocks
 26 2014-08-21 02:33:46 <phantomcircuit> that doesn't say anything about how long you should expect it to take to find another block
 27 2014-08-21 02:33:50 <wumpus> BlueMatt: yes, I'm working on that
 28 2014-08-21 02:34:55 <dgenr8> phantomcircuit: why did you stop at 9?
 29 2014-08-21 02:39:00 <wumpus> BlueMatt: I've split the util in my local branch into string utilities (hex, base32, base64), money utilities (parsesmoney, formatmoney), time (gettime*, sleep, format date) and the rest (logging, argument parsing, config file parsing)... the first two have no state and further dependencies
 30 2014-08-21 02:41:12 <phantomcircuit> dgenr8, you're right im wrong
 31 2014-08-21 02:42:30 <dgenr8> some areas of statistics are as pretty as some areas of cryptography http://en.wikipedia.org/wiki/Poisson_process
 32 2014-08-21 02:42:56 <phantomcircuit> also i think my simulation is broken
 33 2014-08-21 02:43:20 <phantomcircuit> oh nvm counting starts at t=0
 34 2014-08-21 02:45:46 <phantomcircuit> dgenr8, they're crawling the network with nodejs code?
 35 2014-08-21 02:46:05 <phantomcircuit> that should be hilarious when they hit a node spamming addr nonsense
 36 2014-08-21 03:32:19 <sipa> phantomcircuit: in poisson distributions, thr expected time is equal to the average time
 37 2014-08-21 03:32:24 <sipa> always
 38 2014-08-21 03:32:46 <sipa> wumpus: why are you awake!
 39 2014-08-21 03:34:07 <cfields> heh, i think he's the only dev I've ever known who works bright and early in the morning
 40 2014-08-21 03:34:31 <wumpus> sipa: sleep problems
 41 2014-08-21 03:36:10 <cfields> erm. well now i just look like an ass :\
 42 2014-08-21 03:36:38 <wumpus> cfields: nah, it differs a lot per day, though I tend to get up early these days, today is an crazy exception
 43 2014-08-21 03:37:19 <phantomcircuit> sipa, yeah but maths
 44 2014-08-21 03:37:27 <cfields> i see
 45 2014-08-21 03:37:38 <wumpus> but I understand what you mean, I know people too who wouldn't have found their bed by now :-)
 46 2014-08-21 03:38:31 <cfields> wumpus: you interested in possibly hooking up travis for a test-run tomorrow? (er, ~12h-14h from now)
 47 2014-08-21 03:38:39 <sipa> wumpus: same :)
 48 2014-08-21 03:38:44 <wumpus> cfields: sure!
 49 2014-08-21 03:38:47 <cfields> i'm not really sure how to give it a trial without putting it in place
 50 2014-08-21 03:39:01 <wumpus> cfields: what do I need to do for that?
 51 2014-08-21 03:39:16 <cfields> wumpus: grr, sec. dog's about to explode if i don't take him out
 52 2014-08-21 03:39:51 <wumpus> cfields: oh better to that first then :)
 53 2014-08-21 03:48:10 <cfields> ok
 54 2014-08-21 03:48:20 <rgenito> let's say i have a local bitcoin daemon running... is there a way I can query the json-rpc to look at the "ending balance" of a bitcoin public address?
 55 2014-08-21 03:48:33 <cfields> wumpus: one of the github admin will need to allow read-only access for the travis api
 56 2014-08-21 03:48:41 <cfields> that's all there is to it
 57 2014-08-21 03:49:00 <rgenito> also, what is the best way to look out for incoming payments to be public address? do i need to read each newly created block as it comes in from bitcoind?
 58 2014-08-21 03:49:07 <wumpus> cfields: so I need to contact a github admin to allow travis? what information do I need to provide?
 59 2014-08-21 03:49:24 <cfields> sipa's done it for the libsecp256k1 repo, i'll defer to his judgement as to whether it presents any risk
 60 2014-08-21 03:49:29 <wumpus> or can that only be done when you have set up your side?
 61 2014-08-21 03:49:31 <cfields> wumpus: no, sorry. a repo admin
 62 2014-08-21 03:49:55 <wumpus> ok
 63 2014-08-21 03:50:21 <cfields> i dunno who those are for the bitcoin repo. sipa, you know that one?
 64 2014-08-21 03:51:22 <wumpus> I think I can do that
 65 2014-08-21 03:51:36 <wumpus> it's under 'webhooks and services'?
 66 2014-08-21 03:51:48 <cfields> wumpus: before that, i'll need to get the info moved away from my account with travis tomorrow. I can handle that and just ping you when it's ready.
 67 2014-08-21 03:51:50 <cfields> yep
 68 2014-08-21 03:51:57 <sipa> rgenito: bitcoind tracks balances per wallet, not per address
 69 2014-08-21 03:52:17 <cfields> wumpus: i'll draw up some docs describing how everything works. It's really very simple.
 70 2014-08-21 03:52:41 <cfields> and i'll mail the dev list to let everyone know it's going live for a trial as well
 71 2014-08-21 03:52:53 <jgarzik> wumpus, sipa: RE " Encapsulate & protect core class COutPoint #4662"   I've no strong opinion.  It was done after " Encapsulate & protect members of CMessageHeader (kinda), CInv, CAddress #4661", and the genesis of #4661 was comments in src/protocol.h:
 72 2014-08-21 03:52:53 <wumpus> cfields: i indeed see 'travis CI' in that list
 73 2014-08-21 03:52:55 <jgarzik>  // TODO: make private (improves encapsulation)
 74 2014-08-21 03:52:57 <cfields> (once we decide we're ready)
 75 2014-08-21 03:53:19 <jgarzik> I would lean towards OK #4661, but leave core DSs as-is, due to so many existing direct accesses
 76 2014-08-21 03:53:23 <rgenito> sipa, "wallet" meaning the collection of btc addresses?
 77 2014-08-21 03:53:26 <wumpus> jgarzik: wonder who added that comment :p
 78 2014-08-21 03:54:14 <jgarzik> comment added in 507fd9d15baac950df494742d67bcbafdaa4752c
 79 2014-08-21 03:54:15 <sipa> rgenito: not really, as wallets generate their own new keys too
 80 2014-08-21 03:54:20 <wumpus> jgarzik: I have no strong opinion about that either, but I've never ben of the OO-extremist school of 'everything should be an encapsulated object' , sometimes itm akes sense sometimes it doesn't :)
 81 2014-08-21 03:54:24 <jgarzik> Giel van Schijndel <me@mortis.eu>
 82 2014-08-21 03:54:32 <jgarzik> wumpus, agree
 83 2014-08-21 03:55:02 <jgarzik> wumpus, furthermore, I'm an expert on C but a C++ newbie, so I'll follow whatever is the general preference
 84 2014-08-21 03:55:03 <rgenito> sipa, ahh, any suggestions for a development package that will let me "explore some blocks"? :D
 85 2014-08-21 03:55:10 <rgenito> i'm looking at blockchain.info's api at the moment
 86 2014-08-21 03:55:20 <sipa> rgenito: wallets manage their own funds, and the way bitcoind works, it makes little sense to micromanage it per address (it would be confusing and let you shoot yourself in the foot)
 87 2014-08-21 03:55:33 <sipa> rgenito: you shouldn't reuse addresses more than once anyway
 88 2014-08-21 03:55:40 <rgenito> ya i agree.
 89 2014-08-21 03:56:31 <wumpus> jgarzik: well, let's see what others think
 90 2014-08-21 03:56:51 <wumpus> jgarzik: yes I agree on #4661, doing it for the net structures
 91 2014-08-21 03:57:27 <BlueMatt> wumpus: nice, makes my life easier
 92 2014-08-21 03:59:02 <rgenito> sipa, any suggestions for a development package that will let me "explore some blocks"? :D
 93 2014-08-21 04:00:13 <wumpus> BlueMatt: I'm thinking of renaming what remains of util (after all the real utilities gone) to something like 'environment', as logging, argument parsing and storage, config parsing and storage, thread wrappers etc is more about the os/execution environment than 'util' really, but can't think of a good name...
 94 2014-08-21 04:03:08 <BlueMatt> os-interface
 95 2014-08-21 04:03:12 <wumpus> 'stateful shit'
 96 2014-08-21 04:03:15 <BlueMatt> heh
 97 2014-08-21 04:03:16 <wumpus> yeah
 98 2014-08-21 04:03:44 <wumpus> that may be it -- and a library doesn't need the os interface, but the standalone executables do
 99 2014-08-21 04:04:38 <BlueMatt> pretty much
100 2014-08-21 04:05:08 <phantomcircuit> wumpus, leveldb puts that stuff under utils/env_{posix,win}
101 2014-08-21 04:05:18 <phantomcircuit> which seems like a fairly comical way of doing it
102 2014-08-21 04:06:08 <wumpus> phantomcircuit: may make sense - although, in our case, most code is shared between all platforms (there are some #ifdefs ofcourse)
103 2014-08-21 04:07:17 <wumpus> mostly some very obscure things like SetThreadPriority
104 2014-08-21 04:07:59 <wumpus> (which is a perceived need for, but not part of boost::thread0
105 2014-08-21 04:09:12 <sipa> rgenito: to do what?
106 2014-08-21 04:09:46 <sipa> rgenito: except if you're writing a debugging tool, exploring blocks is likely a means to a goal and not a goal by itself
107 2014-08-21 04:09:58 <sipa> ACTION tries to sleep
108 2014-08-21 04:10:09 <wumpus> you can 'explore blocks' with bitcoind just fine, if that means looking into block details
109 2014-08-21 04:10:14 <wumpus> good luck sipa
110 2014-08-21 04:10:32 <BlueMatt> sipa: seriously dude, learn to sleep during night hours
111 2014-08-21 04:11:26 <rgenito> sipa , how do you know? o.O you have know idea what i'm doing over here
112 2014-08-21 04:11:33 <rgenito> anyhoo, leaving office :D gnighty
113 2014-08-21 06:17:43 <phantomcircuit> BlueMatt, sleep during night hours
114 2014-08-21 06:17:45 <phantomcircuit> what is wrong with you
115 2014-08-21 06:17:59 <BlueMatt> phantomcircuit: heh
116 2014-08-21 06:18:53 <Belxjander> phantomcircuit: what are "night hour"s again?
117 2014-08-21 06:19:09 <phantomcircuit> no idea
118 2014-08-21 06:19:17 <Belxjander> phantomcircuit: sorry...I have no sense of this thing called "time" which everyone seems to want to schedule everything by
119 2014-08-21 06:19:39 <gribble> 316753
120 2014-08-21 06:19:39 <phantomcircuit> ;;bc,blocks
121 2014-08-21 06:21:20 <phantomcircuit> blargh
122 2014-08-21 06:23:23 <phantomcircuit> sigh
123 2014-08-21 07:21:38 <Genitrust> what is "block height"? is that the block # basically?
124 2014-08-21 07:26:26 <wumpus> yes
125 2014-08-21 07:26:43 <wumpus> just another word for that
126 2014-08-21 07:42:03 <arioBarzan> Luke-Jr could easily steal coins of careless people who use scripts involving no OP_CHECKSIG like the ones in tx/b5c103dae667c4c5067be34510b30bef059090db09355c993cda00517a2b79a6
127 2014-08-21 07:44:12 <arioBarzan> it needs just few lines of code to check every valid script for spending coins to see whether they sign the outputs or not.
128 2014-08-21 07:45:32 <gwillen> arioBarzan: I see a checksig at the end when I look at that tx
129 2014-08-21 07:45:45 <gwillen> i.e. at the bottom of https://blockchain.info/tx/b5c103dae667c4c5067be34510b30bef059090db09355c993cda00517a2b79a6
130 2014-08-21 07:46:44 <arioBarzan> gwillen: the input comes from tx/9674d6203c43b348e330e32628c5efdad1ca1150b32c7e3069f057fcd140a58a which sent coins to a P2SH address
131 2014-08-21 07:47:09 <gwillen> ahhhhh, okay
132 2014-08-21 07:47:32 <gwillen> and the hashed script has no checksig, I see
133 2014-08-21 07:47:40 <arioBarzan> yup
134 2014-08-21 07:47:44 <gwillen> living on the edge, indeed; I wonder who's emitting those
135 2014-08-21 07:48:56 <arioBarzan> apparently dude's nickname is "poutine"
136 2014-08-21 07:49:15 <arioBarzan> 706f7574696e65 = "poutine"
137 2014-08-21 07:50:21 <gwillen> snrk!
138 2014-08-21 07:50:24 <arioBarzan> ripemd160(sha256("706f7574696e65")) = 7a73cf250e33244910bd6316b57dbadfcb7a8deb63e5b3b148d0c7b8465cfcc2
139 2014-08-21 07:50:56 <gwillen> unless there's somewhere that's being decoded for me on bc.i, I'll take your word for it since I can't see what the script decodes to
140 2014-08-21 07:52:01 <Genitrust> wumpus: ty btw :)
141 2014-08-21 07:53:08 <arioBarzan> gwillen: in a unix terminal type this command "echo 706F7574696E65|xxd -r -p"
142 2014-08-21 07:53:18 <gwillen> arioBarzan: oh, I got that part
143 2014-08-21 07:53:24 <gwillen> I meant the surrounding P2SH script
144 2014-08-21 07:53:42 <gwillen> I see "poutine" aa20<your hash>87
145 2014-08-21 07:53:54 <gwillen> but I don't actually know how that executes
146 2014-08-21 07:54:27 <arioBarzan> gwillen: here is how http://webbtc.com/script/b5c103dae667c4c5067be34510b30bef059090db09355c993cda00517a2b79a6:0
147 2014-08-21 07:55:37 <gwillen> aha, thanks
148 2014-08-21 08:14:24 <iwilcox> arioBarzan: Chances are reasonable that the poutine here in channel is the poutine, so now he's highlighted, maybe we'll find out :)
149 2014-08-21 08:16:43 <sipa> BlueMatt: done!
150 2014-08-21 08:18:39 <Genitrust> it's possible for a public key to be the "input" of a transaction, and for the public key to be the "output" of another separate transaction... all in the same block height, right?
151 2014-08-21 08:19:14 <sipa> you're confused; transactions do not spend from/to a key
152 2014-08-21 08:19:28 <sipa> but the answer is probably yes
153 2014-08-21 08:19:50 <sipa> you can consume a coin (transaction output) that was created in the same block
154 2014-08-21 08:19:54 <Genitrust> nah i'm not confused...just having a hard time figuring out how to put this to english :)
155 2014-08-21 08:26:33 <phantomcircuit> sipa, huh
156 2014-08-21 08:26:58 <phantomcircuit> trying to figure out how long is a reasonable period of time to wait to get an accurate hashrate for a miner
157 2014-08-21 08:27:03 <phantomcircuit> realized the answer is forever
158 2014-08-21 08:45:34 <Eliel> depends on the accuracy you want :)
159 2014-08-21 08:56:29 <phantomcircuit> Eliel, no i mean it's really forever basically
160 2014-08-21 08:56:50 <phantomcircuit> https://i.imgur.com/E0PNumX.png
161 2014-08-21 08:56:58 <phantomcircuit> simulation of diff 1 with 80Gh/s
162 2014-08-21 08:58:05 <Eliel> it does look to me as if it converges eventually
163 2014-08-21 08:58:25 <sipa> of course it takes forever to be ibfibitely accurate, it's a statistical process
164 2014-08-21 08:58:51 <Eliel> so, you can decide accuracy you need and be able to get that in finite time.
165 2014-08-21 08:58:51 <sipa> but you can make a reasonable guess with any amount of data, and calculate how wrong you likely are :p
166 2014-08-21 08:59:45 <phantomcircuit> sipa, that's the part that's holding me up
167 2014-08-21 08:59:52 <phantomcircuit> i was always lol bad at statistics
168 2014-08-21 09:08:47 <arioBarzan> someone destroyed 2609.36304319 BTC at 2011-10-28 by sending coins to "OP_DUP OP_HASH160 OP_FALSE OP_EQUALVERIFY OP_CHECKSIG"
169 2014-08-21 09:09:24 <arioBarzan> block-height/150951
170 2014-08-21 09:09:49 <epscy> wasn't that gox?
171 2014-08-21 09:10:23 <phantomcircuit> epscy, i think so
172 2014-08-21 09:10:33 <phantomcircuit> and it's actually no OP_FALSE it's OP_PUSH 0
173 2014-08-21 09:10:40 <phantomcircuit> which happens to be OP_FALSE
174 2014-08-21 09:41:13 <Genitrust> *sigh*
175 2014-08-21 09:52:37 <wumpus> who sends '.4' as subVersion? it looks broken... 2014-08-21 09:50:31 receive version message: .4: version 31402, blocks=315833, us=:8333, peer=4
176 2014-08-21 11:30:34 <SomeoneWeird> people who are... writing a client? :p
177 2014-08-21 11:30:35 <SomeoneWeird> ACTION shrugs
178 2014-08-21 11:30:56 <SomeoneWeird> sigh
179 2014-08-21 11:42:32 <wumpus> I'm not sure what they're writing, wouldn't be surprised if it was another crawler
180 2014-08-21 11:42:40 <wumpus> hm it stays connected, "services" : "0000000000000000"
181 2014-08-21 11:43:40 <wumpus> no NODE_NETWORK, so either a SPV client or a crawler
182 2014-08-21 11:44:30 <Luke-Jr> ACTION wonders why arioBarzan thinks he's any more likely to steal random coins than anyone else
183 2014-08-21 11:47:10 <wumpus> ACTION thinks about a trace <node> command that logs everything a node does... hm, maybe too nosy :)
184 2014-08-21 11:48:10 <wumpus> does anyone have statistics on OP_RETURN usage?
185 2014-08-21 12:07:16 <amaclin> what kind of OP_RETURN stats? something is here http://webbtc.com/scripts/op_return
186 2014-08-21 12:09:19 <wumpus> I was looking for numbers (how many), but a list is also fine, thanks
187 2014-08-21 12:10:32 <amaclin> wumpus, about .4 node... can you give IP? Or just wireshark it yourself and filter incoming data
188 2014-08-21 12:11:23 <pigeons> wumpus: yeah no stats but a list here too http://coinsecrets.org/
189 2014-08-21 12:13:13 <wumpus> amaclin: its a server in Germany
190 2014-08-21 12:15:03 <amaclin> wumpus: which one? :)
191 2014-08-21 12:19:14 <dsnrk> wumpus: https://github.com/sebicas/bitcoin-sniffer/blob/master/sniffer.py#L27
192 2014-08-21 12:20:45 <wumpus> dsnrk:thanks!
193 2014-08-21 12:21:44 <dsnrk> if you want to identify these sorts of network sniffers, just look at your bandwidth usage. if one has no receives and much, much higher sent, then it's a sniffer. there's a *lot* of them on ipv4 at the moment.
194 2014-08-21 12:22:37 <dsnrk> there's groups like chain.com, bitnodes.io who are trying to have a socket open on every listening node.
195 2014-08-21 12:23:33 <amaclin> wasting traffic ;(
196 2014-08-21 12:24:29 <wumpus> and wasting connection slots :(
197 2014-08-21 12:24:37 <wumpus> at least this one stays connected
198 2014-08-21 12:24:50 <dsnrk> chain.com alone would be burning 7000 sockets over the whole network.
199 2014-08-21 12:25:14 <dsnrk> bitnodes.io scanner slams the network with connections, and seems to even dump the mempool on every pass too.
200 2014-08-21 12:25:27 <dsnrk> ^ and they don't even publish their data anymore
201 2014-08-21 12:25:48 <wumpus> I don't care about traffic so much, maybe I should send them some more :)
202 2014-08-21 12:25:52 <amaclin> by the way. i usually execute my local bitcoin-qt with -maxconnections=1 and my node is not sniffer!
203 2014-08-21 12:27:29 <wumpus> it would be a very polite sniffer with only one connection
204 2014-08-21 12:30:47 <amaclin> but you will see only outgoing traffic from your node in your logs... and no assumption - do I use a sniffer or node with one connection
205 2014-08-21 12:32:55 <wumpus> I've just booted it, lets see if it tries to reconnect
206 2014-08-21 12:33:32 <wumpus> yep  :( receive version message: .4: version 31402, blocks=315833, us=:8333, peer=13
207 2014-08-21 12:34:36 <dsnrk> if history is anything to go by, it'll do that until the end of time. somebodies modified the source code from github.
208 2014-08-21 12:38:01 <amaclin> what a stupid bot owners! first of all the bot shouldn't discover itself by such things. At least my bot doesn't :)
209 2014-08-21 12:41:01 <wumpus> well a normal node wouldn't keep reconnecting if it is booted
210 2014-08-21 12:41:16 <wumpus> certainly not five times...
211 2014-08-21 12:42:21 <amaclin> QTimer::singleShot ( 120 * 60 * 1000, this, SLOT ( restart ( ) ) );
212 2014-08-21 12:43:48 <Guest51612> Anyone here who's familiar with BitcoinJS ?
213 2014-08-21 12:45:10 <TheRingMaster> or, more particularly, anyone ever tried to compile/build/convert the BitcoinJS lib to a ready-to-use .js file ?
214 2014-08-21 12:45:37 <TheRingMaster> because I'd like to use BitcoinJS in a html5 site but I don't use nodejs or anything
215 2014-08-21 12:45:46 <hearn> dsnrk: hmm? the data is here: https://getaddr.bitnodes.io/
216 2014-08-21 12:46:27 <dsnrk> hearn: they used to provide SQL dumps, which aren't there anymore. they wouldn't enjoy me throwing hundreds of thousands of requests at them to build my graphs with.
217 2014-08-21 12:48:50 <amaclin> the graph of all world nodes? hmm... what for?
218 2014-08-21 12:49:02 <hearn> dsnrk: ask addy where they went?
219 2014-08-21 12:49:47 <hearn> i wonder how we ended up with 1000 nodes reliably stuck/behind
220 2014-08-21 12:50:32 <dsnrk> who is addy?
221 2014-08-21 12:51:11 <hearn> the guy who runs that crawler
222 2014-08-21 12:51:40 <wumpus> whoa it's really agressive, it just keeps reconnecting to me
223 2014-08-21 12:51:52 <dsnrk> wumpus: told you.
224 2014-08-21 12:52:00 <wumpus> even though tcpkill gets it before the version message is even sent
225 2014-08-21 12:52:17 <dsnrk> hearn: right, I'll find a way to get in touch with them I guess.
226 2014-08-21 12:52:35 <hearn> dsnrk: ayeowch@gmail.com
227 2014-08-21 12:52:36 <wumpus> we need a 'buggeroff' P2P message
228 2014-08-21 12:52:49 <dsnrk> well that "bitcoin sniffer" thing wouldn't support it
229 2014-08-21 12:53:12 <dsnrk> hearn: k.
230 2014-08-21 12:54:31 <dsnrk> wumpus: would be nice to set up a honeypot of 9 nodes, and see who tries to connect to all of them.
231 2014-08-21 12:54:35 <amaclin> isn't it possible to setup firewall to block incoming connections from that address for... a month?
232 2014-08-21 12:54:53 <wumpus> amaclin: sure, but I like playing with it
233 2014-08-21 12:55:13 <wumpus> dsnrk: good idea
234 2014-08-21 12:55:23 <dsnrk> I'd do it but.. expensive.
235 2014-08-21 12:57:13 <amaclin> dnsrk, let me in to this game. my bot connects to several nodes (~60 right now), but sends "getdata" packet only to first "inv"
236 2014-08-21 12:57:20 <wumpus> amaclin: but indeed, something to auto-ban nodes that are too agressive in connection behavior for a while  would be nice, although it's hard to do in a way that wouldn't be risky to the network
237 2014-08-21 12:58:21 <amaclin> wumpus, unfortunately, banning nodes is not a protocol level of client
238 2014-08-21 12:59:02 <wumpus> amaclin: well we currently ban nodes for misbehavior too, but nothing that spans multiple connections
239 2014-08-21 12:59:27 <amaclin> i know
240 2014-08-21 13:06:36 <wumpus> wwwhat, people are running salvagewallet to 'verify their wallet'? https://github.com/bitcoin/bitcoin/issues/4747
241 2014-08-21 13:06:59 <wumpus> come on, don't make me cry :/
242 2014-08-21 13:08:22 <dsnrk> and why are they importing private keys..
243 2014-08-21 13:08:55 <dsnrk> as soon as you see that, you *know* they're doing something terribly wrong.
244 2014-08-21 13:09:00 <hearn> hah
245 2014-08-21 13:09:07 <hearn> welcome to the hell that is supporting real bitcoin users :)
246 2014-08-21 13:10:03 <dsnrk> like the guy who kept deleting his chainstate and blocks because his node was syncing too slowly.
247 2014-08-21 13:10:34 <dsnrk> or the one that was telling everybody to delete their block files to save space on running nodes
248 2014-08-21 13:12:04 <wumpus> lol...
249 2014-08-21 13:13:07 <dsnrk> what's #4703 about?
250 2014-08-21 13:13:24 <wumpus> another strange issue by the guy
251 2014-08-21 13:13:46 <dsnrk> .. why is he trying to use the RPC server in google chrome
252 2014-08-21 13:14:15 <helo> ssl!
253 2014-08-21 13:14:35 <aschildbach> I'm about to write a small script that takes the output of "bitcoin-cli getpeerinfo" and creates a bind9 zone file for it, in order to be used in a DNS seed setup. Did anyone do this already?
254 2014-08-21 13:14:39 <helo> and json... sounds like web browser stuff to me
255 2014-08-21 13:15:03 <wumpus> a crash deep inside the windows kernel, an assertion without message, that happens every few hours
256 2014-08-21 13:15:19 <hearn> aschildbach: not that i'm aware of
257 2014-08-21 13:15:25 <wumpus> both with bitcoind and bitcoin-qt, and no other reports of such an issue ever
258 2014-08-21 13:15:37 <dsnrk> there's a confirm in there you missed
259 2014-08-21 13:15:42 <dsnrk> https://github.com/bitcoin/bitcoin/issues/4703#issuecomment-52486531
260 2014-08-21 13:15:44 <hearn> aschildbach: sounds like a good idea though, although the output of getpeerinfo is largely static at the moment so i'd not want to point SPV clients at such a seed
261 2014-08-21 13:15:57 <aschildbach> why is that static?
262 2014-08-21 13:16:18 <wumpus> dsnrk: not so sure whether to believe that, or that he just asked someone to post in the issue
263 2014-08-21 13:16:39 <aschildbach> I thought bitcoind is used for all seeds, just the method of getting the data from bitcoind to DNS differs.
264 2014-08-21 13:17:06 <dsnrk> wumpus: good point.
265 2014-08-21 13:17:09 <wumpus> most use sipa's crawler afaik
266 2014-08-21 13:17:26 <wumpus> (which doesn't use bitcoind)
267 2014-08-21 13:17:42 <wumpus> but doing it differently is fine
268 2014-08-21 13:18:19 <wumpus> I'm not sure if publishing your getpeerinfo through DNS makes much sense though; that's only your peers, and they have a limited number of connection slots, which wil likely run out very soon if everyone connects to them
269 2014-08-21 13:18:39 <dsnrk> eh, who knows. given they're also importing private keys.. who knows what is going on.
270 2014-08-21 13:18:56 <aschildbach> The problem with the crawler is that it somehow uses a bad DNS implementation.
271 2014-08-21 13:18:58 <wumpus> dsnrk: well I suspect a hardware issue of some kind
272 2014-08-21 13:19:10 <aschildbach> I'm intent to use bind9.
273 2014-08-21 13:19:15 <dsnrk> on amazon ec2?
274 2014-08-21 13:19:19 <wumpus> ie, memory or hardware corruption
275 2014-08-21 13:20:05 <hearn> aschildbach: actually i'd prefer you export the data over HTTPS if you're going to do work on seeding :-)
276 2014-08-21 13:20:13 <hearn> aschildbach: but at the moment bitcoind establishes peers and then doesn't rotate them
277 2014-08-21 13:20:18 <hearn> aschildbach: that's why we saw they'd run out of connection slots
278 2014-08-21 13:20:39 <hearn> aschildbach: you could also try running sipa's crawler and connect it to bind somehow ....
279 2014-08-21 13:21:09 <wumpus> the crawler can export its data, which you could import into bind
280 2014-08-21 13:21:39 <aschildbach> wumpus: Can it just write a zone file?
281 2014-08-21 13:21:48 <wumpus> aschildbach: I doubt it
282 2014-08-21 13:22:04 <wumpus> though of course you can adapt it to do that
283 2014-08-21 13:22:28 <aschildbach> I'll have a look at it, maybe I manage that despite my non-knowledge of C++
284 2014-08-21 13:37:39 <only> hi, has anyone tried installing this plugin -> http://wordpress.org/plugins/bitcoin-payments-for-woocommerce/
285 2014-08-21 15:19:05 <wumpus> cfields: can you make head or tails of this? https://github.com/bitcoin/bitcoin/issues/4745
286 2014-08-21 15:19:33 <cfields> wumpus: yea, saw that last night. It's on my list to poke for today
287 2014-08-21 15:19:55 <wumpus> he basically says that the gitian build gets an unknown tag, which I'm pretty sure is not true, so I'm not sure what the problem is
288 2014-08-21 15:19:56 <wumpus> ok
289 2014-08-21 15:20:10 <cfields> I think it works correctly due to the git archive thing, but i want to verify that it's actually working as intended
290 2014-08-21 15:20:10 <cfields> right
291 2014-08-21 15:25:04 <wumpus> anyone have suggestions what absolutely should be in 0.9.3? we intend to do a bugfix-only release, so no new features. See https://github.com/bitcoin/bitcoin/commits/0.9.3 for what's already in
292 2014-08-21 15:27:16 <poutine> gwillen, ?
293 2014-08-21 15:27:43 <cfields> wumpus: i think i have a few, will make a list. but for sure the most recent osx font thing needs to go in
294 2014-08-21 15:27:43 <poutine> gwillen, yeah that tx could have been stolen, it was a puzzle in a P2SH
295 2014-08-21 15:27:47 <cfields> sec for commit
296 2014-08-21 15:29:13 <cfields> wumpus: ah nm, that fixed a regression that's probably not in 0.9.3
297 2014-08-21 15:30:01 <wumpus> you mean the font substitution? I'd feel better merging it anyway
298 2014-08-21 15:31:02 <cfields> yea, 292cc072f3bada256bc6af9970512eb9dec8d93a
299 2014-08-21 15:31:38 <cfields> i never saw it present before the separator changes, i don't think it would hurt
300 2014-08-21 15:35:50 <wumpus> OK, pushed that one and the openssl dep upgrade
301 2014-08-21 15:37:12 <cfields> There were a few build fixes, not sure if you want to pull any of those in
302 2014-08-21 15:37:26 <cfields> namely the boost+arm hack
303 2014-08-21 15:37:31 <wumpus> fixes, sure
304 2014-08-21 15:38:08 <wumpus> wtf, how did miniupnpc pull a version update without me noticing
305 2014-08-21 15:38:25 <cfields> 54c7df81f3e5f81cb91646acaf82074a3a6be3b2
306 2014-08-21 15:38:41 <wumpus> thanks
307 2014-08-21 15:38:58 <cfields> wumpus: i looked at that when doing the deps, iirc there was nothing major in there
308 2014-08-21 15:39:30 <wumpus> ....we can always call it bitcoin 0.9.2.20140821! :p
309 2014-08-21 15:39:52 <cfields> heh
310 2014-08-21 15:40:33 <cfields> hmm wait, that changelog doesn't look familiar. maybe i was thinking of another
311 2014-08-21 15:41:06 <cfields> ah yea, i was thinking of qrencode. minor bump for that one
312 2014-08-21 15:42:26 <jeremyrubin> Hey I have a question on bloom filters, perhaps someone here may have an answer
313 2014-08-21 15:43:22 <jeremyrubin> Or rather, I would like to make a "Set" which can only check contains, but can not be (easily) turned into a list of keys
314 2014-08-21 15:43:39 <jeremyrubin> Is a bloom filter appropriate for this
315 2014-08-21 15:43:52 <jeremyrubin> if I am OK with some false positives?
316 2014-08-21 15:44:22 <jeremyrubin> Or are there better data structures for this purpose?
317 2014-08-21 15:45:14 <wumpus> if you are ok with false positives, a bloom filter seems to be the way to go, you can even control the number of false positives by setting the size of the filter
318 2014-08-21 15:46:46 <jeremyrubin> Cool -- do you know where I might read a formal proof, or any resources where I might prove for myself, the non-enumerable property?
319 2014-08-21 15:47:38 <wumpus> whoa, I certainly get a lot of mails from researchers doing research into github participation, I must be  in some top-N list
320 2014-08-21 15:48:49 <wumpus> jeremyrubin: no, I wouldn't know, but I'm sure there is lots of information to be found about bloom filters online
321 2014-08-21 15:50:42 <jeremyrubin> Cool I'll look into it. Thanks :) -- If you're curious about the use case, happy to tell you in a pm, it is for the MIT Bitcoin Study
322 2014-08-21 16:00:51 <cfields> wumpus: #4664 may need to go in, i'm not sure what introduced that symbol
323 2014-08-21 16:05:21 <jintelletec> hey guys. I'm wondering if anyone can help im looking for someone for a unique project with experience in C+11, C++ & Crypto
324 2014-08-21 16:05:30 <jintelletec> ideally with 8 plus years experience
325 2014-08-21 16:05:39 <wumpus> cfields: ok, going to pull those just to be sure
326 2014-08-21 16:06:07 <cfields> yea, should be safe
327 2014-08-21 16:06:23 <cfields> wumpus: i think that's it from me (just went through my closed PRs)
328 2014-08-21 16:08:22 <Luke-Jr> wumpus: you need anything from me for 0.9.3?
329 2014-08-21 16:11:10 <wumpus> Luke-Jr: well if you're missing any important fixes in https://github.com/bitcoin/bitcoin/commits/0.9.3  let me know
330 2014-08-21 17:05:34 <jarekin> hi, i'm looking for the hd-wallet-rpc-calls of bitcoind, may someb give me an url do some code or documentation?
331 2014-08-21 17:09:22 <gmaxwell> jarekin: there are none.
332 2014-08-21 17:10:28 <jarekin> gmaxwell: okay, thanks
333 2014-08-21 17:16:34 <jarekin> gmaxwell: hm, may there is some straightforward code which only generates public keys from the extended public key? I know there are a lot of links in the bip32-file, but i'm not an cryptographer and i did not find a simple function that just takes the extend public key and child chain/number as arguments and outputs me the new child public key
334 2014-08-21 17:17:54 <kgk> jarekin: There is if you're using java
335 2014-08-21 17:17:58 <kgk> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/com/google/bitcoin/wallet/DeterministicKeyChain.java
336 2014-08-21 17:18:07 <jarekin> kgk: thanks!
337 2014-08-21 17:20:35 <gmaxwell> jarekin: please do be careful, manual key management is tricky, and there are some ways you can screw yourself pretty good. (in particular, when you do non-hardened derrivation like that leaking any private key effectively leaks all the private keys in that chain)
338 2014-08-21 17:21:59 <jarekin> gmaxwell: yes, i read about that in the developer guide
339 2014-08-21 17:23:12 <jarekin> gmaxwell: i'm planing to implement the often mentioned use case of an e-commerce-shop that creates pubkeys with the extended pubkey
340 2014-08-21 17:23:41 <jarekin> so any private key should never exist accessable online
341 2014-08-21 17:24:26 <andytoshi> so your attack surface will just grow indefinitely and then when one key leaks every one does?
342 2014-08-21 17:24:27 <andytoshi> don't do that
343 2014-08-21 17:26:30 <jarekin> hm, andytoshi: but as i understood, when u do the hardened-key-way u need the private key to generated additionall public keys, isn't that bad?
344 2014-08-21 17:27:09 <gmaxwell> andytoshi: less of an issue if the keys are being periodically rotated (and/or swept)
345 2014-08-21 17:27:41 <Luke-Jr> jarekin: pycoin can do this stuff i think
346 2014-08-21 17:28:21 <andytoshi> jarekin: good q, i haven't yet looked at how HD keys are implemented
347 2014-08-21 17:28:34 <gmaxwell> I feel somewhat regretful for disclosing the type-2 stuff on the world; with many wallets now using it as their exclusive key generation mechanism... but the webserver case it's still the best alternative.
348 2014-08-21 17:28:52 <jarekin> Luke-Jr: yes it can, i'm sure kgk's java class can do it as well, but i really am looking for a simple straight forward function (static) that takes the following arguments: extend publicy key, child chain, child number
349 2014-08-21 17:30:41 <jarekin> actually im looking for a function (static) that does this: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Public_parent_key_rarr_public_child_key
350 2014-08-21 17:30:52 <Luke-Jr> $ genwallet --wallet-key xpub69BTh1CDQs6zk5Kemw6P1cG2hr7zaTBMvLpoiVB2um5dgjxfLygWvWjQZf6T4tu7R9HLcGsjfWfTbKMWk88FwxRmG9rxYSXkbPWg7d6LqYq --address --subkey 0/2/1
351 2014-08-21 17:47:13 <jarekin> Luke-Jr: https://github.com/richardkiss/pycoin/blob/master/pycoin/key/BIP32Node.py in line 229: there u see that it uses the private key to generate the public key, on a web server i don't have that private key available (of course ...)
352 2014-08-21 17:47:46 <Luke-Jr> jarekin: the command I just pasted does not include a private key anywhere.
353 2014-08-21 17:48:56 <Luke-Jr> jarekin: notice the private key is only needed for the 'p' derivations. if I do 0p/2/1, i get an error "can't derive a private key from a public key"
354 2014-08-21 17:50:29 <jarekin> Luke-Jr: ah okay, so derrivation of private and public keys shares the same code...
355 2014-08-21 17:51:33 <Luke-Jr> ACTION ponders writing a C lib for HD wallet functions
356 2014-08-21 18:04:17 <jarekin> Luke-Jr: found it ;) https://github.com/richardkiss/pycoin/blob/master/pycoin/key/bip32.py line 89
357 2014-08-21 18:24:40 <BlueMatt> sipa: huh?
358 2014-08-21 19:20:16 <sipa> BlueMatt: huh what?
359 2014-08-21 19:20:30 <BlueMatt> <sipa> [08:16:43] BlueMatt: done!
360 2014-08-21 19:53:45 <maraoz> does anyone have ~100 testnet coins to spare? ms7YNZ1LtAW5KncyKkEZxKC4EPSPFJ7tDq
361 2014-08-21 19:54:02 <Someguy123> [12:30:58] <*highlight> * SomeoneWeird sets mode: -o Someguy123 on #bitcoin-dev
362 2014-08-21 19:54:03 <Someguy123> what?
363 2014-08-21 19:54:10 <Someguy123> i'm not even an op...
364 2014-08-21 20:16:45 <Eliel> Someguy123: that doesn't prevent an op from removing your nonexistent ops :P
365 2014-08-21 20:26:51 <elichai2> Amp
366 2014-08-21 20:26:54 <elichai2> ops
367 2014-08-21 21:18:32 <sipa> BlueMatt: you told me to sleep at night
368 2014-08-21 21:36:39 <maraoz> thanks to whoever pointed his testnet miners to my address :3
369 2014-08-21 22:10:16 <BlueMatt> sipa: ahhh