1 2012-06-30 00:14:13 <gribble> New news from bitcoinrss: jgarzik opened pull request 1538 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1538>
  2 2012-06-30 00:24:00 <antkingtube> hey fags
  3 2012-06-30 00:24:05 <antkingtube> did you read my latest post
  4 2012-06-30 00:24:09 <antkingtube> on bitcoin shitheads.org
  5 2012-06-30 00:24:10 <antkingtube> it said
  6 2012-06-30 00:24:13 <antkingtube> go fuck yourselves
  7 2012-06-30 00:24:16 <antkingtube> because you suck penis
  8 2012-06-30 00:24:17 <antkingtube> !!!
  9 2012-06-30 00:24:18 <gribble> Error: "!!" is not a valid command.
 10 2012-06-30 00:24:20 <antkingtube> isn't it great
 11 2012-06-30 00:24:26 <antkingtube> you shitheads
 12 2012-06-30 00:24:28 <antkingtube> sucking dick
 13 2012-06-30 00:24:31 <antkingtube> for life!!!
 14 2012-06-30 00:24:34 <antkingtube> I'm so great
 15 2012-06-30 00:24:47 <antkingtube> k thx
 16 2012-06-30 00:24:52 <antkingtube> for all the great times
 17 2012-06-30 00:24:56 <antkingtube> with me and n0n00dz
 18 2012-06-30 00:25:01 <antkingtube> and all you penis suckers
 19 2012-06-30 00:25:13 <antkingtube> and gmaxwell
 20 2012-06-30 00:25:17 <antkingtube> the penis sucking fat man
 21 2012-06-30 00:25:18 <antkingtube> wow
 22 2012-06-30 00:25:20 <antkingtube> that guy is great
 23 2012-06-30 00:25:26 <antkingtube> the shit head said and I qoute
 24 2012-06-30 00:25:35 <antkingtube> n0n00dz4u has the tastiest penis in bitcoin
 25 2012-06-30 00:25:37 <antkingtube> thats a fact
 26 2012-06-30 00:25:44 <antkingtube> he even offered to blow me for free
 27 2012-06-30 00:25:48 <antkingtube> I'm so great
 28 2012-06-30 00:25:50 <antkingtube> lol
 29 2012-06-30 00:40:40 <gmaxwell> There were no managers of the bitcoin project on ohloh. I added myself so I could fix the URL. Though now its saying "this project is managed by Gregory Maxwell", which wasn't the intended result.
 30 2012-06-30 00:40:54 <luke-jr> lol
 31 2012-06-30 00:40:58 <luke-jr> what's ohloh? <.<
 32 2012-06-30 00:41:29 <gmaxwell> luke-jr: see https://www.ohloh.net/p/bitcoin
 33 2012-06-30 00:41:41 <gmaxwell> basically a site that scrapes SCMs and posts stats.
 34 2012-06-30 00:42:05 <luke-jr> wow, our LOC shot up this year
 35 2012-06-30 00:42:15 <gmaxwell> It's kinda sucky but it does some useful stuff like that.
 36 2012-06-30 01:55:00 <freewil> ohloh... ohhh stats and graphs oh my
 37 2012-06-30 06:37:23 <gribble> New news from bitcoinrss: cardpuncher opened pull request 1539 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1539>
 38 2012-06-30 07:07:59 <gribble> New news from bitcoinrss: fanquake opened pull request 1540 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1540>
 39 2012-06-30 09:11:07 <cardpuncher> Hi. I think I spotted a missing plural form in bitcoin_en.ts and while fixing it I started to wonder whether it would make sense to add plural forms for strings like "<source>Offline (%1 confirmations)</source>".
 40 2012-06-30 09:12:07 <cardpuncher> In fact, stuff related to the number of confirmations doesn't seem to have plural forms. Would adding them on bitcoin_en.ts make sense? (If so, I can submit a pull request)
 41 2012-06-30 09:12:24 <Diapolo> cardpuncher: So you are creating a patch for this? You know you have to create base translations for plurals in the en master file via the Qt Linguist right?
 42 2012-06-30 09:13:48 <cardpuncher> Diapolo: I am playing with bitcoin_en.ts with gedit right now. Adding the plural forms to that file and then running lupdate seems to update correctly other translations.
 43 2012-06-30 09:14:37 <Diapolo> You have to ensure in the source via tr() that plurals are used, then with lupdate the master file is updated but has to be editted with Qt Linguist afterwards.
 44 2012-06-30 09:29:51 <Diapolo> cardpuncher: I'm off now, you can create the pull and I will fore sure take a look and comment :). E.g. take a look how "progressBar->setFormat(tr("~%n block(s) remaining", "", nRemainingBlocks));" is listed in the en master file.
 45 2012-06-30 11:32:05 <gribble> New news from bitcoinrss: Goonie opened pull request 45 on bitcoin/bitcoin.org <https://github.com/bitcoin/bitcoin.org/pull/45>
 46 2012-06-30 11:43:45 <Diapolo> We have a small glitch with translations and the splash screen, it's too small for certain languages. We could resize the current one, which lowers it's quality or perhaps use a new one until we get rid of it. I'm no artist, but take a look here: http://i50.tinypic.com/2i8zoli.jpg
 47 2012-06-30 11:52:58 <gribble> New news from bitcoinrss: Diapolo opened issue 1541 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1541>
 48 2012-06-30 11:53:14 <cardpuncher> In all cases your image seems better to me than the one I created by resizing the existing splash picture.
 49 2012-06-30 11:56:22 <Diapolo> perhaps I should open a pull to get more feedback on this ... it's rather quiet in here currently :)
 50 2012-06-30 11:58:18 <cardpuncher> More feedback? Well, just use a photo of Paris Hilton and see what happens :p
 51 2012-06-30 12:01:02 <Diapolo> ^^ good idea
 52 2012-06-30 12:07:07 <Diapolo> cardpuncher: I commented on the button issue, did you try it out already?
 53 2012-06-30 12:08:17 <gribble> New news from bitcoinrss: Diapolo opened pull request 1542 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1542>
 54 2012-06-30 12:08:37 <cardpuncher> I was struggling with a translation, give me a sec to read the comment.
 55 2012-06-30 12:09:00 <Diapolo> sure
 56 2012-06-30 12:09:54 <tcatm> I don't like the proposed splash sceen. It looks a lot less polished than the old one...
 57 2012-06-30 12:11:15 <Diapolo> that is fine as I said I'm no artist ... was fun to play with it though
 58 2012-06-30 12:11:20 <tcatm> Have you considered making the text two lines  for longer messages?
 59 2012-06-30 12:11:56 <Diapolo> tcatm: I didn't have that idea, but that would be an easy fix I guess.
 60 2012-06-30 12:12:42 <Diapolo> btw. the blurry-ness comes from a blur filter
 61 2012-06-30 12:16:32 <cardpuncher> Diapolo: modifying <width>720</width> and <height>360</height> in a text editor also does it, right?
 62 2012-06-30 12:17:34 <Diapolo> cardpunher: yes that should work
 63 2012-06-30 12:17:46 <Diapolo> cardpuncher: yes that should work
 64 2012-06-30 12:18:52 <Diapolo> seems there is no option included to tell QSplashScreen to word-wrap the messages :-/.
 65 2012-06-30 12:20:43 <cardpuncher> Diapolo: compiled, here's the result on my side: http://ompldr.org/vZWtkZg  I'd say like ten more pixels for the width.
 66 2012-06-30 12:21:57 <Diapolo> Try what would be the best width ... but don't let it grow larger than the base window I would say. A patch for this is really easy.
 67 2012-06-30 12:30:04 <cardpuncher> Diapolo: 760 * 380 seems good -- it was like 40 more pixels rather than 10 but hey, you asked a nearsighted :p
 68 2012-06-30 12:30:59 <Diapolo> tcatm: Is this better http://i50.tinypic.com/o6bev4.jpg? Or do you dislike the used graphics in general?
 69 2012-06-30 12:31:21 <Diapolo> cardpuncher: I'll see how that looks for non french users ^^
 70 2012-06-30 12:32:14 <Diapolo> http://i50.tinypic.com/o6bev4.jpg without ? at the end ^^
 71 2012-06-30 12:33:04 <cardpuncher> The result in French is the following: http://bayimg.com/maPmeaAdg
 72 2012-06-30 12:33:42 <Diapolo> so it nearly hides the main window then?
 73 2012-06-30 12:34:54 <Diapolo> ah sorry thats only the address selection window ^^ how does it look when base window is visible behind ... is it still taller?
 74 2012-06-30 12:35:05 <tcatm> I don't think we should change the splash image just like that. It helps people recognize bitcoin-qt.
 75 2012-06-30 12:36:00 <luke-jr> Diapolo: sizes should not be measured in pixels
 76 2012-06-30 12:36:26 <Diapolo> luke-jr: -_- tell me which unit is used all over Bitcoin-Qt? miles?
 77 2012-06-30 12:36:59 <luke-jr> Diapolo: ex exists for this purpose
 78 2012-06-30 12:37:19 <luke-jr> Diapolo: pixels is just asking for sizing issues
 79 2012-06-30 12:37:47 <Diapolo> luke-jr: Nice input, but that should have been raised in the beginning of the Qt switchover, no?
 80 2012-06-30 12:37:51 <luke-jr> some people have fonts size 7pt, some have 20pt if they're partially blind :p
 81 2012-06-30 12:38:02 <luke-jr> maybe. I don't know how the window is sized now
 82 2012-06-30 12:38:31 <Diapolo> luke-jr: I know from former HTML experiences, that pixels is bad, but I'm not the one currently willing to rework all the code who uses px ;).
 83 2012-06-30 12:40:03 <Diapolo> you are free to start a discussion by opening an issue ticket
 84 2012-06-30 12:42:51 <cardpuncher> Diapolo: here's a screenshot of my desktop with the main window and the resized window: http://bayimg.com/MaPMMAADg
 85 2012-06-30 12:44:53 <Diapolo> cardpuncher: that is looking good, if you want open a pull for it and link to that screenshot :) I'm sure wumpus will accept it and I ACK this too.
 86 2012-06-30 12:45:14 <Diapolo> Have to go now, see you.
 87 2012-06-30 13:43:26 <DBordello> When I start bitcoin-qt I get this error: http://i.imgur.com/XcYJr.png  Ideas?
 88 2012-06-30 13:44:03 <DBordello> I am pretty confident bitcoin wasn't shutdown properly last time
 89 2012-06-30 13:48:53 <DBordello> well, time to resync
 90 2012-06-30 14:32:25 <gribble> New news from bitcoinrss: cardpuncher opened pull request 1543 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1543>
 91 2012-06-30 14:51:10 <gmaxwell> hmph. can't gettransaction on the coinbase of an orphaned block.
 92 2012-06-30 17:57:00 <jgarzik> bitcointalk's "watch" feature is very nice
 93 2012-06-30 17:57:15 <jgarzik> it took how many years to get a 'subscribe' feature going?  :)
 94 2012-06-30 18:07:35 <hattorihanzo> Can someone help explain how the keypool works, and the best way to manage more wallets than the keypool size
 95 2012-06-30 18:10:28 <jgarzik> hattorihanzo: whenever you send out money, you may need a new private key for any "change" that may exist from breaking a bitcoin into pieces.  the keypool is a reserve of those keys.
 96 2012-06-30 18:10:54 <jgarzik> hattorihanzo: the keypool is useful in case you lose your most recent wallet backup...  an older backup may still have keys used since then
 97 2012-06-30 18:19:53 <hattorihanzo> is there much of performance hit making the keypool 1k...10k.. in size?
 98 2012-06-30 18:20:07 <hattorihanzo> default is 100 IIRC
 99 2012-06-30 18:21:37 <gmaxwell> I think I have my online wallet set to 10000, never noticed an issue with it.
100 2012-06-30 18:23:15 <hattorihanzo> so, if I use the first bitcoin address the client generates for me, do X (where x > keypool) transactions
101 2012-06-30 18:23:30 <hattorihanzo> will the first address be deleted?
102 2012-06-30 18:30:04 <jgarzik> hattorihanzo: nothing is deleted.  the oldest address is used, IIRC
103 2012-06-30 18:30:08 <jgarzik> oldest unused
104 2012-06-30 18:45:45 <hattorihanzo> are there any patches for rpc based wallet privkey import/export?
105 2012-06-30 18:48:28 <BlueMatt> you dont need a patch
106 2012-06-30 18:49:32 <hattorihanzo> well damn, i never noticed dump and import, when were those added?
107 2012-06-30 18:50:05 <hattorihanzo> doesnt matter, thanks for the hlep
108 2012-06-30 18:50:10 <hattorihanzo> s/help
109 2012-06-30 20:55:43 <luke-jr> why is .bitcoin 9 GB+?
110 2012-06-30 21:40:27 <jine> 00:55:43 < luke-jr> why is .bitcoin 9 GB+?
111 2012-06-30 21:40:38 <jine> luke-jr: Cause you injected shitloads of crappy religious stuff?
112 2012-06-30 21:44:29 <upb> HAHAHAHHAHAHA
113 2012-06-30 21:44:30 <upb> so true
114 2012-06-30 21:45:53 <jine> Such a stupid question, especially from luke-jr himself.
115 2012-06-30 21:50:57 <ali1234> so ages ago there was talk about a kind of hardware wallet for btc, where you have a small device with just a screen and eg USB connection
116 2012-06-30 21:51:19 <ali1234> it would store the private key, but the key cannot be read out, and when you do a TX it displays it on the screen with "yes/no" buttons, and returns the signed results to the PC which sends it on to the network
117 2012-06-30 21:51:41 <ali1234> what is the current status of that work? does any btc client have support for that kind of system yet?
118 2012-06-30 21:56:30 <ali1234> i ask because i have an old smartphone with a half finished linux port. the screen, keyboard and usb works but that's about it. it's no use as a phone but would be perfect for this, and it's just sitting unused on my desk.
119 2012-06-30 21:57:12 <jine> Well, there is bitcoin clients (both full clients and thiny ones) for that might work on your phone.
120 2012-06-30 21:57:27 <jine> I have no idea about the status for such a project tho, haven't seen anything public about it (as a pressrelease or similar)
121 2012-06-30 21:58:45 <ali1234> thin client would be a start, but i would want to integrate it with a PC side full client
122 2012-06-30 21:59:38 <ali1234> the phone would only be needed when something needed to be signed with the private key. i would want to keep the USB protocol as simple as possible to avoid bugs, and have no other network connections at all (since they don't work anyway)
123 2012-06-30 22:03:25 <ali1234> actually bluetooth works as well, that could be interesting
124 2012-06-30 22:16:10 <jrmithdobbs> ali1234: why even bother? do it over a tls encrypted/authenticated tcp connection from the get go and you get all the same functionality without the wire snooping and driver/hid wrapper writing
125 2012-06-30 22:16:38 <jrmithdobbs> ali1234: usb is not a secure bus and can be sniffed by other devices on it
126 2012-06-30 22:17:33 <ali1234> it doesn't matter
127 2012-06-30 22:17:39 <ali1234> the key will never be sent over the usb bus
128 2012-06-30 22:17:46 <ali1234> so there is nothing to snoop
129 2012-06-30 22:18:55 <ali1234> instead the message digest would be sent, and then the signature would be returned
130 2012-06-30 22:19:04 <ali1234> and that's all public information that goes in the blockchain
131 2012-06-30 22:19:27 <jgarzik> hrm
132 2012-06-30 22:19:40 <jgarzik> has anyone yet written a python interpreter for bitcoin scripts?
133 2012-06-30 22:22:31 <jrmithdobbs> jgarzik: i think either genjix or phantom have a partial one somewhere
134 2012-06-30 22:22:47 <jgarzik> phantomcircuit: ^
135 2012-06-30 22:23:18 <jrmithdobbs> don't know how complete, doesn't libbitcoin have py bindings though? that good enough?
136 2012-06-30 22:23:21 <phantomcircuit> jgarzik, i have one but there's a ton of bugs i just dont care to fix
137 2012-06-30 22:24:44 <jrmithdobbs> I have a weird question
138 2012-06-30 22:25:10 <jgarzik> hrm
139 2012-06-30 22:25:33 <jrmithdobbs> so i was going through the udacity.com crypto course thing to see what their stuff was like and the guy covers bitcoin (very briefly at very high level, in fact he gets scripts/coin xfer completely wrong ...)
140 2012-06-30 22:25:46 <jrmithdobbs> and he made a couple statements that I don't agree with and wanted opinions ;p
141 2012-06-30 22:27:00 <jrmithdobbs> eg, re: sha256(sha256()) he says the only justification was to make the POW "more" work specifically saying that preventing pre-image/collision issues is not the reasons for it. I know those two properties *are* a benefit we've seen vs certain possible attacks ....
142 2012-06-30 22:27:44 <jrmithdobbs> but was that the original reason? It seems it's unnecessary for that specific reason since you can just change the diff adjust alg to account for 2x as many blocks per interval, for instance
143 2012-06-30 22:28:48 <jrmithdobbs> thoughts/comments?
144 2012-06-30 22:30:27 <ali1234> ah, it looks like armory has most of what i need
145 2012-06-30 22:33:20 <phantomcircuit> jgarzik, https://github.com/phantomcircuit/bitcoin-alt
146 2012-06-30 22:33:27 <phantomcircuit> there's a bug with the block organization
147 2012-06-30 22:33:36 <phantomcircuit> but other than that it mostly works
148 2012-06-30 22:34:23 <jrmithdobbs> noone? really? ;p
149 2012-06-30 22:38:22 <ali1234> jrmithdobbs: wait, how does hashing twice prevent collisions?
150 2012-06-30 22:38:22 <jgarzik> phantomcircuit: building my own block reorg handling, just hoping to avoid reinventing the script bits
151 2012-06-30 22:38:57 <phantomcircuit> jgarzik, someone else had done the scripting in python
152 2012-06-30 22:39:06 <phantomcircuit> there are a ton of very subtle mistakes you can make though
153 2012-06-30 22:39:16 <phantomcircuit> so reading through the mainline code is very important
154 2012-06-30 22:39:27 <phantomcircuit> and of course always err on the side of rejecting
155 2012-06-30 22:39:44 <jrmithdobbs> ali1234: because colliding the single hash is already difficult, having to go through 2 iterations is statistically harder
156 2012-06-30 22:39:55 <jgarzik> phantomcircuit: bitcoin.script seems reasonably self-contained
157 2012-06-30 22:40:31 <jrmithdobbs> ali1234: or rather, the probability of their being an issue which can be carried through multiple iterations is lower than one that one be able affect a single iteration
158 2012-06-30 22:41:00 <ali1234> ok. but it doesn't prevent accidental collisions at all. maybe that's what he meant?
159 2012-06-30 22:41:36 <jrmithdobbs> oh well sure, it doesn't prevent accidental collisions but the comment was in the context of security model / blockchain structure
160 2012-06-30 22:42:42 <jrmithdobbs> ali1234: it does, on the other hand, prevent the length extension we know that sha2 is theorhetically weak against
161 2012-06-30 22:44:27 <jrmithdobbs> (once anyone is actually able to show a collision, anyways)
162 2012-06-30 22:44:44 <ali1234> what about hash chains?
163 2012-06-30 22:45:01 <jrmithdobbs> what about them?
164 2012-06-30 22:45:25 <ali1234> if you used that type of attack and found a collision for sha256(x), then the collision for sha256(sha256(x)) is just the previous number in the chain
165 2012-06-30 22:51:59 <jrmithdobbs> ali1234: not exactly ... you do know that there are, for instance, reduced round attacks on aes, right? It's a similar situation, just because you can perform the attack through x number of iterations doesn't mean you can through y at the same cost/benefit
166 2012-06-30 22:55:12 <jrmithdobbs> ali1234: so say there is a sha2 attack that successfully reduces the search to 2^50-60ish (the pratical, but still hard range), that would leave sha256(sha256()) at about 2^90-100+ which is still quite infeasible
167 2012-06-30 22:55:19 <jrmithdobbs> ali1234: https://bitcointalk.org/index.php?topic=45456.0;wap2 basically
168 2012-06-30 23:05:56 <luke-jr> jine: no u troll
169 2012-06-30 23:07:35 <gmaxwell> luke-jr: figure out what happened to your bitcoin directory?
170 2012-06-30 23:08:12 <gmaxwell> luke-jr: I assume you had a 7GB debug.log?
171 2012-06-30 23:11:48 <ali1234> jrmithdobbs: if you have an attack that reduces upper bound for a single collision to 2^60 then calculations required for double-hash is 2^61, no?
172 2012-06-30 23:15:40 <jrmithdobbs> ali1234: important part of that is near the bottom
173 2012-06-30 23:15:45 <jrmithdobbs> ali1234: "Finding collisions is irrelevant for bitcoin, you need to find partial preimage to extend the blockchain, or 2nd-preimage to replace a non-recent block in the blockchain (in the old thread Satoshi mentioned adding extra field with new hash function to blocks, in case 2nd-preimage attack on sha256 becomes practical)."
174 2012-06-30 23:16:41 <ali1234> ok, well replace "collision" with "preimage" in what i said...
175 2012-06-30 23:18:13 <galambo> it doesnt really matter because after its on everyones block chain you cant substitute the merkle root as well
176 2012-06-30 23:18:37 <galambo> to add extra transactions or whatever you're planning
177 2012-06-30 23:20:00 <jrmithdobbs> ali1234: yes, you're right, i think
178 2012-06-30 23:20:16 <ali1234> i think the guy talking about collisions really meant to say preimage anyway
179 2012-06-30 23:20:20 <jrmithdobbs> ali1234: so the distinction for bitcoin matters since it's not the same kind of search
180 2012-06-30 23:20:25 <jrmithdobbs> ya
181 2012-06-30 23:20:50 <jrmithdobbs> so he was right re: collisions then
182 2012-06-30 23:21:15 <jrmithdobbs> but definitely wrong re: pre-image resistance at the same time
183 2012-06-30 23:21:23 <jrmithdobbs> or possibly, anyways
184 2012-06-30 23:23:12 <jrmithdobbs> ok, i see the origins now
185 2012-06-30 23:23:15 <ali1234> if you have z = sha256(y=sha256(x)) and you can compute y in n attacks, then you can compute y and then use it to compute z in another n attacks, ie 2n in total, not n^2.
186 2012-06-30 23:23:18 <jrmithdobbs> http://crypto.stackexchange.com/questions/779/hashing-or-encrypting-twice-to-increase-security
187 2012-06-30 23:24:17 <ali1234> and yes, hash(x) = hash(y) implies hash(hash(x) = hash(hash(y)) - which is why i said it doesn't prevent accidental collisions at all
188 2012-06-30 23:24:41 <jrmithdobbs> so it protects against first (but not second) pre-image sometimes but mostly against length extension
189 2012-06-30 23:26:23 <ali1234> it doesn't really protect against either very much afaict
190 2012-06-30 23:27:07 <ali1234> if either is feasible for a single hashing then it's feasible for two as well
191 2012-06-30 23:27:28 <jrmithdobbs> eventually, but not necessarily immediately
192 2012-06-30 23:27:35 <ali1234> unless it's right on the cusp of feasibility
193 2012-06-30 23:27:44 <ali1234> like you're willing to wait 10 years but not 20
194 2012-06-30 23:27:55 <jrmithdobbs> which would theorhetically give you time to switch out primitives in the protocol
195 2012-06-30 23:28:12 <jrmithdobbs> s/would/could/
196 2012-06-30 23:29:07 <jrmithdobbs> (besides the fact that you need to break it well enough to fake merkle trees if you want to do anything interesting without having to create blocks)
197 2012-06-30 23:30:30 <jrmithdobbs> or if you can collide in <10min 1% or more of the time
198 2012-06-30 23:30:40 <jrmithdobbs> at that point it falls apart of course
199 2012-06-30 23:31:05 <jrmithdobbs> not even 1%
200 2012-06-30 23:31:41 <ali1234> doubling the complexity is not going to buy you much time
201 2012-06-30 23:32:05 <luke-jr> gmaxwell: yep
202 2012-06-30 23:32:14 <galambo> i think the greatest threat is from integer overruns (the only successful exploit so far)
203 2012-06-30 23:32:40 <luke-jr> gmaxwell: it's too bad Linux doesn't have some kind of special log file type that just saves the last n MB
204 2012-06-30 23:36:21 <JFK911> logs belong in databases anyway
205 2012-06-30 23:36:33 <luke-jr> um, no thanks
206 2012-06-30 23:36:47 <JFK911> youve never handled serious logs before.
207 2012-06-30 23:37:04 <luke-jr> sure I have
208 2012-06-30 23:37:07 <gmaxwell> Yea ... no kidding.  In any case, every other daemon manages to have rotatable logs without issue.
209 2012-06-30 23:37:20 <luke-jr> gmaxwell: bitcoind has log rotation on Gentoo :P
210 2012-06-30 23:37:45 <jrmithdobbs> gmaxwell: svlogd
211 2012-06-30 23:37:45 <luke-jr> I was just thinking, instead of having it cut at a random line
212 2012-06-30 23:38:09 <jrmithdobbs> gmaxwell: because no, they don't, so much crap software re: log rotation
213 2012-06-30 23:38:35 <jgarzik> bitcoind reopens on SIGHUP now.  easy log rotation.
214 2012-06-30 23:38:39 <luke-jr> sadly, jrmithdobbs is right when it comes to using syslog
215 2012-06-30 23:39:00 <luke-jr> syslog with debug-level detail can really kill performance
216 2012-06-30 23:39:33 <EricLombrozo> is there a fee anomaly in block 0000000000000600498a139cfff8940a434e2351c418f8fd566236535b487ddd ?
217 2012-06-30 23:40:00 <EricLombrozo> the miner is claiming .1341 BTC in fees but I'm adding up a total of .1346 BTC
218 2012-06-30 23:40:12 <luke-jr> ouch
219 2012-06-30 23:40:13 <EricLombrozo> I have two questions:
220 2012-06-30 23:40:19 <EricLombrozo> 1) is my calculation wrong?
221 2012-06-30 23:40:31 <EricLombrozo> and 2) what happens if the miner claims less in fees than is entitled to?
222 2012-06-30 23:40:34 <gmaxwell> EricLombrozo: nothing requires a miner to claim all the value.
223 2012-06-30 23:40:42 <gmaxwell> And people have intentionally claimed lets in the past.
224 2012-06-30 23:40:52 <EricLombrozo> so the bitcoins just vanish?
225 2012-06-30 23:41:03 <gmaxwell> Yes.
226 2012-06-30 23:41:22 <EricLombrozo> so in principle there could be less than 21 million bitcoins in the end
227 2012-06-30 23:41:28 <luke-jr> there will be
228 2012-06-30 23:41:34 <gmaxwell> EricLombrozo: There always would be less than 21 million.
229 2012-06-30 23:42:10 <luke-jr> EricLombrozo: if it's really off, that suggests a bug in Eloipool :|
230 2012-06-30 23:42:13 <gmaxwell> 21 million is the limit as time goes to infinity and it would even underrun that because the coin precision is finite.
231 2012-06-30 23:42:17 <luke-jr> EricLombrozo: care to help find it?
232 2012-06-30 23:42:20 <EricLombrozo> the geometric series converges on 21 million if we assume satoshis are infinitely divisible
233 2012-06-30 23:42:35 <EricLombrozo> but since satoshis are indivisible, we get less than 21 million
234 2012-06-30 23:42:38 <jgarzik> hrm
235 2012-06-30 23:42:39 <luke-jr> EricLombrozo: http://gitorious.org/bitcoin/eloipool
236 2012-06-30 23:42:42 <jgarzik> that's... odd
237 2012-06-30 23:42:43 <jgarzik> receive version message: version 31800, blocks=186970, us=127.0.0.1:8333, them=127.0.0.1:8333, peer=81.106.112.56:54136
238 2012-06-30 23:42:46 <jgarzik> 127.0.0.1?
239 2012-06-30 23:43:15 <jgarzik> receive version message: version 60000, blocks=186975, us=0.0.0.0:0, them=0.0.0.0:0, peer=77.247.181.165:13805
240 2012-06-30 23:43:26 <jrmithdobbs> gmaxwell: http://pastebin.com/kT7XPfVh
241 2012-06-30 23:43:46 <gmaxwell> jgarzik: current nodes send 0:0 when they don't know a routable IP for themselves.
242 2012-06-30 23:44:04 <jgarzik> gmaxwell: hopefully we check for non-routeable addresses and not just 0.0
243 2012-06-30 23:44:05 <jrmithdobbs> jgarzik: this is much easier because svlogd lets you rotate on size/time/etc
244 2012-06-30 23:44:18 <jrmithdobbs> jgarzik: nice that logrotate will work now tho
245 2012-06-30 23:44:27 <EricLombrozo> so if someone wanted to destroy a bunch of bitcoins, they could mine a two transaction block where the second transaction spends everything on fees and the first transaction (generation transaction) claims nothing
246 2012-06-30 23:44:41 <gmaxwell> jgarzik: We do everywhere we'd need to check, though those particular messages don't do anything important today.
247 2012-06-30 23:45:20 <gmaxwell> EricLombrozo: or they could forward coins to 1BitcoinEaterAddressDontSendf59kuE and save all the mining trouble.
248 2012-06-30 23:45:33 <EricLombrozo> or right - they could send it to a black hole address
249 2012-06-30 23:45:54 <gmaxwell> Or write an unredeemable script.
250 2012-06-30 23:45:57 <jrmithdobbs> there's already lots of lost coins
251 2012-06-30 23:46:04 <jgarzik> "version" : 31800,
252 2012-06-30 23:46:08 <jgarzik> so the weirdos are bitcoinj
253 2012-06-30 23:46:11 <jgarzik> thank you getpeerinfo
254 2012-06-30 23:46:14 <EricLombrozo> but there's a difference - an unredeemable script still shows an amount in the block chain
255 2012-06-30 23:46:28 <Karmaon> Does anyone know how I would determine which pool a block header submitted by a miner is valid for?
256 2012-06-30 23:46:33 <jrmithdobbs> EricLombrozo: there's even some not-fully-redeemed coinbase transactions in some blocks
257 2012-06-30 23:46:33 <Karmaon> for example, a miner doing round robin.
258 2012-06-30 23:46:51 <gmaxwell> EricLombrozo: Thats a distinction, for most purposes I don't know that there is a difference.
259 2012-06-30 23:46:51 <jrmithdobbs> EricLombrozo: as in, the 50/25 you get for finding the block
260 2012-06-30 23:47:26 <gmaxwell> jrmithdobbs: well, one. I don't think there is more than mindnightmagic's.
261 2012-06-30 23:47:36 <jrmithdobbs> gmaxwell: i thought there was 2
262 2012-06-30 23:47:44 <EricLombrozo> is there a good reason why the protocol shouldn't enforce exact calculation of coinbase and fees?
263 2012-06-30 23:47:58 <gmaxwell> There are two that destroy coin by virtue of having duplicate coinbases.
264 2012-06-30 23:48:00 <jrmithdobbs> gmaxwell: thought luke or someone had a bug for like a couple hours
265 2012-06-30 23:48:03 <jgarzik> hrm
266 2012-06-30 23:48:09 <jrmithdobbs> oh ya, that was different
267 2012-06-30 23:48:10 <jgarzik> [jgarzik@eu3 ~]$ grep -c 'socket send buffer full warning' /spare/bitcoin/data/debug.log
268 2012-06-30 23:48:24 <gmaxwell> EricLombrozo: because it would be pointless?
269 2012-06-30 23:48:58 <jrmithdobbs> EricLombrozo: basically it's only going to happen because of software bugs or people being asshats (the midnightmagic block) ;p
270 2012-06-30 23:49:15 <gmaxwell> jrmithdobbs: asshats is the wrong word, it doesn't hurt anyone.
271 2012-06-30 23:49:32 <jgarzik> 524 / 5569 log lines in git HEAD are this send buffer warning
272 2012-06-30 23:49:36 <EricLombrozo> also, I am of the opinion that block height should be stored in the block headers and amounts should be stored in transaction inputs. it is a minimal cost in space for a significant improvement in performance and simplicity in code logic
273 2012-06-30 23:49:43 <jrmithdobbs> gmaxwell: no, he specifically did it because he wanted the total # of coins off by some .35149685207 random-ish number iirc
274 2012-06-30 23:49:50 <jrmithdobbs> gmaxwell: he's not an asshat, but that is asshatery
275 2012-06-30 23:49:53 <jrmithdobbs> heh
276 2012-06-30 23:50:05 <jgarzik> 805 / 5949
277 2012-06-30 23:50:15 <jrmithdobbs> midnightmagic: <3
278 2012-06-30 23:50:22 <gmaxwell> jrmithdobbs: he wanted to toss 1 satoshi to signify the absense of satoshi from bitcoin.
279 2012-06-30 23:50:43 <jrmithdobbs> close enough, still qualifies ;p
280 2012-06-30 23:50:46 <gmaxwell> But he goofed up and discarded 0.02000001 instead.
281 2012-06-30 23:51:44 <EricLombrozo> 8 additional bytes in the header, 8 additional bytes per input isn't going to add significantly to block sizes
282 2012-06-30 23:51:59 <jgarzik> 1547 / 6834
283 2012-06-30 23:52:03 <EricLombrozo> and it would make it far easier to reject malformed blocks
284 2012-06-30 23:52:05 <BlueMatt> jgarzik: hmm...well should probably not print that line unless fDebug then
285 2012-06-30 23:52:25 <jgarzik> BlueMatt: yeah, it's 99% of the log lines on this public node
286 2012-06-30 23:52:35 <EricLombrozo> besides, blocks can be compressed when stored on disk - and the block frequency isn't so high as to make it a bandwidth issue
287 2012-06-30 23:52:56 <gmaxwell> EricLombrozo: We will be putting the height in the coinbase txn. (where it will serve a useful purpose)
288 2012-06-30 23:52:58 <BlueMatt> jgarzik: hmm...probably wanna decrease default send buffer even further and not print that line
289 2012-06-30 23:53:18 <gmaxwell> EricLombrozo: putting values in the inputs doesn't help anything, because you'd still need to lookup the inputs to check the values.
290 2012-06-30 23:54:06 <EricLombrozo> gmaxwell, you still need to look up the inputs to verify values and check the scripts - but at least you could tentatively compute fees and see if they match what the miner claims...or if the miner claims an excess
291 2012-06-30 23:54:10 <gmaxwell> EricLombrozo: also, 8 bytes per input is a significant increase in transaction size.
292 2012-06-30 23:54:19 <jgarzik> BlueMatt: surely it will print that warning whenever it needs to throttle -- a normal occurence on a network?
293 2012-06-30 23:55:01 <BlueMatt> jgarzik: yep, or, more simply, whenever the remote node is downloading a bunch of blocks
294 2012-06-30 23:55:05 <EricLombrozo> starting when will the coinbase be storing height?
295 2012-06-30 23:55:15 <BlueMatt> s/simply/the most common one, Id think/
296 2012-06-30 23:55:20 <gmaxwell> EricLombrozo: If you're going to mine an invalid block you can happily set those high enough so that test passes and you don't fail until you look up the inputs. It achieves _nothing_ against a malicious party except increasing transaction size by 5% or so.
297 2012-06-30 23:56:11 <gmaxwell> EricLombrozo: most likely 0.7.0, though it won't be enforced as a rule until later.
298 2012-06-30 23:59:12 <jrmithdobbs> oh those run scripts remind me, need to rebuild and add onion transit