1 2013-07-07 00:00:19 <michagogo> RPC createrawtransaction shouldn't allow it, then
2 2013-07-07 00:00:30 <michagogo> (if you pass {}, you get a result)
3 2013-07-07 00:00:41 <sipa> michagogo: invalid means invalid
4 2013-07-07 00:00:47 <petertodd> michagogo: nah, that's useful because you can edit the transaction later
5 2013-07-07 00:00:51 <michagogo> Ah
6 2013-07-07 00:01:03 <petertodd> michagogo: createrawtransactions lets you make invalid transactions in a *lot* of ways
7 2013-07-07 00:01:12 <sipa> in a block, it would make the block invalid
8 2013-07-07 00:01:50 <petertodd> michagogo: of course, it is unfortunate that zero output transactions are illegal, there's no good reason for that
9 2013-07-07 00:02:07 <michagogo> Erm.
10 2013-07-07 00:02:19 <michagogo> Okay, I get that you can edit the transaction later
11 2013-07-07 00:02:34 <petertodd> michagogo: The inputs should go 100% to fees with no outputs.
12 2013-07-07 00:02:41 <michagogo> But this shouldn't happen:
13 2013-07-07 00:02:41 <michagogo> "complete" : true}
14 2013-07-07 00:02:41 <michagogo> {"hex" : 01000000017ac4778dc6b5731f9f3da3966611ce7e9ddfb9d0d25674fa760c626d7a9b05f6000000006b483045022100a31ec768ee5036469fd313be209fbe0cbd3b37ff4fcd7b9db0065f9a1915b62702201e6562bee8ef1c4ceff0d4a8f4041cab9c6475dd4bfed4df8526cb3c02d1199701210235206363327e9b66cba001fc3ddcf9115b7d03df4167d139ff8c9d98864868fdffffffff0000000000",
15 2013-07-07 00:03:21 <petertodd> why not?
16 2013-07-07 00:03:32 <petertodd> You know, you can combine transactions too
17 2013-07-07 00:03:42 <sipa> complete means all inputs are signed
18 2013-07-07 00:04:09 <petertodd> If you set SIGHASH_NONE you can use that signed incomplete transaction to add inputs to another one.
19 2013-07-07 02:53:56 <The_Fly> http://developers.slashdot.org/story/13/07/07/017249/modeling-how-programmers-read-code
20 2013-07-07 05:15:03 <warren> Annoyingly, share/setup.nsi has DOS endlines ...
21 2013-07-07 05:15:27 <petertodd> What's share/setup.nsi for?
22 2013-07-07 05:16:23 <warren> petertodd: gitian-win32.yml generates the win32 installer
23 2013-07-07 05:16:40 <petertodd> Ah, figures
24 2013-07-07 05:17:04 <walch> warren: ah hah! I was wondering what /share/pixmaps/nsis-wizard.bmp was used for.
25 2013-07-07 05:18:16 <Luke-Jr> "a Windows-only file has DOS end lines"??? problem?
26 2013-07-07 05:19:25 <warren> Luke-Jr: that file and gitian-win32.yml exists because the linux developers don't want to develop or build on windows? =)
27 2013-07-07 05:19:52 <Luke-Jr> warren: you'd use setup.nsi to build on Windows too
28 2013-07-07 05:20:11 <Luke-Jr> warren: also, until recently, there were zero Windows developers after Satoshi left
29 2013-07-07 05:20:14 <Luke-Jr> now there's 1
30 2013-07-07 05:20:26 <warren> oh, who's the 1?
31 2013-07-07 05:29:09 <Luke-Jr> warren: Diapolo
32 2013-07-07 05:29:46 <warren> ah
33 2013-07-07 05:45:06 <coolty> hi anyone have testnet bitcoins?
34 2013-07-07 05:45:19 <coolty> please send some here: mr7DCHJKesThkFahYbCXwAZt859APTr5kD
35 2013-07-07 05:46:40 <darsie> what's the testnet difficulty?
36 2013-07-07 05:47:50 <coolty> dunno i think 0
37 2013-07-07 05:48:09 <darsie> no one is mining?
38 2013-07-07 05:48:33 <darsie> How does testnet work when no one makes blocks?
39 2013-07-07 05:49:02 <darsie> Are testers expected to mine when they make test tx?
40 2013-07-07 05:54:14 <gmaxwell> darsie: why are you saying no one is mining?!
41 2013-07-07 05:54:37 <darsie> cause [09:44:04] <coolty> dunno i think 0
42 2013-07-07 05:54:45 <darsie> difficulty
43 2013-07-07 05:54:49 <gmaxwell> coolty is giving a clueless response there.
44 2013-07-07 05:54:57 <darsie> k
45 2013-07-07 05:55:15 <gmaxwell> The difficulty cannot be zero. (on testnet or otherwise)
46 2013-07-07 05:55:38 <darsie> no? What's the lowes theoretical difficulty?
47 2013-07-07 05:55:51 <gmaxwell> 1
48 2013-07-07 05:55:57 <darsie> k
49 2013-07-07 05:56:11 <gmaxwell> Last I looked testnet was at 200 or so, but testnet rules are special.
50 2013-07-07 05:56:28 <gmaxwell> in that after 20min without a block it permits a diff 1 block.
51 2013-07-07 05:57:13 <petertodd> gmaxwell: doesn't that tend to drive up difficulty on testnet?
52 2013-07-07 05:59:27 <gmaxwell> doesn't matter at all.
53 2013-07-07 05:59:38 <michagogo> (also note that you can adjust your system cloak 20 minutes forward to mine at difficulty 1)
54 2013-07-07 05:59:45 <gmaxwell> kinda.
55 2013-07-07 05:59:56 <gmaxwell> michagogo: no one will accept blocks once you've entered the future.
56 2013-07-07 06:00:26 <petertodd> gmaxwell: I mean that for a given amount of hashing power, the fact that 20 minute periods get "filled" with diff 1 blocks pushes difficulty up compared to mainnet (which yes, does balance out)
57 2013-07-07 06:00:42 <michagogo> gmaxwell: Only once you're 2 hours ahead
58 2013-07-07 06:00:46 <gmaxwell> petertodd: 20 minutes is greater than the target, so diff goes down even if all the blocks are 20min blocks.
59 2013-07-07 06:00:57 <gmaxwell> michagogo: sure, which takes only 3 blocks.
60 2013-07-07 06:01:02 <michagogo> 6*
61 2013-07-07 06:01:21 <petertodd> gmaxwell: I guess I'm just pointing out that difficulty will be higher on testnet than mainnet for a given amount of mining activity.
62 2013-07-07 06:01:29 <petertodd> s/ativity/hashing power/
63 2013-07-07 06:01:54 <gmaxwell> petertodd: it wont anyways it will be a random number considering that the same rule also causes it to go back to 1 and get stuck there.
64 2013-07-07 06:02:19 <petertodd> gmaxwell: true, on the 2016 boundry
65 2013-07-07 06:02:20 <michagogo> gmaxwell: 6, no? Also, once not-you mines a block, it (likely) will have the right timestamp, and you can move your clock back to 20 minutes ahead of real time
66 2013-07-07 06:02:57 <gmaxwell> michagogo: right 5 or 6. I'm typing in the dark while laying down.
67 2013-07-07 06:03:02 <michagogo> :)
68 2013-07-07 06:25:47 <michagogo> Is there a way to `./bitcoind getnewaddress namehere` without all the addresses showing up in bitcoin-qt's Receive tab?
69 2013-07-07 06:28:47 <Someguy123> michagogo, not really
70 2013-07-07 06:28:56 <michagogo> I see.
71 2013-07-07 06:29:15 <Someguy123> it's usually a good idea to not use bitcoin-qt for any daemon sort-of activities
72 2013-07-07 06:29:21 <Someguy123> or your recieve tab just gets flooded.
73 2013-07-07 06:29:52 <michagogo> Someguy123: Yeah, I'm testing something
74 2013-07-07 06:30:06 <michagogo> And I'm drawing a couple hundred addresses :-/
75 2013-07-07 06:30:49 <Someguy123> michagogo, you can try to set them all under the same label/account
76 2013-07-07 06:30:54 <coolty> t
77 2013-07-07 06:30:54 <michagogo> I am
78 2013-07-07 06:31:22 <Someguy123> setaccount <bitcoinaddress> <account>
79 2013-07-07 06:31:44 <michagogo> Basically, I have a bit of ruby code looping `bitcoind -testnet -rpcuser=foo -rpcpassword=bar getnewaddress "baz"`
80 2013-07-07 06:32:07 <michagogo> And it seems to be creating a new row in the Receive tab for each one
81 2013-07-07 06:32:54 <michagogo> Someguy123: Aha, that made it vanish
82 2013-07-07 06:33:29 <michagogo> After this finishes I'll feed that into setaccount
83 2013-07-07 06:33:32 <michagogo> Thanks!
84 2013-07-07 06:45:16 <darsie> Is blockchain syncing done sequentially or does it download blocks simultaneously from each peer?
85 2013-07-07 06:45:41 <michagogo> darsie: It's sequential
86 2013-07-07 06:46:04 <darsie> make it parallel
87 2013-07-07 06:46:17 <michagogo> Which really sucks if you happen to be pulling from a slow peer
88 2013-07-07 06:46:31 <darsie> I have 8 connections.
89 2013-07-07 06:46:45 <michagogo> darsie: The problem is that you need to get the blocks before you know which blocks to get next
90 2013-07-07 06:47:01 <michagogo> darsie: If you're syncing a new client on mainnet, consider using bootstrap.dat: https://bitcointalk.org/index.php?topic=145386.0;all
91 2013-07-07 06:47:31 <michagogo> Download the file from the bittorrent swarm, and drop it in datadir -- the client will import from it
92 2013-07-07 06:47:32 <darsie> I know I have block 1-x so I want the next 8 blocks.
93 2013-07-07 06:47:49 <michagogo> darsie: Right, but you don't ask for blocks by number
94 2013-07-07 06:47:50 <darsie> My mainnet is synced. Syncing testnet atm.
95 2013-07-07 06:47:54 <michagogo> You ask for them by hash
96 2013-07-07 06:47:58 <michagogo> Ah, I see.
97 2013-07-07 06:47:59 <darsie> hmm
98 2013-07-07 06:48:21 <darsie> So, ask for them by number?
99 2013-07-07 06:48:33 <darsie> Or d/l the hashes.
100 2013-07-07 06:49:15 <michagogo> darsie: The problem would be that you wouldn't know there was a problem until you got all the blocks
101 2013-07-07 06:49:42 <michagogo> darsie: People *have* been talking about headers-first sync. I don't know if it's being actively worked on, code-wise.
102 2013-07-07 06:49:58 <darsie> Seeing a problem after downloading them is fine, I guess.
103 2013-07-07 06:51:04 <darsie> I mean, blocks wolud be downloaded semisequential. The oldest outstanding blocks first. 8 downloads concurrently.
104 2013-07-07 06:51:51 <michagogo> darsie: Not if you download a 200k long chain only to notice at the end that you're missing one in the middle and you've DL'd tens of thousands of orphan blocks
105 2013-07-07 06:56:21 <michagogo> I wonder if anyone's made a bootstrap.dat for testnet
106 2013-07-07 06:56:43 <darsie> You can request the next sequence of hashes after a given block from each peer and if there's a discrepancy ... well, you gotta decide which branch you follow. You could end up with orphaned blocks if you dl them from a peer on a orphan branch, too.
107 2013-07-07 06:58:11 <michagogo> darsie: I'm pretty sure there was a reason that doesn't work, but I don't remember off the top of my head. Maybe someone else knows.
108 2013-07-07 06:59:35 <gmaxwell> it's mildly tricky to write the software for (esp in a dos attack resistant manner), and until somewhat recently it wasn't a performance limiting factor.
109 2013-07-07 06:59:38 <gmaxwell> thats all.
110 2013-07-07 07:00:21 <gmaxwell> (and before you contradict me and insist that its easy, I'll say in advance: I look forward to reviewing your patch.)
111 2013-07-07 07:00:48 <darsie> k
112 2013-07-07 07:01:48 <gmaxwell> (The thing to do is sync the headers ahead??? so you now that the blocks your fetching are at least for the longest possibly valid chain; this also tells you what blocks you need and removes a bunch of possible DOS vectors.)
113 2013-07-07 07:02:25 <michagogo> [11:56:36] <gmaxwell> (and before you contradict me and insist that its easy, I'll say in advance: I look forward to reviewing your patch.)
114 2013-07-07 07:02:25 <michagogo> :-P
115 2013-07-07 07:02:52 <michagogo> gmaxwell: I've heard talk of headers-only syncing, was this something being actively developed/worked on?
116 2013-07-07 07:03:25 <michagogo> (also, I assume it could be implemented in addition to regular syncing, so without any kind of fork or anything, right?)
117 2013-07-07 07:03:42 <gmaxwell> Headers _first_ only makes no sense, if you're not making an error there that I don't know what you're talking about.
118 2013-07-07 07:05:06 <michagogo> gmaxwell: I meant headers-first, ofc
119 2013-07-07 07:05:58 <gmaxwell> so varrious other changes have moved things more in the direction of it being possible, but I don't believe that anyone is working specifically on it at the moment.
120 2013-07-07 07:09:49 <darsie> I'm stuck at testnet block 80991. Will it timeout and try from a different peer? I thought of restarting anyways to connect to a faster peer.
121 2013-07-07 07:11:12 <michagogo> darsie: If you can somehow reset the network connection that might work
122 2013-07-07 07:12:19 <darsie> restarted. Going much faster now. :)
123 2013-07-07 07:15:32 <michagogo> darsie: Are you IRCing from the same machine as you're running bitcoin on?
124 2013-07-07 07:20:10 <darsie> michagogo: yes
125 2013-07-07 07:20:12 <darsie> why?
126 2013-07-07 07:20:54 <michagogo> Ah, so you just aren't accepting incoming connections
127 2013-07-07 07:21:12 <michagogo> (addnode your-address onetry didn't work)
128 2013-07-07 07:21:13 <darsie> Hmm, I'm behind NAT.
129 2013-07-07 07:21:39 <michagogo> Yeah, that could do it
130 2013-07-07 07:23:20 <darsie> I could allow incoming connections on the router ...
131 2013-07-07 07:28:47 <darsie> michagogo: try again
132 2013-07-07 07:29:08 <darsie> testnet just finished syncing.
133 2013-07-07 07:29:39 <michagogo> darsie: Looks like you're a couple versions out of date :-P
134 2013-07-07 07:29:59 <darsie> k ...
135 2013-07-07 07:30:23 <darsie> How do I know I mined a block (on testnet)?
136 2013-07-07 07:30:39 <darsie> I'll take it to #bitcoin-mining ...
137 2013-07-07 07:48:06 <warren> cool! p2pool-13 is released. hardfork with sharechain miner vote.
138 2013-07-07 07:48:29 <warren> it should be a lot more ASIC friendly
139 2013-07-07 07:48:47 <mchgg> What is it?
140 2013-07-07 07:49:10 <warren> mchgg: https://bitcointalk.org/index.php?topic=18313
141 2013-07-07 07:49:17 <warren> mchgg: the ultimate in mining decentralization
142 2013-07-07 07:49:25 <mchgg> No, I mean what changed?
143 2013-07-07 07:49:27 <warren> (assuming there are no bugs...
144 2013-07-07 07:49:28 <warren> oh
145 2013-07-07 07:49:31 <warren> mchgg: read the commits
146 2013-07-07 07:49:45 <petertodd> oh, and the OP_RETURN too, nice!
147 2013-07-07 07:50:10 <mchgg> What OP_RETURN?
148 2013-07-07 07:50:31 <petertodd> marks a transaction output as unspendable
149 2013-07-07 07:50:54 <petertodd> in a standard way so they can be removed from the UTXO set
150 2013-07-07 07:51:12 <mchgg> I know what that *is*, where is it being used here?
151 2013-07-07 07:52:00 <petertodd> P2Pool is using it for the dummy txout they include in blocks
152 2013-07-07 07:53:36 <mchgg> Why do they include a dummy txout?
153 2013-07-07 07:53:44 <petertodd> They have to for the share chain
154 2013-07-07 07:54:26 <petertodd> It can't go in the coinbase or it'd limit what can go in there - bad for merge mining.
155 2013-07-07 08:00:45 <forrestv> mchgg, and the bigger reason is that it's at the end of the transaction, so everything prior to it can be compressed into a SHA256 midstate
156 2013-07-07 08:36:21 <warren> Dang. The -win32-setup.exe never was deterministic huh?
157 2013-07-07 08:54:11 <michagogo> warren: Hmm?
158 2013-07-07 08:54:28 <michagogo> I think it is...
159 2013-07-07 08:59:38 <warren> michagogo: huh? it is never the same in my gitian builds
160 2013-07-07 09:00:25 <michagogo> warren: check gitian.sigs
161 2013-07-07 09:02:00 <warren> michagogo: I'm building an alt coin. everything but the installer is deterministic. If it's supposed to be determinisic then I must have broke something myself.
162 2013-07-07 09:02:25 <michagogo> warren: A couple versions back, the setup was being non-deterministic
163 2013-07-07 09:02:30 <michagogo> I don't remember how it got fixed
164 2013-07-07 09:03:23 <michagogo> (check the commits around then?)
165 2013-07-07 09:05:21 <warren> I've been without sleep for too long
166 2013-07-07 09:59:53 <warren> michagogo: https://github.com/bitcoin/bitcoin/commit/8ab6d0a568013530c2df105fcc7c8dbdc894f74e
167 2013-07-07 09:59:54 <warren> michagogo: this?
168 2013-07-07 10:00:06 <michagogo> Maybe, yeah
169 2013-07-07 10:00:16 <michagogo> (look at gitian.sigs around that time?)
170 2013-07-07 10:00:36 <michagogo> (the 0.8.2 rc builds)
171 2013-07-07 10:01:01 <michagogo> (specifically, check if rc2 was non-deterministic while rc3 was)
172 2013-07-07 10:06:03 <warren> is the procedure of joining gitian.sigs documented?
173 2013-07-07 10:06:35 <warren> Gavin used my gitian hashes as part of releasing 0.8.2 and 0.8.3 ... and I didn't know about the pull request and sigs
174 2013-07-07 10:10:04 <michagogo> warren: What do you mean "joining"?
175 2013-07-07 10:11:47 <warren> michagogo: apparently the only people that count by some official release rule are people already included sometime in the past, and there is no procedure for adding more people, perhaps at a lesser trust level?
176 2013-07-07 10:12:54 <michagogo> warren: Hmm? Idk.
177 2013-07-07 10:13:06 <michagogo> All I know is that my PRs have been merged
178 2013-07-07 10:14:32 <warren> michagogo: I spent a dozen hours porting gitian to fedora. It's true that I haven't contributed much to upstream yet, but given I do gitian builds very often and I have a high level of trust from my other FOSS projects, I can be helpful in the release process here as another gitian verifier. there is however no process for new people to matter.
179 2013-07-07 10:14:45 <michagogo> define "matter"
180 2013-07-07 10:15:11 <warren> hmm, it isn't in my scrollback anymore
181 2013-07-07 10:15:25 <warren> there was a discussion about this right after the rushed release of 0.8.3
182 2013-07-07 10:16:34 <michagogo> Do you remember the date?
183 2013-07-07 10:16:49 <warren> it was within the hour or two after 0.8.3 was released
184 2013-07-07 10:17:02 <michagogo> When was that?
185 2013-07-07 10:17:09 <warren> someone complained to Gavin that he bypassed the release procedure
186 2013-07-07 10:17:16 <warren> i'm trying to find it in logs
187 2013-07-07 10:17:27 <michagogo> I can find it if you know the date
188 2013-07-07 10:17:38 <michagogo> Actually, I can check commit dates on gitian.sigs
189 2013-07-07 10:17:59 <warren> 6-25
190 2013-07-07 10:18:29 <michagogo> probably on http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/06/25 then
191 2013-07-07 10:19:51 <michagogo> 21:54, I think
192 2013-07-07 10:20:00 <warren> \tBlueMatt\twarren: everyone is welcome, but the rule is to wait for 3-from-the-somewhat-arbitrary-gitian-list
193 2013-07-07 10:20:59 <warren> It seems to me that any Ubuntu user can follow a simple procedure to learn how to gitian build, and you can easily have a hundred people testing it within minutes of a call for verification.
194 2013-07-07 10:21:23 <warren> and Luke-Jr's Gentoo and my fedora gitian port makes it even easier
195 2013-07-07 10:22:11 <michagogo> Hmm
196 2013-07-07 10:22:12 <michagogo> 22:03\tBlueMatt\twarren: you are even more welcome to implement a better system than the somewhat arbitrary was-here-when-the-list-was-made/has-git-push list we have now :)
197 2013-07-07 10:22:24 <michagogo> When was the list made, does anyone know
198 2013-07-07 10:22:25 <michagogo> ?
199 2013-07-07 10:22:54 <michagogo> 21:57\tBlueMatt\t(and did for 0.8.2)
200 2013-07-07 10:22:54 <michagogo> 21:57\tBlueMatt\tgmaxwell: well, we briefly discussed actually following the rules that we set after 0.8.1
201 2013-07-07 10:22:54 <michagogo> 21:57\tBlueMatt\t(that were set at like 0.4)
202 2013-07-07 10:22:54 <michagogo> Also, I'm wondering about the details of:
203 2013-07-07 10:23:04 <warren> michagogo: I need to implement a better system for my own team, so might as well do it for Bitcoin too.
204 2013-07-07 10:23:24 <warren> michagogo: I'm wondering where these rules are written
205 2013-07-07 10:23:30 <michagogo> me too
206 2013-07-07 10:23:36 <sipa> nowhere
207 2013-07-07 10:23:39 <warren> tribal knowledge is awesome
208 2013-07-07 10:23:53 <michagogo> Well, 0.8.1 came out 06-09
209 2013-07-07 10:24:06 <michagogo> Erm, no
210 2013-07-07 10:24:11 <michagogo> 03-17*
211 2013-07-07 10:24:17 <warren> 0.8.1 was in response to the 3/12 accident
212 2013-07-07 10:24:25 <michagogo> 06-09 was when sipa added his sigs
213 2013-07-07 10:24:25 <sipa> there was sort ofn informal rule that we waited for 3 trusted people to verify a build before relase, but even that rule hasn't been followed very strictly
214 2013-07-07 10:24:52 <sipa> but i agree, if we want to get this working better, it must become easier
215 2013-07-07 10:25:03 <michagogo> I'm going to the logs to see if I can find this discussion (21:57\tBlueMatt\tgmaxwell: well, we briefly discussed actually following the rules that we set after 0.8.1)
216 2013-07-07 10:38:03 <BlueMatt> hmm, strange
217 2013-07-07 10:38:09 <sipa> fixed?
218 2013-07-07 10:38:19 <BlueMatt> tyea
219 2013-07-07 10:38:20 <BlueMatt> yea
220 2013-07-07 10:38:26 <BlueMatt> just had to part to change nick for some reason...
221 2013-07-07 10:38:38 <michagogo> Hmm, I can't find the discussion BlueMatt mentioned from the 17th through the 21st of March
222 2013-07-07 10:38:42 <imton> sipa: searchrawtransactions may stop indexing txs for some reason?
223 2013-07-07 10:38:57 <BlueMatt> warren: the list kinda grew organically
224 2013-07-07 10:39:08 <BlueMatt> at the time it was essentially list of people with git commit + those helping with gitian stuff
225 2013-07-07 10:39:20 <warren> well, that describes me now
226 2013-07-07 10:39:21 <michagogo> [15:34:41] <BlueMatt> just had to part to change nick for some reason...
227 2013-07-07 10:39:22 <michagogo> Because you weren't identified to nickserv and the channel is +q $~a
228 2013-07-07 10:39:23 <BlueMatt> michagogo: ^
229 2013-07-07 10:39:43 <BlueMatt> fucking overcomplicated irc...
230 2013-07-07 10:39:44 <michagogo> BlueMatt: If you'd ID'd, you'd have been able to change nick
231 2013-07-07 10:39:56 <sipa> wizkid057: no
232 2013-07-07 10:39:57 <BlueMatt> well I had to change my nick to auto-id on the bouncer side
233 2013-07-07 10:40:02 <BlueMatt> (Im too lazy to know my password)
234 2013-07-07 10:40:06 <michagogo> ah
235 2013-07-07 10:40:06 <michagogo> BlueMatt: /msg nickserv id-
236 2013-07-07 10:40:10 <warren> the current procedure is too high a bar. Why not have trusted people and a mass number of untrusted all do it.
237 2013-07-07 10:40:21 <BlueMatt> warren: yes, that would be a good system
238 2013-07-07 10:40:23 <BlueMatt> go implement it!
239 2013-07-07 10:40:23 <sipa> eh
240 2013-07-07 10:40:26 <sipa> imton: no
241 2013-07-07 10:40:32 <SomeoneWeird> ACTION is trusted
242 2013-07-07 10:40:41 <SomeoneWeird> ACTION points gun at room
243 2013-07-07 10:40:45 <BlueMatt> warren: mostly implement something which verifies sigs in such a system
244 2013-07-07 10:40:49 <michagogo> BlueMatt: Solution: set up your bouncer to use SSL with a client certificate
245 2013-07-07 10:41:05 <BlueMatt> michagogo: overcomplicated...
246 2013-07-07 10:41:08 <warren> BlueMatt: trouble with an automated system is it becomes a centralized trust system...
247 2013-07-07 10:41:09 <michagogo> BlueMatt: Not really
248 2013-07-07 10:41:24 <BlueMatt> warren: probably based on https://github.com/devrandom/gitian-builder/blob/master/share/gitian_updater.py
249 2013-07-07 10:41:41 <michagogo> BlueMatt: You just generate a certificate, give it to your bouncer, and tell nickserv about it
250 2013-07-07 10:41:53 <BlueMatt> warren: well come up with a decentralized way that allows $MY_GRANDMA to use it without making it overcomplicated for her
251 2013-07-07 10:43:30 <nsh> pickle($BlueMatts_GRANDMA)
252 2013-07-07 10:44:04 <sipa> if a decentralized verification systems boils down to "download and run X", it's pretty pointless
253 2013-07-07 10:44:05 <warren> even the bitcoin-otc database is worryingly centralized
254 2013-07-07 10:44:12 <warren> yeah, it uses crypto to verify entry
255 2013-07-07 10:44:13 <sipa> you at least need someone who understands what is going on
256 2013-07-07 10:44:17 <warren> but the database itself can be compromised
257 2013-07-07 10:44:26 <BlueMatt> its better than what we have now
258 2013-07-07 10:44:34 <BlueMatt> and as long as some percent of people verify X
259 2013-07-07 10:44:40 <BlueMatt> then its at least reasonable
260 2013-07-07 10:44:58 <BlueMatt> ACTION is more concerned about mitm while updating than mitm during initial download
261 2013-07-07 10:45:18 <imton> sipa: so should "-txindex=1 -addrindex=1" be the same as if I add that to the conf file?
262 2013-07-07 10:45:25 <warren> gavinandresen\tThe only criteria for being on the list should be "is not a sockpuppet of somebody already on the list"
263 2013-07-07 10:46:16 <michagogo> imton: yes
264 2013-07-07 10:46:24 <sipa> imton: yes
265 2013-07-07 10:46:47 <michagogo> BTW, where is this list maintained?
266 2013-07-07 10:47:24 <sipa> for a long time, it was just "those who have access to the gitian repo"
267 2013-07-07 10:47:32 <sipa> there were no others doing builds anyway
268 2013-07-07 10:47:39 <BlueMatt> https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-downloader/ *-download-config
269 2013-07-07 10:47:46 <warren> BlueMatt: should I submit a PR for my own sig now? meanwhile I need to come up with a better system for my own team, so might as well propose it for both teams, and heck both teams can verify each other.
270 2013-07-07 10:47:52 <BlueMatt> to be clear: the list isnt used anywhere....
271 2013-07-07 10:48:04 <imton> sips michagogo: well guys, I am on testnet and an address tx wasn't indexed for "searchrawtransactions". 2 of 3 tx were showing ok , 1 missing. I reindexed and it appeared.
272 2013-07-07 10:48:07 <BlueMatt> warren: there really isnt any point
273 2013-07-07 10:48:09 <warren> teams that somewhat distrust each other can be good to verify gitian
274 2013-07-07 10:48:15 <BlueMatt> no one uses the list for anything currently :(
275 2013-07-07 10:48:20 <imton> sipa michagogo : bug?
276 2013-07-07 10:48:23 <sipa> imton: perhaps
277 2013-07-07 10:48:27 <SomeoneWeird> <warren> but the database itself can be compromised < the database is open source..
278 2013-07-07 10:48:29 <sipa> imton: i have no time to look at it now
279 2013-07-07 10:48:35 <SomeoneWeird> er, s/open source/public
280 2013-07-07 10:49:01 <warren> BlueMatt: then why did someone complain about violating the unwritten release rules? ...
281 2013-07-07 10:49:04 <BlueMatt> warren: it would be nice if someone dealt with the remaining like 2 things required for gitian downloads to even be possible
282 2013-07-07 10:49:17 <warren> what exactly is gitian downloads supposed to do?
283 2013-07-07 10:49:20 <BlueMatt> warren: that was me, and because when releases happen with like 2 sigs its not nice...
284 2013-07-07 10:49:41 <warren> BlueMatt: there were three, i just didn't do it through a PR
285 2013-07-07 10:49:49 <imton> sipa: ok. fyi the missing tx was correcting being shown when doing *getrawtransaction* (btw, this address wasn't in the wallet)
286 2013-07-07 10:50:01 <imton> *correctly '
287 2013-07-07 10:50:04 <warren> BlueMatt: I might have been the first to respond to Gavin in the past two releases
288 2013-07-07 10:50:34 <sipa> imton: ok, interesting
289 2013-07-07 10:50:51 <BlueMatt> warren: also, because I keep wanting to actually enable gitian-downloads, and that means we need 3 sigs from the list at release time
290 2013-07-07 10:51:25 <warren> BlueMatt: is gitian downloader supposed to be a trustworthy way for users to automatically update because N-of-M decentralized trusted leaders all agreed with GPG on signatures?
291 2013-07-07 10:51:57 <warren> If it's meant to be automated where users don't need to worry, 3 isn't enough, I think.
292 2013-07-07 10:51:59 <BlueMatt> essentially
293 2013-07-07 10:52:21 <BlueMatt> we dont get more than 3 builders now...how are we supposed to require more than we can ever get?
294 2013-07-07 10:52:27 <michagogo> Also, it looks like it's not necessarily a certain number
295 2013-07-07 10:52:37 <BlueMatt> its a certain total weight
296 2013-07-07 10:52:38 <pigeons> or N-of-M all have the backdoor
297 2013-07-07 10:52:40 <BlueMatt> each signer gets a weight
298 2013-07-07 10:52:44 <michagogo> But rather a certain weight, where different users can be given more weight than others
299 2013-07-07 10:52:47 <michagogo> yeah
300 2013-07-07 10:53:00 <BlueMatt> pigeons: and right now its N all have the backdoor
301 2013-07-07 10:53:03 <imton> sipa: could it be added to *searchrawtransactions* the txs "made from" this address ? I need to implement an address balance feature an i am missing the "spent" data...
302 2013-07-07 10:53:05 <BlueMatt> so its a shitton better
303 2013-07-07 10:53:17 <sipa> imton: that's supposed to work
304 2013-07-07 10:53:34 <sipa> imton: it indexes the output scripts and the output scripts being consumed
305 2013-07-07 10:53:35 <warren> BlueMatt: apparently at 0.8.2 gmaxwell was amazed when my fedora gitian actually matched Gavin's build. Which makes me wonder if gmaxwell and jgarzik (a fedora users) participate in gitian verification? And petertodd today said he doesn't do it. The top trusted leaders don't do it?
306 2013-07-07 10:53:49 <imton> sipa: sorry? right now? I only get the received txs
307 2013-07-07 10:53:56 <BlueMatt> warren: up until recently jgarzik couldn't due to patent stuff
308 2013-07-07 10:53:57 <sipa> imton: really? :o
309 2013-07-07 10:54:03 <BlueMatt> warren: and we've had lots of problems with gitian matching
310 2013-07-07 10:54:03 <sipa> imton: it also only indexes the blockchain; so it doesn't work for unconfirmed transactions
311 2013-07-07 10:54:03 <warren> BlueMatt: ah
312 2013-07-07 10:54:09 <imton> sipa: i think so...
313 2013-07-07 10:54:11 <BlueMatt> because no one has time to fix it (nor cared)
314 2013-07-07 10:54:17 <sipa> imton: when i last tested it worked fine
315 2013-07-07 10:54:27 <imton> sipa: ok. let me check...
316 2013-07-07 10:54:36 <warren> I fixed part of TheUni's autotools for determinism
317 2013-07-07 10:54:40 <BlueMatt> warren: which is exactly why I wasnt happy when releases briefly happened according to gitian policy, and then went back
318 2013-07-07 10:55:26 <sipa> to be realistic, if gitian building and verification are just a pain that we can't even find 3 people to do it, there is just no reason to
319 2013-07-07 10:55:41 <warren> there is plenty reason to
320 2013-07-07 10:55:43 <warren> and it really isn't hard
321 2013-07-07 10:55:55 <warren> i got my entire Litecoin team to do it by giving them step-by-step instructions
322 2013-07-07 10:56:00 <michagogo> ?
323 2013-07-07 10:56:00 <michagogo> BlueMatt: patent stuff
324 2013-07-07 10:56:07 <warren> michagogo: seriously, don't as
325 2013-07-07 10:56:08 <warren> ask
326 2013-07-07 10:56:15 <michagogo> What patent stuff?
327 2013-07-07 10:56:20 <sipa> well, if people were to demand deterministically verified builds, it would happen
328 2013-07-07 10:56:29 <sipa> but nobody seems to care about it except those that build it
329 2013-07-07 10:56:31 <BlueMatt> sipa: its not, if we have someone who has time to make sure the builds work properly, but when they dont match, the usual response is "oh well"
330 2013-07-07 10:56:35 <sipa> which is a pity
331 2013-07-07 10:56:48 <sipa> i think the time of release is too late
332 2013-07-07 10:56:56 <BlueMatt> this is why I tried to do auto-update that worked
333 2013-07-07 10:56:58 <michagogo> [15:51:40] <sipa> to be realistic, if gitian building and verification are just a pain that we can't even find 3 people to do it, there is just no reason to
334 2013-07-07 10:56:58 <michagogo> I don't understand how it's a pain
335 2013-07-07 10:57:02 <BlueMatt> but...no one cared :p
336 2013-07-07 10:57:11 <sipa> michagogo: to me it's not, but i'm biased
337 2013-07-07 10:57:12 <warren> the litecoin team currently builds twice per user and records hashes in a google doc, each user uses two factor auth. that made it easy for them to actually do it.
338 2013-07-07 10:57:20 <BlueMatt> maybe someday someone will revive it
339 2013-07-07 10:57:20 <michagogo> When a new release it tagged, I reboot into Ubuntu, paste a couple commands into Terminal, and wait
340 2013-07-07 10:57:20 <warren> yeah, it isn't GPG secure
341 2013-07-07 10:57:22 <michagogo> That's it
342 2013-07-07 10:57:22 <sipa> i'm just observing that nobody really cares about it but us
343 2013-07-07 10:57:42 <michagogo> Really not a big deal
344 2013-07-07 10:57:46 <warren> well, my team cares about it now, and we can help bitcoin verification too
345 2013-07-07 10:57:51 <BlueMatt> sipa: mostly it is a prerequisite for auto-update
346 2013-07-07 10:57:51 <michagogo> (in terms of difficulty/hassle)
347 2013-07-07 10:58:10 <BlueMatt> sipa: which, since no one cares about that either, means no one cares about gitian
348 2013-07-07 10:58:10 <warren> my team is even interested in gitian mac cross-compiling
349 2013-07-07 10:58:21 <BlueMatt> warren: talk to the tor guys about that one
350 2013-07-07 10:58:36 <warren> BlueMatt: I already forwarded all that info to our mac dev
351 2013-07-07 10:59:11 <sipa> BlueMatt: well i don't care enough about windows to work on that, indeed
352 2013-07-07 10:59:13 <warren> BlueMatt: can we find funding to pay him? this guy is GOOD but we can't afford to pay him enough
353 2013-07-07 10:59:30 <BlueMatt> sipa: neither do I, really...
354 2013-07-07 10:59:42 <BlueMatt> warren: pay who?
355 2013-07-07 10:59:55 <sipa> so there's no problem - complaining "someone should do this!" will not make it happen
356 2013-07-07 11:00:11 <sipa> and that may be a pity, but it doesn't really mean anything for gitian builds
357 2013-07-07 11:00:20 <BlueMatt> sipa: sorry, I do care enough to do it, but I never have nearly enough time to invest in it
358 2013-07-07 11:00:45 <sipa> by the time a viable update notification is ready, we'll need a strict gitian policy, and there's no problem with that
359 2013-07-07 11:01:14 <michagogo> [15:48:35] <BlueMatt> we dont get more than 3 builders now...how are we supposed to require more than we can ever get?
360 2013-07-07 11:01:14 <michagogo> I just checked the last couple releases
361 2013-07-07 11:01:16 <warren> BlueMatt: face00. Old school OpenBSD and now MacOS X hacker. VP of Engineering at a secret startup currently. I'm convinced he has the skill to do the gitian cross-compile toolchain needed for deterministic mac builds from any linux host, but he needs money.
362 2013-07-07 11:01:31 <michagogo> Other than 0.8.1 which was a rush release, we've had 5-6 several times
363 2013-07-07 11:02:01 <BlueMatt> warren: the tor guys already figured it out
364 2013-07-07 11:02:06 <BlueMatt> warren: no need to hire anyone
365 2013-07-07 11:02:12 <warren> oh? hm
366 2013-07-07 11:02:15 <BlueMatt> michagogo: not at the time of release
367 2013-07-07 11:02:27 <BlueMatt> michagogo: more sigs generally fill in after release, which is kinda broken
368 2013-07-07 11:02:30 <michagogo> Ah.
369 2013-07-07 11:02:54 <BlueMatt> warren: just have to copy their base stuff and adapt it (they are building the whole TBB in gitian for mac, incl firefox)
370 2013-07-07 11:03:16 <warren> BlueMatt: links please? I'll feed it over.
371 2013-07-07 11:03:29 <BlueMatt> dont have them atm
372 2013-07-07 11:03:51 <BlueMatt> look at https://blog.torproject.org/category/tags/gitian though
373 2013-07-07 11:03:57 <warren> https://github.com/bitcoin/bitcoin/commit/8ab6d0a568013530c2df105fcc7c8dbdc894f74e btw, does anyone understand how this works? I tihnk we have the same problem now.
374 2013-07-07 11:04:39 <BlueMatt> warren: nsis nondeterministically reencodes pixmaps if they dont include all the resolutions it wants iirc
375 2013-07-07 11:06:11 <warren> BlueMatt: any idea what tools are needed and what resolutions?
376 2013-07-07 11:06:18 <BlueMatt> nfc
377 2013-07-07 11:06:20 <michagogo> BTW, what are the .pgp files? Public keys?
378 2013-07-07 11:06:25 <BlueMatt> yea
379 2013-07-07 11:06:26 <BlueMatt> usually
380 2013-07-07 11:06:34 <warren> well, it might be pointless, but I'm submitting a PR
381 2013-07-07 11:07:52 <warren> I am thinking about a long-term solution to this.
382 2013-07-07 11:08:14 <BlueMatt> its only useful if you get people to verify the sigs, which no one does
383 2013-07-07 11:09:03 <lupine> well, it has two uses - encryption and identity
384 2013-07-07 11:09:06 <lupine> just like SSL
385 2013-07-07 11:09:06 <warren> verify sigs, as in the regular GPG web of trust procedure?
386 2013-07-07 11:09:28 <BlueMatt> dont even care if you use wot, people right now just download binaries and run
387 2013-07-07 11:09:29 <sipa> warren: as in build and compare
388 2013-07-07 11:09:33 <sipa> ah
389 2013-07-07 11:09:35 <sipa> yeah
390 2013-07-07 11:09:39 <BlueMatt> dont even verify pgp sigs compared to list they download over http
391 2013-07-07 11:09:53 <warren> BlueMatt: yeah, we're worried about that, so we
392 2013-07-07 11:11:26 <warren> BlueMatt: so we're implementing multiple layers of user protection. 1) SSL to one download server hidden by DDoS provider, with firewall has zero open ports to anything but the DDoS provider. 2) GPG signatures for the clueful people. 3) Microsoft and Apple certs for the distributed binaries. 4) User education on building their own gitian builds to help verify.
393 2013-07-07 11:12:09 <warren> As for the problem of not enough people doing gitian verification, I have six people doing it for my team now, and they can easily do it for bitcoin too. We can verify each other, and train more end-users to help.
394 2013-07-07 11:12:44 <sipa> imton: also, anything that reasons in terms of a 'address balance' is broken design imho
395 2013-07-07 11:14:10 <BlueMatt> until there are more than two "clueful people" in category 2, its essentially pointless
396 2013-07-07 11:14:42 <warren> I'm submitting a PR to add myself to contrib/gitian-downloader. I see other people have a trust weight of 40. Should I request 20?
397 2013-07-07 11:15:25 <BlueMatt> do whatever you want, I have no problem with 40, you've been around for a while
398 2013-07-07 11:15:31 <warren> ok thanks
399 2013-07-07 11:15:32 <BlueMatt> (+ the usual its-not-used-anyway...)
400 2013-07-07 11:15:43 <warren> well, it's meant to be used one day
401 2013-07-07 11:15:57 <warren> hmm, what format of key is that?
402 2013-07-07 11:16:04 <warren> most are binary, one is ascii
403 2013-07-07 11:16:41 <BlueMatt> anything gpg can import
404 2013-07-07 11:16:41 <sipa> BlueMatt: how did your previous auto-updater verify signatures? require GPG to be installed?
405 2013-07-07 11:16:54 <BlueMatt> sipa: it came with gpg-for-windows binary
406 2013-07-07 11:16:59 <BlueMatt> (as well as lots of binaries)
407 2013-07-07 11:17:10 <sipa> bleh
408 2013-07-07 11:17:12 <BlueMatt> yep
409 2013-07-07 11:17:43 <nsh> (remember to mentally prepend "NSA-backdoored" to all instances of the word binary)
410 2013-07-07 11:18:24 <BlueMatt> never said it was good
411 2013-07-07 11:18:41 <jouke> What is not used anyway? The signatures from a deterministic build?
412 2013-07-07 11:18:55 <sipa> if only we could use our own signature mechanism...
413 2013-07-07 11:19:07 <BlueMatt> ooo, we should rewrite gpg
414 2013-07-07 11:19:09 <sipa> then it could just be verified internaly
415 2013-07-07 11:19:24 <BlueMatt> ACTION -> back to work
416 2013-07-07 11:19:36 <sipa> isn't it sunday?
417 2013-07-07 11:19:47 <michagogo> sipa: bitcoin has a signature mechanism. Is that what you were referring to
418 2013-07-07 11:19:48 <michagogo> ?
419 2013-07-07 11:19:53 <BlueMatt> yea, took friday and napped all day, but didnt feel like taking a vacation day, so working today
420 2013-07-07 11:19:59 <warren> BlueMatt: that's a big issue for windows users ... the recommended gpg "GPG4Win" is perpetually broken
421 2013-07-07 11:20:13 <warren> BlueMatt: and how do windows users trust the GPG they are downloading is secure...
422 2013-07-07 11:20:15 <jouke> Is there a demand for more people to create a gitian build?
423 2013-07-07 11:20:21 <warren> jouke: yes
424 2013-07-07 11:20:23 <BlueMatt> jouke: not really :(
425 2013-07-07 11:20:25 <warren> jouke: i will publish instructions
426 2013-07-07 11:20:32 <BlueMatt> there should be, but there isnt
427 2013-07-07 11:20:44 <BlueMatt> warren: there are already good instructions....
428 2013-07-07 11:20:54 <michagogo> warren: release-process.md
429 2013-07-07 11:20:55 <BlueMatt> (that are essentially bash + details)
430 2013-07-07 11:20:55 <jouke> why do you believe that is the case BlueMatt?
431 2013-07-07 11:21:05 <BlueMatt> jouke: read scrollback?
432 2013-07-07 11:21:11 <BlueMatt> ACTION -> food, then work
433 2013-07-07 11:21:34 <aspect_> guys, question: will nodes relay transactions if they have invalid inputs?
434 2013-07-07 11:21:56 <sipa> no
435 2013-07-07 11:22:40 <sipa> jouke: i've never heard anyone complain about not enough gitian builders, except those that do gitian builds
436 2013-07-07 11:23:02 <sipa> so there isn't really 'demand' for it, just a feeling that it's the right thing to do by those who do :)
437 2013-07-07 11:23:44 <sipa> ACTION afk
438 2013-07-07 11:23:46 <jouke> Hmmmm.
439 2013-07-07 11:23:57 <aspect_> so if a site processes 0 confirmation transactions, someone would have to connect directly to an ip of the server to issue that...
440 2013-07-07 11:24:30 <warren> aspect_: the node accepts transactions with inputs that it doesn't know about yet and immediately considers the tx an "orphan"
441 2013-07-07 11:25:53 <aspect_> however, if you do listsinceblock I presume this transaction shows up?
442 2013-07-07 11:26:04 <warren> sipa's pgp key is 10-100x the size of everyone else's key. =0
443 2013-07-07 11:26:14 <SomeoneWeird> warren, subkeys?
444 2013-07-07 11:26:26 <Luke-Jr> sipa: well, we need 3 signatures for every release, and it's often hard to get them :p
445 2013-07-07 11:26:28 <warren> prolly
446 2013-07-07 11:26:38 <Luke-Jr> until recently
447 2013-07-07 11:27:51 <jouke> Interesting.
448 2013-07-07 11:28:42 <jouke> Ok. I guess I should find the time to do this.
449 2013-07-07 11:29:21 <jouke> But at the download-stats, I often wonder why so few people download the signatures.
450 2013-07-07 11:32:36 <Luke-Jr> jouke: meh, those signatures are a single person and not especially useful
451 2013-07-07 11:32:49 <Luke-Jr> if someone's checking sigs, they should be cloning the gitian.sigs repo
452 2013-07-07 11:33:32 <jouke> Luke-Jr: you are right.
453 2013-07-07 11:37:02 <warren> BlueMatt: https://github.com/bitcoin/bitcoin/pull/2816
454 2013-07-07 11:37:28 <warren> Luke-Jr: if people are checking sigs they should download all sigs from the key servers
455 2013-07-07 11:38:31 <jouke> sigs from key servers?
456 2013-07-07 11:39:22 <Luke-Jr> warren: AEC1884398647C47413C1C3FB1179EB7347DC10D ?
457 2013-07-07 11:39:39 <Luke-Jr> warren: binary sigs aren't on keyservers
458 2013-07-07 11:42:21 <Luke-Jr> warren: poke
459 2013-07-07 11:43:31 <imton> can someone tell my whe this test net priv key is invalid ? "0812d0b5133bc2f7c92525e4c9204fbc78a07299e77d7e28181fd0b1a9f9e285"
460 2013-07-07 11:44:07 <Luke-Jr> imton: what makes you think it's invalid?
461 2013-07-07 11:44:25 <imton> Luke-Jr: {"code"=>-5, "message"=>"Invalid private key"}
462 2013-07-07 11:44:36 <Luke-Jr> imton: oh, you're trying to use the wrong format
463 2013-07-07 11:44:48 <Luke-Jr> your string there looks like it's hex data
464 2013-07-07 11:44:53 <imton> yes...
465 2013-07-07 11:44:54 <Luke-Jr> importprivkey takes base58
466 2013-07-07 11:44:57 <imton> :(
467 2013-07-07 11:45:06 <imton> Luke-Jr: thanks!
468 2013-07-07 11:45:20 <imton> would be awesome if that is in the docs??? :p
469 2013-07-07 11:45:42 <Luke-Jr> patches welcome?
470 2013-07-07 11:46:38 <imton> :) ok!
471 2013-07-07 11:48:01 <warren> Luke-Jr: yes they are
472 2013-07-07 11:48:07 <warren> Luke-Jr: oh wait
473 2013-07-07 11:48:21 <warren> Luke-Jr: what is that hex string supposed to be?
474 2013-07-07 11:48:46 <warren> Luke-Jr: sorry, two different issues I mixed up
475 2013-07-07 11:49:27 <Luke-Jr> warren: please tell me here your PGP key fingerprint :P
476 2013-07-07 11:49:57 <warren> Luke-Jr: https://togami.com/~warren/warren-gpg-transition-2013.txt.asc
477 2013-07-07 11:50:18 <Luke-Jr> warren: please say the fingerprint here.
478 2013-07-07 11:50:26 <warren> how does that help?
479 2013-07-07 11:50:38 <warren> Key fingerprint = AEC1 8843 9864 7C47 413C 1C3F B117 9EB7 347D C10D
480 2013-07-07 11:50:38 <warren> pub 8192R/347DC10D 2013-06-29
481 2013-07-07 11:50:38 <warren> sub 8192R/668709D4 2013-06-29
482 2013-07-07 11:50:38 <warren> uid Warren Togami (2013) <wtogami@gmail.com>
483 2013-07-07 11:50:38 <warren> [warren@newcaprica gitian-downloader]$ gpg --fingerprint AEC1884398647C47413C1C3FB1179EB7347DC10D
484 2013-07-07 11:51:22 <warren> Luke-Jr: I made this new key recently because a few weeks ago I met this 18 year old girl. She read my business card and immediately scolded me for my "weak" 1024bit DSA key.
485 2013-07-07 11:51:26 <Luke-Jr> warren: my only current link to you is via IRC, so best I can do is verify your NickServ account is properly authenticated and such
486 2013-07-07 11:52:39 <warren> Luke-Jr: btw, are bfgminer releases signed?
487 2013-07-07 11:52:50 <warren> it worries me that cgminer binaies aren't signed
488 2013-07-07 11:52:58 <Luke-Jr> warren: just by me
489 2013-07-07 11:53:05 <Luke-Jr> not built deterministically
490 2013-07-07 11:53:13 <warren> signed at all is better than nothing
491 2013-07-07 11:55:20 <warren> https://litecoin.org/downloads/.warren/warren-gpg-transition-2013.txt.asc <--- yet another place to put it
492 2013-07-07 11:56:12 <Luke-Jr> frankly, that signed message is useless to me :p
493 2013-07-07 12:01:20 <imton> could someone explain me why I get this error when signing a tx {"code"=>-22, "message"=>"Previous output scriptPubKey mismatch:\\nOP_DUP OP_HASH160 651ad09e151a3376e7b63f663e342c426530205e OP_EQUALVERIFY OP_CHECKSIG\\nvs:\\nOP_DUP OP_HASH160 2518bcb5a56f73ab6c7878f4795d720f84c0bcfc OP_EQUALVERIFY OP_CHECKSIG"}
494 2013-07-07 12:08:47 <warren> BlueMatt: it seems that an ideal gitian verification procedre would involve 1) not telling people where to get the inputs, because those imports aren't signed themselves, you add to risk by telling everyone to download a particular unverifiable source tarball at a particular URL.
495 2013-07-07 12:09:17 <warren> 2) and users need to submit hashes without the ability to see hashes submitted by other people
496 2013-07-07 12:10:00 <BlueMatt> warren: in this case ideal is the enemy of good
497 2013-07-07 12:10:03 <BlueMatt> right now we have nothing
498 2013-07-07 12:10:13 <BlueMatt> so making something good that can later be tweaked is the way forward
499 2013-07-07 12:10:57 <warren> BlueMatt: good and decentralized doesn't seem to be compatible here...
500 2013-07-07 12:11:14 <BlueMatt> semi-decentralized is better than nothing
501 2013-07-07 12:11:50 <warren> "better than nothing" is not good enough for end-users to just trust
502 2013-07-07 12:12:03 <warren> but I see your point
503 2013-07-07 12:12:09 <BlueMatt> making an ideal system in this case is essentially impossible
504 2013-07-07 12:12:14 <warren> I want to work on this problem.
505 2013-07-07 12:12:16 <BlueMatt> so make a good one, that is easy for users to use
506 2013-07-07 12:12:39 <warren> the #4 educatoin aspect is easy
507 2013-07-07 12:12:48 <BlueMatt> hah
508 2013-07-07 12:12:54 <BlueMatt> no
509 2013-07-07 12:13:24 <BlueMatt> unless you force every user to rebuild the bins instead of just downloading them
510 2013-07-07 12:13:26 <warren> there are thousands of software engineers out there that use Bitcoin that are comptetent enough to understand how to do this and implications
511 2013-07-07 12:13:32 <BlueMatt> no one is gonna bother rebuilding
512 2013-07-07 12:13:39 <BlueMatt> hell, even I dont bother checking sigs more often than not
513 2013-07-07 12:14:33 <warren> I will think more about this. I agree with the end-goal.
514 2013-07-07 12:33:09 <Eliel> for an ideal solution, either Bitcoin needs to include all necessary code by itself or every dependent library needs to have a similar procedure with which to verify it's integrity.
515 2013-07-07 12:33:58 <michagogo> Am I correct in assuming people don't know me well enough to be added to the gitian list?
516 2013-07-07 12:34:37 <BlueMatt> the second can be accomplished with gitian builds of dependencies
517 2013-07-07 13:03:30 <imton> sipa: you were right, searchrawtransactions is indexing txs made from that addrs too, so i can implement full balances :) love it.
518 2013-07-07 13:04:06 <imton> sipa: do you have any benchmark how fast is searchrawtransactions over the bitcoin network? (i am on testnet)
519 2013-07-07 14:20:35 <gmaxwell> sipa: https://bitcointalk.org/index.php?topic=251615.0 < that doesn't sound good.
520 2013-07-07 14:21:39 <BlueMatt> gmaxwell: Im confused as to what he is testing?
521 2013-07-07 14:21:46 <michagogo> Is there a way for me to move https://github.com/bitcoin/bitcoin/pull/2798 onto another branch?
522 2013-07-07 14:21:54 <BlueMatt> "takes longer for the network" how is he testing a 300-block reorg on the network?
523 2013-07-07 14:22:10 <michagogo> (I can't update master from upstream because that PR is outstanding)
524 2013-07-07 14:22:15 <michagogo> testnet-in-a-box?
525 2013-07-07 14:22:16 <BlueMatt> michagogo: you'd have to open a new pullreq
526 2013-07-07 14:23:39 <gmaxwell> BlueMatt: I had the impression that person is working on an alternative implementation,??? my memory may be failing me there. So I was guessing that he's actually testing acceptance.
527 2013-07-07 14:23:49 <gmaxwell> (e.g. on a node in isolation)
528 2013-07-07 14:24:11 <BlueMatt> gmaxwell: not sure how one node in isolation will take even 1-2 blocks to accept a reorg
529 2013-07-07 14:24:30 <BlueMatt> if you're reorging cs_main should lock so you cant receive new blocks during that time
530 2013-07-07 14:24:38 <BlueMatt> (nor generate on the old blocks, no?)
531 2013-07-07 14:25:50 <gmaxwell> BlueMatt: I was assuming the 1-2 was just that the reorg has to get _ahead_ not tie.
532 2013-07-07 14:25:57 <gmaxwell> But it's a good question.
533 2013-07-07 14:25:59 <BlueMatt> hmm
534 2013-07-07 14:26:08 <BlueMatt> that post just seems very unclear as to what the issue is
535 2013-07-07 14:26:15 <BlueMatt> (if any)
536 2013-07-07 14:26:43 <BlueMatt> would be interesting to turn current block tester into a full-scale tester that tests things like making the target bitcoind generate blocks and while the thing is running and see what it does
537 2013-07-07 14:26:51 <gmaxwell> BlueMatt: While I'm here, need me to explain that rand patch? (I appreciate the review??? I wasn't trying to blow you off with my response)
538 2013-07-07 14:27:15 <BlueMatt> gmaxwell: no, I got it after I actually read it more closely
539 2013-07-07 14:31:09 <michagogo> BlueMatt: Done (I hope I did it right)
540 2013-07-07 14:34:47 <BlueMatt> michagogo: lgtm
541 2013-07-07 14:55:02 <diki> anyone know how the win odds are calculated for dice games?
542 2013-07-07 14:56:26 <gmaxwell> BlueMatt: an actual ack on that patch would be nice if you're happy with it now. :)
543 2013-07-07 14:56:42 <BlueMatt> gmaxwell: you ask for too much
544 2013-07-07 14:56:47 <sipa> imton: it's linear in the search results
545 2013-07-07 14:57:12 <sipa> imton: but please, i beg you to reconsider if you're buildong something that uses "balance of an address"
546 2013-07-07 14:57:32 <BlueMatt> gmaxwell: done, but please do add "(fixes #2714)" to the commitmsg title
547 2013-07-07 14:59:03 <sipa> diki: math
548 2013-07-07 14:59:50 <gmaxwell> BlueMatt: sure, done.
549 2013-07-07 15:00:50 <diki> sipa:what is the exact formula
550 2013-07-07 15:01:16 <BlueMatt> diki: target possibilities divided by total possibilities
551 2013-07-07 15:03:36 <diki> By possibilities you mean 2^32? Since most dice games fetch the first four bytes of the hash
552 2013-07-07 15:04:54 <BlueMatt> sure
553 2013-07-07 15:11:28 <gmaxwell> sipa: am I nitpicking the ping patch too much? Feel free to ignore me if I am.
554 2013-07-07 15:12:11 <sipa> gmaxwell: it's a reasonable comment - i have no idea how hard it is to make a node so busy it doesn't respond dfor one minute
555 2013-07-07 15:12:22 <sipa> i guess that during IBD it may actually be easy
556 2013-07-07 15:14:01 <gmaxwell> sipa: yea, thats a random handwave. TCP isn't actually guarenteed to make progress on a congested link though. But I'm not actually sure that if someone congests you enough to cause 1 minute delays that even 10 minutes would be much harder to achieve.
557 2013-07-07 16:35:54 <jemadux> is there a greek l10n for bitcoin-qt ?
558 2013-07-07 16:36:20 <jemadux> cuz in my system i have all on english ... that's the question
559 2013-07-07 16:37:00 <BlueMatt> jemadux: yes, there does appear to be one
560 2013-07-07 16:37:01 <BlueMatt> https://www.transifex.com/projects/p/bitcoin/
561 2013-07-07 16:40:59 <diki> Have any of you guys looked at the prime proof-of-work paper?
562 2013-07-07 16:42:16 <pigeons> Sunnky King released a paper on that?
563 2013-07-07 16:43:08 <pigeons> with centralized checkpoint distribution ;) ?
564 2013-07-07 16:50:21 <diki> well, still a new non-hashcash proof-of-work
565 2013-07-07 16:51:00 <pigeons> yeah i'm interested
566 2013-07-07 21:47:21 <gmaxwell> Post by Hal: https://bitcointalk.org/index.php?topic=175156.msg2677193#msg2677193