1 2012-07-10 09:53:45 <gribble> New news from bitcoinrss: Diapolo opened pull request 1574 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1574>
  2 2012-07-10 10:00:34 <sipa> gmaxwell: 5m05s to load 185k blocks with a std::map-backed coindb
  3 2012-07-10 10:00:48 <sipa> compared to 6m when using tmpfs-BDB-backed coindb
  4 2012-07-10 10:01:04 <sipa> and 11m when using disk-BDB-backed coindb
  5 2012-07-10 11:36:16 <gribble> New news from bitcoinrss: laanwj opened pull request 1575 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1575>
  6 2012-07-10 12:53:31 <OneEyed> I was reading the contracts page on https://en.bitcoin.it/wiki/Contracts
  7 2012-07-10 12:54:06 <OneEyed> Nowhere it mentions that you have to be able to make the exact input amount, or you'll have the change blocked as well
  8 2012-07-10 13:01:05 <gmaxwell> OneEyed: you can always do a transaction before that transaction to get the inputs the right size.
  9 2012-07-10 13:34:55 <jgarzik> stupid cpuminer
 10 2012-07-10 13:35:11 <jgarzik> solo mined all night last night, with two CPU cores, with no blocks to show for it!
 11 2012-07-10 13:35:43 <Diablo-D3> lol
 12 2012-07-10 13:38:01 <gribble> You are not identified.
 13 2012-07-10 13:38:01 <jgarzik> ;;ident
 14 2012-07-10 13:41:02 <luke-jr> jgarzik: on testnet you mean?
 15 2012-07-10 13:42:40 <jgarzik> luke-jr: mainnet
 16 2012-07-10 13:43:17 <luke-jr> i c, must've been sarcasm ;p
 17 2012-07-10 13:47:22 <jgarzik> machine burn-in
 18 2012-07-10 13:48:10 <jgarzik> great way to get it to run all its fans, exercise its disk (initial block download) and other systems
 19 2012-07-10 13:52:19 <gmaxwell> if only we used proof-of-txn-processing-capacity (where the POW involves H(header)->random_txout_index, H(header+random_txout)=work instead of SHA256^2 it would really excercise everything.
 20 2012-07-10 14:05:01 <jgarzik> it will be interesting to [belatedly] see how many Mhps that these new Intel graphics chips produce
 21 2012-07-10 14:05:38 <jgarzik> nothing close to Radeons, surely, but probably faster than CPU
 22 2012-07-10 14:09:50 <sipa> gmaxwell: in your callgrind chart, BuildMerkleTree has 12.52% usage
 23 2012-07-10 14:10:30 <sipa> gmaxwell: while it has a 2.95% Hash() child and a 11.64% CTransaction::GetHash()
 24 2012-07-10 14:11:12 <jgarzik> *cache
 25 2012-07-10 14:11:39 <sipa> jgarzik: in my branch a transaction's hash is never computed twice
 26 2012-07-10 14:13:45 <gavinandresen> jgarzik: grab me a Mountain Dew, I'm dragging a little this afternoon
 27 2012-07-10 14:13:49 <gmaxwell> sipa: the times are of the total.. so one (or both) of those has other parents, which may be too small to get listed on their own.
 28 2012-07-10 14:14:07 <sipa> gmaxwell: right
 29 2012-07-10 14:14:30 <sipa> gmaxwell: hmm, CheckBlock() is called twice for each block, and has 17% CPU usage
 30 2012-07-10 14:15:20 <BlueMatt> jgarzik: opencl is only supported on ivy bridge, never on sandy bridge, Its been on my todo list to benchmark the ivy bridge I have in the house (and they have an sdk for linux, though its a pretty harsh license)
 31 2012-07-10 14:15:26 <gavinandresen> making a list, checking it twice....
 32 2012-07-10 14:15:38 <[Tycho]> :)
 33 2012-07-10 14:16:02 <jgarzik> BlueMatt: poop.  I have sandy bridge.
 34 2012-07-10 14:16:06 <gavinandresen> Hey [Tycho] : I've been spending a ton of time in the last week or so thinking about transaction fees.  What's your current fee policy?
 35 2012-07-10 14:16:14 <gmaxwell> I wonder how viable it would be to use a multiway sha256 in things like the tree building.
 36 2012-07-10 14:16:26 <gmaxwell> at least a two way wouldn't be too hard to use.
 37 2012-07-10 14:17:16 <[Tycho]> gavinandresen: as stated on the help page, but currently I'm intentionally lowering priority for 1dice TXes to allow more normal free transactions.
 38 2012-07-10 14:17:35 <sipa> gavinandresen: making a list, checking it twice?
 39 2012-07-10 14:17:57 <gavinandresen> sipa: lyrics from "Santa Claus is Coming To Town" song
 40 2012-07-10 14:18:28 <gavinandresen> (are you Sinter Klaus in Belgium?  does he make a list of naughty and nice transactions?)
 41 2012-07-10 14:19:13 <sipa> Sinterklaas, we call him, and he is separate (though looks a bit similar to) the "Chistmas Man"
 42 2012-07-10 14:19:37 <gmaxwell> gavinandresen: Sipa is just doing that dutch thing where they pretend that they're not all americans in a disguise of bicycles and bizarre art.
 43 2012-07-10 14:19:39 <sipa> and he does have a big book with a lsit of which children have been nice and naughty
 44 2012-07-10 14:20:36 <sipa> gmaxwell: now you lost me
 45 2012-07-10 14:20:43 <gavinandresen> [Tycho]: thanks for the fee policy pointer
 46 2012-07-10 14:21:25 <gavinandresen> I like bicycles and bizarre art
 47 2012-07-10 14:21:51 <gavinandresen> But I wasn't born in America, so I guess that figures
 48 2012-07-10 14:23:17 <[Tycho]> gavinandresen: see pm.
 49 2012-07-10 14:24:28 <[Tycho]> Actually that part about "more free TXes than anyone else" is not actual anymore :)
 50 2012-07-10 14:25:28 <gmaxwell> sipa: It seems that all the belgium/netherlands theoretically dutch speaking folks I interact with online are only distinguishable from the 'native speakers' by their superior command of english. :)
 51 2012-07-10 14:26:39 <gmaxwell> So I think it's all a big joke, you're all just claiming to be non-native speakers just because you don't want to be confused for americans who tend to be rude tourists. ;)
 52 2012-07-10 14:27:08 <Diapolo> gmaxwell: LOL I read terrorists at the end of your sentence ^^
 53 2012-07-10 14:27:31 <gmaxwell> I suppose most terrorists are kinda rude.
 54 2012-07-10 14:27:50 <Diapolo> indeed ;)
 55 2012-07-10 14:34:50 <Diapolo> In which header or source file is the current version defined?
 56 2012-07-10 14:45:14 <luke-jr> Diapolo: in git
 57 2012-07-10 14:49:07 <Diapolo> alright
 58 2012-07-10 14:49:48 <gavinandresen> src/version.cpp/version.h
 59 2012-07-10 14:50:29 <gavinandresen> and share/genbuild.sh, which creates obj/build.h
 60 2012-07-10 15:05:35 <Diapolo> thanks gavin, better answer ;)
 61 2012-07-10 15:24:56 <copumpkin> https://plus.google.com/u/0/113212242446665079433/posts/KJ6Wrkyuji5 :)
 62 2012-07-10 16:33:51 <Marf> the pig is right
 63 2012-07-10 16:33:57 <Marf> isnt there a minimal build
 64 2012-07-10 16:42:45 <makomk> ["0x4c 0x00","0 EQUAL"], - curious.
 65 2012-07-10 16:49:52 <pooler> What is the purpose of strAddressBad in src/test/key_tests.cpp? I thought it was for checking if the client is able to recognize bad addresses, but the value appears to be a valid address.
 66 2012-07-10 17:05:47 <sipa> pooler: shouldn't be valid...
 67 2012-07-10 17:17:12 <pooler> Well i fed it to validateaddress and I get: "isvalid" : true
 68 2012-07-10 17:19:53 <lianj> http://blockexplorer.com/q/checkaddress/1HV9Lc3sNHZxwj4Zk6fB38tEmBryq2cBiF
 69 2012-07-10 17:21:06 <lianj> what makes it invalid?
 70 2012-07-10 17:21:38 <mcorlett> lianj: 00 is valid.
 71 2012-07-10 17:21:46 <lianj> yea, i know
 72 2012-07-10 17:22:17 <lianj> oh.. i mis-read pooler.. sorry. ISvalid, not INvalid oO
 73 2012-07-10 17:28:05 <pooler> My question is, if the address is valid, why is it called strAddressBad?
 74 2012-07-10 17:28:29 <pooler> Also, I tried putting various values there, and they didn't influence the output of the test suite.
 75 2012-07-10 17:36:17 <gribble> New news from bitcoinrss: ripper234 opened issue 1576 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1576>
 76 2012-07-10 18:01:36 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1577 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1577>
 77 2012-07-10 18:04:03 <makomk> pooler: it appears to be for checking that Bitcoin won't let you import a Bitcoin address as a private key
 78 2012-07-10 18:05:26 <pooler> Ah! Thanks!
 79 2012-07-10 18:34:06 <[Tycho]> Oh, they are messing with the coinbase again :(
 80 2012-07-10 18:36:25 <cccp> how so?
 81 2012-07-10 18:36:49 <[Tycho]> https://bitcointalk.org/index.php?topic=92558.msg0#new
 82 2012-07-10 18:37:06 <cccp> ty
 83 2012-07-10 18:39:50 <BlueMatt> [Tycho]: I'd say its better to keep bitcoin evolving than to let it remain static...
 84 2012-07-10 18:40:35 <[Tycho]> Is there a description why do we need a block height in the block ?
 85 2012-07-10 18:43:33 <BlueMatt> it enforces coinbase uniqueness
 86 2012-07-10 18:44:01 <BlueMatt> and having block height in the block structure is really nice for certain client models
 87 2012-07-10 18:44:50 <BlueMatt> though mainly its a "there have been several cases where this would have been nice, so while we are adding versions, lets add this"
 88 2012-07-10 18:44:55 <ersi> cccp: choo choo
 89 2012-07-10 18:47:22 <BlueMatt> [Tycho]: how's multisend coming?
 90 2012-07-10 18:47:44 <[Tycho]> Fine, already tested it.
 91 2012-07-10 18:47:48 <BlueMatt> (which, as of ultraprune, has an even bigger impact on storage space...)
 92 2012-07-10 18:47:51 <BlueMatt> nice
 93 2012-07-10 18:48:29 <[Tycho]> Are there many problems with coinbase uniqueness atm ?
 94 2012-07-10 18:48:32 <luke-jr> BIPs really shouldn't make reference to specific clients except as implementations
 95 2012-07-10 18:50:02 <BlueMatt> [Tycho]: no, bip30 made it (somewhat) illegal, and (afaik) we havent seen it since blocks in the 90k range, but its still a nice feature to make clients (or, really, sites like blockchain.info) happy when they assume that tx hashes are unique
 96 2012-07-10 18:50:19 <BlueMatt> (blockchain.info f's up on the two duplicate coinbases in the chain)
 97 2012-07-10 18:51:22 <BlueMatt> if it did, you could kill it pretty easily...
 98 2012-07-10 18:51:27 <BlueMatt> luke-jr: wanna test it?
 99 2012-07-10 18:51:27 <[Tycho]> luke-jr: try me.
100 2012-07-10 18:51:48 <luke-jr> BlueMatt: wanna finance it?
101 2012-07-10 18:51:51 <BlueMatt> [Tycho]: is that a "Im overconfident" or "yes, I implement bip30"?
102 2012-07-10 18:51:57 <BlueMatt> luke-jr: heh...ok so ask Diablo-D3
103 2012-07-10 18:52:29 <gmaxwell> BIP 30 prevents transaction rewrites. It does not prevent the duplication of already spent coinbases, and can't because if it did it would make pruning impossible.
104 2012-07-10 18:52:52 <BlueMatt> gmaxwell: yep, only (somewhat) illegal
105 2012-07-10 18:53:19 <Diablo-D3> ?
106 2012-07-10 18:55:10 <luke-jr> Diablo-D3: wanna waste 50 BTC to see if [Tycho] recognizes BIP30?
107 2012-07-10 18:55:57 <Diablo-D3> I dont really care
108 2012-07-10 18:56:59 <[Tycho]> BlueMatt: so why can't we just require coinbases to be unique, without adding block depth there ? Am I missing something ? Or there are other purposes ?
109 2012-07-10 18:57:18 <luke-jr> [Tycho]: we already do. does deepbit enforce this or not?
110 2012-07-10 18:57:20 <BlueMatt> yes, having a block number in a block is very convenient
111 2012-07-10 18:58:41 <[Tycho]> BlueMatt: will v2 blocks be accepted by old non-mining clients just fine ?
112 2012-07-10 18:58:43 <BlueMatt> [Tycho]: and requiring coinbases be unique full stop means you can no longer pruned block chains
113 2012-07-10 18:58:49 <BlueMatt> yes
114 2012-07-10 18:58:54 <BlueMatt> and old mining clients too
115 2012-07-10 18:59:30 <gmaxwell> luke-jr: we require that they not overwrite a unspent ID, this isn't the same as global uniqueness.
116 2012-07-10 18:59:41 <luke-jr> gmaxwell: for practical purposes, it is
117 2012-07-10 18:59:56 <BlueMatt> its clearly not the same for blockchain.info
118 2012-07-10 19:00:01 <BlueMatt> (and any other sites like it)
119 2012-07-10 19:00:06 <[Tycho]> BlueMatt: how exactly is it convenient ?
120 2012-07-10 19:00:26 <luke-jr> [Tycho]: it also means clients can "cheat" on some things
121 2012-07-10 19:00:37 <luke-jr> by knowing a block's height without having the full chain
122 2012-07-10 19:00:51 <BlueMatt> you have block height without having to have a full chain (of at least block headers)
123 2012-07-10 19:01:28 <[Tycho]> But then you should be sure that this block is accepted by the network.
124 2012-07-10 19:01:29 <gmaxwell> luke-jr: it's really not. Say you have a banking site that can somehow be exploited by there existing duplicated txn.  I can mine a block, spend it into a txn A.. then mine a duplicate of that block.  .. send A to the bank.. wait for it to get spent. Then use my duplicate block to send A' to the bank.
125 2012-07-10 19:02:16 <gmaxwell> luke-jr: and so even with BIP30 you can give duplicate txn to a merchant and make their software do crazy things because they've assumed txn can't have duplicated IDs.
126 2012-07-10 19:04:11 <gmaxwell> This is because BIP30 couldn't deny global duplication without making pruning forever impossible.
127 2012-07-10 19:04:36 <gmaxwell> The only way to prevent duplication without making pruning impossible is to make sure that each coinbase transaction is unique.
128 2012-07-10 19:05:22 <BlueMatt> [Tycho]: ?
129 2012-07-10 19:05:32 <[Tycho]> ?
130 2012-07-10 19:05:43 <BlueMatt> <[Tycho]> But then you should be sure that this block is accepted by the network.
131 2012-07-10 19:05:45 <BlueMatt> ?
132 2012-07-10 19:50:45 <TehZomB> herro
133 2012-07-10 19:51:06 <TehZomB> is it possible to run two bitcoinds on one server, as one user? for example one running out of ~/.bitcoin and one of out ~/.bitcoin2? and if so, is it possible for them to share the blockchain file?
134 2012-07-10 19:51:44 <BlueMatt> possible? yes, possible to share the chain file? no
135 2012-07-10 19:52:01 <TehZomB> okay
136 2012-07-10 19:52:20 <BlueMatt> I believe all you need is -datadir and either -nolisten or -port
137 2012-07-10 19:52:22 <TehZomB> is it kosher to set the second client to only connect to the first client using, i think it's the -addnode argument?
138 2012-07-10 19:52:40 <BlueMatt> you would want -connect for that, and yes it would be recommended
139 2012-07-10 19:52:41 <bonks> or -connect
140 2012-07-10 19:52:50 <TehZomB> ok conenct. thanks
141 2012-07-10 19:55:59 <gribble> 0.0416666666667
142 2012-07-10 19:55:59 <TehZomB> ;;calc 25/600
143 2012-07-10 19:59:11 <gribble> 0.025
144 2012-07-10 19:59:11 <TehZomB> ;;calc 15/600
145 2012-07-10 20:44:27 <Moogs> how do i start bitcoins
146 2012-07-10 20:47:30 <lianj> Moogs: https://en.bitcoin.it/wiki/Getting_started
147 2012-07-10 22:12:38 <copumpkin> what do people think, was bitcoin script a bad idea?
148 2012-07-10 22:12:56 <copumpkin> if we're only allowing predetermined scripts, it seems like people don't trust it anyway
149 2012-07-10 22:13:29 <copumpkin> and the flexibility isn't much use if the clients reject nonstandard scripts. Are there plans to unrestrict it someday?
150 2012-07-10 22:13:44 <gavinandresen> sure, once "we" completely understand it.
151 2012-07-10 22:14:17 <gavinandresen> (and somebody much smarter than me has proven some things about it, or a subset of it)
152 2012-07-10 22:14:57 <gmaxwell> I think script is a fantastic and very important idea. It's not like we can constantly upgrade all bitcoin users everywhere for every transaction style people want.
153 2012-07-10 22:15:22 <gmaxwell> But that doesn't trump the _actual_ exploits observed in real life multiple times until a mellon baller was taken to it.
154 2012-07-10 22:15:24 <gavinandresen> copumpkin: is there a script form that you really want?
155 2012-07-10 22:15:25 <copumpkin> so people are really just waiting for proofs of no badness
156 2012-07-10 22:15:33 <copumpkin> oh no, I was just asking abstractly
157 2012-07-10 22:15:40 <copumpkin> whether in retrospect people thought it was good or not
158 2012-07-10 22:15:46 <copumpkin> it's obviously here to stay, regardless
159 2012-07-10 22:16:16 <gavinandresen> abstractly, yes, I think we need proof of things like "these set of opcodes are bounded in execution time and memory space"
160 2012-07-10 22:16:47 <gavinandresen> Clients will still only understand a subset of transaction forms, I think, it'd be impossible to give a good user experience for "here's an arbitrary script, want to sign it?"
161 2012-07-10 22:16:53 <gmaxwell> And proof that they aren't isomorphic to OP_RUNx86code
162 2012-07-10 22:16:59 <copumpkin> gmaxwell: :)
163 2012-07-10 22:17:21 <copumpkin> there seem to be a lot of highly redundant opcodes
164 2012-07-10 22:17:29 <copumpkin> I guess to save space for common operations?
165 2012-07-10 22:18:00 <gavinandresen> I suppose; I don't think the opcode set is well designed.
166 2012-07-10 22:18:08 <copumpkin> fair enough
167 2012-07-10 22:18:40 <gavinandresen> It fails my "zero one infinity" rule in a bunch of places
168 2012-07-10 22:18:56 <copumpkin> zero one infinity?
169 2012-07-10 22:19:01 <copumpkin> oh
170 2012-07-10 22:19:13 <copumpkin> special cases for 0, 1, and then no others?
171 2012-07-10 22:19:26 <gavinandresen> 0 means leave the feature out, you don't need it.
172 2012-07-10 22:19:41 <gavinandresen> 1 means in practice there will only be one of the damn thing, so just plan for 1.
173 2012-07-10 22:19:56 <gavinandresen> If you're designing for 11 things, then you might as well design for infinity.
174 2012-07-10 22:20:25 <gmaxwell> copumpkin: the implicit directs look a _lot_ like the opcodes for microcode instructions for very high speed network processors with limited microcode space that I've worked with. (which do it for space, because when you have to write packet extraction code in 200 bytes it matters!) But I only assume the motivation was the same in bitcoin.
175 2012-07-10 22:20:31 <gavinandresen> Doesn't apply to hardware, of course, where you've got physical constraints, but I'm a software guy
176 2012-07-10 22:20:46 <copumpkin> yeah
177 2012-07-10 22:20:51 <copumpkin> I see
178 2012-07-10 22:34:59 <[Tycho]> So much efforts for P2SH and no results to end-users yet... Even blockchain.info dropped their support for multisigs.
179 2012-07-10 22:36:33 <doublec> how much use is P2SH getting?
180 2012-07-10 22:40:44 <BlueMatt> [Tycho]: p2sh/multisig is setting up for the future, not actually implementing it ;)
181 2012-07-10 22:41:01 <[Tycho]> doublec:  none.
182 2012-07-10 22:54:12 <copumpkin> http://snapplr.com/d0sq
183 2012-07-10 22:54:16 <copumpkin> why are those marked as special input-wise?
184 2012-07-10 22:54:43 <copumpkin> that doesn't seem to have anything to do with the stack
185 2012-07-10 23:04:53 <BlueMatt> heh...we check sigop count in coinbase input...
186 2012-07-10 23:05:53 <copumpkin> I don't really understand the notation for OP_IF and friends in the input/output parts
187 2012-07-10 23:06:05 <copumpkin> is parsing it the weird part or is the semantics?
188 2012-07-10 23:09:28 <BlueMatt> someone wanna check to make sure we won't generate blocks with >MAX_SIGOPS if we have a coinbase that an unlucky miner stuffed a ton of OP_CHECKMULTISIG's into?
189 2012-07-10 23:11:39 <BlueMatt> heh, any miner that stuffs 0xac,0xad,0xae or 0xaf in their coinbase could potentially generate invalid blocks, and...go see if you can make the pools die
190 2012-07-10 23:12:00 <BlueMatt> also...need to think about this for putting height in coinbase
191 2012-07-10 23:12:36 <luke-jr> BlueMatt: I don't think so.
192 2012-07-10 23:12:39 <BlueMatt> especially any 0xae or 0xaf's because those count as 20 sigops...
193 2012-07-10 23:12:47 <luke-jr> BlueMatt: though you could easily trick p2pool into generating invalid blocks ;)
194 2012-07-10 23:13:03 <luke-jr> (already fixed when gmp_bip gets merged)
195 2012-07-10 23:13:28 <BlueMatt> luke-jr: well that checks that blocks will be accepted, but will it actually give you blocks if it starts to fail?
196 2012-07-10 23:14:01 <luke-jr> BlueMatt: checknewblock != gmp_bip
197 2012-07-10 23:14:24 <luke-jr> BlueMatt: gmp_bip adds sigop info to getmemorypool, so poolservers can avoid breaking the limits
198 2012-07-10 23:14:59 <BlueMatt> does it include the coinbase tx's inputs in the sigop count?
199 2012-07-10 23:15:19 <luke-jr> the sigop count is per-transaction, so yes
200 2012-07-10 23:15:21 <BlueMatt> (and, leave it to the poolserver isnt a valid answer)
201 2012-07-10 23:15:26 <luke-jr> but usually the poolserver makes its own coinbase
202 2012-07-10 23:15:31 <BlueMatt> (and, leave it to the poolserver isnt a valid answer)
203 2012-07-10 23:15:31 <luke-jr> (and coinbase has no inputs)
204 2012-07-10 23:15:40 <BlueMatt> no, but it has scriptSig, and we count that
205 2012-07-10 23:16:58 <luke-jr> bitcoind doesn't serve coinbasetxn, so not an issue there
206 2012-07-10 23:18:12 <gribble> New news from bitcoinrss: TheBlueMatt opened issue 1578 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1578>
207 2012-07-10 23:23:11 <doublec> luke-jr: why does bip 22 use the same name as an existing rpc call?
208 2012-07-10 23:23:22 <doublec> luke-jr: when it seems a lot more complex
209 2012-07-10 23:23:58 <luke-jr> doublec: it standardizes the existing RPC call in a generally useful way
210 2012-07-10 23:24:26 <doublec> luke-jr: given getmemorypool already exists and has usage, wouldn't it be better to give bip 22 a different name
211 2012-07-10 23:24:42 <doublec> luke-jr: since it seems a whole lot more that just getting memory pool information
212 2012-07-10 23:24:44 <luke-jr> doublec: it's backward compatible, and incldues the same usage
213 2012-07-10 23:25:13 <luke-jr> doublec: and notably the old getmemorypool has a flawed design as-is now
214 2012-07-10 23:25:30 <doublec> it's backward comaptible only in that it takes an argument, right?
215 2012-07-10 23:25:30 <sipa> bip22 is really just an improvement for the existing getmemorypool call
216 2012-07-10 23:25:33 <doublec> whereas the original doesn't
217 2012-07-10 23:25:38 <sipa> but that usage is really not getting the memory pool
218 2012-07-10 23:25:54 <doublec> sipa: right, good opportunity to give it a more relevant name
219 2012-07-10 23:26:08 <luke-jr> sipa: most uses get the memory pool :p
220 2012-07-10 23:26:41 <doublec> it's called "getmemorypool" but has a way of sending shares?
221 2012-07-10 23:26:55 <doublec> and getting server information?
222 2012-07-10 23:26:59 <luke-jr> doublec: an earlier draft had "submitblock", but people didn't like that :/
223 2012-07-10 23:27:17 <sipa> it returns information on how to construct a block, based on the memory pool
224 2012-07-10 23:27:18 <doublec> and backup servers?
225 2012-07-10 23:27:25 <doublec> getmemorypool seems completely the wrong name
226 2012-07-10 23:27:34 <sipa> it should be getmininginfo or something
227 2012-07-10 23:27:50 <doublec> right
228 2012-07-10 23:27:58 <sipa> that said, compatibility...
229 2012-07-10 23:28:06 <sipa> we have getrawmemorypool now in git head
230 2012-07-10 23:28:14 <luke-jr> getrawmemorypool was du,mb
231 2012-07-10 23:28:20 <luke-jr> since BIP22 supports that
232 2012-07-10 23:28:41 <sipa> the pull request doesn't, does it?
233 2012-07-10 23:28:44 <luke-jr> no
234 2012-07-10 23:28:59 <sipa> in that case i say scrap it from bip22, and have it be a separate call
235 2012-07-10 23:29:03 <sipa> as its usage is very different
236 2012-07-10 23:29:41 <doublec> why overload bip 22 with so much
237 2012-07-10 23:29:47 <sipa> exactly
238 2012-07-10 23:30:05 <doublec> split it out into different calls and it'll be much easier to get it accepted in bits
239 2012-07-10 23:30:11 <walruscode> Anyone know how I can easily find the first block of the day, without checking the timestamp of every block, starting with the most recent one?
240 2012-07-10 23:30:23 <doublec> it's almost like an rpc system inside of bitcoin's rpc
241 2012-07-10 23:30:39 <luke-jr> bitcoind doesn't need to implement every use case
242 2012-07-10 23:31:35 <doublec> " If the request parameters include a "mode" key, that is used to explicitly select between "template", "proposal", and "submit" calls. Otherwise, it defaults to a submission if there is a "data" key (including the String-type argument mentioned above), and a template request if not. "
243 2012-07-10 23:31:41 <doublec> why not make those different rpc's for example
244 2012-07-10 23:31:54 <luke-jr> doublec: because then bitcoind developers complain about too many RPC methods
245 2012-07-10 23:32:07 <nimdAHK> walruscode: :/ I don't think there's a way currently. Write a script to do it for you :)
246 2012-07-10 23:33:07 <doublec> what does getrawmemorypool do compared to getmemorypool?
247 2012-07-10 23:33:13 <luke-jr> I'm tired of all the fence painting
248 2012-07-10 23:33:14 <sipa> doublec: it gets the memory pool
249 2012-07-10 23:33:16 <walruscode> nimdAHK: I'm doing just that. Do you think checking the blockchain, in order of descending block height, would be a good way of doing it?
250 2012-07-10 23:33:32 <luke-jr> getrawmempool just does gmp({"sigoplimit":false, "sizelimit":false}) more or less
251 2012-07-10 23:33:32 <nimdAHK> yes
252 2012-07-10 23:33:47 <nimdAHK> make sure you account for the no-blocks-yet-today case
253 2012-07-10 23:33:53 <doublec> luke-jr: I'm just saying that splitting it up into seperate calls is likely to make it easier to analyse, debug, use and get accepted
254 2012-07-10 23:33:54 <sipa> doublec: instead of building a block using the block generation code, and then returning information about which transactions were included in it
255 2012-07-10 23:34:09 <luke-jr> doublec: it's already in use
256 2012-07-10 23:34:24 <walruscode> nimdAHK: thanks for your input :)
257 2012-07-10 23:34:45 <doublec> luke-jr: "in use" doens't mean "easy to maintain, debug and understand"
258 2012-07-10 23:34:49 <nimdAHK> walruscode: I'd be interested in the script when you finish it
259 2012-07-10 23:34:55 <nimdAHK> what are you using, python?
260 2012-07-10 23:34:58 <walruscode> yes
261 2012-07-10 23:35:16 <walruscode> i'll pastebin it when i'm done
262 2012-07-10 23:35:25 <luke-jr> doublec: well, single call or multiple is fence painting, and we already had to change it from multiple methods to overloaded-single-method for bitcoind developers
263 2012-07-10 23:35:51 <luke-jr> I don't really care which way it is, but I'm not interested in endless back-and-forth over it
264 2012-07-10 23:36:03 <sipa> my only complaint ever was that the BIP is too complex
265 2012-07-10 23:36:15 <sipa> and i'm hesitant to start supporting it in that way
266 2012-07-10 23:37:17 <sipa> separate RPCs or not is indeed fence painting
267 2012-07-10 23:37:18 <freewil> which BIP?
268 2012-07-10 23:37:22 <sipa> 22
269 2012-07-10 23:37:31 <luke-jr> sipa: what's too complex about gmp_bip branch (which is all that matters to bitcoind developers)?
270 2012-07-10 23:37:47 <doublec> users of bip 22 need to understand it
271 2012-07-10 23:38:00 <doublec> I had to read that sentence I pasted multiple times to understand it
272 2012-07-10 23:38:13 <sipa> luke-jr: it brings support for BIP22, and i don't like BIP22
273 2012-07-10 23:38:34 <sipa> (that sounds wrong, i very much like the idea; i don't like the fact that it tries to do everything)
274 2012-07-10 23:38:35 <copumpkin> anyone have any hints about what's special about the if family of opcodes?
275 2012-07-10 23:38:40 <luke-jr> sipa: that's political power abuse then ;)
276 2012-07-10 23:39:12 <doublec> what's the 'gmp' stand for?
277 2012-07-10 23:39:20 <doublec> I keep thinking gnu multiprecision but I doubt that
278 2012-07-10 23:39:20 <luke-jr> doublec: getmemorypool
279 2012-07-10 23:39:26 <doublec> ah, oh course, thanks :)
280 2012-07-10 23:39:47 <doublec> I was thinking "finally, no more floats"
281 2012-07-10 23:40:02 <sipa> luke-jr: imho, client developers are the final judges about which proposals they choose their software to accept, no?
282 2012-07-10 23:40:09 <luke-jr> doublec: there's already no floats. JSON has Numbers only.
283 2012-07-10 23:40:25 <luke-jr> sipa: sure, but BIP22 isn't focussed on bitcoind
284 2012-07-10 23:40:30 <luke-jr> sipa: it's focussed on poolservers
285 2012-07-10 23:40:33 <sipa> sure, and it shouldn't be
286 2012-07-10 23:40:54 <luke-jr> if bitcoind only wants to implement a simple subset, that makes sense since it isn't a poolserver
287 2012-07-10 23:41:04 <doublec> so make that subset the bip
288 2012-07-10 23:41:14 <doublec> and implement the rest in the pool server or a proxy
289 2012-07-10 23:41:18 <luke-jr> doublec: &
290 2012-07-10 23:41:26 <sipa> that's not really how it could work
291 2012-07-10 23:41:36 <luke-jr> doublec: the purpose of the BIP is to standardize the protocol; so a client-specific subset wouldn't be a BIP
292 2012-07-10 23:42:11 <doublec> ok, maybe I'm misunderstanding. I thought bip 22 was a request to have that in bitcoind
293 2012-07-10 23:42:22 <sipa> bip22 is the entire proposal
294 2012-07-10 23:42:24 <luke-jr> doublec: no, gmp_bip is a limited subset of BIP22 intended for bitcoind
295 2012-07-10 23:42:28 <doublec> ah ok
296 2012-07-10 23:42:36 <luke-jr> doublec: BIP22 is between Eloipool/ecoinpool/PSJ/etc and miners
297 2012-07-10 23:43:11 <luke-jr> bitcoind<->poolserver just uses a subset, but the full BIP is needed to support poolserver<->miner functionality
298 2012-07-10 23:43:26 <sipa> i disagree that all of it is nedded
299 2012-07-10 23:43:36 <sipa> *needed
300 2012-07-10 23:43:46 <sipa> (though certainly more than what bitcoind would implement, and that is fine)
301 2012-07-10 23:44:07 <luke-jr> sipa: because you aren't a developer of poolserver or mining software
302 2012-07-10 23:45:19 <sipa> luke-jr: but without input from such people (apart from you yourself), i'll have to guess
303 2012-07-10 23:45:53 <luke-jr> sipa: I already answered your questions on everything you asked about why it's needed
304 2012-07-10 23:46:39 <sipa> yes, and my impression from that is that most of it is "this may be useful to someone"
305 2012-07-10 23:46:57 <luke-jr> https://en.bitcoin.it/w/index.php?title=BIP_0022#Rationale
306 2012-07-10 23:48:53 <sipa> just to be clear: i don't dispute the necessity of target, workid, sigops
307 2012-07-10 23:50:10 <sipa> all the rest seems to be "in some cases", or provide different ways of doing the same thing
308 2012-07-10 23:51:37 <luke-jr> pretty sure I removed all redundancy a few months ago
309 2012-07-10 23:54:50 <sipa> meh, three ways of representing the list of transactions, several options just for the coinbase, noncerange, several overlapping mutations, ...
310 2012-07-10 23:55:35 <sipa> yes, just the txid list is the easiest if you just want to mine the block itself without varying anything
311 2012-07-10 23:56:00 <sipa> and yes, in some cases you may want to see the full transactions being included (but there is gettransaction too)
312 2012-07-10 23:56:24 <sipa> and yes, in some cases noncerange may be useful, but there are better solutions imho
313 2012-07-10 23:56:41 <sipa> and yes, servers may be picky about what one may do with the coinbase