1 2013-11-30 00:19:41 <HaltingState> I am reading mastercoin spec; whenever someone buys anything for bitcoin, they have to send an output to "exodus address" and it has to be above the dust treshhold of 54 uBTC. which is 1 penny; will be like $1 soon, going to create massive number of unspent transactions
2 2013-11-30 00:21:37 <warren> toffoo: https://github.com/bitcoin/bitcoin/issues/2770
3 2013-11-30 00:21:42 <warren> please respond
4 2013-11-30 00:25:16 <andytoshi> when i pipe bitcoin diffs to mail, sometimes there are too many non-alphanumerics and the MIME type is autodetected wrongly as binary
5 2013-11-30 00:25:24 <andytoshi> is anyone familiar with mailx or mime autodetection?
6 2013-11-30 00:28:40 <dexX7> HaltingState: there seem to be plans to avoid unspendable outputs in the future, either by using op_return or constructs like this: https://blockchain.info/tx/3e5fd9702ec7755a61b8040b0872482896391c5e25739e666c7af70dcbc7625d (which is not "in the spec" currently though)
7 2013-11-30 00:29:36 <gmaxwell> HaltingState: their 'exodus address' is perfectly spendable. It's a regular private key that the creators of the system have.
8 2013-11-30 00:30:41 <HaltingState> gmaxwell, yes; its interesting; wonder how long until someone steals private key :)
9 2013-11-30 00:30:55 <HaltingState> he has to keep it live on computer attached to network for various reasons
10 2013-11-30 00:31:03 <warren> gmaxwell: maybe I should announce a 'spec' with no code too...
11 2013-11-30 00:31:14 <HaltingState> and he has to sign a lot of transactions with it
12 2013-11-30 00:31:57 <HaltingState> dexX7, explain how you prevent unspendable outputs?
13 2013-11-30 00:32:13 <gmaxwell> HaltingState: they originally had it loaded in a blockchain.info wallet at some point.
14 2013-11-30 00:32:31 <HaltingState> gmaxwell, OMFG LULZ
15 2013-11-30 00:32:47 <HaltingState> so its in the blockchain.info backups somewhere
16 2013-11-30 00:33:37 <HaltingState> well mastercoin will be great for minings, its going to create massive transaction fees; people are going to publish gold price in blockchain every minute and its going to cost 10 cents per publication
17 2013-11-30 00:33:43 <gmaxwell> HaltingState: laugh it up, ... but those guys managed to pull in 4 million bucks from other people, what have you accomplished this year? :P
18 2013-11-30 00:34:05 <diki> Question.
19 2013-11-30 00:34:19 <saracen> Answer.
20 2013-11-30 00:34:25 <diki> How would one know if his DNS was compromised and he was redirected to a phishing website?
21 2013-11-30 00:34:39 <HaltingState> gmaxwell, I am going to vegas to stay at guys mansion I know in LA; other guy with me made 10 million in mastercoin this week :) market is getting frothy
22 2013-11-30 00:34:43 <phantomcircuit> gmaxwell, i suspect mastercoin engaged in fraud
23 2013-11-30 00:34:52 <phantomcircuit> however im pretty sure nobody will ever be able to prove it
24 2013-11-30 00:34:53 <phantomcircuit> :(
25 2013-11-30 00:35:10 <HaltingState> i am wondering if the bitcoin vegas thing is going to be a bunch of coked up people or what; will see if price hits $2k before 10th
26 2013-11-30 00:35:20 <saracen> diki: I don't think he would know.
27 2013-11-30 00:35:56 <diki> phantomcircuit:I haven't been living under a rock, but I haven't been much interested in these Zerocoin/Mastercoin. What are they for?
28 2013-11-30 00:36:22 <phantomcircuit> diki, zerocoin is a legitimate attempt to build a truly anonymous payments system
29 2013-11-30 00:36:27 <phantomcircuit> mastercoin is a shitty altcoin
30 2013-11-30 00:36:44 <HaltingState> gmaxwell, well i think you are 100% right about litecoin. mastercoin I think will fail, but its important because people are thinking about this stuff now. they will work it out eventually (hopefully not on main blockchain and hopefully with security someday)
31 2013-11-30 00:36:48 <diki> If mastercoin is an alt, what does it have to do with Bitcoin?
32 2013-11-30 00:36:59 <HaltingState> mastercoin is on the bitcoin block chain
33 2013-11-30 00:37:06 <Luke-Jr> http://codepad.org/iHKynRxn <-- anyone know why Armory won't build?
34 2013-11-30 00:37:08 <HaltingState> its like satoshi dice
35 2013-11-30 00:37:32 <phantomcircuit> diki, they have some crazy shit where they do bitcoin transactions and generate mastercoins as colored coins or something
36 2013-11-30 00:37:37 <phantomcircuit> tbh i cant 100% remember
37 2013-11-30 00:37:52 <dexX7> HaltingState: in the above linked tx there is no unspendable output anymore, it's just the exodus addr, the receiver and 1-of-2 multisig output which includes the sender and the datapacket. this is currently (in a not so compact form) already used, for example: https://blockchain.info/tx/9e2a5bba2d146a9de22ed288fdbc980db5b0cb717a6fc47c92713260051b5fe8
38 2013-11-30 00:38:00 <phantomcircuit> i do however remember gmaxwell breaking their PoW essentially entirely in like 10 minutes
39 2013-11-30 00:38:12 <Luke-Jr> phantomcircuit: I thought that was Bitshares?
40 2013-11-30 00:39:10 <gmaxwell> phantomcircuit: yea, that was bitshares the other alt thing trading on the bitcoin name around the same time.
41 2013-11-30 00:39:24 <HaltingState> gmaxwell, how did you break his proof of work? I liked the idea
42 2013-11-30 00:39:53 <phantomcircuit> gmaxwell, oh ok
43 2013-11-30 00:40:02 <phantomcircuit> it's so hard to keep all these stupid things straight
44 2013-11-30 00:40:28 <HaltingState> I liked find x,y where sha256(x) mod D = = sha256(y) mod D, where difficulty is D. it seemed innovative
45 2013-11-30 00:40:44 <diki> breaking proof of work??
46 2013-11-30 00:41:00 <gmaxwell> HaltingState: because it was just incompetence and unicorn farts strung together with marketing and hope. What you're describing is like their forth attempt. I broke their first one.
47 2013-11-30 00:41:16 <gmaxwell> HaltingState: though that one isn't progress free, so it creates an advantage for larger miners.
48 2013-11-30 00:41:37 <gmaxwell> There is also a time memory tradeoff, so its not actually memory hard.
49 2013-11-30 00:41:37 <HaltingState> ah; you mean miners with more ram per machine?
50 2013-11-30 00:42:03 <HaltingState> oh hash table for lookup; hmm this is interesting problem
51 2013-11-30 00:42:20 <HaltingState> his first paper sucked, was very complicated for the idea
52 2013-11-30 00:42:43 <sipa> complicated paper != good idea
53 2013-11-30 00:43:53 <HaltingState> sipa, did you see mastercoin paper? lol. I read that and first time was like "what is this shit!?". did not take it seriously for months until yesterday
54 2013-11-30 00:44:03 <gmaxwell> the first thing was just marketing bs and had a simple algebraic simplication that let you convert its 128MBs of memory accessed to ~8192 bytes of memory needed and accessed. The problem is that they were hardly putting in the world to do a competent job, but instead throwing crap against the wallet and changing it when someone breaks it.
55 2013-11-30 00:44:35 <gmaxwell> HaltingState: yea, I thought it would go nowhere, I became somewhat concerned when they raised a jillion bitcoin and started creating large numbers of upspendable txouts.
56 2013-11-30 00:44:52 <HaltingState> "let you convert its 128MBs of memory accessed to ~8192 bytes of memory needed and accessed" oh god lol
57 2013-11-30 00:45:43 <HaltingState> litecoin i think should have added writeback into the array, to prevent/deter GPU mining if that was the intention; script seems to have stood up well however
58 2013-11-30 00:48:04 <BustyLoli-Chan> is there a way to make bitcoind show all of the addresses associated with an account and the individual amounts of money that each of those addresses has recieved all in one command?
59 2013-11-30 00:49:10 <BustyLoli-Chan> I'm guessing it would be the listreceivedbyaddress command?
60 2013-11-30 00:50:00 <kjj> for the love of god, will you people please just stop asking the node to do that shit?
61 2013-11-30 00:50:22 <BustyLoli-Chan> the node?
62 2013-11-30 00:50:52 <BustyLoli-Chan> I was under the impression I had a copy of the entire blockchain sitting on my computer... why can't I just browse it locally?
63 2013-11-30 00:50:53 <edcba> accounts aren't associated to addresses
64 2013-11-30 00:51:09 <kjj> if you really care what payments came in to different addresses, you should be writing your own software
65 2013-11-30 00:51:29 <sipa> BustyLoli-Chan: only the transactions in the wallet are indexed
66 2013-11-30 00:51:31 <edcba> the solution i found to do that is using 2 different users
67 2013-11-30 00:51:41 <edcba> export import keys
68 2013-11-30 00:51:50 <BustyLoli-Chan> "address" : "1JjwuYdx1Ta7mLKVj8LNU9obiDuYZJupMi", "account" : "General Purpose", "amount" : 2.98505246, "confirmations" : 389
69 2013-11-30 00:51:52 <edcba> so 1 user has only 1 address
70 2013-11-30 00:52:32 <BustyLoli-Chan> no... one "account" I have has tons
71 2013-11-30 00:52:38 <BustyLoli-Chan> and is going to have a lot mor
72 2013-11-30 00:52:51 <sipa> BustyLoli-Chan: so, you want by address or by account?
73 2013-11-30 00:52:57 <edcba> maybe you should write some software then
74 2013-11-30 00:52:57 <sipa> you receive coins using an address
75 2013-11-30 00:53:02 <sipa> but accounts are just beancounters
76 2013-11-30 00:53:10 <BustyLoli-Chan> I am writing some software
77 2013-11-30 00:53:27 <BustyLoli-Chan> My software is gathering information from bitcoind
78 2013-11-30 00:53:33 <BustyLoli-Chan> pasing it via json
79 2013-11-30 00:53:34 <sipa> if an address is tied to account X, (external) sends to that address will credit that account
80 2013-11-30 00:53:37 <BustyLoli-Chan> *parsing
81 2013-11-30 00:53:52 <sipa> but it's not like the coins belong to that account or anything
82 2013-11-30 00:53:53 <BustyLoli-Chan> okay
83 2013-11-30 00:54:04 <sipa> bitcoind moves coins around between addresses when you do transactions, transparently
84 2013-11-30 00:54:07 <BustyLoli-Chan> but by running "listreceivedbyaddress"
85 2013-11-30 00:54:14 <sipa> the accounts system abstracts from that
86 2013-11-30 00:54:17 <edcba> the best to do is stop using that shitty api and directly transmit through bitcoin port to official client your tx imo
87 2013-11-30 00:54:20 <BustyLoli-Chan> It will show me all amounts recieved by all addresses?
88 2013-11-30 00:54:35 <sipa> by all wallet addresses, from external transactions, yes
89 2013-11-30 00:54:46 <BustyLoli-Chan> okay, thank you
90 2013-11-30 00:54:54 <BustyLoli-Chan> edcba is there a guide on how to do this?
91 2013-11-30 00:54:55 <sipa> it will not show you the "balance" of those addresses
92 2013-11-30 00:55:08 <BustyLoli-Chan> I don't need that... just the money recieved
93 2013-11-30 00:55:11 <sipa> ok
94 2013-11-30 00:55:14 <sipa> that's what it's for
95 2013-11-30 00:56:23 <BustyLoli-Chan> also... how many confirmations is a good number before you can trust that a transaction actually has taken place
96 2013-11-30 00:56:27 <BustyLoli-Chan> is 1 usually enough?
97 2013-11-30 00:57:04 <Belxjander> BustyLoli-Chan: 2-3 confirmations minimum... but the general de facto standard is to have 6 confirmations
98 2013-11-30 00:57:14 <BustyLoli-Chan> I see, thank you
99 2013-11-30 00:57:56 <edcba> btw are split still happening ?
100 2013-11-30 00:58:10 <edcba> do we have some stats for that ?
101 2013-11-30 00:58:32 <sipa> edcba: unless you invent FTL travel, i doubt how we could not have (small, temporary) forks
102 2013-11-30 00:59:37 <edcba> i just wanted some split frequency stats
103 2013-11-30 01:06:02 <maaku> edcba: look in your debug.log for REORG events
104 2013-11-30 01:06:13 <maaku> (and double the number that you see)
105 2013-11-30 01:06:30 <edcba> i don't run much clients much these days :)
106 2013-11-30 01:06:49 <madthanu> sounds stupid to ask, but any chance (&CDataStream[0]) might ever point to an invalid address?
107 2013-11-30 01:07:16 <sipa> madthanu: if no storage has been allocated for it, yes, i think
108 2013-11-30 01:08:27 <madthanu> the stacktrace warren provided in #2770 occurs during a Get(LevelDB::Slice) call
109 2013-11-30 01:08:47 <warren> madthanu: that was toffoo
110 2013-11-30 01:09:55 <madthanu> warren: Sorry, yes, toffo. Anyway, as rescriva also seems to observe, all the keys are iterable when you just recover that chainstate directly using LevelDB
111 2013-11-30 01:11:03 <madthanu> madthanu: I looked into the LevelDB code, and I suspect the SIGSEGV might be happening when dereferencing the Slice provided by bitcoin-qt to LevelDB during the Get() call ......
112 2013-11-30 01:11:46 <sipa> are you talking to yourself? :p
113 2013-11-30 01:12:04 <madthanu> sipa: half waking up now, so forgive my messaging stupidities :)
114 2013-11-30 01:12:31 <madthanu> but yes, that was kind of talking to myself too
115 2013-11-30 01:13:47 <madthanu> Anyway, that Slice is obtained by using CDataStream to serialize a pair<> associated with a coin. I'm delving deeper, but if anyone already knows something related to it, that'd be great.
116 2013-11-30 01:18:10 <sipa> madthanu: it should be impossible to end up with size 0 data, when serializing a CCoins
117 2013-11-30 01:26:31 <HaltingState> is there a GPU /opencl implementation of SHA512?
118 2013-11-30 01:29:13 <madthanu> sipa: hmmm
119 2013-11-30 01:39:29 <warren> I wonder if we should just release. We know it's better than before at least.
120 2013-11-30 01:44:21 <madthanu_> toffoo: thanks for the extra info
121 2013-11-30 01:59:49 <madthanu_> toffoo: any chance you can make public all files except your wallet.dat? including your block files and stuff?
122 2013-11-30 02:00:23 <madthanu_> toffoo: I'm not sure that's safe privacy-wise, but it'll be helpful with debugging
123 2013-11-30 02:00:41 <dexX7> bitcoin.conf might contain some more data
124 2013-11-30 02:00:55 <dexX7> rpc login
125 2013-11-30 02:01:30 <madthanu_> dexX7: private data?
126 2013-11-30 02:05:09 <dexX7> just delete all lines starting with "rpc" in bitcoin.conf, if there are any
127 2013-11-30 02:05:29 <dexX7> one could use those to access your bitcoind from the outside (under some conditions)
128 2013-11-30 02:05:52 <madthanu_> I don't think bitcoin.conf would be helpful anyway, so maybe omit the file?
129 2013-11-30 02:06:36 <JimJones> hey dexX7 can I pm you?
130 2013-11-30 02:06:43 <dexX7> hm sure
131 2013-11-30 02:40:41 <cfields> aha
132 2013-11-30 02:40:46 <cfields> toffoo: still around?
133 2013-11-30 02:41:26 <warren> cfields: I'm doing another build in a few hours if you want something in it.
134 2013-11-30 02:41:52 <cfields> i think i just found a case that the current patch misses
135 2013-11-30 02:42:04 <warren> aha
136 2013-11-30 02:42:05 <cfields> gmaxwell or other dev, around for a sanity check?
137 2013-11-30 02:42:22 <gmaxwell> hm?
138 2013-11-30 02:43:30 <cfields> gmaxwell: can you check me on a leveldb theory real quick? i'm doing up a patch
139 2013-11-30 02:43:57 <gmaxwell> show it to me
140 2013-11-30 02:44:06 <cfields> k, 1 min
141 2013-11-30 02:44:18 <cfields> i didn't think you'd pong so quickly :p
142 2013-11-30 02:45:13 <HaltingState> sipa, ERROR: CTxMemPool::accept() : not enough fees
143 2013-11-30 02:45:15 <HaltingState> what is that error?
144 2013-11-30 02:46:01 <HaltingState> that is for unconfirmed transactions right?
145 2013-11-30 02:46:04 <gmaxwell> HaltingState: it's pretty self explanitory! right?
146 2013-11-30 02:46:11 <lianj> "not enough fees"
147 2013-11-30 02:46:16 <HaltingState> its for a transaction not a block?
148 2013-11-30 02:46:28 <gmaxwell> HaltingState: yes, also note "MemPool::accept"
149 2013-11-30 02:46:31 <kjj> yes, for a transaction received as a transaction (rather than in a block)
150 2013-11-30 02:47:16 <HaltingState> this is my first time going into bitcoin source; very interesting (really protoshares source but its some thing...)
151 2013-11-30 02:48:01 <HaltingState> gmaxwell, i can do GPU miner for protoshares; not GPU immune, but not sure if sha512 implementations are as optimized as sha256 for gpu
152 2013-11-30 02:49:50 <diki> well sha256 has been the primary focus
153 2013-11-30 02:49:51 <diki> so...
154 2013-11-30 02:50:02 <diki> no love for sha512
155 2013-11-30 02:50:21 <diki> So yeah, optimizations are probably possible.
156 2013-11-30 02:50:23 <HaltingState> there is only one round of sha512 vs two rounds of sha256
157 2013-11-30 02:50:53 <diki> This might sound stupid, but don't two rounds of sha256 take around the same time as sha512?
158 2013-11-30 02:50:59 <HaltingState> ok SHA512, 32 million passwords/second :)
159 2013-11-30 02:52:01 <HaltingState> 390 million passwords for per second, omg the password cracking people are on this sha512 thing
160 2013-11-30 02:52:24 <kjj> it depends. the sha-2 variants aren't too different. 512 has a few more rounds, and uses 64 bit values
161 2013-11-30 02:52:47 <HaltingState> so if GPU does not have 64 bit integer ops then it might be slow
162 2013-11-30 02:53:29 <HaltingState> sha512 is 80 rounds, 64 bit word size; same number of rounds as sha256, hmm
163 2013-11-30 02:53:48 <warren> HaltingState: please take this elsewhere?
164 2013-11-30 02:53:54 <warren> this has nothing to do with bitcoin
165 2013-11-30 02:54:08 <HaltingState> k
166 2013-11-30 02:54:54 <cfields> gmaxwell: mm, that fix didn't work as i'd hoped. i'll re-ping in a few.
167 2013-11-30 03:06:02 <cfields> gmaxwell: https://github.com/theuni/bitcoin/commit/1d0e54bfb76b3891468582df97c4429174063c3c
168 2013-11-30 03:07:09 <cfields> the issue is that while it's looping through the write, it unmaps/remaps. and if there's a write that straddles a mapping, it can be split and not flushed to disk properly by osx
169 2013-11-30 03:07:19 <cfields> robert's patch fixes that part
170 2013-11-30 03:07:32 <cfields> however, once the write is complete, it's not immediately unmapped
171 2013-11-30 03:07:54 <cfields> so at that point, the very tail may not be flushed
172 2013-11-30 03:11:18 <madthanu> cfields: even if robert's theory were true, and that is the actual bug, wouldn't UnmapCurrentRegion() be called eventually? for example, while closing the file
173 2013-11-30 03:12:01 <madthanu> cfields: I'm probably not understanding the case where you say robert's msync wouldn't happen
174 2013-11-30 03:12:22 <licnep> how do nodes currently verify if a sender had enough bitcoins for a transaction? they have to go back in the blockchain until they find the latest transaction involving that address?
175 2013-11-30 03:12:31 <madthanu> cfields: If my silly brain is being right, your current patch will convert all Put() operations in LevelDB synchronous, making things really slow
176 2013-11-30 03:12:35 <ers35> s there any evidence that OS X 10.8, 10.9 does not flush dirty pages to disk? Do we know precisely at how that conclusion was arrived?
177 2013-11-30 03:12:39 <gmaxwell> licnep: this is a discussion for #bitcoin
178 2013-11-30 03:12:47 <gmaxwell> licnep: I'll answer you there.
179 2013-11-30 03:12:52 <licnep> ok
180 2013-11-30 03:12:59 <cfields> madthanu: yes, that change would be painful, it's a POC rather than a real fix
181 2013-11-30 03:13:39 <cfields> madthanu: look at Close(). It forces the data to disk before an msync().
182 2013-11-30 03:14:09 <cfields> er, Sync() rather
183 2013-11-30 03:14:37 <madthanu> cfields: your patch would probably alleviate the bug though, whatever the real cause might be
184 2013-11-30 03:14:53 <madthanu> cfields: I'm hoping silly bugs don't keep happening after so many msyncs :)
185 2013-11-30 03:15:16 <phantomcircuit> what exactly are we even storing in leveldb?
186 2013-11-30 03:15:25 <cfields> mine would cause the msync() at the end of each chunk of actual data
187 2013-11-30 03:15:27 <phantomcircuit> it's just the txid/n UTXO right
188 2013-11-30 03:15:30 <cfields> rather than at an arbitrary split
189 2013-11-30 03:15:42 <cfields> so i think it could safely replace the other one
190 2013-11-30 03:16:09 <gmaxwell> phantomcircuit: and an index of blocks, and optionally an index of all transactions.
191 2013-11-30 03:16:28 <madthanu> cfields: looking at Sync(), have some difficulty understanding it ... my brain really is small
192 2013-11-30 03:16:47 <phantomcircuit> gmaxwell, the entire database with txindex is only 300 MB
193 2013-11-30 03:16:51 <cfields> i'm not quite sure what to do about it. Something about his fix made me uneasy, and I couldn't figure out what. I finally realized to night that it leaves the tail of the write hanging.
194 2013-11-30 03:17:17 <phantomcircuit> gmaxwell, it would almost be better if we did an append only journal until we hit 500 MB and then rewrite the entire file
195 2013-11-30 03:17:22 <gmaxwell> phantomcircuit: no. the txindex is 1.4 gbyte alone.
196 2013-11-30 03:17:43 <phantomcircuit> oh i didn't see blocks/index
197 2013-11-30 03:18:12 <gmaxwell> phantomcircuit: we have to support atomic batch updates, and random access.. though what you're describing is kinda how leveldb works.
198 2013-11-30 03:18:14 <phantomcircuit> still though that's small enough that leveldbs multi layered sorted tables approach is probably overkill
199 2013-11-30 03:19:01 <cfields> so the scenario is: append a file with new data, let it finish the Put(), then kill -9
200 2013-11-30 03:19:16 <phantomcircuit> possibly a complete rewrite of leveldb with an eye for reliability and consistency over raw speed is in order?
201 2013-11-30 03:19:20 <madthanu> cfields: oh right, now get it
202 2013-11-30 03:19:28 <phantomcircuit> the current leveldb code is clearly geared towards raw speed at all costs
203 2013-11-30 03:19:37 <cfields> if the last write straddles the boundary, it won't hit the newly added msync
204 2013-11-30 03:21:04 <madthanu> cfields: right ... so, on pkill -9, things get unmapped, and that might be a problem
205 2013-11-30 03:21:32 <cfields> that's my thought process, anyway. It's really hard to test without being able to reproduce
206 2013-11-30 03:21:52 <phantomcircuit> can we just disable mmap entirely?
207 2013-11-30 03:21:59 <madthanu> phantomcircuit: if mere mortals try to do that, they end up achieving speeds equivalent to berkeleydb :) the problem is we have only mere mortals
208 2013-11-30 03:22:01 <cfields> anyway, toffoo's new data backs up that theory, i believe
209 2013-11-30 03:22:12 <phantomcircuit> madthanu, uh yeah no
210 2013-11-30 03:22:16 <madthanu> phantomcircuit: that was about a reliable leveldb that is not fast
211 2013-11-30 03:22:33 <phantomcircuit> i've written a journal that does 250k writes/second in java easy
212 2013-11-30 03:22:56 <cfields> hehe, java. that's cute :)
213 2013-11-30 03:23:06 <madthanu> phantomcircuit: hmmm ... you the man. would love to check the code some day though.
214 2013-11-30 03:23:18 <madthanu> phantomcircuit: or woman, sorry
215 2013-11-30 03:23:25 <phantomcircuit> cfields, it was for an exchange so c/c++ was basically out of the question
216 2013-11-30 03:23:34 <phantomcircuit> i dont have enough eyeballs to verify the code
217 2013-11-30 03:23:58 <madthanu> cfields: see, the thing is, with "pkill -9", if not-flushing-dirty-mmap-data is a problem
218 2013-11-30 03:24:19 <phantomcircuit> cfields, and actually the raw orderbook was faster than my nearly exact copy c++ implementation because it delayed free() indefinitely
219 2013-11-30 03:24:21 <madthanu> cfields: that's equivalent to a system-crash scenario, and leveldb is supposed to work around that
220 2013-11-30 03:24:58 <phantomcircuit> madthanu, leveldbs documented guarantees are wrong, it's a bug
221 2013-11-30 03:25:05 <phantomcircuit> stuff has bugs
222 2013-11-30 03:25:24 <madthanu> phantomcircuit: agreed
223 2013-11-30 03:25:52 <madthanu> phantomcircuit: stupid question, but ever read an interesting research paper?
224 2013-11-30 03:26:07 <phantomcircuit> the ceph paper is interesting
225 2013-11-30 03:26:29 <phantomcircuit> most research papers are either indecipherable gibberish to me or really boring
226 2013-11-30 03:27:11 <madthanu> you should read the "LevelDB" part of this one: http://research.cs.wisc.edu/adsl/Publications/appconsistency-hotdep13.pdf
227 2013-11-30 03:27:51 <phantomcircuit> why i've actually read the leveldb code
228 2013-11-30 03:27:58 <phantomcircuit> their journal doesn't have sequence numbers
229 2013-11-30 03:28:07 <phantomcircuit> they use a fairly weak crc32 checksum
230 2013-11-30 03:28:22 <phantomcircuit> the journal reading code ignores invalid records
231 2013-11-30 03:28:47 <phantomcircuit> because there are actually invalid records at the end of each journal used to preallocate so the file is contiguous on disk
232 2013-11-30 03:29:08 <phantomcircuit> but the way it's implemented it will also skip invalid records in the middle of the journal
233 2013-11-30 03:29:23 <phantomcircuit> those are my major concerns
234 2013-11-30 03:30:18 <madthanu> they don't verify checksums normally, even ... you have to be in a paranoid mode to do that
235 2013-11-30 03:30:37 <phantomcircuit> that's just silly
236 2013-11-30 03:31:10 <madthanu> look at the "checksums" section of http://leveldb.googlecode.com/svn/trunk/doc/index.html
237 2013-11-30 03:32:01 <madthanu> but beyond all that, leveldb seems to be actually better than many other software out there
238 2013-11-30 03:32:10 <phantomcircuit> crc32 is only marginally faster than sha1
239 2013-11-30 03:32:20 <roconnor> really?
240 2013-11-30 03:32:26 <phantomcircuit> roconnor, yup
241 2013-11-30 03:32:29 <roconnor> wow
242 2013-11-30 03:32:43 <roconnor> does crc32 do error correction?
243 2013-11-30 03:33:03 <phantomcircuit> no
244 2013-11-30 03:33:03 <phantomcircuit> you mean forward error correction?
245 2013-11-30 03:33:08 <phantomcircuit> it's a checksum
246 2013-11-30 03:35:28 <phantomcircuit> roconnor, ok so it's maybe 2x faster
247 2013-11-30 03:35:41 <gmaxwell> hm? crc32 with the right generator can be much faster than sha1 on current hardware (that has acceleration for the iscsi / sctp one)
248 2013-11-30 03:36:20 <gmaxwell> madthanu: we run in the paranoid mode.
249 2013-11-30 03:36:50 <sipa> phantomcircuit: can you voice your concerns about consistency on the leveldb issue tracker?
250 2013-11-30 03:37:10 <HaltingState> gmaxwell, i just found arithmetic error in protoshares hashing; doing bitshift wrong...
251 2013-11-30 03:37:18 <phantomcircuit> sipa, yeah
252 2013-11-30 03:37:31 <cfields> we run with crc enabled, not paranoid mode though
253 2013-11-30 03:37:31 <sipa> HaltingState: wtf is protoshares?
254 2013-11-30 03:37:50 <madthanu> gmaxwell: oh. didn't know that.
255 2013-11-30 03:38:06 <phantomcircuit> gmaxwell, sha1 takes ~0.35 usec on an i3-2100 under python (it's a c module) zlic.crc32 takes ~0.1 usec and is also a cmodule
256 2013-11-30 03:38:20 <phantomcircuit> that's ~1m iterations
257 2013-11-30 03:38:27 <HaltingState> sipa, some weirdo altcoin with an interesting PoW function that is preorder for bitshares with is something like mastercoin but different
258 2013-11-30 03:38:34 <madthanu> if anyone could say, this information could be pretty useful
259 2013-11-30 03:38:41 <phantomcircuit> in practice on x86 hardware the "standard" crc32 zlib uses is only about 2x faster
260 2013-11-30 03:39:32 <phantomcircuit> gmaxwell, i did a bunch of testing in java for this with crc32/adler32/sha1/md5/sha256/sha512 and decided on sha1 in the end
261 2013-11-30 03:39:39 <madthanu> in the VerifyDB call, does bitcoin-qt retrieve stuff that are old, but had not been verified by a previous invocation of VerifyDB?
262 2013-11-30 03:39:42 <warren> HaltingState: you could have just said "handwaving"
263 2013-11-30 03:39:49 <phantomcircuit> (i wanted to keep the maximum record size < 512 bytes)
264 2013-11-30 03:40:23 <sipa> madthanu: yes, it only runs at startup
265 2013-11-30 03:40:50 <sipa> madthanu: but all it does is attempt to roll the chainstate in memory back
266 2013-11-30 03:40:54 <madthanu> sipa: no, i do not mean that. pretty long question, can i pm you?
267 2013-11-30 03:41:00 <sipa> yes
268 2013-11-30 03:41:47 <gmaxwell> phantomcircuit: "in java" well there you go. :P
269 2013-11-30 03:42:55 <phantomcircuit> gmaxwell, i'll give it a try in c later but i doubt the result will be significantly different
270 2013-11-30 03:43:17 <phantomcircuit> either was 0.35 usec when the average read is 2usec is reasonable to get to use a much better checksum
271 2013-11-30 03:43:33 <alex_fun> hi folks
272 2013-11-30 03:43:54 <alex_fun> who knows is there any general crypto dev channel or forum somewhere?
273 2013-11-30 03:44:04 <alex_fun> I tried litecoin-dev is quiet :D
274 2013-11-30 03:45:28 <warren> alex_fun: you are asking things that nobody cares about, and has been discussed a hundred times elsewhere.
275 2013-11-30 03:46:14 <alex_fun> warren yes I agree
276 2013-11-30 03:46:38 <alex_fun> warren have they been discussed on forums? or log can be found somewhere
277 2013-11-30 03:46:50 <alex_fun> then I can simply learn from it :)
278 2013-11-30 03:51:36 <toffoo> hi warren, my bootstrap.dat torrent just finished, should I try a fresh reindex now with -OMG6 or do you have another build coming?
279 2013-11-30 03:51:57 <cfields> toffoo: please use the current build
280 2013-11-30 03:52:16 <cfields> then if that corrupts, you can try the new one
281 2013-11-30 03:52:26 <cfields> (if you're willing to be a test-dummy, of course)
282 2013-11-30 03:52:41 <cfields> seems you're the only one around here who can reliably reproduce
283 2013-11-30 03:52:55 <toffoo> okie
284 2013-11-30 03:53:06 <warren> I'll make a build with that patch.
285 2013-11-30 03:56:45 <madthanu> toffoo: if you would be even kinder, perhaps the entire set of data files after the corruption?
286 2013-11-30 03:56:58 <madthanu> toffoo: instead of just the chainstate directory?
287 2013-11-30 03:57:40 <toffoo> madthanu you mean the entire blockchain data files?
288 2013-11-30 03:57:55 <madthanu> toffoo: yeah ... I know it's a lot
289 2013-11-30 03:58:04 <madthanu> toffoo: but it'd be really helpful
290 2013-11-30 03:58:21 <madthanu> toffoo: cuz I can then just run my bitcoin-qt on top of them, and see what is going through
291 2013-11-30 03:58:27 <toffoo> well, I did it once to warren a few days ago after one of the earlier version crashes,
292 2013-11-30 03:58:42 <toffoo> and it takes quite a while,
293 2013-11-30 03:58:52 <sipa> metric: chainstate and blocks are independent
294 2013-11-30 03:58:58 <madthanu> toffoo: hmmm ... is the warren version still around?
295 2013-11-30 03:59:20 <sipa> if you have an up to date blocksdir, you shouls be able to copy toffoo's chainstate over yours and rum
296 2013-11-30 03:59:35 <sipa> eh, madthanu
297 2013-11-30 04:00:14 <toffoo> madthanu probably, ask him for a link I uled a 7GB xz compressed image to his server
298 2013-11-30 04:00:28 <madthanu> sipa: oh ... i actually don't, but i can sync up
299 2013-11-30 04:00:35 <madthanu> toffoo: cool
300 2013-11-30 04:00:48 <madthanu> warren: any chance you have toffoo's image still around?
301 2013-11-30 04:00:53 <warren> I deleted it.
302 2013-11-30 04:01:02 <warren> because the blocks are irrelevant
303 2013-11-30 04:01:07 <toffoo> I did this when a working theory was that perhaps my blockdata from 0.7.2 (which was continually synced since 0.3) was bad in a unique way
304 2013-11-30 04:01:24 <toffoo> I think, if you really want it,
305 2013-11-30 04:01:45 <toffoo> it makes most sense for me to try this new build, with the clean bootstrap.dat data,
306 2013-11-30 04:01:59 <sipa> the block data should not matter at all
307 2013-11-30 04:01:59 <toffoo> and if that corrupts on me I can reup everything again for you
308 2013-11-30 04:02:06 <warren> toffoo: what exactly happened before this crash?
309 2013-11-30 04:02:18 <warren> toffoo: sleep/suspend, lost power, system crash?
310 2013-11-30 04:02:32 <toffoo> warren which crash you referring to now, the most recent?
311 2013-11-30 04:02:39 <warren> toffoo: the first one with OMG6
312 2013-11-30 04:02:41 <sipa> all 0.8 does is scan for ranges of bytes in the old block files thatlook like blocks, and process them as if they were received from the network
313 2013-11-30 04:02:47 <madthanu> the latest chainstate directory with SIGSEGV fault, the database can actually be iterated through without any problem
314 2013-11-30 04:03:17 <madthanu> the crash happens only when you try to Get() using transactions from the block database
315 2013-11-30 04:03:30 <madthanu> so I'm looking for the magic transaction hashes that resulted in the crash
316 2013-11-30 04:03:35 <sipa> wait, what?
317 2013-11-30 04:03:35 <toffoo> warren https://github.com/bitcoin/bitcoin/issues/2770#issuecomment-29543244
318 2013-11-30 04:04:58 <madthanu> sipa, wtogami uploaded toffoo's chainstate after the most recent fault ... right?
319 2013-11-30 04:05:19 <sipa> i haven't followed in detail
320 2013-11-30 04:06:31 <sipa> madthanu: wait, the blocks/index database is corrupted, not the chainstate?
321 2013-11-30 04:06:40 <madthanu> sipa: well, anyway, afaik, that chainstate directory itself doesn't seem to have a problem ...
322 2013-11-30 04:07:36 <madthanu> sipa: so my *wild* guess would be something with the blocks is corrupted, and so bitcoin-qt uses the corrupted blocks to access chainstate in a stupid (NULL pointer) way
323 2013-11-30 04:08:06 <madthanu> repeat, *wild* guess
324 2013-11-30 04:10:10 <cfields> madthanu: er, you can dump the chainstate and see what it's trying to read
325 2013-11-30 04:10:23 <cfields> hint: it's a key, the a huge empty block
326 2013-11-30 04:10:31 <cfields> *then
327 2013-11-30 04:11:11 <madthanu> cfields: i can dump it, it's not readable characters, but there are keys and then there are values ...
328 2013-11-30 04:11:23 <madthanu> are they supposed to be readable (ascii) characters?
329 2013-11-30 04:11:45 <madthanu> ascii 0-127, that is
330 2013-11-30 04:11:45 <sipa> madthanu: GetCoins only serialized the txid (a fixed size 32-byte encoded 256-bit numbers)
331 2013-11-30 04:11:52 <sipa> to be oassed as key
332 2013-11-30 04:12:11 <madthanu> sipa: yeah, true ... i'm barking on the wrong tree then
333 2013-11-30 04:12:18 <sipa> neither keys or values are supposed to be any specific encoding
334 2013-11-30 04:12:24 <sipa> it's all binary data
335 2013-11-30 04:12:33 <cfields> madthanu: dump 011141.log
336 2013-11-30 04:12:47 <madthanu> cfields: trying that
337 2013-11-30 04:15:52 <sipa> ACTION afk
338 2013-11-30 04:16:18 <madthanu> cfields: darn, deleted the directory, give me more time
339 2013-11-30 04:20:34 <madthanu> cfields: errr ... it's not filled with zeros for me
340 2013-11-30 04:20:40 <madthanu> cfields: i think
341 2013-11-30 04:20:57 <cfields> madthanu: sorry, i was thinking of something else. That one has a key but no value
342 2013-11-30 04:20:58 <madthanu> cfields: it could be though, since it's a log file ... it shouldn't be a bother
343 2013-11-30 04:21:13 <madthanu> cfields: but there's something really really wrong here
344 2013-11-30 04:21:14 <cfields> and the key is very suspicious. Notice how many null bytes at the end
345 2013-11-30 04:21:44 <madthanu> well, that might be some valid binary representation, right?
346 2013-11-30 04:24:16 <madthanu> cfields: I don't know ...
347 2013-11-30 04:25:40 <cfields> madthanu: same.
348 2013-11-30 04:28:42 <cfields> erm, that chainstate doesn't crash for me
349 2013-11-30 04:28:57 <cfields> (i hadn't tried it, just dumped it)
350 2013-11-30 04:29:55 <warren> http://download1.rpmfusion.org/~warren/bitcoin-0.8.5-OMG6b/macosx/
351 2013-11-30 04:30:10 <warren> https://github.com/litecoin-project/bitcoinomg/commits/0.8.5-OMG6b
352 2013-11-30 04:31:18 <cfields> ok, headed off for tonight
353 2013-11-30 04:31:28 <cfields> i'll check the forum before bed
354 2013-11-30 04:36:54 <ryan-c> does using -txindex and -reindex re-download the blockchain?
355 2013-11-30 04:37:13 <kjj> no
356 2013-11-30 04:38:51 <ryan-c> I just restarted with it and it's showing zero blocks. I just need to wait for the disk to finish thrashing?
357 2013-11-30 04:42:50 <Evilmax> sorry, i do not remember: what is the command (windows prompt) for start bitcoind-qt as daemon?
358 2013-11-30 04:44:19 <ryan-c> On linux it's bitcoind -server -daemon
359 2013-11-30 04:45:46 <toffoo> ok thanks warren I'll start reindexing bootstrap.dat with -OMG6b now...
360 2013-11-30 04:46:27 <Evilmax> ok
361 2013-11-30 04:46:44 <Evilmax> i do not need command line option
362 2013-11-30 04:47:01 <Evilmax> it's sufficient set server=1 in config file
363 2013-11-30 04:47:14 <Evilmax> it will star anyway as server
364 2013-11-30 04:47:20 <Evilmax> start
365 2013-11-30 05:21:49 <bitanarchy> is megacoin a healthy coin?
366 2013-11-30 05:27:28 <alex_fun> lol
367 2013-11-30 05:38:14 <yhusha> so whats the deal with the altcoin projects that were growing popular yet each seemed to be halted at around the merkel hash point in the tut's?
368 2013-11-30 05:39:52 <yhusha> who has had any success?
369 2013-11-30 05:44:11 <yhusha> I get it.. it's an f u/
370 2013-11-30 05:46:35 <gavinandresen> merkel hash poin in the tut's ????
371 2013-11-30 05:51:29 <bitanarchy> isnt megacoin the coin that is going to have zerocoin on top of it? or will they make a new coin for that?
372 2013-11-30 06:22:26 <cortexA9> hello
373 2013-11-30 06:43:19 <midnightmagic> it is possible to optimize berkeleydb *significantly* over the baseline btw. :)
374 2013-11-30 06:51:40 <BustyLoli-Chan> thank you all for all of your help
375 2013-11-30 06:51:46 <BustyLoli-Chan> look what you have done to the world http://bustyloli.ch/storage/BTCgamble.php
376 2013-11-30 06:52:36 <cfields> gavinandresen: ping
377 2013-11-30 06:52:47 <gavinandresen> cfields: whazzup
378 2013-11-30 06:53:06 <cfields> gavinandresen: you said you had qt5 building on osx before autotools
379 2013-11-30 06:53:14 <cfields> does that mean you were using downloaded binaries?
380 2013-11-30 06:53:33 <gavinandresen> cfields: uhhâ¦. I don't remember. Let me see if I can find out
381 2013-11-30 06:53:40 <cfields> ok
382 2013-11-30 06:54:00 <cfields> i have win32 building and working. trying to decide how ambitious to be for the first round
383 2013-11-30 06:54:51 <BustyLoli-Chan> holy shit bitcoind is attacking e.e
384 2013-11-30 06:55:02 <gavinandresen> cfields: I've got a Qt5.0.2/5.0.2/clang_64/bin directory that I think I was using and that I compiled back in July
385 2013-11-30 06:56:21 <cfields> gavinandresen: built from source using macx-clang, then?
386 2013-11-30 06:56:33 <cfields> well, side-bar..
387 2013-11-30 06:56:51 <cfields> i used 5.1.1 for win32. You oppose that for any reason?
388 2013-11-30 06:57:07 <gavinandresen> cfields: fine by me, wumpus is the QT expert though
389 2013-11-30 06:57:24 <gavinandresen> ⦠he might have reasons to prefer Qt5.something
390 2013-11-30 06:58:01 <cfields> ok
391 2013-11-30 06:58:09 <wumpus> cfields: I always prefer the most recent qt version :p
392 2013-11-30 06:58:16 <cfields> wumpus: ah, you're around...
393 2013-11-30 06:58:33 <cfields> wumpus: how were you using qt5 before autotools?
394 2013-11-30 06:58:48 <wumpus> having said that, we do need to keep qt4 compatibility around for a while
395 2013-11-30 06:58:54 <wumpus> cfields: qmake
396 2013-11-30 06:59:05 <cfields> sure, i've added an --enable-qt5
397 2013-11-30 06:59:34 <cfields> (which will eventually become --enable-qt4, i assume)
398 2013-11-30 07:00:12 <cfields> actually, forget that. the semantics bikeshedding can come later. I added the ability to specify :)
399 2013-11-30 07:00:12 <wumpus> indeed
400 2013-11-30 07:00:28 <warren> what OS/distro needs qt?
401 2013-11-30 07:00:30 <cfields> wumpus: you build primarily on win32?
402 2013-11-30 07:00:30 <warren> qt4
403 2013-11-30 07:00:55 <wumpus> cfields: primarily Linux (Ubuntu)
404 2013-11-30 07:01:14 <wumpus> diapolo is the win32 guy
405 2013-11-30 07:01:17 <cfields> ah, right. diapolo (sp?) is the win32 guy?
406 2013-11-30 07:01:20 <cfields> ok
407 2013-11-30 07:01:21 <Luke-Jr> cfields: shouldn't that be --with-qt5?
408 2013-11-30 07:01:21 <wumpus> yes
409 2013-11-30 07:01:31 <wumpus> but I can do win32 builds/tests if needed
410 2013-11-30 07:01:52 <cfields> wumpus: i'm mainly concerned with how people have acquired qt5 in the past
411 2013-11-30 07:02:01 <cfields> since historically it's been tough, especially on osx
412 2013-11-30 07:02:12 <wumpus> cfields: diapolo builds everything from source
413 2013-11-30 07:02:27 <cfields> ok
414 2013-11-30 07:02:48 <cfields> i have a gitian recipe for qt5 that will spit out a prefix, similar to how it works now. And they work in parallel
415 2013-11-30 07:02:51 <cfields> does that suffice?
416 2013-11-30 07:03:02 <wumpus> which is also what's recommended if you build on windows, as there are gross incompatibilities between different mingw releases
417 2013-11-30 07:03:05 <cfields> or will i need to account for how people build themselves for win32?
418 2013-11-30 07:03:38 <wumpus> cfields: no need to account for that, I guess the configure should work on win32 but how people get the deps is up to them
419 2013-11-30 07:04:29 <cfields> wumpus: well it's pretty limited for win32. i really have to assume everything, since we can't count on discovery in the environment
420 2013-11-30 07:04:42 <cfields> i assume these days everyone builds in gitian, then stashes away the results to build against?
421 2013-11-30 07:05:51 <wumpus> cfields: if autodetection is not possible, best to let them specify everything manually then
422 2013-11-30 07:06:10 <cfields> wumpus: sure, it can all be specified. It just makes for a really long/ugly configure line
423 2013-11-30 07:06:16 <cfields> but sure, no patches needed for that
424 2013-11-30 07:06:28 <wumpus> right, someone could update the build-msw.md accordingly, but building in gitian is indeed priority one
425 2013-11-30 07:06:37 <cfields> ok
426 2013-11-30 07:07:14 <cfields> gavinandresen: mind seeing if you can dig out how you built? I'm happy to work up a build-from-source for osx, but i have a feeling that using the official binary dist will be an easier first step
427 2013-11-30 07:08:00 <cfields> and wumpus: i'll make ubuntu 2nd priority after windows, since I know you're waiting on it
428 2013-11-30 07:08:25 <wumpus> cfields: ok great!
429 2013-11-30 07:08:46 <gavinandresen> cfields: I'll email you my InstallationLog.txt
430 2013-11-30 07:09:17 <cfields> gavinandresen: thanks.
431 2013-11-30 07:10:55 <gavinandresen> cfields: ⦠I only see .cpp files for examples, maybe that IS a binary download/install....
432 2013-11-30 07:11:30 <cfields> gavinandresen: i know when i was poking at qt5 on osx, that was the only reasonable path
433 2013-11-30 07:11:41 <cfields> without substantial blood/sweat/tears, anyway
434 2013-11-30 07:14:22 <cfields> yea...
435 2013-11-30 07:14:28 <cfields> /Users/bld.qt/bamboo-agent-home/xml-data/build-dir/DQTC-RELBUILD502LGPL-OSX106/
436 2013-11-30 07:14:43 <cfields> unless that's you somehow, that smells like a buildbot
437 2013-11-30 07:15:32 <cfields> I'll aim for that to begin with.
438 2013-11-30 07:16:02 <cfields> gavinandresen: suggestions on how to discuss/debate min osx requirements in a civil+productive way?
439 2013-11-30 07:17:38 <gavinandresen> why would it get uncivil? are there two violently opposed viewpoints?
440 2013-11-30 07:18:41 <gavinandresen> rough consensus seems to be OSX 10.6 64-bit as min osx requirement, unless I'm missing something
441 2013-11-30 07:19:17 <cfields> that's fine, i thought you were prepared to push for 10.7
442 2013-11-30 07:19:27 <gavinandresen> nope
443 2013-11-30 07:19:29 <cfields> since 10.6 can be 32bit as well
444 2013-11-30 07:20:25 <wumpus> cfields: do you predict any difficulties for win 64?
445 2013-11-30 07:20:28 <gavinandresen> we're probably going to drop support for 32 bit on all platforms, where "drop support" means "if you have a 32-bit machine, you probably can't sync the blockchain because you'll run out of memory and crash. Sorry."
446 2013-11-30 07:21:44 <wumpus> right, it needs a lot of virtual memory
447 2013-11-30 07:22:05 <Luke-Jr> gavinandresen: â¦
448 2013-11-30 07:22:10 <cfields> er
449 2013-11-30 07:22:13 <lianj> sorry for the stupid question, but why?
450 2013-11-30 07:22:19 <Luke-Jr> 64-bit machine does not imply 64-bit virtual memory
451 2013-11-30 07:22:21 <lianj> leveldb?
452 2013-11-30 07:22:33 <wumpus> yes, probably leveldb
453 2013-11-30 07:22:36 <cfields> i'd be opposed to that enough to help fix problem areas
454 2013-11-30 07:22:47 <cfields> mainly for the sake of arm devices
455 2013-11-30 07:22:55 <Luke-Jr> I run 32-bit.
456 2013-11-30 07:23:11 <upb> not for long :)
457 2013-11-30 07:23:14 <gavinandresen> Luke-Jr: okey dokey. can you sync the chain from scratch? How much memory?
458 2013-11-30 07:23:17 <wumpus> leveldb makes a lot of use of mmap, though they plan to reduce that
459 2013-11-30 07:23:27 <Luke-Jr> gavinandresen: I've never had problems doing so. 16 GB RAM
460 2013-11-30 07:23:35 <gmaxwell> Luke-Jr: go try it again now.
461 2013-11-30 07:23:51 <Luke-Jr> network or bootstrap?
462 2013-11-30 07:23:56 <gmaxwell> it's pretty common for vpses, not even especially limited ones to be 32 bit, just because it reduces their base memory usage when they're doing nothing.
463 2013-11-30 07:24:07 <gmaxwell> Luke-Jr: network, you'll probably survive on a bootstrap
464 2013-11-30 07:24:25 <cfields> gavinandresen: heh, this is what i was trying to avoid...
465 2013-11-30 07:24:35 <Luke-Jr> gmaxwell: then wouldn't headers-first solve it?
466 2013-11-30 07:24:36 <cfields> i'd prefer to stay on target for osx for now..
467 2013-11-30 07:24:37 <gmaxwell> Luke-Jr: we've had several reports lately of people failing a network sync on 32 bit because they run out of address space. Presumably after a block on the network makes them fetch a bunch of orphans.
468 2013-11-30 07:24:47 <gmaxwell> yes, headers first would solve that.
469 2013-11-30 07:24:49 <cfields> unless sweeping changes are planned for .9 ?
470 2013-11-30 07:24:53 <gavinandresen> Patches welcome RE: telling users in advance under what conditions they shouldn't bother trying to use the software because it will crash
471 2013-11-30 07:24:55 <gmaxwell> if thats the cause at leas.t
472 2013-11-30 07:25:03 <wumpus> in any case when gavinandresen says 'drop support for 32 bit' he doesnt mean to actually make it impossible to build for, just to recommend against it
473 2013-11-30 07:25:29 <wumpus> because *right now* it doesn't work very well
474 2013-11-30 07:25:56 <gavinandresen> Right. When I say "need 64 bit" I really mean something else. I have no idea what that something else is....
475 2013-11-30 07:26:21 <wumpus> with later patches to leveldb and such it may well be possible to use 32 bit happily again
476 2013-11-30 07:26:22 <cfields> fair enough. and 64bit requirement seems more than reasonable for osx.
477 2013-11-30 07:26:50 <cfields> i'd have a hard time being that definitive elsewhere, but it seems reasonable in that case
478 2013-11-30 07:27:16 <wumpus> people are very welcome to do actual memory profiling and optimization
479 2013-11-30 07:28:46 <cfields> ok. i'll assume 64bit for osx then. I really don't care either way, i just don't want to have to do it twice :)
480 2013-11-30 07:29:18 <wumpus> yes
481 2013-11-30 07:29:46 <lianj> oh wait im confused, osx only?
482 2013-11-30 07:30:16 <wumpus> for the pre-built osx binaries, yes
483 2013-11-30 07:30:36 <cfields> lianj: i'm doing qt5 stuff. .9 will use qt5 apparently. qt is no fun to build, so i'd prefer to only do it once.
484 2013-11-30 07:30:50 <lianj> ah makes sense
485 2013-11-30 07:31:02 <wumpus> I suppose it will remain possible building on older osx if people really want to...
486 2013-11-30 07:31:55 <cfields> wumpus: probably not without a good bit of patching. qt is a nightmare to build.
487 2013-11-30 07:32:09 <cfields> but if they have their own qt in place, sure
488 2013-11-30 07:32:17 <wumpus> I'm not worried about qt, just bitcoin itself
489 2013-11-30 07:32:32 <cfields> yea, no problem there
490 2013-11-30 07:33:50 <cfields> ok. i'll start pushing up PRs early and ugly, for those waiting on them
491 2013-11-30 07:34:50 <cfields> zzz time, nnite
492 2013-11-30 07:34:54 <wumpus> great
493 2013-11-30 07:34:56 <wumpus> sleep well, later
494 2013-11-30 09:49:21 <toffoo> reindexing v0.8.5-OMG6b from bootstrap.dat on my mac just finished, so far so good
495 2013-11-30 09:50:58 <madthanu> toffoo: great. some ray of hope then.
496 2013-11-30 10:20:27 <skinnkavaj> Whats a better way to protect from ddos than using cloudflare?
497 2013-11-30 10:20:36 <BustyLoli-Chan> SOLO MINE :D
498 2013-11-30 10:21:25 <BustyLoli-Chan> make every member of the pool also a host
499 2013-11-30 10:21:44 <skinnkavaj> i am talking about running an exchange
500 2013-11-30 10:21:51 <BustyLoli-Chan> :O
501 2013-11-30 10:21:53 <skinnkavaj> like btc-e
502 2013-11-30 10:22:13 <porquilho> i have in a cell something like this a;b;c is there any function in Excel to get the 3rd element (c)?
503 2013-11-30 10:22:21 <skinnkavaj> but they use cloudflare, so cloudflare can fuck them up
504 2013-11-30 10:22:37 <a_meteor> skinnkavaj, getting real ddos protection
505 2013-11-30 10:22:44 <a_meteor> but that's a lot more expensive than cloudfare
506 2013-11-30 10:22:46 <skinnkavaj> a_meteor: what is real ddos proection?
507 2013-11-30 10:22:49 <BustyLoli-Chan> have you tried $C$3
508 2013-11-30 10:23:05 <porquilho> $C$3 ?
509 2013-11-30 10:23:10 <a_meteor> a provider that gives you an IP and tunnels clean traffic back to you, for instance
510 2013-11-30 10:23:13 <porquilho> hmm going to try
511 2013-11-30 10:23:32 <a_meteor> there are quite a few, but for the life of me can't remember a single one
512 2013-11-30 10:23:51 <skinnkavaj> a_meteor: isn't that the same as cloudflare?
513 2013-11-30 10:23:54 <porquilho> doesnt work BustyLoli-Chan
514 2013-11-30 10:24:21 <a_meteor> sorta, but they also do stuff at the http layer
515 2013-11-30 10:24:30 <BustyLoli-Chan> should work
516 2013-11-30 10:24:51 <lianj> a_meteor: cloudflare too, which is devil
517 2013-11-30 10:24:52 <BustyLoli-Chan> if you have a formula =$C$3 will absolutely give you cell C#
518 2013-11-30 10:24:54 <BustyLoli-Chan> * C3
519 2013-11-30 10:25:02 <BustyLoli-Chan> even if you drag and copy it about
520 2013-11-30 10:25:38 <a_meteor> you have to trust cloudfare won't do anything evil, ever, with ssl too
521 2013-11-30 10:26:05 <porquilho> BustyLoli-Chan that doesnt work
522 2013-11-30 10:26:06 <a_meteor> you have to use one of their certs
523 2013-11-30 10:26:10 <Happzz> when i buy a large amount of bitcoins - say 5 or so, would it make sense to receive them all to a single address, or ask the other party to split them into like 5 addresses or something
524 2013-11-30 10:26:23 <Happzz> privacy-wise, fees-wise in the future when i want to send them, etc
525 2013-11-30 10:26:27 <BustyLoli-Chan> http://i.imgur.com/ShnWs7X.png
526 2013-11-30 10:26:57 <a_meteor> Happzz, if you plan to not make >1 BTC purchases which would join your addresses together, I could see a privacy argument
527 2013-11-30 10:27:33 <porquilho> BustyLoli-Chan: Imagine I have this on a cell 'a;b;c' I want the 'c' value
528 2013-11-30 10:27:42 <porquilho> not all 'a;b;c'
529 2013-11-30 10:28:24 <Happzz> a_meteor you mean <1 BTC sells?
530 2013-11-30 10:28:33 <Happzz> i can't know what my future transactions will be.
531 2013-11-30 10:28:54 <a_meteor> well the moment you want to spend >1 BTC, your inputs would link at least two addresses together
532 2013-11-30 10:28:55 <Happzz> however, if my future tx will join them - it could be seen together in first place if i didn't split
533 2013-11-30 10:29:12 <Happzz> if they wont - do i benefit anything?
534 2013-11-30 10:30:38 <a_meteor> can't wait until coinjoin is used more to solve some of this :)
535 2013-11-30 10:34:50 <porquilho> BustyLoli-Chan: I done it. It's Excell menu, Data -> Text to Columns
536 2013-11-30 10:44:37 <Happzz> gmaxwell https://bitcointalk.org/index.php?topic=279249.0
537 2013-11-30 10:44:40 <BustyLoli-Chan> lol
538 2013-11-30 10:44:46 <Happzz> gmaxwell you should get some nobelprize or something, seriously
539 2013-11-30 10:44:53 <BustyLoli-Chan> I don't think it has to be that complex
540 2013-11-30 10:45:26 <Happzz> technically, i can't imagine it should be THAT complicated to make this part of bitcoin-qt, or some other tiny software
541 2013-11-30 10:45:50 <Happzz> every small community of bitcoin users could run their own daemon to take inputs from users and do the joint work
542 2013-11-30 10:46:06 <Happzz> "stupid" client software would send in the data. possibly even bitcoin-qt itself.
543 2013-11-30 11:13:04 <midnightmagic> Is there any particular reason why a bitcoind 0.8.5 on an i686 machine on one side would have block index issues on another v0.8.5 i686 machine?
544 2013-11-30 11:13:54 <Emcy> how do you mean
545 2013-11-30 11:14:35 <midnightmagic> I have a functional and working bitcoind on an i686 32-bit machine. I stop bitcoind. I rsync chainstate/ and blocks/ into another machine, and then start bitcoind there. It complains bitterly and demands I rebuild the block indices.
546 2013-11-30 11:15:05 <midnightmagic> ... the rsync failed didn't it..
547 2013-11-30 11:15:27 <Emcy> something with the database got screwed up
548 2013-11-30 11:15:37 <midnightmagic> yeah but how, it's the same executable.
549 2013-11-30 11:15:50 <Emcy> u sure bitcoin was fully exited
550 2013-11-30 11:16:00 <midnightmagic> yeah I always check ps
551 2013-11-30 11:16:19 <Emcy> strange it should work
552 2013-11-30 11:16:28 <midnightmagic> I agree!!
553 2013-11-30 11:16:36 <midnightmagic> ah, i'll figure it out.
554 2013-11-30 11:16:49 <midnightmagic> I'll let you know. I know I hate it when people come in with questions and then never update me.
555 2013-11-30 11:17:25 <Emcy> MIGHT be bad ram on the target machine or somthing
556 2013-11-30 11:17:38 <Emcy> i686 hardware pretty old now
557 2013-11-30 11:18:04 <midnightmagic> I think it's all okay in that department, there's no evidence of it in anything else, it's rock-solid.
558 2013-11-30 11:18:22 <midnightmagic> Like not even those weird crashes where you scratch your head and never find out why it happened.
559 2013-11-30 11:18:30 <gribble> 272273
560 2013-11-30 11:18:30 <midnightmagic> ;;bc,blocks
561 2013-11-30 11:19:53 <Emcy> hmm eligius spawns an 900kb block and a 350 post reddit thread about how the sky is falling
562 2013-11-30 11:20:57 <Emcy> I love how these people complaining about muh 7tps limit are seemingly also the ones complaining about omg 15gb blockchain this is an outrage
563 2013-11-30 11:22:50 <midnightmagic> Emcy: link?
564 2013-11-30 11:23:28 <Emcy> http://www.reddit.com/r/Bitcoin/comments/1rqexb/87898_kb_block_just_now/
565 2013-11-30 11:26:20 <Emcy> hmm it doesnt help that gavin weighed in with a unfiarly black and white representation of what block conservatives are saying.
566 2013-11-30 11:27:52 <Emcy> i dont think many people espouse 1mb forever, just cautiously raising it when we can be reasonably sure it wont damage the core network, by gathering some sort of metrics for that.
567 2013-11-30 11:31:29 <gmaxwell> The size-conservative view isn't 1MB forever, but it's size that doesn't outpace low cost hardware / bandwidth / or demand for blocksize (e.g. don't undermine the fee market); it's an acknowledgment that scarcity of is a _nessary_ part of the systems long term design as advertised, and that there is a tradeoff with decenteralization which must be navigated cautiously, ... and that there is room for and need for alternative methods of ...
568 2013-11-30 11:31:33 <wizkid057> i think Eligius is the only pool doing large blocks
569 2013-11-30 11:31:35 <gmaxwell> ... transacting which are currently under-developed.
570 2013-11-30 11:31:56 <wizkid057> everyone else is either 250 or 500KB
571 2013-11-30 11:33:04 <Emcy> wizkid057 yeah someone pointed out eligius is more likely to spit out hugeblox because the rest arnet
572 2013-11-30 11:35:09 <Emcy> gmaxwell my point is people dont seem to be understanding that tradeoff. And i guess they have to be educated somehow before someone just rolls a patched bitcoin with maxblocksize = 10000000 and furtively passes it around like a cigarette in a classroom, i guess
573 2013-11-30 11:36:12 <lianj> thanks eligius for mining 2k+ tx blocks
574 2013-11-30 11:36:37 <Emcy> yeah, when no one else will
575 2013-11-30 11:36:52 <lianj> why don't btw?
576 2013-11-30 11:37:52 <Emcy> no real reason afaik. Dont seem to affect orphaning that much
577 2013-11-30 11:38:47 <Emcy> whats the average block that comes out of p2pool?
578 2013-11-30 11:43:38 <wizkid057> Emcy: glad we could stir up reddit trouble, seems we're good at that
579 2013-11-30 11:45:30 <Emcy> they stir up thier own trouble
580 2013-11-30 11:46:50 <gmaxwell> Emcy: well it was only so big because it was stufffed full of inefficient satoshibones transactions :(
581 2013-11-30 11:47:26 <gmaxwell> oh actually it was only 50 of them, not that bad.
582 2013-11-30 11:47:38 <Emcy> satoshibones is a new one on me
583 2013-11-30 11:48:44 <Emcy> i had hoped enough people would copy the dice model that the profit for each of htem would be marginal and not worth it. I didnt count on growing the pie though
584 2013-11-30 11:49:32 <Emcy> not much we could do about it really. I wonder if its possible to whip up an angry reddit mob against the dice sites......
585 2013-11-30 11:49:57 <gmaxwell> well the overall volume of them is still _way_ down.
586 2013-11-30 11:50:34 <gmaxwell> Emcy: and no, its not. people will never be angry about dice sites so long as transaction fees exist.
587 2013-11-30 11:57:42 <Emcy> 67kb block from ghash.io
588 2013-11-30 11:57:59 <Emcy> pull your bloody socks up ffs
589 2013-11-30 12:50:21 <diki> Emcy:this is nothing
590 2013-11-30 12:50:38 <diki> recently, luke didn't include ANY transactions in one of his blocks
591 2013-11-30 12:50:54 <kjj> which block?
592 2013-11-30 12:51:09 <diki> It was a while ago, probably over 1000
593 2013-11-30 12:51:19 <diki> if not even over 2000 blocks ago
594 2013-11-30 12:51:34 <kjj> are you sure it was his block?
595 2013-11-30 12:51:55 <diki> yup it said eligius
596 2013-11-30 12:52:02 <kjj> what said eligius?
597 2013-11-30 12:52:30 <diki> kjj:Look at this one https://blockchain.info/block-index/442924
598 2013-11-30 12:52:35 <diki> oh oops
599 2013-11-30 12:52:39 <diki> that's not eligius
600 2013-11-30 12:52:44 <diki> but same thing
601 2013-11-30 12:54:39 <SomeoneWeird> diki, that doesn't mean that eligius mined that block
602 2013-11-30 12:54:46 <kjj> I see 26 transactions in that block
603 2013-11-30 12:55:25 <diki> kjj:Yeah, I couldn't find the eligius one
604 2013-11-30 12:55:38 <SomeoneWeird> diki, i highly doubt it was eligius :)
605 2013-11-30 12:55:40 <diki> SomeoneWeird:Usually the name is in the sig
606 2013-11-30 12:55:47 <diki> but obviously anyone can change it
607 2013-11-30 12:55:47 <gmaxwell> why are you guys responding to diki?
608 2013-11-30 12:55:55 <diki> and impersonate someone, but doubtful
609 2013-11-30 12:56:12 <SomeoneWeird> diki, what are you on about
610 2013-11-30 12:56:16 <diki> by sig I mean coinbase
611 2013-11-30 12:56:17 <kjj> ok. just wanted to make sure you weren't expecting the relayed-by on blockchain.info to be accurate
612 2013-11-30 12:56:40 <SomeoneWeird> gmaxwell, should we not ?
613 2013-11-30 12:56:53 <gmaxwell> SomeoneWeird: I've had him on ignore since 2011 sometime.
614 2013-11-30 12:56:59 <SomeoneWeird> i see.
615 2013-11-30 12:57:25 <gmaxwell> every once in a while someone will respond without prefixes and I'll wonder for a bit if they're losing their minds.
616 2013-11-30 12:57:51 <gmaxwell> but then they respond to something that makes it clear that they're explaining something to a crazy fool and I'll remember.
617 2013-11-30 12:57:57 <diki> someoneweird, while blockchain.info does guess sometimes who relayed the blocks, I think it also reads the coinbase to see who mined it.
618 2013-11-30 12:58:05 <saracen> ACTION tries to think back to the few instances where he responded to diki and looked insane
619 2013-11-30 12:58:14 <SomeoneWeird> diki, yeah uh, no.
620 2013-11-30 12:58:22 <diki> no what?
621 2013-11-30 12:58:41 <cortexA9> hello
622 2013-11-30 12:59:09 <gmaxwell> cortexA9: hello, why is your neon unit slower than cortexa8?
623 2013-11-30 12:59:27 <cortexA9> hehe gmaxwell
624 2013-11-30 12:59:35 <cortexA9> idk :P
625 2013-11-30 12:59:48 <SomeoneWeird> diki, i've never seen a pool stamp a sig in a blocks coinbase
626 2013-11-30 13:00:09 <kjj> really? several do
627 2013-11-30 13:00:14 <diki> yup https://blockchain.info/tx/2b2905919aecaab9fb25684a716b7db1239911780250a59b9459735ed509d0ec
628 2013-11-30 13:00:18 <diki> ^ btcguild
629 2013-11-30 13:00:32 <cortexA9> why no one make a popular bitcoin website
630 2013-11-30 13:00:32 <SomeoneWeird> oh, ok, well :)
631 2013-11-30 13:00:40 <diki> and eligius as well https://blockchain.info/tx/71312df38bc72bfca206edf3d3faba1a952a2087cd05bd886bb55755ad585c09
632 2013-11-30 13:00:49 <gmaxwell> SomeoneWeird: in any case, sometimes miners must produce an empty block, e.g. its so soon after the last one that they haven't had a chance to compute new txn yet. producing a empty block now doesn't prevent someone from producing a noral one 5 seconds later.
633 2013-11-30 13:00:52 <diki> Of course that doesn't guarantee it was them
634 2013-11-30 13:01:02 <diki> I don't see anyone needing to impersonate etc.
635 2013-11-30 13:01:04 <SomeoneWeird> gmaxwell, eh?
636 2013-11-30 13:01:08 <cortexA9> we are in the dev channel
637 2013-11-30 13:01:10 <kjj> but I don't believe that blockchain.info actually checks it. it certainly doesn't check it for the relayed-by field
638 2013-11-30 13:01:22 <cortexA9> make a popular website based on bitcoin
639 2013-11-30 13:01:24 <cortexA9> hehe
640 2013-11-30 13:01:25 <diki> SomeoneWeird:If gmaxwell is saying something about me, ignore him.
641 2013-11-30 13:01:31 <diki> He added me on ignore, I added him.
642 2013-11-30 13:01:41 <SomeoneWeird> diki, how about you not tell me what todo :)
643 2013-11-30 13:02:41 <cortexA9> like a facebook but bitcoin based
644 2013-11-30 13:03:28 <cortexA9> make a good algorithm
645 2013-11-30 13:03:41 <cortexA9> for sharing bitcoins
646 2013-11-30 13:03:49 <cortexA9> through website
647 2013-11-30 13:05:01 <saracen> These ideas don't make much sense.
648 2013-11-30 13:05:16 <cortexA9> why not ?
649 2013-11-30 13:05:41 <cortexA9> maybe an app for mobile
650 2013-11-30 13:05:59 <edcba> shouldn't we have some common service for dispatching blockchain to users of 1 computer ?
651 2013-11-30 13:06:18 <saracen> Maybe they just lack detail, but at the moment, they're just words strung together
652 2013-11-30 13:06:20 <edcba> instead having each user having a copy of the whole blockchain ?
653 2013-11-30 13:06:28 <Luke-Jr> edcba: that's what accounts are for
654 2013-11-30 13:06:42 <saracen> Like, I know, let's make a Pokedex, but bitcoin rather than pokemon based.
655 2013-11-30 13:06:51 <edcba> Luke-Jr: not really
656 2013-11-30 13:06:55 <Luke-Jr> edcba: yes really
657 2013-11-30 13:07:01 <cortexA9> like a social network but with bitcoin address
658 2013-11-30 13:07:02 <sipa> not really
659 2013-11-30 13:07:05 <gmaxwell> saracen: Pokedexes. Can they be local?
660 2013-11-30 13:07:06 <kjj> like-jr: he means a service or root-daemon that serves all users of the computer
661 2013-11-30 13:07:13 <Luke-Jr> edcba: multiple users sharing the same computer already have to trust the administrator anyway
662 2013-11-30 13:07:14 <kjj> with each user still having their own wallet
663 2013-11-30 13:07:25 <cortexA9> social network nicknames
664 2013-11-30 13:07:27 <cortexA9> not real name
665 2013-11-30 13:07:31 <Luke-Jr> kjj: false sense of security
666 2013-11-30 13:07:39 <Luke-Jr> in any case, I think Armory can do that
667 2013-11-30 13:07:54 <gmaxwell> yea, you just need 8 gb ram per user. :(
668 2013-11-30 13:07:54 <kjj> it isn't about security, it is about not having to maintain N copies of the blockchain
669 2013-11-30 13:08:03 <Luke-Jr> gmaxwell: latest Armory says it doesn't use that much RAM
670 2013-11-30 13:08:08 <gmaxwell> \O/
671 2013-11-30 13:08:22 <kjj> he got it down to 6 GB?
672 2013-11-30 13:08:23 <Luke-Jr> kjj: and accounts share the same blockchain copy
673 2013-11-30 13:08:26 <cortexA9> like coinbook or something
674 2013-11-30 13:08:45 <kjj> Luke-Jr: accounts in bitcoin are not even remotely sufficient for multi-user access
675 2013-11-30 13:08:49 <gmaxwell> Luke-Jr: accounts aren't sutiable for multiuser.
676 2013-11-30 13:08:49 <Luke-Jr> https://bitcoinarmory.com/download/ "Latest version: 0.90-beta: ... Previous version: 0.88.1-beta: Note: This version uses 6GB+ RAM."
677 2013-11-30 13:09:00 <Luke-Jr> gmaxwell: in what way?
678 2013-11-30 13:09:15 <saracen> gmaxwell: Local? I'm probably missing a reference to newer games, since red or blue :P
679 2013-11-30 13:09:17 <kjj> it is something that will come naturally when the client gets split into multiple parts
680 2013-11-30 13:09:34 <gmaxwell> Luke-Jr: no access control at all. E.g. I am sysop and you trust me. kjj trusts me. But that doesn't imply you and kjj trust each other.
681 2013-11-30 13:09:56 <Luke-Jr> gmaxwell: ok, well, we *could* add access control on accounts
682 2013-11-30 13:10:26 <edcba> but windows/linux users won't share their client
683 2013-11-30 13:10:34 <edcba> so it doesn't matter
684 2013-11-30 13:11:04 <edcba> you really have to separate the whole thing in 2 parts
685 2013-11-30 13:11:13 <gmaxwell> saracen: https://www.youtube.com/watch?v=2-L3Kgc6Y7E (funny video, worth the 4 minutes, well. esp if you have expirence with technology startups)
686 2013-11-30 13:11:37 <gmaxwell> Luke-Jr: do you want to do the QA on access controls on accounts? :P
687 2013-11-30 13:11:38 <diki> kjj:this was the block https://blockchain.info/block-index/442056 ^^
688 2013-11-30 13:12:03 <gmaxwell> Luke-Jr: if we someday seperate out the wallet functionality then it wouldn't be hard to do what he's asking for .. today, not so much.
689 2013-11-30 13:12:31 <Luke-Jr> shrug, like I said, Armory already does the split wallet thing
690 2013-11-30 13:12:51 <saracen> gmaxwell: Ha, yeah, remember seeing this on hackernews a while back
691 2013-11-30 13:13:01 <kjj> yeah, 7 seconds wasn't enough time to gather new transactions
692 2013-11-30 13:13:03 <Luke-Jr> and Electrum too, if you run a thin server layer
693 2013-11-30 13:13:30 <gmaxwell> Luke-Jr: looks like the armory thing does, but the expense of big disk usage per instance.
694 2013-11-30 13:13:37 <gmaxwell> (it creates its own large block index)
695 2013-11-30 13:16:01 <saracen> moriarty: stop PMing people.
696 2013-11-30 13:16:40 <gmaxwell> what is he PMing with? just support or is it some scam?
697 2013-11-30 13:16:53 <kjj> wants us to join a different channel
698 2013-11-30 13:17:21 <saracen> Yeah, just advertising a channel
699 2013-11-30 13:17:26 <wumpus> right, it would be great if it was possible to run different wallets on top of bitcoind, the current monolithic approach in which everyone tries to put all features in the wallet implementation simply doesn't scale
700 2013-11-30 13:17:56 <kjj> unfortunately, splitting doesn't appear to be easy. every part expects to have full access to every other part
701 2013-11-30 13:18:05 <wumpus> that's not true
702 2013-11-30 13:18:07 <kjj> not impossible, of course, just not easy
703 2013-11-30 13:18:33 <wumpus> it's pretty modular already, for example I could do https://github.com/bitcoin/bitcoin/pull/3332 with some simple code movements
704 2013-11-30 13:19:10 <Luke-Jr> it's been done before, fwiw
705 2013-11-30 13:19:19 <Luke-Jr> someone had a patch to use different RPC users to access different wallets
706 2013-11-30 13:19:39 <wumpus> yes, there was even a multiwallet patch that can give every user their own wallet
707 2013-11-30 13:20:19 <kjj> yeah... disabling the wallet and having multiple wallets are not even remotely the same as having a wallet API
708 2013-11-30 13:20:23 <Luke-Jr> probably would be good if wumpus and etothepi met up and discussed what interfaces they needed to be exposed to do everything over the network ;)
709 2013-11-30 13:20:59 <Luke-Jr> if built around a single connection, it could use stdio for higher security
710 2013-11-30 13:21:21 <TD> gmaxwell: around?
711 2013-11-30 13:21:36 <wumpus> kjj: it's exactly the start of that
712 2013-11-30 13:21:50 <Luke-Jr> otoh, I do like Electrum's concept of having every wallet at least be a SPV client
713 2013-11-30 13:22:22 <wumpus> kjj: I don't really see the difficulty, someone should do it that's all
714 2013-11-30 13:22:37 <wumpus> but it's just software engineering, not rocket science like the crypto stuff :p
715 2013-11-30 13:23:02 <TD> gmaxwell: it's time to test p2sh support in bitcoinj. i tried it on a regtest node and the generated tx was accepted by the bitcoind, but i'm wondering if there's any other way to test it
716 2013-11-30 13:23:20 <wumpus> Luke-Jr: and yes it may be good to discuss with him
717 2013-11-30 13:24:15 <Luke-Jr> TD: 3P14159f73E4gFr7JterCCQh9QjiTjiZrG
718 2013-11-30 13:24:26 <TD> what does that address do?
719 2013-11-30 13:24:36 <Luke-Jr> that's one of my donation addresses
720 2013-11-30 13:26:28 <shesek> TD, heh, I was just talking with gmaxwell about p2sh support in bitcoinj like 10 minutes ago
721 2013-11-30 13:27:07 <shesek> its really awesome that you're working on it, it'll be really helpful for a project I'm working on :)
722 2013-11-30 13:27:52 <shesek> (and btw, if you're looking to test with something that works with p2sh addresses, I have an alpha version of a web multisig interface I'm working on that you can try it with)
723 2013-11-30 13:28:19 <shesek> (and give me some feedback along the way ;)
724 2013-11-30 13:32:41 <TD> Luke-Jr: if i sent something there, would you be able to try spending it immediately? just to check that it works ok. spendijng a multisig address from bitcoind command line seems awkward
725 2013-11-30 13:34:47 <shesek> TD, that interface I'm working on can spend from multisig addresses, and is running on testnet
726 2013-11-30 13:35:09 <Luke-Jr> TD: sure
727 2013-11-30 13:36:04 <TD> shesek: actually the patch was contributed by someone. i guess i can ask him for a p2sh address where he accepts tips :)
728 2013-11-30 13:39:43 <shesek> yeah, I saw that, I was just checking on bitcoinj support for p2sh addresses and saw that it was sent like 3 hours ago
729 2013-11-30 13:40:50 <Luke-Jr> TD: anyhow, just give me an address to return the bitcoins to and I'll help test
730 2013-11-30 13:41:05 <TD> thanks. one second ...
731 2013-11-30 14:05:58 <shesek> which one of you is being naughty and solves blocks on testnet without any transactions?
732 2013-11-30 14:06:06 <shesek> that's not nice of you :)
733 2013-11-30 14:06:28 <edcba> maybe it's a bug
734 2013-11-30 14:06:40 <edcba> anyway it's not a testnet for nothing :)
735 2013-11-30 14:11:52 <TD> Luke-Jr: ok sent
736 2013-11-30 14:11:56 <TD> sorry for the delay
737 2013-11-30 14:12:04 <Luke-Jr> TD: where do I return it?
738 2013-11-30 14:12:16 <TD> 13fLLox43yXYvfoZadXpGbkTUXkW8bhqut
739 2013-11-30 14:12:59 <Luke-Jr> 7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45
740 2013-11-30 14:13:23 <TD> thanks
741 2013-11-30 14:13:35 <Luke-Jr> np
742 2013-11-30 14:18:28 <gmaxwell> td: make sure you test ones with an invalid crc, testnet on mainnet, or other such nonsense which should be rejected.
743 2013-11-30 14:18:56 <TD> i already tested trying to send across chains, which failed. CRC check is already done as part of regular addresses and that code didn't change
744 2013-11-30 14:19:09 <TD> there are unit tests as well. so i think it's good.
745 2013-11-30 14:19:35 <TD> next up - got a submission for the payment protocol, but it doesn't work. need to debug why not.
746 2013-11-30 14:19:41 <TD> lots of patches lately :)
747 2013-11-30 14:37:06 <midnightmagic> Emcy: I re-transferred the blockchain. The original rsync appears to not have done a perfect mirroring job. It's possible that the --delete option I skipped the first time was at fault.
748 2013-11-30 14:37:57 <midnightmagic> Emcy: More analysis suggested that files from the *original* machine I was copying the chainstate/blocks dirs from were the reason I had stale-ish data in the datadir to begin with.
749 2013-11-30 14:38:26 <midnightmagic> My assumption that rsync would clean it all up is of course flawed insofar as there may have been different filename sets between the two datasets.
750 2013-11-30 14:39:36 <Belxjander> midnightmagic: how large a blockchain database is that now
751 2013-11-30 14:39:39 <Belxjander> ???
752 2013-11-30 14:39:57 <midnightmagic> (and without a full -c checksum verification, other factors may have contributed to datafiles not being updated.)
753 2013-11-30 14:40:06 <Emcy> ha
754 2013-11-30 14:40:41 <midnightmagic> Belxjander: Oh. Uh. chainstate is 293MB directory, blocks/* is 15.8GB
755 2013-11-30 14:41:14 <Emcy> and i thought rsync was supposed to be superior
756 2013-11-30 14:41:16 <midnightmagic> :-) And I can also confirm that bitcoind works just fine on a memory-upgraded EeePC. hehe
757 2013-11-30 14:41:29 <midnightmagic> Emcy: It is. You just have to tell it to be superior. :)
758 2013-11-30 14:41:37 <midnightmagic> otherwise it's a lazy sot
759 2013-11-30 14:41:56 <Emcy> 'im not angry with you rsync im dissapointed because i know you can do better'
760 2013-11-30 14:42:05 <midnightmagic> lol precisely
761 2013-11-30 14:42:45 <Emcy> is that 293mb is ram too
762 2013-11-30 14:42:48 <Belxjander> I wonder how I will get on with a PPC box I can dedicate to bitcoind
763 2013-11-30 14:42:48 <Emcy> for the utxo
764 2013-11-30 14:43:12 <Emcy> i used to run bitcoind on an eeepc
765 2013-11-30 14:43:13 <Luke-Jr> you won't.
766 2013-11-30 14:43:14 <Emcy> 2gb
767 2013-11-30 14:43:23 <Luke-Jr> bitcoind only works in little endian
768 2013-11-30 14:43:24 <Belxjander> or would I be better off with an AMD64X2@2.2GHz for bitcoind operations