1 2012-07-16 00:38:58 <jgarzik> Narnia!
  2 2012-07-16 03:43:55 <midnightmagic> :-)
  3 2012-07-16 03:44:16 <luke-jr> he must be getting less busy :D
  4 2012-07-16 03:45:00 <MagicalTux> midnightmagic: things are getting down a bit (plus with what happened with bitcoinica I had to stop what I was doing for a bit and cleanup a few things)
  5 2012-07-16 03:47:49 <midnightmagic> MagicalTux: I'll assume by "down" you mean "slower" and not "depressing."
  6 2012-07-16 03:48:19 <MagicalTux> yep, "slower" sounds close
  7 2012-07-16 03:48:28 <MagicalTux> "depressing" is not far either
  8 2012-07-16 03:53:19 <midnightmagic> Sorry to hear that. Some of us do actually appreciate what you guys are doing, and are pretty realistic about the crazy uphill battles w/ the banks you're forced to endure.
  9 2012-07-16 03:54:11 <nanotube> and others would also, if they weren't such whiny children. :)
 10 2012-07-16 03:55:53 <midnightmagic> +1
 11 2012-07-16 04:10:45 <copumpkin> are reorgs permitted beyond 100 blocks back?
 12 2012-07-16 04:16:09 <luke-jr> copumpkin: there are no limits on reorgs besides what the community decides it won't tolerate (and forks to reverse)
 13 2012-07-16 04:16:43 <copumpkin> but the community right now is generally set on 100?
 14 2012-07-16 04:18:07 <luke-jr> it's never happened
 15 2012-07-16 04:18:21 <luke-jr> I presume tolerance would depend on how the reorg occurred
 16 2012-07-16 04:31:26 <midnightmagic> copumpkin: As far as I'm aware, a reorg can happen straight back to the last checkpoint.
 17 2012-07-16 04:31:56 <midnightmagic> copumpkin: gmaxwell has said in the past that a reorg on that scale would be pretty horrendous.
 18 2012-07-16 04:34:13 <copumpkin> just because of all the confusion in the process?
 19 2012-07-16 04:34:36 <gmaxwell> copumpkin: Yes, reorgs are permitted back past 100 blocks. If the system imposed such an insanely small limit anyone who could mine 200 blocks could turn bitcoin off.
 20 2012-07-16 04:35:04 <gmaxwell> (or really more likely 100 plus some more careful timing)
 21 2012-07-16 04:35:30 <copumpkin> I see
 22 2012-07-16 04:35:38 <midnightmagic> copumpkin: It would be a huge, nasty block storm. The high-bandwidth, high-capacity nodes would sort out first and begin working on another fork until all the blocks propagated everywhere, and there would probably be a bunch of forks as miners found other blocks on chains that were only partially updated (and then reorged again as new blocks came in out of order)
 23 2012-07-16 04:35:43 <midnightmagic> yikes
 24 2012-07-16 04:36:06 <copumpkin> someone needs to make a big-ass simulator :)
 25 2012-07-16 04:36:26 <midnightmagic> I think amiller is doing something academic along those lines..
 26 2012-07-16 04:36:34 <copumpkin> that'd be cool
 27 2012-07-16 04:36:41 <gmaxwell> midnightmagic: eh, 100 blocks wouldn't be some terribly problem to reorg onto, dunno what you're thinking there.
 28 2012-07-16 04:37:02 <copumpkin> anyway, I must sleep
 29 2012-07-16 04:37:03 <midnightmagic> gmaxwell: No, I'm talking back to the last checkpoint.
 30 2012-07-16 04:37:04 <copumpkin> thanks for the help!
 31 2012-07-16 04:37:16 <midnightmagic> or earlier, since not everyone has the same checkpoints..
 32 2012-07-16 04:38:47 <gmaxwell> In any case you can't have a "100 block limit" because I'd just cause half the network to hear mutually exclusive one 100 block forks, and then the network would be forever (until manual intervention at least) two networks. all it would take is mining a 100 block parallel fork and right when it gets to 100 long drop the last blocks on just so it only gets ahead on half the nodes (and then communications delays prevent it from going further)
 33 2012-07-16 04:38:51 <midnightmagic> Checkpoint @ 185333 for e.g. was only inserted in June 19. Before that was 168000, in my checkpoints.cpp anyway.
 34 2012-07-16 04:39:13 <gmaxwell> midnightmagic: sure for checkpoints, no go figure out the fuel costs to do that. :)
 35 2012-07-16 04:39:17 <gmaxwell> s/no/now/
 36 2012-07-16 04:39:26 <amiller> mm, delicious lower bounds
 37 2012-07-16 04:40:58 <midnightmagic> gmaxwell: why wouldn't the chains eventually converge? is there some limit as to what blocks bitcoind will askfor?
 38 2012-07-16 04:41:21 <midnightmagic> gmaxwell: or does your example require one of those mass-connection sybil attacks?
 39 2012-07-16 04:43:11 <gmaxwell> midnightmagic: no, it requires the 100 block maximum reorg limit that luke thinks should exist and had managed to cause copumpkin to think did exist.
 40 2012-07-16 04:43:52 <midnightmagic> it seems to me internally consistent blocks could be used just to exhaust bitcoind memory on most nodes. that would be attack enough, as I'm pretty sure ses.
 41 2012-07-16 04:43:57 <amiller> gmaxwell, you are requiring a network partition though, right?
 42 2012-07-16 04:43:59 <midnightmagic> stupid laptop..
 43 2012-07-16 04:44:13 <gmaxwell> amiller: no I'm requring finite communication speed.
 44 2012-07-16 04:44:27 <gmaxwell> midnightmagic: er, they're not kept in memory.
 45 2012-07-16 04:44:31 <midnightmagic> .. "as I'm pretty sure we don't do resource limitations bumpingnesses recovery so gracefully."
 46 2012-07-16 04:45:09 <midnightmagic> gmaxwell: ah.
 47 2012-07-16 04:46:39 <amiller> if you assume a finite communication radius, and that the attacker doesn't have a head start, then everyone who matters already agrees on the 100th block back
 48 2012-07-16 04:47:07 <amiller> they could mine to 200, but everyone would be past that by then
 49 2012-07-16 04:47:27 <gmaxwell> amiller: if there is an N block limit on reorgs and N doesn't require infeasable resources to create, an attacker can create insoluable partitions by causing some nodes to be on one fork or another easiest for new nodes, feed them the bad data first. But even on existing ones, you can do a race right where the fork would hit the maximum lenght and let communications delays prevent convergence.
 50 2012-07-16 04:48:28 <amiller> sorry, do you mean finite _known_ radius?
 51 2012-07-16 04:48:28 <gmaxwell> amiller: they only have to tie.
 52 2012-07-16 04:48:35 <amiller> like do we get to set the difficulty knowing that radius?
 53 2012-07-16 04:48:45 <gmaxwell> Irrelevant.
 54 2012-07-16 04:48:49 <amiller> not
 55 2012-07-16 04:49:09 <luke-jr> gmaxwell: I didn't say there should be a 100 block reorg limit; I said beyond that point should require user intervention :p
 56 2012-07-16 04:49:25 <midnightmagic> .. because they couldn't correct the 100th block so long as the 101th was found before everyone had already agreed n-100 was X instead of the old Y.
 57 2012-07-16 04:49:55 <amiller> it matters quite a bit if you get to set the parameters knowing that radius, if it's known it's called "synchronous" and if it's unknown it's called "partially synchronous"
 58 2012-07-16 04:50:23 <gmaxwell> amiller: I can tie the network. I create a near tying fork. when I get to the 100th height I hold it and also extend the main fork. I give half the nodes fork a's last block, half fork b's last block.
 59 2012-07-16 04:50:54 <midnightmagic> gmaxwell: that requires partitioning sybil network doesn't it?
 60 2012-07-16 04:50:58 <amiller> you can't tie the network with 49%
 61 2012-07-16 04:51:06 <gmaxwell> midnightmagic: No.
 62 2012-07-16 04:51:23 <midnightmagic> but how do you control which half gets a or b?
 63 2012-07-16 04:51:36 <amiller> not if the network is timely and the difficulty is set according to that radius
 64 2012-07-16 04:51:57 <amiller> the network zooms along at like 50.5% even when you include the delay
 65 2012-07-16 04:52:12 <amiller> because the difficulty is hard enough that mostly blocks get propagated before much effort is duplicated
 66 2012-07-16 04:52:17 <gmaxwell> midnightmagic: I don't
 67 2012-07-16 04:53:14 <midnightmagic> so this is a 66% attack? or are you creating a unity chain up to 100, then two blocks for 101.
 68 2012-07-16 04:53:35 <midnightmagic> ah, just two blocks at the end, nm
 69 2012-07-16 04:53:44 <gmaxwell> midnightmagic: I the latter. Or I let the network create the one of the last two but then timing is hard.
 70 2012-07-16 04:54:17 <gmaxwell> amiller: I'm not sure where we're failing to reach an understanding.
 71 2012-07-16 04:54:19 <midnightmagic> ah..  by "half" you just mean "some"
 72 2012-07-16 04:54:59 <gmaxwell> midnightmagic: not exactly half, of course, but a non-trivial partition. Which would never heal.
 73 2012-07-16 04:55:55 <gmaxwell> The algorithim just doesn't work safely with automatic locking if there is any potential for an attacker to cut that deep.
 74 2012-07-16 04:56:12 <midnightmagic> gmaxwell: You'd be assuming things about the nature of the connected-ness of your connections, or you're connecting to some large number of bitcoind?
 75 2012-07-16 04:56:53 <midnightmagic> anyway if user-intervention is required rather than there being a hard limit, then the discussion is kind of academic anyway isn't it?
 76 2012-07-16 04:57:37 <gmaxwell> midnightmagic: perhaps, it changes the failure modes at least.
 77 2012-07-16 05:00:40 <amiller> if you tell me the strength of your attacker (49% is ok), and a security parameter k, i can tell you X, a good maximum number of blocks to wait for so the attacker has only an e^-k shot at forking someone before the cutoff
 78 2012-07-16 05:01:25 <amiller> the number X doesn't depend on the radius, but i'll need to know the radius to set the difficulty correctly
 79 2012-07-16 05:04:04 <gmaxwell> amiller: Yes, sure you can pick parameters so that he's unlikely to get ahead, but the point I'm maing is that  consequences of a reorg under that model are entirely different.
 80 2012-07-16 05:04:40 <gmaxwell> Instead of just being able to undo his own transactions he can cause the network to form an unresolvable partition.
 81 2012-07-16 05:05:05 <amiller> but only with low probability...
 82 2012-07-16 05:05:59 <amiller> it's not because he can't get ahead, but because he reaches the finish line in last place
 83 2012-07-16 05:08:42 <gmaxwell> No, not with low probablity. His hashpower is 49.999999999%. How many blocks do you need to get his success under one in 1000 assuming the difficulty gives 10 minute blocks and that a 2 minute radius?
 84 2012-07-16 05:09:25 <amiller> the radius is irrelevant, but the answer depends on the 49.9999999%
 85 2012-07-16 05:09:48 <amiller> i'd call that n=100000, because the advantage is 1+1/10000
 86 2012-07-16 05:10:16 <amiller> the number of blocks required is ~n^2
 87 2012-07-16 05:10:31 <gmaxwell> In any case, I'm just commenting on the repetition of a oft repeated bad idea "we can solve reorgs by refusing to perform big ones", no we can't. All that does is convert a one shot bad even on reorg into a perpetual forking attack.  It's only safe if an attacker can't cause a reorg that deep, and if they can't you don't need it.
 88 2012-07-16 05:10:46 <gmaxwell> s/even/event/
 89 2012-07-16 05:11:25 <amiller> "It's only safe if an attacker can't cause a reorg that deep, and if they can't you don't need it." <--- right
 90 2012-07-16 05:12:14 <midnightmagic> gmaxwell: Ah, the block contents are written to disk, MapOrphanBlocks/etc are just effectively pointers then..
 91 2012-07-16 05:14:55 <midnightmagic> reactos?!
 92 2012-07-16 05:15:12 <luke-jr> & that was a random exclamation
 93 2012-07-16 05:15:37 <luke-jr> oh, you saw it when tower left
 94 2012-07-16 05:16:15 <midnightmagic> oh..  I'm mixing reactos with amiga aros.
 95 2012-07-16 05:16:35 <luke-jr> O.o
 96 2012-07-16 05:16:46 <luke-jr> aros is different from Workbench?
 97 2012-07-16 05:17:27 <midnightmagic> yes.
 98 2012-07-16 05:27:03 <[Tycho]> Reactos ? Where is it ?
 99 2012-07-16 05:28:25 <c_k> reactos.org ?
100 2012-07-16 05:28:36 <midnightmagic> it looks like there's a tester for it here. :)
101 2012-07-16 05:31:13 <[Tycho]> I was asking about "[11:14] midnightmagic: reactos?!" :)
102 2012-07-16 05:31:31 <midnightmagic> yes me too!
103 2012-07-16 05:31:48 <[Tycho]> So why did you said that ?
104 2012-07-16 05:32:09 <midnightmagic> because there's a tester for it here, and I mixed it up with AROS, which would have been incredibly unusual.
105 2012-07-16 05:32:48 <[Tycho]> Cool.
106 2012-07-16 05:33:02 <[Tycho]> But how did you know that there is a tester for it ?
107 2012-07-16 05:33:27 <midnightmagic> tower was disconnected and his freenode cloak has reactos/tester/tower in it.
108 2012-07-16 05:34:00 <tower> ?:CC5HB?K [Tycho]
109 2012-07-16 05:34:12 <tower> greetings  [Tycho]
110 2012-07-16 05:34:17 <[Tycho]> Hello.
111 2012-07-16 05:34:31 <tower> sry wrong kbd layout
112 2012-07-16 05:34:42 <midnightmagic> tower: Sorry. :) My mistake.
113 2012-07-16 05:35:47 <[Tycho]> Oh, I see it now. My client only shows hostname on joins :)
114 2012-07-16 05:36:26 <midnightmagic> love all the curious people here =]
115 2012-07-16 06:24:15 <coiax> graingert: You sent me a file link?
116 2012-07-16 06:25:19 <graingert> coiax: a magical file link
117 2012-07-16 06:28:43 <coiax> graingert: What is it
118 2012-07-16 06:28:58 <graingert> No idea
119 2012-07-16 06:48:06 <Commander710> hello
120 2012-07-16 06:48:30 <Commander710> i got a few questions concerning the bitcoin daemon
121 2012-07-16 06:49:41 <Commander710> my wallet.dat is in the .bitcoin directory. that's where i thought the bitcoind would normally take the wallet from.
122 2012-07-16 06:50:34 <Commander710> but if i type: getbalance, is doesn't display the correct balance. i have to start bitcoind with the -datadir=.bitcoin to get the correct balance displayed
123 2012-07-16 06:51:23 <Commander710> how can i tell bitcoind to always use the .bitcoin folder to look for the wallet.dat
124 2012-07-16 06:51:25 <Commander710> ?
125 2012-07-16 06:55:42 <josephcp> have you tried -rescan
126 2012-07-16 06:57:36 <kinlo> Commander710: do you have multiple .bitcoin directories?
127 2012-07-16 06:57:57 <kinlo> Commander710: it should be the .bitcoin directory in your home directory, not just any .bitcoin directory
128 2012-07-16 07:00:09 <Commander710> i have just the .bitcoin folder that was created by the setup
129 2012-07-16 07:07:33 <Commander710> and this is in my home dir
130 2012-07-16 10:05:38 <gribble> New news from bitcoinrss: Diapolo opened issue 1599 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1599>
131 2012-07-16 11:30:10 <Forexmasterja> Is there an IRC channel for MTGOX for support, I am having a problem I would like a technical perosn from MTGOX to look into.
132 2012-07-16 11:34:19 <helo> yes, and you get one guess as to what it is ;)
133 2012-07-16 11:54:35 <zooko> The main one in my opinion only arises when you try to take a "real world events" perspective.
134 2012-07-16 11:54:55 <zooko> To explain what I mean let's contrast this symmetric-keyed contrast introduction with a public-keyed secure introduction.
135 2012-07-16 11:55:06 <epscy> yes let's
136 2012-07-16 11:55:06 <zooko> Ah, whoops, that was intended for #tahoe-lafs.
137 2012-07-16 11:55:09 <zooko> :-)
138 2012-07-16 11:55:32 <zooko> Please join #tahoe-lafs in order to contrast a symmetric-keyed secure introduction with a public-keyed secure introduction. ??
139 2012-07-16 12:31:16 <PlotCitizen> Hello. I'm trying to use cURL to access the JSON-RPC (since I can't use bitcoind) in order to sign a message. How would I go about doing that? I can't seem to find anything helpful by searching.
140 2012-07-16 12:44:12 <jgarzik> PlotCitizen: https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29#Command_line_.28cURL.29
141 2012-07-16 12:44:54 <PlotCitizen> I've read that, and I don't think it's particularly helpful.
142 2012-07-16 12:50:48 <PlotCitizen> It's ok, I found it.
143 2012-07-16 16:00:25 <gribble> New news from bitcoinrss: gruez opened issue 1601 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1601> || gruez opened issue 1600 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1600>
144 2012-07-16 16:18:33 <OneEyed> Any reason why this transaction would not be included in the last two blocks? http://blockchain.info/tx-index/12410217/a014310c466af92f52c46f8fd6a53cdabfd518e22041ac38345c028d4c807954
145 2012-07-16 16:21:05 <OneEyed> (or would not be propagated a lot, I cannot see it in my bitcoind, this is GLBSE->me)
146 2012-07-16 16:24:33 <BlueMatt> hmmm...can we make 0-value txouts invalid?
147 2012-07-16 16:24:46 <BlueMatt> could make for a nasty dos
148 2012-07-16 16:39:01 <gavinandresen> BlueMatt: any DoS with 0-value txouts could be easily accomplished with 1-satoshi txouts (spend 1 BTC and you get potentially 100,000,000 1-satoshi outputs to play with)
149 2012-07-16 16:42:34 <LuaKT> Quick question, if I add multiple recipients does it count as a single transaction and cost only 1 fee?
150 2012-07-16 16:42:43 <LuaKT> Or do I still pay as if each person is a transaction
151 2012-07-16 16:42:51 <copumpkin> only one transaction
152 2012-07-16 16:42:57 <LuaKT> Great, thanks
153 2012-07-16 16:57:05 <BlueMatt> gavinandresen: yea, I was just thinking for pruned nodes though, its no huge deal, but it does mean you get infinite unspent outputs without costing anything instead of a limited amount
154 2012-07-16 16:57:22 <gavinandresen> 1 satoshi is approximately equal to zero
155 2012-07-16 16:57:26 <luke-jr> BlueMatt: 0-value txouts could fork the blockchain (so requires P2SH-alike rollout), and is used by p2pool
156 2012-07-16 16:57:42 <luke-jr> making them invalid, I mean
157 2012-07-16 16:57:45 <BlueMatt> why does p2pool use it?
158 2012-07-16 16:57:57 <luke-jr> BlueMatt: it uses a 0-value output for its merged mining
159 2012-07-16 16:58:01 <BlueMatt> gavinandresen: close, but not exact ;)
160 2012-07-16 16:58:26 <BlueMatt> why use an output for merged mining instead of coinbase???
161 2012-07-16 16:58:27 <gavinandresen> Making 0-satoshi inputs invalid might be worth thinking about.  That would make 0-satoshi outputs immediately prune-able
162 2012-07-16 16:58:49 <luke-jr> BlueMatt: outputs are at the end, so they can distribute midstates instead of the full coinbase txn
163 2012-07-16 16:58:57 <BlueMatt> well, if someone actually uses it, its not a great idea imho, but I dont see why it should be used...
164 2012-07-16 16:59:34 <luke-jr> gavinandresen: I think it would be nice to define "If the first opcode is OP_RETURN, the output cannot be spent and need not be indexed" formally
165 2012-07-16 17:00:04 <gavinandresen> zero is a really useful number; I could imagine zero-value outputs/inputs to be used by transaction validation services that just want to sign transactions and say "I stand behind this"
166 2012-07-16 17:00:13 <luke-jr> and encourage stuff like p2pool to use it
167 2012-07-16 17:00:48 <gavinandresen> luke-jr: OP_FALSE would probably be the right opcode to use for that.
168 2012-07-16 17:00:49 <luke-jr> gavinandresen: you don't need an input to add a signature
169 2012-07-16 17:00:49 <[Tycho]> Sometimes I wanted to use transactions with no outputs, but AFAIR this is not allowed :(
170 2012-07-16 17:00:52 <BlueMatt> no, putting that stuff in an unpruneable txout should be highly discouraged
171 2012-07-16 17:01:06 <luke-jr> gavinandresen: OP_FALSE could be ignored by later code; OP_RETURN prevents anything further from executing
172 2012-07-16 17:01:20 <BlueMatt> luke-jr: wait, midstate of what?
173 2012-07-16 17:01:27 <luke-jr> BlueMatt: of the coinbase transaction
174 2012-07-16 17:01:45 <BlueMatt> wait...what?
175 2012-07-16 17:01:52 <BlueMatt> they are distributing what, exactly?
176 2012-07-16 17:01:52 <luke-jr> BlueMatt: normal merged mining requires that the merged chains distribute the full coinbase txn to link the merged-merkle-tree to the proof
177 2012-07-16 17:02:09 <gavinandresen> luke-jr: ?  I mean "OP_FALSE" as an IsStandard() scriptPubKey meaning "you can prune this output immediately."
178 2012-07-16 17:02:25 <luke-jr> by putting their merged-merkle-tree in the last output, they can replace that with the midstate of the coinbase txn hash, just prior to the merged-tree
179 2012-07-16 17:02:48 <TD> please don't remove zero-value inputs/outputs
180 2012-07-16 17:02:53 <luke-jr> gavinandresen: ah, but then they can't throw extra junk after it like p2pool wants to do ;)
181 2012-07-16 17:03:07 <BlueMatt> luke-jr: ah, still that should be highly discouraged
182 2012-07-16 17:03:20 <gavinandresen> luke-jr: oh, they want extra junk.  Ok, then PUSH-up-to-N-bytes OP_FALSE
183 2012-07-16 17:03:30 <BlueMatt> its a cool optimization, but it creates unpruneable outputs for pretty much no reason
184 2012-07-16 17:03:41 <BlueMatt> I think alt-chains can handle the extra bw...
185 2012-07-16 17:03:58 <BlueMatt> TD: what use-case do you have for it?
186 2012-07-16 17:04:05 <TD> there are some contracts on the wiki that use them
187 2012-07-16 17:04:14 <BlueMatt> mmm
188 2012-07-16 17:04:16 <TD> of course they can use 1satoshi outputs/inputs too, but that's lame
189 2012-07-16 17:04:27 <TD> disk space is cheap, after all. i don't see it as being a big deal.
190 2012-07-16 17:04:40 <luke-jr> gavinandresen: IMO, easier to just check scriptPubKey[0] == OP_RETURN
191 2012-07-16 17:05:19 <BlueMatt> TD: I think the limiting factor (after script checking) of pruning full nodes is looking up txouts in the db, which is a function of the number of outputs unspent...
192 2012-07-16 17:05:41 <TD> the fate of bitcoin is to grow and grow. fortunately that's also true of storage.
193 2012-07-16 17:05:52 <luke-jr> BlueMatt: if scriptPubKey[0]==OP_RETURN is used as "don't index this"&
194 2012-07-16 17:06:03 <BlueMatt> its not a big deal, really, but still people should avoid using 0-outputs for no real gain (if there is another way to do it)
195 2012-07-16 17:06:22 <TD> there is another way to do it, use a 1 satoshi output, but there's no point in requiring this
196 2012-07-16 17:06:36 <TD> let's not over-optimize ...
197 2012-07-16 17:06:39 <BlueMatt> meh, whatever
198 2012-07-16 17:06:52 <BlueMatt> if there is a use-case for it, fine, I just wasnt aware anyone was using it
199 2012-07-16 17:07:02 <BlueMatt> (but, seriously, p2pool really shouldnt be doing that)
200 2012-07-16 17:07:29 <BlueMatt> (any data in a 0-value out can always be stuffed in a OP_DROP anyway...)
201 2012-07-16 17:08:26 <BlueMatt> forrestv: can you start the 0-value txout in p2pool coinbases with OP_RETURN and then the hash instead of the hash?
202 2012-07-16 17:09:37 <BlueMatt> in other news, finally have some nice test cases which are run on bitcoinj and now have a tool which pulls in the same test cases and throws the blocks at bitcoind to make sure both accept the same blocks
203 2012-07-16 17:09:43 <TD> cool!
204 2012-07-16 17:10:11 <gavinandresen> yeah, cool!
205 2012-07-16 17:10:30 <gavinandresen> ... although rejecting the same set of blocks is just as important....
206 2012-07-16 17:10:36 <BlueMatt> it checks that too
207 2012-07-16 17:10:43 <gavinandresen> really cool!
208 2012-07-16 17:11:02 <BlueMatt> another topic, can we make bitcoind never send blocks it found to be invalid to nodes requesting them
209 2012-07-16 17:11:23 <gmaxwell> Er. Why is that desirable?
210 2012-07-16 17:11:48 <gmaxwell> If it doesn't announce them that should be sufficient. Doing something more narrow than that may making troubleshooting much harder.
211 2012-07-16 17:12:27 <BlueMatt> just seems wrong when bitcoind is expected to verify blocks and then provide that info to spv nodes
212 2012-07-16 17:12:55 <BlueMatt> if a spv node is on a fork, any bitcoind will keep that fork going on that node, even if it thinks that fork is invalid
213 2012-07-16 17:12:57 <gavinandresen> better might be to add an extra piece of data that says "valid/invalid/not sure" ... and maybe a boolean for whether or not it's in the main chain
214 2012-07-16 17:13:20 <gavinandresen> but then we'd have to think about what would happen if an attacker just simply lied
215 2012-07-16 17:13:25 <BlueMatt> s/giving that fork/extending that fork/
216 2012-07-16 17:14:13 <BlueMatt> an attacker lying doesnt change much there, they can already just not forward blocks for the same result
217 2012-07-16 17:14:24 <TD> invalid blocks should not be in the best chain
218 2012-07-16 17:14:30 <TD> so why is that an issue?
219 2012-07-16 17:14:42 <TD> the remote bitcoind will send the valid parts of the chain in response to getblocks
220 2012-07-16 17:15:25 <BlueMatt> a->b a->c (c is found to be invalid) c->d if a spv node is on c, and asks a bitcoind for the latest blocks, bitcoind will send d
221 2012-07-16 17:15:38 <BlueMatt> it should never really be an issue, but it seems wrong...
222 2012-07-16 17:16:33 <BlueMatt> (or...I cant really think of a way to make that into a useful or really any attack, but...)
223 2012-07-16 17:16:54 <luke-jr> BlueMatt: consider that one *real issue* we have right now is that we need to start forwarding blocks before checking them&
224 2012-07-16 17:16:55 <TD> i don't think it will ?
225 2012-07-16 17:17:12 <BlueMatt> TD: Im 99% sure it does
226 2012-07-16 17:17:19 <TD> i think bitcoind will discard d as invalid and when the client does a getblocks, will tell it about the next best valid block
227 2012-07-16 17:18:07 <BlueMatt> if its invalid pow, it will, if d is otherwise valid, but eg c has a coinbase which tries to generate 100000BTC, bitcoind will send d
228 2012-07-16 17:18:07 <TD> the block locator states where the peer is in on the chain. getblocks then walks back to find the earliest point the client already has on the best chain
229 2012-07-16 17:19:01 <TD> ok, well i might be wrong, i'd have to check the code. my memory was that getblocks will only ever provide you with the best valid chain
230 2012-07-16 17:19:31 <BlueMatt> CBlockLocator::GetBlockIndex() just searches in mapBlockIndex
231 2012-07-16 17:19:46 <BlueMatt> and c and d will be left in mapBlockIndex, though not connected
232 2012-07-16 17:20:48 <TD> seems like a bug in getblocks
233 2012-07-16 17:21:55 <BlueMatt> yea, I think we should change it but, again, "all bugs are features" and i dont see how to use it to do anything nasty
234 2012-07-16 17:23:13 <luke-jr> "all bugs are features" IMO does not apply to the p2p protocol
235 2012-07-16 17:55:58 <eian> Is the guy behind blockchain info in here?
236 2012-07-16 17:56:19 <copumpkin> not as far as I know
237 2012-07-16 17:56:19 <luke-jr> not usually
238 2012-07-16 17:56:23 <copumpkin> he doesn't come on IRC much
239 2012-07-16 17:56:53 <genjix> sipa: my internet is being slow right now, but i think there's a missing BN_clear_free(bn) in CKey::GetSecret()
240 2012-07-16 17:57:18 <eian> what's his nick?
241 2012-07-16 17:59:24 <genjix> sipa: is that const bignum supposed to be free'ed after
242 2012-07-16 17:59:38 <gavinandresen> sipa was on his way to Iceland last I heard
243 2012-07-16 17:59:51 <gavinandresen> (only he spelled it funny)
244 2012-07-16 18:00:20 <genjix> ah ok
245 2012-07-16 18:01:37 <gavinandresen> I updated the JSON-RPC API list on the wiki to include the raw transaction calls, and wrote https://en.bitcoin.it/wiki/Raw_Transactions
246 2012-07-16 18:01:42 <BlueMatt> genjix: sipa is on vacation till the end of the month
247 2012-07-16 18:07:29 <eian> genjix, does libbitcoin use blocking i/o? If not, is it using something like libevent?
248 2012-07-16 18:20:59 <genjix> eian: non-blocking io. libevent is nice. i'm using asio which is better.
249 2012-07-16 19:05:55 <phantomcircuit> gavinandresen, would it be reasonable to assume no block will ever be > 10MB?
250 2012-07-16 19:07:16 <gavinandresen> phantomcircuit: right now there is a size limit on blocks of 1MB, changing that will mean a hard fork. If it is ever changed, my guess is it would be to a floating size determined by miners
251 2012-07-16 19:07:56 <phantomcircuit> hmm
252 2012-07-16 19:08:05 <phantomcircuit> so yes but only if you're prepared to change it
253 2012-07-16 19:08:18 <phantomcircuit> but a change would be a one time expensive conversion so it's probably ok
254 2012-07-16 19:08:36 <kinlo> do clients flat out reject blocks > 1mb?
255 2012-07-16 19:08:40 <luke-jr> yes
256 2012-07-16 19:18:40 <gribble> New news from bitcoinrss: mariosal opened issue 1602 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1602>
257 2012-07-16 19:46:00 <lianj> how is http://blockexplorer.com/q/hashestowin calculated?
258 2012-07-16 19:46:38 <lianj> also /q/probability
259 2012-07-16 19:52:20 <BlueMatt> /q/probability is probably just a current diff * constant of diff 1
260 2012-07-16 19:52:37 <BlueMatt> hashestowin you can calculate from that
261 2012-07-16 19:53:01 <lianj> thanks. let me try :)
262 2012-07-16 20:04:01 <D34TH> bluematt, i have an error extracing the files
263 2012-07-16 20:04:02 <D34TH> D:
264 2012-07-16 20:06:23 <luke-jr> XD
265 2012-07-16 20:06:37 <D34TH> meh, i give up
266 2012-07-16 20:08:05 <BlueMatt> D34TH: error extracting?
267 2012-07-16 20:08:11 <D34TH> yep
268 2012-07-16 20:08:18 <D34TH> bbl
269 2012-07-16 20:08:31 <BlueMatt> do you have xzutils installed?
270 2012-07-16 20:11:11 <lianj> BlueMatt: yay, although my hashestowin calc is off by one :|
271 2012-07-16 20:15:34 <BlueMatt> round up?
272 2012-07-16 20:16:42 <lianj> i guess. btw probability is 1.0 / hashestowin
273 2012-07-16 20:16:52 <BlueMatt> yep
274 2012-07-16 20:22:02 <lianj> BlueMatt: hm, but on bbe side. /q/probability ==  1.0 / (/q/hashestowin + 1)
275 2012-07-16 20:24:29 <D34TH> bluematt: i do
276 2012-07-16 20:25:23 <BlueMatt> lianj: according to my calculator, floor(1/prob) == hashestowin
277 2012-07-16 20:25:31 <BlueMatt> which seems like how bbe probably calculates it
278 2012-07-16 20:25:38 <BlueMatt> D34TH: whats the error?
279 2012-07-16 20:25:43 <D34TH> it just stops
280 2012-07-16 20:25:53 <D34TH> thats it
281 2012-07-16 20:25:54 <BlueMatt> -v?
282 2012-07-16 20:26:03 <D34TH> sec, gotta restart it
283 2012-07-16 20:26:20 <D34TH> there was a kernel update
284 2012-07-16 20:26:54 <BlueMatt> what version of xz/liblzma do you have? (mine is "liblzma 5.1.0alpha")
285 2012-07-16 20:28:39 <D34TH> same
286 2012-07-16 20:31:05 <BlueMatt> hmm... tar xvf ubuntu.tar.xz works fine for me
287 2012-07-16 20:31:43 <BlueMatt> well...works up to an error, but it untars everything before the error afaict
288 2012-07-16 20:31:43 <D34TH> i just xz'ed it and now im going to tar it
289 2012-07-16 20:31:51 <D34TH> and see if it works that way
290 2012-07-16 20:42:10 <D34TH> it worked
291 2012-07-16 20:42:11 <D34TH> :D
292 2012-07-16 21:51:31 <copumpkin> when computing a block hash
293 2012-07-16 21:51:34 <copumpkin> what goes into that?
294 2012-07-16 21:51:47 <copumpkin> do the bits need to be reversed?
295 2012-07-16 21:52:53 <BlueMatt> what language do you prefer? there are examples in just about all of them by now...
296 2012-07-16 21:53:03 <copumpkin> hmm, don't really care
297 2012-07-16 21:53:11 <copumpkin> but I guess the wiki doesn't really specify?
298 2012-07-16 21:53:33 <copumpkin> https://en.bitcoin.it/wiki/Protocol_specification#Hashes
299 2012-07-16 21:55:06 <copumpkin> I'll just read roconnor's one
300 2012-07-16 21:55:43 <copumpkin> oh
301 2012-07-16 21:56:03 <copumpkin> I see
302 2012-07-16 21:58:02 <Joric> ;;asks 10
303 2012-07-16 21:58:03 <gribble> There are currently 18350.814 bitcoins offered at or under 10.0 USD, worth 168371.253493 USD in total.
304 2012-07-16 21:58:16 <Joric> isn't it wonderful 16k till $10
305 2012-07-16 22:00:36 <jgarzik> me too
306 2012-07-16 22:01:03 <copumpkin> aha, there we go
307 2012-07-16 22:01:10 <copumpkin> the hashes look good now
308 2012-07-16 22:01:11 <copumpkin> :D
309 2012-07-16 22:44:14 <graingert> ;;ask 31
310 2012-07-16 22:44:15 <gribble> Error: "ask" is not a valid command.
311 2012-07-16 22:44:17 <graingert> ;;asks 31
312 2012-07-16 22:44:19 <gribble> There are currently 65485.862 bitcoins offered at or under 31.0 USD, worth 1048149.99549 USD in total.
313 2012-07-16 22:44:33 <Joric> lol not so much either
314 2012-07-16 22:44:40 <graingert> ;;asks 0.40
315 2012-07-16 22:44:41 <gribble> There are currently 0 bitcoins offered at or under 0.4 USD, worth 0.0 USD in total.
316 2012-07-16 22:44:48 <graingert> ;;bids 0.40
317 2012-07-16 22:44:49 <gribble> There are currently 596094.82 bitcoins demanded at or over 0.4 USD, worth 1877149.41309 USD in total.
318 2012-07-16 22:45:55 <graingert> this one is better for spotting
319 2012-07-16 22:47:08 <jrmithdobbs> did those lost/stolen/whatever funds get xfered to an mtgox account or something?
320 2012-07-16 22:47:22 <jrmithdobbs> wondering why the surge right after, seems contrary to history
321 2012-07-16 22:47:24 <graingert> jrmithdobbs: who knows
322 2012-07-16 23:00:11 <upb> well whats the easyest way to get mtgoxusd out of gox untracably
323 2012-07-16 23:00:20 <upb> buy btc and withdraw those
324 2012-07-16 23:04:12 <graingert> it helps if you crash the market first
325 2012-07-16 23:04:36 <graingert> so you get out 1000$ worth at 0.0001 btc per dollar
326 2012-07-16 23:06:42 <upb> didnt the last trollback coincide with the bubble bursting tho?
327 2012-07-16 23:09:05 <amiller> i'm having a good day, i hope all of you are too