1 2013-07-03 00:00:00 <BW^-> michagogo: or just simply another peer with a slow connection or behind blocking firewalls!
2 2013-07-03 00:00:14 <sipa> that's why you have 8 outgoing connections
3 2013-07-03 00:00:18 <sipa> and not 1
4 2013-07-03 00:00:36 <michagogo> sipa: What if for some reason either you didn't, or an attacker managed to get all your connections
5 2013-07-03 00:00:44 <sipa> that's a sybil attack
6 2013-07-03 00:00:51 <michagogo> brb, googling
7 2013-07-03 00:00:52 <BW^-> sipa: during this download process for a bootstrapping bitcoind, is the bitcoind in some kind of "blocked" mode where it only does "getblocks" calls to get up to date, and does *not* do followup work on any blocks it gets broadcast-gossiped to it?
8 2013-07-03 00:01:06 <sipa> BW^-: it follows up on everything it hears
9 2013-07-03 00:01:10 <sipa> BW^-: and it gets easily confused
10 2013-07-03 00:01:14 <BW^-> sipa: straight away, always?
11 2013-07-03 00:01:22 <sipa> it's not that simple
12 2013-07-03 00:01:33 <sipa> it remembers which blocks it has already asked for
13 2013-07-03 00:01:42 <sipa> and will not ask the same twice within a given period of time
14 2013-07-03 00:01:44 <sipa> iirc 1 minute
15 2013-07-03 00:02:11 <sipa> but that whole mechanism is very hackish/broken, and needs replacement by headers-first-sync
16 2013-07-03 00:02:14 <michagogo> sipa: Okay, so if an attacker manages a sybil attack (although from the wp article I'm not exactly clear that this is what this is)
17 2013-07-03 00:02:27 <sipa> michagogo: they can stop you from getting the best chain
18 2013-07-03 00:02:33 <michagogo> I know, but wait a sec
19 2013-07-03 00:02:36 <sipa> they can't make you accept an invalid chain
20 2013-07-03 00:02:44 <michagogo> Right, but just a sec while I type
21 2013-07-03 00:02:54 <BW^-> sipa: first jut to get it, so say that my bootstrapping bitcoind only knows blocks 0-500 yet, and it gets broadcast to it block number 9999999999. how does it ask for its preceding blocks, using 'getblocks'? what arguments, i mean 'getblocks' returns *following* blocks not preceding??
22 2013-07-03 00:03:21 <BW^-> so which protocol operation is used to retrieve preceding blocks?
23 2013-07-03 00:03:26 <michagogo> sipa: If they claim that there are no more blocks past, say, 230000 (past the latest checkpoint, right?), and then inv you the latest block
24 2013-07-03 00:03:27 <sipa> none
25 2013-07-03 00:03:34 <sipa> it's always the following you need
26 2013-07-03 00:03:38 <michagogo> sipa: Would *that* end up sucking up tons of RAM?
27 2013-07-03 00:03:48 <sipa> BW^-: it will send a getblocks with locator for the 500 blocks it has, and stophash 99999999
28 2013-07-03 00:04:00 <sipa> BW^-: and the reply will be invs for 501-1000
29 2013-07-03 00:04:12 <sipa> if it has up to 200000 already
30 2013-07-03 00:04:20 <sipa> and the new best is 200200
31 2013-07-03 00:04:33 <sipa> it will send a locator for the first 200000, and stophash 200200
32 2013-07-03 00:04:42 <sipa> and it'll get a reply with 200001-200199
33 2013-07-03 00:04:48 <BW^-> sipa: what do you mean by "stophash"?
34 2013-07-03 00:04:58 <sipa> BW^-: the second argument of getblocks
35 2013-07-03 00:05:00 <BW^-> aaaha
36 2013-07-03 00:05:04 <michagogo> 32 hash_stop char[32] hash of the last desired block; set to zero to get as many blocks as possible (500)
37 2013-07-03 00:05:05 <BW^-> aa aha
38 2013-07-03 00:05:06 <sipa> the hash at which the peer can stop
39 2013-07-03 00:05:19 <sipa> actually it's the hash of the first undesired block
40 2013-07-03 00:05:25 <sipa> i think
41 2013-07-03 00:05:26 <michagogo> sipa: second: wiki says 4th
42 2013-07-03 00:05:29 <michagogo> second?*
43 2013-07-03 00:05:40 <michagogo> Unless the fields aren't in order
44 2013-07-03 00:05:53 <sipa> 4th?
45 2013-07-03 00:06:03 <sipa> there's only a CBlockLocator and a uint256 in there
46 2013-07-03 00:06:10 <michagogo> version, hash count, locator hashes, hash_stop
47 2013-07-03 00:06:13 <The_Fly> are large wallets currently a performance bottleneck? if so any way to prune them?
48 2013-07-03 00:06:18 <michagogo> https://en.bitcoin.it/wiki/Protocol_specification#getblocks
49 2013-07-03 00:06:31 <sipa> michagogo: (hash count, locator hashes) together are CBlockLocator
50 2013-07-03 00:06:37 <BW^-> sipa: so your point is that, if a peer gets a block broadcasted to it that it does not know the preceding block for, then it will consider it an orphan and stored it in RAM, and, it will send a getblocks request with the newest block it knows of as "locator hash", and the broadcasted block as "stophash", and use that as mechanism using which to retrieve all the news and thu sget an up to date block database - and get to a place
51 2013-07-03 00:06:37 <BW^-> where it can properly flush the newly broadcasted block into the blockchain?
52 2013-07-03 00:06:55 <michagogo> sipa: Ah, so the 3rd argument
53 2013-07-03 00:07:13 <sipa> michagogo: and that protocol version is part of the header
54 2013-07-03 00:07:18 <michagogo> Ah, okay
55 2013-07-03 00:07:19 <sipa> there's more in the header in any case
56 2013-07-03 00:07:25 <michagogo> (so why is it listed as payload there?)
57 2013-07-03 00:07:47 <sipa> meh :)
58 2013-07-03 00:07:55 <sipa> someone considered it part of the payload :p
59 2013-07-03 00:08:02 <sipa> BW^-: correct
60 2013-07-03 00:08:03 <BW^-> sipa,michagogo: what's the point with getblocks supporting more than one block hash to look up the blocks following after it? i mean, there's only one hash_stop argument.. so what's the sense?
61 2013-07-03 00:08:08 <BW^-> sipa: cool!
62 2013-07-03 00:08:13 <michagogo> BW^-: I asked that before
63 2013-07-03 00:08:16 <sipa> BW^-: forks
64 2013-07-03 00:08:35 <sipa> BW^-: if you just send you tip, and the peer doesn't know your tip, he must assume you don't have any block in common
65 2013-07-03 00:08:39 <michagogo> Apparently, it's a general snapshot of which blocks the requesting client knows
66 2013-07-03 00:08:43 <sipa> so you send a few earlier hashes too
67 2013-07-03 00:08:49 <sipa> in case the tip doesn't work out
68 2013-07-03 00:09:08 <michagogo> The last 10 blocks, and then exponentially farther apart blocks back until genesis (IIUC)
69 2013-07-03 00:09:14 <sipa> correct
70 2013-07-03 00:09:57 <sipa> so, N, N-1, N-2, ... N-9, N-11, N-15, N-23, N-39, N-71, N-137, N-263, N-519, N-1031, N-2055, ...
71 2013-07-03 00:09:59 <BW^-> sipa: aha, so the point with a getblock call having several block locator hashes is if it has more than one block chain branch, and this way it will ask like, "hey look I have these branches A, B and C, ending at block hash X1 and X2 and X3 respectively. please give me all the blocks from the end up to stop hash X4", and then the response will be *only one inv* which is for the branch that actually had an X4 in it to return all the bl
72 2013-07-03 00:10:01 <michagogo> So how many does that turn out to be?
73 2013-07-03 00:10:20 <sipa> BW^-: no, you don't give multiple branches
74 2013-07-03 00:10:26 <sipa> BW^-: you give your chain
75 2013-07-03 00:10:31 <sipa> or a subsample of it
76 2013-07-03 00:10:46 <BW^-> sipa: why would you do that then?
77 2013-07-03 00:10:49 <sipa> michagogo: ~38
78 2013-07-03 00:10:50 <michagogo> BW^-: You send your best chain as a (sparser the older it gets) sampling
79 2013-07-03 00:10:54 <The_Fly> im thinking of keeping pubkeys only on server, via codeshark's importaddress, but after transactions have confirmed i could quite easily prune
80 2013-07-03 00:10:59 <sipa> BW^-: what if the peer doesn't have your tip?
81 2013-07-03 00:11:02 Eiii has joined
82 2013-07-03 00:11:04 <sipa> BW^-: then what would he send?
83 2013-07-03 00:11:06 Eiii has quit (Changing host)
84 2013-07-03 00:11:06 Eiii has joined
85 2013-07-03 00:11:17 <BW^-> sipa: tip?
86 2013-07-03 00:11:21 <sipa> BW^-: head
87 2013-07-03 00:11:22 <michagogo> BW^-: And then the peer will inv you starting from the last block you have that it recognozes
88 2013-07-03 00:11:23 <sipa> best block
89 2013-07-03 00:11:24 <BW^-> ah, tip of chain
90 2013-07-03 00:11:24 <sipa> tip
91 2013-07-03 00:11:25 <michagogo> recognizes
92 2013-07-03 00:11:42 <michagogo> (again, IIUC)
93 2013-07-03 00:11:42 <BW^-> aha
94 2013-07-03 00:11:42 <sipa> BW^-: it's to help you find the last block you have in common with the peer
95 2013-07-03 00:11:57 <BW^-> ahaa
96 2013-07-03 00:12:03 <sipa> or better, the last block your best chain has in common with the peer's best chain
97 2013-07-03 00:12:19 <BW^-> greatly neat. and, getblocks will be responded to starting with the *highest* block that was in common right?
98 2013-07-03 00:12:19 robocoin has quit (Ping timeout: 264 seconds)
99 2013-07-03 00:12:26 <sipa> BW^-: correct
100 2013-07-03 00:12:27 <michagogo> BW^-: Right.
101 2013-07-03 00:12:31 <BW^-> neat
102 2013-07-03 00:12:44 <BW^-> but hey, so these calls are made in the context of an existing common understanding of which is the longest chain
103 2013-07-03 00:12:57 <sipa> eh
104 2013-07-03 00:13:05 <BW^-> why this sequential approach within the longest chain, and not like data tree syncing operations?
105 2013-07-03 00:13:18 <sipa> how is this not a data tree syncing operation?
106 2013-07-03 00:13:19 <BW^-> of course there should be one longest chian only and everyone agreeing on it
107 2013-07-03 00:13:21 <The_Fly> i guess i should go try load a large number of keys (or just CKeyIDs via importaddress) and see how it fares
108 2013-07-03 00:13:42 <sipa> BW^-: no
109 2013-07-03 00:13:46 <gmaxwell> 16:44 < BW^-> but hey, so these calls are made in the context of an existing common understanding of which is the longest chain
110 2013-07-03 00:13:49 <gmaxwell> uh. no
111 2013-07-03 00:13:50 <The_Fly> just had heard one or two complain before
112 2013-07-03 00:13:50 <sipa> the point is to converge to a common history
113 2013-07-03 00:13:57 <BW^-> gmaxwell: how is it not?
114 2013-07-03 00:13:58 <gmaxwell> If you don't have a block you obviously haven't converged.
115 2013-07-03 00:14:02 <sipa> you cannot have global consistent consensus
116 2013-07-03 00:14:19 <BW^-> i mean, if a node using the protocol, does not even have the capacity to download blocks from another branch than the one the other peer considers the longest right now??
117 2013-07-03 00:14:25 <gmaxwell> If you're already consistent with someone there is nothing else to do.
118 2013-07-03 00:14:48 <michagogo> BW^-: Why would you need that?
119 2013-07-03 00:14:53 <gmaxwell> BW^-: the other peer will tell it about a new block on that branch and then you'll start trying to converge onto it.
120 2013-07-03 00:14:56 <BW^-> how are fork/branch switches coordinated at protocol level?
121 2013-07-03 00:15:03 <michagogo> BW^-: They're not really
122 2013-07-03 00:15:06 <BW^-> gmaxwell: aha, that makes sense
123 2013-07-03 00:15:15 <sipa> BW^-: well you know everything i think
124 2013-07-03 00:15:24 <sipa> BW^-: nodes just always try to find the best chain
125 2013-07-03 00:15:25 <michagogo> BW^-: Well, if a reorg happened, your client would inv the new longest block to all its peers
126 2013-07-03 00:15:32 <sipa> if they find a better one, they switch to it
127 2013-07-03 00:15:36 <michagogo> er, new tip of best chain
128 2013-07-03 00:15:38 <sipa> and that's a purely local operation
129 2013-07-03 00:15:44 <gmaxwell> Importantly: it takes doing something expensive (creating a possibly valid block header) to get you going out and trying to fetch stuff.
130 2013-07-03 00:16:15 <sipa> because the entire system is designed around the fact that not everyone will always agree
131 2013-07-03 00:16:18 <sipa> and that's fine
132 2013-07-03 00:16:51 <sipa> it does guarantee (under some conditions) that the chance of disagreement in stable operation decreases exponentially with how long ago the block was created
133 2013-07-03 00:17:30 <BW^-> aha
134 2013-07-03 00:18:22 <BW^-> the miner that mines the newest block, in case when it generates this newest block, it happens to be on the "wrong branch", and the rest of the system accordingly will ignore that and proceed with the actually longest branch, then that mining success will be permanently lost right, and the miner will not have any benefit of it -
135 2013-07-03 00:18:53 <BW^-> there's no inherent autorepair that makes a new block made on an non-longest branch autocorrect to magically being on the longest branch, for the miner to get the reward and so on?
136 2013-07-03 00:18:53 <sipa> there is no "actually longest branch"
137 2013-07-03 00:19:06 <BW^-> (branch known to all the others as longest)
138 2013-07-03 00:19:08 <sipa> everyone just accepts whatever longest branch they know about at any point in time
139 2013-07-03 00:20:12 <BW^-> aha. to zoom out a bit: when you commit a transaction (using the 'sendfrom' RPC call for instance), what is the process of it being included into the newest block then?
140 2013-07-03 00:20:23 <BW^-> so, this transaction is broadcast all through the network
141 2013-07-03 00:20:24 <michagogo> BW^-: And no, if a miner mines a block that ends up on the non-longest block, they don't get a reward
142 2013-07-03 00:20:33 <BW^-> michagogo: noted
143 2013-07-03 00:20:42 <michagogo> BW^-: It's broadcast across the network. It ends up in miners' mempools
144 2013-07-03 00:20:57 <michagogo> BW^-: Those miners include it in a block they're trying to find
145 2013-07-03 00:21:12 <BW^-> and at some point supposedly so many peers that the miner that will happen to be the miner that finds the next PoW so that it will create the next block, will have it on its mempool - right.
146 2013-07-03 00:21:20 <BW^-> right
147 2013-07-03 00:21:32 <BW^-> michagogo: so this is how a transaction is "cemented" into the block chain
148 2013-07-03 00:21:39 <michagogo> Once a miner finds a block, any transactions the miner decided to include in that block become confirmed once
149 2013-07-03 00:22:18 <michagogo> And as the block where a transaction was included gets buried deeper into the blockchain, it becomes harder to exclude from the blockchain, and hence gets more confirmations
150 2013-07-03 00:22:23 <BW^-> michagogo: is this also what we call "confirmations"? or, are confirmations when a peer gets back from its peers, a gossipping of the transaction it itself sent out, thus confirming that other peers viewed the transaction it sent as valid?
151 2013-07-03 00:22:37 <sipa> BW^-: the first confirmation is the block the transaction is included in
152 2013-07-03 00:22:44 <sipa> BW^-: any block on top of that is another confirmation
153 2013-07-03 00:23:37 <michagogo> BW^-: And as long as a transaction meets the relay rules, it will spread across the (vast majority of the) network within seconds
154 2013-07-03 00:25:17 <BW^-> michagogo: cool.; is anyone deploying an algorithm where they consider a transaction successful prior to the first confirmation (i.e. knowledge there was a block generated that included the sent transaction)?
155 2013-07-03 00:25:28 <BW^-> i mean, it could be 10 or even 40 mins to the first confirmation right?
156 2013-07-03 00:25:35 <michagogo> BW^-: Yes.
157 2013-07-03 00:25:39 <michagogo> (to the second question)
158 2013-07-03 00:25:40 <BW^-> michagogo: what's that algorithm?
159 2013-07-03 00:25:45 patcon has joined
160 2013-07-03 00:25:47 <BW^-> ah
161 2013-07-03 00:25:55 <sipa> BW^-: "return true;"
162 2013-07-03 00:25:55 <michagogo> And no, there's no way to know that
163 2013-07-03 00:26:02 <sipa> BW^-: which is a very dangerous algorithm :)
164 2013-07-03 00:26:03 <BW^-> 10-40mins is a lot - someone may want to see business happen before that
165 2013-07-03 00:26:07 <BW^-> :)))
166 2013-07-03 00:26:19 <BW^-> sipa: you couldn't just send your transaction to lots of peers and wiat for them to broadcast it back to you somehow?
167 2013-07-03 00:26:26 <michagogo> BW^-: It's likely that a transaction will be successful, almost guaranteed, UNLESS there's something malicious going on
168 2013-07-03 00:26:33 <sipa> BW^-: what does that prove?
169 2013-07-03 00:26:42 <BW^-> and use this as indication that now that so many apparently agree with your transaction so that they tell you it's true, it must be true, that kind of thing
170 2013-07-03 00:26:44 <BW^-> sipa: yeah, nothing.
171 2013-07-03 00:26:52 <michagogo> BW^-: In which case, you need to wait for at least a confirmation or two to have cursory insurance against a double spend
172 2013-07-03 00:26:57 <BW^-> yeah
173 2013-07-03 00:26:58 <BW^-> that's a good point
174 2013-07-03 00:27:05 <michagogo> BW^-: Basically, the risk is a double spend
175 2013-07-03 00:27:14 <BW^-> so, you're working in an operative scope where your wallet *should be unique to the running machine* and the known balances correct and so o
176 2013-07-03 00:27:15 <BW^-> n
177 2013-07-03 00:27:43 <michagogo> If the attacker just mined a block with a transaction that double-spends the output he's trying to pay you with, and hasn't yet broadcast it
178 2013-07-03 00:28:06 <BW^-> and, your certainty that this is how it is, should be so high that a 10minute time to get the "transaction denied" response is OK - as the possibility of that happening should be zero, it would indicate you did something terminally invalid in the first place
179 2013-07-03 00:28:15 <michagogo> It doesn't matter how many peers see the transaction paying you, as long as he can broadcast the block with the transaction that invalidates that one ebfore another block is found
180 2013-07-03 00:28:20 <BW^-> such as , having a system open for someone to copy out your wallet.dat and happily spend your wallet contents, for instance
181 2013-07-03 00:28:41 zrad has quit (Read error: Connection reset by peer)
182 2013-07-03 00:28:44 <michagogo> BW^-: The thing is, there's no way to ensure that
183 2013-07-03 00:29:09 <michagogo> BW^-: You can't know that that's the only copy of the privkey, since it's information
184 2013-07-03 00:29:30 Julius129 has quit (Ping timeout: 246 seconds)
185 2013-07-03 00:29:38 <BW^-> michagogo: right to the first, and right to the second.
186 2013-07-03 00:30:03 <michagogo> BW^-: Once you've gotten one confirmation, that's minimally safe within a minute or so
187 2013-07-03 00:30:31 <BW^-> michagogo: was it just a coincidence that you mentioned a miner here as fraudlent party? i mean, if there's just some node X on the network, it can too transmit transactions that challenge a previously send transaction, until there's been a block "cementing" the validity of the first transaction, right?
188 2013-07-03 00:30:32 <michagogo> BW^-: Once you have 2 confirmations, for low-value transactions you might be able to rely on it
189 2013-07-03 00:30:57 <michagogo> BW^-: Right, but it'll be rejected as a double-spend by any nodes that have seen the first one
190 2013-07-03 00:31:34 <michagogo> Now, if a miner does see both somehow, or sees the double-spend first, the other one might be included in a block
191 2013-07-03 00:31:50 <BW^-> michagogo: this effectively means that any Bitcoin transactioning where you want sub-1-minute transaction times (such as, when buying a donut or metro ticket at a tobacconist's ) with Bitcoin, you need some faster-guaranteed-payments infrastructure built *atop* the Bitcoin network, to perform it?
192 2013-07-03 00:31:54 <michagogo> But the easiest way to get a double-spend into the blockchain is indeed to find a block yourself
193 2013-07-03 00:31:55 roconnor has joined
194 2013-07-03 00:32:12 <michagogo> BW^-: Right, or just accept the risk and hope people are honest
195 2013-07-03 00:33:03 <BW^-> michagogo: as in, you receive the transaction on the network and it lands in your mempool, and you know it's unconfirmed and you accept it presuming the other party is not heading for making a double spend?
196 2013-07-03 00:33:04 <michagogo> For a donut, the risk of a 0-confirmation transaction is probably not too bad
197 2013-07-03 00:33:12 <michagogo> Right
198 2013-07-03 00:33:13 <BW^-> yeah, you would need some finesse to successfully make a double spend anyhow
199 2013-07-03 00:33:14 <BW^-> mhm
200 2013-07-03 00:33:23 <michagogo> Well, not necessarily
201 2013-07-03 00:34:01 <BW^-> michagogo: so, you got your paying bitcoind, you've got the tobbaconist's bitcoind, and then I guess you have another bitcoind using which you want to doublespend as to fraud the tobacconist?
202 2013-07-03 00:34:05 PrimeStunna_ has joined
203 2013-07-03 00:34:35 <michagogo> If you have peers with a lowered relay policy or the attacker finds your node, the attacker can pay you with a no-fee, big transaction that won't make its way through the network
204 2013-07-03 00:34:53 <BW^-> michagogo: the trick would be to generate a propagation pattern through the bitcoin peer network such that the transaction from your paying bitcoind is propagated up to the tobbaconist's bitcoind *BEFORE* the fraudlent transaction is propagated to there ,no?
205 2013-07-03 00:35:04 <michagogo> Exactly
206 2013-07-03 00:35:30 <michagogo> And then get a double-spending tx in in such a way that it propagates widely
207 2013-07-03 00:35:39 <BW^-> michagogo: what would a lowered relay policy be?
208 2013-07-03 00:36:03 <michagogo> BW^-: Well, older clients for example will relay txs with dust outputs
209 2013-07-03 00:36:11 <BW^-> michagogo: indeed if you knew the actual IP of the tobacconist's bitcoind as to broadcast to it directly, that would be completely convenient
210 2013-07-03 00:36:26 <michagogo> Say you include an output of a satoshi, 0.8.2+ clients won't relay
211 2013-07-03 00:36:38 PrimeStunna has quit (Ping timeout: 248 seconds)
212 2013-07-03 00:36:38 PrimeStunna_ is now known as PrimeStunna
213 2013-07-03 00:36:42 <BW^-> michagogo: aha, so you mean that version differences between bitcoind versions could help you get a certain propagation effect - yeah
214 2013-07-03 00:36:58 <michagogo> Among other things
215 2013-07-03 00:37:17 <michagogo> Anyway, for anything that you would lose too much money by giving away for free, you should wait for at least a confirmation
216 2013-07-03 00:37:27 <michagogo> And for anything significant, at least 2
217 2013-07-03 00:37:37 <BW^-> michagogo: and now, how is it, each bitcoind peer will accept the first transaction it received right.. or how is it? so if there's a peer N out there , it got the fraudlent transaction already and now some peer sends it the correct one, what happens?
218 2013-07-03 00:37:41 <BW^-> it just ignores it, doens't it?
219 2013-07-03 00:37:48 <michagogo> I believe so.
220 2013-07-03 00:37:59 robocoin has joined
221 2013-07-03 00:38:16 <BW^-> michagogo: what happens when the next block is generated, both spends (the valid and the invalid tx) should be discarded then.. what's this logics?
222 2013-07-03 00:38:18 <michagogo> One sec, let me find the wiki article that explains the exact validation steps
223 2013-07-03 00:38:29 <BW^-> right ,it's on bitcoin.it ..
224 2013-07-03 00:38:44 <michagogo> BW^-: Whichever transaction makes it into the blockchain is the final one
225 2013-07-03 00:38:56 <BW^-> michagogo: this https://en.bitcoin.it/wiki/Protocol_rules ?
226 2013-07-03 00:39:13 <michagogo> Indeed.
227 2013-07-03 00:39:30 <michagogo> So yeah, step 9 under tx messages
228 2013-07-03 00:40:00 <michagogo> And also see that note, #5
229 2013-07-03 00:40:16 <BW^-> michagogo: right. so.. this new block N comes in with a TX in it. so then, there's some logics in bitcoind to drop all mempooled transactions that become irrelevant or invalid because of this new block database content right?
230 2013-07-03 00:40:21 <BW^-> aha
231 2013-07-03 00:40:25 <michagogo> If both transactions do make to a miner, the miner can choose
232 2013-07-03 00:40:40 <michagogo> FOr example, the miner can be configured to prefer the one with the bigger fee
233 2013-07-03 00:41:34 <BW^-> michagogo: this would be a non-satoshi client/bitcoind -based miner right? i mean, because bitcoind always only accepts one+
234 2013-07-03 00:41:34 <BW^-> ?
235 2013-07-03 00:41:39 MobiusL has quit (Remote host closed the connection)
236 2013-07-03 00:41:51 <michagogo> BW^-: Right, or at least modified
237 2013-07-03 00:42:17 <michagogo> Vanilla satoshi will simply reject any TX that's a double spend of another, including in mempool
238 2013-07-03 00:42:37 MobiusL has joined
239 2013-07-03 00:42:47 <michagogo> Other clients or patched satoshi can do anything, as long as there's no double-spend within the blockchain
240 2013-07-03 00:43:07 <BW^-> right. interesting.
241 2013-07-03 00:43:59 <michagogo> [03:12:15] <BW^-> michagogo: right. so.. this new block N comes in with a TX in it. so then, there's some logics in bitcoind to drop all mempooled transactions that become irrelevant or invalid because of this new block database content right?
242 2013-07-03 00:43:59 <michagogo> I assume so, though that wiki article doesn't state it explicitly. (sipa?)
243 2013-07-03 00:44:16 <sipa> indeed
244 2013-07-03 00:44:49 <BW^-> so, a 'getblocks' always results in *one* inv response, and that *one* inv response will contain all the blocks in the longest chain known to the responding peer, starting with the block *right after* the block mentioned in "locator hashes" that is the highest one, and all way up to "stop hash" or 500 blocks, whichever comes first.
245 2013-07-03 00:45:17 <michagogo> Right
246 2013-07-03 00:45:24 wei_ has quit (Quit: wei_)
247 2013-07-03 00:45:39 PrimeStunna has quit (Read error: Connection reset by peer)
248 2013-07-03 00:45:46 <michagogo> (the highest one that the responding peer knows as part of the longest chain, that is)
249 2013-07-03 00:45:54 mrkent has quit (Ping timeout: 240 seconds)
250 2013-07-03 00:46:05 o3u has quit (Read error: Connection reset by peer)
251 2013-07-03 00:46:08 <BW^-> right
252 2013-07-03 00:47:04 <BW^-> could there theoretically be a state of the blockchain database messed up completely because there'd be approx equal PoW being made on more than one branch at the same time?
253 2013-07-03 00:47:08 <BW^-> what would the loss be in such a situation?
254 2013-07-03 00:47:34 <BW^-> so say there'd be three branches and each would have somewhere between 30 and 36% of the PoW all the time
255 2013-07-03 00:47:59 <BW^-> so thus, the nodes would constantly switch longest known branch constantly
256 2013-07-03 00:48:22 <BW^-> of course this is just a theoretical idea and will never happen ever, though it highlights the protocol aspect of:
257 2013-07-03 00:48:28 <BW^-> what would the permanent damage be? any?
258 2013-07-03 00:48:49 <BW^-> so, first off, 2/3 of the mining done would end up being worthless at some point
259 2013-07-03 00:48:53 o3u has joined
260 2013-07-03 00:49:24 <BW^-> what about transactions committed during such mess, when at some point one branch would show as "the winner", is there some kind of "self healing" somehow bringing over all transactions made, to the "winning" longest chain?
261 2013-07-03 00:49:27 <gmaxwell> BW^-: if they have "between 30 and 36%" then there is clearly one longest one.
262 2013-07-03 00:49:49 <gmaxwell> BW^-: do you mean what if there are three _absolutely equal_ longest tips?
263 2013-07-03 00:50:04 <BW^-> gmaxwell: yeah but if there's a variation all the time: right now 32:32:36, then 36:32:32, then 32:36:32 and they circulate like that all the time
264 2013-07-03 00:50:23 <BW^-> gmaxwell: that would be interesting to learn too!
265 2013-07-03 00:50:46 <michagogo> BW^-: That wouldn't happen, because the chances that a block would be found on all 3 branches at the same time is minicsule
266 2013-07-03 00:50:48 <BW^-> gmaxwell: what about that case, and then if there'd be some cyclical changes in which one of the existing ones is longest
267 2013-07-03 00:50:52 <michagogo> miniscule*
268 2013-07-03 00:51:08 <michagogo> Because all the blocks would propagate around the network
269 2013-07-03 00:51:15 <BW^-> anyhow - what are the self healing mechanisms found? so for instance, when that fork happened because of the 0.7/0.8 behavior difference,
270 2013-07-03 00:51:29 <michagogo> And miners would work on the longest chain they know about
271 2013-07-03 00:51:35 <BW^-> when it was eventually corrected, the transactions that were made on that "losing chain", were they somehow transfered over to the "winning chain"?
272 2013-07-03 00:51:41 <michagogo> BW^-: Yes.
273 2013-07-03 00:51:48 <Krellan> If a stub blockchain becomes orphaned (bitcoind switches to different blockchain that is higher), then what of the TX in the stub? Are they discarded, or are they returned to mempool, if they are different from the TX in the newly accepted blockchain?
274 2013-07-03 00:51:50 <BW^-> michagogo: using what logics did that self-healing take place?
275 2013-07-03 00:51:57 <michagogo> BW^-: The transactions were simply rebroadcast
276 2013-07-03 00:52:14 <BW^-> michagogo: what logics caused that?
277 2013-07-03 00:52:35 <michagogo> BW^-: The satoshi client automatically rebroadcasts wallet transactions, for one
278 2013-07-03 00:52:55 <michagogo> Krellan: AFAIK returned to mempool
279 2013-07-03 00:52:58 <BW^-> michagogo: but the satoshi client stops transmitting transactions after it got a couple of confirmations, doesn't it?
280 2013-07-03 00:53:30 <michagogo> BW^-: Right, but if a reorg happens, the transactions are no longer confirmed if they're not in the longest chain
281 2013-07-03 00:54:09 <michagogo> Krellan: https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages
282 2013-07-03 00:54:10 <BW^-> michagogo: so the satoshi client has built-in listeners in the "reorg" operation code, that says, from the branch we switched away from now, take all the transactions and put them in the mempool as to be included in this longer chian now?
283 2013-07-03 00:54:11 <michagogo> 18.5
284 2013-07-03 00:54:25 <Krellan> michiagogo: Thanks. It would be tough to reconcile TX between both competing branches of the blockchain, though. If TX is in conflict, it is dropped on the floor, but if TX is otherwise OK (but just not included in the new blockchain) then it is returned to mempool?
285 2013-07-03 00:54:49 <michagogo> Krellan: Look at step 5 of step 18
286 2013-07-03 00:55:05 <michagogo> BW^-: Look at step 5 of step 18 of https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages
287 2013-07-03 00:55:23 <gmaxwell> 17:22 < BW^-> gmaxwell: what about that case, and then if there'd be some cyclical changes in which one of the existing ones is longest
288 2013-07-03 00:55:30 o3u has quit (Ping timeout: 256 seconds)
289 2013-07-03 00:56:00 <gmaxwell> ^ no, in the case where you're saying there is not a "cylical change" nodes will run on the longest chain if there are three tips of different lengths then there is only one long est chain
290 2013-07-03 00:57:19 <Krellan> OK, great to know. So, an abandoned stub will have all of its transactions reprocessed against the winning blockchain, just as if they had been received over the network all over again.
291 2013-07-03 00:57:26 <michagogo> Krellan: yes
292 2013-07-03 00:57:27 <Krellan> Satoshi was a genius and thought it all through :)
293 2013-07-03 00:58:27 <michagogo> Right, what gmaxwell said. And like I mentioned, because blocks are broadcast across the network, when the longest (even if only by a block or two) block is inv'ed, each peer will either realize it's the best, or will see it as an orphan, and start inv'ing backwards until it meets the main chain and realized the new block is best
294 2013-07-03 00:58:30 EPiSKiNG- has quit (Read error: Operation timed out)
295 2013-07-03 00:58:46 wizkid057 has quit (Ping timeout: 252 seconds)
296 2013-07-03 00:58:58 EPiSKiNG- has joined
297 2013-07-03 00:59:00 EPiSKiNG- is now known as Guest90949
298 2013-07-03 00:59:20 xenland has quit (Quit: Konversation terminated!)
299 2013-07-03 01:00:08 <gmaxwell> BW^-: now, it's certantly possible to be tied.
300 2013-07-03 01:00:14 <gmaxwell> Nodes mine on the first best that they get.
301 2013-07-03 01:00:24 <gmaxwell> eventually one will become ahead.
302 2013-07-03 01:00:30 <gmaxwell> But it's perfectly possible to run in parallel for some time.
303 2013-07-03 01:00:50 <gmaxwell> Nodes that reorg off some chain will then reload any non-conflicted txn that fell out of the chain into their memorypools
304 2013-07-03 01:01:32 <michagogo> I wonder if such a tie has ever happened on more than a pair of chains
305 2013-07-03 01:02:10 <gmaxwell> ties are pretty rare.
306 2013-07-03 01:02:30 <michagogo> gmaxwell: I know, but I'm sure some have happened
307 2013-07-03 01:02:43 <michagogo> What I'm wondering is, has there ever been a 3-way tie
308 2013-07-03 01:02:49 <gmaxwell> Part of whats required to make the network converge is that the time between blocks makes persistant ties sufficiently infrequent that latency doesn't prevent convergence.
309 2013-07-03 01:03:07 <michagogo> Right, ofc
310 2013-07-03 01:03:13 <gmaxwell> michagogo: sure, ties happen every day.. about 1% of mined blocks get orphaned.
311 2013-07-03 01:03:21 <michagogo> 1%? Really?
312 2013-07-03 01:03:33 wizkid057 has joined
313 2013-07-03 01:03:39 <gmaxwell> so about 1/1000, or so, I'd guess would end up in a three way tie.
314 2013-07-03 01:03:45 <michagogo> gmaxwell: Do you have an example of 3 blocks at the same height found at the same time?
315 2013-07-03 01:03:53 macboz has joined
316 2013-07-03 01:04:09 <gmaxwell> michagogo: why would I? it's not like the data is well preserved.
317 2013-07-03 01:04:19 <michagogo> Hmm, just found http://blockchain.info/orphaned-blocks
318 2013-07-03 01:04:21 * michagogo looks
319 2013-07-03 01:04:56 <gmaxwell> michagogo: why are you surprised by 1%? it just requires a second block be found before the first is validated by the network.
320 2013-07-03 01:05:17 <michagogo> gmaxwell: Yeah, but if blocks are found every 10 minutes
321 2013-07-03 01:05:29 <michagogo> And it should only take a matter of seconds to propagate a block...
322 2013-07-03 01:05:53 <michagogo> (I mean, a 2-digit number I'm sure, but probably not more than 30, no?)
323 2013-07-03 01:05:58 <gmaxwell> so you can say... what is the CDF of the 10 minute exponential distribution below whatever the latency is for the whole network to recieve and validate block.
324 2013-07-03 01:06:08 <michagogo> CDF?
325 2013-07-03 01:06:30 tkolsto has quit (Ping timeout: 248 seconds)
326 2013-07-03 01:06:33 <Krellan> Nice, read that page of protocol rules. I'm surprised by footnote 5, that it would be "first seen transaction wins", instead of "highest TX fee wins". You'd think it would be possible to replay a transaction with a higher TX fee, in an effort to push it out to the network faster, if the user was unhappy with the speed of their transaction the first time.
327 2013-07-03 01:06:34 <gmaxwell> michagogo: on old software it was taking minutes in some cases.
328 2013-07-03 01:06:55 <michagogo> Ah, that would do it
329 2013-07-03 01:07:13 <michagogo> Krellan: That's not a protocol rule, as the note notes
330 2013-07-03 01:07:45 <michagogo> Krellan: Nodes are free to do whatever they want -- push out the lower for the newer, reject, even keep both
331 2013-07-03 01:07:59 <gmaxwell> michagogo: integral of the pdf.
332 2013-07-03 01:08:06 <michagogo> pdf?
333 2013-07-03 01:08:15 tkolsto has joined
334 2013-07-03 01:08:34 <michagogo> Krellan: And so if a miner gets both and one is a higher fee, the miner may choose to include the one with the higher fee
335 2013-07-03 01:08:37 hanti is now known as HANTI
336 2013-07-03 01:09:23 <michagogo> Krellan: Basically, as long as only one transaction spending a given output ends up in the blockchain, the network couldn't care less about which one propagates
337 2013-07-03 01:09:33 o3u has joined
338 2013-07-03 01:11:16 miscrean1ty has joined
339 2013-07-03 01:11:26 <Krellan> Nice, thanks. So only the winning miner would have to make this change to their selection technique. The other nodes would still see it as valid, and not reject the block or anything like that, because miner is allowed to make the choice.
340 2013-07-03 01:11:44 <michagogo> Hmm, interesting... there was an 11-block fork back in February
341 2013-07-03 01:12:11 <gmaxwell> Krellan: if they even heard the txn.
342 2013-07-03 01:12:25 <Krellan> OK, thanks.
343 2013-07-03 01:12:29 <michagogo> Krellan: Well, any nodes running unmodified Satoshi client code will reject the second transaction they see as a double-spend
344 2013-07-03 01:12:41 <Krellan> Ah that's the catch, then.
345 2013-07-03 01:12:52 <BW^-> is come guy with Enormous CPU power would create a longest chain starting with the genesis chain so there'd be a reorg over to that, then Many bitcoinds would crash because their memory pool would be so big that it'd be shut down by the OS, i mean, containing all these transactions made til now?
346 2013-07-03 01:12:54 Guest90949 has left ()
347 2013-07-03 01:13:02 EPiSKiNG- has joined
348 2013-07-03 01:13:11 <michagogo> Krellan: If a miner ends up seeing both of them somehow, and the miner's software is modified accordingly, it can keep both and use whichever it wants
349 2013-07-03 01:13:15 jtimon has quit (Ping timeout: 246 seconds)
350 2013-07-03 01:13:20 <BW^-> michagogo,gmaxwell: what do you mean by "tie"?
351 2013-07-03 01:13:24 stochasm has joined
352 2013-07-03 01:13:27 <warren> good luck with "Enormous CPU power"
353 2013-07-03 01:13:27 <michagogo> Krellan: And then whatever ends up in the blockchain is what's considered canonical
354 2013-07-03 01:13:32 <Krellan> Makes sense to me
355 2013-07-03 01:13:58 <michagogo> BW^-: In *theory*, yes, but such a feat is impossible
356 2013-07-03 01:14:07 miscreanity has quit (Ping timeout: 264 seconds)
357 2013-07-03 01:14:16 <michagogo> BW^-: A tie, when there are 2 blockchains of equal length
358 2013-07-03 01:15:01 <michagogo> BW^-: For example, if 2 people find block ,,calc[,,bc,blocks+1] at the same time
359 2013-07-03 01:15:01 <gribble> (calc <math expression>) -- Returns the value of the evaluated <math expression>. The syntax is Python syntax; the type of arithmetic is floating point. Floating point arithmetic is used in order to prevent a user from being able to crash to the bot with something like '10**10**10**10'. One consequence is that large values such as '10**24' might not be exact.
360 2013-07-03 01:15:02 <gribble> 244478
361 2013-07-03 01:15:04 <michagogo> er
362 2013-07-03 01:15:17 <michagogo> BW^-: For example, if 2 people find block [,,calc ,,bc,blocks+1] at the same time
363 2013-07-03 01:15:17 <gribble> (calc <math expression>) -- Returns the value of the evaluated <math expression>. The syntax is Python syntax; the type of arithmetic is floating point. Floating point arithmetic is used in order to prevent a user from being able to crash to the bot with something like '10**10**10**10'. One consequence is that large values such as '10**24' might not be exact.
364 2013-07-03 01:15:18 <gribble> 244478
365 2013-07-03 01:15:27 <michagogo> uh.
366 2013-07-03 01:15:43 <michagogo> If 2 people find block 244479 at the same time
367 2013-07-03 01:16:13 miscrean1ty has quit (Ping timeout: 268 seconds)
368 2013-07-03 01:16:19 miscreanity has joined
369 2013-07-03 01:16:30 owowo has quit (Ping timeout: 240 seconds)
370 2013-07-03 01:16:34 <michagogo> There will be a fork, with 2 blockchains of the same length
371 2013-07-03 01:16:54 <Krellan> I know it's bad to accept zero-confirmation TX as valid, but I was thinking of adding a Bitcoin acceptor to an arcade game (just as proof of concept)
372 2013-07-03 01:16:55 <BW^-> what's the max number of TX:es a block can hold? blocks would have a max byte size limit on them, no, and then it would be as many tx:es as fit within that total byte limit right?
373 2013-07-03 01:17:09 <michagogo> BW^-: Just about, yeah
374 2013-07-03 01:17:26 anarchy5 has joined
375 2013-07-03 01:17:30 <michagogo> BW^-: Actually, I think there might be a number limit as well as a bytesize limit, but I'm not sure
376 2013-07-03 01:18:09 <Krellan> and a thought: is it possible to have a "waiting period" just after receiving a TX, to see if any other TX come in from any other nodes, that might be trying to double-spend the coins in the first TX? Right now, bitcoind just silently drops this on the floor, without notifying.
377 2013-07-03 01:18:13 <michagogo> Krellan: For a non-prize-giving arcade game where there's no actual *loss* for a fraudulent play, should be fine I think
378 2013-07-03 01:18:34 wei_ has joined
379 2013-07-03 01:18:40 <michagogo> Krellan: A double-spend tx probably wouldn't make it to you in the first place, because most nodes will simply drop it as you said
380 2013-07-03 01:19:01 <Krellan> I was thinking a "waiting period" of around 2 seconds, just to try and defend against the hack of sending you one TX and sending many other nodes a different TX, in hope the miners pick up the different TX.
381 2013-07-03 01:19:02 <BW^-> Krellan: Nice, thanks. So only the winning miner would have to make this change to their selection technique. The other nodes would still see it as valid, and not reject the block or anything like that, because miner is allowed to make the choice.
382 2013-07-03 01:19:16 <BW^-> (ah, that was a quote by krellan - now my re:)
383 2013-07-03 01:19:32 <BW^-> Krellan: That would presume that the miner actually got all the transaction variants propagated up to it, so it would need to be connected well enough as to get those!
384 2013-07-03 01:19:38 <michagogo> Exactly.
385 2013-07-03 01:19:56 <BW^-> ] sipa: that's why you have 8 outgoing connections
386 2013-07-03 01:20:04 <michagogo> Most nodes will simply drop a transaction that they see as a double-spend
387 2013-07-03 01:20:10 <BW^-> wait, a bitcoind has more than 8 connections to other peer sby default, right???
388 2013-07-03 01:20:13 <BW^-> not??
389 2013-07-03 01:20:18 <BW^-> 8 is really little!
390 2013-07-03 01:20:31 <michagogo> BW^-: It can, but I think it only actively tries to form more connections if it has <8
391 2013-07-03 01:20:49 <michagogo> For example, I have 8 right now
392 2013-07-03 01:21:08 <michagogo> If someone else connects to me, I'll have 9, but my client isn't going to go hunting for more peers
393 2013-07-03 01:21:20 <BW^-> ] warren: good luck with "Enormous CPU power"
394 2013-07-03 01:21:41 <BW^-> what about some quantum computer or something. anyhow yeah that's like beyond only a theoretical idea, at least by all known today.
395 2013-07-03 01:21:57 <michagogo> BW^-: Quantum computers can barely add 2+2
396 2013-07-03 01:22:16 <Krellan> yes, it's an exploit against the "first come first serve" of the Satoshi client
397 2013-07-03 01:22:42 Muis_ has joined
398 2013-07-03 01:22:54 <michagogo> BW^-: Not to mention, if it were possible to do SHA256s quickly on a quantum computer, it's a safe bet honest miners would also use them
399 2013-07-03 01:23:03 owowo has joined
400 2013-07-03 01:23:12 <Krellan> the idea is that if attacker learns what nodes you are connected to, he can send you the fake TX first, then send all other nodes the real TX just a fraction of a second later, so that your client remembers the fake TX, but everybody else in the Bitcoin world remembers the real TX.
401 2013-07-03 01:23:33 <michagogo> Right.
402 2013-07-03 01:23:38 <Krellan> hence my thought about the "waiting period".
403 2013-07-03 01:24:05 <michagogo> Krellan: In theory that could help mitigate that one single attack
404 2013-07-03 01:24:11 Gnaf_ has joined
405 2013-07-03 01:24:31 <michagogo> Krellan: But for something like an arcade game where it's not high-value, you don't really need confirmations so much
406 2013-07-03 01:25:11 digitalmagus2 has joined
407 2013-07-03 01:25:11 digitalmagus2 has quit (Changing host)
408 2013-07-03 01:25:11 digitalmagus2 has joined
409 2013-07-03 01:25:20 a_meteorite has quit (Ping timeout: 343 seconds)
410 2013-07-03 01:25:21 digitalmagus has quit (Ping timeout: 343 seconds)
411 2013-07-03 01:25:26 Gnaf has quit (Write error: Connection reset by peer)
412 2013-07-03 01:25:44 <michagogo> (though ideally, if the game rewards prizes or tickets or something, it would be good to make those revocable just in case)
413 2013-07-03 01:26:06 <Krellan> True. I read the "Double-spending" Wiki, that talks about the problem more.
414 2013-07-03 01:26:24 <BW^-> michagogo: what about if it's the sale of a donut that you actually paid a supplier for?
415 2013-07-03 01:26:41 <Krellan> The game, being of low value, I could throttle the rate at which it gets credited up. If there's a problem, I can stop adding credits.
416 2013-07-03 01:26:50 a_meteorite has joined
417 2013-07-03 01:26:58 <BW^-> ] Krellan: the idea is that if attacker learns what nodes you are connected to, he can send you the fake TX first, then send all other nodes the real TX just a fraction of a second later, so that your client remembers the fake TX, but everybody else in the Bitcoin world remembers the real TX.
418 2013-07-03 01:27:14 a_meteorite is now known as Guest68652
419 2013-07-03 01:27:16 <michagogo> BW^-: Well, it all comes down to "are you willing to trade the security of confirmations for the convenience of speed?"
420 2013-07-03 01:27:29 BTC_Bear has quit (hbrntng!~BTC_Bear@unaffiliated/btc-bear/x-5233302|Ping timeout: 248 seconds)
421 2013-07-03 01:27:29 Muis has quit (Ping timeout: 248 seconds)
422 2013-07-03 01:27:31 <BW^-> so, there is a strategic value in having others *not know* the IP of your bitcoind installation
423 2013-07-03 01:27:34 FabianB has joined
424 2013-07-03 01:27:34 <Krellan> Hence my desire for a little window of time in which to listen to the network and get notifications if there was an attempted double-spend, instead of just the default behavior of "first come first serve, then silently drop all others on the floor without telling anybody about it".
425 2013-07-03 01:27:35 <BW^-> \wallet\
426 2013-07-03 01:27:48 starsoccer_ has joined
427 2013-07-03 01:28:08 <BW^-> i mean, if you have a store "itobbaconist.com" that accept bitcoins, then *DON'T* run your bitcoind directly on that public ip, because that would make you completely exposed to double spends
428 2013-07-03 01:28:16 <michagogo> Krellan: Sure, you could patch bitcoind to disable relaying of received transactions and do something if a doublespend is detected
429 2013-07-03 01:28:27 pjorrit_ has joined
430 2013-07-03 01:28:28 Eiii has quit (Read error: Connection reset by peer)
431 2013-07-03 01:28:28 <BW^-> someone just connects to your bitcoind and gives it the one transaction, and then spreads the other transaction to everyone else
432 2013-07-03 01:28:29 <BW^-> right?
433 2013-07-03 01:28:37 <Krellan> yes, that would be how the attack works
434 2013-07-03 01:28:40 paybitcoin1 has joined
435 2013-07-03 01:28:49 <BW^-> that's a great reason to run bitcoind over Tor!!!!
436 2013-07-03 01:28:53 starsoccer has quit (Ping timeout: 246 seconds)
437 2013-07-03 01:28:54 FabianB_ has quit (Ping timeout: 246 seconds)
438 2013-07-03 01:28:54 pjorrit has quit (Ping timeout: 246 seconds)
439 2013-07-03 01:28:54 paybitcoin has quit (Ping timeout: 246 seconds)
440 2013-07-03 01:28:59 winterblack has joined
441 2013-07-03 01:29:01 enquirer2 has quit (Ping timeout: 246 seconds)
442 2013-07-03 01:29:05 <michagogo> Krellan: Well, on the one hand, you want the transaction paying you to propagate, so you'd want to relay it
443 2013-07-03 01:29:14 <BW^-> ..given that the merchant accepts zero-transaction purchases of course.
444 2013-07-03 01:29:16 <BW^-> interesting!!!!
445 2013-07-03 01:29:18 <Krellan> I wouldn't patch to disable relaying, I'd keep network behaviour the same, but I would rather like to add notifications of attempted problems with TX that are affecting my wallet.
446 2013-07-03 01:29:21 blaeks has quit (Ping timeout: 246 seconds)
447 2013-07-03 01:29:26 Gnaf has joined
448 2013-07-03 01:29:26 Grishnakh_ has joined
449 2013-07-03 01:29:30 <michagogo> But OTOH, once you relay it, other peers won't accept and therefore won't relay a double-spend of it
450 2013-07-03 01:29:37 Eiii has joined
451 2013-07-03 01:29:37 Eiii has quit (Changing host)
452 2013-07-03 01:29:37 Eiii has joined
453 2013-07-03 01:29:49 <michagogo> BW^-: If it's just a donut then sure, it's a loss, but a small one, that you could probably just write off
454 2013-07-03 01:29:56 <Krellan> If a notification happens, then my app falls back to waiting for confirmations. Then, worst that can happen is customer has to wait 10 minutes to get their credit.
455 2013-07-03 01:30:03 MobGod has quit (Ping timeout: 246 seconds)
456 2013-07-03 01:30:04 chax has joined
457 2013-07-03 01:30:13 patcon has quit (Remote host closed the connection)
458 2013-07-03 01:30:17 <michagogo> Right, but if you relay, then the moment you relay any peer you
459 2013-07-03 01:30:18 <Krellan> in the common case, I could still accept instantly fast, because (I assume) most customers wouldn't try to double-spend.
460 2013-07-03 01:30:22 blaeks has joined
461 2013-07-03 01:30:26 <michagogo> 're connected to won't relay a double-spend to you
462 2013-07-03 01:30:26 <BW^-> michagogo: so, such a merchant should run so noone knows his bitcoind's IP right?
463 2013-07-03 01:30:28 <BW^-> such as, over Tor?
464 2013-07-03 01:30:36 <michagogo> BW^-: That would be good
465 2013-07-03 01:30:37 o3u_ has joined
466 2013-07-03 01:30:42 <BW^-> very interesting
467 2013-07-03 01:30:45 <michagogo> Though tor is probably not necessary
468 2013-07-03 01:30:45 enquirer has joined
469 2013-07-03 01:30:46 patcon has joined
470 2013-07-03 01:30:49 aspect___ has joined
471 2013-07-03 01:31:02 <michagogo> BW^-: For a single donut you could probably not require any confirmations
472 2013-07-03 01:31:08 FluffySh1ap has joined
473 2013-07-03 01:31:19 <michagogo> But for amount over, say, a couple dollars equivalent, require at least a confirmation
474 2013-07-03 01:31:29 toffoo_ has joined
475 2013-07-03 01:31:40 Pucilowski_ has joined
476 2013-07-03 01:31:40 digitalmagus has joined
477 2013-07-03 01:31:40 digitalmagus has quit (Changing host)
478 2013-07-03 01:31:40 digitalmagus has joined
479 2013-07-03 01:31:50 hsmiths2 has joined
480 2013-07-03 01:31:55 <michagogo> Anything you want to be fairly confident in, 2 confs, and once you're at 3+ you're most likely safe
481 2013-07-03 01:32:15 gribble has quit (Disconnected by services)
482 2013-07-03 01:32:21 <michagogo> o_O
483 2013-07-03 01:32:26 agricocb has quit (Quit: Leaving.)
484 2013-07-03 01:32:26 <Krellan> That's the idea, a cutoff on the value, so low risk would be accepted instantly: in my case, something like that has to be done anyway, because the arcade game requires time to mechanically get credited up (relay to close switch then reopen it).
485 2013-07-03 01:32:47 <michagogo> Right.
486 2013-07-03 01:33:18 <michagogo> Krellan: Though, as I mentioned, it's a problem to try to listen for double-spend transactions
487 2013-07-03 01:33:39 <Krellan> At TX received time, I start coining up the arcade game. Then, if there's a problem notified, I stop coining up. Higher value gives me more time to recognize problem, since I have to coin up the game slowly anyway.
488 2013-07-03 01:33:51 <michagogo> Because if you don't relay the paying-you tx, it may not get anywhere,
489 2013-07-03 01:33:51 brocktic1 has joined
490 2013-07-03 01:33:55 flound1139 has joined
491 2013-07-03 01:33:57 a_meteor has joined
492 2013-07-03 01:33:57 saivann__ has joined
493 2013-07-03 01:34:00 dugo_ has joined
494 2013-07-03 01:34:04 dub_ has joined
495 2013-07-03 01:34:17 mhanne_ has joined
496 2013-07-03 01:34:18 gribble has joined
497 2013-07-03 01:34:20 a_meteor is now known as Guest50559
498 2013-07-03 01:34:30 <michagogo> Krellan: But if you do relay it, any node you relay to will be ~guaranteed to not relay a double-spend to you
499 2013-07-03 01:34:46 <michagogo> Because they will have seen the paying-you tx
500 2013-07-03 01:34:54 patcon has quit (Ping timeout: 240 seconds)
501 2013-07-03 01:35:04 <Krellan> maybe I could slow down the relaying of the good TX, giving some more time in which to receive a possible double-spend attempt.
502 2013-07-03 01:35:12 <michagogo> Unless you patch the code to only relay transactions to 50% of nodes or something
503 2013-07-03 01:35:19 <michagogo> Krellan: Yeah, but that can backfire
504 2013-07-03 01:35:53 <michagogo> Krellan: Since a tx can make it across the network in seconds, if you wait, the other tx might be widewpread enough to block out the legit one
505 2013-07-03 01:36:00 <Krellan> Or have a "listening post" elsewhere on the network, that would notify my app independently whenever it sees a TX that affects me. That at least lets me compare network propagation.
506 2013-07-03 01:36:01 Belkaar has quit (Ping timeout: 256 seconds)
507 2013-07-03 01:36:17 <michagogo> Krellan: That may help.
508 2013-07-03 01:36:19 kinlo_ has joined
509 2013-07-03 01:37:37 LordOfTime has joined
510 2013-07-03 01:37:46 <Krellan> Probably that's the best solution for now: establish a few "listening posts" (just other bitcoind instances running with a different set of peers), and compare incoming payments with them, to make sure most of the network has heard my payment, and not the double-spend.
511 2013-07-03 01:37:52 kantlive- has joined
512 2013-07-03 01:37:56 stochasm- has joined
513 2013-07-03 01:38:05 <michagogo> Krellan: Also, consider this: Do you expect the target audience for an arcade game to be scammers with the technical knowledge to pull off a double-spend?
514 2013-07-03 01:38:14 <BW^-> michagogo: well, if you run 0-confirmation sales, a potential attacker must not be able to connect to you directly - and for that using tor would be very practical as it's free and requires no accounts or alike
515 2013-07-03 01:38:19 <BW^-> so all these minor single-block forks that happen all the time in the blockchain - does it always happen with them, that the miner who made the block that shows to be "losing", actually loses the reward?
516 2013-07-03 01:38:29 <Krellan> Such a thing already exists, right? I saw reference to those kinds of services somewhere.
517 2013-07-03 01:38:35 stochasm- has quit (Max SendQ exceeded)
518 2013-07-03 01:38:43 Belkaar has joined
519 2013-07-03 01:38:50 <michagogo> BW^-: You could just not have your address public
520 2013-07-03 01:38:51 zerogravity has quit (Ping timeout: 256 seconds)
521 2013-07-03 01:39:10 <BW^-> michagogo: bitcoin address or IP?
522 2013-07-03 01:39:16 <michagogo> the latter
523 2013-07-03 01:39:30 <Krellan> I saw the guidelines (limit connections, do not accept inbound, etc.) for accepting 0-confirmation TX. Running in Tor is also a good idea, for the same reason.
524 2013-07-03 01:40:05 <michagogo> Considering how many nodes there are, it would probably be unlikely to stumble upon your address. Also hard to identify as you. Also what Krellan
525 2013-07-03 01:40:06 <michagogo> said
526 2013-07-03 01:40:30 Guest68593 has joined
527 2013-07-03 01:40:31 <BW^-> michagogo: yeah. so for a retail merchant that would work, but for a web site like "itobacconist.com" it would be much more difficult!
528 2013-07-03 01:40:33 LordOfTime is now known as LordOfTime|EC2
529 2013-07-03 01:40:33 Benjojo has quit (Ping timeout: 256 seconds)
530 2013-07-03 01:40:34 <Krellan> Thanks for all advice. As for target audience for an arcade game, it depends on where the arcade game is placed. Wanted to site it at the Bitcoin convention in San Jose in May....
531 2013-07-03 01:40:36 <michagogo> BW^-: Also, note that when a tx is relayed to you, you immediately broadcast it to *your* nodes
532 2013-07-03 01:40:55 <michagogo> BW^-: Not really, just get a different IP address
533 2013-07-03 01:41:00 <BW^-> michagogo: if you use another IP for your bitcoin installation, then even so it'd for sur ebe in the same /24 or /22 block and an attacker could scan all those IP:s for a bitcoin installation -
534 2013-07-03 01:41:07 pecket has joined
535 2013-07-03 01:41:07 Transisto has joined
536 2013-07-03 01:41:07 variousnefarious has joined
537 2013-07-03 01:41:07 stochasm has joined
538 2013-07-03 01:41:07 jeremias has joined
539 2013-07-03 01:41:07 <michagogo> BW^-: Not necessarily
540 2013-07-03 01:41:07 weex has quit (Ping timeout: 256 seconds)
541 2013-07-03 01:41:16 <michagogo> BW^-: Use a different host
542 2013-07-03 01:41:24 <BW^-> michagogo: any matches there have a high probability of being it
543 2013-07-03 01:41:44 <BW^-> michagogo: yeah, but that would require payments for a VPN service or something - in that case using Tor is so much mor eplug n play
544 2013-07-03 01:41:49 weex has joined
545 2013-07-03 01:41:49 weex has quit (Changing host)
546 2013-07-03 01:41:49 weex has joined
547 2013-07-03 01:42:13 <BW^-> krellan: ah - just not accepting inbound connections!
548 2013-07-03 01:42:26 <BW^-> michagogo,krellan: right - just not accepting inbound connections works as a full answer!
549 2013-07-03 01:42:43 <michagogo> Well, mostly
550 2013-07-03 01:42:53 <michagogo> I mean, you could always happen to stumble upon an attacker
551 2013-07-03 01:43:00 patcon has joined
552 2013-07-03 01:43:14 <BW^-> though that does make the node slightly less valuable in the big picture, i mean, it won't allow others to connect to it
553 2013-07-03 01:43:23 fronti has quit (Ping timeout: 256 seconds)
554 2013-07-03 01:43:23 troc has quit (Ping timeout: 256 seconds)
555 2013-07-03 01:43:30 <michagogo> Right, but in this case you're running it for yourself
556 2013-07-03 01:43:34 <BW^-> so won't contribute to others' bootstrapping peers
557 2013-07-03 01:43:43 <michagogo> Not solely to help the netwprk
558 2013-07-03 01:43:45 <BW^-> so it works only if a limited % of bitcoin users do that
559 2013-07-03 01:43:57 BitCoroner has quit (Ping timeout: 256 seconds)
560 2013-07-03 01:44:12 fronti has joined
561 2013-07-03 01:44:25 BitCoroner has joined
562 2013-07-03 01:44:31 jeremias has quit (Ping timeout: 256 seconds)
563 2013-07-03 01:44:52 <BW^-> interesting stuff.
564 2013-07-03 01:45:08 <BW^-> (repeat:) so all these minor single-block forks that happen all the time in the blockchain - does it always happen with them, that the miner who made the block that shows to be "losing", actually loses the reward?
565 2013-07-03 01:45:22 jeremias has joined
566 2013-07-03 01:45:29 <BW^-> so ~1% of rewards are lost?
567 2013-07-03 01:46:00 <BW^-> now that ~1% of new block generations happen to be "forking" and shortly get to be ignored
568 2013-07-03 01:46:05 altgribble has quit (Remote host closed the connection)
569 2013-07-03 01:46:17 altgribble has joined
570 2013-07-03 01:46:23 troc has joined
571 2013-07-03 01:47:31 freewil has joined
572 2013-07-03 01:47:31 MKCoin has joined
573 2013-07-03 01:47:54 melvster_ has quit (Ping timeout: 240 seconds)
574 2013-07-03 01:48:06 Benjojo has joined
575 2013-07-03 01:48:30 poggy has joined
576 2013-07-03 01:48:38 <BW^-> https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages block propagation rule number 5: "5. Block timestamp must not be more than two hours in the future "
577 2013-07-03 01:48:58 <BW^-> so, badly configured timezone setting on local note could completely mess its bitcoind up
578 2013-07-03 01:49:04 <BW^-> as to be completely disfunctional
579 2013-07-03 01:49:08 <michagogo> BW^-: Correct and correct.
580 2013-07-03 01:49:36 <michagogo> BW^-: Any block that isn't part of the main chain, by definition, doesn't have its coinbase as part of the main chain
581 2013-07-03 01:49:49 <michagogo> BW^-: And therefore can't be spent in the main chain.
582 2013-07-03 01:49:56 <BW^-> wow. that would be good to have an automatic check for in bitcoind, so that if bitcoind suspects that is the case based on network input, it prints it out to debug log/console
583 2013-07-03 01:50:24 <michagogo> BW^-: That's why coinbases need 100 confirmations before they can be spent
584 2013-07-03 01:50:39 <michagogo> (and the satoshi client actually enforces 120 confirmations)
585 2013-07-03 01:54:03 <BW^-> new blocks are "gossiped" through the network through spontaneous propagation of "inv" of the new block, originating all from the miner that generated the block and "inv":ed it to its peers?
586 2013-07-03 01:54:43 mrkent has joined
587 2013-07-03 01:55:43 mrkent has quit (Max SendQ exceeded)
588 2013-07-03 01:56:07 mrkent has joined
589 2013-07-03 01:56:08 <michagogo> Yes
590 2013-07-03 01:56:42 <michagogo> When a miner finds a block, it sends inv messages to all its peers, and the peers respond with getdata, and the miner responds with block
591 2013-07-03 01:57:02 <michagogo> And then all those peers repeat the process, sending invs to all their peers, etc
592 2013-07-03 02:01:08 dan_ has quit (Remote host closed the connection)
593 2013-07-03 02:01:26 <BW^-> in bitcoind, when I've sent a transaction, there is an automatic counting of how many confirmations it got right, namely: locate the block in which it is stored, and then use the block count between that one and up to the newest block, as number of confirmations
594 2013-07-03 02:01:43 <michagogo> Yeah
595 2013-07-03 02:01:58 <BW^-> michagogo: is there any easy internal code for looking ths up, in bitcoind?
596 2013-07-03 02:02:04 <BW^-> some method/procedure/alike
597 2013-07-03 02:02:24 <michagogo> BW^-: I don't know where exactly in the code it is
598 2013-07-03 02:02:30 <BW^-> hooking in to the listening for new block should be quite straightforward
599 2013-07-03 02:03:00 <BW^-> so then just, if there's some transaction you're "tracking" confirmations for, what's the best practice way for actually doing that check now when this event trigged
600 2013-07-03 02:03:01 <BW^-> mhm
601 2013-07-03 02:03:28 <BW^-> i believe i saw an automated transaction statement in JSON generated by bitcoind before, that showed number of transactions, like a really high one like 900
602 2013-07-03 02:03:39 <michagogo> Maybe something relating to https://github.com/bitcoin/bitcoin/blob/74e4d80068f9c29d4891439332b4027328c8584b/src/qt/transactionrecord.h ?
603 2013-07-03 02:03:49 <michagogo> er, https://github.com/bitcoin/bitcoin/blob/master/src/qt/transactionrecord.h
604 2013-07-03 02:04:27 <BW^-> right, here we go, the "gettransaction" JSON RPC call has a return value ""confirmations" : number of confirmations of the transaction"
605 2013-07-03 02:06:20 <michagogo> result.push_back(Pair("confirmations", (int)txGen.GetDepthInMainChain()));
606 2013-07-03 02:07:23 <michagogo> BW^-: https://github.com/bitcoin/bitcoin/blob/master/src/main.h#L478 , maybe
607 2013-07-03 02:07:47 <michagogo> (note that I'm not good with c++, I may be misreading)
608 2013-07-03 02:08:00 <BW^-> int GetDepthInMainChain() const { CBlockIndex *pindexRet; return GetDepthInMainChain(pindexRet); }
609 2013-07-03 02:08:32 <BW^-> brings us to main.cpp:1020
610 2013-07-03 02:12:11 <BW^-> michagogo: yeah it's there, so apparently that does it
611 2013-07-03 02:13:13 laround has joined
612 2013-07-03 02:14:50 michagogo has quit (Ping timeout: 256 seconds)
613 2013-07-03 02:14:51 Tantadruj has joined
614 2013-07-03 02:17:18 patcon has quit (Ping timeout: 246 seconds)
615 2013-07-03 02:21:46 ltcbtc has joined
616 2013-07-03 02:22:16 dub_ is now known as dub
617 2013-07-03 02:22:39 swulf--2 has joined
618 2013-07-03 02:24:28 swulf-- has quit (Ping timeout: 256 seconds)
619 2013-07-03 02:26:10 <BW^-> hm, so MAX_OUTBOUND_CONNECTIONS is 8 by default, and the Keep-Alive message interval is hardcoded to 30 minutes (main.cpp:3946)
620 2013-07-03 02:26:40 <BW^-> there are several usecases that would benefit from those being configurable.
621 2013-07-03 02:26:47 <BW^-> to higher values.
622 2013-07-03 02:26:54 <BW^-> em, the first one higher, the other one lower.
623 2013-07-03 02:27:20 <gmaxwell> No, increasing outbound connections would not be beneficial.
624 2013-07-03 02:28:25 <BW^-> gmaxwell: why not? what if you're in an unreliable network environment and all 8 of them go down without you knowing it - in this case it might take 30 minutes before you realize!
625 2013-07-03 02:28:29 <BW^-> main.cpp:3961: // Except during reindex, importing and IBD, when old wallet
626 2013-07-03 02:28:32 <BW^-> what's IBD?
627 2013-07-03 02:28:44 <gmaxwell> and the keepalive interval will be 30 seconds, though it's mostly pointless because normal traffic is more often than that.
628 2013-07-03 02:29:30 <BW^-> gmaxwell: is it 30 seconds?
629 2013-07-03 02:29:37 <BW^-> main.cpp:3946: if (pto->nLastSend && GetTime() - pto->nLastSend > 30 * 60 && pto->vSendMsg.empty()) {
630 2013-07-03 02:29:49 <gmaxwell> BW^-: _will be_
631 2013-07-03 02:29:51 <BW^-> ah
632 2013-07-03 02:29:56 <BW^-> gmaxwell: a pending commit?
633 2013-07-03 02:29:59 <gmaxwell> BW^-: but your mental model for how it works is incorrect.
634 2013-07-03 02:30:18 <gmaxwell> BW^-: TCP will notice that the connection went down in two minutes and tear it down.
635 2013-07-03 02:30:22 fanquake has joined
636 2013-07-03 02:30:36 <BW^-> gmaxwell: only if the socket has FD_KEEPALIVE or alike set?
637 2013-07-03 02:30:52 <BW^-> gmaxwell: TCP was specifically designed for connections to survive *long* network downtimes
638 2013-07-03 02:30:59 anarchy5 has joined
639 2013-07-03 02:31:01 <gmaxwell> And this works reliably, I interupt the network on my host 2-6 times per day and its always connected within a couple of minutes of being back online.
640 2013-07-03 02:32:56 <BW^-> aha nice anyhow that it's going down to a lower value (30sec) in a future version
641 2013-07-03 02:32:56 <BW^-> gmaxwell: if it's a sensitive application, connecting to more than 8 peers would decrease the possibility of connecting to a broken peer further also, wouldn't it?
642 2013-07-03 02:33:44 <BW^-> i mean, if you're in a situation where you absolutely need it to work, then you would want to counteract a scenario of being connected to broken peers only..
643 2013-07-03 02:33:55 <BW^-> that's a bit theoretical of course also..
644 2013-07-03 02:34:13 <gmaxwell> BW^-: Go do the math. say you have a 1% chance of a broken peer. 1%^8 is 1e-16.
645 2013-07-03 02:34:14 <BW^-> though for instance, over Tor connections can freeze-die
646 2013-07-03 02:34:40 mrkent has quit (Ping timeout: 240 seconds)
647 2013-07-03 02:35:15 ltcbtc has quit (Quit: latez)
648 2013-07-03 02:35:16 <gmaxwell> On the flip sideâ more than a handfull of hosts turning that up "for good measure" could utterly run the network out of listening sockets. If you want more connections: listen.
649 2013-07-03 02:35:30 owowo has quit (Ping timeout: 240 seconds)
650 2013-07-03 02:36:11 <gmaxwell> we've run very close to running out of sockets a couple times in the past, tor nodes in particular get a ton of inbounds. And with multibit soon to be promoted over bitcoin-qt for desktop systems its likely to get a lot worse.
651 2013-07-03 02:36:13 <BW^-> gmaxwell: hm. good points both. re listening more - that welcomes simple bitcoin clients that want to listen only and don't broadcast anything though, so would increase possibility of peers broken for your purpose?
652 2013-07-03 02:36:45 <BW^-> hmhm interesting
653 2013-07-03 02:36:54 <gmaxwell> BW^-: exponentiation is a marvelous thing.
654 2013-07-03 02:39:25 <phantomcircuit> there really needs to be a pretty significant change in the network structure to make that less of a problem
655 2013-07-03 02:39:49 <phantomcircuit> actually i think the default max could be increased significantly now
656 2013-07-03 02:39:53 <phantomcircuit> recent network changes
657 2013-07-03 02:40:02 <phantomcircuit> networking code changes*
658 2013-07-03 02:40:12 <BW^-> in the current version, there is no logic that ensure that bitcoind always has some number of outbound connections, is it?
659 2013-07-03 02:40:36 <BW^-> i mean, i see logics that check the number of inbound + outbound ones available and opening outbound ones if it's too low, and declining inbound ones if it's too high
660 2013-07-03 02:40:45 <phantomcircuit> BW^-, yeah there is it tries to maintain 8 outbound connections
661 2013-07-03 02:40:53 <gmaxwell> BW^-: no, it maintains 8 outbound connections.
662 2013-07-03 02:41:09 freewil has quit (Quit: Leaving)
663 2013-07-03 02:41:32 <gmaxwell> Your peers choose to connect to you, allowing someone to isolate you would be a significant security problem.
664 2013-07-03 02:43:23 <BW^-> gmaxwell,: yeah
665 2013-07-03 02:43:32 <BW^-> gmaxwell,phantomcircuit: where in the code is the logic for that? just curious
666 2013-07-03 02:43:42 <BW^-> searching for MAX_OUTBOUND_CONNECTIONS in net.cpp shows to places that don't look related to this to me
667 2013-07-03 02:43:54 Subo1978 has joined
668 2013-07-03 02:44:16 <phantomcircuit> ThreadOpenConnections
669 2013-07-03 02:44:19 <phantomcircuit> or something liek that
670 2013-07-03 02:44:26 Subo1978_ has quit (Remote host closed the connection)
671 2013-07-03 02:44:48 owowo has joined
672 2013-07-03 02:46:19 <BW^-> phantomcircuit: ah
673 2013-07-03 02:46:51 roconnor_ has joined
674 2013-07-03 02:52:44 Guest50559 has left ()
675 2013-07-03 02:57:55 roconnor has quit (Remote host closed the connection)
676 2013-07-03 02:59:13 wamatt has quit (Quit: wamatt)
677 2013-07-03 02:59:17 anarchy5 has quit (Quit: Textual IRC Client: www.textualapp.com)
678 2013-07-03 03:01:14 wamatt has joined
679 2013-07-03 03:04:51 MobGod has joined
680 2013-07-03 03:04:56 MobGod has quit (Changing host)
681 2013-07-03 03:04:56 MobGod has joined
682 2013-07-03 03:05:53 <BW^-> how do SPV nodes respond to blockchain download requests (ie 'getblocks', 'getheaders', 'getdata')?
683 2013-07-03 03:06:49 <BW^-> even if pointless in the bigger picture, there could be some use in having logics for a "pre-confirmation", consisting of that you get gossipped back to you a transaction you commited to the network?
684 2013-07-03 03:07:00 k9quaint has quit (Quit: Leaving)
685 2013-07-03 03:07:09 <BW^-> i mean, that does show that there are at least a number of other peers that do agree that your transaction is valid
686 2013-07-03 03:08:13 <phantomcircuit> BW^-, they dont
687 2013-07-03 03:08:15 <BW^-> which is a quite strong hint that your transaction is valid - compared with just blindly shooting away a transaction and presuming it's valid, that is a quite strong indicator of probability of validity - even though of course 1-2 real confirmations is the only hard value
688 2013-07-03 03:08:37 <phantomcircuit> there's a bitfield in the version message that's used to show capabilities
689 2013-07-03 03:08:37 <BW^-> phantomcircuit: you could find some peers to connect to and send to them, that are other peers than those your bitcoind are connected to
690 2013-07-03 03:08:53 <BW^-> phantomcircuit: aha. what about?
691 2013-07-03 03:09:05 <phantomcircuit> you dont ask an spv node for getblocks because they dont set the network node flag
692 2013-07-03 03:09:18 <BW^-> aha
693 2013-07-03 03:09:58 <BW^-> phantomcircuit: ah right, "1 NODE_NETWORK This node can be asked for full blocks instead of just headers"
694 2013-07-03 03:10:24 <BW^-> phantomcircuit: ah right, and if a SPV node gets a 'getheaders' then it should indeed be able to respond as well as any node :)
695 2013-07-03 03:11:07 <phantomcircuit> BW^-, right but if they get a getblock request they can just ignore it
696 2013-07-03 03:11:28 <BW^-> exactly - right noted.
697 2013-07-03 03:13:06 ralphtheninja has quit (Ping timeout: 252 seconds)
698 2013-07-03 03:16:29 HM2 has quit (Ping timeout: 245 seconds)
699 2013-07-03 03:18:33 jgarzik has joined
700 2013-07-03 03:18:48 <jgarzik> evenin'
701 2013-07-03 03:19:39 <jgarzik> change? change? can anybody spare someone testnet3 coins? mmyipXKsbZVyRBzKa3uKmw3WWU1jkaoM92
702 2013-07-03 03:20:09 graingert has joined
703 2013-07-03 03:21:40 HM has joined
704 2013-07-03 03:25:32 patcon has joined
705 2013-07-03 03:28:21 malaimo has quit (Ping timeout: 246 seconds)
706 2013-07-03 03:29:52 [7] has quit (Disconnected by services)
707 2013-07-03 03:30:01 TheSeven has joined
708 2013-07-03 03:30:25 malaimo has joined
709 2013-07-03 03:30:57 patcon has quit (Ping timeout: 256 seconds)
710 2013-07-03 03:33:21 paracyst has quit ()
711 2013-07-03 03:35:44 paracyst has joined
712 2013-07-03 03:38:54 brson has quit (Quit: leaving)
713 2013-07-03 03:40:45 roconnor_ has quit (Remote host closed the connection)
714 2013-07-03 03:41:28 dan_ has joined
715 2013-07-03 03:49:47 Tantadruj has quit (Quit: DoubleRecall Turns Paywalls Into Advertising Dollars - NYTimes.com http://nyti.ms/odHOgy)
716 2013-07-03 03:49:51 enquirer2 has joined
717 2013-07-03 03:49:57 enquirer has quit (Ping timeout: 252 seconds)
718 2013-07-03 03:51:29 graingert has quit (Quit: Ex-Chat)
719 2013-07-03 03:52:58 enquirer has joined
720 2013-07-03 03:53:26 Krellan has quit (Ping timeout: 256 seconds)
721 2013-07-03 03:54:23 enquirer2 has quit (Ping timeout: 252 seconds)
722 2013-07-03 03:59:38 <jgarzik> thanks
723 2013-07-03 03:59:46 <jgarzik> have testnet coins
724 2013-07-03 04:01:32 laround has quit (Ping timeout: 250 seconds)
725 2013-07-03 04:01:39 robocoin has quit (Ping timeout: 256 seconds)
726 2013-07-03 04:04:43 ThomasV has joined
727 2013-07-03 04:06:31 robocoin has joined
728 2013-07-03 04:10:11 agnostic98 has quit (Read error: Connection reset by peer)
729 2013-07-03 04:11:10 agnostic98 has joined
730 2013-07-03 04:11:56 tg has quit (Ping timeout: 276 seconds)
731 2013-07-03 04:18:59 MobPhone has joined
732 2013-07-03 04:24:42 o3u_ has quit (Ping timeout: 246 seconds)
733 2013-07-03 04:29:07 TheSeven has quit (Read error: Operation timed out)
734 2013-07-03 04:30:19 o3u has joined
735 2013-07-03 04:31:14 TheSeven has joined
736 2013-07-03 04:33:15 PiZZaMaN2K is now known as PiZZaMaN2K|away
737 2013-07-03 04:35:25 <imd23> hi
738 2013-07-03 04:35:49 <imd23> I need help in multi sig transactions
739 2013-07-03 04:36:07 <imd23> The problem is I am building a kind of a escrow system
740 2013-07-03 04:36:16 <imd23> and this multi sign transaction would be awesome
741 2013-07-03 04:37:26 <phantomcircuit> imd23, your clients will probably need to be able to use multisig transactions also
742 2013-07-03 04:37:31 <phantomcircuit> which mostly they wont be able to do
743 2013-07-03 04:38:29 squwiggle has joined
744 2013-07-03 04:38:34 <imd23> but because the seller (of btc's) doesn't know the other party who is selling (the buyer of btcs) after we match them, and we want to do the transaction automatically, i can't think of a way without asking/emailing the seller to do the transaction because he need to do it to 2 address (our /the escrow/ and the buyer of btcs)
745 2013-07-03 04:39:21 <imd23> is there a way to overcome this? because we want the highest security for everyone, and if there is a way we don't "own" the bit coins, better.
746 2013-07-03 04:40:29 <imd23> we are building the system, which will be an online system, so.
747 2013-07-03 04:40:35 impulse has joined
748 2013-07-03 04:41:08 free499__ has quit (Ping timeout: 264 seconds)
749 2013-07-03 04:41:39 squwiggle is now known as xenland
750 2013-07-03 04:44:41 mrkent has joined
751 2013-07-03 04:44:59 <BW^-> phantomcircuit: what about?
752 2013-07-03 04:45:56 <phantomcircuit> imd23, that completely ignores the fundamental issue with escrow, dispute resolution
753 2013-07-03 04:47:35 <phantomcircuit> the escrow agent *must* be able to make that decision
754 2013-07-03 04:48:11 o3u has quit (Ping timeout: 246 seconds)
755 2013-07-03 04:49:33 owowo has quit (Quit: sayonara)
756 2013-07-03 04:49:50 gfinn has quit (Ping timeout: 240 seconds)
757 2013-07-03 04:50:18 o3u has joined
758 2013-07-03 04:57:58 Luke-Jr has quit (Excess Flood)
759 2013-07-03 04:58:22 Luke-Jr has joined
760 2013-07-03 04:59:54 paracyst has quit (Read error: Connection reset by peer)
761 2013-07-03 05:02:16 o3u_ has joined
762 2013-07-03 05:02:16 o3u has quit (Read error: Connection reset by peer)
763 2013-07-03 05:05:30 RazielZ has joined
764 2013-07-03 05:09:36 mrkent has quit (Read error: Operation timed out)
765 2013-07-03 05:14:05 owowo has joined
766 2013-07-03 05:16:34 melvster_ has joined
767 2013-07-03 05:21:05 stochasm has quit (Ping timeout: 246 seconds)
768 2013-07-03 05:22:49 Jackneill has joined
769 2013-07-03 05:26:18 stochasm has joined
770 2013-07-03 05:27:34 PrimeStunna has joined
771 2013-07-03 05:33:08 ThomasV has quit (Read error: Operation timed out)
772 2013-07-03 05:34:36 _BtZeal0t has joined
773 2013-07-03 05:36:49 Julius129 has joined
774 2013-07-03 05:39:22 agnostic98 has quit (Read error: Connection reset by peer)
775 2013-07-03 05:40:14 variousnefarious has quit (Ping timeout: 245 seconds)
776 2013-07-03 05:40:21 variousnefarious has joined
777 2013-07-03 05:40:40 agnostic98 has joined
778 2013-07-03 05:44:47 macboz has quit (Ping timeout: 256 seconds)
779 2013-07-03 05:53:09 <imd23> phantomcircuit
780 2013-07-03 05:53:17 <imd23> i want dispute resolution
781 2013-07-03 05:54:49 <imd23> but I want 2 things, that I don't know if they are possible: #1 us, the mediator, be able to decide to which place to go (back to the seller of the btcs or the buyer) and #2 we only can decide, but not get the coin it self.
782 2013-07-03 05:55:34 RazielZ has quit (Ping timeout: 248 seconds)
783 2013-07-03 05:57:03 <walch> imd23: where would the funds go if the mediator could't get enough information to decide either way?
784 2013-07-03 05:58:42 mrkent has joined
785 2013-07-03 05:59:03 wamatt has quit (Quit: wamatt)
786 2013-07-03 06:00:04 <imd23> walch: obviously i am missing something, but i don't know why. Could you elaborate what you mean by "can't get enough info"?
787 2013-07-03 06:00:15 <imd23> *i don't know what
788 2013-07-03 06:01:43 <walch> imd23: I assume that if both the seller and buyer both claim that the other is in the wrong, then it's up to the mediator to decide who is telling the truth. in some cases though, it would be very hard to tell either way
789 2013-07-03 06:02:01 <walch> I'm more curious how the escrow works than anything, as i've never had to use it before.
790 2013-07-03 06:04:32 <imd23> walch: yeah, it's that way.
791 2013-07-03 06:05:42 <imd23> walch: what I want / may not be possible, or may it be the default behavior of multi_sign in btw / is that we, the mediator, to only have the power of deciding where the btcs go in case of a problem, but NO having the option of spending them.
792 2013-07-03 06:06:52 <imd23> This will give more trust to the people who use the service, and if a potential hacker attack our servers, they can not spend the coins, but just decide... (i am thinking in worse scenario)
793 2013-07-03 06:07:03 <imd23> *worst case scenario
794 2013-07-03 06:08:00 <imd23> of course there is a lot more security we will develop in our service, encrypt everything in the db's etc.. but I need to know if this little case is possible, so I can consider it or throw it away.
795 2013-07-03 06:09:55 <walch> imd23: the only place I can find that deals with them is blockchain.info, and I'm not really sure how it works. their description is incredibly vague.
796 2013-07-03 06:10:14 <walch> their US$5 fee is a little on the heavy side too.
797 2013-07-03 06:10:35 <walch> I suppose you're pioneering with this one.
798 2013-07-03 06:11:43 <imd23> awesome :)
799 2013-07-03 06:15:16 gst has quit (Remote host closed the connection)
800 2013-07-03 06:16:08 gjs278 has joined
801 2013-07-03 06:16:38 gst has joined
802 2013-07-03 06:17:08 variousnefarious has quit (Ping timeout: 264 seconds)
803 2013-07-03 06:19:38 variousnefarious has joined
804 2013-07-03 06:21:47 stalled has quit (Ping timeout: 241 seconds)
805 2013-07-03 06:22:15 peetaur2 has joined
806 2013-07-03 06:23:58 melvster_ has quit (Ping timeout: 252 seconds)
807 2013-07-03 06:30:36 tg has joined
808 2013-07-03 06:31:44 MC1984 has quit (Quit: Leaving)
809 2013-07-03 06:34:46 melvster has joined
810 2013-07-03 06:36:53 stalled has joined
811 2013-07-03 06:37:41 Eiii has quit ()
812 2013-07-03 06:46:07 toffoo_ has quit ()
813 2013-07-03 06:46:28 toffoo has joined
814 2013-07-03 06:47:02 Thepok has joined
815 2013-07-03 06:47:17 peetaur2 has quit (Quit: Konversation terminated!)
816 2013-07-03 06:47:59 adam3us has joined
817 2013-07-03 06:48:48 pecket has quit (Ping timeout: 240 seconds)
818 2013-07-03 06:49:34 peetaur2 has joined
819 2013-07-03 06:52:21 MC1984 has joined
820 2013-07-03 06:53:03 RazielZ has joined
821 2013-07-03 06:53:08 mrkent has quit (Ping timeout: 246 seconds)
822 2013-07-03 06:55:39 randy-waterhouse has joined
823 2013-07-03 07:01:00 Julius129 has quit (Ping timeout: 256 seconds)
824 2013-07-03 07:06:37 <melvster> anyone know what's the favourite alt coin hashing algo these days? sha256 / scrypt / other?
825 2013-07-03 07:08:11 <Luke-Jr> like legit altcoins or scamcoins?
826 2013-07-03 07:08:47 BW^- has quit (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
827 2013-07-03 07:09:47 <walch> are there any altcoins that are anything but litecoin and bitcoin forks?
828 2013-07-03 07:10:04 <Luke-Jr> walch: you're implying litecoin has any originality
829 2013-07-03 07:10:25 <Luke-Jr> afaik ripple and microcash are the only non-bitcoin forks
830 2013-07-03 07:10:48 <walch> Luke-Jr: I realise that it is just a fork with the proof of work changed, but I thought people would move to more radical hashing algorithms
831 2013-07-03 07:10:58 <Luke-Jr> walch: why? SHA256d works fine
832 2013-07-03 07:11:21 <Luke-Jr> yacoin has a different scrypt variant (though still just about as flawed as litecoin's)
833 2013-07-03 07:11:36 <Luke-Jr> all the legit altcoins use SHA256d though
834 2013-07-03 07:11:44 tg has quit (Ping timeout: 264 seconds)
835 2013-07-03 07:11:45 <walch> of course, but there's only so many times you can fork a currency before people get bored
836 2013-07-03 07:11:59 <Luke-Jr> apparently not
837 2013-07-03 07:12:29 <Luke-Jr> sometimes I am tempted to write a bot that automatically releases a fork of every new scamcoin
838 2013-07-03 07:13:20 <walch> uh, wow. I knew there was a couple of other forks, but the alternate cryptocurrencies subforum is just unbelievable
839 2013-07-03 07:14:28 <Luke-Jr> walch: the only altcoins worth looking at are TBC, NMC, and FRC, basically
840 2013-07-03 07:14:38 <randy-waterhouse> toxic swamp
841 2013-07-03 07:14:44 ShapeShifter499 has quit (Ping timeout: 264 seconds)
842 2013-07-03 07:15:05 <randy-waterhouse> what are TBC and FRC?
843 2013-07-03 07:15:09 jeewee has joined
844 2013-07-03 07:15:11 <Luke-Jr> Tonal Bitcoin, Freicoin
845 2013-07-03 07:15:30 sensorii has quit (Ping timeout: 240 seconds)
846 2013-07-03 07:15:31 <randy-waterhouse> oh, k
847 2013-07-03 07:15:47 <randy-waterhouse> so basically just NMC
848 2013-07-03 07:16:11 <randy-waterhouse> Luke-Jr: are you maintaining TBC?
849 2013-07-03 07:16:13 <walch> I was going to make a comment about wasted effort, but most of them don't seem to have changed much other than the logos.
850 2013-07-03 07:16:38 <Luke-Jr> randy-waterhouse: define maintaining
851 2013-07-03 07:16:41 <MC1984> tbc is an altcoin like coke zero is an entirely seperate beverage
852 2013-07-03 07:16:51 <Luke-Jr> it basically just works
853 2013-07-03 07:17:47 sensorii has joined
854 2013-07-03 07:18:33 <randy-waterhouse> Luke-Jr: i'll look into it ... are you the creator?
855 2013-07-03 07:18:48 <MC1984> no wait, tbc is more like new coke :P
856 2013-07-03 07:18:52 peetaur2 has quit (Quit: Konversation terminated!)
857 2013-07-03 07:19:50 <Luke-Jr> randy-waterhouse: yes
858 2013-07-03 07:20:13 <randy-waterhouse> Luke-Jr: been meaning to show you this http://tauday.com/ Pi is wrong
859 2013-07-03 07:20:19 <Luke-Jr> randy-waterhouse: http://bitcointroll.org/?topic=218388.0;all
860 2013-07-03 07:20:29 <Luke-Jr> randy-waterhouse: I'm aware of tau, even have the key on my keyboard
861 2013-07-03 07:20:44 <randy-waterhouse> cool ... how did you get that?
862 2013-07-03 07:20:46 <walch> Luke-Jr: most of these altcoins seem to ask the user to put addnode lines in their configurations, does that just mean that their network is lacking the bootstrapping Bitcoin uses?
863 2013-07-03 07:20:49 <Luke-Jr> http://luke.dashjr.org/education/tonal/keyboard/dvorak-tonal.png <-- it's AltGr-Y
864 2013-07-03 07:20:56 <Luke-Jr> walch: probably
865 2013-07-03 07:21:11 <Luke-Jr> randy-waterhouse: or http://luke.dashjr.org/education/tonal/keyboard/dvorak-tonal.xmodmap for X11
866 2013-07-03 07:21:36 <Luke-Jr> (also Windows and Mac keymaps in the dir too)
867 2013-07-03 07:23:10 Gnaf_ has joined
868 2013-07-03 07:23:22 <jgarzik> Here are the beginnings of the command line tools I've discussed in here from time to time (CC sipa gmaxwell): https://github.com/jgarzik/txtool
869 2013-07-03 07:23:27 <jgarzik> *tool
870 2013-07-03 07:24:26 <jgarzik> Goal is to make fiddling with transactions, or making odd duck transactions, easier. Hopefully this makes things like multisig a bit more accessible to more people, for testing and experimentation. https://github.com/jgarzik/txtool/blob/master/examples/multisig.txt
871 2013-07-03 07:24:43 <walch> Luke-Jr: I was going to look at the source and check, but most of these altcoins aren't even open source..
872 2013-07-03 07:25:16 <Luke-Jr> jgarzik++
873 2013-07-03 07:26:10 Gnaf has quit (Read error: Connection reset by peer)
874 2013-07-03 07:31:27 <randy-waterhouse> jgarzik: nice ... anything to watch out for when calling txtool from inside shell script?
875 2013-07-03 07:32:52 <melvster> sha256 is dominated by asics, im not sure about the scrypt variants but im seeing scrypt used all over the place now ...maybe the ideal is to make it modular like TLS
876 2013-07-03 07:33:12 <melvster> didnt brian carpenter say something similar in internet axioms?
877 2013-07-03 07:33:49 <walch> melvster: that's a good thing though, a higher hashrate means an attack is more expensive
878 2013-07-03 07:34:34 <melvster> for bitcoin yes, but for an altcoin you're in trouble
879 2013-07-03 07:34:38 TD has joined
880 2013-07-03 07:35:17 <jgarzik> randy-waterhouse, only the currently lame behavior of tossing a Javascript exception on error. shell will notice non-zero exit status, of course. But console dump is not pretty.
881 2013-07-03 07:35:33 * jgarzik spies a TD
882 2013-07-03 07:35:41 <TD> hello
883 2013-07-03 07:36:21 <jgarzik> TD: New toy https://github.com/jgarzik/txtool
884 2013-07-03 07:36:51 <TD> neat
885 2013-07-03 07:36:52 <jgarzik> TD: will use that to work up some examples of advanced transactions
886 2013-07-03 07:37:13 <jgarzik> TD: crowd funding will probably be the next working example
887 2013-07-03 07:37:17 <TD> sounds good. i'm still hoping to see some real-time network metrics :)
888 2013-07-03 07:37:32 <TD> yeah, that'd be awesome, though what i'd really like to see is a gui + a server for collecting and monitoring the pledges ...
889 2013-07-03 07:37:42 <jgarzik> agreed
890 2013-07-03 07:37:50 tsche has quit (Ping timeout: 256 seconds)
891 2013-07-03 07:38:14 <jgarzik> this is mainly for geeks to tinker, and to demonstrate for others
892 2013-07-03 07:38:57 <jgarzik> Infrastructure for passing around partially signed transactions is weak, in general
893 2013-07-03 07:40:09 imd23 has quit (Quit: imd23)
894 2013-07-03 07:40:45 agnostic98 has quit (Remote host closed the connection)
895 2013-07-03 07:41:01 <Luke-Jr> melvster: ASICs are a GOOD thing
896 2013-07-03 07:41:03 <melvster> internet axioms 6.4 In choosing algorithms, the algorithm should be one which is
897 2013-07-03 07:41:03 <melvster> widely regarded as strong enough to serve the purpose. Among
898 2013-07-03 07:41:03 <melvster> alternatives all of which are strong enough, preference should be
899 2013-07-03 07:41:03 <melvster> given to algorithms which have stood the test of time and which are
900 2013-07-03 07:41:03 <melvster> not unnecessarily inefficient.
901 2013-07-03 07:41:08 <melvster> oops sorry for flood
902 2013-07-03 07:41:38 <Luke-Jr> only scams fear ASICs
903 2013-07-03 07:41:51 <melvster> Luke-Jr: I dont doubt that ... just trying to figure out what hashing algo is best in the general case
904 2013-07-03 07:42:21 <MC1984> ive heard someone is doing fpga for scrypt
905 2013-07-03 07:42:24 tsche has joined
906 2013-07-03 07:42:32 <Luke-Jr> melvster: SHA256d has basically met the ideal position for POW
907 2013-07-03 07:42:33 <MC1984> knc or something
908 2013-07-03 07:43:32 <melvster> found it: Wherever a cryptographic algorithm is called for in a protocol, the protocol should be designed to permit alternative algorithms to be used and the specific algorithm employed in a particular implementation should be explicitly labeled. Official labels for algorithms are to be recorded by the IANA.
909 2013-07-03 07:44:54 <Luke-Jr> melvster: found what?
910 2013-07-03 07:45:06 random_cat has quit (Remote host closed the connection)
911 2013-07-03 07:45:07 <Luke-Jr> melvster: that doesn't apply to bitcoin
912 2013-07-03 07:46:16 <gjs278> my avalon is running today
913 2013-07-03 07:46:21 <Luke-Jr> you can't just change out proofs-of-work in bitcoin
914 2013-07-03 07:46:21 random_cat has joined
915 2013-07-03 07:46:35 <Luke-Jr> gjs278: are you turning it off tomorrow?
916 2013-07-03 07:46:40 <gjs278> nope
917 2013-07-03 07:47:02 <gjs278> I just got it, from a batch 2 order after they reopened it in feb
918 2013-07-03 07:47:18 OPrime has joined
919 2013-07-03 07:47:22 <Luke-Jr> ah
920 2013-07-03 07:47:30 <Luke-Jr> I think #bitcoin-mining is for this discussion then? XD
921 2013-07-03 07:47:32 setkeh has quit (Ping timeout: 260 seconds)
922 2013-07-03 07:52:43 TD has quit (Quit: TD)
923 2013-07-03 07:59:19 setkeh has joined
924 2013-07-03 07:59:21 <melvster> Luke-Jr: I was quoting design principles for internet wide systems, a classic design doc from brian carpenter ... the design of the WWW and other highly scalable systems were based on this
925 2013-07-03 07:59:51 <Luke-Jr> melvster: nothing like bitcoin has ever been done before
926 2013-07-03 08:00:05 <melvster> Luke-Jr: sure it has
927 2013-07-03 08:00:12 <SomeoneWeird> melvster, ...?
928 2013-07-03 08:00:22 * melvster been following this space since 1995 ;)
929 2013-07-03 08:00:56 <Luke-Jr> melvster: really? there's been a former p2p system that relied on 100% perfect consensus? :p
930 2013-07-03 08:01:37 leakybuckit has joined
931 2013-07-03 08:02:11 <melvster> this space has been evolving for about 20 years ... satoshi has been active at least 15 years ;)
932 2013-07-03 08:02:42 <Krellan_> don't all P2P systems rely on consensus?
933 2013-07-03 08:03:01 <melvster> very loosely speaking you could argue that
934 2013-07-03 08:03:17 Jere_Jones has quit (Remote host closed the connection)
935 2013-07-03 08:03:20 <Krellan_> deviate from the protocol and your transmissions will get rejected by your peers
936 2013-07-03 08:03:42 <melvster> satoshi's genius was in putting the building blocks together in a way no one had ever thought of before, and to back that up with code
937 2013-07-03 08:04:16 <Krellan_> yep - all the pieces were there - "hashcash", proof of work, etc.
938 2013-07-03 08:04:25 <melvster> so if you look at ripple / XPR ... they have BOTH proof of work and human consensus model
939 2013-07-03 08:04:27 imd23 has joined
940 2013-07-03 08:04:33 Jackneill has quit (Remote host closed the connection)
941 2013-07-03 08:04:50 <Krellan_> Satoshi put the pieces together into a working system. I remember reading about proof of work, originally intended to stop the problem of spam email.
942 2013-07-03 08:05:14 <Krellan_> i wonder if somebody could invent "postage" for email, which requires the sender to do some Bitcoin mining? that would then bring it full circle :)
943 2013-07-03 08:05:20 Jere_Jones has joined
944 2013-07-03 08:05:25 <melvster> Krellan_: yes exactly, and satoshi used it to also solve byzantine generals problem, network synchronization, double spend etc.
945 2013-07-03 08:06:19 <melvster> Luke-Jr: I dont disagree with you ... but any conversation involving x is 'like' y ... is gonna have an element of subjectivity ... just saying there's a lot of history
946 2013-07-03 08:06:56 <melvster> Krellan_: it's already done ... spam assassin has been using PoW for ages
947 2013-07-03 08:07:11 <melvster> *under* using I should say ... it's part of the scoring system
948 2013-07-03 08:07:59 <imd23> I read that PoW didn't work in the end for email because it was too much work for email clients in commodity pcs
949 2013-07-03 08:08:02 <imd23> is it true?
950 2013-07-03 08:08:16 <melvster> so a bitcoin-like system where you can swap out hash algorithms would be interesting ... in effect the bitcoin scripts partially allow it already
951 2013-07-03 08:08:40 <melvster> but the OP_CODES have a central registry
952 2013-07-03 08:08:54 <melvster> one per each alt coin
953 2013-07-03 08:09:24 The_Fly has quit (Read error: Operation timed out)
954 2013-07-03 08:10:00 The_Fly has joined
955 2013-07-03 08:10:26 dustjn has quit (Ping timeout: 248 seconds)
956 2013-07-03 08:11:44 Jere_Jones has quit (Remote host closed the connection)
957 2013-07-03 08:12:00 <melvster> are they any good alternative to BOTH sha256 and scrypt?
958 2013-07-03 08:12:19 <Luke-Jr> scrypt does not work as a POW
959 2013-07-03 08:12:24 <melvster> oh
960 2013-07-03 08:12:43 <melvster> didnt know that, thanks ... i knew it has a large memory footprint
961 2013-07-03 08:12:52 Jere_Jones has joined
962 2013-07-03 08:12:52 Jere_Jones has quit (Changing host)
963 2013-07-03 08:12:52 Jere_Jones has joined
964 2013-07-03 08:13:03 <melvster> some people say scrypt is resistent to GPU other not
965 2013-07-03 08:13:11 <Luke-Jr> either it's configured so small that it just hurts the consumer hardware (Litecoin), or it's configured so large that verification isn't cheap
966 2013-07-03 08:13:14 <Krellan_> i thought Scrypt worked just fine as a POW - isn't that what Litecoin uses?
967 2013-07-03 08:13:22 dustjn has joined
968 2013-07-03 08:13:26 <Luke-Jr> Krellan_: and why litecoin can never succeed
969 2013-07-03 08:14:29 <Krellan_> i honestly don't think there's room for any altcoins besides bitcoin to have a serious value - because if i'm going to give up real world value for a cryptocoin, why wouldn't i want the best, most widely accepted, cryptocoin? Gresham's Law
970 2013-07-03 08:16:19 <Krellan_> perhaps litecoin is good to give frustrated CPU/GPU miners something to do after bitcoin comes to be dominated by ASIC mining
971 2013-07-03 08:17:19 <Krellan_> and litecoin does tweak the constants in a way that seems to make sense: mine blocks faster than once every 10 minutes, mine more units of currency, etc.
972 2013-07-03 08:18:30 Jere_Jones has quit (Read error: Connection reset by peer)
973 2013-07-03 08:19:23 Jere_Jones has joined
974 2013-07-03 08:19:23 Jere_Jones has quit (Changing host)
975 2013-07-03 08:19:23 Jere_Jones has joined
976 2013-07-03 08:20:24 <petertodd> jgarzik: txtool is written in javascript just so you can use tabs for indentation isn't it...
977 2013-07-03 08:20:48 savetheinternet has quit (Quit: Textual IRC Client: www.textualapp.com)
978 2013-07-03 08:24:36 <melvster> Krellan_: i predict there will be 1000s of alt coins in a few years time, but bitcoin will (hopefully) still be top 2
979 2013-07-03 08:24:46 <melvster> (by market cap at least)
980 2013-07-03 08:24:51 jeewee has quit (Read error: Connection reset by peer)
981 2013-07-03 08:25:09 <melvster> XRP is arguably bigger now
982 2013-07-03 08:25:22 <melvster> but does something very different
983 2013-07-03 08:28:23 agnostic98 has joined
984 2013-07-03 08:35:26 Krellan has joined
985 2013-07-03 08:35:37 Namworld has quit ()
986 2013-07-03 08:36:05 agnostic98 has quit (Read error: Connection reset by peer)
987 2013-07-03 08:39:39 Guest83631 has joined
988 2013-07-03 08:40:02 imd23_ has joined
989 2013-07-03 08:40:35 imd23 has quit (Ping timeout: 246 seconds)
990 2013-07-03 08:40:36 imd23_ is now known as imd23
991 2013-07-03 08:42:01 stretchwarren has quit (Ping timeout: 252 seconds)
992 2013-07-03 08:43:32 mappum has quit (Ping timeout: 264 seconds)
993 2013-07-03 08:44:03 CodesInChaos_ has joined
994 2013-07-03 08:44:56 <petertodd> interesting: https://inputs.io/ "Inputs.io is a new bitcoin payment processor leveraging an offchain payment network."
995 2013-07-03 08:45:37 Julius129 has joined
996 2013-07-03 08:46:04 <petertodd> Don't see any auditing tech implemented yet, but that can be added.
997 2013-07-03 08:46:10 TD[gone] is now known as TD
998 2013-07-03 08:46:10 owowo has quit (Ping timeout: 240 seconds)
999 2013-07-03 08:46:18 <walch> petertodd: I helped out the developer with their copyrighting last night
1000 2013-07-03 08:46:37 <TD> what country is .io and what's with this fashion of using ridiculous TLDs for websites?
1001 2013-07-03 08:46:37 <petertodd> walch: interesting
1002 2013-07-03 08:46:49 t7 has joined
1003 2013-07-03 08:47:05 <walch> petertodd: it's not bad once you're inside, but the PIN entering system is insane for "security reasons"
1004 2013-07-03 08:47:07 <petertodd> TD: the interwebs
1005 2013-07-03 08:47:21 <TD> by "off chain network" they seem to simply mean that they use a shared wallet and internal transfers are free?
1006 2013-07-03 08:47:40 <walch> petertodd: think an onscreen keyboard which shuffles the numbers around when you use it
1007 2013-07-03 08:47:47 <petertodd> walch: yeah, typical security theater stuff
1008 2013-07-03 08:47:53 <TD> doh
1009 2013-07-03 08:48:00 <walch> TD: yes, and they offer redeemable voucher codes which can be exchanged for a balance
1010 2013-07-03 08:48:10 omnibrain has joined
1011 2013-07-03 08:48:21 <petertodd> TD: Looks like it, with a nice API.
1012 2013-07-03 08:48:30 * TD sighs
1013 2013-07-03 08:48:40 <TD> we should have a warning banner on bitcoin.org
1014 2013-07-03 08:48:45 <TD> "do not attempt to run bitcoin banks"
1015 2013-07-03 08:48:47 <TD> <learn more>
1016 2013-07-03 08:48:47 <walch> TD: the .io ccTLD has been modified on Google's side to be generic, that's why people use it a lot now
1017 2013-07-03 08:49:05 <TD> british indian ocean territory?
1018 2013-07-03 08:49:23 <petertodd> TD: meh, you're not going to get fancy auditing systems on the get go, and there is no other way to do random micropayments even right now, let alone in the future
1019 2013-07-03 08:49:36 <TD> actual use: "popular with startup companies; little of anything related to the territory itself" haha
1020 2013-07-03 08:50:04 <TD> walch: i see
1021 2013-07-03 08:50:40 <TD> petertodd: they don't allow random micropayments either. the recipient would have to be on the same site. and, of course, they'd have to decide not to throttle you even if 99% of their web traffic was micropayments ...
1022 2013-07-03 08:51:11 owowo has joined
1023 2013-07-03 08:51:14 <walch> TD: they do, in a sense. you can "send" to an email address, and they get sent a voucher code
1024 2013-07-03 08:51:47 <TD> .. which i can only use if i sign up with them?
1025 2013-07-03 08:51:51 <walch> correct.
1026 2013-07-03 08:52:09 <petertodd> TD: they allow random micropayments to a degree not possible with Bitcoin; I'm not going to argue scaling with you
1027 2013-07-03 08:55:42 <TD> actually, you're just assuming that they do. they don't charge fees for these transfers, so they don't directly benefit in any way from them. your argument would be that people who run bitcoin nodes wouldn't bother with the hardware needed to support micropayments, whereas inputs.io would, despite that neither has any obvious incentive to do so
1028 2013-07-03 08:56:32 <TD> regardless, bitbanks are a bad idea no matter what the motivation .... if only because they risk getting in trouble for running an unlicensed bank
1029 2013-07-03 08:56:55 handle_ has joined
1030 2013-07-03 08:57:20 <petertodd> TD: not going to argue scaling with you
1031 2013-07-03 08:58:30 i2pRelay has quit (Ping timeout: 240 seconds)
1032 2013-07-03 08:58:30 guruvan has quit (Ping timeout: 240 seconds)
1033 2013-07-03 08:58:30 KillYourTV has quit (Ping timeout: 240 seconds)
1034 2013-07-03 08:58:50 gst has quit (Ping timeout: 240 seconds)
1035 2013-07-03 08:59:10 handle has quit (Ping timeout: 240 seconds)
1036 2013-07-03 08:59:10 sacredchao has quit (Ping timeout: 240 seconds)
1037 2013-07-03 08:59:36 PrimeStunna has quit (Quit: PrimeStunna)
1038 2013-07-03 09:00:38 i2pRelay has joined
1039 2013-07-03 09:00:57 <petertodd> oh nifty: https://inputs.io/clearsign nice message format
1040 2013-07-03 09:01:00 gst has joined
1041 2013-07-03 09:01:32 <petertodd> however this is relevant: https://xkcd.com/1181/
1042 2013-07-03 09:01:37 sacredchao has joined
1043 2013-07-03 09:01:48 <petertodd> (they include the BTC address in the sig....)
1044 2013-07-03 09:01:54 <phantomcircuit> that's funny
1045 2013-07-03 09:02:22 <TD> why would they include the address above the signature? that seems useless
1046 2013-07-03 09:03:15 <phantomcircuit> that's cute
1047 2013-07-03 09:03:24 agnostic98 has joined
1048 2013-07-03 09:03:54 <phantomcircuit> i'll be building a clearinghouse system relatively soon in an attempt to make micropayments practically possible
1049 2013-07-03 09:03:58 <phantomcircuit> we'll see if anybody cares
1050 2013-07-03 09:04:13 <TD> they have a long history of going nowhere, unfortunately
1051 2013-07-03 09:04:18 <petertodd> phantomcircuit: good! There needs to be a standard for provider-to-provider messages.
1052 2013-07-03 09:04:24 <petertodd> s/messages/transactions/
1053 2013-07-03 09:04:31 KillYourTV has joined
1054 2013-07-03 09:04:35 <petertodd> phantomcircuit: Of course, I'll warn you the market for uT
1055 2013-07-03 09:04:37 <phantomcircuit> petertodd, transactions are messages in a clearinghouse :)
1056 2013-07-03 09:04:42 <petertodd> uTx's is likely to be small...
1057 2013-07-03 09:04:53 guruvan has joined
1058 2013-07-03 09:04:58 <phantomcircuit> petertodd, yeah im fully aware that it's a limited field
1059 2013-07-03 09:05:03 <walch> I can't actually get the signed messages from inputs.io to verify.
1060 2013-07-03 09:05:12 <phantomcircuit> i suspect there will also be interest from people who dont want to pay fees
1061 2013-07-03 09:05:19 <petertodd> The whole idea of microtransactions doesn't mesh well with how people think - the cost to evaluate whether it is worth making a transaction is easily higher than it's worth.
1062 2013-07-03 09:05:20 <phantomcircuit> on anything
1063 2013-07-03 09:05:50 <petertodd> Really the #1 thing inputs.io and similar are useful for is privacy; fees is secondary.
1064 2013-07-03 09:06:14 <walch> the example signature the website supplies won't verify with the header on, with or without the whitespace
1065 2013-07-03 09:06:19 <phantomcircuit> then they're not doing a great job with all the javascript nonsense
1066 2013-07-03 09:06:50 <petertodd> walch: like the one that shows up in the textbox by default? working for me (in the xkcd sense)
1067 2013-07-03 09:07:15 kinlo_ has quit (Changing host)
1068 2013-07-03 09:07:15 kinlo_ has joined
1069 2013-07-03 09:07:15 <phantomcircuit> now if only i could walk to the kitchen
1070 2013-07-03 09:07:17 <phantomcircuit> >.>
1071 2013-07-03 09:07:25 kinlo_ is now known as kinlo
1072 2013-07-03 09:07:27 agnostic98 has quit (Read error: Connection reset by peer)
1073 2013-07-03 09:07:35 <petertodd> phantomcircuit: that sounds bad...
1074 2013-07-03 09:07:36 <walch> petertodd: yes. it verifies in the form they have there (POSTs to the server and returns true), but not in anything else.
1075 2013-07-03 09:07:53 <phantomcircuit> petertodd, terrible sunburn on my legs
1076 2013-07-03 09:08:00 <phantomcircuit> which has caused swelling
1077 2013-07-03 09:08:03 <petertodd> walch: ah, well it is a non-standard message format
1078 2013-07-03 09:08:07 <phantomcircuit> walking hurts from the pressure
1079 2013-07-03 09:08:16 <petertodd> phantomcircuit: ouch :(
1080 2013-07-03 09:08:41 <walch> petertodd: sort of defeats the purpose if it can only be verified on the originating website.
1081 2013-07-03 09:09:02 <petertodd> oh nice, looks like they accept deposits after a single confirmation, more convenient than easywallet
1082 2013-07-03 09:09:24 <petertodd> walch: yeah, seems like a feature they threw in at the last minute
1083 2013-07-03 09:09:56 <petertodd> walch: in general sites like that kinda worry me, because the incompetent people always go live first...
1084 2013-07-03 09:10:31 jtimon has joined
1085 2013-07-03 09:11:27 <petertodd> oh lovely... in their "transactions" tab they show transactions as having a from address...
1086 2013-07-03 09:12:05 Krellan has quit (Remote host closed the connection)
1087 2013-07-03 09:12:05 <walch> petertodd: the service makes me incredibly uncomfortable.
1088 2013-07-03 09:12:27 <petertodd> walch: Little details like that sure do smell like incompetence...
1089 2013-07-03 09:14:51 <walch> petertodd: security is nothing like my area of expertise, but I know that real_escape_string() is an incredibly bad idea.
1090 2013-07-03 09:14:52 <petertodd> This is bad too: "It is very important to make sure the request came from our IP, 50.116.37.202" <- from their callback API
1091 2013-07-03 09:15:30 tg has joined
1092 2013-07-03 09:15:35 <kinlo> linode
1093 2013-07-03 09:15:38 <petertodd> walch: PHP in general is an increedibly bad idea: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ but I'll give them a pass on pragmatism grounds there sadly :(
1094 2013-07-03 09:15:41 <kinlo> they haven't been hacked before eh :)
1095 2013-07-03 09:15:56 <petertodd> kinlo: heh, hopefully they have secure backend servers, but I wouldn't count on it
1096 2013-07-03 09:16:15 <petertodd> anyone else have an inputs.io account? wanna try an account-to-account send
1097 2013-07-03 09:16:32 <kinlo> I can create one and you can send me monniez :)
1098 2013-07-03 09:16:48 <petertodd> kinlo: sure
1099 2013-07-03 09:16:48 <walch> petertodd: jcpduquy@sharklasers.com
1100 2013-07-03 09:17:08 <walch> ^ the account I was using for testing before
1101 2013-07-03 09:17:53 <petertodd> walch: enjoy your penny
1102 2013-07-03 09:18:14 <petertodd> I like how off-chain tx hashes start with "io"
1103 2013-07-03 09:19:05 <kinlo> petertodd: kinlo@triplemining.com should work :)
1104 2013-07-03 09:19:24 <petertodd> kinlo: here, what's your BTC addr though for the account
1105 2013-07-03 09:19:41 <kinlo> I need a btc addres too?
1106 2013-07-03 09:19:55 <petertodd> kinlo: well, I wanna see what that functionality is like
1107 2013-07-03 09:20:15 <kinlo> sec
1108 2013-07-03 09:21:10 <kinlo> Your bitcoin address: 1JncLzoGEJRXumGmh6ZGXD6gSM4dNmYDUC <- you need that? :)
1109 2013-07-03 09:21:15 stretchwarren has joined
1110 2013-07-03 09:21:46 <petertodd> ah cool, it auto-converts to your email
1111 2013-07-03 09:21:48 <kinlo> shouldn't I deposit on that address and send you using your email address instead of a bitcoin address?
1112 2013-07-03 09:22:19 <petertodd> kinlo: point is, I already tested send-to-email - I want to explore the functionality, not give money away :P
1113 2013-07-03 09:22:28 <kinlo> I've received monniez
1114 2013-07-03 09:22:33 <kinlo> lots of monniez :)
1115 2013-07-03 09:22:38 <petertodd> lol
1116 2013-07-03 09:23:06 <petertodd> semi-dissappointed that they're limiting any transfer to 1mBTC, but nothing stopping them from lowering that in the future
1117 2013-07-03 09:23:12 <kinlo> mmmz site doesn't work that well
1118 2013-07-03 09:23:21 <petertodd> kinlo: yeah?
1119 2013-07-03 09:23:31 <kinlo> perhaps it is because I'm probably the only guy left on this world using opera as browser
1120 2013-07-03 09:23:39 <petertodd> ha
1121 2013-07-03 09:24:35 zer0def has quit (Ping timeout: 276 seconds)
1122 2013-07-03 09:25:47 <kinlo> kinda stupid I can't type my pin
1123 2013-07-03 09:25:59 <kinlo> otoh it does help against stupid keyloggers
1124 2013-07-03 09:26:20 <petertodd> kinlo: Well that *is* the whole point of the PIN thing.,
1125 2013-07-03 09:26:22 <walch> kinlo: I did mention that to the developer. the layout os the numbers used to be randomised too.
1126 2013-07-03 09:26:43 <kinlo> walch: nah, this is fine. This protects against hardware keyloggers
1127 2013-07-03 09:26:54 <kinlo> anything softwarebased would just capture the http traffic
1128 2013-07-03 09:27:02 <kinlo> before encryption that is
1129 2013-07-03 09:27:09 <gmaxwell> kinlo: go log into the us social security administration website...
1130 2013-07-03 09:27:23 <kinlo> gmaxwell: I can't :)
1131 2013-07-03 09:27:24 <petertodd> Long term what we really need is these off-chain services to accept transactions in the form of signed Bitcoin transactions of a special format so you can use hardware wallets.
1132 2013-07-03 09:27:38 <gmaxwell> they have insane password rules ... "must use at least 15 character classes" (well not quite) ... and an onscreen javascript keyboard.
1133 2013-07-03 09:28:05 <gmaxwell> ... and you can only log into the site during business hours. (which are pretty long, but ... )
1134 2013-07-03 09:28:09 <kinlo> gmaxwell: but only password?
1135 2013-07-03 09:28:11 <walch> kinlo: isn't the assumption usually that with physical access, all protection is moot?
1136 2013-07-03 09:28:42 <gmaxwell> kinlo: no worries, you can set the password to be a bunch of crap and then just recover it using your DOB and SSN or whatever. :P
1137 2013-07-03 09:28:45 <kinlo> gmaxwell: my goverment data is protected with a 4 number pin code
1138 2013-07-03 09:28:51 <kinlo> and a smartcard :)
1139 2013-07-03 09:28:53 <walch> kinlo: I mean, in this case, the interface inconveniences every user to protect against a very limited attack
1140 2013-07-03 09:29:30 <kinlo> every belgian has a identity card (required to carry at all times)
1141 2013-07-03 09:29:37 <kinlo> and it contains a chip that uses x509
1142 2013-07-03 09:29:53 <phantomcircuit> gmaxwell, dont bother just reset the passwor everytime
1143 2013-07-03 09:29:58 <phantomcircuit> you only need your ssn
1144 2013-07-03 09:30:05 <phantomcircuit> brilliant securitythere
1145 2013-07-03 09:30:06 <kinlo> so our data is clearly more secure....
1146 2013-07-03 09:30:32 <petertodd> kinlo: interesting... can you use that card to sign arbitrary data?
1147 2013-07-03 09:30:33 <kinlo> only pain in the ass is installing drivers for the smartcardreader
1148 2013-07-03 09:30:38 <gmaxwell> the SS site doesn't do much except that it has your complete income history on it. ... (in more detail than required: it's irrelevant to them if your income is over the maximum, e.g. 110k == 150k == 900k, but they still display the actual amounts)
1149 2013-07-03 09:30:45 <kinlo> petertodd: it's a regular x509 certificate... so yes.
1150 2013-07-03 09:30:57 <kinlo> petertodd: linux support by our governement too...
1151 2013-07-03 09:31:33 <petertodd> kinlo: Crazy, and I could use it for my proof-of-belgian-government-says-your-a-person cryptocurrency...
1152 2013-07-03 09:31:33 <kinlo> (support as in they released the source and the drivers, not as in there is a helpdesk helping you to configure your ubuntu)
1153 2013-07-03 09:31:56 <MC1984> what country is that
1154 2013-07-03 09:32:03 <kinlo> belgium
1155 2013-07-03 09:32:14 <MC1984> +1 for belgium
1156 2013-07-03 09:32:47 <MC1984> now about chaum blinded cryptoelections and stuff.....
1157 2013-07-03 09:32:55 <phantomcircuit> gmaxwell, if youre receiving benefits you can change the mailing aress an even the irect eposit info
1158 2013-07-03 09:32:56 <kinlo> heh
1159 2013-07-03 09:33:03 <kinlo> we can't vote online yet
1160 2013-07-03 09:33:23 Fnar has quit (Quit: Client exiting)
1161 2013-07-03 09:33:30 <gmaxwell> phantomcircuit: I think banks are quick to catch SS check fraud at least.
1162 2013-07-03 09:33:47 <phantomcircuit> gmaxwell, uick but not instant
1163 2013-07-03 09:33:49 <MC1984> i would not trust any sort of e voting unless it was 100% provably secure and legit with crypto etc
1164 2013-07-03 09:33:59 <petertodd> kinlo: Universal identity cards like that are the only time I'd even begin to grudgingly accept electronic voting.
1165 2013-07-03 09:34:33 <petertodd> kinlo: And only because you can do some extremely powerful auditing that way...
1166 2013-07-03 09:34:43 <kinlo> petertodd: I don't like x509. I only need a copy of the CA keyfile and I'm free to do what I want
1167 2013-07-03 09:34:58 <petertodd> kinlo: What do you mean?
1168 2013-07-03 09:34:59 <MC1984> some sort of votechain would be great, that any citizen could count the vote of the entire nation
1169 2013-07-03 09:35:02 <kinlo> if I keep low profile it will be ages before someone notices
1170 2013-07-03 09:35:15 agnostic98 has joined
1171 2013-07-03 09:35:18 <petertodd> MC1984: voting isn't a consensus problem
1172 2013-07-03 09:35:29 <gmaxwell> MC1984: blockchains are not pixie dust, they don't prevent censorship. :P solves the wrong problem.
1173 2013-07-03 09:35:30 <kinlo> petertodd: that the entire certificate system fails when 1 file is compromised
1174 2013-07-03 09:35:45 <MC1984> agreeing on vote totals is
1175 2013-07-03 09:35:47 <kinlo> or in teh case of browsers: when 1 out of thousands of those files is compromised
1176 2013-07-03 09:35:50 <petertodd> kinlo: You mean the CA's private keys?
1177 2013-07-03 09:35:55 <kinlo> yes
1178 2013-07-03 09:36:01 <gmaxwell> MC1984: No, agreeing on the totals, given the votes is just addition.
1179 2013-07-03 09:36:28 <MC1984> how else to give the votes to everyone securely?
1180 2013-07-03 09:36:29 <petertodd> kinlo: Well, security measures for that stuff are usually extreme... read how they did the DNSSEC root keys sometime.
1181 2013-07-03 09:36:55 <kinlo> petertodd: dnssec is probably "ok"
1182 2013-07-03 09:37:16 <gmaxwell> MC1984: :( a blockchain doesn't help that problem at all. So I'm not sure how to answer how else. ... How else can we get to the moon except by molesting camels?
1183 2013-07-03 09:37:17 <petertodd> MC1984: read jdillon's voting protocol, you'll find it illuminating: https://bitcointalk.org/index.php?topic=230864.0;all
1184 2013-07-03 09:37:22 <kinlo> petertodd: but you're not convincing me of the way the all browser ca's are handled
1185 2013-07-03 09:37:43 <MC1984> you have strange tastes gmaxwell
1186 2013-07-03 09:37:47 <petertodd> kinlo: For sure - DNSSEC did it right, but there are hundreds of CA's out there.
1187 2013-07-03 09:37:48 <kinlo> petertodd: and I have heard about the dnssec root keys, I never heard about the way they treated the belgian root certificate...
1188 2013-07-03 09:37:58 <kinlo> thousands, not hundreds
1189 2013-07-03 09:38:09 <kinlo> all capable of signing any site you surf to
1190 2013-07-03 09:38:19 <petertodd> kinlo: A slightly insane system...
1191 2013-07-03 09:38:27 <gmaxwell> sub-CAs are a lot of that problem.
1192 2013-07-03 09:38:27 <MC1984> forget the blockchain then
1193 2013-07-03 09:38:37 <MC1984> but i bet chaum stuff could be applied to it
1194 2013-07-03 09:38:41 <MC1984> ill read that thing
1195 2013-07-03 09:38:48 <petertodd> kinlo: Oh well, Google is making half-decent efforts there with cert-pinning and what not. Far from perfect, but at least it's progress.
1196 2013-07-03 09:38:58 <gmaxwell> MC1984: sure, there are proposals on cryptographic voting systems, though they leave a lot of hard problems unsolved.
1197 2013-07-03 09:39:11 <gmaxwell> petertodd: not only google. :P
1198 2013-07-03 09:39:18 <gmaxwell> but pinning doesn't scale...
1199 2013-07-03 09:39:20 <petertodd> gmaxwell: Yup, EFF too.
1200 2013-07-03 09:39:28 * gmaxwell kicks
1201 2013-07-03 09:39:34 agnostic98 has quit (Ping timeout: 248 seconds)
1202 2013-07-03 09:39:44 <MC1984> oh its a blocksize vote
1203 2013-07-03 09:39:46 <petertodd> gmaxwell: As I said, it's progress over what we have.
1204 2013-07-03 09:40:09 <MC1984> j dillion is for smaller blocks right?
1205 2013-07-03 09:40:12 <petertodd> MC1984: Yup, and understand *why* jdillon is proposing the system he is.
1206 2013-07-03 09:40:29 <petertodd> MC1984: Anyone sane is for a limit, the problem is agreeing on what the limit should be.
1207 2013-07-03 09:40:45 <MC1984> indeed
1208 2013-07-03 09:40:46 <petertodd> MC1984: It's a political problem within the boundries of technical constraints.
1209 2013-07-03 09:41:21 <MC1984> the limit should be nearly totally based on technical metrics imo
1210 2013-07-03 09:41:29 <MC1984> cos politics is a bust
1211 2013-07-03 09:41:43 <MC1984> but i dont want to start a huge thing about it now.....
1212 2013-07-03 09:41:43 <randy-waterhouse> "It's a political problem within the boundries of technical constraints." <=== that's cute, i gotta use that sometime
1213 2013-07-03 09:41:47 <petertodd> MC1984: I *really* like the idea of voting for it because it's the only sane way be can deal with the fact that the technical metrics mean different things to different people.
1214 2013-07-03 09:42:08 <petertodd> MC1984: I used to think voting wasn't going to work due to miner censorship, but jdillon's solution is extremely clever with regard to that.
1215 2013-07-03 09:42:19 <MC1984> i dont like the idea of locking out the developing world because us westerners have i7's and stuff
1216 2013-07-03 09:42:54 <petertodd> MC1984: Well, that's exactly the issue. What you consider to be the technical limits depends on non-technical things.
1217 2013-07-03 09:42:56 <randy-waterhouse> what about a commodore 64 does that put me in the game?
1218 2013-07-03 09:43:48 <MC1984> well pulling something out of my ass, id like a FVN to be doable with at most a few days of patience on hardware from a -5 years rolling window
1219 2013-07-03 09:44:27 <petertodd> Indeed, and the fact that you are talking about a FVN on hardware shows how you aren't as worried about network bandwidth as other people.
1220 2013-07-03 09:44:48 <randy-waterhouse> ok, now that's a technical boundary that actually tries to define the problem
1221 2013-07-03 09:45:14 <gmaxwell> MC1984: I don't know that this is true right now if blocks were maximum size. Shamefully, I'm not aware of _anyone_ who has done a full scale out test. I've tested single blocks and small runs of large size. I don't think _anyone_ has tested a 100gbyte blockchain.
1222 2013-07-03 09:45:24 <petertodd> But that's exactly the issue: *which* technical boundaries we consider more or less important isn't a technical question, it's a political question.
1223 2013-07-03 09:45:32 <randy-waterhouse> patience= ~ few days ; hardware <= 5 yyo
1224 2013-07-03 09:45:59 <gmaxwell> patience shouldn't be the right word: full verifying shouldn't really make you wait.
1225 2013-07-03 09:46:20 <gmaxwell> it's only the lameness of current software that your ability to use it is impeaded by the syncup.
1226 2013-07-03 09:47:13 <sipa> FVN?
1227 2013-07-03 09:47:40 <gmaxwell> "full verifying node"
1228 2013-07-03 09:47:44 <sipa> oh
1229 2013-07-03 09:47:54 <sipa> why didn't i ever see that abbreviated?
1230 2013-07-03 09:48:11 <randy-waterhouse> i agree ... there is maybe another technical limit also depending on the >50% chance of occurence of an error before full chain download
1231 2013-07-03 09:48:21 <gmaxwell> it's a mc1984ism, I think hes used it before.
1232 2013-07-03 09:48:59 <kinlo> gmaxwell: did you btw know of https://www.trustico.com/material/DS_GeoRoot_0205.pdf ?
1233 2013-07-03 09:49:02 <gmaxwell> randy-waterhouse: well if a node spends most of its life synching it can't contribute much to the network! :)
1234 2013-07-03 09:49:03 <petertodd> randy-waterhouse: There's *tons* of technical limits and tradeoffs. For instance being able to keep up with the blockchain isn't actually good enough: you need significantly more bandwidth than that in reserve to be able to recover from large re-orgs.
1235 2013-07-03 09:49:39 swulf--2 has quit (Ping timeout: 252 seconds)
1236 2013-07-03 09:49:48 <sipa> btw: in case of a reorg, we only announce the new tip
1237 2013-07-03 09:49:51 <gmaxwell> kinlo: in the abstract, not that vendor in particlar. Many parties have done this.
1238 2013-07-03 09:49:54 <randy-waterhouse> yep and yep
1239 2013-07-03 09:50:03 <sipa> i think we should announce all new blocks in the chain
1240 2013-07-03 09:50:22 <kinlo> gmaxwell: for me that just reads "ca system is broken"
1241 2013-07-03 09:50:37 <sipa> that saves a round trip with peers that dont have the overtaking sidechain yet
1242 2013-07-03 09:50:39 <petertodd> sipa: Not a bad idea; sucks that the blockchain is both stricly linear and doesn't have a total work field. :(
1243 2013-07-03 09:50:47 <gmaxwell> sipa: isn't the tip sufficient? the peer will try to fetch its parents. (If its not, I'd like to understand even if announcing is just simply better)
1244 2013-07-03 09:50:53 <gmaxwell> oh okay, fair enough.
1245 2013-07-03 09:51:09 <sipa> and others ignore it anyway
1246 2013-07-03 09:51:14 <randy-waterhouse> sipa: what happens with a fork?
1247 2013-07-03 09:51:37 <sipa> forks are fine
1248 2013-07-03 09:51:43 <sipa> they are not observable
1249 2013-07-03 09:51:51 <sipa> it is reorgs you need to be worried about
1250 2013-07-03 09:51:59 <gmaxwell> kinlo: enjoy this: https://bugzilla.mozilla.org/show_bug.cgi?id=724929
1251 2013-07-03 09:52:15 <randy-waterhouse> right ... what i meant i guess
1252 2013-07-03 09:52:45 <gmaxwell> kinlo: it's broken in a lot of ways, as I like to point out: lots of CAs (e.g. godaddy) have you authenticate control of a domain by having you place a text file on a webserver at that domain.. which they fetch over an insecure channel (duh, becauseâ no cert yet).
1253 2013-07-03 09:52:46 <sipa> the new block is announced, peers switch when it results in a new best chain
1254 2013-07-03 09:54:01 <petertodd> sipa: reminds me: it'd be useful if we broadcast headers for every block meeting the difficulty globally so we could measure the orphan rate. The bandwidth consumption would be trivial, and it'd be a very useful metric to know.
1255 2013-07-03 09:54:26 <gmaxwell> kinlo: so, with a few hundred bucks you can get a valid ca for any domain you can MITM near the server.
1256 2013-07-03 09:54:38 <gmaxwell> er valid ca signed cert.
1257 2013-07-03 09:55:00 <gmaxwell> "loltifricate"
1258 2013-07-03 09:55:45 <petertodd> gmaxwell: That's a perfect example where a mechanism based on automated fraud proofs would help make things more secure just by taking politics out of the equation.
1259 2013-07-03 09:57:10 <gmaxwell> except... you never escape the politics, â rather you hope to replace the politics with a suicide pact: maybe the foreknoweldge of this will make it acceptable. Dunno.
1260 2013-07-03 09:57:31 <gmaxwell> The reason the politics exist there isn't to protect the CA so much (though perhaps some of that) but to protect all the other crap it has signed for.
1261 2013-07-03 09:58:03 <gmaxwell> an interesting thought would be if there would be a way of preventing the CA from issuing new certs somehow if it breaks trust, but not breaking the existing ones.
1262 2013-07-03 09:58:08 <petertodd> gmaxwell: There is the meta-politics of adopting such a system in the first place of course.
1263 2013-07-03 09:58:22 <petertodd> gmaxwell: Timestamping...
1264 2013-07-03 09:58:59 <petertodd> Fraud proof would trigger code that invalidated any cert after the fraud was detected.
1265 2013-07-03 09:59:14 <TD> certs being stolen from insecure companies and servers are a much bigger deal than bad CAs
1266 2013-07-03 09:59:28 <gmaxwell> Yea. I think if that was viable it would make it easy. grandfather all the old ones, kill all the new ones. that would remove most of the suicidepactness of it.
1267 2013-07-03 09:59:38 <petertodd> TD: no, if I am a secure company a bad CA breaks my security
1268 2013-07-03 09:59:55 <petertodd> That's a good point: it's much less of a sucidie pact in that case.
1269 2013-07-03 10:00:03 <petertodd> *suicide
1270 2013-07-03 10:00:08 <TD> i'm talking about actual security problems that exist commonly. your company is very unlikely to be more secure than a CA, statistically.
1271 2013-07-03 10:00:20 <gmaxwell> TD: I'm not sure what dimension that you're measuring deal on, I mean "anyone with some money who can MITM the server can get a cert" really moots the protection against a broad class of attacks.
1272 2013-07-03 10:00:32 <TD> and how do you intend to MITM the server?
1273 2013-07-03 10:00:50 <petertodd> ...because I control your internet connection for instance.
1274 2013-07-03 10:01:36 <TD> and that is easy to achieve for which servers, exactly? can you take control of my server running inside a linode datacenter? probably not. at least, not easily. can you MITM the connection between a CA and google.com? i doubt it.
1275 2013-07-03 10:01:44 <gmaxwell> TD: maybe I spent too much time working for ISPs with enable on default free zone routers, for many people that particular thing isn't a pratical difficulty at all (short of a target like .. uh, google, which would get noticed)
1276 2013-07-03 10:02:09 <petertodd> Anyway, the main issue is the client's network connection.
1277 2013-07-03 10:02:56 <petertodd> I should be able to rely on SSL to protect me no matter how I am connecting to the internet, and with MITM enabling CA's I can't.
1278 2013-07-03 10:03:02 <TD> i think it is rather difficult. it's always easy to be an armchair hacker, harder to actually pull these things off without being detected. especially once you consider that most attackers that would want to do such a thing don't have the requisite skills to do so.
1279 2013-07-03 10:03:15 <gmaxwell> TD: e.g. during a nanog a couple years ago I and some cohorts happily did a demo 'hijacking' a /24 using _/23_ announcements which shouldn't have propagated at all, from varrious points on the interent with pretty good success. I should see if there is a recording of that.
1280 2013-07-03 10:03:18 <TD> (the ones that do have the skills, tend to have better approaches available)
1281 2013-07-03 10:03:51 <TD> yes, but any interesting target would have noticed that their site suddenly had a giant outage.
1282 2013-07-03 10:03:54 <petertodd> As usual TD assumes a world where the threat model is only small attackers.
1283 2013-07-03 10:03:56 <gmaxwell> We did without more than 20 minutes preparation, basically answering some fool at a mic that said it was hard.
1284 2013-07-03 10:04:17 <TD> you can sometimes hijack IP ranges if you can get access to an unfiltered BGP announcer, but doing that without anybody noticing you issued yourself a cert in the meantime? that has never been reported, right
1285 2013-07-03 10:04:19 <gmaxwell> TD: we didn't create one, since we routed the traffic back. (what we were taking was one of Wikimedia's unused /24s at the time)
1286 2013-07-03 10:04:58 <TD> as usual I assume a world with realistic threat models, not an infinite number of infinitely skilled/resourced attackers who are interested in every possible attack.
1287 2013-07-03 10:05:22 <TD> gmaxwell: ok, so you took control of an IP range that wasn't serving? so how would you issue a cert that way?
1288 2013-07-03 10:05:37 <gmaxwell> uh, ... I mean "attacker has access to the network" is the _specific_ problem SSL is intended to solve.
1289 2013-07-03 10:05:50 <petertodd> No, the most interesting threats right now are well-funded attackers trying to attack a very large number of targets at low cost, IE the NSA. For that the CA vulnerabilities help them greatly, while breaking into computers remotely is impractical.
1290 2013-07-03 10:06:25 <petertodd> Also, as gmaxwell points out SSL is failing at the very problem it was supposed to solve.
1291 2013-07-03 10:07:01 <gmaxwell> TD: you grab space that is, you redirect the actual traffic back (this is only technically hard if the traffic is _large_), and you request a cert from godaddy. You can do this in minutes if you precreate the request. They give you the file to place, and http fetch it right away.. and issue in under an hour.
1292 2013-07-03 10:07:10 <imd23> hey guys,don't want to bother, I need a way to get txs given an address (no 3rd party online APIs, I need to host this service/server on my own)
1293 2013-07-03 10:07:13 <TD> for the 99.9%+ of people who do not count governments in their personal threat model, the NSA is not an interesting threat because they know they can't win (and often don't even want to). for the vast majority of normal threats, like nosy coffee shop patrons or telcos that want to sell personal data, SSL is working fine and you don't have to worry about bad CAs because they're so rare.
1294 2013-07-03 10:07:35 zer0def has joined
1295 2013-07-03 10:08:07 <petertodd> Lol, telco's wanting to sell personal data is an example of a decently well funded attacker who can easily afford a few hundred bucks for a MITM box.
1296 2013-07-03 10:08:29 <TD> and the NSA doesn't seem to care about CA vulernabilities because they're trying to be stealthy (or were) and bogus certs can/do get detected. much easier for them to just use superwarrants
1297 2013-07-03 10:08:33 <petertodd> Specifically telcos are your example of an attacker trying to keep the cost per target low.
1298 2013-07-03 10:08:46 <gmaxwell> petertodd: you really must grant him the can't win point on sufficient attackers.
1299 2013-07-03 10:08:49 <TD> yes, and how does my mobile provider MITM my SSL connections? they can't, right.
1300 2013-07-03 10:08:59 <gmaxwell> TD: uhhh
1301 2013-07-03 10:09:01 <TD> it works well enough to stop that threat.
1302 2013-07-03 10:09:29 <petertodd> gmaxwell: Of course, but remember that cost *is* a very important issue for even well funded attackers because so often their target list is huge. Again, the "telco selling personal data" example is exactly that.
1303 2013-07-03 10:10:02 <petertodd> TD: They buy a MITM capable certificant from a CA playing loose with the rules, just like the link that was posted earlier.
1304 2013-07-03 10:10:05 tg has quit (Ping timeout: 276 seconds)
1305 2013-07-03 10:10:14 <petertodd> TD: (specifically a hardware box in that case)
1306 2013-07-03 10:10:18 ericmuyser has quit (Remote host closed the connection)
1307 2013-07-03 10:10:46 <petertodd> gmaxwell: It's why even just getting solid security against passive attackers is 90% of the problem really... which SSL does do a good job of.
1308 2013-07-03 10:11:21 egis has joined
1309 2013-07-03 10:11:21 <TD> they "just" do that, huh? CA's that incorrectly issue such certs get revoked. it has happened, what, once or twice? in the history of SSL? and at least one was a mistake. especially now you're seeing clients actively start to check they're getting the expect trust chains only suicidal CAs would do such a thing as
1310 2013-07-03 10:11:37 <petertodd> gmaxwell: But that other 10% is increasingly becoming an issue - mobile providers are doing MITM against SSL already, albeit by stripping off the SSL.
1311 2013-07-03 10:11:46 <TD> sorry, saying that a system as widely deployed as SSL doesn't work because of events I can count on the fingers of one hand is hardly compelling
1312 2013-07-03 10:12:02 <gmaxwell> TD: hm? issuing sub-ca certs for corporate use is a _product_, not a fluke.
1313 2013-07-03 10:12:17 <gmaxwell> https://www.trustico.com/material/DS_GeoRoot_0205.pdf
1314 2013-07-03 10:12:23 <gmaxwell> (as kinlo provided earlier)
1315 2013-07-03 10:12:55 <gmaxwell> they usually demand it be locked in an HSM, which is the only reason that every skiddie worth his salt doesn't have a couple. :P
1316 2013-07-03 10:14:09 <gmaxwell> the bluecoat boxes (etc) have an optional hsm so it can do DPI and dataleak detection against traffic leaving your network. In the intended app, not so scarry, but in those apps you could have just installed another trusted CA cert. :( the off label uses are more interesting.
1317 2013-07-03 10:15:21 zer0def has quit (Read error: Operation timed out)
1318 2013-07-03 10:15:24 reizuki__ has quit (Quit: Konversation terminated!)
1319 2013-07-03 10:15:38 <gmaxwell> petertodd: well, not just: http://gaurangkp.wordpress.com/2013/01/09/nokia-https-mitm/
1320 2013-07-03 10:15:40 <petertodd> What's so sad about those bluecoat boxes is how they could be implemented by just having a custom site-specific cert and adding it to the CA list on site-present devices.
1321 2013-07-03 10:16:12 <gmaxwell> petertodd: but it is the normâ ever since mobile providers have had data that they goof with the traffic like crazy, mostly for good motivations, for the most part ssl has been excempt.
1322 2013-07-03 10:16:18 <petertodd> gmaxwell: Heh, that's who I was thinking of - didn't realize they were doing it with a cert...
1323 2013-07-03 10:16:38 <gmaxwell> (or as you note, they force downgrade in some cases)
1324 2013-07-03 10:16:57 <petertodd> Yup, and force downgrade is perfectly acceptable, and makes it clear to anyone who bring in a device externally what is going on.
1325 2013-07-03 10:17:03 <petertodd> It's the honest way to do it.
1326 2013-07-03 10:18:06 <gmaxwell> Though some carriers have big plans to monetize collecting data on the users, mostly just because of the weird business dynamics. Competitive pressure has them selling service plans which aren't aligned with their costs and they need to make it up somehow other than higher loss volumes. :)
1327 2013-07-03 10:18:17 <TD> gmaxwell: yeah and trustwave came very close to total revocation. i doubt they'll be advertising such a product again. ssl is hardly perfect, but my original point stands - the weak point for most normal people is not SSL. it's the server getting hacked or the keys being stolen/acquired some other way
1328 2013-07-03 10:18:23 <TD> (like with stuxnet being a signed binary)
1329 2013-07-03 10:18:58 <TD> things like nokia are different because they actually issued you the device - i think it goes without saying that people who control your device can read your traffic ssl or no.
1330 2013-07-03 10:19:08 <petertodd> Again, it depends on your attacker: against an attacker with a large number of targets the low cost of MITM attacks is what is making the attacks possible.
1331 2013-07-03 10:19:36 <gmaxwell> TD: okay, I don't actually think we disagree, I do think you're taking a more homogeneous view of things than I am. The basic software security on both the client and server is #1 and #2 issues. But with enough application of money or paranoia, they can be addressed enough that SSL weaknesses are worse.
1332 2013-07-03 10:20:06 <gmaxwell> And for something like an MTGOX or what have you, fixing sever security is a survival requirement... so SSL security is more important.
1333 2013-07-03 10:20:54 <petertodd> MTGOX is a good example: CA vulnerabilities are something that the service provider has very little control over, while they do have control over their internal security practices.
1334 2013-07-03 10:21:10 <TD> for mtgox, possibly so, just because they're such an extreme case.
1335 2013-07-03 10:21:26 <TD> i'd like to build a bluetooth/local wifi propagating keystore app for android some day
1336 2013-07-03 10:21:34 <petertodd> Any financial site is in the same boat, as is any healthcare site.
1337 2013-07-03 10:21:40 <TD> so as you meet and mingle socially with people keys are being exchanged/compared in the background
1338 2013-07-03 10:21:45 <gmaxwell> Or the tor project or indymedia or...
1339 2013-07-03 10:21:53 toffoo has quit ()
1340 2013-07-03 10:21:59 <gmaxwell> TD: like the intersection of people who'd use that and mingle is non empty! :P
1341 2013-07-03 10:22:06 <TD> petertodd: i bet 90% of financial sites have crap server side security. most of them, don't operate in a world where hacks are fatal to the company
1342 2013-07-03 10:22:07 <petertodd> Or any site distributing software
1343 2013-07-03 10:22:27 <gmaxwell> petertodd: well, in an ideal world.. but it's pretty miserable now.
1344 2013-07-03 10:22:49 <gmaxwell> I like debian begging people to turn off the debian-multimedia repo because some unknown person got ownership of the domain...
1345 2013-07-03 10:22:50 <petertodd> TD: I don't believe that for a second because I know people in the industry and from what they tell me they take that stuff pretty seriously, and they are convincingly competent people.
1346 2013-07-03 10:23:20 <petertodd> gmaxwell: Ha, yeah, OTOH debian is protected by the PGP signing of packages to an extent.
1347 2013-07-03 10:23:32 <TD> anyway, back to work
1348 2013-07-03 10:23:42 <gmaxwell> petertodd: I imagine its not very consistent, TD is right about "most of them, don't operate in a world where hacks are fatal to the company" though they do all fund security which is better than 99% of all companies. :P
1349 2013-07-03 10:23:48 ralphtheninja has joined
1350 2013-07-03 10:24:03 <petertodd> gmaxwell: Yup, just because it's not fatal doesn't mean a security fuckup isn't horribly expensive.
1351 2013-07-03 10:24:31 <TD> i'm thinking of US banks that use password/secret question here ...
1352 2013-07-03 10:24:56 <gmaxwell> E.g. I had a friend who was a dedicated "computer security" for a tiny bank with only a dozen or two branches. ... but as far as I could tell his real job was only to be fired in case of hack.
1353 2013-07-03 10:25:00 <petertodd> TD: So what? That's the client's problem; that doesn't reflect the security of the servers themselves.
1354 2013-07-03 10:25:13 <gmaxwell> "If hacked, break out glass, remove dismissal papers"
1355 2013-07-03 10:25:16 <petertodd> gmaxwell: Keep in mind I'm in Canada; we don't have small banks.
1356 2013-07-03 10:25:37 <gmaxwell> well my point though was that at least they did have a dedicated computer security person.
1357 2013-07-03 10:25:46 <petertodd> gmaxwell: True
1358 2013-07-03 10:25:53 <SomeoneWeird> gmaxwell, that's true with a lot of companies
1359 2013-07-03 10:25:56 <SomeoneWeird> fallguy
1360 2013-07-03 10:25:58 <TD> alright, there were also cases where at least one bank had an unauthenticated account number in the url ...
1361 2013-07-03 10:26:32 <petertodd> SomeoneWeird: Granting, having a fallguy means you have at least one person who has an incentive to push to make things better. That person may be incompetent, but if they are competent it helps.
1362 2013-07-03 10:27:37 michagogo has joined
1363 2013-07-03 10:27:43 <SomeoneWeird> true
1364 2013-07-03 10:27:45 <gmaxwell> petertodd: my friend spent a lot of time making useless reports about how often they were port scanned. He wasn't incompetent by far, but security's real deliverables are invisible, while big portscan reports with graphs and look interesting.
1365 2013-07-03 10:28:06 <gmaxwell> i dunno if he ever actually improved security or if he was too busy with the fluff. :P
1366 2013-07-03 10:29:53 <petertodd> gmaxwell: Heh, yeah, the people I know in the industry complain about how much management likes useless reports like that.
1367 2013-07-03 10:30:10 rdponticelli has quit (Ping timeout: 240 seconds)
1368 2013-07-03 10:30:25 rdponticelli has joined
1369 2013-07-03 10:30:44 <petertodd> The impression I get is that banking stuff tends towards a model where you assume every system is vulnerable, there is nothing you can do about it, but with audits you can find problems after the fact.
1370 2013-07-03 10:31:00 <petertodd> Which is wrong in the age of crypto, but it's still much better than not doing it at all.
1371 2013-07-03 10:31:42 <petertodd> It also leads to an insurance model where you keep systems the way they are provided the losses aren't too high, even if in theory a redesign could drive losses down to zero.
1372 2013-07-03 10:32:23 <petertodd> Fundemental problem is the management has no capability to evaluate if a redesign is or isn't crypto snakeoil, but they do understand auditing.
1373 2013-07-03 10:32:51 <gmaxwell> s/management/mankind/ perhaps
1374 2013-07-03 10:32:56 <gmaxwell> this stuff is not easy.
1375 2013-07-03 10:33:05 <petertodd> Heh, mankind - crypto nerds
1376 2013-07-03 10:33:17 <sipa> i'm glad they at least realize that crypto snakeoil exists :)
1377 2013-07-03 10:33:22 <petertodd> Just look at the discussions we have on -wizards...
1378 2013-07-03 10:33:49 <petertodd> sipa: Sadly from what I hear that's party because the industry has been burned before...
1379 2013-07-03 10:33:52 <gmaxwell> SSL is arguably snake oil as deployedâ regardless of TD's reasonable arguments about the weakest link, it doesn't provide the properties people believe and expect it to provide. If SSL can be pratically snake oil, what else is?
1380 2013-07-03 10:34:17 zer0def has joined
1381 2013-07-03 10:34:42 <petertodd> gmaxwell: Depends: I firmly believe that protection against passive evesdroppers is 90% of the problem - SSL would be better if a https connection could be made with no CA's involved at all without the browser going into fits.
1382 2013-07-03 10:35:28 <petertodd> gmaxwell: Obviously you need a scheme for a site to be able to force CA-certified SSL if they need too of course...
1383 2013-07-03 10:37:13 <MC1984> how do you do it without public authorities
1384 2013-07-03 10:37:15 <gmaxwell> petertodd: I started talking to some people about making "HTTP" urls do transparent use SPDY/TLS if available... maybe that will go someplace.
1385 2013-07-03 10:37:24 <MC1984> ive been told that WOT is cute but would be a bust on that scale
1386 2013-07-03 10:37:29 <petertodd> gmaxwell: Good! That needs to happen.
1387 2013-07-03 10:38:05 <gmaxwell> petertodd: idea being that if you use HTTP and SPDY/TLS is there it'll use that. If not it won't. It won't validate the cert... but you can't tell if its encrypted or not otherwise. If you use https, you'd get the current behavior.
1388 2013-07-03 10:38:47 <petertodd> gmaxwell: Perfect.
1389 2013-07-03 10:39:12 <petertodd> gmaxwell: If I had a nickel for every time some idiot goes on about how unauthenticated SSL is worse than not encrypting at all...
1390 2013-07-03 10:39:35 <gmaxwell> well its true if it risks tricking people. :P but no harm if the user can't tell. :)
1391 2013-07-03 10:39:38 <sipa> it is worse if it gives a false sense of security
1392 2013-07-03 10:39:49 <sipa> it's not technically worse
1393 2013-07-03 10:40:09 <petertodd> Yup, hence just don't tell the user it's SSL...
1394 2013-07-03 10:40:17 <sipa> sounds perfect
1395 2013-07-03 10:40:28 <TD> gmaxwell: that would be very hard to deploy
1396 2013-07-03 10:40:34 <gmaxwell> the model would be the same HTTP == insecure, HTTPS == (lol)secure. But if quasisecure is possible for http the it would do it and kill the passive interception.
1397 2013-07-03 10:41:15 <MC1984> is spdy crypted by default? I thought spdy was opportunistic any way
1398 2013-07-03 10:41:19 <petertodd> gmaxwell: There's also an interesting low-cost encrypted TCP protocol out there too BTW that would do OS-level opportunistic encryption.
1399 2013-07-03 10:41:31 <petertodd> MC1984: spdy has no uncrypted mode
1400 2013-07-03 10:41:43 <MC1984> oh cool
1401 2013-07-03 10:41:56 <petertodd> MC1984: it's actually a technical decision to ensure proxies don't mess it up
1402 2013-07-03 10:42:03 <MC1984> so if its opportunistic, isnt the situation above already the case
1403 2013-07-03 10:42:11 <petertodd> MC1984: (modulo CA cert fraud MITM boxes...)
1404 2013-07-03 10:42:20 <TD> quite a few sites can't handle all their traffic being SSL for performance/load reasons.
1405 2013-07-03 10:42:36 <gmaxwell> I mean, this may ultimately fit into httpbis, I'm going to be talking with some people at the berlin ietf meeting about it.
1406 2013-07-03 10:42:39 <TD> so it'd have to be opt in. and then ..... that defeats the point. might as well just deploy the real thing.
1407 2013-07-03 10:42:46 <gmaxwell> TD: some of that is some unfortuante consequences of the design of SSL.
1408 2013-07-03 10:42:47 <petertodd> TD: meh, spend the extra 10% on hardware, SSL is cheap
1409 2013-07-03 10:42:57 <petertodd> httpbis?
1410 2013-07-03 10:43:12 <TD> no. you cannot just randomly increase the load on every website in the world by deploying an overnight browser upgrade and tell people to suck it
1411 2013-07-03 10:43:32 <petertodd> On the other hand leaving the blocksize up to miners is perfectly ok...
1412 2013-07-03 10:43:34 <gmaxwell> TD: and no, being opt in doesn't actually defeat the point. It means that is must be vulnerable to downgrading, and would take a long time to deploy, but thats an active attack.
1413 2013-07-03 10:44:08 <TD> the goal is to get encryption for traffic to sites that don't really care, right? so why would they ever deploy it?
1414 2013-07-03 10:44:33 akrmn has quit (Read error: Operation timed out)
1415 2013-07-03 10:44:33 <gmaxwell> Because it can eventually be a default on in webservers and such.
1416 2013-07-03 10:44:38 <petertodd> gmaxwell: Downgrading risk isn't so bad anyway - you only need to make one non-MITM'd connection initially to protect from downgrades later.
1417 2013-07-03 10:44:40 Skav has joined
1418 2013-07-03 10:46:19 <TD> you can't protect from "downgrades" in the presence of a MITM because you can't treat key rotations as errors
1419 2013-07-03 10:46:27 <gmaxwell> And moreover, it gives a middle ground option between totally unencrypted and vulnerable to passive attackers and full https which has a lot more setup costs. Just some knob in your webserver that you can turn off if there are load problems. In ten years its on everywhere and hardware has been made suitably capable.
1420 2013-07-03 10:46:29 <TD> gmaxwell: that really would take years! but true
1421 2013-07-03 10:47:15 MobPhone has quit (Ping timeout: 240 seconds)
1422 2013-07-03 10:47:20 <petertodd> TD: If CA's weren't commiting fraud that would be fine - the downgrade would only be to non-SSL.
1423 2013-07-03 10:47:35 <gmaxwell> right, downgrading can't be stopped in that context. But thats what doing real security is for. Bonus: hardware has been subdizied by all the people getting crypto by default, so the only real cost of real security is setting up the PKI.
1424 2013-07-03 10:48:06 Skav has quit (Read error: Connection reset by peer)
1425 2013-07-03 10:48:09 MobPhone has joined
1426 2013-07-03 10:48:41 daybyter has joined
1427 2013-07-03 10:49:09 <petertodd> Commodity x86 hardware increasingly has dedicated crypto instructions for instance for AES and SHA*
1428 2013-07-03 10:49:16 <TD> i suppose another possible objection is that some website operators would try and advertise their site as encrypted, even if they weren't using real certs. if the browsers didn't provide any way to see that unverified SSL was in use, then you solve that problem, but just go back to the lack of incentive, why would websites opt in to that when nobody would notice
1429 2013-07-03 10:49:24 <TD> that was the rationale for the padlock
1430 2013-07-03 10:49:55 <gmaxwell> well websites already put all kinds of idiot fake security emblems on them.
1431 2013-07-03 10:49:59 <walch> TD: I've seen people report similar before. even just a picture of a padlock somewhere on a sales page increases the number of customers that ordered and paid, even if there was no real security
1432 2013-07-03 10:50:06 <TD> yeah
1433 2013-07-03 10:50:08 setkeh has quit (Ping timeout: 256 seconds)
1434 2013-07-03 10:50:20 <michagogo> What part of the code generates block templates?
1435 2013-07-03 10:50:22 <TD> basically ~nobody understands the concept of trusted vs untrusted pixels, this is a well known problem
1436 2013-07-03 10:50:29 <michagogo> (in response to gegblocktemplate)
1437 2013-07-03 10:50:30 <petertodd> michagogo: CreateNewBlock()
1438 2013-07-03 10:50:43 <michagogo> get*
1439 2013-07-03 10:50:58 <TD> the biggest and most important upgrade to browser security we could make right now is fixing the damn address bar
1440 2013-07-03 10:51:00 <michagogo> Also, will this do what I'm expecting, or will it backfire spectacularly:
1441 2013-07-03 10:51:11 <petertodd> I posted a challenge to my friends to send me an encrypted message with PGP... one person managed to send me an encrypted message, but only encrypted to themselves.
1442 2013-07-03 10:51:11 <TD> i was talking to someone the other day who "exited" the bitcoin scene after she lost all her coins to phishing
1443 2013-07-03 10:51:19 <michagogo> I'm trying to figure out how to solo-mine a block on the testnet
1444 2013-07-03 10:51:21 tg has joined
1445 2013-07-03 10:51:26 <TD> petertodd: so you recreated the why jonny study? :)
1446 2013-07-03 10:51:32 <TD> i guess that gives it more scientific validity ..
1447 2013-07-03 10:51:36 <gmaxwell> But why would the site? "The power of defaults" and "This is advertised as a best practice". On the way, the payoff from performing attacksâ building varrious spy infrastructure, hacking network infrastructure, etc. goes down just because of the reduction in targets even if its not everyone.
1448 2013-07-03 10:51:40 <michagogo> bfgminer seems to not recognize that the difficulty drops to 1 every 20 minutes
1449 2013-07-03 10:51:40 <walch> TD: there's sort of been attempts to do that, the whole extended verification system with a green bar was apparently meant to improve customer recognition of security
1450 2013-07-03 10:51:45 <petertodd> TD: why jonny?
1451 2013-07-03 10:52:03 <TD> petertodd: "why jonny can't encrypt" http://www.gaudior.net/alma/johnny.pdf
1452 2013-07-03 10:52:13 <michagogo> What I was thinking was, maybe I could patch bitcoind to always generate a block template with a difficulty of 1
1453 2013-07-03 10:52:23 <TD> walch: the issue is not the color or the padlocks. it's the fact that iirc ~25% of people never look at the address bar _at all_
1454 2013-07-03 10:52:31 <TD> walch: because it contains nonsense, right? just technical junk
1455 2013-07-03 10:52:33 <petertodd> TD: Ah, yeah that's exactly what I was doing.
1456 2013-07-03 10:52:45 <gmaxwell> petertodd: we made our opus/webrtc intern at the office get a signed PGP key to get access to a review system. Took him all morning to get it going. :P PGP/GPG usablity is awful.
1457 2013-07-03 10:53:03 <TD> walch: phishing is by far more common a problem than issues with SSL and it works very reliably, because lots of people have just tuned out of the address bar due to the horrible usability / ui design of it
1458 2013-07-03 10:53:11 <michagogo> And then any such blocks found would simply not be considered valid until the difficulty dropped again
1459 2013-07-03 10:53:19 <walch> TD: the address bar used to make a whole lot more sense. I enjoyed when URL were categorical.
1460 2013-07-03 10:53:21 <michagogo> Would this work, or am I overlooking something?
1461 2013-07-03 10:53:27 <petertodd> gmaxwell: Yeah, although I don't have high hopes for making it much better because the fundemental concepts are a lot harder for people to understand than I think we realize.
1462 2013-07-03 10:53:29 <TD> i tried to get the chrome guys to do something about that years ago when the product was brand new, but they were far more conservative than i was :) they went as far as not display http:// by default and even that enraged a bunch of geeks :)
1463 2013-07-03 10:53:44 <walch> TD: that is, if I saw example.com/fish/red/, I could expect that example.com/fish/ would contain a list of all fish
1464 2013-07-03 10:53:49 <petertodd> gmaxwell: I run into this with revision control at work: the very concept of revisions is surprisingly hard for people to understand.
1465 2013-07-03 10:53:54 <gmaxwell> michagogo: thats not how it works. difficulty is a function of the particular chain you're on. and the best chain is the chain with the greatest sum difficulty.
1466 2013-07-03 10:54:14 <michagogo> gmaxwell: I know, but on the testnet the difficulty drops if no block is found for 20 mins
1467 2013-07-03 10:54:51 <gmaxwell> michagogo: I missed you were asking about testnet. You can only do that if you timestamp your blocks in the future.
1468 2013-07-03 10:54:52 <TD> well, this is why i'm interested in passive solutions. the web of trust model isn't totally bogus - your roots of trust are usually people you've met or know indirectly in some way. the problem is that the actual act of moving keys around and using them is so explicit and horrible
1469 2013-07-03 10:54:56 <michagogo> gmaxwell: And apparently that drop is only in effect for one block, rather than resetting to 1 and building up from there
1470 2013-07-03 10:54:58 <lianj> i always said the internet could benefit from some kind of a drivers license :P
1471 2013-07-03 10:54:58 setkeh has joined
1472 2013-07-03 10:55:11 <gmaxwell> michagogo: sometimes
1473 2013-07-03 10:55:17 <michagogo> Sometimes?
1474 2013-07-03 10:55:20 <michagogo> What does that mean?
1475 2013-07-03 10:55:30 <gmaxwell> michagogo: it resets to one if the block before a retarget was a special 1 block.
1476 2013-07-03 10:55:34 <petertodd> TD: Sure, so am I. But I accept that it's probably impossible to get the masses to have much better security than security against passive attackers.
1477 2013-07-03 10:55:44 <michagogo> gmaxwell: Ah
1478 2013-07-03 10:55:55 <michagogo> But still, that retarget will take a month
1479 2013-07-03 10:56:09 <michagogo> gmaxwell: Anyway, bfgminer doesn
1480 2013-07-03 10:56:13 <petertodd> TD: Roots of trust stuff with your social group smells like an AI problem for instance.
1481 2013-07-03 10:56:14 <gmaxwell> michagogo: in any case, if you mine blocks with difficulty 1 _and_ put a 20 minute gap in their timestamps, then they'll become valid as the timestamps become current enough.
1482 2013-07-03 10:56:26 <michagogo> 't appear to recognize the difficulty drop
1483 2013-07-03 10:56:43 <gmaxwell> michagogo: but if someone else mines a higher difficulty in meantime, it'll kill your fork.
1484 2013-07-03 10:56:53 fanquake has quit (Ping timeout: 276 seconds)
1485 2013-07-03 10:57:08 <gmaxwell> michagogo: you sure about that? Or are you just getting confused because it can't longpoll against bitcoind so it doesn't find out about it for two minutes?
1486 2013-07-03 10:57:13 <TD> i'd say UI problems rather than AI :)
1487 2013-07-03 10:57:19 talso has quit (Ping timeout: 252 seconds)
1488 2013-07-03 10:57:49 <walch> speaking of UI problems, would anybody be able to help tackle issue #2810 today?
1489 2013-07-03 10:58:00 <michagogo> gmaxwell: I'm running with `bfgminer.exe -o http://192.168.56.101:18332 -u user -p password --coinbase-addr mvXQFs7xmJ5PJGrqYYLMnZ31DcaqXVASFA --request-diff 1 -P -s 7 -E 7`
1490 2013-07-03 10:58:08 <petertodd> TD: No, I'm quite serious about AI, because as I say a very large chunk of the population is incapable of understanding what trust is so the computer will be making decisions for them. (against certain classes of attackers)
1491 2013-07-03 10:58:10 <michagogo> So it's getblocktemplate-ing every 7 seconds
1492 2013-07-03 10:58:41 <michagogo> gmaxwell: Why can't I simply make getblocktemplate always return the target corresponding to difficulty 1? Unless I misunderstand how it works, bfgminer will submit any blocks that it finds with difficulty 1
1493 2013-07-03 10:58:54 <michagogo> But until the 20-minute mark is hit, those blocks will just be thrown out by bitcoind
1494 2013-07-03 10:59:06 <petertodd> TD: Again, this is like revision control: you have to deal with the fact that many people actually can't understand the idea of a hiarchical revision system, or even revisions at all.
1495 2013-07-03 11:00:16 fanquake has joined
1496 2013-07-03 11:00:23 <gmaxwell> petertodd: well, hey, getting only attacked by people who went through the trouble of setting up a bluetooth thingy on the train platform near my house is an _improvement_ of getting hacked by kids in china.
1497 2013-07-03 11:00:30 <gmaxwell> s/of/over/
1498 2013-07-03 11:00:33 <petertodd> TD: You don't realize this in programming, but I work in hardware and it just isn't possible to hire people who are competent enough to understand revisions, yet don't get bored silly by the manual labor required to build things.
1499 2013-07-03 11:00:41 <TD> so the trick is, don't ask them to. though SSL isn't perfect, it does often work correctly because you hear a friend say, hey check out widgets.com and then when you type widgets.com into your browser, the rest happens more or less automagically. there are plenty of things that can go wrong along the way, but ultimately an encrypted connection is set up without the user understanding what happened, and it mostly works, most of the time
1500 2013-07-03 11:01:13 <gmaxwell> TD: some people have proposed URL schemes that have fingerprints in them, to bootstrap off the trust of the link you followed.
1501 2013-07-03 11:01:16 <TD> and revision control is again not a hard concept. lawyers use it in MS Word all the time. it's not as sophisticated as git, but it's good enough for what they need.
1502 2013-07-03 11:01:18 <petertodd> gmaxwell: Sure, I agree we can improve on the situation, I'm just saying the maximum improvements are far from "make better UI's and have everyone use web-of-trust properly"
1503 2013-07-03 11:01:33 <TD> gmaxwell: well like onion URLs. there's a tor protocol proposal to let you have hidden services without the hidden prat
1504 2013-07-03 11:01:35 <TD> part
1505 2013-07-03 11:02:00 <michagogo> gmaxwell: Is there something that I'm missing, some reason that won't work?
1506 2013-07-03 11:02:19 <petertodd> TD: your average lawyer is a lot more capable of thinking abstractly than the technicians I'm talking about...
1507 2013-07-03 11:03:01 <michagogo> I mean, the getblocktemplate code can be modified without affecting the block sumbission validation code, right?
1508 2013-07-03 11:03:07 <gmaxwell> petertodd: in the US the lawschool entrance test has a fantastic logic puzzle section. They're pretty fun.
1509 2013-07-03 11:03:08 <michagogo> submission*
1510 2013-07-03 11:03:27 <michagogo> (submitblock?)
1511 2013-07-03 11:03:30 <petertodd> gmaxwell: Law is basically fuzzy programming. :P
1512 2013-07-03 11:03:44 <gmaxwell> petertodd: http://www.cambridgelsat.com/resources/free-downloads/logic-games-practice/
1513 2013-07-03 11:04:00 <gmaxwell> michagogo: sure you could modify it so you gave yourself invalid work and spammed it and would accept it once valid.
1514 2013-07-03 11:04:58 <michagogo> Huh, I just thought of something
1515 2013-07-03 11:05:06 <michagogo> Wait, nvm
1516 2013-07-03 11:05:20 <michagogo> gmaxwell: What would I need to modify to do that?
1517 2013-07-03 11:05:44 o3u_ has quit (Read error: Connection reset by peer)
1518 2013-07-03 11:05:59 <michagogo> gmaxwell: Would it be https://github.com/bitcoin/bitcoin/blob/v0.8.3/src/rpcmining.cpp#L333 ?
1519 2013-07-03 11:06:21 <michagogo> Or would it be hashTarget.GetHex?
1520 2013-07-03 11:07:17 talso has joined
1521 2013-07-03 11:07:26 <gmaxwell> you'll need to change CreateNewBlock or it'll never match up, I suspect.
1522 2013-07-03 11:08:00 <gmaxwell> look for GetNextWorkRequired somewhere in it.
1523 2013-07-03 11:09:50 <michagogo> So that's https://github.com/bitcoin/bitcoin/blob/v0.8.3/src/main.cpp#L4173 ?
1524 2013-07-03 11:09:56 BTCOxygen has quit (Ping timeout: 240 seconds)
1525 2013-07-03 11:11:36 <gmaxwell> someplace in there.
1526 2013-07-03 11:11:56 <gmaxwell> michagogo: go try, failure is the best way to learn
1527 2013-07-03 11:12:08 <michagogo> https://github.com/bitcoin/bitcoin/blob/v0.8.3/src/main.cpp#L4402 maybe?
1528 2013-07-03 11:12:22 <petertodd> michagogo: maybe
1529 2013-07-03 11:12:29 omnibrain has quit (Ping timeout: 276 seconds)
1530 2013-07-03 11:12:29 <michagogo> gmaxwell: The problem is, I don't really know c++ :-/
1531 2013-07-03 11:12:40 <michagogo> So I can't really tell what all these things are doing
1532 2013-07-03 11:13:03 <gmaxwell> michagogo: go randomly ape in some printf statements (results show up in debug log).
1533 2013-07-03 11:13:16 <michagogo> hmm?
1534 2013-07-03 11:13:27 <michagogo> What printf statements?
1535 2013-07-03 11:13:46 omnibrain has joined
1536 2013-07-03 11:13:49 <petertodd> michagogo: Add in printf() statements that print variables and other stuff to learn what's going on.
1537 2013-07-03 11:14:53 <gmaxwell> michagogo: you can add code to make it print things. printf("yippie\n"); then look in the logs and see whats happening. you can go look at the code for other printfs to guess at the syntax.
1538 2013-07-03 11:16:26 <michagogo> pblock->nBits = GetNextWorkRequired(pindexPrev, pblock);
1539 2013-07-03 11:16:26 <michagogo> looks like it might be the right place for it
1540 2013-07-03 11:16:43 <michagogo> But I don't know what the "pblock->nBits" syntax means or does
1541 2013-07-03 11:17:05 <gmaxwell> http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B
1542 2013-07-03 11:17:28 <gmaxwell> hm less helpful than I might have guessed.
1543 2013-07-03 11:18:00 <gmaxwell> nBits is a varable in the pblock object, its getting assingned to the result of GetNextWorkRequired() there.
1544 2013-07-03 11:18:11 <gmaxwell> nbits is the compact representation of the difficulty used in the block headers.
1545 2013-07-03 11:18:56 <michagogo> ...what's a Structure dereference?
1546 2013-07-03 11:19:32 <gmaxwell> michagogo: what languages do you know? (or do you know any at all?)
1547 2013-07-03 11:19:46 <michagogo> I know a little bit of Ruby
1548 2013-07-03 11:20:09 <michagogo> And I can read some similar languages and somewhat understand them
1549 2013-07-03 11:20:18 <michagogo> C++ does not appear to be one of these languages.
1550 2013-07-03 11:21:10 <gmaxwell> okay I know squat about ruby. But in that case there is a pblock object. It has a variable inside it called "nBits". It's getting set here. (in C there are no objects, but structs are similar/based on the same machinery, and so the syntax is the same for this).
1551 2013-07-03 11:21:32 <michagogo> I don't suppose " pblock->nBits = 0x00000000FFFF0000000000000000000000000000000000000000000000000000;" woudl work?
1552 2013-07-03 11:21:43 <michagogo> gmaxwell: I see.
1553 2013-07-03 11:22:38 <gmaxwell> pblock->nBits = nProofOfWorkLimit; should work.
1554 2013-07-03 11:22:53 <gmaxwell> ah, no, Params().ProofOfWorkLimit().GetCompact();
1555 2013-07-03 11:22:58 OneFixt has quit (Read error: Connection reset by peer)
1556 2013-07-03 11:23:07 <gmaxwell> code has changed around a bit with the chain parameters refactoring.
1557 2013-07-03 11:23:36 <michagogo> "pblock->nBits = Params().ProofOfWorkLimit().GetCompact();" ?
1558 2013-07-03 11:23:36 OneFixt has joined
1559 2013-07-03 11:23:41 <gmaxwell> maybe!
1560 2013-07-03 11:23:44 <michagogo> And is that the only change I would need?
1561 2013-07-03 11:23:52 <gmaxwell> in any case, go bludgeon yourself for an hour against it. you'll learn something.
1562 2013-07-03 11:23:56 <gmaxwell> Maybe!
1563 2013-07-03 11:24:17 <michagogo> I'll try adding "printf(Params().ProofOfWorkLimit().GetCompact());"
1564 2013-07-03 11:25:10 MC1984 has quit (Read error: Connection reset by peer)
1565 2013-07-03 11:25:33 <walch> gmaxwell: if you've time to, would you be able to help with my quick issue?
1566 2013-07-03 11:25:50 <gmaxwell> 4am here. I'm out! sorry!
1567 2013-07-03 11:26:03 paraipan has joined
1568 2013-07-03 11:26:03 viperhr has quit (Read error: Operation timed out)
1569 2013-07-03 11:26:06 paraipan has quit (Remote host closed the connection)
1570 2013-07-03 11:26:09 <walch> ah, never mind. I'm sure somebody will see it at some point.
1571 2013-07-03 11:28:00 adam3us has quit (Quit: Leaving.)
1572 2013-07-03 11:28:11 adam3us has joined
1573 2013-07-03 11:29:13 <michagogo> ...well that didn't work
1574 2013-07-03 11:29:18 <michagogo> main.cpp: In function âCBlockTemplate* CreateNewBlock(CReserveKey&)â:
1575 2013-07-03 11:29:18 <michagogo> main.cpp:4402:16: error: âParamsâ was not declared in this scope
1576 2013-07-03 11:29:18 <michagogo> main.cpp:4404:9: error: ânProofOfWorkLimitâ was not declared in this scope
1577 2013-07-03 11:29:57 <michagogo> I added "printf(Params().ProofOfWorkLimit().GetCompact());" and "printf(nProofOfWorkLimit);"
1578 2013-07-03 11:30:10 <michagogo> :-/
1579 2013-07-03 11:30:18 <petertodd> michagogo: I think you may just have to bite the bullet and learn some C++
1580 2013-07-03 11:33:50 <petertodd> damn: I've got a 684 tx deep chain of 0 fee transactions moving around 248BTC in my mempool right now, 142KiB worth - that spammer is persistent
1581 2013-07-03 11:34:34 <petertodd> (my cpfp-mempool I'm working on keeps track of depth and sum fees and size)
1582 2013-07-03 11:36:06 one_zero has quit ()
1583 2013-07-03 11:36:34 <walch> petertodd: is there anybody maintaining graphs of that sort of information?
1584 2013-07-03 11:36:42 <walch> I like graphs.
1585 2013-07-03 11:36:54 <petertodd> walch: AFAIK no, although I thought jgarzik had plans for some of that stuff
1586 2013-07-03 11:37:57 nizeguy has joined
1587 2013-07-03 11:38:12 agnostic98 has joined
1588 2013-07-03 11:38:23 <randy-waterhouse> i've seen graphs of UTX0 ... not sure who's though
1589 2013-07-03 11:38:24 JZavala has joined
1590 2013-07-03 11:38:46 <petertodd> randy-waterhouse: yeah, lots of blockchain data, but very little P2P network data
1591 2013-07-03 11:39:18 <randy-waterhouse> published p2p data
1592 2013-07-03 11:39:21 <petertodd> although it shouldn't be possible to collect too much p2p network data for privacy reasons...
1593 2013-07-03 11:39:32 <michagogo> randy-waterhouse: UTXO
1594 2013-07-03 11:39:34 <michagogo> O, not 0
1595 2013-07-03 11:39:56 <randy-waterhouse> O
1596 2013-07-03 11:41:28 viperhr has joined
1597 2013-07-03 11:41:33 agnostic98 has quit (Read error: Connection reset by peer)
1598 2013-07-03 11:42:29 porquilho has joined
1599 2013-07-03 11:43:09 paraipan has joined
1600 2013-07-03 11:43:14 <randy-waterhouse> this one is for the devs .... "The currency could plummet at a later date if the developers change the terms and remove the limits on how much source code can be mined, "
1601 2013-07-03 11:43:32 <randy-waterhouse> http://www.smh.com.au/it-pro/business-it/winklevoss-twins8217-bid-to-bring-bitcoins-to-the-masses-20130703-hv0nb.html
1602 2013-07-03 11:43:35 <randy-waterhouse> source code minig is the new new
1603 2013-07-03 11:43:49 <michagogo> How much source code can be mined?
1604 2013-07-03 11:43:50 <michagogo> LOL
1605 2013-07-03 11:44:06 <michagogo> Not to mention, they can't "change the terms" unilaterally
1606 2013-07-03 11:44:10 _BtZeal0t has left ()
1607 2013-07-03 11:44:19 paraipan has quit (Remote host closed the connection)
1608 2013-07-03 11:44:30 <michagogo> Changing that would mean it was no longer bitcoin
1609 2013-07-03 11:44:37 <petertodd> That's a pretty reasonable thing to have in a SEC disclosure actually; the issue isn't that the devs can actually change the terms, it's that if they did that confidence in Bitcoin would drop because we'd realize the devs were crazy and we'd need a brand new team.
1610 2013-07-03 11:44:59 <gmaxwell> the SEC filings addressed this. Did they actually link to them?
1611 2013-07-03 11:45:26 <gmaxwell> http://www.sec.gov/Archives/edgar/data/1579346/000119312513279830/d562329ds1.htm
1612 2013-07-03 11:45:29 datagutt has joined
1613 2013-07-03 11:45:35 <randy-waterhouse> that wording is just wrong though ... how can anyone "mine source code"?
1614 2013-07-03 11:45:52 <gmaxwell> "The administrators of the Bitcoin Networkâs source code could propose amendments to the Bitcoin Networkâs protocols and software that, if accepted and authorized by the Bitcoin Networkâs community, could adversely affect an investment in the Shares. "
1615 2013-07-03 11:46:03 paraipan has joined
1616 2013-07-03 11:46:06 paraipan has quit (Remote host closed the connection)
1617 2013-07-03 11:46:25 <michagogo> gmaxwell: What you suggested wouldn't compile
1618 2013-07-03 11:46:50 <michagogo> "error: âParamsâ was not declared in this scope"
1619 2013-07-03 11:47:28 <randy-waterhouse> although it sounds kind of correct and cool ... I'll be in my cave mining some source code, do not disturb
1620 2013-07-03 11:47:43 paraipan has joined
1621 2013-07-03 11:47:51 paraipan has quit (Remote host closed the connection)
1622 2013-07-03 11:48:55 <randy-waterhouse> seymour cray used to dig tunnels under his property while he was thinking up new designs for boards, architectures, etc
1623 2013-07-03 11:49:16 paraipan has joined
1624 2013-07-03 11:49:18 <randy-waterhouse> he said the fairies in the mines gave him the best ideas
1625 2013-07-03 11:50:21 MC1984 has joined
1626 2013-07-03 11:51:30 Jere_Jones has quit ()
1627 2013-07-03 11:52:17 paraipan has quit (Remote host closed the connection)
1628 2013-07-03 11:52:18 Jackneill has joined
1629 2013-07-03 11:52:18 Jackneill has quit (Changing host)
1630 2013-07-03 11:52:18 Jackneill has joined
1631 2013-07-03 11:53:55 a_meteorite has joined
1632 2013-07-03 11:54:19 a_meteorite is now known as Guest41549
1633 2013-07-03 11:55:05 <randy-waterhouse> elves actually
1634 2013-07-03 11:55:43 sivu has quit (Changing host)
1635 2013-07-03 11:55:43 sivu has joined
1636 2013-07-03 11:55:48 sivu has left ()
1637 2013-07-03 11:55:50 taha has joined
1638 2013-07-03 11:56:01 sivu has joined
1639 2013-07-03 11:56:11 <sivu> elves don't go into mines
1640 2013-07-03 11:56:30 msvb-lab has joined
1641 2013-07-03 11:57:33 Guest41549 has left ()
1642 2013-07-03 11:58:06 <randy-waterhouse> ok, it's probably some corporate BS anyway ...
1643 2013-07-03 11:59:13 BTCOxygen has joined
1644 2013-07-03 12:00:27 nizeguy has quit (Remote host closed the connection)
1645 2013-07-03 12:01:26 imd23 has quit (Quit: imd23)
1646 2013-07-03 12:03:50 nizeguy has joined
1647 2013-07-03 12:07:14 ericmuyser has joined
1648 2013-07-03 12:08:51 agnostic98 has joined
1649 2013-07-03 12:13:15 agnostic98 has quit (Ping timeout: 256 seconds)
1650 2013-07-03 12:13:15 ralphtheninja has quit (Ping timeout: 256 seconds)
1651 2013-07-03 12:20:44 execut3 has quit (Ping timeout: 276 seconds)
1652 2013-07-03 12:24:51 _BtZeal0t has joined
1653 2013-07-03 12:30:56 Grouver has joined
1654 2013-07-03 12:32:28 execut3 has joined
1655 2013-07-03 12:33:13 wei_ has quit (Quit: wei_)
1656 2013-07-03 12:33:37 ousado has quit (Read error: Operation timed out)
1657 2013-07-03 12:35:28 ousado has joined
1658 2013-07-03 12:37:50 _BtZeal0t has quit ()
1659 2013-07-03 12:38:15 Insti has quit (Ping timeout: 248 seconds)
1660 2013-07-03 12:39:00 Insti has joined
1661 2013-07-03 12:47:00 jtimon_ has joined
1662 2013-07-03 12:48:02 kjj has quit (Ping timeout: 276 seconds)
1663 2013-07-03 12:48:23 jtimon has quit (Ping timeout: 248 seconds)
1664 2013-07-03 12:50:42 kjj has joined
1665 2013-07-03 12:53:02 daybyter has quit (Quit: Konversation terminated!)
1666 2013-07-03 12:58:26 jeewee has joined
1667 2013-07-03 12:59:40 paraipan has joined
1668 2013-07-03 13:02:03 leakybuckit has quit (Quit: Leaving)
1669 2013-07-03 13:04:45 paraipan has quit (Remote host closed the connection)
1670 2013-07-03 13:04:55 hnz has quit (Ping timeout: 248 seconds)
1671 2013-07-03 13:06:37 paraipan has joined
1672 2013-07-03 13:09:08 hnz has joined
1673 2013-07-03 13:09:42 randy-waterhouse has quit (Ping timeout: 250 seconds)
1674 2013-07-03 13:09:53 agnostic98 has joined
1675 2013-07-03 13:13:52 paraipan has quit (Remote host closed the connection)
1676 2013-07-03 13:14:26 agnostic98 has quit (Ping timeout: 248 seconds)
1677 2013-07-03 13:14:36 paraipan has joined
1678 2013-07-03 13:16:26 setkeh has quit (Ping timeout: 256 seconds)
1679 2013-07-03 13:17:34 graingert has joined
1680 2013-07-03 13:17:56 Grouver has quit (Quit: HydraIRC -> http://www.hydrairc.com <- \o/)
1681 2013-07-03 13:19:01 paraipan has quit (Remote host closed the connection)
1682 2013-07-03 13:22:01 graingert has quit (Client Quit)
1683 2013-07-03 13:22:13 graingert has joined
1684 2013-07-03 13:22:36 graingert is now known as Guest43316
1685 2013-07-03 13:22:38 setkeh has joined
1686 2013-07-03 13:24:20 debiantoruser has quit (Ping timeout: 264 seconds)
1687 2013-07-03 13:25:33 stochasm has quit (Read error: Connection reset by peer)
1688 2013-07-03 13:26:10 debiantoruser has joined
1689 2013-07-03 13:26:37 stochasm has joined
1690 2013-07-03 13:27:49 stochasm has quit (Max SendQ exceeded)
1691 2013-07-03 13:28:38 stochasm has joined
1692 2013-07-03 13:29:07 stochasm has quit (Max SendQ exceeded)
1693 2013-07-03 13:29:37 stochasm has joined
1694 2013-07-03 13:34:35 ThomasV has joined
1695 2013-07-03 13:37:07 wrabbit has quit (Ping timeout: 256 seconds)
1696 2013-07-03 13:39:56 wrabbit has joined
1697 2013-07-03 13:42:00 MobiusL has quit (Remote host closed the connection)
1698 2013-07-03 13:42:04 jeewee has quit (Quit: Leaving.)
1699 2013-07-03 13:43:08 MobiusL has joined
1700 2013-07-03 13:52:10 Guest43316 has quit (Quit: Ex-Chat)
1701 2013-07-03 13:52:17 jeewee has joined
1702 2013-07-03 13:52:33 graingert_ has joined
1703 2013-07-03 13:55:43 execut3 has left ()
1704 2013-07-03 13:55:59 shesek has joined
1705 2013-07-03 13:57:00 <jgarzik> mornin'
1706 2013-07-03 13:57:19 <jgarzik> Morning plug for new toy https://github.com/jgarzik/txtool
1707 2013-07-03 13:59:46 duckybsd has joined
1708 2013-07-03 14:00:04 Gnaf_ has quit (Remote host closed the connection)
1709 2013-07-03 14:02:46 kwikness has joined
1710 2013-07-03 14:08:11 guruvan has quit (Ping timeout: 240 seconds)
1711 2013-07-03 14:10:41 stochasm has quit (Ping timeout: 260 seconds)
1712 2013-07-03 14:10:42 guruvan has joined
1713 2013-07-03 14:13:57 msvb-lab has quit (Quit: msvb-lab)
1714 2013-07-03 14:13:59 gritball has joined
1715 2013-07-03 14:17:04 setkeh has quit (Ping timeout: 256 seconds)
1716 2013-07-03 14:17:29 duckybsd has quit (Remote host closed the connection)
1717 2013-07-03 14:17:52 handle_ is now known as handle]
1718 2013-07-03 14:17:54 handle] is now known as handle
1719 2013-07-03 14:18:44 BW^- has joined
1720 2013-07-03 14:18:56 <BW^-> https://en.bitcoin.it/wiki/Scalability under Storage writes: The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.
1721 2013-07-03 14:19:03 <BW^-> at the same time it says the unspent transactions are 100MB data
1722 2013-07-03 14:19:16 <BW^-> a"dedicated server class machine" today can fit hundreds of gigabytes of RAM.
1723 2013-07-03 14:19:49 <TD> yes? i don't see the issue
1724 2013-07-03 14:19:50 <BW^-> 64GB is common enough, server hosts tend to rent those out
1725 2013-07-03 14:20:01 <TD> that's why it says "it is quite possible the set will always fit in memory"
1726 2013-07-03 14:20:23 <BW^-> wouldn't "very possible" or just "plausible" be a better wording?
1727 2013-07-03 14:20:46 <TD> they would read the same to me. seems like a minor issue anyway - the meaning would be identical
1728 2013-07-03 14:20:58 <BW^-> hm
1729 2013-07-03 14:21:00 <BW^-> aha good point.
1730 2013-07-03 14:22:04 nomailing has joined
1731 2013-07-03 14:22:05 setkeh has joined
1732 2013-07-03 14:25:34 jeewee has quit (Quit: Leaving.)
1733 2013-07-03 14:27:51 reizuki__ has joined
1734 2013-07-03 14:36:32 patcon has joined
1735 2013-07-03 14:36:47 taha has quit (Quit: Leaving)
1736 2013-07-03 14:37:42 <walch> alright. so can /anybody/ help me find the string that controls the "verify message" menu item in Bitcoin-QT?
1737 2013-07-03 14:38:09 jedunnigan has joined
1738 2013-07-03 14:38:49 <walch> it's not in the language pack with all of the rest of them, and beyond that I've really no idea how QT Builder works.
1739 2013-07-03 14:39:50 graingert_ has quit (Ping timeout: 276 seconds)
1740 2013-07-03 14:40:02 taha has joined
1741 2013-07-03 14:41:24 agnostic98 has joined
1742 2013-07-03 14:41:40 paraipan has joined
1743 2013-07-03 14:42:31 nomailing1 has joined
1744 2013-07-03 14:43:37 Ferroh has joined
1745 2013-07-03 14:43:43 nomailing has quit (Ping timeout: 264 seconds)
1746 2013-07-03 14:44:15 paraipan has quit (Remote host closed the connection)
1747 2013-07-03 14:44:23 <BW^-> walch: grep -ri "verify message" * ?
1748 2013-07-03 14:45:04 <walch> BW^-: only, that throws up the original definition in the headers, rather than a string I can modify without breaking everything
1749 2013-07-03 14:45:08 agnostic98 has quit (Read error: Connection reset by peer)
1750 2013-07-03 14:46:02 <walch> I want to capitalise the menus so that they all match, it really shouldn't be this hard.
1751 2013-07-03 14:46:40 <BW^-> walch: so you want to get hold of the corresponding string in the langstrings?
1752 2013-07-03 14:46:43 paraipan has joined
1753 2013-07-03 14:46:53 <walch> yes, but that string doesn't exist in them.
1754 2013-07-03 14:47:03 paraipan has quit (Remote host closed the connection)
1755 2013-07-03 14:47:07 <sipa> walch: talk to wumpus
1756 2013-07-03 14:48:36 <walch> sipa: wumpus usually deals with interface stuff?
1757 2013-07-03 14:48:44 <sipa> walch: he wrote the GUI
1758 2013-07-03 14:49:03 <sipa> (he's laanwj on github)
1759 2013-07-03 14:50:06 <walch> are they ever on IRC?
1760 2013-07-03 14:51:04 <walch> not idling, I mean.
1761 2013-07-03 14:51:55 <sipa> yes
1762 2013-07-03 14:52:25 moses__ has joined
1763 2013-07-03 14:52:35 jeewee has joined
1764 2013-07-03 14:53:02 <walch> alright, thanks sipa.
1765 2013-07-03 14:53:07 RazielZ has quit (Read error: Operation timed out)
1766 2013-07-03 14:54:20 <walch> it's sort of evident why designers don't usually attempt to contribute to open source projects; it's not exactly easy.
1767 2013-07-03 14:55:31 chorao has quit (Read error: Connection reset by peer)
1768 2013-07-03 14:55:51 chorao has joined
1769 2013-07-03 14:55:51 chorao has quit (Changing host)
1770 2013-07-03 14:55:51 chorao has joined
1771 2013-07-03 14:56:39 ousado has quit (Read error: Operation timed out)
1772 2013-07-03 14:59:01 ousado has joined
1773 2013-07-03 14:59:07 <sipa> walch: i carefully stay away from everything GUI :P
1774 2013-07-03 14:59:17 <sipa> it scares me
1775 2013-07-03 14:59:33 <kinlo> you're a big boy, you shouldn't be afraid of a few lines of code :)
1776 2013-07-03 14:59:45 <walch> it's what I work with every day, I really want to improve how the client acts and feels.
1777 2013-07-03 14:59:49 <BW^-> walch: there's no "verify message" in any langstrings file but there is "Verify Message" - perhaps it's displayed with a lower-casing filteR?
1778 2013-07-03 15:00:29 <walch> kinlo: I'm perfectly fine with code, I've just ever used C++ or QT, so you'll have to excuse my confusion
1779 2013-07-03 15:01:09 <kinlo> I was talking to sipa :)
1780 2013-07-03 15:01:24 <kinlo> walch: I assume you meant "never used C++ or QT" ?
1781 2013-07-03 15:01:33 <walch> yes.
1782 2013-07-03 15:01:43 <kinlo> C++ can be a bit confusing
1783 2013-07-03 15:01:55 <kinlo> walch: did much gui coding before?
1784 2013-07-03 15:02:17 <walch> BW^-: filters; is that the ampersand before the text?
1785 2013-07-03 15:02:18 cc_8 has joined
1786 2013-07-03 15:02:59 <walch> kinlo: not generally, no. my deliverables usually have only extended to mockups and assets.
1787 2013-07-03 15:03:14 nomailing1 has quit (Ping timeout: 276 seconds)
1788 2013-07-03 15:03:50 <kinlo> walch: my experience is that programming gui's takes a LOT of time to do not so much in the end
1789 2013-07-03 15:04:25 <handle> really? programming a gui is just making an interface to already existing functions
1790 2013-07-03 15:04:31 <handle> and at that point it's not bad at all
1791 2013-07-03 15:04:46 <kinlo> handle: ever programmed a gui before?
1792 2013-07-03 15:04:46 <handle> if you're making a program around a gui then you might have it tougher
1793 2013-07-03 15:04:51 <handle> kinlo: several times
1794 2013-07-03 15:04:53 roconnor has joined
1795 2013-07-03 15:05:07 <handle> Qt is easy, both with designer and just writing the gui in code
1796 2013-07-03 15:05:20 Thepok has quit (Quit: Nettalk6 - www.ntalk.de)
1797 2013-07-03 15:05:27 <kinlo> currently working on a gui project and it's going slow as hell
1798 2013-07-03 15:05:34 <handle> shitty
1799 2013-07-03 15:05:35 <walch> BW^-: editing the bitcoin_en.ts doesn't seem to do much at all to the compiled app; certainly I can't change the sign/verify strings
1800 2013-07-03 15:05:37 <kinlo> altough I'm doing advanced drag & drop
1801 2013-07-03 15:05:41 <handle> ah, I see
1802 2013-07-03 15:05:45 <handle> yeah, D&D can be complicated
1803 2013-07-03 15:05:58 <handle> have you made many GUIs in the past?
1804 2013-07-03 15:06:20 <kinlo> first time d&d but yes, made more guis then I'd like
1805 2013-07-03 15:06:28 <kinlo> I don't like guis tough, I prefer someone else doing that
1806 2013-07-03 15:06:50 <handle> lol
1807 2013-07-03 15:07:03 <walch> I'll just drop wumpus a private message and see if he'll work through it all with me.
1808 2013-07-03 15:07:08 <BW^-> walch: weird. those strings are not in the sourcecode, so there is some intermediary file you're not reocmpiling
1809 2013-07-03 15:07:08 <handle> most things i make, it would require either a gui or using curses
1810 2013-07-03 15:07:15 <BW^-> walch: yeah makes sense
1811 2013-07-03 15:07:22 <kinlo> I like curses :)
1812 2013-07-03 15:07:33 btsec has joined
1813 2013-07-03 15:07:39 <kinlo> I'm one of those few people left actually using an ncurses mailclient
1814 2013-07-03 15:07:43 <handle> I find curses complicated, but htats because i do more GUI than curses
1815 2013-07-03 15:08:06 <sipa> kinlo: me too :)
1816 2013-07-03 15:08:09 <sipa> (mutt)
1817 2013-07-03 15:08:11 <nsh> heathen
1818 2013-07-03 15:08:12 <nsh> s
1819 2013-07-03 15:08:18 <handle> s/th/v/
1820 2013-07-03 15:08:18 <kinlo> sipa: eh, I don't like mutt
1821 2013-07-03 15:08:22 <kinlo> alpine ftw!
1822 2013-07-03 15:08:22 <handle> pine?
1823 2013-07-03 15:08:26 <handle> close :P
1824 2013-07-03 15:08:27 <sipa> haha
1825 2013-07-03 15:08:31 <walch> BW^-: I've no idea what I'm missing, and watching `make clean && qmake && make` gets tiring after a while
1826 2013-07-03 15:08:41 <handle> make -j999
1827 2013-07-03 15:08:46 <handle> ok maybe not 999
1828 2013-07-03 15:09:02 <handle> but -j<number of cores plus one>
1829 2013-07-03 15:09:07 cc_8 has quit ()
1830 2013-07-03 15:10:18 <walch> still takes an awful long time to compile really
1831 2013-07-03 15:10:25 <Ry4an> mutt++
1832 2013-07-03 15:10:45 <handle> if only GPUs sped up compilation
1833 2013-07-03 15:11:26 graingert has joined
1834 2013-07-03 15:11:26 graingert has quit (Changing host)
1835 2013-07-03 15:11:26 graingert has joined
1836 2013-07-03 15:11:56 ralphtheninja has joined
1837 2013-07-03 15:12:23 agnostic98 has joined
1838 2013-07-03 15:12:32 <walch> sipa: is it more appropriate to email wumpus or DM them?
1839 2013-07-03 15:14:21 Gnaf has joined
1840 2013-07-03 15:14:28 <sipa> walch: you can just hilight him in your pullreq too
1841 2013-07-03 15:15:07 <jgarzik> hrm
1842 2013-07-03 15:15:21 <jgarzik> is there an RPC to obtain current best block hash?
1843 2013-07-03 15:15:25 <jgarzik> if not, there should be.
1844 2013-07-03 15:15:36 <walch> sipa: ah, I closed that until I could work out all the business with the strings
1845 2013-07-03 15:15:43 <jgarzik> certainly best-height is available. but best hash?
1846 2013-07-03 15:15:56 <sipa> jgarzik: gettxoutsetinfo does return it, but it's an incredibly slow RPC :)
1847 2013-07-03 15:16:27 RazielZ has joined
1848 2013-07-03 15:17:16 <michagogo> jgarzik: pipe getblockcount into getblockhash
1849 2013-07-03 15:18:35 <jgarzik> Both effective answers, thanks. They both tell me I should add getbestblockhash
1850 2013-07-03 15:18:40 <jgarzik> ;p
1851 2013-07-03 15:18:54 <michagogo> Well, it's not the best block
1852 2013-07-03 15:19:03 <michagogo> maybe getlatestblockhash
1853 2013-07-03 15:19:11 <michagogo> or just `getblockhashlatest`
1854 2013-07-03 15:19:17 <michagogo> or just `getblockhash latest`, I mean
1855 2013-07-03 15:19:27 agnostic98 has quit (Read error: Connection reset by peer)
1856 2013-07-03 15:19:30 <handle> "getthelatestblockhashfromthebitcoinblockchain"
1857 2013-07-03 15:19:32 <handle> perfect
1858 2013-07-03 15:21:07 <michagogo> "getthehashofthetipofthebestblockchainseenonthebitcoinnetworkpleasethankyougoodbye"
1859 2013-07-03 15:21:59 <jgarzik> it's not the latest block :) the latest block may have been an orphan or on a side chain.
1860 2013-07-03 15:22:12 <sipa> getblockchaintiphash
1861 2013-07-03 15:22:24 <sipa> getbestblockhash
1862 2013-07-03 15:22:25 <michagogo> `getblockhash bestchaintip`, then
1863 2013-07-03 15:22:30 moses__ has quit (Quit: Page closed)
1864 2013-07-03 15:22:30 <michagogo> sipa: Not best block
1865 2013-07-03 15:22:31 <jgarzik> yeah I had just thought getblocktip
1866 2013-07-03 15:22:49 <jgarzik> but the code uses "best", thus getbestblockhash
1867 2013-07-03 15:23:08 <michagogo> jgarzik: It refers to it as the "best block"?
1868 2013-07-03 15:23:36 <jgarzik> michagogo, yes
1869 2013-07-03 15:23:44 <michagogo> o_O
1870 2013-07-03 15:23:49 <jgarzik> xtern int nBestHeight;
1871 2013-07-03 15:23:49 <jgarzik> extern uint256 nBestChainWork;
1872 2013-07-03 15:23:49 <jgarzik> extern uint256 nBestInvalidWork;
1873 2013-07-03 15:23:49 <jgarzik> extern uint256 hashBestChain;
1874 2013-07-03 15:23:49 <jgarzik> extern CBlockIndex* pindexBest;
1875 2013-07-03 15:23:57 <michagogo> Best chain, right
1876 2013-07-03 15:24:02 <michagogo> height of the best chain
1877 2013-07-03 15:24:06 <michagogo> etc
1878 2013-07-03 15:24:16 ralphtheninja has quit (Quit: leaving)
1879 2013-07-03 15:24:26 msvb-lab has joined
1880 2013-07-03 15:25:00 <handle> "getjustthetip"
1881 2013-07-03 15:25:06 <handle> oh, we're done that now :( aw
1882 2013-07-03 15:25:15 dan_ has quit (Remote host closed the connection)
1883 2013-07-03 15:29:19 stochasm has joined
1884 2013-07-03 15:30:24 rdymac has quit (Read error: Connection reset by peer)
1885 2013-07-03 15:31:29 rdymac has joined
1886 2013-07-03 15:32:50 <BW^-> just curious: https://en.bitcoin.it/wiki/Genesis_block : "The first 50BTC block reward went to address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, though this reward can't be spent due to a quirk in the way that the genesis block is expressed in the code (this may have been intentional). "
1887 2013-07-03 15:33:06 <BW^-> https://en.bitcoin.it/wiki/Talk:Genesis_block ] "Can anyone explain more about what the quirk was exactly? " - curiosity is shared. :}
1888 2013-07-03 15:33:08 <BW^-> why is this?
1889 2013-07-03 15:33:44 <sipa> ask satoshi?
1890 2013-07-03 15:34:20 <jgarzik> rofl.
1891 2013-07-03 15:34:57 <BW^-> :)
1892 2013-07-03 15:35:11 <TD> the quirk is that the genesis block is special and isn't inserted into the database
1893 2013-07-03 15:35:20 <jgarzik> I think I will start using "ask satoshi" for any imponderable, annoying, silly or impossible to answer questions posed to me.
1894 2013-07-03 15:35:22 <BW^-> ah i thought this comment here implied that the way the genesis block is represented in its .cpp file somehow makes it unspendable by programmatical reasons
1895 2013-07-03 15:35:24 Lachesis is now known as lachesis
1896 2013-07-03 15:35:24 <TD> i doubt it was "intentional", more like the way the code worked out and hardly worth bothering about.
1897 2013-07-03 15:35:27 <jgarzik> It's like "see figure 1"
1898 2013-07-03 15:35:33 <jgarzik> but for the bitcoin community.
1899 2013-07-03 15:35:55 <BW^-> jgarzik: :)
1900 2013-07-03 15:36:16 <BW^-> yeah, it makes sense - if you'd try to spend it, a database lookup for it would be made, which would fail because it's not there, something like that
1901 2013-07-03 15:37:02 <sipa> BW^-: it is because the the gensis block never went through the normal block connection logic, but was just hardcoded
1902 2013-07-03 15:37:03 Subo1978_ has joined
1903 2013-07-03 15:37:18 <sipa> BW^-: so yes, it's because of how the code is structured - it could easily have been done otherwise
1904 2013-07-03 15:37:31 <sipa> right now, that logic is maintained by a special case for the genesis block
1905 2013-07-03 15:38:27 patcon has quit (Read error: Connection reset by peer)
1906 2013-07-03 15:38:28 patcon_ has joined
1907 2013-07-03 15:38:43 <michagogo> sipa: jgarzik: Could you tell me if there are any flaws with the plan I'm about to describe:
1908 2013-07-03 15:39:09 ShapeShifter499 has joined
1909 2013-07-03 15:39:11 macboz has joined
1910 2013-07-03 15:39:16 <michagogo> I'm trying to solomine a testnet block, as you may know. bfgminer doesn't seem to be aware of the testnet's "reset after 20 minutes" ruke
1911 2013-07-03 15:39:17 <michagogo> rule*
1912 2013-07-03 15:40:11 <michagogo> And for some reason, even with `bfgminer.exe -o http://192.168.56.101:18332 -u user -p password --coinbase-addr mvXQFs7xmJ5PJGrqYYLMnZ31DcaqXVASFA --request-diff 1 -P -s 7 -E 7`, making it getblocktemplate every seven seconds, it doesn't appear to be recognizing the difficulty drop
1913 2013-07-03 15:40:31 Subo1978 has quit (Ping timeout: 240 seconds)
1914 2013-07-03 15:41:08 <michagogo> I'm trying to think of a way to work around it, and I thought about patching bitcoind to always return a target of 0x00000000FFFF0000000000000000000000000000000000000000000000000000
1915 2013-07-03 15:42:06 <michagogo> That way, it'll be mining on difficulty 1, and because I won't touch the block submission logic, until the difficulty drops to 1 the blocks will just get thrown out by bitcoind
1916 2013-07-03 15:42:13 graingert has quit (Quit: Ex-Chat-GNOME)
1917 2013-07-03 15:42:22 <michagogo> Is there anything I'm missing here, any reason that wouldn't work?
1918 2013-07-03 15:42:36 TunneSpec has joined
1919 2013-07-03 15:43:13 <jgarzik> michagogo, bfgminer does not use anything that returns a target, strictly speaking. it does not use 'getwork'.
1920 2013-07-03 15:43:20 <jgarzik> it uses 'getblocktemplate'
1921 2013-07-03 15:43:32 <michagogo> jgarzik: I know
1922 2013-07-03 15:43:51 <michagogo> jgarzik: but the result of getblocktemplate has a target field, no?
1923 2013-07-03 15:44:35 <jgarzik> michagogo, hum, it does. I am surprised :)
1924 2013-07-03 15:44:39 <jgarzik> nevermind then :)
1925 2013-07-03 15:44:44 <michagogo> Does that target field not get used?
1926 2013-07-03 15:44:56 <michagogo> What does bfgminer use to determine difficulty?
1927 2013-07-03 15:50:58 ralphtheninja has joined
1928 2013-07-03 15:51:54 <CodeShark> target_diff
1929 2013-07-03 15:51:57 <CodeShark> ?
1930 2013-07-03 15:53:22 denisx has joined
1931 2013-07-03 15:53:50 Spiralvortex has joined
1932 2013-07-03 15:54:11 <michagogo> Uhhhh.....
1933 2013-07-03 15:54:29 <michagogo> I just typed getblocktemplate into the bitcoin-qt console
1934 2013-07-03 15:54:32 <michagogo> And it crashed
1935 2013-07-03 15:56:09 <michagogo> (mainnet)
1936 2013-07-03 15:57:05 <michagogo> Nothing in debug.log
1937 2013-07-03 15:57:23 <kjj> well, don't do that then
1938 2013-07-03 15:57:33 <michagogo> -_-
1939 2013-07-03 15:57:54 <kjj> is it repeatable?
1940 2013-07-03 15:59:02 t7 has quit (Quit: ChatZilla 0.9.90 [Firefox 22.0/20130618035212])
1941 2013-07-03 15:59:44 <michagogo> I'll test
1942 2013-07-03 16:06:02 Namworld has joined
1943 2013-07-03 16:06:48 rdymac has quit (Read error: Connection reset by peer)
1944 2013-07-03 16:06:54 mE\Ta has joined
1945 2013-07-03 16:06:56 BW^- has quit (Read error: Connection reset by peer)
1946 2013-07-03 16:07:51 macboz has quit (Ping timeout: 256 seconds)
1947 2013-07-03 16:08:38 agnostic98 has joined
1948 2013-07-03 16:08:47 OPrime has quit (Quit: OPrime)
1949 2013-07-03 16:10:29 rdymac has joined
1950 2013-07-03 16:12:21 jeewee has quit (Quit: Leaving.)
1951 2013-07-03 16:12:48 <michagogo> Hmm, https://en.bitcoin.it/wiki/BIP_0022#Transactions_Object_Format doesn't explain all the parameters in getblocktemplate's return
1952 2013-07-03 16:13:09 <michagogo> Erm, https://en.bitcoin.it/wiki/BIP_0022#Block_Template_Request
1953 2013-07-03 16:13:11 <sipa> see BIP23, i guess :)
1954 2013-07-03 16:14:02 Tom_Soft has joined
1955 2013-07-03 16:14:12 topace has quit (Ping timeout: 246 seconds)
1956 2013-07-03 16:14:28 Tom_Soft has quit (Client Quit)
1957 2013-07-03 16:14:42 <michagogo> Ah,
1958 2013-07-03 16:14:55 jedunnigan has quit (Remote host closed the connection)
1959 2013-07-03 16:15:01 Krellan has joined
1960 2013-07-03 16:28:21 graingert has joined
1961 2013-07-03 16:28:21 graingert has quit (Changing host)
1962 2013-07-03 16:28:21 graingert has joined
1963 2013-07-03 16:28:55 handle has quit (Quit: leaving)
1964 2013-07-03 16:29:03 <michagogo> What would changing https://github.com/bitcoin/bitcoin/blob/v0.8.3/src/rpcmining.cpp#L333 to ' result.push_back(Pair("target", "0x00000000FFFF0000000000000000000000000000000000000000000000000000"));' do?
1965 2013-07-03 16:30:44 handle has joined
1966 2013-07-03 16:30:44 handle is now known as hndl
1967 2013-07-03 16:31:29 <michagogo> Hmmmm.....
1968 2013-07-03 16:31:49 hndl is now known as handle
1969 2013-07-03 16:32:22 i2pRelay has quit (Remote host closed the connection)
1970 2013-07-03 16:32:35 <michagogo> Doing that results in a getblocktemplate with that target
1971 2013-07-03 16:32:45 <michagogo> But then, bfgminer says this:
1972 2013-07-03 16:32:47 <michagogo> [2013-07-03 19:03:03] hex2bin sscanf '0x' failed
1973 2013-07-03 16:32:47 <michagogo> [2013-07-03 19:03:03] JSON inval target
1974 2013-07-03 16:32:47 <michagogo> [2013-07-03 19:03:03] Network difficulty changed to 240 ( 1.72Gh/s)
1975 2013-07-03 16:33:30 <michagogo> Oh
1976 2013-07-03 16:34:00 wei_ has joined
1977 2013-07-03 16:34:28 <michagogo> No 0x at the beginning
1978 2013-07-03 16:36:21 <michagogo> Hmm.
1979 2013-07-03 16:36:22 <michagogo> [2013-07-03 19:08:00] Probing for an alive pool
1980 2013-07-03 16:36:22 <michagogo> [2013-07-03 19:08:00] Network difficulty changed to 240 ( 1.72Gh/s)
1981 2013-07-03 16:36:38 <michagogo> And then the top says Connected to 192.168.56.101 diff 1 without LP as user user
1982 2013-07-03 16:36:38 <michagogo> Block: ...a4d62086 # 94343 Diff:240 ( 1.72Gh/s) Started: [19:08:00]
1983 2013-07-03 16:38:13 i2pRelay has joined
1984 2013-07-03 16:40:07 xenland has quit (Quit: Konversation terminated!)
1985 2013-07-03 16:42:10 denisx has quit (Quit: denisx)
1986 2013-07-03 16:45:16 melvster has quit (Remote host closed the connection)
1987 2013-07-03 16:48:57 mE\Ta has quit (Ping timeout: 264 seconds)
1988 2013-07-03 16:49:59 swulf-- has joined
1989 2013-07-03 16:52:21 nizeguy has quit (Remote host closed the connection)
1990 2013-07-03 16:57:04 nizeguy has joined
1991 2013-07-03 16:57:53 <michagogo> Ah, bits
1992 2013-07-03 16:58:05 fishfish has joined
1993 2013-07-03 16:58:20 melvster_ has joined
1994 2013-07-03 17:01:28 <michagogo> ;;genrate 1 13
1995 2013-07-03 17:01:28 mE\Ta has joined
1996 2013-07-03 17:01:29 <gribble> The expected generation output, at 1.0 Mhps, given difficulty of 13.0, is 38.6851166485 BTC per day and 1.61187986036 BTC per hour.
1997 2013-07-03 17:01:33 <michagogo> ;;genrate 13 1
1998 2013-07-03 17:01:34 <gribble> The expected generation output, at 13.0 Mhps, given difficulty of 1.0, is 6537.7847136 BTC per day and 272.4076964 BTC per hour.
1999 2013-07-03 17:01:38 <michagogo> ;;gentime 13 1
2000 2013-07-03 17:01:39 <gribble> The average time to generate a block at 13.0 Mhps, given difficulty of 1.0, is 5 minutes and 30 seconds
2001 2013-07-03 17:04:15 oiram has joined
2002 2013-07-03 17:08:51 dugo_ has left ()
2003 2013-07-03 17:09:38 dugo has joined
2004 2013-07-03 17:13:25 flound1139 has left ()
2005 2013-07-03 17:13:47 flound1129 has joined
2006 2013-07-03 17:13:51 <flound1129> any campbx folks around?
2007 2013-07-03 17:15:07 CodeShark has quit (Remote host closed the connection)
2008 2013-07-03 17:15:26 <warren> flound1129: http://bitcoinity.org/markets/list
2009 2013-07-03 17:15:33 <warren> flound1129: apparently there aren't many...
2010 2013-07-03 17:16:44 <flound1129> their site performance is horrid
2011 2013-07-03 17:16:48 <flound1129> 30 second page to oage
2012 2013-07-03 17:17:11 <flound1129> wondering if they're under dos or just getting slammed with gox refugees.. although with that market share I suspect the former
2013 2013-07-03 17:17:25 <flound1129> or just badly tuned
2014 2013-07-03 17:18:00 <warren> aren't the gox refugees still trapped?
2015 2013-07-03 17:18:10 <warren> flound1129: wrong channel to discuss this anyway
2016 2013-07-03 17:18:28 <flound1129> I converted all my gox cash back to bitcoin and now looking for somewhere to sell it
2017 2013-07-03 17:18:44 <flound1129> can't use bitstamp as my bank apparently doesn't have a swift code
2018 2013-07-03 17:19:29 <warren> flound1129: U.S.? coinbase works well, but still wrong channel to discuss this.
2019 2013-07-03 17:19:45 <flound1129> yeah we're interrupting all the other convo going on..
2020 2013-07-03 17:20:16 <flound1129> :P
2021 2013-07-03 17:23:56 Jere_Jones has joined
2022 2013-07-03 17:23:56 Jere_Jones has quit (Changing host)
2023 2013-07-03 17:23:56 Jere_Jones has joined
2024 2013-07-03 17:26:09 PhantomSpark has joined
2025 2013-07-03 17:28:31 michagogo has quit (Remote host closed the connection)
2026 2013-07-03 17:28:54 michagogo has joined
2027 2013-07-03 17:29:26 Thepok has joined
2028 2013-07-03 17:30:07 dan_ has joined
2029 2013-07-03 17:35:00 conradsteink has joined
2030 2013-07-03 17:35:45 roconnor has quit (Ping timeout: 246 seconds)
2031 2013-07-03 17:43:09 Insti has quit (Ping timeout: 276 seconds)
2032 2013-07-03 17:44:01 Insti has joined
2033 2013-07-03 17:44:41 nizeguy_ has joined
2034 2013-07-03 17:47:34 ericmuys_ has joined
2035 2013-07-03 17:48:14 HANTI is now known as hanti
2036 2013-07-03 17:48:45 PrimeStunna has joined
2037 2013-07-03 17:49:33 ericmuyser has quit (Ping timeout: 260 seconds)
2038 2013-07-03 17:51:23 brson has joined
2039 2013-07-03 17:53:40 omnibrain has quit (Ping timeout: 252 seconds)
2040 2013-07-03 17:54:38 idstam has joined
2041 2013-07-03 17:57:02 Astrohacker has joined
2042 2013-07-03 18:00:20 peetaur2 has joined
2043 2013-07-03 18:02:00 Lekane has quit (Ping timeout: 276 seconds)
2044 2013-07-03 18:02:57 mrkent has joined
2045 2013-07-03 18:04:15 Krellan has quit (Remote host closed the connection)
2046 2013-07-03 18:04:30 dan_ has quit (Remote host closed the connection)
2047 2013-07-03 18:05:18 <michagogo> Hmm... So that bitcoind patch appears to be working, sort of
2048 2013-07-03 18:05:45 <michagogo> I mean, it *is* mining at difficulty 1 and bitcoind is simply throwing out the blocks
2049 2013-07-03 18:07:06 <michagogo> However, I'm still only finding a block every 5-10 mins
2050 2013-07-03 18:07:46 <sipa> what hashrate?
2051 2013-07-03 18:07:52 <michagogo> 10-15 mh/s
2052 2013-07-03 18:07:55 <michagogo> Mh*
2053 2013-07-03 18:08:04 <michagogo> And if finding a block at difficulty 1 doesn't happen to coincide with the fairly narrow window at the 20-minute mark, it still doesn't help
2054 2013-07-03 18:08:13 <sipa> ;;calc 2**32 / (12*10**6)
2055 2013-07-03 18:08:14 <gribble> 357.913941333
2056 2013-07-03 18:08:20 <sipa> ;;calc 2**32 / (10*10**6)
2057 2013-07-03 18:08:21 <gribble> 429.4967296
2058 2013-07-03 18:08:24 <michagogo> ;;gentime 13 1
2059 2013-07-03 18:08:24 <sipa> ;;calc 2**32 / (15*10**6)
2060 2013-07-03 18:08:25 <gribble> The average time to generate a block at 13.0 Mhps, given difficulty of 1.0, is 5 minutes and 30 seconds
2061 2013-07-03 18:08:26 <gribble> 286.331153067
2062 2013-07-03 18:08:32 <sipa> bad luck?
2063 2013-07-03 18:09:03 roconnor has joined
2064 2013-07-03 18:09:18 tonikt has left ("Leaving")
2065 2013-07-03 18:09:21 <michagogo> sipa: The problem is that if finding a block doesn't match up with the <60 second window, it just gets thrown away
2066 2013-07-03 18:09:41 <michagogo> My question is this: is there any way to save this block for submission at the 20 minute mark?
2067 2013-07-03 18:09:53 Lekane has joined
2068 2013-07-03 18:11:44 hanti has left ()
2069 2013-07-03 18:12:51 sensorii has quit (Ping timeout: 240 seconds)
2070 2013-07-03 18:13:10 RedEmerald has quit (Ping timeout: 245 seconds)
2071 2013-07-03 18:14:02 taha has quit (Quit: Leaving)
2072 2013-07-03 18:14:10 dan_ has joined
2073 2013-07-03 18:15:08 fishfish has quit (Quit: Zzzzz..zzzzz)
2074 2013-07-03 18:18:51 RedEmerald has joined
2075 2013-07-03 18:18:54 melvster_ has quit (Ping timeout: 276 seconds)
2076 2013-07-03 18:19:19 BGL has quit (Ping timeout: 256 seconds)
2077 2013-07-03 18:19:28 sensorii has joined
2078 2013-07-03 18:19:55 brocktic1 is now known as brocktice
2079 2013-07-03 18:20:42 PhantomSpark has joined
2080 2013-07-03 18:21:02 PhantomSpark has quit (Read error: Connection reset by peer)
2081 2013-07-03 18:21:35 PhantomSpark has left (2!~kvirc@pool-71-251-16-105.nycmny.fios.verizon.net|)
2082 2013-07-03 18:21:40 wamatt has joined
2083 2013-07-03 18:22:28 <sipa> michagogo: you can't 'save' a block
2084 2013-07-03 18:22:35 <sipa> michagogo: if it isn't valid now, it isn't valid later
2085 2013-07-03 18:22:48 <michagogo> Ah, I see. And why is that?
2086 2013-07-03 18:23:51 <sipa> because the validity rules are time-independent
2087 2013-07-03 18:24:02 <sipa> (except for the fact that the timestamp can't be too much in the future)
2088 2013-07-03 18:24:56 <michagogo> sipa: How is that the case on testnet?
2089 2013-07-03 18:25:37 <michagogo> Shouldn't a block of difficulty 1 be valid once the 20-minute mark is reached?
2090 2013-07-03 18:26:16 <sipa> no
2091 2013-07-03 18:26:17 <sipa> it
2092 2013-07-03 18:26:24 <sipa> it's the block's timestamp that matters, not time
2093 2013-07-03 18:27:19 <michagogo> Ah, I see...
2094 2013-07-03 18:27:43 <michagogo> How far in the future can the timestamp be?
2095 2013-07-03 18:27:51 jeewee has joined
2096 2013-07-03 18:28:55 <sipa> 2 hours, i think
2097 2013-07-03 18:30:36 Transisto has quit ()
2098 2013-07-03 18:30:58 fishfish has joined
2099 2013-07-03 18:30:59 Transisto has joined
2100 2013-07-03 18:32:16 freewil has joined
2101 2013-07-03 18:36:18 <michagogo> sipa: Wait, so I could mine a block with a timestamp 20 minutes into the future and have it be a valid block, even if another block was found 2 minutes ago?
2102 2013-07-03 18:36:25 <sipa> correct
2103 2013-07-03 18:36:33 <michagogo> Huh.
2104 2013-07-03 18:36:50 <michagogo> Would setting the system clock 20 minutes ahead accomplish this?
2105 2013-07-03 18:36:53 fanquake has left ()
2106 2013-07-03 18:36:57 <michagogo> Or would it need another bitcoind patch?
2107 2013-07-03 18:37:02 <michagogo> .j #ubuntu
2108 2013-07-03 18:37:04 <michagogo> erm
2109 2013-07-03 18:37:24 melvster has joined
2110 2013-07-03 18:38:12 RedEmerald has quit (Changing host)
2111 2013-07-03 18:38:12 RedEmerald has joined
2112 2013-07-03 18:41:20 Thepok has quit (Ping timeout: 264 seconds)
2113 2013-07-03 18:42:50 BGL has joined
2114 2013-07-03 18:48:11 Thepok has joined
2115 2013-07-03 18:53:03 dust-otc has joined
2116 2013-07-03 18:55:11 santoscork has joined
2117 2013-07-03 18:55:11 paracyst has joined
2118 2013-07-03 18:56:20 TunneSpec has quit (Ping timeout: 264 seconds)
2119 2013-07-03 18:56:43 nus has joined
2120 2013-07-03 18:57:25 troj has quit (Ping timeout: 240 seconds)
2121 2013-07-03 18:58:04 fishfish has quit (Quit: Zzzzz..zzzzz)
2122 2013-07-03 19:01:33 graingert has quit (Quit: Ex-Chat-GNOME)
2123 2013-07-03 19:01:38 troj has joined
2124 2013-07-03 19:03:49 jeewee has quit (Quit: Leaving.)
2125 2013-07-03 19:10:01 mE\Ta has quit (Ping timeout: 264 seconds)
2126 2013-07-03 19:10:24 <michagogo> ...I'm such an idiot
2127 2013-07-03 19:10:38 <michagogo> It looks like setting the system clock forward 20 minutes does work
2128 2013-07-03 19:11:12 <michagogo> Which means that I had no reason to start messing with code patches at all in the first place
2129 2013-07-03 19:15:58 cads has joined
2130 2013-07-03 19:23:30 fluxbox has joined
2131 2013-07-03 19:28:08 xenland has joined
2132 2013-07-03 19:30:11 cads has quit (Quit: Leaving)
2133 2013-07-03 19:30:14 PiZZaMaN2K is now known as away!~PiZZaMaN2@unaffiliated/pizzaman2k|PiZZaMaN2K
2134 2013-07-03 19:30:33 cads has joined
2135 2013-07-03 19:30:53 Krellan has joined
2136 2013-07-03 19:32:52 imd23 has joined
2137 2013-07-03 19:34:58 fluxbox has quit (Ping timeout: 256 seconds)
2138 2013-07-03 19:35:10 Krellan__ has joined
2139 2013-07-03 19:36:16 Krellan has quit (Ping timeout: 252 seconds)
2140 2013-07-03 19:41:20 McKay has quit (Quit: No Ping reply in 180 seconds.)
2141 2013-07-03 19:43:07 <imd23> guys, what's the best open source project to build on top of (if not already done), to get realtime "tx"s about "Address"
2142 2013-07-03 19:43:54 <imd23> because with bitcoind i can only get tx about address that are on the wallets.
2143 2013-07-03 19:44:00 <imd23> i need to index all, and to be fast.
2144 2013-07-03 19:44:07 <imd23> even with tx that are not confirmed
2145 2013-07-03 19:45:13 daybyter has joined
2146 2013-07-03 19:45:27 agnostic98 has quit (Remote host closed the connection)
2147 2013-07-03 19:46:25 santoscork has quit (Quit: Quiet while I make like a cat)
2148 2013-07-03 19:46:49 fluxbox_ has joined
2149 2013-07-03 19:49:34 McKay has joined
2150 2013-07-03 19:55:53 PiZZaMaN2K is now known as PiZZaMaN2K|away
2151 2013-07-03 19:56:03 dan_ has quit (Remote host closed the connection)
2152 2013-07-03 19:56:30 <sipa> imd23: what do you need that for?
2153 2013-07-03 19:58:36 peetaur2 has quit (Quit: Konversation terminated!)
2154 2013-07-03 20:00:53 peetaur2 has joined
2155 2013-07-03 20:01:00 jMyles has joined
2156 2013-07-03 20:01:53 <imd23> a rails app i am doing
2157 2013-07-03 20:02:24 <imd23> I need to know about each users address the transfers made
2158 2013-07-03 20:02:41 <imd23> so.. it can be said that *we* are the wallet. (our app)
2159 2013-07-03 20:03:06 <imd23> this service can be in c++ , or whatever⦠I need to get a JSON from rails .
2160 2013-07-03 20:04:19 drizztbsd has joined
2161 2013-07-03 20:04:19 drizztbsd has quit (Changing host)
2162 2013-07-03 20:04:19 drizztbsd has joined
2163 2013-07-03 20:05:20 RazielZ has quit (Ping timeout: 264 seconds)
2164 2013-07-03 20:06:25 Thepok has quit (Ping timeout: 256 seconds)
2165 2013-07-03 20:07:33 pecket has joined
2166 2013-07-03 20:11:22 <michagogo> http://test.webbtc.com/tx/8d1080227bf9aef2e10a5c97d1e37e195642a7e5cfb99e42ce783c9b17c5f408
2167 2013-07-03 20:13:36 Thepok has joined
2168 2013-07-03 20:17:34 <imd23> michagogo: yeah, but afaik webbtc does not know about tx instantly
2169 2013-07-03 20:17:51 <michagogo> imd23: What?
2170 2013-07-03 20:17:52 <imd23> they need confirmations/blocks before they are displayed
2171 2013-07-03 20:18:03 <michagogo> imd23: I wasn't suggesting that you use webbtc or anything like that
2172 2013-07-03 20:18:13 <michagogo> That was completely unrelated
2173 2013-07-03 20:18:17 <imd23> oh sorry
2174 2013-07-03 20:18:47 <imd23> it's just that webbtc is one of the best options for what I asked coincidentally
2175 2013-07-03 20:19:54 dan_ has joined
2176 2013-07-03 20:22:43 toffoo has joined
2177 2013-07-03 20:23:52 drizztbsd has quit (Remote host closed the connection)
2178 2013-07-03 20:25:14 dust-otc has quit (Remote host closed the connection)
2179 2013-07-03 20:26:35 drizztbsd has joined
2180 2013-07-03 20:26:35 drizztbsd has quit (Changing host)
2181 2013-07-03 20:26:35 drizztbsd has joined
2182 2013-07-03 20:28:03 peetaur2 has quit (Quit: Konversation terminated!)
2183 2013-07-03 20:28:50 wizkid057 has quit (Read error: Connection reset by peer)
2184 2013-07-03 20:31:43 drizztbsd has quit (Read error: Connection reset by peer)
2185 2013-07-03 20:32:55 blaeks has quit (Ping timeout: 240 seconds)
2186 2013-07-03 20:33:50 wizkid057 has joined
2187 2013-07-03 20:34:18 drizztbsd has joined
2188 2013-07-03 20:34:18 drizztbsd has quit (Changing host)
2189 2013-07-03 20:34:18 drizztbsd has joined
2190 2013-07-03 20:35:09 fishfish has joined
2191 2013-07-03 20:35:36 Diapolis has quit (Remote host closed the connection)
2192 2013-07-03 20:44:12 Jackneill has quit (Remote host closed the connection)
2193 2013-07-03 20:44:19 fluxbox_ has quit (Remote host closed the connection)
2194 2013-07-03 20:44:23 imd23 has quit (Ping timeout: 256 seconds)
2195 2013-07-03 20:46:43 imd23 has joined
2196 2013-07-03 20:46:54 RazielZ has joined
2197 2013-07-03 20:49:02 tg has quit (Quit: leaving)
2198 2013-07-03 20:53:05 daybyter has quit (Quit: Konversation terminated!)
2199 2013-07-03 20:54:39 Pinion has joined
2200 2013-07-03 20:54:46 agnostic98 has joined
2201 2013-07-03 20:54:51 i2pRelay has quit (Ping timeout: 240 seconds)
2202 2013-07-03 20:55:01 agnostic98 has quit (Read error: Connection reset by peer)
2203 2013-07-03 20:55:02 Pinion is now known as Guest42184
2204 2013-07-03 20:55:33 agnostic98 has joined
2205 2013-07-03 20:58:16 Belkaar has quit (Ping timeout: 256 seconds)
2206 2013-07-03 20:58:39 fluxbox_ has joined
2207 2013-07-03 20:58:59 Belkaar has joined
2208 2013-07-03 20:59:46 sensorii has quit (Ping timeout: 240 seconds)
2209 2013-07-03 20:59:46 guruvan has quit (Ping timeout: 240 seconds)
2210 2013-07-03 20:59:46 KillYourTV has quit (Ping timeout: 240 seconds)
2211 2013-07-03 20:59:46 gst has quit (Ping timeout: 240 seconds)
2212 2013-07-03 20:59:46 wiretapped has quit (Ping timeout: 240 seconds)
2213 2013-07-03 20:59:46 handle has quit (Ping timeout: 240 seconds)
2214 2013-07-03 20:59:46 random_cat has quit (Ping timeout: 240 seconds)
2215 2013-07-03 20:59:46 Subo1978_ has quit (Ping timeout: 240 seconds)
2216 2013-07-03 20:59:46 RazielZ has quit (Ping timeout: 264 seconds)
2217 2013-07-03 21:00:42 Drone[02] has joined
2218 2013-07-03 21:05:46 Sliver has quit (Ping timeout: 264 seconds)
2219 2013-07-03 21:05:46 Sliver has joined
2220 2013-07-03 21:05:47 blaeks has joined
2221 2013-07-03 21:07:20 sandbote has joined
2222 2013-07-03 21:09:24 aspect___ has quit (Ping timeout: 252 seconds)
2223 2013-07-03 21:10:07 Sliver^^ has joined
2224 2013-07-03 21:11:01 saivann__ has quit (Ping timeout: 246 seconds)
2225 2013-07-03 21:14:07 setkeh has quit (Ping timeout: 264 seconds)
2226 2013-07-03 21:14:36 cads has quit (Max SendQ exceeded)
2227 2013-07-03 21:15:53 setkeh has joined
2228 2013-07-03 21:15:53 cads has joined
2229 2013-07-03 21:16:21 saivann has joined
2230 2013-07-03 21:18:43 Transisto has quit (Ping timeout: 248 seconds)
2231 2013-07-03 21:19:19 Transisto has joined
2232 2013-07-03 21:21:38 guruvan has joined
2233 2013-07-03 21:21:45 wiretapped has joined
2234 2013-07-03 21:21:48 gst has joined
2235 2013-07-03 21:22:59 Subo1978 has joined
2236 2013-07-03 21:23:00 dan_ has quit (Remote host closed the connection)
2237 2013-07-03 21:24:06 KillYourTV has joined
2238 2013-07-03 21:24:38 sensorii has joined
2239 2013-07-03 21:27:50 be3f has joined
2240 2013-07-03 21:28:39 sandbote has quit (Remote host closed the connection)
2241 2013-07-03 21:30:13 ThomasV_ has joined
2242 2013-07-03 21:30:40 ralphtheninja has quit (Quit: leaving)
2243 2013-07-03 21:32:52 drizzt_ has joined
2244 2013-07-03 21:32:59 nizeguy_ has quit (Read error: Connection reset by peer)
2245 2013-07-03 21:33:14 Hunner has quit (Read error: Connection reset by peer)
2246 2013-07-03 21:33:16 realazthat has quit (Ping timeout: 240 seconds)
2247 2013-07-03 21:33:21 Hunner has joined
2248 2013-07-03 21:33:21 Hunner has quit (Changing host)
2249 2013-07-03 21:33:21 Hunner has joined
2250 2013-07-03 21:33:57 sacredchao has joined
2251 2013-07-03 21:34:01 realazthat has joined
2252 2013-07-03 21:34:07 wiretapped has quit (Remote host closed the connection)
2253 2013-07-03 21:34:45 Guest83631 has quit (Ping timeout: 256 seconds)
2254 2013-07-03 21:34:50 drizztbsd has quit (Ping timeout: 256 seconds)
2255 2013-07-03 21:35:34 a_meteorite has joined
2256 2013-07-03 21:35:45 a_meteorite has quit (Changing host)
2257 2013-07-03 21:35:45 a_meteorite has joined
2258 2013-07-03 21:35:45 wiretapped has joined
2259 2013-07-03 21:37:20 paraipan has joined
2260 2013-07-03 21:37:32 fluxbox_ has quit (Read error: Connection reset by peer)
2261 2013-07-03 21:37:55 handle has joined
2262 2013-07-03 21:38:27 omnibrain has joined
2263 2013-07-03 21:41:26 Namworld has quit ()
2264 2013-07-03 21:41:32 jaekwon has left ()
2265 2013-07-03 21:41:41 jaekwon has joined
2266 2013-07-03 21:44:20 rdponticelli has joined
2267 2013-07-03 21:44:30 Mobius_ has joined
2268 2013-07-03 21:44:41 random_cat has joined
2269 2013-07-03 21:44:52 Mobius_ is now known as MobiusL
2270 2013-07-03 21:52:11 kwikness has quit (Quit: Leaving.)
2271 2013-07-03 21:52:54 Scrat is now known as OTCTipBot
2272 2013-07-03 21:53:04 OTCTipBot is now known as Scrat
2273 2013-07-03 21:53:39 davout has joined
2274 2013-07-03 21:53:39 davout has quit (Changing host)
2275 2013-07-03 21:53:39 davout has joined
2276 2013-07-03 21:54:32 ahbritto has quit (Ping timeout: 252 seconds)
2277 2013-07-03 21:54:43 IanCormac has joined
2278 2013-07-03 21:54:44 ThomasV_ has quit (Quit: Quitte)
2279 2013-07-03 21:54:47 owowo has joined
2280 2013-07-03 21:56:42 imd23 has quit (Quit: imd23)
2281 2013-07-03 21:58:31 random_cat has quit (Ping timeout: 240 seconds)
2282 2013-07-03 21:59:14 imd23 has joined
2283 2013-07-03 21:59:40 random_cat has joined
2284 2013-07-03 22:00:21 Muis_ is now known as Muis
2285 2013-07-03 22:02:21 <jaekwon> is anybody familiar with bitcoin address relay? i'm trying to understand "When they meet the above criteria, the node hashes all the eligible node IP addresses, as well as the current day in the form of an integer, and the two nodes with the lowest hash value are chosen to have the address relayed to them.
2286 2013-07-03 22:02:22 <jaekwon> "
2287 2013-07-03 22:03:13 <IanCormac> OK, so what that is doing is randomly choosing which IPs to send the address to
2288 2013-07-03 22:03:43 <IanCormac> So every day, the hash(IP || date) is a different pseudorandom value
2289 2013-07-03 22:03:48 <jaekwon> does that mean, in general, those self originated "addr" messages get forwarded with a branch factor of 2, and they tend to forward my IP to a particular direction?
2290 2013-07-03 22:04:24 <jaekwon> i don't understand why it's being forwarded to the lowest hash value. what good does that do?
2291 2013-07-03 22:04:30 <IanCormac> Randomness
2292 2013-07-03 22:04:32 <IanCormac> It's just random
2293 2013-07-03 22:04:40 <IanCormac> I would imagine, at least
2294 2013-07-03 22:04:44 <IanCormac> I actually don't know the context for this
2295 2013-07-03 22:05:25 <jaekwon> yes, but considering a collection of nodes, there would tend to be more collisions since everybody is using the same algo.
2296 2013-07-03 22:05:41 <IanCormac> Let me look this up
2297 2013-07-03 22:05:56 nus has quit (Ping timeout: 240 seconds)
2298 2013-07-03 22:05:56 <jaekwon> but maybe that's the point⦠to limit the amount of propagation. that would be kinda brilliant.
2299 2013-07-03 22:06:02 <jaekwon> thanks Ian!
2300 2013-07-03 22:06:05 <IanCormac> np
2301 2013-07-03 22:07:20 ahbritto has joined
2302 2013-07-03 22:09:13 <IanCormac> That is a good question though. Certain IP addresses would be get much more addr messages on certain days
2303 2013-07-03 22:09:26 Thepok has quit (Ping timeout: 246 seconds)
2304 2013-07-03 22:09:47 <IanCormac> There might be something I'm missing here
2305 2013-07-03 22:11:41 Skav has joined
2306 2013-07-03 22:11:51 MobPhone has quit (Read error: Connection reset by peer)
2307 2013-07-03 22:19:02 <jaekwon> i guess i should look at the commit history and find someone or mail some mailing list.
2308 2013-07-03 22:19:45 patcon_ has quit (Remote host closed the connection)
2309 2013-07-03 22:20:12 patcon has joined
2310 2013-07-03 22:22:32 <sipa> jaekwon: there is a per-node salt that is hashed together
2311 2013-07-03 22:22:48 <sipa> so "the two lowest hashes" is really pseudo-random
2312 2013-07-03 22:22:59 <sipa> and it doesn't cause more collisions than any other random
2313 2013-07-03 22:23:58 <jaekwon> oh ok. so my self "addr" gets propagated with a branch factor of 1 or 2, and goes on for roughly an hour
2314 2013-07-03 22:24:23 <jaekwon> does it get grouped with other "addr"s? maybe up to 10?
2315 2013-07-03 22:24:24 <sipa> your own addr is broadcasted differently, afaik
2316 2013-07-03 22:24:39 <sipa> this algorithm is about relaying addresses you receive yourself
2317 2013-07-03 22:24:49 <gmaxwell> yea, your own addr is just directly broadcasted every 24 hours or something like that, IIRC.
2318 2013-07-03 22:25:07 <jaekwon> yeah. thanks for the clarification
2319 2013-07-03 22:25:15 patcon has quit (Ping timeout: 276 seconds)
2320 2013-07-03 22:27:09 Skav has quit (Quit: -a- Android IRC 2.1.8 Just need to be Chiznillen)
2321 2013-07-03 22:27:51 wamatt has quit (Ping timeout: 276 seconds)
2322 2013-07-03 22:28:37 bloke has joined
2323 2013-07-03 22:30:07 patcon has joined
2324 2013-07-03 22:30:16 FabianB_ has joined
2325 2013-07-03 22:30:30 wamatt has joined
2326 2013-07-03 22:30:56 FabianB has quit (Ping timeout: 240 seconds)
2327 2013-07-03 22:33:25 dan_ has joined
2328 2013-07-03 22:33:47 Thepok has joined
2329 2013-07-03 22:35:03 shesek has quit (Ping timeout: 248 seconds)
2330 2013-07-03 22:35:14 nizeguy has quit (Remote host closed the connection)
2331 2013-07-03 22:35:34 idstam has quit (Read error: Connection reset by peer)
2332 2013-07-03 22:36:00 idstam has joined
2333 2013-07-03 22:37:50 mint has joined
2334 2013-07-03 22:37:52 MobiusL has quit (Remote host closed the connection)
2335 2013-07-03 22:38:11 dan_ has quit (Ping timeout: 248 seconds)
2336 2013-07-03 22:38:18 phpwn has joined
2337 2013-07-03 22:38:51 MobiusL has joined
2338 2013-07-03 22:44:07 Astrohacker has quit (Ping timeout: 246 seconds)
2339 2013-07-03 22:44:48 gritball has quit (Remote host closed the connection)
2340 2013-07-03 22:45:36 gritball has joined
2341 2013-07-03 22:47:09 shesek has joined
2342 2013-07-03 22:48:44 atweiden has joined
2343 2013-07-03 22:50:23 wizkid057 has quit (Ping timeout: 246 seconds)
2344 2013-07-03 22:50:50 wizkid057 has joined
2345 2013-07-03 22:52:03 <IanCormac> Ah, the salt thing makes much more sense. I'm going to edit the wiki to reflect that
2346 2013-07-03 22:52:54 <sipa> please do; it's a 256-bit salt, randomly generated at startup
2347 2013-07-03 22:53:03 ToryJujube has joined
2348 2013-07-03 22:53:33 <IanCormac> Randomly generated for every node, or just one single salt that's used every time the hash is calculated?
2349 2013-07-03 22:53:48 <sipa> there's just one salt
2350 2013-07-03 22:53:52 <IanCormac> OK
2351 2013-07-03 22:54:20 paraipan has quit (Quit: Saliendo)
2352 2013-07-03 22:55:30 <IanCormac> Hmm. Don't seem to have edit privileges. Just registered
2353 2013-07-03 22:55:50 <sipa> oh, there's a 0.01 BTC fee to get edit permission i think
2354 2013-07-03 22:56:00 Astrohacker has joined
2355 2013-07-03 22:56:03 <sipa> there was a ton of spam before
2356 2013-07-03 22:56:13 <IanCormac> Oh. Where do I pay that?
2357 2013-07-03 22:56:47 CodeName has joined
2358 2013-07-03 22:56:49 <sipa> click log out; log in
2359 2013-07-03 22:56:50 <gmaxwell> IanCormac: instructions are on the login screen.
2360 2013-07-03 22:56:55 <sipa> there's a link there
2361 2013-07-03 22:56:56 <IanCormac> Thanks
2362 2013-07-03 22:57:37 <sipa> https://en.bitcoin.it/wiki/Special:BitcoinPayment
2363 2013-07-03 22:58:43 <IanCormac> Guess I'll wait for that to confirm
2364 2013-07-03 22:58:53 <sipa> i think they wait for 6 confirms
2365 2013-07-03 23:00:29 davout has quit (Remote host closed the connection)
2366 2013-07-03 23:00:59 <michagogo> Indeed it does.
2367 2013-07-03 23:01:18 <michagogo> (BTW, I made a couple edits to remove or past-tense references to IRC)
2368 2013-07-03 23:01:32 <michagogo> (past-tense is a verb in that sentence)
2369 2013-07-03 23:02:27 <IanCormac> English is very flexible with nouns, adjectives, and verbs
2370 2013-07-03 23:02:31 <IanCormac> I like that
2371 2013-07-03 23:02:41 PrimeStunna has quit (Quit: PrimeStunna)
2372 2013-07-03 23:04:54 CodeName has quit (Ping timeout: 276 seconds)
2373 2013-07-03 23:05:55 brson has quit (Ping timeout: 248 seconds)
2374 2013-07-03 23:06:33 brson has joined
2375 2013-07-03 23:07:07 <sipa> IanCormac: some will disagree with you :D
2376 2013-07-03 23:07:15 <sipa> (i'm not native english, i don't care)
2377 2013-07-03 23:07:43 <IanCormac> I bet haha
2378 2013-07-03 23:08:00 <sipa> i hear there's people that particularly hate it when nouns are turned into verbs
2379 2013-07-03 23:08:12 <handle> sipa: i'll have to google that
2380 2013-07-03 23:08:27 <sipa> search for "to verb" :p
2381 2013-07-03 23:08:35 patcon has quit (Ping timeout: 245 seconds)
2382 2013-07-03 23:08:38 <handle> haha
2383 2013-07-03 23:08:41 <IanCormac> sipa: There was a big debate a few decades ago about using "impact" as a verb
2384 2013-07-03 23:09:16 <sipa> http://en.wikipedia.org/wiki/Conversion_(word_formation)#Verbification
2385 2013-07-03 23:10:42 <jaekwon> did it impact anything?
2386 2013-07-03 23:10:52 <handle> verbification
2387 2013-07-03 23:10:53 <handle> awesome wor
2388 2013-07-03 23:10:54 <handle> d
2389 2013-07-03 23:10:58 brson has quit (Client Quit)
2390 2013-07-03 23:11:02 saivann has quit (Ping timeout: 246 seconds)
2391 2013-07-03 23:11:12 brson has joined
2392 2013-07-03 23:11:13 <sipa> i prefer 'to verb', as it's pretty much a QED on itself :P
2393 2013-07-03 23:11:33 <jaekwon> stop verbing.
2394 2013-07-03 23:12:08 bloke has left ()
2395 2013-07-03 23:12:18 <sipa> sometimes a noun is verbified even when a verb with that meaning already exists (to friend vs to befriend)
2396 2013-07-03 23:13:10 <jaekwon> what about the other way around?
2397 2013-07-03 23:13:23 <jaekwon> a lot of verbs are nouns already
2398 2013-07-03 23:14:10 <IanCormac> I sure do like going on facebook and giving a like to people who are verbing
2399 2013-07-03 23:14:26 <sipa> http://www.youtube.com/watch?v=J7E-aoXLZGY
2400 2013-07-03 23:14:35 <IanCormac> Or nouning, I guess
2401 2013-07-03 23:14:35 <sipa> that's one verbing too far!
2402 2013-07-03 23:15:18 eqwl has joined
2403 2013-07-03 23:15:27 gritball has quit (Remote host closed the connection)
2404 2013-07-03 23:16:10 <jaekwon> oh, you like "likes" eh?
2405 2013-07-03 23:16:18 <jaekwon> there's a nouned verb for you.
2406 2013-07-03 23:16:26 <handle> i like, like the like, likes... like yeah
2407 2013-07-03 23:16:39 <handle> and like, stuff
2408 2013-07-03 23:17:43 PrimeStunna has joined
2409 2013-07-03 23:21:52 eqwl has quit ()
2410 2013-07-03 23:22:59 Pucilowski_ has left ()
2411 2013-07-03 23:23:01 Pucilowski_ has joined
2412 2013-07-03 23:23:24 Pucilowski_ has left ()
2413 2013-07-03 23:23:38 Pucilowski has joined
2414 2013-07-03 23:24:38 Spiralvortex has quit (Read error: Connection reset by peer)
2415 2013-07-03 23:25:59 Spiralvortex has joined
2416 2013-07-03 23:27:00 Astrohacker has quit (Quit: Leaving)
2417 2013-07-03 23:27:46 ralphtheninja has joined
2418 2013-07-03 23:28:48 agnostic98 has quit (Read error: Connection reset by peer)
2419 2013-07-03 23:29:02 agnostic98 has joined
2420 2013-07-03 23:30:03 i2pRelay has joined
2421 2013-07-03 23:30:04 ToryJujube has quit (Remote host closed the connection)
2422 2013-07-03 23:30:04 one_zero has joined
2423 2013-07-03 23:30:14 wei_ has quit (Quit: wei_)
2424 2013-07-03 23:32:39 adam3us has quit (Ping timeout: 248 seconds)
2425 2013-07-03 23:33:01 IanCormac has quit (Quit: IanCormac)
2426 2013-07-03 23:34:19 jgarzik has quit (Quit: package updates)
2427 2013-07-03 23:35:55 chorao has quit ()
2428 2013-07-03 23:37:30 mrkent has quit (Quit: Leaving)
2429 2013-07-03 23:37:59 viperhr has quit (Ping timeout: 248 seconds)
2430 2013-07-03 23:41:24 graingert has joined
2431 2013-07-03 23:41:24 graingert has quit (Changing host)
2432 2013-07-03 23:41:24 graingert has joined
2433 2013-07-03 23:42:55 egis has quit (Quit: Leaving)
2434 2013-07-03 23:43:04 roconnor has quit (Remote host closed the connection)
2435 2013-07-03 23:44:29 jgarzik has joined
2436 2013-07-03 23:46:27 super3 has joined
2437 2013-07-03 23:51:42 Thepok has quit (Ping timeout: 276 seconds)
2438 2013-07-03 23:54:00 <super3> hey
2439 2013-07-03 23:55:00 <jaekwon> what
2440 2013-07-03 23:58:41 macboz has joined
2441 2013-07-03 23:59:12 drizzt_ has quit (Quit: Konversation terminated!)