1 2012-04-14 04:28:24 <gribble> New news from bitcoinrss: laanwj opened pull request 1096 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1096>
  2 2012-04-14 05:47:36 <gribble> New news from bitcoinrss: laanwj opened pull request 1097 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1097>
  3 2012-04-14 07:47:43 <gribble> New news from bitcoinrss: nomnombtc opened issue 1098 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1098>
  4 2012-04-14 10:42:25 <t7> ;;calc 4000 * 60 * 10
  5 2012-04-14 10:42:26 <gribble> 2400000
  6 2012-04-14 10:43:22 <gribble> 720000000
  7 2012-04-14 10:43:22 <t7> ;;calc 4000 * 60 * 10 * 300
  8 2012-04-14 10:44:13 <t7> at 4000 txs a second, assuming each tx is 300 bytes, thats 720 meg a block
  9 2012-04-14 10:44:45 <Diablo-D3> 4000 tx a second would also be global transaction peak roughly
 10 2012-04-14 10:44:45 <t7> i hope bitcoin doesnt get popular
 11 2012-04-14 10:45:05 <Diablo-D3> and like I said, in the future, you'd have bitcoin banks that offer bitcoin debit cards of some sort
 12 2012-04-14 12:42:34 <paulo_> how do I compile bitcoind on my box?
 13 2012-04-14 13:20:52 <paulo_> sigh, bitcoind on my VPS is downloading the block chain...
 14 2012-04-14 13:25:32 <paulo_> bitcoind is not letting my shell go.
 15 2012-04-14 13:29:23 <luke-jr> -daemon
 16 2012-04-14 13:30:00 <paulo_> thanks
 17 2012-04-14 13:54:22 <gribble> New news from bitcoinrss: jgarzik opened issue 1099 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1099>
 18 2012-04-14 15:24:52 <paulo_> is it possible for a wallet to contain only addresses, not private keys??
 19 2012-04-14 15:29:38 <Joric> paulo_, wallet.dat contains keypairs
 20 2012-04-14 15:30:15 <Joric> so no, not really
 21 2012-04-14 15:31:01 <luke-jr> paulo_: possible, yes
 22 2012-04-14 15:31:05 <luke-jr> likely, no
 23 2012-04-14 16:28:02 <graingert> why was safemode removed?
 24 2012-04-14 16:28:11 <graingert> it seems quite handy
 25 2012-04-14 16:39:16 <luke-jr> [Monday, April 09, 2012] [4:47:53 PM] <sipa>    wait, we have GetDataDir(), which does the following: check a cached value, if set, return it; if not set, return default
 26 2012-04-14 16:39:27 <luke-jr> sipa: did you eventually figure out that it didn't do just quite that?
 27 2012-04-14 17:16:45 <sipa> luke-jr: i changed it in my boostpaths pullreq
 28 2012-04-14 17:17:12 <luke-jr> I know you changed it, but did you notice it *doesn't* do what you initially thought it did? :P
 29 2012-04-14 17:17:30 <luke-jr> the "cached value" is a copy of -datadir
 30 2012-04-14 17:17:33 <luke-jr> only
 31 2012-04-14 18:16:35 <jjjrmy> I'm working on a project for Startup Weekend related to Bitcoin. I need some customer validation from the Bitcoin community. Please take this survey: http://www.surveymonkey.com/s/BGYWYW6
 32 2012-04-14 18:23:14 <sipa> luke-jr: i wasn't sure about that, actually; it's a lot more understandable now, imho
 33 2012-04-14 18:31:12 <dikidera> it's ok the run 0.6.0, right?
 34 2012-04-14 18:31:23 <dikidera> *to
 35 2012-04-14 18:31:44 <splatster> dikidera: Read the topic "Latest version: 0.6.0 *OLD VERSIONS HARM THE NETWORK AND YOUR SECURITY*"
 36 2012-04-14 18:31:59 <splatster> Yes, you are quite fine to be using 0.6
 37 2012-04-14 18:33:42 <dikidera> man
 38 2012-04-14 18:33:51 <dikidera> I haven't ran the client for so long, it's stuck on startup..
 39 2012-04-14 18:34:13 <splatster> dikidera: It might take a bit for it to load the blockindex.
 40 2012-04-14 18:34:26 <dikidera> weren't there improvements from sipa?
 41 2012-04-14 18:34:31 <splatster> and then your wallet, and then the address book, etc.
 42 2012-04-14 18:34:42 <splatster> dikidera: It still takes a minute.
 43 2012-04-14 18:36:25 <dikidera> more like 15 to go
 44 2012-04-14 18:36:28 <dikidera> or perhaps 30
 45 2012-04-14 18:36:32 <luke-jr> dikidera: delete addr.dat ?
 46 2012-04-14 18:36:36 <luke-jr> (rename it actually)
 47 2012-04-14 18:36:39 <dikidera> why?
 48 2012-04-14 18:38:08 <sipa> there's a known issue where the client gets stuck when addr.dat was silently corrupted before, and you upgrade to 0.6
 49 2012-04-14 18:38:39 <dikidera> It ran just fine, just downloading 1-2 blocks per second
 50 2012-04-14 18:38:44 <dikidera> and I had 2.5k to go
 51 2012-04-14 18:39:05 <luke-jr> addr.dat != blk*
 52 2012-04-14 18:39:16 <dikidera> trolling?
 53 2012-04-14 18:39:40 <sipa> ok, so you don't have a problem really
 54 2012-04-14 18:39:54 <sipa> the last few thousand blocks are a lot slower
 55 2012-04-14 18:43:51 <dikidera> I'd hate to be the poor bastard, who is downloading the chain from scratch
 56 2012-04-14 18:44:23 <splatster> dikidera: Everyone has at one point been that poor bastard.
 57 2012-04-14 18:45:05 <sipa> dikidera: takes around 1-2 hours in good conditions
 58 2012-04-14 18:45:26 <sipa> fast cpu, fast disk, good network, good peer
 59 2012-04-14 18:46:09 <dikidera> Considering there are a lot of "sleeps" inside, a fast CPU wouldn't really contribute much
 60 2012-04-14 18:46:34 <dikidera> but you have a point there
 61 2012-04-14 18:47:41 <gmaxwell> it really does, assuming the rest is fast.. a good chunk of the end is just cpubound.
 62 2012-04-14 18:49:05 <splatster> gmaxwell: Is it possible to make an output that can be redeemable by anyone? ie. no privkey
 63 2012-04-14 18:49:15 <gmaxwell> splatster: sure.
 64 2012-04-14 18:49:17 <sipa> splatster: yes
 65 2012-04-14 18:49:21 <sipa> not standard, but yes
 66 2012-04-14 18:49:27 <splatster> I think that would be interesting for a sort of giveaway.
 67 2012-04-14 18:49:36 <dikidera> I think it wouldn't
 68 2012-04-14 18:49:45 <dikidera> unless you freely tell people how to "redeem" it
 69 2012-04-14 18:49:56 <dikidera> Because, for instance, I don't know how
 70 2012-04-14 18:49:59 <gmaxwell> because its non-standard it a bit hard to redeem... also, luke has written code to redeem these already, so its fine if you want to give money to luke. :)
 71 2012-04-14 18:50:13 <splatster> heh
 72 2012-04-14 18:50:42 <luke-jr> splatster: my client has a mod that automatically tries to spend every output, FWIW
 73 2012-04-14 18:51:11 <[Tycho]> luke-jr: it's not effective
 74 2012-04-14 18:51:22 <luke-jr> [Tycho]: it's lazy
 75 2012-04-14 18:51:33 <splatster> luke-jr: Have tou ever actually redeemed any coins with this modded client?
 76 2012-04-14 18:51:45 <dikidera> I say most likely
 77 2012-04-14 18:52:18 <luke-jr> splatster: all the time.
 78 2012-04-14 18:52:26 <splatster> really?
 79 2012-04-14 18:52:32 <splatster> How much?
 80 2012-04-14 18:52:44 <[Tycho]> It's easy to make it more effective, but his script only helps is rare cases.
 81 2012-04-14 18:52:45 <luke-jr> I used to get p2pool zero-value debug outputs, before I made it check amount >= 1
 82 2012-04-14 18:52:55 <splatster> Also, TX IDs or it didn't happen
 83 2012-04-14 18:53:06 <luke-jr> 8f07268d72d7f2af635366b812eb291a6a3b7ad5dc5845b5a9656095555c193a
 84 2012-04-14 18:53:09 <luke-jr> 3bd28f27f621b31f3fca4c16fa2012a986f68a19dba4b443be04fcdb20d03e77
 85 2012-04-14 18:53:12 <luke-jr> 39ed81ea0787b7770ee8b229ad65482d06c9f4841a8f91f59336eacf580899d0
 86 2012-04-14 18:54:24 <splatster> 0.12163307 BTC total received isn't that much.
 87 2012-04-14 18:54:35 <dikidera> free money is free money
 88 2012-04-14 18:54:39 <luke-jr> splatster: this is part of my regular client, which I use for normal txns all the time
 89 2012-04-14 18:55:24 <splatster> Ok... 0.12163307 BTC still isn't that much
 90 2012-04-14 18:55:37 <[Tycho]> For example, he didn't manage to catch this: http://blockexplorer.com/tx/aea682d68a3ea5e3583e088dcbd699a5d44d4b083f02ad0aaf2598fe1fa4dfd4#o1
 91 2012-04-14 18:56:07 <[Tycho]> I think BlueMatt or sipa collected them.
 92 2012-04-14 18:56:31 <luke-jr> [Tycho]: I only try arbitrary numbers of OP_1
 93 2012-04-14 18:56:38 <sipa> [Tycho]: I didn't.
 94 2012-04-14 18:56:42 <dikidera> Is this what you guys do with your free time?
 95 2012-04-14 18:56:55 <[Tycho]> dikidera: strange transactions are cool.
 96 2012-04-14 18:57:09 <[Tycho]> sipa: so it was BlueMatt then.
 97 2012-04-14 18:57:32 <splatster> luke-jr: You might find a bunch on testnet.
 98 2012-04-14 18:57:47 <splatster> But a goldmine of testnet coins is worthless.
 99 2012-04-14 18:58:08 <[Tycho]> splatster: in some cases it may be possible.
100 2012-04-14 18:58:42 <[Tycho]> For example, mtgox lost ~2000+ BTC to strange TXes. Sadly, they are not easy to redeem.
101 2012-04-14 18:59:17 <splatster> I thought those coins that Gox mis-sent were unredeemable.
102 2012-04-14 18:59:33 <[Tycho]> I can't remember exact script.
103 2012-04-14 18:59:53 <[Tycho]> May be they are redeemable if you bruteforce a 0-hash :)
104 2012-04-14 19:00:28 <[Tycho]> But there is still a chance that someone makes a mistake and sends a fortune to redeemable address
105 2012-04-14 19:00:58 <paulo_> can strange transactions harm the network?
106 2012-04-14 19:01:10 <[Tycho]> paulo_: usually not.
107 2012-04-14 19:01:33 <[Tycho]> Except for DOS attempts,
108 2012-04-14 19:01:40 <gmaxwell> Or bugs they exploit.
109 2012-04-14 19:02:05 <gmaxwell> e.g. https://en.bitcoin.it/wiki/Incidents#LSHIFT_and_RETURN_bugs
110 2012-04-14 20:16:19 <sipa> luke-jr: you never requested a BIP number for getmemorypool?
111 2012-04-14 20:22:28 <luke-jr> sipa: I did.
112 2012-04-14 20:23:21 <sipa> amir says he never assigned a number
113 2012-04-14 20:23:27 <luke-jr> 22
114 2012-04-14 20:23:36 <luke-jr> do I need to find my log? :P
115 2012-04-14 20:24:56 <sipa> i don't care - but i prefer to have a single directory, and amir just gave me number 22 for determinstic wallets
116 2012-04-14 20:25:08 <luke-jr> -.-
117 2012-04-14 20:27:01 <sipa> i'll ask for another
118 2012-04-14 20:27:19 <sipa> another know how to create a Template:Bip on bitcoin.it's wiki?
119 2012-04-14 20:27:38 <sipa> I copied some code using ambox, but that seems to fail there
120 2012-04-14 20:28:33 <sipa> gmaxwell, MagicalTux: ^
121 2012-04-14 20:36:00 <luke-jr> [Saturday, March 03, 2012] [9:11:10 PM] <genjix>        BIP 22
122 2012-04-14 20:36:02 <luke-jr> sipa: ^
123 2012-04-14 20:37:13 <luke-jr> ironically, when I went to make the wiki page, there was also a BIP 22 already back then; genjix said he didn't approve it, and moved or deleted it
124 2012-04-14 20:39:52 <luke-jr> https://en.bitcoin.it/wiki/OP_CHECKSIGEX_DRAFT_BIP <-- "BIP 22" before getmemorypool
125 2012-04-14 20:43:03 <jgarzik> luke-jr, sipa: TD has the right plan... pick a sufficiently large, unused two digit number :)
126 2012-04-14 20:43:43 <luke-jr> jgarzik: that's just asking for trouble :P
127 2012-04-14 20:44:44 <sipa> there was supposed to be nice mechanism, with one person in charge of just assigning numbers
128 2012-04-14 20:44:54 <sipa> but things still get messed up
129 2012-04-14 20:50:13 <jgarzik> luke-jr: any chance you have a patch, against [remotely] current bitcoin/bitcoin.git code, that updates RPC server to do thread-per-connection?
130 2012-04-14 20:50:36 <luke-jr> jgarzik: yes
131 2012-04-14 20:50:48 <jgarzik> luke-jr: url?
132 2012-04-14 20:50:53 <luke-jr> https://github.com/bitcoin/bitcoin/pull/568
133 2012-04-14 20:51:20 <luke-jr> JoelKatz's part includes a comment on it being experimental, but only allows removing it as part of a merge to mainline
134 2012-04-14 20:52:09 <luke-jr> I've kept rebasing this one as master changed, so it should merge cleanly
135 2012-04-14 20:52:31 <luke-jr> as well as continued to test it on Eligius (though it uses getmemorypool now, so not as "busy") and locally
136 2012-04-14 20:54:57 <jgarzik> luke-jr: good to know, thanks.  As I noted in the pull req, I like it.  With sipa's payment stuff, improving the internal HTTP server becomes even more useful.  And that's what the RPC server is, so...
137 2012-04-14 20:55:02 <graingert> sipa: can we get number assignment in the blockchain?
138 2012-04-14 20:55:20 <luke-jr> sipa's payment stuff?
139 2012-04-14 20:55:27 <graingert> sipa: like namecoin
140 2012-04-14 20:55:33 <sipa> graingert: ieeuw
141 2012-04-14 20:55:39 <graingert> heh
142 2012-04-14 20:55:40 <luke-jr> graingert: I think the reason for the human is to filter out BS ;)
143 2012-04-14 20:55:42 <jgarzik> luke-jr: see his email from today, in bitcoin-devel's "fill or kill" discussion
144 2012-04-14 20:56:03 <graingert> unacceptable
145 2012-04-14 20:56:08 <graingert> the block chain is the only law
146 2012-04-14 20:56:14 <sipa> graingert: NO
147 2012-04-14 20:56:26 <jgarzik> luke-jr: https://gist.github.com/1237788
148 2012-04-14 20:56:30 <sipa> the blockchain is the rule for one thing and one thing only: ordering otherwise valid transactions
149 2012-04-14 20:56:41 <graingert> otherwise?
150 2012-04-14 20:56:55 <sipa> transactions that are valid apart from being potentially double spent
151 2012-04-14 20:57:07 <sipa> the block chain's only function is preventing double spending
152 2012-04-14 20:57:25 <graingert> handy that
153 2012-04-14 20:58:02 <jgarzik> luke-jr: to be specific... when you say "I've kept it up to date with master", are you referring to (a) your local git or (b) the commits found in pull req #568, last updated 10 months ago
154 2012-04-14 20:58:03 <jgarzik> ?
155 2012-04-14 21:15:16 <luke-jr> jgarzik: the pullreq
156 2012-04-14 21:15:29 <luke-jr> jgarzik: the timestamps in the commits don't change when you rebase
157 2012-04-14 21:15:54 <luke-jr> https://github.com/luke-jr/bitcoin/commit/73636bc230806fadf892398ff2bd73ea5ec310a2 <-- actual commit shows author *and* commit date (4 days ago)
158 2012-04-14 21:16:51 <sipa> indeed, sometimes i'd prefer that github used commit times on the pullreq page
159 2012-04-14 21:17:14 <luke-jr> well, for the "x days ago" bit at least
160 2012-04-14 21:17:29 <sipa> indeed
161 2012-04-14 21:56:09 <jgarzik> sipa: +1
162 2012-04-14 21:56:14 <jgarzik> luke-jr: ok, thanks
163 2012-04-14 21:56:31 <luke-jr> jgarzik: np, hope it gets in finally
164 2012-04-14 21:56:47 <luke-jr> (though tbh, I'd expect it more of 0.7 than 0.6.1&)
165 2012-04-14 23:02:58 <gribble> New news from bitcoinrss: luke-jr opened pull request 1100 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1100>
166 2012-04-14 23:05:22 <luke-jr> jgarzik: why the need to reinvent things? you seem to be missing a number of threadsafety things at least
167 2012-04-14 23:06:57 <luke-jr> anyhow, IMO, best to merge the tried-and-tested branch and try to do cleanup after that; at least then if something breaks, it can be bisected down
168 2012-04-14 23:07:24 <jgarzik> luke-jr: you may apply the latter two patches on top of these two important ones
169 2012-04-14 23:08:00 <gribble> New news from bitcoinrss: jgarzik opened pull request 1101 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1101>
170 2012-04-14 23:08:29 <luke-jr> jgarzik: thread-safety issues aren't exactly unimportant
171 2012-04-14 23:08:47 <jgarzik> luke-jr: req #568 is not upstream ready.  The very first comment in the patch tells you "remove me before going upstream"
172 2012-04-14 23:09:08 <luke-jr> jgarzik: which can't really legally be removed until it actually is being merged.
173 2012-04-14 23:09:17 <luke-jr> removing a single comment is trivial anyhow
174 2012-04-14 23:10:10 <jgarzik> luke-jr: sorry, we don't merge-first, fix-afterwards.  The time to get things right is -before- it goes upstream.
175 2012-04-14 23:10:19 <luke-jr> jgarzik: that's my point.
176 2012-04-14 23:10:45 <jgarzik> luke-jr: the thread safety crap is definitely the wrong approach, and there is no technical reason why it must be patch #2 rather than patch #3
177 2012-04-14 23:11:02 <jgarzik> luke-jr: we already have a per-RPC-call info table.  just update that.
178 2012-04-14 23:11:33 <luke-jr> that would definitely be better, I agree. it's also unwritten and completely untested, so riskier.
179 2012-04-14 23:11:37 <jgarzik> regardless, patches #2 and #4 may be trivially rebased on top of what I just pushed.
180 2012-04-14 23:12:42 <sipa> hmm, why boost locks directly, instead of our macros? this way gavin's lock detection becomes less useful
181 2012-04-14 23:12:58 <luke-jr> I'm just concerned that the pullreq there *as-is* is very unsafe, so it isn't upstream-ready unless we did merge-first-fix-afterwards.
182 2012-04-14 23:13:32 <luke-jr> sipa: it was to enable inner scopes to release the lock
183 2012-04-14 23:13:38 <luke-jr> sipa: afaik our macros can't do that.
184 2012-04-14 23:14:53 <sipa> sure they can
185 2012-04-14 23:14:56 <luke-jr> ?
186 2012-04-14 23:15:30 <sipa> it's used in walletlockthread and net::beginmessage
187 2012-04-14 23:16:22 <jgarzik> sipa: agree, will update
188 2012-04-14 23:16:51 <sipa> there's a better solution, using an sort of scoped anti-lock object
189 2012-04-14 23:17:04 <luke-jr> hmm
190 2012-04-14 23:17:14 <sipa> but it didn't occur frequently enough yet to implement that
191 2012-04-14 23:17:16 <jgarzik> sipa: one-big-lock is just fine, until getwork is updated to be thread safe
192 2012-04-14 23:17:41 <jgarzik> sipa: no point in merging all those "mark RPC calls thread safe, or not" shite upstream... just fix the few places that are not thread safe
193 2012-04-14 23:17:50 <luke-jr> or removed, since maintaining getwork was basically ruled as uninteresting last I heard
194 2012-04-14 23:17:59 <sipa> jgarzik: ACK
195 2012-04-14 23:18:05 <jgarzik> luke-jr: that's 100% bullshit, re getwork
196 2012-04-14 23:18:24 <sipa> i'd like to see a move away from getwork too
197 2012-04-14 23:18:31 <luke-jr> jgarzik: you haven't been here for months &
198 2012-04-14 23:18:33 <jgarzik> sipa: to getmemorypool?
199 2012-04-14 23:18:40 <sipa> yes, certainly
200 2012-04-14 23:18:54 <sipa> but we can't drop it just yet
201 2012-04-14 23:19:01 <jgarzik> not for a while yet
202 2012-04-14 23:19:03 <luke-jr> jgarzik: *nobody* uses getwork anymore. the hashrate required to solo mine is higher than what bitcoind can handle.
203 2012-04-14 23:19:25 <sipa> some pools use heavily patched bitcoinds still
204 2012-04-14 23:19:29 <jgarzik> yes
205 2012-04-14 23:19:37 <luke-jr> sipa: not 0.5+ afaik
206 2012-04-14 23:21:29 <luke-jr> anyhow, this line of discussion isn't getting anywhere
207 2012-04-14 23:21:49 <luke-jr> if jgarzik wants to make all the JSON-RPC calls threadsafe, that's clearly the better solution
208 2012-04-14 23:24:06 <sipa> that should not be hard
209 2012-04-14 23:24:18 <luke-jr> maybe. I admit I didn't even attempt it.
210 2012-04-14 23:24:38 <sipa> start by making them all take cs_main and cs_wallet
211 2012-04-14 23:24:49 <sipa> except the obvious ones
212 2012-04-14 23:25:04 <luke-jr> well, that was more or less what my ThreadSafeRPC functions did :P
213 2012-04-14 23:25:26 <sipa> right, but it does belong in the rpc functions
214 2012-04-14 23:25:29 <luke-jr> but that's not making them threadsafe, it's just providing a temporary migration path
215 2012-04-14 23:25:42 <sipa> or even better, in the actual code
216 2012-04-14 23:25:58 <sipa> when everything is properly encapsulated
217 2012-04-14 23:28:31 <sipa> 1912 called; they want Titanic back
218 2012-04-14 23:28:42 <luke-jr> O.o
219 2012-04-14 23:29:16 <sipa> (sank 100 years and 10 minutes ago)
220 2012-04-14 23:29:19 <sipa> 11
221 2012-04-14 23:29:45 <luke-jr> o
222 2012-04-14 23:30:01 <luke-jr> are we going to be doing this anniversary thing with 9/11 too?
223 2012-04-14 23:31:06 <jgarzik> sipa: most of the RPC calls should already be thread-safe.  comments in the patch and from Back When seemed to indicate getwork was the main problem.  Likely solution is simply (1) I'll review the RPC calls for thread safety and (2) add LOCK() to getwork