1 2012-11-29 00:02:09 <jrmithdobbs> and who is bradley? what happened to bob?
2 2012-11-29 00:05:10 <gmaxwell> I'm happy to see a flooding chat network exits. But ... oy.
3 2012-11-29 00:06:59 <jrmithdobbs> it's interesting but it seems to me the POW-per-message requirement undoes the circumventing of pgp/smime complexity (smime using whitelisted CAs or specific certs, not *the* PKI)
4 2012-11-29 00:07:26 <jrmithdobbs> so it puts you back where you started. with gpg/etc there's a one time investment at ramp up vs ~4 minutes of work every message
5 2012-11-29 00:07:51 <gmaxwell> I'm surprised it doesn't have integrated mix pooling.. at least as described in the paper it sounds quite traffic analysis vulnerable.
6 2012-11-29 00:09:33 <jrmithdobbs> gmaxwell: it proposes something that's effectively the same if I understand
7 2012-11-29 00:09:38 <gmaxwell> Not sure why they don't do merged mining as the pow.
8 2012-11-29 00:10:43 <jrmithdobbs> gmaxwell: since the acks to a message can be an ack to multiple messages or the sending of another /etc it kind of has the same effect (assuming that's actually implemented)
9 2012-11-29 00:10:59 <gmaxwell> freeking gui is incompatible with xmona.
10 2012-11-29 00:11:05 <gmaxwell> er xmonad
11 2012-11-29 00:11:59 <gmaxwell> jrmithdobbs: no no. For example. I dunno who you are, you send me some messages. I use my magical power to observe the whole network to coorelate the times your messages came in with which nodes were online and sending data around that time.
12 2012-11-29 00:12:21 <jrmithdobbs> gmaxwell: yes they cover that
13 2012-11-29 00:12:51 <jrmithdobbs> gmaxwell: section 7 and 8 both address it somewhat (7 more than 8) but are sparse on details
14 2012-11-29 00:13:27 <jrmithdobbs> it doesn't really describe the how just the what
15 2012-11-29 00:15:12 <jrmithdobbs> gmaxwell: if I'm understanding correctly the ack includes sender provided data and said data can contain other messages of any type (pubkey request, ack, new message) in such a way that someone ack'ing your message that envelopes them sends the original message as well
16 2012-11-29 00:16:31 <jrmithdobbs> I still want to know if bob is on vacation or what. That is irksome :P
17 2012-11-29 00:17:19 <gmaxwell> jrmithdobbs: I think bob was killed by apache helecoptors after being mistaken for an insurgent with a RPG.
18 2012-11-29 00:18:03 <jrmithdobbs> gmaxwell: it was bound to happen with all those secrets he's been keeping for so many years
19 2012-11-29 00:18:43 <jrmithdobbs> gmaxwell: one of those messages he passed to alice was bound to decode with some terrorist's key into something sensical eventually!
20 2012-11-29 00:18:59 <jrmithdobbs> poor bob :(
21 2012-11-29 00:50:53 <gmaxwell> jgarzik: where did you find this thing. It does a bunch of weird stuff.
22 2012-11-29 00:51:57 <gmaxwell> E.g. it requires a two way exchange to send someone a message because for some reason I can't comprehend they copied bitcoin's hash of a public key thing... well. they may have been more inclined to do that because it's using 2048 bit RSA instead of ECDH.
23 2012-11-29 00:52:35 <Diablo-D3> dem diffie helmans
24 2012-11-29 00:53:54 <gmaxwell> if anyone wants to try sending me a message: BM-2ne7uh1TMsJqGcA8emn9WC3YdKbVeQBqeeU
25 2012-11-29 01:05:00 <jgarzik> gmaxwell: it was posted on reddit/r/Bitcoin/ No opinion on its quality
26 2012-11-29 01:05:17 <jgarzik> obviously bitcoin-inspired
27 2012-11-29 01:05:46 <jgarzik> maybe has proof-of-work to prevent spam too, I remember reading?
28 2012-11-29 01:05:57 <gmaxwell> yes, it's based on PoW for rate control.
29 2012-11-29 01:51:34 <LightRider> So is anyone working on a client for 0x10c? dcpu.com dcpu.ru 0x10co.de
30 2012-11-29 01:55:38 <gmaxwell> LightRider: that would be a little silly.
31 2012-11-29 02:00:23 <LightRider> Silly but awesome.
32 2012-11-29 02:07:46 <LightRider> Is anyone working on an assembly version of bitcoin in general? That would be silly and awesome also.
33 2012-11-29 02:09:03 <copumpkin> sure, I'll take the regular one and run it through g++ -S
34 2012-11-29 02:09:59 <LightRider> I mean a bare metal hand optimized version. Would it be too impractical?
35 2012-11-29 02:10:57 <Luke-Jr> LightRider: extremely
36 2012-11-29 02:11:08 <Luke-Jr> also stupid, since compilers are better at optimizing than humans are
37 2012-11-29 02:11:25 <Luke-Jr> and there isn't any one "assembly" language - there are about 50
38 2012-11-29 02:11:35 <Luke-Jr> and what works with one DOESN'T work with most of the others
39 2012-11-29 02:11:55 <Luke-Jr> and even if a human did hand-optimize better than the compiler, it would be specific to a certain CPU
40 2012-11-29 02:13:21 <LightRider> I suppose. In my early CS courses, I was always told that hand crafted assembly is usually superior.
41 2012-11-29 02:13:53 <gmaxwell> You were misinformed, at least wrt 'usually'.
42 2012-11-29 02:14:53 <gmaxwell> Any remotely modern processor is quite hard to schedule for, and the compiler embodies a lot of super ninja skills. It's certantly possible to beat the compiler, ??? at least for some people some of the time while also benchmarking their work against the compilers (so they couldn't do worse)... but usually? no.
43 2012-11-29 02:19:21 <Luke-Jr> LightRider: you begin to see how useless universities have become??? :P
44 2012-11-29 02:21:10 <copumpkin> LightRider: back in michael abrash's day, maybe
45 2012-11-29 02:21:17 <copumpkin> when he wrote that black book of awesome optimization techniques
46 2012-11-29 02:21:31 <gmaxwell> As an example, idiv on i7 has something like 90 cycles latency. but when you write b=a/7; the compiler writes a multiply by 1840700269, a shift, and a subtract.. for a net latency of something like 5. (and higher throughput too)
47 2012-11-29 02:21:41 <copumpkin> now there's too much to keep track of
48 2012-11-29 02:22:09 <gmaxwell> and sure, there are assembly coders that can optimize like that??? (otherwise I wouldn't know to tell you that example), but they aren't common and the amount of code they can optimize that tightly is limited.
49 2012-11-29 02:22:13 <copumpkin> pretty much the main reason for dropping down to assembly these days is to use things that compilers don't generate very well, like fancy SSE instructions (gcc has intrinsics for them, but they're kinda weird)
50 2012-11-29 02:22:34 <copumpkin> or to do weird things that your language won't let you do, like screw with the stack or jump around in odd ways
51 2012-11-29 02:22:52 <Luke-Jr> or implement the libc <.<
52 2012-11-29 02:23:08 <gmaxwell> copumpkin: setjmp /longjmp ftw. :P
53 2012-11-29 02:23:13 <copumpkin> :)
54 2012-11-29 02:23:28 <Luke-Jr> gmaxwell: I wonder if using div(3) hurts more than it helps
55 2012-11-29 02:24:32 <LightRider> I remember reading that nVidia was more of a software company than a hardware company because they spent most of their time on driver/compiler optimazation. I guess Intel/AMD went that way also. 90 cycles for idiv seems crazy.
56 2012-11-29 02:24:56 <gmaxwell> LightRider: go write out a divider with basic logic and you'll see why.
57 2012-11-29 02:25:16 <copumpkin> LightRider: one of the big things that has changed since people hand-optimized things are crazy superscalar archs
58 2012-11-29 02:25:26 <copumpkin> well
59 2012-11-29 02:25:26 <gmaxwell> Big ones (E.g. 32/64 bit) ones are really really hard to to make compact!
60 2012-11-29 02:26:05 <copumpkin> LightRider: which means that reordering instructions can make things way faster
61 2012-11-29 02:26:09 <copumpkin> your compiler is doing that behind your back for you
62 2012-11-29 02:27:11 <LightRider> 0x10c already has about a dozen OS implementations and at least 1 partial python port.
63 2012-11-29 02:27:25 <gmaxwell> There is a lot of optimization techniques in GCC that no human could have invented.. people used tools like gnu superoptimizer to search for faster isomorphic instruction sequences via brute force and the compiler substitutes them in as it can.
64 2012-11-29 02:28:07 <LightRider> And people still in this consumer infinite growth economy. Astonishing.
65 2012-11-29 02:28:19 <copumpkin> LightRider: also worth noting that although things like cache awareness are important for speed, even michael abrash said back in the day that the main thing you should be looking for are algorithmic improvements
66 2012-11-29 02:28:23 <LightRider> *believe in
67 2012-11-29 02:28:29 <gmaxwell> it kinda makes me said that notch didn't use MMIX ... at least it would be a semimodern hypothetical architecture. Oh well. :(
68 2012-11-29 02:30:27 <LightRider> It wouldn't fit the story. He's limiting himself to 1980's computing power.
69 2012-11-29 02:31:47 <etotheipi_> gmaxwell: does Bitcoin-Qt use the passphrase directly to derive the encryption key for the wallet? or does it use the passphrase to derive a key to decrypt the decryption-key for the wallet?
70 2012-11-29 02:32:23 <gmaxwell> The latter. There is an encrypted master key. Otherwise changing the password would be quite a bit more burdensome.
71 2012-11-29 02:33:27 <etotheipi_> besides the effort required to change the password (re-encrypting all the encrypted data in the wallet) is there anything wrong with the former?
72 2012-11-29 02:33:50 <LightRider> Well, I do remember having to tell my professors about the latest advancements in processor architecture in class a few times. I should have realized they were behind the times.
73 2012-11-29 02:35:35 <gmaxwell> etotheipi_: well not effort, but also harder to make it safe since it needs to be atomic. Other than that??? it's harder to securely erase more data when you change keys, though I admit thats super fringe.
74 2012-11-29 02:36:05 <gmaxwell> e.g. if you worry your password is compromised you only need to make sure the old encrypted master key is erased vs the whole wallet in the indirect scheme.
75 2012-11-29 02:37:20 <etotheipi_> yeah... I was thinking I would prefer the individual key encryption to change when the passphrase is changed, but I'm having a tough time finding a scenario where that would actually matter (especially with deterministic wallets)
76 2012-11-29 02:38:24 <gmaxwell> the indirect scheme still lets you do that if you want.. e.g. you could also rotate the master key at the same time.
77 2012-11-29 02:38:32 <gmaxwell> though that would defeat the purpose. :P
78 2012-11-29 03:25:34 <etotheipi_> gmaxwell, sipa, is it necessary to settle for a 4-byte "fingerprint" for HD wallet nodes/addresses? That makes addresses very likely to be unique, but also likely to result in collisions that I have to build around
79 2012-11-29 03:25:52 <etotheipi_> is there objection to just using a 16-byte fingerprint and avoid it altogether?
80 2012-11-29 03:40:24 <midnightmagic> why does wei dai write assembly for crypto++ if hand-optimization is as useless as you two describe?
81 2012-11-29 03:41:12 <Luke-Jr> midnightmagic: maybe he's a closet miner.
82 2012-11-29 03:42:03 <Luke-Jr> (more seriously, probably SHA256 is too complicated for compilers to optimize well)
83 2012-11-29 03:42:12 <Luke-Jr> (and other crypto algorithms)
84 2012-11-29 03:44:08 <midnightmagic> for chips like many of the atmel, or similar, hand-optimizing is still better, since on many of those chips there *are* no weird branch prediction or cache or whatever shortcuts. also, optimization is not always for speed. compilers still don't (and likely never will, because nobody cares about it) optimize for space better than a human can.
85 2012-11-29 03:45:36 <midnightmagic> Luke-Jr: and yet an architecture-optimized version (similar to what mrb_ wrote for example) for md5 rules wei dai's crypto++ assembly version for speed...
86 2012-11-29 03:52:05 <Diablo-D3> midnightmagic: heh
87 2012-11-29 03:52:06 <Diablo-D3> dude
88 2012-11-29 03:52:14 <midnightmagic> yeah.. I'm pretty sure that your guys' assumptions about hand-optimization are only valid if you compare a stereotypical historical hero-coder human-optimizer egotist (which, if what you say is true, would continually fail at what he does) that doesn't really exist.
89 2012-11-29 03:52:16 <Diablo-D3> some of that assembly isnt for optimization
90 2012-11-29 03:52:21 <Diablo-D3> some of its to whack the hardware into working
91 2012-11-29 03:52:33 <Diablo-D3> like, to prevent data leaking and such
92 2012-11-29 03:52:54 <midnightmagic> Diablo-D3: But he makes mistakes. I found one in his SHA256 routines.
93 2012-11-29 03:53:04 <Diablo-D3> ouch
94 2012-11-29 03:53:06 <midnightmagic> (I helped warner find one, rather.)
95 2012-11-29 03:53:09 <Diablo-D3> still, point stands
96 2012-11-29 03:53:19 <Diablo-D3> openssl does it too
97 2012-11-29 03:53:24 <Diablo-D3> lots of black voodoo magic shit
98 2012-11-29 03:53:55 <Diablo-D3> shit, I went downstairs to get a soda, I came up with a piece of apple pie
99 2012-11-29 03:53:57 <midnightmagic> that would be valid, but *everything* is written in it, and there are non-asm alternatives also in the package.
100 2012-11-29 03:54:12 <Diablo-D3> notice I am still lacking a soda
101 2012-11-29 03:54:18 <midnightmagic> go get a soda.
102 2012-11-29 03:54:23 <midnightmagic> ACTION tugs on a coke zero
103 2012-11-29 03:55:10 <midnightmagic> ^^^ deliberate reference to people who are reading this log in about.. 5 years. Hello, future human!
104 2012-11-29 03:55:42 <midnightmagic> greetings from the past, cock-knocker!
105 2012-11-29 03:56:04 <Diablo-D3> I bet in 5 years my music tastes will still be what they are now
106 2012-11-29 03:56:19 <midnightmagic> all that dubstep. bleh, really?
107 2012-11-29 03:57:01 <jgarzik> not bad at all
108 2012-11-29 03:57:03 <jgarzik> chain-verf: validating mainnet chainfile /spare/tmp/chaindb/blocks.dat
109 2012-11-29 03:57:15 <jgarzik> that includes an in-memory unspent-TX hash table
110 2012-11-29 03:57:19 <jgarzik> and verifies spent-ness
111 2012-11-29 03:57:29 <Diablo-D3> midnightmagic: no
112 2012-11-29 03:57:36 <jgarzik> maxed out at 1.0g RSS
113 2012-11-29 03:57:36 <midnightmagic> ooOOoo how do I do that too? i wanna try!
114 2012-11-29 03:58:25 <midnightmagic> also, wtf machine do you have that actually fills in maxres?
115 2012-11-29 03:58:33 <jgarzik> I could probably shrink my UTXO entries a bit more, be a bit smarter about memory allocation
116 2012-11-29 03:58:47 <jgarzik> midnightmagic: linux/x86-64/fedora
117 2012-11-29 03:59:00 <midnightmagic> jgarzik: Is that on a test branch somewhere I can try?
118 2012-11-29 03:59:31 <midnightmagic> and, especially, does it do a debug trace on bad data?
119 2012-11-29 04:00:31 <jgarzik> midnightmagic: that is picocoin's chain-verf test, from picocoin.git HEAD
120 2012-11-29 04:00:42 <jgarzik> midnightmagic: you can trace whatever gdb permits you
121 2012-11-29 04:01:13 <midnightmagic> jgarzik: I mean, does it identify or highlight broken data that fails verification?
122 2012-11-29 04:01:34 <jgarzik> midnightmagic: yes. the test fails, and it tells you where it failed.
123 2012-11-29 04:01:37 <Diablo-D3> midnightmagic: like, atm, Im listening to shiro sagisu - spending time in preperation
124 2012-11-29 04:01:54 <midnightmagic> Diablo-D3: sounds like japanidubstep
125 2012-11-29 04:03:18 <Diablo-D3> midnightmagic: nope.
126 2012-11-29 04:03:45 <Diablo-D3> https://www.youtube.com/watch?v=3ae1ryQJkc8
127 2012-11-29 04:04:58 <midnightmagic> i never did understand what the fuss was about neon genesis..
128 2012-11-29 04:05:10 <Diablo-D3> midnightmagic: well
129 2012-11-29 04:05:20 <Diablo-D3> you have to watch it several times through to really get it
130 2012-11-29 04:05:44 <midnightmagic> i have an anime translator who explains everything while we're watching, i don't have to do that.
131 2012-11-29 04:05:55 <Diablo-D3> midnightmagic: its not that
132 2012-11-29 04:06:24 <Diablo-D3> basically, anno, the director, made the show as a sort of physchological therapy for himself
133 2012-11-29 04:06:58 <Diablo-D3> midnightmagic: the characters are borderline real people.
134 2012-11-29 04:07:22 <Diablo-D3> midnightmagic: and its not even that great of an anime for anime's sake
135 2012-11-29 04:07:35 <Diablo-D3> its just that repeating viewings you get to pick up on how really fucked up the entire show is
136 2012-11-29 04:07:53 <Diablo-D3> and the more you dig into it, the more fucked up it gets
137 2012-11-29 04:08:07 <midnightmagic> lol what does that even mean ?
138 2012-11-29 04:08:15 <Diablo-D3> midnightmagic: its layers and layers and layers of bullshit
139 2012-11-29 04:08:48 <midnightmagic> scratch that. let's go to another channel and maybe you can just give me one, narrow, specific example?
140 2012-11-29 04:08:54 <Diablo-D3> bullshit of society, bullshit of interpersonal relationships, bullshit of mental illness
141 2012-11-29 04:08:57 <midnightmagic> lol #bitcoin-assets? :)
142 2012-11-29 04:09:18 <Diablo-D3> meh
143 2012-11-29 04:09:29 <Diablo-D3> ACTION continues in #assets
144 2012-11-29 04:10:48 <Luke-Jr> wumpus: sipa: when you guys are ready to build 0.7.2rc2 let me know and I'll tag/push it..,
145 2012-11-29 04:23:43 <jgarzik> old: 142.51user 2.18system 2:27.04elapsed 98PU (0avgtext+0avgdata 1095480maxresident)k
146 2012-11-29 04:23:54 <jgarzik> new: 138.94user 2.10system 2:23.24elapsed 98PU (0avgtext+0avgdata 797648maxresident)k
147 2012-11-29 04:23:59 <jgarzik> much better
148 2012-11-29 04:24:08 <jgarzik> memory usage-wise
149 2012-11-29 04:24:29 <jgarzik> that's full mainnet in memory UTXO set
150 2012-11-29 04:50:24 <jgarzik> what is current testnet3 height, please?
151 2012-11-29 04:50:39 <jgarzik> 39057?
152 2012-11-29 05:25:22 <synthetik> ok guys i was over in #bitcoin but not much help there i really need help as its a matter of quite a few thousand
153 2012-11-29 05:25:31 <synthetik> i lost control of one of my accounts
154 2012-11-29 05:25:57 <synthetik> in order to regain control they asked for my deposit addresses into my exchange (cavirtex)
155 2012-11-29 05:26:14 <synthetik> i need to look up certain amounts via date and time in the block chain
156 2012-11-29 05:26:19 <synthetik> any suggestions how ?
157 2012-11-29 05:27:55 <maaku> blockchain.info
158 2012-11-29 05:28:47 <maaku> but are you saying thats a security question?
159 2012-11-29 05:29:11 <maaku> because that'd be pretty dumb, blockchain data being public
160 2012-11-29 05:30:38 <Cusipzzz> so you have amount, date, and time of txn and need the addresses??
161 2012-11-29 05:30:39 <jgarzik> picocoin officially (a) validates mainnet and testnet3 block chains, except for script validation, and
162 2012-11-29 05:30:47 <jgarzik> (b) passes ref client script validation tests
163 2012-11-29 05:31:12 <jgarzik> takes < 3 minutes to check mainnet chain
164 2012-11-29 05:31:18 <jgarzik> excl. script
165 2012-11-29 05:31:39 <synthetik> Cusipzzz: yes
166 2012-11-29 05:32:01 <synthetik> I have date time and amount
167 2012-11-29 05:32:05 <Cusipzzz> how accurate are the times? do you have block #s?
168 2012-11-29 05:32:08 <synthetik> i need deposit address
169 2012-11-29 05:33:32 <synthetik> for instance last deposit was Nov. 8, 2012, 8:50 p.m. \tDeposit \t10.11
170 2012-11-29 05:33:56 <synthetik> no i don't have block numbers sorry
171 2012-11-29 05:34:38 <synthetik> but i would say the time is fairly accurate
172 2012-11-29 05:35:31 <Cusipzzz> is that UTC time? eastern?
173 2012-11-29 05:36:41 <synthetik> i just made a withdrawl 15 min ago and it said Nov. 28, 2012, 11:15 p.m
174 2012-11-29 05:36:50 <synthetik> so that would be GMT -8
175 2012-11-29 05:36:54 <synthetik> iirc
176 2012-11-29 05:38:05 <andrew12-> jgarzik: wow.
177 2012-11-29 05:40:28 <synthetik> Cusipzzz: Ideas ?
178 2012-11-29 05:40:37 <Cusipzzz> synthetik: closest I found was b977e507e479c46c98ce369d2a9cd909e29213dded546a953e7ccd9520f8c7a1 - could be 8 hrs to gmt, minus 6 blocks for confirmations
179 2012-11-29 05:41:13 <Cusipzzz> http://blockexplorer.com/tx/b977e507e479c46c98ce369d2a9cd909e29213dded546a953e7ccd9520f8c7a1
180 2012-11-29 05:42:40 <synthetik> how did you get to that point though
181 2012-11-29 05:43:16 <Cusipzzz> everythng is public...all nodes have that information?
182 2012-11-29 05:44:02 <synthetik> ok but that block was nov 9th
183 2012-11-29 05:44:16 <synthetik> i need nov 8th
184 2012-11-29 05:44:26 <Cusipzzz> yes, 8pm nov 8 = nov 9 gmt
185 2012-11-29 05:45:14 <synthetik> is it all in UTC ?
186 2012-11-29 05:46:13 <Diablo-D3> no, its in ptc.
187 2012-11-29 05:46:32 <Diablo-D3> the penis time zone.... named for my penis, which is so large, it takes up an entire time zone.
188 2012-11-29 05:47:37 <synthetik> ok i know that the time given is based of of alberta canada's time
189 2012-11-29 05:47:46 <synthetik> which is not GMT
190 2012-11-29 05:47:49 <synthetik> i don't think
191 2012-11-29 05:50:18 <synthetik> so currently it would be Thu, 29 Nov 2012 06:50:07 GMT
192 2012-11-29 05:51:30 <Cusipzzz> yes. so convert that nov 8 time to gmt, find the corresponding block, account for how many confirmations they wait before showing the deposit, and you should have it
193 2012-11-29 05:53:41 <synthetik> so how did you zero in on that date though
194 2012-11-29 05:53:48 <synthetik> or rather that block vs that date
195 2012-11-29 05:54:16 <Cusipzzz> that block is close to the time conversion and has a txn with the 10.11btc amount
196 2012-11-29 05:54:56 <synthetik> sure but how did you look that block up via the date or the amount ?
197 2012-11-29 05:55:44 <Cusipzzz> is has to be block 2071xx based on the date and time
198 2012-11-29 05:56:28 <synthetik> sure ok i get that but how did you come that conclusion like say i wanted to look up augest 3rd how would i know what block range ?
199 2012-11-29 05:57:07 <Cusipzzz> if you run a nde you have all of this information, or you can use a site like blockexplorer or blockcahin info
200 2012-11-29 05:57:10 <Cusipzzz> node
201 2012-11-29 06:01:57 <synthetik> so would it be safe to say then this is probably the transaction http://blockexplorer.com/address/19SMy7srGqvVbX1WqWbvfKAefCAiPjseRL
202 2012-11-29 06:03:59 <Cusipzzz> possibly. i didn't do an exhaustive search, but that was the closest I found
203 2012-11-29 06:06:33 <Cusipzzz> if it's really worth thousands to you, i suggest paying someone to research all the date/times/amounts
204 2012-11-29 06:40:44 <midnightmagic> sipa: if we don't reorg on new branches, do we treat our own submitted solutions differently? that is, for mining purposes, do we still reorg on branches with same-work sums if the block is our own, so that future mining commands build on our own block rather than someone else's?
205 2012-11-29 06:41:08 <midnightmagic> sipa: re: pull request #1980
206 2012-11-29 08:43:50 <joepie91> very interesting concept that may appeal to people here: http://falkvinge.net/2012/11/20/payright-a-copyrightpatent-reform-proposal-to-make-piracy-obsolete/
207 2012-11-29 09:06:46 <sipa> midnightmagic: our own blocks are treated the same as everyone else
208 2012-11-29 09:08:25 <epscy> is the 0.8 branch going to be more performant than 0.7
209 2012-11-29 09:10:19 <sipa> etotheipi_: i didn't want to waste too much data on it; if there are multiple matches, try them all on import
210 2012-11-29 09:10:39 <epscy> i seem to have issues running bitcoind on openvz
211 2012-11-29 09:10:40 <t7> if you guys where building a service using bitcoin, would you use a leightweight client or a full verifying node ?
212 2012-11-29 09:11:08 <epscy> t7: i think that depends on what you are doing
213 2012-11-29 09:13:02 <sipa> epscy: a lot
214 2012-11-29 09:16:14 <t7> how many transactions have ever used a custom script ?
215 2012-11-29 09:17:08 <abrkn> i see them some times
216 2012-11-29 09:17:27 <epscy> sipa: i seem to get std::bad_alloc messages alot
217 2012-11-29 09:17:35 <epscy> and then have to restart
218 2012-11-29 09:17:47 <epscy> so is the memory usage of 0.8 likely to be less?
219 2012-11-29 09:19:01 <t7> does bitcoind keep a database of all unspent outputs or does it search for them in the blockchain when it needs them?
220 2012-11-29 09:25:35 <sipa> t7: up to 0.7 an index of txid in the blockchain, since 0.8 a db of utxo
221 2012-11-29 09:25:56 <sipa> epscy: bad_alloc? how do you do that?
222 2012-11-29 09:26:09 <epscy> run out of memory i assume
223 2012-11-29 09:26:28 <epscy> could just be this VPS is dodgy though too
224 2012-11-29 09:26:51 <sipa> 0.8 should use a little less memory
225 2012-11-29 09:29:09 <t7> sipa have you considered using a postgres or something to store all this?
226 2012-11-29 09:29:28 <t7> im not sure how that would affect performance and/or memory usage
227 2012-11-29 09:29:47 <t7> might get some nice things for free though
228 2012-11-29 09:30:17 <epscy> postgres would be a pretty hefty dependancy
229 2012-11-29 09:30:41 <t7> well its a pretty hefty program at the moment
230 2012-11-29 09:30:47 <epscy> and typically a bitcoin client only has one user
231 2012-11-29 09:31:23 <epscy> so it's scaling problems are different from a traditional sql db
232 2012-11-29 09:31:28 <t7> i guess most users are going to move to lightweight clients in the future
233 2012-11-29 09:31:38 <epscy> i don't think bitcoin is that hefty
234 2012-11-29 09:32:19 <epscy> i'm guessing it's kloc is less than postgres for example
235 2012-11-29 09:32:42 <t7> yeah i meant runtime cost rather than LOC
236 2012-11-29 09:32:53 <t7> LOC isnt so much
237 2012-11-29 09:33:30 <epscy> well it's runtime cost is due to disk space and cpu usage
238 2012-11-29 09:33:31 <epscy> but once you are synced it shouldn't be that bad
239 2012-11-29 09:34:01 <sipa> t7: why postgres?
240 2012-11-29 09:34:32 <sipa> libbitcoin uses sqlite iirc
241 2012-11-29 09:34:39 <sipa> abe uses an sql b
242 2012-11-29 09:34:43 <sipa> db
243 2012-11-29 09:34:55 <sipa> bitsofproof too
244 2012-11-29 09:35:13 <epscy> did you guys look at tokyo cabinet
245 2012-11-29 09:35:17 <sipa> bitcoind used bdb, and is switching to leveldb
246 2012-11-29 09:35:30 <epscy> or kyoto cabinet, whichever makes more sense
247 2012-11-29 09:35:50 <sipa> epscy: yes, didn't seem to have advantages over leveldb
248 2012-11-29 09:35:56 <t7> i figured postgres will be clever with caching and stuff automatically
249 2012-11-29 09:36:28 <sipa> t7: sure, but so is leveldb
250 2012-11-29 09:37:11 <wumpus> the part that uses so much memory is not the databse
251 2012-11-29 09:37:39 <epscy> can you run postgres as an embedded database like sqlite?
252 2012-11-29 09:37:53 <epscy> does postgres run on windows?
253 2012-11-29 09:37:54 <wumpus> no
254 2012-11-29 09:37:56 <wumpus> yes
255 2012-11-29 09:38:09 <epscy> right
256 2012-11-29 09:38:24 <epscy> so you would be adding a postgres server as a dependency
257 2012-11-29 09:38:31 <wumpus> there was a project to run mysql as an embedded database but it was abandoned long time ago.. there's a limit to the amouint of complexity that is useful for an embedded database
258 2012-11-29 09:39:19 <epscy> which would probably would ok for systems with a decent package manager
259 2012-11-29 09:39:19 <wumpus> sqlite is neatly at that limit IMO
260 2012-11-29 09:39:20 <epscy> sqlite is kinda annoying
261 2012-11-29 09:39:20 <wumpus> annoying?!
262 2012-11-29 09:39:28 <epscy> i always try to put sqlite databases on a ramdisk if i can
263 2012-11-29 09:39:32 <wumpus> what are you trying to use it for? I'm not saying it is a good fit for bitcoin or 'large dumb data' storage
264 2012-11-29 09:39:47 <epscy> simple way to minimise concurrency issues
265 2012-11-29 09:40:18 <epscy> wumpus: i tried to use it for storing details of mp3s
266 2012-11-29 09:40:41 <wumpus> yes it was not really designed for concurrent use, they recommend using a single thread that does that database access
267 2012-11-29 09:40:56 <epscy> indeed
268 2012-11-29 09:41:13 <wumpus> should be fine for that
269 2012-11-29 09:41:39 <epscy> well if you are adding a lot of stuff at the same time, you can't read
270 2012-11-29 09:50:52 <wumpus> there's also firebird, also an open source sql embeddedable database but a step up from sqlite (both in capabilities and, size probably, I haven't used it)
271 2012-11-29 09:52:05 <epscy> oh interesting
272 2012-11-29 09:52:06 <epscy> for some reason i thought firebird was commericial
273 2012-11-29 09:58:21 <abrkn> i think ive messed up my wallet with using move
274 2012-11-29 09:58:57 <abrkn> https://gist.github.com/4168198
275 2012-11-29 09:59:17 <abrkn> but if i add up the send and receive's, i should have a balance of 6.4115
276 2012-11-29 10:00:09 <abrkn> anyway to clean up this mess? i pretty much just want to stop using accounts/labels/move
277 2012-11-29 10:04:41 <sipa> abrkn: that is indeed very messed up; but if you want to stop using accounts, there is no problem really
278 2012-11-29 10:04:44 <abrkn> sipa: just not sure how to clean it up?
279 2012-11-29 10:05:00 <sipa> meh, don't
280 2012-11-29 10:05:13 <abrkn> atm i dont understand how much is in the wallet, cant send it either
281 2012-11-29 10:05:34 <sipa> getbalance will tell you how much is in the wallet
282 2012-11-29 10:05:41 <abrkn> hmm, it says zero
283 2012-11-29 10:05:46 <sipa> then you have 0 :)
284 2012-11-29 10:05:49 <abrkn> dafuq...
285 2012-11-29 10:06:04 <abrkn> going through my transactions says otherwise
286 2012-11-29 10:06:53 <abrkn> i did have issues when i upgraded from 0.6 etc, but i backed up my wallet carefully
287 2012-11-29 10:07:42 <sipa> any unconfirmed incoming transactions, or immature mining outputs?
288 2012-11-29 10:08:01 <abrkn> checking
289 2012-11-29 10:10:13 <abrkn> well, the addresses are: 1BQEwyZxBgS5MCrpF2Q5Lev5vYzDYhKuqC, 1Q6A5YyxPK34qoKyS6qoDrLfyqV2eLaXQz, 1MUEKPtnGuqfdhEgnBdYQimttj7q8xqkQ7, 1EL7TVW8wGkTkh52s63ta6sinW5vbF9jA8"
290 2012-11-29 10:10:28 <abrkn> found by listaccounts and then getaddressesbyaccount for each
291 2012-11-29 10:11:52 <abrkn> only one i see any activity on is https://blockchain.info/address/1MUEKPtnGuqfdhEgnBdYQimttj7q8xqkQ7
292 2012-11-29 10:27:26 <abrkn> ok, now i tried to dump priv key, delete wallet.dat, import priv key, still getbalance zero wtf
293 2012-11-29 11:14:58 <grondilu> Check this out guys: http://rosettacode.org/wiki/Bitcoin/address_validation#C
294 2012-11-29 11:15:26 <grondilu> Somehow the author managed to convert a base58 string into bytes without using big integers
295 2012-11-29 11:15:43 <grondilu> Did you know it was possible?
296 2012-11-29 11:15:46 <sipa> sure
297 2012-11-29 11:16:01 <grondilu> Well, I had no clue
298 2012-11-29 11:16:48 <grondilu> I still don't get how it works, actually
299 2012-11-29 11:18:27 <sipa> he is using the output buffer as a big integer essentially
300 2012-11-29 11:21:45 <wumpus> yes he just uses a hand-rolled fixed-size bigint implementation specially for this purpose
301 2012-11-29 11:23:43 <grondilu> damn I'm embarassed now. I still don't quite understand. But I'll figure it out eventually.
302 2012-11-29 11:25:21 <sipa> grondilu: in each run of the inner loop he does a (x -> 58*x+n) on the integer represented by the output buffer
303 2012-11-29 11:25:43 <sipa> wumpus: which may actually be faster than what we do...
304 2012-11-29 11:28:00 <abrkn> back, any ideas on how to fix my wallet issues? https://blockchain.info/address/1MUEKPtnGuqfdhEgnBdYQimttj7q8xqkQ7 is my address
305 2012-11-29 11:28:02 <wumpus> probably
306 2012-11-29 11:28:07 <abrkn> but when i do importprivkey i getn othing
307 2012-11-29 11:28:12 <abrkn> gettbalance still zero
308 2012-11-29 11:29:06 <wumpus> there's a pull request that speeds up the base58 encoding/decoding, but it didn't get very much interest because we're not bound by its performance anywhere
309 2012-11-29 11:29:48 <sipa> wumpus: this code is however only useful if you know the output size
310 2012-11-29 11:29:59 <sipa> which we do, actually
311 2012-11-29 11:30:57 <wumpus> indeed, if you know the input size you know the (upper bound to the) output size
312 2012-11-29 11:30:58 <grondilu> it's a nice trick anyway
313 2012-11-29 11:51:19 <t7> can anyone point me to docs explaining how light clients work? (multibit)
314 2012-11-29 11:52:38 <jeremias> it is explained in the original satoshi paper
315 2012-11-29 11:52:47 <jeremias> they keep the lightweight version of the block chain
316 2012-11-29 11:52:50 <jeremias> headers only
317 2012-11-29 11:52:56 <jeremias> but there are other models as well
318 2012-11-29 11:53:05 <jeremias> electrum doesn't keep block chain at all
319 2012-11-29 11:53:42 <jeremias> but is still pretty trustable, private keys are not stored on the server
320 2012-11-29 12:04:50 <AlbusTalpa> Hey there. Is it normal that if a transaction tx get's included in block Bn, calling "bitcoind listsinceblock Bn" doesn't show the transaction tx. However, calling "bitcoind listsinceblock Bn-1" does include the transaction tx
321 2012-11-29 12:06:45 <abrkn> sipa: i solved my wallet problem. *double facepalm* bitcoind getblockcount ---- 194888
322 2012-11-29 12:06:51 <freewil> AlbusTalpa, yes
323 2012-11-29 12:07:11 <freewil> listsinceblock only shows transactions after that block
324 2012-11-29 12:07:23 <AlbusTalpa> ok thanks
325 2012-11-29 12:28:53 <molec> hmm. bitcoin-qt 0.7.1: swapped in a wallet.dat backup and did "bitcoin-qt -rescan". It rescans, then shows all the transactions but balance BTC 0.0. any ideas?
326 2012-11-29 12:40:06 <sipa> wumpus: i mean when decoding an address, you know the output is 20 bytes eg
327 2012-11-29 12:40:53 <wumpus> yep
328 2012-11-29 12:41:09 <sipa> and an upper bound is also easily calculatable: same as the input size
329 2012-11-29 12:41:15 <sipa> (in case it's all zeroes)
330 2012-11-29 12:47:35 <t7> where are the openssl docs, the website seems incomplete
331 2012-11-29 13:05:56 <NewLiberty> If I were to send bitcoins using the regular client, but I wasn't connected to directly or indirectly to any mining nodes, and then decided that I didn't want to send those bitcoins, from a technical perspective, how would I stop my Bitcoin-QT client from trying to send that transaction?
332 2012-11-29 13:07:06 <NewLiberty> Any related information about where sent bitcoins are stored after they're sent but before the transaction is confirmed or how that process works would be helpful.
333 2012-11-29 13:10:08 <kjj> they are in the wallet
334 2012-11-29 13:12:10 <NewLiberty> I know I'm not a regular face around here, but for those of you that don't know me, I ran the first exchange, made the first financial transaction with Bitcoins and PayPal, and the first person to try to actively popularize Bitcoin.
335 2012-11-29 13:13:52 <NewLiberty> Thanks kjj. I guess I'll look into the wallet file format.
336 2012-11-29 13:17:55 <kjj> it is a BDB file. when you send a transaction, it gets recorded in there and sent to the network
337 2012-11-29 13:18:18 <kjj> from time to time, it will try to resend any unconfirmed entries in that database
338 2012-11-29 13:20:19 <NewLiberty> I've just found some Python code for accessing it, which helps.
339 2012-11-29 13:27:35 <NewLiberty> So what would happen bitcoins were sent and confirmed, but then the block chain was deleted and re-downloaded? While the block chain is catching back up, would the client try to resend those transactions if the blockchain had changed and they were no longer confirmed?
340 2012-11-29 13:32:17 <helo> i think it would send them again
341 2012-11-29 13:34:05 <helo> both before it has the block where they were confirmed (only to be ignored by peers with the tx in a block), and if the confirming block was orphaned (so they could be included in a subsequent block)
342 2012-11-29 13:38:20 <Luke-Jr> wasn't MtGox the first exchange?
343 2012-11-29 13:41:10 <stamit> the first and the last!
344 2012-11-29 13:48:05 <kjj> the node can know that it is catching up. I don't know without looking at the code whether or not it attempts to retransmit while it is behind
345 2012-11-29 13:55:32 <sipa> Luke-Jr: there was one "before our time"
346 2012-11-29 13:55:54 <sipa> NewLiberty: i believe it rebroadcasts during IBD yes
347 2012-11-29 13:56:22 <NewLiberty> What is IDB?
348 2012-11-29 13:57:17 <sipa> initial block download
349 2012-11-29 13:57:37 <sipa> the state the client is in when it knows it hasn't caught up
350 2012-11-29 13:59:03 <NewLiberty> Ok, so I think first thing I would need is a switch to enable or disable that functionality.
351 2012-11-29 14:01:03 <sipa> i think it's generally a good idea to disable that
352 2012-11-29 14:02:27 <NewLiberty> Well after the import has completed, I don't want to make the user wait to catch up to send any new transactions.
353 2012-11-29 14:03:22 <NewLiberty> Speaking of which, confirming blocks in my x86 Linux VM is dog slow. It takes like 5-10 minutes per block.
354 2012-11-29 14:03:52 <NewLiberty> If it wasn't so slow, that wouldn't be an issue.
355 2012-11-29 14:04:10 <kjj> seriously?
356 2012-11-29 14:04:32 <sipa> NewLiberty: it shouldn't be more than a second
357 2012-11-29 14:04:37 <helo> sounds like it is not doing hardware virt
358 2012-11-29 14:05:02 <sipa> it can be, if IO is virtualized
359 2012-11-29 14:05:16 <sipa> NewLiberty: 0.8 should be a lot faster in that situation
360 2012-11-29 14:05:37 <kjj> I'm running two full nodes on an 11 year old Athlon XP and it takes me at most a couple of seconds
361 2012-11-29 14:05:49 <NewLiberty> It should be hardware virtualized. I'm on a dual core 64-bit machine running VirtualBox on a Linux Host.
362 2012-11-29 14:06:05 <sipa> the CPU is likely not the problem
363 2012-11-29 14:06:33 <NewLiberty> Yeah, that what I would expect. During the halving party yesterday there was a guy on XP that was having the same problem.
364 2012-11-29 14:07:16 <NewLiberty> Anyway, I'm not too concerned about it at the moment. Just thought I'd mention it. Hopefully 0.8 will resolve it.
365 2012-11-29 14:07:17 <sipa> NewLiberty: feel free to try git head to see if it's faster, but don't use it in production yet
366 2012-11-29 14:21:49 <silur> Hello
367 2012-11-29 14:22:03 <silur> Q: What the best way to withdraw cash (CAD -> to bank) from MtGox if you're Canadian (in terms of minimizing fees)?
368 2012-11-29 14:22:40 <helo> ripple to be implemented using a blockchain: https://groups.google.com/forum/?fromgroups=#!topic/rippleusers/IVin3Qwrp7k
369 2012-11-29 14:23:09 <helo> "with a novel miner-less consensus mechanism that allows proof of stake
370 2012-11-29 14:23:20 <helo> errr messed that paste up...
371 2012-11-29 14:23:54 <helo> "with a novel miner-less consensus mechanism that allows transactions to be confirmed nearly instantaneously." <--- i guess this is not proof of stake...
372 2012-11-29 14:25:55 <sipa> helo: they fail to mention one name; iirc justmoon is working for them now :)
373 2012-11-29 14:26:08 <Eliel> helo: considering it's Ripple, even Proof of Stake would make no sense.
374 2012-11-29 14:26:59 <Eliel> proof of work would in some ways though.
375 2012-11-29 14:27:23 <Eliel> I expect it probably makes use of the trust-network that Ripple requires to operate anyway.
376 2012-11-29 14:28:56 <helo> yeah... i don't know anything about ripple
377 2012-11-29 14:31:35 <NewLiberty> Here's a link to my just-now-posted announcement of an alternative block chain. https://bitcointalk.org/index.php?topic=128370.0
378 2012-11-29 14:32:17 <Eliel> quite different from Bitcoin. First of all, it can't really create it's own unit of exchange as it's a debt based system. Instead it'll use whatever units the users want to use.
379 2012-11-29 14:32:35 <Eliel> although, well, it's certainly possible to implement without support for multiple currencies.
380 2012-11-29 14:57:31 <maaku> helo: it's proof of activity, maybe
381 2012-11-29 14:57:55 <maaku> we won't know until they post the protocol :\\
382 2012-11-29 15:24:49 <etotheipi_> sipa: I think there's plenty of cases where you can try multiple available options for colliding fingerprints but (1) It's a lot of extra complexity to handle such a corner case (2) I'm concerned that there will be use cases that will have complete roadblocks in them, because you don't have unique IDs... perhaps some system where you're trying to link an address to a grandparent and you don't know the path from grandparent to ch
383 2012-11-29 15:25:50 <etotheipi_> sipa: I don't have any good examples of use cases where it would really hinder you, but it wouldn't surprise me if they cropped up
384 2012-11-29 15:26:04 <etotheipi_> but I recognize 4 bytes is preferable, and with our current foresight, it's not a bad decision
385 2012-11-29 15:29:24 <TD> good afternoon
386 2012-11-29 15:34:31 <sipa> etotheipi_: sure you have a unique id: the hash160 of the pubkey
387 2012-11-29 15:35:01 <sipa> etotheipi_: that doesn't mean you need the full id of the parent in each serialized chain
388 2012-11-29 15:35:11 <etotheipi_> sipa: duh
389 2012-11-29 15:35:14 <sipa> it's more of a checksum
390 2012-11-29 15:35:21 <etotheipi_> if I want a unique ID, I just use the hash160
391 2012-11-29 15:35:34 <etotheipi_> okay, I'm happy
392 2012-11-29 15:35:36 <etotheipi_> :)
393 2012-11-29 15:37:01 <sipa> etotheipi_: also, what do you think about cascasius' proposal to use 4 version bytes to make them more visually appealing?
394 2012-11-29 15:37:12 <etotheipi_> then, I will probably store fingerprints, but link things together with the hash160 values instead... I don't care about wasting an extra 16 bytes per address -- wallet files are already small, and the reduced complexity is worth it to me
395 2012-11-29 15:37:14 <sipa> etotheipi_: i consider it low priority, but i like it
396 2012-11-29 15:37:33 <sipa> etotheipi_: internally i will defintely use 20-byte fingerprints
397 2012-11-29 15:37:49 <etotheipi_> sipa: I kind of like the prefixes
398 2012-11-29 15:38:30 <sipa> that's a yes?
399 2012-11-29 15:38:34 <etotheipi_> it's a shame we can't pick a prefix that will automatically be converted to "xprv" and "xpub" when converted to Base58 :)
400 2012-11-29 15:38:58 <sipa> ?
401 2012-11-29 15:39:00 <etotheipi_> unless we put it at the end
402 2012-11-29 15:39:05 <sipa> ??
403 2012-11-29 15:40:20 <etotheipi_> he suggested to add 4 byte prefix to the pub or priv key for consistency, and those 4 bytes would be ASCII for xpub or xprv, right?
404 2012-11-29 15:41:04 <sipa> no
405 2012-11-29 15:41:09 <etotheipi_> maybe I should go re-read what he said
406 2012-11-29 15:41:45 <sipa> just 4 bytes prefixed to the serialized format, which result in a base58 form starting with xprv or xpub
407 2012-11-29 15:42:06 <etotheipi_> how do you know it's going to come out as xprv or xpub
408 2012-11-29 15:42:07 <etotheipi_> ?
409 2012-11-29 15:42:26 <sipa> math?
410 2012-11-29 15:42:31 <etotheipi_> lol
411 2012-11-29 15:43:16 <etotheipi_> what I'm saying is, you need an exact multiple of 58 bits on the key in order to guarantee the top 4 base58 chars are consistent, otherwise bits from the ke yget bundled into the prefix
412 2012-11-29 15:43:21 <etotheipi_> or am I missing something?
413 2012-11-29 15:44:01 <sipa> you know the range of numbers (in base 256) that are possible when you know length and prefix
414 2012-11-29 15:44:29 <sipa> if both edges of that range map to a base58 form you want, everything in between will too
415 2012-11-29 15:44:49 <etotheipi_> oooh, I see
416 2012-11-29 15:45:05 <sipa> actually, i think 3 bytes should be enough for 4 base58 chars
417 2012-11-29 15:45:07 <etotheipi_> I had just implicitly assumed that wasn't reasonable
418 2012-11-29 15:45:13 <etotheipi_> *feasible
419 2012-11-29 15:45:16 <etotheipi_> I don't know why
420 2012-11-29 15:45:32 <etotheipi_> okay, so yeah, I really like it
421 2012-11-29 15:45:59 <etotheipi_> sorry, sometimes my brain starts walking down a particular [sometimes irrational] path and can't find its way back :)
422 2012-11-29 15:48:04 <jm9000> Has there been any discussion on creating a visual finger print representation of a bitcoin address? Similar to a visual SSH fingerprint, or identicons. The point of this would be to make it easy to distinguish at a glance if it has been typed in wrong or tampered with. Probably not so useful in the current implementation, but it would become more useful if mobile bitcoin devices became
423 2012-11-29 15:48:13 <etotheipi_> sipa: so what's the downside? besides slightly-longer encodings of public and private keys which I am already okay with?
424 2012-11-29 15:48:49 <sipa> jm9000: i think any solution where humans have to verify raw addresses is flawed
425 2012-11-29 15:49:12 <t7> any old image hash will work on a btc addres
426 2012-11-29 15:49:13 <sipa> jm9000: right now, nothih better exists, but hopefully that will change soon with a payment protocol
427 2012-11-29 15:49:30 <sipa> etotheipi_: indeed
428 2012-11-29 15:50:45 <sipa> i feel like a hypocrit... on one hand i'm advocating changing a format to make it look better, and on the other i'm saying humans shouldn't see them anyway :)
429 2012-11-29 15:51:03 <swulf--> I know this is bitcoin-related development, but is it an appropriate place to talk about non-core bitcoind dev? I've put up a new site and I'd love to get a few people to try it and give feedback
430 2012-11-29 15:51:15 <swulf--> s/this/this place
431 2012-11-29 15:51:32 <etotheipi_> sipa: I was *just* about to make a comment about that :)
432 2012-11-29 15:52:11 <sipa> etotheipi_: but i guess we're targetting power users here anyway... and exchanging chains won't be done in a payment protocol
433 2012-11-29 15:53:36 <etotheipi_> sipa: that's essentially what Armory's niche is.... those Bitcoin DIY'ers who want full control over their coins (though the payment protocol could be part of that if they get themselves a CA-signed cert)
434 2012-11-29 15:54:39 <sipa> you could always exchange payment-protocol-files by hand without signing, imho
435 2012-11-29 15:54:40 <TD> swulf--: i guess if it's bitcoin and dev related, it's appropriate for #bitcoin-dev
436 2012-11-29 15:54:47 <TD> swulf--: we discuss non-satoshi codebases all the time
437 2012-11-29 15:55:06 <swulf--> well, would something like satoshidice.com be a topic suited for this chan?
438 2012-11-29 15:55:49 <etotheipi_> swulf--: do first, ask for forgiveness later... it's a lot smoother :) If you sound off-topic, someone will suggest a better channel for you
439 2012-11-29 15:55:57 <TD> sure
440 2012-11-29 15:56:33 <swulf--> ok: I've been working on a gambling/gaming bitcoin site over the past week and I'm looking for a few brave souls willing to spend a few mins to test and give feedback:)
441 2012-11-29 15:57:32 <sipa> imho that's better on #bitcoin, but if you're looking how to integrate with the bitcoin system, maybe here
442 2012-11-29 15:58:38 <swulf--> at this point, all the tech things are figured out, so you're probably right its a more suitable topic for #bitcoin. thanks:)
443 2012-11-29 16:04:29 <Luke-Jr> swulf--: satoshidice is considered a DDoS attack against Bitcoin
444 2012-11-29 16:04:36 <swulf--> by some, sure
445 2012-11-29 16:04:55 <TD> hah
446 2012-11-29 16:05:04 <TD> it's a reminder that we need to scale, that's all
447 2012-11-29 16:05:16 <zeiris> So what percentage of the blockchain is satoshidice right now?
448 2012-11-29 16:05:17 <BlueMatt> if you are gonna do a sd-like site, there are ways that are "better" for the network that you should try to ensure you implement
449 2012-11-29 16:05:18 <Luke-Jr> TD: nobody could handle the load SatoshiDice demands
450 2012-11-29 16:05:19 <swulf--> and the people playing are willingly paying tx fees, so..
451 2012-11-29 16:05:38 <Luke-Jr> swulf--: it doesn't work like that
452 2012-11-29 16:05:38 <zeiris> And how long until the entire bitcoin network collapses under the weight of the block chain, as users can't practically keep the thing around?
453 2012-11-29 16:05:40 <swulf--> blue: my site isn't based on transactions, but it is gambling
454 2012-11-29 16:06:03 <Luke-Jr> swulf--: those fees don't cover the expenses, they're only there to deter DoS attacks; SatoshiDice is using gamblers' addictions to bypass that DoS-deterrant
455 2012-11-29 16:06:05 <BlueMatt> swulf--: ok, I hadnt been reading, just thought Id make sure to point it out
456 2012-11-29 16:06:25 <swulf--> Right. SatoshiDice is exploiting gamblers.
457 2012-11-29 16:06:41 <Luke-Jr> and Bitcoin
458 2012-11-29 16:06:44 <TD> nobody?
459 2012-11-29 16:06:51 <TD> sd is doing like 1 tx per 2 seconds or something like that
460 2012-11-29 16:07:24 <TD> sipa: what's the next step for ultraprune? database conversion?
461 2012-11-29 16:07:29 <Luke-Jr> TD: SD is doing 1 tx per action.
462 2012-11-29 16:07:35 <BlueMatt> Id argue bitcoin is handling sd load pretty well, its just more load than we would prefer to have with the system in its current state
463 2012-11-29 16:07:37 <swulf--> bitcoin network needs to be able to handle 1000x the traffic if it expects to be anything greater than this
464 2012-11-29 16:07:43 <gmaxwell> no, two per action.
465 2012-11-29 16:07:45 <Luke-Jr> TD: that'd be like walmart processing each can of soda pop as a separate transaction
466 2012-11-29 16:07:51 <Luke-Jr> right, two
467 2012-11-29 16:07:59 <gmaxwell> But this is really offtopic here now.
468 2012-11-29 16:08:15 <BlueMatt> swulf--: and it will, but...yea, this discussion has happened here so many times, let not get into it again :)
469 2012-11-29 16:08:19 <Luke-Jr> swulf--: 1000x more users can handle 1000x the traffic.
470 2012-11-29 16:08:28 <Luke-Jr> (also 1000x more development time, etc)
471 2012-11-29 16:08:30 <swulf--> also, downloading 5GB blockchain is a huge deterrant at this point for newcomers
472 2012-11-29 16:08:52 <zeiris> Have there been any practical (ie safe) solutions to trimming the blockchain in the last few months?
473 2012-11-29 16:09:04 <BlueMatt> yes
474 2012-11-29 16:09:12 <BlueMatt> actually, a lot
475 2012-11-29 16:09:18 <zeiris> Any good starting points for reading about 'em? :)
476 2012-11-29 16:09:20 <gmaxwell> swulf--: 5GB is really small, I think most modern commercial games are now larger than that. And there is no reason that it has to be a blocker in front of new users.
477 2012-11-29 16:09:35 <Luke-Jr> but in practice, Bitcoin will suffer if people are trimming the blockchain too much at this point
478 2012-11-29 16:09:40 <swulf--> gmax: and most modern commercial games aren't downloaded. they're still purchased in stores
479 2012-11-29 16:09:46 <Luke-Jr> because there aren't enough peers
480 2012-11-29 16:10:02 <gmaxwell> swulf--: so? go buy your bitcoin client in a store then? :P
481 2012-11-29 16:10:06 <zeiris> I think the issue with 5GB was that, last I checked, it was a really non-linear download that thrashed your hard drive. The challenge was getting the thing onto your harddrive and packed in the right format, not 5GB of traffic. That's trivial now.
482 2012-11-29 16:10:37 <swulf--> gmaxwell: not-sure-if-serious.jpg
483 2012-11-29 16:10:40 <sipa> zeiris: that's being solved
484 2012-11-29 16:10:45 <zeiris> Ooh!
485 2012-11-29 16:10:48 <gmaxwell> zeiris: the newest software (not yet released) can fully sync in an hour or two.
486 2012-11-29 16:10:50 <Luke-Jr> zeiris: ultraprune in theory speeds up the processing and IO
487 2012-11-29 16:11:15 <sipa> Luke-Jr: was practice different for you?
488 2012-11-29 16:11:25 <Luke-Jr> sipa: in practice, I can't get it to sync period :P
489 2012-11-29 16:11:26 <swulf--> I synced the whole blockchain a few weeks ago and it was pretty brutal to disk usage
490 2012-11-29 16:11:39 <TD> yeah. the code in git master is a lot better at that
491 2012-11-29 16:11:47 <Luke-Jr> still stuck with sipa: bitcoind: main.cpp:1457: bool CBlock::DisconnectBlock(CBlockIndex*, CCoinsViewCache&): Assertion `blockUndo.vtxundo.size() + 1 == vtx.size()' failed.
492 2012-11-29 16:11:48 <TD> and it lays the foundation for deletion of old data (by some nodes)
493 2012-11-29 16:11:57 <swulf--> TD: cool. new version is desperately wanted then
494 2012-11-29 16:12:07 <gmaxwell> well, 'some foundation' at least.
495 2012-11-29 16:12:12 <TD> yeah, well, we all want it out ASAP. unfortunately now sipa has a job :) so, things are going a bit slower
496 2012-11-29 16:12:23 <swulf--> no worries. it'll come when its ready
497 2012-11-29 16:12:24 <swulf--> later guys. dinner calls:)
498 2012-11-29 16:12:32 <gmaxwell> swulf--: then get in and start testing the new stuff (preferably on testnet and mainnet with wallets where you're not worried about losing coin)
499 2012-11-29 16:12:53 <gmaxwell> swulf--: it'll never be ready if everyone who wants it says "it'll come when its ready". :P
500 2012-11-29 16:13:30 <Luke-Jr> hmm, I wonder if jgarzik is around? :>
501 2012-11-29 16:14:03 <sipa> Luke-Jr: is that a clean sync from scratch?
502 2012-11-29 16:14:14 <Luke-Jr> sipa: -reindex from scratch
503 2012-11-29 16:14:40 <sipa> Luke-Jr: ok, whatever your block files contain, that is a bug then
504 2012-11-29 16:14:46 <helo> ACTION decides to do a full network sync
505 2012-11-29 16:14:59 <helo> -loadblocks has been taking 2.3 hours or so
506 2012-11-29 16:15:14 <sipa> Luke-Jr: anything special like read-only files or hardlinks?
507 2012-11-29 16:15:22 <Luke-Jr> sipa: I gave up on those, so no.
508 2012-11-29 16:16:01 <sipa> TD: next step is indeed auto-upgrade, but i've been working on bug reports mostly
509 2012-11-29 16:16:28 <sipa> Luke-Jr: just to be sure: no test_bitcoin executed since -reindex was started?
510 2012-11-29 16:16:37 <TD> wt
511 2012-11-29 16:16:38 <TD> wt
512 2012-11-29 16:16:41 <Luke-Jr> sipa: correct, I avoided test_bitcoin running
513 2012-11-29 16:16:42 <TD> argh i hate this keyboard
514 2012-11-29 16:16:43 <TD> i wanted to say
515 2012-11-29 16:16:44 <TD> WTF
516 2012-11-29 16:16:51 <TD> why does there not seem to be a free Qt SDK download anymore?
517 2012-11-29 16:17:36 <sipa> Luke-Jr: can you put your blk*.dat files online somewhere, or is it too much?
518 2012-11-29 16:18:07 <Luke-Jr> yeah, probably??? tempting to write some kind of script to "compress" it by using block hashes :P
519 2012-11-29 16:19:43 <Luke-Jr> sipa: first I'll do one more verify of the problem from a clean ~/.bitcoin
520 2012-11-29 16:20:09 <sipa> i got 4 times a failed build/test from pulltester yesterday on #2049, and it seems it has given up on my pull now :(
521 2012-11-29 16:22:02 <TD> ah it's at a different site
522 2012-11-29 16:33:44 <jgarzik> Luke-Jr: ?
523 2012-11-29 16:36:21 <Luke-Jr> jgarzik: do you know of any reason why one would want to software-RAID-1 across two partitions on the same hard disk?
524 2012-11-29 16:36:45 <jgarzik> <shrug> I suppose it would guard against some sectors dying and not others
525 2012-11-29 16:36:58 <jgarzik> but seems largely pointless
526 2012-11-29 16:37:21 <Luke-Jr> yeah, that's what I thought :/
527 2012-11-29 16:37:36 <Luke-Jr> I think I'm going to blow away WD's setup and just stick Gentoo or Debian on this thing
528 2012-11-29 16:38:09 <gmaxwell> Luke-Jr: well failing _sectors_ seem to have become more common as disks have become larger.
529 2012-11-29 16:40:07 <jgarzik> Modern disks have spare sectors, too. You can usually fix a bad sector these days by writing zeroes to it. That will trigger replacement of a bad sector.
530 2012-11-29 16:40:49 <jgarzik> i.e. in this scenario, mark RAID1 partition bad, un-add RAID1 partition, re-add.
531 2012-11-29 16:41:05 <jgarzik> resync from the good half should reinit the data
532 2012-11-29 16:50:08 <Luke-Jr> hmm, not sure I'm worried about sector failure for WD's firmware data more than I would be for my actual files
533 2012-11-29 16:51:14 <jgarzik> wosh
534 2012-11-29 16:51:16 <jgarzik> woah
535 2012-11-29 16:51:23 <jgarzik> one backbone node, running HEAD, crashed
536 2012-11-29 16:51:26 <midnightmagic> Just fwiw, since I'm probably lost in the scrollback. I disagree with pull request 1980, but only because as I understand it, it doesn't reorg to same-work trees that are submitted locally by a miner. Unless I'm misunderstanding, 1980 isn't good for miners. :(
537 2012-11-29 16:51:41 <jgarzik> ************************
538 2012-11-29 16:52:22 <midnightmagic> Luke-Jr: perhaps it's not two partitions of the same physical hard disk?
539 2012-11-29 16:52:47 <Luke-Jr> midnightmagic: this is a single 3 TB drive NAS
540 2012-11-29 16:53:07 <gmaxwell> midnightmagic: don't be daft please. 1980 fixes a bug introduced by ultraprune which would significantly hurt network convergance an increase the risk for double spending.
541 2012-11-29 16:53:29 <Luke-Jr> sipa: confirmed clean datadir has this problem, will put blk files somewhere
542 2012-11-29 16:53:53 <midnightmagic> gmaxwell: That's why I said "but". This change ignores locally-solved solutions that are same-height stales, correct?
543 2012-11-29 16:54:01 <gmaxwell> midnightmagic: if you wanted to reorg for your own blocks??? meh. it's such a small difference, and hard to make workable as soon as you have more than one bitcoind.
544 2012-11-29 16:54:06 <gmaxwell> midnightmagic: which is what bitcoin has always done.
545 2012-11-29 16:54:07 <jgarzik> midnightmagic: ...and that is a correct behavior
546 2012-11-29 16:55:05 <Luke-Jr> midnightmagic: as much as I hate to lose a block, the classical "never reorg to same height or backward" rule works out nicely
547 2012-11-29 16:55:09 <midnightmagic> gmaxwell: You really gotta work on the name-calling thing..
548 2012-11-29 16:55:24 <midnightmagic> :-/
549 2012-11-29 16:56:40 <gmaxwell> midnightmagic: ... You're opposing fixing a newly introduced bug that risks network convergence. This is a clear sign of required coffee intake. I get to say you're being daft.
550 2012-11-29 16:56:53 <gmaxwell> :P
551 2012-11-29 16:57:23 <D34TH> gmaxwell, bugs are just undocumented features
552 2012-11-29 16:58:59 <jgarzik> other two exmulti backbone nodes still up
553 2012-11-29 16:59:04 <jgarzik> just us2 died
554 2012-11-29 17:02:40 <midnightmagic> gmaxwell: No I'm not.
555 2012-11-29 17:04:02 <jgarzik> OK, time to upgrade backbone from 0.7.1-ish to 0.8/HEAD
556 2012-11-29 17:04:10 <jgarzik> let's see what new crashes HEAD will bring
557 2012-11-29 17:04:24 <Luke-Jr> jgarzik: good luck >_<
558 2012-11-29 17:04:44 <jgarzik> even though it's mainnet, I'll set a core on mining long-term
559 2012-11-29 17:04:49 <jgarzik> should increase possibility of catching bugs
560 2012-11-29 17:07:07 <gavinandresen> jgarzik: would you be willing to setup and run a VM on the dev team machine as another backbone (and/or maybe permanent testnet) node?
561 2012-11-29 17:08:22 <jgarzik> gavinandresen: is that in addition to other nodes already running on that machine? it seems not much use to run multiple mainnet and testnet nodes on there.
562 2012-11-29 17:08:48 <gavinandresen> jgarzik: right now it is just running jenkins.
563 2012-11-29 17:09:06 <etotheipi_> are non M-of-N transactions considered isStandard? i.e. ((A and B) or C)? If I create a P2SH script using ((A and B) or C), it will be propagated normally because no one knows, but the redemption script will be non-std...?
564 2012-11-29 17:09:13 <midnightmagic> gmaxwell: lol Well, don't get all bent out of shape when I start calling you daft. I would like to point out that name-calling tends to entrench people, especially when they've already requested clarification.
565 2012-11-29 17:09:29 <midnightmagic> So no, name-calling is never called-for.
566 2012-11-29 17:09:32 <etotheipi_> (and require a miner to agree to accept the redemption script)
567 2012-11-29 17:09:32 <jgarzik> gavinandresen: in that case, I would be willing yes. B.F. needs to run nodes
568 2012-11-29 17:09:37 <midnightmagic> ya douche.
569 2012-11-29 17:09:38 <gavinandresen> etotheipi_: no. Standard scripts are CHECKSIG, CHECKMULTISIG, and DUP HASH160 <> EQUALVERIFY CHECKSIG
570 2012-11-29 17:09:39 <jgarzik> gavinandresen: ideally, it should run nodes on multiple networks
571 2012-11-29 17:09:39 <sipa> midnightmagic: you may argue that we should favor locally produced blocks, but the current situation is just a violation of the network rules
572 2012-11-29 17:09:46 <sipa> midnightmagic: #1980 is a bug fix
573 2012-11-29 17:10:13 <midnightmagic> sipa: And I'm running it in my miners due to the fact it's a bugfix, and I agree with the general-case.
574 2012-11-29 17:10:23 <midnightmagic> sipa: fwiw. (:P gmaxwell)
575 2012-11-29 17:10:29 <gavinandresen> jgarzik: we've got the budget to buy more physical machines, if you want to spearhead that project....
576 2012-11-29 17:10:29 <sipa> midnightmagic: it's just restoring the pre-ultraprune behaviour
577 2012-11-29 17:10:42 <etotheipi_> gavinandresen: so it is correct that if you made a P2SH script with non-std type, you'd have to find a miner to help you redeem it
578 2012-11-29 17:10:48 <gavinandresen> etotheipi_: yes
579 2012-11-29 17:11:03 <gavinandresen> etotheipi_: you'd have no trouble funding it, though
580 2012-11-29 17:11:10 <etotheipi_> gavinandresen: I'm not requesting it, but I'm curious if we have any intention to make those standard
581 2012-11-29 17:11:14 <jgarzik> gavinandresen: It would mainly be a cost comparison between physical and VPS
582 2012-11-29 17:11:35 <jgarzik> gavinandresen: if we can get more nodes for the dollar, running VPS's, that might be the way to go.
583 2012-11-29 17:11:45 <gavinandresen> jgarzik: ok. Wanna be the person to make that happen?
584 2012-11-29 17:11:53 <sipa> BlueMatt: any idea what pulltester gave up trying #2049?
585 2012-11-29 17:11:57 <jgarzik> gavinandresen: if the goal (mine is) is to have as many wallet-free nodes as possible
586 2012-11-29 17:12:02 <etotheipi_> gavinandresen: mainly I'm wondering if I should build them into my wallet design now, or simply leave room to do it later
587 2012-11-29 17:12:12 <jgarzik> gavinandresen: I don't mind the responsibility... but probably won't have time for a week or two
588 2012-11-29 17:12:35 <jgarzik> gavinandresen: and I can definitely work on getting main/test nodes on the monster
589 2012-11-29 17:13:04 <midnightmagic> sipa: I agree with the bugfix, especially if it restored pre-ultraprune behaviour. This was the genesis of my confusion, that I wasn't clear on pre-bugfix behaviour. Then I alter my position: I would *like* to favour local blocks, but only because of the long-term lottery-like benefits as bitcoin value increases over time and this issue is buried.
590 2012-11-29 17:13:05 <gavinandresen> jgarzik: great, talk with Matt, he setup the VM host stuff
591 2012-11-29 17:13:14 <jgarzik> gavinandresen: will do
592 2012-11-29 17:13:19 <jgarzik> backbone project++
593 2012-11-29 17:13:23 <gavinandresen> amen!
594 2012-11-29 17:13:27 <midnightmagic> sipa: Would you object to a softly-worded feature request for posterity?
595 2012-11-29 17:13:43 <gmaxwell> midnightmagic: do you have logs from here from about 13 months ago?
596 2012-11-29 17:13:49 <midnightmagic> gmaxwell: Yes.
597 2012-11-29 17:13:56 <gmaxwell> midnightmagic: there was a long discussion about this around then.
598 2012-11-29 17:14:02 <Luke-Jr> gavinandresen: don't suppose we have the budget to hire sipa away from his new job? :P
599 2012-11-29 17:14:20 <gavinandresen> Luke-Jr: not yet... need a few more Platinum members
600 2012-11-29 17:15:27 <gmaxwell> midnightmagic: My recollection of it was that it seemed not to be a worthwhile thing considering the increased bug exposure, because that the probablity of it mattering quite low, it favors hashpower consolidation (making the mistaken belief that bigger pools get an unfair advantage actually true), and because it stops helping as soon as you're mining on more than one bitcoind.
601 2012-11-29 17:16:06 <jgarzik> gavinandresen: This is a personal question and feel free not to answer: are you personally secure yet, vis a vis B.F. salary? Are you funded for at least a year?
602 2012-11-29 17:16:37 <Luke-Jr> sipa: http://eligius.st/~luke-jr/blk00000.dat.xz
603 2012-11-29 17:16:45 <midnightmagic> gmaxwell: I don't suppose there's evidence tycho is favouring his own blocks is there?
604 2012-11-29 17:16:53 <gmaxwell> midnightmagic: the opposite, in fact.
605 2012-11-29 17:17:11 <sipa> Luke-Jr: i'll download it tonight
606 2012-11-29 17:17:12 <Luke-Jr> midnightmagic: Tycho has produced competing blocks even :P
607 2012-11-29 17:17:19 <gmaxwell> he's actually managed to issue getworks on competing forks.
608 2012-11-29 17:17:20 <midnightmagic> gmaxwell: It was all set to be surprised. Tycho being so reluctant to alter the base bitcoind behaviour from satoshi's original stuff for so long..
609 2012-11-29 17:17:35 <midnightmagic> it/I
610 2012-11-29 17:18:04 <gavinandresen> jgarzik: yes, the Foundation has started paying me a "good enough" salary (hopefully to be increased closer to my fair market value as membership/funding/bitcoin prices allow...)
611 2012-11-29 17:18:06 <gmaxwell> (something that should be hard to accomplish without modifying things or at least having partitioning between your own nodes!)
612 2012-11-29 17:18:39 <midnightmagic> ACTION pipes down.
613 2012-11-29 17:18:40 <midnightmagic> thanks.
614 2012-11-29 17:18:46 <jgarzik> gavinandresen: good deal
615 2012-11-29 17:19:04 <jgarzik> ACTION starts bringing up us2.exmulti.net (crashed backbone node) on 0.8/HEAD
616 2012-11-29 17:19:12 <jgarzik> look at that fast syncing, whee
617 2012-11-29 17:19:18 <D34TH> whee
618 2012-11-29 17:19:26 <zeiris> Awesome!
619 2012-11-29 17:19:33 <D34TH> ACTION waves his hands in the air like he just don't care
620 2012-11-29 17:19:47 <midnightmagic> to all of you: THANK YOU for the super-fast sync'ing stuff in HEAD. you really saved me a pile of time.
621 2012-11-29 17:20:08 <midnightmagic> like weeks of combined machine time..
622 2012-11-29 17:20:41 <gavinandresen> lunch time...
623 2012-11-29 17:20:59 <gmaxwell> midnightmagic: are you still getting periodic corruption?
624 2012-11-29 17:21:04 <jgarzik> gangnam time...
625 2012-11-29 17:22:14 <jgarzik> I am concerned about a few reports w/ leveldb along the lines of "my machine crashed, now program won't come back up"
626 2012-11-29 17:22:19 <midnightmagic> gmaxwell: Not anymore. I believe it was FS structural corruption. I moved the main mining bitcoind off the problematic machines and and waiting now. I'm running two different versions, one leveldb (just HEAD from github), and one next-test, for my mining p2pool+bitcoind.
627 2012-11-29 17:22:27 <jgarzik> i.e. crash not necessarily bitcoin's fault
628 2012-11-29 17:22:33 <jgarzik> but bitcoin failed to recover afterwards
629 2012-11-29 17:23:24 <midnightmagic> gmaxwell: I also did a full reinstall of that machine. I'm almost of the opinion that the mining activities makes kernel lose interrupts, but.. of course it's such a far-fetched possibility I've never really attempted to pursue it. that and I'm super lazy.
630 2012-11-29 17:24:00 <midnightmagic> doesn't seem to be anything wrong with the physical disk..
631 2012-11-29 17:24:33 <BlueMatt> sipa: did you delete the comment on the pull req?
632 2012-11-29 17:25:09 <BlueMatt> sipa: anyway, test log is at http://jenkins.bluematt.me/pull-tester/7b3b6b85a86c85dab4ad3c1093fe0e48f4853d31/test.log (thats just the commit id of the head of the pull branch)
633 2012-11-29 17:25:17 <BlueMatt> error is:
634 2012-11-29 17:25:18 <BlueMatt> test/test_bitcoin.cpp: In constructor 'TestingSetup::TestingSetup()':
635 2012-11-29 17:25:45 <sipa> BlueMatt: that's the last failed one, but after that i updated again
636 2012-11-29 17:25:55 <sipa> (i think)
637 2012-11-29 17:25:56 <BlueMatt> thats the commit id github shows as head?
638 2012-11-29 17:26:07 <BlueMatt> github lag?
639 2012-11-29 17:26:07 <sipa> oh, then i was just too tired and forgot to push :D
640 2012-11-29 17:26:17 <sipa> no, it was yesterday evening
641 2012-11-29 17:26:29 <BlueMatt> ah, ok
642 2012-11-29 17:27:00 <sipa> jgarzik: i'm generally concerned about the quality of the windows port
643 2012-11-29 17:27:26 <sipa> jgarzik: reports like it using a gig of RAM and slowing down and crashing... seems like a leak
644 2012-11-29 17:28:55 <sipa> jgarzik: on my own system i haven't been able to corrupt the leveldb ever
645 2012-11-29 17:29:12 <D34TH> sweet i got midstatec compiled on windows for mingw32
646 2012-11-29 17:30:34 <jgarzik> sipa: rofl we'll wind up implementing our own db at this rate
647 2012-11-29 17:31:15 <sipa> jgarzik: note that i made some small modifications myself to the win port, as it was not compatible with pre-c11xx gcc
648 2012-11-29 17:35:53 <jgarzik> yeah saw at least one report about gig of ram & crashing
649 2012-11-29 17:36:04 <jgarzik> WTH would it use so much ram?
650 2012-11-29 17:36:45 <sipa> ... leak
651 2012-11-29 17:41:40 <D34TH> i've not seen it use more than 300mb ram
652 2012-11-29 17:41:48 <D34TH> and i have the most problematic system every
653 2012-11-29 17:42:11 <D34TH> since i switched to head all my problems go away if i even have one
654 2012-11-29 17:43:00 <sipa> midnightmagic: thanks, by the way :)
655 2012-11-29 17:49:07 <D34TH> woohoo i got stratum mining proxy working on windows
656 2012-11-29 17:49:09 <D34TH> i am champion
657 2012-11-29 17:49:15 <D34TH> time to propose changes to slush
658 2012-11-29 17:49:34 <midnightmagic> sipa: what for?
659 2012-11-29 17:49:48 <sipa> 19:19:46 < midnightmagic> to all of you: THANK YOU for the super-fast sync'ing stuff in HEAD. you really saved me a pile of time
660 2012-11-29 17:50:15 <midnightmagic> oh, y/w, it's kicking some serious butt over here.
661 2012-11-29 17:50:26 <sipa> still some rough spots :)
662 2012-11-29 17:50:40 <midnightmagic> well i don't mind mining on HEAD, I'll take the risk.
663 2012-11-29 17:51:06 <sipa> i'm sure you (and several others, myself included) don't mind the personal risk
664 2012-11-29 17:51:27 <sipa> but if a significant portion of the mining power was on HEAD, and there was a forking bug...
665 2012-11-29 17:53:11 <midnightmagic> I'm going to eat my words in about 4 months, probably, but while I would never do something on purpose to generate problems on non-testnet, if it happened despite best-efforts I would be excited.
666 2012-11-29 18:04:19 <MC1984> hey gentlemen
667 2012-11-29 18:04:27 <MC1984> how is 0.8 going
668 2012-11-29 18:05:35 <D34TH> jgarzik, writing up a batch commit for picocoin
669 2012-11-29 18:10:24 <werlitz> was bangdb ever considered over leveldb? from these benchmarks it looks like it has superior performance: http://highscalability.com/blog/2012/11/29/performance-data-for-leveldb-berkley-db-and-bangdb-for-rando.html
670 2012-11-29 18:22:46 <sipa> werlitz: no; haven't heard about it before
671 2012-11-29 18:31:09 <jgarzik> D34TH: go for it
672 2012-11-29 18:31:21 <D34TH> it's being naughty but im trying
673 2012-11-29 18:32:20 <D34TH> poll.h is a massive blockade i don't want to dig into
674 2012-11-29 18:38:24 <jgarzik> D34TH: picocoin already requires libevent, so poll could be replaced with that
675 2012-11-29 18:39:05 <jgarzik> D34TH: and fork() usage could be replaced with thread, for Windows only
676 2012-11-29 18:39:25 <jgarzik> I'm fine with Win-specific code, where it is impossible to find an easy cross-platform solution
677 2012-11-29 18:39:39 <D34TH> i've also replaced your define win32
678 2012-11-29 18:39:44 <D34TH> with __MINGW__
679 2012-11-29 18:39:45 <D34TH> :D
680 2012-11-29 19:29:29 <jgarzik> wonder if it's time to do another checkpoint
681 2012-11-29 19:29:46 <jgarzik> ACTION leans towards "checkpoint right before 0.8rc1"
682 2012-11-29 19:30:06 <jgarzik> ACTION needs to redo the torrent for the max-file-size problem in 0.7
683 2012-11-29 19:30:36 <gmaxwell> I'd missed this problem?
684 2012-11-29 19:33:39 <TD> gavinandresen: do you have any plans to acquire an apple signing cert?
685 2012-11-29 19:34:35 <gavinandresen> TD: thanks for the reminder, I'll ask Patrick if there has been progress on the Foundation getting a DUNS number (I want the Foundation to be the legal entity behind the signing cert)
686 2012-11-29 19:34:47 <TD> ah yes
687 2012-11-29 19:34:48 <sipa> jgarzik: 210000 is a nice checkpoint candidate, imho :)
688 2012-11-29 19:34:58 <TD> the DUNS numbe
689 2012-11-29 19:35:50 <sipa> we could add a temporary one now a few 1000 blocks back, and replace it for 0.8
690 2012-11-29 19:36:28 <BlueMatt> or, since its just master and we arent releasing it, we could just checkpoint 210000 and not release right away
691 2012-11-29 19:36:34 <BlueMatt> (or are we talking about an rc?)
692 2012-11-29 19:36:44 <BlueMatt> (ie do I need to kick my ass in gear re: bloom filters)
693 2012-11-29 19:38:36 <sipa> given that syncing from scratch from disk takes 15 minutes to het to 193k, and 2 hours or so for the rest...
694 2012-11-29 19:38:44 <sipa> ... we need parallel sig check
695 2012-11-29 19:39:03 <BlueMatt> hey, bitcoinj actually has something that bitcoind doesnt for full verification :)
696 2012-11-29 19:39:13 <sipa> hehe
697 2012-11-29 19:39:25 <TD> :)
698 2012-11-29 19:39:41 <gmaxwell> BlueMatt: but is it 4x slower but runs 4 in parallel? :P
699 2012-11-29 19:39:55 <jgarzik> gmaxwell: LoadExternalBlockFile() used fseek(FILE*, 32-bit signed int) throughout the block loading operation
700 2012-11-29 19:40:01 <BlueMatt> sipa: did I see you already did some parallel sig checking, or not, because a lot of the branch I did for cblockstore should still apply
701 2012-11-29 19:40:07 <jgarzik> gmaxwell: so current bootstrap.dat is effectively truncated in practice
702 2012-11-29 19:40:17 <BlueMatt> gmaxwell: not the branch I have, its only like 3x slower and runs 4 in parallel :)
703 2012-11-29 19:40:33 <jgarzik> gmaxwell: sipa fixed the problem, but 0.7 and 0.7.1 remain impacted
704 2012-11-29 19:40:58 <jgarzik> sipa: yes, a nice checkpoint :)
705 2012-11-29 19:41:03 <sipa> BlueMatt: i had it working, except for an occasional segfault
706 2012-11-29 19:41:04 <sipa> t
707 2012-11-29 19:41:20 <BlueMatt> ah, ok, nevermind then
708 2012-11-29 19:41:59 <sipa> i'm really going to need to make a todo list and prioritize :(
709 2012-11-29 19:42:28 <BlueMatt> heh
710 2012-11-29 19:42:39 <TD> i wonder if we should just provide an openssl based implementation of ECKey
711 2012-11-29 19:42:47 <TD> rather than try to optimize a java version
712 2012-11-29 19:42:58 <BlueMatt> TD: next time I do the sig stuff, Im gonna do that
713 2012-11-29 19:43:00 <TD> it'd not help android but then you aren't gonna do sig checking on android anyway.
714 2012-11-29 19:43:01 <TD> yeah
715 2012-11-29 19:43:06 <jgarzik> restarting crashed us2.exmulti.net (public backbone/fallback node) on git HEAD
716 2012-11-29 19:43:11 <jgarzik> let's see how it goes
717 2012-11-29 19:43:12 <BlueMatt> (probably just use hal's as-is and throw it in a jni wrapper)
718 2012-11-29 19:43:17 <jgarzik> (note the crash was pre-ultraprune)
719 2012-11-29 19:43:43 <gmaxwell> BlueMatt: ever figure out hal's comments on further speedups?
720 2012-11-29 19:43:44 <TD> sounds good
721 2012-11-29 19:44:02 <BlueMatt> gmaxwell: no, sadly not (didnt spend too much time reading up on it though)
722 2012-11-29 19:44:18 <sipa> TD: no EC crypto experts at google we could ask for help with that?
723 2012-11-29 19:44:27 <BlueMatt> ACTION is gonna have some busy holidays...
724 2012-11-29 19:44:42 <jgarzik> ACTION plans to import Hal's speedup that he posted, into picocoin
725 2012-11-29 19:44:51 <TD> talk to emilia
726 2012-11-29 19:45:04 <sipa> we provably should do the same in bitcoind
727 2012-11-29 19:45:09 <sipa> *probably
728 2012-11-29 19:45:15 <gmaxwell> QED
729 2012-11-29 19:45:16 <TD> she wrote the paper on it, literally
730 2012-11-29 19:45:17 <TD> http://dejanseo.com.au/research/google/37376.pdf
731 2012-11-29 19:45:20 <TD> works at the zurich office too
732 2012-11-29 19:45:28 <sipa> just import Hal's code now, and optimize further later
733 2012-11-29 19:45:31 <sipa> TD: cool
734 2012-11-29 19:45:44 <TD> that paper is called "Fast Elliptic Curve Cryptography in OpenSSL"
735 2012-11-29 19:45:48 <TD> so if anyone knows, it should be her :)
736 2012-11-29 19:46:05 <D34TH> who knows, she might even have bitcoin
737 2012-11-29 19:46:06 <D34TH> :D
738 2012-11-29 19:46:25 <D34TH> s/have/use
739 2012-11-29 19:48:09 <sipa> oh wow
740 2012-11-29 19:49:15 <gmaxwell> sounds like someone to hit up on the hdwallet construct too.
741 2012-11-29 19:49:41 <jgarzik> sipa: agreed (RE import now opt later)
742 2012-11-29 19:49:57 <jgarzik> ACTION is tempted to do a little endian, BigInt implementation
743 2012-11-29 19:50:02 <jgarzik> I don't like OpenSSL's
744 2012-11-29 19:50:06 <jgarzik> the more I use it and see it
745 2012-11-29 19:50:11 <sipa> how about gmp?
746 2012-11-29 19:50:27 <jgarzik> everybody seems to want to do things as big endian, then swap on LE
747 2012-11-29 19:50:38 <jgarzik> I was thinking of 32-bit LE int as smallest native type
748 2012-11-29 19:50:42 <gmaxwell> I like GMP a lot, but it's lgpl...
749 2012-11-29 19:51:04 <jgarzik> GMP seems to follow OpenSSL's BIGNUM in having a BE-centric, swap-back-to-LE-at-end implementation IIUC
750 2012-11-29 19:51:16 <sipa> uh?
751 2012-11-29 19:51:35 <sipa> internally it uses native 32-bit or 64-bit ints
752 2012-11-29 19:51:58 <sipa> oh yes, lgpl
753 2012-11-29 20:02:12 <jgarzik> well I'll be damned. I thoroughly misunderstood OpenSSL's BIGNUM code
754 2012-11-29 20:02:20 <jgarzik> I thought it was byte for byte not ulong for ulong
755 2012-11-29 20:02:35 <jgarzik> I like it a lot more now
756 2012-11-29 20:06:17 <sipa> jgarzik: oh no, that would be horribly slow!
757 2012-11-29 20:07:09 <Eliel> what's the problem with lgpl? you can use it with code that's not gpl, no?
758 2012-11-29 20:08:35 <helo> you can link to it
759 2012-11-29 20:08:57 <helo> but you can't grab a snippet of it and put it in your non-gpl code for optimization
760 2012-11-29 20:11:17 <isitlove> selling at 12 usd via pp
761 2012-11-29 20:11:22 <sipa> isitlove: #bitcoin-otc
762 2012-11-29 20:11:30 <sipa> Luke-Jr: eta 2h
763 2012-11-29 20:19:06 <gmaxwell> Eliel: it's not wrong, it would complicated the licensing. If jeff wanted to have downstream users of picocoin subject to the lgpl he might as well lgpl the whole thing.
764 2012-11-29 20:21:56 <gmaxwell> (at least for something as central as a bignum library)
765 2012-11-29 20:25:50 <sipa> Luke-Jr: pushed v0.7.2rc1 sigs; win32 matches
766 2012-11-29 20:41:15 <TD> hmmm
767 2012-11-29 20:41:19 <TD> bitmessage is sort of a disappointment
768 2012-11-29 20:46:10 <gmaxwell> I successfully exchanged messages with someone in here with it... but.. yea. it's .. odd.
769 2012-11-29 20:46:51 <TD> python was not the greatest choice ever
770 2012-11-29 20:46:59 <TD> i got bored about 30 seconds in to generating a new identity
771 2012-11-29 20:47:34 <gmaxwell> TD: RSA key generation just stinks. I don't even think thats python's problem there.
772 2012-11-29 20:47:38 <TD> it's sort of like, the goal is good, the effort is good. but it needs more design work and a real implementation using C++ and ElGamal or something like that
773 2012-11-29 20:47:49 <TD> afaict the rsa implementation he uses is pure python
774 2012-11-29 20:48:24 <x18882> yeah forget about python for any intensive work
775 2012-11-29 20:48:34 <gmaxwell> I don't see any reason why it's using RSA... certantly the bloated keys are not great for scalablity.
776 2012-11-29 20:48:46 <slush1> ...it is just a prototype
777 2012-11-29 20:49:17 <gmaxwell> The whole thing about having to have the counterparty online just so they can provide a public key is weird and unwelcome.
778 2012-11-29 21:14:52 <Luke-Jr> sipa: eta 2h for ?
779 2012-11-29 21:16:11 <sipa> Luke-Jr: download of your block file done now
780 2012-11-29 21:16:26 <sipa> Luke-Jr: download of your block file; done now
781 2012-11-29 21:16:55 <Luke-Jr> ah
782 2012-11-29 21:17:03 <jgarzik> https://bitcointalk.org/index.php?topic=128413.0
783 2012-11-29 21:17:03 <Luke-Jr> sipa: ready to build rc2? :P
784 2012-11-29 21:17:06 <jgarzik> "Their system is based on a Bitcoin-style blockchain, much as we have
785 2012-11-29 21:17:10 <jgarzik> Ripple-based
786 2012-11-29 21:17:39 <sipa> jgarzik: they even hired justmoon :)
787 2012-11-29 21:18:20 <jgarzik> sounds like JoelKatz is on board too
788 2012-11-29 21:20:16 <Luke-Jr> funny they mention Jed specifically though
789 2012-11-29 21:20:35 <Luke-Jr> after the 2011 MtGox exploits, I don't have much opinion of him
790 2012-11-29 21:21:21 <sipa> there's no such thing as bad publicity :)
791 2012-11-29 21:22:01 <Luke-Jr> sipa: perhaps, but I think it'd be better publicity if they left Jed out of it :P
792 2012-11-29 21:22:27 <Luke-Jr> seeing that makes me think "oh boy, I wonder how long until someone sets their debts to negative"
793 2012-11-29 21:28:04 <jgarzik> Jed is a big name, long before bitcoin
794 2012-11-29 21:28:54 <jgarzik> Chris Larsen @ Prosper.com is an interesting name
795 2012-11-29 21:29:06 <jgarzik> I did several thousand dollars worth of loans on Prosper.com, years ago
796 2012-11-29 21:29:08 <sipa> Luke-Jr: at which block do you get the error?
797 2012-11-29 21:29:20 <gmaxwell> jgarzik: I'm sorry for your loss. :P
798 2012-11-29 21:29:21 <jgarzik> maybe 60% were paid back to me
799 2012-11-29 21:29:45 <jgarzik> it was always high risk capital, but the Prosper.com community really reminded me of the bitcoin one
800 2012-11-29 21:29:51 <jgarzik> high hopes of helping humanity
801 2012-11-29 21:30:03 <jgarzik> but in the end, it turns out, poor people make really bad money managemment decisions
802 2012-11-29 21:30:06 <sipa> jgarzik: that sounds like an anachronism :)
803 2012-11-29 21:30:17 <jgarzik> and people with poor credit scores have poor credit scores for a good reason
804 2012-11-29 21:30:27 <Luke-Jr> sipa: http://codepad.org/xssn6Wo4
805 2012-11-29 21:31:04 <Luke-Jr> jgarzik: sometimes*
806 2012-11-29 21:31:15 <jgarzik> Just like the bitcoin community insists upon learning basic lessons about trust and money. c.f. repeated cases where people trusted others they did not know to securely hold thousands or millions of dollars worth of bitcoins
807 2012-11-29 21:31:17 <Luke-Jr> jgarzik: lately it seems credit reporting agencies are just avenues for slander
808 2012-11-29 21:31:20 <jgarzik> and not run off with them
809 2012-11-29 21:32:02 <jgarzik> "TORwallet was a scam, so I'm opening another TOR wallet. I insist that _this_ one is not a scam, even though I and my site are anonymous"
810 2012-11-29 21:32:02 <sipa> Luke-Jr: works flawless here
811 2012-11-29 21:32:21 <gmaxwell> hah did torwallet turn out to be a scam?
812 2012-11-29 21:32:24 <Luke-Jr> sipa: you're located somewhere totally different. I don't expect there to be a comparison :P
813 2012-11-29 21:32:33 <jgarzik> gmaxwell: looks like it
814 2012-11-29 21:32:38 <gmaxwell> I didn't hear about it after telling everone it was probably a scam...
815 2012-11-29 21:32:41 <sipa> Luke-Jr: i'm at 172k
816 2012-11-29 21:32:46 <jgarzik> the bitcoins done R-U-N-N-O-F-T
817 2012-11-29 21:32:46 <Luke-Jr> first I've heard of TORwallet
818 2012-11-29 21:33:01 <Luke-Jr> sipa: O.o
819 2012-11-29 21:33:13 <sipa> i passed that reorg, and nothing bad happened
820 2012-11-29 21:33:30 <sipa> i can try doing it again under valgrind, but that can take a while
821 2012-11-29 21:33:45 <Luke-Jr> ACTION ponders
822 2012-11-29 21:34:39 <sipa> Luke-Jr: so, what i do: i create a .bitcoin/bitcoin.conf, put your file in .bitcoin/blocks/, and run with -reindex
823 2012-11-29 21:34:46 <Luke-Jr> sipa: on the off-chance my binary doesn't match my source, let me clean & rebuild first???
824 2012-11-29 21:34:54 <sipa> in an otherwise completely empty .bitcoin
825 2012-11-29 21:35:21 <sipa> on current git head (with #2049, but that should not be related)
826 2012-11-29 21:36:12 <Luke-Jr> oh (#%*
827 2012-11-29 21:36:21 <Luke-Jr> git stash refuses to stash unless you set name/email
828 2012-11-29 21:36:59 <Luke-Jr> sigh
829 2012-11-29 21:37:03 <sipa> haha :)
830 2012-11-29 21:39:02 <sipa> gmaxwell: i beat you :D
831 2012-11-29 21:39:40 <gmaxwell> wtf!
832 2012-11-29 21:39:53 <gmaxwell> how did we both manage to do that at the sameish time!
833 2012-11-29 21:41:05 <sipa> sameish? 11 minutes is around 200 million km apart, relativistically!
834 2012-11-29 21:41:45 <gmaxwell> well, same relative to the ~24 hours ago that we were discussing this before~
835 2012-11-29 21:43:47 <sipa> wow, optimized binary running under valgrind is faster than expected... 60k blocks in 7.5 minutes
836 2012-11-29 21:52:22 <helo> (network IBD finished in 5 hours 23 minutes)
837 2012-11-29 21:53:27 <gmaxwell> helo: thats way slwo
838 2012-11-29 21:53:29 <gmaxwell> er slow
839 2012-11-29 21:53:39 <gmaxwell> helo: did it spend a lot of time stuck?
840 2012-11-29 21:56:14 <helo> bah, already blew the log away to time loadblock IBD
841 2012-11-29 22:11:01 <sipa> Luke-Jr: anyway, i can start a build until 2 hours from now
842 2012-11-29 22:13:39 <Luke-Jr> sipa: ok, I'll plan to push the tag within an hour then
843 2012-11-29 22:28:28 <D34TH> can you specify datadir in bitcoin.conf?
844 2012-11-29 22:28:53 <gavinandresen> yes, but then the universe implodes.
845 2012-11-29 22:29:13 <D34TH> well it wouldnt matter if i had bitcoin.conf in appdata but i want the blockchain elsewhere
846 2012-11-29 22:30:09 <gavinandresen> seriously, yes, if I recall correctly you can. But it is less mind-bending to specify -datadir=.... -conf=....
847 2012-11-29 22:30:28 <gavinandresen> ... on the command-line
848 2012-11-29 22:31:17 <D34TH> okey
849 2012-11-29 22:36:00 <D34TH> ooh
850 2012-11-29 22:36:03 <D34TH> for extra points
851 2012-11-29 22:38:14 <D34TH> brb dinrar
852 2012-11-29 22:38:20 <D34TH> whoops wrong window
853 2012-11-29 22:38:28 <D34TH> i feel stupid
854 2012-11-29 22:42:32 <phantomcircuit> D34TH, you can but dont
855 2012-11-29 22:59:06 <D34TH> everything after okey was meant for someone else
856 2012-11-29 23:05:40 <sipa> with 8 GiB of RAM, i can only valgrind bitcoind up to importing 126k blocks
857 2012-11-29 23:06:16 <gmaxwell> hm. I don't recall valgrind leaking memory while testing bitcoin.
858 2012-11-29 23:06:34 <gmaxwell> though maybe I just have enough that I didn't notice.
859 2012-11-29 23:09:20 <Luke-Jr> sipa: v0.7.2rc2 tagged
860 2012-11-29 23:09:42 <Luke-Jr> gmaxwell: is it leaking, if it's using the tracking data?
861 2012-11-29 23:11:54 <gmaxwell> Luke-Jr: the tracking data shouldn't be more than some constant factor memory usage, at least if you don't have track origins on.
862 2012-11-29 23:22:16 <DBordello> When did we roll over from blk0001.dat to blk0002.dat?
863 2012-11-29 23:22:36 <sipa> in juli or so?
864 2012-11-29 23:24:37 <DBordello> It looks like blk0002.dat is almost full
865 2012-11-29 23:30:29 <jgarzik> Let's see how long full verf, including script, takes
866 2012-11-29 23:31:50 <jgarzik> first 90,000 blocks in less than 60 secs
867 2012-11-29 23:32:26 <sipa> what does full verf include?
868 2012-11-29 23:33:32 <jgarzik> sipa: everything check I can find mention of. Started with https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages
869 2012-11-29 23:34:07 <sipa> but not writing block files, writing undo data, keeping an on-disk database, ...?
870 2012-11-29 23:34:11 <jgarzik> builds UTXO, verifies script, spend-ability
871 2012-11-29 23:34:18 <gmaxwell> utxo in memory.
872 2012-11-29 23:34:19 <jgarzik> sipa: correct. this is all in-memory
873 2012-11-29 23:34:22 <sipa> ok
874 2012-11-29 23:34:39 <jgarzik> no disk writing, and no reorg
875 2012-11-29 23:34:54 <sipa> no reorg?
876 2012-11-29 23:35:10 <sipa> oh, it just veirifes a given chain
877 2012-11-29 23:35:34 <jgarzik> no. it will store weak branches, but does not support current branch becoming the weak one.
878 2012-11-29 23:35:52 <sipa> right
879 2012-11-29 23:37:37 <jgarzik> First time I've run script verf on the full chain. It has been passing the ref client tests for a couple weeks now, but never hooked up everything together before.
880 2012-11-29 23:37:45 <jgarzik> chain-verf: spend fail 394 00000000dd30457c001f4095d208cc1296b0eed002427aa599874af7a432b105
881 2012-11-29 23:37:53 <jgarzik> didn't like testnet3, at height 394
882 2012-11-29 23:38:07 <jgarzik> but looking good so far on mainnet,
883 2012-11-29 23:38:08 <jgarzik> chain-verf: spend block @ 120000
884 2012-11-29 23:38:37 <jgarzik> clearly the testnet3 chain has some tests that ref client test/data/ lacks ;p