1 2013-03-11 00:00:43 <HM> Luke-Jr: lol, not bitcoind rpc's
  2 2013-03-11 00:00:46 <HM> this is something i'm working on
  3 2013-03-11 00:03:54 <sipa> Luke-Jr: what % of 0.8 nodes do you see?
  4 2013-03-11 00:55:15 <Luke-Jr> sipa: 38%  http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
  5 2013-03-11 00:55:50 <sipa> Luke-Jr: hmm, nice
  6 2013-03-11 00:56:21 <sipa> i get a reachability-weighted ratio of 47% even
  7 2013-03-11 00:56:36 <Luke-Jr> reachability-weighted?
  8 2013-03-11 00:57:31 <sipa> count each node weighted by its reachability%
  9 2013-03-11 01:04:11 <CodeShark> might such statistics not be skewed by whether nodes accept incoming connections?
 10 2013-03-11 01:04:37 <sipa> i wouldn't say skewed; it's literally what i'm calculating
 11 2013-03-11 01:05:16 <sipa> of course it won't match the population of all nodes
 12 2013-03-11 01:05:33 <sipa> but there's no way to observe those anyway
 13 2013-03-11 01:05:39 <warren> 0.3.x nodes are still compatible?!
 14 2013-03-11 01:05:48 <sipa> yes
 15 2013-03-11 01:06:04 <sipa> there has never been a hardfork, ever
 16 2013-03-11 01:06:10 <CodeShark> I'm saying that even major hub nodes might not be ranked too high by a bot if, say, the hub nodes have long lists of connect=
 17 2013-03-11 01:06:12 <warren> ah
 18 2013-03-11 01:06:28 <sipa> and only one backward-incompatible network protocol change (which kicked off pre=0.2.10 nodes)
 19 2013-03-11 01:06:55 <doublec> sipa: p2sh didn't count as a hard fork?
 20 2013-03-11 01:07:01 <sipa> doublec: absolutely not
 21 2013-03-11 01:07:21 <sipa> that was only a softfork (=backward compatible)
 22 2013-03-11 01:07:24 <doublec> ok, I thought a bunch of nodes got orphaned blocks after that
 23 2013-03-11 01:07:33 <sipa> yes, it was a fork, but not a hard one
 24 2013-03-11 01:08:06 <sipa> the difference is that in the case of a soft fork, only those mining on the old chain are vulnerable, but never those trusting the longest chain
 25 2013-03-11 01:08:21 <sipa> while in a hardfork, every old client is dropped on the fork
 26 2013-03-11 01:08:33 <doublec> ah ok
 27 2013-03-11 01:08:55 <sipa> hence, softforks are safe as soon as a supermajority of miners upgrades
 28 2013-03-11 01:09:07 <sipa> hardforks are safe as soon as _everyone_ (not just miners) upgrade
 29 2013-03-11 01:09:54 <doublec> that makes sense, thanks
 30 2013-03-11 01:13:11 <Luke-Jr> sipa: there has..
 31 2013-03-11 01:13:47 <warren> Luke-Jr: is that nodes that are listening only?
 32 2013-03-11 01:13:49 <Luke-Jr> sipa: when most script opcodes were disabled, for example
 33 2013-03-11 01:13:52 <Luke-Jr> warren: yes
 34 2013-03-11 01:13:53 <sipa> Luke-Jr: softfork
 35 2013-03-11 01:14:29 <Luke-Jr> hmm
 36 2013-03-11 01:14:35 <sipa> (clients which have all opcodes enabled still, will still validate the new best chain)
 37 2013-03-11 01:14:53 <Luke-Jr> yeah, I guess you're right then
 38 2013-03-11 01:15:16 <sipa> at that point in time the difference probably didn't matter much
 39 2013-03-11 01:15:41 <sipa> and the OP_RETURN related bugs were probably bad enough that if a hardfork had been necessary to fix them, it wouldn't have been a problem
 40 2013-03-11 01:16:45 <sipa> i wonder whether the OP_RETURN change (instead of evaluating input + OP_CODESEP + output, evaluate both separately) can result in something that is now accepted but wasn't back then
 41 2013-03-11 01:16:57 <sipa> if that's the case, it was a hardfork, though i can't think of anything
 42 2013-03-11 02:03:29 <HM> "It's like playing Satoshi Dice, only you are using your bitcoins to buy something epic, supporting models, contributing to charity, and getting something in return."
 43 2013-03-11 02:03:30 <64MACUB4N> standard bitcoin client transaction fee are insane! http://blockchain.info/it/tx/e5767544f082391517c03e452d793c5d6e8d99bc617f13eb89c430f3dfab842e
 44 2013-03-11 02:47:58 <Lophie> hello, anyone interested in a conversation regarding electrum
 45 2013-03-11 02:48:15 <Lophie> I have things I need to know and don't know where to find
 46 2013-03-11 02:48:25 <Lophie> and yes I tried google o_o
 47 2013-03-11 02:50:40 <phantomcircuit> did you try #electrum
 48 2013-03-11 03:31:14 <Lophie> brb
 49 2013-03-11 03:36:11 <unknown45682> hi
 50 2013-03-11 04:34:24 <bonks> In bitcoin-qt 0.8 I tried the importprivkey command via the Debug window, and any subsequent command does sent does not return a response. Is this expected behavior?
 51 2013-03-11 04:35:02 <bonks> s/command does/command
 52 2013-03-11 04:47:14 <bonks> That was weird. So I saw it appear in my address book. Then decided to restart bitcoin-qt. It took several minutes to shut down. I started it again and the address moved from my Address book to Receive coins, where I expected it.
 53 2013-03-11 04:53:22 <bonks> Oh I think I understand it now, it'll just take a long time to process
 54 2013-03-11 04:53:24 <bonks> :x
 55 2013-03-11 05:04:07 <warren> bonks: I heard something about it rescanning the entire blockchain after import key (
 56 2013-03-11 05:08:55 <bonks> warren: Yea I just realized that in help rescan is the last parameter and defaulted to true
 57 2013-03-11 05:09:01 <bonks> On my linux box I did not see that
 58 2013-03-11 05:09:36 <warren> I think it can't know your balance if you don't rescan?
 59 2013-03-11 05:10:10 <bonks> Probably. I'm just discovering paper wallets and am testing it out :)
 60 2013-03-11 05:14:01 <jgarzik> https://twitter.com/bitcoininfo/status/310949558102401024
 61 2013-03-11 05:14:06 <jgarzik> "Confirmation time vs price: Another reason to keep the blocksize where it is? http://ur1.ca/d18t6  #bitcoin
 62 2013-03-11 05:17:43 <warren> What does he mean by "slower miners"?
 63 2013-03-11 05:49:29 <CodeShark> dunno - not sure that part really makes sense
 64 2013-03-11 05:49:48 <CodeShark> the time to include new transactions (including the network latency until the miner sees the transaction) is negligible in comparison with the time it takes to mine a block
 65 2013-03-11 05:51:58 <warren> supposedly including more tx's increases your chances of orphans, but I haven't seen the math of that
 66 2013-03-11 05:53:14 <CodeShark> you mean deadend sidechains?
 67 2013-03-11 05:53:45 <CodeShark> I hate the usage of the term "orphan" to refer to a sidechain since this usage has absolutely nothing to do with the way the term is normally understood in the English language - which is something without parents
 68 2013-03-11 05:54:06 <CodeShark> and we absolutely need a term to refer to blocks that don't have known parents
 69 2013-03-11 05:54:10 <CodeShark> and the term "orphan" is perfect :)
 70 2013-03-11 05:54:50 <sivu> bastards instead?
 71 2013-03-11 05:55:01 <CodeShark> heh, that's not bad
 72 2013-03-11 05:55:01 <sivu> for the sidechain
 73 2013-03-11 05:55:14 <CodeShark> I've also heard "extinct" proposed
 74 2013-03-11 05:55:36 <CodeShark> an extinct block is a block which nobody mines against anymore
 75 2013-03-11 05:55:49 <CodeShark> which is not in the main chain
 76 2013-03-11 05:56:19 <sivu> thats more like evolutionary misstep than extinction because the block still exists
 77 2013-03-11 05:56:34 <CodeShark> yeah, true
 78 2013-03-11 05:56:50 <CodeShark> and in principle it could be brought back to life (with sufficient computational power)
 79 2013-03-11 05:58:10 <CodeShark> bastard block isn't that bad :)
 80 2013-03-11 05:58:28 <CodeShark> lol
 81 2013-03-11 06:00:31 <CodeShark> anyhow, getting back to warren's comment - how would including more tx's increase chances of bastard blocks? I suppose if two blocks are mined at around the same time and a miner sees both he might choose to mine against the smaller block so he can pocket fees from transactions in the other
 82 2013-03-11 06:02:03 <CodeShark> also, sending a larger block takes slightly longer so some might argue it propagates a little more slowly (although I doubt this is significant)
 83 2013-03-11 06:02:07 <weex> it takes longer for each relaying node to validate blocks with more transactions in them
 84 2013-03-11 06:02:13 <weex> so network propogation is slower
 85 2013-03-11 06:02:35 <CodeShark> yeah, but by how much?
 86 2013-03-11 06:02:41 <CodeShark> can't be more than the order of seconds
 87 2013-03-11 06:03:08 <weex> i think gavin calculated this in a recent foundation or forum post
 88 2013-03-11 06:03:38 <warren> CodeShark: bigger blocks take longer to propagate, increasing the likelihood of a competing block to orphan it?  I'm not really sure.
 89 2013-03-11 06:03:39 <CodeShark> in any case, it's far less than the 10 expected minutes between blocks
 90 2013-03-11 06:04:00 <warren> CodeShark: apparently some pools reduced tx's to reduce orphans
 91 2013-03-11 06:04:46 <CodeShark> I guess we need a new word to describe blocks without known parents :(
 92 2013-03-11 06:04:58 <CodeShark> because we're going to have nomenclature confusion forever
 93 2013-03-11 06:05:59 <weex> vestigal
 94 2013-03-11 06:07:47 <CodeShark> vestigal is a great term for deadend sidechain blocks
 95 2013-03-11 06:08:36 <CodeShark> they still exist...but they no longer support the organism
 96 2013-03-11 06:09:29 <CodeShark> I'm gonna see if I can convince piuk to change the term on blockchain.info
 97 2013-03-11 06:10:21 <CodeShark> I don't mind using a different word for these blocks - the problem is that now I don't have a word to describe blocks without known parents
 98 2013-03-11 06:11:42 <CodeShark> and the term orphan to mean "an object without known parents" is consistent with the way satoshi used it and the way it's used in the bitcoind source code
 99 2013-03-11 06:12:20 <CodeShark> and inconsistent with the way blockchain.info uses it
100 2013-03-11 06:13:44 <warren> CodeShark: Folks need to get over "the way satoshi used it" as reason for anything.
101 2013-03-11 06:13:57 <warren> CodeShark: He is wicked smart, but he can't have got everything right.
102 2013-03-11 06:14:03 <CodeShark> that's not the main reason - the main reason is that that's what it actually means in the English language
103 2013-03-11 06:14:04 <CodeShark> lol
104 2013-03-11 06:14:12 <CodeShark> that's how it's construed in the English language
105 2013-03-11 06:14:21 <CodeShark> whereas blockchain.info's usage is totally foreign
106 2013-03-11 06:14:28 <warren> The parents disowned it, or the parents were killed.
107 2013-03-11 06:15:08 <CodeShark> there are many things that satoshi did that I disagree with - but his usage of this term is not one of them :)
108 2013-03-11 06:17:04 <CodeShark> someone whose parents are killed is not necessarily an orphan
109 2013-03-11 06:17:21 <CodeShark> and a parent block has no say as to whether its children are disowned
110 2013-03-11 06:17:42 <CodeShark> it's the later generations that determine whether it stays in the main chain
111 2013-03-11 06:18:14 <CodeShark> furthermore, an orphan's parents might still be alive
112 2013-03-11 06:18:22 <CodeShark> orphan just means we don't know who the parents are
113 2013-03-11 06:18:43 <CodeShark> anyhow, it's silly to argue this :p
114 2013-03-11 06:20:02 <CodeShark> if everyone wants to redefine "orphan" to mean a block in a chain which is no longer being extended, I don't really have a problem with that - as long as we also have an unambiguous term to mean a block whose parents we don't know...and make sure to mention this in the documentation so people familiar with typical English usage of these terms doesn't get confused
115 2013-03-11 06:22:15 <CodeShark> also, comments should be added to the bitcoind source code to point out this discrepancy :)
116 2013-03-11 06:23:02 <CodeShark> I guess we could use the term "unconnected chain"
117 2013-03-11 06:23:08 <CodeShark> rather than "orphaned chain"
118 2013-03-11 06:23:58 <CodeShark> it might still become a side chain if we learn of the blocks connecting it with the genesis block
119 2013-03-11 06:24:11 <CodeShark> so "orphaned" status isn't necessarily permanent
120 2013-03-11 06:29:24 <CodeShark> or the term "isolated" might also work
121 2013-03-11 06:29:37 <CodeShark> an isolated block - or an isolated chain
122 2013-03-11 06:30:11 <warren> isolated has an incorrect implication of valid
123 2013-03-11 06:31:03 <CodeShark> island block and island chain?
124 2013-03-11 06:31:06 <CodeShark> lol
125 2013-03-11 06:33:14 <CodeShark> problem with the term "unconnected" is that we're only referring to backwards connections - it might still be referenced by future blocks
126 2013-03-11 06:33:18 <CodeShark> unlinked?
127 2013-03-11 06:33:40 <warren> by future blocks that could reorg the entire chain and become the valid one?
128 2013-03-11 06:34:12 <CodeShark> the block chain is a singly linked list - what's the official term for an element in a linked list which has a bad pointer? :)
129 2013-03-11 06:34:58 <CodeShark> or for a linked list which contains a node with a bad pointer
130 2013-03-11 06:37:05 <CodeShark> "unconnected" is analogous in this context with the way it is used to refer to transactions which have bad inputs
131 2013-03-11 06:38:35 <CodeShark> or inputs whose scripts we cannot validate for whatever reason
132 2013-03-11 06:40:42 <CodeShark> anyhow, I don't mean to be pedantic - there are real practical reasons for having an unambiguous term
133 2013-03-11 06:40:43 <CodeShark> :p
134 2013-03-11 06:42:02 <warren> CodeShark: you're having a long conversation with yourself
135 2013-03-11 06:43:30 <CodeShark> anyhow, back to the idea that including more transactions increases the risk of an abandoned block
136 2013-03-11 06:43:44 <CodeShark> (I like the term abandoned, btw)
137 2013-03-11 06:45:44 <CodeShark> isn't it really the number of inputs that determines how quickly it can be validated?
138 2013-03-11 06:45:52 <CodeShark> not the number of transactions
139 2013-03-11 06:46:06 <rdponticelli1> I'm getting depressed... All those poor little blocks... :P
140 2013-03-11 06:46:11 <CodeShark> lol
141 2013-03-11 06:46:25 <warren> CodeShark: perhaps "unfavored"
142 2013-03-11 06:47:13 <CodeShark> the bottleneck in transaction validation is signature verification - which happens once per txin
143 2013-03-11 06:47:57 <CodeShark> or more, perhaps
144 2013-03-11 06:48:01 <CodeShark> in the case of a multisig
145 2013-03-11 06:51:36 <CodeShark> another thing about block validation - nodes can validate transactions prior to seeing them in blocks - and there's no real need to revalidate the transaction when the block is seen
146 2013-03-11 06:53:42 <CodeShark> although I don't think bitcoind does this optimization
147 2013-03-11 06:58:53 <CodeShark> or nevermind...
148 2013-03-11 06:59:17 <CodeShark> once a transaction is marked as connected it is no longer validated
149 2013-03-11 06:59:33 <CodeShark> (at least the signatures aren't verified again)
150 2013-03-11 07:01:30 <CodeShark> so this would only apply to transactions in the block that are not already in the mempool
151 2013-03-11 08:48:25 <moarrr> Bitcoins @ 5JzdYNEKBZhCmubuhosCWsM5e6cDguhsdnSK7jumegQU9cZBKq3 (1jqfg3fCu4ssKWANk2FvXoU3x54pBPGoc)
152 2013-03-11 08:58:43 <CodeShark> current balance is 0 :p
153 2013-03-11 08:59:05 <CodeShark> and it never had an output large enough to even be worth spending
154 2013-03-11 09:05:59 <CodeShark> lol
155 2013-03-11 09:08:59 <lianj> wonder which one makes it
156 2013-03-11 09:18:42 <lianj> ah, the higher fee one ofcourse
157 2013-03-11 11:18:27 <whitez> Hello. Super n00b question, but where can I download bitcoind?
158 2013-03-11 11:18:42 <sipa> bitcoin.org
159 2013-03-11 11:19:23 <kriqCoin> I hear there was a meetup in Zurich of BC devs
160 2013-03-11 11:19:33 <kriqCoin> whats up with that?
161 2013-03-11 11:21:22 <epscy> they were discussing the killswitch
162 2013-03-11 11:21:28 <whitez> sipa: Is it embedded in Bitcoin-Qt?
163 2013-03-11 11:25:28 <CodeShark> Bitcoin-Qt is essentially bitcoind with a GUI on top of it
164 2013-03-11 11:26:19 <whitez> CodeShark: Ok, I see. I
165 2013-03-11 11:26:48 <whitez> I've downloaded Bitcoin, so I'll try to load it as a daemon
166 2013-03-11 11:27:51 <CodeShark> you can also build it yourself if you prefer from the github repository
167 2013-03-11 11:28:15 <CodeShark> and you can also get it as a package with several linux distros
168 2013-03-11 11:35:02 <whitez> CodeShark: It works!!!
169 2013-03-11 11:35:12 <CodeShark> :)
170 2013-03-11 11:35:19 <whitez> Magic :D
171 2013-03-11 11:35:47 <whitez> And the icon is all nice and green. Awesome. Thanks very much! ???
172 2013-03-11 11:36:03 <sipa> whitez: if you're seeing an icon, you're not running bitcoind
173 2013-03-11 11:36:21 <TD> kriqCoin: yeah
174 2013-03-11 11:36:45 <TD> kriqCoin: https://groups.google.com/d/msg/bitcoin-switzerland/QsIPKM-AYxY/iFwXbq_oobIJ
175 2013-03-11 11:38:29 <CodeShark> I'd also be interested in what stephan has to say :)
176 2013-03-11 11:38:29 <Scrat> google performing a 51% attack in the zurich meetup?
177 2013-03-11 11:41:01 <whitez> sipa: Do you know how to make it not-an-icon ?
178 2013-03-11 11:41:30 <whitez> "Bitcoin-Qt -datadir=1  -daemon"
179 2013-03-11 11:41:37 <sipa> whitez: bitcoin-qt is the GUI, bitcoind has no GUI, so if you see any GUI, you
180 2013-03-11 11:41:46 <sipa> 're not running bitcoind but bitcoin-qt
181 2013-03-11 11:41:50 <CodeShark> whitez, if it's built as Bitcoin-Qt you cannot make it headless - you need to build it headless
182 2013-03-11 11:42:08 <CodeShark> so you need to either get a bitcoind binary or build it from source
183 2013-03-11 11:42:20 <whitez> Ah, I see - build from source. Gotcha. Will do. Thanks. :)
184 2013-03-11 11:46:18 <CodeShark> Bitcoin-Qt and bitcoind are two different builds that use the same underlying source code for the daemon portion
185 2013-03-11 11:47:43 <whitez> I'm on a Mac, so working off this now: http://bitcoin.stackexchange.com/questions/793/what-are-the-steps-in-building-bitcoind-on-mac-os-x-10-6?rq=1
186 2013-03-11 11:48:09 <sipa> oh, right; for windows and linux, bitcoind is just bundled with the package, but on OSX it's only bitcoin-qt
187 2013-03-11 11:49:15 <CodeShark> whitez, you can also install macports and then port install boost
188 2013-03-11 11:49:28 <whitez> boost?
189 2013-03-11 11:49:46 <CodeShark> it's one of the library dependencies
190 2013-03-11 11:50:00 <CodeShark> https://github.com/CodeShark/bitcoin/blob/configure_script/doc/build-osx.txt
191 2013-03-11 11:50:06 <whitez> It's whirring and clicking now....
192 2013-03-11 11:50:39 <CodeShark> what version of OS X are you running?
193 2013-03-11 11:51:28 <whitez> CodeShark: Oh, that's helpful, thanks. 10.8.2
194 2013-03-11 11:51:53 <CodeShark> then it's the same as for 10.7
195 2013-03-11 11:53:01 <whitez> I started by trying "sudo port install bitcoin", I don't need a super up-to-date version.
196 2013-03-11 11:53:24 <CodeShark> is there a macport for bitcoin? lol
197 2013-03-11 11:54:07 <sipa> whitez: you really want an up-to-date version - old versions have significantly worse performance, and often security bugs
198 2013-03-11 11:54:33 <CodeShark> and are also likely to be abandoned by the network in future releases
199 2013-03-11 11:54:43 <whitez> sipa: Oh, ok. I'll let this finish and then install a shiney new version
200 2013-03-11 11:55:27 <CodeShark> that build-osx.txt gives you step-by-step instructions for installing the newest release
201 2013-03-11 11:56:39 <whitez> Hah! "Error: Processing of port bitcoin failed"
202 2013-03-11 11:56:46 <whitez> I'll try your way now. :)
203 2013-03-11 11:57:17 <CodeShark> I'd be curious as to why it failed
204 2013-03-11 11:58:20 <whitez> CodeShark: I can send you the log if you want.
205 2013-03-11 11:58:28 <CodeShark> yes, please do so
206 2013-03-11 11:59:07 <gavinandresen> whitez: Ignore the "uncomment build_arch" instruction
207 2013-03-11 11:59:17 <gavinandresen> .. that'll just get you a bunch of conflicts with your existing ports
208 2013-03-11 11:59:24 <whitez> gavinandresen: Ok
209 2013-03-11 12:00:59 <kriqCoin> Thanks TD
210 2013-03-11 12:01:07 <kriqCoin> I am  bringing along some friends)
211 2013-03-11 12:56:41 <ItsDom> So satoshi client tracks up 16k known nodes. Does anyone know the justification for the number 16k?
212 2013-03-11 12:57:14 <HM> it's higher than 10k and lower than 20k
213 2013-03-11 12:57:29 <ItsDom> aaah, I hadn't thought of that.... ??_?? :P
214 2013-03-11 12:58:15 <ItsDom> but seriously though, if only keeping about 10 live connections, why hold as much as 16k? and if network is well of 16k, why only hold 16k? Is it just a trade off between resources and network knowledge?
215 2013-03-11 12:58:26 <ItsDom> well over*
216 2013-03-11 12:58:38 <HM> is it actually 16k, or 16384?
217 2013-03-11 12:58:52 <davout> ItsDom: why do you say it keeps only 10 connections ?
218 2013-03-11 12:59:25 <sipa> ItsDom: have you read the comments in addrman.h ?
219 2013-03-11 12:59:43 <ItsDom> I can't remember the exact number, but it only maintains a small number of connections, around 10 I thought. That's what I was told on here yesterday. I read the comments but it doesn't justify the numbers
220 2013-03-11 12:59:54 <ItsDom> it gives the numbers, but no reason as to why (not that I could find)
221 2013-03-11 13:00:06 <davout> I believe you can change it in bitcoin.conf
222 2013-03-11 13:00:20 <davout> but as for the why it's a good question
223 2013-03-11 13:00:27 <gmaxwell> ItsDom: It makes 8 outbound connections.
224 2013-03-11 13:00:34 <gmaxwell> davout: go read the extensive comments in addrman.h
225 2013-03-11 13:00:37 <ItsDom> but my original point still stands: why hold so many known nodes if you're only going to use a small fraction of them?
226 2013-03-11 13:01:15 <ItsDom> I could understand it hold ALL the known nodes in the network (that would obvs be a bit silly from scalability point of view) but 16k just seems a bit....random?
227 2013-03-11 13:01:24 <gmaxwell> ItsDom: You are connected to 8 outbound at any one time. But your memory is persistent.
228 2013-03-11 13:01:53 <gmaxwell> ItsDom: there are potentially 2^128 possible nodes that you can be told about. You are not going to store all you've been told about.
229 2013-03-11 13:02:12 <ItsDom> exactly, it would be silly.
230 2013-03-11 13:02:23 <gmaxwell> No. Not silly. Not possible.
231 2013-03-11 13:02:40 <ItsDom> but why not just hold, say, 512 known nodes?
232 2013-03-11 13:02:48 <gmaxwell> It would be nice to store all of them??? but we used to, but then its a DOS vector.
233 2013-03-11 13:03:03 <gmaxwell> ItsDom: because we need to resist a malicious peer flushing out the memory.
234 2013-03-11 13:03:11 <gmaxwell> This is explained in addrman.h.
235 2013-03-11 13:03:34 <ItsDom> I'll go take another look through addrman.h - I didn't notice that bit.
236 2013-03-11 13:07:19 <ItsDom> Ah, I see the comment, I didn't make the link in my head the ability to fill the nodes list with malicious entries and the size of the known nodes list.
237 2013-03-11 13:07:36 <ItsDom> so is this based on the assumption that an attacker wont have more than 16k compromised nodes....?
238 2013-03-11 13:08:36 <gmaxwell> ::sigh::
239 2013-03-11 13:08:44 <gmaxwell> Do you see the number "16k" in there?
240 2013-03-11 13:12:44 <ItsDom> No, i was assuming 16k from 256 buckets for new addresses and 64 entries per bucket.....
241 2013-03-11 13:15:29 <ItsDom> it's actually less than 16k though due to duplications.
242 2013-03-11 13:16:25 <gmaxwell> The parameters are selected to give resistance to attack, the total is just falls out of those. There are actually 20480 slots in total, but as you note there can be some duplication (which is intended and good as it makes flushing harder). But the total numbers aren't so interesting, they're just a result of trading off attack resistance against storage.
243 2013-03-11 13:19:22 <ItsDom> Aaah, thanks for the response. I suspected as much. Thanks again for taking the time to help - I really appreciate it.
244 2013-03-11 14:08:16 <jgarzik> 
ACTION wonders what happened to [tycho]

245 2013-03-11 14:08:24 <jgarzik> doesn't seem to login much anymore
246 2013-03-11 14:08:28 <gribble> Error: "Tycho" is not a valid command.
247 2013-03-11 14:08:28 <jgarzik> ;;seen [Tycho]
248 2013-03-11 14:08:37 <jgarzik> ;;seen \\[Tycho\\]
249 2013-03-11 14:08:38 <gribble> Error: "Tycho\\" is not a valid command.
250 2013-03-11 14:09:08 <gribble> I have not seen tycho.
251 2013-03-11 14:09:08 <kinlo> ;;seen tycho
252 2013-03-11 14:09:15 <kinlo> ofcourse, that's useless
253 2013-03-11 14:09:19 <abracadabra> !seen [Tycho]
254 2013-03-11 14:09:19 <gribble> Error: "Tycho" is not a valid command.
255 2013-03-11 14:09:25 <abracadabra> meh
256 2013-03-11 14:09:30 <abracadabra> to the logmobile!
257 2013-03-11 14:09:34 <gmaxwell> I saw nanotube tell some other user how to deal with that.
258 2013-03-11 14:09:42 <kinlo> the problem is that gribble wants to expand stuff :)
259 2013-03-11 14:09:51 <Scrat> nickserv to the rescue
260 2013-03-11 14:09:54 <Scrat> [17:09] -NickServ- Last seen  : Dec 06 15:09:13 2012 (13 weeks, 3 days, 23:59:58 ago)
261 2013-03-11 14:10:18 <abracadabra> tycho is hard at work adding stratum to his pool
262 2013-03-11 14:10:19 <abracadabra> ;)
263 2013-03-11 14:10:48 <Graet> heh
264 2013-03-11 14:11:11 <gribble> [tycho] was last seen in #bitcoin-dev 18 weeks, 0 days, 16 hours, 11 minutes, and 58 seconds ago: <[Tycho]> !seen tcatm
265 2013-03-11 14:11:11 <kinlo> ;;seen "[tycho]"
266 2013-03-11 14:11:17 <kinlo> there you go :)
267 2013-03-11 14:11:24 <kinlo> rtfm still works :p
268 2013-03-11 14:11:33 <Luke-Jr> jgarzik: he never did :p
269 2013-03-11 14:15:40 <gribble> [Tycho] was last seen in #bitcoin-dev 18 weeks, 0 days, 16 hours, 16 minutes, and 27 seconds ago: <[Tycho]> !seen tcatm
270 2013-03-11 14:15:40 <SomeoneWeird> ;;seen "[Tycho]"
271 2013-03-11 14:36:58 <WolfWindshadow_> I am working on a little coin project of my own, just to teach my kids about BTC and crypto in general, and was wondering where in the source I set the limits on total coins and the difficulty, so that I can set up my own little demo network.
272 2013-03-11 14:37:22 <WolfWindshadow_> what file would that be in?
273 2013-03-11 14:37:26 <SomeoneWeird> how old are they? (just wondering)
274 2013-03-11 14:37:30 <SomeoneWeird> also look at testnetinabox
275 2013-03-11 14:37:44 <_dr> you're never too young to learn about generators in cyclic groups!
276 2013-03-11 14:37:49 <SomeoneWeird> https://github.com/freewil/bitcoin-testnet-box
277 2013-03-11 14:39:21 <jgarzik> ouch, poor BTCGuild.  Accidentally paid out for some generated blocks, before their server caught up with the chain
278 2013-03-11 14:39:31 <jgarzik> ancient blocks, at low difficulty
279 2013-03-11 14:39:31 <WolfWindshadow_> that addy is 404
280 2013-03-11 14:39:54 <SomeoneWeird> refresh a couple times, github is having some problems
281 2013-03-11 14:41:51 <WolfWindshadow_> ok...   in any case, anybody know what files I would dig in to change that?   I've been programming since basic on the Commodore 64 was as good as it got, just a matter of finding it....
282 2013-03-11 14:42:17 <xjrn> WolfWindshadow_: asm on the c64 was as good as it got though
283 2013-03-11 14:42:46 <WolfWindshadow_> asm was a p.i.t.a. :P
284 2013-03-11 14:43:09 <WolfWindshadow_> but did freak out teachers that did not now it
285 2013-03-11 14:43:14 <WolfWindshadow_> know
286 2013-03-11 14:44:40 <TD> jgarzik: oops
287 2013-03-11 14:44:54 <TD> jgarzik: yeah, details like that make bitcoin programming remarkably painful and tricky to get right
288 2013-03-11 14:44:58 <xjrn> WolfWindshadow_: i tuned in late, sorry, i can't be of more assistance
289 2013-03-11 14:45:22 <TD> jgarzik: i've been trying to figure out how to make bitcoinj as safe an API as possible and the number of edge cases you end up with is just amazing
290 2013-03-11 14:45:56 <WolfWindshadow_> was asking where in the bitcoin source to change things to set difficulty and total coins and such to make my own small demo network for my kids
291 2013-03-11 14:46:20 <WolfWindshadow_> teaching the little cyber-monsters how to use crypto
292 2013-03-11 14:46:55 <xjrn> worst-case, create some blocks on bogus datetime trajectories
293 2013-03-11 14:46:58 <TD> WolfWindshadow_: hm, i was only interested in video games when i was a kid :)
294 2013-03-11 14:47:19 <TD> WolfWindshadow_: the bitcoin codebase is not exactly kid friendly (or adult friendly for that matter), but look in main.cc for the constants at the top
295 2013-03-11 14:48:25 <lianj> http://i.imgur.com/cQlkclt.gif
296 2013-03-11 14:48:49 <helo> WolfWindshadow_: it may be easier to teach them crypto by using bitcoin directly... there's still plenty of crypto going on even after the coin is started
297 2013-03-11 14:49:28 <gavinandresen> WolfWindshadow_: BlueMatt uses a patch that sets difficulty very low as part of our pull-tester process...
298 2013-03-11 14:50:03 <gavinandresen> WolfWindshadow_: ??? ah, the .patch file here: https://github.com/TheBlueMatt/test-scripts/
299 2013-03-11 14:50:50 <WolfWindshadow_> thanks...   code is my thing....   starting with the concepts... once I have a demo running, gonna leave it to them and their friends...
300 2013-03-11 14:51:09 <WolfWindshadow_> thanks again, and have a great day
301 2013-03-11 14:57:12 <TD> sigh
302 2013-03-11 14:57:18 <TD> the bitcoinj api is so crap in so many ways
303 2013-03-11 14:57:48 <gavinandresen> api design is really hard
304 2013-03-11 14:58:19 <TD> yeah. especially when there aren't any pre-existing examples to help you. and especially when the thing the api does is inherently concurrent. and especially when some of your users have hard latency/thread affinity requirements.
305 2013-03-11 14:58:38 <sipa> the largest problem is that use cases evolve, and you don't know in what ways you'll need extensibility in the future
306 2013-03-11 14:58:48 <TD> that's definitely a large problem.
307 2013-03-11 14:59:16 <TD> right now one of my biggest source of bugs comes from the fact that there are listeners you can register at various points, and managing the re-entrancy and locking around that is quite hard, as basically at any listener point anything can happen
308 2013-03-11 14:59:43 <TD> it's awfully handy to just have a function that runs when something happens, but it's an absolute nightmare to handle all the different possibilities.
309 2013-03-11 15:00:04 <Scrat> TD: can I use the bitcoinj API if I don't run a java client?
310 2013-03-11 15:00:20 <gavinandresen> api design for multithreading is hard^n ...
311 2013-03-11 15:00:25 <TD> ainfo was asking me about this. i experimented with compiling it down to native code and using it from (objective) C++ a while ago
312 2013-03-11 15:00:35 <TD> it worked OK. i mean it presented a basically C++-like API, with a bit of massaging
313 2013-03-11 15:00:42 <TD> that was using GCJ/CNI
314 2013-03-11 15:01:00 <TD> but that branch bitrotted. i upgraded bouncy castle and some code i didn't use hit a stub. i never got around to slicing the necessary parts out, as nobody seemed to care about it much
315 2013-03-11 15:01:22 <TD> also, back then i was doing it for an iphone client, and then apple banned everything. so i stopped. if there's interest i can try to resurrect it.
316 2013-03-11 15:01:49 <HM> Atm I'm trying to massage some APIs in to a stateless condition
317 2013-03-11 15:01:56 <HM> so servers don't need to maintain any state
318 2013-03-11 15:02:03 <HM> API design is a time sink
319 2013-03-11 15:02:04 <TD> which APIs?
320 2013-03-11 15:02:10 <_dr> did apple give a reason? or simple 'violation of tos, blah!'
321 2013-03-11 15:02:13 <HM> just a mini bitcoin project
322 2013-03-11 15:02:34 <TD> _dr: some kneejerk reaction by a lawyer there, iiuc. something like "money is hard! it's probably illegal somewhere in the world. simpler to just ban it"
323 2013-03-11 15:02:50 <_dr> that's what i was expecting
324 2013-03-11 15:02:51 <TD> HM: yeah it's a timesink but a very important one. otherwise you end up with mistakes like BTCGuilds
325 2013-03-11 15:02:59 <TD> my goal is to make dangerous mistakes like that hard to do
326 2013-03-11 15:03:55 <HM> got an example of a bad API you're dealing with right now?
327 2013-03-11 15:04:01 <TD> bitcoinj :)
328 2013-03-11 15:04:06 <TD> ok, most of it isn't terrible
329 2013-03-11 15:04:07 <HM> yeah, but specifically
330 2013-03-11 15:04:48 <TD> transactions have an associated object called TransactionConfidence which has data on things like how deep it is in the chain, how many peers announced it, whether it's in a side chain or not, etc
331 2013-03-11 15:04:56 <TD> you can register a listener on that so you find out when it's changed.
332 2013-03-11 15:05:21 <TD> the idea being, if a transaction reaches, say, 6 confirmations, and you want to do something at that point, you can just do that within your listener.
333 2013-03-11 15:05:33 <HM> edge triggered or level triggered?
334 2013-03-11 15:06:07 <TD> how do you mean? the listeners are run on any change. it's up to you to determine whether the transition is interesting.
335 2013-03-11 15:06:18 <HM> right
336 2013-03-11 15:06:25 <HM> so what's the problem with it?
337 2013-03-11 15:06:28 <TD> ie, depth can go down as well as up
338 2013-03-11 15:06:32 <TD> the problem is that there are unexpected re-entrancy constraints on what you can actually do inside that listener.
339 2013-03-11 15:06:38 <TD> well, that's one problem
340 2013-03-11 15:07:05 <TD> another problem is that the confidence data is sometimes modified in ways that users would not expect. for example, during a re-organize, confidence can change to intermediate states.
341 2013-03-11 15:07:10 <TD> because of how the code is written.
342 2013-03-11 15:07:28 <HM> sounds like a super-callback
343 2013-03-11 15:07:31 <HM> trying to do too much
344 2013-03-11 15:08:15 <TD> as a trivial example, it's not safe to actually re-spend the money from inside the listener, because the listeners run with the wallet locked. if you then try and lock a peer, you can trigger an inversion detection assert.
345 2013-03-11 15:08:25 <TD> so it's just a mess.
346 2013-03-11 15:08:50 <TD> i think the right fix is to make the whole confidence object immutable, and then batch up changes during certain operations so they don't trigger event listeners.
347 2013-03-11 15:09:05 <TD> and then trigger the listener once at the end with the very latest state, without the wallet being locked.
348 2013-03-11 15:09:20 <HM> why is it not immutable?
349 2013-03-11 15:09:48 <TD> because confidence is inherently something that changes, right :) the only question is whether the whole object changes or whether parts of it are tweaked directly.
350 2013-03-11 15:10:04 <HM> yeah, but from the callback it should be immutable
351 2013-03-11 15:10:17 <HM> send the callback a copy and then hold no locks
352 2013-03-11 15:10:27 <TD> yes. that's pretty much what i'm saying needs to change.
353 2013-03-11 15:11:44 <HM> i guess it depends whether you need to enforce immutability over the entire callback
354 2013-03-11 15:11:46 <TD> along with lots of other things
355 2013-03-11 15:12:15 <HM> but there's a difference between notifications and pluggable functionality
356 2013-03-11 15:12:42 <TD> the issue is not so much that the confidence object can change during a callback. it's more that the act of changing the confidence data is too tightly linked to the act of running the callbacks
357 2013-03-11 15:13:03 <HM> this is what i meant by edge triggered, you need to decide whether the confidence is static while the callback is in flight.
358 2013-03-11 15:13:03 <TD> so there are too many places where the confidence is mutated but it's not really safe for the wallet to be arbitrarily re-entered.
359 2013-03-11 15:13:22 <HM> ah
360 2013-03-11 15:13:33 <HM> spaghetti code
361 2013-03-11 15:14:10 <TD> i wouldn't say it's spaghetti. but it's certainly complicated. it can be simplified a bit, but most of the complexity comes from the inherent nature of what some of these objects do. eg, processing a re-org is inherently a complicated operation
362 2013-03-11 15:14:30 <TD> because you're essentially rewinding time and then replaying a new timeline, and what the API user really wants to find out, is the delta between those two timelines
363 2013-03-11 15:14:58 <TD> and if there were any "merge conflicts" (i.e. double spends)
364 2013-03-11 15:15:08 <TD> Satoshis code is already complicated and he didn't try to tackle this at all
365 2013-03-11 15:15:27 <HM> sounds like you need a fullhog message queue and signal system
366 2013-03-11 15:15:32 <TD> double spends trigger absolutely no useful form of feedback and there's not really any obvious place to fix that. if a tx is double spent away it just goes unconfirmed forever.
367 2013-03-11 15:16:21 <TD> the callbacks are basically signals, of a form.
368 2013-03-11 15:16:34 <TD> (you can add/remove listeners at any point)
369 2013-03-11 15:16:55 <HM> but all callbacks should be called under a set of well defined preconditions
370 2013-03-11 15:17:14 <TD> yeah. mostly they are. it's this one corner of the api where the callbacks are problematic.
371 2013-03-11 15:17:34 <TD> the callbacks for things like peers being connected, disconnected, new blocks being processed etc are all ok
372 2013-03-11 15:18:05 <TD> most of the classes allow for arbitrary re-entrancy.
373 2013-03-11 15:19:38 <TD> i think we'll get this sorted. it's an ongoing effort. the api is ugly in other ways too, but i'm not aware of a better one.
374 2013-03-11 15:19:49 <TD> at least it has good documentation and is mostly unsurprising
375 2013-03-11 15:20:01 <TD> it also has example apps, things like that
376 2013-03-11 15:20:20 <grau> TD: I solve the problem by disconnecting callbacks though a message bus. Events sent there have high abstraction e.g. complete reorg of blocks added/removed
377 2013-03-11 15:21:16 <TD> well, if you register an event listener on the BlockChain then you get access to the list of blocks on both sides of the chain plus the split point.
378 2013-03-11 15:21:31 <TD> the problem being that that isn't what is directly interesting to the users. they are thinking in terms of transactions (really: payments).
379 2013-03-11 15:21:45 <TD> so they want to know that transaction XYZ just got double-spent away, or that it reached a certain amount of work done, etc
380 2013-03-11 15:21:52 <HM> sounds like a new API is required
381 2013-03-11 15:21:57 <HM> one that deals only in user concerns
382 2013-03-11 15:21:58 <TD> and then on learning that they want to do things :)
383 2013-03-11 15:22:04 <TD> HM: that's what the bitcoinj api is trying to do
384 2013-03-11 15:22:21 <TD> HM: the devil is in the details, however. i'll fix it and then it'll behave exactly as users expect/need.
385 2013-03-11 15:22:51 <TD> right now the API looks right, but there are odd restrictions on what you can do, and sometimes you get state changes that don't really map directly to user-interesting events. so it just needs tightening up.
386 2013-03-11 15:24:43 <grau> HM: here it is https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/api/BCSAPI.java
387 2013-03-11 15:25:01 <grau> A new API, that has payment focus
388 2013-03-11 15:26:05 <TD> yes, but it's currently under-specified. eg, if I use registerConfirmationListener you say it's called "if the transaction is confirmed up to depth 10 "
389 2013-03-11 15:26:16 <TD> so what happens if it gets to 10 blocks, then a re-org moves it down to 8 blocks
390 2013-03-11 15:26:23 <TD> and then it goes back to 10 blocks after a couple more blocks arrive
391 2013-03-11 15:26:29 <TD> does it get called twice?
392 2013-03-11 15:26:46 <TD> also, what happens if a re-org means that the tx will never confirm because its inputs were double spent? etc
393 2013-03-11 15:26:54 <TD> so, it's just tough to get all these details right
394 2013-03-11 15:26:58 <HM> hmm
395 2013-03-11 15:27:15 <TD> grau: also that interface doesn't say anything about what thread it runs on or what re-entrancy is allowed
396 2013-03-11 15:27:29 <grau> TD: yes it is called whenever confirmation number of tx changes
397 2013-03-11 15:27:30 <HM> well you perhaps need to specify the maximum difference between blockchain heights before it's called
398 2013-03-11 15:27:43 <HM> so like, depth of 10 with a minimum block branch distance of 4
399 2013-03-11 15:27:45 <HM> or whatever
400 2013-03-11 15:27:45 <TD> so what's the "up to 10" about?
401 2013-03-11 15:27:57 <lianj> TD: maybe have a reorg callback in the callback and if its != null then this confirmation happend due to a reorg
402 2013-03-11 15:28:17 <grau> TD: This is an API that runs by a message consumer detached from the kernel.
403 2013-03-11 15:28:32 <helo> if you ask for 10, you'd be aware that the last few confirms could ~easily be undone, but that you can consider it permanent. so you'd not care about it reaching 10 a second time?
404 2013-03-11 15:28:41 <TD> http://plan99.net/~mike/bitcoinj/0.7/index.html?com/google/bitcoin/core/TransactionConfidence.html
405 2013-03-11 15:28:44 <TD> this is the api i'm talking about
406 2013-03-11 15:28:53 <helo> as for 10-deep reorgs... :/
407 2013-03-11 15:29:10 <TD> grau: what does that mean? which thread does it run on? one i have to provide myself?
408 2013-03-11 15:29:32 <TD> grau: also, do you have a wallet? most of the complexity in bitcoinj TransactionConfidence comes from interaction with the wallet.
409 2013-03-11 15:29:55 <TD> if all you do is receive the data, it's not really so bad. it's when you want to start doing things based on that data like creating new spends and broadcasting them that the pain starts :)
410 2013-03-11 15:30:20 <xjrn> td any netty headaches to speak of?
411 2013-03-11 15:30:38 <grau> TD: this is not a single process. The thread that calls the API is coming from a thread pool that listens on a message bus. All requests to the server again go through the bus. Asynchronously.
412 2013-03-11 15:30:57 <TD> netty 3.x has a really bizarre and confusing API too, which doesn't help. netty 4 looks a lot better but it's in beta
413 2013-03-11 15:31:18 <TD> grau: ok so the listeners do have to be thread safe, yeah
414 2013-03-11 15:31:28 <grau> Wallet for me is a constuctor of keys. not more.
415 2013-03-11 15:32:28 <grau> Listeners are serial per topic.
416 2013-03-11 15:33:04 <TD> that's not really how wallets work. they need to store transactions and create spends with them too
417 2013-03-11 15:33:07 <grau> The real API is a subscription and publish protocol on a bus, the Java classes are just convinience wrapper
418 2013-03-11 15:33:25 <grau> no they do not
419 2013-03-11 15:33:41 <grau> this is just how yours nd satoshis work
420 2013-03-11 15:33:41 <TD> how do you make a spend then?
421 2013-03-11 15:34:18 <grau> You query UTXO to know what you can spend.
422 2013-03-11 15:34:32 <HM> yeah
423 2013-03-11 15:34:56 <HM> send a script filter over and have the service select the transactions
424 2013-03-11 15:34:57 <TD> xjrn: i guess one minor annoyance is there doesn't seem to be any way to suspend the IO threads from processing things. not that it's a big deal. it'd be nice to have though.
425 2013-03-11 15:35:29 <HM> so the main API deals in transactions and scripts and the wallet api abstracts over the top, only knowing about a few script forms?
426 2013-03-11 15:35:30 <xjrn> TD see pm.  i have that sussed.
427 2013-03-11 15:35:36 <grau> HM: you send a list of adresses and server sends you UTX of them
428 2013-03-11 15:35:56 <HM> why does the wallet API need to care about transactions?
429 2013-03-11 15:36:07 <HM> inputs i mean
430 2013-03-11 15:36:26 <HM> a 'wallet' is already a high level abstraction, it should be an idiot api
431 2013-03-11 15:36:36 <HM> imho
432 2013-03-11 15:37:46 <TD> if you assume access to a fully indexed UTXO set then yes, that is one way to do it. quite expensive to maintain though.
433 2013-03-11 15:38:25 <HM> it's not necessarily expensive if you make your index data opaque and pass it over to the wallet subsystem
434 2013-03-11 15:38:39 <grau> TD: yes, it is expensive, not an option for a mobile. But that is not my market either.
435 2013-03-11 15:38:54 <HM> but this is just me philandering, API design *is* hard
436 2013-03-11 15:39:37 <grau> HM: it is. The reason I have not yet announced beta of mine, because I still tune the API as I build on it.
437 2013-03-11 15:41:22 <Happzz> i wonder why anyone thought placing the ip of whoever sends btcs in the blockchain
438 2013-03-11 15:41:31 <Happzz> or is it not in the chain but just broadcasted?
439 2013-03-11 15:41:49 <HM> it's actually a typical stateful server problem. indexes on the utxo set are server state and carry a hefty burden. keeping track of them transactions in your wallet system avoids that but breaks the abstraction
440 2013-03-11 15:41:54 <TD> it's not even broadcasted
441 2013-03-11 15:42:31 <Happzz> so why do people use tor to anonymize bitcoin?
442 2013-03-11 15:42:57 <HM> Happzz: no IPs in the blockchain afaik?
443 2013-03-11 15:43:07 <Happzz> HM i'm asking, not saying :o
444 2013-03-11 15:43:36 <TD> blockchain.info connects to lots of nodes and records the IP it sees broadcast first.
445 2013-03-11 15:43:39 <HM> IPs aren't future proof
446 2013-03-11 15:43:42 <TD> sometimes that is actually not inaccurate
447 2013-03-11 15:43:58 <HM> we might all move to meshnets in the future, that don't use IPs :P
448 2013-03-11 15:47:15 <xjrn> HM: butterfly networks++
449 2013-03-11 15:48:56 <HM> xjrn: never heard of them
450 2013-03-11 15:50:33 <ProfMac> has anyone seen an IPv6 address in the blockchain.info data?
451 2013-03-11 15:51:38 <xjrn> HM: http://en.wikipedia.org/wiki/Linear_network_coding
452 2013-03-11 16:59:48 <Belkaar> If I use "encryptwallet" the client tells me that I need to replace my backups, because they will be made useless. How does this work? Private keys can not be invalidated or am I wrong?
453 2013-03-11 17:01:02 <Luke-Jr> Belkaar: backups are only good for 100 transactions after they're made anyway
454 2013-03-11 17:02:03 <HM> well BitSpend is a scary idea
455 2013-03-11 17:02:51 <Belkaar> Luke-Jr: So I'm guessing the encryption-process deletes all unused keys in the pool?
456 2013-03-11 17:03:11 <Luke-Jr> Belkaar: it marks them as used
457 2013-03-11 17:03:25 <Luke-Jr> Belkaar: the assumption being it's best to avoid using potentially-compromised keys
458 2013-03-11 17:04:32 <Belkaar> I see. The message in the Qt-Client suggests that it's no longer a Problem if an unecrypted wallet backup leaks, because it's useless now.
459 2013-03-11 17:06:05 <Belkaar> But that would only be true if all coins are moved to a fresh address after encryption. Maybe there shoul be an option for that.
460 2013-03-11 17:18:04 <gmaxwell> Belkaar: even _if_ you have no funds something must be done with the keypool keys, and doing that invalidates the backups.
461 2013-03-11 17:18:27 <Belkaar> gmaxwell
462 2013-03-11 17:19:21 <Belkaar> gmaxwell: I get that. I'm only concerned about the false sense of security it implies. "Encrypt your wallet and the unencrypted backups are useless (to thieves)"
463 2013-03-11 17:23:09 <Belkaar> gmaxwell: And that is true for the unused addresses but not for the already used ones containing coins.
464 2013-03-11 17:24:56 <MobGod> gavinandresen you therre
465 2013-03-11 17:26:50 <gavinandresen> no, I'm here
466 2013-03-11 17:28:09 <jgarzik> thar he blows, an ump like a snowhill
467 2013-03-11 17:30:12 <Luke-Jr> MobGod: I'm there.
468 2013-03-11 17:30:17 <helo> it does seem sensible that the client would offer to send all of your plain privkey coin to an encryption-protected address after encryption is enabled... but i'd bet that's been ruled out already for a good reason.
469 2013-03-11 17:30:38 <MobGod> Luke-Jr where?
470 2013-03-11 17:30:42 <Luke-Jr> MobGod: there!
471 2013-03-11 17:30:55 <MobGod> great
472 2013-03-11 17:31:08 <MobGod> trying to install name coin on my mac
473 2013-03-11 17:31:20 <MobGod> would you be able to provide any help ?
474 2013-03-11 17:31:22 <Luke-Jr> MobGod: #namecoin
475 2013-03-11 17:31:28 <MobGod> i'm there
476 2013-03-11 17:31:38 <MobGod> :)
477 2013-03-11 17:31:41 <Luke-Jr> that's where to ask for help
478 2013-03-11 17:32:15 <MobGod> i did with not one answer for 10 hours
479 2013-03-11 17:32:56 <MobGod> i no gavinandresen runs a mac thats why i was going to ask him
480 2013-03-11 17:33:24 <Luke-Jr> MobGod: probably because namecoin is dead
481 2013-03-11 17:33:37 <gavinandresen> I don't know nuthin about namecoin
482 2013-03-11 17:33:52 <alexwaters> cosbycoin is where it's at
483 2013-03-11 17:34:03 <MobGod> Luke-Jr why do you feel it's dead
484 2013-03-11 17:34:41 <gavinandresen> I think it is dead because it was an ill-conceived project from the start, but that discussion would be off-topic here
485 2013-03-11 17:34:49 <Luke-Jr> MobGod: you just demonstrated why. and it's off-topic here in any case
486 2013-03-11 17:35:05 <Luke-Jr> gavinandresen++
487 2013-03-11 17:35:31 <MobGod> i guess that does make sense :P
488 2013-03-11 17:48:00 <midnightmagic> namecoin is not quite dead yet.
489 2013-03-11 17:48:07 <Happzz> it'll be soon
490 2013-03-11 17:48:11 <Happzz> it's useless.
491 2013-03-11 17:48:17 <midnightmagic> Happzz: nope.
492 2013-03-11 17:48:49 <jgarzik> it's still merge-mined by a few big pools.  who knows if it's actually used.
493 2013-03-11 17:48:50 <warren> midnightmagic: if someone updates it to be modern and cleans up the half-outdated website, maybe.
494 2013-03-11 17:49:00 <warren> also the "registars" are charging 1 BTC?  that's a bit much
495 2013-03-11 17:49:16 <midnightmagic> warren: There is no website.
496 2013-03-11 17:49:18 <warren> jgarzik: I tried half of the listed domains last week, most are dead
497 2013-03-11 17:49:29 <warren> midnightmagic: dotbit?
498 2013-03-11 17:49:30 <K1773R> warren, if you do it yourself it costs like nothing
499 2013-03-11 17:49:39 <midnightmagic> warren: That is not namecoin's website.
500 2013-03-11 17:49:52 <K1773R> midnightmagic, dotbit IS namecoin's website
501 2013-03-11 17:50:01 <midnightmagic> K1773R: Nope.
502 2013-03-11 17:50:20 <midnightmagic> Vince is gone, there was no website, nor is there.
503 2013-03-11 17:50:21 <warren> well, whatever the situation is, plenty of reasons why nobody is using it
504 2013-03-11 17:51:03 <warren> btw, why is it that merge mining works with getwork but not stratum?  limitation of the protocol or just implementation?
505 2013-03-11 17:52:05 <K1773R> you get MM work with the RPC call getworkaux <aux> and since work generation is local in stratum, this wont work
506 2013-03-11 17:52:27 <K1773R> stratum would have to be adjusted/changed to see it working
507 2013-03-11 17:58:08 <jgarzik> stratum just does dumb concatenation, so merged mining seems possible?
508 2013-03-11 17:59:23 <K1773R> yes, but not with the current implementation, it would have to be changed a bit on the server's side
509 2013-03-11 17:59:31 <K1773R> well, a bit is a underestimation
510 2013-03-11 18:03:34 <jgarzik> as long as stratum mining proxy uses GBT, should be straightforward :)
511 2013-03-11 18:06:38 <sipa> hmm, how acceptable would it be to make bitcoin depend on GMP?
512 2013-03-11 18:06:50 <Luke-Jr> warren: merged mining works just fine with stratum and GBT
513 2013-03-11 18:07:10 <warren> Luke-Jr: oh?  ok, crappy other implmenetations then.
514 2013-03-11 18:07:18 <Luke-Jr> K1773R: which implementation? Eloipool does it fine
515 2013-03-11 18:07:36 <Luke-Jr> sipa: ?
516 2013-03-11 18:09:07 <jgarzik> sipa: ?
517 2013-03-11 18:09:24 <sipa> Luke-Jr: i'm writing a secp256k1 implementations from scratch, and there are a few operations which still need a bignum library; either OpenSSL or GMP can provide those, but GMP is significantly faster
518 2013-03-11 18:09:37 <jgarzik> Ah, I parsed that as GetMemoryPool
519 2013-03-11 18:09:42 <Luke-Jr> 
ACTION also :p

520 2013-03-11 18:09:48 <sipa> oh, i mean gnu multiprecision library
521 2013-03-11 18:10:01 <Luke-Jr> sipa: we already have OpenSSL, and CBigNum?
522 2013-03-11 18:10:14 <sipa> Luke-Jr: as i said, OpenSSL is slower
523 2013-03-11 18:10:18 <jgarzik> sipa: do those operations occur outside of 256-bit and 160-bit integers?
524 2013-03-11 18:10:32 <jgarzik> RE "there are a few operations which still need a bignum library"
525 2013-03-11 18:11:02 <sipa> jgarzik: yes
526 2013-03-11 18:11:14 <sipa> it's operations with scalar coefficients
527 2013-03-11 18:11:25 <sipa> so not field elements (which are modulo 2^256-p)
528 2013-03-11 18:11:34 <gavinandresen> I've finished my big shutdown cleanup spring cleaning:  https://github.com/gavinandresen/bitcoin-git/compare/master...shutdowncleanup
529 2013-03-11 18:11:50 <gavinandresen> ???still need to test on Windows before making it a pull request
530 2013-03-11 18:13:41 <sipa> jgarzik, Luke-Jr: hardly an urgent issue - there are other options available like implementing the necessary operations directly so no dependency is needed
531 2013-03-11 18:14:12 <sipa> Luke-Jr, Luke-Jr: just wondering whether there are legal/ideological/technological/religious/... oppositions against a GMP dependency
532 2013-03-11 18:14:16 <jgarzik> sipa: picocoin.git is monitoring your efforts closely ;p
533 2013-03-11 18:14:38 <jgarzik> sipa: surely it's LGPL'd, so works even with proprietary software
534 2013-03-11 18:14:44 <sipa> it's LGPL indeed
535 2013-03-11 18:14:48 <Luke-Jr> sipa: LICENSE="LGPL-3"
536 2013-03-11 18:14:55 <jgarzik> sipa: most of these Younger Kids(tm) seem to not care about licenses, as long as the software works
537 2013-03-11 18:14:57 <jgarzik> :)
538 2013-03-11 18:14:58 <Luke-Jr> can't think of any problems
539 2013-03-11 18:15:05 <sipa> to clarify: best performance on OpenSSL: 165us, best performance on GMP: 136us
540 2013-03-11 18:15:46 <sipa> that is for a full ECDSA signature check, including pubkey decompression
541 2013-03-11 18:15:59 <sipa> not including any bitcoin-specific processing like calculating the message hash
542 2013-03-11 18:16:09 <xjrn> sipa seen https://github.com/MetaScale/nt2 ?
543 2013-03-11 18:16:54 <Luke-Jr> GMP seems to have no dependencies of its own..
544 2013-03-11 18:18:09 <Luke-Jr> seems KDE, GCC, and GHC depend on GMP, so it should be a standard part of most OS
545 2013-03-11 18:18:39 <Luke-Jr> so probably the only real cost is in Windows binary size increase, which IMO doesn't matter much
546 2013-03-11 18:18:39 <sipa> it's really just one operation for which it matters, modular inversion, and it's only used twice per signature check; but OpenSSL needs 26us for it, and GMP only 3us
547 2013-03-11 18:19:06 <Luke-Jr> sipa: any reason not to submit a patch to OpenSSL to improve it there?
548 2013-03-11 18:19:55 <sipa> Luke-Jr: that's also an option - i haven't investigated where the performance difference comes from, as both libraries use assembly-based optimized code at several levels
549 2013-03-11 18:20:13 <sipa> but somehow i like the idea of not depending on OpenSSL...
550 2013-03-11 18:20:27 <fiesh> there's also http://bsdmp.org/, offering a less restrictive license
551 2013-03-11 18:20:30 <Luke-Jr> well, I imagine removing the OpenSSL dependency is more complicated than just using GMP
552 2013-03-11 18:20:32 <fiesh> maybe worth checking out how fast it is
553 2013-03-11 18:20:52 <sipa> Luke-Jr: if we stick to RPC-SSL support, ditching OpenSSL is no option at all
554 2013-03-11 18:21:05 <Luke-Jr> fiesh: which isn't even packaged in some OS, let alone a standard component???
555 2013-03-11 18:21:06 <fiesh> and then there's the original bsd library... what was it called again
556 2013-03-11 18:21:16 <warren> Is this stuff for like 0.9?
557 2013-03-11 18:21:26 <fiesh> Luke-Jr: of course I mean integrating it into the bitcoin source
558 2013-03-11 18:21:31 <_dr> sipa: did you have a look at http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/polynomial-multiplication-instructions-paper.pdf?
559 2013-03-11 18:21:36 <Luke-Jr> sipa: I'm not sure why we even support RPC-SSL considering exposing it to an untrusted network is unsupported/discourage
560 2013-03-11 18:21:45 <Luke-Jr> fiesh: even worse
561 2013-03-11 18:21:54 <sipa> warren: who knows; at this point, it's just experimenting
562 2013-03-11 18:22:06 <xjrn> sipa mguanard and jfalcou on freenode maintain nt2 in #nt2 oddly enough.  you'd be able to use headers-only afaik
563 2013-03-11 18:22:08 <Luke-Jr> although, it looks like BSDMP is a drop-in alternative for GMP, so coding for GMP should work fine
564 2013-03-11 18:22:21 <warren> sipa: I welcome this very much as Fedora/RHEL lacks ecdsa
565 2013-03-11 18:22:26 <_dr> they do several karatrusba runs to approximate the 256bit mult with carryless 64bit mult
566 2013-03-11 18:22:26 <warren> sipa: in openssl
567 2013-03-11 18:22:50 <warren> hmm, what GNU library is this?
568 2013-03-11 18:23:09 <Luke-Jr> nevermind, BSDMP makes no sense
569 2013-03-11 18:23:12 <fiesh> oh, the traditional bsd library is just called libmp
570 2013-03-11 18:23:21 <sipa> _dr: seems interesting; there are certainly multiple improvements possible still with the field operations
571 2013-03-11 18:23:36 <fiesh> Luke-Jr: yeah, seems to be not well enough developed, I agree -- I found it accidentally when looking for the original BSD library
572 2013-03-11 18:23:41 <sipa> warren: i don't feel like being responsible for the entire ECDSA verification stack in bitcoin, so i'm not eager to have this merged without very serious review anyway
573 2013-03-11 18:24:09 <warren> sipa: you're implementing one embedded in bitcoin itself, or switching to another library?
574 2013-03-11 18:24:31 <fiesh> oh but the current bsd mp implementation just uses openssl, hehe... so no gains there
575 2013-03-11 18:24:41 <Luke-Jr> lol
576 2013-03-11 18:24:43 <sipa> warren: at this point, it's even independent of bitcoin; i just started writing an ECDSA implementation specific for secp256k1 from scratch, with all optimizations i know of
577 2013-03-11 18:25:10 <sipa> warren: and given that it's significantly faster than OpenSSL at this point, it would be nice to take advantage of it
578 2013-03-11 18:25:12 <_dr> sipa: then have a look at that paper
579 2013-03-11 18:25:42 <_dr> my guess is you won't get faster than the guys at intel, their crytpo library is the fastest since they know their hardware
580 2013-03-11 18:26:28 <sipa> well, this is for one specific curve
581 2013-03-11 18:26:30 <xjrn> https://en.bitcoin.it/wiki/Secp256k1 looks like a static eval field-day
582 2013-03-11 18:26:40 <_dr> they do a clever trick. while they only use a 64bit multiplication, they use the ymm registers to keep the results of the intermedia steps in the 256 bit vector registers
583 2013-03-11 18:28:06 <sipa> _dr: i don't want to go into maintaining our own assembly-optimized versions
584 2013-03-11 18:28:36 <_dr> also, the carryless instruction is part of aes-ni, which is availabe in all core cpus so you won't have to use a sandy bridge cpu
585 2013-03-11 18:29:45 <_dr> sipa: you can always use intrinsics, but IMO maintaining a well written and documented assembly kernel is doable. you'd only have to write the 'hot' parts in actual assembly
586 2013-03-11 18:30:00 <sipa> sure, and those are very limited
587 2013-03-11 18:30:28 <sipa> my current field implementation uses 5 64-bit integers, each holding 52 bits
588 2013-03-11 18:30:54 <sipa> so no carry is needed to add the result of several multiplications
589 2013-03-11 18:31:12 <_dr> i think they list their code at the end of the paper, they claim a 6x speedup comparing to openssl 1.0.0a wrt 256 ecdsa signing
590 2013-03-11 18:31:44 <_dr> no sorry, 6x speedup wrt verification! signing is slower, but who cares ;)
591 2013-03-11 18:31:49 <sipa> i'm already close to a 5x speedup over OpenSSL :p
592 2013-03-11 18:32:02 <_dr> wow, very nice
593 2013-03-11 18:32:31 <sipa> but there are secp256k1-specific optimizations at every level
594 2013-03-11 18:32:53 <sipa> so that 5x speedup is certainly not (only) because of fast field operations
595 2013-03-11 18:33:18 <sipa> 5x is exaggerated i think; it's closer to 4x
596 2013-03-11 18:34:47 <_dr> and once again we see that single-core optimization is worthwhile
597 2013-03-11 18:34:48 <xjrn> sipa straight c?
598 2013-03-11 18:35:12 <K1773R> Luke-Jr, didnt know that, ty! gonna check it out :) is it possible to mine on multiple chains or just 1 altchain?
599 2013-03-11 18:36:45 <_dr> and we'll get another boost from HNI once skywell is out. i think they'll actually do 128bit ints
600 2013-03-11 18:37:05 <sipa> hni?
601 2013-03-11 18:37:23 <Luke-Jr> K1773R: Eloipool depends on a fork of merged-mining-proxy to handle that all; it should handle unlimited chains so long as you have Eloipool's merkletree.py available to it
602 2013-03-11 18:37:45 <Luke-Jr> _dr: GCC already has 128-bit ints on some platforms
603 2013-03-11 18:38:03 <sipa> Luke-Jr: GCC does; hardware doesn't
604 2013-03-11 18:38:06 <_dr> Luke-Jr: I'm talking about native
605 2013-03-11 18:38:20 <Luke-Jr> sipa: AFAIK, GCC only provides it when the hardware does - including modern x86
606 2013-03-11 18:38:27 <sipa> Luke-Jr: no
607 2013-03-11 18:38:41 <_dr> sipa: AVX2. the documents says The 128-bit numeric processing instructions in AVX cover floating-point and
608 2013-03-11 18:38:44 <_dr> integer data processing across 128-bit vector and scalar processing
609 2013-03-11 18:38:44 <sipa> Luke-Jr: the hardware has a 64bit * 64bit multiplication with 2x 64-bit output
610 2013-03-11 18:39:07 <sipa> Luke-Jr: GCC's __int128 is an aggregate of two 64-bit variables that is needed to capture the output of such an instruction
611 2013-03-11 18:39:10 <_dr> Luke-Jr: i can assure you there's no support for 128bit mult in hardware yet (unfortunately)
612 2013-03-11 18:39:35 <sipa> Luke-Jr: but adding two __int128 together for example will be translated to separate additions on separate registers
613 2013-03-11 18:39:45 <_dr> at least for intel cpus. there may be more exotic architecures that provite it, though
614 2013-03-11 18:40:04 <Luke-Jr> :<
615 2013-03-11 18:40:39 <sipa> so in a sense there is an extremely-limited support for 128-bit types in the hardware indeed: namely as the result of a 64-bit * 64-bit multiplication
616 2013-03-11 18:42:53 <gmaxwell> It just carries on the same thing i386 had-> a 32x32->64h/l which was also inaccessible in C except via long long... amd64 just scaled up the registers so you got a 64x64->64h/l
617 2013-03-11 18:44:43 <_dr> i really wonder why they don't have them though. can't be that hard, can it? avx has 256 bits, but no integer instructions at all
618 2013-03-11 18:45:54 <Luke-Jr> _dr: AVX2 is supposed to have 256-bit int as well I hear
619 2013-03-11 18:46:18 <gmaxwell> _dr: the avx2 stuff adds all the integer operations, but those are vector registers. The complexity of doing 8 32 bit multiplies is much lower than 2 128 bit ones. :P
620 2013-03-11 18:47:08 <_dr> yeah I know, but... if you have the large registers, why not offer an instrction that does the 256 bit multiplication in hardware, but slower than a 32/64 bit multiplication
621 2013-03-11 18:47:48 <_dr> all these instructions are pipelined, so using a larger operad size would just increase the latency
622 2013-03-11 18:54:47 <_dr> sipa: is your code on github?
623 2013-03-11 19:03:34 <HM> faster verification is awesome
624 2013-03-11 19:03:58 <HM> i wonder how well it'd run on arm
625 2013-03-11 19:07:13 <ThomasV> can ecdsa be used for message encryption?
626 2013-03-11 19:08:02 <Luke-Jr> no
627 2013-03-11 19:08:21 <Luke-Jr> but it could sign a key that is
628 2013-03-11 19:08:37 <ThomasV> oh: http://stackoverflow.com/questions/3098005/is-it-possible-to-use-elliptic-curve-cryptography-for-encrypting-data
629 2013-03-11 19:08:58 <gmaxwell> the ECC keys we use certantly can be, but thats not ECDSA
630 2013-03-11 19:09:17 <HM> public key encryption is a matter of some complexity, especially if you want authentication using the same key
631 2013-03-11 19:09:26 <ThomasV> gmaxwell: yeah, I meant the keys
632 2013-03-11 19:10:43 <warren> sipa: sorry disappeared earlier, power went out
633 2013-03-11 19:11:01 <warren> sipa: what's the link again?
634 2013-03-11 19:34:21 <sipa> warren, _dr: https://github.com/sipa/secp256k1
635 2013-03-11 20:11:51 <_dr> thanks
636 2013-03-11 20:18:04 <egecko> ok.. quick query.. what are command line flags to have it read from block chain from one directory and the wallet from a different one?  i see -datadir but it looks like block chain and wallet have to be in the same directory, is that correct?
637 2013-03-11 20:18:32 <weex> yup
638 2013-03-11 20:18:41 <egecko> bummah!
639 2013-03-11 20:18:45 <egecko> oh well
640 2013-03-11 20:23:58 <sipa_> egecko: symlinks to the rescue
641 2013-03-11 20:24:03 <rdponticelli1> egecko: Just use a symlink
642 2013-03-11 20:25:37 <egecko> yeah, that'll get done once this node finishes reindexing the block chain
643 2013-03-11 20:26:00 <egecko> anyway to tell when a daemon is done reindexing?
644 2013-03-11 20:26:08 <egecko> other than watching for the CPU usage to drop?
645 2013-03-11 20:43:58 <egecko> well at least bitdozer still works with 0.8!
646 2013-03-11 20:46:03 <nick___> hello
647 2013-03-11 20:46:22 <sipa> what is bitdozer?
648 2013-03-11 20:46:30 <nick___> no idea
649 2013-03-11 20:47:07 <egecko> its a windows client for access bitcoin servers
650 2013-03-11 20:47:10 <egecko> windows phone
651 2013-03-11 20:48:22 <egecko> pretty useful if you wanna send coins from your windows phone :)
652 2013-03-11 20:48:31 <nick___> anyone have success with the socketio / websockets c# projects on github? i load the examples and it connects but no trade messages are ever sent to my client by the server
653 2013-03-11 20:48:33 <alexwaters> 
ACTION envisions a bulldozer paid for in bitcoin - bulldozing a local bank - because of bitcoin

654 2013-03-11 20:49:37 <nick___> with socketio i never get back confirmation messages that my subscriptions were ack, and i've tried dozens of different types of message formats to try to get a subscription to work
655 2013-03-11 21:52:45 <HM> hmm the exchange rate for selling my $ers seems favourable right now
656 2013-03-11 21:53:00 <HM> (in to ?? as well as Bitcoin)
657 2013-03-11 21:53:12 <HM> err not Bitcoin, just ?? :P