1 2013-08-09 03:05:20 <jgarzik> Avalon physical security drama posted on www.avalon-asics.com
  2 2013-08-09 03:13:29 <gjs278> uhh so they're making more products
  3 2013-08-09 03:13:31 <gjs278> ok cool
  4 2013-08-09 03:34:46 <alexwaters> does anyone know where I can find some python code that converts a private key to a WIF private key? I am about to dig through electrum, but it would be cool if someone knows where it lives
  5 2013-08-09 03:36:31 <lianj> alexwaters: is ruby fine too?
  6 2013-08-09 03:36:40 <alexwaters> that's fine
  7 2013-08-09 03:36:47 <lianj> https://github.com/lian/bitcoin-ruby/blob/master/lib/bitcoin/key.rb#L158
  8 2013-08-09 03:36:52 <alexwaters> lianj: thank yoy
  9 2013-08-09 03:36:54 <alexwaters> lianj: thank you
 10 2013-08-09 03:36:57 <Luke-Jr> alexwaters: https://en.bitcoin.it/wiki/Wallet_import_format has a simple overview
 11 2013-08-09 03:38:41 <alexwaters> Luke-Jr: that step one where it says take a private key. Is there information on what requirements that private key must have? I'm assuming it has to be hex, no?
 12 2013-08-09 03:39:01 <alexwaters> Luke-Jr: thank you btw
 13 2013-08-09 03:39:12 <Luke-Jr> err, it has to be binary
 14 2013-08-09 03:39:46 <Luke-Jr> beyond that, there are some limitations, but it can *mostly* be any binary data
 15 2013-08-09 03:40:07 <Luke-Jr> the WIF exists because otherwise it couldn't be identified as such
 16 2013-08-09 03:46:18 <turboroot> alexwaters: if you still need an example, here's a direct example in golang https://gist.github.com/turboroot/6033908#file-bitcoingen-go-L84-L111
 17 2013-08-09 03:46:53 <alexwaters> oh cool, thanks turboroot
 18 2013-08-09 03:58:53 <lianj> turboroot: it skips compressed addresses?
 19 2013-08-09 03:59:26 <turboroot> lianj: oh yeah
 20 2013-08-09 03:59:42 <lianj> just add a 0x01 at the end before checksuming
 21 2013-08-09 03:59:43 <turboroot> lianj: just from a private key to wif
 22 2013-08-09 04:00:34 <lianj> no, if you have a private key that is used as a compressed pubkey address, this wif would be broken
 23 2013-08-09 04:02:15 <turboroot> lianj: the example is meant to take a private key directly from generation: https://gist.github.com/turboroot/6033908#file-bitcoingen-go-L16
 24 2013-08-09 04:03:04 <lianj> ah ok
 25 2013-08-09 04:03:49 <lianj> be nice on the network and show them how to generate compressed addresses :P
 26 2013-08-09 04:03:51 <Luke-Jr> turboroot: nobody should be using uncompressed keys anymore though!
 27 2013-08-09 04:04:23 <turboroot> i should go fix that then :)
 28 2013-08-09 06:02:13 <Vinnie_win> wuddup peeps
 29 2013-08-09 06:17:35 <alexwaters> in step 6 of http://gobittest.appspot.com/PrivateKey - I am getting a different step 7 with the same hex string. here is the code: http://pastie.org/8221059 - what I am doing incorrectly?
 30 2013-08-09 06:26:59 <alexwaters> oops I meant: http://pastie.org/8221074
 31 2013-08-09 12:08:16 <jgarzik> sipa, gavinandresen, gavinandresen_: is there any sort of canonical ordering of signatures, in a multi-sig transaction?  My "txtool" already does multi-sig P2SH transactions: https://github.com/jgarzik/txtool/blob/master/examples/multisig.txt
 32 2013-08-09 12:08:31 <jgarzik> Now I'm working on combining signatures myself, rather than handing it off to bitcoind to do the work for me
 33 2013-08-09 12:08:58 <jgarzik> CombineSignatures-area code in script.cpp seems to use a map, which would imply a sort
 34 2013-08-09 12:09:11 <jgarzik> and therefore a predictable ordering of signatures
 35 2013-08-09 12:11:46 <jgarzik> 
ACTION also wonders if there is a canonical or preferred ordering of pubkeys/pubkeyhashes, in the script.  But that is a much less important question.

 36 2013-08-09 12:12:00 <sipa> jgarzik: well, the assumption for any P2SH stuff is that you know the actual redeem script
 37 2013-08-09 12:12:26 <jgarzik> sipa, ?or can rebuild it :)
 38 2013-08-09 12:13:03 <sipa> for simple p2sh types i suppose a canonical ordering makes sense
 39 2013-08-09 12:13:52 <sipa> but in settings where for example the keys are taken from BIP32 chains, you probably want the order of the chains fixed, rather than re-order the keys in every instance
 40 2013-08-09 12:14:05 <jgarzik> yep
 41 2013-08-09 12:14:10 <sipa> so in general, imho, it is the wallets responsability to maintain the ability to come up with the scripts
 42 2013-08-09 12:15:25 <jgarzik> Yep.  Adding that to wally (SPV node.js client) and txtool (command line multi-party signature helper) right now.
 43 2013-08-09 12:16:40 <jgarzik> For combining signatures (scriptSig), it is easiest to simply append new signatures onto the end of the list (after, perhaps, removing and replacing the P2SH blob) regardless of order
 44 2013-08-09 12:16:45 <jgarzik> And just filter out dups
 45 2013-08-09 12:17:05 <jgarzik> Presumably the wallet already knows the script, a la bitcoind
 46 2013-08-09 12:17:36 <jgarzik> hmmm.  I guess a good check might be that all wallets in a multi-party transaction agreement that the P2SH in the scriptSig is correct.
 47 2013-08-09 12:17:45 <jgarzik> *agree
 48 2013-08-09 12:18:11 <jgarzik> (my stuff involves multiple humans, passing around partially signed transactions, and signing them)
 49 2013-08-09 12:21:45 <TD> jgarzik: btw what's the rationale for writing wally?
 50 2013-08-09 12:23:14 <jgarzik> TD, BitPay wanted a node.js SPV wallet. Not much more complex than that.  BitPay can use it as a reference implementation for future wallet features.
 51 2013-08-09 12:23:31 <jgarzik> TD, Internally, bitcoind's wallet isn't scaling
 52 2013-08-09 12:23:47 <sipa> indeed, it doesn't scale
 53 2013-08-09 12:23:54 <sipa> at least not with the current design, or interface
 54 2013-08-09 12:24:54 <TD> jgarzik: that's circular. why does bitpay want one? :)
 55 2013-08-09 12:25:23 <TD> jgarzik: sure, i was wondering bitcoind scalability could be improved instead, or you could improve bitcoinj. is there some super strong reason it _has_ to be node.js ?
 56 2013-08-09 12:25:32 <TD> and won't that potentially lead to scaling issues of its own, due to the lack of real threading?
 57 2013-08-09 12:26:33 <jgarzik> TD, BitPay likes node.js, you know how it goes ;p   "the lingua franca of the Internet" and all that
 58 2013-08-09 12:26:35 <Ry4an> TD: because that's what the people doing the paying asked for.
 59 2013-08-09 12:27:09 <jgarzik> TD, RE scaling? it can do multi-process quite easily, so easily address if CPU usage becomes an issue
 60 2013-08-09 12:27:15 <jgarzik> *addressed
 61 2013-08-09 12:27:28 <jgarzik> node.js stuff also uses C++ modules in some circumstances
 62 2013-08-09 12:27:46 <jgarzik> so ECDSA is pure compiled code
 63 2013-08-09 12:28:46 <TD> yeah, as long as you can parallelise everything without shared state (or by keeping it in c++) i guess it can work
 64 2013-08-09 12:28:53 <helo> i hate that most programming jobs around here want experience with multi-threaded
 65 2013-08-09 12:29:15 <TD> oh well. i was hoping you'd be able to focus on big upgrades of bitcoind.  a full spv wallet in javascript is quite a lot of work. i guess it will keep you busy for the forseeable future
 66 2013-08-09 12:29:42 <TD> helo: why? that doesn't seem unreasonable.
 67 2013-08-09 12:30:18 <jgarzik> TD, There remains a focus on the "sipa vision" of bitcoind, as a public blockchain server / border router
 68 2013-08-09 12:30:23 <jgarzik> TD, Just not on the wallet side
 69 2013-08-09 12:30:28 <TD> ok
 70 2013-08-09 12:30:49 <TD> btw what's bitpay's plan for the payment protocol? any roadmap yet?
 71 2013-08-09 12:30:50 <sipa> 
ACTION sometimes does feel he's the only one actually working on that...

 72 2013-08-09 12:31:41 <jgarzik> BitPay vision seems to be "enterprise wallet platform" (node-libcoin) + "p2p blockchain" (bitcoind)
 73 2013-08-09 12:32:19 <jgarzik> sipa, one option might be to add #ifdefs to the wallet code, just to have an early method of experimenting with a wallet-free bitcoind
 74 2013-08-09 12:32:26 <helo> TD: multi-threading has its uses, but i've seen it misused more often than not
 75 2013-08-09 12:32:35 <TD> that's too bad.
 76 2013-08-09 12:32:37 <sipa> jgarzik: just don't load/register one in init.cpp; done
 77 2013-08-09 12:32:49 <sipa> i doubt there are other issues
 78 2013-08-09 12:33:05 <sipa> right, many rpcs point to pwalletMain directly
 79 2013-08-09 12:33:12 <sipa> the multiwallet stuff fixed that
 80 2013-08-09 12:33:14 <jgarzik> sipa, probably a few assumptions of pwalletMain scattered
 81 2013-08-09 12:33:15 <sipa> but...
 82 2013-08-09 12:34:19 <jgarzik> sipa, I could add -nowallet, then
 83 2013-08-09 12:34:35 <sipa> meh
 84 2013-08-09 12:34:52 <jgarzik> true no-wallet operation would excise several RPCs altogether
 85 2013-08-09 12:34:56 <sipa> multiwallet refactoring would lead to much cleaner code
 86 2013-08-09 12:35:19 <sipa> even for the case where only 0 or 1 wallets are loaded
 87 2013-08-09 12:35:24 <jgarzik> TheUni, (aside) how close to merging autotools?
 88 2013-08-09 12:35:45 <jgarzik> sipa, what remains?  the internal multi-wallet stuff seems there
 89 2013-08-09 12:35:58 <jgarzik> obviously no UI multi-wallet stuff exists (AFAIK)
 90 2013-08-09 12:36:06 <sipa> CodeShark had a walletloader pull-request
 91 2013-08-09 12:36:12 <sipa> that's pretty much what's needed i think
 92 2013-08-09 12:36:36 <sipa> and you need some rpc redesign
 93 2013-08-09 12:36:43 <sipa> as some rpcs implicitly assume a wallet
 94 2013-08-09 12:36:52 <sipa> so those need to be moved to a wallet-specific addressing
 95 2013-08-09 12:37:51 <sipa> reason i'm not immediately saying "just remove the wallet code altogether", is because i'd like to see at least bitcoin-qt (the released binary) move to an SPV wallet
 96 2013-08-09 12:38:18 <sipa> once we have headers-first, i think SPV will be Really Easy(tm), as the actual wallet code doesn't rely on the blockchain being present
 97 2013-08-09 12:41:17 <jgarzik> headers-first will be nice for several reasons
 98 2013-08-09 12:41:24 <sipa> yes
 99 2013-08-09 12:41:42 <sipa> the sugar is faster downloads, but that's not actually why i want it :)
100 2013-08-09 12:41:56 <jgarzik> multi-peer downloads, even
101 2013-08-09 12:42:01 <sipa> read https://github.com/sipa/bitcoin/commit/527ac0aa599bca6d0c9ca19370e901ab61fabd08 :)
102 2013-08-09 12:43:49 <petertodd> jgarzik: by signatures do you actually mean pubkeys, or do you really mean the signatures themselves?
103 2013-08-09 12:44:01 <jgarzik> petertodd, the signatures themselves.  scriptSig
104 2013-08-09 12:44:16 <jgarzik> TD, BitPay wants to be first out of the gate supporting the payment protocol
105 2013-08-09 12:44:25 <petertodd> jgarzik: right, ordering them by pubkey order seems pretty logical to me, and canonical pubkey order sounds obvious
106 2013-08-09 12:44:25 <TD> super!
107 2013-08-09 12:44:34 <jgarzik> TD, definitely want to support it, in all its glory ;p
108 2013-08-09 12:44:43 <sipa> \\o/
109 2013-08-09 12:44:59 <TD> sipa: *competitive* SPV means using bloom filtering and possibly first-run checkpointing as well.
110 2013-08-09 12:45:12 <TD> jgarzik: spiffy. i guess you'll sign all requests as BitPay LLC?
111 2013-08-09 12:45:21 <jgarzik> petertodd, CombineMultisig() seems to have an order it prefers
112 2013-08-09 12:45:25 <sipa> TD: bloom filtering is already implemented :p
113 2013-08-09 12:45:26 <TD> it'd be cool if merchants were willing to share their SSL private keys, but i suspect many would balk at that
114 2013-08-09 12:45:44 <TD> sipa: you know what i mean :p
115 2013-08-09 12:45:46 <jgarzik> sipa, NIH ;p
116 2013-08-09 12:46:11 <petertodd> jgarzik: Oh, I just checked: EvalScript() mandates they be ordered by corresponding pubkey.
117 2013-08-09 12:46:19 <sipa> wut?
118 2013-08-09 12:46:22 <sipa> oh yes
119 2013-08-09 12:46:29 <sipa> the signatures have to be in the order of the pubkeys
120 2013-08-09 12:46:34 <sipa> but the pubkeys have no enforced order
121 2013-08-09 12:47:03 <petertodd> sipa: yup, so order pubkeys lexigraphically and we're all good
122 2013-08-09 12:47:22 <sipa> TD: what i mean is that bitcoin-qt is a well-tested and trusted wallet client, and it's currently mostly hurt by the fact that it unnecessarily depends on a local full block chain
123 2013-08-09 12:47:27 <jgarzik> 
ACTION wrote https://github.com/gasteve/node-libcoin/blob/master/Bloom.js a little while ago.  Still untested, probably broken due to JavaScript's complete inability to do math (a basic function of computers...)

124 2013-08-09 12:47:40 <sipa> TD: and i don't think the work to remove that dependency is much
125 2013-08-09 12:48:02 <jgarzik> the pubkeys have an order, once locked in via P2SH
126 2013-08-09 12:48:10 <TD> yeah
127 2013-08-09 12:48:12 <petertodd> jgarzik: oh, reminds me, I have bloom for python-bitcoinlib half-done too
128 2013-08-09 12:48:15 <sipa> petertodd: or order them lexicographically by the BIP32 chain fingerprint they are from?
129 2013-08-09 12:48:23 <sipa> petertodd: imho, this is all up to wallet implementations
130 2013-08-09 12:48:26 <jgarzik> petertodd, send a pull req :)
131 2013-08-09 12:48:36 <sipa> and for compatibility, they shouldn't require a specific ordering
132 2013-08-09 12:48:49 <sipa> as multisig inherently means wallets will need to cooperate
133 2013-08-09 12:48:51 <petertodd> jgarzik: yup, I'm telling you so I'll feel embarassed if I don't finish this weekend :)
134 2013-08-09 12:48:51 <TD> fwiw the micropayment channel code fixes the ordering as part of the protocol spec
135 2013-08-09 12:49:06 <jgarzik> sipa, yes
136 2013-08-09 12:49:21 <petertodd> sipa: Hmm... is there any reason not to always order them within a given P2SH lexigraphically? Like, when wouldn't that be convenient?
137 2013-08-09 12:49:46 <sipa> petertodd: as long as we're limited to M-of-N things, that's probably fine
138 2013-08-09 12:49:53 <sipa> i just don't see it generalizing further
139 2013-08-09 12:50:07 <sipa> and ultimately, you just need everyone involved to know the script
140 2013-08-09 12:50:19 <petertodd> sipa: Ah, right, I mean checkmultisig M-of-N only - advanced stuff like OTP's and master keys is a whole 'nother issue...
141 2013-08-09 12:50:24 <jgarzik> if there was a well known order
142 2013-08-09 12:50:28 <jgarzik> that makes it easy to recreate the script
143 2013-08-09 12:50:30 <sipa> which may mean more metadata that can't be reconstructed just from the pubkeys
144 2013-08-09 12:50:41 <sipa> so if you make createmultisigaddress order pubkeys, sure
145 2013-08-09 12:50:57 <sipa> as long as the addmultisigaddress or whatever works with any order
146 2013-08-09 12:51:21 <sipa> and that may mean that createmultisigaddress needs to reorder the input and echo it back, so that other involved parties may import it
147 2013-08-09 12:52:06 <petertodd> sipa: IMO at the RPC layer make the "cooked" versions - create/add multisig (especially add) follow the strict order and provide addredeemscript for the rare case where you have to manually do something odd.
148 2013-08-09 12:52:45 <sipa> right, just don't require every wallet implementation to agree with your default ordering
149 2013-08-09 12:53:07 <sipa> jgarzik: not sure what you meant by NIH above, btw?
150 2013-08-09 12:53:20 <petertodd> sipa: well... if we don't mandate it, at least in the context of stuff that needs compatibility, then a default ordering just isn't as useful
151 2013-08-09 12:53:28 <sipa> petertodd: that's my point
152 2013-08-09 12:53:33 <petertodd> sipa: I'm not saying we make this a protocol rule with a soft-fork :)
153 2013-08-09 12:54:49 <petertodd> sipa: example where it matters: if you are abusing checkmultisig for timestamps, you want the digest last so you can use SHA256 midstates, but that's a way non-std use-case that has nothing to do with wallets
154 2013-08-09 13:00:21 <MC1984> high IOPS is good for chain building right
155 2013-08-09 13:01:12 <petertodd> yup
156 2013-08-09 13:01:18 <sipa> or high dbcache
157 2013-08-09 13:01:19 <MC1984> 100,000 is pretty high IOPS isnt it
158 2013-08-09 13:01:39 <MC1984> oh yes dbcache is even better
159 2013-08-09 13:01:51 <petertodd> pretty good for storage yes
160 2013-08-09 13:02:04 <MC1984> the chain is written out sequentially from dbcache then
161 2013-08-09 13:02:23 <sipa> with a few gigs of dbcache, you only need to write to disk once really
162 2013-08-09 13:03:03 <MC1984> god the thing im most excited about is seeing how fast a IDB runs #suchanerd
163 2013-08-09 13:11:03 <petertodd> jgarzik: So, does javascript have, say, a reasonably fast multiprecision integer library?
164 2013-08-09 13:56:53 <helo> got a blockchain corruption error when i rebooted last night :(
165 2013-08-09 13:58:00 <helo> not sure exactly what git commit it's on though
166 2013-08-09 14:13:51 <alexwaters> does anyone mind pointing out what Im doing wrong here: http://pastie.org/8221074 - I'm not getting the expected step 7 of private key to WIF
167 2013-08-09 14:14:18 <alexwaters> it's slightly different
168 2013-08-09 14:15:14 <jgarzik> petertodd, yes
169 2013-08-09 14:15:31 <jgarzik> petertodd, It's pretty easy to write C++ modules for node.js
170 2013-08-09 14:16:03 <jgarzik> sipa, NIH == not invented here == joking that I reimplemented bloom filter code all over again
171 2013-08-09 14:17:01 <lianj> alexwaters: bitcoin base58 uses/prepend leading zeros
172 2013-08-09 14:26:49 <alexwaters> lianj: ahhh sweet, got it. sorry I didn't realize it was needed for WIF priv keys. thank you
173 2013-08-09 14:30:38 <lianj> hm actually, maybe it doesn't
174 2013-08-09 15:43:27 <jgarzik> hmmm
175 2013-08-09 15:44:00 <jgarzik> so signature order is dictated by pubkey order, for multisig?
176 2013-08-09 15:45:05 <jgarzik> It would seem to make it difficult to know an insertion point for your signature, if you do not know all pubkeys -and- which signatures were provided by which pubkeys
177 2013-08-09 15:46:13 <jgarzik> i.e. txtool is given a 5-of-7 multisig TX to sign.  it has 3 signatures.  Our pubkey is the 2nd in line.  where to insert the signature?
178 2013-08-09 15:47:05 <jgarzik> gavinandresen, gmaxwell ?
179 2013-08-09 15:50:48 <sipa> jgarzik: the dummy you create has 7 ""-signatures from the start, you replace the ones corresponding with the pubkeys you know with the correct signature
180 2013-08-09 15:50:57 <sipa> jgarzik: and then before final broadcast, drop the remaining zeros
181 2013-08-09 15:59:18 <jgarzik> sipa, ah!
182 2013-08-09 15:59:36 <jgarzik> sipa, tnx
183 2013-08-09 17:23:35 <alexwaters> lianj: alright to PM?
184 2013-08-09 18:04:23 <CodeShark> jgarzik: the problem you were speaking of sounds a lot like what I did here: https://github.com/CodeShark/CoinClasses/tree/master/examples/txbuilder
185 2013-08-09 18:05:35 <CodeShark> what sipa proposed is actually exactly what I did :)
186 2013-08-09 18:06:24 <CodeShark> I created an "edit" format for a transaction which uses NO_OP place holders for missing signatures
187 2013-08-09 18:09:07 <CodeShark> I'm now working on a way to interface a transaction store with a key chain
188 2013-08-09 18:09:21 <CodeShark> and on a protocol for requesting signatures from other nodes
189 2013-08-09 18:10:46 <CodeShark> I want to improve that TransactionBuilder class, though - to make it more generic and work more directly with the script
190 2013-08-09 18:11:03 <CodeShark> rather than just hardcoding a couple standard transaction types
191 2013-08-09 18:13:53 <CodeShark> the idea is to be able to provide an arbitrary txout to a key chain and have the key chain supply the complete redeem script for the input - and to have a signer which can sign the transaction once it's fully assembled
192 2013-08-09 18:16:17 <CodeShark> for full security, it would be necessary to provide not only the txout but the complete transaction containing the txout (so that the output amount can be verified)
193 2013-08-09 18:17:29 <CodeShark> so something like getRedeemScript(fulltx, outindex)
194 2013-08-09 18:17:46 <CodeShark> the redeemscript would just have NO_OPS for signature placeholders
195 2013-08-09 18:19:12 <CodeShark> although ideally I'd like the missing signature placeholders directly incorporated into the scripting language itself
196 2013-08-09 18:19:45 <CodeShark> and the output amounts incorporated into the hash that ultimately gets signed
197 2013-08-09 18:23:52 <CodeShark> actually, more correct would probably be getScriptSig
198 2013-08-09 18:24:31 <CodeShark> since redeemscript in the literature only refers to the part of scriptsig that gets popped off the stack per BIP0016
199 2013-08-09 18:40:52 <devrandom> if anybody is interested, I have a pull request for electrum that integrates offline+multisig+HD
200 2013-08-09 18:40:55 <devrandom> https://github.com/spesmilo/electrum/pull/266
201 2013-08-09 19:00:29 <TD> devrandom: cool!
202 2013-08-09 19:01:19 <TD> 
ACTION wishes that there was a decent block explorer tool out there

203 2013-08-09 19:04:45 <CodeShark> what features would you like it to have?
204 2013-08-09 19:07:55 <Luke-Jr> CodeShark: integrated into your own full node
205 2013-08-09 19:08:28 <Luke-Jr> other than that, it shouldn't misrepresent how Bitcoin works :p
206 2013-08-09 19:08:52 <CodeShark> the first step would probably be to abstract the storage engine from the validation/relay engine so that different storage engines can be plugged in with different index options
207 2013-08-09 19:09:29 <Luke-Jr> I don't see why that's necessary.
208 2013-08-09 19:09:46 <Luke-Jr> I think with sipa's address index, no more indexes are necessary.
209 2013-08-09 19:10:25 <CodeShark> I've found use for other indices - for instance, tracking addresses that are known to be in the same wallet
210 2013-08-09 19:11:33 <CodeShark> and there could conceivably be other useful indices. I've had use for quick searches by script pattern matches, for instance
211 2013-08-09 19:11:51 <CodeShark> when trying to find particular types of transactions
212 2013-08-09 19:12:19 <CodeShark> or searches by transactions containing a minimum number of inputs or outputs
213 2013-08-09 19:12:45 <CodeShark> anyhow, bitcoind should be a lean and mean verification/relay engine
214 2013-08-09 19:12:51 <CodeShark> and should NOT focus on bloated storage
215 2013-08-09 19:13:39 <CodeShark> it should use a storage engine optimized for size and speed for only the queries necessary to perform full validation
216 2013-08-09 19:14:25 <CodeShark> by abstracting the storage engine it would be possible to hook up fatter backends for block explorer type apps
217 2013-08-09 19:15:00 <CodeShark> which could provide much fatter interfaces, like SQL or whatever
218 2013-08-09 19:15:05 <gmaxwell> sure, such as abe, which now needs like 200gb disk space and 16 gb ram to load its data in a month or so. block explorers for everyone!
219 2013-08-09 19:15:47 <CodeShark> apps like abe are far more optimized for searches than for insertions
220 2013-08-09 19:15:54 <CodeShark> insertions are SLOOOOOWWW
221 2013-08-09 19:16:50 <CodeShark> I also have an SQL block explorer I wrote - and yes, it takes forever to sync from scratch
222 2013-08-09 19:18:25 <CodeShark> but it's still possible in principle to have a more efficient storage engine that still provides an SQL interface
223 2013-08-09 19:18:29 <gmaxwell> "forever to sync from scratch" basically means "writing software for centeralized websites for free", if thats your thing, knock yourself out... but ecosystem wise I think we generally need less dependance on things like that.
224 2013-08-09 19:18:59 <gmaxwell> yea, sure, indeed. And what will you do a decade from now after you're done reinventing RDBMSs? :P
225 2013-08-09 19:19:06 <CodeShark> lol
226 2013-08-09 19:19:17 <CodeShark> that type of app is not currently my focus anymore :p
227 2013-08-09 19:19:38 <CodeShark> I've actually gone the opposite direction - trying to identify the minimal amount of data required to process transactions securely
228 2013-08-09 19:20:18 <CodeShark> barebones SPV
229 2013-08-09 19:45:11 <TD> Luke-Jr: a real-time view of pending transactions and their position inside the next block
230 2013-08-09 19:45:25 <TD> Luke-Jr: amongst other things. also ability to see all blocks in a timeline with their sizes
231 2013-08-09 19:45:27 <Luke-Jr> TD: bitcoind has that.. <.<
232 2013-08-09 19:45:41 <Luke-Jr> TD: but you can only know what position *you'd* give them
233 2013-08-09 19:45:44 <TD> sure
234 2013-08-09 19:45:46 <Luke-Jr> which is all that's possible anyway
235 2013-08-09 19:45:53 <Luke-Jr> so, not very useful to non-miners
236 2013-08-09 20:36:30 <CodeShark> argh! anyone here ever have any success using websocketpp on OS X?
237 2013-08-09 20:39:24 <c0rw1n> was browserver using websocket? if so, yes
238 2013-08-09 20:39:42 <CodeShark> were you using C++11?
239 2013-08-09 20:39:54 <c0rw1n> no, that's all web
240 2013-08-09 20:40:03 <c0rw1n> not my code mind you
241 2013-08-09 20:40:27 <CodeShark> I'm talking specifically about the C++ websocketpp library: https://github.com/zaphoyd/websocketpp
242 2013-08-09 20:40:42 <c0rw1n> ah ok no i didn't try that i know
243 2013-08-09 20:41:23 <CodeShark> having problems with throw specifiers
244 2013-08-09 20:41:53 <CodeShark> also having problems with throw specifiers in boost
245 2013-08-09 20:42:41 <c0rw1n> i really can't help you. those kinda things are why i don't c++
246 2013-08-09 20:43:06 <c0rw1n> abstruse "errything is a type" weird academically-perfect language
247 2013-08-09 20:45:05 <CodeShark> academically-perfect language would be more like LISP
248 2013-08-09 20:45:15 <CodeShark> C++ is hardly academically perfect :p
249 2013-08-09 20:45:46 <CodeShark> it's full of special constructs added just to make specific engineering tasks simpler
250 2013-08-09 20:47:04 <CodeShark> full of ad-hoc features, supporting a vast number of conflicting idioms
251 2013-08-09 20:47:14 <CodeShark> *mutually conflicting
252 2013-08-09 20:47:28 <CodeShark> and styles
253 2013-08-09 20:47:57 <CodeShark> an academically perfect language is minimal and regular
254 2013-08-09 21:20:03 <HaltingState> Is anyone here going to burning man?
255 2013-08-09 21:22:35 <TheLordOfTime> HaltingState:  don't super crosspost
256 2013-08-09 21:32:02 <warren> https://github.com/bitcoin/bitcoin/pull/2658  any thoughts?  I hope I didn't unduly slow this down with the problem I saw earlier but now am unable to reproduce.  It seems that this patch is capable of reporting false positives and could scare users unnecessarily.
257 2013-08-09 21:36:26 <sipa> warren: i'll comment on the pr still, but i'd like to delay that until after headers-first sync (i'm very close to a fully-featured implementation)
258 2013-08-09 21:37:09 <sipa> as it means you always have the correct view of the block chain, even without having the relevant blocks, this becomes a lot more robust
259 2013-08-09 21:38:31 <warren> sipa: nice!
260 2013-08-09 21:38:51 <gmaxwell> wrt headers first sync, I think that should be integrated sooner rather than later, as it will take some time pounding on it to hammer out any corner case issues.
261 2013-08-09 21:39:10 <sipa> well, right now, reindex segfaults :p
262 2013-08-09 21:39:20 <warren> pounding
263 2013-08-09 21:39:38 <gmaxwell> sipa: right, well, as soon as it stops reliably failing for you. :)
264 2013-08-09 21:39:55 <warren> I'm not sure *how* I saw scary fork warnings during -reindex twice in a row.  that's supposed to fix corrupt chain state right?
265 2013-08-09 21:40:32 <sipa> was that with that chain split detect code merged in?
266 2013-08-09 21:41:24 <warren> yes, we tested litecoin-0.8.x with those three patches added for about a 1 month, and pulled it after I saw it print scary things in debug.log during -reindex.  I didn't have time to investigate back then, and now I can't reproduce the problem.
267 2013-08-09 22:28:52 <phantomcircuit> oh boy
268 2013-08-09 22:29:09 <phantomcircuit> someone sent tons of tiny transfers to the intersango hotwallet
269 2013-08-09 22:29:10 <phantomcircuit> fun
270 2013-08-09 22:34:54 <phantomcircuit> i should not have tried to open this wallet in bitcoin-qt
271 2013-08-09 23:19:23 <phantomcircuit> gmaxwell, apparently this wallet is large enough that new blocks are causing a bdb crash
272 2013-08-09 23:19:25 <phantomcircuit> fun
273 2013-08-09 23:19:39 <phantomcircuit> *** System error: CDB() : can't open database file wallet.dat, error -30974
274 2013-08-09 23:22:45 <gmaxwell> /usr/include/libdb/db.h:#define DB_REP_WOULDROLLBACK    (-30974)/* UNDOC: rollback inhibited by app. */
275 2013-08-09 23:23:43 <gmaxwell> I ... am vaguely guessing thats saying that the undo data and the database itself are inconsistent?
276 2013-08-09 23:23:49 <phantomcircuit> #define DB_RUNRECOVERY          (-30974)/* Panic return. */
277 2013-08-09 23:24:05 <phantomcircuit> i guess the error numbers are version dependent
278 2013-08-09 23:24:10 <phantomcircuit> this is using db4.8
279 2013-08-09 23:24:14 <gmaxwell> yea, crazy I see that.
280 2013-08-09 23:24:43 <phantomcircuit> anyways opening the wallet again everything is fine
281 2013-08-09 23:24:57 <phantomcircuit> so im thinking it's dying trying to change too many things or something
282 2013-08-09 23:25:14 <phantomcircuit> i guess it's time to export all the keys and start over
283 2013-08-09 23:26:14 <phantomcircuit> how does someone not see the correlation???
284 2013-08-09 23:26:29 <phantomcircuit> er
285 2013-08-09 23:44:15 <alexwaters> the first time I call generate_btc_address(0x552219f09e1b3537df689113be859f6bd0e57c403bb7ac10fd4ec7c07b378f01) it generates the expected addr_58, but any additional calls return a different addr_58. I'm assuming because it is not resetting the curve on additional calls. Can anyone confirm that that's the reason? http://pastie.org/8223335
286 2013-08-09 23:50:51 <gmaxwell> resetting the curve?!
287 2013-08-09 23:51:35 <alexwaters> gmaxwell: i have no idea what i'm doing, lol. I'm assuming it's doing something with a stored value instead of reinitializing every time the function is run
288 2013-08-09 23:52:10 <alexwaters> gmaxwell: i don't want that function to have a state, but it seems to and I don't know why
289 2013-08-09 23:55:17 <alexwaters> ah never mind, the ripehash had to be localized. got it :)