1 2013-01-12 00:44:50 <stealth222> for such addresses, we need pagination
  2 2013-01-12 00:51:28 <gmaxwell> first cursors then the next thing is a full sql query interface...
  3 2013-01-12 00:51:57 <stealth222> lol
  4 2013-01-12 00:52:02 <stealth222> nah, we don't have to take it that far
  5 2013-01-12 00:55:32 <stealth222> even if JSON could handle it, sending >8500 transactions at a time over HTTP is a little ridiculous :)
  6 2013-01-12 00:56:08 <gmaxwell> 8500 seems kinda boring to me. It's not like it's 8500 over a cell modem. :P
  7 2013-01-12 00:56:32 <stealth222> but the JSON can't even be properly parsed until it's all been sent
  8 2013-01-12 00:58:00 <gmaxwell> really? not even by a specialzed stream oriented parser?
  9 2013-01-12 00:58:15 <stealth222> I suppose so - but that's not standard, is it?
 10 2013-01-12 00:59:14 <gmaxwell> Who knows. Not my problem.
 11 2013-01-12 00:59:18 <stealth222> lol
 12 2013-01-12 00:59:56 <gmaxwell> I mean, if you window the output, the next thing you're going to want is to be able to make multiple calls atomically so it doesn't change out from under you... it's just a whole mess.
 13 2013-01-12 01:01:23 <stealth222> the RPC should be stateless
 14 2013-01-12 01:01:34 <stealth222> walletpassphrase notwithstanding
 15 2013-01-12 01:02:20 <gmaxwell> stealth222: great, now what happens when you query and get a million row answer, and before you connect again to get the second hunk of it and bunch of txn are added/removed/etc. from the result set?
 16 2013-01-12 01:03:12 <stealth222> then reserve that API for local queries and dump it to file - don't expose it via HTTP
 17 2013-01-12 01:03:16 <stealth222> lol
 18 2013-01-12 01:03:43 <stealth222> it's still a useful API for testing
 19 2013-01-12 01:03:50 <stealth222> but not necessarily a useful one for app development
 20 2013-01-12 01:04:48 <stealth222> dunno
 21 2013-01-12 01:05:37 <stealth222> querying for total received and total sent might be useful for app development
 22 2013-01-12 01:06:04 <stealth222> but querying for the entire set of transactions ceases to be particularly useful for anything other than historical analysis
 23 2013-01-12 01:06:23 <stealth222> which is something I'm actually pretty interested in - but it isn't most applications
 24 2013-01-12 01:10:07 <stealth222> most useful for typical applications is querying for unspent outputs and filtering with callbacks
 25 2013-01-12 01:10:52 <stealth222> with those two things alone it is possible to write an entire wallet app that runs separately
 26 2013-01-12 01:11:44 <stealth222> spent transactions are only of historical interest
 27 2013-01-12 01:12:20 <gmaxwell> if you really want to do analysis you then probably want the whole dataset with a schema nicely setup for quering, including custom index types ('show me all txn with NOP1').
 28 2013-01-12 01:12:27 <gmaxwell> That isn't so.
 29 2013-01-12 01:12:44 <gmaxwell> Spent transactions are needed to feed the history of a wallet.
 30 2013-01-12 01:13:04 <stealth222> that's what is said, no? :)
 31 2013-01-12 01:13:32 <stealth222> and actually, a wallet should be keeping track of its own transactions
 32 2013-01-12 01:14:07 <stealth222> but it needs to query unspent outputs to make sure it is synched correctly - and it needs callbacks to update in realtime
 33 2013-01-12 01:14:40 <gmaxwell> no, querying the unspent outputs can make it miss transactions if it isn't the only copy of itself.
 34 2013-01-12 01:15:12 <stealth222> I was thinking about that...perhaps the wallet app could be smart enough to sync with other copies of itself
 35 2013-01-12 01:15:16 <stealth222> lol
 36 2013-01-12 01:15:18 <gmaxwell> This is the electrum-server and armory usecases.
 37 2013-01-12 01:15:45 <stealth222> I dislike the verification/relay agent having to maintain state and indexes specifically for a wallet client
 38 2013-01-12 01:16:11 <stealth222> for a single wallet client, that is
 39 2013-01-12 01:16:38 <stealth222> any wallet client, regardless of its present state, should be able to connect to any compliant verification/relay agent
 40 2013-01-12 01:17:18 <stealth222> the spent transactions are necessary to fully sync up multiple copies of itself that do not communicate with each other - that's true
 41 2013-01-12 01:18:37 <stealth222> but nonetheless, this information isn't super critical for most typical wallet usage
 42 2013-01-12 01:18:58 <stealth222> when you go to your bank's ATM, you don't usually query for a list of all your past transactions
 43 2013-01-12 01:19:29 <stealth222> if anything, only the last few transactions are ever of interest
 44 2013-01-12 01:19:47 <stealth222> and of course, the present balance
 45 2013-01-12 01:20:34 <stealth222> when you do your taxes it's another matter - but that's a separate app :)
 46 2013-01-12 01:31:44 <stealth222> the more I think about it, the more convinced I am that the wallets should be responsible for synching with one another
 47 2013-01-12 01:32:07 <stealth222> it's really no different than your contact list
 48 2013-01-12 01:33:15 <stealth222> or your calendar, or your music collection
 49 2013-01-12 01:33:30 <stealth222> google apps not withstanding :p
 50 2013-01-12 01:34:03 <gmaxwell> stealth222: yea, well tell that to the people with the 'business model' of clients which are stateless and are just recovered from a stored key.
 51 2013-01-12 01:34:32 <stealth222> well, then you need storage agents
 52 2013-01-12 01:34:38 <stealth222> that's fine, too
 53 2013-01-12 01:34:44 <stealth222> you can use encrypted cloud storage
 54 2013-01-12 01:35:00 <sipa> stealth222: walletpassphrase is not state for RPC :)
 55 2013-01-12 01:35:12 <sipa> it's wallet state
 56 2013-01-12 01:35:30 <stealth222> good point, sipa
 57 2013-01-12 01:36:07 <stealth222> anyhow, gmaxwell, recovering wallet states is not a verification/relay node function
 58 2013-01-12 01:36:17 <gmaxwell> stealth222: in any case, you are to some extent preaching to the chior here, and I'm trying to play devils advocate.
 59 2013-01-12 01:36:35 <gmaxwell> stealth222: Correct, thats why this would never be a default feature and double never not be exposed to the p2p network.
 60 2013-01-12 01:37:16 <stealth222> but getting unspent outputs and filtered callbacks should be
 61 2013-01-12 01:37:34 <gmaxwell> Making it really easy to use the reference software as a server for superlightweight wallets, is??? however??? one way to advocate more implementations of the reference software.
 62 2013-01-12 01:38:28 <gladoscc> bitcoin isn't recongizing my bitcoin.conf file
 63 2013-01-12 01:38:34 <gladoscc> I've set the permissions to 400
 64 2013-01-12 01:38:49 <gladoscc> but it still does not recongize it. what's the right permissions I should use?
 65 2013-01-12 01:39:07 <gmaxwell> gladoscc: why do you believe the permissions has anything to do with it?
 66 2013-01-12 01:39:27 <gladoscc> cause I fiddled around with chmod and now it doesnt work :P
 67 2013-01-12 01:39:44 <gmaxwell> gladoscc: any errors in the log?
 68 2013-01-12 01:40:19 <gmaxwell> 400 should work. Mine appearsr to be 664 here.
 69 2013-01-12 01:40:59 <gladoscc> nope, just that I must set rpcpassword which already exists in bitcoin.conf
 70 2013-01-12 01:41:13 <gladoscc> after ThreadRPCServer starts
 71 2013-01-12 01:45:04 <stealth222> are you running bitcoind from the right user account?
 72 2013-01-12 01:45:25 <gladoscc> Yes, they are all ubuntu
 73 2013-01-12 01:45:44 <gladoscc> heh
 74 2013-01-12 01:45:50 <gladoscc> I removed bitcoin.conf and created a new one
 75 2013-01-12 01:45:52 <gladoscc> and it worked :s
 76 2013-01-12 01:46:21 <Cusipzzz> sounds like an error between the chair and the monirot
 77 2013-01-12 01:46:26 <Cusipzzz> monitor even
 78 2013-01-12 01:46:58 <gladoscc> Cusipzzz: the thing is they're all owned by the same user account
 79 2013-01-12 01:47:01 <gladoscc> so I don't really know what went wrong.
 80 2013-01-12 01:49:49 <stealth222> so in conclusion to the earlier discussion, I'm not sure I like having a gettransactionsbyaddress call - although I do love getrawtransaction and getreceivedbyaddress and getunspentbyaddress
 81 2013-01-12 01:50:19 <stealth222> actually, perhaps just getunspentbyaddress
 82 2013-01-12 01:50:28 <stealth222> not even sure getreceivedbyaddress is completely necessary :)
 83 2013-01-12 01:50:34 <gmaxwell> stealth222: by not having it we condemn people to being forced to use a single functonal centeralized block explorer site???
 84 2013-01-12 01:50:53 <gmaxwell> stealth222: and we reduce the number of servers for things like electrum as they'll continue to require patched daemons.
 85 2013-01-12 01:51:04 <stealth222> there is another one, gmaxwell
 86 2013-01-12 01:51:08 <gladoscc> exactly. or you'll have to build your own blockchain
 87 2013-01-12 01:51:09 <stealth222> blockhawk.net
 88 2013-01-12 01:51:10 <gladoscc> db*
 89 2013-01-12 01:51:33 <gmaxwell> stealth222: almost none stay working for long. E.g. abe is more or less unmaintainble.
 90 2013-01-12 01:51:53 <stealth222> this one should be maintainable
 91 2013-01-12 01:52:11 <gladoscc> stealth222: two isn't any better, and while it isn't completely necessary it's very useful
 92 2013-01-12 01:52:20 <regen> man, this gmaxwell guy's still talking here? he's such a zero. i hear his wife is going to leave him. hahahaha
 93 2013-01-12 01:52:27 <stealth222> well then I'll publish the source code for blockhawk.net and you can run your own :)
 94 2013-01-12 01:52:30 <gladoscc> not to the average user using qt, but a lot of calls aren't useful
 95 2013-01-12 01:54:12 <stealth222> the biggest problems with running a site like blockhawk or blockchain.info is initial sync time
 96 2013-01-12 01:54:26 <stealth222> db insertions are very slow
 97 2013-01-12 01:56:10 <gmaxwell> stealth222: doesn't take much time in sipa's patch. And it's not just that. It's that it's somewhat costly to maintain and has no good honest way of monteizing it. So the operators generally lose interest.
 98 2013-01-12 01:56:25 <stealth222> which patch?
 99 2013-01-12 01:56:26 <gmaxwell> Making it cheaper to run one will make more of them, and making it an option in the client will get people to self service.
100 2013-01-12 01:57:09 <gmaxwell> stealth222: the one that isn't a pull request yet, that adds an efficent by address index.. that we were discussing earlier. It goes with the option to add a by txid index thats now a pull request.
101 2013-01-12 01:57:51 <stealth222> I'm sure that blockhawk could be made to sync faster with a faster storage engine - the storage engine is really the slowest part
102 2013-01-12 01:58:09 <stealth222> but it also maintains a LOT of indicesa
103 2013-01-12 01:58:28 <stealth222> even query by known addresses in wallet: http://blockhawk.net/bitcoin/address/1LbQmzf5Szks5GQHeLiRP6HsGqsoA5LWWC
104 2013-01-12 01:59:42 <stealth222> but you're right - without a good way to monetize it the incentive to really improve it diminishes
105 2013-01-12 02:00:00 <stealth222> unless it can be opensourced
106 2013-01-12 02:00:27 <gmaxwell> but putting the backend in the refrence client we get 9/10ths of the maintance for free.
107 2013-01-12 02:00:43 <gmaxwell> The unique code for it ends up being the small amount to maintain an extra index and query it.
108 2013-01-12 02:01:12 <stealth222> known addresses in wallet is computed by looking at txins in transactions
109 2013-01-12 02:01:34 <gmaxwell> stealth222: yea, thats a lossy metric in any case.
110 2013-01-12 02:01:49 <gmaxwell> It would give wrong results for a good fraction of my addresses, for example.
111 2013-01-12 02:02:10 <stealth222> it would require some heuristics atop it to really be useful
112 2013-01-12 02:02:12 <gmaxwell> And it'll just get worse in the future as people popularize easy tools for joint transactions.
113 2013-01-12 02:09:29 <stealth222> I would really like an API like this in the reference client, though: http://blockhawk.net/bitcoin/getOutputsByAddress?address=1JnQS6CmMYRBR7FhTFoZYSg888jsxCyBL9
114 2013-01-12 02:10:15 <stealth222> even if only for unspent (which is the default in this call)
115 2013-01-12 02:10:58 <stealth222> that alone is enough to build a signing agent that doesn't require a continuous connection to a network
116 2013-01-12 02:12:13 <stealth222> a signing agent that requires next to no synching at all
117 2013-01-12 02:12:26 <gmaxwell> a signing agent shouldn't be online at all.
118 2013-01-12 02:12:43 <gmaxwell> You should author the txn (and thus do the lookups) online and carry them to the signing agent.
119 2013-01-12 02:12:51 <stealth222> lol
120 2013-01-12 02:13:13 <stealth222> on a USB drive? or should I write it out on paper? :)
121 2013-01-12 02:13:15 <gmaxwell> You can happily do this now with armor, it has a nice UI.
122 2013-01-12 02:13:30 <gmaxwell> And you do it with USB or RS232.
123 2013-01-12 02:13:38 <gmaxwell> er armory.
124 2013-01-12 02:14:16 <stealth222> a signing agent could be behind a firewall that only lets through these specific queries
125 2013-01-12 02:15:36 <gmaxwell> The armory model is still nicer. :P
126 2013-01-12 02:19:30 <stealth222> who is behind armory?
127 2013-01-12 02:20:04 <gmaxwell> etotheipi_
128 2013-01-12 02:20:14 <stealth222> ah, cool
129 2013-01-12 02:20:24 <stealth222> yeah, he helped me write my signing agent
130 2013-01-12 02:20:29 <stealth222> I wasn't aware he did armory
131 2013-01-12 02:21:11 <etotheipi_> g'day!
132 2013-01-12 02:21:16 <stealth222> hi there! :)
133 2013-01-12 02:21:50 <stealth222> btw, etothepi, have you checked out pull request 2121 perchance?
134 2013-01-12 02:22:08 <etotheipi_> can you link me?
135 2013-01-12 02:22:12 <etotheipi_> I'm not familiar with it
136 2013-01-12 02:22:30 <stealth222> https://github.com/bitcoin/bitcoin/pull/2121
137 2013-01-12 02:23:22 <stealth222> perhaps the armory model is even better, though
138 2013-01-12 02:23:30 <etotheipi_> cool, I'll be watching
139 2013-01-12 02:23:38 <etotheipi_> I was just talking about implementing and RPC interface
140 2013-01-12 02:23:43 <etotheipi_> so I can easily match whatever you're doing
141 2013-01-12 02:24:03 <stealth222> gotta go for a bit but I'd love to continue this discussion later
142 2013-01-12 02:24:08 <etotheipi_> I mean, up until now, Armory has been a GUI/end-user-focused application... not so much on the backend for devs
143 2013-01-12 02:24:34 <etotheipi_> so I've focused on trying to make it as easy as possible to do with point-and-click...
144 2013-01-12 02:24:47 <etotheipi_> but I do need to create some atomic code operations that devs can build off of
145 2013-01-12 02:26:45 <Cory> Anybody know anything about retep's claim of a new, patchable vulnerability related to 0-confirmation transactions? https://bitcointalk.org/index.php?topic=135985.0
146 2013-01-12 02:28:29 <gmaxwell> Cory: Don't accept unconfirmed transactions.
147 2013-01-12 02:28:41 <gmaxwell> This is both general and specific advice.
148 2013-01-12 02:28:50 <Cory> Thanks. :)
149 2013-01-12 02:29:12 <gmaxwell> (it is not specific to any particlar client software either)
150 2013-01-12 02:29:57 <Cory> Hm, neat.
151 2013-01-12 02:32:20 <etotheipi_> Cory: I second that
152 2013-01-12 02:32:46 <etotheipi_> there is no patch for it... it's just the way that the network works -- zero-conf tx are just way too "easy" to reverse
153 2013-01-12 02:32:54 <etotheipi_> for tiny transactions you're willing to eat, it may be okay
154 2013-01-12 02:33:28 <etotheipi_> waiting for 1 confirmation is an order of magnitude safer... and waiting for 2+ is yet another order of magnitude safer
155 2013-01-12 02:34:21 <etotheipi_> none of us are surprised to hear that someone figured out how to "reverse" a 0- or 1-conf tx... a 2-conf transaction would definitely perk our ears, though
156 2013-01-12 02:34:53 <Cory> It doesn't sound like the issue can be fixed very quickly. Can I expect to learn more about it soon?
157 2013-01-12 02:35:19 <etotheipi_> it's not something that can be "fixed"... the network just needs time to globally agree that a transaction is "confirmed"
158 2013-01-12 02:35:36 <etotheipi_> that's the point of confirmations... the deeper it is, the more confident you can be that it will be there forever
159 2013-01-12 02:35:58 <etotheipi_> unfortunately, 0- and 1-conf tx are just too young to have high degrees of confidence
160 2013-01-12 02:36:14 <etotheipi_> 1-conf are much safer, but for medium/large transactions you'd best wait for 2+
161 2013-01-12 02:36:35 <etotheipi_> and standard practice is to wait 6 for any important transaction
162 2013-01-12 02:37:22 <etotheipi_> but since there's no central authority, that's just how long it takes for the network to reach a consensus on whether a tx is real or not... it's not a bug
163 2013-01-12 02:37:29 <Cory> It seems like the sort of thing that if it is ever to ever be explained, it may as well be explained sooner rather than later.
164 2013-01-12 02:37:57 <etotheipi_> without a central authority, there's also no central place to explain these things :)
165 2013-01-12 02:38:07 <Cusipzzz> explained? 0 conf txns have always been very vulnerable
166 2013-01-12 02:38:09 <etotheipi_> but all this information is out there
167 2013-01-12 02:38:33 <etotheipi_> you just might have to aggregate from multiple sources
168 2013-01-12 02:38:51 <Cory> Seeing a stickied thread, I assumed somebody discovered something new.
169 2013-01-12 02:39:48 <etotheipi_> Just remember zero-conf is like "hey, someone is trying to send you money",  1-conf is like "okay, the network has given an indication it will be accepted"
170 2013-01-12 02:40:00 <gmaxwell> etotheipi_++
171 2013-01-12 02:40:58 <Cory> I understand how transactions are confirmed. I was just curious about what somebody recently realized that was important enough to make an announcement.
172 2013-01-12 02:41:09 <etotheipi_> Cory, where?
173 2013-01-12 02:41:15 <Cory> https://bitcointalk.org/index.php?topic=135985.0
174 2013-01-12 02:44:17 <gladoscc> That's not important
175 2013-01-12 02:44:21 <gladoscc> It's someone trying to stirr up some fuss.
176 2013-01-12 02:44:26 <Cory> Thanks for the post gmaxwell. I look forward to the demystification.
177 2013-01-12 02:45:54 <etotheipi_> Cory: I see now... yeah for me that's old news, but I can see why some people would freak out about it
178 2013-01-12 02:45:57 <gmaxwell> gladoscc: he's not. I think his post could have been better worded but its genuine concern.
179 2013-01-12 02:46:11 <gmaxwell> And there are lots of things accepting unconfirmed txn. A scarry amount.
180 2013-01-12 02:46:24 <gladoscc> that's true, but was it ever said that 0 conf TXes are safe?
181 2013-01-12 02:46:30 <gladoscc> it's pretty much a "the sky is blue" post
182 2013-01-12 02:46:53 <Cusipzzz> gladoscc: agreed, can lead a horse to water i guess.
183 2013-01-12 02:46:53 <yareyare> the word "unconfirmed" pretty much explains what a 0 conf TX is
184 2013-01-12 02:47:18 <Cory> It was posted in the "Important Announcements" subforum, too.
185 2013-01-12 02:47:24 <gmaxwell> gladoscc: yea and yet lots of things were accepting them. You will be surprised at the list of some of the things that were vulnerable I promise.
186 2013-01-12 02:47:31 <etotheipi_> well judging by the mass number of security fails in the past two years, it doesn't surprise me that many devs overlooked that
187 2013-01-12 02:47:49 <gladoscc> gmaxwell: yeah, and loopholes
188 2013-01-12 02:47:56 <gladoscc> I know a site that needs 4 confirms
189 2013-01-12 02:48:00 <gladoscc> but the REFERRAL program doesn't.
190 2013-01-12 02:48:33 <gladoscc> either way, it brings exposure to the problem which is good
191 2013-01-12 02:48:46 <Cusipzzz> 6 maybe overkill but 0 is pretty absurd. what's next a sticky on backing up your wallet?
192 2013-01-12 02:50:11 <Cory> Methods of double spending unconfirmed transactions have been discussed pretty thoroughly on Bitcointalk. This must be a less obvious one?
193 2013-01-12 02:51:19 <gmaxwell> Cusipzzz: 6 is sadly underkill under a bunch of different attack models now.
194 2013-01-12 02:51:46 <gmaxwell> 6 wasn't a recommendation that was made assuming you could hack one computer or kidnap one person and get 20% of the hashpower. :(
195 2013-01-12 02:52:36 <gmaxwell> In any case, please don't muse on it in here.
196 2013-01-12 02:52:52 <gmaxwell> You may figure it out and that will increase exposure.
197 2013-01-12 02:55:11 <Cusipzzz> gmaxwell: eh, maybe if people don't understand who they are connecting to
198 2013-01-12 02:59:30 <gladoscc> gmaxwell: what would be a safe number of confirmations?
199 2013-01-12 03:00:38 <gmaxwell> depends on the coin moved in the blocks, and how much of it you think could be an attacker's transactions.
200 2013-01-12 03:01:44 <gmaxwell> 21:42 < gmaxwell> I was contemplating having a setting in bitcoin clients your confirms to be considered confirmed would be adaptive based on the transaction value and a setting you give "maximum attacker hashpower" where you'd set it to the largest consolidation you believe exists.
201 2013-01-12 03:01:49 <gmaxwell> 21:43 < gmaxwell> But the problem is that an attacker can attack multiple people with one reorg, so it's not the transaction value that matters, but the sum transaction value for the whole block that would be reorged.
202 2013-01-12 03:01:53 <gmaxwell> 21:43 < gmaxwell> and it turns out that consolidations of, e.g. 30% like we have from big pools actually suggest that you should have quite long confirmation horizons. :(
203 2013-01-12 03:01:56 <gmaxwell> 21:44 < gmaxwell> since we frequently have blocks that move tens of thousands of btc.
204 2013-01-12 03:01:59 <gmaxwell> 21:49 < gmaxwell> e.g. 30% can reorg 15 blocks with p=0.0101008 ... if they fail they lose 25*15 BTC. If they are successful they get 25*15 plus what they can double spend.
205 2013-01-12 03:02:02 <gmaxwell> 21:49 < gmaxwell> so they need to double spend solve((0.9898992*(-25*15))+(0.0101008*(x+25*15))=0,x) = 36375 BTC to break even.
206 2013-01-12 03:02:05 <gmaxwell> 21:50 < gmaxwell> So if you're pessimstic and assume all transactions in a block are potential double spend fodder, then with current levels of consolidation and values in flight people should be really waiting 10-20 confirms
207 2013-01-12 03:02:09 <gmaxwell> 21:51 < gmaxwell> unless you really believe that holding a gun to a poolops head (or really, just hacking his systems) is all that hard.
208 2013-01-12 03:02:30 <gmaxwell> of course, if you have other trust factors then its less of an issue.
209 2013-01-12 03:02:46 <gmaxwell> E.g. if you know who the recipent is...
210 2013-01-12 03:03:40 <gladoscc> I see, the problem is that mining pools aren't decentralized enough them
211 2013-01-12 03:04:18 <gmaxwell> right well, and soon potentially not pools. The "asicminer" company on the forums claims to be about to bring 7TH/s online in their first major turnup.
212 2013-01-12 03:04:20 <gladoscc> green addresses should be more widely adopted
213 2013-01-12 03:04:40 <gmaxwell> gladoscc: greenaddresses do not scale, and create other vulnerabilties.
214 2013-01-12 03:05:01 <Cusipzzz> do not want greenaddresses, building in trust and centralization where not needed
215 2013-01-12 03:05:14 <gladoscc> Well yeah, considering how trust is basically the concept behind green addresses
216 2013-01-12 03:05:23 <gmaxwell> You don't need a green address to know who is paying you... but using them lets _everyone_ know, which means that the transactions lose privacy and become vulnerable to blocking.
217 2013-01-12 03:05:25 <Cusipzzz> and i'll believe the 7TH/s when i see it
218 2013-01-12 03:05:33 <gladoscc> But it's highy improable that for example mt.gox starts double spending coins
219 2013-01-12 03:06:11 <etotheipi_> gladoscc: a big pool operator may not intend to double-spend, but an attacker who gets temporary control of their resources might
220 2013-01-12 03:06:45 <gmaxwell> and the usage of green addresses basically requires bouncing coins around or creating junk signing outputs, which reduces the scalablity of bitcoin.  Payment protocols or detatched signed txids can give you the same thing without breaking privacy.
221 2013-01-12 03:06:49 <Cusipzzz> the problem with large pools used to be much worse. but yeah, still a problem
222 2013-01-12 03:07:10 <gladoscc> Yeah, didn't deepbit get over 50% once?
223 2013-01-12 03:07:21 <gmaxwell> Petertodd's proposals for chaum token banks would allow instant smallpayments with even better privacy than bitcoin alone can have. Lots of options.
224 2013-01-12 03:08:38 <Cusipzzz> gladoscc: yes, for several days
225 2013-01-12 08:43:36 <Jouke> gmaxwell: this so called new vulnerability relating to zero-confirmation transactions is just about a discovery of a new way to easily perform a double spend useing old and known techniques?
226 2013-01-12 08:51:28 <midnightmagic> Jouke: he went to bed.
227 2013-01-12 08:51:56 <petertodd> jouke: I answered on the forum
228 2013-01-12 11:29:57 <yareyare> dear anyone who produces build scripts: please test them. i just had a script try to compile a version of a library where the makefile was broken. there's no way that it ever worked
229 2013-01-12 11:31:05 <Diapolo> if you find bugs you are encouraged to report them ;)
230 2013-01-12 11:31:35 <Diapolo> Does anyone know, which function catches throw JSONRPCError()?
231 2013-01-12 11:33:33 <yareyare> i suppose i could look for an email address
232 2013-01-12 11:34:54 <Diapolo> yareyare: when it's related to the Satoshi bitcoin client just report them here: https://github.com/bitcoin/bitcoin/issues
233 2013-01-12 11:35:12 <yareyare> in this case, it is not :P
234 2013-01-12 11:35:25 <Diapolo> ^^
235 2013-01-12 11:35:26 <yareyare> still, the world would be a slightly better place if people test build scripts more.
236 2013-01-12 11:35:49 <yareyare> it turns out that they included a makefile patch, but it's not in the build documentation, it's one line in the release notes
237 2013-01-12 11:36:14 <yareyare> i dont know why they didnt just update the library to the x.x.x.1 revision...surely that wouldnt break anything
238 2013-01-12 11:41:13 <Diapolo> is it a bitcoin related lib?
239 2013-01-12 11:43:39 <yareyare> nope :P
240 2013-01-12 11:44:50 <yareyare> well, unless someone wants to build an arm toolchain from source, then use that to build bitcoin.
241 2013-01-12 11:45:36 <SomeoneWeird> heh
242 2013-01-12 13:03:27 <SomeoneWeird> not related to btc, but does anybody know the different fields in a pw hash pulled from a windows system?
243 2013-01-12 13:08:58 <SomeoneWeird> i wonder if http://www.governmentsecurity.org/forum/topic/19141-ntlm-hashes-with-rainbow-crack/page__view__findpost__p__143387 is right
244 2013-01-12 13:17:53 <ECKey> hello
245 2013-01-12 13:22:34 <yareyare> SomeoneWeird: i'm vaguely familiar with them. all recent ones should have a dummy hash in the LM part, since cracking LM is a bad joke
246 2013-01-12 13:22:55 <SomeoneWeird> lol, ya
247 2013-01-12 13:23:01 <yareyare> there ought to be some sort of special award
248 2013-01-12 13:23:11 <yareyare> to come up with "let's split the password in 2 and hash them separately!"
249 2013-01-12 13:23:21 <SomeoneWeird> i think it's name:id:lm:ntlm:::
250 2013-01-12 13:23:24 <SomeoneWeird> not sure about the last 2
251 2013-01-12 13:23:50 <SomeoneWeird> (seeing as theyre blank)
252 2013-01-12 13:23:52 <yareyare> it might depend on the software that extracted them
253 2013-01-12 13:24:00 <SomeoneWeird> yeah, maybe
254 2013-01-12 16:32:47 <grau> TD: may I have comments to blocktester and how it is integrated to bitcoinj?
255 2013-01-12 16:33:41 <grau> just missed by seconds...
256 2013-01-12 17:10:43 <grau> TD: may I have comments to blocktester and how it is integrated to bitcoinj?
257 2013-01-12 17:11:03 <TD> it's currently not integrated, i think. i'll have to work with matt to get it actually checked in. i don't remember what the issue was
258 2013-01-12 17:11:12 <TD> but i didn't write it, so maybe matt is a better guy to talk to about that
259 2013-01-12 17:11:49 <grau> it is in the test directory of bitcoinj whatis missing is the tester against bitcoind that is with Matt in a separate repository
260 2013-01-12 17:11:59 <grau> my question is about the classes in bitcoinj test
261 2013-01-12 17:13:22 <TD> ok
262 2013-01-12 17:13:25 <TD> what is the question?
263 2013-01-12 17:15:00 <grau> The file FullPrunedBlockChainTest is in test directory therefore not bundled into the bitcoinj jar
264 2013-01-12 17:15:12 <grau> therefore I can not create a maven that simply pulls it in
265 2013-01-12 17:15:19 <TD> yes
266 2013-01-12 17:15:29 <grau> could you have an artifact for it or move it into main source ?
267 2013-01-12 17:15:50 <grau> anothe rproblem is that it defines a package protected class that it returns
268 2013-01-12 17:15:56 <grau> this again disallows reuse
269 2013-01-12 17:16:02 <TD> i suppose we could, but why not just copy it into your own source tree?
270 2013-01-12 17:16:22 <TD> the bitcoinj API isn't really fixed or stable right now, so most users track the git repository
271 2013-01-12 17:16:25 <grau> because gmaxwell would not believe me its the same :)
272 2013-01-12 17:17:25 <TD> well, i mean just copy the files :)
273 2013-01-12 17:17:41 <TD> or just make your own clone of bitcoinj and patch it. then you can just rebase on top of master every so oftne
274 2013-01-12 17:17:55 <grau> I did for temp fix, just let you know what would be nicer
275 2013-01-12 17:18:07 <TD> having other code depend on the public API is one thing, having other code depend on the details of testing tools is a bit unusual and i suspect we'll forget or unintentionally break things at some point
276 2013-01-12 17:18:11 <TD> ok, thanks for the heads up
277 2013-01-12 17:19:41 <grau> Thats what I want independent test cases, therefore convert the test chain your tool generates into JSON, gmaxwell will not believe in anything either
278 2013-01-12 18:00:39 <X-Scale> gmaxwell: http://tech.mit.edu/V132/N61/swartz.html
279 2013-01-12 18:17:44 <gmaxwell> X-Scale: I am aware, ??? though I suppose other people might care to know.  I'd also suggest http://lessig.tumblr.com/post/40347463044/prosecutor-as-bully
280 2013-01-12 18:24:24 <ThomasV> shit
281 2013-01-12 18:48:11 <jgarzik> gmaxwell: Saw that Lessig post elsewhere.  Reminds me of every federal prosecutorial story I've ever heard :(  I certainly agree with this:  Somehow, we need to get beyond the ???I???m right so I???m right to nuke you??? ethics that dominates our time.
282 2013-01-12 18:51:27 <gmaxwell> My understanding is that the people questioned by the grand jury in his case were asked almost entirely questions related to wikileaks and pacer/recap. The zeal of the prosecutor has created a stir previously: http://thephoenix.com/Boston/news/141253-15th-annual-muzzle-awards/?page=2#TOPCONTENT
283 2013-01-12 18:55:42 <stealth222> I know people who have outright stolen millions of dollars - literally - and only got a few years
284 2013-01-12 18:56:14 <stealth222> not just hypothetical "it could be worth millions"
285 2013-01-12 18:56:19 <jgarzik> Federal prosecutors always overcharge, presumably to (among other reasons) encourage a plea, and have something to throw away in negotiations.
286 2013-01-12 18:56:46 <jgarzik> But on the other side, if you are innocent or want to dispute some of the charges, it is that much more costly
287 2013-01-12 18:57:01 <stealth222> it's a negotiation tactic - yes
288 2013-01-12 18:57:32 <stealth222> the seller starts above the target and the buyer starts below
289 2013-01-12 18:57:38 <stealth222> and hopefully they meet somewhere in between
290 2013-01-12 18:57:44 <jgarzik> IOW, prosecutors do not seem likely to say "oh well, he's fighting the charges, I'll just drop the ones that are questionable and proceed to trial with the others"
291 2013-01-12 18:57:58 <jgarzik> overcharging also pumps up the sentence, should the prosecution prevail
292 2013-01-12 18:58:21 <stealth222> but it also can have a greater risk of a hung jury
293 2013-01-12 18:58:40 <jgarzik> federal conviction rates seem to imply that's not much risk
294 2013-01-12 18:59:49 <gmaxwell> Overcharging is also especilly encouraged by the points system in federal court, and also because unless you convince a jury that you are lily-white they're likely to let _some_ charges stick even if they believe you are innocent.
295 2013-01-12 19:00:32 <gmaxwell> (they'll internally negoiate and resolve a hang by compromising on some charges)
296 2013-01-12 19:01:14 <stealth222> in some cases it can also help coerce cooperation - turning suspects into witnesses
297 2013-01-12 19:57:38 <gmaxwell> jgarzik: obviously it won't do anything, but worth mentioning: https://petitions.whitehouse.gov/petition/remove-united-states-district-attorney-carmen-ortiz-office-overreach-case-aaron-swartz/RQNrG1Ck
298 2013-01-12 20:01:09 <RNZ> hi
299 2013-01-12 20:02:29 <RNZ> anybody know how to speedup sync blk*.dat ?
300 2013-01-12 20:02:58 <Cusipzzz> RNZ: get better hardware :)
301 2013-01-12 20:03:34 <RNZ> )))
302 2013-01-12 20:05:00 <RNZ> i talk about a lot of flush io operations do it by bitcoind(qt)
303 2013-01-12 20:07:00 <RNZ> may be present more lower intensive flushing mode?
304 2013-01-12 20:10:28 <RNZ> and if i have more then one instances bitcoind running, may I use one blk*.dat files for all running instances for read and one instance for write?
305 2013-01-12 20:36:19 <gmaxwell> RNZ: no, multiple instances may not share the same blk files easily.  If you run the development version it is much faster.
306 2013-01-12 20:37:39 <RNZ> thx. how about not easy method?
307 2013-01-12 20:39:00 <RNZ> need modifications in src?
308 2013-01-12 20:39:58 <gmaxwell> the blk.dat files themselves are append only, you can have multiple nodes reusing the same historic dat files.
309 2013-01-12 20:44:50 <Luke-Jr> RNZ: if you have a hardlink-capable OS, you can use https://bitcointalk.org/index.php?topic=94881 for blk0001
310 2013-01-12 20:45:17 <RNZ> thx, I never wanted to do.
311 2013-01-12 20:45:57 <RNZ> ptfu... thx, I wanted to do.
312 2013-01-12 20:45:59 <RNZ> )))
313 2013-01-12 21:02:44 <RNZ> Luke-jr: With blk0001.dat is clear, but currently blk0002.dat - syncing. And may present method run bitcoind in watch only mode on blk0***.dat? Example, bitcoind watch to blk files by inotify/fanotify or reread dir by time and update only  index and other files, instead blk0***.dat files?
314 2013-01-12 21:03:59 <RNZ> s/instead/exclude/
315 2013-01-12 21:07:18 <gmaxwell> RNZ: that would be a basic rewrite... the files on disk must be consistent with what is in memoy.
316 2013-01-12 21:07:23 <gmaxwell> er, memory.
317 2013-01-12 21:07:33 <Luke-Jr> RNZ: not supported
318 2013-01-12 21:07:52 <Luke-Jr> gmaxwell: probably trivial, just make -reindex continuous?
319 2013-01-12 23:15:30 <kuzetsa> Luke-Jr: windows NTFS has supported hard links for years :P
320 2013-01-12 23:21:40 <sipa> kuzetsa: i think Luke-Jr was referring to the fact that the client doesn't support sharing the block file/database