1 2013-07-31 00:00:11 realazthat is now known as pinkee
   2 2013-07-31 00:00:25 <petertodd> SPV nodes for one
   3 2013-07-31 00:00:47 <sipa> even SPV nodes will want to ask for the data in it (perhaps just filtered)
   4 2013-07-31 00:01:02 pinkee is now known as pinkie
   5 2013-07-31 00:01:06 <petertodd> not all SPV nodes in the future will even want transactions at all
   6 2013-07-31 00:01:11 pinkie is now known as peenkee
   7 2013-07-31 00:01:12 <sipa> (playing devil's advocate here)
   8 2013-07-31 00:01:19 peenkee is now known as pinkee
   9 2013-07-31 00:01:27 <sipa> do you have a use case for that?
  10 2013-07-31 00:01:51 <petertodd> we also should try to distribute headers as fast as possible, because miners will want to know so they can change their mining strategy to produce smaller blocks when they know their block is about to be killed
  11 2013-07-31 00:01:55 <petertodd> timestamping
  12 2013-07-31 00:02:06 <petertodd> and really anything that needs a random beacon
  13 2013-07-31 00:02:08 <sipa> right
  14 2013-07-31 00:02:37 <petertodd> also SPV is more secure if you are peering with other SPV nodes - lets you have fewer full nodes, and/or better able to detect if the full nodes are lying
  15 2013-07-31 00:03:00 bmcgee has joined
  16 2013-07-31 00:03:06 <sipa> i'm not opposed to a p2p way to request "send me headers, even without blocks"
  17 2013-07-31 00:03:31 tg has joined
  18 2013-07-31 00:03:34 <sipa> and we can probably do without the inv-getdata cycle in between, as a headers packet is hardly larger than an inv
  19 2013-07-31 00:03:44 <petertodd> I guess the main thing is how do you say "well I've got a header INV, but not a block yet"
  20 2013-07-31 00:03:54 <sipa> you just broadcast the header
  21 2013-07-31 00:04:05 ralphtheninja has joined
  22 2013-07-31 00:04:09 <sipa> hmm
  23 2013-07-31 00:04:40 <petertodd> oh, right, yes just broadcasting the header is fine
  24 2013-07-31 00:04:48 <sipa> i think that could work, but some marker to indicate "not in a block" is perhaps safer and easier to handle
  25 2013-07-31 00:04:51 marco__ has joined
  26 2013-07-31 00:05:19 <Luke-Jr> sipa, petertodd: In case either of you are interested, apparently you don't need to be an industry member to run for the industry seat in the BC Foundation (but you do need an industry member to nominate you)
  27 2013-07-31 00:05:36 <sipa> i hate politics
  28 2013-07-31 00:05:47 <Luke-Jr> who doesn't? :p
  29 2013-07-31 00:07:05 <petertodd> sipa: well, lets have a header INV type, or I mean, whatever you produce in response to a getheaders, and add a flag for "I have this block"
  30 2013-07-31 00:07:32 <sipa> petertodd: for backward compatibility, rather add a flag for "I don't have this block"
  31 2013-07-31 00:08:08 <petertodd> sipa: right, but I thought we didn't already have a header data type at all? or are you sending what an SPV node would otherwise get?
  32 2013-07-31 00:08:27 marco__ has quit (Client Quit)
  33 2013-07-31 00:08:30 <sipa> you send a "headers" message in response to a "getheaders" message
  34 2013-07-31 00:08:43 kadoban has joined
  35 2013-07-31 00:08:45 marco__ has joined
  36 2013-07-31 00:09:17 <sipa> it's the same mechanism that SPV nodes use to sync, yes
  37 2013-07-31 00:09:19 <petertodd> ah, ok, I didn't realize we already had getheaders
  38 2013-07-31 00:09:25 <jgarzik> yes, "headers" message was added when "getheaders" message was added
  39 2013-07-31 00:09:30 <jgarzik> which was >year ago at least
  40 2013-07-31 00:09:36 <jgarzik> I think Satoshi added it?
  41 2013-07-31 00:09:41 <sipa> jgarzik: it's been there as long as i remember
  42 2013-07-31 00:09:44 * petertodd hasn't studied the network code enough
  43 2013-07-31 00:09:52 <sipa> and i first looked at the code in december 2010 or so
  44 2013-07-31 00:09:53 <jgarzik> as part of his half-hearted fClient effort
  45 2013-07-31 00:10:23 <sipa> was added in 0.3.18
  46 2013-07-31 00:10:46 <petertodd> I see, so getheaders was added, but of course until your work "headers" is ignored
  47 2013-07-31 00:11:01 <sipa> indeed, no handler for 'headers' existed
  48 2013-07-31 00:11:07 <jgarzik> [mildly] related,
  49 2013-07-31 00:11:07 <jgarzik> has the hard fork happened yet?
  50 2013-07-31 00:11:22 <sipa> not afaik
  51 2013-07-31 00:11:47 <petertodd> sipa: hmm... problematic, because who knows how SPV clients will handle any data added to the vHeaders vector?
  52 2013-07-31 00:12:07 <sipa> petertodd: well you don't add anything unless negotiated to do so
  53 2013-07-31 00:12:11 Pengoo has quit (Ping timeout: 245 seconds)
  54 2013-07-31 00:12:19 marco__ has quit (Client Quit)
  55 2013-07-31 00:12:34 <petertodd> sipa: ok, so make it a protocol version thing?
  56 2013-07-31 00:12:47 bbrian has joined
  57 2013-07-31 00:12:49 <sipa> that's possible, but i'm not sure i want to enforce such functionality
  58 2013-07-31 00:12:53 <petertodd> sipa: bump to 70003? (I have a good use for 70002...
  59 2013-07-31 00:13:26 <sipa> (and even it's not strict enforcing, version numbers are a linear sequence, so you can't have a client that says "i don't want the feature added in 70003, but i do want the one added in 70004"
  60 2013-07-31 00:13:49 <petertodd> I'm basically thinking, if your peer is >= 70003, then "headers" is defined to have "I have this block", and if that is set, don't expect me to follow it up with an INV
  61 2013-07-31 00:13:57 <sipa> that doesn't work
  62 2013-07-31 00:14:05 <sipa> it's always min(your_version, peer_version)
  63 2013-07-31 00:14:22 <sipa> but there is technically no problem
  64 2013-07-31 00:14:23 <petertodd> the alternative would be to just send headers if all we have is headers, and an INV if we have both
  65 2013-07-31 00:14:30 [\\\] has quit (Remote host closed the connection)
  66 2013-07-31 00:14:33 <petertodd> which means sometimes will send both in the end
  67 2013-07-31 00:14:37 <sipa> you could just declare that 'headers' never indicates the presence of a full block
  68 2013-07-31 00:14:40 <petertodd> IMO that's fine, 80 bytes is nothing
  69 2013-07-31 00:14:47 Thepok has quit (Ping timeout: 264 seconds)
  70 2013-07-31 00:14:50 <sipa> and 'inv' does
  71 2013-07-31 00:15:06 <sipa> as headers are never sent without request (right now)
  72 2013-07-31 00:15:07 <petertodd> oh, and the logic works too, because if we have an INV, obviously we have the block, and we'll send them the headers if we don't have it yet
  73 2013-07-31 00:15:21 marco__ has joined
  74 2013-07-31 00:15:27 <sipa> i think my current patch would deal perfectly with that
  75 2013-07-31 00:15:29 <petertodd> yeah, although it's safe to send our peers headers, because unknown messages are ignored (at least for the ref bitcoind)
  76 2013-07-31 00:16:02 <sipa> well, but P2P clients already rely on the headers message, so they have an implementation for it
  77 2013-07-31 00:16:12 <sipa> sending it for different reason than they expect may confuse them
  78 2013-07-31 00:16:19 <petertodd> yeah, and no-one has written a pure non-SPV alt, I think?
  79 2013-07-31 00:16:39 <sipa> altcoin?
  80 2013-07-31 00:16:46 <sipa> oh, alternate client?
  81 2013-07-31 00:16:48 <petertodd> yeah
  82 2013-07-31 00:17:02 <sipa> bitsofproof maybe
  83 2013-07-31 00:17:03 <petertodd> probably work figuring out what bitcoinj does in response to an unsolicited header basically
  84 2013-07-31 00:18:14 <jgarzik>  <petertodd> I see, so getheaders was added, but of course until your work "headers" is ignored  <<---  eh?  bitcoinj has been using 'getheaders' for ages
  85 2013-07-31 00:18:16 <sipa> but there may be just be like a field in version (or another, currently non-existing message) to request "i want these features to be enabled", and have verack (or equivalent) answer with "these features are now enabled! "
  86 2013-07-31 00:18:21 <jgarzik> anyway, baby bedtime
  87 2013-07-31 00:18:22 realzies has joined
  88 2013-07-31 00:19:36 <petertodd> jgarzik: I meant in the ref bitcoind
  89 2013-07-31 00:20:31 sserrano44 has quit (Quit: Computer has gone to sleep.)
  90 2013-07-31 00:21:24 agnostic98 has joined
  91 2013-07-31 00:21:42 <petertodd> hmm... yeah, just doing the headers + inv eventually thing seems simplier to me over all
  92 2013-07-31 00:21:55 <petertodd> I mean, you should be able to handle peers giving you arbitrary bits of information
  93 2013-07-31 00:22:59 sserrano44 has joined
  94 2013-07-31 00:24:59 <petertodd> Here's the other thing: when we receive a new block, and haven't sent headers out yet, what we actually should be doing is sending headers first, followed by the block INV advertisement.
  95 2013-07-31 00:25:37 <petertodd> The extra bit of BW is tiny, and it makes sure someone will in fact get the headers out to the P2P network prior to the block at some point.
  96 2013-07-31 00:27:40 macboz has joined
  97 2013-07-31 00:28:57 <sipa> makes sense... send out header when you extended your header-chain, send out inv when you extended your block-chain
  98 2013-07-31 00:29:36 <sipa> as processing a block means first processing its header, you'll get both automatically when an unknown block that connects arrives
  99 2013-07-31 00:29:47 agnostic98 has quit (Ping timeout: 264 seconds)
 100 2013-07-31 00:30:06 <petertodd> mind, doesn't the networking code only receive stuff in it's entirely?
 101 2013-07-31 00:30:23 <petertodd> I mean, I don't think we can deserialize and process the header first
 102 2013-07-31 00:30:55 <sipa> sure
 103 2013-07-31 00:31:04 <sipa> i mean the processing logic, not the network side
 104 2013-07-31 00:31:08 <petertodd> ah yeah
 105 2013-07-31 00:31:15 <sipa> so yes, you'll download the entire block first
 106 2013-07-31 00:31:22 <sipa> but its header is still processed first
 107 2013-07-31 00:31:23 mappum has quit (Ping timeout: 256 seconds)
 108 2013-07-31 00:31:47 <petertodd> yeah, so if you were, say, the peer that actually created the block, you could in theory only send the block, not the header
 109 2013-07-31 00:31:56 <petertodd> (or if your peer was older)
 110 2013-07-31 00:32:25 <petertodd> but you'll always send out the header first because the act of processing a block changes what is the new pindexBestHeader
 111 2013-07-31 00:32:39 <sipa> indeed
 112 2013-07-31 00:32:41 freewil has quit (Quit: Leaving)
 113 2013-07-31 00:32:49 <sipa> that's what happens, btw
 114 2013-07-31 00:33:03 <sipa> if you actually mine a block, it is immediately broadcast without preceding inv
 115 2013-07-31 00:33:06 <petertodd> We should also have new headers, and heck, new blocks, "jump the queue" when it comes to messages we're sending to peers - pretty sure we aren't doing that.
 116 2013-07-31 00:33:21 <petertodd> Ah good, so that case is being tested.
 117 2013-07-31 00:33:29 <petertodd> Heh, that's actually a privacy risk in theory...
 118 2013-07-31 00:33:50 <sipa> so run a bitcoind in between :)
 119 2013-07-31 00:34:04 <sipa> (and remove whatever advantage the lack of 'inv' had)
 120 2013-07-31 00:34:21 <petertodd> Indeed... hmm, we should add code that occasionally drops INVs with, say 1% probability.
 121 2013-07-31 00:34:50 <petertodd> Could be good in general really to enforce some level of robustness. :(
 122 2013-07-31 00:35:31 <Vinnie_win> Robustness is always good.
 123 2013-07-31 00:35:51 <sipa> except for things that need to break :)
 124 2013-07-31 00:36:19 <petertodd> well they need to break occasionally, or they'll break...
 125 2013-07-31 00:38:26 <sipa> failing to fail can be a failure...
 126 2013-07-31 00:38:53 <phantomcircuit> sipa, yo dawg
 127 2013-07-31 00:38:54 <petertodd> sipa: I notice that you have the code always send a getheaders in response, on the assumption that we're syncing - that should change
 128 2013-07-31 00:40:32 <petertodd> heh, annoying: I see that getheaders only works in one direction
 129 2013-07-31 00:41:20 <sipa> petertodd: how so?
 130 2013-07-31 00:41:33 <sipa> ah
 131 2013-07-31 00:41:37 <petertodd> "for (; pindex; pindex = pindex->pnext)"
 132 2013-07-31 00:42:13 <sipa> see, there's a difference!
 133 2013-07-31 00:42:23 <petertodd> also, your getheaders implementation adds "&& pindex->nHeight <= nBestHeight", which we actually don't want - we and to get able to getheaders even if we haven't gotten the blocks yet
 134 2013-07-31 00:43:00 <sipa> not convinced
 135 2013-07-31 00:43:21 <sipa> as there is currently no way to distinguish between having headers and having blocks
 136 2013-07-31 00:43:45 <petertodd> consider the SPV headers only peer case - they'll expose getheaders, but not have blocks
 137 2013-07-31 00:43:51 <sipa> maybe we need entirely new messages for this
 138 2013-07-31 00:43:52 <petertodd> or partial mode for that matter
 139 2013-07-31 00:44:12 <petertodd> new messages is a perfectly good solution too, especially since getheaders is only going in one direction
 140 2013-07-31 00:44:38 <sipa> you mean you can't ask for ancestry?
 141 2013-07-31 00:45:31 <petertodd> oh yeah, locator is an index right?
 142 2013-07-31 00:45:35 <petertodd> not a hash?
 143 2013-07-31 00:45:41 <sipa> it's a set of hashes
 144 2013-07-31 00:45:57 <sipa> look at the code :)
 145 2013-07-31 00:46:05 <sipa> it's in main.h afaik
 146 2013-07-31 00:46:10 <petertodd> looking
 147 2013-07-31 00:46:48 CheckDavid has joined
 148 2013-07-31 00:46:56 <petertodd> ok, that's more complex than I realized, I thought locator was a hash for some reason
 149 2013-07-31 00:50:57 <petertodd> so this means if I want to download the block headers, from the newest first, I actualy can't without checkpoints right? because I don't have block hashes to give the locator?
 150 2013-07-31 00:51:10 sserrano44 has quit (Quit: Computer has gone to sleep.)
 151 2013-07-31 00:55:14 <sipa> indeed, but why would you want to go backwards?
 152 2013-07-31 00:55:27 <sipa> you can't validate later ones without their parents
 153 2013-07-31 00:56:27 <petertodd> if I'm really memory/bandwidth constrained I might want to accumulate total work quickly, so my attacker can't send me off into a long low-work chain
 154 2013-07-31 00:56:30 agnostic98 has joined
 155 2013-07-31 00:56:43 <sipa> right, you can check individual PoW
 156 2013-07-31 00:57:00 cypher has quit (Remote host closed the connection)
 157 2013-07-31 00:57:23 <petertodd> with total work proofs it's even better because they can prove the total work of the chian - but that's a fair bit of code to implement
 158 2013-07-31 00:57:29 cypher has joined
 159 2013-07-31 00:58:27 <sipa> how?
 160 2013-07-31 00:58:39 <phantomcircuit> petertodd, part of the problem with initial block sync is that there's no easy way to get all of the headers
 161 2013-07-31 00:58:41 mappum has joined
 162 2013-07-31 00:58:51 <sipa> phantomcircuit: it's not hard...
 163 2013-07-31 00:59:08 <petertodd> they commit to a merkle sum tree of all headers, I pick a random one, they prove they have it (and that the sums along the path make sense)
 164 2013-07-31 00:59:09 <phantomcircuit> sipa, it is if you're trying to avoid the network latency between blocks of 500
 165 2013-07-31 00:59:18 <phantomcircuit> get 500, process, goto 1
 166 2013-07-31 00:59:33 <sipa> phantomcircuit: you can get headers in batches of 2000
 167 2013-07-31 00:59:52 <phantomcircuit> sipa, well really im talking about full blocks
 168 2013-07-31 01:00:02 [\\\] has joined
 169 2013-07-31 01:00:04 <phantomcircuit> it's the primary reason the pipelined code is so much faster
 170 2013-07-31 01:00:17 <phantomcircuit> you're not sitting around waiting for the next 500 blocks
 171 2013-07-31 01:00:21 <petertodd> sipa: if I pick n headers they have a 1/n chance of getting away with any fraud basically
 172 2013-07-31 01:00:27 <sipa> phantomcircuit: yes, i noticed :)
 173 2013-07-31 01:00:56 <phantomcircuit> sipa, heh im sure you did
 174 2013-07-31 01:00:57 <petertodd> sipa: then just weight the tree by work - IE randomly go down from the tip, higher work branches more likely to be requested in proportin to work claimed
 175 2013-07-31 01:01:05 <sipa> petertodd: right, though it's not really a proof, in the sense that for 100% safety you still need all headers
 176 2013-07-31 01:01:09 agnostic98 has quit (Ping timeout: 256 seconds)
 177 2013-07-31 01:01:32 <petertodd> sipa: sure, but I can get exponentially more safety for every header picked
 178 2013-07-31 01:01:37 <sipa> agree
 179 2013-07-31 01:01:58 <sipa> phantomcircuit: though technically, you don't need headers-based syncing for pipelining
 180 2013-07-31 01:01:59 <petertodd> sipa: soon the real issue is "are all my peers frauds?"
 181 2013-07-31 01:02:20 Tantadruj has quit (Quit: DoubleRecall Turns Paywalls Into Advertising Dollars - NYTimes.com http://nyti.ms/odHOgy)
 182 2013-07-31 01:02:22 <phantomcircuit> sipa, right
 183 2013-07-31 01:02:30 <sipa> phantomcircuit: as even if you ask for 500 blocks in one getdata, the actual blocks arrive one by one in 'block' messages
 184 2013-07-31 01:02:30 <petertodd> For now anyway most recent header first is pretty damn good...
 185 2013-07-31 01:02:41 <phantomcircuit> headers based sync just allows you to do hybrid spv operation until you've synced completely
 186 2013-07-31 01:02:58 <sipa> no, not really
 187 2013-07-31 01:03:10 <sipa> for SPV you need wallet-filtered sync too
 188 2013-07-31 01:03:13 agnostic98 has joined
 189 2013-07-31 01:03:26 <sipa> though headers-based sync is a large step towards SPV
 190 2013-07-31 01:03:28 <phantomcircuit> sipa, right but that's gonna be *much* faster
 191 2013-07-31 01:03:51 <sipa> sure, but SPV is essentially a way to implement an efficient wallet, using a headers-synced chain
 192 2013-07-31 01:04:04 <phantomcircuit> yeah
 193 2013-07-31 01:04:08 <sipa> while headers-based syncing is a way to improve IBD for a full node
 194 2013-07-31 01:04:17 <sipa> they share the "sync headers" part, but that's it
 195 2013-07-31 01:05:11 <phantomcircuit> sipa, well you could more or less operate as an SPV node, quickly get wallet transactions
 196 2013-07-31 01:05:20 <phantomcircuit> then more slowly become a full node
 197 2013-07-31 01:05:32 <sipa> yeah, they can be combined
 198 2013-07-31 01:05:38 <sipa> that's be pretty much optimal :)
 199 2013-07-31 01:05:49 <phantomcircuit> yeah
 200 2013-07-31 01:05:58 <phantomcircuit> i suspect that'll be kind of difficult to actually implement though
 201 2013-07-31 01:06:06 <sipa> i don't think so
 202 2013-07-31 01:06:28 <phantomcircuit> sipa, i'll be happy to be proven wrong :)
 203 2013-07-31 01:11:15 CodeShark has quit ()
 204 2013-07-31 01:11:33 CodeShark has joined
 205 2013-07-31 01:12:18 bbrian has quit (Ping timeout: 268 seconds)
 206 2013-07-31 01:19:32 ry4nn has quit (Ping timeout: 248 seconds)
 207 2013-07-31 01:22:50 c0rw1n has quit (Remote host closed the connection)
 208 2013-07-31 01:25:58 <CodeShark> do we still need to support any compilers that don't support c++11?
 209 2013-07-31 01:26:45 <CodeShark> I guess c++11 is still being worked out
 210 2013-07-31 01:27:05 <CodeShark> no compiler supports all the features
 211 2013-07-31 01:28:20 <sipa> the gcc in the ubuntu VM used for gitian doesn't support c++11 yet, afaik
 212 2013-07-31 01:28:47 <sipa> actually, it seems it does
 213 2013-07-31 01:29:03 <sipa> at least, some of the features...
 214 2013-07-31 01:29:25 <CodeShark> I'm starting to get into the habit of using some of the features copiously
 215 2013-07-31 01:29:28 <CodeShark> and it's hard to go back :p
 216 2013-07-31 01:30:48 <CodeShark> it really is a significant improvement of the language on many fronts
 217 2013-07-31 01:31:22 <sipa> i know
 218 2013-07-31 01:31:46 <sipa> rvalue/move semantics are complex, but really fix an long an inherent problem
 219 2013-07-31 01:32:28 <sipa> the bitcoin codebase uses swaps explicitly in some case to get the performance of move semantics
 220 2013-07-31 01:34:59 * sipa ACPI STANDBY
 221 2013-07-31 01:36:52 [\\\] has quit (Remote host closed the connection)
 222 2013-07-31 01:38:11 <Luke-Jr> sipa: ubuntu mingw doesn't
 223 2013-07-31 01:38:32 <Luke-Jr> so I should start using anonymous functions in my Bitcoin code?
 224 2013-07-31 01:38:42 <Luke-Jr> aka lambdas
 225 2013-07-31 01:40:30 <CodeShark> I've been using them a lot in other code - they are quite convenient :)
 226 2013-07-31 01:40:52 zer0def has quit (Ping timeout: 248 seconds)
 227 2013-07-31 01:41:25 kfreds has quit (Ping timeout: 264 seconds)
 228 2013-07-31 01:41:49 kfreds has joined
 229 2013-07-31 01:44:09 <CodeShark> the whole function pointer syntax in C has long been one of the language's warts
 230 2013-07-31 01:44:17 pecket has quit (Quit: I'm not stupid. I'm just unlucky when I think.)
 231 2013-07-31 01:44:49 <CodeShark> functions really should be treated as any other datatype
 232 2013-07-31 01:46:11 <CodeShark> in C++ you have the ability to overload the () operator, but that's a hack
 233 2013-07-31 01:46:46 <CodeShark> it just hides the ugliness inside a class
 234 2013-07-31 01:49:22 <CodeShark> wouldn't be a problem if the semantics were consistent - but they aren't - the () operator is also used for constructors and for operator precedence
 235 2013-07-31 01:49:59 <CodeShark> although the latter two can be easily distinguished
 236 2013-07-31 01:51:21 CodeShark has quit (Remote host closed the connection)
 237 2013-07-31 01:52:04 fribcell has joined
 238 2013-07-31 01:54:05 Squidicuz has quit (Ping timeout: 276 seconds)
 239 2013-07-31 01:56:09 ericmuyser has quit (Remote host closed the connection)
 240 2013-07-31 01:56:35 ericmuyser has joined
 241 2013-07-31 01:59:11 brson has quit (Quit: leaving)
 242 2013-07-31 02:09:35 roconnor has quit (Quit: Konversation terminated!)
 243 2013-07-31 02:15:15 yme has joined
 244 2013-07-31 02:17:00 o3u_ has joined
 245 2013-07-31 02:19:31 debiantoruser has quit (Ping timeout: 268 seconds)
 246 2013-07-31 02:21:01 debiantoruser has joined
 247 2013-07-31 02:21:42 h2odysee has joined
 248 2013-07-31 02:21:46 mappum has quit (Ping timeout: 245 seconds)
 249 2013-07-31 02:22:00 [\\\] has joined
 250 2013-07-31 02:32:08 CheckDavid has quit (Quit: Leaving)
 251 2013-07-31 02:32:28 Krellan__ has quit (Remote host closed the connection)
 252 2013-07-31 02:35:52 owowo has quit (Quit: dead)
 253 2013-07-31 02:36:08 _jps has quit (Quit: _jps)
 254 2013-07-31 02:37:35 dust-otc has joined
 255 2013-07-31 02:41:15 Squidicuz has joined
 256 2013-07-31 02:41:26 Vinnie_win has quit ()
 257 2013-07-31 02:42:13 fribcell has left ()
 258 2013-07-31 02:50:52 ThomasV has joined
 259 2013-07-31 02:51:08 Subo1978_ has joined
 260 2013-07-31 02:52:36 BTCOxygen has quit (Ping timeout: 245 seconds)
 261 2013-07-31 02:52:39 Applicat_ has quit (Ping timeout: 260 seconds)
 262 2013-07-31 02:54:20 Subo1978 has quit (Ping timeout: 240 seconds)
 263 2013-07-31 02:55:13 Vinnie_win has joined
 264 2013-07-31 02:55:29 qbasicer has quit (Read error: No route to host)
 265 2013-07-31 02:58:06 qbasicer has joined
 266 2013-07-31 03:01:05 MobPhone has joined
 267 2013-07-31 03:01:36 dust-otc has quit (Remote host closed the connection)
 268 2013-07-31 03:04:37 BTCOxygen has joined
 269 2013-07-31 03:05:46 BTCOxygen has quit (Max SendQ exceeded)
 270 2013-07-31 03:06:35 BTCOxygen has joined
 271 2013-07-31 03:10:42 denom has quit (Ping timeout: 268 seconds)
 272 2013-07-31 03:11:56 BTCOxygen has quit (Ping timeout: 268 seconds)
 273 2013-07-31 03:12:20 brson has joined
 274 2013-07-31 03:13:48 AusBitBank has joined
 275 2013-07-31 03:15:01 BTCOxygen has joined
 276 2013-07-31 03:17:35 melvster has joined
 277 2013-07-31 03:25:34 ralphtheninja has quit (Quit: leaving)
 278 2013-07-31 03:29:41 Application has joined
 279 2013-07-31 03:30:14 Applicat_ has joined
 280 2013-07-31 03:30:39 ThomasV has quit (Ping timeout: 246 seconds)
 281 2013-07-31 03:32:29 Arnavion has quit (Quit: Arnavion)
 282 2013-07-31 03:33:23 Arnavion has joined
 283 2013-07-31 03:33:31 MobPhone has quit (Ping timeout: 268 seconds)
 284 2013-07-31 03:33:51 Application has quit (Ping timeout: 245 seconds)
 285 2013-07-31 03:40:54 MobPhone has joined
 286 2013-07-31 03:40:56 <petertodd> inputs.io now does GPG auth - I'm impressed
 287 2013-07-31 03:42:02 <petertodd> inputs.io has also told me they intend to implement merkle sum tree commitments to the balances of all their accounts so as to prove they really have the coins backing deposits
 288 2013-07-31 03:43:46 TheSeven has quit (Disconnected by services)
 289 2013-07-31 03:43:47 [7] has joined
 290 2013-07-31 03:44:57 Pengoo has joined
 291 2013-07-31 03:45:07 <nsh> nice
 292 2013-07-31 03:47:41 <petertodd> the method they said they were going to use for balance verification sounds like it won't be optimal - it will be done every hour or so - but it's a very good first step
 293 2013-07-31 03:47:55 <petertodd> (you can do balance verification per transaction with the right data structure
 294 2013-07-31 03:47:58 <petertodd> )
 295 2013-07-31 03:48:44 <Luke-Jr> petertodd: of course, this assumes they don't know who will or won't be checking balances ;p
 296 2013-07-31 03:49:15 <Luke-Jr> it might not work for MtGox, since they probably have a number of old users that never claimed their account after the cracking incident
 297 2013-07-31 03:49:28 <petertodd> sort of: they publish a public commitment, and then users check the balance; you have to know in advance
 298 2013-07-31 03:49:37 <petertodd> yeah, you can get away with old accounts for sure
 299 2013-07-31 03:49:49 <petertodd> just expiure their password :P
 300 2013-07-31 03:50:01 <petertodd> "oh sorry, it's a manual process to reactivate..."
 301 2013-07-31 03:53:24 macboz has quit (Ping timeout: 246 seconds)
 302 2013-07-31 03:57:59 Someguy123 has quit (Ping timeout: 260 seconds)
 303 2013-07-31 03:58:35 Someguy123 has joined
 304 2013-07-31 04:02:02 Someguy123 has quit (Excess Flood)
 305 2013-07-31 04:02:32 Someguy123 has joined
 306 2013-07-31 04:02:44 [\\\] has quit (Remote host closed the connection)
 307 2013-07-31 04:03:45 [\\\] has joined
 308 2013-07-31 04:15:06 Skav has joined
 309 2013-07-31 04:17:18 MobPhone has quit (Ping timeout: 268 seconds)
 310 2013-07-31 04:19:23 MobiusL has quit (Quit: Ex-Chat)
 311 2013-07-31 04:20:26 <phantomcircuit> petertodd, depends on if anybody is storing the old records
 312 2013-07-31 04:20:33 MobPhone has joined
 313 2013-07-31 04:21:58 <Vinnie_win> sup peeps
 314 2013-07-31 04:23:01 Skav has quit (Ping timeout: 245 seconds)
 315 2013-07-31 04:25:03 aa has joined
 316 2013-07-31 04:25:27 aa is now known as Guest39384
 317 2013-07-31 04:25:35 Guest39384 has quit (Remote host closed the connection)
 318 2013-07-31 04:25:53 Mobius_ has joined
 319 2013-07-31 04:26:14 Krellan_ has joined
 320 2013-07-31 04:26:15 Mobius_ is now known as MobiusL
 321 2013-07-31 04:26:47 MobPhone has quit (Ping timeout: 264 seconds)
 322 2013-07-31 04:27:27 Neozonz has joined
 323 2013-07-31 04:27:42 JZavala has joined
 324 2013-07-31 04:29:26 yme has quit (Ping timeout: 250 seconds)
 325 2013-07-31 04:30:52 Neozonz has quit (Ping timeout: 268 seconds)
 326 2013-07-31 04:46:25 chorao has quit ()
 327 2013-07-31 04:48:45 MobPhone has joined
 328 2013-07-31 04:48:53 brson has quit (Quit: leaving)
 329 2013-07-31 04:48:54 PiZZaMaN2K is now known as away!~PiZZaMaN2@unaffiliated/pizzaman2k|PiZZaMaN2K
 330 2013-07-31 04:49:08 brson has joined
 331 2013-07-31 04:53:36 patcon has joined
 332 2013-07-31 04:53:43 richcollins has joined
 333 2013-07-31 04:54:23 zer0def has joined
 334 2013-07-31 04:55:59 <petertodd> phantomcircuit: you don't publish records for all accounts to preserve privacy
 335 2013-07-31 04:56:19 melvster has quit (Ping timeout: 256 seconds)
 336 2013-07-31 04:57:36 debiantoruser has quit (Ping timeout: 245 seconds)
 337 2013-07-31 04:59:31 debiantoruser has joined
 338 2013-07-31 05:02:42 daktak has quit (Read error: Connection reset by peer)
 339 2013-07-31 05:03:27 daktak has joined
 340 2013-07-31 05:04:45 melvster has joined
 341 2013-07-31 05:08:20 MobiusL has quit (Ping timeout: 240 seconds)
 342 2013-07-31 05:10:47 zer0def has quit (Ping timeout: 260 seconds)
 343 2013-07-31 05:11:39 MobiusL has joined
 344 2013-07-31 05:11:41 richcollins has quit (Quit: richcollins)
 345 2013-07-31 05:12:11 copumpkin has quit (Ping timeout: 268 seconds)
 346 2013-07-31 05:12:41 <phantomcircuit> petertodd, the only thing that has to be preserved is the root
 347 2013-07-31 05:12:49 copumpkin has joined
 348 2013-07-31 05:15:09 catcow has quit (Read error: Connection reset by peer)
 349 2013-07-31 05:16:17 gst has joined
 350 2013-07-31 05:17:08 catcow has joined
 351 2013-07-31 05:17:08 catcow has quit (Changing host)
 352 2013-07-31 05:17:08 catcow has joined
 353 2013-07-31 05:18:43 mappum has joined
 354 2013-07-31 05:19:37 Subo1978 has joined
 355 2013-07-31 05:19:40 Subo1978_ has quit (Ping timeout: 240 seconds)
 356 2013-07-31 05:20:40 richcollins has joined
 357 2013-07-31 05:27:41 sserrano44 has joined
 358 2013-07-31 05:28:20 brson has quit (Quit: leaving)
 359 2013-07-31 05:29:43 paracyst has quit ()
 360 2013-07-31 05:30:23 jeewee has joined
 361 2013-07-31 05:31:00 Skav has joined
 362 2013-07-31 05:31:38 Krellan_ has quit (Ping timeout: 264 seconds)
 363 2013-07-31 05:32:29 Arnavion has quit (Quit: Arnavion)
 364 2013-07-31 05:33:23 MobPhone has quit (Ping timeout: 264 seconds)
 365 2013-07-31 05:34:46 PiZZaMaN2K is now known as PiZZaMaN2K|away
 366 2013-07-31 05:37:07 Skav has quit (Read error: Connection reset by peer)
 367 2013-07-31 05:37:24 MobPhone has joined
 368 2013-07-31 05:37:31 ralphtheninja has joined
 369 2013-07-31 05:37:40 Arnavion has joined
 370 2013-07-31 05:44:04 Arnavion has quit (Quit: Arnavion)
 371 2013-07-31 05:52:17 Arnavion has joined
 372 2013-07-31 05:52:47 Arnavion has quit (Client Quit)
 373 2013-07-31 05:53:49 Arnavion has joined
 374 2013-07-31 06:03:40 GordonG3kko has quit (Ping timeout: 240 seconds)
 375 2013-07-31 06:04:57 darknyan has quit (Read error: Connection reset by peer)
 376 2013-07-31 06:05:41 Zoo has quit (Read error: No route to host)
 377 2013-07-31 06:05:43 patcon has quit (Remote host closed the connection)
 378 2013-07-31 06:05:50 Zoo has joined
 379 2013-07-31 06:06:18 darknyan has joined
 380 2013-07-31 06:07:23 GordonG3kko has joined
 381 2013-07-31 06:07:44 richcollins has quit (Quit: richcollins)
 382 2013-07-31 06:17:53 tmsk has joined
 383 2013-07-31 06:18:02 tmsk has quit (Client Quit)
 384 2013-07-31 06:18:19 tmsk has joined
 385 2013-07-31 06:21:27 mappum has quit (Ping timeout: 246 seconds)
 386 2013-07-31 06:36:01 yubrew has quit (Remote host closed the connection)
 387 2013-07-31 06:39:35 ericmuyser has quit (Remote host closed the connection)
 388 2013-07-31 06:40:42 ericmuyser has joined
 389 2013-07-31 06:40:50 ericmuyser has quit (Remote host closed the connection)
 390 2013-07-31 06:41:13 Zoo has quit (Read error: Connection reset by peer)
 391 2013-07-31 06:41:30 Zoo has joined
 392 2013-07-31 06:42:11 gjs278 has quit (Remote host closed the connection)
 393 2013-07-31 06:42:44 Eiii has quit ()
 394 2013-07-31 06:52:36 a_meteorite has quit (Ping timeout: 245 seconds)
 395 2013-07-31 06:52:50 <Luke-Jr> petertodd: src/main.h:1204: double CMemPoolTx::FeesPerKB() const: Assertion `nSumTxSize >= 0' failed.
 396 2013-07-31 06:59:08 <melvster> does anyone know why the payments protocol uses BOTH sha256 and sha1?
 397 2013-07-31 06:59:20 <melvster> i would have thought just sha256 would be OK?
 398 2013-07-31 06:59:57 zer0def has joined
 399 2013-07-31 07:00:12 <melvster> cc: gavinandresen ^^
 400 2013-07-31 07:02:42 ivan\ has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
 401 2013-07-31 07:03:23 ivan\ has joined
 402 2013-07-31 07:03:28 Applicat_ has quit (Read error: Operation timed out)
 403 2013-07-31 07:05:03 eoss has joined
 404 2013-07-31 07:06:03 Application has joined
 405 2013-07-31 07:09:53 a_meteorite has joined
 406 2013-07-31 07:11:34 gjs278 has joined
 407 2013-07-31 07:16:29 patcon has joined
 408 2013-07-31 07:17:59 Neozonz has joined
 409 2013-07-31 07:17:59 Neozonz has quit (Changing host)
 410 2013-07-31 07:17:59 Neozonz has joined
 411 2013-07-31 07:19:47 paraipan has joined
 412 2013-07-31 07:20:00 gjs278 has quit (Quit: Konversation terminated!)
 413 2013-07-31 07:20:14 gjs278 has joined
 414 2013-07-31 07:21:04 Neozonz has quit (Disc!~Neozonz@unaffiliated/neozonz|Ping timeout: 268 seconds)
 415 2013-07-31 07:21:18 patcon has quit (Ping timeout: 246 seconds)
 416 2013-07-31 07:24:47 Thepok has joined
 417 2013-07-31 07:28:16 eoss has quit (Remote host closed the connection)
 418 2013-07-31 07:36:58 CodeName has joined
 419 2013-07-31 07:39:28 PiZZaMaN2K is now known as away!~PiZZaMaN2@unaffiliated/pizzaman2k|PiZZaMaN2K
 420 2013-07-31 07:42:21 thrasher` has quit (Ping timeout: 256 seconds)
 421 2013-07-31 07:43:03 thrasher` has joined
 422 2013-07-31 07:44:02 djoot has quit (Read error: Connection reset by peer)
 423 2013-07-31 07:45:44 t7 has joined
 424 2013-07-31 07:45:45 CodeName has quit (Ping timeout: 256 seconds)
 425 2013-07-31 07:50:17 h2odysee has quit (Ping timeout: 256 seconds)
 426 2013-07-31 07:52:39 Bezzeb has joined
 427 2013-07-31 07:56:15 Eneerge_ has quit (Read error: Connection reset by peer)
 428 2013-07-31 07:56:49 Jaagu has joined
 429 2013-07-31 07:57:59 Eneerge has joined
 430 2013-07-31 07:57:59 Eneerge has quit (Changing host)
 431 2013-07-31 07:57:59 Eneerge has joined
 432 2013-07-31 07:57:59 Eneerge has quit (Changing host)
 433 2013-07-31 07:57:59 Eneerge has joined
 434 2013-07-31 08:00:08 Jaagu has quit (Client Quit)
 435 2013-07-31 08:02:50 realzies has quit (Ping timeout: 264 seconds)
 436 2013-07-31 08:04:55 kadoban has quit (Remote host closed the connection)
 437 2013-07-31 08:07:25 agnostic98 has quit (Remote host closed the connection)
 438 2013-07-31 08:17:03 bmcgee has quit (Quit: bmcgee)
 439 2013-07-31 08:19:16 ntu has quit (Read error: Operation timed out)
 440 2013-07-31 08:21:04 arioBarzan has joined
 441 2013-07-31 08:21:42 ThomasV has joined
 442 2013-07-31 08:24:04 GordonG3kko has quit (Remote host closed the connection)
 443 2013-07-31 08:24:40 <phantomcircuit> melvster, where?
 444 2013-07-31 08:26:12 <warren> sipa: how's secp256k1 doing?
 445 2013-07-31 08:27:01 gst has quit (Ping timeout: 240 seconds)
 446 2013-07-31 08:28:11 GordonG3kko has joined
 447 2013-07-31 08:29:12 BTCOxygen has quit (Ping timeout: 246 seconds)
 448 2013-07-31 08:29:13 gst has joined
 449 2013-07-31 08:30:57 Prattler has joined
 450 2013-07-31 08:31:56 Applicat_ has joined
 451 2013-07-31 08:34:24 cdecker1 has left ()
 452 2013-07-31 08:34:45 Application has quit (Ping timeout: 256 seconds)
 453 2013-07-31 08:37:51 agnostic98 has joined
 454 2013-07-31 08:39:43 Muis_ has quit (Read error: Connection reset by peer)
 455 2013-07-31 08:40:07 Muis_ has joined
 456 2013-07-31 08:44:05 agnostic98 has quit (Read error: Connection reset by peer)
 457 2013-07-31 08:47:19 <sipa> warren: no progress
 458 2013-07-31 08:50:18 saulimus has joined
 459 2013-07-31 08:52:00 paraipan has quit (Remote host closed the connection)
 460 2013-07-31 08:52:39 paraipan has joined
 461 2013-07-31 08:52:56 <melvster> phantomcircuit: https://en.bitcoin.it/wiki/BIP_0070#Certificates ?
 462 2013-07-31 08:53:58 <phantomcircuit> melvster, i have no idea, that seems wrong
 463 2013-07-31 08:55:53 <gmaxwell> melvster: IIRC there was some issue like "php doesn't include a sha256 implementation" or something like that. But I could be misremembering.
 464 2013-07-31 08:56:45 <arioBarzan> sipa: Hi, I tested your new update on pull/2861 and I got these: -sendtoaddress still leads to error: {"code":-4,"message":"Signing transaction failed"}  -indexing of blocks became significantly slower.
 465 2013-07-31 08:56:52 <phantomcircuit> gmaxwell, php doesn't include useful x509 or protobuf support either...
 466 2013-07-31 08:57:06 <sipa> arioBarzan: during a reindex?
 467 2013-07-31 08:57:17 <gmaxwell> arioBarzan: significantly slower relative to not having the patch, right?
 468 2013-07-31 08:57:25 <arioBarzan> sipa: I erased whole blocks
 469 2013-07-31 08:57:34 <arioBarzan> gmaxwell: yes
 470 2013-07-31 08:57:49 <sipa> then sync speed is just determined by whether you pick a fast peer or not
 471 2013-07-31 08:57:58 <sipa> that's not a useful benchmark
 472 2013-07-31 08:58:07 <arioBarzan> gmaxwell: even relative to sipa's own code before last update
 473 2013-07-31 08:58:12 <sipa> feel free to test a -reijdex though
 474 2013-07-31 08:58:25 <gmaxwell> oh you're not measuring a -reindex? ah.
 475 2013-07-31 08:58:37 <sipa> which will rebuild the chain using the blocks you already have on disk
 476 2013-07-31 08:59:17 <gmaxwell> phantomcircuit: you can easily implement protobuf in php, and the x509 stuff is handled by available libraries I thought. But perhaps I'm just misremembering the motivation there.
 477 2013-07-31 08:59:30 <arioBarzan> sipa: I tested reindex and it got worse. Balance for the address at block 170 (1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3) didn't get updated.
 478 2013-07-31 08:59:57 <sipa> arioBarzan: when did you do that reindex?
 479 2013-07-31 09:00:16 <arioBarzan> sipa: after 600 blocks
 480 2013-07-31 09:00:17 <phantomcircuit> gmaxwell, i suspect that's exactly the motivation, but that it's misplaced
 481 2013-07-31 09:00:26 <arioBarzan> sipa: without the importedt address
 482 2013-07-31 09:00:58 <sipa> "it got worse", what got worse?
 483 2013-07-31 09:01:08 <arioBarzan> sipa: after 6000 blocks I imported address 1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 and then closed and then reopened -reindex=true
 484 2013-07-31 09:01:20 <gmaxwell> phantomcircuit: personally I'm really tired of the security of stuff being broken by people using these slow and busted dynamic languages, but there seems to be nothing to do about it. If you tell them not to do whatever awful thing they want to do, they'll just do something even worse.
 485 2013-07-31 09:01:50 <phantomcircuit> lol
 486 2013-07-31 09:01:56 * phantomcircuit goes back to python scripts
 487 2013-07-31 09:01:57 <arioBarzan> sipa: the reading of transactions who belong to 1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3 got worse, i.e. it didn't get any balance
 488 2013-07-31 09:02:10 <phantomcircuit> except this is actually beautiful and fast
 489 2013-07-31 09:02:10 <phantomcircuit> so
 490 2013-07-31 09:02:13 <phantomcircuit> shrug
 491 2013-07-31 09:03:22 <sipa> arioBarzan: interesting; i'll have a look this evening
 492 2013-07-31 09:07:33 <sipa> feel free to report on the pullrequest
 493 2013-07-31 09:08:28 <arioBarzan> sipa: I still have criticism on your approach to this issue. Putting the coding aside (in which I'm not as professional as you guys) for a minute, I hope alternative algorithms for implementing watch-only discussed in advance.
 494 2013-07-31 09:09:47 <gmaxwell> arioBarzan: please don't complain that you have complaints, please just state your actual concerns.
 495 2013-07-31 09:10:06 <gmaxwell> Making comments like that at all just sound like "please do nothing at all".
 496 2013-07-31 09:10:29 <gmaxwell> (preferrably state them on the pull, since they're less likely to be missed there, but here works too)
 497 2013-07-31 09:11:29 <arioBarzan> gmaxwell: My concern is on the processing performance of sipa's approach. To check for spendable coins every time at selectcoins would be redundant, I believe
 498 2013-07-31 09:12:41 <sipa> hmm, that may be an issue for very large wallets
 499 2013-07-31 09:12:53 agnostic98 has joined
 500 2013-07-31 09:13:03 <sipa> ir's just a constant factor, but it may be large
 501 2013-07-31 09:13:19 <sipa> wait no
 502 2013-07-31 09:13:31 <sipa> we were already doing an IsMine check anyway
 503 2013-07-31 09:13:41 <arioBarzan> if we code better, that would give users the freedom to get proper performance even when they chose to monitor large number of watch-only addresses
 504 2013-07-31 09:14:01 <sipa> i don't think there will be a noticable performamce difference
 505 2013-07-31 09:14:16 <sipa> but if there is, feel free to post numbers
 506 2013-07-31 09:15:33 <gmaxwell> IIRC that code makes a single pass to gather up the spendable ones first, right?
 507 2013-07-31 09:15:44 <sipa> yes
 508 2013-07-31 09:16:22 agnostic98 has quit (Read error: Connection reset by peer)
 509 2013-07-31 09:16:23 <gmaxwell> If so the overhead over maintaining a seperate database on actually spendable coins is at best O(number of transactions you make) which is, meh.
 510 2013-07-31 09:16:23 <sipa> a performance drop could come from the extra hash that is being calculated in script's IsMine
 511 2013-07-31 09:16:42 <sipa> which is done for every txout
 512 2013-07-31 09:17:11 <sipa> that can be avoided, but disables bare multisig matching
 513 2013-07-31 09:17:16 CodeShark has joined
 514 2013-07-31 09:17:42 <sipa> i don't think it's relevant though
 515 2013-07-31 09:17:54 <gmaxwell> hm. If this were much of a concern I'd assume someone would care to fix things like ECDSA in the fee loop. (0_o)
 516 2013-07-31 09:19:12 <gmaxwell> arioBarzan: in any case, it sounds like thats simply a performance optimization which could be done at any point. Even now, since there is that ismine check.
 517 2013-07-31 09:20:57 shesek has quit (Ping timeout: 245 seconds)
 518 2013-07-31 09:22:41 <gavinandresen> melvster: gmaxwell remembered correctly, php support for sha256 is fairly recent, but even ancient versions of php support sha1
 519 2013-07-31 09:23:42 <gavinandresen> phantomcircuit: see https://github.com/gavinandresen/paymentrequest/tree/master/php
 520 2013-07-31 09:24:08 <gavinandresen> (patches welcome if you want to do a python implementation)
 521 2013-07-31 09:24:50 <phantomcircuit> iirc the openssl methods aren't available on shared hosts, which is the only place sha256 wont be supported
 522 2013-07-31 09:25:16 thrasher` has quit (Changing host)
 523 2013-07-31 09:25:16 thrasher` has joined
 524 2013-07-31 09:25:18 <phantomcircuit> and im rewriting my peer enumerator to be less aggressive
 525 2013-07-31 09:25:26 <phantomcircuit> for... reasons
 526 2013-07-31 09:25:36 <sipa> there is already a python bip32 implementation, which would be nice as a payment server
 527 2013-07-31 09:25:36 <gavinandresen> phantomcircuit: ummm… no…  I noticed sha256 wasn't supported on the bitcoincore.org VPS (don't remember what version of php)
 528 2013-07-31 09:25:49 <gmaxwell> phantomcircuit: huh? I thought the norm was that you could use foreign functions if they were already installed, but can't install your own.
 529 2013-07-31 09:26:01 <gmaxwell> phantomcircuit: otherwise there is a _lot_ of standard stuff that wouldn't work.
 530 2013-07-31 09:26:10 <phantomcircuit> gmaxwell, ridiculousness with safemode
 531 2013-07-31 09:26:13 <melvster> gavinandresen: ah thanks
 532 2013-07-31 09:26:18 <phantomcircuit> lots of places whitelist functions
 533 2013-07-31 09:26:22 <phantomcircuit> which ends up being... interesting
 534 2013-07-31 09:26:46 <phantomcircuit> gavinandresen, sha256 has been available through the mhash module for a really long time
 535 2013-07-31 09:27:18 <melvster> ive had to do php x509 stuff via open_ssl in the past
 536 2013-07-31 09:27:43 <phantomcircuit> maybe using those functions is more common than i think
 537 2013-07-31 09:28:32 <arioBarzan> gmaxwell: when we close the daemon, we have on wallet.dat the wallet transactions indexed in addition to other stuff. did I understood it right?
 538 2013-07-31 09:28:54 toffoo has quit ()
 539 2013-07-31 09:29:08 <sipa> arioBarzan: hardly 'indexed', but they are saved yes
 540 2013-07-31 09:29:23 <phantomcircuit> not indexed at all :)
 541 2013-07-31 09:29:39 <sipa> well thry are accessible by txid
 542 2013-07-31 09:29:43 <arioBarzan> ok, not indexed but saved
 543 2013-07-31 09:31:10 <gavinandresen> phantomcircuit: it is support for SHA256 in the openssl_sign() function that is missing (OPENSSL_ALGO_SHA256 added in php 5.something)
 544 2013-07-31 09:33:00 shesek has joined
 545 2013-07-31 09:33:36 <arioBarzan> sipa not indexed but accessible by txid. however the daemon calls "accessible by txid" indexing, since I trigger that with at importprivaddress '...' '...' true <--reindex
 546 2013-07-31 09:34:05 <arioBarzan> * importprivkey
 547 2013-07-31 09:38:43 mintmoneyman has joined
 548 2013-07-31 09:39:54 <phantomcircuit> gavinandresen, lol i see it missed the last debian stable by a couple months
 549 2013-07-31 09:39:56 <phantomcircuit> oh well
 550 2013-07-31 09:40:05 <phantomcircuit> i stand corrected
 551 2013-07-31 09:40:17 <sipa> arioBarzan: oh, you mean a rescan
 552 2013-07-31 09:40:23 <sipa> arioBarzan: no, that's something entirely different
 553 2013-07-31 09:40:47 <sipa> rescanning is searching through the block chain data to find transactions that are (now) missing in your wallet
 554 2013-07-31 09:41:00 <arioBarzan> sipa: you're right. I asked wrong question.
 555 2013-07-31 09:43:00 guyguyguyguy has quit (Ping timeout: 264 seconds)
 556 2013-07-31 09:43:10 <arioBarzan> however I got the answer for what I was looking for, that we have relevant transactions and their txid saved in wallet.dat. tnx.
 557 2013-07-31 09:43:19 <Krellan> It would be rather cool to run "sha256sum" on an official download of the bitcoin client, and get 00000000...
 558 2013-07-31 09:44:03 <arioBarzan> Krellan: why not, let's mine some official downloads :)
 559 2013-07-31 09:44:48 ThomasV has quit (Ping timeout: 264 seconds)
 560 2013-07-31 09:45:40 tmsk has quit (Quit: tmsk)
 561 2013-07-31 09:50:18 shesek has quit (Ping timeout: 268 seconds)
 562 2013-07-31 09:56:21 johnsoft has joined
 563 2013-07-31 09:58:57 cads has quit (Ping timeout: 268 seconds)
 564 2013-07-31 10:02:17 shesek has joined
 565 2013-07-31 10:05:25 PiZZaMaN2K is now known as PiZZaMaN2K|away
 566 2013-07-31 10:06:54 cdecker1 has joined
 567 2013-07-31 10:11:57 datagutt has joined
 568 2013-07-31 10:13:07 debiantoruser has quit (Ping timeout: 268 seconds)
 569 2013-07-31 10:13:22 agnostic98 has joined
 570 2013-07-31 10:14:35 debiantoruser has joined
 571 2013-07-31 10:15:50 agnostic98 has quit (Read error: Connection reset by peer)
 572 2013-07-31 10:17:09 c0rw1n has joined
 573 2013-07-31 10:19:55 nsh has quit (Ping timeout: 240 seconds)
 574 2013-07-31 10:20:32 CodeShark has quit (Remote host closed the connection)
 575 2013-07-31 10:21:34 nsh has joined
 576 2013-07-31 10:27:00 AtashiCon has quit (Quit: AtashiCon)
 577 2013-07-31 10:27:15 AtashiCon has joined
 578 2013-07-31 10:31:29 abrkn has joined
 579 2013-07-31 10:31:37 danda has joined
 580 2013-07-31 10:35:12 danda__ has quit (Ping timeout: 264 seconds)
 581 2013-07-31 10:35:35 hoolandi has joined
 582 2013-07-31 10:35:48 abrkn\ has quit (Ping timeout: 264 seconds)
 583 2013-07-31 10:38:25 ThomasV has joined
 584 2013-07-31 10:39:06 shesek has quit (Read error: Connection reset by peer)
 585 2013-07-31 10:40:44 CheckDavid has joined
 586 2013-07-31 10:41:23 <Krellan> arioBarzan: although it might seem silly, it would give a way to help vouch for the "officialness" of an official download: not merely to match it with something posted to a website (which is kind of useless if both download and the posting originate from same website, hacker can change both).
 587 2013-07-31 10:42:26 <Krellan> although to be bitcoin compatible a quick patch would need to be made to sha256sum, add an option -B to have it make 2 passes, not just 1.
 588 2013-07-31 10:43:36 hoolandi has quit (Ping timeout: 246 seconds)
 589 2013-07-31 10:43:54 agnostic98 has joined
 590 2013-07-31 10:44:08 <Krellan> instead of trying to meet a target difficulty, you'd just keep mining the same "block" as much as you wanted, so you get a lower hash the longer amount of time you spend on it.
 591 2013-07-31 10:45:41 <Krellan> perhaps useful as a way to deter somebody making a quick replacement of your download with a trojan.
 592 2013-07-31 10:46:00 <t7> or just sign it
 593 2013-07-31 10:46:04 <Krellan> Not sure if actually useful in practice, though.  Certainly would be a fun hack.
 594 2013-07-31 10:46:05 agnostic98 has quit (Read error: Connection reset by peer)
 595 2013-07-31 10:46:08 <t7> easier and stronger
 596 2013-07-31 10:46:30 <t7> but i agree, would be fun
 597 2013-07-31 10:47:37 kicek has quit (Quit: Leaving)
 598 2013-07-31 10:49:10 <arioBarzan> Krellan: your suggestion is, to be concise, the use of POW (proof of work) for securing an official download. Those who want to do that POW, in this case bitcoin developers, might not have enough incentive to spend processing power on solving such a problem.
 599 2013-07-31 10:51:17 <sipa> why would you want proof of work for a download?
 600 2013-07-31 10:51:23 <sipa> you want proof of authenticity
 601 2013-07-31 10:52:09 <sipa> Krellan: if you trust a download that has PoW more than one that hasn't, then i thjnk you're confused
 602 2013-07-31 10:52:31 <sipa> there is no reason why an attacker couldn't gather more PoW than the develooers
 603 2013-07-31 10:52:54 daybyter has joined
 604 2013-07-31 10:52:57 <sipa> in fact, the opposite, since he likely has a financial incentive to do so
 605 2013-07-31 10:56:05 <gmaxwell> In general PoW doesn't make for a good _security_ construct, in that it doesn't create an attacker vs defender differential cost. It can, however, be used to create economic incentives, but its often tricky.
 606 2013-07-31 10:56:17 shesek has joined
 607 2013-07-31 10:56:39 <gmaxwell> Bitcoin creates attacker/defender asymetry because mining PoW rewards you with bitcoins (subsidy or fees) which attacks debase.
 608 2013-07-31 11:00:16 saulimus has quit (Read error: Connection reset by peer)
 609 2013-07-31 11:00:32 saulimus has joined
 610 2013-07-31 11:00:37 Pengoo has quit (Ping timeout: 268 seconds)
 611 2013-07-31 11:02:29 knotwork has quit (Ping timeout: 248 seconds)
 612 2013-07-31 11:03:43 knotwork has joined
 613 2013-07-31 11:05:42 bmcgee has joined
 614 2013-07-31 11:05:48 ThomasV has quit (Ping timeout: 256 seconds)
 615 2013-07-31 11:10:01 one_zero has quit ()
 616 2013-07-31 11:10:12 tmsk has joined
 617 2013-07-31 11:14:11 debiantoruser has quit (Ping timeout: 268 seconds)
 618 2013-07-31 11:15:09 <runeks> sipa: I'm trying out your revised version of the watch-only functionality. importaddress doesn't work for me any longer. importaddress used to take a while to return, presumably scanning the blockchain, but now it returns immediately and I don't see anything with listtransactions
 619 2013-07-31 11:16:49 <Krellan> good points, gmaxwell, about PoW and motives.
 620 2013-07-31 11:18:40 <runeks> Works on testnet though...
 621 2013-07-31 11:20:50 debianto1user has joined
 622 2013-07-31 11:21:02 <gmaxwell> sipa: I'm sorta surprised that 2802 doesn't make import use the index instead of rescanning.
 623 2013-07-31 11:21:35 shesek has quit (Ping timeout: 268 seconds)
 624 2013-07-31 11:23:07 <arioBarzan> runeks: I also got same result as yours.
 625 2013-07-31 11:23:28 <runeks> arioBarzan: Works on testnet but not on mainnet?
 626 2013-07-31 11:23:59 <arioBarzan> runeks: I just checked mainnet. dunno about testnet.
 627 2013-07-31 11:24:03 bmcgee has quit (Quit: bmcgee)
 628 2013-07-31 11:24:38 <runeks> arioBarzan: Ok. Could you try testnet? Would be nice to confirm whether this always works or it just works for me.
 629 2013-07-31 11:26:35 Prattler has quit (Quit: ZNC - http://znc.in)
 630 2013-07-31 11:29:09 ThomasV has joined
 631 2013-07-31 11:29:13 <sipa> runeks: strange that testnet works
 632 2013-07-31 11:29:21 <sipa> runeks: i'll have a look later
 633 2013-07-31 11:29:51 <sipa> gmaxwell: i'm sure people will demand that, but i don't feel like encouraging it
 634 2013-07-31 11:30:17 <gmaxwell> sipa: okay, fine enough. I didn't comment on that point in the pull with the thought you might be thinking that.
 635 2013-07-31 11:30:18 <runeks> sipa: Could be just me. I have txindex=1 in my bitcoin.conf if that's relevant.
 636 2013-07-31 11:30:30 <sipa> runeks: doesn't matter
 637 2013-07-31 11:33:16 bmcgee has joined
 638 2013-07-31 11:33:33 shesek has joined
 639 2013-07-31 11:35:12 knotwork has quit (Ping timeout: 264 seconds)
 640 2013-07-31 11:36:42 <arioBarzan> runeks: it doesn't work on testnet either.
 641 2013-07-31 11:36:55 <runeks> arioBarzan: Ok. That's odd. I'll try it again.
 642 2013-07-31 11:38:27 <runeks> Still works on testnet for me.
 643 2013-07-31 11:39:02 <sipa> i'm especially surprised that importaddress doesn't rescan
 644 2013-07-31 11:39:13 <sipa> i did not touch that part at all, afaik
 645 2013-07-31 11:39:17 <arioBarzan> I runned the daemon for 4033 blocks on testnet. then stopped it. then disconnected from internet, opened the daemon again and imported the address n4mBcgsUXnnMAXvA7XnTVjWTjghrE9xKRD from block 9 with rescan=true. it did not work.
 646 2013-07-31 11:40:57 <gmaxwell> arioBarzan: what do you mean "with rescan=true"
 647 2013-07-31 11:41:07 <runeks> arioBarzan: What does mainnet say with the listaccounts command? I see the label for the address I added, but the balance for that address (and listunspent, listtransactions etc.) don't show the correct result
 648 2013-07-31 11:41:33 <runeks> I think rescanning might be broken.
 649 2013-07-31 11:42:02 <runeks> Running bitcoind with -rescan doesn't seem to rescan. Is there a way to see whether this is the case besides looking at disk/CPU activity?
 650 2013-07-31 11:42:17 <sipa> runeks: interesting
 651 2013-07-31 11:42:29 <sipa> runeks: anything related in debug.log at startup?
 652 2013-07-31 11:42:29 <arioBarzan> gmaxwell: I used this in console: importaddress n4mBcgsUXnnMAXvA7XnTVjWTjghrE9xKRD third true
 653 2013-07-31 11:43:05 <sipa> maybe some exception is thrown that isn't reported but interrupts rescan
 654 2013-07-31 11:43:32 <runeks> I'll see...
 655 2013-07-31 11:45:45 <runeks> I just see
 656 2013-07-31 11:45:47 <runeks> 2013-07-31 11:43:15 init message: Rescanning...
 657 2013-07-31 11:45:47 <runeks> 2013-07-31 11:43:15 Rescanning last 249415 blocks (from block 0)...
 658 2013-07-31 11:45:47 <runeks> 2013-07-31 11:43:15  rescan                  102ms
 659 2013-07-31 11:45:50 <arioBarzan> runeks: In mainnet, I also see the label of the account in which I imported the address, but no correct result from listunspent, or getbalance, etc.
 660 2013-07-31 11:46:12 <sipa> so rescanning is broken
 661 2013-07-31 11:46:22 <sipa> thanks for the reports, arioBarzan and runeks
 662 2013-07-31 11:46:35 <runeks> Right. It seems like it's added correctly. I get a message saying " Loaded 14tZ8MQBbbZVkbssFbKbD3MfvxnkmVtYK4!" in debug.log, which is the watch-only address I added.
 663 2013-07-31 11:46:41 <runeks> sipa: No prob :)
 664 2013-07-31 11:47:08 <arioBarzan> sipa: No prob.
 665 2013-07-31 11:48:35 <gmaxwell> sipa: address decoding as part of the addr indexing stuff throwing an exception perhaps?
 666 2013-07-31 11:49:38 shesek has quit (Ping timeout: 264 seconds)
 667 2013-07-31 11:52:18 <sipa> gmaxwell: this is not related to addrindex
 668 2013-07-31 11:53:29 ThomasV has quit (Ping timeout: 264 seconds)
 669 2013-07-31 11:54:59 <arioBarzan> sipa: rescan doesn't work maybe because of ismine()
 670 2013-07-31 11:55:07 <arioBarzan> I got this :   NotifyAddressBookChanged 18Ggrm1TsTywghF6r2FPoB9WYVHmUDHPF3 third isMine=0 status=0
 671 2013-07-31 11:55:12 <runeks> sipa: Running with -rescan in gdb seems to work... :\
 672 2013-07-31 11:55:14 <arioBarzan> in debul.log
 673 2013-07-31 11:55:36 <arioBarzan> *debug.log
 674 2013-07-31 11:55:44 <runeks> It's scanning now. Not stopping after ~100ms
 675 2013-07-31 11:58:24 Plinker_ has quit (Read error: Connection reset by peer)
 676 2013-07-31 12:00:09 jeewee1 has joined
 677 2013-07-31 12:00:55 jeewee has quit (Ping timeout: 240 seconds)
 678 2013-07-31 12:02:22 shesek has joined
 679 2013-07-31 12:06:45 <runeks> arioBarzan: Can you try running bitcoind in gdb with -rescan? This works for me.
 680 2013-07-31 12:09:16 <arioBarzan> runeks: maybe later.
 681 2013-07-31 12:11:44 <runeks> Cool.
 682 2013-07-31 12:16:04 shesek has quit (Read error: Operation timed out)
 683 2013-07-31 12:16:41 agnostic98 has joined
 684 2013-07-31 12:17:21 paracyst has joined
 685 2013-07-31 12:19:28 agnostic98 has quit (Read error: Connection reset by peer)
 686 2013-07-31 12:24:53 bmcgee has quit (Quit: bmcgee)
 687 2013-07-31 12:25:36 debianto1user has quit (Ping timeout: 264 seconds)
 688 2013-07-31 12:27:26 debiantoruser has joined
 689 2013-07-31 12:27:43 <sipa> wait, in gdb it works, but not in a normal build?
 690 2013-07-31 12:27:48 <sipa> sounds like i have memory corruption
 691 2013-07-31 12:27:55 <sipa> or some race condition
 692 2013-07-31 12:29:12 [\\\] has quit (Ping timeout: 264 seconds)
 693 2013-07-31 12:30:00 AusBitBank has quit (Ping timeout: 246 seconds)
 694 2013-07-31 12:30:54 shesek has joined
 695 2013-07-31 12:36:48 paraipan has quit (Remote host closed the connection)
 696 2013-07-31 12:37:31 paraipan has joined
 697 2013-07-31 12:40:12 <arioBarzan> wouldn't it be better if we don't block coins of a watch-only address by checking IsMine() in CWallet::AvailableCoins, and instead let them get into CWallet::CreateTransaction but later in SignSignature() we would temporarily ask for the private to sign the coin ?
 698 2013-07-31 12:40:14 jeewee1 has quit (Read error: Connection reset by peer)
 699 2013-07-31 12:40:53 <arioBarzan> *(ask for private key)
 700 2013-07-31 12:42:32 jeewee has joined
 701 2013-07-31 12:44:42 <sipa> that would complicate the interface a lot; for now, i think it's better to limit the signing of watch-only stuff to the raw transaction api
 702 2013-07-31 12:45:52 PiZZaMaN2K is now known as away!~PiZZaMaN2@unaffiliated/pizzaman2k|PiZZaMaN2K
 703 2013-07-31 12:46:00 <gmaxwell> that would require replacing all the non-raw rpc send interfaces with incompatible new ones.
 704 2013-07-31 12:46:10 <gmaxwell> Other than that minor detail I think that would be spiffy.
 705 2013-07-31 12:47:44 AusBitBank has joined
 706 2013-07-31 12:47:46 Muis_ has quit (Read error: Connection reset by peer)
 707 2013-07-31 12:47:48 agnostic98 has joined
 708 2013-07-31 12:48:53 agnostic98 has quit (Read error: Connection reset by peer)
 709 2013-07-31 12:49:38 shesek has quit (Ping timeout: 264 seconds)
 710 2013-07-31 12:49:42 Phoebus has quit (Read error: Operation timed out)
 711 2013-07-31 12:51:04 <arioBarzan> ok, leave the part which allows coins to get into CreateTransaction aside for now. (maybe someone would write code that later). However, I still insist if we have categorize the coins into separate lists (spendable, locked, and watch-only) we wouldn't need to alter the code as much as sipa is currently doing with IsMine()
 712 2013-07-31 12:51:26 wizkid057 has quit (Ping timeout: 264 seconds)
 713 2013-07-31 12:51:28 starsoccer has quit (Ping timeout: 256 seconds)
 714 2013-07-31 12:51:49 Prattler has joined
 715 2013-07-31 12:51:54 EPiSKiNG- has quit (Ping timeout: 276 seconds)
 716 2013-07-31 12:52:03 agricocb has quit (Quit: Leaving.)
 717 2013-07-31 12:52:05 forrestv has quit (Quit: ZNC - http://znc.sourceforge.net)
 718 2013-07-31 12:52:11 <arioBarzan> we could separate watch-only coins in CWallet::AvailableCoins
 719 2013-07-31 12:52:25 <gmaxwell> arioBarzan: uh, making an backward incompatible wallet format change with addtitional record types would be less code?
 720 2013-07-31 12:52:26 <sipa> .. that's exactly what we're doing?
 721 2013-07-31 12:52:51 <sipa> availablecoins calls ismine, and stores in the returned COutput objects whether they're spendable or not
 722 2013-07-31 12:52:55 dfsfdsjkfhkjh has quit (Ping timeout: 264 seconds)
 723 2013-07-31 12:53:06 <arioBarzan> you're doiing that one-by-one every time you make an outgoing transaction.
 724 2013-07-31 12:53:24 <sipa> well, we're calling ismine _already_ one-by-one every time you make an outgoing transactions
 725 2013-07-31 12:53:37 <sipa> yes, that can be improved (a bit), but that's out of scope for this change
 726 2013-07-31 12:53:38 dfsfdsjkfhkjh has joined
 727 2013-07-31 12:54:01 forrestv has joined
 728 2013-07-31 12:54:03 EPiSKiNG- has joined
 729 2013-07-31 12:54:20 starsoccer has joined
 730 2013-07-31 12:54:26 EPiSKiNG- is now known as Guest64641
 731 2013-07-31 12:54:48 <sipa> there are tons of potential caching/indexing opportunities in the wallet code, i'll gladly admit that
 732 2013-07-31 12:55:16 <sipa> and dealing with those would be a significant performance improvement (like balances per account could be stored instead of recomputed on the fly)
 733 2013-07-31 12:55:24 <sipa> but that's a much larger change than this
 734 2013-07-31 12:55:34 <sipa> and a much more dangerous one to get right
 735 2013-07-31 12:55:53 Phoebus has joined
 736 2013-07-31 12:55:55 wizkid057 has joined
 737 2013-07-31 12:56:42 <phantomcircuit> sipa, unpossible
 738 2013-07-31 12:56:48 Lolcust has quit (Quit: Nap time)
 739 2013-07-31 12:57:29 BTCOxygen has joined
 740 2013-07-31 12:58:03 Lolcust has joined
 741 2013-07-31 12:58:04 <arioBarzan> There is no need for "making a backward incompatible wallet", because we don't need to write those lists on disk. It would be the same solution that we already use by lockunspent
 742 2013-07-31 12:58:12 Tom_Soft has joined
 743 2013-07-31 12:58:31 <arioBarzan> lockunspent is not dangerous, why a future lock-watch-only would be dangerous?
 744 2013-07-31 12:59:03 <arioBarzan> it also leads for sure to less changes in the current code, compare with what is sipa doing.
 745 2013-07-31 12:59:10 <gmaxwell> arioBarzan: I think you're spending too much thought right now on a very small optimization when there are very many other ones which are more important that no one has cared to do.
 746 2013-07-31 12:59:28 Tom_Soft has quit (Client Quit)
 747 2013-07-31 12:59:43 <gmaxwell> I don't see how you're saying there would be less changes.
 748 2013-07-31 12:59:54 <sipa> arioBarzan: ok, so you want to keep a list of watch-only coins in the wallet; fine
 749 2013-07-31 13:00:03 <sipa> arioBarzan: how are you going to keep that list up to date?
 750 2013-07-31 13:00:12 <sipa> tell me how you'd implement that, and we'll talk again
 751 2013-07-31 13:02:06 starsoccer has quit (Ping timeout: 268 seconds)
 752 2013-07-31 13:02:10 <sipa> a new transaction arrives, which may or may not be to a watch-only address; you need to update this list (and i believe just that updating code would be as much change as we have now)
 753 2013-07-31 13:02:12 wizkid057 has quit (Ping timeout: 264 seconds)
 754 2013-07-31 13:02:26 forrestv has quit (Quit: ZNC - http://znc.sourceforge.net)
 755 2013-07-31 13:02:29 <sipa> a new key is imported, you need to rebuild this list (as some watch-only coins may have become spendable)
 756 2013-07-31 13:02:47 <sipa> a transaction is removed from the wallet because it is reorganized, you probably want to remove it from this list
 757 2013-07-31 13:03:01 forrestv has joined
 758 2013-07-31 13:03:10 shesek has joined
 759 2013-07-31 13:03:20 starsoccer has joined
 760 2013-07-31 13:03:22 dfsfdsjkfhkjh has quit (Ping timeout: 256 seconds)
 761 2013-07-31 13:03:24 <sipa> please, try to see the whole picture involved before commenting on a small part of it that seems slightly overcomplicated
 762 2013-07-31 13:03:33 MobPhone has quit (Quit: -a- Android IRC 2.1.8 Just need to be Chiznillen)
 763 2013-07-31 13:03:49 dfsfdsjkfhkjh has joined
 764 2013-07-31 13:04:52 knotwork has joined
 765 2013-07-31 13:04:52 knotwork has quit (Changing host)
 766 2013-07-31 13:04:52 knotwork has joined
 767 2013-07-31 13:08:09 Guest64641 has quit (Ping timeout: 276 seconds)
 768 2013-07-31 13:08:12 Phoebus has quit (Ping timeout: 264 seconds)
 769 2013-07-31 13:08:29 starsoccer has quit (Ping timeout: 264 seconds)
 770 2013-07-31 13:08:37 forrestv has quit (Quit: ZNC - http://znc.sourceforge.net)
 771 2013-07-31 13:09:51 starsoccer has joined
 772 2013-07-31 13:09:57 forrestv has joined
 773 2013-07-31 13:09:59 EPiSKiNG has joined
 774 2013-07-31 13:10:22 jeewee has quit (Read error: Connection reset by peer)
 775 2013-07-31 13:10:48 _jps has joined
 776 2013-07-31 13:10:53 Phoebus has joined
 777 2013-07-31 13:10:57 roconnor has joined
 778 2013-07-31 13:11:09 jeewee has joined
 779 2013-07-31 13:11:14 knotwork has quit (Ping timeout: 264 seconds)
 780 2013-07-31 13:11:33 wizkid057 has joined
 781 2013-07-31 13:14:18 denom has joined
 782 2013-07-31 13:14:42 starsoccer has quit (Ping timeout: 256 seconds)
 783 2013-07-31 13:16:34 agricocb has joined
 784 2013-07-31 13:16:54 wizkid057 has quit (Ping timeout: 268 seconds)
 785 2013-07-31 13:17:22 starsoccer has joined
 786 2013-07-31 13:17:25 jeewee has quit (Ping timeout: 240 seconds)
 787 2013-07-31 13:18:25 daybyter has quit (Quit: Konversation terminated!)
 788 2013-07-31 13:18:51 agnostic98 has joined
 789 2013-07-31 13:19:50 _jps has quit (Quit: _jps)
 790 2013-07-31 13:19:58 wizkid057 has joined
 791 2013-07-31 13:20:09 jeewee has joined
 792 2013-07-31 13:20:39 <arioBarzan> ok, that one is not good, so let's assume we leave Mr. IsMine() alone , and instead add a new function IsWatched() and check for that only in CWallet::AvailableCoins.
 793 2013-07-31 13:21:16 agnostic98 has quit (Read error: Connection reset by peer)
 794 2013-07-31 13:21:53 <runeks> sipa: It works for me without gdb too now. Running it for the first time on mainnet importaddress didn't work. it returned immediately and the balance of the added watch-only address was 0.0. Running it with -rescan didn't do anything either. But after running with -rescan in gdb everything works fine now.
 795 2013-07-31 13:23:01 _jps has joined
 796 2013-07-31 13:23:46 starsoccer has quit (Ping timeout: 256 seconds)
 797 2013-07-31 13:24:02 <arioBarzan> gmaxwell: if we leave Mr. IsMine() alone , and instead add a new function IsWatched() and check for that only in CWallet::AvailableCoins, wouldn't it involve less changes?
 798 2013-07-31 13:24:24 EPiSKiNG has quit (Ping timeout: 276 seconds)
 799 2013-07-31 13:24:32 forrestv has quit (Quit: ZNC - http://znc.sourceforge.net)
 800 2013-07-31 13:24:38 <gmaxwell> arioBarzan: we'd need to go walk around and change lots and lots of code to be IsWatched() like all the code that catches changes to addresses.
 801 2013-07-31 13:24:54 wizkid057 has quit (Ping timeout: 256 seconds)
 802 2013-07-31 13:25:01 forrestv has joined
 803 2013-07-31 13:25:31 EPiSKiNG has joined
 804 2013-07-31 13:25:34 bmcgee has joined
 805 2013-07-31 13:25:53 starsoccer has joined
 806 2013-07-31 13:27:01 knotwork has joined
 807 2013-07-31 13:28:12 imton has joined
 808 2013-07-31 13:28:25 wizkid057 has joined
 809 2013-07-31 13:29:06 bmcgee_ has joined
 810 2013-07-31 13:29:12 Phoebus has quit (Ping timeout: 264 seconds)
 811 2013-07-31 13:29:42 Insti has quit (Ping timeout: 245 seconds)
 812 2013-07-31 13:29:58 ThomasV has joined
 813 2013-07-31 13:30:01 mortikia has quit (Remote host closed the connection)
 814 2013-07-31 13:30:10 mortikia has joined
 815 2013-07-31 13:30:11 bmcgee_ has quit (Client Quit)
 816 2013-07-31 13:30:15 melvster has quit (Remote host closed the connection)
 817 2013-07-31 13:30:45 suporte85 has joined
 818 2013-07-31 13:30:57 bmcgee has quit (Ping timeout: 245 seconds)
 819 2013-07-31 13:31:40 _jps has quit (Quit: _jps)
 820 2013-07-31 13:32:37 Phoebus has joined
 821 2013-07-31 13:33:48 <arioBarzan> gmaxwell: so why, in case of lockunspent, we didn't go walk around and change lots and lots of code to set IsLockedCoin() ?
 822 2013-07-31 13:34:08 bmcgee has joined
 823 2013-07-31 13:34:44 <sipa> arioBarzan: because locked coins only change when a user asks for it
 824 2013-07-31 13:34:46 <sipa> that's easy
 825 2013-07-31 13:34:52 bmcgee has quit (Client Quit)
 826 2013-07-31 13:35:02 <arioBarzan> The difference is in incoming tranasction, I see.
 827 2013-07-31 13:35:05 <sipa> watched coins is a concept that automatically changes when even just new transactions arrive
 828 2013-07-31 13:35:10 <sipa> or addresses are imported
 829 2013-07-31 13:36:05 starsoccer has quit (Ping timeout: 264 seconds)
 830 2013-07-31 13:36:11 Namworld has quit ()
 831 2013-07-31 13:36:58 <sipa> moreover, that new code which would go update the set of watched coins when a new transaction arrives, would most easily be implemented by calling (the new) IsMine() on it...
 832 2013-07-31 13:37:13 <roconnor> sipa: do you know what litecoin's scrypt parameters are and why they are considered poor for avoiding GPU implementations?
 833 2013-07-31 13:37:24 EPiSKiNG has quit (Ping timeout: 276 seconds)
 834 2013-07-31 13:37:34 <sipa> roconnor: IIRC they require 256 KiB of memory, or something like that
 835 2013-07-31 13:37:34 Phoebus has quit (Read error: Operation timed out)
 836 2013-07-31 13:37:39 forrestv has quit (Quit: ZNC - http://znc.sourceforge.net)
 837 2013-07-31 13:37:48 PiZZaMaN2K has quit (Quit: Linkinus - http://linkinus.com)
 838 2013-07-31 13:37:52 <gmaxwell> 128KiB.
 839 2013-07-31 13:38:01 <sipa> which means you can still run 4000 in parallel on a 512 MiB graphics card
 840 2013-07-31 13:38:14 wizkid057 has quit (Ping timeout: 264 seconds)
 841 2013-07-31 13:38:25 starsoccer has joined
 842 2013-07-31 13:38:26 <gmaxwell> Which is even less than it sounds because of the cache locality of scrypt. (iirc it always reads in 64 byte chunks)
 843 2013-07-31 13:38:28 forrestv has joined
 844 2013-07-31 13:38:33 EPiSKiNG- has joined
 845 2013-07-31 13:38:45 <gmaxwell> It's even small enough that you can do a computation / memory tradeoff. Though I don't think thats a win on gpus.
 846 2013-07-31 13:38:45 EPiSKiNG- is now known as Guest8752
 847 2013-07-31 13:39:01 <warren> gmaxwell: no, it's done
 848 2013-07-31 13:39:20 <warren> gmaxwell: the sweet spot seems to be half memory
 849 2013-07-31 13:39:50 Phoebus has joined
 850 2013-07-31 13:41:26 <roconnor> wow, the litecoin parameters are surprisingly small.
 851 2013-07-31 13:41:30 wizkid057 has joined
 852 2013-07-31 13:42:06 <warren> If they were higher, block PoW validation would be slow.  I'm not suggesting it was a good idea, it just is.
 853 2013-07-31 13:42:11 <warren> it just exists*.
 854 2013-07-31 13:42:31 <roconnor> warren: hmm
 855 2013-07-31 13:42:56 <sipa> sure, the number of iterations required for the current difficulty is equal to the validator advantage over a miner
 856 2013-07-31 13:43:04 <sipa> so if you make it harder, that number will drop
 857 2013-07-31 13:43:07 <runeks> sipa: The watch-only rescan breaking problem is present on testnet too. And it's also fixed by running bitcoind with -rescan in gdb in this case.
 858 2013-07-31 13:43:37 <sipa> runeks: this smells like some uninitialized variable or other memory corruption
 859 2013-07-31 13:45:41 starsoccer has quit (Ping timeout: 264 seconds)
 860 2013-07-31 13:45:46 <runeks> sipa: So it works in gdb just because it uses different memory locations?
 861 2013-07-31 13:46:06 <phantomcircuit> iirc gdb initalizes some memory with patterns
 862 2013-07-31 13:46:30 Guest8752 has quit (Ping timeout: 276 seconds)
 863 2013-07-31 13:46:38 wizkid057 has quit (Ping timeout: 264 seconds)
 864 2013-07-31 13:46:39 <runeks> Oh.
 865 2013-07-31 13:47:08 <runeks> Memory corruption bugs scare me.
 866 2013-07-31 13:47:26 starsoccer has joined
 867 2013-07-31 13:47:35 EPiSKiNG has joined
 868 2013-07-31 13:49:11 <jgarzik> phantomcircuit, glibc has an environment variable, something like GLIBC_MEMFROB=42, which will initialize all memory to a specified canary value
 869 2013-07-31 13:49:31 <runeks> But I guess we should be able to get an idea of what the offending code is by doing a diff between the first rebase of the watch-only patch, and the second iteration that introduces IsMine() etc. I didn't see the bug using the first version at least.
 870 2013-07-31 13:49:34 <jgarzik> can do so on free etc.
 871 2013-07-31 13:49:39 <jgarzik> makes crashes more predictable, and memory problems more detectable
 872 2013-07-31 13:49:50 <phantomcircuit> yeah that
 873 2013-07-31 13:49:58 <phantomcircuit> jgarzik, i think gdb does that by default
 874 2013-07-31 13:50:18 <phantomcircuit> but iirc it defaults to 0
 875 2013-07-31 13:51:13 <gmaxwell> phantomcircuit: no, the kernel returns 0ed memory.
 876 2013-07-31 13:51:43 <phantomcircuit> gmaxwell, that i know but even memory that's been allocated before iirc ends up being zero'd in gdb
 877 2013-07-31 13:51:50 <gmaxwell> but malloc may happily return previously used memory without dorking with it.
 878 2013-07-31 13:52:10 <phantomcircuit> possibly it's something i changed locally
 879 2013-07-31 13:52:25 <arioBarzan> sipa: when we check for AvailableCoins() do we lock the wallet first?
 880 2013-07-31 13:52:38 <phantomcircuit> arioBarzan, it should be
 881 2013-07-31 13:52:42 MoALTz__ has joined
 882 2013-07-31 13:53:00 EPiSKiNG has quit (Ping timeout: 276 seconds)
 883 2013-07-31 13:53:18 forrestv has quit (Quit: ZNC - http://znc.sourceforge.net)
 884 2013-07-31 13:53:27 <gmaxwell> phantomcircuit: oh in gdb, perhaps.
 885 2013-07-31 13:53:28 normanrichards has joined
 886 2013-07-31 13:53:31 <sipa> arioBarzan: define 'lock'
 887 2013-07-31 13:53:45 <phantomcircuit> gmaxwell, yeah he was wondering why it wasn't crashing in gdb
 888 2013-07-31 13:53:47 starsoccer has quit (Excess Flood)
 889 2013-07-31 13:53:52 dfsfdsjkfhkjh has quit (Ping timeout: 245 seconds)
 890 2013-07-31 13:53:53 <arioBarzan> LOCK(cs_wallet)
 891 2013-07-31 13:53:56 bmcgee has joined
 892 2013-07-31 13:53:57 <sipa> yes
 893 2013-07-31 13:54:02 <warren> runeks: try MALLOC_PERTURB_=X with different values of X
 894 2013-07-31 13:54:05 Phoebus has quit (Ping timeout: 264 seconds)
 895 2013-07-31 13:54:08 <arioBarzan> so if we have already locked the wallet, we don't need to worry about up to dating watch-only coins.
 896 2013-07-31 13:54:27 starsoccer has joined
 897 2013-07-31 13:54:35 EPiSKiNG has joined
 898 2013-07-31 13:54:44 <sipa> arioBarzan: i don't see how that is remotely related to it
 899 2013-07-31 13:54:51 dfsfdsjkfhkjh has joined
 900 2013-07-31 13:54:52 <arioBarzan> exactly here we could check IsWatched() for coins one-by-one
 901 2013-07-31 13:54:53 <sipa> the wallet keeps a state, the transactions
 902 2013-07-31 13:55:00 forrestv has joined
 903 2013-07-31 13:55:00 <warren> jgarzik: MALLOC_PERTURB_=
 904 2013-07-31 13:55:11 patcon has joined
 905 2013-07-31 13:55:14 wizkid057 has joined
 906 2013-07-31 13:55:14 MoALTz_ has quit (Ping timeout: 256 seconds)
 907 2013-07-31 13:55:27 <gmaxwell> if you actually think you have this class of error you should be testing under valgrind memcheck.
 908 2013-07-31 13:55:40 <arioBarzan> sipa: if you agree, then there would be no need to change IsMine()
 909 2013-07-31 13:55:41 <gmaxwell> (or, in general— periodic valgrinding will save your bacon)
 910 2013-07-31 13:55:48 <sipa> arioBarzan: and how would you implement IsWatched()?
 911 2013-07-31 13:56:08 <arioBarzan> Duplicate it from IsMine() with few changes
 912 2013-07-31 13:56:21 Phoebus has joined
 913 2013-07-31 13:56:28 <sipa> ok
 914 2013-07-31 13:56:30 <sipa> go do that
 915 2013-07-31 13:56:34 <sipa> and see how much code you need
 916 2013-07-31 13:56:52 <gmaxwell> arioBarzan: IsMine() is called in about 30 places, most of them would need to be changed to your IsWatched().
 917 2013-07-31 13:57:19 EPiSKiNG has left ()
 918 2013-07-31 13:57:22 <arioBarzan> gmaxwell: I won't touch IsMine() at all
 919 2013-07-31 13:57:30 saulimus has quit (Ping timeout: 246 seconds)
 920 2013-07-31 13:57:32 EPiSKiNG- has joined
 921 2013-07-31 13:57:36 <sipa> no, but you would need to touch all its call sites
 922 2013-07-31 13:57:40 <sipa> plus duplicate code
 923 2013-07-31 13:57:43 <arioBarzan> I'll just add IsWatched() and only use it in AvailableCoins()
 924 2013-07-31 13:57:44 <sipa> please
 925 2013-07-31 13:57:47 <sipa> any other good ideas?
 926 2013-07-31 13:57:59 <sipa> otherwise i'm really done wasting time on this
 927 2013-07-31 13:58:12 <gmaxwell> arioBarzan: You're confused there.
 928 2013-07-31 13:58:46 <sipa> arioBarzan: the whole point of watch-only coins is that they behave identically to normal spendable coins
 929 2013-07-31 13:59:03 <sipa> so any place that currently deals with spendable coins, must get to deal with watch-only coins too
 930 2013-07-31 13:59:12 <sipa> the only exception is creating transactions
 931 2013-07-31 13:59:40 c0rw1n has quit (Remote host closed the connection)
 932 2013-07-31 13:59:51 <sipa> and AvailableCoins() is really not the only place
 933 2013-07-31 13:59:59 <phantomcircuit> sipa, god that sounds like it's gonna be super confusing
 934 2013-07-31 14:01:00 <sipa> well, i think mixing watch-only and spendable coins in one wallet is confusing yourself probably
 935 2013-07-31 14:01:18 <sipa> but before we have decent multiwallet support, it's not really viable to require them to be separated
 936 2013-07-31 14:01:43 Neozonz has quit (Read error: Connection reset by peer)
 937 2013-07-31 14:02:04 <phantomcircuit> i cant imagine it's a good idea to have them in the same wallet
 938 2013-07-31 14:02:09 Neozonz has joined
 939 2013-07-31 14:02:13 <phantomcircuit> i can hear the confused pissed off users now
 940 2013-07-31 14:02:22 _jps has joined
 941 2013-07-31 14:02:23 <phantomcircuit> ghosts of the future
 942 2013-07-31 14:02:25 <arioBarzan> In CWallet::SelectCoins() do we not only check AvailableCoins() ?
 943 2013-07-31 14:03:56 TheUni has quit (Ping timeout: 246 seconds)
 944 2013-07-31 14:03:57 c0rw1n has joined
 945 2013-07-31 14:04:03 Neozonz has quit (Read error: Connection reset by peer)
 946 2013-07-31 14:04:06 <arioBarzan> sipa: I might be wrong because I am not aware any other place that we deal with spending the coins other than SelectCoins()
 947 2013-07-31 14:04:29 Neozonz has joined
 948 2013-07-31 14:04:49 TheUni has joined
 949 2013-07-31 14:04:53 c0rw1n has quit (Remote host closed the connection)
 950 2013-07-31 14:06:15 <arioBarzan> if I'm asking too much questions, tell me and I would not hesitate to stop asking more.
 951 2013-07-31 14:06:49 yubrew has joined
 952 2013-07-31 14:10:25 arioBarzan has left ("Leaving...")
 953 2013-07-31 14:10:34 arioBarzan has joined
 954 2013-07-31 14:10:55 tcatm has quit (Ping timeout: 264 seconds)
 955 2013-07-31 14:12:48 <sipa> arioBarzan: the problem is all other places where IsMine() is called that are NOT related to spending
 956 2013-07-31 14:13:00 <sipa> those would need to be adapted to call IsWatching() as well
 957 2013-07-31 14:14:00 <arioBarzan> sipa: if don't touch IsMine() why we should bother about other places where IsMine is called ? I insist on NOT touching IsMine()
 958 2013-07-31 14:14:21 <arioBarzan> *if (we) don't...
 959 2013-07-31 14:14:59 <gmaxwell> I insist on a billion dollars appearing in my bank account.
 960 2013-07-31 14:15:46 <phantomcircuit> gmaxwell, for how long?
 961 2013-07-31 14:15:47 <jgarzik> sipa, RE pull req #2867 just submitted…  overall goal is to move not-public-blockchain stuff out of main.cpp
 962 2013-07-31 14:15:56 <jgarzik> sipa, trying to cycle up to fork separation
 963 2013-07-31 14:16:01 ericmuyser has joined
 964 2013-07-31 14:16:07 <arioBarzan> why you guys talk about IsMine(). we don't touch it, then only in AvailableCoins() we call IsWatched() as well as IsMine()
 965 2013-07-31 14:16:09 <kjj> well, under Quantum Banking, your account is a seething froth of billions of dollars and anti-dollars whenever you aren't looking at it.  close enough?
 966 2013-07-31 14:16:15 <jgarzik> sipa, there is surprisingly (to me) little remaining wallet code in main.cpp
 967 2013-07-31 14:16:25 <jgarzik> sipa, it is mostly P2P-node stuff already, which is nice
 968 2013-07-31 14:16:31 <phantomcircuit> gmaxwell, ACH has properties similar to blockchain.info unconfirmed transactions
 969 2013-07-31 14:17:23 <sipa> arioBarzan: i'm not sure how i can explain that any further
 970 2013-07-31 14:17:42 <gmaxwell> arioBarzan: You are not pausing to think about what we actually need to do here, I'm not sure what else can be said to make it clear.
 971 2013-07-31 14:17:57 <sipa> arioBarzan: for almost every purpose, watched and spendable coins need to be treated almost identically
 972 2013-07-31 14:18:07 <gmaxwell> arioBarzan: when a block arrives with new transactions we must check their outputs and add the ones we care about to our wallet.
 973 2013-07-31 14:18:15 <gmaxwell> (I'm giving an example)
 974 2013-07-31 14:18:27 <sipa> arioBarzan: that is why it is jntegrated in IsMine, so every caller of it automatically gets the watch-only functionality
 975 2013-07-31 14:18:31 <gmaxwell> arioBarzan: that includes all watched and all spendable transactions.
 976 2013-07-31 14:18:41 <sipa> jgarzik: fully in favor of splitting of mining code
 977 2013-07-31 14:18:53 <gmaxwell> By making IsMine returned watched coins then all that just works.
 978 2013-07-31 14:19:09 <jgarzik> sipa, wallet dispatch (for each wallet…) is only remaining bit, after that, to be moved
 979 2013-07-31 14:19:12 <jgarzik> doing that now
 980 2013-07-31 14:19:32 <gmaxwell> If you have a seperate IsWatched then all those chain reorg cases would need to be changed to check IsWatched()
 981 2013-07-31 14:19:55 <sipa> jgarzik: regarding forking... my preferred approach is having a no-rpc no-wallet bitcoind process and a separate gui/rpc/wallet process, simply communicating over p2p/spv
 982 2013-07-31 14:21:28 <jgarzik> sipa, That's a fine long term goal, though I wonder if an incremental approach isn't better:  API separation -> fork() separation -> separate programs.
 983 2013-07-31 14:21:46 <jgarzik> sipa, I also think bitcoind will retain RPC or HTTP REST or -some- form of API control and query
 984 2013-07-31 14:21:53 <arioBarzan> IsMine() is not altered at all in pull/2121? why there it works ?
 985 2013-07-31 14:21:55 <sipa> probably yeah
 986 2013-07-31 14:21:56 CheckDavid has quit (Quit: Leaving)
 987 2013-07-31 14:22:24 <sipa> arioBarzan: it's via keystore in 2121
 988 2013-07-31 14:22:37 <sipa> the address is added as a fake key to the store
 989 2013-07-31 14:22:43 <sipa> so ismine matches it implicitly
 990 2013-07-31 14:22:59 <sipa> in my pull, they are handled separately and a bit more generally
 991 2013-07-31 14:23:14 <kjj> sipa: just the other day I was wondering how hard it would be to add a make flag to build a binary without the wallet stuff
 992 2013-07-31 14:24:21 <arioBarzan> Isn't that fake one easier to implement? If one adds a Iswatched() and call it only in AvailableCoins() there would be no more issues.
 993 2013-07-31 14:25:19 <arioBarzan> sipa: the good point about fake key is we could alter all keys to fake and vice versa whenever we will
 994 2013-07-31 14:25:45 frib has joined
 995 2013-07-31 14:26:26 <arioBarzan> sipa: Armory has something similar, that sweeps the keys.
 996 2013-07-31 14:26:49 <frib> Hi.  I'm trying to sign a transaction but getting the flag complete: false, and the hex remains unchanged.  However, I am able to sign a message with the same address.  What's up with this?
 997 2013-07-31 14:27:14 <sipa> arioBarzan: dealing with it explicitly is necessary for 1) p2sh support 2) listig spendability in listspendable 3) excluding watch-only from creating transactions
 998 2013-07-31 14:27:40 <sipa> arioBarzan: i'm done discussing this; you argue for simplifying things without having a clue of the repercussions or downsides
 999 2013-07-31 14:27:43 <phantomcircuit> sipa, that's a pretty good design for separating issues
1000 2013-07-31 14:27:45 <phantomcircuit> i like
1001 2013-07-31 14:27:48 <sipa> arioBarzan: sorry
1002 2013-07-31 14:27:49 <phantomcircuit> me gusta
1003 2013-07-31 14:27:54 <kjj> frib: p2sh, multisig, or just plain regular sendtoaddres in raw form?
1004 2013-07-31 14:28:17 <frib> kjj, createrawtransaction -> signrawtransaction
1005 2013-07-31 14:28:25 <jgarzik> mi gusto
1006 2013-07-31 14:29:03 <sipa> arioBarzan: i have by now spent more time discussing this with you than implementing it cost me
1007 2013-07-31 14:29:05 <jgarzik> speaking of…  IMO there are a few places that could use an optional sweep-on-import
1008 2013-07-31 14:29:26 <jgarzik> nice for added security
1009 2013-07-31 14:29:37 <kjj> frib: post a paste of the commands you are using?
1010 2013-07-31 14:29:41 gst has quit (Ping timeout: 240 seconds)
1011 2013-07-31 14:30:43 <arioBarzan> sipa: I appreciate your answers, however I said earlier to tell me if I shouldn't ask anymore questions.
1012 2013-07-31 14:30:50 gst has joined
1013 2013-07-31 14:30:55 <phantomcircuit> arioBarzan, let me help, shhhhh
1014 2013-07-31 14:31:26 <sipa> arioBarzan: i don't mind discussing things or even just explaining things, so no hard feelings... but if you keep hammering on the same tiny issue, sorry :)
1015 2013-07-31 14:36:32 [\\\] has joined
1016 2013-07-31 14:37:35 MoALTz__ has quit (Quit: brb)
1017 2013-07-31 14:37:43 Neozonz has quit (Read error: Connection reset by peer)
1018 2013-07-31 14:37:56 MoALTz has joined
1019 2013-07-31 14:38:09 Neozonz has joined
1020 2013-07-31 14:40:03 Lolcust has quit (Quit: Nap time)
1021 2013-07-31 14:40:55 Lolcust has joined
1022 2013-07-31 14:41:48 AusBitBank has quit (Ping timeout: 264 seconds)
1023 2013-07-31 14:41:51 tcatm has joined
1024 2013-07-31 14:41:51 tcatm has quit (Changing host)
1025 2013-07-31 14:41:51 tcatm has joined
1026 2013-07-31 14:42:48 <arioBarzan> sipa: I'm sorry that I made you frustrated. I should have provided all of my argument, short and organized to not waste your time, with such a long "keep hammering" attitude :)
1027 2013-07-31 14:42:49 atweiden has joined
1028 2013-07-31 14:45:05 arioBarzan has left ()
1029 2013-07-31 14:46:23 <frib> where should I pastE?
1030 2013-07-31 14:47:55 <frib> kjj, here's a summary of what I'm trying to do: http://paste.debian.net/20867/
1031 2013-07-31 14:48:28 Lolcust has quit (Quit: Nap time)
1032 2013-07-31 14:48:39 <frib> there shouldn't be any problem having a tx pay change to the originating address and/or without a tx fee, right? It should still sign regardless?
1033 2013-07-31 14:48:43 Lolcust has joined
1034 2013-07-31 14:48:43 Lolcust has quit (Excess Flood)
1035 2013-07-31 14:49:13 Lolcust has joined
1036 2013-07-31 14:49:59 <kjj> frib: if the signing wallet already has the key, you can skip everything but the hex
1037 2013-07-31 14:50:28 <frib> you're referring to the signrawtransaction command?
1038 2013-07-31 14:50:33 agnostic98 has joined
1039 2013-07-31 14:50:43 <kjj> frib: the raw transaction API only looks at pure transaction validity.  it doesn't know about fees, doesn't care about them
1040 2013-07-31 14:51:01 <frib> I took that for granted, but I can't imagine what else would be wrong
1041 2013-07-31 14:51:06 <frib> initially I did it only with the hex but it still didn't sign
1042 2013-07-31 14:51:36 <kjj> does the wallet doing the signing have the key?
1043 2013-07-31 14:51:46 <frib> it has to I signed a message with the address
1044 2013-07-31 14:51:51 <frib> and then successfully verified it
1045 2013-07-31 14:51:55 <frib> I can dump the priv key
1046 2013-07-31 14:52:07 <kjj> hmm, hang on.  how offline is your offline wallet?
1047 2013-07-31 14:52:13 <frib> completely offline
1048 2013-07-31 14:52:26 <frib> 100%
1049 2013-07-31 14:52:39 bbrian has joined
1050 2013-07-31 14:52:53 agnostic98 has quit (Read error: Connection reset by peer)
1051 2013-07-31 14:53:43 <kjj> your sign command specifies vout:1.  is that right?
1052 2013-07-31 14:53:45 samban has joined
1053 2013-07-31 14:54:10 <frib> I believe it is, but to be 100% sure can I give you the tx number?
1054 2013-07-31 14:54:29 bbrian has quit (Client Quit)
1055 2013-07-31 14:54:35 <kjj> it should be the same vout used in createrawtransaction
1056 2013-07-31 14:54:45 zm0 has quit (Ping timeout: 250 seconds)
1057 2013-07-31 14:54:54 <frib> it is
1058 2013-07-31 14:55:04 <frib> can I pm you?
1059 2013-07-31 14:55:07 <kjj> as in, <txid,vout> specify the same input in both places
1060 2013-07-31 14:55:10 <kjj> sure
1061 2013-07-31 14:56:42 <jgarzik> sipa, done
1062 2013-07-31 14:57:02 CheckDavid has joined
1063 2013-07-31 14:57:13 <jgarzik> sipa, next step, trivial API transformations, then fork() on Unix (while still working just fine on Windows with a thread)
1064 2013-07-31 14:57:41 <jgarzik> fork() is a minimal incremental step that proves -- by kernel process separation -- that the two sides of code may live and function independently of each other
1065 2013-07-31 14:58:05 <jgarzik> from there it is another straightforward incremental step to have two separate programs
1066 2013-07-31 14:58:57 GordonG3kko has quit (Remote host closed the connection)
1067 2013-07-31 15:00:35 saulimus has joined
1068 2013-07-31 15:00:38 HaltingState has quit (Read error: Connection reset by peer)
1069 2013-07-31 15:01:43 GordonG3kko has joined
1070 2013-07-31 15:02:07 Lolcust has quit (Quit: Nap time)
1071 2013-07-31 15:02:59 c0rw1n has joined
1072 2013-07-31 15:03:25 Neozonz has quit (Read error: Connection reset by peer)
1073 2013-07-31 15:03:45 normanrichards has quit (Quit: normanrichards)
1074 2013-07-31 15:03:49 Neozonz has joined
1075 2013-07-31 15:03:52 Lolcust has joined
1076 2013-07-31 15:05:50 HaltingState has joined
1077 2013-07-31 15:07:28 c0rw1n has quit (Ping timeout: 256 seconds)
1078 2013-07-31 15:11:56 Insti has joined
1079 2013-07-31 15:12:43 <jgarzik> BlueMatt: Let me publicly admit in this logged channel:  I was wrong about CBlockEngine
1080 2013-07-31 15:15:34 frib has quit (Quit: Leaving)
1081 2013-07-31 15:21:10 agnostic98 has joined
1082 2013-07-31 15:23:01 guruvan has quit (Ping timeout: 240 seconds)
1083 2013-07-31 15:24:27 agnostic98 has quit (Read error: Connection reset by peer)
1084 2013-07-31 15:24:34 guruvan has joined
1085 2013-07-31 15:26:05 realzies has joined
1086 2013-07-31 15:26:05 realzies has quit (Changing host)
1087 2013-07-31 15:26:05 realzies has joined
1088 2013-07-31 15:26:32 grib has joined
1089 2013-07-31 15:27:49 agnostic98 has joined
1090 2013-07-31 15:29:54 samban has left ()
1091 2013-07-31 15:30:17 samban has joined
1092 2013-07-31 15:37:48 samban has left ()
1093 2013-07-31 15:38:20 Neozonz has joined
1094 2013-07-31 15:39:50 ericmuyser has quit (Remote host closed the connection)
1095 2013-07-31 15:40:01 peetaur2 has joined
1096 2013-07-31 15:41:41 jedunnigan has joined
1097 2013-07-31 15:41:49 Neozonz has quit (Ping timeout: 268 seconds)
1098 2013-07-31 15:42:31 Dyaheon has quit ()
1099 2013-07-31 15:45:27 normanrichards has joined
1100 2013-07-31 15:45:41 bmcgee has quit (Ping timeout: 264 seconds)
1101 2013-07-31 15:54:40 daybyter has joined
1102 2013-07-31 15:54:48 patcon_ has joined
1103 2013-07-31 15:55:03 patcon has quit (Ping timeout: 264 seconds)
1104 2013-07-31 15:55:04 MobPhone has joined
1105 2013-07-31 15:56:01 <sipa> jgarzik: moving the management of wallets from main to wallet if very ugly, imho
1106 2013-07-31 15:56:14 <sipa> i also don't see why it's necessary?
1107 2013-07-31 15:56:29 <sipa> if anything, those should be converted to signals that wallets register to
1108 2013-07-31 15:56:38 t7 has quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212])
1109 2013-07-31 15:56:48 <sipa> but making wallet responsible for dispatching to wallets feels like wrong design to me
1110 2013-07-31 15:58:47 <jgarzik> sipa, it's just a code organization placement choice.  could easily be dispatch.cpp instead.
1111 2013-07-31 15:59:14 <sipa> jgarzik: i feel main is the only meaningful place for it
1112 2013-07-31 15:59:22 <sipa> it's main that is sending the signals...?
1113 2013-07-31 15:59:59 <sipa> if the problem is the dependency of main on wallet, the solution is using signals instead of the ad-hoc registration stuff now
1114 2013-07-31 16:00:06 grib has left ()
1115 2013-07-31 16:00:13 _jps has quit (Quit: _jps)
1116 2013-07-31 16:00:20 <sipa> (or have a BlockChainEventListener in main.h, implemented by wallet)
1117 2013-07-31 16:00:51 _jps has joined
1118 2013-07-31 16:01:52 knotwork has quit (Ping timeout: 256 seconds)
1119 2013-07-31 16:02:14 <sipa> that would also remove the dependency on wallet.h in main.cpp
1120 2013-07-31 16:02:22 <sipa> which is ugly now
1121 2013-07-31 16:03:12 <jgarzik> sipa, agreed
1122 2013-07-31 16:03:48 <jgarzik> sipa, in general I tend to think of BCE (blockchain engine) as "server" and wallet as "client", though obviously async messages can be triggered at any time by either party
1123 2013-07-31 16:04:28 <jgarzik> I hate boost signals
1124 2013-07-31 16:04:31 patcon has joined
1125 2013-07-31 16:04:35 chmod755 has joined
1126 2013-07-31 16:04:54 <jgarzik> and given that this will eventually be moved across a fork boundary, a wrapper class for the wallet side seems like the best long term plan
1127 2013-07-31 16:05:13 <jgarzik> boost signals would work in step 1, then update the wrapper class to boost:: interprocess calls in step 2.
1128 2013-07-31 16:05:32 patcon_ has quit (Ping timeout: 245 seconds)
1129 2013-07-31 16:05:52 <sipa> i don't care if you use boost signals (imho they are neat, and apart from the fact that it requires a boost dependency - which is at this point inevitable - i have no problems with it) or a BlockChainEventListener
1130 2013-07-31 16:05:59 <jgarzik> then finally wrapper class becomes a wrapper for walletd<->blockchaind RPC/P2P calls
1131 2013-07-31 16:06:07 <sipa> huh
1132 2013-07-31 16:06:07 <jgarzik> in step 3
1133 2013-07-31 16:06:20 <sipa> eventually, you'll just have a SPV client with the wallet/gui in
1134 2013-07-31 16:06:32 jedunnigan has quit (Remote host closed the connection)
1135 2013-07-31 16:06:33 <sipa> and a full but otherwise simple bitcoind
1136 2013-07-31 16:06:42 <sipa> no need for any RPC for wallet
1137 2013-07-31 16:06:44 <sipa> bah
1138 2013-07-31 16:07:32 <sipa> which is why i'm not sure about the fork split now - working on SPV seems a much more useful end solution
1139 2013-07-31 16:07:40 <jgarzik> It seems likely that -some- wallet client will find blockchain query RPCs/REST useful, outside of current P2P protocol
1140 2013-07-31 16:07:52 knotwork has joined
1141 2013-07-31 16:07:56 jeewee has quit (Ping timeout: 240 seconds)
1142 2013-07-31 16:08:11 <sipa> jgarzik: maybe, but as of now, there is no need for that
1143 2013-07-31 16:08:14 <sipa> which is super-neat, imho
1144 2013-07-31 16:09:46 <sipa> so, while i love the encapsulation and dependency-breaking results of working towards a split-process solution, i'm not sure whether actually doing this is worth it
1145 2013-07-31 16:12:51 <jgarzik> I think full, two-executable separation is a ways off, even if SPV is done.  You must fix all the installer issues for multi-exe, educate users, test, etc.   Presuming that, it is IMO nice and useful to have a fork() separation in the meantime, and should not set back the process-separation effort.
1146 2013-07-31 16:14:01 <sipa> it could be the same code base, and the same binary - just a main "wallet" SPV process that optionally splits off a full one in the background
1147 2013-07-31 16:14:06 yubrew has quit (Remote host closed the connection)
1148 2013-07-31 16:14:17 <jgarzik> yep
1149 2013-07-31 16:14:31 <sipa> i just like the P2P protocol much more as a communication mechanism than anything we'd invent or RPC
1150 2013-07-31 16:14:56 <jgarzik> sipa, agree
1151 2013-07-31 16:15:07 <sipa> as it's asynchronous, fast, does not require exclusively locking the whole thing, and most of all: it's already being used to implement wallets!
1152 2013-07-31 16:15:23 <jgarzik> sipa, though I don't think current P2P protocol encompasses 100% of a wallet client's needs
1153 2013-07-31 16:15:26 <sipa> it does
1154 2013-07-31 16:15:28 bitbitbyte has quit (Quit: Lämnar)
1155 2013-07-31 16:15:56 <sipa> afaik, our wallet does not at any point rely on the full blockchain or UTXO state being available
1156 2013-07-31 16:16:04 <sipa> (well, it does in some legacy code)
1157 2013-07-31 16:16:08 yubrew has joined
1158 2013-07-31 16:16:17 nsh has quit (Changing host)
1159 2013-07-31 16:16:17 nsh has joined
1160 2013-07-31 16:16:34 <jgarzik> sipa, people still want access to the full tx index or upcoming address index.  will that be exposed via P2P?
1161 2013-07-31 16:17:03 <sipa> jgarzik: then they talk to the blockchain process, not the wallet process
1162 2013-07-31 16:17:13 ericmuyser has joined
1163 2013-07-31 16:17:18 <sipa> i mean, we could still have a debug console that exposes that functionality
1164 2013-07-31 16:17:31 melvster has joined
1165 2013-07-31 16:18:20 <gmaxwell> I'd assumed the blockchain process would still have an RPC for that stuff.. also connection stats, p2p networking stuff, etc.
1166 2013-07-31 16:18:26 <sipa> yeah, indeed
1167 2013-07-31 16:18:45 bitbitbyte has joined
1168 2013-07-31 16:18:50 roro__ has joined
1169 2013-07-31 16:18:52 nowan has joined
1170 2013-07-31 16:18:57 <sipa> jgarzik: the current wallet code does not use the blockchain's txindex for example
1171 2013-07-31 16:18:58 <gmaxwell> and the spv client would just know how to use that too, for whatever of that you want to make available in it directly / via a debug console.
1172 2013-07-31 16:19:04 <jgarzik> sipa, that's the point I'm headed towards -- the Qt or command line "wallet client" will in practice be querying some of that blockchaind RPCs
1173 2013-07-31 16:19:11 <jgarzik> and thus, not 100% P2P in practice
1174 2013-07-31 16:19:22 <sipa> not in any "normal" usage
1175 2013-07-31 16:19:30 <gmaxwell> I think it's fine and good if it has more functionality when used with a trusted bitcoind.
1176 2013-07-31 16:19:32 <sipa> in a debug console it's useful, but not necessary
1177 2013-07-31 16:19:42 <gmaxwell> But should still have all the basic functionality.
1178 2013-07-31 16:19:58 <jgarzik> sipa, I agree it is not "needed" or "necessary".  But will wallet client include that functionality?  Yes.
1179 2013-07-31 16:20:26 <jgarzik> useful == included == must be designed-for and supported
1180 2013-07-31 16:20:30 <sipa> jgarzik: sure, but no way to have deeply buried logic for interprocess communication in our core code for that
1181 2013-07-31 16:20:38 <sipa> jgarzik: it'd be just some UI that sends JSON-RPC
1182 2013-07-31 16:21:04 <sipa> s/way/need/
1183 2013-07-31 16:22:03 <sipa> note that you _can_ use "trusted" data via P2P, for example, you shouldn't rely on the mempool P2P command in the public internet to give you valid transactions
1184 2013-07-31 16:22:11 <gmaxwell> basically you shouldn't have to choose to use a _different_ wallet if you just want low resource usage. But you shouldn't be forced to forgo advanced features just because you use a client that can work with low resources.
1185 2013-07-31 16:22:14 <sipa> but if you have your own blockchain daemon, you can use it
1186 2013-07-31 16:22:50 <davec> hey guys.  I noticed that nChainWork sums up uint256 values.  This is fine for the main network because max proof of work is 2^224-1, and max blocks are 2^32-1.  2^224-1 * 2^32-1 < 2^256-1.  Hence you don't overflow.
1187 2013-07-31 16:22:54 <davec> But for the regression test network, max proof of work is 2^255-1.  If I'm not mistaken, that means the nChainWork accumulator can (and will) overflow because it uses getuint256 which truncates.
1188 2013-07-31 16:22:59 <davec> When that happens, nChainWork for A will be > B when it shouldn't be.  Won't that cause different behavior between the regression test and main networks?
1189 2013-07-31 16:23:16 <sipa> davec: if nChainWork overflows, we have boiled the oceans
1190 2013-07-31 16:23:32 <sipa> it literally means we have done 2^256 double-SHA256 iterations
1191 2013-07-31 16:24:08 <sipa> davec: nChainWork is the sum of 2^256/target, not the sum of target
1192 2013-07-31 16:24:29 CheckDavid has quit (Quit: Leaving)
1193 2013-07-31 16:24:58 <sipa> jgarzik: what i want to avoid is that we clutter or core code with interprocess wrapping stuff because we move functionality to another process
1194 2013-07-31 16:25:45 <jgarzik> certainly
1195 2013-07-31 16:26:17 <sipa> jgarzik: when almost all functionality can just be done by making the wallet SPV, and the few cases where you want to use trusted data from your own bitcoind, can be implemented pretty much as extensions in high-level code
1196 2013-07-31 16:26:46 <jgarzik> the core code shouldn't change much at all.  It's just a few callbacks, as my wallet-move commit demonstrates.  Just need to change the guts of those callbacks.
1197 2013-07-31 16:27:18 <sipa> i'm in favor of turning them into boost signals, or having a BlockChainEventListener
1198 2013-07-31 16:27:25 <sipa> then you can do pretty much everything
1199 2013-07-31 16:27:28 <davec> sipa: ah right thanks.  So in the case of the regresion test network that is 2^256/2^255 = 2^1  (excluding the -1 there for ease of math)
1200 2013-07-31 16:27:33 <sipa> davec: indeed
1201 2013-07-31 16:27:38 porquilho has joined
1202 2013-07-31 16:27:53 _jps has quit (Quit: _jps)
1203 2013-07-31 16:28:05 patcon has quit (Remote host closed the connection)
1204 2013-07-31 16:31:52 zer0def has quit (Ping timeout: 246 seconds)
1205 2013-07-31 16:32:55 Someguy123 has quit (Ping timeout: 246 seconds)
1206 2013-07-31 16:34:09 Someguy123 has joined
1207 2013-07-31 16:34:24 Apexseals has quit (Read error: Connection reset by peer)
1208 2013-07-31 16:34:47 Apexseals has joined
1209 2013-07-31 16:37:19 Someguy123 has quit (Max SendQ exceeded)
1210 2013-07-31 16:39:53 Someguy123 has joined
1211 2013-07-31 16:48:48 yubrew has quit (Remote host closed the connection)
1212 2013-07-31 16:49:20 egis has joined
1213 2013-07-31 16:49:50 yubrew has joined
1214 2013-07-31 16:54:18 Bezzeb has quit (Quit: Leaving.)
1215 2013-07-31 16:55:49 denom has quit (Ping timeout: 268 seconds)
1216 2013-07-31 16:56:05 daybyter has quit (Quit: Konversation terminated!)
1217 2013-07-31 16:58:53 imton_ has joined
1218 2013-07-31 16:59:31 imton has quit (Ping timeout: 246 seconds)
1219 2013-07-31 16:59:31 imton_ is now known as imton
1220 2013-07-31 17:00:47 Skav has joined
1221 2013-07-31 17:02:45 Skav has quit (Read error: Connection reset by peer)
1222 2013-07-31 17:03:19 Skav has joined
1223 2013-07-31 17:03:24 MobPhone has quit (Ping timeout: 264 seconds)
1224 2013-07-31 17:04:17 bmcgee has joined
1225 2013-07-31 17:04:28 cads has joined
1226 2013-07-31 17:06:26 <jgarzik> sipa, ACK the initial miner separation (separate pull), yes?
1227 2013-07-31 17:06:41 <sipa> jgarzik: i haven't looked at the code; i very much agree with the idea
1228 2013-07-31 17:07:00 <sipa> in fact, you beat me to it :p
1229 2013-07-31 17:07:28 tmsk has quit (Quit: tmsk)
1230 2013-07-31 17:09:23 Skav has quit (Read error: Connection reset by peer)
1231 2013-07-31 17:10:19 MobPhone has joined
1232 2013-07-31 17:13:50 <petertodd> Luke-Jr: I gotta look at that mempool code again, have been auditing litecoin and other things since I last touched it.
1233 2013-07-31 17:13:54 Applicat_ has quit (Remote host closed the connection)
1234 2013-07-31 17:14:51 MobPhone has quit (Ping timeout: 264 seconds)
1235 2013-07-31 17:18:29 patcon has joined
1236 2013-07-31 17:19:53 kadoban has joined
1237 2013-07-31 17:28:09 i2pRelay has quit (Remote host closed the connection)
1238 2013-07-31 17:28:35 i2pRelay has joined
1239 2013-07-31 17:31:33 Someguy123 has quit (Max SendQ exceeded)
1240 2013-07-31 17:32:16 Someguy123 has joined
1241 2013-07-31 17:32:28 denom has joined
1242 2013-07-31 17:37:51 yubrew has quit (Remote host closed the connection)
1243 2013-07-31 17:38:03 bbrian has joined
1244 2013-07-31 17:38:07 yubrew has joined
1245 2013-07-31 17:39:41 Applicat_ has joined
1246 2013-07-31 17:39:46 handle_ has joined
1247 2013-07-31 17:40:50 _jps has joined
1248 2013-07-31 17:41:21 KillYourTV has quit (Ping timeout: 240 seconds)
1249 2013-07-31 17:41:21 handle has quit (Ping timeout: 240 seconds)
1250 2013-07-31 17:41:54 jedunnigan has joined
1251 2013-07-31 17:43:48 KillYourTV has joined
1252 2013-07-31 17:44:31 suporte85 has quit (Quit: Saindo)
1253 2013-07-31 17:47:42 Applicat_ has quit (Remote host closed the connection)
1254 2013-07-31 17:52:01 jedunnigan has quit (Read error: Connection reset by peer)
1255 2013-07-31 17:55:00 debiantoruser has quit (Ping timeout: 264 seconds)
1256 2013-07-31 17:56:15 Someguy123 has quit (Quit: ZNC - http://znc.sourceforge.net)
1257 2013-07-31 17:56:41 debiantoruser has joined
1258 2013-07-31 17:57:27 melvster has quit (Ping timeout: 264 seconds)
1259 2013-07-31 18:00:48 MobPhone has joined
1260 2013-07-31 18:01:17 chorao has joined
1261 2013-07-31 18:01:36 normanrichards has quit (Quit: normanrichards)
1262 2013-07-31 18:02:29 brson has joined
1263 2013-07-31 18:02:38 toffoo has joined
1264 2013-07-31 18:03:35 devrando1 is now known as devrandom
1265 2013-07-31 18:04:01 rdponticelli has quit (Ping timeout: 240 seconds)
1266 2013-07-31 18:04:32 Someguy123 has joined
1267 2013-07-31 18:04:47 <_jps> If I want to spend bitcoins from a multisig account, is there a way to look up valid txid's to use, or is the only way to keep a record of the txids from the funding transactions?
1268 2013-07-31 18:05:00 zer0def has joined
1269 2013-07-31 18:05:58 brson has quit (Client Quit)
1270 2013-07-31 18:06:40 brson has joined
1271 2013-07-31 18:07:18 <Luke-Jr> _jps: you mean a multisig output?
1272 2013-07-31 18:07:23 <Luke-Jr> or a multisig P2SH address?
1273 2013-07-31 18:07:40 <Luke-Jr> there aren't multisig accounts (yet?)…
1274 2013-07-31 18:08:20 <_jps> maybe account was the wrong word
1275 2013-07-31 18:08:33 <_jps> looking at: https://gist.github.com/gavinandresen/3966071
1276 2013-07-31 18:09:02 <_jps> gavin does `createmultisig`
1277 2013-07-31 18:09:26 <_jps> and sends bitcoin to the returned address
1278 2013-07-31 18:11:41 Subo1978 has quit (Ping timeout: 240 seconds)
1279 2013-07-31 18:11:50 Subo1978_ has joined
1280 2013-07-31 18:12:31 rdponticelli has joined
1281 2013-07-31 18:12:31 <_jps> then used the txid from the funding transaction in `createrawtransaction`, and signs it with two private keys
1282 2013-07-31 18:14:32 Someguy123 has quit (Excess Flood)
1283 2013-07-31 18:15:33 Someguy123 has joined
1284 2013-07-31 18:15:58 <_jps> in his example, he sends the funding and spending transactions at the same time, but I assume that doesn't have to be the case
1285 2013-07-31 18:18:10 ericmuyser has quit (Remote host closed the connection)
1286 2013-07-31 18:19:02 agnostic_ has joined
1287 2013-07-31 18:19:24 richcollins has joined
1288 2013-07-31 18:22:36 agnostic98 has quit (Ping timeout: 264 seconds)
1289 2013-07-31 18:28:10 GordonG3kko has quit (Remote host closed the connection)
1290 2013-07-31 18:30:49 GordonG3kko has joined
1291 2013-07-31 18:31:30 canar has quit (Remote host closed the connection)
1292 2013-07-31 18:32:31 owowo has joined
1293 2013-07-31 18:36:24 jeewee has joined
1294 2013-07-31 18:40:29 <ThomasV> gmaxwell: bip32 says " Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG. "
1295 2013-07-31 18:41:01 <ThomasV> why is there this "advised"
1296 2013-07-31 18:41:17 thrasher` has quit (Remote host closed the connection)
1297 2013-07-31 18:41:35 <ThomasV> I assume 128 is safe, or it would not be in the spec
1298 2013-07-31 18:41:36 thrasher` has joined
1299 2013-07-31 18:42:29 normanrichards has joined
1300 2013-07-31 18:43:47 harningt has joined
1301 2013-07-31 18:44:32 Internet13 has quit (Quit: Leaving)
1302 2013-07-31 18:45:45 gst has quit (Remote host closed the connection)
1303 2013-07-31 18:47:19 brson has quit (Quit: Lost terminal)
1304 2013-07-31 18:48:29 brson has joined
1305 2013-07-31 18:50:04 Internet13 has joined
1306 2013-07-31 18:53:46 egis has quit (Quit: Leaving)
1307 2013-07-31 18:55:04 gst has joined
1308 2013-07-31 18:56:39 richcollins has quit (Quit: richcollins)
1309 2013-07-31 19:01:18 Application has joined
1310 2013-07-31 19:08:27 roconnor has quit (Ping timeout: 245 seconds)
1311 2013-07-31 19:08:50 PiZZaMaN2K has joined
1312 2013-07-31 19:09:02 justusranvier has quit (Ping timeout: 240 seconds)
1313 2013-07-31 19:14:13 danda_ has joined
1314 2013-07-31 19:16:56 tmsk has joined
1315 2013-07-31 19:17:25 danda has quit (Ping timeout: 246 seconds)
1316 2013-07-31 19:18:31 Application has quit (Remote host closed the connection)
1317 2013-07-31 19:20:09 freewil has joined
1318 2013-07-31 19:23:03 <maaku> ThomasV: how much do you trust your RNG?
1319 2013-07-31 19:24:48 <handle_> I didn't realize you're supposed to put "trust" in an RNG
1320 2013-07-31 19:25:00 handle_ is now known as handle
1321 2013-07-31 19:26:18 <maaku> handle: that's why you include more bits...
1322 2013-07-31 19:26:52 <handle> what does including more bits have to do with trust?
1323 2013-07-31 19:27:03 <handle> does adding more bits allow you to "trust" your RNG more?
1324 2013-07-31 19:27:05 <maaku> what do you mean by trust?
1325 2013-07-31 19:27:16 <maaku> i mean: trust that it is, in fact, random
1326 2013-07-31 19:27:17 <handle> 03:24 < maaku> ThomasV: how much do you trust your RNG?
1327 2013-07-31 19:28:04 <handle> things like RNGs shouldn't have trust; they should have proof
1328 2013-07-31 19:28:09 <maaku> if it has only 0.9 bits entropy per generated bit, then you're actually at 115 bits of security, not 128
1329 2013-07-31 19:28:22 <nsh> lol
1330 2013-07-31 19:28:32 <maaku> um.. right
1331 2013-07-31 19:28:43 <nsh> handle, can i be coauthor on your paper to prove randomness of a bitsream
1332 2013-07-31 19:28:45 <nsh> *stream
1333 2013-07-31 19:28:57 <nsh> i'll draw some diagrams or whatever :)
1334 2013-07-31 19:29:09 ericmuyser has joined
1335 2013-07-31 19:29:12 roconnor has joined
1336 2013-07-31 19:29:14 <handle> there are methods of measuring, not necessarily randomness, but unpredictability
1337 2013-07-31 19:29:23 <maaku> no, there is not
1338 2013-07-31 19:29:28 <maaku> you can measure it it looks random
1339 2013-07-31 19:29:30 <handle> yes, there is
1340 2013-07-31 19:29:33 <maaku> you can't measure if it *is* random
1341 2013-07-31 19:29:38 <sipa> relevant: http://search.dilbert.com/comic/Random%20Nine
1342 2013-07-31 19:29:42 <maaku> and if you can, I'd like to be coauthor too :)
1343 2013-07-31 19:29:44 <handle> did I say you could measure randomness
1344 2013-07-31 19:29:48 <handle> no, I did not
1345 2013-07-31 19:30:03 <sipa> you can't measure unpredictability either
1346 2013-07-31 19:30:05 <nsh> but you suggested that an RNG should be able to provide assurances of nonpredictability
1347 2013-07-31 19:30:09 tucenaber has joined
1348 2013-07-31 19:30:09 <nsh> this is a very nontrivial thing to attempt
1349 2013-07-31 19:30:13 <sipa> there may be a pattern that you are unable to recognize
1350 2013-07-31 19:30:29 <sipa> in fact, cryptographic stream cipher have exactly this property
1351 2013-07-31 19:30:38 <handle> indeed
1352 2013-07-31 19:31:45 <handle> nsh: I did not
1353 2013-07-31 19:31:52 <handle> nor did I say these methods proved unpredictability
1354 2013-07-31 19:32:14 <nsh> right, sorry. i was referring to the conversation i created in my head by reading the words on the screen
1355 2013-07-31 19:32:25 <nsh> this obviously bears little resemblance to what occurred :)
1356 2013-07-31 19:32:28 <sipa> they can't reliably measure either
1357 2013-07-31 19:32:47 <sipa> you can try to match against a finite list of known patterns
1358 2013-07-31 19:33:08 <sipa> if it matches, you have detected lack of randomness
1359 2013-07-31 19:33:14 <sipa> if it doesn't, you don't know anything
1360 2013-07-31 19:33:48 <handle> so, what is entropy?
1361 2013-07-31 19:34:02 <sipa> a more well-defined word for randomness
1362 2013-07-31 19:34:03 ericmuyser has quit (Ping timeout: 264 seconds)
1363 2013-07-31 19:34:08 <handle> is it a number that means shit all?
1364 2013-07-31 19:34:11 <handle> it means unpredictability
1365 2013-07-31 19:34:21 <sipa> yes
1366 2013-07-31 19:34:26 <sipa> but you can't measure entropy :)
1367 2013-07-31 19:34:37 realzies has quit (Read error: Connection reset by peer)
1368 2013-07-31 19:35:00 <sipa> well, you can try - that's basically what entropy coders do
1369 2013-07-31 19:35:15 denom has quit (Ping timeout: 264 seconds)
1370 2013-07-31 19:35:33 <sipa> but they will tell you that the output of a stream cipher is 100% random
1371 2013-07-31 19:36:06 <handle> certainly, if it's a good stream cipher
1372 2013-07-31 19:36:55 <sipa> indeed, but it's completely wrong
1373 2013-07-31 19:37:26 serialbandicoot has quit (Quit: serialbandicoot)
1374 2013-07-31 19:37:30 <sipa> as the entropy of the entire stream is equal to that of the key, the IV + a variable indicating its position/length
1375 2013-07-31 19:38:06 <handle> yes
1376 2013-07-31 19:38:43 <handle> I'd say even the position/length does not actually add to the entropy
1377 2013-07-31 19:39:22 <sipa> if you look at the entire output as a single entity, it does
1378 2013-07-31 19:39:51 <sipa> as the output of "read 1000 bytes from stream cipher with key=K" is different from the output of "read 10000 bytes from stream cipher with key=K"
1379 2013-07-31 19:40:11 <sipa> and it's really about the number of possible outputs, and their probability
1380 2013-07-31 19:40:21 <handle> however the seed is exactly the same, and the first 1000 bytes would also be the same
1381 2013-07-31 19:40:28 <handle> however
1382 2013-07-31 19:40:42 <handle> position, potentially - length, I'd argue against that
1383 2013-07-31 19:40:55 <sipa> ok then
1384 2013-07-31 19:41:01 <sipa> it's a philosophical discussion anyway :)
1385 2013-07-31 19:41:14 <handle> lol, yeah
1386 2013-07-31 19:43:17 mappum has joined
1387 2013-07-31 19:45:00 <ThomasV> sipa: but the bip32 recommendation is not philosophical I guess
1388 2013-07-31 19:45:08 <sipa> ThomasV: right
1389 2013-07-31 19:45:36 <ThomasV> it looks like FUD
1390 2013-07-31 19:45:48 <sipa> ThomasV: it's still 256-bit crypto, that uses 256-bit keys; even though brute-forcing it only requires 2^128 executions, there may be a way (in theory) for an attacker to take advantage of the fact that the potential keys are drawn from a smaller subset
1391 2013-07-31 19:46:40 <sipa> basically, i don't dare to say that if you use 128-bit keys, you get the maximum level of security
1392 2013-07-31 19:46:45 <ThomasV> I know that, but I don't understand why this "advice" is given in the bip
1393 2013-07-31 19:47:16 <sipa> because if there is no difficulty for you to use 256-bit seeds, you should absolutely do so
1394 2013-07-31 19:47:23 CodeShark has joined
1395 2013-07-31 19:47:28 <sipa> but if that is hard, 128 is probably ok
1396 2013-07-31 19:47:29 <ThomasV> I hope that if 128 was insecure, 128 would not be mentioned at all in the bip
1397 2013-07-31 19:47:56 <ThomasV> hmm
1398 2013-07-31 19:48:07 <sipa> it's rather because if i'd put 256 there, i'm sure some people would find it too hard, and use less
1399 2013-07-31 19:48:20 <sipa> so the point is really, if you're going to use less than 256, please don't use less than 128
1400 2013-07-31 19:48:29 nowan has quit (Ping timeout: 268 seconds)
1401 2013-07-31 19:48:30 <sipa> because at that point, you are definitely reducing security
1402 2013-07-31 19:49:21 <ThomasV> bitcoin addresses have only 160 bits of entropy, so 256 is a bit overkill
1403 2013-07-31 19:49:56 <sipa> that's not correct
1404 2013-07-31 19:50:09 <ThomasV> no?
1405 2013-07-31 19:50:11 <sipa> because EC crypto halves the security level
1406 2013-07-31 19:50:54 <ThomasV> ?
1407 2013-07-31 19:51:06 <sipa> if you have a full public key, you only need 2^128 executions (in theory, i believe the best practical algorithms require more, and ridiculous amounts of memory) to find the matching private key
1408 2013-07-31 19:51:35 <CodeShark> if you have the hash you can't recover the public key, though
1409 2013-07-31 19:51:56 <sipa> yes, so addresses are safely above that 128 bit target
1410 2013-07-31 19:52:04 <sipa> but if you are reducing the size of the keyspace
1411 2013-07-31 19:52:25 <sipa> it *may* be possible to speed up the 2^128 attack as well
1412 2013-07-31 19:57:59 agnostic_ has quit (Remote host closed the connection)
1413 2013-07-31 20:00:06 bmcgee has quit (Ping timeout: 264 seconds)
1414 2013-07-31 20:00:28 digitalmagus2 has joined
1415 2013-07-31 20:01:24 michagogo has joined
1416 2013-07-31 20:02:23 paraipan has quit (Quit: Saliendo)
1417 2013-07-31 20:04:41 porquilho has quit ()
1418 2013-07-31 20:04:59 normanrichards has quit (Quit: normanrichards)
1419 2013-07-31 20:05:17 Application has joined
1420 2013-07-31 20:05:37 bmcgee has joined
1421 2013-07-31 20:06:30 joesmoe has quit (Ping timeout: 245 seconds)
1422 2013-07-31 20:07:03 Lolcust has quit (Ping timeout: 264 seconds)
1423 2013-07-31 20:07:12 realzies has joined
1424 2013-07-31 20:08:36 realzies has quit (Read error: Connection reset by peer)
1425 2013-07-31 20:13:16 realzies has joined
1426 2013-07-31 20:13:16 realzies has quit (Changing host)
1427 2013-07-31 20:13:16 realzies has joined
1428 2013-07-31 20:13:30 denom has joined
1429 2013-07-31 20:16:42 arioBarzan has joined
1430 2013-07-31 20:17:02 arioBarzan has left ()
1431 2013-07-31 20:17:31 arioBarzan has joined
1432 2013-07-31 20:19:02 bmcgee has quit (Quit: bmcgee)
1433 2013-07-31 20:20:08 arioBarzan has quit (Remote host closed the connection)
1434 2013-07-31 20:21:36 PiZZaMaN2K is now known as PiZZaMaN2K|away
1435 2013-07-31 20:22:27 santoscork has joined
1436 2013-07-31 20:22:52 patcon_ has joined
1437 2013-07-31 20:23:18 arioBarzan has joined
1438 2013-07-31 20:26:15 patcon has quit (Ping timeout: 264 seconds)
1439 2013-07-31 20:26:26 lordbunson has quit (Quit: Leaving)
1440 2013-07-31 20:27:49 agricocb has quit (Quit: Leaving.)
1441 2013-07-31 20:29:05 jeewee has quit (Quit: Leaving.)
1442 2013-07-31 20:29:06 bmcgee has joined
1443 2013-07-31 20:30:29 Lone has joined
1444 2013-07-31 20:30:38 Prattler has quit (Quit: ZNC - http://znc.in)
1445 2013-07-31 20:31:13 BurtyB has quit (Read error: Connection reset by peer)
1446 2013-07-31 20:31:36 LainZ has quit (Ping timeout: 256 seconds)
1447 2013-07-31 20:31:39 BurtyB has joined
1448 2013-07-31 20:31:42 Tantadruj has joined
1449 2013-07-31 20:34:59 yano has quit (Remote host closed the connection)
1450 2013-07-31 20:38:34 Lolcust has joined
1451 2013-07-31 20:39:22 joesmoe has joined
1452 2013-07-31 20:41:01 joesmoe has quit (Excess Flood)
1453 2013-07-31 20:41:39 joesmoe has joined
1454 2013-07-31 20:43:03 debiantoruser has quit (Ping timeout: 264 seconds)
1455 2013-07-31 20:43:07 debianto1user has joined
1456 2013-07-31 20:43:34 _jps has quit (Quit: _jps)
1457 2013-07-31 20:44:31 _jps has joined
1458 2013-07-31 20:44:52 Namworld has joined
1459 2013-07-31 20:45:45 jgarzik has quit (Quit: Leaving)
1460 2013-07-31 20:46:13 jgarzik has joined
1461 2013-07-31 20:46:13 jgarzik has quit (Changing host)
1462 2013-07-31 20:46:13 jgarzik has joined
1463 2013-07-31 20:46:32 richcollins has joined
1464 2013-07-31 20:46:41 chmod755 is now known as someone
1465 2013-07-31 20:46:48 someone is now known as chmod755
1466 2013-07-31 20:47:51 handle is now known as alwaysunkown
1467 2013-07-31 20:47:55 alwaysunkown is now known as handle
1468 2013-07-31 20:52:46 <arioBarzan> How reliable is Berkeley DB's remove() ? Could we be sure that it will purge the content of the file (here wallet.dat) before it ask the file system to remove the link to file from partition table?
1469 2013-07-31 20:53:15 normanrichards has joined
1470 2013-07-31 20:54:42 agricocb has joined
1471 2013-07-31 20:54:47 <arioBarzan> apparently we use that Remove() in CDB::Rewrite() without purging the content of wallet.dat ourselves and we rely on Berkeley DB.
1472 2013-07-31 20:55:33 yano has joined
1473 2013-07-31 20:58:40 <arioBarzan> ;;ticker --last
1474 2013-07-31 20:58:41 <gribble> 107.00010
1475 2013-07-31 20:59:29 <sipa> arioBarzan: no, it doesn't
1476 2013-07-31 20:59:48 <sipa> arioBarzan: our security model is that we don't want files to contain sensitve data (so for example, backups are safe)
1477 2013-07-31 21:00:09 <sipa> it's mostly impossible to defend against an attacker that has direct access to your hard drive
1478 2013-07-31 21:06:20 <michagogo> sensitive == unencrypted privkeys?
1479 2013-07-31 21:07:22 Cory has quit ()
1480 2013-07-31 21:08:22 MobPhone has quit (Read error: Connection reset by peer)
1481 2013-07-31 21:08:43 <arioBarzan> Since CWallet::EncryptWallet uses CDB::Rewrite(strWalletFile); at final step, it, to be correct, leaves the wallet UNENCRYPTED on the disk. So what would be the point of encryption ?
1482 2013-07-31 21:08:55 MobPhone has joined
1483 2013-07-31 21:11:07 <sipa> arioBarzan: as i said, we don't defend against an attacker who has raw access to your disk
1484 2013-07-31 21:11:15 <sipa> claiming that we do, would be a false sense of security
1485 2013-07-31 21:12:50 handle is now known as someone
1486 2013-07-31 21:13:09 someone is now known as handle
1487 2013-07-31 21:19:22 <gmaxwell> on many kinds of media now rewrite is _impossible_ at least in a safe and platform portable manner. :(
1488 2013-07-31 21:20:51 shesek has quit (Ping timeout: 264 seconds)
1489 2013-07-31 21:21:22 <phantomcircuit> gmaxwell, rewrite hasn't been guaranteed for a very long time
1490 2013-07-31 21:21:37 <phantomcircuit> relocated sectors
1491 2013-07-31 21:21:42 <phantomcircuit> it was just far less common
1492 2013-07-31 21:21:46 <gmaxwell> my now time horizon is about 25 years.
1493 2013-07-31 21:22:05 <gmaxwell> Though relations were at least unlikely to screw you.
1494 2013-07-31 21:22:14 kadoban has quit (Read error: Connection reset by peer)
1495 2013-07-31 21:22:17 <gmaxwell> But journaled filesystems predate SSDs by a long time.
1496 2013-07-31 21:22:23 Cory has joined
1497 2013-07-31 21:22:38 AusBitBank has joined
1498 2013-07-31 21:23:06 <gmaxwell> If you create a new wallet, encrypt right away, nothing important ever ends up unencrypted on disk. Thats about the best we can do.
1499 2013-07-31 21:23:47 <gmaxwell> If prompt for keys on install we'll very reliably get people entering in keys and losing them. If we try to secure erase the file we'll likely just create false security _and_ make the data better preserved.
1500 2013-07-31 21:23:49 <phantomcircuit> well to be fair with most ssds you'd have to interigate the raw nand flash cips
1501 2013-07-31 21:23:57 <phantomcircuit> (not that this is particularly difficult)
1502 2013-07-31 21:24:13 <phantomcircuit> although some of them have debug modes that pass raw flash content
1503 2013-07-31 21:24:47 roconnor has quit (Remote host closed the connection)
1504 2013-07-31 21:25:37 justusranvier_ has joined
1505 2013-07-31 21:26:57 <arioBarzan> Unfortunately one might get DB_NEED_REWRITE and then trigger an unwanted Rewrite even if he had encrypted his wallet right away after creating it.
1506 2013-07-31 21:27:38 yubrew has quit (Remote host closed the connection)
1507 2013-07-31 21:28:12 chmod755 has quit (Quit: Leaving)
1508 2013-07-31 21:28:42 yubrew has joined
1509 2013-07-31 21:28:59 <sipa> only when upgrading from pre-0.5 clients
1510 2013-07-31 21:30:09 yubrew has quit (Remote host closed the connection)
1511 2013-07-31 21:31:02 <gmaxwell> arioBarzan: not an issue with a newly created wallet, as I said.
1512 2013-07-31 21:31:21 <midnightmagic> SSD once erased are gone. it's only wear-levelling or addiitonal space mapping that could get you any residual data, unless you do have a really crappy old-style ssd.
1513 2013-07-31 21:31:44 <phantomcircuit> midnightmagic, ssds are copy on write, so overwriting data doesn't overwrite it
1514 2013-07-31 21:31:47 <phantomcircuit> it makes a copy
1515 2013-07-31 21:32:00 <gmaxwell> midnightmagic: the wear leveling means that if you rewrite data it will _never_ (on most recent SSDs) overwrite the actual data.
1516 2013-07-31 21:32:13 BCBot has quit (Remote host closed the connection)
1517 2013-07-31 21:32:21 <gmaxwell> eventually it will be overwritten, during a relocation event but that could be months later.
1518 2013-07-31 21:32:22 <phantomcircuit> gmaxwell, trim helps to make that less of a problem
1519 2013-07-31 21:32:24 <phantomcircuit> but still
1520 2013-07-31 21:32:52 <midnightmagic> phantomcircuit: that's space mapping. if you continue writing to disk eventually you will; alternatively many drives have a drive-wiping feature which is extremely effective.
1521 2013-07-31 21:32:59 <petertodd> phantomcircuit, midnightmagic: ssd's have specific low-level mechanisms to do device-wide wipes that electrically speaking wipe every chip at once regardless of relocation
1522 2013-07-31 21:33:05 <gmaxwell> even with trim, erase blocks are 128k typically. The drive isn't promised to do a relocation just to fast reap a few sectors.
1523 2013-07-31 21:33:35 shesek has joined
1524 2013-07-31 21:33:45 <phantomcircuit> petertodd, im aware
1525 2013-07-31 21:33:45 <gmaxwell> petertodd: sure, hdparm secure erase, for example. But .. yea.. "now that you've entered in a wallet passphrase, we're going to secure erase your whole disk"
1526 2013-07-31 21:33:50 <midnightmagic> gmaxwell: that's only if you can't force the drive to wipe itself, or you don't feel like writing through both the drive and all its additional unreported data.
1527 2013-07-31 21:33:58 <phantomcircuit> but that doesn't help here
1528 2013-07-31 21:34:01 <phantomcircuit> as gmaxwell is saying
1529 2013-07-31 21:34:05 <petertodd> gmaxwell: yeah, encryption is the only nice way to handle less than a device wiping
1530 2013-07-31 21:34:06 <gmaxwell> midnightmagic: yes you can wipe the _whole disk_, but not a single file.
1531 2013-07-31 21:34:45 <petertodd> gmaxwell: for instance if you look into the details of dmcrypt on linux there's a mechanism where your key information is spread across multiple sectors so if any one part is gone you are safe
1532 2013-07-31 21:34:46 <gjs278> I don't know how well data recovery works on ssds to get that data
1533 2013-07-31 21:34:49 <phantomcircuit> and actually even with TRIM more than likely the erase block is just marked as empty but not actually erased
1534 2013-07-31 21:35:07 <phantomcircuit> petertodd, superblocks
1535 2013-07-31 21:35:17 <Scrat> some new SSDs will just wipe the encryption key (it's on by default)
1536 2013-07-31 21:35:23 <midnightmagic> gmaxwell: just writing to the disk for long periods of time will get it eventually (but it's expensive to do that.) I'm pretty sure it is possible to instruct some drives to wipe smaller portions of sensitive data, but I don't know about SSD released in the last year.
1537 2013-07-31 21:35:28 <phantomcircuit> iirc they use the same offsets as ext4 which makes for weirdness trying to recover superblocks from luks/ext4
1538 2013-07-31 21:35:49 BCBot has joined
1539 2013-07-31 21:35:51 <gmaxwell> phantomcircuit: thats right, trim often won't trigger an erase because it would then have to relocate all the other crap in that sector. Better to wait and hope that the rest gets erased/dirtied later.
1540 2013-07-31 21:36:06 <phantomcircuit> midnightmagic, no you can tell the drive you no longer care about the sector using TRIM, but that's just a suggestion
1541 2013-07-31 21:36:16 tmsk has quit (Quit: tmsk)
1542 2013-07-31 21:36:21 <gmaxwell> midnightmagic: you can trim the sectors in question but I'm not aware of any drive that promises to do anything in response to trim.
1543 2013-07-31 21:36:52 <phantomcircuit> gmaxwell, iirc the very expensive STEC drives do
1544 2013-07-31 21:36:53 <midnightmagic> TRIM doesn't relocate data unless you are trying to TRIM less than an erase block of whatever size that drive's controller is built on.
1545 2013-07-31 21:37:06 <midnightmagic> (or across boundaries or whatever)
1546 2013-07-31 21:37:10 <arioBarzan> if secure-erase the file, at least we make it safe from hands of stupid hackers, who might not have time or energy to f-ck with the physical disk.
1547 2013-07-31 21:37:12 richcollins has quit (Quit: richcollins)
1548 2013-07-31 21:37:15 <phantomcircuit> midnightmagic, right it just marks the sector as empty in the drives internal sector map
1549 2013-07-31 21:38:17 <gmaxwell> midnightmagic: presumably if you manage to trim an entire erase block it will actually do it ... uh, if it's paying attention to trim at all.. BUT the logical->physical mapping isn't visible, 128k contigious sectors will likely not be a single erase block. Esp on a file that has been randomly written to.
1550 2013-07-31 21:38:19 <midnightmagic> phantomcircuit: hrm. i'm not completely sure that's true. guess I'll have to read those papers again.
1551 2013-07-31 21:38:35 <midnightmagic> gmaxwell: the garbage collector eventually gets around to it during quiescence
1552 2013-07-31 21:38:56 <gmaxwell> arioBarzan: no, not even in that case, on a data logging file system a simple tool pointed at the device will happily get the data.
1553 2013-07-31 21:38:57 <midnightmagic> ah I see.
1554 2013-07-31 21:39:02 * midnightmagic reads whole sentences next time.
1555 2013-07-31 21:39:13 <gjs278> I don't know if trim just marks the sector internally because there are quite a few issues with turning trim on while running dmcrypt where it physically exposes the holes
1556 2013-07-31 21:39:18 Lolcust has quit (Ping timeout: 248 seconds)
1557 2013-07-31 21:39:19 <gmaxwell> arioBarzan: so even a dump skript kiddy tool can find it.
1558 2013-07-31 21:39:51 <gmaxwell> gjs278: on many drives it instantly makes the sector 'return' zeros, doesn't mean anything is erased.
1559 2013-07-31 21:40:33 Lolcust has joined
1560 2013-07-31 21:40:36 Lolcust has quit (Excess Flood)
1561 2013-07-31 21:41:06 Lolcust has joined
1562 2013-07-31 21:42:49 <phantomcircuit> gjs278, trim causes the the sector to return zero, which gets decrypted by dmcrypt and causes weirdness
1563 2013-07-31 21:42:54 <sipa> hmmmm
1564 2013-07-31 21:43:05 <sipa> do we trigger a wallet rewriten when you change the passphrase?
1565 2013-07-31 21:43:19 ThomasV has quit (Ping timeout: 256 seconds)
1566 2013-07-31 21:43:25 <phantomcircuit> i forget the specific issue but you can identify the filesystem used if you use dmcrypt w/ discard enabled
1567 2013-07-31 21:43:26 <gmaxwell> phantomcircuit: not weirdness but it leaks usage.
1568 2013-07-31 21:43:27 <sipa> because if we don't, the master key may remain accessible using the old passphrase
1569 2013-07-31 21:43:34 <midnightmagic> well, kingston only does whole-drive secureerase: http://www.kingston.com/en/community/articledetail?articleid=10
1570 2013-07-31 21:43:41 <gjs278> yes you can externally see that the data isn't really random
1571 2013-07-31 21:43:43 <phantomcircuit> which coudl potentially allow you to exploit the filesystem
1572 2013-07-31 21:43:46 <midnightmagic> that sucks.
1573 2013-07-31 21:43:53 <phantomcircuit> gjs278, you can *definitely* see that
1574 2013-07-31 21:43:58 <phantomcircuit> actually
1575 2013-07-31 21:44:00 <midnightmagic> I wonder what fusion-io type vendors do..
1576 2013-07-31 21:44:05 <gjs278> I have fusion-io car
1577 2013-07-31 21:44:06 <gjs278> d
1578 2013-07-31 21:44:07 <phantomcircuit> if you're using an ssd there is zero deniability
1579 2013-07-31 21:44:13 <midnightmagic> gjs278: My condolences. :(
1580 2013-07-31 21:44:18 <gjs278> lol why
1581 2013-07-31 21:44:18 <phantomcircuit> the metadata has timestamps yo
1582 2013-07-31 21:44:20 <gjs278> it's great
1583 2013-07-31 21:44:30 <gjs278> I mean sure, I had to patch the drivers by hand to work on kernel 3.10
1584 2013-07-31 21:44:30 <midnightmagic> I guess the best option would be whole-drive encryption then. Oh well.
1585 2013-07-31 21:44:48 richcollins has joined
1586 2013-07-31 21:44:52 <gjs278> and you can brick them so easily that you might as well just keep an adapter aruond to fix the broken modules
1587 2013-07-31 21:45:02 <phantomcircuit> midnightmagic, fusion-io and friends do not even try to hide usage
1588 2013-07-31 21:45:07 <midnightmagic> gjs278: It's extremely expensive: so expensive that for many of the applications it's touted for, it would be cheaper and faster to just get a high-end drive array with a bunch of SAS drives.
1589 2013-07-31 21:45:08 <phantomcircuit> or provide deniability
1590 2013-07-31 21:45:17 <gjs278> I got mine on ebay
1591 2013-07-31 21:45:26 <midnightmagic> gjs278: in that case, winning!
1592 2013-07-31 21:45:32 <gjs278> the over provisioned area gives it away
1593 2013-07-31 21:45:55 <gjs278> yeah 80mb/s 4k qd1 is great
1594 2013-07-31 21:46:13 <gjs278> I just got tired of living in the 30mb/s 4k qd1 world of ssds
1595 2013-07-31 21:46:18 digitalmagus2 has quit (Ping timeout: 264 seconds)
1596 2013-07-31 21:46:18 <phantomcircuit> lol
1597 2013-07-31 21:46:54 <phantomcircuit> so far the only application i've had that seriously tested my 840 pro is running 8 bitcoinds concurrently doing ibc
1598 2013-07-31 21:47:08 <midnightmagic> aww, lame: http://www.fusionio.com/overviews/fusionsureerase/
1599 2013-07-31 21:47:12 <midnightmagic> fusion io, too.
1600 2013-07-31 21:47:57 <gjs278> http://img4.imageshack.us/img4/287/07pg.png
1601 2013-07-31 21:48:15 <midnightmagic> Well the cool part is that fusion io devices can be purged in less than a minute. That's pretty cool.
1602 2013-07-31 21:48:33 <gmaxwell> midnightmagic: yea, secure erase on a random intel ssd takes like a minute.
1603 2013-07-31 21:48:45 <midnightmagic> better than HDD
1604 2013-07-31 21:48:48 <arioBarzan> sipa: the code instead of ReWrite() does this: CWalletDB(strWalletFile).WriteMasterKey(pMasterKey.first, pMasterKey.second);
1605 2013-07-31 21:49:04 <gmaxwell> midnightmagic: turns out that the drive itself can zero the thing in parallel really fast.
1606 2013-07-31 21:49:31 <Krellan> FusionIO = I worked at a company that used their SSD drives, they're blindingly fast, like RAM that survives a reboot.  Incredibly expensive but you get what you pay for.
1607 2013-07-31 21:49:44 <petertodd> gmaxwell: That kinda surprises me actually - indicates the charge pumps in their flash chips aren't large enough to do a full-chip erase instantly, which in turn suggests they are in general bandwidth limited.
1608 2013-07-31 21:49:58 <petertodd> gmaxwell: Electrically you can make flash chips erase instantly.
1609 2013-07-31 21:50:01 <gjs278> I actually have tested them against a ramdisk and for the most part I ended up being cpu limited on everything
1610 2013-07-31 21:50:02 <sipa> arioBarzan: yes?
1611 2013-07-31 21:50:10 <midnightmagic> Krellan: It's an illusion. Hardcore long-term writing can catch up with the wear leveller and things slow down after heavy use pretty badly. :(
1612 2013-07-31 21:50:43 <gjs278> it is indeed an illusion and you can tell because it will use host ram to speed things up but I've never hit that point in my usage so far
1613 2013-07-31 21:50:50 <Krellan> midnightmagic: Thanks, I wonder how long they last before the slowdown happens? I didn't work there long enough to notice any slowdown by the time I left.
1614 2013-07-31 21:51:04 <midnightmagic> Krellan: Depends on the size of the device and how much data you can push at it.
1615 2013-07-31 21:51:11 <gjs278> I have an iodrive duo I need to flash the firmware on and I can start doing some great 1.5gb/s read writes
1616 2013-07-31 21:51:40 <arioBarzan> sipa: I couldn't find ReWrite() after changing passphrase.
1617 2013-07-31 21:51:57 <midnightmagic> Krellan: Extremely heavy database-like operations choke it to death. So far RAMSan is the fastest I've seen tested, then something like violin, then violin's flash-based stuff, then devices like fusion io or zeus iops.
1618 2013-07-31 21:52:10 saulimus has quit (Quit: saulimus)
1619 2013-07-31 21:52:21 <Krellan> midnightmagic: As for mass erase, I would be surprised if they did *not* offer a military model by now that had a big capacitor or something like that, which could deliver the mass erase.
1620 2013-07-31 21:53:02 <sipa> arioBarzan: there is none
1621 2013-07-31 21:53:06 <midnightmagic> Krellan: yeah looks like they mention that (military) specific use-case and do offer fast whole-disk erase. I'm trying to find out whether it's even possible to address specific regions or not.
1622 2013-07-31 21:53:16 <sipa> arioBarzan: oh, you were answering my question; sorry!
1623 2013-07-31 21:53:22 <sipa> arioBarzan: yes, i've found out too
1624 2013-07-31 21:53:25 <midnightmagic> Maybe only when one has direct access to the chips themselves.
1625 2013-07-31 21:53:38 <Krellan> midnightmagic: Good to know. I just drove by Violin Memory's HQ the other day (strange coincidence). As for really needing mass erase, the military has explosives!
1626 2013-07-31 21:53:42 peetaur2 has quit (Quit: Konversation terminated!)
1627 2013-07-31 21:54:25 <midnightmagic> Krellan: I love the violin people, they're great. "We" have a $50k violin unit and I *LOVE* it. just love it.
1628 2013-07-31 21:54:37 <gjs278> midnightmagic: http://www.ebay.com/itm/Violin-1010-Scalable-Flash-Based-DRAM-Memory-Appliance-1000094S-A-06-/310648483115
1629 2013-07-31 21:54:39 <gjs278> what is this
1630 2013-07-31 21:54:41 <midnightmagic> Krellan: kaboom!
1631 2013-07-31 21:55:15 <gjs278> if I bought that and filled it with ram and connected to it would it work?
1632 2013-07-31 21:55:29 <phantomcircuit> gjs278, maybe?
1633 2013-07-31 21:55:30 <arioBarzan> sipa: I think we rewrite previous masterkey in WriteMasterKey()
1634 2013-07-31 21:55:42 <midnightmagic> gjs278: I don't think it's proper RAM-based. That's one of their flash models. Lemme check what we have in the lab.
1635 2013-07-31 21:56:02 <gjs278> check the last image, it has a shitton of open ram slots
1636 2013-07-31 21:56:04 <phantomcircuit> midnightmagic, no that's definitely ram
1637 2013-07-31 21:56:08 <Krellan> midnightmagic: Nice!  It's a great market to be in, the people who need that kind of speed *really* need it and are willing to pay for it.
1638 2013-07-31 21:56:40 <midnightmagic> phantomcircuit: yeah but they sell units that have no backup and thus don't need flash.
1639 2013-07-31 21:58:24 <arioBarzan> sipa: please ignore my last comment about masterkey, it was very stupid.
1640 2013-07-31 21:59:05 bmcgee has quit (Quit: bmcgee)
1641 2013-07-31 21:59:09 <gjs278> how do you connect to it? I want to boot my os off of one of these now and make people jealous
1642 2013-07-31 21:59:38 <sipa> arioBarzan: done!
1643 2013-07-31 21:59:56 <midnightmagic> My mistake.
1644 2013-07-31 22:00:02 <midnightmagic> We have a violin 3205a.
1645 2013-07-31 22:00:32 <gjs278> according to this press release, the violin 1010 can have 500gb of ram or flash
1646 2013-07-31 22:00:37 <gjs278> You can use DRAM, NAND Flash or both, and the machine will support up to 504 GB of RAM.
1647 2013-07-31 22:00:45 <midnightmagic> Anyway, it's god-damned fast. One of the fastest devices I've ever used, and rebooting it loses all data. it has no persistent backup.
1648 2013-07-31 22:00:48 <gjs278> the question is what kind of nand flash do I have to provide it
1649 2013-07-31 22:00:54 <gjs278> ohhh
1650 2013-07-31 22:00:56 <gjs278> ok
1651 2013-07-31 22:00:57 <gjs278> nevermind then
1652 2013-07-31 22:01:10 <gjs278> I thought it offered persistent too
1653 2013-07-31 22:01:29 <Krellan> midnightmagic: wow, it's just RAM?  I thought the whole point is that it was a really fast "disk".
1654 2013-07-31 22:01:35 <midnightmagic> Since a reboot effectively wipes it, I was under the impression it was pure RAM. I still think it is.
1655 2013-07-31 22:01:41 <midnightmagic> We also have a flash unit in too, but that's slower.
1656 2013-07-31 22:02:01 <midnightmagic> Krellan: RAMSan is just RAM with a bunch of HDD backup and some batteries.
1657 2013-07-31 22:02:24 <gjs278> The second release of VIMMs will be based on NAND Flash and provide very high density and persistent storage. The 64 Gigabyte VIMMs planned would support a 5 Terabyte Violin 1010. The Violin 1010 and the associated Violin Intelligent Memory Modules (VIMMs) are now available. A 120 Gigabyte DRAM Starter Kit is available for less than $50K.
1658 2013-07-31 22:02:34 <midnightmagic> Krellan: For database operations, databases have transaction logs that can be written to permanent storage and used to recover state in the event of a powerout.
1659 2013-07-31 22:02:51 <gjs278> looks it can have persistent
1660 2013-07-31 22:03:06 <gjs278> and it can connect over pci-e
1661 2013-07-31 22:03:11 <Krellan> midnightmagic: Tiered RAM seems like a good solution to me, use batteries to tide it over until the RAM can be dumped fully to the spinning HD.
1662 2013-07-31 22:03:38 <gjs278> midnightmagic: since it connects over pci-e, does the device you are connecting it to need some sort of special driver to work with violin devices?
1663 2013-07-31 22:03:46 <midnightmagic> Ah hah!  Our 3205a is the flash model. That's what's plugged in now. There's a 500GB memory model we have too. That's the fast one.
1664 2013-07-31 22:04:00 <Krellan> midnightmagic: I'm not a DB guy but remember the DBA's talking about it.  Double-writing is cool: update the fast live DB, but also update a journal/log at the same time so DB can be replayed at will.
1665 2013-07-31 22:04:13 digitalmagus2 has joined
1666 2013-07-31 22:04:32 <BlueMatt> jgarzik: wtf is CBlockEngine, and what were you wrong about?
1667 2013-07-31 22:05:00 <gjs278> or will it just appear as a disk magically
1668 2013-07-31 22:05:17 metabyte has quit (Read error: Connection reset by peer)
1669 2013-07-31 22:05:47 <midnightmagic> gjs278: Yep looks like it. I don't know if it's closed-source, but: [   22.881118] vtms(0): Violin Memory Array: vtmsa (PCIE: x8)
1670 2013-07-31 22:05:54 <arioBarzan> sipa: one question about watch-only. If we import an address that we have its privkey could we use something similar to "Erase(std::make_pair(std::string("wkey"), vchPubKey));" from WriteCryptedKey() and maybe vice versa for going back and forth between watch-only and normal keys?
1671 2013-07-31 22:06:01 <gjs278> dah
1672 2013-07-31 22:06:03 <gjs278> that could be a problem
1673 2013-07-31 22:06:33 <gjs278> http://www.redhat.com/archives/lvm-devel/2012-November/msg00063.html
1674 2013-07-31 22:06:35 <gjs278> hey sweet
1675 2013-07-31 22:06:56 <gjs278> http://72.47.217.141/software/archive/201205_Linux-Driver-Release-D5.2.0.4/D5.2.0.4-README.txt
1676 2013-07-31 22:07:14 <gjs278> not too bad then I guess
1677 2013-07-31 22:07:39 BCBot has quit (Remote host closed the connection)
1678 2013-07-31 22:07:51 metabyte has joined
1679 2013-07-31 22:07:53 <gjs278> I'll go download a copy of the driver and see if it compiles, then bide my time on ebay
1680 2013-07-31 22:07:55 BCBot has joined
1681 2013-07-31 22:07:57 johnsoft1 has joined
1682 2013-07-31 22:08:35 datagutt has quit (Quit: Computer has gone to sleep.)
1683 2013-07-31 22:08:54 Tantadruj has quit (Quit: DoubleRecall Turns Paywalls Into Advertising Dollars - NYTimes.com http://nyti.ms/odHOgy)
1684 2013-07-31 22:09:37 johnsoft has quit (Ping timeout: 246 seconds)
1685 2013-07-31 22:10:23 <midnightmagic> The violin memory-based stuff is pretty ridiculous. If you open the lid up, watching the little raid patterns is really mesmerizing.
1686 2013-07-31 22:14:38 <petertodd> FYI: https://s3.amazonaws.com/peter.todd/litecoin-v0.8.3.7-audit-report.tar.bz2
1687 2013-07-31 22:14:54 <petertodd> The results of the Litecoin v0.8.3.7 audit I just finished.
1688 2013-07-31 22:15:34 <petertodd> report.txt.asc SHA256 hash: 24832b4b8411f3fbcc98b96bdfaaf90f4aeac39a7fbfb491bff5a76d23859dbd
1689 2013-07-31 22:15:35 <midnightmagic> petertodd: thanks for the link
1690 2013-07-31 22:15:55 <petertodd> np
1691 2013-07-31 22:18:03 shesek has quit (Ping timeout: 276 seconds)
1692 2013-07-31 22:18:42 roconnor has joined
1693 2013-07-31 22:21:12 <arioBarzan> sipa: one question about watch-only. If we import an address that we have its privkey could we use something similar to "Erase(std::make_pair(std::string("wkey"), vchPubKey));" from WriteCryptedKey() and maybe vice versa for going back and forth between watch-only and normal keys?
1694 2013-07-31 22:23:16 bbrian has quit (Ping timeout: 246 seconds)
1695 2013-07-31 22:24:31 c0rw1n has joined
1696 2013-07-31 22:26:15 <jgarzik> bluematt: your super-huge interface class, that never got merged into bitcoin.git.  I forget the exact class name.
1697 2013-07-31 22:26:26 <jgarzik> CBlockchainEngine ?
1698 2013-07-31 22:29:02 patcon_ has quit (Remote host closed the connection)
1699 2013-07-31 22:31:02 darksk1ez has joined
1700 2013-07-31 22:32:30 Lone has quit (Ping timeout: 264 seconds)
1701 2013-07-31 22:34:17 shesek has joined
1702 2013-07-31 22:34:23 p8m has quit (Ping timeout: 240 seconds)
1703 2013-07-31 22:34:34 RoboTeddy has quit (Remote host closed the connection)
1704 2013-07-31 22:34:49 egis has joined
1705 2013-07-31 22:35:50 enikanorov has quit (Read error: Connection reset by peer)
1706 2013-07-31 22:36:02 justusranvier_ has quit (Ping timeout: 240 seconds)
1707 2013-07-31 22:37:11 enikanorov has joined
1708 2013-07-31 22:37:43 a_meteorite has quit (Ping timeout: 256 seconds)
1709 2013-07-31 22:38:33 btsec has quit (Ping timeout: 256 seconds)
1710 2013-07-31 22:38:43 justusranvier_ has joined
1711 2013-07-31 22:39:00 LainZ has joined
1712 2013-07-31 22:39:51 LainZ has quit (Client Quit)
1713 2013-07-31 22:40:09 debianto1user has quit (Ping timeout: 276 seconds)
1714 2013-07-31 22:40:49 debiantoruser has joined
1715 2013-07-31 22:43:22 arioBarzan has quit (Remote host closed the connection)
1716 2013-07-31 22:46:47 skinnkavaj has quit (Ping timeout: 245 seconds)
1717 2013-07-31 22:56:52 one_zero has joined
1718 2013-07-31 22:58:01 macboz has joined
1719 2013-07-31 22:58:25 _jps has quit (Quit: _jps)
1720 2013-07-31 23:01:01 hnz has quit (Ping timeout: 264 seconds)
1721 2013-07-31 23:01:05 Neozonz is now known as Disc!~Neozonz@unaffiliated/neozonz|neozonz
1722 2013-07-31 23:01:54 roconnor has quit (Quit: Konversation terminated!)
1723 2013-07-31 23:04:07 digitalmagus3 has joined
1724 2013-07-31 23:04:38 digitalmagus2 has quit (Ping timeout: 240 seconds)
1725 2013-07-31 23:04:47 macboz has quit (Ping timeout: 240 seconds)
1726 2013-07-31 23:05:52 hnz has joined
1727 2013-07-31 23:06:32 RoboTeddy has joined
1728 2013-07-31 23:13:38 santoscork has quit (Quit: Hibernation Time …)
1729 2013-07-31 23:15:05 yubrew has joined
1730 2013-07-31 23:16:47 tcatm has quit (Quit: No Ping reply in 180 seconds.)
1731 2013-07-31 23:17:04 tcatm has joined
1732 2013-07-31 23:17:04 tcatm has quit (Changing host)
1733 2013-07-31 23:17:04 tcatm has joined
1734 2013-07-31 23:17:33 bitanarchy has joined
1735 2013-07-31 23:19:09 sserrano44 has quit (Quit: Computer has gone to sleep.)
1736 2013-07-31 23:20:15 RoboTeddy has quit (Ping timeout: 264 seconds)
1737 2013-07-31 23:20:23 patcon has joined
1738 2013-07-31 23:24:27 robocoin has quit (Ping timeout: 264 seconds)
1739 2013-07-31 23:30:22 sserrano44 has joined
1740 2013-07-31 23:34:16 sserrano44 has quit (Client Quit)
1741 2013-07-31 23:36:23 sserrano44 has joined
1742 2013-07-31 23:36:58 Eiii has joined
1743 2013-07-31 23:41:21 sserrano44 has quit (Quit: Computer has gone to sleep.)
1744 2013-07-31 23:45:12 robocoin has joined
1745 2013-07-31 23:45:16 metabyte_ has joined
1746 2013-07-31 23:45:56 digitalmagus3 has quit (Ping timeout: 240 seconds)
1747 2013-07-31 23:46:17 <BlueMatt> CBlockSomething, I dunno
1748 2013-07-31 23:46:35 <BlueMatt> thats kinda old at this point...
1749 2013-07-31 23:46:43 <BlueMatt> nor do I remember you being wrong about anything there
1750 2013-07-31 23:47:58 metabyte has quit (Ping timeout: 246 seconds)
1751 2013-07-31 23:48:32 <sipa> it seems jgarzik now believes more in the CHub/...-like design than back then, i believe
1752 2013-07-31 23:48:39 <BlueMatt> ahh, ok
1753 2013-07-31 23:49:09 GordonG3kko has quit (Remote host closed the connection)
1754 2013-07-31 23:49:27 <sipa> maybe ironically... i'm now much more in favor of trying to do as much over p2p as possible, with wallets just spv clients that connect to potentially trusted full nodes
1755 2013-07-31 23:52:33 <BlueMatt> that just seems like needless complication for a wallet, which should be disjoint from knowing if it is backed by spv or full chain
1756 2013-07-31 23:52:55 digitalmagus3 has joined
1757 2013-07-31 23:52:59 <sipa> right, implementation-wise inagree
1758 2013-07-31 23:53:09 <sipa> it's more about process separation
1759 2013-07-31 23:53:15 <BlueMatt> "Yo dawg, I heard you like nodes, so put an SPV-node in your wallet so you can use SPV with your full node"
1760 2013-07-31 23:53:26 <sipa> hehe
1761 2013-07-31 23:53:37 <sipa> s/inagree/i agree/
1762 2013-07-31 23:53:43 <BlueMatt> yea, but you can do process separation without putting spv in the wallet process, you can just trust a node, whether its spv or not
1763 2013-07-31 23:54:49 GordonG3kko has joined
1764 2013-07-31 23:54:57 <sipa> the only downside is an extra header tree being held, really
1765 2013-07-31 23:55:50 <BlueMatt> yep, but also code complication for wallets, which is already a very complicated piece of code
1766 2013-07-31 23:56:30 <sipa> well ideally all wallet code is written to just listen to events from some validation engine, whuch may be spv or full or whatever
1767 2013-07-31 23:56:50 <sipa> and at that point, it doesn't really matter for the code
1768 2013-07-31 23:57:08 <BlueMatt> exactly
1769 2013-07-31 23:57:36 <sipa> but from a running point of view, i think wallet processes should just be spv nodes
1770 2013-07-31 23:58:10 <BlueMatt> so no need to run spv in process
1771 2013-07-31 23:58:28 <BlueMatt> you can just listen to generic publisher, which doesnt have to do any spv stuff
1772 2013-07-31 23:58:38 normanrichards has quit (Quit: normanrichards)
1773 2013-07-31 23:58:56 <sipa> well if not, you need some network protocol to propagate events
1774 2013-07-31 23:59:07 <BlueMatt> why?
1775 2013-07-31 23:59:07 <sipa> which can just be some lightweight rpc mechanjsm, sure
1776 2013-07-31 23:59:19 <BlueMatt> I'd hope you arent running the node your wallet is on over the internet
1777 2013-07-31 23:59:31 <BlueMatt> if its not local, you may be doing something wrong (or be a large-scale merchant)
1778 2013-07-31 23:59:53 <sipa> i mean local, either same machine or within a local network