1 2014-02-05 00:34:22 <tlrobinson> why does the block 90th percentile tend to be either 10-30 seconds, or almost exactly 120 seconds? http://bitcoinstats.com/network/propagation/
2 2014-02-05 00:35:57 <go1111111> is there a simple way to list all addresses in the keypool?
3 2014-02-05 00:36:29 <sipa> dumpwallet RPC
4 2014-02-05 00:36:33 <sipa> in 0.9.0rc1
5 2014-02-05 00:37:56 <go1111111> thanks
6 2014-02-05 02:18:07 <alex_fun> hello :)
7 2014-02-05 02:18:25 <alex_fun> does bitcoin somehow hardcodes max value of 21 million coins?
8 2014-02-05 02:18:28 <alex_fun> or not really?
9 2014-02-05 02:19:37 <SomeoneWeird> alex_fun, yes
10 2014-02-05 02:22:04 <alex_fun> SomeoneWeird: and how its done?
11 2014-02-05 02:22:29 <SomeoneWeird> i'd have to find the bit of code, and i'm at work atm
12 2014-02-05 02:22:49 <SomeoneWeird> grep the codebase for 2100000 or something
13 2014-02-05 02:22:52 <alex_fun> via halving I presume
14 2014-02-05 02:23:14 <alex_fun> I greped it there is one function but it seems to check transaction sanity
15 2014-02-05 02:26:06 <alex_fun> I found something here 21,000,000 = 2 * 50 * 210,000
16 2014-02-05 02:29:05 <copumpkin> I thought it was just the sum of a geometric series
17 2014-02-05 02:43:32 <andytoshi> alex_fun: ./src/core.h:18:static const int64_t MAX_MONEY = 21000000 * COIN;
18 2014-02-05 02:44:14 <alex_fun> andytoshi: that seems to be max transaction value
19 2014-02-05 02:44:19 <andytoshi> but MAX_MONEY is just used in some (redundant) sanity checks.
20 2014-02-05 02:44:20 <andytoshi> rigth
21 2014-02-05 02:44:35 <alex_fun> so some people wont send like 50000000000000000 coins :D
22 2014-02-05 02:44:39 <andytoshi> the actual coin limit is the sum of a geometric series
23 2014-02-05 02:44:56 <alex_fun> yes i figured that out with google help :)
24 2014-02-05 02:45:02 <andytoshi> MAX_MONEY is only there to screw with dogecoin developers ;)
25 2014-02-05 02:45:08 <alex_fun> hehehe
26 2014-02-05 02:45:12 <alex_fun> :)))
27 2014-02-05 02:45:57 <alex_fun> int64 AmountFromValue(const Value& value) { double dAmount = value.get_real(); if (dAmount <= 0.0 || dAmount > this also checks for max transactions?
28 2014-02-05 02:46:33 <alex_fun> so if its less than 0 and higher that 21,000,000 it gives error 3
29 2014-02-05 02:46:38 <alex_fun> invalid amount
30 2014-02-05 02:48:42 <alex_fun> oki tv time :)
31 2014-02-05 02:52:17 <antephialtic> has an altcoin ever been written that uses NTRU signatures?
32 2014-02-05 04:09:57 <nessence> doubtful if it's patented
33 2014-02-05 04:14:41 <gmaxwell> sipa: https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L299 < care to fix that too, I know you changed the signing to switch to the order/2 check.
34 2014-02-05 04:19:47 <jbitcm-> hello
35 2014-02-05 04:19:58 <jbitcm-> can you help me please
36 2014-02-05 04:20:20 <jbitcm-> i want to know how i can get involved for develop bitcoin
37 2014-02-05 05:33:56 <quellhorst> how can i get the data on all bitcoin addresses and transactions without using blockchain.info's website?
38 2014-02-05 05:34:58 <Luke-Jr> quellhorst: getrawtransaction, unless it's pruned
39 2014-02-05 05:35:15 <Luke-Jr> quellhorst: if you reindex with txindex=1 in your config, it will work for any transaction
40 2014-02-05 05:36:48 <quellhorst> ok, so all i need is bitcoind with a copy of the entire blockchain and i can get all the data from running shell commands?
41 2014-02-05 05:37:33 <antephialtic> if you prefer Java, create a BitcoinJ BlockStore with the fullStoreDepth set to Integer.MAX_INT
42 2014-02-05 05:37:47 <quellhorst> antephialtic: yeah, i'm getting a bit more into java these days
43 2014-02-05 05:38:12 <quellhorst> antephialtic: do i need to redownload everything with bitcoinj?
44 2014-02-05 05:38:59 <antephialtic> unfortunately, yes, it uses a different on-disk format.
45 2014-02-05 05:40:03 <quellhorst> hmm, maybe i could specify my dedicated node to seed from that way it could download faster
46 2014-02-05 05:42:22 <antephialtic> yes, there are methods for this in the PeerGroup class.
47 2014-02-05 05:42:57 <antephialtic> I'll be in #bitcoinj if you have any more questions
48 2014-02-05 09:51:28 <omefire> Hey guys
49 2014-02-05 09:51:57 <omefire> I'm trying to understand how bitcoin-qt calculates the balance.
50 2014-02-05 09:53:09 <omefire> from whatever I have glanced from the code, it seems like the UI gets the balance from CWallet.getBalance()
51 2014-02-05 09:53:52 <jaakkos> are you interested on general level how the balance is computed or code-level details in bitcoin-qt?
52 2014-02-05 09:54:10 <omefire> and CWallet maintains an in-memory data structure of transactions : mapWallet or something similar
53 2014-02-05 09:54:43 <omefire> my question is : who calls/notifies CWallet about new transactions so that it can update itself ?
54 2014-02-05 09:55:19 <omefire> jaakkos : I'm interested in code-level details.
55 2014-02-05 09:57:23 <omefire> I have found that CWallet gets notified about new transactions by main.cpp via boost sigals .
56 2014-02-05 09:57:55 <omefire> but who calls main.cpp about transactions updates ?
57 2014-02-05 10:23:55 <Grouver> sipa, We have shutted down the trusted node and copied the blocks folder and chainstate folder. We have pasted this on my local pc where we deleted the index folder in the blocks folder and removed all lock files and database/log files. Now when i s tart bitcoin-qt from the terminal I get this error in the terminal.
58 2014-02-05 10:24:42 <Grouver> grouver@bitonic$ ./bitcoin-qt
59 2014-02-05 10:24:43 <Grouver> Aborted (core dumped)
60 2014-02-05 10:24:43 <Grouver> bitcoin-qt: main.cpp:1602: bool ConnectBlock(CBlock&, CValidationState&, CBlockIndex*, CCoinsViewCache&, bool): Assertion `hashPrevBlock == view.GetBestBlock()' failed.
61 2014-02-05 10:25:49 <Grouver> Again this is about 0.9.0rc1
62 2014-02-05 10:26:00 <jouke> Grouver: ircc you also specified -rescan
63 2014-02-05 10:26:19 <Grouver> Right.
64 2014-02-05 10:26:37 <Grouver> jouke, I get the same error if I do this without -rescan.
65 2014-02-05 10:35:01 <alex_fun> hello, I have been reading about as to why coins take 100 confirmation before valid when they are mined. The purpose of this rule is to prevent long chain splits from invalidating lots of transactions that spend newly-generated BTC. But how splitted chain can invalidate recent transcations?
66 2014-02-05 10:35:28 <alex_fun> low diff creates 2 chains and then they keep swapping places as to who is longest chain?
67 2014-02-05 10:35:56 <alex_fun> also is there some graphical representation of bitcoin forks real time?
68 2014-02-05 10:50:54 <Emcy> f the other chain overtakes the "real" one, all txns in that cahin up to current are erased from the timeline
69 2014-02-05 10:51:02 <Emcy> including coinbase txn that mints coins
70 2014-02-05 10:51:59 <Emcy> this would cause a huge shitstorm so 120 confs is like doubling up the rubbers when youre slumming in bangkok
71 2014-02-05 10:58:00 <epscy> nice metaphor
72 2014-02-05 10:58:13 <alex_fun> hehehe
73 2014-02-05 10:58:48 <alex_fun> I love thai girls
74 2014-02-05 11:00:10 <alex_fun> Emcy: so say there is pool xyz once another chain become longer
75 2014-02-05 11:00:31 <alex_fun> it deletes previous chain data from ./bitcoin?
76 2014-02-05 11:00:42 <alex_fun> what if they back it up and restore?
77 2014-02-05 11:01:24 <sipa> alex_fun: it is nit an implementation problem
78 2014-02-05 11:01:41 <sipa> the problem is that coinbase transactions depend on the chain that created them
79 2014-02-05 11:01:53 <sipa> if we reorganjze, that chain is not loner active
80 2014-02-05 11:02:27 <Emcy> alex_fun there is only one unbroken chain, that is the definition of the system
81 2014-02-05 11:02:33 <sipa> so its coinbase transactions, and anyone paid using its outputrs, and all transactions that spent coins from it, become invalid
82 2014-02-05 11:03:26 <sipa> Grouver: what if you run 0.8.2 on the new node? does it accept the database?
83 2014-02-05 11:03:28 <Emcy> alex_fun i think orphaned blocks from a usurped chain segment are stored for a while by the database
84 2014-02-05 11:03:35 <alex_fun> but longer chain would still be built on previosly longer chain
85 2014-02-05 11:03:51 <sipa> alex_fun: #bitcoin please
86 2014-02-05 11:04:28 <alex_fun> sipa is there some wiki entry related to it? as #bitcoin is kinda mad
87 2014-02-05 11:05:25 <sipa> read bitcoin.stackexchange.com, read the paper, ...
88 2014-02-05 11:05:51 <alex_fun> I read it like 20 times lol
89 2014-02-05 11:06:02 <Apocalyptic> alex_fun, if you really understand how bitcoin works it's straightforward to see
90 2014-02-05 11:06:21 <sipa> sorry, but this is not the place for explaining bitcoin's basics
91 2014-02-05 11:06:51 <alex_fun> sipa yet this paper is not very obviou :)
92 2014-02-05 11:06:54 <alex_fun> obvious
93 2014-02-05 11:07:08 <alex_fun> or say all potential implications
94 2014-02-05 11:09:57 <alex_fun> but what is the issue? client checks for longest chain each time when it request new work, so its allways on the longest chain, and that new long chain would still cointan old coins and transations that happen prior to split, only when some how two forks exist same time mess can happen. but how they can co exist when client ask for longest chain each time it gets work?
95 2014-02-05 11:11:00 <Grouver> sipa, okay i will try.
96 2014-02-05 11:11:32 <Grouver> sipa, if i may ask, why not 0.8.6?
97 2014-02-05 11:19:30 <alex_fun> :)))
98 2014-02-05 11:20:47 <sipa> Grouver: i mean 0.8.6, sorry
99 2014-02-05 11:21:14 <Grouver> sipa, Right. I am downloading now.
100 2014-02-05 11:22:23 <sipa> alex_fun: forks happen all the time, because sometimes two blocks are generated simultaneously, and their miners may not have heard yet about eachother's new block just because of propagation delay across the earth
101 2014-02-05 11:23:01 <sipa> alex_fun: and bitcoin most deal with them
102 2014-02-05 11:23:06 <sipa> *must
103 2014-02-05 11:24:33 <sipa> alex_fun: in normal cases, transactions from one fork can move to the other fork just fine, as the coins exist likely in both
104 2014-02-05 11:24:51 <sipa> alex_fun: but coinbase transactions cannot mocve to a new chain
105 2014-02-05 11:25:10 <sipa> as they onky exist in the block that generates them
106 2014-02-05 11:27:50 <alex_fun> ok ty
107 2014-02-05 11:29:55 <Grouver> sipa, bitcoin 0.8.6 has no problems with the same blocks & chainstate folder.
108 2014-02-05 11:31:10 <Grouver> sipa, Thats cause maybe its a 0.8.6 blockchain i copied from the trusted node.
109 2014-02-05 11:34:02 <sipa> Grouver: can you put the chainstate online?
110 2014-02-05 11:35:54 <Diablo-D3> https://plus.google.com/+UrsH%C3%B6lzle/posts/UseinB6wvmh
111 2014-02-05 11:49:46 <Emcy> does testnet really generate like 20 blocks a minute sometimes
112 2014-02-05 11:50:26 <Grouver> sipa, We stopped the trusted node before copying. But right now we are gonna try it again. Maybe, just maybe the daemon was still running.
113 2014-02-05 11:52:14 <jouke> Hmm, the bitcoind of the trusted node we tried to copy it from just segfaulted :(
114 2014-02-05 11:52:52 <Grouver> But for some reason now 0.8.6 and 0.9.0 dont recognize the blocks and start completey over with syncing. Then in the debug logs we see it get the first block from the network and wants to overwrite the already existing block. Really weird.
115 2014-02-05 11:52:52 <jouke> (after giving the stop command through rpc)
116 2014-02-05 11:53:26 <warren> jouke: did you build the bitcoind yourself? what version of boost?
117 2014-02-05 11:53:43 <Emcy> "Please note that as I am no longer employed by Google, after 0.11 signing the Google contributor license agreement will no longer be necessary"
118 2014-02-05 11:54:31 <Emcy> does that mean bitcoinj is a product of mike as a google employee? I thought it was a personal endeavour
119 2014-02-05 11:56:13 <jouke> warren: 8.5 prebuilt
120 2014-02-05 11:57:45 <warren> ok, I think that static links to whatever boost is in 10.04
121 2014-02-05 12:02:09 <jouke> Upgraded to 0.8.6, starts just fine, works as expected, but segfaults at shutdown.
122 2014-02-05 12:02:30 <jouke> I guess that is why the other bitcoin client can't load the blockchain-files?
123 2014-02-05 12:03:38 <sipa> 0.9 may have some stronger consistency checks
124 2014-02-05 12:06:07 <jouke> but 8.6 didn't work either. We copied blocks/*.dat and chainstate/
125 2014-02-05 12:06:50 <Grouver> jouke, we loaded it up without the index folder which is in the blocks folder
126 2014-02-05 12:12:10 <sipa> heh, that won't work
127 2014-02-05 12:12:33 <sipa> the chainstate may not be newer than the block index
128 2014-02-05 12:13:26 <sipa> that is, the best chain in chainstate must be present in blocks and blocks/imdex
129 2014-02-05 12:15:54 <Grouver> hmm, I thought i red some where we only needed the blocks folder and chainstate folder where we dont need the index folder which is in the blocks folder. Hmm. Attemp #4
130 2014-02-05 12:16:11 <jouke> Right. Let's try that again.
131 2014-02-05 12:16:37 <jouke> The node still segfaults with 8.6 on shutting down by the way.
132 2014-02-05 12:23:40 <sipa> Grouver: blocks > blocks/index > chainstate
133 2014-02-05 12:23:56 <sipa> you can copy just blocks, blocks+blocks/index, or all
134 2014-02-05 12:24:11 <sipa> they're like several stages of processing
135 2014-02-05 12:24:20 <sipa> the chainstate refers to things in the block index
136 2014-02-05 12:24:24 <sipa> and the block index to stuff in blocks
137 2014-02-05 12:24:43 <Grouver> sipa, Ah. Okay. Thanks for pointing that out.
138 2014-02-05 12:24:58 <sipa> well, blocks+blocks/index can be created independently from the chainstate
139 2014-02-05 12:25:11 <sipa> as the chainstate only refers to blocks by hash, not by position on disk
140 2014-02-05 12:25:45 <Grouver> so the chainstate folder is actually not really needed?
141 2014-02-05 12:26:22 <sipa> if you don't copy it, you have to rebuild it
142 2014-02-05 12:26:28 <sipa> which takes almost as long as reindexing
143 2014-02-05 12:26:49 <sipa> the chainstate is the trusted part
144 2014-02-05 12:27:20 <Grouver> Yes. Right. But if you have a other wallet.dat and not the original wallet.dat from the trusted node?
145 2014-02-05 12:27:46 <sipa> wallet.dat is completely independent
146 2014-02-05 12:28:08 <sipa> you can run 0.9 without wallet even
147 2014-02-05 12:28:24 <Grouver> oh, I always thought the index folder was connected to your keys.
148 2014-02-05 12:28:29 <sipa> no, not at all
149 2014-02-05 12:28:39 <sipa> eerything related to your wallet is in wallet.dat
150 2014-02-05 12:28:49 <sipa> (and at runtime, the database/ folder)
151 2014-02-05 12:29:24 <Grouver> Alright. :)
152 2014-02-05 12:30:11 <michagogo> cloud|ACTION wonders if wumpus is around
153 2014-02-05 12:31:33 <sipa> Grouver: blocks/index basically contains "block X can be found in blocks file X position Y, along with some metadata about the blocks"
154 2014-02-05 12:32:05 <gribble> wumpus was last seen in #bitcoin-dev 3 days, 1 hour, 56 minutes, and 49 seconds ago: <wumpus> hehe
155 2014-02-05 12:32:05 <michagogo> cloud|;;seen wumpus
156 2014-02-05 12:35:03 <wumpus> test
157 2014-02-05 12:35:19 <wumpus> lol, I've been talking here for nothing for quite a while
158 2014-02-05 12:35:27 <wumpus> wasn't id'd so my messages didn't come through
159 2014-02-05 12:35:45 <michagogo> cloud|heh
160 2014-02-05 12:35:50 <michagogo> cloud|Isn't there an error
161 2014-02-05 12:35:56 <michagogo> cloud|"cannot send to channel" or something?
162 2014-02-05 12:36:00 <wumpus> yes, but not in this tab
163 2014-02-05 12:36:04 <michagogo> cloud|Ahh
164 2014-02-05 12:36:14 <wumpus> [13:41:38] -*- michagogo|cloud wonders if wumpus is around
165 2014-02-05 12:36:14 <wumpus> [13:41:59] -*- wumpus hides
166 2014-02-05 12:36:17 <wumpus> hehe
167 2014-02-05 12:36:21 <michagogo> cloud|:P
168 2014-02-05 12:36:38 <michagogo> cloud|ACTION is currently booted into his external HD with Ubuntu on it
169 2014-02-05 12:36:57 <michagogo> cloud|ACTION spent several hours last night rebuilding the system after it somehow became unbootable
170 2014-02-05 12:37:22 <michagogo> cloud|wumpus: What did you want me to test?
171 2014-02-05 12:37:25 <wumpus> strange
172 2014-02-05 12:37:38 <wumpus> maybe a kernel that doesn't want to work with your hw?
173 2014-02-05 12:37:44 <sipa> OS on USB == bad idea
174 2014-02-05 12:37:59 <sipa> reliability, many small writes, bad parallellism, ...
175 2014-02-05 12:38:00 <michagogo> cloud|The linux deps gbuild with your 2014_01_gitian_linux_deps_fix branch?
176 2014-02-05 12:38:26 <sipa> (I almost said 'OS on USD')
177 2014-02-05 12:38:29 <wumpus> michagogo|cloud: linux gitian build (including deps and boost) with #3622
178 2014-02-05 12:39:07 <michagogo> cloud|Btw, if you care about my sigs from tag 0.9.0rc1, you can see github.com/Michagogo/gitian.sigs
179 2014-02-05 12:39:13 <wumpus> sipa: hah, I've run ubuntu from an USB stick for a while, had no problems, though I know it should wear out the stick quite quickly
180 2014-02-05 12:39:19 <michagogo> cloud|I have two branches there, one from LXC and one from KVM
181 2014-02-05 12:39:36 <michagogo> cloud|KVM is from last night after I reinstalled Ubuntu
182 2014-02-05 12:40:00 <michagogo> cloud|wumpus: Including boost? I saw you didn't bump the version number there
183 2014-02-05 12:40:04 <wumpus> michagogo|cloud: I've made a lot of (necessary) determinism changes in that pull
184 2014-02-05 12:40:36 <wumpus> well the underlying code didn't change; determism is all in times, timezones, ordering of the zips, etc
185 2014-02-05 12:40:48 <Grouver> sipa, Thanks.
186 2014-02-05 12:41:33 <wumpus> should not affect the resulting bitcoind/bitcoin-qt/etc, but it's nice to get the intermediate outputs hashes deterministic as well
187 2014-02-05 12:41:36 <michagogo> cloud|wumpus: So should I rebuild boost r1 even though it's still r1?
188 2014-02-05 12:41:41 <wumpus> yes
189 2014-02-05 12:41:48 <wumpus> and upload the .zip if it doesn't match mine
190 2014-02-05 12:41:58 <michagogo> cloud|.zips, you mean
191 2014-02-05 12:42:13 <wumpus> well, only the 32-bit is usually enough
192 2014-02-05 12:42:20 <michagogo> cloud|Ah, okay
193 2014-02-05 12:42:57 <michagogo> cloud|BTW, how come we build 32 and 64 bit for Linux in two separate gitian VMs (32 in 32, 64 in 64), but build both 32 and 64 bit for Windows in one 64 bit VM?
194 2014-02-05 12:43:06 <wumpus> usually if they differ they both differ
195 2014-02-05 12:43:10 <wumpus> michagogo|cloud: good question
196 2014-02-05 12:43:29 <wumpus> it should absolutely be possible to build 32-bit executables on a 64-bit VM
197 2014-02-05 12:43:43 <wumpus> even linux->linux
198 2014-02-05 12:43:47 <warren> are the 32bit libraries available in the 64bit arch?
199 2014-02-05 12:44:05 <warren> I'm not sure how debian/ubuntu handles multilib
200 2014-02-05 12:44:09 <wumpus> AFAIK yes
201 2014-02-05 12:44:18 <wumpus> but no one looked at this in detail, that's why it's still like this
202 2014-02-05 12:44:30 <gribble> Error: "32" is not a valid command.
203 2014-02-05 12:44:30 <michagogo> cloud|;;32 bit libraries ubuntu 64 bit
204 2014-02-05 12:44:35 <michagogo> cloud|;;google 32 bit libraries ubuntu 64 bit
205 2014-02-05 12:44:36 <gribble> 32bit_and_64bit - Community Ubuntu Documentation: <https://help.ubuntu.com/community/32bit_and_64bit>; Is it possible to have 32 bit libraries installed on a 64 ... - Ask Ubuntu: <http://askubuntu.com/questions/60751/is-it-possible-to-have-32-bit-libraries-installed-on-a-64-bit-system>; 12.04 - how can I install a 32bit library on a 64bit system - Ask Ubuntu: (1 more message)
206 2014-02-05 12:44:45 <gribble> <http://askubuntu.com/questions/126108/how-can-i-install-a-32bit-library-on-a-64bit-system>
207 2014-02-05 12:44:45 <michagogo> cloud|;;more
208 2014-02-05 12:45:10 <warren> not all pkgconfig gets it right
209 2014-02-05 12:45:23 <wumpus> the basics should be there, libc and such, it used to be something like -m32 to build 32-bit executables on 64-bit
210 2014-02-05 12:45:33 <wumpus> we don't care about that; all the interesting deps we build ourselves
211 2014-02-05 12:45:53 <warren> ooh, especially now that it has a deps zip on linux
212 2014-02-05 12:46:12 <wumpus> the only uncertainty would be qt
213 2014-02-05 12:46:44 <michagogo> cloud|sudo apt-get install packagename:i386
214 2014-02-05 12:46:44 <michagogo> cloud|You should be able to install 32-bit packages on a 64-bit system with:
215 2014-02-05 12:47:02 <wumpus> would need a package like libqt4-dev:i386
216 2014-02-05 12:47:07 <wumpus> yes
217 2014-02-05 12:47:21 <warren> does it install into a separate chroot or /usr/lib64 /usr/lib like Fedora?
218 2014-02-05 12:47:45 <Diablo-D3> yeah
219 2014-02-05 12:47:52 <Diablo-D3> also you need the sources added for 32 bit
220 2014-02-05 12:47:54 <michagogo> cloud|wumpus: 38658a215429992a8d066f827b6f46ca63abc14173983647d16ac0e21a9ddfb7 build/out/bitcoin-deps-linux32-gitian-r3.zip
221 2014-02-05 12:47:59 <wumpus> /usr/lib32
222 2014-02-05 12:48:21 <Diablo-D3> so like for me, deb [arch=amd64,i386] http://ftp.us.debian.org/debian/ sid main non-free contrib
223 2014-02-05 12:48:45 <warren> I need to sleep...
224 2014-02-05 12:49:10 <wumpus> michagogo|cloud: so it matches the OP, good!
225 2014-02-05 12:51:04 <michagogo> cloud|T××× ×× ×× KVM
226 2014-02-05 12:51:14 <michagogo> cloud|This is in KVM
227 2014-02-05 12:51:31 <michagogo> cloud|(KVM running in a native-running OS)
228 2014-02-05 12:52:43 <michagogo> cloud|Unfortunately, running KVM inside a VMware Player VM, while possible, doesn't work to build the deps
229 2014-02-05 12:52:58 <michagogo> cloud|OpenSSL throws an error, something having to do with assembly code
230 2014-02-05 12:53:12 <michagogo> cloud|wumpus: 2dc3b04d0bb03e1ad0c18dfe1c5635aa6e3741a7a6173203554d8345cd5b5a95 bitcoin-deps-linux64-gitian-r3.zip
231 2014-02-05 12:53:30 <wumpus> also matches what is in #3622
232 2014-02-05 12:53:32 <michagogo> cloud|Building your boost now
233 2014-02-05 12:54:14 <wumpus> yes, the openssl assembly problem is very strange, must be some image problem, maybe that's what happens if you build the 32-bit version in 64-bit or vice versa? :)
234 2014-02-05 12:55:22 <michagogo> cloud|wumpus: My guess is that VMware's virtualization virtualization isn't perfect
235 2014-02-05 12:56:03 <wumpus> at least virtualbox warns when it cannot enable 64-bit-in-64-bit virt, but qemu/kvm may not and just proceed with.. something
236 2014-02-05 12:56:19 <michagogo> cloud|Well
237 2014-02-05 12:56:24 <wumpus> LXC could work?
238 2014-02-05 12:56:27 <michagogo> cloud|I know that in qemu, KVM simply fails to run
239 2014-02-05 12:56:41 <michagogo> cloud|erm, in vbox*
240 2014-02-05 12:56:52 <michagogo> cloud|Or maybe it even fails to install at the apt-get stage?
241 2014-02-05 12:56:57 <michagogo> cloud|Don't remember
242 2014-02-05 12:57:08 <wumpus> KVM in general works very badly inside VMs
243 2014-02-05 12:57:17 <wumpus> I think that's one reason why LXC support was added
244 2014-02-05 12:57:49 <michagogo> cloud|Virtualbox doesn't give its guests access to hardware virtualization at all
245 2014-02-05 12:58:20 <wumpus> LXC may even work on crappy VPS'es, though I haven't tried, would be nice to have some automatic nightly builder some day
246 2014-02-05 12:58:29 <michagogo> cloud|It does
247 2014-02-05 12:58:43 <michagogo> cloud|I gbuilt 0.8.6 on DigitalOcean
248 2014-02-05 12:58:51 <wumpus> cool
249 2014-02-05 12:59:10 <michagogo> cloud|I think I needed the 3rd tier ($0.03/hour, 2GB RAM)
250 2014-02-05 13:01:18 <wumpus> the only annoying thing about LXC seems to be that it hangs the whole machine for some seconds here while starting, but that's only a problem if you're using the computer for anything interactive
251 2014-02-05 13:01:50 <michagogo> cloud|I wish gitian could be ported to Windows
252 2014-02-05 13:02:02 <wumpus> i'm sure that's possible
253 2014-02-05 13:02:31 <michagogo> cloud|There's a bunch it'd require
254 2014-02-05 13:02:32 <wumpus> at least qemu/kvm exists for windows, and virtualbox, LXC would obviously not work :)
255 2014-02-05 13:02:59 <michagogo> cloud|As far as I could tell from a 10-second Google search, apt-cacher-ng doesn't exist for Windows
256 2014-02-05 13:03:23 <wumpus> hm that isn't just some ruby/python script?
257 2014-02-05 13:03:40 <wumpus> if it needs compilation it generally sucks on windows
258 2014-02-05 13:04:20 <michagogo> cloud|http://www.unix-ag.uni-kl.de/~bloch/acng/
259 2014-02-05 13:05:22 <michagogo> cloud|http://packages.debian.org/sid/apt-cacher-ng
260 2014-02-05 13:05:44 <wumpus> cannot find anything about the language it's in, so that probably means C :(
261 2014-02-05 13:06:29 <wumpus> it'd be pretty simple to do a caching proxy in python though
262 2014-02-05 13:06:46 <michagogo> cloud|1e534dc2e337bc0ac35ebd6544e15c4641b245c621706cc2c03436de545c600a build/out/boost-linux32-1.55.0-gitian-r1.zip
263 2014-02-05 13:07:13 <wumpus> ...or ruby, for that matter
264 2014-02-05 13:07:16 <michagogo> cloud|0473f96aa382d4448994fde4192155f3a96454a7436efdc04c5fc693b185d864 boost-linux64-1.55.0-gitian-r1.zip
265 2014-02-05 13:07:33 <wumpus> michagogo|cloud: they match!
266 2014-02-05 13:07:41 <sipa> \o/
267 2014-02-05 13:07:57 <michagogo> cloud|Hm
268 2014-02-05 13:08:36 <michagogo> cloud|wumpus: Are there any changes in your branch that are relevant to the build?
269 2014-02-05 13:09:08 <wumpus> michagogo|cloud: yes, in openssl
270 2014-02-05 13:09:10 <michagogo> cloud|In other words, do I need to figure out how to have it use your git repo for the actual build, or are your changes just in the descriptors
271 2014-02-05 13:09:16 <wumpus> so in the -deps
272 2014-02-05 13:09:18 <michagogo> cloud|I mean, the bitcoin build itself
273 2014-02-05 13:09:26 <wumpus> the boost is only determinism fixes
274 2014-02-05 13:09:34 <wumpus> (hence the version bump for -deps)
275 2014-02-05 13:10:01 <wumpus> "need to build OpenSSL with faketime because a timestamp is embedded into cversion.o" that's what triggered all of this
276 2014-02-05 13:11:00 <michagogo> cloud|Looks like it's just in the descriptors
277 2014-02-05 13:11:30 <wumpus> oh yes, it's not just in the descriptors, but the openssl change affects the end product
278 2014-02-05 13:11:35 <wumpus> -not
279 2014-02-05 13:12:10 <wumpus> also don't forget that the git commit id is embedded in the build
280 2014-02-05 13:12:35 <wumpus> so if you build from master with #3622's descriptors you will get a different result
281 2014-02-05 13:12:59 <michagogo> cloud|Hmm?
282 2014-02-05 13:14:21 <wumpus> the whole business with src/version.cpp and build.h
283 2014-02-05 13:14:22 <michagogo> cloud|Gitian pulls its own copy of the repo listed in the descriptors
284 2014-02-05 13:14:44 <wumpus> michagogo|cloud: yes, sucks doesn't it
285 2014-02-05 13:14:58 <michagogo> cloud|Okay, running this: micha@micha-Precise-ExtHD:~/GitianBuild/gitian-builder$ ./bin/gbuild ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml --commit bitcoin=v0.9.0rc1
286 2014-02-05 13:15:00 <wumpus> I've commented out that a long time ago and manage the inputs/bitcoin repository myself
287 2014-02-05 13:15:10 <sipa> i have a script that initializes gitian from a local repository
288 2014-02-05 13:15:12 <wumpus> otherwise it drove me insane
289 2014-02-05 13:16:58 <wumpus> the elegant way would be to add a command line option to gbuild 'ignore the repository in the descriptor and fetch from this (local) one'
290 2014-02-05 13:17:06 <michagogo> cloud|That's with the descriptor at the head of your 2014_01_gitian_linux_deps_fix branch
291 2014-02-05 13:18:06 <wumpus> in any case, I can build master with the new descriptors and cross-check with you, no problem
292 2014-02-05 13:18:20 <michagogo> cloud|wumpus: Well, if you think about it, it makes sense given gitian's goal, which is to build in a deterministic way
293 2014-02-05 13:18:51 <wumpus> yes, but usually I want to build in a deterministic way from my local repository, not the upstream one
294 2014-02-05 13:19:10 <wumpus> otherwise it's impossible to test other pulls in gitian, for example
295 2014-02-05 13:19:43 <michagogo> cloud|I guess.
296 2014-02-05 13:19:45 <wumpus> (which is also what happens, almost no one tests their pulls in gitian or while developing)
297 2014-02-05 13:20:21 <wumpus> so a day before the release all the gitian problems come to light :P
298 2014-02-05 13:20:27 <michagogo> cloud|I dislike the way Ubuntu handles multiple windows of one application
299 2014-02-05 13:20:45 <michagogo> cloud|wumpus: hey, I ran a gbuild at some point a couple weeks ago
300 2014-02-05 13:20:56 <michagogo> cloud|(it's the way I know to build a Windows binary)
301 2014-02-05 13:21:35 <wumpus> yes it's also the only way in which I build windows binaries nowadays, I had my own cross-build script that ran natively but it's far out of date
302 2014-02-05 13:22:13 <michagogo> cloud|But at the time it was git master that I was trying to build, so...
303 2014-02-05 13:23:00 <michagogo> cloud|(it was when Jeff updated bootstrap.dat to 279,000)
304 2014-02-05 13:23:57 <wumpus> in any case, just report which exact commit id you built and I'll build the same and compare
305 2014-02-05 13:24:11 <michagogo> cloud|v0.9.0rc1
306 2014-02-05 13:24:35 <wumpus> so you built 0.9.0rc1 with the descriptors of #3622?
307 2014-02-05 13:24:40 <michagogo> cloud|Yes
308 2014-02-05 13:24:45 <wumpus> ok, I'll do the same
309 2014-02-05 13:25:07 <michagogo> cloud|wumpus: http://paste.ubuntu.com/6879035/
310 2014-02-05 13:26:05 <michagogo> cloud|65825311a3860984ed7cafdb2f603ea69520f87ed33fafbb5d4ebbe2cfc576ec build/out/src/bitcoin-0.9.0.tar.gz
311 2014-02-05 13:26:05 <michagogo> cloud|micha@micha-Precise-ExtHD:~/GitianBuild/gitian-builder$ sha256sum build/out/src/bitcoin-0.9.0.tar.gz
312 2014-02-05 13:26:10 <michagogo> cloud|64-bit is running now
313 2014-02-05 13:26:50 <warren> wumpus: FWIW, the very first win64 build I left running before my trip to Asia. got back today and it was still running with no crash.
314 2014-02-05 13:27:13 <warren> ACTION failing to sleep.
315 2014-02-05 13:30:05 <gribble> The operation succeeded.
316 2014-02-05 13:30:05 <michagogo> cloud|;;later tell devrandom Did you see my comment about the Vagrantfile in Gitian?
317 2014-02-05 13:31:16 <gribble> The operation succeeded.
318 2014-02-05 13:31:16 <michagogo> cloud|;;later tell devrandom If not: I checked, and unless there's something I'm missing, it's not fully equivalent to what make-base-vm does to make a KVM base VM...
319 2014-02-05 13:35:00 <michagogo> cloud|wumpus: done
320 2014-02-05 13:35:01 <michagogo> cloud|http://paste.ubuntu.com/6879066/
321 2014-02-05 13:35:01 <michagogo> cloud|micha@micha-Precise-ExtHD:~/GitianBuild/gitian-builder$ head -n30 result/bitcoin-res.yml | pastebinit
322 2014-02-05 13:36:14 <wumpus> mine is still building
323 2014-02-05 13:37:14 <michagogo> cloud|Okay, I g2g
324 2014-02-05 13:37:29 <wumpus> okay, later
325 2014-02-05 13:37:32 <michagogo> cloud|You can check if that matches
326 2014-02-05 13:37:37 <wumpus> yes
327 2014-02-05 13:37:45 <michagogo> cloud|And maybe later I'll test for determinism in lxc
328 2014-02-05 13:39:23 <wumpus> michagogo|cloud: all match
329 2014-02-05 13:40:10 <goodbtc> I may be offtopic and have no idea if this is relevant, maybe sometime this could be important: http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html
330 2014-02-05 13:40:41 <wumpus> seems we have an actual deterministic build now, including intermediate targets, first time since the autotools switch... at least for linux, next stop would be windows
331 2014-02-05 13:40:45 <goodbtc> tl,dr : packet corrupted but checksum ok
332 2014-02-05 13:41:58 <wumpus> goodbtc: sounds familiar; I've had lots of those problems a few years ago with mobile internet connections
333 2014-02-05 13:44:13 <goodbtc> i hope it cannot affect a public key trenasmitted over the network, for example
334 2014-02-05 13:44:28 <wumpus> the IP-level checksum is lame and there's a considerable % of packets that make it through despite the checksum checking
335 2014-02-05 13:44:55 <wumpus> it can
336 2014-02-05 13:45:25 <goodbtc> call satoshi :P
337 2014-02-05 13:45:53 <wumpus> pgp-sign (or otherwise authenticate) your messages that contain public keys
338 2014-02-05 13:46:09 <wumpus> consider network corruption a MITM attack by nature
339 2014-02-05 13:52:15 <michagogo> cloud|wumpus: cool
340 2014-02-05 13:52:27 <michagogo> cloud|When I get home I'll test lxc
341 2014-02-05 13:52:40 <wumpus> michagogo|cloud: binaries all match but src/bitcoin-0.9.0.tar.gz doesn't match... wtf :)
342 2014-02-05 13:53:09 <michagogo> cloud|In my vm, and maybe I'll also spin up a do droplet
343 2014-02-05 13:53:43 <michagogo> cloud|wumpus: yeah, I've noticed those send to be non-set
344 2014-02-05 13:53:58 <michagogo> cloud|tend* non-det*
345 2014-02-05 13:54:11 <wumpus> I suppose the .tar.gz needs a sorting step as wll
346 2014-02-05 13:54:48 <wumpus> file systems tend to return files in non-determnistic order. And maybe the timestamps or other file attributes need to be normalized...
347 2014-02-05 13:55:01 <wumpus> it's a nightmare
348 2014-02-05 13:55:58 <sipa> find | sort | tar -T /dev/stdin
349 2014-02-05 13:56:35 <sipa> and maybe use --mtime to tar, to prevent it from storing mtimes of the actual files
350 2014-02-05 13:56:40 <michagogo> cloud|sipa: he already does something like that in boost and deps
351 2014-02-05 13:57:05 <wumpus> yes, that's what I made zip do, but the .tar.gz is created by 'make dist' internally
352 2014-02-05 13:57:13 <wumpus> so it needs to go through a kind of whitening filter
353 2014-02-05 13:58:35 <wumpus> hm no, that's for the source archive returned with the windows deps
354 2014-02-05 13:58:48 <wumpus> this one is created in the gitian descriptor itself so sipa's solution is easy to apply
355 2014-02-05 13:59:59 <wumpus> hm no it isn't.. that's a tar xf
356 2014-02-05 14:00:33 <wumpus> it doesn't build a .tar.gz with the binaries in it at all
357 2014-02-05 14:02:11 <michagogo> cloud|wumpus: yeah, release-process.md does that
358 2014-02-05 14:02:45 <wumpus> I suppose that's because the 32 and 64 bit files are collected over two VM runs
359 2014-02-05 14:02:54 <michagogo> cloud|Yeah
360 2014-02-05 14:03:03 <michagogo> cloud|Wait, if there are two builds
361 2014-02-05 14:03:13 <michagogo> cloud|And they produce a src tarball
362 2014-02-05 14:03:39 <michagogo> cloud|Does the 32-bit tarball just get overwritten by the 64-bit one?
363 2014-02-05 14:04:11 <wumpus> yes :-)
364 2014-02-05 14:04:50 <sipa> hopefully the generated source is independent of the target platform :)
365 2014-02-05 14:04:58 <wumpus> hopefully :)
366 2014-02-05 14:05:03 <michagogo> cloud|...
367 2014-02-05 14:05:09 <michagogo> cloud|You know what I mean.
368 2014-02-05 14:05:25 <michagogo> cloud|ACTION hopes that the digital dog in the bus stop is wrong
369 2014-02-05 14:05:32 <michagogo> cloud|sign on*
370 2014-02-05 14:05:47 <michagogo> cloud|How'd autocorrect get from sign to dog?
371 2014-02-05 14:05:55 <Diablo-D3> lol.
372 2014-02-05 14:06:00 <michagogo> cloud|Oh, I get it
373 2014-02-05 14:06:00 <wumpus> hehehehhe
374 2014-02-05 14:06:05 <Diablo-D3> get your digital dog on.
375 2014-02-05 14:06:23 <michagogo> cloud|D and S are together
376 2014-02-05 14:06:32 <Diablo-D3> wasd ftw
377 2014-02-05 14:06:35 <michagogo> cloud|I and O are together as well
378 2014-02-05 14:06:48 <wumpus> autocorrect is a threat to the sanity of human communication!
379 2014-02-05 14:07:01 <michagogo> cloud|wumpus: while it messed up a lot
380 2014-02-05 14:07:09 <michagogo> cloud|messes*... How ironic
381 2014-02-05 14:07:19 <michagogo> cloud|It fixes a hell of a lot more
382 2014-02-05 14:07:36 <wumpus> it will be forbidden after WW3 is started by an autocorrect mistake
383 2014-02-05 14:07:51 <michagogo> cloud|I hope not
384 2014-02-05 14:08:10 <michagogo> cloud|If that happens it'll mean much slower typing
385 2014-02-05 14:08:23 <sipa> wumpus: sounds like a hilarious plot for a hollywood doomsday-comedy
386 2014-02-05 14:08:27 <michagogo> cloud|(On mobile, that is)
387 2014-02-05 14:08:32 <wumpus> sipa: yes :)
388 2014-02-05 14:11:44 <Grouver> sipa, Would you know by any coincidence why 0.9.0rc1 doesnt load up my request url containing a signed paymentrequest file when I click the bitcoin uri? It does load up when i manually download the regarding payment request file and load it up in the client. Really weird.
389 2014-02-05 14:12:17 <wumpus> anything in debug.log?
390 2014-02-05 14:12:19 <sipa> Grouver: i know nothing about GUI stuff :)
391 2014-02-05 14:12:25 <Grouver> :(
392 2014-02-05 14:12:35 <wumpus> can you give the link?
393 2014-02-05 14:13:28 <wumpus> I can debug the issue probably
394 2014-02-05 14:13:29 <Grouver> wumpus, Its a localhost link. So. I can give it to you but it wouldnt work on your side.
395 2014-02-05 14:13:35 <wumpus> hmm
396 2014-02-05 14:13:43 <Grouver> This worked last time though.
397 2014-02-05 14:13:56 <Grouver> last time = a couple of months back
398 2014-02-05 14:14:07 <wumpus> so, anything in debug.log?
399 2014-02-05 14:14:44 <wumpus> it maybe you need to pass -debug=qt to get it to spew verbose messages about that
400 2014-02-05 14:29:46 <jgarzik> mornin'
401 2014-02-05 14:30:14 <jgarzik> Grouver, I wonder if it's an issue with signed requests
402 2014-02-05 14:30:28 <Grouver> it is :)
403 2014-02-05 14:31:09 <Grouver> but, when you load the payment request file itself, it will show you a green screen.
404 2014-02-05 14:32:25 <michagogo> cloud|ACTION hopes the Begin is backed up
405 2014-02-05 14:41:56 <Grouver> are payment requests through URI: nog logged?
406 2014-02-05 14:41:59 <Grouver> *not
407 2014-02-05 14:47:57 <jgarzik> Grouver, seems like an oversight, if so
408 2014-02-05 14:48:10 <jgarzik> Grouver, BitPay is working on testing payment requests right now, too
409 2014-02-05 14:53:05 <wumpus> Grouver: maybe optionally, have you tried passing -debug=qt ?
410 2014-02-05 14:53:37 <wumpus> there should be some logging for payment requests
411 2014-02-05 14:53:56 <wumpus> but it may be optional after the 0.9 logging changes
412 2014-02-05 14:54:00 <Grouver> it is just -debug
413 2014-02-05 14:54:13 <wumpus> that's ok, -debug should enable all debugging
414 2014-02-05 14:54:59 <Grouver> We have watched the debug output. We saw that the cert chaining failed. Strangly enough we only saw this error once in the debug output.
415 2014-02-05 14:55:44 <Grouver> If we load the bitcoin uri containing the payment request again debug doesnt show the same error again. Really weird.
416 2014-02-05 14:56:13 <michagogo> cloud|How does debug=1 in 0.9 compare to the default pre-0.9
417 2014-02-05 14:56:25 <michagogo> cloud|?
418 2014-02-05 14:56:38 <wumpus> michagogo|cloud: enables all debug information
419 2014-02-05 14:56:47 <wumpus> very, very noisy
420 2014-02-05 14:57:05 <wumpus> that's why -debug was split into categories
421 2014-02-05 14:57:17 <wumpus> --help should show which ones
422 2014-02-05 14:57:29 <michagogo> cloud|The amount of debug verbosity was reduced between 0.8 and 0.9, wasn't it?
423 2014-02-05 14:57:40 <michagogo> cloud|By default, that is
424 2014-02-05 14:57:42 <wumpus> if you don't provide -debug, yes
425 2014-02-05 14:57:53 <michagogo> cloud|What was removed?
426 2014-02-05 14:57:58 <wumpus> don't know by heart
427 2014-02-05 14:58:06 <michagogo> cloud|Okay
428 2014-02-05 14:58:32 <michagogo> cloud|Is the data with -debug the same as it was before?
429 2014-02-05 14:59:19 <wumpus> I don't think so, I think it logs more now, not sure though...
430 2014-02-05 14:59:52 <wumpus> you do realize that 0.8 is a year ago, that's ancient history in bitcoin terms :)
431 2014-02-05 15:00:10 <michagogo> cloud|Wow, really?
432 2014-02-05 15:00:27 <michagogo> cloud|When was 0.8.2?
433 2014-02-05 15:00:50 <wumpus> 0.8.0 was feb 2013, dunno about .2
434 2014-02-05 15:00:58 <sipa> Date: Mon Feb 18 18:49:32 2013 -0500
435 2014-02-05 15:00:58 <sipa> $ git show v0.8.0
436 2014-02-05 15:00:58 <sipa> Tagger: Gavin Andresen <gavinandresen@gmail.com>
437 2014-02-05 15:00:58 <sipa> tag v0.8.0
438 2014-02-05 15:00:59 <michagogo> cloud|Hmm, battery's about to die
439 2014-02-05 15:01:08 <michagogo> cloud|Almost home, though...
440 2014-02-05 15:01:11 <sipa> 0.8.2 was in may
441 2014-02-05 15:01:48 <michagogo> cloud|ACTION is on a bus
442 2014-02-05 15:02:34 <michagogo> cloud|ACTION greets Gavin
443 2014-02-05 15:05:30 <Grouver> wumpus, I am using gavins php payment request lib for this. But its an old one. From about 2~3 months ago. Would this maybe matter anything?
444 2014-02-05 15:05:56 <Grouver> Ill try launching it with debug=qt for now.
445 2014-02-05 15:06:03 <michagogo> cloud|wimpish: okay, about a minute away
446 2014-02-05 15:07:38 <wumpus> Grouver: should only make a difference if it still uses request= instead of r=, apart from that nothing changed in the standard
447 2014-02-05 15:08:18 <Grouver> Right, well its using the ?request parameter. So thats not it then.
448 2014-02-05 15:08:49 <wumpus> ?r= I hope?
449 2014-02-05 15:10:14 <wumpus> ?request= is what *doesn't* work anymore, it was shortened for compactness in qr codes and such
450 2014-02-05 15:10:22 <Grouver> wumpus fixed. Wow. ;_;
451 2014-02-05 15:10:52 <wumpus> heh
452 2014-02-05 15:11:11 <Grouver> It was using ?request
453 2014-02-05 15:12:47 <Grouver> Right. Thanks for the help.
454 2014-02-05 15:22:26 <nkuttler> do i need some newer release to send to 2NBSPnairPi7NvWWLHvZMV5FAyWy8wYEQA? should be valid, shouldn't it?
455 2014-02-05 15:23:51 <sipa> what type of address is that?
456 2014-02-05 15:23:56 <nkuttler> testnet
457 2014-02-05 15:24:21 <nkuttler> i got a request on my faucet, no idea who generated it
458 2014-02-05 15:24:29 <sipa> testnet addresses start with a m or n i thought
459 2014-02-05 15:24:40 <nkuttler> https://en.bitcoin.it/wiki/List_of_address_prefixes
460 2014-02-05 15:24:46 <nkuttler> 2 Testnet script hash
461 2014-02-05 15:25:12 <sipa> oh, testnet p2sh
462 2014-02-05 15:25:14 <nkuttler> not sure though what script hash means..
463 2014-02-05 15:25:43 <wumpus> nkuttler: seems to get a checksum mismatch
464 2014-02-05 15:25:49 <nkuttler> wumpus: oh
465 2014-02-05 15:26:10 <nkuttler> wumpus: yeah, on 0.8.6
466 2014-02-05 15:26:23 <nkuttler> but i vaguely remember this format being used for multi sig transactions.. or something..
467 2014-02-05 15:26:41 <michagogo> cloud|nkuttler: ,,(bc,wiki p2sh)
468 2014-02-05 15:26:42 <gribble> https://en.bitcoin.it/wiki/BIP_0016 | Dec 6, 2013 ... This page describes a BIP (Bitcoin Improvement Proposal). Please see BIP 0001 for more information about BIPs and creating them. Please do ...
469 2014-02-05 15:27:00 <nkuttler> michagogo|cloud: thanks
470 2014-02-05 15:27:14 <michagogo> cloud|Heh, "17:06:01 <michagogo|cloud> wimpish: okay, about a minute away" made it through
471 2014-02-05 15:27:23 <michagogo> cloud|My battery died as I sent it
472 2014-02-05 15:27:37 <michagogo> cloud|And couldn't fix the autocorrect
473 2014-02-05 15:27:52 <wumpus> nkuttler: if it gets a checksum mismatch it will get a checksum mismatch on any version, that part hasn't changed since the beginning
474 2014-02-05 15:28:15 <wumpus> newer version may add other address types (version bytes) but the checksum computation will not change
475 2014-02-05 15:28:19 <nkuttler> wumpus: how did you know it's a checksum mismatch? validateaddress just says valid false
476 2014-02-05 15:28:21 <wumpus> lol michagogo|cloud
477 2014-02-05 15:28:41 <wumpus> nkuttler: python-bitcoinlib
478 2014-02-05 15:28:45 <nkuttler> wumpus: ok, thanks
479 2014-02-05 15:28:55 <nkuttler> i mean, it's just my faucet. i guess people could submit invalid addresses
480 2014-02-05 15:29:24 <wumpus> maybe they clipped off a letter
481 2014-02-05 15:29:27 <michagogo> cloud|nkuttler: if you don't validate, of course they could
482 2014-02-05 15:29:31 <wumpus> or added one
483 2014-02-05 15:29:39 <nkuttler> michagogo|cloud: i just throw it at bitcoind
484 2014-02-05 15:29:51 <nkuttler> (later)
485 2014-02-05 15:29:55 <michagogo> cloud|Try truncating it, or adding each of the 58 chars
486 2014-02-05 15:30:00 <wumpus> hehe
487 2014-02-05 15:30:02 <nkuttler> heh
488 2014-02-05 15:30:09 <nkuttler> oh well, i guess i'll pass :)
489 2014-02-05 16:06:01 <michagogo> cloud|wumpus: sorry, got distracted when I got home
490 2014-02-05 16:06:40 <michagogo> cloud|D'you want a copy of my src tarball?
491 2014-02-05 16:11:55 <Subo1977> 31NAAEFTQ: which means your username?
492 2014-02-05 16:15:54 <wumpus> michagogo|cloud: first trying to add sorting/time normalizing to the tar output, then that will make sense
493 2014-02-05 16:19:37 <jiffe98> is there anything special about the genesis block that it needs to be hard coded?
494 2014-02-05 16:25:06 <michagogo> cloud|wumpus: Okay -- if you want it anyway, http://michagogo.cadoth.net/bitcoin-0.9.0.tar.gz
495 2014-02-05 17:07:50 <devrandom> michagogo|cloud: is the main concern about vagrant security or repeatability?
496 2014-02-05 17:08:12 <devrandom> it's definitely not secure right now, since images are not verified
497 2014-02-05 17:08:37 <michagogo> cloud|I don't know, there may be concerns about those
498 2014-02-05 17:09:32 <michagogo> cloud|What I was thinking, though, is that the Vagrant-generted VM should be as similar as possible to the KVM VMs that make-base-vm makes
499 2014-02-05 17:09:58 <devrandom> I definitely agree
500 2014-02-05 17:10:18 <devrandom> so need to investigate what the base image comes with and compare to what debbootstrap has
501 2014-02-05 17:10:23 <michagogo> cloud|Indeed.
502 2014-02-05 17:10:36 <michagogo> cloud|Wait, debootstrap? That's used for KVM?
503 2014-02-05 17:10:44 <michagogo> cloud|I thought it's only used for LXC
504 2014-02-05 17:10:50 <devrandom> that's what vmbuilder uses underneath
505 2014-02-05 17:10:59 <devrandom> vmbuilder is used for both KVM and LXC
506 2014-02-05 17:11:00 <michagogo> cloud|erm...
507 2014-02-05 17:11:00 <michagogo> cloud|sudo apt-get install debootstrap lxc # for LXC mode
508 2014-02-05 17:11:22 <devrandom> AFAIK vmbuilder pulls deboostrap too
509 2014-02-05 17:11:37 <michagogo> cloud|So why do you call for it specifically for lxc like that?
510 2014-02-05 17:11:48 <devrandom> I don't recall writing that line ;)
511 2014-02-05 17:12:10 <michagogo> cloud|http://packages.ubuntu.com/search?keywords=python-vm-builder
512 2014-02-05 17:12:24 <michagogo> cloud|http://packages.ubuntu.com/precise/python-vm-builder
513 2014-02-05 17:12:34 <michagogo> cloud|It does indeed depend on debootstrap
514 2014-02-05 17:12:42 <devrandom> yeah
515 2014-02-05 17:12:45 <michagogo> cloud|As well as qemu-kvm...
516 2014-02-05 17:14:19 <jaakkos> when an SPV node gives filters to neighbors, do they have to go through whole blockchain to match them? utxo surely can't be enough because the SPV wants to know about history as wel?
517 2014-02-05 17:14:45 <devrandom> jaakkos: it's up to the node to ask the peer for blocks after setting up the filter
518 2014-02-05 17:15:13 <devrandom> the node can ask for just a range of blocks if they already scanned earlier ones or have a reason to believe that the address wasn't used before a certain time
519 2014-02-05 17:15:18 <devrandom> e.g. timestamp on the key
520 2014-02-05 17:16:55 <jaakkos> alright, that makes sense
521 2014-02-05 17:19:16 <devrandom> interesting for autonomous agents: http://www.wired.com/wiredscience/2014/02/cryptography-breakthrough/
522 2014-02-05 17:22:14 <omefire> Hi
523 2014-02-05 17:22:28 <omefire> I'm trying to understand how bitcoin-qt calculates the balance.
524 2014-02-05 17:22:48 <omefire> from whatever I have glanced from the code, it seems like the UI gets the balance from CWallet.getBalance()
525 2014-02-05 17:23:07 <omefire> nd CWallet maintains an in-memory data structure of transactions : mapWallet or something similar
526 2014-02-05 17:23:20 <omefire> my question is : who calls/notifies CWallet about new transactions so that it can update itself ?
527 2014-02-05 17:23:29 <omefire> I have found that CWallet gets notified about new transactions by main.cpp via boost sigals .
528 2014-02-05 17:23:37 <omefire> but who calls main.cpp about transactions updates ?
529 2014-02-05 17:24:15 <jgarzik> omefire, fundamentally, your balance is your unspent outputs
530 2014-02-05 17:24:41 <jgarzik> omefire, that list of unspent outputs may be updated by (a) you, creating a new transaction or (b) receiving new data from a transaction via the network
531 2014-02-05 17:25:46 <sipa> omefire: main (the validation engine, mostly) sees all blocks and transactions that are processed (seen on the network, or locally generated)
532 2014-02-05 17:27:05 <TD> devrandom: yes, the papers are quite interesting. but it's not really clear how far it is from practicality
533 2014-02-05 17:27:15 <omefire> sipa : which class is the validation engine implemented in ? or the part that monitors network transactions ?
534 2014-02-05 17:27:23 <TD> devrandom: there are important impossibility results lurking at every corner
535 2014-02-05 17:28:51 <devrandom> TD: I see... will look at it further.
536 2014-02-05 17:29:39 <omefire> jgarzik + sipa, : And also : at any point in time, I have access to the whole blockchain on disk, right ? so, I can potentially look up unspent transactions for any addresses, not just those in my wallet. am I wrong ?
537 2014-02-05 17:30:20 <michagogo> cloud|omefire: You have the UTXO set, as a full node, yes
538 2014-02-05 17:30:40 <michagogo> cloud|If you want to be able to look up arbitrary transactions, set txindex=1 in yhe conf file
539 2014-02-05 17:30:47 <michagogo> cloud|Note that you'll need to reindex to activate that
540 2014-02-05 17:31:29 <sipa> omefire: you have the whole blockchain on disk, but not indexed
541 2014-02-05 17:31:59 <sipa> omefire: you only know where to find on disk every block, not where transactions are found, and certainly no information about addresses (those don't exist at the protocol level)
542 2014-02-05 17:32:15 <sipa> omefire: there is however a separate and mostly independent database of all unspent transaction outputs
543 2014-02-05 17:32:50 <sipa> omefire: validation is implemented in various classes and functions in main.cpp, coins.cpp, script.cpp, ...
544 2014-02-05 17:33:42 <jbitcm-_> can you help me please
545 2014-02-05 17:33:59 <omefire> sipa: how do I access the UTXO database ?
546 2014-02-05 17:34:13 <sipa> omefire: the pcoinsTip object
547 2014-02-05 17:34:36 <sipa> omefire: it represents the set of unspent transaction output at the currently-active block
548 2014-02-05 17:38:35 <omefire> sipa: this means that pcoinsTip is upto date ? (confused about the " currently-active block" part)
549 2014-02-05 17:38:52 <sipa> it is up to date when it is up to date
550 2014-02-05 17:39:06 <omefire> sipa: :)
551 2014-02-05 17:39:09 <sipa> obviously while it is being brought up to date, it is not
552 2014-02-05 17:39:16 <sipa> but usually, at stable points in the program, it is
553 2014-02-05 17:39:29 <sipa> and how do you define up to date?
554 2014-02-05 17:39:38 <sipa> there can always be a new block on the network you don't know about yet
555 2014-02-05 17:40:28 <omefire> sipa: up to date = data gets refreshed constantly, at least every 15 minutes or so.
556 2014-02-05 17:40:43 <sipa> there is no such guarantee
557 2014-02-05 17:40:49 <sipa> when you're building the index, it can take hours
558 2014-02-05 17:41:18 <sipa> the only guanrantee is that at stable points in the code (while cs_main is not being held, for example), pcoinsTip is synchronized with chainActive
559 2014-02-05 17:42:01 <omefire> makes sense.
560 2014-02-05 17:45:09 <omefire> sipa : if instead of going through pcoinsTip, I wanted to access the UTXO from a separate program, is there a file or database file that I can open up and read from ?
561 2014-02-05 17:45:28 <michagogo> cloud|omefire: the chainstate directory
562 2014-02-05 17:48:04 <omefire> michaelgogo: thanks.
563 2014-02-05 17:48:27 <michagogo> cloud|omefire: Micha isn't short for Michael
564 2014-02-05 17:48:46 <michagogo> cloud|http://en.wikipedia.org/wiki/Micha
565 2014-02-05 17:49:07 <omefire> micha : Oops ! sorry
566 2014-02-05 17:49:12 <michagogo> cloud|np :)
567 2014-02-05 17:50:55 <omefire> micha : so in order to read the UTXO, I'd have to read and parse these files in chainstate folder ?
568 2014-02-05 17:51:27 <omefire> hmmm, it won't be fun
569 2014-02-05 17:52:36 <wumpus> I wouldn't suggest trying to parse the chainstate data yourself, it's not a supported interface
570 2014-02-05 17:52:56 <wumpus> also AFAIK you cannot access the leveldb data while bitcoind is running
571 2014-02-05 17:54:32 <jgarzik> wumpus, correct
572 2014-02-05 17:54:43 <jgarzik> though "should not" is perhaps a better phrase :)
573 2014-02-05 17:54:58 <omefire> ok,
574 2014-02-05 17:55:41 <omefire> can I compute the UTXO myself by using code similar to this one ? https://bitcointalk.org/index.php?topic=117866.0