1 2012-04-18 00:11:28 <gribble> New news from bitcoinrss: gavinandresen opened pull request 1121 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1121>
  2 2012-04-18 02:57:14 <gribble> New news from bitcoinrss: dlitz opened pull request 1122 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1122>
  3 2012-04-18 07:36:26 <sneak> hi
  4 2012-04-18 07:36:38 <sneak> how does the bitcoin client find out the current block count?
  5 2012-04-18 07:36:49 <sneak> to give the little percentage synched display
  6 2012-04-18 07:40:24 <sirk390> sneak: there is a field called 'start_height" in the version message
  7 2012-04-18 07:41:12 <sirk390> sneak: this gives the last block received by the remote peer
  8 2012-04-18 07:41:26 <sneak> ahh, gotcha.
  9 2012-04-18 07:41:48 <sneak> thanks for the info! :)
 10 2012-04-18 07:42:04 <sirk390> you're welcome
 11 2012-04-18 09:41:55 <Rebroad> sipa, thanks for the help with git. now rebased
 12 2012-04-18 10:20:42 <random2> hello does anyone know if the bitcoinj java client supports a full client or is it limited?
 13 2012-04-18 10:23:50 <Joric> random2, it's not a full-node, it doesn't download/populate whole blocks, only headers
 14 2012-04-18 10:24:24 <Joric> multibit/bitcoinj is a parasite of the bitcoin world :)
 15 2012-04-18 10:25:11 <random2> my problem is im all java . is there a full java client?
 16 2012-04-18 10:26:19 <Joric> only bitcoinj afaik
 17 2012-04-18 10:26:28 <Joric> ie there's none
 18 2012-04-18 10:26:57 <random2> cpp here i come. oh well
 19 2012-04-18 10:27:01 <Joric> 'bitcoinj ??? A Java implementation of a Bitcoin client-only node'
 20 2012-04-18 11:04:22 <UukGoblin> https://github.com/goblin/chronobit
 21 2012-04-18 11:04:26 <UukGoblin> feedback welcome :-)
 22 2012-04-18 11:05:42 <luke-jr> UukGoblin: interesting; add it to BitGit :p
 23 2012-04-18 11:08:40 <gmaxwell> UukGoblin: holy crap, you used perl? :)
 24 2012-04-18 11:08:48 <gmaxwell> Why not brainf#@$@ ? :)
 25 2012-04-18 11:09:29 <UukGoblin> gmaxwell, I LIKE perl!
 26 2012-04-18 11:09:32 <UukGoblin> luke-jr, done
 27 2012-04-18 11:10:04 <Diablo-D3> predictinator's generator script is perl
 28 2012-04-18 11:28:04 <[Tycho]> Why use coinbase for this, when you can just submit a TX ?
 29 2012-04-18 11:28:55 <UukGoblin> [Tycho], actually, this should also be able to create proofs for a submitted TX. Basically a TX costs money, and people don't like "dodgy" transactions bloating up the bitcoin chain.
 30 2012-04-18 11:29:34 <UukGoblin> [Tycho], you'd either have to burn 0.0005 BTC forever (to an address that doesn't exist but is actually a hash), or create a 0-valued output and get a miner to include it
 31 2012-04-18 11:29:36 <[Tycho]> So adding data to coinbase is not bloating ?
 32 2012-04-18 11:30:14 <UukGoblin> [Tycho], I'm not adding anything to the coinbase (assuming you're merged mining namecoins already)
 33 2012-04-18 11:30:17 <[Tycho]> 1) You aren't doing anything bad if you at least pay fees for your TX, 2) Don't burn money, use redeemable TXes.
 34 2012-04-18 11:30:39 <[Tycho]> Oh, merged mining...
 35 2012-04-18 11:30:44 <gmaxwell> [Tycho]: this adds no bloat, so it scales. Adding TXs doesn't scale.
 36 2012-04-18 11:30:44 <UukGoblin> [Tycho], I'm not saying it's bad, I'm saying some people don't like it
 37 2012-04-18 11:31:09 <[Tycho]> Well, I can say that merged mining bloats the blockchain :)
 38 2012-04-18 11:31:12 <[Tycho]> jk.
 39 2012-04-18 11:32:11 <UukGoblin> it kinda does, actually. :->
 40 2012-04-18 11:32:16 <gmaxwell> UukGoblin's system could commit to a trillion hashes, and it adds zero bytes.  (since it currently only works with p2pool, which is alredy merged mining you can't even say it adds 32 bytes/block ... but 32bytes a block would be pretty good for a trillion commitments)
 41 2012-04-18 11:34:21 <gmaxwell> The bad p2sh transaction is still circulating I see.
 42 2012-04-18 11:34:26 <[Tycho]> Adding one TX per each service providing timestamping is not too bad.
 43 2012-04-18 11:34:32 <[Tycho]> gmaxwell: where ?
 44 2012-04-18 11:35:15 <luke-jr> UukGoblin: would be nice if it wasn't p2pool-dependent tho ;P
 45 2012-04-18 11:40:26 <UukGoblin> luke-jr, well, normal pools don't link their shares
 46 2012-04-18 11:50:24 <gmaxwell> Interesting to see a block with an eligius style coinbase mining an invalid block: https://blockchain.info/block-index/208510
 47 2012-04-18 11:56:32 <DrHaribo> Why is it invalid?
 48 2012-04-18 12:03:04 <gmaxwell> DrHaribo: because it includes an invalid transaction.
 49 2012-04-18 12:03:23 <gmaxwell> (this one https://blockchain.info/tx-index/3618498/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2?show_adv=true )
 50 2012-04-18 12:04:12 <luke-jr> gmaxwell: Eligius-style how?
 51 2012-04-18 12:04:45 <DrHaribo> Wow, that tx has been included in a lot of blocks
 52 2012-04-18 12:04:50 <luke-jr> lol
 53 2012-04-18 12:06:00 <DrHaribo> What exactly is wrong with this tx?
 54 2012-04-18 12:06:02 <UukGoblin> DrHaribo, exactly what I just wanted to say
 55 2012-04-18 12:06:07 <UukGoblin> in a lot of orphaned blocks
 56 2012-04-18 12:06:11 <luke-jr> DrHaribo: it's invalid
 57 2012-04-18 12:06:30 <luke-jr> but valid under pre-BIP16 rules
 58 2012-04-18 12:06:31 <UukGoblin> there's either a bug somewhere or someone's been trying pretty hard to include it
 59 2012-04-18 12:06:45 <DrHaribo> Why it's invalid is what I wanted to know
 60 2012-04-18 12:06:46 <UukGoblin> ah, that's unsurprising, someone mining with an old bitcoind
 61 2012-04-18 12:06:49 <luke-jr> this is why miners without BIP16 support can't make blocks
 62 2012-04-18 12:07:04 <DrHaribo> Damn, someone lost a lot of BTC on this
 63 2012-04-18 12:07:05 <luke-jr> DrHaribo: it's basically an attempt to steal BIP16-sent funds
 64 2012-04-18 12:07:59 <DrHaribo> Hm, would it be an idea to have a bitcoind json-rpc call to validate a transaction?
 65 2012-04-18 12:08:00 <luke-jr> DrHaribo: due to how Bitcoin works, its existence pretty much guarantees non-BIP16-compliant miners will always produce invalid blocks
 66 2012-04-18 12:08:08 <luke-jr> DrHaribo: I've considered that.
 67 2012-04-18 12:08:11 <DrHaribo> So bitcoind could tell you if it is valid or not before you start hashing it
 68 2012-04-18 12:08:26 <luke-jr> DrHaribo: well, pre-BIP16 bitcoind would say this is valid :P
 69 2012-04-18 12:08:51 <DrHaribo> Yes, but in general.. currently I just use the exact txes I get with "getmemorypool"
 70 2012-04-18 12:09:03 <DrHaribo> Messing with it is a bit dangerous if you can't be sure a tx is valid
 71 2012-04-18 12:09:05 <luke-jr> the reason for a processtx JSON-RPC call would be to validate miner-provided transactions (GMP mining)
 72 2012-04-18 12:09:14 <UukGoblin> luke-jr, so that kinda shows us how much hashpower gets wasted on un-updated miners
 73 2012-04-18 12:09:41 <DrHaribo> GMP? new acronym?
 74 2012-04-18 12:09:41 <luke-jr> UukGoblin: yeah, might be nice to chart pre-BIP16 hashrate :p
 75 2012-04-18 12:09:46 <luke-jr> DrHaribo: GetMemoryPool
 76 2012-04-18 12:09:50 <DrHaribo> ah nvm :P
 77 2012-04-18 12:10:06 <gmaxwell> DrHaribo: you absoltely can't twiddle with the transactions just based on some validate call.. because transactions can conflict with each other.
 78 2012-04-18 12:10:07 <luke-jr> DrHaribo: Eligius serves it to end miners, for decentralized mining
 79 2012-04-18 12:10:24 <luke-jr> gmaxwell: ugh, you just made my life harder :P
 80 2012-04-18 12:10:24 <UukGoblin> you can see there was a lot of blocks on 2nd and 3rd of april
 81 2012-04-18 12:10:27 <UukGoblin> then just 2 on 4th and 3 on 5th
 82 2012-04-18 12:10:53 <luke-jr> maybe GMP isn't well-suited for mining :/
 83 2012-04-18 12:10:56 <DrHaribo> gmaxwell: damn, good point.. ok, how about "please tell me whether this list of txes makes a valid block"?
 84 2012-04-18 12:10:57 <luke-jr> or needs more extension
 85 2012-04-18 12:11:02 <gmaxwell> I mean a validate call could validate a _set_ but single txn wouldn't be safe.
 86 2012-04-18 12:11:12 <gmaxwell> DrHaribo: that would work.
 87 2012-04-18 12:11:13 <luke-jr> pool -> miner: GMP block template
 88 2012-04-18 12:11:15 <luke-jr> miner -> pool: GMP block proposal
 89 2012-04-18 12:11:19 <luke-jr> pool -> miner: ACK
 90 2012-04-18 12:11:25 <luke-jr> miner -> pool: header results
 91 2012-04-18 12:11:27 <gavinandresen> The best way to tell if a block is valid is to broadcast it and then see if more than 50% of the network builds on it....  :)
 92 2012-04-18 12:11:36 <gmaxwell> luke-jr: if you do that kind of set validation, you should also make it nak if the proposed block burns fees.
 93 2012-04-18 12:11:41 <luke-jr> gavinandresen: then you need to do the work first
 94 2012-04-18 12:12:18 <luke-jr> gmaxwell: hmm
 95 2012-04-18 12:12:32 <luke-jr> maybe ACK should allow revising the generation txn
 96 2012-04-18 12:13:15 <DrHaribo> Much less overhead if gen tx isn't included
 97 2012-04-18 12:13:48 <DrHaribo> (client can increase an extra-nonce without checking with you every time)
 98 2012-04-18 12:14:03 <gavinandresen> Anybody looking to do some productive busy-work?  I'
 99 2012-04-18 12:14:21 <gavinandresen> I'm looking for volunteers to expand the tests in:  https://github.com/bitcoin/bitcoin/pull/1121/files
100 2012-04-18 12:14:37 <luke-jr> gavin accidentally his enter key.
101 2012-04-18 12:14:44 <gavinandresen> no I did
102 2012-04-18 12:14:45 <gavinandresen> nt
103 2012-04-18 13:33:44 <banshee12> <banshee12> surely this is a scam
104 2012-04-18 13:33:45 <banshee12> <banshee12> http://www.youtube.com/watch?v=yAZSQO7BAkg
105 2012-04-18 13:35:16 <banshee12> luke-jr, gmaxwell: you guys heard of these?
106 2012-04-18 13:36:59 <Graet> i saw a forum post and lolled
107 2012-04-18 13:37:21 <banshee12> do you think people will fall for this?
108 2012-04-18 13:37:50 <banshee12> "here download this .exe on drop box... earn 3 times as much, it really works" lol
109 2012-04-18 13:37:54 <JFK911> amazing technology
110 2012-04-18 13:37:57 <banshee12> unbeleivable
111 2012-04-18 13:38:18 <Graet> yep, i download any random stuff from someone elses dropbox ;)
112 2012-04-18 13:38:36 <JFK911> worked great for wallet.dats
113 2012-04-18 13:38:44 <Graet> :P
114 2012-04-18 14:36:08 <gribble> New news from bitcoinrss: c00w opened issue 1123 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1123>
115 2012-04-18 14:37:45 <luke-jr> would be nice if the exception handling didn't break coredumping
116 2012-04-18 15:49:38 <ciscoftw> had a question regarding the way that bitcoind and long polling work... when i participate via pooled mining, my mining client (phoenix) reports 'LP: New Work pushed' even when a block has not been solved by the network (would make sense if the 'new work pushed' only occured when a block solved -but it doesnt) ...when i run bitcoind (with --server argument) i never see a 'LP: new work
117 2012-04-18 15:52:58 <luke-jr> bitcoind doesn't support longpolling at all, nor really mining directly anymore
118 2012-04-18 15:53:17 <ciscoftw> thanx for reponse, what are the mining pool operators useing?
119 2012-04-18 15:53:43 <luke-jr> Eloipool (Python), ecoinpool (Erlang), and PoolServerJ (Java) mainly
120 2012-04-18 15:53:51 <luke-jr> (in order of most maintained)
121 2012-04-18 15:53:56 <sipa> note that luke-jr is the author of eloipool
122 2012-04-18 15:54:07 <ciscoftw> :)
123 2012-04-18 15:54:51 <luke-jr> sipa: it's interesting how the other poolservers seem to fall off unmaintained fairly rapidly, though
124 2012-04-18 17:09:01 <ferroh> someone was recently asking me if there was a command to specify the location of the wallet in the satoshi client
125 2012-04-18 17:09:15 <ferroh> (but leave the blockchain on the disk)
126 2012-04-18 17:09:52 <ferroh> the reason is that he wanted to have his wallet on a usb key, but not the blockchain (since leaving the blockchain on the usb key basically renders the satoshi client unusable)
127 2012-04-18 17:10:26 <sipa> for now, no
128 2012-04-18 17:10:43 <ferroh> It seems like a good idea to me. Does anyone see a problem with having a flag that specifies the wallet location only?
129 2012-04-18 17:10:51 <ferroh> yeah, I know such a flag doesn't exist
130 2012-04-18 17:11:11 <ferroh> im wondering if you can think of any reason not to implement this.
131 2012-04-18 17:11:11 <sipa> no, but it's not that trivial to impleement
132 2012-04-18 17:11:32 <sipa> it would need a second database environment
133 2012-04-18 17:12:03 <sipa> not that hard, but we're considering moving away from bdb for the wallet entirely
134 2012-04-18 17:12:28 <ferroh> a hackish temp solution I suppose would be to just use a script that copies the wallet from the usb key before opening the client. That should work, right?
135 2012-04-18 17:12:47 <ferroh> what are the proposed database alternatives sipa?
136 2012-04-18 17:13:10 <sipa> textfile, own binary format, ...
137 2012-04-18 17:13:40 <sipa> there have been some ideas, but nothing implemented so far
138 2012-04-18 17:19:27 <seco> textfile makes it easy to print to paper after decryption of the wallet for offline usage :)
139 2012-04-18 17:22:09 <sipa> the problem is that different clients have a very different idea of what a wallet is
140 2012-04-18 17:22:52 <sipa> so i don't think compatible wallets is easily achievable, but maybe a common wallet interchange format...
141 2012-04-18 17:23:05 <seco> yep, but thats also something Open Document Format had at the beginnning...M$ still thinks different then most textprocessors :P
142 2012-04-18 17:23:35 <sipa> no, that's something very different; MS Office and OpenOffice at least agree on what a text document is
143 2012-04-18 17:23:57 <sipa> it's more like comparing .doc with .tex if you want an analogy with wallets
144 2012-04-18 17:24:17 <seco> mhm .doc is binary, .tex not
145 2012-04-18 17:24:52 <sipa> or .tex and .html
146 2012-04-18 17:25:07 <sipa> you can't just convert one to the other
147 2012-04-18 17:25:25 <seco> well im usability oriented sorry to sound sometimes dumb, but in many cases it has to be just "easy" usable at the end
148 2012-04-18 17:25:42 <sipa> right, but how do you deal with one program that uses deterministic wallets, and another that uses random generated keys?
149 2012-04-18 17:25:55 <sipa> you can't convert one to the other, in neither direction
150 2012-04-18 17:26:12 <sipa> even though the user interface may be very similar
151 2012-04-18 17:26:18 <seco> agree on printable keypairs of private and public keys :)
152 2012-04-18 17:26:40 <sipa> whatabout a printable deterministic wallet seed?
153 2012-04-18 17:26:58 <sipa> that's the equivalent on the other side
154 2012-04-18 17:27:02 <sipa> and actually much more useful than just printable keys
155 2012-04-18 17:27:25 <seco> if it doesnt fit to the other wallet struct, then simply call it "proprietary" :p
156 2012-04-18 17:27:58 <seco> like optional tags interpretated by each client different by tagname
157 2012-04-18 17:28:07 <sipa> i'll tell you what will happen if you try: you define a common format with some optional tags
158 2012-04-18 17:28:33 <sipa> but in the end no tool will really work well with the others, because none use the common tags, and all user their own proprietary tags
159 2012-04-18 17:28:54 <seco> yes, let everybody put whatevery they want into the optional tags
160 2012-04-18 17:29:19 <sipa> my point is that this only makes sense if programs agree on what a wallet is
161 2012-04-18 17:29:24 <sipa> and they don't
162 2012-04-18 17:29:27 <seco> i would just state by convention on all clients: everything there is not MUST have to use the wallet
163 2012-04-18 17:29:54 <sipa> i don't understand that
164 2012-04-18 17:32:40 <seco> i find printable private and public keys as universal for a text-wallet. everything else could just be put into an "other"-tag, and if clients do overwrite it (similar to X-Tag on email headers), its up to the clients to evaluate but coins MUST not be lost, because everbody agreed on using the bottom part of the wallet outside "other"-tag only for universal format of private and public keys
165 2012-04-18 17:32:53 <seco> i always try to find comparisons like ODF or this new css-specification i think it is, where they try to solve those problems of collaborating, or already solved it
166 2012-04-18 17:33:19 <seco> every browser has its own tags they interpret
167 2012-04-18 17:34:03 <sipa> right, but browsers agree on what a site is
168 2012-04-18 17:34:11 <seco> i think W3C simply put alltogether into some "other"-tag :p (well some containers like chrome-1, or firefox-10 or such)
169 2012-04-18 17:34:51 <seco> so this is something bitcoin should also, and i find printable textformat of private addresses VERY useful
170 2012-04-18 17:35:06 <seco> just my 2cents
171 2012-04-18 17:35:09 <sipa> will you make a backup after every transaction?
172 2012-04-18 17:35:15 <sipa> to paper?
173 2012-04-18 17:35:48 <sipa> just storing addresses/keys is not enough to prevent money loss, if clients for example sure different types of transactions built from them
174 2012-04-18 17:36:04 <forrestv> the solution is obvious: implement some kind of scripting language and make "wallets" just code that, when executed, generates a (possibly infinite) list of private keys
175 2012-04-18 17:36:08 <seco> i considered saving some coins to a special offline wallet, or 2to2 multisig address: why not removeing that address from wallet after the coins moved in and i printed it out
176 2012-04-18 17:36:42 <sipa> forrestv: that's the keys part; what about how transactions are created and stored, or marked spent?
177 2012-04-18 17:36:57 <sipa> what if there is specific logic necessary to detect which outputs are change or not
178 2012-04-18 17:37:18 <sipa> armory uses a heuristic for this, that depends on its deterministic key generation scheme
179 2012-04-18 17:37:30 <gavinandresen> that's easy, just make the scripting language c++ and have the user download an executable that... oh, wait.
180 2012-04-18 17:37:39 <sipa> gavinandresen: bingo :)
181 2012-04-18 17:37:46 <seco> xD
182 2012-04-18 17:37:49 <forrestv> hehe
183 2012-04-18 17:38:11 <sipa> my take on this: do not try to make clients agree on what a wallet is; only try to make a common interchange format that can be exported to and imported from
184 2012-04-18 17:39:22 <forrestv> my (more serious) recommendation: nobody here is a stranger to JSON
185 2012-04-18 17:39:24 <seco> just wanted to drag this definition to a "wallet", and the other one as "satoshiwallet"- , or "armorywallet"-file: in regards of the users
186 2012-04-18 17:39:26 <gavinandresen> yup.  If you want to move your bitcoins from one wallet to another, use the "send" button.  If you have a well-known bitcoin address... well, we should move away from "well known bitcoin addresses" anyway
187 2012-04-18 17:40:04 <sipa> gavinandresen: right! most bitcoin clients have this incredibly useful function that allows them to transfer money between them!
188 2012-04-18 17:41:00 <gavinandresen> ... and there's a nifty interchange format for them, too!  It even has a little scripting language in it!
189 2012-04-18 17:41:04 <sipa> no way?!
190 2012-04-18 17:41:09 <gavinandresen> totally!
191 2012-04-18 17:41:16 <sipa> awesome dude
192 2012-04-18 17:43:17 <seco> just in case i didnt get you right: moveing coins "offline" by transfer of private address in printable way, i still regard as a valid use case
193 2012-04-18 17:44:05 <sipa> me too; but that's very different from compatibility between entire wallets
194 2012-04-18 17:44:35 <seco> it gets important if someone wants to forbid bitcoin-communication: to transfer them via mail or such
195 2012-04-18 17:45:30 <gavinandresen> transfer bitcoins via mail?  You should do that by creating a transaction and then sending the transaction....
196 2012-04-18 17:46:18 <gavinandresen> private keys should remain private, when at all possible.
197 2012-04-18 17:46:47 <seco> that has the same purpose yes :)
198 2012-04-18 18:16:28 <ciscoftw> how exactly does 'long polling' increase efficiency? again, it totally makes sense to send a 'new work pushed' when the block is solved, but why do pools send them alot more often?
199 2012-04-18 18:19:48 <[Tycho]> ciscoftw: some pools do this for "merged mining"
200 2012-04-18 18:22:09 <ciscoftw> when i pool mine i do it via bitclockers and they dont mine for namecoins
201 2012-04-18 18:22:58 <ciscoftw> there has to be some performance/efficiency reason for sending LP's (when the current block is still valid).
202 2012-04-18 18:38:57 <davout_> ciscoftw: your current work is invalidated each time a pool includes a new TX in its currently mined block
203 2012-04-18 18:39:05 <luke-jr> davout_: not true
204 2012-04-18 18:39:28 <davout_> doesn't the merkle root change ?
205 2012-04-18 18:39:31 <luke-jr> ciscoftw: pools send new work for a variety of reasons
206 2012-04-18 18:39:42 <luke-jr> davout_: that doesn't mean the old work is invalid
207 2012-04-18 18:39:57 <luke-jr> ciscoftw: pushpool has a notorious memory leak unless you LP often
208 2012-04-18 18:41:00 <davout> luke-jr: if a pool includes a tx in its collection, and immediately receives a solved chunk of work that was based on an outdated merkle root, how can the pool see that the solution is valid?
209 2012-04-18 18:41:33 <luke-jr> ciscoftw: and if there's a big txn fee, a pool might want to LP it asap
210 2012-04-18 18:41:56 <luke-jr> davout: every miner has a unique merkle root in the first place
211 2012-04-18 18:42:45 <luke-jr> davout: pools keep a hashtable of issued merkleroots
212 2012-04-18 18:43:29 <davout> luke-jr: interesting, i guess you're the pool operator here, heh
213 2012-04-18 18:43:38 <davout> luke-jr: is it true for all pools?
214 2012-04-18 18:43:43 <luke-jr> davout: it's impossible to run a pool without some kind of merkletree lookup
215 2012-04-18 18:44:29 <luke-jr> davout: because every worker *needs* a unique merkleroot
216 2012-04-18 18:44:46 <davout> luke-jr: i guess my pool operation knowledge is fairly limited
217 2012-04-18 18:44:50 <luke-jr> a single merkleroot is only good for 4 GH/s
218 2012-04-18 18:44:56 <davout> luke-jr: i guess that's true for your pool, where AFAIK rewards are paid directly in the coinbase tx, right ?
219 2012-04-18 18:44:59 <luke-jr> davout: that's true in general. there are 2^32 nonces to try each second.
220 2012-04-18 18:45:00 <Cory> luke-jr: So some people mining with more than 4 GH/s need to take that into consideration?
221 2012-04-18 18:45:00 <davout> luke-jr: but how is that necessary for pools who have a regular coinbase that gets split afterwards
222 2012-04-18 18:45:00 <luke-jr> davout: there's still only 2^32 nonces per merkleroot per second& that's 4 GH/s
223 2012-04-18 18:45:01 <Cory> Cool!
224 2012-04-18 18:45:01 <luke-jr> Cory: yes
225 2012-04-18 18:45:08 <luke-jr> Cory: cgminer is notoriously bad about it& it gets a new work for every thread aggressively
226 2012-04-18 18:45:17 <Cory> Ah
227 2012-04-18 18:48:29 <gribble> New news from bitcoinrss: sipa opened pull request 1124 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1124>
228 2012-04-18 19:04:00 <ciscoftw> luke-jr: thanks for leading this discussion. I guess the answer is because at 4GH/sec an entire merkle root is exhausted, which leads to an LP. Not sure what daveout is talking about regarding the tx's, i thought all tx's were 'cached' by network until block was solved at which all tx's are hashed to block (included). tx broadcast to network doesnt effect current efforts to solve hash for
229 2012-04-18 19:04:01 <ciscoftw> valid block does it?
230 2012-04-18 19:04:18 <luke-jr> ciscoftw: & no
231 2012-04-18 19:04:55 <luke-jr> ciscoftw: you're misunderstanding so much, I don't know where to begin :/
232 2012-04-18 19:05:49 <ciscoftw> 1.) do tx's dynamically effect how a block is solved?
233 2012-04-18 19:06:42 <gmaxwell> 1. Maybe.
234 2012-04-18 19:07:49 <ciscoftw> does the tx fee apply to my question
235 2012-04-18 19:07:50 <gmaxwell> If you wish to include it, you need to update the merkel root, but you're not required to include it. Many pools don't LP for transasction, but it's not unwise to so do (imagine missing a 50btc fee transaction because of this).. Though obviously you'd not want to LP for every single one.
236 2012-04-18 19:08:23 <ciscoftw> thanx, but most (almost all tx fees) are super small
237 2012-04-18 19:08:47 <luke-jr> my pool doesn't LP for fees.
238 2012-04-18 19:08:54 <gmaxwell> Right. Most are zero in fact.. sometimes there are larger ones for ??? who knows what purpose. :)
239 2012-04-18 19:08:56 <luke-jr> it does LP for network health.
240 2012-04-18 19:09:23 <luke-jr> when Eligius sees a new block, it sends out a longpoll immediately with no transactions in it
241 2012-04-18 19:09:30 <gmaxwell> and likewise, if it's been an hour since the last block, it would kinda suck to miss the last hour of txn even if they were all free :)
242 2012-04-18 19:09:37 <luke-jr> when it's done calculating the new transaction merkletree, it sends another LP with it populated
243 2012-04-18 19:09:54 <ciscoftw> ummmm, thanx gmaxwell -good explaination
244 2012-04-18 19:10:00 <luke-jr> gmaxwell: well, I've never heard of jobs being valid more than 2 minutes :P
245 2012-04-18 19:10:17 <gmaxwell> luke-jr: fair enough, but it could be done
246 2012-04-18 19:12:32 <ciscoftw> so another reason to LP would be the completion of a single merkle root by your cluster, in addition to maximizing tx fee collection (as explained above)
247 2012-04-18 19:14:20 <luke-jr> & no
248 2012-04-18 19:14:27 <luke-jr> every job has a unique merkle root
249 2012-04-18 19:14:40 <luke-jr> and they're never complete, just expired.
250 2012-04-18 19:14:50 <ciscoftw> job being a node?
251 2012-04-18 19:14:56 <luke-jr> ciscoftw: yes
252 2012-04-18 19:15:19 <luke-jr> if you have a 4 GH/s FPGA mining rig, you get a new job every minute or so
253 2012-04-18 19:15:39 <luke-jr> the getwork protocol can't scale to slower speeds sanely, so you get 4 GH/s worth of work with each request
254 2012-04-18 19:18:28 <ciscoftw> the 'midstate' data in a getwork request would be the same until that merkle root has expired (bitcoind)
255 2012-04-18 19:18:59 <luke-jr> 'midstate' is deprecated
256 2012-04-18 19:19:03 <luke-jr> and will be removed eventually
257 2012-04-18 20:09:19 <tcatm> It's really scary when using the bitcoin-qt client with an old backup of a wallet seeing old transactions appear with very recent timestamps. For a second, I thought someone might have managed to get one of my private keys.
258 2012-04-18 22:14:57 <gmaxwell> ;;tell bluematt hey, why doesn't the jenkins install do all-platform gitian builds automatically?
259 2012-04-18 22:15:07 <gmaxwell> okay, I fail at gribble.
260 2012-04-18 22:15:48 <Graet> ;;later tell bluematt hey, why doesn't the jenkins install do all-platform gitian builds automatically?
261 2012-04-18 22:16:16 <BlueMatt> you could just tag me...
262 2012-04-18 22:16:35 <BlueMatt> because gitian needs vt-x to be even remotely reasonably fast
263 2012-04-18 22:16:38 <BlueMatt> gmaxwell: ^
264 2012-04-18 22:16:48 <BlueMatt> and aws doesnt provide vt-x :(
265 2012-04-18 22:16:58 <gmaxwell> BlueMatt: okay, then use a remote buildslave.
266 2012-04-18 22:17:08 <gmaxwell> jenkins can ssh into anything that can run java.
267 2012-04-18 22:17:29 <BlueMatt> do you have a 24/7 server with vt-x to donate? Im sure gavin would appreciate no longer having to pay for aws anymore...
268 2012-04-18 22:18:01 <BlueMatt> (and, for the record, jenkins's build scripts are really close to the gitian ones)
269 2012-04-18 22:18:06 <BlueMatt> pretty much all thats missing is faketime
270 2012-04-18 22:18:23 <BlueMatt> oh, and I think they run on a different version of ubuntu...
271 2012-04-18 22:18:25 <gmaxwell> ah I didn't see a win32 cross compile.
272 2012-04-18 22:18:31 <BlueMatt> no, thats there
273 2012-04-18 22:18:42 <gmaxwell> (someone in #bitcoin is hitting the crash-on-some-wrong-passwords bug and I want him to try current git)
274 2012-04-18 22:18:55 <BlueMatt> bitcoin-qt.exe is there
275 2012-04-18 22:18:58 <BlueMatt> as is bitcoind.exe
276 2012-04-18 22:19:09 <gmaxwell> oh indeed.
277 2012-04-18 22:21:57 <gmaxwell> ... and.. he's solved.
278 2012-04-18 22:22:09 <gmaxwell> The hardest thing about that bug is convincing people their password is wrong. :)
279 2012-04-18 22:26:18 <BlueMatt> heh
280 2012-04-18 22:33:21 <seco> wrong choosen pass to wallet encryption?
281 2012-04-18 22:34:14 <gmaxwell> seco: there is a bug in all current released versions of bitcoin where some wrong passwords crash bitcoin-qt rather than telling you that the password is wrong. (do to some subtle crypto library behavior)
282 2012-04-18 22:34:26 <gmaxwell> Only about 1/256 wrong passwords does this. The rest tell you that they're wrong.
283 2012-04-18 22:35:03 <gmaxwell> So user enters a password... it says wrong.. tries another .. crashes. "Ah that must be right! but, damn! it crashed!"
284 2012-04-18 22:35:30 <seco> oh, and bug is not traceale somehow?
285 2012-04-18 22:35:34 <seco> traceable*
286 2012-04-18 22:35:59 <gmaxwell> traceable?
287 2012-04-18 22:36:00 <seco> maybe its the password he used when it crashed: some special symbol in it?
288 2012-04-18 22:36:21 <gmaxwell> No no. It's solved we just haven't released a new version with the fix yet.
289 2012-04-18 22:36:37 <gmaxwell> And if it were something _that_ obvious the user would figure it out. nah..
290 2012-04-18 22:36:41 <seco> yes, somehow this 1 case out of 256 cases needs to be isolated
291 2012-04-18 22:36:47 <seco> ah k
292 2012-04-18 22:37:24 <seco> i would show allowed symbols in gui to make sure user dont use weird ones leading unexpected behavior
293 2012-04-18 22:37:44 <gmaxwell> All symbols are allowed. That wasn't the issue.
294 2012-04-18 22:38:00 <seco> ill try with some ascii-codechars tomorrow :D
295 2012-04-18 22:38:19 <seco> oh and some hebrew ones hehe
296 2012-04-18 22:38:31 <sipa> try as you may
297 2012-04-18 22:39:01 <gmaxwell> Yes, it's solved. certian incorrect keys causes the crypto library to toss an error on decryption, because they can be detected as incorrect by virtue of the corrupted padding. Some do not.  The ones that do not were properly getting detected.  It was just a simple error handling bug, caused by the fact that there were two ways it could fail and only one was getting tested because it was more likely.
298 2012-04-18 22:39:32 <seco> ahh
299 2012-04-18 22:39:58 <gmaxwell> er* were not properly getting detected.
300 2012-04-18 22:40:06 <gmaxwell> too many were nots there.
301 2012-04-18 22:40:42 <seco> working exact sometimes is very hard! :)
302 2012-04-18 22:41:22 <gmaxwell> Thats a kind of bug where code coverage analysis would have been helpful
303 2012-04-18 22:41:40 <gmaxwell> the error handling code that should have run when the password failed wouldn't have been run.