1 2012-12-05 00:05:03 <jgarzik> ah hah
  2 2012-12-05 00:05:05 <jgarzik> 12/05/12 01:01:37 ProcessMessages(version, 110 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
  3 2012-12-05 00:05:13 <jgarzik> as I suspected
  4 2012-12-05 00:07:04 <jgarzik> odd that the code doesn't drop me, for a crazy "version"
  5 2012-12-05 00:07:22 <jgarzik> just pops right into normal messaging mode
  6 2012-12-05 00:14:54 <jgarzik> w00t
  7 2012-12-05 00:15:19 <jgarzik> forgot the hardcoded detail, where "version" encodes/decodes addrTo and addrFrom addresses as MIN_PROTO_VERSION, not PROTO_VERSION
  8 2012-12-05 00:15:27 <jgarzik> possibly worth a code comment
  9 2012-12-05 00:20:43 <jgarzik> interesting
 10 2012-12-05 00:20:56 <jgarzik> we definitely send "inv"... possibly racing with and sending before "verack"
 11 2012-12-05 00:21:00 <jgarzik> that is... unexpected
 12 2012-12-05 00:21:11 <sipa> really?
 13 2012-12-05 00:21:13 <jgarzik> we just spit out "inv" as fast and as soon as possiblew
 14 2012-12-05 00:24:14 <jgarzik> certainly appears that way, but who knows, might be a bug here
 15 2012-12-05 00:27:06 <BitDev> in Base58Encode as input goes string or array of bytes? (i think second)
 16 2012-12-05 00:28:37 <jgarzik> BitDev: array of bytes
 17 2012-12-05 00:30:49 <BitDev> in EncodeBase58 at while (bn > bn0)  first loop goes out, so from 1 round its goes out - its normal?
 18 2012-12-05 00:32:12 <BitDev> i think not
 19 2012-12-05 00:38:54 <sipa> you know what bn0 is?
 20 2012-12-05 00:48:51 <BitDev> marker of end of number
 21 2012-12-05 00:49:10 <BitDev> i think you understand what i mean
 22 2012-12-05 00:49:22 <BitDev> i found some bugs
 23 2012-12-05 00:52:37 <sipa> such as?
 24 2012-12-05 00:52:46 <BitDev> moment in bignum buffer must go like big endian?
 25 2012-12-05 00:53:05 <BitDev> length of buffer goes like big endian
 26 2012-12-05 00:53:11 <BitDev> but buffer content
 27 2012-12-05 00:53:54 <BitDev> i found in sources answer - yes
 28 2012-12-05 00:57:01 <BitDev> what function and what file are function that convert public key to bitcoin address?
 29 2012-12-05 00:57:09 <BitDev> maybe someone knows
 30 2012-12-05 00:57:35 <Diablo-D3> BitDev: its described on the wiki
 31 2012-12-05 00:57:47 <Diablo-D3> BitDev: you chop the key to 160? bits and then base58 it
 32 2012-12-05 00:58:03 <BitDev> i know, but not working - want to look how it must be done
 33 2012-12-05 00:58:06 <BitDev> yes
 34 2012-12-05 00:58:14 <BitDev> i do like this
 35 2012-12-05 00:58:52 <BitDev> RIPEMD160(Sha256(compressed public key))
 36 2012-12-05 00:59:10 <BitDev> then put 0 at the begining
 37 2012-12-05 00:59:33 <Diablo-D3> shouldnt it be a 1?
 38 2012-12-05 00:59:39 <BitDev> and then Base58Encode with concated checksum (4 bytes)
 39 2012-12-05 00:59:55 <Diablo-D3> BitDev: ask sipa and gmaxwell
 40 2012-12-05 00:59:59 <Diablo-D3> or TD
 41 2012-12-05 01:00:22 <BitDev> if sipa gonna answer me :(
 42 2012-12-05 01:02:40 <sipa> BitDev: take a nice look at the list of source files, and make a guess which one might contain key-related functions
 43 2012-12-05 01:03:07 <sipa> oh, i misread, sorry
 44 2012-12-05 01:03:28 <sipa> addresses and other base58 formats are in base58.h
 45 2012-12-05 01:03:29 <sipa> addresses and other base58 formats are in base58.h
 46 2012-12-05 01:04:37 <sipa> and RIPEMD160(SHA256(compressedpubkey)) is right; then prepend network byte (0x00), then add checksum (4 bytes of double sha256 of everything before), then base58 encode
 47 2012-12-05 01:06:28 <BitDev> hm, so it must be this byte order: [hash160][0] or [0][hash160]?
 48 2012-12-05 01:06:45 <BitDev> if i get it right - first one
 49 2012-12-05 01:06:57 <sipa> prepend means "to put in front"
 50 2012-12-05 01:07:06 <sipa> so first 0x00, then hash160
 51 2012-12-05 01:08:20 <Luke-Jr> (but that's the old address format)
 52 2012-12-05 01:09:12 <BitDev> old address format? what is new address format?
 53 2012-12-05 01:09:22 <sipa> i don't think this is the point where we should explain P2SH yet :)
 54 2012-12-05 01:10:46 <Luke-Jr> BitDev: [5][ripemd160(sha256(scriptRedeem))][checksum]
 55 2012-12-05 01:11:40 <BitDev> Luke - thnx!
 56 2012-12-05 01:13:17 <BitDev> i dont know what is scriptRedeem :(
 57 2012-12-05 01:13:26 <BitDev> and cant find some info
 58 2012-12-05 01:13:40 <sipa> Luke-Jr: you get to explain that to him :p
 59 2012-12-05 01:13:46 <sipa> ACTION -> zZzZ
 60 2012-12-05 01:14:18 <Luke-Jr> BitDev: https://en.bitcoin.it/w/index.php?title=Script
 61 2012-12-05 01:14:51 <Diablo-D3> lol
 62 2012-12-05 01:14:54 <Diablo-D3> luke fails as usual
 63 2012-12-05 01:14:55 <Diablo-D3> luke fails as usual
 64 2012-12-05 01:15:01 <Diablo-D3> BitDev: learn to do it the easy way first
 65 2012-12-05 01:15:02 <BitDev> Luke - thnx very much! i will read it
 66 2012-12-05 01:15:34 <BitDev> ow yea, its hard way )
 67 2012-12-05 01:15:50 <BitDev> and old address will work or not in future?
 68 2012-12-05 01:16:54 <Luke-Jr> BitDev: build a time machine and find out!
 69 2012-12-05 01:17:06 <BitDev> :)
 70 2012-12-05 01:17:13 <BitDev> not bad :)
 71 2012-12-05 01:18:07 <BitDev> i mean - if my client will use old address format - it will correct work with others new address format clients?
 72 2012-12-05 01:32:42 <aethero> Any armory devs in here?
 73 2012-12-05 01:51:44 <hasha> aethero: u can ask etotheipi_
 74 2012-12-05 01:52:08 <aethero> etotheipi_ alive?
 75 2012-12-05 02:54:04 <maaku> was going to ask lindsay but figured I might as well ask here: what size grants will the foundation be giving out?
 76 2012-12-05 02:54:13 <maaku> i'm trying to scale my proposal accordingly
 77 2012-12-05 02:54:14 <maaku> i'm trying to scale my proposal accordingly
 78 2012-12-05 03:11:19 <jgarzik> sipa: RE addrman, comment says "Based on the address range (/16 for IPv4) of source of the information, 32 buckets are selected at random"
 79 2012-12-05 03:11:29 <jgarzik> sipa: how many bits used for IPv6?
 80 2012-12-05 03:11:33 <jgarzik> /64?
 81 2012-12-05 03:19:29 <dparrish> anyone know how the work is going to reduce the amount of disk i/o bitcoind does?
 82 2012-12-05 03:19:46 <dparrish> it's currently doing 73% of the disk io on my home fileserver :(
 83 2012-12-05 03:20:47 <denisx> dparrish: there is alot of work in that area
 84 2012-12-05 03:21:04 <dparrish> good to know :)
 85 2012-12-05 03:22:41 <Hasimir> jgarzik, 128
 86 2012-12-05 03:34:06 <MC1984> damn i remember the last time the price hit 13.37
 87 2012-12-05 03:34:08 <MC1984> gaddam
 88 2012-12-05 04:02:23 <maaku> MC1984: I'm waiting for 133.7
 89 2012-12-05 04:37:08 <jgarzik> man
 90 2012-12-05 04:37:17 <jgarzik> we sure do pass around a lot of useless, long dead addresses
 91 2012-12-05 04:37:42 <jgarzik> and even the mainline client seems to depend on DNS seeds delivering freshness
 92 2012-12-05 04:39:52 <gmaxwell> jgarzik: it works without them, but it can take a while to find good ones.
 93 2012-12-05 04:40:11 <jgarzik> ACTION ponders negative caching -- remembering addresses that _don't_ work, so that picocoin will not forget them, and then receive them again in 'addr', and decide to try them anew
 94 2012-12-05 04:40:24 <jgarzik> gmaxwell: it is indeed taking a while :)
 95 2012-12-05 04:41:23 <jgarzik> ACTION has picocoin timeout connect(2) after 30 seconds.  Have 10,000 peer addresses in the database, as exchanged from peers, but have not yet found a single live address.
 96 2012-12-05 04:41:24 <jgarzik> ACTION has picocoin timeout connect(2) after 30 seconds.  Have 10,000 peer addresses in the database, as exchanged from peers, but have not yet found a single live address.
 97 2012-12-05 04:41:35 <jgarzik> so, rotating through 8 addresses every 30 seconds
 98 2012-12-05 04:42:25 <gmaxwell> and then we find out someone has been attacking the network but we didn't notice. :P
 99 2012-12-05 04:42:50 <jgarzik> right now, picocoin aggressively deletes peer addresses, if a single connection attempt fails
100 2012-12-05 04:43:12 <jgarzik> figuring that it will see new addresses soon enough
101 2012-12-05 04:51:07 <jgarzik> zero successes after 10 minutes.  that's 160 hosts (10 minutes, 30 second connect timeout, maximum 8 peers being attempted at once)
102 2012-12-05 04:53:12 <jgarzik> Maybe bitcoind should only pass along addresses that (a) it's personally connected to/from, or (b) are totally untried.  Pointedly exclude ones we've tried and failed.
103 2012-12-05 04:53:15 <jgarzik> If we don't already do that.
104 2012-12-05 05:34:02 <midnightmagic> whoah, what's up with the old version of bitcoind in ubuntu repos?
105 2012-12-05 05:40:40 <muhoo> is there any signal or interrupt i could register in bitcoind or in some library, to be notified when a transation hits the network that affects one of the addresses in my account?
106 2012-12-05 05:41:14 <muhoo> or, do i have to poll bitcoind continually with json, to watch all the transactions (listtransactions) and manually sort through it looking for new ones?
107 2012-12-05 05:49:47 <muhoo> in other words, some way i could trigger an interrupt upon these:
108 2012-12-05 05:49:48 <muhoo> CTxMemPool::accept() : accepted bdca803929 (poolsz 188)
109 2012-12-05 05:58:53 <jgarzik> muhoo: -blocknotify
110 2012-12-05 06:01:23 <jgarzik> sipa, gmaxwell: when implementing Tor... should SOCKS4 or SOCKS5 be implemented?
111 2012-12-05 06:02:52 <Diablo-D3> 5
112 2012-12-05 06:03:10 <Diablo-D3> 4 leaks DNS info
113 2012-12-05 06:03:20 <midnightmagic> 5a?
114 2012-12-05 06:03:23 <Diablo-D3> and tor bitches if you try to connect with a socks4 app
115 2012-12-05 06:03:34 <Diablo-D3> midnightmagic: you mean 4a?
116 2012-12-05 06:03:41 <Diablo-D3> still doesnt work for what tor needs
117 2012-12-05 06:03:55 <midnightmagic> ... hrm, no i thought 5a.
118 2012-12-05 06:04:20 <Diablo-D3> there isnt one afaik
119 2012-12-05 06:14:38 <muhoo> jgarzik: thanks!
120 2012-12-05 06:20:36 <muhoo> jgarzik: hmm, no. that's not right, it only logs a new block, not every new tx
121 2012-12-05 06:37:23 <jgarzik> muhoo: yes, every new block == each TX, as it is confirmed
122 2012-12-05 06:54:39 <muhoo> well i looked in the source, and printf("CTxMemPool::accept() : accepted %s (poolsz %"PRIszu")\\n",
123 2012-12-05 06:55:08 <muhoo> that's the message. and it doesn't look like anywhere in that function does it trigger the notification
124 2012-12-05 06:55:53 <muhoo> plus i ran it with -blocknotify, and indeed it only notifies of blocks, not transactions. if i were watching for only confirmed transactions, then that'd be what i'd want, sure.  but it isn't what i was looking for
125 2012-12-05 08:14:09 <sipa> jgarzik: RE: address bucket bits for IPv6: see NetAddr::GetGroup
126 2012-12-05 08:15:22 <sipa> dparrish: 0.8 should do a lot less I/O (and almost only sequential wries)
127 2012-12-05 08:15:57 <sipa> jgarzik: addrman also removes unua
128 2012-12-05 08:16:17 <sipa> unused dead address, but only after ae
129 2012-12-05 08:16:34 <sipa> several attempts, i think
130 2012-12-05 08:17:15 <sipa> and aa it mostly tries recent addresses, that takes a long time for old ones
131 2012-12-05 08:17:54 <t7> is leveldb in .8 ?
132 2012-12-05 08:19:59 <sipa> jgarzik: you need socks4 or socks5 to connect to the outside world, but socks5 is the only one that supports hidden addresses
133 2012-12-05 08:21:16 <sipa> t7: yes
134 2012-12-05 08:28:37 <sipa> jgarzik: socks4a also works
135 2012-12-05 08:39:04 <denisx> nice, 20% faster sha1 calculatin https://hashcat.net/p12/js-sha1exp_169.pdf
136 2012-12-05 08:44:43 <_dr> wow
137 2012-12-05 08:46:24 <_dr> denisx: so where can i get/git the kernel for this one? ;)
138 2012-12-05 08:46:46 <denisx> _dr: its only sha1 and not sha256
139 2012-12-05 08:48:01 <_dr> oh :(
140 2012-12-05 10:37:07 <dparrish> sipa: that's good to hear!
141 2012-12-05 11:15:14 <jaromil> Diablo-D3: I knew the opposite, that tor over socks5 leaks dns info and socks4a doesn't. are you 100% sure of your information?
142 2012-12-05 11:15:34 <jaromil> I'm not 100% sure about mine.
143 2012-12-05 11:17:03 <sipa> jaromil: socks4 only supports requesting IP addresses as destination, so clients are required to do DNS lookups yourself
144 2012-12-05 11:17:04 <sipa> jaromil: socks4 only supports requesting IP addresses as destination, so clients are required to do DNS lookups yourself
145 2012-12-05 11:17:20 <jaromil> ack. I had the wrong info then
146 2012-12-05 11:17:30 <jaromil> but wait, i'm talking about socks4a
147 2012-12-05 11:17:31 <jaromil> but wait, i'm talking about socks4a
148 2012-12-05 11:17:33 <sipa> jaromil: socks4a and socks5 support requesting hostnames as destination, which is good, but there is no way to force clients not do do lookups by themself
149 2012-12-05 11:18:08 <jaromil> that for sure... well there is a way ;) iptables on the router
150 2012-12-05 12:32:40 <TD_> BlueMatt: hey
151 2012-12-05 12:33:07 <TD> BlueMatt: FYI there are some findbugs warnings in your full validation code
152 2012-12-05 13:12:48 <gimme_bottles> i need some testcoins, and since the faucet is down i ask here. the address is n4L1GFod511BK7hbV1pXwLVTMNHUNoMWHA , 1 or 2 coins would be enough, thanks in advance
153 2012-12-05 13:15:21 <slush> gimme_bottles: I sent you few spare coins
154 2012-12-05 13:16:08 <gimme_bottles> thanks a lot
155 2012-12-05 13:16:22 <slush> gimme_bottles: did you say "10-20k would be enough"?
156 2012-12-05 13:17:01 <gimme_bottles> haha, transaction just arrived, i though what?!?
157 2012-12-05 13:17:50 <slush> dealing with thousands of coins is much more fun
158 2012-12-05 13:17:52 <gimme_bottles> i'll send them back when i finished testing my app
159 2012-12-05 13:18:01 <slush> no problem, I still have few tens of thousands
160 2012-12-05 13:18:06 <slush> send them to testnet then
161 2012-12-05 13:18:12 <gimme_bottles> ok
162 2012-12-05 13:27:06 <MyBits> can some one help me? here is transaction: http://blockexplorer.com/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b  - how to calculate ScriptSig value?
163 2012-12-05 13:27:57 <MyBits> no one knows?
164 2012-12-05 13:30:45 <sipa> scriptsig of which txin?
165 2012-12-05 13:31:29 <MyBits> how to calculate this value?
166 2012-12-05 13:33:02 <sipa> what do you want? the scriptsigs that transaction contains, or the scriptsig a transaction input would need to spend one of the outputs of that transaction?
167 2012-12-05 13:35:11 <MyBits> how to calculate scriptsigs of inputs and how to calculate scriptsigs of outputs points
168 2012-12-05 13:38:35 <nsdyu> you can Error in this channel log.
169 2012-12-05 13:39:05 <sipa> MyBits: only txins have scriptsigs; txouts have scriptpubkeys (both are scripts, and the name is a bit confusing nowaways)
170 2012-12-05 13:39:18 <sipa> the scripts in outputs are basically just expanded versions of the address sent to
171 2012-12-05 13:39:43 <nsdyu> you can see Error in this channel log.
172 2012-12-05 13:39:44 <nsdyu> you can see Error in this channel log.
173 2012-12-05 13:40:37 <sipa> the scripts in inputs provide the data to make the scripts in the outputs they are spending evaluate to true
174 2012-12-05 13:41:08 <sipa> but it's a bit much to explain entirely over chat... try understand the script system first
175 2012-12-05 13:41:43 <MyBits> where can i read about script system?
176 2012-12-05 13:42:12 <nsdyu> sipa every sentence saved double check log
177 2012-12-05 13:42:57 <sipa> MyBits: the wiki has an extensive page about it, but it certainly isn't detailed enough to write your own transaction creation
178 2012-12-05 13:43:07 <sipa> MyBits: if you need that level, go check the source code of any client
179 2012-12-05 13:52:20 <MC1984> "Half of all app store revenue goes to just 25 developersHalf of all app store revenue goes to just 25 developers"
180 2012-12-05 13:52:31 <MC1984> jesus welcome to the future of computing
181 2012-12-05 13:53:02 <helo> jesus says thanks for the warm welcome
182 2012-12-05 13:54:26 <MC1984> ih i keep posting this shit is the wrong room
183 2012-12-05 13:59:36 <MyBits> how to create coinbase transaction?
184 2012-12-05 13:59:45 <MyBits> some one know it?
185 2012-12-05 14:09:11 <MyBits> no one knows?
186 2012-12-05 14:09:12 <MyBits> no one knows?
187 2012-12-05 14:11:05 <BlueMatt> ;;later tell TD thanks, Ill take a look and see what needs fixing
188 2012-12-05 14:11:06 <gribble> The operation succeeded.
189 2012-12-05 14:18:59 <MyBits> sipa if i get it right if txn is coinbase (mining) in inputs scriptSign - is random value and in outputs is ECDSA signed that value?
190 2012-12-05 14:21:04 <sipa> outputs never contain signatures; they just state who is allowed to spend it
191 2012-12-05 14:25:39 <MyBits> sipa how to create this coinbase txn?
192 2012-12-05 14:25:52 <MyBits> i still dont get it
193 2012-12-05 14:26:13 <sipa> any byte sequence that doesn't break any rules is good :)
194 2012-12-05 14:28:48 <MyBits> sipa - tx_in previous_output (hash 0) script length and signature script - how to calculate it?
195 2012-12-05 14:29:22 <sipa> MyBits: i think you really need to understand the big picture before trying to go into those details
196 2012-12-05 14:30:16 <MyBits> and how can i see whole picture?
197 2012-12-05 14:30:29 <MyBits> i understand every think except this
198 2012-12-05 14:42:21 <MyBits> if coinbase txn - then ScriptPubKey is just public key, but i still dont get it - what is ScriptSig in txn_in (inputs)
199 2012-12-05 14:51:56 <MyBits> i make some research and i found out - then if txn is first one (mining txn) then scriptSign can be anything in inputs and in outputs its public key - that is correct?
200 2012-12-05 14:53:05 <sipa> the first transaction in every block is the coinbase transaction, and it always has exactly one txin (the coinbase), with special values for prevout, and the scriptSig of the coinbase transaction is otherwise ignored (but required to be between 2 and 100 bytes)
201 2012-12-05 14:53:33 <sipa> well... *almost* ignored
202 2012-12-05 14:54:12 <MyBits> so its random value that must be between 2 and 100 bytes long?
203 2012-12-05 14:54:25 <sipa> the scriptSig of the coinbase, yes
204 2012-12-05 14:54:32 <sipa> not random, but arbitrary
205 2012-12-05 14:55:28 <t7> you can put a message in there :3
206 2012-12-05 14:55:32 <MyBits> and what official client puts there - random value?
207 2012-12-05 14:55:35 <MyBits> :)
208 2012-12-05 14:56:00 <gmaxwell> No even arbritary anymore. :)
209 2012-12-05 14:56:32 <gmaxwell> MyBits: it puts the extranonce in there, a value that gets incremented as it mines to make coinbase txn unique.
210 2012-12-05 14:56:37 <sipa> since v==2 blocks, there is indeed an extra requirement: it must start with the serialized block height
211 2012-12-05 14:56:50 <gmaxwell> ^ and that.
212 2012-12-05 14:57:55 <MyBits> serialized block height? what its mean?
213 2012-12-05 14:58:08 <t7> the binary representation of
214 2012-12-05 14:58:35 <t7> or ascii ?
215 2012-12-05 14:58:58 <sipa> ascii is a way of encoding text in bytes
216 2012-12-05 14:59:00 <t7> its when you make something suitable for (network) transport
217 2012-12-05 14:59:09 <sipa> not for numbers
218 2012-12-05 14:59:13 <jgarzik> sipa: ACK, thanks for the addrman and Tor/SOCKS info
219 2012-12-05 14:59:48 <t7> sipa actually its 7 bits :)
220 2012-12-05 15:00:12 <sipa> agree
221 2012-12-05 15:00:18 <sipa> anyway... no it's using a binary encoding
222 2012-12-05 15:06:18 <MyBits> and sequence in txn header is -1 ?
223 2012-12-05 15:07:12 <sipa> no, 0xFFFFFFFF
224 2012-12-05 15:07:22 <sipa> at least if you want the transaction to be non-replaceable
225 2012-12-05 15:07:57 <MyBits> tnx
226 2012-12-05 16:48:30 <gavinandresen> sipa luke-jr : my gitian build matched sipa's, lets release:  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.2/test/?
227 2012-12-05 16:50:23 <drizztbsd> is 0.7.2 tagged?
228 2012-12-05 16:51:30 <gavinandresen> drizztbsd: I'll push the 0.7.2rc2 tag to github (give luke a hard time for using gitorious for me, please)
229 2012-12-05 16:52:17 <drizztbsd> oh, rc2
230 2012-12-05 16:53:20 <gavinandresen> I expect with 98% probability rc2 will be the final 0.7.2 release.
231 2012-12-05 16:53:42 <sipa> gavinandresen: both linux and win32?
232 2012-12-05 16:53:50 <gavinandresen> sipa: yes, both matched
233 2012-12-05 16:53:55 <sipa> good
234 2012-12-05 16:54:47 <jgarzik_> This is a fun experiment.  picocoin is slowly working through 13,000 hosts that peers have given to it by other peers... while avoiding DNS seeds completely.  So far, haven't found a single working bitcoin host, and have tried just over 1,000.
235 2012-12-05 16:55:14 <jgarzik_> We are really passing a ton of useless addresses around, and keeping them alive too long.
236 2012-12-05 16:55:35 <phantomcircuit> jgarzik_, there's ~400k peers being broadcast
237 2012-12-05 16:55:40 <phantomcircuit> ~4k peers connectable
238 2012-12-05 16:55:45 <jgarzik_> yep
239 2012-12-05 16:55:50 <jgarzik_> I can believe it
240 2012-12-05 16:56:02 <gavinandresen> "patches welcome"
241 2012-12-05 16:56:09 <phantomcircuit> i should start keeping track of who told me about which peer
242 2012-12-05 16:56:12 <gmaxwell> 400k? since when? well I suppose _that_ is an attack. though a somewhat lame one.
243 2012-12-05 16:56:22 <phantomcircuit> i think there's a small number of peers that are throwing round bullshit
244 2012-12-05 16:56:51 <jgarzik_> My initial seeding (DNS seed + connect to 8 + request addresses) only produced just over 14,000 unique addresses.
245 2012-12-05 16:57:17 <jgarzik_> Obviously that is smaller than connecting to -everybody- and requesting addresses, but still.
246 2012-12-05 16:57:39 <phantomcircuit> well maybe not
247 2012-12-05 16:57:43 <jgarzik_> I think addrman should maybe pass along fewer unknown-quality addresses.
248 2012-12-05 16:57:43 <sipa> jgarzik_: do you prioritize addresses with a recent timestamp?
249 2012-12-05 16:57:53 <phantomcircuit> the total number of peers i've seen hasn't signiticantly changed in a while now
250 2012-12-05 16:58:06 <phantomcircuit> so i guess there is just a huge stock of peers that are old or not connectable
251 2012-12-05 16:58:17 <sipa> my seeder considers around 2000 nodes well-reachable
252 2012-12-05 16:58:20 <jgarzik_> sipa: I have a last_ok and last_fail timestamp.  Zero is default for both, if never tried.
253 2012-12-05 16:58:42 <sipa> jgarzik_: i mean the timestamp in the addr packets
254 2012-12-05 16:58:53 <sipa> if that is too old, ignore it
255 2012-12-05 16:58:57 <jgarzik_> sipa: that field appears to be useless
256 2012-12-05 16:59:23 <gmaxwell> Why do you say that?
257 2012-12-05 16:59:24 <gmaxwell> Why do you say that?
258 2012-12-05 16:59:51 <jgarzik_> because we assign random values to it
259 2012-12-05 17:00:50 <gmaxwell> jgarzik_: while my memory is failing me, I thought that the randomness was bounded.
260 2012-12-05 17:00:51 <sipa> yes, but we never increment it witgout seeing the node alive, afaik
261 2012-12-05 17:01:39 <jgarzik_> when looking at the network as a whole it still results in some addresses being refreshed needlessly
262 2012-12-05 17:01:47 <gmaxwell> E.g. if you see a really old one you know its really old (or at least the peer is lying, but if it wanted you to not connect to something it could just not tell you about it)
263 2012-12-05 17:02:22 <sipa> well, that is why we need host keys, with the timestamp signed by the host itself
264 2012-12-05 17:04:05 <jgarzik_> looks like addrman just returns a shuffle of vRandom
265 2012-12-05 17:04:09 <sipa> yes
266 2012-12-05 17:04:15 <jgarzik_> when it should probably filter out old addresses
267 2012-12-05 17:04:35 <sipa> old addresses get filtered out eventually anyway
268 2012-12-05 17:05:05 <jgarzik_> "eventually" is the problem ;p
269 2012-12-05 17:05:18 <jgarzik_> we should not pass crappy data to others ;p
270 2012-12-05 17:27:51 <jgarzik_> net: 98.226.154.206 addr(1000 addresses, 164 old)
271 2012-12-05 17:27:52 <jgarzik_> net: 98.226.154.206 addr(1000 addresses, 164 old)
272 2012-12-05 17:27:57 <jgarzik_> not quite as bad as I had feared
273 2012-12-05 17:28:03 <jgarzik_> "old" is defined as older than 7 days
274 2012-12-05 17:38:23 <jgarzik> also quite pleased that picocoin is happily talking to IPv6 nodes
275 2012-12-05 17:38:30 <jgarzik> that part Just Worked(tm)
276 2012-12-05 17:39:53 <gmaxwell> jgarzik: well thats bad, enh? right because if you're not getting old data and the data is still bad then the old exclusion doesn't save you.
277 2012-12-05 17:41:04 <phantomcircuit> there's still a lot of old peers out there
278 2012-12-05 17:41:07 <jgarzik> gmaxwell: having difficulty parsing that
279 2012-12-05 17:41:15 <jgarzik> gmaxwell: we -are- getting old data
280 2012-12-05 17:41:18 <jgarzik> and sending it
281 2012-12-05 17:41:19 <phantomcircuit> they pretty much just give you a random sampling of any peer they have ever heard about
282 2012-12-05 17:43:20 <gmaxwell> jgarzik: I'm saying that if only a small part of your data is old, and you're still slow connecting then excluding old data will not help much with your connection speed.
283 2012-12-05 17:44:22 <jgarzik> gmaxwell: Yes, the focus on the general problem has narrowed to a smaller, related problem that was noticed
284 2012-12-05 17:45:14 <jgarzik> picocoin's rule of 8 parallel connect(3) w/ 30 second timeout must get much more aggressive, when sorting through the garbage
285 2012-12-05 17:45:41 <jgarzik> Will probably up that to ... 25 parallel connect(2), if no love after startup+30 sec
286 2012-12-05 17:46:27 <jgarzik> But I also wanted to tackle the side problem of remembering, and passing around, too many dead peers for too long
287 2012-12-05 17:46:53 <jgarzik> Fixing picocoin's behavior does not address that general stupidity ;p
288 2012-12-05 17:47:51 <phantomcircuit> jgarzik, best way to do it is to have ~100 parallel connection attempts and then drop them when you have your 8 peers
289 2012-12-05 17:49:24 <jgarzik> phantomcircuit: not sure where to draw the line.  I know that some networks flag that as abusive behavior.
290 2012-12-05 17:49:44 <phantomcircuit> 100 is about the point at which some home routers basically melt
291 2012-12-05 17:49:45 <jgarzik> Definitely should not do 100 immediately, if you wind up with fresh addresses.
292 2012-12-05 17:50:01 <jgarzik> That's why I like the rule "8 parallel at first, increase if no love"
293 2012-12-05 17:50:08 <phantomcircuit> jgarzik, start at 0
294 2012-12-05 17:50:14 <phantomcircuit> every second try another
295 2012-12-05 17:50:31 <phantomcircuit> most peers will connect in < 1 second
296 2012-12-05 17:50:52 <phantomcircuit> if you have good peer info you'll never get past a dozen connections
297 2012-12-05 19:06:19 <jgarzik> ACTION anxiously awaits BlueMatt and TD[gone]'s BIP 37 deployment
298 2012-12-05 19:06:33 <jgarzik> it will be nice to save bandwidth by -not- sending "inv" to those who don't care
299 2012-12-05 19:06:34 <jgarzik> it will be nice to save bandwidth by -not- sending "inv" to those who don't care
300 2012-12-05 19:45:27 <ciscoftw> who created satoshi dice?
301 2012-12-05 19:45:28 <ciscoftw> who created satoshi dice?
302 2012-12-05 19:47:16 <weex> ciscoftw: you're looking for the programmer?
303 2012-12-05 19:47:51 <ciscoftw> yeah, the dev who created it. its fucking boss!
304 2012-12-05 19:49:31 <helo> you will not find many in here who agree
305 2012-12-05 19:51:09 <weex> i'm sure many could code the same thing
306 2012-12-05 19:51:20 <weex> but i have no idea who the coder wasa
307 2012-12-05 19:52:05 <helo> the only hard part is getting a decentralized virtual currency up and running :/
308 2012-12-05 19:52:30 <weex> to create a game like satoshi dice, first you must create the universe
309 2012-12-05 19:53:01 <ciscoftw> its not just the game, its the concepts behind it, regarding his disclousre/verification of secrets etc
310 2012-12-05 19:53:19 <jurov> iirc bitcoin.it details from who erik bought it
311 2012-12-05 19:53:25 <sipa> i think the only innovative thing about SD is their reuse of unconfirmed inputs
312 2012-12-05 19:53:35 <weex> ciscoftw: the secret thing i never saw before some kamikaze site
313 2012-12-05 19:53:49 <weex> what sipa said
314 2012-12-05 19:58:36 <gmaxwell> ciscoftw: there have been _many_ gambling sites with verification.
315 2012-12-05 19:59:30 <gmaxwell> (e.g. http://bitjack21.com/cryptoproof )
316 2012-12-05 20:02:12 <gmaxwell> (or http://ragecoin.appspot.com/  or well pick one??? it's pretty common)
317 2012-12-05 20:02:53 <gmaxwell> What most of these schemes can't do is show you that the house isn't mostly playing itself or rigging results for selected patrons, however. Which isn't an important property usually, but some people are confused about that.
318 2012-12-05 20:02:54 <gmaxwell> What most of these schemes can't do is show you that the house isn't mostly playing itself or rigging results for selected patrons, however. Which isn't an important property usually, but some people are confused about that.
319 2012-12-05 20:06:29 <ciscoftw> gmaxwell: this is why i find sd interesting
320 2012-12-05 20:09:57 <helo> because it may be dishonest despite appearing to be honest?
321 2012-12-05 20:18:18 <amiller> i showed some friends satoshidice and everyone flipped out and played it for hours :/
322 2012-12-05 20:18:31 <sipa> you have strange friends!
323 2012-12-05 20:20:07 <Pucilowski> whats the logic behind change addresses? Why can't the change just be sent back to the address the money's coming from
324 2012-12-05 20:20:17 <gmaxwell> ciscoftw: because it's like everything else?
325 2012-12-05 20:20:19 <sipa> Pucilowski: privacy
326 2012-12-05 20:20:34 <gmaxwell> ciscoftw: SD is also in the "most of these schemes can't do" I described.
327 2012-12-05 20:21:28 <helo> Pucilowski: it makes analysis of bitcoin flow and identities much more difficult
328 2012-12-05 20:21:46 <phantomcircuit> amiller, gambling addicts are addicts
329 2012-12-05 20:21:47 <phantomcircuit> amiller, gambling addicts are addicts
330 2012-12-05 20:21:59 <ciscoftw> not sure i understand sd enought to disagree... but it appears it is impossible for house to cheat or have predefined secret key used to identify lucky number
331 2012-12-05 20:22:00 <ciscoftw> not sure i understand sd enought to disagree... but it appears it is impossible for house to cheat or have predefined secret key used to identify lucky number
332 2012-12-05 20:24:14 <gmaxwell> ciscoftw: You are reading something into my statement which I did not intend to say.
333 2012-12-05 20:24:46 <sipa> ciscoftw: they could (for one day) tell everyone they lost, and at the same time play the game themself so that it seems the expected number of winnings occur
334 2012-12-05 20:25:14 <gmaxwell> ciscoftw: They know all the future secrets. They can use that knoweldge to generate winning and losing transactions... or to help you generate winning and losing transactions.
335 2012-12-05 20:25:18 <gmaxwell> sipa: interesting point!
336 2012-12-05 20:25:47 <gmaxwell> (the misunderstanding I was speaking to mostly has come up with respect to SD share holders, or people claiming that it couldn't be used for money laundering)
337 2012-12-05 20:27:50 <phantomcircuit> sipa, actually they cant
338 2012-12-05 20:28:07 <phantomcircuit> the txid is used in calculating whether a tx is a winner/loser
339 2012-12-05 20:28:22 <phantomcircuit> they couldn't possibly control that
340 2012-12-05 20:28:30 <sipa> phantomcircuit: but they don need to reveal that for one day
341 2012-12-05 20:28:47 <sipa> they could change the formule one day to "everyone loses, except when we play ourself"
342 2012-12-05 20:28:49 <phantomcircuit> so?
343 2012-12-05 20:29:02 <sipa> it means they can run will the bet income from one day
344 2012-12-05 20:29:11 <phantomcircuit> people know who runs it
345 2012-12-05 20:29:12 <phantomcircuit> people know who runs it
346 2012-12-05 20:29:17 <phantomcircuit> i dont think they'd get very far with that
347 2012-12-05 20:29:25 <sipa> well, if you trust who runs it, why the trick with the txid anyway?
348 2012-12-05 20:29:32 <phantomcircuit> especially when you consider the degenerate gamblers who tend to use it...
349 2012-12-05 20:29:45 <sipa> i'm just saying their scheme isn't theoretically perfect
350 2012-12-05 20:29:52 <sipa> not saying that this is a problem in practice
351 2012-12-05 20:29:54 <phantomcircuit> sipa, it limits their stealing to a single 24 hour window
352 2012-12-05 20:29:58 <amiller> if SD says that someone loses who shouldn't have lost, then the would-be loser would be able to prove that it occurred
353 2012-12-05 20:30:04 <sipa> yes, i never claimed otherwise
354 2012-12-05 20:30:15 <phantomcircuit> which is very small compared to how other gambling sites have stolen from people over the course of years
355 2012-12-05 20:30:18 <amiller> they wouldn't be able to resume normal operation the next day
356 2012-12-05 20:30:19 <sipa> but from a perfect scheme i would expect this window to be 0
357 2012-12-05 20:30:40 <phantomcircuit> the window could actually be reduced to a single game
358 2012-12-05 20:30:48 <phantomcircuit> but i dont think anybody cares enough to do that
359 2012-12-05 20:30:51 <amiller> i see they'd only be able to prove it after the 24 hr went by
360 2012-12-05 20:30:55 <phantomcircuit> these are gamblers after all
361 2012-12-05 20:31:36 <ciscoftw> thanks for discussion all
362 2012-12-05 20:32:15 <phantomcircuit> sipa, i think it's far more likely that they're going to screw up and lock you funds away as an unspendable transaction for days/weeks
363 2012-12-05 20:33:16 <sipa> yeah, their use-inputs-for-payout mechanism means they are by themself protected from damage by 51%/finney attacks, but their players aren't
364 2012-12-05 20:35:13 <helo> the txid is used, so can't they permute something in their tx until they get one that will pay them?
365 2012-12-05 20:35:38 <sipa> ?
366 2012-12-05 20:35:54 <sipa> sure, that's exactly what they can do
367 2012-12-05 20:37:13 <flatfly> https://spideroak.com/blog/20121205114003-exploit-information-leaks-in-random-numbers-from-python-ruby-and-php
368 2012-12-05 20:37:25 <flatfly> Does this affect the RNG(s) used in Bitcoin in any way?
369 2012-12-05 20:44:49 <helo> bitcoin doesn't use any of those directly, so first guess is 'no'
370 2012-12-05 20:46:29 <jgarzik> unsigned int CNetAddr::GetByte(int n) const
371 2012-12-05 20:46:36 <jgarzik> ahhhhhhhhhhhhhhhh  *facepalm*  *facepalm*
372 2012-12-05 20:46:53 <jgarzik> ACTION now has to go back and reverse all the offsets in his code
373 2012-12-05 20:47:36 <gmaxwell> I contemplated asking how you were deseralizing the values... I guess I should have!
374 2012-12-05 20:50:07 <sipa> jgarzik: the first rule of bitcoin is to always doubt the byte order :P
375 2012-12-05 20:52:18 <jgarzik> hehe
376 2012-12-05 20:52:21 <BlueMatt> jgarzik: yep, as soon as exams are done (or TD does it)
377 2012-12-05 20:57:42 <ciscoftw> bluematt: did you create a bitcoin protocol dissector via wireshark?
378 2012-12-05 20:58:00 <BlueMatt> me? no, I had nothing to do with that
379 2012-12-05 20:58:06 <BlueMatt> its a shame the author disappeared
380 2012-12-05 20:58:16 <ciscoftw> yeah it is
381 2012-12-05 20:58:31 <ciscoftw> sux someone else is using your handle
382 2012-12-05 20:58:52 <BlueMatt> where did you see my handle creating it?
383 2012-12-05 20:59:08 <BlueMatt> na, it was done by blueCommand
384 2012-12-05 20:59:14 <ciscoftw> ummmm, ur right my bad
385 2012-12-05 21:09:06 <sipa> jgarzik, gmaxwell: ACK on #2056?
386 2012-12-05 21:09:52 <sipa> gavinandresen: opinion on #2059, as you've NAK'd benchmarking things in the past?
387 2012-12-05 21:12:06 <gavinandresen> sipa: ack'ed.  I've been tempted in the past to create a little benchmarking class to avoid the repetitive start = gettime(); ....  printf(now-start) ...
388 2012-12-05 21:12:50 <jgarzik> kinda like the CImportingNow class ;p
389 2012-12-05 21:13:11 <gavinandresen> (back later, chauffeuring kids)
390 2012-12-05 21:13:59 <sipa> yes, nothing as fun as overusing RAII :p
391 2012-12-05 21:35:40 <sipa> off-topic: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454
392 2012-12-05 21:36:47 <sipa> " If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes."
393 2012-12-05 21:43:19 <upb> yes
394 2012-12-05 21:49:09 <ThomasV> lol
395 2012-12-05 21:54:32 <nanotube> gavinandresen: so who reviews the grant proposals?
396 2012-12-05 23:44:15 <gavinandresen> nanotube: Foundation Board will decide how much of the budget to give to grants, then review the proposals. At least, that's the way it will work to start, maybe at some point there will be a Grant Review Subcommittee or something.
397 2012-12-05 23:45:34 <nanotube> ah ok, sounds good.
398 2012-12-05 23:46:26 <nanotube> keep in mind that if you don't get any good proposals, you don't have to fund anything this first period. don't feel like you have to fund /something/ ;)
399 2012-12-05 23:47:19 <gavinandresen> absolutely
400 2012-12-05 23:48:19 <nanotube> also, make sure sumbissions to GSOC for next year are on your todolist
401 2012-12-05 23:48:25 <gavinandresen> The core dev team already got a grant, by the way.  I'll be mentioning that in a week or so (it'll be my turn to post something on the Foundation's blog)
402 2012-12-05 23:48:33 <nanotube> iirc they post the rfps around february, so it's just around the corner.
403 2012-12-05 23:48:45 <nanotube> cool cool!
404 2012-12-05 23:49:26 <nanotube> we kinda missed gsoc last year, hopefully this year we can get in on google summer of code.
405 2012-12-05 23:50:22 <gavinandresen> I dunno... more code isn't really our bottleneck right now.  Testing still is (sigh)
406 2012-12-05 23:50:43 <nanotube> well, here's a gsoc project: test suite for bitcoin to test x,y,z :)
407 2012-12-05 23:50:49 <nanotube> perfect fit! :)
408 2012-12-05 23:53:06 <nanotube> i think a well-put-together proposal for test code would be just as competitive as anything else.
409 2012-12-05 23:54:09 <nanotube> anyway just a suggestion - i don't actually know if they have more specific guidelines...
410 2012-12-05 23:55:41 <gavinandresen> good idea... remind me again in January...
411 2012-12-05 23:58:04 <nanotube> ;:scheduler add [seconds 30d] later tell nanotube remind gavinandresen about gsoc. :)
412 2012-12-05 23:58:17 <nanotube> heh
413 2012-12-05 23:58:39 <gavinandresen> wow, will that actually work?
414 2012-12-05 23:58:42 <nanotube> yes
415 2012-12-05 23:58:57 <nanotube> though if gribble's vps gets rebooted in the meantime, he'll lose the scheduled event
416 2012-12-05 23:59:02 <gavinandresen> ;:scheduler add [seconds 30d] later tell gavinandresen figure out how GSOC works
417 2012-12-05 23:59:21 <nanotube> well, it'd have to be ;; not ;: :) i deliberately didn't actually trigger the bot
418 2012-12-05 23:59:38 <gavinandresen> ;;scheduler add [seconds 30d] later tell member:gavinandresen figure out how GSOC works
419 2012-12-05 23:59:38 <gribble> Error: You don't have the scheduler.add capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
420 2012-12-05 23:59:45 <nanotube> and... that too.
421 2012-12-05 23:59:48 <gavinandresen> awwww
422 2012-12-05 23:59:50 <gribble> The operation succeeded.  Event #10 added.
423 2012-12-05 23:59:50 <nanotube> ;;scheduler add [seconds 30d] later tell member:gavinandresen figure out how GSOC works
424 2012-12-05 23:59:56 <nanotube> there :)