1 2014-10-17 00:00:21 <jtimon> so do you mind if I separate core/transaction already? it should help with the script stuff
  2 2014-10-17 00:00:37 <jtimon> also seems independent from your other movements
  3 2014-10-17 00:00:51 <sipa> coryfields_: i don't understand why that would be needed
  4 2014-10-17 00:01:18 <coryfields_> sipa: it might've been undo and not compressor, sec
  5 2014-10-17 00:01:42 <sipa> undo needs txcompressor
  6 2014-10-17 00:02:14 <sipa> but undo in main, and txcompressor in coins should work - unless i'm missing something
  7 2014-10-17 00:03:07 <jtimon> also that commit (probably they should be 2 separated commits) seems independently useful and non controversial, any reason not to create a PR with it already?
  8 2014-10-17 00:03:39 <coryfields_> sipa: sorry, i really can't remember the problem now. i've moved way too much stuff around this week
  9 2014-10-17 00:03:43 <sipa> ok
 10 2014-10-17 00:03:52 <coryfields_> sipa: as usual, 95% change i'm just flat-out misremembering
 11 2014-10-17 00:04:10 <sipa> no worries; always better to have something that works
 12 2014-10-17 00:04:26 <sipa> i'm mostly just questioning my own understanding
 13 2014-10-17 00:04:55 <jtimon> sipa any reason to make main fatter instead of having separated files?
 14 2014-10-17 00:05:54 <coryfields_> jtimon: no reason not to PR it, just trying to keep the code movement to a minimum until there's something to show for it
 15 2014-10-17 00:05:54 <sipa> i'm not actually a fan of the "one file for every class" mentality
 16 2014-10-17 00:06:08 <coryfields_> but if it would help you as well, you're welcome to go for it
 17 2014-10-17 00:06:28 <sipa> i'm not opposed to separate files, btw, just saying that it is wrong that something is in core now, and would fit in main
 18 2014-10-17 00:06:50 <sipa> independently moving it to another file (depended on by main, and not by core) accomplishes the same goal
 19 2014-10-17 00:07:06 <jtimon> I see, thanks, I'll move inpoint to txmempool and separate core/transaction for now
 20 2014-10-17 00:08:08 <jtimon> I mean, my slow and low memory laptop some times has problems compiling main already
 21 2014-10-17 00:08:47 <coryfields_> sipa: btw, this key movement is working out really nicely i think. From the looks, i'd much rather do this than the other movements i proposed
 22 2014-10-17 00:09:22 <sipa> jtimon: ha, yes, that's a good reason to split things up, but the actual amount of .cpp code moved is tiny compared to what is already in main i think
 23 2014-10-17 00:09:47 <sipa> and header movement doesn't help here, as you'd still need to (directly or indirectly) include the headers in main
 24 2014-10-17 00:09:53 <sipa> coryfields_: looking forward
 25 2014-10-17 00:10:06 <jtimon> yeah, was just concerned about making main even bigger
 26 2014-10-17 00:10:27 <sipa> yeah, fair enough
 27 2014-10-17 00:11:16 <coryfields_> jtimon: as for the core classes (i believe you were asking earlier), i really don't mind how they're arranged/moved at all, as long as new dependencies aren't added
 28 2014-10-17 00:11:24 <coryfields_> which i'm sure you're not doing anyway
 29 2014-10-17 00:12:08 <jtimon> #5096
 30 2014-10-17 00:12:30 <jtimon> no, I won't add more deps, just a couple of moveonly PRs
 31 2014-10-17 00:12:58 <jtimon> that #5096 is specially trivial
 32 2014-10-17 00:13:08 <coryfields_> ok, don't worry about me then. only one that would collide is the commit above, which is no problem to work around
 33 2014-10-17 00:35:40 <coryfields_> sipa: no clue what the problem was there, works fine now (the circular dep). I must've had some other local conflicting changes.
 34 2014-10-17 00:36:48 <sipa> ok, cool
 35 2014-10-17 01:50:42 <dcousens> Anyone know who runs webbtc.com?
 36 2014-10-17 01:51:40 <justanotheruser> dcousens: whois says Marius Hanne
 37 2014-10-17 01:52:28 <justanotheruser> 
ACTION pings mhanne 

 38 2014-10-17 01:52:34 <dcousens> cheers justanotheruser
 39 2014-10-17 03:39:37 <Overlord> Cheap Cloud Node Contracts: https://zeushash.com/refer/2z6737
 40 2014-10-17 03:39:59 <phantomcircuit> gwillen, ^
 41 2014-10-17 04:04:15 <nullbyte> .wu
 42 2014-10-17 04:04:30 <nullbyte> disregard
 43 2014-10-17 04:05:00 <gwillen> phantomcircuit: thanks
 44 2014-10-17 05:12:59 <SomeoneWeird> phantomcircuit: you don't have ops?
 45 2014-10-17 05:13:01 <SomeoneWeird> 
ACTION shrugs

 46 2014-10-17 06:53:46 <slorunner> hello, i don't find the github link for bitcoin payment (PHP) anyone here to help?
 47 2014-10-17 06:57:16 <wumpus> https://github.com/gavinandresen/paymentrequest
 48 2014-10-17 07:12:57 <todam00n> is there a pre compiled bitcoin-cli for os x somewhere?
 49 2014-10-17 07:13:39 <wumpus> not AFAIK
 50 2014-10-17 07:23:54 <todam00n> ok
 51 2014-10-17 07:24:07 <Luke-Jr> todam00n: depending on what you need, note Bitcoin Core GUI does have a Debug console that works the same more or less
 52 2014-10-17 07:24:13 <todam00n> also, is there any bitcoin client that can remotely connect to a wallet via RPC?
 53 2014-10-17 07:24:20 <todam00n> I mostly just want to test my RPC connection
 54 2014-10-17 07:25:13 <wumpus> easiest would be to run a basic bitcoin-bitcoinrpc test hten
 55 2014-10-17 07:26:16 <Luke-Jr> todam00n: unless you have a use for it, it's probably better if you don't enable the RPC connection..
 56 2014-10-17 07:28:24 <wumpus> ie, http://www.hastebin.com/ukonoqided.py  then call it with python simple_python_bitcoinrpc.py http://bitcoinrpc:password@127.0.0.1:8332/
 57 2014-10-17 07:33:49 <todam00n> I have to... bitcoind server is on another machine
 58 2014-10-17 07:41:45 <Luke-Jr> todam00n: bitcoind very intentionally won't accept connections from other machines by default, and, IMO, can never safely do so
 59 2014-10-17 07:45:06 <todam00n> that was not my question
 60 2014-10-17 08:04:10 <phantomcircuit> SomeoneWeird, this is like the only channel i dont
 61 2014-10-17 08:04:13 <phantomcircuit> shrug
 62 2014-10-17 08:18:25 <slorunner> hmm, php script doesn't work, and i can't find the problem, modules work right, but index doesnt :/ using: https://github.com/blockchain/receive_payment_php_demo
 63 2014-10-17 08:19:18 <phantomcircuit> slorunner, DO NOT USE BC.I
 64 2014-10-17 08:19:28 <phantomcircuit> YOU *WILL* LOSE BITCOINS
 65 2014-10-17 08:19:35 <phantomcircuit> also you're off topic
 66 2014-10-17 08:20:00 <slorunner> sry then :/ gonna find another
 67 2014-10-17 08:20:13 <phantomcircuit> try ##php
 68 2014-10-17 08:20:17 <phantomcircuit> gl with that though
 69 2014-10-17 08:20:52 <slorunner> is this one ok? https://github.com/gavinandresen/paymentrequest
 70 2014-10-17 08:21:38 <phantomcircuit> slorunner, sure
 71 2014-10-17 08:23:15 <slorunner> gonna set it up later then :)
 72 2014-10-17 08:47:11 <wumpus> so, headers-first merge today? people have been able to test it for a few days, and I've seen no critical new issues that have surfaced
 73 2014-10-17 08:47:38 <Luke-Jr> ☺
 74 2014-10-17 08:47:47 <sipa> but but but... nobody has acked it
 75 2014-10-17 08:48:06 <wumpus> good point
 76 2014-10-17 08:48:20 <Luke-Jr> we'll probably accidentally a hardfork, but not sure there's anything more we can do to reduce the risk.
 77 2014-10-17 08:48:26 <wumpus> my browser crashes when I open the issue, so adding my ack will take a while :-)
 78 2014-10-17 08:48:59 <wumpus> Luke-Jr: huh?
 79 2014-10-17 08:49:15 <wumpus> why do you think this would cause a hardfork?
 80 2014-10-17 08:49:18 <justanotheruser> wumpus: you should add that to your browsers issue list
 81 2014-10-17 08:49:30 <Luke-Jr> wumpus: just the sheer complexity. I'm not suggesting delaying a merge.
 82 2014-10-17 08:49:32 <wumpus> it changes download strategy
 83 2014-10-17 08:49:51 <sipa> some validation rules are shuffled too
 84 2014-10-17 08:49:57 <sipa> because they happen in a different order now
 85 2014-10-17 08:50:21 <sipa> though not the tricky ones (as in: script validation, utxo update logic, block connection are all untouched)
 86 2014-10-17 08:50:36 <wumpus> right
 87 2014-10-17 08:50:42 <Luke-Jr> I'd just say we should avoid releasing right before any kind of big event we're all going to - so if something happens, we're able to react quickly
 88 2014-10-17 08:51:07 <sipa> i think it's likelier that there is some bug that allows a peer to make get stuck than anything else
 89 2014-10-17 08:51:20 <sipa> (but then again... that happened spontaneously before anyway)
 90 2014-10-17 08:51:25 <Luke-Jr> sipa: stuck on one tree could cause a reorg off it
 91 2014-10-17 08:51:47 <wumpus> it's better than the current code
 92 2014-10-17 08:51:51 <Luke-Jr> wumpus: definitely.
 93 2014-10-17 08:52:36 <wumpus> anyhow - suggestions to reduce risk are welcome, but I don't think waiting with the merge will help there.. if anything, merging it into master makes sure it gets more testing before the actual release
 94 2014-10-17 08:52:54 <Luke-Jr> wumpus: like I said, probably not much more we can do - might as well merge it
 95 2014-10-17 08:54:29 <Luke-Jr> I mean, unless everyone wants to wait around for a year until every miner is running both 0.8 and 0.9 concurrently to avoid issues - but that's just crazy :p
 96 2014-10-17 08:55:19 <Luke-Jr> sometimes, risks are better handled reactively (if at all) than proactively
 97 2014-10-17 08:55:33 <sipa> wumpus: i've heard one complain from someone, but it turned out he was running the bitcoind in his path rather than the headersfirst one
 98 2014-10-17 08:55:40 <sipa> wumpus: oh, and from rebroad
 99 2014-10-17 08:57:59 <wumpus> rebroad is on a very strange network setup on a very faulty computer, I think he lives in a fuzzer :)
100 2014-10-17 08:58:04 <gmaxwell> There is risk, but the code already in master is basically known broken. We're not planning on beginning a RC cycle right away... this needs baking time, which means getting every developer onto it.
101 2014-10-17 08:58:31 <wumpus> anyhow - most problems can be solved after merge
102 2014-10-17 09:00:29 <wumpus> as far as I know rebroad is building on top of headers-first, so anything he's doing can be submitted as a pull afterwards
103 2014-10-17 09:00:42 <wumpus> and tested/reviewed separately
104 2014-10-17 09:11:31 <gmaxwell> I haven't tracked rebroad's latest work ... some of the stuff he was doing was planned already and was just left out because it was too much at once (e.g. dynamic windows),  some of it seems clearly wrong (but no doubt whatever issue is motivating it for him is probably real), and some is probably fine.
105 2014-10-17 09:34:35 <spinza> Sipa: there was just that slight "issue where it was disc
106 2014-10-17 09:34:55 <sipa> oh, right, the disconnection of -addnode's
107 2014-10-17 09:35:01 <spinza> *disconnecting addnodes from the conf
108 2014-10-17 09:35:08 <sipa> meh, that can be fixed later; but be sure to file an issue for that after mergre
109 2014-10-17 09:35:13 <spinza> Sorry mobile typing
110 2014-10-17 09:36:00 <spinza> Yeah think it's meh also but might surprise some
111 2014-10-17 09:41:15 <spinza> It's also only an issue until sync is completed
112 2014-10-17 10:20:03 <todam00n> what if i downloaded the blockchain with an old version of bitcoin
113 2014-10-17 10:20:25 <wumpus> no problem, the blockchain is still the same
114 2014-10-17 10:20:28 <todam00n> is there any way to restructure it to be compatible?
115 2014-10-17 10:20:30 <todam00n> ok
116 2014-10-17 10:20:38 <todam00n> i thought newer versions were storing the blockchain differently
117 2014-10-17 10:20:38 <wumpus> nooo no such thing needed
118 2014-10-17 10:20:53 <wumpus> the problem is the other way around :)
119 2014-10-17 10:21:03 <todam00n> ah ok :)
120 2014-10-17 10:21:14 <wumpus> if you sync using headers-first, then the files will not be in-order, so older versions won't understand
121 2014-10-17 10:23:21 <wumpus> that's not because shuffling the blocks is better, but because they can arrive in different orderings
122 2014-10-17 10:31:08 <wumpus> anyhow
123 2014-10-17 10:31:11 <wumpus> 
ACTION 84d13ee - (HEAD, master) Merge pull request #4468 

124 2014-10-17 10:36:19 <wumpus> woohoo! headers first is merged, thanks to sipa and everyone else who worked on it or helped testing and reviewing it
125 2014-10-17 10:42:15 <fanquake> woo
126 2014-10-17 10:42:27 <fanquake> I think I’ve found a case where the blockfiles aren’t compatible between HF and not HF.
127 2014-10-17 10:43:25 <wumpus> different from the (known) case I mention above?
128 2014-10-17 10:44:58 <fanquake> heh, it could be that exact case. Master and 0.9.3 wouldn’t read the blockfiles after I’d been running headers first.
129 2014-10-17 10:46:13 <wumpus> ok, yes,that's expected
130 2014-10-17 10:47:20 <fanquake> ok, no worries.
131 2014-10-17 10:47:23 <wumpus> also warned about in sipa's post: http://sourceforge.net/p/bitcoin/mailman/message/32921390/
132 2014-10-17 10:47:48 <fanquake> I’m probably not quite keeping up on my reading.
133 2014-10-17 10:48:21 <wumpus> I'm not sure we could make this any clearer.. maybe add a warning to README.md about *warning, running master will make your block files incompatible with earlier versions*
134 2014-10-17 10:50:52 <sipa> wumpus: w00000t!
135 2014-10-17 11:00:35 <fanquake> wumpus obviously something like that’ll be in bold at the top of the 0.10.0 release
136 2014-10-17 11:00:57 <fanquake> otherwise it’ll be the end of the world for anyone who tries to downgrade
137 2014-10-17 11:01:57 <wumpus> well not the end of the world, they can always re-bootstrap, it's not like it changes your wallet.dat into an image of nyan cat
138 2014-10-17 11:05:27 <wumpus> (good point to not break wallet backward compatibilty as well, though)
139 2014-10-17 11:08:14 <fanquake> wumpus yep. slight over exaggeration. Maybe keep the nyan cat for april fools next year.
140 2014-10-17 11:13:45 <wumpus> something like https://github.com/laanwj/bitcoin/commit/62e26d3f62a953cfb619bc6e04c7003c6b69360c  ?
141 2014-10-17 11:15:52 <fanquake> Yep
142 2014-10-17 11:18:08 <paveljanik> wumpus: s/compatiblity/compatibility/
143 2014-10-17 11:20:56 <Rozal> Can we code something in the Bitcoin to make the prices go higher
144 2014-10-17 11:26:11 <sipa> Rozal: no
145 2014-10-17 11:26:16 <sipa> Rozal: make it more useful
146 2014-10-17 11:27:13 <Rozal> excuse you, it's rude to speak when not spoken to.
147 2014-10-17 11:28:03 <Rozal> :)
148 2014-10-17 11:33:19 <wumpus> there is no correlation between usefulness and the price IMO, anyhow this belongs in #bitcoin-pricetalk
149 2014-10-17 11:47:40 <melvster> hi all there's some rant trending on reddit about the bitcoin-dev mailing list ... the guy's name is melcarvalho which is very similar to the name I post under ( Melvin Carvalho ) ... just wanted to point out that the reddit poster isnt me ... I have great respect for bitcoin devs and process, you guys have helped out out many times ...
150 2014-10-17 11:48:53 <wumpus> I've seen the rant; I wonder how many of the people ranting have actually followed the mailing list, they make it seem like everyone is swearing and shouting at each other
151 2014-10-17 11:50:50 <melvster> yeah would be more productive to actually add patches, test, help ... simple truth is that 80%-90% of people on almost all mail lists lurk
152 2014-10-17 11:57:12 <wumpus> it's interesting in a way because most of the shouting and childish mobbing towards bitcoin development comes from reddit in the first place, which acts as a giant hate amplifier... so it's mostly self-criticism... anyhow, I've said my thing there and if there are serious issues with people misbehaving on the mailing list, let me know and we can try to handle it professionally
153 2014-10-17 12:03:10 <gmaxwell> melvster: thanks for that bit of clarification there to clear your name. :)
154 2014-10-17 12:24:27 <petertodd> wumpus, melvster: I think you guys are getting trolled: https://www.reddit.com/r/Bitcoin/comments/2jhzxq/linus_regrets_how_insults_damaged_the_linux/clbydo7 <- that last comment is mine, and I did not edit it (as can be verified by the github timestamp)
155 2014-10-17 12:26:01 <petertodd> anyway, I gotta go and catch a plane flight, later
156 2014-10-17 12:27:20 <melvster> petertodd: cheers, have a good trip
157 2014-10-17 12:27:58 <petertodd> melvster: thanks!
158 2014-10-17 13:31:48 <jgarzik> hum
159 2014-10-17 13:31:56 <jgarzik> I'm definitely seeing node drops here too, post-HF-merge
160 2014-10-17 13:43:28 <wumpus> maybe this https://github.com/bitcoin/bitcoin/issues/5097 ?
161 2014-10-17 13:46:47 <kruug> ugh...the release-process.md file on github is out of date :/
162 2014-10-17 13:47:07 <wumpus> kruug: how?
163 2014-10-17 13:47:13 <kruug> Has anyone else built with it?  The intermediate input versions are off so the sha256 can't be checked.
164 2014-10-17 13:47:38 <wumpus> are you using the release-process.md of the tag you're building?
165 2014-10-17 13:47:49 <kruug> oh, duh...I didn't check that
166 2014-10-17 13:48:10 <kruug> there we go, now the versions look right :/
167 2014-10-17 13:48:20 <wumpus> in master it's could be that the sha256s are not right, but big changes to gitian are coming anyhow
168 2014-10-17 13:48:48 <wumpus> ok
169 2014-10-17 13:49:13 <kruug> yeah, I was in master and not 0.9.3
170 2014-10-17 13:49:44 <kruug> wumpus: just fyi, 0.9.3 doesn't have sha256 for the osx files
171 2014-10-17 13:50:03 <wumpus> that's known, they're not really deterministic IIRC, but the end product is
172 2014-10-17 13:50:23 <kruug> gotcha
173 2014-10-17 13:52:26 <wumpus> reminds me that I need to change the gitian.sigs README.md to not refer to master's release process
174 2014-10-17 14:52:01 <kruug> is there a place to find sha256/md5's of the outputs of the gitian process?
175 2014-10-17 14:52:46 <kinlo> https://github.com/bitcoin/gitian.sigs ?
176 2014-10-17 14:53:05 <kinlo> or do you mean on your local gitian install?
177 2014-10-17 14:53:28 <kruug> kinlo: I just went through the build process and I want to compare my output to the outputs of others.
178 2014-10-17 14:53:43 <kinlo> kruug: then look at github
179 2014-10-17 14:53:49 <wumpus> those are in the gitian.sigs repo that kinlo mentions
180 2014-10-17 14:53:59 <kruug> gotcha.  Thanks
181 2014-10-17 14:56:45 <kruug> Hmmm...not exactly what I was looking for.
182 2014-10-17 14:57:32 <kruug> I have the bitcoin .exe's, .dmg, and .tar.gz for distribution, and I was looking to verify those.
183 2014-10-17 14:58:00 <kinlo> those are in the repo, no?
184 2014-10-17 14:58:27 <wumpus> the hashes in the assert files are sha256 hashes https://github.com/bitcoin/gitian.sigs/blob/master/0.9.3/laanwj/bitcoin-build.assert
185 2014-10-17 14:58:59 <kruug> right, but there is no `bitcoin-0.9.3-win64-setup.exe` hash, for example.
186 2014-10-17 14:59:02 <wumpus> you could also follow the build instructions entirely, it will write an assert file for yourself, then you can use the 'gverify' command to compare
187 2014-10-17 14:59:09 <kinlo> you gotta use the -win directory
188 2014-10-17 14:59:18 <kinlo> as the plain dir has hte linux build
189 2014-10-17 14:59:21 <kinlo> https://github.com/bitcoin/gitian.sigs/blob/master/0.9.3rc2-win/gavinandresen/bitcoin-build.assert
190 2014-10-17 14:59:23 <wumpus> there should be one
191 2014-10-17 14:59:35 <kinlo> that's where you for example find the exe's
192 2014-10-17 15:00:12 <kruug> oh, gotcha.
193 2014-10-17 15:00:13 <kinlo> so https://github.com/bitcoin/gitian.sigs/blob/master/0.9.3-win/gavinandresen/bitcoin-build.assert are gavin's sigs for the latest build
194 2014-10-17 15:00:24 <kinlo> the previous url was for a beta
195 2014-10-17 15:04:23 <kruug> does the sha256 sum include filenames?
196 2014-10-17 15:04:50 <wumpus> no - it is the sha256sum *of the file*
197 2014-10-17 15:04:58 <kruug> The build-process told me to rename the Bitcoin-QT.dmg to bitcoin-0.9.3-osx.dmg, but the gitian.sigs asserts all have the Bitcoin-Qt.dmg as a file name
198 2014-10-17 15:05:24 <wumpus> ok; yes that's how to do the release, doesn't matter for the hash
199 2014-10-17 15:07:11 <kruug> interesting...my Win and OSX builds match, but the Linux doesn't
200 2014-10-17 15:12:27 <btcdrak> nice work on the headers first PR!
201 2014-10-17 16:42:26 <blast> sup gang
202 2014-10-17 16:53:23 <wumpus> kruug: and the intermediates match? are you using LXC or KVM?
203 2014-10-17 18:29:22 <lechuga_> sipa: nice job! (and every1 else who helped)
204 2014-10-17 18:42:15 <coryfields_> sipa: ping
205 2014-10-17 18:42:20 <sipa> coryfields_: pong
206 2014-10-17 18:42:24 <coryfields_> sipa: quick POC of what we discussed yesterday: https://github.com/theuni/bitcoin/commit/6e8d7336ea6505773bcc04a0c47c32f8c3db1f06
207 2014-10-17 18:42:49 <coryfields_> don't bother reviewing, it was done very hastily. just looking to see if you agree with the concept in general
208 2014-10-17 18:44:14 <sipa> coryfields_: agree with concept
209 2014-10-17 18:44:21 <coryfields_> the actual key functionality moves to a new file that knows nothing of CKey/CPubKey/CPrivKey. buffers are passed in/out, allowing the caller to create the mem backings for privkey operations
210 2014-10-17 18:44:36 <sipa> i'd call the file eccrypto, and wrap it in a namespace eccrypto or so :)
211 2014-10-17 18:44:47 <coryfields_> that gets us dangerously close to a key manip lib api
212 2014-10-17 18:45:27 <coryfields_> rather... signing api. the key part is abstract
213 2014-10-17 18:46:21 <sipa> though it would be nice if you could link i nverification functionality, without signing functionality
214 2014-10-17 18:46:50 <sipa> as if we would switch to libsecp256k1 for signing, i guess we prefer not to depend on that for just the script validation library
215 2014-10-17 18:46:53 <coryfields_> sure, they could be split up
216 2014-10-17 18:47:51 <coryfields_> once the functionality is moved out of the Key classes, it becomes really easy to split up however we want
217 2014-10-17 18:49:53 <coryfields_> ok, i'll do a cleaned up version. I can justify spending some time on it since this is (imo) a better alternative to the other code movement necessary for boost removal for libbitcoinconsensus
218 2014-10-17 18:50:35 <coryfields_> ack on the namespace, i was surprised that it worked without clashing
219 2014-10-17 19:19:04 <sipa> +
220 2014-10-17 19:58:44 <coryfields_> sipa: looks like with openssl at least, there's not much hope for getting it to use pre-allocated mem for all priv key operations
221 2014-10-17 19:59:15 <gmaxwell> hm? thought they were all on the stack.
222 2014-10-17 19:59:51 <sipa> in openssl? not at all
223 2014-10-17 20:01:05 <sipa> you can use preallocated memory for BN's, i think, but all operations internally done on them would likely copy them to heap space anyway
224 2014-10-17 20:01:07 <coryfields_> i suppose i'll loosen the initial implementation to: you pass us your allocated privkey, but assume that it will be copied around
225 2014-10-17 20:01:47 <sipa> libsecp256k1 won't copy it
226 2014-10-17 20:02:02 <coryfields_> ok, great
227 2014-10-17 20:02:15 <sipa> wait, it will, but only on the stack
228 2014-10-17 20:02:38 <sipa> which is extremely unlikely to end up in swap as it's constantly changing
229 2014-10-17 20:03:07 <sipa> so yeah - do what you can to secure it, but we can't guarantee it won't be temporarily copied (though if it is, it will be wiped after use)
230 2014-10-17 20:03:11 <coryfields_> well, i don't think it's a huge concern for now, only trying to keep the possibility open for the fugure
231 2014-10-17 20:03:22 <coryfields_> sounds good, will do
232 2014-10-17 20:03:27 <Luke-Jr> in theory, couldn't even registers end up in swap?
233 2014-10-17 20:03:30 <coryfields_> *future
234 2014-10-17 20:03:56 <sipa> coryfields_: if the compiler emits code to swap them to ram, sure
235 2014-10-17 20:04:02 <sipa> eh, lechuga_
236 2014-10-17 20:04:05 <sipa> eh, Luke-Jr
237 2014-10-17 20:05:11 <hearn> sipa: eh? it can get swapped out when the app is idle
238 2014-10-17 20:05:27 <hearn> (the stack)
239 2014-10-17 20:05:48 <hearn> 
ACTION gave up on the idea of keeping priv keys in "safe memory" after reading an article about all the different ways stuff can leak

240 2014-10-17 20:05:54 <sipa> hmm, ok
241 2014-10-17 20:07:08 <hearn> of course now i can't find the article again. gah.
242 2014-10-17 20:07:47 <hearn> ah yes
243 2014-10-17 20:07:47 <hearn> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
244 2014-10-17 20:07:57 <sipa> signing takes in the order of 30us, so there is actually quite some chance of being interrupted during that time
245 2014-10-17 20:08:28 <gmaxwell> hearn: dunno if they fixed it since but the first version of that article was too optimistic. :)
246 2014-10-17 20:08:31 <hearn> tl;dr - even if you try and do the right thing, the compiler will screw you over. it's free to make copies of your data anywhere it likes, at any time, even when working in C
247 2014-10-17 20:08:45 <hearn> and then it's easy to forget things like AES registers too
248 2014-10-17 20:09:04 <earlz> I'm surprised there aren't bitcoin compatible dongles yet... like where you plugin the USB device and some special bitcoin wallet talks to the dongle for all key signing and such
249 2014-10-17 20:09:13 <sipa> earlz: you mean the trezor?
250 2014-10-17 20:09:19 <earlz> not heard of it
251 2014-10-17 20:09:34 <sipa> wow, ok :)
252 2014-10-17 20:09:55 <hearn> there have been several
253 2014-10-17 20:10:00 <hearn> trezor is the best by far, and what i use
254 2014-10-17 20:10:19 <earlz> dat price though
255 2014-10-17 20:10:22 <sipa> i actually have a smartcard sized usb signing device that supports multisig :)
256 2014-10-17 20:10:27 <earlz> I was imaginging somethign that'd fit on an AVR lol
257 2014-10-17 20:10:43 <sipa> the hard part is how do you communicate with the user
258 2014-10-17 20:10:55 <earlz> 
ACTION is one of the stupid people who trust coinbase with everything ;) 

259 2014-10-17 20:11:05 <sipa> as you need to show something so that the user knows they are signing the right thing
260 2014-10-17 20:11:12 <earlz> good point
261 2014-10-17 20:11:16 <hearn> well, that's no more stupid than the other few billion people who use banks. however, it's not what i'd recommend :)
262 2014-10-17 20:11:19 <sipa> as your software could be malicious and ask to sign something other than what it clames
263 2014-10-17 20:11:30 <earlz> at least coinbase's vault thing is insured to some extent
264 2014-10-17 20:11:51 <hearn> yes, but so are banks. so why not use a real one? no offence to coinbase, but a bank they are not
265 2014-10-17 20:12:11 <earlz> I don't hold enough bitcoin to actually worry either though..
266 2014-10-17 20:12:13 <BlueMatt> hearn: banks are insured (in the us) by the group that can print money to cover it, coinbase...not so much
267 2014-10-17 20:12:21 <earlz> Most I've ever held at any time was $600 worth
268 2014-10-17 20:12:32 <hearn> indeed
269 2014-10-17 20:12:41 <hearn> earlz: yeah if you only ever had $600 max then a trezor is massive overkill
270 2014-10-17 20:12:59 <BlueMatt> spend 100$ to cover your $600 investment!
271 2014-10-17 20:12:59 <hearn> earlz: for you, there are/will be services that do two factor authentication. bitgo is an example of that, not sure if they're doing a consumer focused wallet
272 2014-10-17 20:13:10 <hearn> chris pacia/alon muroch are working on a decentralised, spv 2-factor authd wallet
273 2014-10-17 20:13:23 <hearn> you use an android app in conjunction with a desktop app to authorise. that's pretty good, and cheap, if you have an android phone already
274 2014-10-17 20:13:42 <BlueMatt> note: the hardwarewallet.com one is 25$ for two
275 2014-10-17 20:13:55 <BlueMatt> and appears to be quite competent, at least from third-party accounts
276 2014-10-17 20:13:56 <earlz> Eh, I worry about keeping the keys safe... like not from theives but from if my house burns down
277 2014-10-17 20:13:57 <coryfields_> BlueMatt: no different than buying a ridiculous $1000 purse and putting $10 worth of stuff in it :)
278 2014-10-17 20:14:14 <BlueMatt> earlz: buy a bank vault!
279 2014-10-17 20:14:15 <BlueMatt> those are cheap
280 2014-10-17 20:14:21 <earlz> yea true
281 2014-10-17 20:14:22 <BlueMatt> coryfields_: but...but...fasion statement!
282 2014-10-17 20:14:26 <hearn> cheap?
283 2014-10-17 20:14:29 <hearn> maybe in the usa :)
284 2014-10-17 20:14:37 <hearn> 
ACTION rents a box in a bank vault

285 2014-10-17 20:14:46 <therp> hearn: 100 CHF per year, IIRC
286 2014-10-17 20:14:49 <earlz> A safety deposit box I assume is what you mean?
287 2014-10-17 20:14:54 <hearn> but yes  - key escrow tied to your identity is a service we definitely need. of course, then perhaps it's not so different to just using coinbase.
288 2014-10-17 20:14:59 <hearn> earlz: right
289 2014-10-17 20:15:23 <chmod755> therp, sounds about right
290 2014-10-17 20:15:37 <earlz> I personally want to see an anti-fraud multisig service. You use some special *EASY TO USE* mutlisig-only wallet
291 2014-10-17 20:15:44 <hearn> therp: yeah, that sounds right
292 2014-10-17 20:15:50 <hearn> earlz: yes that's what bitgo and friends are.
293 2014-10-17 20:16:04 <hearn> i think greenaddress, too
294 2014-10-17 20:16:14 <earlz> When you want to send funds out, the anti-fraud service has to ok your transaction.. sending a huge amount or if something looks suspicious, you have to do further authorizatins
295 2014-10-17 20:16:27 <earlz> are they easy to use though?
296 2014-10-17 20:16:36 <hearn> they look not too bad, but i never used them myself.
297 2014-10-17 20:16:38 <earlz> I not looked for competent multisig stuff in a while
298 2014-10-17 20:16:56 <hearn> the hard part of building such a service is knowing what fraud looks like. bitcoin is a "signal poor" environment
299 2014-10-17 20:17:04 <earlz> can you combine multisig with HD seeds?
300 2014-10-17 20:17:26 <hearn> well, plus, so far everyone who wanted to make such a fraud beating service has had to roll their own wallet from scratch. but now bcj 0.12 has multisig wallets support i hope it'll become a lot easier.
301 2014-10-17 20:17:29 <hearn> earlz: yes of course
302 2014-10-17 20:18:43 <hearn> earlz: the startups i know of in the bitcoin anti fraud space are focusing on b2b stuff at the moment, though
303 2014-10-17 20:18:47 <earlz> I think the most difficult bit about mutlisig is notifying the 2nd keyholder that a transaction needs signed, since it has to be outsid eof the standard p2p network and all
304 2014-10-17 20:18:48 <hearn> i guess they feel there's not much consumer demand
305 2014-10-17 20:19:03 <hearn> that's easy. you just have a protocol between wallet app and server.
306 2014-10-17 20:19:11 <earlz> yea, isn't there a BIP for that?
307 2014-10-17 20:19:35 <hearn> no there isn't. it's a bit early for a BIP. it's no big deal for protocols here to diverge for a while, people need to experiment and learn what works before standardisation makes sense
308 2014-10-17 20:19:53 <hearn> like i said, the hard parts are (a) building your own wallet, hopefully now mostly solved at least once bcj 0.12 wallets start launching (real soon now),   and (b) knowing what rules to use
309 2014-10-17 20:19:59 <earlz> at least multisig transactions are ok to send in cleartext so that's not a concern
310 2014-10-17 20:20:15 <hearn> it's easy to handwave from an armchair saying "velocity limits!" but it's hard to implement in a way that doesn't end up being trivially beaten, or have too many FPs to be useful
311 2014-10-17 20:20:56 <hearn> think about how often americans complain about their credit card stopping working when they travel
312 2014-10-17 20:21:03 <hearn> and that's WITH enormous amounts of data
313 2014-10-17 20:21:39 <earlz> Well, idealy, you'd have an out of band way to easily approve and fix things like that
314 2014-10-17 20:22:01 <hearn> yes, a second factor. but then you may as well just do that without any third party service and 2fa every transaction :) that's chris/alon's approach
315 2014-10-17 20:22:04 <earlz> like when the fraud service detects something it'd ask you by email and SMS or whatever for approval
316 2014-10-17 20:22:20 <earlz> I wouldn't mind that
317 2014-10-17 20:22:39 <hearn> https://www.reddit.com/r/Bitcoin/comments/2etbsx/bitcoin_authenticator_decentralized_2fa_and_next/
318 2014-10-17 20:22:41 <earlz> recurring transactions are big use case that's not easy right now without a 3rd party holding yoru money
319 2014-10-17 20:22:54 <hearn> yeah, there was a  proposed BIP for that a while ago but it was never implemented afaik
320 2014-10-17 20:23:35 <earlz> Unless you do the unrecommended thing of keeping all yoru funds in a single address, I don't see any easy way to do it without a special wallet constantly running on yoru computer
321 2014-10-17 20:23:54 <hearn> yes you do it the latter (or on your phone, which is easier)
322 2014-10-17 20:24:12 <hearn> you can create time locked funds, potentially, but then you need all the money up front
323 2014-10-17 20:24:18 <earlz> I want it to happen automatically though
324 2014-10-17 20:24:21 <earlz> yea, that's the problem
325 2014-10-17 20:24:22 <NewLiberty> or be prompted
326 2014-10-17 20:24:46 <hearn> earlz: is it such a big deal to have your phone do it in the background, for you? it can be fully automatic so you don't get asked
327 2014-10-17 20:25:01 <earlz> I mean, if it's the same people asking for money each month, same amount and same company, I don't wan tto approve it. I trust that it's not in error
328 2014-10-17 20:25:04 <hearn> most people have their phones on most of the time. if you trust your phone enough to have access to sufficient funds, it can be alright
329 2014-10-17 20:25:15 <hearn> yes that is quite straightforward to implement with bip70
330 2014-10-17 20:25:32 <earlz> Also, easy rejection though as well by either party
331 2014-10-17 20:25:32 <hearn> bip70+extension
332 2014-10-17 20:25:52 <earlz> If the business is hacked, they should be able to easily invalidate everyone who would normally send them funds
333 2014-10-17 20:26:37 <ThomasV> hearn: is bitcoin authenticator open sourced?
334 2014-10-17 20:26:46 <hearn> the way the proposed mechanism worked, when you set up the "direct debit" you could impose a max limit and recurrences
335 2014-10-17 20:26:51 <hearn> so there was some safety there.
336 2014-10-17 20:27:02 <hearn> ThomasV: https://github.com/negedzuregal/BitcoinAuthWallet  + https://github.com/cpacia/BitcoinAuthenticator
337 2014-10-17 20:27:08 <hearn> first is the desktop app. second is the android app.
338 2014-10-17 20:27:17 <ThomasV> oh nice
339 2014-10-17 20:27:38 <hearn> yeah it's pretty cool. quite heavy into crypto geek territory though. it's got the tor support and shamir's secret sharing, etc
340 2014-10-17 20:27:50 <hearn> more for power users than mainstream consumer, i think, but their progress is pretty neat
341 2014-10-17 20:27:56 <hearn> i like that they teamed up :)
342 2014-10-17 20:30:27 <earlz> I really need to learn more about how HD seeds work
343 2014-10-17 20:41:55 <ThomasV> hearn: btw, did you implement bip44 in bitcoinj? (with the wallet birth date)
344 2014-10-17 20:42:46 <hearn> no. just the regular bip32 hierarchy. using bip44 by default would have imposed too many constraints on the API and wallet designers, and having a choice of hierarchies to select from didn't make it for 0.12
345 2014-10-17 20:43:21 <ThomasV> right.. but my question was more about the scanning for wallet addresses
346 2014-10-17 20:43:55 <hearn> if you restore from seed+birthday then it'll find the rest of the addresses yes, using a gap limit of 100 by default + 1/3rd to keep bloom filter refreshes down
347 2014-10-17 20:43:58 <hearn> so 133 key lookahead
348 2014-10-17 20:44:26 <ThomasV> ok
349 2014-10-17 20:45:17 <hearn> why?
350 2014-10-17 20:46:13 <ThomasV> because I just read gavin's post about utxo commitments, and the prospect of nodes not having old full blocks
351 2014-10-17 20:47:34 <gmaxwell> really birth dates aren't enough, we should be keeping good until dates where possible as well.
352 2014-10-17 20:47:52 <hearn> yes. at the moment the p2p protocol has no pruning support though, so all peers spv clients can find can serve the whole chain
353 2014-10-17 20:49:01 <sipa> minimal pruning support (with nodes just stopping to announce themselves as full nodes) will likely be in 0.10
354 2014-10-17 20:49:34 <hearn> right, i know, but those peers don't exist from an spv clients perspective.
355 2014-10-17 20:49:39 <sipa> indeed
356 2014-10-17 20:52:22 <ThomasV> sipa: will that be default?
357 2014-10-17 20:52:32 <sipa> ThomasV: hell no
358 2014-10-17 20:52:46 <sipa> it will also disable wallet support, so i doubt many people will run it
359 2014-10-17 20:52:53 <sipa> except low-disk relay-only nodes
360 2014-10-17 20:53:05 <hearn> why does it disable wallet support?
361 2014-10-17 20:53:12 <gmaxwell> it's a second step to the full support.
362 2014-10-17 20:53:37 <gmaxwell> hearn: because it currently breaks a bunch of wallet rpcs and breaks rescanning.
363 2014-10-17 20:53:38 <sipa> hearn: just because nobody really thought hard about the wallet implications of it, i guess
364 2014-10-17 20:53:39 <earlz> Is there an estimate of how much diskspace will be required after the "minimal pruning" bit?
365 2014-10-17 20:53:43 <hearn> ah ok
366 2014-10-17 20:53:48 <sipa> earlz: 1 GB or so
367 2014-10-17 20:53:53 <earlz> wow
368 2014-10-17 20:54:02 <earlz> that's runnable on my VPS heh
369 2014-10-17 20:54:25 <gmaxwell> hearn: trying to complete the whole thing in one step would just delay it further. This much made a reasonable atomic unit.
370 2014-10-17 20:54:57 <hearn> sure, not against that, was just wondering if there was a specific issue with the wallet that needed the full chain. yes, if rescanning breaks, that's an issue.
371 2014-10-17 20:55:29 <sipa> right; just a bunch of edge cases to consider
372 2014-10-17 20:55:37 <sipa> and few people willing to work on the wallet code...
373 2014-10-17 20:56:12 <gmaxwell> plus it has a side effect of discouraging rapid deployment before we've handled some of the network cases. (e.g. still being able to sync from the blocks that the node does have)
374 2014-10-17 20:56:27 <gmaxwell> which is just a happy alignment.
375 2014-10-17 20:56:31 <earlz> Is there a list somewhere of alternative fully validating node libraries?
376 2014-10-17 21:02:06 <earlz> ?
377 2014-10-17 21:02:26 <hearn> not that i know of. there might be one on the wiki
378 2014-10-17 21:02:28 <earlz> I know there is a ruby implementation that's a full node.. not of anything else though
379 2014-10-17 21:03:26 <hearn> bitcoinj has sort of part of one, btcd is one, there are refactorings of bitcoin core.
380 2014-10-17 21:04:20 <hearn> there was another java one a while back that sank into obscurity because the guy basically didn't announce it or market it, but the code looked remarkably clean
381 2014-10-17 21:04:30 <lechuga_> which was that?
382 2014-10-17 21:04:48 <hearn> done by some retired IBM guy to keep his mind nimble, he said.
383 2014-10-17 21:04:48 <hearn> i can't remember the name unfortunately
384 2014-10-17 21:04:49 <earlz> what do you mean "sort of part of one"? lol
385 2014-10-17 21:05:18 <hearn> earlz: it does full validation and can calculate an address-indexed utxo set if you want, but it doesn't accept connections from other clients
386 2014-10-17 21:06:59 <hearn> oh yes
387 2014-10-17 21:07:01 <hearn> bits of proof too
388 2014-10-17 21:08:13 <lechuga_> earlz: what's your use case?
389 2014-10-17 21:09:54 <earlz> just curiosity as to how things could be better
390 2014-10-17 21:10:09 <ThomasV> I believe bits of proof is closed source
391 2014-10-17 21:10:14 <earlz> Are HD wallets considered as safe as traditional wallets?
392 2014-10-17 21:10:32 <lechuga_> it depends on how u use them
393 2014-10-17 21:10:36 <sipa> earlz: we're currently working on a dynamic library built from the bitcoin core source code, so others don't need to reimplement (all of) the consensus rules
394 2014-10-17 21:10:59 <sipa> earlz: as it has shown to be incredibly tricky to replicate the behavior bug-for-bug (and not doing so would be a forking risk)
395 2014-10-17 21:11:40 <sipa> i would be very surprised if any codebase perfectly matches bitcoin core in validation behavior
396 2014-10-17 21:12:35 <earlz> I'm reading bip32 trying to understand this ugh
397 2014-10-17 21:12:54 <Luke-Jr> I think if you use only hardened derivation, HD wallets are at least as secure
398 2014-10-17 21:13:11 <lechuga_> earlz: i'd also recommend http://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/
399 2014-10-17 21:13:16 <Luke-Jr> I guess except for the ability to access future bitcoins if you're compromised
400 2014-10-17 21:13:18 <sipa> HD with only hardened derivation is just deterministic wallets
401 2014-10-17 21:13:29 <Luke-Jr> sipa: ?
402 2014-10-17 21:13:43 <Luke-Jr> you lose the hierarchy?
403 2014-10-17 21:13:58 <sipa> right, sure
404 2014-10-17 21:14:25 <sipa> i mean, technically the behavior of a hardened HD wallet chain is very easy to replicate using just a deterministic wallet
405 2014-10-17 21:14:36 <sipa> just reuse your derivation construction on generated private keys
406 2014-10-17 21:15:20 <earlz> so, are any random string of bytes a suitable private key, or am I wrong?
407 2014-10-17 21:15:30 <Luke-Jr> sipa: I don't understand why you need to lose hierarchy
408 2014-10-17 21:15:37 <sipa> Luke-Jr: you don't
409 2014-10-17 21:15:45 <Luke-Jr> oh ok
410 2014-10-17 21:15:56 <sipa> Luke-Jr: but you can easily add the hierarchy again if you already have a determinstic derivation
411 2014-10-17 21:16:08 <Luke-Jr> sipa: I was thinking a hardened-only HD wallet would be ideal, so your wallet can keep private keys just for spending a limited amount of funds, and if it gets control of too much, it deletes some
412 2014-10-17 21:16:36 <sipa> that means you also lose the fun part :)
413 2014-10-17 21:16:43 <Luke-Jr> maybe, but it's a nice use case
414 2014-10-17 21:40:11 <coryfields_> sipa: for sign/signcompact, i should think client libs/apps be expecting to pass in der privkeys?
415 2014-10-17 21:40:20 <coryfields_> *would be
416 2014-10-17 21:40:26 <sipa> eww no
417 2014-10-17 21:40:40 <sipa> der privkeys is just an artefact of using openssl before
418 2014-10-17 21:40:48 <sipa> they're annoyingly large and hard to parse
419 2014-10-17 21:55:33 <coryfields_> mm ok
420 2014-10-17 23:05:25 <kgk> I have always wondered this. In the protocol spec, why is a tx output's value an int64 and not a uint64?
421 2014-10-17 23:06:04 <Luke-Jr> kgk: the two are equivalent in this case
422 2014-10-17 23:06:17 <Luke-Jr> it should be safe to treat it as a uint64
423 2014-10-17 23:06:23 <kgk> could the value be nagative?
424 2014-10-17 23:06:25 <kgk> ah ic
425 2014-10-17 23:06:35 <kgk> so it's really treated as uint64
426 2014-10-17 23:06:55 <kgk> thx :)
427 2014-10-17 23:07:00 <Luke-Jr> it doesn't matter what it's treated as
428 2014-10-17 23:07:07 <Luke-Jr> the high bit is never set
429 2014-10-17 23:07:20 <kgk> ohhhh duh
430 2014-10-17 23:42:13 <coryfields_> jtimon: ping
431 2014-10-17 23:42:47 <jtimon> pong
432 2014-10-17 23:43:47 <coryfields_> jtimon: i've decided to go a different route wrt shuffling stuff around for boost. Am I going to get in your way by reworking key.h/key.cpp significantly ?
433 2014-10-17 23:44:17 <jtimon> nope, I'm not touching key.o
434 2014-10-17 23:44:52 <coryfields_> ok, great
435 2014-10-17 23:54:40 <jtimon> I have a PR prepared to move CTransaction out of core that should help with the minimal libscript, it may cause a trivial conflict on #4981 on the include in main.h, are you ok with that? I can rebase on top of your PR too, yours already has many PRs
436 2014-10-17 23:55:54 <coryfields_> no problem
437 2014-10-17 23:57:32 <coryfields_> wait
438 2014-10-17 23:57:35 <coryfields_> why move it out?