1 2013-10-23 10:11:14 <petertodd> http://pbfcomics.com/168/
  2 2013-10-23 10:11:21 <petertodd> I'm too hip for smbc now
  3 2013-10-23 10:11:35 <petertodd> (and too dada)
  4 2013-10-23 10:27:47 <TD> gmaxwell: awake?
  5 2013-10-23 10:28:26 <gmaxwell> TD: Yep.
  6 2013-10-23 10:28:45 <gmaxwell> (In Scotland right now)
  7 2013-10-23 10:28:48 <TD> i need an ECC lesson :) the order n - is that a property of the curve, or of a curve point?
  8 2013-10-23 10:28:57 <TD> the SEC documents seem to use it in both contexts
  9 2013-10-23 10:29:02 <TD> i thought it was of the curve
 10 2013-10-23 10:29:28 <gmaxwell> TD: in sane curves for ecc there is only a single subgroup, all points have a cycle of the same order.
 11 2013-10-23 10:29:30 <TD> that is, i thought it was the number of valid points on the curve
 12 2013-10-23 10:29:58 <gmaxwell> But you can have a curve with multiple subgroups.. start at one point and you'll cycle back to it after X steps, start with another point, you'll cycle after Y.
 13 2013-10-23 10:30:08 <TD> right, so it's basically a property of the curve and the way the SEC documents express it (order n of G) is just another way to say the same thing
 14 2013-10-23 10:30:12 <gmaxwell> (and those subgroups are thus mutually exclusive)
 15 2013-10-23 10:30:21 <gmaxwell> TD: right.
 16 2013-10-23 10:30:22 <TD> ok, thanks.
 17 2013-10-23 10:30:30 <TD> got it. how is scotland? foggy, i would imagine
 18 2013-10-23 10:30:38 <gmaxwell> rainy this morning. :)
 19 2013-10-23 10:32:04 <TD> ah, some variety :)
 20 2013-10-23 10:32:12 <gmaxwell> (We use curve with only one subgroup for ECC because they reduce the order possible for the larger one (because points are split into two or more groups), and if one of the subgroups has a very small cycle, using points on it would render you insecure)
 21 2013-10-23 10:37:04 <TD> yes, that makes sense
 22 2013-10-23 10:38:27 <TD> one more question
 23 2013-10-23 10:39:52 <TD> actually n/m
 24 2013-10-23 10:44:04 <sipa> TD: iirc they do define the cofactor h for the subgroup generated by the generator; if that is 1, it is equal to the size of the group
 25 2013-10-23 10:44:27 <TD> right. they do indeed.
 26 2013-10-23 10:44:37 <TD> i'm implementing the S canonicalization for bitcoinj
 27 2013-10-23 10:44:41 <TD> hence my questions
 28 2013-10-23 10:44:51 <TD> ACTION learned today what the cofactor variable means
 29 2013-10-23 10:48:50 <sipa> TD: in any case; if S > n/2, S = n - S
 30 2013-10-23 10:49:27 <gmaxwell> TD: thanks for implementing that.
 31 2013-10-23 10:50:27 <TD> sipa: sure, i can read the code, i was just using it as an excuse to learn more maths
 32 2013-10-23 10:50:44 <TD> don't want to implement this stuff when <100% confident i understand the reasoning
 33 2013-10-23 10:50:51 <sipa> of course
 34 2013-10-23 10:51:52 <TD> there we go: https://code.google.com/p/bitcoinj/source/detail?r=ddf9d9f4e017ea355528892074a52683d4c91681
 35 2013-10-23 10:54:39 <sipa> TD: LGTM
 36 2013-10-23 11:16:47 <gmaxwell> woo: 2013-10-23 11:13:34 ERROR: DisconnectBlock() : outputs still spent? database corrupted
 37 2013-10-23 11:16:51 <gmaxwell> 2013-10-23 11:13:37 ERROR: VerifyDB() : *** coin database inconsistencies found (last 31 blocks, 33821 good transactions before that)
 38 2013-10-23 11:16:59 <gmaxwell> wish I knew how I caused it!
 39 2013-10-23 11:18:42 <gmaxwell> linux, clean shutdown of the node last execution. No system reboot.
 40 2013-10-23 11:19:35 <sipa> weird :o
 41 2013-10-23 11:19:41 <CodeShark> perhaps we should add more debug tracers to the db code
 42 2013-10-23 11:20:02 <sipa> that should be easy... we only write to it from one plac
 43 2013-10-23 11:20:27 <sipa> but i doubt it will help
 44 2013-10-23 11:21:07 <CodeShark> leveldb is supposed to support atomic operations, no?
 45 2013-10-23 11:21:11 <sipa> yes
 46 2013-10-23 11:21:25 <sipa> but that is irrelevant even in case of a clean shutdown
 47 2013-10-23 11:22:49 <gmaxwell> https://people.xiph.org/~greg/db.failure.txt  < see anything interesting it there?  (unmodified, except for some Addtowallet events, debug log end of the last successful execution and the end of the one before it)
 48 2013-10-23 11:25:16 <Delerium> Has the recommended fee really gone up 100% to 0.005 now?
 49 2013-10-23 11:25:37 <MC1984_> up?
 50 2013-10-23 11:26:01 <sipa> i know of no "recommended" fee?
 51 2013-10-23 11:26:10 <gmaxwell> Delerium: can you please give some more context?
 52 2013-10-23 11:26:34 <sipa> in many cases, cleints enforce a minimum fee to guarantee propagation on the network
 53 2013-10-23 11:26:44 <sipa> this fee depends on the size (in kilobytes) of the transaction
 54 2013-10-23 11:27:02 <sipa> so in case you need to spend many old coins, the fee may go up
 55 2013-10-23 11:27:13 <sipa> (coins as in individual transaction outputs)
 56 2013-10-23 11:27:20 <gmaxwell> normally 0.0001/kb, since thats what most of the network requires for very low priority transactions
 57 2013-10-23 11:27:20 <MC1984_> fees affect propagation?
 58 2013-10-23 11:27:28 <gmaxwell> sipa: s/old //
 59 2013-10-23 11:27:35 <Delerium> sorry, for example mtgox have now increased their fee up from 0.005 from 0.0005
 60 2013-10-23 11:27:52 <Delerium> up to*
 61 2013-10-23 11:28:01 <sipa> complain to mtgox then :)
 62 2013-10-23 11:28:03 <MC1984_> thats more than 100%
 63 2013-10-23 11:28:20 <gmaxwell> Delerium: dunno what mtgox is up to, they've had problems with transactions confirming slowly, but I don't believe they were generally fee related. E.g. they were creating invalid transactions, I dunno if they've fixed that yet.
 64 2013-10-23 11:29:08 <Delerium> seems a little drastic for a 100% increase, just wanted to check what the 'norm' fee was these days
 65 2013-10-23 11:31:25 <CodeShark> look at the most recent blocks and calculate fee statistics
 66 2013-10-23 11:32:44 <gmaxwell> Delerium: thats 1000% btw.
 67 2013-10-23 11:33:23 <Delerium> good point
 68 2013-10-23 11:33:41 <Delerium> its almost a bank charge now... not the way i'd like bitcoin to go
 69 2013-10-23 11:36:27 <keyboard> I'd expect high tx fees because tx end up in everyones hard disks
 70 2013-10-23 11:38:26 <CodeShark> you don't need to keep them if you don't need to be relaying full blocks to others
 71 2013-10-23 11:38:55 <CodeShark> you can even do full verification and then trash the txs that you don't care about, only keeping the block headers
 72 2013-10-23 11:39:00 <MC1984_> gmaxwell in scotland, business or pleasure?
 73 2013-10-23 11:39:36 <gmaxwell> MC1984_: I'm speaking at a conference (non bitcoin stuff)
 74 2013-10-23 11:39:54 <MC1984_> oh cool
 75 2013-10-23 11:40:14 <MC1984_> welcome to sunny uk lol
 76 2013-10-23 11:41:16 <gmaxwell> I'll be in vancouver in a week, another sunny place. :P
 77 2013-10-23 11:44:31 <TD> Delerium: i'd agree with you that fees are too high, although that sounds like mtgox had too many complaints about slowly confirming txns and didn't understand the root cause
 78 2013-10-23 11:44:45 <TD> Delerium: (in which case the higher fee won't solve their problem)
 79 2013-10-23 11:45:05 <Delerium> yup trying to relay that to MT :P
 80 2013-10-23 11:45:39 <TD> fees used to be much lower and things worked fine, but because they're hard-coded at the moment when the exchange rate went up by 20x, so did the fee ....
 81 2013-10-23 11:46:37 <Delerium> yeah but a 1000% jump is just a little bit ridiculous by them
 82 2013-10-23 11:46:57 <Delerium> if they must change fees, they should perhaps give customers a tiered fee system (High/Med/Low) etc
 83 2013-10-23 11:47:08 <TD> right. it sounds like a quick sledgehammer move ....
 84 2013-10-23 11:47:11 <TD> hopefully they'll fix it
 85 2013-10-23 11:47:15 <Delerium> idd
 86 2013-10-23 11:47:27 <TD> though i have no idea if people are even still able to move fiat in and out of mtgox right now. their lack of communication on their status is not great
 87 2013-10-23 11:47:50 <Delerium> you can via SEPA, international wires, the queue is massive :/
 88 2013-10-23 11:48:25 <TD> yeah i know they technically support it, i meant, "even still able in practice"
 89 2013-10-23 11:48:38 <MC1984_> do they even care any more
 90 2013-10-23 11:48:48 <Delerium> very much so
 91 2013-10-23 11:48:55 <TD> i'm sure they do, but it must be very hard for them to get banking partners since their legal issues
 92 2013-10-23 11:48:57 <Delerium> my fiance works for their support team
 93 2013-10-23 11:48:57 <TD> (in the usa)
 94 2013-10-23 11:49:12 <MC1984_> well shit
 95 2013-10-23 11:49:17 <TD> it seems all exchanges are having big problems getting bank accounts
 96 2013-10-23 11:49:29 <MC1984_> yup
 97 2013-10-23 11:49:34 <Delerium> number 1 problem = banks
 98 2013-10-23 11:49:52 <Delerium> they have a monopoly and power, why would they want to release that
 99 2013-10-23 11:50:01 <TD> i doubt it's about competitive issues now
100 2013-10-23 11:50:05 <Delerium> but sorry, going way off topic in this chan
101 2013-10-23 11:50:10 <TD> they're all just scared of the US Treasury dept
102 2013-10-23 11:51:32 <MC1984_> but i was told the banks run the govt
103 2013-10-23 11:51:41 <TD> not at all
104 2013-10-23 11:52:48 <MC1984_> are you saying i have been misinformed sir
105 2013-10-23 13:31:58 <topi`> what happens if I import a privkey into Multibit wallet, and have specified the date (how far back to look for transactions) too late? Will it miss the few vital transactions?
106 2013-10-23 13:32:13 <topi`> I guess I just need to delete that wallet and create a new one and repeat, rinse, lather
107 2013-10-23 13:33:29 <topi`> it just shows the balance wrong?
108 2013-10-23 13:33:36 <topi`> i.e. doesn't allow me to spend all of it
109 2013-10-23 13:34:32 <TD> yeah
110 2013-10-23 13:34:38 <TD> i think jim puts in some slack though
111 2013-10-23 13:34:48 <TD> you could check the balance multibit thinks you have vs what blockchain.info thinks
112 2013-10-23 13:34:49 <topi`> ok :)
113 2013-10-23 13:35:17 <topi`> under no circumstances could those outputs change to "unspendable" in any case I presume?
114 2013-10-23 13:35:41 <CodeShark> unless someone steals your keys :)
115 2013-10-23 13:35:43 <topi`> since that would be a silly way to leak money out of the max 21 million ...
116 2013-10-23 13:35:52 <TD> it's really just best to make sure you pick the right date
117 2013-10-23 13:36:09 <topi`> TD: I agree, but it's easy to forget when you forge the .key file manually ;)
118 2013-10-23 13:36:19 <t7> i still think there will be a place for banks, even if everyone used bitcoin. Banks can provide physical security
119 2013-10-23 13:36:24 <TD> ah. well, that's totally unsupported of course
120 2013-10-23 13:36:41 <t7> i dont wanna get tortured for my private key to my life savings
121 2013-10-23 13:36:46 <topi`> TD: I'm completely used to doing totally unsupported things ;)
122 2013-10-23 13:37:22 <topi`> t7: why not split the key between others you trust? like, your wife and you both know just one half fo the key
123 2013-10-23 13:37:33 <topi`> ok, that might turn very bad in case of a divorce...
124 2013-10-23 13:37:45 <t7> also in a bitcoin only world, tax returns could be generated for you by a government blockchain scanner
125 2013-10-23 13:38:18 <topi`> yeah, no more grey economy, everything in the open ledger ;)
126 2013-10-23 13:38:19 <t7> say goodbye to your privacy
127 2013-10-23 13:39:08 <CodeShark> there will be ways to mitigate that eventually
128 2013-10-23 13:39:35 <CodeShark> right now the user experience in bitcoin is terrible enough
129 2013-10-23 13:39:44 <CodeShark> without the additional complexity of trying to really mitigate privacy
130 2013-10-23 13:40:43 <CodeShark> however, eventually much of the complexity will be hidden from the enduser
131 2013-10-23 13:41:19 <CodeShark> bitcoin is just proof of concept that it's possible to create a decentralized p2p currency
132 2013-10-23 13:41:32 <CodeShark> it's an early biplane - we're still learning how to get off the ground
133 2013-10-23 13:41:56 <CodeShark> we haven't even neared the jet age
134 2013-10-23 13:43:11 <topi`> in Multibit, is it wise to delete a wallet with balance > 0 btc?
135 2013-10-23 13:43:22 <topi`> I *know* I have the private keys in safe, though
136 2013-10-23 13:43:52 <CodeShark> if you have the private keys you can always rescan the chain (preferably using bloom filters and multiple connections)
137 2013-10-23 13:43:54 <topi`> or rather, I'll just create another wallet, and import the same privkey there. let's see...
138 2013-10-23 13:44:14 <topi`> yeah, bloom filter would be useful
139 2013-10-23 13:45:40 <topi`> especially since my coins go back to early 2011 :)
140 2013-10-23 13:45:55 <CodeShark> I'm currently working on exactly that :)
141 2013-10-23 13:46:06 <CodeShark> a bloom filter scanner for synching wallets
142 2013-10-23 13:46:25 <topi`> cool. I've only once implemented a bloom filter, and that was from a damn tutorial ;)
143 2013-10-23 13:46:46 <topi`> but the concept itself is simple, and implementation easy if you use Redis
144 2013-10-23 13:47:41 <topi`> I guess the Multibit is based on the bitcoinj codebase
145 2013-10-23 13:47:59 <topi`> I'm tempted in creating an alternative lite client in Haskell :)
146 2013-10-23 13:48:24 <CodeShark> I'm using natively compiled code for practically everything
147 2013-10-23 13:48:42 <CodeShark> I want this to be FAST
148 2013-10-23 13:48:53 <topi`> for readability, C++ sucks. and same - partially - applies to java.
149 2013-10-23 13:49:13 <CodeShark> there are many different styles, idioms, and practices in both languages
150 2013-10-23 13:49:29 <CodeShark> it takes a while to get used to some of them, and some of them are very clever while some suck
151 2013-10-23 13:49:35 <topi`> if you had looked at compiler shootout benchmarks, you'd know the Haskell compiler is within a striking distance from G++
152 2013-10-23 13:49:40 <gfawkes_> cant really blame a language. blame the coders who are writing code that is not readable ;)
153 2013-10-23 13:50:27 <topi`> gfawkes_: well, higher level code enhances readability. Take for example C++ vs. Python
154 2013-10-23 13:50:47 <topi`> both perfectly object oriented, but C++ syntax is just distracting
155 2013-10-23 13:50:49 <Musk> Python was good until 3.x
156 2013-10-23 13:51:12 <CodeShark> C++ supports a very wide variety of coding styles and techniques - it can be made very readable, but yes - it generally requires a more in-depth understanding to be able to really use it well
157 2013-10-23 13:51:44 <CodeShark> it's the price to pay for greater control
158 2013-10-23 13:52:04 <Musk> Battle of languages are pointless, using a language is all about solving issues, confort zone and nerdity.
159 2013-10-23 13:52:16 <CodeShark> what Musk said :)
160 2013-10-23 13:53:03 <Musk> and nerdity is pretty much your cult of allegiance to a specific language / platform / framework.. etc..
161 2013-10-23 13:53:43 <topi`> indeed.. I've been a linux dude from day 0
162 2013-10-23 13:54:06 <CodeShark> I also find myself sometimes getting stuck in a rut - but I make an effort to learn something different often
163 2013-10-23 13:54:42 <CodeShark> it can be frustrating at first not being as productive as you're used to being as you begin working with something new
164 2013-10-23 13:54:54 <Musk> topi` who woudn't really.. people who hate linux 90% of the time is due to total ignorance of the OS.
165 2013-10-23 13:55:01 <topi`> CodeShark: exactly my sentiments after starting with java..
166 2013-10-23 13:55:35 <topi`> Musk: the same can be applied to Python, of course, BFDL and all :)
167 2013-10-23 13:55:39 <t7> Musk: my teacher in college used to say he hates linux and open source because 'any kid can now compile a website and steal credit card details'
168 2013-10-23 13:55:43 <CodeShark> but the upside is you add more tools to your toolkit and later on can find better solutions to problems
169 2013-10-23 13:56:19 <topi`> t7: by analogy, we should ban kitchen knifes, because they can be used to kill.
170 2013-10-23 13:56:32 <Musk> t7 i hope this is really a quotation and if it is shame on your teacher for not understanding anything related to IT... i mean "Compile a Website"
171 2013-10-23 13:56:37 <Musk> dafuq/
172 2013-10-23 13:56:47 <t7> he was a moron
173 2013-10-23 13:56:55 <topi`> make -f Makefile Website
174 2013-10-23 13:57:32 <topi`> didn't Facebook have a translator of sort that outputs C++ out of PHP code? they then literally "compile" their website :)
175 2013-10-23 13:57:34 <Musk> gcc website.cpp -o website <-- more like this
176 2013-10-23 13:57:42 <t7> i think he was making the point that it is very easy to change zencart or whatever software to spit out credit card numbers
177 2013-10-23 13:57:55 <Musk> topi` HipHop
178 2013-10-23 13:58:17 <topi`> speaking of PHP, yet another useless language
179 2013-10-23 13:58:23 <Musk> not really efficient in my opinion... maybe on huge scale but even there PHP isn't know for scalability
180 2013-10-23 13:58:34 <t7> but its a tiny con vs a lot of big pros
181 2013-10-23 13:58:55 <Musk> if it were me making a webapp today id use Node.JS
182 2013-10-23 13:59:11 <topi`> Musk: we used that in our corporate setting, and gave up
183 2013-10-23 13:59:15 <Musk> fast, efficient, scalable, cost effictive.
184 2013-10-23 13:59:22 <Musk> topi` o rly
185 2013-10-23 13:59:35 <Musk> didnt like 0.10.x  ?
186 2013-10-23 13:59:45 <topi`> perf was ok, but managing it gets complex, and it's not easy to get involved even if you know JS already
187 2013-10-23 14:00:06 <Musk> depends what kind of project... i guess.
188 2013-10-23 14:00:10 <topi`> but our problem was also the lack of a suitable control flow lib, like step.js or async.js
189 2013-10-23 14:00:25 <Musk> right.
190 2013-10-23 14:00:27 <topi`> that should have been done right from the beginning... fatal flaw
191 2013-10-23 14:00:49 <Musk> switched to python instead i assume ?
192 2013-10-23 14:01:04 <topi`> python on JVM (jython)
193 2013-10-23 14:01:15 <CodeShark> JS wasn't originally designed with large scale code structuring in mind. it outgrew its original intended purpose and eventually people discovered ways to structure it decently…but the structuring is an afterthought
194 2013-10-23 14:01:34 <topi`> CodeShark: ...in other words, it's called a "hack" :)
195 2013-10-23 14:01:35 <Musk> it seems to be the balance now people using either Node.JS or Python for these kinds of functionality/
196 2013-10-23 14:01:59 <topi`> Musk: I do think that in the right hands, Node.js is very productve
197 2013-10-23 14:02:01 <CodeShark> topi`: the funny thing is that js actually turned out to have some pretty powerful features
198 2013-10-23 14:02:20 <topi`> CodeShark: indeed, functions as first class objects
199 2013-10-23 14:02:36 <topi`> but I dislike the prototype-based class model
200 2013-10-23 14:02:57 <topi`> maybe that's because I learned python first
201 2013-10-23 14:03:27 <topi`> the great thing about python is that you have very, very few drawbacks, and none of them showstoppers
202 2013-10-23 14:03:38 <topi`> and the ecosystem is huge
203 2013-10-23 14:03:51 <CodeShark> the greatest feature of python, IMO, is its regularity
204 2013-10-23 14:04:01 <Musk> tried to learn Django once... gave up..
205 2013-10-23 14:04:06 <CodeShark> constructs have consistent syntax
206 2013-10-23 14:04:16 <Musk> not my usual way of thinking ^_^
207 2013-10-23 14:04:22 <topi`> CodeShark: that's why Guido gave us Python 3, which Musk dislikes ;)
208 2013-10-23 14:04:46 <CodeShark> I'm not generally big on frameworks, period - django is not so terrible, but I don't like to design to a framework
209 2013-10-23 14:04:59 <CodeShark> I like to pick and choose frameworks when they fit the particular project
210 2013-10-23 14:05:08 <CodeShark> or better yet, design my own :)
211 2013-10-23 14:06:10 <CodeShark> but the framework issue is wholely separate from the language issue
212 2013-10-23 14:06:34 <CodeShark> as a language, python is very regular
213 2013-10-23 14:06:43 <CodeShark> it's slow as hell, but you can't have everything :p
214 2013-10-23 14:07:11 <Musk> My point on this is that for me Python was more of a language to use to perform almost 'bash' script like operation but with more complexity... etc.
215 2013-10-23 14:07:29 <CodeShark> agreed, Musk - bash is an example of an extremely irregular language
216 2013-10-23 14:07:34 <Musk> Also wut i liked about python back in the days was how easy it was to manipulate sockets.
217 2013-10-23 14:07:54 <Musk> and do SDL also was pretty neet
218 2013-10-23 14:07:59 <CodeShark> on practically all points (except for barebones support practically everywhere) python beats bash hands down
219 2013-10-23 14:08:58 <Musk> no doubt but its like two diff things in a way.. don't think the mind set of bash was design to scale. lol
220 2013-10-23 14:10:02 <topi`> CodeShark: have you tried recent versions of PyPy? it's slowly approaching Google V8 engine speeds
221 2013-10-23 14:11:33 <topi`> I remember somebody implemented (phantomcircuit?) the bitcoin protocol in python
222 2013-10-23 14:11:47 <topi`> would be fun to try that on PyPy
223 2013-10-23 14:12:15 <CodeShark> all the math-intensive stuff still needs to be done in C/C++ (with inline asm if you want it to-the-metal)
224 2013-10-23 14:12:44 <CodeShark> but for things like user interfaces or control flow not involving extremely tight loops, it does the job
225 2013-10-23 14:13:34 <topi`> CodeShark: well, there's Cython :) you can compile your python project even as a standalone binary
226 2013-10-23 14:13:41 <Musk> CodeShark some scientist out there would point out Fortran ;)
227 2013-10-23 14:13:51 <topi`> but it's not really much faster unless you static type your variables
228 2013-10-23 14:15:01 <Musk> i don't know if it the new gen of dev not respecting their ancestors but it seems we are seeing a trend of people just trying to avoid using C/C++ even when its needed... Just like they despise this beautiful language.
229 2013-10-23 14:15:08 <Musk> its sad.
230 2013-10-23 14:15:40 <CodeShark> practically all systems software (including probably the operating system you're using right now) uses copious amounts of C/C++
231 2013-10-23 14:15:42 <t7> C++ is a BBW
232 2013-10-23 14:16:06 <t7> and im not really into them, and this analogy is breaking down because i do like C++ and its fast
233 2013-10-23 14:16:07 <CodeShark> most language interpreters and JIT for other languages is written using C/C++
234 2013-10-23 14:16:28 <Musk> CodeShark ofcourse unless ur on Mac which would be primarly Objective-C though the Kernel is probably written in C anyways
235 2013-10-23 14:17:35 <CodeShark> ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/src/mkernel/kernel/intel/
236 2013-10-23 14:17:39 <Musk> i wish there was more C out there...
237 2013-10-23 14:18:13 <Musk> ACTION tips is hat to ritchie and kernighan
238 2013-10-23 14:19:48 <CodeShark> and C++ continues to evolve - C++11 is a major improvement over its predecessor on many fronts
239 2013-10-23 14:20:58 <Musk> C++ 0x :D
240 2013-10-23 14:21:23 <Musk> :3
241 2013-10-23 14:21:44 <CodeShark> perhaps the biggest drawback of C/C++ is safety
242 2013-10-23 14:22:10 <topi`> Musk: I despise C/C++, but I'm old enough to have started with C and Assembler ;)
243 2013-10-23 14:22:28 <topi`> quite another thing is, to not to try to learn C/C++ *at all*
244 2013-10-23 14:22:47 <CodeShark> I really love compiletime optimization
245 2013-10-23 14:23:26 <CodeShark> that's the feature I most love about C++
246 2013-10-23 14:23:56 <CodeShark> it strikes a good balance between affording tremendous compiletime optimization and providing high level code organization constructs
247 2013-10-23 14:24:24 <Musk> topi` i started on C++ at 14 yr old :3
248 2013-10-23 14:24:40 <t7> Musk: same-ish maybe 12-13
249 2013-10-23 14:24:44 <Musk> was planning for world domination at this age :D
250 2013-10-23 14:24:55 <CodeShark> C affords at least as much compiletime optimization but lacks the high level code organization constructs
251 2013-10-23 14:25:07 <t7> now i teach basic IT and english :P
252 2013-10-23 14:25:32 <topi`> totally another thing, but does anyone have any discount codes for coinabul.com? :)
253 2013-10-23 14:25:42 <CodeShark> I started with BASIC as a kid :p
254 2013-10-23 14:25:58 <Musk> i did VB6 at 15yr old.
255 2013-10-23 14:26:51 <Musk> when i started College i coudn't keep with slow pace classes we had... espicially Visual Basic holyshit.. that was easy.
256 2013-10-23 14:27:08 <topi`> for me, Turbo Pascal in college ;)
257 2013-10-23 14:27:29 <Musk> i did some pascal and tried Delphi didn't really like those.
258 2013-10-23 14:27:43 <CodeShark> pascal is too verbose for my taste :)
259 2013-10-23 14:27:48 <Musk> ^
260 2013-10-23 14:28:32 <CodeShark> but pascal was sort of my introduction to structured programming
261 2013-10-23 14:28:34 <topi`> so, nobody here a Coinabul customer?
262 2013-10-23 14:28:36 <CodeShark> so I have to give it some credit
263 2013-10-23 14:29:27 <pigeons> topi`: try #bitcoin-otc
264 2013-10-23 14:29:46 <Musk> i should get back into doing some ASM... i think it should be helpful for possible futur project.
265 2013-10-23 14:31:45 <CodeShark> I should get back to bed :p
266 2013-10-23 14:48:16 <Eremes> anyone know how long to get 1 confirmation on blockchain ? its been 10 minutes without 1 confirmation
267 2013-10-23 14:48:39 <Eremes> err nvm its showing up now
268 2013-10-23 14:49:53 <Ry4an> Eremes: it could in theory be infinitely long, but that's pretty darn unlikely. :)
269 2013-10-23 14:50:13 <Eremes> Ry4an: thanks its suddenly showing 2 confirmation
270 2013-10-23 15:15:20 <lianj> anyone know the origin or reason for http://blockexplorer.com/tx/ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767 ?
271 2013-10-23 15:18:18 <gmaxwell> 01:21 < swulf--> anyone around to take a look at a txn? ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767 is weird
272 2013-10-23 15:18:21 <gmaxwell> 01:21 < swulf--> not sure why it's even valid
273 2013-10-23 15:18:22 <gmaxwell> 01:26 <@gmaxwell> scriptpubkeys are only parsed on spend.
274 2013-10-23 15:18:22 <gmaxwell> 01:26 <@gmaxwell> swulf--: why wouldn't it be?
275 2013-10-23 15:19:19 <lianj> gmaxwell: thanks. bummer for serialization roundtrips though :D
276 2013-10-23 15:20:11 <sipa> ?
277 2013-10-23 15:21:09 <lianj> like a blockexplorer or roundtrips from to json / from json
278 2013-10-23 15:32:05 <TD> interesting
279 2013-10-23 15:32:09 <TD> someone managed to make a script that nothing renders?
280 2013-10-23 15:32:15 <TD> i wonder what the outputs contain
281 2013-10-23 15:38:28 <lianj> TD: nothing, just breaking the parser
282 2013-10-23 15:38:43 <TD> oh, literally empty
283 2013-10-23 15:39:58 <lianj> like OP_PUSHDATA[01] with no content etc
284 2013-10-23 15:49:52 <jouke> lianj: Abe has problems with that transaction as well :)
285 2013-10-23 15:51:49 <lianj> bc.i's error is best
286 2013-10-23 16:11:46 <dobry-den> jegz: i gotcha.
287 2013-10-23 16:12:10 <dobry-den> jegz: that pursuit inspired me to work on my current project
288 2013-10-23 16:38:09 <warren> gmaxwell: jgarzik_: I asked spot if submitting the documentation detailing how secp256k1 is not covered by <known patents> will help them to review it, he said "probably".  secp256k1 was split into this new ticket, could you please re-post your summary here? https://bugzilla.redhat.com/show_bug.cgi?id=1021898  If the documentation is sensitive I might suggest submitting it to their legal directly.
289 2013-10-23 16:41:17 <petertodd> lianj: the tx has truncated PUSHDATA's in every possible form if you decode it by hand
290 2013-10-23 16:41:48 <petertodd> llanj: yeah, you can't do serialization round-trips at all currently due to the different pushdata forms
291 2013-10-23 16:41:56 <TD> petertodd: did you see this paper? http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
292 2013-10-23 16:42:08 <TD> it's all about block sizes, propagation delays and the impact on chain forking
293 2013-10-23 16:42:42 <lianj> petertodd: i did, and found a workaround for serialization round-trips
294 2013-10-23 16:43:06 <petertodd> TD: yah, it's on old data, though I made some very rough calculations and the basic idea seems to apply still
295 2013-10-23 16:43:53 <TD> i like christian but i found this paper somewhat disappointing. the data collection is good, but they missed a lot of ways to improve things. no mention of always relaying bloom filtered blocks, or analysis of why accepting transactions is slow.
296 2013-10-23 16:44:06 <TD> perhaps we should take out inv broadcasts for transactions though
297 2013-10-23 16:44:11 <sipa> TD: afaik, the measurements are from before 0.8 even
298 2013-10-23 16:44:19 <TD> ah
299 2013-10-23 16:44:21 <sipa> unless they were updated
300 2013-10-23 16:44:26 <TD> block height 180,000-200,000 i think
301 2013-10-23 16:44:35 <TD> i don't recall the height when 0.8 was released
302 2013-10-23 16:44:40 <TD> really we need ongoing analytics like that
303 2013-10-23 16:45:10 <TD> i was hoping jgarzik_ would write a tool to plot graphs like that on an ongoing basis but i guess he got swallowed by bitpays internal work     o_o
304 2013-10-23 16:45:34 <sipa> v0.8.0 was tagged on feb 18th
305 2013-10-23 16:46:01 <TD> oh, wow
306 2013-10-23 16:46:06 <TD> 180k was more than a year ago
307 2013-10-23 16:46:08 <petertodd> TD: right, but a lot of those improvements aren't trust free, which complicates things re: mining strategies. (though note how TXO commitments *really* could make this stuff non-uniform; a minimum guarantees UTXO set may be a nice thing to have, although hard to really make into a true protocol rule)
308 2013-10-23 16:46:09 <TD> time passes so quickly
309 2013-10-23 16:46:14 <lianj> petertodd: also something like "M\x01\x00"" was missing
310 2013-10-23 16:46:31 <TD> so yeah i guess propagation is looking a lot healthier these days
311 2013-10-23 16:46:57 <TD> that would explain the absence of mention of bloom filtering :)
312 2013-10-23 16:47:12 <lianj> there are some script that not even have a wrong length payload but no payload at all after its length field
313 2013-10-23 16:47:26 <petertodd> TD: my numbers weren't that it was much different re: blocks
314 2013-10-23 16:47:35 <petertodd> lianj: yeah, you mean pushdata's
315 2013-10-23 16:47:38 <sipa> well bloom filtering doesn't help propagation among full nodes
316 2013-10-23 16:47:46 <lianj> yes
317 2013-10-23 16:48:01 <TD> no but i mean, by simply making full-match filters the default, it would do
318 2013-10-23 16:48:05 <sipa> ah, the full filter approach could help, actually, by not resending txn that are already known
319 2013-10-23 16:48:09 <TD> and that'd be a nice bandwidth saving
320 2013-10-23 16:48:38 <TD> given that blocks have to criss-cross the world many times to fully flood the network, and relaying is serial, i guess reducing bandwidth for a new block can reduce propagation delay significantly
321 2013-10-23 16:50:07 <petertodd> TD: well you need the inverse to our current bloom filters actually... you want to match on what the other side doesn't have, with 0% false positives
322 2013-10-23 16:50:15 <petertodd> bbl
323 2013-10-23 16:50:31 <TD> that's what the bloom code already does. it watches what you've announced and pushes a merkle block followed by the transactions you're missing
324 2013-10-23 16:50:58 <TD> perhaps referring to it as bloom filtering is misleading. there's no filtering. it's just a way to re-use the existing code that sends loose transactions after a merkleblock message
325 2013-10-23 16:51:11 <petertodd> oh, right, good call
326 2013-10-23 16:51:31 <sipa> yeah, i don't think there's a disadvantage to doing that
327 2013-10-23 16:51:47 <sipa> it's limited by the degree of seen-txid retention your peer is willing to do
328 2013-10-23 16:52:38 <kuzetsa> is that amount even configurable?
329 2013-10-23 16:52:43 <petertodd> sipa: the disadvantages are all second-order effects by the perverse miner strategies, and network failure modes that it makes possible
330 2013-10-23 16:52:48 <kuzetsa> (how much seen-txid retension a node does)
331 2013-10-23 16:52:48 <petertodd> alrrhgt, I really gotta go :P
332 2013-10-23 16:52:55 <sipa> kuzetsa: no
333 2013-10-23 16:53:53 <sipa> ah, actually, yes
334 2013-10-23 16:54:02 <sipa> it's the number of kilobytes send buffer
335 2013-10-23 16:54:09 <sipa> so by default the last 1000 tixdsa
336 2013-10-23 16:54:12 <sipa> txids
337 2013-10-23 16:54:19 <kuzetsa> hmm
338 2013-10-23 16:54:58 <TD> we could easily fix that though
339 2013-10-23 16:58:11 <kuzetsa> it's not clear to me why these defaults were selected: -maxreceivebuffer=<n>  Maximum per-connection receive buffer, <n>*1000 bytes (default: 5000) /// -maxsendbuffer=<n>     Maximum per-connection send buffer, <n>*1000 bytes (default: 1000)
340 2013-10-23 16:58:53 <kuzetsa> or what an increase or decrease of either one might improve or harm
341 2013-10-23 17:00:29 <kuzetsa> whoa, 10 megabytes each? --> https://github.com/gavinandresen/bitcoin-git/commit/f36b494aebcfe4cc6a45003520ee7d15eeaba8df
342 2013-10-23 17:01:48 <TD> because we got ourselves into a bad state where bitcoind wasn't able to serve the block chain
343 2013-10-23 17:02:07 <TD> the "send buffer" is an artifact of the single-threaded nature of how bitcoin is written. the send buf has to be sized to be able to fit the maximum response into it
344 2013-10-23 17:02:31 <TD> heck, even 10mb is probably too small these days
345 2013-10-23 17:03:12 <TD> that's a good point actually
346 2013-10-23 17:03:18 <kuzetsa> but the defaults in 0.8.5 (I cut-copy-pasted above) says it's 1mb and 5mb respectively
347 2013-10-23 17:03:42 <kuzetsa> or is the in-built help just a liar and the defaults aren't what it says they are
348 2013-10-23 17:29:20 <Ascendion> *** sigh *** giving up on a reasonable bitcoin client as library implementation in C# -- gonna poll bitcoind for what I need :(
349 2013-10-23 17:30:27 <TD> Ascendion: you could use bitcoinj via IKVM too
350 2013-10-23 17:30:37 <Luke-Jr> Ascendion: !
351 2013-10-23 17:30:40 <Luke-Jr> Ascendion: where have you been?
352 2013-10-23 17:30:57 <Ascendion> up to my ass in RL problems and a new job
353 2013-10-23 17:31:11 <Luke-Jr> >_< glad to see you back (hopefully with those problems resolved..)
354 2013-10-23 17:31:24 <Ascendion> not 100% resolved but on the way to resolving them
355 2013-10-23 17:31:54 <Ascendion> might even have time to finish the mining board one of the days
356 2013-10-23 17:35:49 <Ascendion> TD -- is bitcoinj up to date -- and I mean VERY up to date ??
357 2013-10-23 17:38:52 <Ascendion> here is my problem -- I want to implement a client with a sql database backing store for the blockchain and transactions (and also for multiple wallets but thats later)... BitcoinSharp (fail - outdated or something) was based on BitcoinJ
358 2013-10-23 17:40:02 <Ascendion> BitcoinSharp had an interface for defining custom storage for the blockchain.. I'd need to be able to hook that with my c# based storage if I attempted this with BitcoinJ
359 2013-10-23 17:40:18 <Belxjander> Ascendion: I've been considering implimenting a BitCoin Wallet for AmigaOS myself... and need to look at receiving and sending transactions myself along with blockchain storage
360 2013-10-23 17:40:40 <Ascendion> god how old is your hardware ??
361 2013-10-23 17:41:23 <Ascendion> or are you running emulation ??
362 2013-10-23 17:41:26 <Belxjander> Ascendion: what? because of the name you assume the age?  my hardware is actually new and entirely PPC based
363 2013-10-23 17:41:48 <Belxjander> Ascendion: PowerPC AMCC440EP processor
364 2013-10-23 17:42:05 <Belxjander> and running the AmigaOS *native*
365 2013-10-23 17:42:39 <Ascendion> otay -- if dats what bakes your cookies :)
366 2013-10-23 17:42:45 <Belxjander> see www.acube-systems.biz << they show the boards with links to www.hyperion-entertainment.biz who make the OS
367 2013-10-23 17:42:48 <Luke-Jr> Ascendion: AmigaOS is still maintained and sold, IIRC
368 2013-10-23 17:43:01 <Ascendion> I'm looking at the amigaOS website now
369 2013-10-23 17:43:15 <Belxjander> Luke-Jr: yes it is... actively developed... "AmiWest 2013" was this week too
370 2013-10-23 17:43:42 <CircusPeanut> test
371 2013-10-23 17:44:29 <Ascendion> Belxjander -- if its got dev tools it shouldn't be TOO horrible of a job to port bitcoind over
372 2013-10-23 17:44:50 <Belxjander> Ascendion: well the first challenge is being able to *read* the code
373 2013-10-23 17:44:57 <Belxjander> and I don't comprehend C++ very well
374 2013-10-23 17:45:08 <Ascendion> why read it ?? does amigaOS have a gcc toolchain ??
375 2013-10-23 17:45:15 <Luke-Jr> it's too bad the best free GPUs are Intel :<
376 2013-10-23 17:45:21 <Belxjander> Ascendion: GCC yes, POSIX = no
377 2013-10-23 17:45:34 <Belxjander> Luke-Jr: "free" GPU?
378 2013-10-23 17:45:44 <Ascendion> that shouldnt be THAT much of an issue -- just have to rework the threading most likely
379 2013-10-23 17:46:07 <Luke-Jr> Belxjander: well, free on the software end
380 2013-10-23 17:46:13 <Belxjander> Ascendion: the "boost" library on AmigaOS is too old and not compiled with the same settings as bitcoind
381 2013-10-23 17:46:32 <Ascendion> so build a new one :)
382 2013-10-23 17:46:49 <Belxjander> Luke-Jr: the dev handling AmigaOS Radeon and RadeonHD drivers is getting official support afaik
383 2013-10-23 17:46:56 <Luke-Jr> Ascendion: C isn't very portable without some POSIX
384 2013-10-23 17:47:00 <Luke-Jr> even Windows has some POSIX
385 2013-10-23 17:47:24 <Luke-Jr> Belxjander: well, I'd only be interested in the hardware, as AmigaOS is non-free too :P
386 2013-10-23 17:47:43 <Luke-Jr> Belxjander: Radeons have sub-par free software support unfortunately
387 2013-10-23 17:47:53 <Luke-Jr> it's not *bad*, but it isn't as good as Intel GPUs
388 2013-10-23 17:47:56 <Belxjander> Luke-Jr: well that is certainly an option... since you don't need to install the OS license disk that comes with the board
389 2013-10-23 17:48:16 <Belxjander> Luke-Jr: any of those Intel GPUs on PCI or PCIe16 cards ?
390 2013-10-23 17:48:25 <Luke-Jr> no :<
391 2013-10-23 17:48:30 <Luke-Jr> that's the problem
392 2013-10-23 17:48:46 <Belxjander> Intel only bundles them as CPU built-in modules ?
393 2013-10-23 17:48:51 <Luke-Jr> they're all integrated in Intel CPUs
394 2013-10-23 17:49:20 <Ascendion> anyway -- I'll look at BitcoinJ if I dont get anywhere cloning the blockchain and transactions to my database using bitcoind/jsonrpc
395 2013-10-23 17:49:25 <Luke-Jr> ACTION wishes Intel would release specs for the microcode so someone could port PPC to their chips XD
396 2013-10-23 17:49:41 <Luke-Jr> Ascendion: parsing the blockchain is easy
397 2013-10-23 17:49:43 <Belxjander> right... standard "embrace and extend 101" for trying to tie the users and lock them into the family of products by the most subtle means possible
398 2013-10-23 17:50:25 <Ascendion> luke -- there is at least one PPC implementation for FPGA that I'm aware of .. dunno if its free but its out there
399 2013-10-23 17:50:44 <Luke-Jr> Ascendion: not what I mean :p
400 2013-10-23 17:50:52 <Luke-Jr> Ascendion: I mean turning an Intel CPU into a PPC architecture
401 2013-10-23 17:51:24 <Luke-Jr> there's microcode emulating x86 right now; no reason AFAIK a PPC variant couldn't be made if people had specs
402 2013-10-23 17:51:55 <Ascendion> I seriously doubt the PPC and X86 chips use compatible microcode on identical internal logic
403 2013-10-23 17:52:07 <Belxjander> Luke-Jr: and play with the "secret sauce"?
404 2013-10-23 17:56:44 <Belxjander> Ascendion: have you looked at the picocoin git repository?
405 2013-10-23 17:57:58 <CircusPeanut> I am implementing dumpprivkey(address) in the Armory Daemon. I noticed that it will not return the root private key for a wallet because that is keyed with "ROOT". I want dumpprivkey to work like the Bitcoin Daemon version and I want to be able to get the root private key. Suggestions?
406 2013-10-23 17:58:40 <CircusPeanut> I'm leaning towards just making a new method called dumprootprivkey()
407 2013-10-23 17:58:46 <dobry-den> The Bitcoin wiki does a great job of voluntarily annotating the reference spec. What is the state of the spec? Is there any work towards deliberating one?
408 2013-10-23 18:00:52 <dobry-den> I'm not even so sure what delineates a reference implementation from a spec. I suppose it's when any sort of arbitrary/inherited cruft has been removed from a system.
409 2013-10-23 18:04:53 <jgarzik> a reference implementation works. a spec is a rough guide to something that might work, after you learn all the lessons not mentioned in the spec.
410 2013-10-23 18:04:59 <jgarzik> that's the difference.
411 2013-10-23 18:06:22 <michagogo> cloud|dobry-den: some conversation has been happening on the mailing list about thy
412 2013-10-23 18:06:26 <michagogo> cloud|That*
413 2013-10-23 18:07:32 <michagogo> cloud|I think the archives are online somewhere, you can take a look
414 2013-10-23 18:07:40 <dobry-den> I'll check out the discourse
415 2013-10-23 18:10:00 <dobry-den> jgarzik: reference implementation works at the expense of ease of implementation
416 2013-10-23 18:10:41 <dobry-den> the uncertainty of what's a bug and what's a feature being the killer
417 2013-10-23 18:22:21 <warren> hmm, anyone know how get the unit tests to print debug info to the console?
418 2013-10-23 18:22:27 <warren> where is output currently redirected to?
419 2013-10-23 18:38:46 <helo> dobry-den: with bitcoin, an implementation bug must sometimes be considered a feature as far as alternative implementations are concerned
420 2013-10-23 18:39:14 <helo> dobry-den: i.e. if they don't implement the bug, they will be incompatible and broken
421 2013-10-23 18:41:39 <edcba> dobry-den: what kind of bug/features are you talking about ?
422 2013-10-23 19:01:27 <dobry-den> helo: Right, that's what I'm referring to.
423 2013-10-23 19:02:26 <helo> dobry-den: if there had been a spec, it would just have to be updated to reflect these kinds of bugs in the implementation, so it's not really very useful
424 2013-10-23 19:03:41 <dobry-den> Sure, but wouldn't a spec demystify what is intentional and what is not?
425 2013-10-23 19:03:45 <helo> ideally a perfect implementation of a perfect spec would be written. but barring exactly that, we're stuck in the present situation.
426 2013-10-23 19:04:29 <dobry-den> Of course, I'm not lamenting the lack of a spec. This topic started because I asked if there was any talk of arriving at one that I could check out.
427 2013-10-23 19:13:02 <Ascendion> Belxjander -- might look at it (picocoin) later but I'm more interested in a library rather than a full client I'd have to strip down -- BitcoinRPCSharp seems able to get me all I need at the expense of running a local bitcoind and having to poll for updates... bitcoinj is my 2nd alternative
428 2013-10-23 19:16:11 <shripadk> Hello all!
429 2013-10-23 19:16:25 <Ascendion> grrr @ shripadk :)
430 2013-10-23 19:17:57 <shripadk> I have a question: Why is it that in createrawtransaction a return address need to be provided while in sendtoaddress there is no need for one? From inspecting the txid of the two transactions I noticed that sendtoaddress doesn't use createrawtransaction under the hood.
431 2013-10-23 19:18:05 <shripadk> Ascendion: :)
432 2013-10-23 19:20:22 <Luke-Jr> shripadk: huh? there is no return address in createrawtransaction..
433 2013-10-23 19:20:55 <Luke-Jr> and there's a huge difference between createRAWtransaction and end-user methods like sendtoaddress
434 2013-10-23 19:21:47 <shripadk> Luke-Jr: By return address i mean this: If the sum of all unspent inputs > outputs then the difference goes as fees right? So if I want to pay 0.0001BTC as fee, I would have to provide a "return" address (address generated via getnewaddress) so that the change is returned to that address.
435 2013-10-23 19:22:02 <Luke-Jr> oh, the change address
436 2013-10-23 19:22:15 <shripadk> sorry ! change address is correct terminology
437 2013-10-23 19:22:18 <Luke-Jr> shripadk: well, that's because it's a raw command :p
438 2013-10-23 19:22:40 <shripadk> please explain the difference between createrawtransaction and sendtoaddress
439 2013-10-23 19:22:53 <shripadk> i'm more interested in the coin selection mechanism used by sendtoaddress
440 2013-10-23 19:23:39 <Luke-Jr> shripadk: createrawtransaction is a low-level tool; sendtoaddress is a more end-user tool
441 2013-10-23 19:24:43 <shripadk> Luke-Jr: how does sendtoaddress send the exact amount specified? I always thought that the amount is dictated by unspent inputs (which can be same or greater but never lesser).
442 2013-10-23 19:25:10 <Luke-Jr> shripadk: it creates a change address behind the scenes
443 2013-10-23 19:26:09 <shripadk> Luke-Jr: okay thanks :) so I was confused mainly because of the way getransaction JSON-RPC command reports transaction information
444 2013-10-23 19:27:58 <shripadk> Luke-Jr: if you perform a transaction using sendtoaddress, gettransaction  doesn't report the change address used (even the UI doesn't update the balance).. example: if I send 50BTC, and my balance is 100BTC… behind the scenes, input used is 62.5BTC and change returned is 12.4BTC (with 0.1BTC fee), the UI should get updated with the new balance right (until it receives 1 confirmation)?
445 2013-10-23 19:28:42 <shripadk> Luke-Jr: whereas If I use createrawtransaction and broadcast it, the UI updates correctly showing lower balance and only updates to the correct balance when the change has been returned
446 2013-10-23 19:29:11 <Luke-Jr> shripadk: your own transactions are considered confirmed immediately
447 2013-10-23 19:29:24 <Luke-Jr> not sure why that doesn't work with createrawtransaction
448 2013-10-23 19:30:35 <shripadk> Luke-Jr: it doesn't though… for instance I just sent 4BTC to address X with 30BTC as change and the UI is showing "Unconfirmed: 30 BTC"
449 2013-10-23 19:30:52 <shripadk> Luke-Jr: I have to wait for at least 1 confirmation for the UI to correct itself
450 2013-10-23 19:31:04 <Luke-Jr> hm
451 2013-10-23 19:34:05 <shripadk> Luke-Jr: even get balance reports the wrong balance
452 2013-10-23 19:34:12 <shripadk> is this a bug??
453 2013-10-23 19:35:38 <Luke-Jr> shripadk: maybe
454 2013-10-23 19:42:12 <phantomcircuit> shripadk, there is a bug with calculating the balance for unconfirmed transactions paid to yourself
455 2013-10-23 19:42:22 <phantomcircuit> in certain circumstances it can even display a negative balance
456 2013-10-23 19:42:55 <shripadk> phantomcircuit: okay thanks for letting me know :) is this documented somewhere?
457 2013-10-23 19:43:05 <phantomcircuit> not that i know
458 2013-10-23 19:44:19 <shripadk> phantomcircuit: so even if i have 0 balance and some X BTC in unconfirmed transactions, I can broadcast transactions right?
459 2013-10-23 19:44:56 <shripadk> when I say "broadcast transactions"  I mean regular transactions via sendtoaddress
460 2013-10-23 19:45:25 <phantomcircuit> yeah the coin selection algorithm will use unconfirmed outputs if it has to
461 2013-10-23 19:46:19 <shripadk> thanks then that settles my worries… its more a cosmetic bug than anything else!
462 2013-10-23 19:59:02 <petertodd> gmaxwell: new, decentralized, alternative to blockchain over satellite that you may be able to help us implement: http://www.nasa.gov/press/2013/october/nasa-laser-communication-system-sets-record-with-data-transmissions-to-and-from/#.UmgqcdU5Bfx
463 2013-10-23 20:00:21 <petertodd> ACTION wonders how long until the FCC starts regulating allocations for laser moon bounce target patch real-estate.
464 2013-10-23 20:04:44 <jgarzik> petertodd, heh
465 2013-10-23 20:08:07 <skinnkavaj> gmaxwell
466 2013-10-23 20:08:11 <skinnkavaj> what has been changed regardign BIP?
467 2013-10-23 20:09:46 <jgarzik> petertodd, sadly, the fancy new lasers could boost the nanosat cost far above $60,000
468 2013-10-23 20:11:01 <petertodd> jgarzik: how so?
469 2013-10-23 20:11:15 <jgarzik> petertodd, because fancy == expensive
470 2013-10-23 20:11:43 <petertodd> jgarzik: oh no, see in this system, you don't need a nanosat at all!
471 2013-10-23 20:12:10 <petertodd> jgarzik: just shoot a laser at the moon, and anyone with a telescope and light->data demodulator gets to turn it back into the blockchain
472 2013-10-23 20:12:28 <Thepok> wow thats cool
473 2013-10-23 20:12:35 <jgarzik> petertodd, I spec'd out a nanosat + launch costs, presuming a typical high density PODS rideshare launch.  The transceiver does something like 16 KB/sec, rather low tech.
474 2013-10-23 20:12:45 <jgarzik> just broadcasting the latest block, over and over
475 2013-10-23 20:12:55 <petertodd> jgarzik: ha, nice
476 2013-10-23 20:12:57 <Thepok> not only lastblocks
477 2013-10-23 20:13:09 <Thepok> should alternate between last block and old blocks
478 2013-10-23 20:13:21 <petertodd> jgarzik: see sounds like this stuff is actually high bandwidth, so doing whole blocks would be trivial, even fast enough for mining against it
479 2013-10-23 20:13:22 <jgarzik> sure, or latest transactions, or...
480 2013-10-23 20:13:26 <Thepok> or checkblocks
481 2013-10-23 20:13:38 <petertodd> jgarzik: which also means you could have multiple senders...
482 2013-10-23 20:13:39 <Thepok> at least last checkpoint
483 2013-10-23 20:15:33 <helo> moon not geosync :/
484 2013-10-23 20:15:47 <jgarzik> petertodd, ideally you have more than one nanosat, with all the bitcoin zillionaires out there ;p
485 2013-10-23 20:15:55 <jgarzik> multiple... everything
486 2013-10-23 20:16:33 <jgarzik> stick some mining chips in the nanosat to generate heat and revenue both!     (j/k)
487 2013-10-23 20:17:01 <Thepok> most stupid miner ever;D
488 2013-10-23 20:17:49 <petertodd> jgarzik: access to launch vehicles is probably less decentralized than access to lasers and telescopes :)
489 2013-10-23 20:21:27 <Thepok> some heliumballons may be cheaper
490 2013-10-23 20:21:37 <Thepok> and you could repair tham
491 2013-10-23 20:21:47 <Thepok> if the tech somehow fails
492 2013-10-23 20:22:06 <Thepok> like the google baloon internettech
493 2013-10-23 20:23:46 <jgarzik> balloons are great, going over 60 miles IIRC
494 2013-10-23 20:23:57 <jgarzik> unfortunately that is cheap balloon X many launches
495 2013-10-23 20:24:48 <jgarzik> every now and then an amateur will send a smartphone 60+ miles up, with a balloon
496 2013-10-23 20:43:05 <goodbtc> Q: how can I remove a private key from my wallet? (it is compromised)
497 2013-10-23 20:44:27 <sipa> why do you need to remove it?
498 2013-10-23 20:44:52 <goodbtc> i accidentally used it to receive coins
499 2013-10-23 20:44:52 <sipa> (there is no automatic way to remove a key... too risky for losing coins)
500 2013-10-23 20:45:16 <goodbtc> and those vanished as soon as it were received
501 2013-10-23 20:45:36 <goodbtc> I wish to save a copy of my wallet 'clean'
502 2013-10-23 20:45:50 <goodbtc> (I could export the rest of the keys and build a new wallet)
503 2013-10-23 20:46:27 <sipa> in git head, there is a dumpwallet and importwallet command
504 2013-10-23 20:46:36 <sipa> which export/import to a human readable format
505 2013-10-23 20:48:06 <goodbtc> i guess I will do it manually key by key (I have only 6 addresses to save)
506 2013-10-23 20:49:14 <sipa> did you include all change addresses?
507 2013-10-23 20:49:24 <goodbtc> nope :(
508 2013-10-23 20:49:30 <goodbtc> damn, you're right
509 2013-10-23 20:50:33 <goodbtc> I could move all coins to a new address thou :)
510 2013-10-23 21:17:13 <swulf--> why would bitcoind stall on blockchain downloading?  been stalled at 265537 for a while
511 2013-10-23 21:18:26 <sipa> define 'a while' ?
512 2013-10-23 21:18:31 <sipa> multiple minutes is very common
513 2013-10-23 21:18:45 <sipa> the download mechanism is quite stupid and often gets confused
514 2013-10-23 21:18:49 <swulf--> hmm
515 2013-10-23 21:18:56 <swulf--> ~20 minutes I guess
516 2013-10-23 21:19:01 <sipa> ;;tslb
517 2013-10-23 21:19:02 <swulf--> oh weird
518 2013-10-23 21:19:04 <swulf--> there it goes
519 2013-10-23 21:19:05 <gribble> Time since last block: 13 minutes and 39 seconds
520 2013-10-23 21:19:14 <sipa> usuaully a new block on the network gets it going again
521 2013-10-23 21:19:18 <swulf--> ahh
522 2013-10-23 21:19:20 <swulf--> ok
523 2013-10-23 21:19:31 <swulf--> guessing a new block just came out then
524 2013-10-23 21:19:32 <sipa> (i'm working on rewriting that code, but it requires significant changes)
525 2013-10-23 21:19:33 <swulf--> ;;tslb
526 2013-10-23 21:19:36 <gribble> Time since last block: 58 seconds ago
527 2013-10-23 21:19:39 <swulf--> yup
528 2013-10-23 21:21:09 <swulf--> InvalidChainFound: Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.
529 2013-10-23 21:22:02 <sipa> crap
530 2013-10-23 21:22:07 <sipa> your database is corrupted...
531 2013-10-23 21:22:38 <swulf--> this happens quite often for me..
532 2013-10-23 21:22:51 <sipa> :(
533 2013-10-23 21:25:49 <swulf--> Maybe it doesn't happen as often to other people, but if this is a really serious issue that corrupts a 10GB database, why is there no move to get away from LevelDB?
534 2013-10-23 21:28:06 <sipa> the database is just 250 MB
535 2013-10-23 21:28:16 <swulf--> which directory is it in?
536 2013-10-23 21:28:19 <sipa> chainstate
537 2013-10-23 21:28:37 <sipa> there is no reason to move away from it, as there it is unclear what the cause is
538 2013-10-23 21:28:46 <sipa> with BDB with certainly had similar complaints
539 2013-10-23 21:29:04 <swulf--> if i have a known working copy of chainstate, i can replace it and finish a blockchain sync instead of a full -reindex ?
540 2013-10-23 21:29:09 <sipa> yes
541 2013-10-23 21:29:15 <sipa> you can just copy the chainstate even
542 2013-10-23 21:29:31 <swulf--> cool, because the blocks dir is huge and the backups too large
543 2013-10-23 21:29:32 <sipa> (not while the program is running)
544 2013-10-23 21:29:46 <sipa> the only requirement is that the chainstate is not newer than the blocks dir
545 2013-10-23 21:29:57 <swulf--> which should be the case
546 2013-10-23 21:30:04 <sipa> (it cannot refer to a block that is not known)
547 2013-10-23 21:30:12 <swulf--> makes sense
548 2013-10-23 21:30:38 <sipa> it will rebuild the chainstate up to the point where the blocks dir is, at startup then
549 2013-10-23 21:30:46 <sipa> which may mean that startup is really slow
550 2013-10-23 21:30:55 <sipa> even hours if you'd do it from scratch
551 2013-10-23 21:31:14 <sipa> s/rebuild/complete/
552 2013-10-23 21:31:24 <swulf--> i'm only off by a few hundred blocks so it wouldn't be bad
553 2013-10-23 21:32:01 <sipa> right
554 2013-10-23 22:01:45 <jegz> what's the maximum length of 'account'?
555 2013-10-23 22:04:07 <Anduck> hmm..
556 2013-10-23 22:04:24 <Anduck> is there a way to make sendmany send to some "change address"?
557 2013-10-23 22:05:14 <Anduck> if i got X amount of coins in the wallet and i want them all to be at same address.. if i sendmany from that X amount, is it ok if i just make 1 more sendmany output with (X - sent coins) so there's 0 change?
558 2013-10-23 22:05:44 <sipa> yes, though accounting for fee may be hard
559 2013-10-23 22:05:59 <sipa> but why?
560 2013-10-23 22:06:20 <sipa> if you want all of the wa
561 2013-10-23 22:06:43 <sipa> llet's value in a single coin, just send everything to one address
562 2013-10-23 22:08:35 <Anduck> i mean..
563 2013-10-23 22:08:56 <sipa> ah, you mean while doing a transaction?
564 2013-10-23 22:09:03 <Anduck> i got X amount of coins in 1 address and i just want to send some of the balance out (i want the balance to be verifiable via blockchain)
565 2013-10-23 22:09:18 <Anduck> yea
566 2013-10-23 22:09:35 <sipa> why would change not be verifiable?
567 2013-10-23 22:12:18 <Anduck> if the change coins are sent to some random address
568 2013-10-23 22:13:08 <sipa> well you know which address, if needed
569 2013-10-23 22:14:40 <Anduck> yeah..
570 2013-10-23 22:15:11 <Anduck> but is there a way to send change back to origin address?
571 2013-10-23 22:15:14 <Anduck> with sendmany
572 2013-10-23 22:15:45 <jegz> is there like a single magical wiki page somewhere that gives me all the hard limits on all the data stored for a transaction in bitcoind?
573 2013-10-23 22:19:52 <sipa> Anduck: using the raw transaction api you can do what you want
574 2013-10-23 22:20:01 <Anduck> hmm ok
575 2013-10-23 22:20:07 <sipa> Anduck: not using regu
576 2013-10-23 22:20:18 <BlueMatt> sipa: do you ever sleep?
577 2013-10-23 22:20:29 <sipa> lar transaction creation, as it follows best practice to never reuse an address
578 2013-10-23 22:20:36 <sipa> BlueMatt: certainly!
579 2013-10-23 22:20:46 <BlueMatt> somehow I dont believe that
580 2013-10-23 22:20:51 <jegz> are my questions so tough?? :p
581 2013-10-23 22:20:54 <sipa> between 3am and 9am or so
582 2013-10-23 22:21:05 <BlueMatt> either that or the sipa on irc is a bot designed to look like sipa
583 2013-10-23 22:21:15 <sipa> jegz: what limits are you talking about?
584 2013-10-23 22:21:24 <jegz> sipa: like the length of strings and such
585 2013-10-23 22:21:30 <sipa> jegz: accounts are just local database things, they can be huge
586 2013-10-23 22:21:36 <sipa> i suppose megabytes
587 2013-10-23 22:21:42 <jegz> for a single account name?
588 2013-10-23 22:21:46 <sipa> yes
589 2013-10-23 22:21:50 <jegz> oh
590 2013-10-23 22:22:03 <jegz> ok there is some data i get back from listtransactions, 'category'
591 2013-10-23 22:22:11 <jegz> what are all the possible values?
592 2013-10-23 22:22:21 <sipa> send/receive/generate ?
593 2013-10-23 22:22:25 <jegz> maybe there's a file in the source you could refer me to
594 2013-10-23 22:22:29 <jegz> i see
595 2013-10-23 22:27:15 <sipa> jegz: wallet.cpp
596 2013-10-23 22:27:33 <sipa> there may be a separate category for immature coins
597 2013-10-23 22:28:17 <jegz> wth is an "immature" coin?
598 2013-10-23 22:37:51 <mbelshe_> hello bitcoindev.  is there a way i can verify that a transaction is valid (signatures, etc all done properly) without actually sending it?
599 2013-10-23 22:38:26 <sipa> i believe signrawtransaction tells you whether it is complete
600 2013-10-23 22:38:47 <sipa> i'm not entirely sure what that entails, but perhaps it is a full check
601 2013-10-23 22:39:45 <mbelshe_> ok.  it does do that.  let me futz with that for a bit.  thanks!
602 2013-10-23 22:41:38 <sipa> it does not fully check, but probably close enough
603 2013-10-23 22:41:57 <sipa> i suppose it may be fooled by nLockTime or similar things
604 2013-10-23 22:42:22 <mbelshe_> ok
605 2013-10-23 22:42:24 <sipa> it does check whether all inputs are available, and signatures are correct
606 2013-10-23 22:42:51 <sipa> unsure whether it checks outputs or overspending
607 2013-10-23 22:43:17 <swulf--> InvalidChainFound: Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.
608 2013-10-23 22:43:19 <swulf--> happens _AGAIN_
609 2013-10-23 22:43:37 <sipa> what system are you on?
610 2013-10-23 22:44:33 <swulf--> linux 3.2.0, debian
611 2013-10-23 22:46:32 <sipa> what type of disk/fs?
612 2013-10-23 22:47:15 <sipa> and are you sure you don't have some flaky memory or cpu for example?
613 2013-10-23 22:47:31 <swulf--> well
614 2013-10-23 22:47:43 <swulf--> it's on a loop-aes fs
615 2013-10-23 22:47:51 <swulf--> ext4 + aes128
616 2013-10-23 22:48:08 <swulf--> and i recently rebuilt and got a new machine, new everything, this same issue was happening on it too
617 2013-10-23 22:48:14 <sipa> hmm, i wonder whether that influences it
618 2013-10-23 22:48:29 <sipa> the encryption
619 2013-10-23 22:48:52 <swulf--> bitcoind was running fine for about a month
620 2013-10-23 22:49:05 <swulf--> today i restarted it, and ever since restarting it's been crapping out
621 2013-10-23 22:49:41 <swulf--> seems to be related to the higher speed of blocks incoming?
622 2013-10-23 22:50:00 <swulf--> if it ends up syncing completely then it's usually good for a long time
623 2013-10-23 22:50:02 <sipa> have you tried runming with -par=1 ?
624 2013-10-23 22:50:10 <swulf--> what's -par?
625 2013-10-23 22:50:23 <swulf--> ACTION checks
626 2013-10-23 22:50:35 <sipa> parallellism
627 2013-10-23 22:50:41 <sipa> for some, it seems to help
628 2013-10-23 22:50:47 <swulf--> hmm
629 2013-10-23 22:51:20 <swulf--> welp, let's try it
630 2013-10-23 22:51:46 <swulf--> also kinda wished loading a wallet with 75000 keys didn't take almost an hour :(
631 2013-10-23 22:52:56 <sipa> swulf--: an hour? :o
632 2013-10-23 22:53:05 <swulf--> eh...45 minutes:)
633 2013-10-23 22:53:33 <sipa> 20ms per key...?
634 2013-10-23 22:54:10 <sipa> anyway, an improvemeny for wallet load time was recently merged
635 2013-10-23 22:54:26 <sipa> though 20ms per key sounds wextremely slow
636 2013-10-23 22:54:47 <gribble> 0.036
637 2013-10-23 22:54:47 <sipa> ;;calc 45*60/75000
638 2013-10-23 22:54:52 <sipa> 36 even
639 2013-10-23 22:55:12 <sipa> phantomcircuit: any idea what could cause such loading times?
640 2013-10-23 22:55:49 <swulf--> i modified my bitcoin build slightly so that it would print out the key index as it reads from the wallet
641 2013-10-23 22:56:03 <swulf--> so that i at least know there's progress
642 2013-10-23 22:56:41 <phantomcircuit> sipa, that's about how long it takes to load a wallet that size without the hashing speed up if you're memory constrainted
643 2013-10-23 22:56:46 <phantomcircuit> constrained
644 2013-10-23 22:57:03 <sipa> wtf is it doing for 36ms?
645 2013-10-23 22:57:04 <phantomcircuit> swulf--, what cpu?
646 2013-10-23 22:57:18 <phantomcircuit> sipa, accessing the disk in the most inefficient way possible
647 2013-10-23 22:57:26 <edcba> :)
648 2013-10-23 22:57:27 <swulf--> i think we've had this discussion before - it's an intel atom
649 2013-10-23 22:57:32 <phantomcircuit> oh
650 2013-10-23 22:57:48 <sipa> phantomcircuit: how does the hash trick help to avoid inefficient disk access?
651 2013-10-23 22:58:02 <phantomcircuit> sipa, is it possible the check_key call would take ~16ms on an atom?
652 2013-10-23 22:58:15 <phantomcircuit> sipa, it doesn't really
653 2013-10-23 22:58:26 <sipa> that seems extremely slow, but i haven't benchmarked it
654 2013-10-23 22:58:38 <edcba> why loading a key requires cpu ?
655 2013-10-23 22:58:44 <sipa> i expect at least an order of magnitude more
656 2013-10-23 22:58:45 <phantomcircuit> it takes about 1ms on an i3
657 2013-10-23 22:58:51 <edcba> just to verify it's valid ?
658 2013-10-23 22:58:54 <swulf--> you couldn't make one check_key call per frame and still run a game/movie/video at 60fps
659 2013-10-23 22:58:55 <phantomcircuit> so i could see it taking much longer on an atom
660 2013-10-23 22:59:28 <phantomcircuit> edcba, the public key is derived from the private key
661 2013-10-23 22:59:38 <phantomcircuit> which acts as a checksum