1 2012-07-09 00:00:10 <gmaxwell> (e.g. he can't reverse a transaction unboundly far in the past without equally unbounded work in private)
  2 2012-07-09 00:00:45 <mcorlett> Thank you, gentlemen.
  3 2012-07-09 00:23:52 <gmaxwell> oh, people on the forums... : "So, my client isn't able to get the block chain because of how I set my clock on my computer (I think it's crappy, but I don't care)."
  4 2012-07-09 00:24:57 <Karmaon> Bitcoin world problems
  5 2012-07-09 00:56:01 <setkeh> !help ban
  6 2012-07-09 00:56:02 <gribble> Error: There is no command "ban".
  7 2012-07-09 00:56:09 <setkeh> oops wc lol srry
  8 2012-07-09 03:09:30 <copumpkin> is there a description of the coin-picking algorithm that picks which source addresses to use for a given transaction?
  9 2012-07-09 03:17:48 <luke-jr> copumpkin: it doesn't have anything to do with addresses right now
 10 2012-07-09 03:18:55 <copumpkin> well, say I have a few smallish balances in my wallet now and will get a moderately sized transaction of X coins, and intend to send those X to another address
 11 2012-07-09 03:19:12 <copumpkin> will the client reach into my smaller balances or is it trying to keep as few inputs as possible?
 12 2012-07-09 03:19:57 <luke-jr> there are no balances, just coins
 13 2012-07-09 03:20:15 <luke-jr> it will choose the older coins first, for the most part
 14 2012-07-09 03:20:24 <luke-jr> if you wait for the big one to mature 6 blocks, it might use it
 15 2012-07-09 03:20:38 <luke-jr> if you use next-test, you can use Coin Control to restrict coin selection by source address
 16 2012-07-09 03:20:51 <copumpkin> Coin Control? is that a different client?
 17 2012-07-09 03:21:17 <phantomcircuit> it's a patch
 18 2012-07-09 03:21:22 <copumpkin> oh
 19 2012-07-09 03:22:33 <phantomcircuit> i love all the people making threats in the bitcoinica thread
 20 2012-07-09 03:22:36 <luke-jr> copumpkin: next-test is a 0.7 preview with a lot of experimental patches merged: https://bitcointalk.org/?topic=89099
 21 2012-07-09 03:22:45 <phantomcircuit> there is literally no way for that to help them
 22 2012-07-09 03:23:08 <phantomcircuit> either i believe their threat in which case i call the cops and they never get anything
 23 2012-07-09 03:23:13 <phantomcircuit> or i dont and it just makes me annoyed
 24 2012-07-09 03:23:27 <phantomcircuit> people who dont understand game theory are the bane of my existence
 25 2012-07-09 03:23:32 <copumpkin> lol
 26 2012-07-09 03:23:46 <copumpkin> what is happening with that debacle these days?
 27 2012-07-09 03:23:52 <copumpkin> I stopped following
 28 2012-07-09 03:24:05 <phantomcircuit> jokers with threats
 29 2012-07-09 03:24:35 <gmaxwell> copumpkin: the deposited funds are currently with pirate growing until everyone can be paid back.
 30 2012-07-09 03:24:38 <copumpkin> luke-jr: I see. No mac builds I assume?
 31 2012-07-09 03:24:44 <copumpkin> gmaxwell: hah I bet
 32 2012-07-09 03:24:46 <phantomcircuit> gmaxwell, loooooooooolllllllllllllll
 33 2012-07-09 03:24:50 <luke-jr> copumpkin: only bitcoind for 0.5 and 0.6
 34 2012-07-09 03:24:53 <phantomcircuit> people dont really realize just how much work it is
 35 2012-07-09 03:25:10 <phantomcircuit> paying back a claim takes between 1 minute and several hours
 36 2012-07-09 03:25:12 <gmaxwell> "an alchemical brew of intermingled conspiracy theories"
 37 2012-07-09 03:25:13 <copumpkin> phantomcircuit: you think it'll come back someday, or was it just a crock of shit?
 38 2012-07-09 03:25:30 <phantomcircuit> copumpkin, well im running this fucked up horror show now
 39 2012-07-09 03:25:34 <phantomcircuit> it will come back
 40 2012-07-09 03:25:42 <phantomcircuit> none of zhou's code will be used
 41 2012-07-09 03:25:48 <luke-jr> copumpkin: https://bitcointalk.org/?topic=83743 is my hope for getting Mac builds
 42 2012-07-09 03:26:08 <luke-jr> phantomcircuit: as a legit site, or another bucket shop?
 43 2012-07-09 03:26:17 <phantomcircuit> it took me a grand total of 3 hours to take my bitcoinica balance from 0.1337 to 23k btc using various race conditions in the original code base
 44 2012-07-09 03:26:48 <phantomcircuit> luke-jr, afaikt it wasn't a bucket shop except for when it got hacked and all of a sudden was short
 45 2012-07-09 03:26:55 <gmaxwell> copumpkin: the coin selector uses a subset sum solver to try to minimize the excess input.. so it tends to avoid using extra inputs. But it's totally blind to the fact that some inputs come from the same address.
 46 2012-07-09 03:26:58 <copumpkin> luke-jr: oh, I forgot about that
 47 2012-07-09 03:27:04 <copumpkin> yay subset-sum
 48 2012-07-09 03:27:17 <gmaxwell> (because there is a weak assumption that people will use unique addresses per transaction)
 49 2012-07-09 03:27:54 <luke-jr> phantomcircuit: oh? gmaxwell was under the impression it was and I generally trust him on these things :p
 50 2012-07-09 03:28:07 <copumpkin> luke-jr: how much are you looking for to get started on the Mac work?
 51 2012-07-09 03:28:27 <phantomcircuit> luke-jr, the way it worked was that the net positions of all the users was calculated every like 10 seconds and if the net position was out of whack with the actual assets by more than a fixed amount a hedge order would be placed
 52 2012-07-09 03:28:53 <copumpkin> gmaxwell: and there's no way I can force the client right now to avoid the other sources?
 53 2012-07-09 03:29:00 <copumpkin> I guess I could temporarily send them off to a different wallet :)
 54 2012-07-09 03:29:24 <phantomcircuit> afaict zhou made a series of decisions out of pure lazyness which made the entire thing work
 55 2012-07-09 03:29:30 <gmaxwell> The existance of hedging doesn't itself make it not a bucketshop. Though if the hedging really was 100% then it would be mostly not one.
 56 2012-07-09 03:29:56 <phantomcircuit> gmaxwell, the hedging was on the delta between net positions and the calculated expected assets
 57 2012-07-09 03:30:03 <luke-jr> copumpkin: well, with 7.7 BTC more, I could do an hour at my usual (Bitcoin/open source) rate; I'm SURE it will take much more than an hour, but that seems somewhere to start
 58 2012-07-09 03:30:09 <phantomcircuit> which wasn't always 100% right due to various bugs (and people stealing)
 59 2012-07-09 03:30:33 <gmaxwell> Zhou refused to answer direct questions about the degree of hedging. Also, even 100% itself ignores the liquidity risk.
 60 2012-07-09 03:31:01 <copumpkin> luke-jr: sent :) good luck!
 61 2012-07-09 03:31:08 <phantomcircuit> gmaxwell, the hedge was only on the difference between all the users net positions and the calculated expected assets
 62 2012-07-09 03:31:27 <luke-jr> phantomcircuit: stealing was going on for a while unnoticed? :o
 63 2012-07-09 03:31:33 <luke-jr> copumpkin: thanks
 64 2012-07-09 03:31:36 <phantomcircuit> luke-jr, yeah
 65 2012-07-09 03:31:40 <luke-jr> phantomcircuit: ouch!
 66 2012-07-09 03:31:43 <copumpkin> :/
 67 2012-07-09 03:31:43 <gmaxwell> The real question is are the positions backed by actual assets. Now the externally visible evidence suggests they were not ... because people aren't paid back. But there are obvious other reasons for that.
 68 2012-07-09 03:31:51 <phantomcircuit> mostly i think it was just people not noticing small amounts though
 69 2012-07-09 03:32:01 <phantomcircuit> there was someone who had leverage of 500x
 70 2012-07-09 03:32:05 <phantomcircuit> that was uh
 71 2012-07-09 03:32:14 <phantomcircuit> but his account was only -1.50
 72 2012-07-09 03:32:22 <phantomcircuit> so i guess that didn't work as well as he thought it would
 73 2012-07-09 03:32:24 <copumpkin> wow
 74 2012-07-09 03:32:45 <gmaxwell> Also, the lack in change in MTGOX volume suggests to me that 'calculated expected assets' might have been a bit optimistic!
 75 2012-07-09 03:33:10 <gmaxwell> phantomcircuit: hah.  "haxor 500x leverage ... loses 500x the funds"
 76 2012-07-09 03:33:30 <phantomcircuit> gmaxwell, there was a db variable which would be incremented and decremented when a user deposited/withdraw/liquidated/straight traded
 77 2012-07-09 03:33:40 <phantomcircuit> so it totally had no idea about any fuck ups
 78 2012-07-09 03:33:49 <gmaxwell> crazy!
 79 2012-07-09 03:34:00 <phantomcircuit> but actually that wasn't so bad because it meant when fuck ups happened there wasn't an instant buy of 25k btc
 80 2012-07-09 03:35:05 <gmaxwell> it's not unusal for bugs/flaws to compensiate for each other.
 81 2012-07-09 03:35:11 <gmaxwell> The ones that don't get noticed and fixed.
 82 2012-07-09 03:35:32 <phantomcircuit> so assuming nobody was stealing (heh yeah right) the total liabilities/total assets would match if all the positions were liquidated simultaneously
 83 2012-07-09 03:36:12 <phantomcircuit> which is something a bucket shop cant do
 84 2012-07-09 03:36:48 <gmaxwell> phantomcircuit: but 'liquidated simultaneously' isn't the most interesting mode.  And balance isn't a constant because the short positions have caps.
 85 2012-07-09 03:36:54 <phantomcircuit> the entire codebase was nothing but fuckups of design and just not having any clue
 86 2012-07-09 03:37:08 <gmaxwell> E.g. what would happen if the btc/$ rate on mtgox stepped to $1000 and never moved from there again?
 87 2012-07-09 03:37:11 <phantomcircuit> like zhou was relying on user.lock! to serialize access to various things
 88 2012-07-09 03:37:18 <phantomcircuit> except he was calling it outside of a transaction
 89 2012-07-09 03:37:22 <phantomcircuit> so it doesn't do anything
 90 2012-07-09 03:38:06 <phantomcircuit> gmaxwell, honestly if that happened rapidly bitcoinica would have just wiped out all the shorts and the resulting profit would have covered any loss from slow trade reaction
 91 2012-07-09 03:39:20 <gmaxwell> uh. Well thats a question that can be answered, .. but it isn't a universal truth.  At the limit (replace $1000 with as large as you like) thats only true if you're not canceling any shorts against the longs.
 92 2012-07-09 03:39:52 <gmaxwell> and so we're back the the core definition of a bucket shop: the positions are not asset backed. There is _some_ increase in asset price which is uncoverable.
 93 2012-07-09 03:40:37 <gmaxwell> And the customers had no way to reason about the risk. E.g. perhaps there were always enough short assets compared to the long positions (e.g. 100:1) that any realistic increase in btc price could be covered.
 94 2012-07-09 03:40:39 <phantomcircuit> gmaxwell, no all the positions were asset backed
 95 2012-07-09 03:41:39 <phantomcircuit> actually sort of
 96 2012-07-09 03:41:44 <gmaxwell> phantomcircuit: for that to be true the short underlying assets had to outnumber the long positions * their leverage.
 97 2012-07-09 03:41:48 <phantomcircuit> there was a race condition that could cause that to not be true
 98 2012-07-09 03:42:06 <gmaxwell> (you'd have to have 100x the value in short positions to long)
 99 2012-07-09 03:42:14 <phantomcircuit> well no not really
100 2012-07-09 03:42:27 <phantomcircuit> one person short really does cancel out one person long
101 2012-07-09 03:43:00 <phantomcircuit> but it depends largely on the order of operations
102 2012-07-09 03:43:08 <phantomcircuit> and this is where it gets probabilistic
103 2012-07-09 03:43:26 <phantomcircuit> the liquidation logic and the hedging logic ran parallel to each other
104 2012-07-09 03:43:30 <phantomcircuit> as separate jobs
105 2012-07-09 03:43:41 <gmaxwell> just assume the bitcoin price goes to infinite in one step. How does that leave people?
106 2012-07-09 03:43:57 <gmaxwell> The hedging is irrelevant because it can't move fast enough for a infinite step change.
107 2012-07-09 03:44:09 <gmaxwell> (or at least the reaction of hedging, prior hedging counts)
108 2012-07-09 03:44:26 <phantomcircuit> no but it can
109 2012-07-09 03:45:04 <gmaxwell> It's only safe if the short deposits (1/10th the postions) plus hedge purchased coins are greater than the leveraged positions (10x leverage value).
110 2012-07-09 03:45:39 <gmaxwell> And thats a heck of a lot of hedging. I'm skeptical that this was happening. In fact, I think it would be arguably irrational to run the business so safely.
111 2012-07-09 03:45:54 <phantomcircuit> lol it was
112 2012-07-09 03:46:04 <gmaxwell> (simply because if the customers actually cared they'd be demanding proof of it too!)
113 2012-07-09 03:46:06 <phantomcircuit> the mtgox btc account history file is like 15+MB
114 2012-07-09 03:48:10 <gmaxwell> It would have been interesting to seralize and delay trades which would take the system out of the fully backed zone until the hedge transactions made it through.
115 2012-07-09 03:49:16 <gmaxwell> (or more than X over, where X is the amount of the operators coin they're willing to risk on fringe events)
116 2012-07-09 04:10:56 <phantomcircuit> gmaxwell, the magic number is 100% change
117 2012-07-09 04:11:14 <phantomcircuit> i think
118 2012-07-09 04:11:20 <phantomcircuit> i'd have to look at the numbers again
119 2012-07-09 04:11:57 <phantomcircuit> there are more complex risk models you can employ that take into account the liquidation point
120 2012-07-09 04:17:07 <phantomcircuit> blargh
121 2012-07-09 04:17:21 <phantomcircuit> there is no way to have qemu start vnc after the vm has started
122 2012-07-09 04:18:15 <bonks> if i have two clients, both using the same and only node (using connect=), will their local blockchains be identical?
123 2012-07-09 07:39:31 <gribble> New news from bitcoinrss: Diapolo opened pull request 1571 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1571>
124 2012-07-09 09:41:19 <drizztbsd> hi, does bitcoin 0.6.3 works with new boost (filesystem v3)?
125 2012-07-09 09:42:00 <sipa> yes
126 2012-07-09 09:46:49 <gribble> New news from bitcoinrss: Diapolo opened pull request 1572 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1572>
127 2012-07-09 11:47:56 <gmaxwell> I strongly disapprove of the addition of closed webservices and unreviewable propritary clients to the bitcoin.org site.
128 2012-07-09 11:48:15 <gmaxwell> Does anyone think I'm crazy in holding this position?
129 2012-07-09 11:48:49 <copumpkin> which one are you referring to?
130 2012-07-09 11:49:18 <gmaxwell> copumpkin: the bottom half of the clients page. http://bitcoin.org/clients.html
131 2012-07-09 11:49:30 <copumpkin> oh
132 2012-07-09 11:49:54 <copumpkin> some of blockchain.info is on github
133 2012-07-09 11:49:54 <_dr> I think no sane person will want to have closed source handling its bitcoins :)
134 2012-07-09 11:50:00 <copumpkin> but not all of it
135 2012-07-09 11:50:20 <copumpkin> enough for me to see it's all done in java :)
136 2012-07-09 11:50:39 <gmaxwell> I'm starting to think we should remove the clients page. This is just going to be a source of disputes.
137 2012-07-09 11:50:59 <copumpkin> how are people supposed to know about them then?
138 2012-07-09 11:51:37 <gmaxwell> copumpkin: The same way you or I know about them which would also give them an oppturnity to find out about the risks in them.
139 2012-07-09 11:52:17 <copumpkin> I guess :)
140 2012-07-09 11:52:22 <copumpkin> bbiab
141 2012-07-09 12:05:52 <Anduck> hi
142 2012-07-09 12:06:03 <helo> if there was ever a client listed on bitcoin.org that contained a backdoor or something, it would essentially validate all of the claims that bitcoin security is unworkable
143 2012-07-09 12:06:04 <Anduck> how do i get network block count with bitcoind?
144 2012-07-09 12:07:11 <Anduck> getblockcount replies with loaded block count
145 2012-07-09 12:07:29 <Anduck> but how can i see the overall block count.. that how much i need to load
146 2012-07-09 12:07:42 <sipa> it's not exposed, and it is a guess only
147 2012-07-09 12:07:47 <sipa> based on what other nodes say
148 2012-07-09 12:07:55 <Anduck> how can i see wut other nodes say?
149 2012-07-09 12:08:05 <Anduck> how does bitcoin-qt know whats the block count in network?
150 2012-07-09 12:08:33 <sipa> during the protocol negotiation, both sides send a "version" message, with their current number of blocks
151 2012-07-09 12:08:38 <sipa> (among other things)
152 2012-07-09 12:08:56 <sipa> bitcoin-qt uses the median of these reports as a guess for the actual number of blocks
153 2012-07-09 12:09:04 <Anduck> is there a way to read it with bitcoind
154 2012-07-09 12:09:08 <sipa> no
155 2012-07-09 12:09:31 <Anduck> =(
156 2012-07-09 12:09:46 <sipa> you shouldn't depend on it, except for a progressbar or something for end-users, imho
157 2012-07-09 12:11:14 <Anduck> thats what i am looking for
158 2012-07-09 12:11:18 <Anduck> but its not that important.
159 2012-07-09 12:11:30 <sipa> 0.7.0 will have a getpeerinfo
160 2012-07-09 12:11:46 <sipa> and that will report for each connected peer its claimed number of blocks
161 2012-07-09 12:11:59 <sipa> (at connection time, which may be outdated by the time you request it)
162 2012-07-09 12:12:41 <Anduck> yea
163 2012-07-09 12:12:48 <Anduck> well, thx for answering
164 2012-07-09 12:12:50 <gavinandresen> gmaxwell: I don't think you're crazy to insist on open source for the clients page.  And I tend to agree that a clients page will just turn into a big arm-wrestling mess
165 2012-07-09 12:14:49 <gmaxwell> I reverted the recent changes and threw up some critiera. We'll see where it goes.  My instinct when the page was created was that it was going to be more trouble than it was worth, I would have been glad to be wrong on that one.
166 2012-07-09 12:16:31 <sipa> i was wondering about a future mode of operation, where 4 different best-block pointers are kept instead of 1
167 2012-07-09 12:17:20 <sipa> 1) latest/best header downloaded connected to the block tree, and not known to be invalid
168 2012-07-09 12:17:35 <sipa> 2) latest/best block downloaded, not known to be invalid
169 2012-07-09 12:17:58 <sipa> 3) current state of the block index (having ConnectBlock() applied)
170 2012-07-09 12:18:14 <sipa> 4) point up to which signatures are verified
171 2012-07-09 12:18:52 <sipa> all 4 can essentially be separate processes (with 4 even being multi-threaded)
172 2012-07-09 12:19:39 <gmaxwell> sipa: so one issue(?) with ultraprune's current data structures is that I think it's pretty vulnerable to corruption, esp corruption from non-atomic updates on power failure.  Maintaining multiple heads might help with that, because you could have a lagging head which you switch to.
173 2012-07-09 12:20:01 <sipa> and you could choose to stop before the last step (eg stop at 1 if you only need to know the current best, and trust highest mining power), stop at 2 if you only want to be an archive, ...
174 2012-07-09 12:20:37 <sipa> gmaxwell: well, the (recent) blocks are still available and there certainly are some consistency checks possible
175 2012-07-09 12:20:43 <sipa> (though indeed less than before)
176 2012-07-09 12:21:21 <gmaxwell> sipa: right, but for example if you manage to get the txout updates to disk, but not the undo logs.
177 2012-07-09 12:22:29 <sipa> good point
178 2012-07-09 12:22:51 <sipa> it'd be nice if there was a cheap way to retain snapshots of earlier coin db's
179 2012-07-09 12:24:40 <sipa> gmaxwell: at least code-wise, undo logs are written before any permanent db modifications are done
180 2012-07-09 12:24:53 <sipa> but corruption is always possible of course
181 2012-07-09 12:25:34 <gmaxwell> right, but no guarentee the system hasn't done something stupid under you. Especially if you're not fsyncing().
182 2012-07-09 12:25:58 <sipa> that said, if an undo log is unavailable (or corrupted, there are some consistency checks), failure will occur when disconnecting a block
183 2012-07-09 12:26:13 <sipa> and the last db modification made is updating the best block pointer
184 2012-07-09 12:26:37 <sipa> so if everything succeeds except that, it will fail before of a BIP30 violation when reconnecting the partially-connected block
185 2012-07-09 12:27:42 <sipa> but it's probably good to try to reason what effects a randomly corrupted database would have
186 2012-07-09 12:30:56 <gmaxwell> sipa: IIRC someone had a special block device that basically acted as a log of FS block updates, so you could basically simulate a power outage plus block tear at every point along the operation if you wanted to.
187 2012-07-09 12:31:36 <sipa> gmaxwell: LLVM has snapshots
188 2012-07-09 12:31:57 <BlueMatt> gmaxwell: no, I agree that linking to proprietary clients is not a good idea unless you hold half of the key necessary to spend all your coins in a floss one
189 2012-07-09 12:32:08 <BlueMatt> gmaxwell: why it was added to that page without discussion and without a pull request, I dont know
190 2012-07-09 12:33:17 <sipa> gmaxwell: that said, undo log files need an fdatasync() or equivalent, indeed
191 2012-07-09 12:35:10 <gmaxwell> BlueMatt: the flip side of pull requests is that we also need to be diligent in processing them.. the addition of the bitcoin mag pull has been sitting around for a while.
192 2012-07-09 12:35:34 <gmaxwell> (I haven't commented on it because I've yet to see the publication, at least Matthew is saying all the right stuff)
193 2012-07-09 12:35:40 <BlueMatt> I was under the impression the addition of bitcoin mag pull was going to wait for a few issues and more verification before pulling
194 2012-07-09 12:36:02 <BlueMatt> or, that was the sense I got from you, and afair you are the only one who had any opinion when it was brought up here
195 2012-07-09 12:37:12 <gmaxwell> Well I just don't have an opinion because I haven't seen it. I was hoping people who'd seen it would pipe up.
196 2012-07-09 12:38:05 <BlueMatt> anyway, the bitcoin.org pulls tend to get processed pretty quickly (rarely wait longer than a week for anything that would need discussion) so I dont think thats a huge issue for the website
197 2012-07-09 12:42:09 <BlueMatt> sipa: how do you currently handle smaller-work-than-head forks when you get them in ultraprune?
198 2012-07-09 12:42:16 <BlueMatt> in terms of tx connection, that is
199 2012-07-09 12:44:27 <gmaxwell> My ultraprune callgrind is up to height=186245  (I started it when sipa asked about profiling again. 0_o )
200 2012-07-09 12:53:21 <gavinandresen> BlueMatt: Last URI pull is causing a QT build error on my Mac:  /opt/local/include/boost/interprocess/ipc/message_queue.hpp:339: error: no matching function for call to get_rounded_size(long unsigned int, const unsigned int&)
201 2012-07-09 12:53:41 <sipa> BlueMatt: hmm?
202 2012-07-09 12:54:04 <gavinandresen> BlueMatt: remind me what's up with URI support on the Mac?  Can I just put back in the #ifdefs so that code isn't called on the Mac?
203 2012-07-09 12:54:25 <BlueMatt> gavinandresen: yep, its currently never called, so ifdefing it out should work no problem
204 2012-07-09 12:54:33 <sipa> BlueMatt: nothing changed in block downloading, only in block connection (making them part of the best chain)
205 2012-07-09 12:56:07 <sipa> gmaxwell: so it took a day to callgrind up to that point...?
206 2012-07-09 12:56:24 <BlueMatt> sipa: does ultraprune store full blocks for undo, or just a list of tx outs created/destroyed?
207 2012-07-09 12:56:47 <sipa> BlueMatt: it stores blocks, and an additional undo file
208 2012-07-09 12:57:15 <sipa> the undo file just contains a list of amount/height/scriptpubkey of txouts destroyed
209 2012-07-09 12:57:33 <BlueMatt> wait...what? It thought it stored only set of txouts unspent, never full blocks, except for undo stuff
210 2012-07-09 12:57:40 <sipa> yes
211 2012-07-09 12:57:43 <sipa> exactly
212 2012-07-09 12:57:48 <sipa> ah
213 2012-07-09 12:58:26 <sipa> no, it has full blocks available for reorg/rescan/serving
214 2012-07-09 12:58:39 <sipa> but it does not require *all* full blocks to be available
215 2012-07-09 12:58:49 <BlueMatt> so undo file == full block?
216 2012-07-09 12:58:53 <sipa> no
217 2012-07-09 12:59:00 <sipa> the undo files are separate files
218 2012-07-09 12:59:12 <sipa> to undo, you need the block + undo file
219 2012-07-09 12:59:18 <BlueMatt> oh...
220 2012-07-09 12:59:26 <sipa> you could create a larger undo file that does not need the block itself
221 2012-07-09 12:59:39 <BlueMatt> could you not use the info in the block to not use the undo file?
222 2012-07-09 12:59:57 <sipa> ?
223 2012-07-09 13:00:02 <sipa> the block itself does not know the txouts that were consumed
224 2012-07-09 13:00:12 <sipa> only the outpoints
225 2012-07-09 13:00:23 <BlueMatt> the list of txins is the list of txouts consumed, or?
226 2012-07-09 13:00:49 <sipa> yes, but you need the actual amounts and scripts (and for coinbases, heights) of the consumed txouts
227 2012-07-09 13:00:53 <sipa> in order to restore the coin db
228 2012-07-09 13:01:08 <BlueMatt> ah, yea, yea
229 2012-07-09 13:01:24 <BlueMatt> sipa: in case you missed it, last night I finished getting bitcoinj to implement ultraprune, so I was asking to see if you did it differently
230 2012-07-09 13:01:33 <sipa> i noticed :)
231 2012-07-09 13:02:21 <sipa> make sure you keep all necessary information around, should you ever want to consider full block validation
232 2012-07-09 13:02:38 <BlueMatt> yea, Im working on full block validation now
233 2012-07-09 13:03:15 <sipa> for each tx, you need txid -> (bitmask of available txouts, amounts/scripts for available txouts, coinbase yes/no, height)
234 2012-07-09 13:03:27 <sipa> height is only really necessary if it's a coinbase
235 2012-07-09 13:03:42 <BlueMatt> the way I have it now: storage of full blocks is /either/ the full set of txouts spent/created or the full set of txes, where the full set of txes is stored is only used in case you get a fork'd block that we dont bother connecting yet...and also all block headers
236 2012-07-09 13:03:50 <BlueMatt> so Ive got all of that
237 2012-07-09 13:04:06 <BlueMatt> though I dont do it by txid, I index by txid:index
238 2012-07-09 13:04:30 <sipa> currently, txids are almost 40% of the storage
239 2012-07-09 13:04:45 <sipa> so it's worthwhile trying to minimize duplicating them :)
240 2012-07-09 13:05:21 <BlueMatt> yea...the current implementation isnt hugely efficient in storage space, Im gonna work on that after I actually write a disk-backed implementation of the db...
241 2012-07-09 13:05:52 <BlueMatt> that said, thanks to java's wonderfully aweful all-objects-are-essentially-pointers "feature" I dont double-store any hashes
242 2012-07-09 13:06:04 <BlueMatt> in memory, that is
243 2012-07-09 13:07:50 <sipa> BlueMatt: just keeping the serialized coins (which are compact and per-tx) in a txid-to-coins std::map, costs around 300 MB
244 2012-07-09 13:08:01 <sipa> in Java i guess it will be even more
245 2012-07-09 13:08:43 <BlueMatt> I have to admit I have yet to actually import the full chain, Ive only been using the unit tests already in bitcoinj and adding more specific testing
246 2012-07-09 13:10:25 <sipa> iirc i experiemented with self-contained undo files, but those were around 30% of the block's size, instead of 12%
247 2012-07-09 13:11:20 <sipa> and as you need the actual blocks anyway to do a full disconnect including moving disconnected transactions to the memory pool, i figured it was better not to duplicate that 20%
248 2012-07-09 13:12:27 <BlueMatt> yea...putting disconnected txs back into mempool is the only issue, otherwise not storing the full txes is nice
249 2012-07-09 13:14:32 <sipa> next i'm going to implement a memory-backend for coindb, to see how fast we can get without any DB management at all
250 2012-07-09 13:14:44 <sipa> and also to be able to calculate merkle-root hashes of the coindb
251 2012-07-09 13:15:12 <sipa> if those can be compared to coindb's extracted from pre-ultraprune code, we have an excellent test :)
252 2012-07-09 13:38:08 <gmaxwell> sipa: https://people.xiph.org/~greg/ultraprune_profile2.png Looks much nicer now. Most cycles appear to be spent on sha256 and ecdsa.
253 2012-07-09 13:39:23 <gmaxwell> looks like it's losing something vaguely like 15% on copies and heap twiddling
254 2012-07-09 13:58:23 <gmaxwell> :-/ And now Amir commited a change to make the client order display 'random' (per run of jekyll, not per load) so now the reference client won't be listed first most of the time.
255 2012-07-09 13:59:01 <gmaxwell> (and isn't now)
256 2012-07-09 14:06:03 <BlueMatt> hey TD
257 2012-07-09 14:06:49 <TD> hey. just saw your message. very cool! in a meeting right now
258 2012-07-09 14:06:52 <TD> available to talk in 20-30 mins
259 2012-07-09 14:07:50 <TD> btw, if you're bored, see my post in the dev forum
260 2012-07-09 15:36:26 <Diablo-D3> hey guys
261 2012-07-09 15:36:28 <Diablo-D3> who runs devcoin?
262 2012-07-09 15:37:56 <luke-jr> I think coblee runs that too
263 2012-07-09 15:38:50 <Diablo-D3> I know you do
264 2012-07-09 16:51:34 <Venomm> just donated a bunch of money to a super cool and secret bitcoin project
265 2012-07-09 16:51:46 <Venomm> help me replace the money by donating as much btc as possible to the following address
266 2012-07-09 16:51:47 <Venomm> 1G6Fp2oEDWdnRmLBRm32AuES9VYudE2ZLd
267 2012-07-09 16:52:03 <luke-jr> &
268 2012-07-09 16:52:15 <BlueMatt> wow...because that is going to work
269 2012-07-09 16:52:34 <TD> lol
270 2012-07-09 16:52:39 <lianj> give me a testnet address..
271 2012-07-09 16:52:49 <luke-jr> I did that too, but the super cool and secret project I donated to is far more super cool and secret. Reimburse me at 3P14159f73E4gFr7JterCCQh9QjiTjiZrG
272 2012-07-09 16:52:50 <luke-jr> :P
273 2012-07-09 16:53:15 <gmaxwell> I actually donated money to the set of all possible super cool and secret projects &
274 2012-07-09 16:53:25 <Diablo-D3> I invested a bunch of money in DMC. It is hyper cool, but not secret. Give me your money.
275 2012-07-09 16:53:37 <gmaxwell> Diablo-D3: You could have just used the last sentence there.
276 2012-07-09 16:53:40 <luke-jr> I invested money in DMC before Diablo-D3!
277 2012-07-09 16:53:45 <luke-jr> gmaxwell: LOL
278 2012-07-09 16:53:49 <Diablo-D3> luke-jr: ... .....
279 2012-07-09 16:53:50 <moartr4dez> that's so super cool that I'll donate to you in a secret way that you can't even tell how I did it or if I did.
280 2012-07-09 16:53:55 <Diablo-D3> luke-jr: goddamn you.
281 2012-07-09 16:54:06 <Diablo-D3> moartr4dez: but what if I open the box?
282 2012-07-09 16:54:14 <gmaxwell> luke-jr: ha! well I invested in Diablo-D3 directly!
283 2012-07-09 16:54:22 <luke-jr> gmaxwell: do you own him then?
284 2012-07-09 16:54:33 <gmaxwell> Hmm. Interesting question.
285 2012-07-09 16:54:43 <gmaxwell> Diablo-D3: **FETCH**
286 2012-07-09 16:54:59 <Diablo-D3> Aint happening.
287 2012-07-09 16:55:02 <gmaxwell> Hmph.
288 2012-07-09 16:55:13 <gmaxwell> Apparently not.
289 2012-07-09 16:55:16 <Diablo-D3> I paud off my debt to the community over two weeks of 8 hour a day hard work.
290 2012-07-09 16:55:19 <luke-jr> gmaxwell: is it legal to beat disobedient slaves where you live?
291 2012-07-09 16:55:28 <gmaxwell> I am in Virginia, so probably.
292 2012-07-09 16:55:31 <Diablo-D3> The worlds best GCN kernel.
293 2012-07-09 16:55:32 <Diablo-D3> Bam.
294 2012-07-09 16:55:51 <gmaxwell> luke-jr: Man, does everything you touch turn controversial?  Can we somehow bottle this power and put it on sale?
295 2012-07-09 16:55:52 <luke-jr> Diablo-D3: didn't Con's from-scratch kernel do just as well?
296 2012-07-09 16:56:07 <luke-jr> gmaxwell: what this time?
297 2012-07-09 16:56:14 <gmaxwell> luke-jr: just reflecting on the clients page.
298 2012-07-09 16:56:21 <Diablo-D3> luke-jr: nope
299 2012-07-09 16:56:30 <luke-jr> gmaxwell: hey, if it was merged the way I did it, it wouldn't be controversial!
300 2012-07-09 16:56:32 <luke-jr> ;)
301 2012-07-09 17:01:48 <TD> gmaxwell: lol
302 2012-07-09 17:01:57 <TD> bottled controversy
303 2012-07-09 17:01:58 <TD> it sounds useful
304 2012-07-09 17:02:34 <gmaxwell> I expect the TV news anchors would be a major buyer of it.
305 2012-07-09 17:02:54 <TD> i think they have enough already
306 2012-07-09 17:02:58 <luke-jr> hmm
307 2012-07-09 17:03:13 <luke-jr> I may need to rethink how I present a summary of work done to some clients
308 2012-07-09 17:03:20 <BlueMatt> hey, wanna take the heat off, just sprinkle some controversy elsewhere, yay!
309 2012-07-09 17:03:24 <luke-jr> "You were fighting Zombies<<G?"
310 2012-07-09 17:03:47 <gmaxwell> "Today mathematicians announced a new theorm about the carnality of the set of primes <opens bottle> OMG MAYBE THE PRIMES AREN'T INFINITE AND WE'RE GOING TO RUN OUT OF THEM!"
311 2012-07-09 17:04:20 <BlueMatt> we need to stop using up so many primes, we should put a limit on individual prime usage
312 2012-07-09 17:04:44 <Diablo-D3> well thats just prime
313 2012-07-09 17:07:13 <gmaxwell> http://www.smbc-comics.com/index.php?db=comics&id=2595
314 2012-07-09 17:08:18 <OneEyed> We can launch a contest to find the biggest prime, anybody can submit an entry, price to submit is 1 BTC, first people to submit a divisor gets .5 BTC, the other .5 BTC enters a jackpot, if no divisor is found in one week for a prime, submitter gets 50% of the current jackpot, so that other big numbers get a chance too
315 2012-07-09 17:08:28 <OneEyed> (sorry, thinking aloud)
316 2012-07-09 17:08:45 <gmaxwell> OneEyed: I'd rather have a more useful contest.
317 2012-07-09 17:11:59 <OneEyed> luke-jr: what was it?
318 2012-07-09 17:12:02 <gmaxwell> FWIW, the reason etotheipi hasn't been around is because of IRC being a time sink.
319 2012-07-09 17:13:14 <ThomasV> gmaxwell: oh. let's all leave irc asap!
320 2012-07-09 17:13:58 <gmaxwell> :) ... well it's true. But I _wish_ IRC were the worst of my problems.
321 2012-07-09 17:14:34 <luke-jr> OneEyed: https://bitcointalk.org/?topic=90362
322 2012-07-09 17:14:42 <ThomasV> so what's going to happen with the 'clients' page?
323 2012-07-09 17:14:52 <luke-jr> looks like it's up to 2.25 BTC reward
324 2012-07-09 17:16:31 <gmaxwell> ThomasV: I see consensus forming around having it not be random, and being a little more conservative in what gets added.
325 2012-07-09 17:17:13 <gmaxwell> but we'll see what happens when more people get a chance to comment on the thread.
326 2012-07-09 17:17:38 <luke-jr> oh wait
327 2012-07-09 17:17:41 <luke-jr> someone did redeem it
328 2012-07-09 17:22:57 <sipa> gmaxwell: that callgrind is done with bdb on a tmpfs?
329 2012-07-09 17:25:01 <sipa> not on a computer now, i'll have a look at the graph later
330 2012-07-09 17:25:22 <sipa> but i suppose some percentage of time is still spent inside bdb too
331 2012-07-09 17:28:56 <gmaxwell> sipa: Right callgrind is going to assume that all the syscalls take one cycle though.
332 2012-07-09 17:30:07 <sipa> ah, i see
333 2012-07-09 17:39:50 <gmaxwell> sipa: the callgrind stuff works by doing the data collection from the valgrind VM. So in some ways it less intrusive e.g. than gperf profiling. But the valgrind cpu emulation's ideas of instruction times, branch prediction, etc. are not especially accurate. Six one way - Half a dozen another.
334 2012-07-09 17:40:24 <gmaxwell> The kcachegrind tool for visulaizing the profiles is quite good though, which makes it worth using even if gprof or oprofile style data collection would be better.
335 2012-07-09 17:42:17 <Diablo-D3> I never could get gperf to work right
336 2012-07-09 17:42:27 <Diablo-D3> it just ignores new threads
337 2012-07-09 18:45:04 <gribble> New news from bitcoinrss: Diapolo opened issue 1573 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1573>
338 2012-07-09 18:47:04 <TD> BlueMatt: by the way, my copy of bitcoin magazine finally arrived
339 2012-07-09 18:47:05 <TD> it's pretty good
340 2012-07-09 18:47:09 <TD> judging from the contents page, at least :)
341 2012-07-09 18:47:50 <BlueMatt> nice
342 2012-07-09 18:53:24 <gmaxwell> TD: no classified ads for third world sexslaves or anything embarassing like that?
343 2012-07-09 18:53:39 <TD> didn't see any yet
344 2012-07-09 19:20:17 <TD> the main issue is it needs more writers
345 2012-07-09 19:20:26 <TD> i'm on page 25 and so far all the articles are written by the same guy
346 2012-07-09 19:20:30 <TD> who is a good writer, mind you
347 2012-07-09 19:20:37 <TD> but even so. i'm sure this will come with time
348 2012-07-09 19:21:07 <TD> also, it has an article on "bitcoin successes and failures", where bitcoinica is listed as a success. lol.
349 2012-07-09 19:22:33 <justmoon> TD: there are quite a few more writers in the next issue I'm pretty sure
350 2012-07-09 19:22:54 <justmoon> I contributed a short story - not sure if it'll make it in ^^
351 2012-07-09 19:24:32 <TD> yeah
352 2012-07-09 19:24:49 <TD> they interviewed me. i think it'll be a while though. deadline for ads is tomorrow so it can't go to press until at least a week or two from then, i guess
353 2012-07-09 19:24:54 <TD> justmoon: btw what is helpcoin?
354 2012-07-09 19:28:05 <justmoon> TD: jon wanted to start an agency for brokering bitcoin consulting engagements and he asked me if I would take consulting jobs if he sent them my way
355 2012-07-09 19:28:33 <justmoon> he since started doing the email support for weusecoins which several hours per day worth of work
356 2012-07-09 19:28:45 <justmoon> so he gets a link on wuc in exchange for his efforts
357 2012-07-09 19:28:57 <justmoon> the link is now to coinabul though, I think helpcoin is defunc
358 2012-07-09 19:29:00 <justmoon> defunct*
359 2012-07-09 19:29:59 <TD> ok
360 2012-07-09 19:43:49 <BlueMatt> TD: do you happen to know of any import-bitcoind-style-blk0001.dat-files bitcoinj clients?
361 2012-07-09 19:44:26 <TD> none that read the block file. but you can just connect your client to localhost and have it download the chain in the usual manner. reading the file off disk might be slightly faster, but not by a huge amount
362 2012-07-09 19:44:52 <BlueMatt> meh, alright
363 2012-07-09 19:48:11 <TD> BlueMatt: btw make sure to disable fast catchup
364 2012-07-09 19:48:14 <TD> otherwise it'll just do a getheaders
365 2012-07-09 19:48:54 <BlueMatt> yep...also need to spend some time with PeerGroups to make that more useable with full blockchain...
366 2012-07-09 19:51:06 <TD> probably there will be a lot of changes for what you want to do
367 2012-07-09 19:51:29 <TD> by the way, what is your end goal with this work?
368 2012-07-09 19:51:43 <TD> SPV clients that can upgrade to pruning full nodes if they have sufficient resources?
369 2012-07-09 19:51:55 <BlueMatt> yep
370 2012-07-09 19:52:03 <BlueMatt> its about time we get a second full pruning codebase on the network
371 2012-07-09 19:52:07 <BlueMatt> s/pruning//
372 2012-07-09 19:52:25 <BlueMatt> maybe even mining, but thats a long way off and needs way more testing
373 2012-07-09 19:55:26 <justmoon> BitcoinJS is a full codebase that supports mining - Trucoin ran (runs?) a private testnet which consisted of mining BitcoinJS nodes entirely
374 2012-07-09 19:55:46 <justmoon> to mine on the main network it would need better tx prioritization and DoS protection code
375 2012-07-09 19:55:53 <justmoon> but otherwise it'd be set to go
376 2012-07-09 19:56:11 <BlueMatt> oh...didnt realize bitcoinjs had full verification
377 2012-07-09 19:56:20 <BlueMatt> in any case, more full codebases is always much better
378 2012-07-09 19:56:38 <justmoon> weren't you there about a year ago when I excitedly announced that I implemented the whole script interpreter? :P
379 2012-07-09 19:57:04 <BlueMatt> must've missed it...
380 2012-07-09 19:57:47 <justmoon> http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/07/09
381 2012-07-09 19:58:07 <Cory> Does anybody want to make it so when a new address is created it is automatically selected in the list of addresses? :P
382 2012-07-09 19:58:07 <justmoon> it was actually one year to the day lol and you congratulated me:
383 2012-07-09 19:58:11 <justmoon> BlueMatt
384 2012-07-09 19:58:14 <justmoon> :D
385 2012-07-09 19:58:16 <justmoon> <3
386 2012-07-09 19:58:26 <BlueMatt> heh...sorry
387 2012-07-09 19:58:35 <justmoon> no worries
388 2012-07-09 19:58:54 <TD> heh
389 2012-07-09 19:58:58 <BlueMatt> justmoon: whats the storage backend like?
390 2012-07-09 19:59:00 <TD> yeah bitcoinjs is probably more complete
391 2012-07-09 19:59:06 <justmoon> it's leveldb based
392 2012-07-09 19:59:13 <BlueMatt> full blocks?
393 2012-07-09 19:59:18 <justmoon> of course
394 2012-07-09 19:59:20 <TD> though, honestly, i don't trust any reimplementation of the full algorithm yet
395 2012-07-09 19:59:28 <TD> there are way too many subtle edge cases in satoshis code
396 2012-07-09 19:59:33 <justmoon> TD: for sure
397 2012-07-09 19:59:37 <TD> i wouldn't trust bitcoinj to mine unless the test suite was 10x larger than now
398 2012-07-09 19:59:50 <gmaxwell> TD: as you shouldn't... the reference one isn't trustworthy but at least all-bugs-are-features saves it. :)
399 2012-07-09 19:59:55 <TD> haha :)
400 2012-07-09 19:59:57 <TD> right
401 2012-07-09 20:00:03 <justmoon> ^^
402 2012-07-09 20:00:24 <justmoon> also the fact that it has the most developers by far helps
403 2012-07-09 20:00:36 <TD> the general direction i see for bitcoinj is for end-user thin clients, and as an API that people use to build apps that they connect to a local satoshi client. that way you get the security of a known-good local node, but the nice(ish) api
404 2012-07-09 20:00:50 <TD> though the bitcoinj api is still pretty warty. the result of development that is 100% focused on moble ux
405 2012-07-09 20:00:54 <TD> *mobile
406 2012-07-09 20:01:32 <gmaxwell> This was one reason I was excited about roconnor going towards as CoQ validator... because I hoped there would be some crazy functional extraction that could automatically generate test cases for every rule... then see if bitcoind and the coq implementation agreed.
407 2012-07-09 20:02:00 <TD> coq _is_ crazy. i remember looking at it very briefly a long time ago
408 2012-07-09 20:02:09 <TD> my conclusion was you can't prove the correctness of any interesting program
409 2012-07-09 20:02:13 <TD> at least not with that
410 2012-07-09 20:02:19 <gmaxwell> TD: Your conclusion was incorrect!
411 2012-07-09 20:02:29 <Diablo-D3> coq?
412 2012-07-09 20:02:33 <BlueMatt> http://en.wikipedia.org/wiki/Coq
413 2012-07-09 20:02:33 <gmaxwell> (considering there are now validated C compilers (e.g. compcert!))
414 2012-07-09 20:02:38 <TD> i suppose i can just redefine "interesting" to be more and more complicated until i'm right :)
415 2012-07-09 20:02:41 <TD> ah, there are?
416 2012-07-09 20:02:43 <TD> ok.
417 2012-07-09 20:02:47 <Diablo-D3> am I supposed to pronounce this cock or cog?
418 2012-07-09 20:02:49 <gmaxwell> Yea, surprised me too.
419 2012-07-09 20:02:49 <TD> well, a compiler is still just a gigantic pure function
420 2012-07-09 20:02:52 <TD> but even so
421 2012-07-09 20:02:55 <TD> not bad!
422 2012-07-09 20:03:07 <gmaxwell> TD: so is block validation though. If you define the parameters right. :)
423 2012-07-09 20:03:14 <Diablo-D3> gmaxwell: huh, thats interesting?
424 2012-07-09 20:03:39 <luke-jr> gmaxwell: bitcoind doesn't necessarily have "all-bugs-are-features" ;)
425 2012-07-09 20:03:49 <gmaxwell> In theory something like KLEE should be able to generate test vectors that hit all the rules. But in practice there is just far too much stuff in bitcoin block messages that doesn't do anything interesting. :(
426 2012-07-09 20:03:49 <luke-jr> gmaxwell: if all miners switched to BitcoinJS, it would ;)
427 2012-07-09 20:04:21 <luke-jr> assuming MtGox's client agreed with BJS
428 2012-07-09 20:04:33 <TD> i hadn't seen klee
429 2012-07-09 20:04:35 <gmaxwell> luke-jr: I mean that there can be many bugs that we'd not notice because the only widespread full validator is bitcoind. The bug would be just an unobservable 'feature' right now.
430 2012-07-09 20:04:35 <TD> that's interesting
431 2012-07-09 20:05:03 <gmaxwell> I've used it successfully on software simpler than bitcoin (entropy coders) to quickly build 100% branch coverage test vectors.
432 2012-07-09 20:05:11 <luke-jr> gmaxwell: and I mean if the majority of miners and exchanges disagreed, bitcoind would probably have to adapt ;)
433 2012-07-09 20:06:01 <luke-jr> (assuming it was really a bug in bitcoind and not an exploit in the miners/exchanges)
434 2012-07-09 20:06:17 <gmaxwell> luke-jr: I expect in the future when there are multiple validators you'd run all popular ones.. and not extend blocks that don't pass all of them.  "The longest least common denominator chain"
435 2012-07-09 20:06:45 <luke-jr> gmaxwell: makes sense
436 2012-07-09 20:07:05 <TD> justmoon: bitcoinjs got a lot bigger since i last saw it!
437 2012-07-09 20:07:13 <TD> justmoon: but what's your eventual goal for it?
438 2012-07-09 20:07:32 <gmaxwell> luke-jr: it would make exploits at the blockchain level very hard.
439 2012-07-09 20:07:38 <SteveBell> bitcoin client 0.6.3 crashing on mac on startup...
440 2012-07-09 20:07:41 <SteveBell> is this known?
441 2012-07-09 20:07:53 <BlueMatt> SteveBell: whats the error?
442 2012-07-09 20:07:55 <BlueMatt> or none?
443 2012-07-09 20:08:14 <SteveBell> nothing so far. let me fire up console.app
444 2012-07-09 20:08:23 <justmoon> TD: well, it's been enough time with absolutely zero adaptation that it's time to consider that there might not be a demand for it
445 2012-07-09 20:08:51 <luke-jr> justmoon: do you have a BIP22 implementation using it?
446 2012-07-09 20:08:56 <justmoon> TD: even if I fixed the remaining bugs and implemented the remaining missing features, the advantages over bitcoind would be slim
447 2012-07-09 20:09:03 <TD> mm
448 2012-07-09 20:09:27 <SteveBell> I just see the loading blockindex wallet image and app becomes unresponsive...
449 2012-07-09 20:09:37 <SteveBell> no error msgs in console
450 2012-07-09 20:09:41 <luke-jr> SteveBell: debug.log?
451 2012-07-09 20:09:53 <SteveBell> where'd I find that?
452 2012-07-09 20:10:04 <luke-jr> where wallet.dat is
453 2012-07-09 20:10:05 <BlueMatt> justmoon: does it have support for multisig?
454 2012-07-09 20:10:21 <BlueMatt> justmoon: if you made a web-wallet software with support for multisig, i think gavin might love you
455 2012-07-09 20:10:26 <justmoon> luke-jr: no, it does have a memory pool and it does have the function to convert a tx to json, so it'd be reasonably easy to add I guess
456 2012-07-09 20:10:44 <gavinandresen> I already love justmoon
457 2012-07-09 20:10:51 <TD> justmoon: btw, did you see my post about distributed bond markets?
458 2012-07-09 20:10:59 <SteveBell> lol debug.log is 8.2MB
459 2012-07-09 20:11:04 <TD> justmoon: https://bitcointalk.org/index.php?topic=92421.0    seems like the kind of thing that's up your street
460 2012-07-09 20:11:12 <SteveBell> should I erase it and restart the app then send the log?
461 2012-07-09 20:11:26 <TD> no
462 2012-07-09 20:11:29 <TD> just look at the bottom
463 2012-07-09 20:11:30 <luke-jr> SteveBell: just pastebin the end ~50 lines
464 2012-07-09 20:11:35 <SteveBell> kk
465 2012-07-09 20:11:45 <gavinandresen> tail -50 works in console.app
466 2012-07-09 20:12:09 <justmoon> BlueMatt: ben contributed a tiny patch enabling the creation of multisig transactions in bitcoinjs-lib, but I haven't had a chance to implement multisig on the server yet :( - I kinda stopped developing for a bit and only recently picked it back up, adding testnet3 support
467 2012-07-09 20:12:49 <justmoon> BlueMatt: I thought BlockChain.info had some kind of feature for creating multisig transactions, but I could be wrong, talk to ben on that
468 2012-07-09 20:12:59 <justmoon> gavinandresen: <3
469 2012-07-09 20:13:28 <SteveBell> http://pastebin.com/5MrsfsyL
470 2012-07-09 20:13:31 <SteveBell> valid for 1h
471 2012-07-09 20:13:36 <justmoon> TD: will look at it thanks - guess we'll have plenty of time to discuss it next weekend
472 2012-07-09 20:13:41 <TD> yeah
473 2012-07-09 20:13:47 <[Tycho]> justmoon: he disabled it recently.
474 2012-07-09 20:13:55 <luke-jr> SteveBell: looks like it's working.
475 2012-07-09 20:13:57 <TD> it's got a bunch of stuff in it. i'm not sure it's all fully baked
476 2012-07-09 20:14:02 <TD> i propose a new SIGHASH flag for the next hard fork
477 2012-07-09 20:14:14 <luke-jr> SteveBell: ignore it being unresponsive?
478 2012-07-09 20:14:30 <luke-jr> TD: there's a wiki page of ideas for a hardfork
479 2012-07-09 20:14:42 <SteveBell> yes that's what I though. no error in sight. but when opening the force quit window I see bitcoin-qt (unresponsive) also nothing happens for several minutes when opening the client
480 2012-07-09 20:14:42 <TD> i should write up the sighash proposal in more detail. currently it's not well argued.
481 2012-07-09 20:14:50 <SteveBell> *thouht
482 2012-07-09 20:15:01 <SteveBell> *thought damn it!
483 2012-07-09 20:15:09 <BlueMatt> justmoon: hmm...well bitcoin-qt (or more ideally, android-wallet) needs a gui for multisig stuff, but if there were a webwallet with multisig, that would be awesome
484 2012-07-09 20:15:18 <SteveBell> ah ok, looks like it's just loading very slowly. opens finally after about 2-3 minutes
485 2012-07-09 20:15:20 <SteveBell> hmm.
486 2012-07-09 20:15:25 <SteveBell> now working fine
487 2012-07-09 20:15:27 <BlueMatt> (multisig as in sign a tx with webwallet+local client)
488 2012-07-09 20:15:39 <gavinandresen> SteveBell: glad we could help.
489 2012-07-09 20:15:58 <SteveBell> hehe, it#s appreciated. and thanks for your work!
490 2012-07-09 20:16:11 <TD> justmoon: andreas and I are thinking of maybe trying a CHECKMULTISIG based 2-factor coin extension at the berlin hackathon
491 2012-07-09 20:16:18 <gmaxwell> TD: the sighash flags are so frustrating. A considerable amount of thought was needed to see that they were needed, but then there are useful cases they don't cover. :-/
492 2012-07-09 20:16:31 <SteveBell> and if you ever have too much time on your hands URI support on mac would be <3
493 2012-07-09 20:16:35 <TD> it means upgrading multibit/bitcoin wallet/bitcoinj simultaneously, probably tied together with bluetooth
494 2012-07-09 20:16:45 <TD> not sure it's achievable in one weekend no matter how intense the hacking is
495 2012-07-09 20:16:52 <justmoon> BlueMatt: I was literally building the whole stack from my own leveldb Node.js binding to web-based GUI, it's too much, if you want GUI features, talk to Ben, he's the only person I know who is seriously working on it
496 2012-07-09 20:16:53 <TD> gmaxwell: yes. i know the feeling :)
497 2012-07-09 20:17:03 <TD> gmaxwell: i don't think i ever came up with a use case for SIGHASH_NONE, actually
498 2012-07-09 20:18:13 <gmaxwell> TD: It works with the NOPs to allow new network rules about how the outputs work.
499 2012-07-09 20:18:29 <TD> how so?
500 2012-07-09 20:18:34 <justmoon> TD: sounds cool - I guess I'm gonna hope there will be some kind of JavaScript developer other than myself there, I quite like the idea of writing a bookmarklet verifiable deployment, so that you can load a webbased client without installing anything and without trusting a server
501 2012-07-09 20:18:51 <gmaxwell> TD: right now there are no script conditional ways to adjust the outputs, you could do something with NOPs to have scripts adjust outputs and sighash_none to make the txn valid to old nodes.
502 2012-07-09 20:18:53 <TD> justmoon: hmm, neat, i guess. how would upgrades work?
503 2012-07-09 20:18:58 <gmaxwell> TD: or at least thats what _I_ thought it was for.
504 2012-07-09 20:19:05 <TD> gmaxwell: scripts adjust outputs?
505 2012-07-09 20:19:13 <TD> gmaxwell: you mean verify the form of a spending transaction
506 2012-07-09 20:19:14 <TD> ?
507 2012-07-09 20:19:46 <justmoon> basically the bookmarklet would contain a SHA256 implementation and a list of HTTP servers that host the client, it would download a string containing two loader stages
508 2012-07-09 20:19:58 <TD> hah, sha256 in a bookmark
509 2012-07-09 20:20:20 <justmoon> stage 1 contains a ECDSA implementation and a list of client developer keys, stage 2 would be the client itself signed by n-of-m of the developers
510 2012-07-09 20:20:36 <justmoon> stage 1's hash is in the bookmarklet
511 2012-07-09 20:20:39 <TD> gmaxwell: satoshi told me what it was for once
512 2012-07-09 20:20:43 <TD> gmaxwell: let me dig it out
513 2012-07-09 20:20:49 <TD> something to do with negotiations
514 2012-07-09 20:20:54 <BlueMatt> justmoon: now thats a crazy fancy awesome client
515 2012-07-09 20:20:57 <gmaxwell> TD: thats better than my guesses for sure!
516 2012-07-09 20:21:02 <TD> There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.".  If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.
517 2012-07-09 20:21:28 <justmoon> BlueMatt: using a bookmarklet wasn't my idea, I was wrecking my brain today trying to remember the guy's name... :( - he suggested it here on IRC I think
518 2012-07-09 20:21:59 <justmoon> it basically means no internet explorer, but it might be a pretty cool option for iphone
519 2012-07-09 20:22:21 <gmaxwell> TD: ah, I see.  "I've died and don't care anymore what will be done with these transactions for which I am a signing multiparty"
520 2012-07-09 20:22:23 <TD> justmoon: i read that opera on iphone can access the camera?
521 2012-07-09 20:22:37 <justmoon> (ie6 for example has a 600-ish character limit on bookmarklets, no sha256 implementation fits in that)
522 2012-07-09 20:22:47 <BlueMatt> justmoon: meh...so what?
523 2012-07-09 20:23:05 <justmoon> TD: yeah there is an HTML5 standard for camera access now, I assume all browsers will have it a couple versions down the road
524 2012-07-09 20:23:19 <justmoon> TD: but then I'll be waiting for an HTML5 NFC API :P
525 2012-07-09 20:24:04 <justmoon> the life of a web developer - waiting until the cool kids finally let you play with their toys in your (browser) sandbox
526 2012-07-09 20:24:22 <TD> gmaxwell: yeah it's for terminating negotiations that are taking place using nLockTimed multi-party transactions where each party can increment the sequence number independently. it means once you "bowed out" the others can continue to negotiate
527 2012-07-09 20:24:48 <TD> like i said, i never found a use case where that was needed though. he must have had one in mind
528 2012-07-09 20:25:24 <TD> he mentioned pushing unresponsive parties out using default fallback transactions prepared after each round of negotiation
529 2012-07-09 20:25:27 <TD> perhaps it's related to that
530 2012-07-09 20:26:27 <justmoon> ok, good night all - TD: I dissed you on the mailing list, enjoy :D
531 2012-07-09 20:26:28 <justmoon> bye
532 2012-07-09 20:26:32 <TD> hehe
533 2012-07-09 20:26:33 <TD> later :)
534 2012-07-09 20:53:21 <OneEyed> Funny fact: GLBSE takes more than 30 seconds to acknowledge a withdrawal request& which is more than the lifetime of the 2 factor key
535 2012-07-09 20:57:48 <Gamebak> hello guys is ther a way to keep acces to a wallet with php
536 2012-07-09 21:02:04 <[Tycho]> Hello, Gamebak
537 2012-07-09 21:02:46 <gege> Hi guys, is it just me or is socketio.mtgox.com down? If it is down, is this a common occurance?
538 2012-07-09 21:02:52 <Gamebak> i think i found what i was looking for
539 2012-07-09 21:02:53 <Gamebak> https://en.bitcoin.it/wiki/PHP_developer_intro
540 2012-07-09 21:03:06 <Gamebak> the password is always root:root ?
541 2012-07-09 21:06:47 <sipa> Gamebak: whatever you set username and password to
542 2012-07-09 21:06:59 <Gamebak> thanks
543 2012-07-09 22:33:32 <Elio19> How will i know if a transaction will exceed the size limit and require a fee?
544 2012-07-09 22:37:53 <luke-jr> Elio19: you won't.
545 2012-07-09 22:39:39 <Elio19> luke-jr, who would?
546 2012-07-09 22:40:08 <luke-jr> Elio19: no human
547 2012-07-09 22:40:33 <copumpkin> that is why you pay a pumpkin
548 2012-07-09 22:41:12 <gmaxwell> Elio19: the GUI will tell you when that happens and offer to let you pay a fee.
549 2012-07-09 22:41:33 <Elio19> gmaxwell, yes i noticed that.
550 2012-07-09 22:41:59 <Elio19> I would be happy to pay a pumpkin to tell me tho.
551 2012-07-09 22:42:05 <luke-jr> Elio19: I have a patch on GitHub that will let you set an upper limit to fees, but it won't be pulled until someone implements an "undo"
552 2012-07-09 22:42:32 <luke-jr> Elio19: also, most cases where someone wants to know a fee in advance are misguided for bitcoind
553 2012-07-09 22:43:05 <Elio19> luke-jr, regardless of my direction, what do you mean by an undo?
554 2012-07-09 22:43:31 <luke-jr> Elio19: the same patch allows you to bypass the fees, so undo is required if a transaction gets stuck
555 2012-07-09 22:43:52 <gmaxwell> luke-jr: I still liked my idea of being able to make a txn that isn't sent until the rules pass... and then have instant aborts for anything unset.
556 2012-07-09 22:43:56 <gmaxwell> er unsent.
557 2012-07-09 22:44:44 <gmaxwell> (the problem with sending being is that any undo on a sent tranasction needs to have a dead time so it doesn't end up getting dropped as a doublespend)
558 2012-07-09 22:45:46 <Elio19> So how does my bitcoin client determine that a fee is necessary?
559 2012-07-09 22:46:34 <gmaxwell> Elio19: because it has the rules that most of the other nodes use to decide if a transaction will be relayed embedded inside it.
560 2012-07-09 22:47:05 <gmaxwell> (these rules generally may it costly to DOS attack the bitcoin network, because they make people who rapidly respend coin pay fees)
561 2012-07-09 22:47:38 <Elio19> Thanks for the help guys