1 2012-07-22 00:38:01 <lianj> cheako: exact or average :P
  2 2012-07-22 02:19:30 <copumpkin> blk***.dat are append-only, right?
  3 2012-07-22 02:19:56 <gmaxwell> yes.
  4 2012-07-22 02:30:28 <MC1984> will a heavily fragmented blockchain shit thing up quite a lot
  5 2012-07-22 02:32:32 <copumpkin> fragmented?
  6 2012-07-22 02:33:16 <MC1984> file fragmentation
  7 2012-07-22 02:33:55 <gmaxwell> MC1984: the accesses are random in any case, so it really shouldn't matter a ton. Fragmented index files are probably worse, but harder to avoid.
  8 2012-07-22 02:34:50 <MC1984> oh well ill defrag anyway
  9 2012-07-22 02:37:34 <jgarzik> amusingly, gdbm as a blockchain db is standing up to more punishment than BDB, when used via python's dbm enginery
 10 2012-07-22 02:38:18 <jgarzik> gdbm survives Ctrl-C, bsddb does not.  Probably have to turn on autocommit or somesuch.  It is just amusing that poor old gdbm skunks bdb out of the box here.
 11 2012-07-22 02:43:28 <MC1984> hmm could you make the installer detect where youve already got bitcoin installed if not in the default location, for upgrade installs
 12 2012-07-22 02:43:53 <MC1984> this would make it easier for me to mash Next until it goes away thanks
 13 2012-07-22 02:54:35 <jgarzik> WARNING: overwriting duplicate TX d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599, height 91841, oldblk 00000000000af0aed4792b1acee3d966af36cf5def14935db8de83d6f9306f2f, oldspent 0, newblk 00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec
 14 2012-07-22 02:55:00 <copumpkin> another one?
 15 2012-07-22 02:55:13 <jgarzik> #91841 and #91879, old blocks
 16 2012-07-22 02:55:28 <copumpkin> oh wait
 17 2012-07-22 02:55:34 <copumpkin> that's the same one we were looking at before
 18 2012-07-22 02:55:36 <copumpkin> [20:08:35] <jgarzik> d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599
 19 2012-07-22 02:55:43 <copumpkin> except off-by-oone?
 20 2012-07-22 02:56:36 <jgarzik> mine is technically height-1, because it has not yet processed the block in question
 21 2012-07-22 02:56:39 <jgarzik> so yes
 22 2012-07-22 02:56:58 <copumpkin> ah, okay
 23 2012-07-22 03:14:55 <midnightmagic> fragmentation does make an enormous different in (for example) Windows files, btw; even a normal seek in one of those files can be measurably slower.
 24 2012-07-22 03:15:26 <midnightmagic> and, since we grow the blk* files in small pieces at a time, we are going to see this.
 25 2012-07-22 03:15:47 <midnightmagic> "fragmentation" doesn't make nearly so much of a diff. on unix-like machinery.
 26 2012-07-22 03:16:59 <copumpkin> just preallocate all 2 gigs of the blk* file :)
 27 2012-07-22 03:17:04 <copumpkin> you know it's gonna grow that big
 28 2012-07-22 03:18:08 <copumpkin> O(1) extra space and space is cheap ;)
 29 2012-07-22 03:18:53 <midnightmagic> that requires basically a seek to specify to the OS that you're going to build a file that large. you can avoid the huge chunk-at-a-time overhead by pre-allocating in smaller chunks. depending on db access patterns, return on larger-and-larger preallocation shrinks quickly
 30 2012-07-22 03:19:14 <midnightmagic> "return" I guess better said as "savings"
 31 2012-07-22 03:19:29 <midnightmagic> time savings? whatever you want to cal lit.
 32 2012-07-22 03:19:38 <midnightmagic> aaaand my namecoin wallet is corrupt.
 33 2012-07-22 03:20:04 <MC1984> lolwindows
 34 2012-07-22 03:20:20 <MC1984> welp time for contig.exe
 35 2012-07-22 03:20:40 <midnightmagic> MC1984: was that your question? on a windows machine? you didn't specify.
 36 2012-07-22 03:20:58 <MC1984> yes
 37 2012-07-22 03:21:06 <midnightmagic> ok
 38 2012-07-22 03:22:40 <MC1984> are there any good java mobile QR readers
 39 2012-07-22 04:01:20 <jgarzik> scan complete
 40 2012-07-22 04:01:28 <jgarzik> just those two dups in the mainnet chain
 41 2012-07-22 04:02:45 <MC1984> what
 42 2012-07-22 04:17:25 <copumpkin> duplicate transaction IDs
 43 2012-07-22 04:17:40 <copumpkin> jgarzik: is that the issue roconnor brought up a few months ago?
 44 2012-07-22 04:23:35 <copumpkin> is bitcoin using the hash storage method in bdb or the btree one?
 45 2012-07-22 05:44:37 <Keefe> is there any tool for determining the balance of an arbitrary address, or more particularly the balances of an arbitrary list of addresses, completely offline using just an up to date blk* file set?
 46 2012-07-22 05:45:23 <Keefe> i saw some forum threads and i think a stackexchange post about this, but without conclusion
 47 2012-07-22 05:47:24 <Varan> There is this: https://bitcointalk.org/index.php?topic=88584.0
 48 2012-07-22 05:47:49 <Varan> but it doesn't really do what you want i think... but could maybe be modified to do this
 49 2012-07-22 05:50:43 <weex> Keefe: when you say using just, is loading into mysql ok? I think something called Abe might do that.
 50 2012-07-22 05:54:48 <Keefe> "Compute and print the balance for all keys ever used since the beginning of time (30 seconds)"
 51 2012-07-22 05:54:51 <Keefe> nice!
 52 2012-07-22 05:55:29 <Keefe> sounds useful for my need
 53 2012-07-22 05:55:32 <Keefe> thanks Varan
 54 2012-07-22 05:56:19 <Keefe> weex: i suppose that could work as well. i don't mind starting with making a list of all keys, then filtering by my own list
 55 2012-07-22 06:25:51 <Varan> Keefe: np
 56 2012-07-22 13:16:06 <cheako> lianj: Instead of asking, why not answer.  It sounds like you have two answers, on that's exact and another that's an average.  You could have simply said exact block ID is X, but the average block ID is X sub l to X sub h.
 57 2012-07-22 13:19:45 <cheako> midnightmagic: There is NOW a call for linux at least to allocate a hole, thus avoiding the whole seek to end and write out a byte.
 58 2012-07-22 13:22:51 <cheako> http://lwn.net/Articles/226710/
 59 2012-07-22 13:30:51 <cheako> Don't ask to answer, just answer for each output of your question...  Especially if the number of outputs is under 5 or so.
 60 2012-07-22 14:33:01 <cheako> How can I get onto or into the DNS based on bitcoin?  Is there such a thing?
 61 2012-07-22 14:34:05 <chmod755> cheako: do you mean namecoin?
 62 2012-07-22 14:34:10 <Joric> cheako, go here http://dot-bit.org
 63 2012-07-22 14:44:39 <jgarzik> copumpkin: yes
 64 2012-07-22 15:01:39 <jgarzik> Here's pynode: https://github.com/jgarzik/pynode
 65 2012-07-22 15:01:52 <jgarzik> it does initial block download, and maintains a memory pool and block db.
 66 2012-07-22 15:02:06 <jgarzik> it does NOT verify scripts, nor handle reorg
 67 2012-07-22 15:03:38 <luke-jr> does it keep orphan txns out of the memory pool until their parents are confirmed?
 68 2012-07-22 15:04:20 <luke-jr> blah, Python 2
 69 2012-07-22 15:09:40 <copumpkin> lol
 70 2012-07-22 15:13:21 <jgarzik> luke-jr: not smart enough to figure out orphans yet
 71 2012-07-22 15:13:59 <jgarzik> luke-jr: all transactions received from bitcoind are put into the memory pool.  blocks are the only thing that remove txs from the memory pool.
 72 2012-07-22 15:14:33 <jgarzik> The next step is to verify valid mempool inputs
 73 2012-07-22 15:14:48 <jgarzik> Once connectedness is verified, you can make a getmemorypool or getwork
 74 2012-07-22 15:24:11 <jgarzik> pynode thread: https://bitcointalk.org/index.php?topic=94645.0
 75 2012-07-22 15:27:58 <jgarzik> MemPool: blk.vtx.sz 111, neverseen 1, poolsz 76
 76 2012-07-22 15:27:58 <jgarzik> MemPool: blk.vtx.sz 470, neverseen 1, poolsz 71
 77 2012-07-22 15:28:21 <jgarzik> pynode notices when pools inject TX's that have never been broadcast to the network ('neverseen')
 78 2012-07-22 15:33:49 <TD> jgarzik: what's the goal of this work?
 79 2012-07-22 15:35:31 <jrmithdobbs> sounds like an attempt to get better auditing logs, i'd guess probably using libevent/etc too for io because jgarzik ;p,  out of an easier to modify/maintain "lite" (in functionality, not as in headers only) implementation
 80 2012-07-22 15:36:56 <jrmithdobbs> and having python libraries that actually parses all that stuff is useful in general for one-off analyzation and stuff, basically: same reasons phantom started down the road of a python client
 81 2012-07-22 15:37:23 <jrmithdobbs> or: why not?
 82 2012-07-22 16:10:38 <luke-jr> -rw-r--r-- 19 luke-jr luke-jr 2097361271 Jul 21 14:48 /home/luke-jr/.bitcoin/blk0001.dat
 83 2012-07-22 16:10:42 <luke-jr> wee, 19 hardlinks :p
 84 2012-07-22 16:12:39 <luke-jr> hmm, that should've freed 36 GB, but only 32 GB avail total :/
 85 2012-07-22 16:12:44 <copumpkin> lol
 86 2012-07-22 17:14:00 <jgarzik> TD[gone]: jrmithdobbs pretty much got it
 87 2012-07-22 17:14:33 <jgarzik> TD[gone]: no big goal, just wanted a python node for various chores -- statistics, auditing, implementation comparison, etc.
 88 2012-07-22 17:14:45 <jgarzik> pynode is intended to be a fully capable "full node"
 89 2012-07-22 17:17:32 <jgarzik> I'm also interested in exploring whether or not it will work for miners -- sans wallet
 90 2012-07-22 17:17:45 <jgarzik> i.e. point the coinbase to a list of addresses, so that a wallet need not be held
 91 2012-07-22 17:28:23 <jgarzik> running a wallet actually interests me the least
 92 2012-07-22 17:28:36 <jgarzik> so maybe it is closer to "bitcoin router" side of things
 93 2012-07-22 17:29:49 <cheako> Does any one know about merged mining?  Does that take twice the CPU/GPU/ect power per nonce?
 94 2012-07-22 17:30:10 <luke-jr> cheako: it does not
 95 2012-07-22 17:30:27 <cheako> Where can I find information on how that works?
 96 2012-07-22 17:30:30 <luke-jr> cheako: it basically amounts to OtherChain accepting a valid Bitcoin proof-of-work
 97 2012-07-22 17:32:23 <cheako> Ohh.  Wouldn't that mean there is data(at the vary least a hash or signature) for the other chain leaking into both?
 98 2012-07-22 17:33:30 <cheako> When I was looking at it, I was basically thinking a miner would work on a block that contained bitcoin and namecoin transactions.
 99 2012-07-22 17:34:32 <cheako> Sooner or later the block could be added to either chain as a proper solution, but now you say that the block would then be valid for both chains.
100 2012-07-22 17:36:31 <luke-jr> cheako: yes, the other chain needs the bitcoin block header and coinbase transaction
101 2012-07-22 17:36:57 <luke-jr> p2pool abuses a 0-amount output instead of the coinbase scriptSig, to be "the last N<64 bytes of the coinbase txn"
102 2012-07-22 17:38:17 <cheako> Can you point me at a block that was merged mined?
103 2012-07-22 17:39:40 <luke-jr> http://explorer.dot-bit.org/b/730e26f48ff3b0f2821a9c1692bd568f982e12a51fb2cded357acf62682935c1
104 2012-07-22 17:40:54 <luke-jr> note that Bitcoin does NOT currently support merged mining, so you won't find any on the Bitcoin blockchain
105 2012-07-22 17:41:20 <luke-jr> (which means almost all merged-mined blocks have Bitcoin as the parent chain)
106 2012-07-22 17:44:46 <cheako> I don't get how that could work.  How can a double round of sha256 be done once on two different blocks?
107 2012-07-22 17:45:41 <cheako> It sounds like you either work on a bitcoin block or you work on a bitcoin block that has namecoin data init that can be used on the namecoin chain.
108 2012-07-22 17:45:53 <cheako> in it
109 2012-07-22 17:52:06 <luke-jr> cheako: you work on a bitcoin block
110 2012-07-22 17:52:11 <amiller> cheako, you only work on one block, but it contains additional data, to the bitcoin chain it appears as (bitcoindata, junk) and to nmc chain it appears as (junk, namecoindata)
111 2012-07-22 17:52:24 <luke-jr> the bitcoin block's first transaction, the coinbase, can contain arbitrary data in scriptSig
112 2012-07-22 17:52:32 <luke-jr> put plug the namecoin block header hash in there
113 2012-07-22 17:52:51 <luke-jr> then namecoin accepts block header + coinbase txn + merkle link + bitcoin block header as proof
114 2012-07-22 18:23:46 <cheako> So a successful block is then used on both chains?
115 2012-07-22 18:28:47 <cheako> I've not got a response over at #namecoin.  How can I get my domains into namecoin, I guess I'd be registering .bit domains for the .net/.com domains I already own?
116 2012-07-22 18:31:40 <cheako> It sounds fabulous, It would save me domain renewal fees?  However I can't help but notice that the root nameservers don't seam to have a delegation for bit.
117 2012-07-22 18:32:44 <cande> how safe is it to open up rpcallowip=* with a safe password?
118 2012-07-22 18:35:53 <luke-jr> cheako: namecoin seems mostly dead now IMO
119 2012-07-22 18:36:21 <cheako> ahh, that's too bad.
120 2012-07-22 18:37:30 <cheako> Yeah, I think they would have a hard time getting published in the root nameservers...  who runs them?
121 2012-07-22 18:38:11 <cheako> Though they may be able to get ppl to put them in there bootstrap file.
122 2012-07-22 18:38:18 <luke-jr> not to mention the agency that runs the root nameservers has always been hostile to anyone else adding TLD
123 2012-07-22 18:39:10 <jgarzik> my my my my
124 2012-07-22 18:39:18 <jgarzik> 07/22/12 20:38:50 SetBestChain: new best=00000000000001fe9350  height=190277  work=397331445042998428014  date=07/22/12 20:38:03
125 2012-07-22 18:39:19 <jgarzik> 07/22/12 20:38:50 SetBestChain: 1 of last 100 blocks above version 1
126 2012-07-22 18:39:31 <jgarzik> gmaxwell ^
127 2012-07-22 18:39:47 <luke-jr> someone mining on next-test?
128 2012-07-22 18:40:24 <luke-jr> jgarzik: know which block?
129 2012-07-22 18:41:08 <jgarzik> luke-jr: look at the output just pasted
130 2012-07-22 18:41:16 <luke-jr> jgarzik: it's not block 190277
131 2012-07-22 18:41:36 <luke-jr> unless blockchain.info just hard-coded version 1 -.-
132 2012-07-22 18:42:05 <luke-jr> BBE says 190277 is also ver 1
133 2012-07-22 18:42:21 <jgarzik> 07/22/12 07:15:00 SetBestChain: new best=00000000000001f167ee  height=190192  work=396650067028590193389  date=07/22/12 07:14:32
134 2012-07-22 18:42:22 <jgarzik> 07/22/12 07:15:00 SetBestChain: 1 of last 100 blocks above version 1
135 2012-07-22 18:43:18 <luke-jr> hmm
136 2012-07-22 18:43:29 <luke-jr> it doesn't look like it's got the height either ;/
137 2012-07-22 18:43:42 <luke-jr> a merge-mining BIP16-enabled miner
138 2012-07-22 18:44:43 <luke-jr> on another note, it might be worth seriously considering to use the txn version number instead of the block ver #
139 2012-07-22 18:44:53 <luke-jr> the block ver # might be needed for ASICs. maybe.
140 2012-07-22 18:57:11 <Hunner> cheako: There isn't one group that runs the root servers, but IANA has their hand in the TLD allocation
141 2012-07-22 19:00:34 <cheako> That hand is likely unnecessary.
142 2012-07-22 19:11:43 <cande> any source about magnetlinks and bitcoin?
143 2012-07-22 19:23:34 <luke-jr> cande: no such thing
144 2012-07-22 19:23:52 <cande> yes... it's just the URI?
145 2012-07-22 19:31:18 <genjix> jgarzik: can you merge this? it's been days, and i posted on the mailing list, https://github.com/bitcoin/bitcoin.org/pull/46
146 2012-07-22 19:31:38 <cheako> /home/cheako/.bitcoin/debug.log  <--- this file is kinda big.  Can I add it to mylog rotation?  Something like: kill -HUP $(pgrep bitcoind)
147 2012-07-22 19:31:57 <jgarzik> genjix: done
148 2012-07-22 19:32:34 <luke-jr> cheako: with 0.7, bitcoind respects SIGHUP
149 2012-07-22 19:32:42 <luke-jr> cheako: alternatively, Gentoo has a patch for older versions
150 2012-07-22 19:32:49 <luke-jr> (applied with USE=logrotate)
151 2012-07-22 19:34:14 <cheako> If I was going to recompile...  Yeah, I'm only on 0.3.24~dfsg-1~bpo60+1.
152 2012-07-22 19:37:06 <cheako> squeeze-updates is empty?  Well, I was thinking that the debian packages could ship a bitcoind-data package that has the updates to a recent known good block id.
153 2012-07-22 19:38:05 <cheako> There used to be an exemption for clamav to release new versions in debian-volitile, but it looks like it's gone now.
154 2012-07-22 19:38:32 <cheako> I believe that bitcoin software might have been covered under the same exemption.
155 2012-07-22 19:38:33 <gribble> New news from bitcoinrss: luke-jr opened pull request 1620 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1620>
156 2012-07-22 19:39:00 <luke-jr> cheako: 0.3.24 has known vulnerabilities
157 2012-07-22 19:39:22 <cheako> luke-jr: Debian security backports fixes.
158 2012-07-22 19:39:28 <luke-jr> cheako: no, they don't.
159 2012-07-22 19:39:31 <cheako> luke-jr: I'll check.
160 2012-07-22 19:39:48 <cheako> luke-jr: Well they need to, they just need to be told is all.
161 2012-07-22 19:40:39 <luke-jr> cheako: nobody maintains 0.3
162 2012-07-22 19:40:46 <luke-jr> cheako: there is no tracking of what issues affect it at all
163 2012-07-22 19:41:19 <cheako> luke-jr: Ohh, well anyone can fix that.  Plus the security team maintains any package that has issues, via NMUs.
164 2012-07-22 19:41:40 <luke-jr> but at the very least: CVE-2012-1909, BIP-0016, CVE-2012-2459, and CVE-2012-3789
165 2012-07-22 19:42:32 <cheako> Thank you, I'll forward that.
166 2012-07-22 19:42:42 <luke-jr> I already told them 0.3 was unmaintained and full of bugs
167 2012-07-22 19:42:51 <luke-jr> they were rude and said it wasn't a bug
168 2012-07-22 19:43:11 <luke-jr> and eventually concluded that they'll work on getting a recent version in the next release
169 2012-07-22 19:43:18 <luke-jr> ignoring the current stable
170 2012-07-22 19:43:58 <genjix> jgarzik: thanks
171 2012-07-22 19:45:21 <cheako> Is there any one we should cc on discussions about these?
172 2012-07-22 19:51:57 <luke-jr> cheako: you can CC me, I maintain 0.4.x, 0.5.x, and 0.6.x
173 2012-07-22 19:53:16 <gmaxwell> 14:39 < cheako> luke-jr: Debian security backports fixes.
174 2012-07-22 19:53:18 <gmaxwell> HAHAHAH
175 2012-07-22 19:53:22 <gmaxwell> Yea, good luck with that.
176 2012-07-22 19:53:32 <luke-jr> :p
177 2012-07-22 19:53:47 <gribble> New news from bitcoinrss: luke-jr opened pull request 1621 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1621>
178 2012-07-22 19:54:41 <gmaxwell> hopefully when they "backport" they will send a useful version string so I can make my own nodes refuset to connect to the inevitably broken debian nodes?
179 2012-07-22 19:55:10 <luke-jr> gmaxwell: don't say that. they might not if you're threatening such
180 2012-07-22 19:55:17 <luke-jr> and it's better if they do
181 2012-07-22 19:55:34 <luke-jr> cheako: BTW, the fixes for the last 2 of those are not disclosed
182 2012-07-22 19:55:49 <luke-jr> (nor the nature of them)
183 2012-07-22 19:56:05 <gavinandresen> how are we doing with upgrade percentage, by the way?  You still tracking that luke?
184 2012-07-22 19:56:15 <luke-jr> gavinandresen: 72%
185 2012-07-22 19:56:19 <gavinandresen> oooh, so close
186 2012-07-22 19:56:26 <luke-jr> it's been going slow
187 2012-07-22 19:56:30 <luke-jr> I think it was 71% a week ago
188 2012-07-22 19:56:51 <luke-jr> I still think it'll be fall before we reach 77%
189 2012-07-22 19:57:05 <gmaxwell> I dunno, I bet the 0.7 release bumps it over.
190 2012-07-22 19:57:11 <luke-jr> maybe.
191 2012-07-22 19:57:23 <luke-jr> I bet everyone who upgrades to 0.7 will have been using 0.6.3 already
192 2012-07-22 19:57:51 <luke-jr> speaking of which, I wonder if 0.6.3 has been out long enough that we can bump it to stable on Gentoo&
193 2012-07-22 19:58:17 <luke-jr> 4 more days
194 2012-07-22 20:00:07 <gmaxwell> 0.7 has a lot of awesomeness that might pull along some stragglers.
195 2012-07-22 20:00:47 <luke-jr> gmaxwell: so did 0.6!
196 2012-07-22 20:00:58 <cheako> gmaxwell: Debian will on request, if it comes from the authors of the software...  I still havn't gotten a clear definition of how one tells who that is.  However the point is that Debian is willing to take on extra responsibility if it will make ppl happy and by extra we mean above what the license would require.  This does include not packaging a GPL application at all, though in my experience compromises have been made to satisfy the
197 2012-07-22 20:00:59 <cheako> developers requirements.
198 2012-07-22 20:01:09 <[Tycho]> What upgrade are you talking about ?
199 2012-07-22 20:01:53 <luke-jr> cheako: Debian should just bump stable to 0.4.7
200 2012-07-22 20:02:16 <luke-jr> cheako: it has some minor changes from 0.3.24 to 0.4.1, but not too much; and from 0.4.1 to 0.4.7 is only bugfixes
201 2012-07-22 20:02:39 <cheako> luke-jr: Debian package requirements dictate transparency in that regard, at the vary least we will end up with open DSAs against the packages.
202 2012-07-22 20:03:10 <luke-jr> cheako: ?
203 2012-07-22 20:03:42 <cheako> luke-jr: That's an often requested solution, unfortunately it's either version X that was shipped in stable or package removed...  Usually.
204 2012-07-22 20:04:27 <cheako> luke-jr: For every patch it must be vary clear what the patch is for and how it works.
205 2012-07-22 20:04:48 <luke-jr> cheako: every patch between 0.3.24 and 0.4.7 is available in git
206 2012-07-22 20:05:50 <luke-jr> cheako: also, Debian stable did a major incompatible bump of MySQL not long ago; a compatible bump like this should be nothing
207 2012-07-22 20:06:01 <cheako> luke-jr: You would have to find just cause to include each and every one.
208 2012-07-22 20:06:04 <luke-jr> (yes, I'm aware they wrote a nasty note bashing Oracle for having to do it)
209 2012-07-22 20:06:18 <luke-jr> cheako: "fixes a bug" is just cause IMO
210 2012-07-22 20:06:41 <cheako> Each and every commit, must fix a bug.
211 2012-07-22 20:06:49 <gmaxwell> I really don't think debian's stable model is well fit to bitcoin at this time. Bitcoin is beta software, and I think it was packaged prematurely.
212 2012-07-22 20:07:10 <luke-jr> cheako: OK, so take 0.3.24 and backport every commit between 0.4.1 and 0.4.7, then you've got it
213 2012-07-22 20:07:37 <cheako> git does it?
214 2012-07-22 20:08:14 <luke-jr> cheako: it probably could
215 2012-07-22 20:08:31 <cheako> Transparency of changes made to upstream source is something that I don't believe has ever been successfully overturned, if any one has even tried.
216 2012-07-22 20:09:33 <cheako> gmaxwell: Debian will only package code that has been released.  I'm not sure if Beta releases count, but 0.3.x is hardly beta.
217 2012-07-22 20:10:15 <gmaxwell> cheako: _all_ of the bitcoin reference software is beta.
218 2012-07-22 20:11:14 <cheako> http://bitcoin.org/releases/2011/07/08/v0.3.24.html  <--- beta not found.
219 2012-07-22 20:12:23 <gmaxwell> cheako: then you didn't actually pull the software.
220 2012-07-22 20:14:04 <gmaxwell> $ grep -i BETA `find ./` | wc -l
221 2012-07-22 20:14:09 <gmaxwell> (on 0.3.24)
222 2012-07-22 20:14:20 <gmaxwell> Sorry that telling you 74 times isn't enough. ;)
223 2012-07-22 20:15:04 <gmaxwell> Including in the first line of the readme, and every place the software displays the version message.
224 2012-07-22 20:15:12 <cheako> Ahh, yes I see now: Bitcoin 0.3.24 BETA from doc/README
225 2012-07-22 20:16:06 <cheako> gmaxwell: irc doesn't count, I'm afraid.  It needs to be public where any DD can verify.
226 2012-07-22 20:16:28 <gmaxwell> cheako: I don't know how someone can make it more public than in the software itself.
227 2012-07-22 20:16:41 <cheako> gmaxwell: In the release notes?
228 2012-07-22 20:16:41 <gmaxwell> Bitcoin is novel and risky distributed currency software. The line between feature and fixes is often not very clear.
229 2012-07-22 20:17:07 <cheako> release announcement would be better.
230 2012-07-22 20:17:10 <D34TH> gmaxwell, why find ./ instead of ls
231 2012-07-22 20:17:45 <cheako> Why not: find ./ -exec grep -i BETA {} + | wc -l
232 2012-07-22 20:17:48 <gmaxwell> cheako: _every_ release is beta currently. It would get a little repetative that way and someone who doesn't follow bitcoin well enough to know this really shouldn't be packaging it.
233 2012-07-22 20:18:26 <gmaxwell> D34TH: to make it recursive.
234 2012-07-22 20:18:31 <gmaxwell> cheako: no type f too? :)
235 2012-07-22 20:18:44 <cheako> gmaxwell: DMs would surprise you, they arn't always the brightest bunch...  overall.
236 2012-07-22 20:19:02 <dooglus> grep -r ?
237 2012-07-22 20:19:33 <gmaxwell> What is this& this old commandline? :)
238 2012-07-22 20:24:27 <luke-jr> I prefer: grep whatever $(git ls-files)
239 2012-07-22 20:24:28 <luke-jr> <.<
240 2012-07-22 20:25:53 <cccp_> ack is nice as well :)
241 2012-07-22 20:26:15 <gmaxwell> luke-jr: thats a pretty good one.
242 2012-07-22 20:26:21 <lianj> luke-jr: why not git grep .. then?
243 2012-07-22 20:27:03 <gmaxwell> lianj: because luke's form is generic and works with whatever tool you want to plug in.
244 2012-07-22 20:27:06 <genjix> does anyone know how to stop ubuntu adding spaces to paths when tab completing for ack-grep?
245 2012-07-22 20:30:10 <genjix> i have this https://bugs.launchpad.net/ubuntu/+source/ack-grep/+bug/746380
246 2012-07-22 20:31:28 <luke-jr> (as in, takes much more than 23 minutes
247 2012-07-22 21:31:56 <Ferroh> ok so multikey is live in the client right now right?
248 2012-07-22 21:32:29 <Ferroh> currently what I do, is have a wallet for a public bitcoin-service site on a completely separate server
249 2012-07-22 21:32:38 <Ferroh> but I'd like to move the satoshi client to the website server
250 2012-07-22 21:32:42 <Ferroh> however,
251 2012-07-22 21:33:00 <Ferroh> I don't want this client to be able to spend funds without a secondary key
252 2012-07-22 21:33:42 <Ferroh> but the problem is
253 2012-07-22 21:35:02 <Ferroh> transmitting the secondary key to the client, without it being discovered if the site is compromised without my knowledge
254 2012-07-22 21:35:06 <Ferroh> I guess this isn't possible.
255 2012-07-22 21:35:32 <Ferroh> er,
256 2012-07-22 21:35:33 <Ferroh> lol nevermind
257 2012-07-22 21:35:41 <Ferroh> I can just copy the site's wallet to the secondary server
258 2012-07-22 21:35:47 <Ferroh> instead of transmitting the secondary key
259 2012-07-22 21:35:49 <Ferroh> derp
260 2012-07-22 21:36:03 <Ferroh> you can ignore that ^^ wall of text now.
261 2012-07-22 21:41:26 <luke-jr> Ferroh: multikey is supported by Bitcoin live, but not any clients really
262 2012-07-22 21:41:52 <Ferroh> luke-jr, I meant it is now supported by the current stable version of the satoshi client, right?
263 2012-07-22 21:41:55 <luke-jr> Ferroh: but really, it sounds like you want HD wallets, not multikey
264 2012-07-22 21:42:03 <Ferroh> luke-jr, "HD wallets"?
265 2012-07-22 21:42:05 <luke-jr> Ferroh: no, no client supports multikey really
266 2012-07-22 21:42:22 <luke-jr> Ferroh: HD wallets allow you to deploy a read-only webserver with another client that can spend
267 2012-07-22 21:42:31 <Ferroh> luke-jr, What I want is to prevent this client from being able to spend funds without a secondary authenticator.
268 2012-07-22 21:42:33 <luke-jr> so the webserver can make new addresses, but it can't spend from them
269 2012-07-22 21:42:35 <gavinandresen> They support sending to multikey addresses, but not spending if they don't have all the keys
270 2012-07-22 21:42:46 <luke-jr> ^ right, it can send to them
271 2012-07-22 21:42:52 <gavinandresen> Ferroh: see https://gist.github.com/3161162   (which I wrote up this weekend)
272 2012-07-22 21:43:01 <luke-jr> (IMO, spending-if-you-have-all-the-keys is worthless really)
273 2012-07-22 21:43:14 <gavinandresen> (agreed, was only useful for testing)
274 2012-07-22 21:43:45 <Ferroh> Well, how else do I achieve the ability to have a site that can accept coins to an arbitrary number of addresses, without spending them?
275 2012-07-22 21:43:54 <luke-jr> Ferroh: HD wallets
276 2012-07-22 21:44:06 <Ferroh> gavinandresen, to be clear, you're saying that https://gist.github.com/3161162 is not an ideal solution, and was merely a good test?
277 2012-07-22 21:44:26 <gavinandresen> I'm saying that gist explains how you can do what you probably want to do with the current code in git HEAD
278 2012-07-22 21:44:28 <luke-jr> Ferroh: https://en.bitcoin.it/wiki/BIP_0032 - also not implemented anywhere (although Armory has an earlier draft)
279 2012-07-22 21:45:01 <gmaxwell> multisignature isn't the tool you want for a recieve only wallet.
280 2012-07-22 21:45:02 <luke-jr> (note Armory's wallets are only Deterministic, not Hierarchial)
281 2012-07-22 21:45:38 <Ferroh> gmaxwell, well it isnt receive only -- it needs to spend, it's just that I want to make sure that the client on the site cant spend if the site is compromised
282 2012-07-22 21:45:38 <gmaxwell> Hell you could just use a regular wallet, set the keypool to an enormous size, encrypt it.. and never let the decryption key touch the webserver. This is not as good as what can be done with HD wallets, but it works today.
283 2012-07-22 21:45:41 <gavinandresen> Ferroh: but that gist is the "duct tape and bailing wire" solution until we figure out how to make a GUI that works for that kind of thing
284 2012-07-22 21:46:09 <luke-jr> Ferroh: the hard part there is determining if the site is compromised ;)
285 2012-07-22 21:46:24 <gmaxwell> Ah for spending, then yes, multisignature does that.. but the UI to make it useful to you isn't done yet.
286 2012-07-22 21:46:26 <Ferroh> what I currently do is pregenerate 10K public keys at a time, and store them in an SQL database on the site.
287 2012-07-22 21:46:31 <Ferroh> luke-jr, I shouldn't have to determine that.
288 2012-07-22 21:46:43 <luke-jr> Ferroh: you do.
289 2012-07-22 21:46:46 <Ferroh> so currently I store no private keys on the site
290 2012-07-22 21:46:46 <luke-jr> Ferroh: it's unavoidable
291 2012-07-22 21:46:47 <gmaxwell> er, that sure sounds like a read-only wallet to me then.
292 2012-07-22 21:47:03 <Ferroh> gmaxwell, no, because I have all the same keys on a spendable client elsewhere
293 2012-07-22 21:47:12 <Ferroh> luke-jr, no, you shouldn't have to detect that, and it is possible.
294 2012-07-22 21:47:12 <gavinandresen> yes, if you've got another secure system where all spends can be done, do what gmaxwell suggests
295 2012-07-22 21:47:24 <gmaxwell> Ferroh: sure... a wallet that can't be spent by _anyone_ isn't very useful. :)
296 2012-07-22 21:47:57 <luke-jr> Ferroh: it is impossible to have "allow spending, but only if the spend is authorized from a non-compromised system" without defining "non-compromised" in some technical manner
297 2012-07-22 21:48:02 <Ferroh> luke-jr, well, to be clear, you dont have to detect if the website server is compromised -- but you'd have to detect if the OTHER wallet that can spend is compromised -- still that's much better due to linode hack type situations
298 2012-07-22 21:48:11 <Ferroh> luke-jr, yes exactly
299 2012-07-22 21:48:26 <Ferroh> luke-jr, er sorry, I thought you said "possible"
300 2012-07-22 21:48:26 <luke-jr> Ferroh: so define it. it's not obvious.
301 2012-07-22 21:49:00 <Ferroh> luke-jr, okay for example, you do exactly what I'm doing now. which is store only public keys on server A, and then all keys on server B. Now only server B can spend, and we dont care if server A is compromised or not.
302 2012-07-22 21:49:18 <luke-jr> Ferroh: but you want server A to spend if it's not compromised&
303 2012-07-22 21:50:26 <Ferroh> luke-jr, I see what you mean, but that's not actually important since server B can spend from all of server A's addresses. I don't actually need server A to technically spend
304 2012-07-22 21:50:47 <gavinandresen> gmaxwell: have you thought at all about luke-jr's proposal for a priority formula?  priority = WEIGHT1*sum(inputs)*age/size + WEIGHT2*fee ?
305 2012-07-22 21:50:52 <luke-jr> Ferroh: ok then
306 2012-07-22 21:50:55 <Ferroh> the point is that I want to be able to spend from server A's wallet, without anyone who has compromised server A being able to do so
307 2012-07-22 21:51:42 <luke-jr> Ferroh: Armory can do that today. BIP 32 (HD wallets) is the feature you want to look for going forward.
308 2012-07-22 21:52:17 <Ferroh> luke-jr, I cant run armory on a webserver due to the ram requirements
309 2012-07-22 21:52:19 <Ferroh> gmaxwell, I guess I like that idea, I'll try that.
310 2012-07-22 21:52:24 <Ferroh> thanks guys
311 2012-07-22 21:53:23 <gmaxwell> gavinandresen: I don't have a strong opinion on it... although I expect if the weights are configuratble will set it 0/1 because it isn't clear what the tradeoffs actually mean.
312 2012-07-22 21:55:06 <gavinandresen> gmaxwell: I don't have a strong opinion either; default weights could be set so that a transaction with "foo" age-based-priority and zero fee has the same priority as one with "bar" fee.  It makes the transaction selection code simpler, which is a plus.
313 2012-07-22 21:57:38 <gavinandresen> (oh, and I got the formula wrong, it is really    (WEIGHT1*sum(input*age) + WEIGHT2*fee) / size )
314 2012-07-22 21:58:08 <gmaxwell> I'd assumed fee was fee/kb there, so it's rearrangably the same in any case. :)
315 2012-07-22 21:58:43 <gmaxwell> Thats probably reasonable if we could come up with an intutive way of seeing the weights that won't result in the priority weight being 0 out of ignorance.
316 2012-07-22 21:59:13 <luke-jr> heh, I thought it was gavinandresen politely demanding that part be changed <.<
317 2012-07-22 21:59:34 <gmaxwell> perhaps just flooring is so you can't weight priority below where a sub minfee transaction is higher priority than a free txn under the current rules.
318 2012-07-22 21:59:52 <gavinandresen> luke-jr: I politely demanded that the fee part not also be multiplied by the input value size, if I recall
319 2012-07-22 22:00:05 <luke-jr> gavinandresen: yes, I confused that with this ;)
320 2012-07-22 22:00:51 <gmaxwell> nah, fee should always be looked at as fee per kb. Thats the only sane thing.. otherwise you create weird incentives, especially since space is the scarce resource.
321 2012-07-22 22:01:07 <gavinandresen> yup
322 2012-07-22 22:01:26 <jgarzik> w00t
323 2012-07-22 22:01:42 <luke-jr> gavinandresen: so shall I adjust txn_prio for that change, or are you integrating it into your branch anyway?
324 2012-07-22 22:01:47 <jgarzik> pynode appears to be properly connecting inputs, on the first try.  that kind of thing never happens.  there has -got- to be a bug somewhere.
325 2012-07-22 22:01:50 <gavinandresen> baby peed when you were changing his diaper and you managed to duck out of the way this time?
326 2012-07-22 22:02:02 <luke-jr> haha
327 2012-07-22 22:03:42 <gavinandresen> luke-jr: I'd like any change to the transaction priority to be separate from the bundle-dependent-transactions change (separate commit, at least)
328 2012-07-22 22:04:50 <gavinandresen> I like the bundle-dependent-transactions change, but I'd like to do things step by step to try to prevent an "oops, those two things together did something bad we didn't anticipate...."
329 2012-07-22 22:05:12 <gavinandresen> (that we might not see until a majority of blocks use the new transaction inclusion rules)
330 2012-07-22 22:05:16 <jgarzik> next step, making memory pool validate connectivity.  then I can create a getmemorypool clone.
331 2012-07-22 22:06:52 <gavinandresen> nobody has written a Python-based Script validator?
332 2012-07-22 22:09:46 <jgarzik> gavinandresen: not that I've seen
333 2012-07-22 22:10:27 <jgarzik> there is this from phantomcircuit, https://github.com/phantomcircuit/bitcoin-alt/blob/master/bitcoin/script.py
334 2012-07-22 22:10:33 <xenland> I'd be suprised if anyone used Bitcoin script :P
335 2012-07-22 22:10:34 <jgarzik> but he said it was incomplete
336 2012-07-22 22:11:03 <jgarzik> gavinandresen: I'll write one for pynode, if none appears
337 2012-07-22 22:11:28 <luke-jr> gavinandresen: I'm pretty sure someone did.
338 2012-07-22 22:11:55 <luke-jr> jgarzik: there's some minimal txn/node framework in Eloipool that might or might not be useful
339 2012-07-22 22:12:39 <jgarzik> luke-jr: does it validate scripts?
340 2012-07-22 22:12:42 <luke-jr> https://gitorious.org/bitcoin/eloipool/blobs/master/bitcoin/node.py https://gitorious.org/bitcoin/eloipool/blobs/master/bitcoin/txn.py https://gitorious.org/bitcoin/eloipool/blobs/master/bitcoin/script.py
341 2012-07-22 22:12:47 <luke-jr> jgarzik: no, it's very minimal
342 2012-07-22 22:13:19 <luke-jr> just barely smart enough to count SIGOPs right
343 2012-07-22 22:16:16 <gavinandresen> might be easier to package up script.cpp/script.h into a python-callable doohickey
344 2012-07-22 22:16:37 <gavinandresen> You'd drag in openssl as a dependency, though
345 2012-07-22 22:18:43 <jgarzik> phantomcircuit's work might be a useful starting point
346 2012-07-22 22:19:01 <Joric> python-ecdsa lacks point conversion :(
347 2012-07-22 22:21:19 <jgarzik> interesting.  https://bitcointalk.org/index.php?topic=28231.0 leads to https://bitcointalk.org/index.php?topic=23241.0
348 2012-07-22 22:21:28 <jgarzik> the latter of which might solve the problem in pure python
349 2012-07-22 22:22:06 <copumpkin> that sounds like problem solves you
350 2012-07-22 22:23:22 <Joric> shoulda reupload brutus
351 2012-07-22 22:30:04 <Joric> here, with point compression https://github.com/samrushing/caesure/blob/master/ecdsa_pure.py
352 2012-07-22 22:30:24 <Joric> oops https://github.com/joric/brutus/blob/master/ecdsa_pure.py
353 2012-07-22 22:31:13 <lianj> gavinandresen: i got one in ruby. mostly complete, runs almost any script in the mainnet
354 2012-07-22 22:31:32 <copumpkin> there's roconnor's very clear pure haskell one :)
355 2012-07-22 22:31:39 <copumpkin> although I suppose it's not very clear if you don't like/know haskell
356 2012-07-22 22:32:12 <gavinandresen> lianj: have you tested it on testnet3 ?  I mined a bunch of interesting test cases there....
357 2012-07-22 22:33:12 <lianj> gavinandresen: nope. but good to know.. i will try it some day
358 2012-07-22 22:34:36 <lianj> usually i only add something if it show up on the mainnet and break my block validation :D
359 2012-07-22 22:52:29 <jgarzik> yeah unfortunately pynode only runs on mainnet right now :/   Need to get that fixed, because the testnet3 tests are good exercise
360 2012-07-22 22:52:59 <luke-jr> jgarzik: any particular reason you're using old Python 2?
361 2012-07-22 22:54:00 <jgarzik> luke-jr: that's the default on Fedora, and people seem more likely to actually have python2 than python3
362 2012-07-22 22:55:10 <[darkwhite]_u> does anybody see something better than btc being created in the next 3 years or so? i know its hard to predict. but i thought maybe somebody might have inside info here
363 2012-07-22 22:55:15 <copumpkin> lots of people still stick with ruby 1.8.*
364 2012-07-22 22:58:56 <luke-jr> [darkwhite]_u: any real improvement can generally be added to Bitcoin with a hardfork; therefore, if there was anything game-changing enough to compete with Bitcoin, Bitcoin could just assimilate it
365 2012-07-22 22:59:06 <luke-jr> therefore, I don't think anything will take over Bitcoin
366 2012-07-22 22:59:15 <luke-jr> copumpkin: I stick with no-ruby
367 2012-07-22 22:59:20 <copumpkin> same here :)
368 2012-07-22 22:59:29 <copumpkin> I think we picked different alternatives though
369 2012-07-22 23:03:54 <MC1984> wow litcoin chain download is significantly faster than bitcoin
370 2012-07-22 23:04:06 <MC1984> is that cos there are no txns in it
371 2012-07-22 23:04:15 <MC1984> i heard litecoin was spammed
372 2012-07-22 23:05:18 <doublec> no transactions - small blocks
373 2012-07-22 23:05:23 <doublec> except for that time when it was spammed
374 2012-07-22 23:08:28 <MC1984> 300 hashes per second
375 2012-07-22 23:59:45 <jgarzik> yay, successfully imported block chain w/ TX connectivity verification