1 2012-05-16 00:03:24 <upou> sipa: https://bitcointalk.org/index.php?topic=81954.msg902819;topicseen#msg902819
  2 2012-05-16 00:06:18 <Matt_von_Mises> I think I made a mistake when I made my code in little endian. Doesn't go with bitcoin too nicely.
  3 2012-05-16 00:06:41 <gmaxwell> upou: "After encrypting my wallet on the Bitcoin client, it started to crash every time i entered the correct passphrase" means you have an incorrect passphrase in older versions of bitcoin  that bug has since been fixed.
  4 2012-05-16 00:07:40 <gmaxwell> "After upgrading to 0.6.2 I am unable to start bitcoin-qt at all" may be an upgrade after unclean shutdown.  Which can be most easily fixed by deleting all the database files except the wallet.. Though they should be backed up first in case the wallet is corrupted.
  5 2012-05-16 00:08:22 <luke-jr> gmaxwell: it's not that simple
  6 2012-05-16 00:08:36 <luke-jr> unclean shutdown means you need the database/ dir for wallet.dat
  7 2012-05-16 00:08:40 <gmaxwell> luke-jr: what isn't?
  8 2012-05-16 00:08:50 <luke-jr> and if the database/ dir exists, it could very well recreate blkindex.dat from it too
  9 2012-05-16 00:08:52 <gmaxwell> luke-jr: no not usually, because wallet.dat gets flushed all the time.
 10 2012-05-16 00:09:14 <gmaxwell> luke-jr: I did say "deleting all the database files" and "they should be backed up first in case the wallet is corrupted".
 11 2012-05-16 00:11:11 <upou> he/she replied the thread
 12 2012-05-16 00:11:24 <upou> fatal error
 13 2012-05-16 00:14:08 <gmaxwell> upou: yea, thats the behaior you get when upgrading an uncleanly shut down node.
 14 2012-05-16 00:14:45 <upou> ok
 15 2012-05-16 03:17:20 <wumpus> sipa: https://github.com/bitcoin/bitcoin/issues/1015  it's a known problem in the swedish translation, I think it's been fixed on transifex
 16 2012-05-16 03:27:36 <gribble> New news from bitcoinrss: laanwj opened pull request 1321 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1321>
 17 2012-05-16 03:35:46 <Nachtwind> hi: Simple question: Are transaction IDs randomly chosen or are they manipulable/choosable?
 18 2012-05-16 03:36:39 <MagicalTux> it's not random, nor manipulable/choosable
 19 2012-05-16 03:36:47 <MagicalTux> it's a hash
 20 2012-05-16 03:38:04 <Nachtwind> ok
 21 2012-05-16 03:38:14 <Nachtwind> thanks
 22 2012-05-16 03:38:58 <gmaxwell> er, well they're manipulatable  as its a hash of the transaction data.
 23 2012-05-16 03:39:31 <gmaxwell> with 2^n attempted modifications of the transaction on average you can choose n bits of the txn id.
 24 2012-05-16 03:39:57 <Nachtwind> ok, so manipulable but not in reality occuring
 25 2012-05-16 03:40:23 <Nachtwind> but the txid is always 64 characters long?
 26 2012-05-16 03:40:44 <gmaxwell> yes, it's a hex encode of a 256 bit hash value.
 27 2012-05-16 03:40:59 <Nachtwind> ok, great
 28 2012-05-16 04:34:57 <luke-jr> wow, I have an OSX cross-compiler
 29 2012-05-16 04:35:04 <luke-jr> better sleep to be sure it's not a dream
 30 2012-05-16 04:35:08 <luke-jr> night
 31 2012-05-16 08:55:01 <slothbag> hi all, anyone know of a good tool to convert a 44 byte priv key to other formats for importing into the reference client?
 32 2012-05-16 09:22:16 <gribble> New news from bitcoinrss: Diapolo opened pull request 1322 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1322>
 33 2012-05-16 11:39:32 <gribble> New news from bitcoinrss: Diapolo opened pull request 1323 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1323>
 34 2012-05-16 13:21:35 <jgarzik> looks like gavinandresen is on top of it, and most of them probably related to obscure DoS's way down on the priority scale
 35 2012-05-16 13:22:56 <gavinandresen> jgarzik: yes, but low-priority obscure DoS's have a way of turning into critical issues, so I do appreciate him bringing them up
 36 2012-05-16 13:24:14 <gmaxwell> I'm a little sketpical that the caching approach is really all that useful in an anti-dos context the attacker will just build a working set larger than the cache. But I was waiting to see the code to comment.
 37 2012-05-16 13:27:07 <sipa> about ipaddr.dat: do we care enough to do a conversion from addr.dat to ipaddr.dat?
 38 2012-05-16 13:27:17 <sipa> it would be trivial to implement, but low priority nonetheless
 39 2012-05-16 13:28:22 <gmaxwell> I'm much more concerned about e.g. avoiding losing ipaddr.dat during unclean restarts than preserving it across the upgrade.
 40 2012-05-16 13:28:49 <sipa> it's written to a separate file now and moved atomically
 41 2012-05-16 13:28:54 <Eliel> a partial solution would be the possibility of adding permanent authenticated "friend" nodes. no?
 42 2012-05-16 13:29:05 <sipa> Eliel: -addnode ?
 43 2012-05-16 13:29:30 <Eliel> yes, but more visibly in the interface. Plus, is that authenticated?
 44 2012-05-16 13:29:35 <gmaxwell> It's unfortunate that we don't have a way to have authenticated peerings, but not a priority.
 45 2012-05-16 13:29:42 <sipa> how do you mean authenticated?
 46 2012-05-16 13:30:10 <Eliel> every node already has lots of private encryption keys. I don't understand what's the problem with authenticating them :P
 47 2012-05-16 13:30:11 <sipa> add a host key, and the ability to specify an address the peer has to be able to sign with?
 48 2012-05-16 13:30:28 <gmaxwell> sipa: If I'm evil McHacker and I controll your ISP or just your local router, I can replace all of your addnoded peers with my own hosts and you won't know.
 49 2012-05-16 13:30:37 <sipa> right, that
 50 2012-05-16 13:30:38 <helo> problem is that they're all encrypted, right?
 51 2012-05-16 13:30:50 <sipa> but i wouldn't use wallet keys for that
 52 2012-05-16 13:31:00 <gmaxwell> helo: encrypted?? No. There is no encryption in bitcoin _at all_ except for the wallet encryption.
 53 2012-05-16 13:31:01 <sipa> that's fundamentally incompatible with the separation of wallet and node
 54 2012-05-16 13:31:16 <Eliel> sipa: easy enough to generate one key just for that.
 55 2012-05-16 13:31:21 <sipa> of course
 56 2012-05-16 13:31:47 <helo> gmaxwell: wallet encryption what i'm referring to. the "lots of private encryption keys" that would be convenient for host authentication are all encrypted
 57 2012-05-16 13:32:04 <jgarzik> gmaxwell: that's not really a problem that either addr.dat or ipaddr.dat addresses
 58 2012-05-16 13:32:07 <gmaxwell> helo: ah I see what you're saying.
 59 2012-05-16 13:32:30 <gmaxwell> jgarzik: I know, I was responding to sipa's question about eliel's tangent.
 60 2012-05-16 13:32:46 <Eliel> wallet keys could perhaps be used in the negotiation process to make it simpler for users to communicate to each other the credentials.
 61 2012-05-16 13:32:48 <gavinandresen> sipa: I vote no on upgrade code. 
 62 2012-05-16 13:33:19 <sipa> ok
 63 2012-05-16 13:33:37 <jgarzik> gavinandresen: why?
 64 2012-05-16 13:33:53 <gavinandresen> jgarzik: less code to maintain, bugfix, etc
 65 2012-05-16 13:34:12 <sipa> jgarzik: your pullreq has no upgrade code in it, right?
 66 2012-05-16 13:34:33 <gavinandresen> This is a one-time upgrade, and rebuilding the address database from seeds seems perfectly fine to me
 67 2012-05-16 13:34:54 <jgarzik> ah, ok.  I misunderstood.
 68 2012-05-16 13:34:58 <sipa> I somehow would hate to make the network forget everything
 69 2012-05-16 13:35:01 <jgarzik> I thought gavinandresen was NAK'ing ipaddr.dat.
 70 2012-05-16 13:35:08 <gmaxwell> sipa: people upgrade quite slowly however.
 71 2012-05-16 13:35:11 <jgarzik> sipa: no upgrade code
 72 2012-05-16 13:35:25 <jgarzik> just ignores addr.dat completely, and rebuilds ipaddr.dat from scratch
 73 2012-05-16 13:35:30 <sipa> yes, booting from seednodes is (right now) not a problem at all
 74 2012-05-16 13:35:39 <gmaxwell> Also, is ipaddr.dat a good name? presumably we'll store onions in there too when the onion patch gets pulled.
 75 2012-05-16 13:35:57 <sipa> gmaxwell: indeed; but many people thought addr.dat was for the address book
 76 2012-05-16 13:36:07 <sipa> so i think ipaddr is a lot clearer already
 77 2012-05-16 13:36:09 <gavinandresen> peers.dat
 78 2012-05-16 13:36:16 <jgarzik> sure
 79 2012-05-16 13:36:21 <sipa> peers is fine to me as well
 80 2012-05-16 13:37:10 <gmaxwell> Indeed. I like peers too.
 81 2012-05-16 13:37:41 <gmaxwell> of if you want to be really obvious p2p-peers.dat
 82 2012-05-16 13:37:59 <sipa> Eliel: are you sure you're not talking about Tor?
 83 2012-05-16 13:38:12 <Eliel> sipa: yes, tor doesn't authenticate.
 84 2012-05-16 13:38:26 <gmaxwell> Onions are authenticated but not mutually.
 85 2012-05-16 13:38:26 <sipa> a tor destination is a hash of a public key
 86 2012-05-16 13:38:43 <gmaxwell> there are applications which do mutual onion auth though.
 87 2012-05-16 13:38:58 <sipa> Eliel: i mean tor hidden services, by the way, not using exit nodes
 88 2012-05-16 13:39:36 <Eliel> sipa: hmm... I am not too familiar with tor
 89 2012-05-16 13:39:58 <luke-jr_> anyone want an OSX cross compiler suite?
 90 2012-05-16 13:40:16 <sipa> luke-jr_: if you can make gitian produce OSX binaries...
 91 2012-05-16 13:40:26 <luke-jr_> sipa: that's the plan ;)
 92 2012-05-16 13:40:52 <Eliel> anyway, what I want to say is that if enough users set up these authenticated connections, sybil attacks become very difficult if not impossible.
 93 2012-05-16 13:40:54 <luke-jr_> except, I don't see a problem with using Nokia's Qt binaries
 94 2012-05-16 13:41:44 <jgarzik> peers.dat it is, then
 95 2012-05-16 13:41:46 <sipa> Eliel: quite like bitcoin; a node has a secret key; the hash of its public key is its onion address, and communication with those is afaik authenticated using a public key whose hash equals the address
 96 2012-05-16 13:42:19 <jgarzik> Any other BDB schema changes I should look into?
 97 2012-05-16 13:42:43 <jgarzik> I could put blk????.dat and BDB metadata into GetDataDir() / "blockchain"
 98 2012-05-16 13:43:04 <Eliel> sipa: ah, that sounds like a pretty sensible design :)
 99 2012-05-16 13:43:33 <sipa> Eliel: furthermore, bitcoin 0.7.0 will most likely support connecting bitcoins running on a hidden service
100 2012-05-16 13:43:48 <sipa> jgarzik: i'd like that (and i like the BDB refactots too), but i wonder about backward compatibility there
101 2012-05-16 13:44:00 <jgarzik> about the only other BDB change I can think of is possibly doing some test runs, then looking at the output of db_stat to see if database page size can be tuned.
102 2012-05-16 13:44:49 <Eliel> sipa: I'm not so sure if the feature should be restricted to those who wish to use tor.
103 2012-05-16 13:45:08 <sipa> for peer addresses, losing them is not that much of an issue, but i suppose many people will complain if they have to redownload the blockchain
104 2012-05-16 13:45:24 <sipa> of course, the loadblock could be used to re-import their blk0001.dat file
105 2012-05-16 13:45:40 <sipa> but that'd require some sort of migration wizard for GUI users
106 2012-05-16 13:46:31 <gavinandresen> luke-jr_: Nokia's OSX Qt binaries are fine as long as we can redistribute them as part of the Bitcoin-Qt.app bundle and they're compatible with osx10.5 users
107 2012-05-16 13:46:34 <gmaxwell> well loadblock had the unfortunate quality of needing 2x disk space.
108 2012-05-16 13:46:34 <jgarzik> sipa: yes, people must re-download the block chain after my BDB changes (or at least re-index).
109 2012-05-16 13:47:01 <jgarzik> I think I can whip up a migration that does not require blk????.dat duplication
110 2012-05-16 13:47:12 <sipa> gmaxwell: maybe... we could have a reindex function that just reuses blk0001.dat
111 2012-05-16 13:47:19 <jgarzik> maybe an external tool is better
112 2012-05-16 13:47:20 <sipa> i don't think that would be hard
113 2012-05-16 13:47:29 <sipa> it would be almost as slow, though
114 2012-05-16 13:47:32 <jgarzik> gavinandresen's bitcointools should already know blk????.dat format
115 2012-05-16 13:47:34 <gavinandresen> luke-jr_: oh, and it would be nice if they don't make the osx download a lot bigger (they might if they've got ppc support in them)
116 2012-05-16 13:47:43 <jgarzik> and bdb
117 2012-05-16 13:48:07 <gavinandresen> jgarzik: yes, bitcointools knows about blk*
118 2012-05-16 13:48:41 <sipa> reindexing is easier, i think
119 2012-05-16 13:48:58 <luke-jr_> gavinandresen: my cross compiler is only x86_32
120 2012-05-16 13:49:09 <jgarzik> I think the easiest to code is:  move blk????.dat to subdirectory, then internally reindex  (all within bitcoin.git codebase)
121 2012-05-16 13:49:19 <jgarzik> long startup, one time cost
122 2012-05-16 13:49:40 <sipa> jgarzik: exactly
123 2012-05-16 13:49:41 <jgarzik> maybe pop up "your program is about to pause for a REALLY LONG TIME" message box ;)
124 2012-05-16 13:49:48 <sipa> jgarzik: a progress bat!
125 2012-05-16 13:49:50 <sipa> *bar
126 2012-05-16 13:49:53 <drizztbsd> luke-jr: x86_64 is faster
127 2012-05-16 13:50:00 <sipa> drizztbsd: unsure
128 2012-05-16 13:50:06 <sipa> hmm, a progress bat would be nice as well
129 2012-05-16 13:50:10 <gavinandresen> drizztbsd: _32 is more compatible, which is more important
130 2012-05-16 13:50:13 <jgarzik> heh
131 2012-05-16 13:50:26 <drizztbsd> I use bitcoin on x86_64 linux without any problem :)
132 2012-05-16 13:50:27 <jgarzik> a progress bar would be ideal -- but a bigger code burden for this one-time upgrade
133 2012-05-16 13:50:38 <kinlo> luke-jr: if you drop leopard as supported platform (which is now a few years unsupported by apple) you have 64bit support on all machines...
134 2012-05-16 13:50:44 <jgarzik> progress bar would be called _very_ early in GUI code
135 2012-05-16 13:50:50 <jgarzik> maybe wumpus can help
136 2012-05-16 13:51:01 <luke-jr> kinlo: but why bother?
137 2012-05-16 13:51:04 <sipa> jgarzik: i wouldn't bother with the GUI for now
138 2012-05-16 13:51:05 <luke-jr> drizztbsd: not significantly
139 2012-05-16 13:51:19 <kinlo> luke-jr: I wouldn't bother creating a 32bit version actually
140 2012-05-16 13:51:25 <sipa> jgarzik: worst case, we make a pop-up message "upgrading to new database format; go drink 15 coffees"
141 2012-05-16 13:51:39 <luke-jr> kinlo: 32-bit is easier and uses less memory
142 2012-05-16 13:51:49 <sipa> jgarzik: best case, the GUI guys come up with something nice
143 2012-05-16 13:51:50 <kinlo> luke-jr: easier in what way?
144 2012-05-16 13:51:57 <luke-jr> kinlo: people have actually done it
145 2012-05-16 13:52:25 <jgarzik> sipa: yes -- I was thinking to call InitWarning() to pop up message box when operation begins.  that is known to work in init.cpp already.
146 2012-05-16 13:52:34 <sipa> jgarzik: exactly
147 2012-05-16 13:52:50 <jgarzik> OK, "upgrade + message box" added to TODO list
148 2012-05-16 13:53:05 <jgarzik> any schema or $MAJOR changes to consider?
149 2012-05-16 13:53:08 <jgarzik> now's the time....
150 2012-05-16 13:54:33 <luke-jr> jgarzik: it'd be nice to prepare for the blockchain/wallet split
151 2012-05-16 13:54:42 <jgarzik> medium term, isolating all file and database I/O behind a class interface (I was going to call it CBlockStore :)) would be nice.
152 2012-05-16 13:54:43 <luke-jr> by indexing every address seen
153 2012-05-16 13:54:51 <luke-jr> rather than just "my own"
154 2012-05-16 13:55:00 <jgarzik> i.e. move CBlock::WriteToDisk() and CBlock::AddBlockIndex() outside of CBlock
155 2012-05-16 13:55:21 <jgarzik> then CBlock could be reused outside of bitcoind
156 2012-05-16 13:55:23 <gmaxwell> Also should we perhaps be detecting upgrades on unclean BDB and just refusing to start?   I'm getting a little concerned about the "HALP! I UPGRADED AND IT DOESN'T START" anymore reports.
157 2012-05-16 13:55:52 <sipa> luke-jr: i think such an index is nice for certain purposes, but it should certainly not be necessary
158 2012-05-16 13:55:53 <jgarzik> gmaxwell: we don't care about old BDB data
159 2012-05-16 13:56:04 <jgarzik> gmaxwell: upgrade only requires blk????.dat data
160 2012-05-16 13:56:16 <gmaxwell> jgarzik: Ahem. Wallets?
161 2012-05-16 13:56:34 <jgarzik> gmaxwell: I meant old blkindex.dat/addr.dat, to be specific
162 2012-05-16 13:56:54 <gmaxwell> So far I've not encountered anyone with a hosed wallet in upgrade, though I expect thats just a matter of time too.
163 2012-05-16 13:57:51 <jgarzik> sipa: if it's a non-BDB format (I assume it is), we want on-disk magic numbers and checksums
164 2012-05-16 13:58:06 <jgarzik> sipa: I _think_ that is missing from serialized data, but I could be wrong
165 2012-05-16 13:58:21 <jgarzik> verifying that is one final peers.dat issue on my list
166 2012-05-16 13:58:34 <sipa> jgarzik: it has both :)
167 2012-05-16 13:58:39 <jgarzik> sipa: good
168 2012-05-16 13:59:06 <jgarzik> sipa: as long as file(1) has a signature to work with, and we detect on-disk corruption, life is good.
169 2012-05-16 13:59:31 <jgarzik> file(1) and other utils need to be able to uniquely identify our files
170 2012-05-16 13:59:45 <sipa> ack on that
171 2012-05-16 14:00:06 <luke-jr> jgarzik: able to, or actually do?
172 2012-05-16 14:00:11 <sipa> ok, how does one use a union in C++?
173 2012-05-16 14:00:18 <luke-jr> eg, how does that fit in with sipa's custom HD wallet format?
174 2012-05-16 14:00:25 <gmaxwell> sipa: trying to fix that aliasing bit for the socket?
175 2012-05-16 14:00:25 <sipa> luke-jr: orthogonal
176 2012-05-16 14:00:34 <jgarzik> luke-jr: the possibility exists.  creating of file(1) patches is not a merge requirement.
177 2012-05-16 14:00:47 <sipa> gmaxwell: no, i'm refactoring CBitcoinAddress to be independent from its base58 encoding
178 2012-05-16 14:01:10 <sipa> luke-jr: i could implement hd wallets with the current wallet format
179 2012-05-16 14:01:24 <luke-jr> sipa: maybe, but I think it's still a good idea to do that append-only thing
180 2012-05-16 14:01:34 <sipa> luke-jr: absolutely
181 2012-05-16 14:01:41 <sipa> but they're independent improvements i mean
182 2012-05-16 14:01:55 <sipa> script.h:42:16: error: member CKeyID CTxDestination::<anonymous union>::keyID with constructor not allowed in union
183 2012-05-16 14:03:13 <sipa> i could take th long, complex but neater way of using a superclass and virtual subclasses for the different destinations
184 2012-05-16 14:03:46 <sipa> or just use a union if that worked
185 2012-05-16 14:04:30 <sipa> hmm, boost has tagged unions
186 2012-05-16 14:08:08 <sipa> do we need support for MSVC6 and 7.0, or Intel C++ 7.0?
187 2012-05-16 14:08:09 <jgarzik> sipa: where can I find magic number and checksum implementation?
188 2012-05-16 14:08:43 <jgarzik> sipa: is it buried somewhere in serialize.h?
189 2012-05-16 14:09:06 <sipa> jgarzik: no, not at all, but my prototype implementation of the append-only format has those
190 2012-05-16 14:09:49 <jgarzik> sipa: OK, so I need to write that code, for peers.dat.
191 2012-05-16 14:10:11 <sipa> oh, yes
192 2012-05-16 14:10:25 <sipa> just put a 4-byte magic in front
193 2012-05-16 14:11:04 <luke-jr> please test: git clone git://gitorious.org/cross-osx/cross-osx.git && cd cross-osx && make
194 2012-05-16 14:11:37 <jgarzik> sipa: yes, I know how :)   I had misunderstood our earlier conversation, and thought you were saying that bitcoin's serialize code -already had- magic number and checksum built into it.
195 2012-05-16 14:11:47 <sipa> jgarzik: i see; no, it doesn't
196 2012-05-16 14:12:13 <sipa> the blk0001.dat does, by the way
197 2012-05-16 14:12:38 <jgarzik> sipa: interesting!
198 2012-05-16 14:13:00 <jgarzik> sipa: where may I find the code to read/write blk????.dat's magic number and checksum?
199 2012-05-16 14:14:17 <sipa> jgarzik: CBlock::WriteToDisk(), main.cpp line 955
200 2012-05-16 14:14:34 <sipa> fileout << FLATDATA(pchMessageStart) << nSize;
201 2012-05-16 14:14:53 <sipa> every block in the file starts with the message header + block size
202 2012-05-16 14:14:59 <sipa> followed by the serialized full block
203 2012-05-16 14:16:25 <jgarzik> sipa: main.h you mean.  I see it thanks.
204 2012-05-16 14:16:41 <sipa> ah, right!
205 2012-05-16 14:16:48 <jgarzik> sipa: I guess that changes with -testnet, too... nice
206 2012-05-16 14:16:48 <sipa> somehow i don't expect such code in a .h file
207 2012-05-16 14:16:51 <sipa> ...
208 2012-05-16 14:17:02 <jgarzik> sipa: agreed
209 2012-05-16 14:17:19 <jgarzik> sipa: I can move it to .cpp when I move WriteToDisk outside CBlock
210 2012-05-16 14:17:29 <sipa> go ahead
211 2012-05-16 14:17:59 <jgarzik> sipa: any objection to using pchMessageStart for peers.dat?
212 2012-05-16 14:18:08 <jgarzik> it nicely changed with each block chain
213 2012-05-16 14:18:29 <sipa> i'd just use that, yes
214 2012-05-16 14:25:55 <sipa> jgarzik: do you intend to add a checksum as well? quite sure loading random data into addrman could create trouble
215 2012-05-16 14:26:02 <gavinandresen> sipa: I'm moving code in key.h to key.cpp right now ...
216 2012-05-16 14:26:41 <sipa> gavinandresen: ah good! (i'm actually refactoring key/script/keystore/base58 a bit, but moving things shouldn't be a problem)
217 2012-05-16 14:27:22 <jgarzik> sipa: yes.  doing the simple approach:  read datastream into RAM, checksum, deserialize into addrman.
218 2012-05-16 14:27:52 <sipa> jgarzik: good enough; addrman data is limited to a few megabytes in size anyway
219 2012-05-16 14:28:05 <jgarzik> sipa: HOWEVER, that does not protect against bugs in the program that occur prior to previous checksum-and-write
220 2012-05-16 14:28:28 <jgarzik> granted, that is a tiny window, but such bugs do exist on occasion
221 2012-05-16 14:28:48 <jgarzik> someone could intentionally write garbage, then properly checksum it
222 2012-05-16 14:28:58 <sipa> i have good hope (though no guarantees at all, of course), that there are no bugs causing inconsistencies in addrman anyway
223 2012-05-16 14:29:02 <sipa> *anymore
224 2012-05-16 14:29:48 <sipa> anyway, got to go
225 2012-05-16 14:59:44 <gribble> New news from bitcoinrss: laanwj opened pull request 1324 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1324>
226 2012-05-16 15:08:26 <wumpus> jgarzik: I guess we could add a progressbar to the splash screen somehow
227 2012-05-16 15:09:17 <wumpus> the only thing that would have to be passed extra to initmessage() from the core is a progress %
228 2012-05-16 15:17:35 <luke-jr> sync.h is missing an include util.h (for Sleep)
229 2012-05-16 15:19:34 <Joric> http://www.groklaw.net/article.php?story=20120515120106322
230 2012-05-16 15:19:35 <Joric> Judge: We heard the testimony of Mr. Bloch. I couldn't have told you the first thing about Java before this problem. I have done, and still do, a significant amount of programming in other languages. I've written blocks of code like rangeCheck a hundred times before. I could do it, you could do it.
231 2012-05-16 15:19:52 <Joric> that Judge...
232 2012-05-16 15:20:17 <Joric> he's amazing
233 2012-05-16 15:33:45 <luke-jr> devrandom: so this OSX cross-compiler requires a lot of input files& how do you suggest deal with it? :p
234 2012-05-16 15:38:14 <Diablo-D3> joric: I know
235 2012-05-16 15:38:16 <Diablo-D3> damnit he left
236 2012-05-16 16:03:06 <devrandom> luke-jr: if the inputs are from separate authors, I would keep them separate
237 2012-05-16 16:03:26 <luke-jr> devrandom: most are patch files
238 2012-05-16 16:03:54 <luke-jr> 7 patches
239 2012-05-16 16:04:06 <devrandom> are the patch files maintained by bitcoin people?
240 2012-05-16 16:04:10 <luke-jr> I guess I could provide a script to auto download all but one
241 2012-05-16 16:04:15 <luke-jr> devrandom: they're not maintained period.
242 2012-05-16 16:04:25 <devrandom> maybe stick the patch files in a repo and have just one input
243 2012-05-16 16:04:42 <devrandom> how would people get the patch files?
244 2012-05-16 16:04:49 <luke-jr> they're on a webserver
245 2012-05-16 16:05:27 <devrandom> I would put them in a repo...
246 2012-05-16 16:05:51 <devrandom> on gitorious ;)
247 2012-05-16 16:06:07 <luke-jr> well, you could right now do: git clone git://gitorious.org/cross-osx/cross-osx.git && cd cross-osx && make
248 2012-05-16 16:06:12 <luke-jr> and get a working cross compiler
249 2012-05-16 16:07:07 <devrandom> then that's just one input, right?
250 2012-05-16 16:07:13 <devrandom> if all the patches are there too
251 2012-05-16 16:07:15 <luke-jr> make does the fetching there ;)
252 2012-05-16 16:07:28 <devrandom> oh
253 2012-05-16 16:07:39 <luke-jr> except for Apple's stupid no-direct-links Xcode DVD
254 2012-05-16 16:07:44 <luke-jr> that still needs a user to get
255 2012-05-16 16:08:35 <devrandom> so you are saying that the makefile from cross-osx gets some patches from a webserver, gets some stuff off the Xcode DVD, and then compiles?
256 2012-05-16 16:09:36 <luke-jr> yes
257 2012-05-16 16:10:40 <devrandom> and that just produces the cross-compiler?  then there's the process of compiling bitcoin itself?
258 2012-05-16 16:11:15 <devrandom> I would separate the two steps into separate gitian scripts
259 2012-05-16 16:11:18 <luke-jr> right, need to build bdb, Qt, boost, openssl after that
260 2012-05-16 16:11:26 <luke-jr> I want to put those in their own ymls tho
261 2012-05-16 16:11:36 <devrandom> so build the x-compiler first, and provide that as input to the main bitcoin script
262 2012-05-16 16:11:43 <luke-jr> osx-deps/{cross,bdb,qt,boost,openssl}.yml
263 2012-05-16 16:12:15 <devrandom> okay, so one script for the x-compiler, one script per dependency, and a final one to build bitcoin
264 2012-05-16 16:12:20 <luke-jr> yep
265 2012-05-16 16:12:42 <devrandom> the x-compiler may be a bit tricky, because the build process is not meant to access the network
266 2012-05-16 16:12:45 <luke-jr> also, one of the inputs for cross-osx is from svn
267 2012-05-16 16:12:59 <devrandom> sigh
268 2012-05-16 16:14:01 <devrandom> I would put all the deps in one or more git repos, and patch the makefile so that it doesn't fetch from the network but takes the supplied git clone dirs
269 2012-05-16 16:14:50 <devrandom> the whole point of gitian is that you know exactly what goes into a build... the build process fetch from the network would make that impossible
270 2012-05-16 16:15:06 <luke-jr> making your own private git clones kinda defeats that too :p
271 2012-05-16 16:15:53 <devrandom> the git clones could be accessed by anybody wanting to replicate the build
272 2012-05-16 16:16:47 <devrandom> that said, you could just distribute the x-compiler binaries
273 2012-05-16 16:17:01 <devrandom> since hopefully they can't break out of the VM
274 2012-05-16 16:17:25 <devrandom> but then you won't know for sure that the result is safe, because the binaries might have been tampered with
275 2012-05-16 16:17:29 <luke-jr> that's just about as safe as just distributing the OSX bitcoin bins
276 2012-05-16 16:19:23 <devrandom> another option - you could not worry about building deterministic x-compiler binaries, and hope that the final bitcoin output doesn't mutate due to that
277 2012-05-16 16:20:54 <devrandom> if someone patches the x-compiler in a way that affects code generation, it might be difficult to track down the reason for the diff if you have 5 devs all building their own different x-compiler
278 2012-05-16 16:21:39 <devrandom> so I would make at least some attempt to make sure that everybody is using the same inputs
279 2012-05-16 16:27:00 <luke-jr> building a x-compiler for OS X isn't entirely straight-forward (for example, the default -O2 breaks it), so I'd prefer to have gitian make it, even if it isn't deterministic
280 2012-05-16 16:27:18 <devrandom> ok
281 2012-05-16 16:30:25 <luke-jr> so I guess I should add the patch files to git, and just add the big stuff as inputs?
282 2012-05-16 16:35:06 <devrandom> that sounds right
283 2012-05-16 16:44:00 <luke-jr> devrandom: possible to specify an exact remote commit?
284 2012-05-16 16:45:26 <luke-jr> in the yml
285 2012-05-16 16:51:14 <SupaDupaJenkins> I think Bitcoin P2Pool is crashing
286 2012-05-16 16:51:21 <SupaDupaJenkins> it's going down 1 GH/s every 3 seconds
287 2012-05-16 16:51:28 <SupaDupaJenkins> already down 55 GH/s ! :O
288 2012-05-16 16:54:03 <Eliel> SupaDupaJenkins: you'll most likely want #p2pool channel for that.
289 2012-05-16 16:54:25 <SupaDupaJenkins> ok thanks was wondering if anyone knew what the fuck is going on
290 2012-05-16 16:54:28 <SupaDupaJenkins> thanks Eliel :D
291 2012-05-16 16:58:03 <devrandom> luke-jr: yes.  In fact, that's the preferred way
292 2012-05-16 16:58:22 <luke-jr> devrandom: how? :p
293 2012-05-16 17:09:22 <devrandom> luke-jr: the remotes yml array takes url, dir and commit
294 2012-05-16 17:09:57 <devrandom> (existing bitcoin.yml doesn't specify a commit, since that's supplied on the commandline)
295 2012-05-16 18:06:19 <sipa> jgarzik: is it necessary to serialize addrman data twice?
296 2012-05-16 18:07:22 <sipa> you can calculate the hash of ssPeers after serializing addrman into it, and then add it at the end of it
297 2012-05-16 18:13:39 <jgarzik> sipa: it makes life a bit easier on read, when you can read and checksum, before hitting addr data.
298 2012-05-16 18:13:57 <jgarzik> sipa: could accomplish same with a bit of seeking around, I suppose
299 2012-05-16 18:14:33 <sipa> ok, write the checksum to the file, then ssPeer?
300 2012-05-16 18:14:46 <jgarzik> sipa: I just revised the recent upload a bit too, so make sure you're looking at commit 0be94ce
301 2012-05-16 18:14:50 <jgarzik> i.e. click reload
302 2012-05-16 18:15:01 <jgarzik> revised the revision, as it were
303 2012-05-16 18:15:34 <sipa> you're still serializing twice
304 2012-05-16 18:16:08 <jgarzik> sipa: yes, but double-buffering was eliminated
305 2012-05-16 18:16:18 <sipa> i noticed :)
306 2012-05-16 18:16:32 <sipa> but it still seems unnecessary (not that it matters much... but it's just silly)
307 2012-05-16 18:17:27 <sipa> you can send one CDataStream into another, using << i believe
308 2012-05-16 18:17:38 <jgarzik> sipa: <shrug> I can change it to fwrite
309 2012-05-16 18:17:38 <sipa> so just make the ssSeed non-local to the hashing block, and reuse it?
310 2012-05-16 18:17:40 <jgarzik> sipa: hmmm
311 2012-05-16 18:18:16 <sipa> well, the CAutoFile is no CDataStream, but it has the same interface
312 2012-05-16 18:18:52 <Matt_von_Mises> Can anyone tell me how much strings are used with bitcoin and do people think it's worth using reference counting for strings with making a bitcoin library?
313 2012-05-16 18:19:10 <sipa> Matt_von_Mises: i wouldn't bother
314 2012-05-16 18:19:33 <Matt_von_Mises> I was thinking this because I'm implementing the bitcoin addresses.
315 2012-05-16 18:19:56 <sipa> you're not doing conversion between binary and base58 format frequently
316 2012-05-16 18:20:09 <Matt_von_Mises> I'm caching the strings and theres a lot of copying going on and I wonder if making a new structure would be better.
317 2012-05-16 18:20:09 <sipa> internally, always use the binary representation
318 2012-05-16 18:20:26 <sipa> don't be tempted to think that because it's a lot of code to write, it's slow
319 2012-05-16 18:21:35 <jgarzik> sipa: double-serialization removed in additional #addrman commit
320 2012-05-16 18:22:09 <jgarzik> used CDataStream::write()
321 2012-05-16 18:22:35 <sipa> jgarzik: "fileout << ssAddr;" doesn't work?
322 2012-05-16 18:22:56 <Matt_von_Mises> Well if I use reference counting I can just retain a bitcoin address base-58 string when caching and make a new one when returning the string with caching disabled. I wouldn't need to copy any strings and it would be consistent with the model I'm using for other data structures.
323 2012-05-16 18:23:15 <sipa> Matt_von_Mises: i think you're optimizing prematurely
324 2012-05-16 18:23:23 <luke-jr> Matt_von_Mises: This is cbitcoin?
325 2012-05-16 18:23:26 <Matt_von_Mises> I'm not thinking of optimisation
326 2012-05-16 18:23:38 <Matt_von_Mises> This would actually make the library easier I think
327 2012-05-16 18:23:43 <Matt_von_Mises> Easier to use
328 2012-05-16 18:23:44 <sipa> then go for it
329 2012-05-16 18:23:57 <jgarzik> sipa: "fileout << ssAddr;" seems to compile, at any rate :)
330 2012-05-16 18:24:01 <Matt_von_Mises> And I need to decide early on since it would be a pain to change
331 2012-05-16 18:24:14 <Matt_von_Mises> sipa: Yes I think I will. :-)
332 2012-05-16 18:24:16 <luke-jr> Matt_von_Mises: more imporantly, what does your code do when it encounters an "address" that cannot be serialized as a string?
333 2012-05-16 18:24:18 <sipa> jgarzik: it's exactly the same thing, i believe (just concatenation)
334 2012-05-16 18:25:19 <jgarzik> sipa: pushed that change out
335 2012-05-16 18:25:21 <Matt_von_Mises> luke-jr: What do you mean?
336 2012-05-16 18:25:50 <luke-jr> Matt_von_Mises: really, you should probably be dealing with struct { unsigned int refcount; unsigned size_t size; char*scriptData; }
337 2012-05-16 18:26:03 <luke-jr> Matt_von_Mises: I mean, not every destination can be represented as a string-address
338 2012-05-16 18:26:15 <luke-jr> Matt_von_Mises: for example, there is no standard for send-to-password
339 2012-05-16 18:26:35 <luke-jr> s/scriptData/scriptPubKey/
340 2012-05-16 18:26:46 <Matt_von_Mises> I'm not getting to the script yet
341 2012-05-16 18:26:59 <luke-jr> my point is that you should only be dealing with the script :p
342 2012-05-16 18:27:21 <sipa> addresses are indeed only something that ends up on top of a lot of machinery below
343 2012-05-16 18:27:23 <luke-jr> two functions, address-to-script and script-to-address, make sense for dealing with addresses
344 2012-05-16 18:27:25 <Matt_von_Mises> I shouldn't have a structure for dealing with bitcoin addresses?
345 2012-05-16 18:27:31 <sipa> sure you do
346 2012-05-16 18:27:34 <luke-jr> Matt_von_Mises: nope, just those 2 functions
347 2012-05-16 18:27:51 <luke-jr> addresses are strictly a user-side thing, for the most part
348 2012-05-16 18:27:51 <sipa> luke-jr: i think that's an oversimplification
349 2012-05-16 18:27:57 <sipa> it may be possible
350 2012-05-16 18:27:59 <wumpus> the fun of implementing something in c, you end up writing half a python/lisp interpreter :-)
351 2012-05-16 18:28:01 <luke-jr> sipa: what else needs to work with an address?
352 2012-05-16 18:28:12 <luke-jr> wumpus: depends on that something :p
353 2012-05-16 18:28:24 <luke-jr> to implement Bitcoin, you DO need to write an interpreter
354 2012-05-16 18:28:30 <luke-jr> in any language really
355 2012-05-16 18:29:08 <Matt_von_Mises> Though addresses are used in the standard implementation and common for bitcoin so I see no reason why not to provide a structure for them.
356 2012-05-16 18:29:29 <sipa> Matt_von_Mises: there is no reason not to, but they may be used less than you imagine now
357 2012-05-16 18:29:59 <sipa> jgarzik: fails to read written peers.dat data now
358 2012-05-16 18:30:00 <luke-jr> Matt_von_Mises: the only purpose of addresses are to display scriptPubKey to humans, and accept human input of them
359 2012-05-16 18:30:05 <wumpus> luke-jr: it seems to apply for every large-ish project
360 2012-05-16 18:30:56 <luke-jr> too bad C11 didn't add more on the standard library front
361 2012-05-16 18:31:08 <wumpus> inner platform syndrome, or something like that, you worry about all the low-level details of implementing a language instead of what you're trying to write
362 2012-05-16 18:31:11 <luke-jr> standard hash tables, refcounted data, etc would be nice
363 2012-05-16 18:31:13 <Matt_von_Mises> Well I'm implementing it. At the very least bitcoinj implements it.
364 2012-05-16 18:31:17 <wumpus> yep
365 2012-05-16 18:31:38 <sipa> mimicking bitcoinj is probably not a bad idea
366 2012-05-16 18:31:55 <Matt_von_Mises> luke-jr: C11 wont be implemented for a while I reckon.
367 2012-05-16 18:32:18 <sipa> most compilers already implement a large portion of it, i understond, but i don't know too many details
368 2012-05-16 18:32:21 <Matt_von_Mises> Google C11, I don't think anyone even cares
369 2012-05-16 18:32:54 <Matt_von_Mises> Hmmm. I don't think even GCC actually implements C99 100% properly yet.
370 2012-05-16 18:33:06 <luke-jr> Matt_von_Mises: I use C11 with GCC all the time
371 2012-05-16 18:33:09 <sipa> C++11 is the thing to google for
372 2012-05-16 18:33:10 <TD> C++11 is pretty well implemented
373 2012-05-16 18:33:17 <TD> the spec evolved in parallel with the compilers
374 2012-05-16 18:33:20 <TD> we're using some of it at work already
375 2012-05-16 18:33:46 <Matt_von_Mises> luke-jr: Really? So it implements the threads and everything?
376 2012-05-16 18:33:50 <luke-jr> in fact, I wonder how much of the boost deps go away if we update
377 2012-05-16 18:33:58 <luke-jr> Matt_von_Mises: doubt it ;)
378 2012-05-16 18:35:47 <sipa> even just rvalue references in c++11 fix an important problem with C++
379 2012-05-16 18:41:35 <jgarzik> sipa: error message?
380 2012-05-16 18:42:28 <sipa> EXCEPTION: NSt8ios_base7failureE
381 2012-05-16 18:42:29 <sipa> bitcoin in AppInit()
382 2012-05-16 18:42:30 <gribble> New news from bitcoinrss: sgornick opened issue 1325 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1325>
383 2012-05-16 18:42:33 <sipa> terminate called after throwing an instance of 'std::ios_base::failure' what():  CDataStream::read() : end of data
384 2012-05-16 18:44:40 <jgarzik> sipa: hrm.  I wonder if CDataStream adds some sort of stream header, that makes "a = ser(A); str = a << B << C" != "str = A << B << C"
385 2012-05-16 18:45:15 <jgarzik> c = ser(C); str = A << B << c          vs        str = A << B << C
386 2012-05-16 18:45:35 <sipa> it should
387 2012-05-16 18:49:00 <jgarzik> sipa: OK, pushed out fix for the minor, immediate issue (not catching de-ser errors)
388 2012-05-16 18:49:24 <jgarzik> sipa: at least it will crash with a proper error message now :)
389 2012-05-16 18:50:22 <sipa> let's try
390 2012-05-16 18:51:32 <sipa> ERROR: CAddrman::Read() : I/O error or stream data corrupted
391 2012-05-16 18:53:12 <sipa> you don't have that problem?
392 2012-05-16 18:53:20 <jgarzik> sipa: related question...  is it safe to memcmp(unsigned char *, &uint256) ?
393 2012-05-16 18:53:30 <sipa> i think so
394 2012-05-16 18:54:28 <jgarzik> sipa: gonna try a few things, back in a bit
395 2012-05-16 18:59:45 <jgarzik> sipa: is the serialization of uint256 fixed size or variable size?
396 2012-05-16 19:11:48 <sipa> jgarzik: fixed, 32 bytes (it's used in block headers and tx prevouts)
397 2012-05-16 20:49:13 <luke-jr> wumpus: did you fix transifex first? :p
398 2012-05-16 20:49:27 <wumpus> what?
399 2012-05-16 20:49:46 <luke-jr> wumpus: it's putting &amp; everywhere apparently
400 2012-05-16 20:49:54 <luke-jr> rather than &
401 2012-05-16 20:49:55 <wumpus> is it?
402 2012-05-16 20:50:05 <wumpus> I've only seen it in one case
403 2012-05-16 20:50:13 <luke-jr> [00:03:46] <tosku> gavinandresen: From what I can see online, there's ampersands where there are supposed to be ampersands. "&Overview" is translated to "&??versikt" and "&Transactions" is translated to "&Transaktioner". On my computer, the Overview button is displayed as "amp& ??versikt", but the Transaction button is displayed correctly. It seems the problem is not with the translation itself.
404 2012-05-16 20:50:15 <luke-jr> [00:04:20] <sipa> wumpus: ^ any idea?
405 2012-05-16 20:50:31 <wumpus> yes, that's in the finnish translation
406 2012-05-16 20:50:36 <wumpus> afaik that's been fixed a long time ago
407 2012-05-16 20:50:50 <wumpus> we really need a re-import from transifex
408 2012-05-16 20:50:52 <luke-jr> [23:51:43] <tosku> I updated to 0.6.2 for Windows.
409 2012-05-16 20:50:53 <luke-jr> [23:51:58] <tosku> There seems to be something wrong with the Swedish translation.
410 2012-05-16 20:51:07 <wumpus> oh, swedish
411 2012-05-16 20:51:55 <wumpus> the problem appeared as &amp;amp; in the xml, not &amp; which is a valid entity
412 2012-05-16 20:53:05 <luke-jr> what 2-char is swedish?
413 2012-05-16 20:54:26 <wumpus> &amp;amp;s are in the _fa, _pt_BR and _sv translations currently in git
414 2012-05-16 20:54:30 <luke-jr> 9d4b05c0 (Nils Schneider  2012-02-05 13:28:39 +0100   62)         <translation>&amp;amp; Kopiera till Urklipp</translation>
415 2012-05-16 20:54:39 <wumpus> I'd guess _sv is swedish
416 2012-05-16 20:55:03 <luke-jr> came from transifex it seems
417 2012-05-16 20:55:10 <wumpus> yes it was wrong in transifex
418 2012-05-16 20:56:00 <luke-jr> so it was fixed already since then, but just not updated in git?
419 2012-05-16 20:56:05 <wumpus> afaik, yes
420 2012-05-16 20:56:09 <luke-jr> i c
421 2012-05-16 20:56:16 <wumpus> the last pull from transifex has been a long time ago
422 2012-05-16 20:57:01 <wumpus> at least for existing languages, the one I just merged adds a few
423 2012-05-16 20:58:25 <wumpus> hmm also some translations have & followed by a space... that kind of defeats the purpose
424 2012-05-16 20:58:26 <luke-jr> would be nice to have a git hook automatically upload ts files to transifex, and get more strict on merging updates in before releases&
425 2012-05-16 20:58:31 <luke-jr> lol
426 2012-05-16 20:59:55 <wumpus> nah, we never upload ts files to transifex (except for the english one)
427 2012-05-16 21:00:37 <wumpus> the other ts files only come from transifex
428 2012-05-16 21:00:55 <luke-jr> I meant the English one :p
429 2012-05-16 21:01:04 <wumpus> nah, the english one is fine
430 2012-05-16 21:01:19 <wumpus> we update it regularly.. the other ones on the other hand :-)
431 2012-05-16 21:02:15 <wumpus> afaik transifex automatically pulls the master file every day
432 2012-05-16 21:03:38 <wumpus> it really works very well... but it can't protect against translators making strange mistakes once in a while :p
433 2012-05-16 21:14:31 <jgarzik> and suddenly
434 2012-05-16 21:14:41 <jgarzik> changing vchData.reserve() to vchData.resize() makes everything work
435 2012-05-16 21:14:49 <jgarzik> the perils of direct pointer accesses
436 2012-05-16 21:15:40 <luke-jr> O.o
437 2012-05-16 21:32:58 <jgarzik> sipa: ok, #addrman ready for testing again
438 2012-05-16 21:33:37 <Matt_von_Mises> So close to getting addresses to work. The checksum wont work for some reason. :(
439 2012-05-16 21:36:00 <Matt_von_Mises> Silly me. Generating a checksum for the RIPEMD160 hash but not including the network byte.
440 2012-05-16 21:41:04 <Matt_von_Mises> Yay! Addresses work.
441 2012-05-16 21:56:21 <luke-jr> 53 MB bin-osx-cross-4.0.1.tbz2 1fed2b1fb0bed372e8eca1dd8778a5a5aebf6e1344f0dbc5bb2bcf73d51994c8
442 2012-05-16 22:17:34 <Matt_von_Mises> So I'm looking at the script interpreter. Basically the input script is run and then the output script is run with the stack leftover from the input script. The input script basically gives parameters to the output script to verify.
443 2012-05-16 22:18:01 <Matt_von_Mises> Seems pretty simple to me.
444 2012-05-16 22:21:14 <phantomcircuit> now implement
445 2012-05-16 22:22:30 <Matt_von_Mises> THe only problem with the implementation is there are loads of the instructions.
446 2012-05-16 22:22:51 <luke-jr> Matt_von_Mises: many are disabled, so you can skip them
447 2012-05-16 22:23:13 <luke-jr> (enabling them requires a hardfork, which is likely to include a lot of other changes too, so no point doing it now)
448 2012-05-16 22:23:26 <Matt_von_Mises> Does the wiki page give correct information on which ones are disabled? https://en.bitcoin.it/wiki/Script
449 2012-05-16 22:23:32 <luke-jr> I'd double-check it
450 2012-05-16 22:23:35 <luke-jr> and if it's wrong, correct it
451 2012-05-16 22:23:55 <Matt_von_Mises> OK.
452 2012-05-16 22:31:16 <Matt_von_Mises> Looks like all these ones are disabled? https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L267
453 2012-05-16 22:34:03 <Matt_von_Mises> Wiki is fine.
454 2012-05-16 22:41:48 <Matt_von_Mises> My goodness. Looking at all these codes I see I'm up for a daunting task.
455 2012-05-16 22:43:24 <Matt_von_Mises> At least some of them do similar things.
456 2012-05-16 22:57:21 <jine> Gosh, In a minute this block hits 1 hour. The entire network is unlucky? :D
457 2012-05-16 22:57:28 <jine> I need confirmations goddamit :D
458 2012-05-16 22:57:51 <Graet> lol
459 2012-05-16 22:58:18 <Graet> doin my best to confirm it for you jine :P
460 2012-05-16 22:58:41 <jine> So do I.
461 2012-05-16 22:58:48 <Graet> hehe :D
462 2012-05-16 22:59:29 <gribble> Time since last block: 1 hour, 1 minute, and 18 seconds
463 2012-05-16 22:59:29 <nanotube> ;;bc,tslb
464 2012-05-16 23:00:05 <jine> nanotube: Did you see my previous post in -otc regarding GPG-register with gribble?
465 2012-05-16 23:01:38 <nanotube> jine: hmmm maybe. :) remind me again what was up?
466 2012-05-16 23:02:07 <nanotube> ah, problem creating encrypted otp
467 2012-05-16 23:02:42 <jine> Exacly.
468 2012-05-16 23:02:47 <nanotube> would you please try eauth again (let's go to -foyer or #gribble), and i'll check log to see whatsup
469 2012-05-16 23:03:17 <jine> Well I'm authed, i just wanted to create a new gpg-identity for Bitlc.net
470 2012-05-16 23:03:27 <gribble> You are identified as user jine, with GPG key id 5500CE1E2AC9B78F, and key fingerprint 03482206C0D71A94A0E303C25500CE1E2AC9B78F.
471 2012-05-16 23:03:27 <jine> ;;ident
472 2012-05-16 23:03:29 <nanotube> ah... so you were trying eregister?
473 2012-05-16 23:03:30 <luke-jr> How is bitcoind distributed for Mac? or is it not?
474 2012-05-16 23:03:33 <jine> nanotube: Exactly
475 2012-05-16 23:03:34 <nanotube> for a new user and key?
476 2012-05-16 23:03:36 <jine> Yes.
477 2012-05-16 23:03:37 <TD> has anyone used bit-pay before?
478 2012-05-16 23:03:39 <nanotube> hmm, what key jine
479 2012-05-16 23:03:41 <luke-jr> or better question: how *should* bitcoind be distributed for Mac?
480 2012-05-16 23:03:53 <nanotube> TD: i've used it once to pay for something. it worked. :)
481 2012-05-16 23:04:04 <TD> nanotube: is the page supposed to reload or notice once the tx is broadcast?
482 2012-05-16 23:04:12 <TD> i paid to the given address and the web page is surprisingly ..... static
483 2012-05-16 23:04:16 <jine> nanotube: BDDC7A4E296D8BB1
484 2012-05-16 23:04:16 <TD> but it doesn't actually say it'll do anything
485 2012-05-16 23:04:36 <nanotube> TD: hmm i don't recall.
486 2012-05-16 23:04:40 <TD> ok
487 2012-05-16 23:04:48 <TD> it's got a countdown
488 2012-05-16 23:04:57 <nanotube> jine: ah, no encryption subkey on that key.
489 2012-05-16 23:05:38 <jine> Ah, is it a requirement? I thought it encrypted with my pub-key
490 2012-05-16 23:06:02 <jine> Lets create one then.
491 2012-05-16 23:06:13 <TD> ah ha
492 2012-05-16 23:06:16 <TD> yes it does do something
493 2012-05-16 23:06:25 <nanotube> jine: the standard setup is a master signing key, and an encryption subkey.
494 2012-05-16 23:06:25 <TD> it's just slow to notice new transactions. either that or  tx propagation time has gone up a lot
495 2012-05-16 23:06:44 <jine> nanotube: Yeah, i know. I just didn't thought it required the subkey :)
496 2012-05-16 23:06:47 <TD> i think the current code doesn't build on OS X
497 2012-05-16 23:07:06 <nanotube> (though it's possible to go into guru-mode and make the master key both sign and encrypt, there is iirc a crafted plaintext attack on that)
498 2012-05-16 23:07:08 <TD> where is build.h supposed to come from ?
499 2012-05-16 23:07:51 <luke-jr> TD: err, we have OS X releases for Bitcoin-Qt at least
500 2012-05-16 23:08:01 <TD> Sleep() is not defined
501 2012-05-16 23:08:03 <TD> in sync.cpp
502 2012-05-16 23:08:18 <luke-jr> oh that
503 2012-05-16 23:08:23 <luke-jr> yeah, I reported that earlier
504 2012-05-16 23:08:34 <luke-jr> [17:17:35] <luke-jr> sync.h is missing an include util.h (for Sleep)
505 2012-05-16 23:09:00 <jine> nanotube: Generatin''.. :)
506 2012-05-16 23:09:10 <nanotube> jine: ok :)
507 2012-05-16 23:10:22 <TD> the build.h thing is also an issue
508 2012-05-16 23:10:40 <TD> it's supposed to be produced by the build system. i ran qmake and then used xcode
509 2012-05-16 23:10:45 <TD> perhaps that procedure is out of date
510 2012-05-16 23:11:09 <luke-jr> TD: well, I'm going to be cross-compiling on Ubuntu anyway
511 2012-05-16 23:11:19 <luke-jr> the question I have is, do we put bitcoind inside the .app or what?
512 2012-05-16 23:11:33 <TD> hmm
513 2012-05-16 23:11:53 <TD> daemons might make more sense as a macport or something
514 2012-05-16 23:12:07 <TD> not sure if a gui-less daemon really fits on OS X. ideally there'd be a pref pane or something for it
515 2012-05-16 23:12:11 <TD> but then why not just run the gui app
516 2012-05-16 23:14:51 <Karmaon> who hosts the forum
517 2012-05-16 23:14:54 <Karmaon> bitcointalk
518 2012-05-16 23:15:17 <TD> magicaltux does i think
519 2012-05-16 23:16:10 <luke-jr> I don't see bitcoind in the current Mac builds, so I guess I can omit it
520 2012-05-16 23:16:25 <luke-jr> Karmaon: theymos runs it, with hosting from MagicalTux
521 2012-05-16 23:17:55 <jine> ;;eregister Bitlc.net BDDC7A4E296D8BB1
522 2012-05-16 23:17:56 <Karmaon> thanks
523 2012-05-16 23:17:59 <gribble> Request successful for user Bitlc.net, hostmask jine!jine@jine.be. Get your encrypted OTP from http://bitcoin-otc.com/otps/BDDC7A4E296D8BB1
524 2012-05-16 23:18:06 <jine> Tyvm gribble
525 2012-05-16 23:18:27 <jine> (and nanotube!)
526 2012-05-16 23:18:42 <jine> ;;rate nanotube 10
527 2012-05-16 23:18:43 <gribble> Rating entry successful. Your rating for user nanotube has changed from 8 to 10.
528 2012-05-16 23:18:53 <gribble> Error: "rating" is not a valid command.
529 2012-05-16 23:18:53 <jine> ;;rating nanotube
530 2012-05-16 23:18:59 <gribble> (rate <nick> <rating> [<notes>]) -- Enters a rating for <nick> in the amount of <rating>. Use optional <notes> field to enter any notes you have about this user. <nick> must be the user's GPG-registered username, Your previously existing rating, if any, will be overwritten.
531 2012-05-16 23:18:59 <jine> ;;rate nanotube
532 2012-05-16 23:19:05 <jine> Whatever
533 2012-05-16 23:19:56 <gribble> Error: For identification purposes, you must be identified via GPG to use the rating system.
534 2012-05-16 23:19:56 <Karmaon> ;;rate gribble 999
535 2012-05-16 23:20:01 <Graet> ;;getrating nanotube
536 2012-05-16 23:20:03 <gribble> User nanotube, created on Mon Nov  8 10:14:09 2010. Cumulative rating 531, from 157 total ratings. Received ratings: 157 positive, 0 negative. Sent ratings: 159 positive, 2 negative. Details: http://bitcoin-otc.com/viewratingdetail.php?nick=nanotube  Currently authenticated from hostmask nanotube!~nanotube@unaffiliated/nanotube
537 2012-05-16 23:20:12 <luke-jr> is there a reason you guys are doing #bitcoin-otc games in #bitcoin-dev ?
538 2012-05-16 23:20:30 <jine> luke-jr: No, i started it, and I'm sorry :)
539 2012-05-16 23:20:52 <luke-jr> np, was just curious
540 2012-05-16 23:22:17 <luke-jr> devrandom: you should just put faketime in the original image imo :p
541 2012-05-16 23:23:52 <TD> qtipcserver also doesn't compile
542 2012-05-16 23:23:57 <Diablo-D3> I have to admit I like the new sync bar
543 2012-05-16 23:27:40 <Karmaon> is magicaltux in japan?
544 2012-05-16 23:28:31 <Diablo-D3> yes
545 2012-05-16 23:29:06 <luke-jr> Karmaon: he's searching for Satoshi
546 2012-05-16 23:29:08 <luke-jr> :p
547 2012-05-16 23:30:12 <Karmaon> he is satoshi
548 2012-05-16 23:31:55 <MagicalTux> ssssshh
549 2012-05-16 23:32:04 <luke-jr> o.o he's alive
550 2012-05-16 23:32:12 <luke-jr> MagicalTux: how's QBitcoin coming along? anything public yet? :p
551 2012-05-16 23:32:28 <Karmaon> MagicalTux: i sent you a pm
552 2012-05-16 23:32:28 <luke-jr> the wiki still sez 2011 for first release <.<
553 2012-05-16 23:32:33 <MagicalTux> luke-jr: I'll be able to resume work after june
554 2012-05-16 23:32:38 <luke-jr> MagicalTux: neat
555 2012-05-16 23:32:55 <TuxBlackEdo> MagicalTux, when will mtgox have a namecoin exchnage?
556 2012-05-16 23:33:04 <luke-jr> MagicalTux: is MtGox using QBC Core, or something completely independent?
557 2012-05-16 23:33:18 <luke-jr> TuxBlackEdo: LOLOL
558 2012-05-16 23:34:09 <MagicalTux> luke-jr: ported QBC core in PHP
559 2012-05-16 23:35:08 <luke-jr> O.O
560 2012-05-16 23:35:48 <luke-jr> doesn't that leak like crazy?
561 2012-05-16 23:35:49 <MagicalTux> :D
562 2012-05-16 23:35:53 <MagicalTux> doesn't leak at all
563 2012-05-16 23:35:55 <MagicalTux> and works multithread
564 2012-05-16 23:36:04 <luke-jr> didn't know PHP even supported threading
565 2012-05-16 23:36:04 <MagicalTux> it's not a long term bitcoin client
566 2012-05-16 23:37:03 <jgarzik> receiving is easy...  you have a list of public keys, and you watch blocks for TXs with those public keys
567 2012-05-16 23:37:16 <luke-jr> jgarzik: watching blocks requires long-term client?
568 2012-05-16 23:37:35 <luke-jr> (by "long-term" I mean not "run for the request duration then exit")
569 2012-05-16 23:39:57 <devrandom> luke-jr: agreed
570 2012-05-16 23:40:49 <nanotube> jine: :)
571 2012-05-16 23:41:13 <Matt_von_Mises> I looked on the wiki for QBitcoin and it says "this version is planned for mid-january 2011"
572 2012-05-16 23:41:58 <TuxBlackEdo> classic goxxing
573 2012-05-16 23:45:39 <luke-jr> 3.3 MB 08efab4511a415c0c0d7379bbe90a8cda207c03b801c1cb97158240858468f30 bin-osx-bdb-4.8.30.tbz2
574 2012-05-16 23:59:38 <luke-jr> 37 KB 009494e944a5ed54ca611e9eff6361e0d3e85411d9013d9558514dd8011b2fd0 bin-osx-miniupnpc-1.6.tbz2