1 2013-06-03 00:08:47 <ne0futur> update : http://www.reddit.com/r/Bitcoin/comments/1f9apl/alert_microsoft_advertising_network_is_serving_up/caayjwp
2 2013-06-03 04:06:34 <midnightmagic> Is there a snappy way to directly import the blockchain into the leveldb store without replaying blocks? Like a db copy?
3 2013-06-03 04:07:09 <midnightmagic> I have a fast machine and a slow machine. The fast machine keeps up easily. The slow machine does not..
4 2013-06-03 04:08:13 <sipa> you can copy the databases (while the program isn't running)
5 2013-06-03 04:08:24 <midnightmagic> I see chainstate/* and blocks/* and I'm hoping I can just copy stuff over into them.
6 2013-06-03 04:08:29 <sipa> yes
7 2013-06-03 04:08:30 <midnightmagic> sipa: Thank you.
8 2013-06-03 04:08:40 <sipa> you can even copy them independently
9 2013-06-03 04:08:52 <sipa> just make sure that the chainstate/* is not newer than blocks/*
10 2013-06-03 04:08:56 <midnightmagic> ah nice.
11 2013-06-03 05:20:11 <betatwelve> hello
12 2013-06-03 05:20:39 <betatwelve> what are testcoins used for and how to get some?
13 2013-06-03 05:24:19 <lianj> betatwelve: testing. http://tpfaucet.appspot.com/
14 2013-06-03 05:24:46 <betatwelve> How can I get some testcoins?
15 2013-06-03 05:25:47 <betatwelve> OK i try to go to tpfaucet.appspot.com
16 2013-06-03 05:32:02 <Luke-Jr> "TestNet coins are worthless, but useful. They are useful because they are worthless. If you will add value to them, they will be useless, therefore worthless." <-- lol, nice
17 2013-06-03 05:32:21 <jouke> :)
18 2013-06-03 06:22:44 <dansmith_btc> Is there a way to run bitcoind so that it doesn't sync and yet is connected so that I could sendrawtransaction ?
19 2013-06-03 06:45:57 <kinlo> dansmith_btc: why do you want to do that, if you are already capable of building raw transactions without knowing from which inputs, why don't you just submit the transaction on the p2p network yourself?
20 2013-06-03 06:49:57 <sipa> i don't think that'll even work: sendrawtransaction submits to the local mempool, which won't accept it if it consumes inputs that it doesn't know about (yet)
21 2013-06-03 06:50:10 <sipa> i think we need a 'force' flag to sendrawtransaction to skip that
22 2013-06-03 07:35:58 <dansmith_btc> kinlo, is there a simple tool which submits rawtransactions to the network?
23 2013-06-03 07:36:18 <dansmith_btc> sipa, yes a force flag would be great
24 2013-06-03 07:36:38 <kinlo> I doubt the force flag would make sense
25 2013-06-03 07:36:49 <kinlo> I'd still think you just should send it on p2p
26 2013-06-03 07:37:07 <gmaxwell> considering your whole crazy idea is for blockchain.info users, why not use https://blockchain.info/pushtx
27 2013-06-03 07:37:11 <gmaxwell> ?
28 2013-06-03 07:37:48 <lianj> or http://webbtc.com/relay_tx
29 2013-06-03 07:39:12 <dansmith_btc> gmaxwell, I knew about pushtx, I'm just trying to find as an autonomous solution as possible. If sending raw can be done from my machine, that's a prefereable path.
30 2013-06-03 07:42:51 <lianj> dansmith_btc: connecting to the network and sending a tx packet is kinda easy
31 2013-06-03 07:43:43 <dansmith_btc> lianj, yes, you are right
32 2013-06-03 07:46:41 <sipa> well there are other uses for a force sendrawtransaction
33 2013-06-03 07:46:50 <sipa> for example to rebroadcast a tx already in your mempool
34 2013-06-03 08:20:01 <Subo1978> !seen sipa
35 2013-06-03 08:20:02 <gribble> sipa was last seen in #bitcoin-dev 33 minutes and 11 seconds ago: <sipa> for example to rebroadcast a tx already in your mempool
36 2013-06-03 08:25:53 <runeks> So I'm trying to run bitcoind on a Raspberry Pi. And it's all went pretty well so far. But it seems to have stopped at block 225724.
37 2013-06-03 08:26:22 <runeks> After that, debug.log just has a lot of "Flushed <n> addresses to peers.dat 1700ms"
38 2013-06-03 08:26:47 <runeks> And it seems it's trying to connect to peers instead of processing blocks.
39 2013-06-03 08:28:25 <lianj> runeks: which version did you compile?
40 2013-06-03 08:28:43 <runeks> lianj: v0.8.2.2-g09e437b-beta
41 2013-06-03 08:28:53 <runeks> Here's the debug.log in case that's useful: http://runeks.dk/files/debug.log
42 2013-06-03 08:30:05 <lianj> are you still connected to at least one peer? tried to restart it and see if it starts syncing again?
43 2013-06-03 08:31:58 <runeks> lianj: Trying to ask how many connections it has now. It's using 70% CPU and very slow to respond, so it's definitely doing something.
44 2013-06-03 08:32:43 <runeks> lianj: Haven't tried to restart. I haven't dared touch it. But perhaps I should try that.
45 2013-06-03 08:32:46 <lianj> bitcoind getinfo
46 2013-06-03 08:33:03 <lianj> also, you have enough ram + swap space=?
47 2013-06-03 08:33:09 <runeks> I'm doing a getconnectioncount but it's still waiting.
48 2013-06-03 08:33:27 <runeks> lianj: I have 145420 KB of free RAM
49 2013-06-03 08:33:41 <runeks> 0.8.2 really has helped with that. It ran out of memory with 0.8.1
50 2013-06-03 08:37:34 <warren> hmm, I have already cloned a copy of bitcoin/bitcoin into wtogami/bitcoin. to update it to master again, do I need to use a command line client to pull and push, or does the web interface have a option to pull from its original origin?
51 2013-06-03 08:38:57 <runeks> warren: AFAIK you need to do it via command line.
52 2013-06-03 08:39:20 <warren> k
53 2013-06-03 08:39:22 <warren> just checking
54 2013-06-03 08:49:00 <warren> hmm, how do I copy a branch from a different git tree into your own?
55 2013-06-03 08:50:36 <warren> oooh, might have figured it out
56 2013-06-03 08:52:34 <lianj> warren: new to git? :)
57 2013-06-03 08:53:04 <warren> lianj: new to advanced git ... features beyond svn in complexity. Loving it!
58 2013-06-03 08:54:40 <warren> lianj: failing at the sleep thing...
59 2013-06-03 08:57:39 <dansmith_btc> I tried signrawtransaction <hex> <txid,vout,scriptPubkey> <priv key> both on a synced and an UNsynced bitcoind. It didn't work on the UNsynced one. So, what info is the UNsynced bitcoind lacking in order to sign?
60 2013-06-03 09:06:52 <sipa> warren: i guess the secp256k1 gitian stuff doesn't work for win32?
61 2013-06-03 09:07:04 <sipa> right, it only touches gitian.yml, so indeed
62 2013-06-03 09:07:06 <sipa> still, thanks!
63 2013-06-03 09:07:18 <warren> Anyone know how to do root commands within gitian? I shelled in using "on-target". I don't know how it configures the sudo or su password.
64 2013-06-03 09:07:59 <warren> sipa: I think I can make win32 work
65 2013-06-03 09:08:03 <warren> sipa: poking at it
66 2013-06-03 09:08:25 <warren> sipa: any idea how to do sudo or su commands in gitian's on-target?
67 2013-06-03 09:08:26 <randy-waterhouse> any way to disconnect from a misbehaving node without stopping and starting bitcoind?
68 2013-06-03 09:08:43 <warren> randy-waterhouse: iptables block the IP
69 2013-06-03 09:09:17 <randy-waterhouse> yeah, i was hoping for bitcoind command
70 2013-06-03 09:10:55 <warren> randy-waterhouse: I wonder if addnode=IP remove would work
71 2013-06-03 09:10:59 <warren> RPC
72 2013-06-03 09:11:46 <randy-waterhouse> hmmm might do, thnx
73 2013-06-03 09:11:52 <warren> sipa: I can figure this out, but I'm stuck with gitian ...
74 2013-06-03 09:13:13 <warren> hah, that was easier than expected
75 2013-06-03 09:13:20 <warren> on-target --user root
76 2013-06-03 09:13:26 <warren> which does not match the documentation ...
77 2013-06-03 09:16:47 <randy-waterhouse> ./bitcoind addnode 68.11.136.208 remove error: {"code":-24,"message":"Error: Node has not been added."}
78 2013-06-03 09:17:07 <randy-waterhouse> nope ... might be nice to have ability to boot nodes off on the fly
79 2013-06-03 09:18:42 <warren> I agree, I'd like that
80 2013-06-03 09:18:54 <warren> randy-waterhouse: what if you add then remove?
81 2013-06-03 09:19:35 <randy-waterhouse> i think it is just for the addnode list that is referenced at start-up from bitcoin.conf isn't it?
82 2013-06-03 09:20:06 <warren> addnode also connects to something immediately, I think.
83 2013-06-03 09:20:19 <randy-waterhouse> ok .. didn't know that
84 2013-06-03 09:23:17 <sipa> warren: hmm, why do you compile gmp from source, instead of just depending on libgmp-dev?
85 2013-06-03 09:23:38 <warren> sipa: libgmp-dev is too old in lucid.
86 2013-06-03 09:25:04 <sipa> warren: that's a serious problem
87 2013-06-03 09:25:17 <sipa> as it means the compiled binary will not work on lucid...?
88 2013-06-03 09:25:40 <warren> oh? I thought everything linked in gitian was static?
89 2013-06-03 09:25:47 <warren> ACTION looks at my own build
90 2013-06-03 09:26:39 <sipa> ah, could be!
91 2013-06-03 09:27:07 <warren> sipa: crap. you're right.
92 2013-06-03 09:27:07 <warren> sipa: ok, I need to rework that gmp in gitian to be static.
93 2013-06-03 09:28:06 <randy-waterhouse> warren: nope ... addnode doesn't appear to disconnect the given node
94 2013-06-03 09:28:26 <warren> randy-waterhouse: addnode add then subsequent remove doesn't?
95 2013-06-03 09:28:37 <randy-waterhouse> right
96 2013-06-03 09:28:44 <warren> addnode remove failing to disconnect is a bug, IMHO
97 2013-06-03 09:29:01 <sipa> ;;genrate 11000
98 2013-06-03 09:29:02 <gribble> The expected generation output, at 11000.0 Mhps, given difficulty of 12153411.7098, is 0.455178497433 BTC per day and 0.0189657707264 BTC per hour.
99 2013-06-03 09:29:03 <warren> randy-waterhouse: file an issue, I think
100 2013-06-03 09:29:16 <randy-waterhouse> well it appears there would be a need for some sort of command than can disconnect a node
101 2013-06-03 09:29:46 <randy-waterhouse> i can optimise my network neighbourhood then ..
102 2013-06-03 09:29:52 <warren> randy-waterhouse: debate in the issue what the command should be. addnode remove seems logical as it already exists (even though it's strange)
103 2013-06-03 09:30:27 <randy-waterhouse> do you know if addnode initiates an immediate connection?
104 2013-06-03 09:30:36 <warren> I thought it did.
105 2013-06-03 09:30:43 <warren> It did here at least a few times
106 2013-06-03 09:31:52 <warren> sipa: fuck...
107 2013-06-03 09:32:25 <warren> sipa: gmp is LGPL. can't static link it while keeping the core "open", if that's a goal...
108 2013-06-03 09:33:12 <sipa> warren: keep the ubuntu gitian build no-GMP perhaps?
109 2013-06-03 09:33:43 <warren> what is the detriment as no-GMP?
110 2013-06-03 09:34:06 <warren> sipa: that means all gitian builds will be slower only for the sake of an ancient Ubuntu version?
111 2013-06-03 09:34:25 <sipa> yes
112 2013-06-03 09:34:40 <sipa> but still significantly faster than openssl
113 2013-06-03 09:35:11 <warren> wouldn't it be better to put newgmp into lucid-backports?
114 2013-06-03 09:35:42 <sipa> i think we should just upgrade the build env and drop lucid support :0
115 2013-06-03 09:35:50 <warren> +1
116 2013-06-03 09:36:16 <warren> I can rewrite gitian to use Fedora as the deterministic env. Latest tools for everything! =)
117 2013-06-03 09:37:41 <warren> sipa: huh... are bitcoin's official win32 and mac binaries static linking qt right now?
118 2013-06-03 09:37:52 <warren> if so, the "open" goal is lost.
119 2013-06-03 09:38:14 <warren> sipa: linux gitian builds are dynamic linking qt at least.
120 2013-06-03 09:38:35 <BlueMatt> hey, its a TD
121 2013-06-03 09:39:09 <warren> ?
122 2013-06-03 09:39:15 <sipa> warren: i don't know enough about licensing issues or static/dynamic builds
123 2013-06-03 09:40:28 <warren> (Politically, I don't care about the "open" goal, LGPL static linked can infect everything else with FREEDOM, but I assumed Bitcoin being licensed the way it is, someone intended it to be "open".)
124 2013-06-03 09:41:22 <TD> hi
125 2013-06-03 09:41:41 <warren> It's as if TD were summoned.
126 2013-06-03 09:43:43 <warren> hmm, I thought mingw32 had yasm in it, but there is none.
127 2013-06-03 09:44:27 <warren> sipa: it seems sticking to max performance for the standard gitian build would be ideal. If you want to use it on an ancient distro, make a gmp backport.
128 2013-06-03 09:44:30 <warren> sipa: not hard
129 2013-06-03 09:46:15 <randy-waterhouse> warren thanks https://github.com/bitcoin/bitcoin/issues/2729
130 2013-06-03 09:47:44 <warren> randy-waterhouse: thanks for filing
131 2013-06-03 09:47:49 <warren> I want this
132 2013-06-03 09:53:42 <warren> sipa: oh btw, I have a mac friend that thinks he can figure out mac deterministic builds.
133 2013-06-03 09:53:56 <sipa> in a gitian VM?
134 2013-06-03 09:54:04 <warren> sipa: I wonder if we can make a bounty for that
135 2013-06-03 09:54:06 <sipa> legally?
136 2013-06-03 09:54:18 <warren> it wouldn't be gitian
137 2013-06-03 09:54:46 <sipa> well without *some* VM at some level, you won't get determinstic builds
138 2013-06-03 09:55:05 <warren> one mode of gitian itself uses no VM
139 2013-06-03 09:55:34 <warren> I'm not sure how he intends on doing this.
140 2013-06-03 09:56:05 <warren> The goal is "the exact same binary built from the exact same source, no matter who builds it" right?
141 2013-06-03 09:56:15 <warren> So does it matter how it achieves that goal?
142 2013-06-03 09:56:38 <nsh> how affects whether
143 2013-06-03 09:57:38 <BlueMatt> warren: talk to Luke-Jr and mikeperry from tor
144 2013-06-03 09:57:45 <BlueMatt> they are working on in-gitian mac deterministic builds
145 2013-06-03 09:58:06 <BlueMatt> at least for tor, we'll see if we can re-use it in bitcoin
146 2013-06-03 09:58:07 <warren> hmm, what kind of VM can they run in mac, that would contain mac build tools?
147 2013-06-03 09:58:09 <BlueMatt> (its cross-compiled)
148 2013-06-03 09:58:29 <BlueMatt> some project which pulls out apple's public source patches and compiled them into a xcompiler
149 2013-06-03 09:58:42 <BlueMatt> (linux vm)
150 2013-06-03 09:58:49 <warren> I personally don't see why you necessarily need a VM for this.
151 2013-06-03 09:58:58 <BlueMatt> neither do I
152 2013-06-03 09:59:10 <BlueMatt> as long as it runs in linux, everyone can run it
153 2013-06-03 09:59:56 <warren> I mean, mac tools to build a standard mac build environment, which you in turn use to build the deterministic mac bitcoin binary
154 2013-06-03 09:59:58 <warren> no VM needed
155 2013-06-03 10:00:14 <BlueMatt> yes, but if it requires a mac, we'll get like...1 developer building?
156 2013-06-03 10:00:15 <BlueMatt> maybe 2
157 2013-06-03 10:00:28 <warren> that's all you have now anyway, Gavin
158 2013-06-03 10:00:34 <BlueMatt> no its not
159 2013-06-03 10:00:34 <warren> my friend is a mac dev wizard
160 2013-06-03 10:00:52 <BlueMatt> for win/linux we get at least 3 per version (or will get...)
161 2013-06-03 10:00:57 <warren> (he also wants to do OpenBSD port official)
162 2013-06-03 10:01:04 <BlueMatt> if we're gonna redo mac builds to be deterministic, we should target at least that
163 2013-06-03 10:01:09 <BlueMatt> which means...compile in linux
164 2013-06-03 10:01:18 <warren> hm
165 2013-06-03 10:01:37 <warren> I suppose it's hilarious enough that the win32 builds are in linux, and win32 builds on windows are unsupported.
166 2013-06-03 10:01:56 <BlueMatt> why would we support windows building?
167 2013-06-03 10:01:59 <BlueMatt> windows is a mess
168 2013-06-03 10:02:03 <buZz> windows should be unsupported anyway, just stop supporting microsoft
169 2013-06-03 10:02:11 <warren> =)
170 2013-06-03 10:02:23 <BlueMatt> we have enough users we have to provide binaries, but building things in windows....noooo
171 2013-06-03 10:02:24 <buZz> 'here is a binary but you will need to buy this 120 usd cd to run it!'
172 2013-06-03 10:02:54 <lianj> buZz: thats the spirit
173 2013-06-03 10:03:02 <warren> mac-hosted deterministic build, you have 2 people capable now? I can be a third.
174 2013-06-03 10:03:21 <kinlo> BlueMatt: I could provide mac builds, gavin too, if we find one more person...
175 2013-06-03 10:03:52 <kinlo> anyway, we need something to cross-build so it can be done using gitian
176 2013-06-03 10:03:55 <BlueMatt> no offense, but I meant >=3 people who are "trusted" devs...I suppose y'all may qualify for that, but for gitian its essentially people who've been around for 2 years as active devs
177 2013-06-03 10:04:01 <warren> BlueMatt: unlike windows, mac devs are more numerous here and actually care about the platform being supported well
178 2013-06-03 10:04:21 <BlueMatt> I have no doubt you can find 100 people to run the builds, which I suppose would be just as good
179 2013-06-03 10:04:25 <lianj> BlueMatt: was just about to mention that. thanks
180 2013-06-03 10:04:28 <BlueMatt> still...having 3 build systems seems like a pain
181 2013-06-03 10:04:28 <warren> it would
182 2013-06-03 10:04:39 <BlueMatt> would be nice to have gitian and thats it
183 2013-06-03 10:04:39 <warren> nah, two build systems
184 2013-06-03 10:04:45 <warren> gitian linux, gitian win32, mac
185 2013-06-03 10:04:48 <BlueMatt> plus because it apparently is entirely possible to xcompile in gitian...
186 2013-06-03 10:05:05 <BlueMatt> (mikeperry got firefox to xcompile, so if he can do that, we can get bitcoin)
187 2013-06-03 10:05:34 <kinlo> BlueMatt: well, gitian also works with "less" trusted users, and I've been around for 2 years :)
188 2013-06-03 10:05:35 <warren> also .... the linux builds in gitian aren't functionally equivalent to native builds ... seems to have nicer GNOME 3 notifications of some type with my native builds. Not sure how I could make that happen in gitian.
189 2013-06-03 10:06:37 <BlueMatt> kinlo: yes, just means you need 100 of them :p anyway, I just kinda want to make builds possible for /everyone/ and that means gitian or other linux run
190 2013-06-03 10:06:52 <BlueMatt> warren: possibly due to linking old libs...dunno...
191 2013-06-03 10:07:05 <warren> yes.... can we get rid of lucid? please?
192 2013-06-03 10:07:20 <kinlo> BlueMatt: I fully agree there, we should get mac building underway... I've quickly looked at it, but atm it doesn't seem to be that easy
193 2013-06-03 10:07:48 <kinlo> BlueMatt: don't know where you've found documentation to crosscompile to mac, but everything I find is outdated :/
194 2013-06-03 10:08:17 <kinlo> as in too old to build something usefull for modern mac systems
195 2013-06-03 10:08:20 <warren> challenge: make deterministic cross-compile in gitian the same output as the deterministic mac build =)
196 2013-06-03 10:09:20 <BlueMatt> kinlo: yes, you need to ping mikepeery at tor and/or Luke-Jr and the guy who wrote the xcompiler that is being used...
197 2013-06-03 10:09:49 <BlueMatt> kinlo: if you are interested in helping, I can forward you the emails later
198 2013-06-03 10:10:14 <warren> OK, I guess that's a "no" to deterministic mac native builds?
199 2013-06-03 10:10:16 <kinlo> BlueMatt: perhaps I can help, I have some knowledge and I have a mac... feel free to email at kinlo@triplemining.com
200 2013-06-03 10:10:36 <BlueMatt> warren: its better than what we have now, I just think we should target gitian if at all possible
201 2013-06-03 10:10:54 <BlueMatt> kinlo: I wont remember, but if you email me Ill be sure to forward them when I get around to it...
202 2013-06-03 10:11:19 <warren> either way, I need it both here and for sillycoin
203 2013-06-03 10:11:31 <kinlo> me@bluematt.net ? (if this is correct I'm scary good at remembering email addresses)
204 2013-06-03 10:12:05 <warren> ok, seriously sleeping now...
205 2013-06-03 10:12:11 <warren> sipa: working on win32 sec256kp1 later this week
206 2013-06-03 10:13:21 <t7> use opencl :D
207 2013-06-03 10:15:44 <jonass> BlueMatt does the pulltester has a merge issue? or is there suddenly something wrong in the pull reqs.? https://github.com/bitcoin/bitcoin/pull/2651 https://github.com/bitcoin/bitcoin/pull/2613
208 2013-06-03 10:16:58 <BlueMatt> kinlo: me@bluematt.me
209 2013-06-03 10:17:15 <kinlo> right, thanks :)
210 2013-06-03 10:18:23 <BlueMatt> jonass: I dunno, have you tried rebaseing onto master?
211 2013-06-03 10:24:07 <jonass> BlueMatt no? let me play with it. Just thought because to pull had merge problems?
212 2013-06-03 10:27:03 <BlueMatt> I dunno why it would...
213 2013-06-03 10:28:56 <jonass> Bluematt my fault. Qt5 changes came across...
214 2013-06-03 11:30:14 <funky2> can I send btc out from machine where all incoming ports are closed?
215 2013-06-03 11:38:43 <helo> funky2: sure
216 2013-06-03 11:39:20 <helo> funky2: you just won't be available to be a 'syncing' node for others
217 2013-06-03 11:45:29 <funky2> helo so say person a sends me coins, chain knows about it, i can send them to person b without sync?
218 2013-06-03 11:51:19 <Ry4an> funky2: in absolute sense, definitely. The client you're using to send them may or may not let you, but it's a valid transaction.
219 2013-06-03 11:54:04 <helo> funky2: you will be able to get synched without incoming connections, you just won't be able to help others sync
220 2013-06-03 12:03:02 <funky2> thanks
221 2013-06-03 13:53:51 <runeks> Anyone here running bitcoind on an Amazon EC2 micro instance?
222 2013-06-03 13:54:58 <maaku> micro instances can be a bitch because of cpu-stealing
223 2013-06-03 13:56:08 <runeks> But they're free for one year :)
224 2013-06-03 13:56:11 <runeks> That's a big plus.
225 2013-06-03 13:56:20 <runeks> maaku: What exactly do you mean by "CPU stealing" though?
226 2013-06-03 13:57:10 <maaku> http://www.krenger.ch/blog/amazon-ec2-micro-cpu-performance/
227 2013-06-03 14:04:24 <maaku> there's a reason they're free ;)
228 2013-06-03 14:05:14 <runeks> maaku: So does this matter for bitcoind. It's hardly a CPU muncher.
229 2013-06-03 14:05:21 <runeks> Yeah, and not just free, but free*
230 2013-06-03 14:08:09 <maaku> it's not just cpu - it's pretty much all resources (and bitcoind can consume significant CPU when validating)
231 2013-06-03 14:08:37 <maaku> you can make it work, just don't expect consistent performance
232 2013-06-03 14:13:12 <yubrew> i have bitcoind running on digitalocean $5/mo droplet
233 2013-06-03 14:13:13 <runeks> maaku: That's cool. I'm not going to do demanding work on it.
234 2013-06-03 14:13:35 <yubrew> add swap and it works alright
235 2013-06-03 14:14:00 <runeks> yubrew: How do you do initial sync? Just let it sync and eat up bandwidth, or scp block chain files to it and do a -reindex?
236 2013-06-03 14:14:30 <michagogo> If you already have a trusted node, you can even just copy over the index
237 2013-06-03 14:15:28 <runeks> michagogo: Oh, right. I'll do that I think.
238 2013-06-03 14:16:03 <msvb> Hello folks.
239 2013-06-03 14:16:19 <runeks> Hmm. Although that's ~11GB of data on my 1mbit upload link :\\
240 2013-06-03 14:16:35 <runeks> Only 32 hours.
241 2013-06-03 14:16:58 <michagogo> runeks: [19:12:15] <runeks> yubrew: How do you do initial sync? Just let it sync and eat up bandwidth, or scp block chain files to it and do a -reindex?
242 2013-06-03 14:17:07 <michagogo> runeks: The blockchain files are the big ones
243 2013-06-03 14:17:17 <runeks> Right.
244 2013-06-03 14:17:36 <maaku> runeks: sync with an ec2 hosted node
245 2013-06-03 14:17:49 <runeks> maaku: What do you mean?
246 2013-06-03 14:18:03 <runeks> How do I find one?
247 2013-06-03 14:18:14 <maaku> by IP, or by asking around
248 2013-06-03 14:18:26 <runeks> Anyone have an EC2 bitcoind node I can sync from?
249 2013-06-03 14:18:41 <runeks> maaku: Is the traffic free if it's EC2 instance to EC2 instance?
250 2013-06-03 14:18:50 <maaku> it's much, much cheaper
251 2013-06-03 14:18:56 <yubrew> michagogo let it eat up bandwidth
252 2013-06-03 14:19:10 <michagogo> yubrew: I wasn
253 2013-06-03 14:19:12 <michagogo> 't asking
254 2013-06-03 14:19:14 <yubrew> i guess i could ftp the file over or something like that
255 2013-06-03 14:19:40 <yubrew> oh oops haha sry
256 2013-06-03 14:20:49 <yubrew> ec2 to ec2 seems like a much better solution
257 2013-06-03 14:24:01 <runeks> So how angry would Amazon get if I portscan my machine's IP/16 for instances listening on port 8333?
258 2013-06-03 14:24:58 <gonffen> what if you just check blockchain.info's peer list?
259 2013-06-03 14:25:09 <runeks> gonffen: Good idea!
260 2013-06-03 14:26:45 <runeks> gonffen: You're a genius! There are plenty.
261 2013-06-03 14:26:48 <maaku> or `dig dnsseed.bluematt.me` until you hit one in amazon's IP range
262 2013-06-03 14:29:28 <ThomasV> maaku: patricia tree is implemented in storage.py, see add_address() and delete_address()
263 2013-06-03 14:44:43 <runeks> Will I get any advantage from connecting to multiple nodes during block sync? I recall reading that only one node is used (or was used) for the initial sync.
264 2013-06-03 14:46:37 <sipa> runeks: no
265 2013-06-03 14:47:10 <maaku> ThomasV: yes, I saw that after you posted. It matters less whether utxo's are using a trie, as large per-script utxo lists are the exception not the rule
266 2013-06-03 14:47:34 <runeks> sipa: Ok. I guess I'll manage with the 1MB/s I was getting before :)
267 2013-06-03 14:47:58 <sipa> runeks: which is why i don't like throttling solutions at the bandwidth level, as it hurts the receiver a lot
268 2013-06-03 14:48:22 <funky2> when I send coins does standard bitcoind sends IP along or not?
269 2013-06-03 14:48:24 <sipa> runeks: i much more prefer throttling by disconnecting peers that ask too much of you, so they get select a better sync peer
270 2013-06-03 14:48:34 <runeks> sipa: Makes sense. So you'll not appreciate my recent commit :)
271 2013-06-03 14:48:42 <sipa> runeks: at this point, no
272 2013-06-03 14:49:07 <sipa> (i'm not against throttling in general, but because of how sync works right now, i don't think it's the best solution)
273 2013-06-03 14:49:36 <maaku> funky2: no, but don't assume you're anonymous unless you're connected through tor
274 2013-06-03 14:50:13 <sipa> funky2: bitcoin transaction don't _contain_ IP addresses, but that doesn't mean someone can't figure it out
275 2013-06-03 14:50:30 <runeks> sipa: Fair enough. I didn't make it for it to be distributed with bitcoin in any case. I made it cause it's necessary for me to limit bandwidth in my setup. My ADSL line becomes unusable when it's uploading at ~100KB/s, and I think having bitcoind running constantly is more helpful than giving out my full bandwidth at select times.
276 2013-06-03 14:50:53 <sipa> runeks: in that case i'd just advise you to run with -nolisten
277 2013-06-03 14:51:05 <sipa> runeks: it will reduce the peers downloading from you dramatically
278 2013-06-03 14:52:01 <funky2> what is no listen? means u are not acting as synching peer?
279 2013-06-03 14:52:14 <sipa> at some point we'll add support to the P2P protocol for not serving historical blocks (which is necessary for pruned nodes)
280 2013-06-03 14:52:16 <runeks> sipa: But that's not what I want. I want to prevent bitcoind from consuming my entire upload bandwidth. I should probably do some more intelligent QoS'ing, but this is as far as my skills in tc/iptables go currently.
281 2013-06-03 14:52:37 <maaku> runeks: use -nolisten
282 2013-06-03 14:52:47 <maaku> it means others can't connect to you
283 2013-06-03 14:52:57 <sipa> runeks: the right solution would be setting your bitcoind to don't serve historical blocks once a bandwidth limit is reached
284 2013-06-03 14:52:58 <funky2> yumm
285 2013-06-03 14:52:59 <runeks> maaku: I know. How does that help the network if everyone uses that?
286 2013-06-03 14:53:25 <maaku> it doesn't, but if you're not capible of running a full node..
287 2013-06-03 14:53:42 <sipa> runeks: it helps much more than just very very slowly serving peers who need to download it anyway
288 2013-06-03 14:53:47 <runeks> maaku: I am with the bandwidth cap on.
289 2013-06-03 14:53:51 <sipa> it's better for both you and them that they just select another peer
290 2013-06-03 14:54:13 <runeks> sipa: Yeah I can see that. How do I not serve historical blocks?
291 2013-06-03 14:54:22 <sipa> runeks: the P2P protocol doesn't support that right now
292 2013-06-03 14:54:31 <sipa> the best approximation is -nolisten
293 2013-06-03 14:54:37 <BlueMatt> run a thin client...
294 2013-06-03 14:54:40 <runeks> sipa: Ok. I see the issue.
295 2013-06-03 14:54:41 <BlueMatt> s/thin/spv/
296 2013-06-03 14:54:43 <sipa> as almost all block syncing is done by the connecting peer
297 2013-06-03 14:54:59 <sipa> if you advertize yourself as a serving peer, you're just stalling others trying to sync
298 2013-06-03 14:55:13 <runeks> sipa: Yeah, that makes sense. I will use a cap and -nolisten then.
299 2013-06-03 14:55:26 <sipa> but many VPS/hosted environments have tons of bandwidth
300 2013-06-03 14:55:34 <sipa> while mnay home users have very little
301 2013-06-03 14:56:03 <sipa> BlueMatt: he wants to help the network
302 2013-06-03 14:56:33 <runeks> sipa: If I can figure out exactly how much bandwidth/mo the free Amazon EC2 Micro instance has, I'll set the limit to that.
303 2013-06-03 14:57:40 <sipa> is there any way to configure the firewall to randomly disconnect connections instead of throttling them?
304 2013-06-03 14:58:57 <runeks> sipa: What do you mean by "randomly disconnect"?
305 2013-06-03 14:59:19 <BlueMatt> verifying blocks and not listening wont really help all that much...
306 2013-06-03 14:59:24 <sipa> just drop the TCP connection
307 2013-06-03 14:59:29 <sipa> instead of slowing it down
308 2013-06-03 14:59:42 <BlueMatt> its iptables...you can do whatever the hell you can dream up
309 2013-06-03 14:59:53 <runeks> sipa: Right, it can definitely do that, but I'm not sure if it accepts randomness...
310 2013-06-03 15:00:03 <sipa> doesn't even need to be random
311 2013-06-03 15:00:12 <sipa> whatever connection makes you go over the limit, drop it
312 2013-06-03 15:00:31 <runeks> Seems like the free t1.micro instance has 15GB/mo of bandwidth.
313 2013-06-03 15:00:59 <sipa> i'm already at 400 GB of upload after 19 days...
314 2013-06-03 15:01:19 <funky2> lol
315 2013-06-03 15:01:29 <funky2> its costly gb there
316 2013-06-03 15:02:03 <runeks> Yeah. 15GB seems like a lot. But not when you're on a 100mbit link. Or whatever they use.
317 2013-06-03 15:07:45 <funky2> hehe
318 2013-06-03 15:09:52 <funky2> can I somehow make wallet to send coins based on some conditions? say it reads some site api and if dow jones is down 10% it then send coins
319 2013-06-03 15:10:14 <funky2> some kind of digital contracts tied up to independent data
320 2013-06-03 15:16:03 <shesek> funky2, you can send transactions with with the json-rpc API
321 2013-06-03 15:31:00 <runeks> Ok. I figured out the bandwidth quota stuff.
322 2013-06-03 15:33:39 <runeks> Just put this script in /etc/cron.monthly/ and it will limit the monthly bandwidth of Bitcoin connections (source or dest. port == 8333) to 14GB per month: http://pastebin.com/iM71GbjJ
323 2013-06-03 15:34:55 <runeks> Hmm. Except this allows 14GB/mo for *both* to and from port 8333. Need to work on that.
324 2013-06-03 15:37:37 <funky2> how the heck someone hacked instawallet hmm
325 2013-06-03 15:37:51 <funky2> if users use pass phrase its impossible to use wallet dat
326 2013-06-03 15:42:28 <funky2> From what I understand, they don't have access to the private keys on their own servers, but if someone took control of their server and started injecting malicious JS, the private keys could be sniffed.
327 2013-06-03 15:45:32 <ne0futur> runeks: just limiting the number of connections could be enough to scale the bandwidth usage
328 2013-06-03 15:45:57 <runeks> ne0futur: Could be. But it's nice to be on the safe side if you're paying for bandwidth.
329 2013-06-03 15:50:00 <nsh> browser crypto: it's foolproof
330 2013-06-03 15:50:48 <Cylta> hi. Is there a freebsd version of bitcoin-qt satoshi client?
331 2013-06-03 15:51:00 <funky3> nsh: lol means?
332 2013-06-03 15:51:44 <gribble> Error: This url is not on the whitelist.
333 2013-06-03 15:51:44 <nsh> ;;title http://www.matasano.com/articles/javascript-cryptography/
334 2013-06-03 15:51:47 <nsh> eat a dick
335 2013-06-03 15:51:53 <nsh> (Javascript Cryptography Considered Harmful)
336 2013-06-03 15:52:13 <funky3> ACTION I repead this dick is not on the list
337 2013-06-03 15:52:15 <funky3> :P
338 2013-06-03 15:52:18 <nsh> ACTION smiles
339 2013-06-03 15:52:19 <funky3> *repeat
340 2013-06-03 15:53:12 <nsh> synopsis: crypto in the browser gives you all the feeling of security with none of the pesky assurances
341 2013-06-03 15:54:45 <funky3> hackadelic crypto
342 2013-06-03 15:54:49 <nsh> addendum: Nadim Kobeissi got a B in maths last semester
343 2013-06-03 15:58:16 <funky3> can I somehow send ssl api call with wallet password to remote wallett?
344 2013-06-03 16:03:49 <maaku> sipa: is CTxOutCompressor deterministic / well-defined?
345 2013-06-03 16:04:16 <funky3> http://www.coindesk.com/carbonwallet-offers-new-way-to-store-bitcoins/
346 2013-06-03 16:11:48 <runeks> Ok. I totally figured it out.
347 2013-06-03 16:12:07 <runeks> This script will limit the bandwidth to Bitcoin nodes to 14GB: http://pastebin.com/q6NpwDmF
348 2013-06-03 16:12:35 <runeks> So just run it once every month and you should be good for a free Amazon EC2 Micro instance.
349 2013-06-03 16:13:14 <runeks> Make sure to run bitcoind with -nolisten, or it will keep trying to establish connections to Bitcoin nodes, even after the quota is met.
350 2013-06-03 16:14:32 <funky3> tyty
351 2013-06-03 16:16:24 <sipa> maaku: yes
352 2013-06-03 16:16:28 <sipa> maaku: both
353 2013-06-03 17:13:51 <funky2> what is most secure exchange mtgox?
354 2013-06-03 17:14:24 <gdbz> try to hack, see which one is.
355 2013-06-03 17:14:33 <funky2> lol I dunno how to
356 2013-06-03 17:14:46 <gdbz> how can we known witch one is the most secure :p
357 2013-06-03 17:15:04 <gdbz> which*
358 2013-06-03 17:15:18 <funky2> hmm using logic
359 2013-06-03 17:16:00 <gdbz> MtGox is reliable, but bitstamp is also
360 2013-06-03 17:16:19 <funky2> gbbz is there a way for me to send command to hot wallet on remote server with my passphrase via ssl?
361 2013-06-03 17:17:00 <runeks> funky2: What do you want to do exactly?
362 2013-06-03 17:17:19 <Luke-Jr> wumpus: FWIW, rebasing is anti-decentralization
363 2013-06-03 17:17:50 <Luke-Jr> not that it makes merges any less ugly in git ???
364 2013-06-03 17:17:55 <funky2> I am toying with ideas of exchanges security :)
365 2013-06-03 17:18:11 <gdbz> funky2: https://bitbucket.org/nitrous/mtgox-api/overview
366 2013-06-03 17:19:06 <funky2> maybe tonal pass , you have to sing in :D
367 2013-06-03 17:19:07 <funky2> hehe
368 2013-06-03 17:20:27 <funky2> i think if bitcoinica used manual withdrawal they would of been fine
369 2013-06-03 17:20:34 <funky2> I just read about them
370 2013-06-03 17:20:54 <funky2> simply hire people like in the bank to manually process withdrawals
371 2013-06-03 17:21:11 <helo> they lost a huge amount of bitcoin too though
372 2013-06-03 17:22:17 <funky2> helo I am thinking any ways to talk to wallet server can be replicated expect manual
373 2013-06-03 17:37:23 <maaku> etotheipi_: wouldn't scriptPubKeys be stored twice, once in the txindex, once in the utxoindex?
374 2013-06-03 17:38:43 <helo> funky2: i've always thought exchagnes should require signmessage of any transfer requests
375 2013-06-03 17:44:56 <funky2> helo how would that work, person manually sign message ?
376 2013-06-03 17:45:46 <funky2> i had `similar` idea using pgp signature lol
377 2013-06-03 17:46:18 <nsh> ACTION revokes funky2's punctuation privileges
378 2013-06-03 17:48:43 <etotheipi_> maaku: you might have a point
379 2013-06-03 17:49:25 <etotheipi_> maaku: I was thinking that the address tree would be standalone, but of course it would simply be a secondary index that points to the already-present UTXOs in the tx-index
380 2013-06-03 17:49:50 <sipa> that's not necessarily better
381 2013-06-03 17:49:56 <sipa> depending on how you index
382 2013-06-03 17:50:16 <sipa> as txid-indexed UTXOs have a txid:vout index, which is 36 bytes
383 2013-06-03 17:50:23 <sipa> much larger than the average UTXO itself
384 2013-06-03 17:51:12 <sipa> so duplicating the UTXOs in both txid-indexed and script-indexed trees may be both more compact and more efficient
385 2013-06-03 17:51:17 <etotheipi_> sipa: would it be irresponsible to index by 12- or 16-byte TxIDs?
386 2013-06-03 17:51:25 <etotheipi_> the uniqueness will be maintained
387 2013-06-03 17:51:29 <sipa> 16 should be fine, imho
388 2013-06-03 17:52:19 <maaku> sipa: the scriptPubKey -> UTXO index needs the txid:n pairs though, as that's what a wallet uses to make transactions
389 2013-06-03 17:52:39 <sipa> maaku: good point!
390 2013-06-03 17:52:40 <maaku> the question is whether it should be keyed by scriptPubKey or (truncated?) hash(scriptPubKey)
391 2013-06-03 17:52:52 <sipa> hash of the scriptpubkey, imho
392 2013-06-03 17:53:06 <sipa> why would you bother dealing with variable-length data?
393 2013-06-03 17:54:04 <etotheipi_> sipa: because with a level-compressed trie, the length doesn't matter
394 2013-06-03 17:54:24 <etotheipi_> but if you maintain the UTXO scripts in that tree... if you use the raw script... you don't need to store it in the leaf *value*, only the key
395 2013-06-03 17:54:43 <sipa> interesting
396 2013-06-03 17:54:54 <sipa> hadn't thought about it that way
397 2013-06-03 17:55:12 <sipa> so you'd really have a scriptPubKey -> [(txid:n)] map
398 2013-06-03 17:55:19 <sipa> oh
399 2013-06-03 17:55:29 <maaku> yes
400 2013-06-03 17:55:41 <sipa> scriptPubKey -> [(txid:n,amount,fCoinbase,nHeight)]
401 2013-06-03 17:55:45 <sipa> probably
402 2013-06-03 17:55:49 <maaku> well, yes :)
403 2013-06-03 17:55:59 <sipa> yes, that makes sense
404 2013-06-03 17:56:01 <petertodd> etotheipi_: Have you thought about proof size? We don't want a lot of merkle path wasted on trivially different scriptPubKey's
405 2013-06-03 17:56:32 <sipa> petertodd: hmm?
406 2013-06-03 17:56:37 <etotheipi_> petertodd: yes... there's not a lot of overhead keying the tree that way
407 2013-06-03 17:57:10 <maaku> sipa: but unfortunately you need the scriptPubKey for validation too, so it needs to be accessible in the regular txindex too. hence the duplication
408 2013-06-03 17:57:35 <petertodd> sipa, etotheipi_: I should be able to construct a short proof consisting of the txid stuff with a merkle path leading to the block header, and the size of that proof should not depend on the actions of others.
409 2013-06-03 17:57:55 <sipa> for a patricia tree the depth is always limited in any case
410 2013-06-03 17:58:03 <sipa> well, not for variable-length keys...
411 2013-06-03 17:58:10 <petertodd> sipa: Exactly
412 2013-06-03 17:58:37 <sipa> it's still bounded by the script size you choose youself
413 2013-06-03 17:58:40 <maaku> sipa: but it an 'attacker' (what would they be attacking?) couldn't extend the length of the key
414 2013-06-03 17:58:47 <maaku> yes
415 2013-06-03 17:59:51 <petertodd> sipa: Seems undesirable frankly. Consider the case of a bare OP_CHECKMULTISIG where someone could easilly drasticly extend my proof size by creating a scriptPubKey duplicating the first part.
416 2013-06-03 18:00:21 <sipa> petertodd: use P2SH
417 2013-06-03 18:01:46 <sipa> and drastically extend... yes, but it's still bounded by something you choose
418 2013-06-03 18:02:12 <petertodd> sipa: Lovely... Why not just do that tiny extra bit of computation then and compute Hash160(scriptPubKey)?
419 2013-06-03 18:02:33 <petertodd> sipa: I'd hate for us to find out down the road this was a big mistake; just seems to cute to be a good idea.
420 2013-06-03 18:03:21 <sipa> i find the idea of not needing to store the scriptpubkey a second time in full nice
421 2013-06-03 18:03:46 <petertodd> Why do we have to store it twice?
422 2013-06-03 18:03:54 <petertodd> Or do you mean scriptPubKey + hash?
423 2013-06-03 18:03:57 <sipa> because you need the output script
424 2013-06-03 18:04:01 <maaku> petertodd: by manipulating the scriptPubKey to put the hash(pubkey)/p2sh data out front, you can use the data structure to lookup scripts by address, even if there's prefixed OP_DROP messages
425 2013-06-03 18:04:46 <maaku> and you store it twice because there's two indices: one scriptPubKey -> txid:n, and an authenticated version of the usual ultraprune index
426 2013-06-03 18:05:00 <petertodd> maaku: I'm skeptical that's worth it. Remember that we'll eventually use this UTXO stuff for important stuff like fraud proofs, where proof size matters.
427 2013-06-03 18:05:27 <maaku> i am skeptical as well, but i see merits for both
428 2013-06-03 18:05:55 <maaku> proof size can't be arbitrarily extended - it's worse-case a constant factor of the length of the script you choose
429 2013-06-03 18:06:11 <petertodd> The attacker may be chosing the script in the case of someone wanting to mess up a UTXO fraud proof.
430 2013-06-03 18:06:16 <petertodd> *choosing
431 2013-06-03 18:06:20 <sipa> if it were up to me, P2SH would be the only supported way of doing transactions in the first place
432 2013-06-03 18:06:32 <maaku> sipa: agreed
433 2013-06-03 18:06:36 <petertodd> Now they can make them as long as 10k * whatever constant.
434 2013-06-03 18:07:01 <petertodd> Heh, see, I'm skeptical about that too because marking transactions with data is a important use-case for a lot of protocols.
435 2013-06-03 18:07:18 <BlueMatt> kinlo: yea, best bet is to ask Luke-Jr how far they got and mikeperry on #tor-dev on OFTC
436 2013-06-03 18:07:43 <sipa> petertodd: maybe
437 2013-06-03 18:07:49 <sipa> i'm not convinced about that
438 2013-06-03 18:08:00 <etotheipi_> petertodd: the proof size is bounded by your own decision to bound your script sizes... someone who puts a 10 kB script near your branch is not causing you any trouble
439 2013-06-03 18:08:01 <BlueMatt> kinlo: they were working on using https://github.com/javacom/toolchain4 in gitian
440 2013-06-03 18:08:40 <BlueMatt> kinlo: (there is an email thread, but its somewhat long and its a few days stale, so no idea where they actually are in getting it to work)
441 2013-06-03 18:09:12 <BlueMatt> sipa: lets make everything but p2sh non-standard in 0.9
442 2013-06-03 18:09:14 <BlueMatt> or...maybe 1.0
443 2013-06-03 18:09:35 <petertodd> etotheipi_: Again, fraud proof stuff. The attacker creates a bunch of 10kB script txouts, then watches as everyone chokes on the huge proof required.
444 2013-06-03 18:09:54 <petertodd> etotheipi_: Having such a massive difference between normal and worst case seems really bad to me.
445 2013-06-03 18:09:58 <etotheipi_> petertodd: the PATRCIA tree is level compressed...
446 2013-06-03 18:09:58 <maaku> imho p2sh should be the only scriptPubKey... if you want data on the block chain, put it in a scriptSig
447 2013-06-03 18:10:38 <etotheipi_> so that 10 kB minus 25 bytes difference is exactly one hop
448 2013-06-03 18:11:00 <petertodd> etotheipi_: Yes, that's why I said creates a bunch, each with differences down the line.
449 2013-06-03 18:11:44 <petertodd> That's 10k transactions basically, no big deal.
450 2013-06-03 18:11:54 <etotheipi_> petertodd: I see your point, and I might concede to it... but I need to think about it...
451 2013-06-03 18:12:43 <sipa> petertodd: i'm still not convinced about any use case where you actually need to store data in the chain (as opposed to proving that it commits to some piece of data)... but i'm not up-to-date with all the stuff you talk about either
452 2013-06-03 18:13:02 <petertodd> etotheipi_: Again, I'm *really* hesitant to have a ~300x difference in normal to worst case size...
453 2013-06-03 18:13:27 <etotheipi_> petertodd: I understand that concern
454 2013-06-03 18:16:42 <petertodd> sipa: It makes it a lot easier to do auditing in many cases, where OP_CHECKMULTISIG, for example, lets you easily see where funds are even when they're being semi-controlled by others, without requiring extensive communication.
455 2013-06-03 18:16:57 <petertodd> sipa: Of course, that exact example is incompatible with the UTXO stuff I'm advocating. :P
456 2013-06-03 18:17:09 <BlueMatt> ;;seen jgarzik
457 2013-06-03 18:17:09 <gribble> jgarzik was last seen in #bitcoin-dev 2 days, 23 hours, 20 minutes, and 43 seconds ago: <jgarzik> plus writeback scheduling in the OS
458 2013-06-03 18:24:04 <nsh> NSA'd
459 2013-06-03 18:26:55 <Ry4an> I hope that's a home star runner reference.
460 2013-06-03 18:28:50 <nsh> everything is
461 2013-06-03 19:42:13 <B0g4r7> Hi guyz. Why does my bitcoin-qt sometimes become unresponsive and use 100% CPU for tens of seconds at a time?
462 2013-06-03 19:42:28 <Luke-Jr> p2pool?
463 2013-06-03 19:42:48 <B0g4r7> neg
464 2013-06-03 19:43:06 <phantomcircuit> B0g4r7, large wallet?
465 2013-06-03 19:43:07 <B0g4r7> I'm running 0.8.1 on OS X 10.6.8 on a q6600 system with 8GB of ram and an SSD.
466 2013-06-03 19:43:24 <B0g4r7> 259 transactions.
467 2013-06-03 19:43:37 <Luke-Jr> B0g4r7: any kind of poolserver or anything else that would call getblocktemplate?
468 2013-06-03 19:43:39 <phantomcircuit> yes but is there a large number of keys?
469 2013-06-03 19:44:03 <B0g4r7> There may be some things calling getwork of getblocktemplate, come to think of it. Will that do that?
470 2013-06-03 19:44:08 <B0g4r7> or
471 2013-06-03 19:44:32 <B0g4r7> Shouldn't be a ton of keys. A few dozen probably.
472 2013-06-03 19:44:41 <phantomcircuit> lol
473 2013-06-03 19:44:48 <phantomcircuit> ssh root@
474 2013-06-03 19:44:54 <phantomcircuit> Display all 300 possibilities
475 2013-06-03 19:44:58 <MC1984> B0g4r7 processblock
476 2013-06-03 19:44:59 <phantomcircuit> oh god
477 2013-06-03 19:46:45 <sipa> B0g4r7: first of all, what are you doing?
478 2013-06-03 19:47:32 <B0g4r7> Just sending payments.
479 2013-06-03 19:47:38 <B0g4r7> and receiving.
480 2013-06-03 19:47:38 <sipa> not mining?
481 2013-06-03 19:47:46 <sipa> anything using rpc at all?
482 2013-06-03 19:48:39 <B0g4r7> Not really.
483 2013-06-03 19:48:55 <B0g4r7> I think I have some miners calling it tho, failing over to it.
484 2013-06-03 19:48:59 <B0g4r7> Checking on that now.
485 2013-06-03 19:49:02 <sipa> ...
486 2013-06-03 19:49:09 <B0g4r7> There was one for sure.
487 2013-06-03 19:51:03 <BlueMatt> Luke-Jr: what happened to your 0.8.2 sigs?
488 2013-06-03 19:51:07 <BlueMatt> I see none in gitian.sigs
489 2013-06-03 19:51:12 <Luke-Jr> BlueMatt: O.o
490 2013-06-03 19:51:27 <BlueMatt> oh, forgot to reset
491 2013-06-03 19:51:28 <BlueMatt> sorry
492 2013-06-03 20:03:06 <BlueMatt> Luke-Jr: ok, new question, why is the pgp key in contrib/gitian-downloader not the same one you are using to sign?
493 2013-06-03 20:03:23 <Luke-Jr> BlueMatt: it's not?
494 2013-06-03 20:03:49 <BlueMatt> I get gpg: Can't check signature: No public key trying to verify your sig, but I just imported the one there (and already had it)
495 2013-06-03 20:04:03 <Luke-Jr> which one do you have?
496 2013-06-03 20:04:31 <BlueMatt> gpg: key 21F4889F: "Luke Dashjr <luke@dashjr.org>" not changed
497 2013-06-03 20:05:03 <Luke-Jr> ACTION kicks gitian
498 2013-06-03 20:05:09 <Luke-Jr> no idea why it's signing from my old key
499 2013-06-03 20:05:37 <Luke-Jr> devrandom: ^
500 2013-06-03 20:06:27 <BlueMatt> because you specified the wrong key?
501 2013-06-03 20:06:33 <BlueMatt> what is your old key's id?
502 2013-06-03 20:09:25 <Luke-Jr> BlueMatt: D53E9583
503 2013-06-03 20:09:29 <Luke-Jr> BlueMatt: gitian doesn't ask me what key
504 2013-06-03 20:09:43 <sipa> gitian passes the 'signer' argument to gpg
505 2013-06-03 20:09:51 <sipa> to figure out the key to sign with
506 2013-06-03 20:09:54 <sipa> not sure how it works
507 2013-06-03 20:10:03 <sipa> or what it does in case of ambiguity
508 2013-06-03 20:10:32 <BlueMatt> Luke-Jr: I dont see it on any keyservers...
509 2013-06-03 20:10:50 <BlueMatt> meh, whatever, weve got 3...
510 2013-06-03 20:14:28 <Goonie_> Luke-Jr: it would be useful if your "branches.html" would contain sub-versions in the chart. To see e.g. 0.8.2 vs rest.
511 2013-06-03 20:14:55 <BlueMatt> we only sign the setup? I thought we signed bitcoin-qt.exe too?
512 2013-06-03 20:15:18 <sipa> we do, afaik
513 2013-06-03 20:15:22 <Luke-Jr> Goonie_: to show every little version would get cluttered, I think?
514 2013-06-03 20:15:38 <BlueMatt> well, unless gitian signed it, we didnt for 0.8.2
515 2013-06-03 20:15:44 <Luke-Jr> whatever, I can't figure out how to tell GPG to only use my new key with -u
516 2013-06-03 20:15:58 <sipa> BlueMatt: wait, are you talking about the OS signing stuff?
517 2013-06-03 20:16:00 <sipa> or gitian?
518 2013-06-03 20:16:02 <BlueMatt> os
519 2013-06-03 20:16:08 <sipa> only the installer there
520 2013-06-03 20:16:16 <BlueMatt> ok, yea, I was just surprised
521 2013-06-03 20:16:23 <sipa> it'd be very hard to get the inner binary signed by gitian
522 2013-06-03 20:16:29 <sipa> without the key...
523 2013-06-03 20:16:47 <BlueMatt> ahh, yes...
524 2013-06-03 20:16:57 <Luke-Jr> now we just need OS to adopt gitian???
525 2013-06-03 20:17:01 <sipa> the obvious way around would be building the installer outside of gitian, but that slightly defeats the purpose
526 2013-06-03 20:17:13 <Goonie_> BlueMatt: well a .99 could round the number before up, so 0.8.1.99 would be equivalent to 0.8.2
527 2013-06-03 20:17:25 <Goonie_> sorry I meant Luke-Jr
528 2013-06-03 20:17:35 <BlueMatt> sipa: yea
529 2013-06-03 20:17:48 <sipa> ACTION zZzZ
530 2013-06-03 20:18:09 <BlueMatt> official docs on PE format: "Appears to be a signature WORD of some sort"
531 2013-06-03 20:18:10 <Luke-Jr> Goonie_: security.html shows current versions distinct from outdated ones
532 2013-06-03 20:18:19 <BlueMatt> in other words m$ isnt even sure what the hell is in pe anymore...
533 2013-06-03 20:18:26 <Goonie_> Luke-Jr: and sub-versions could also be represented as "sub-pies"
534 2013-06-03 20:18:40 <Luke-Jr> Goonie_: perhaps..
535 2013-06-03 20:18:51 <Luke-Jr> Goonie_: personally, I'd like to sometime redo the chart with time
536 2013-06-03 20:18:58 <Luke-Jr> so we can see how it changes day by day
537 2013-06-03 20:19:51 <Goonie_> why does 0.8.1 count as updated? its outdated now
538 2013-06-03 20:20:29 <sipa> there's no known problems with 0.8.1
539 2013-06-03 20:20:44 <Goonie_> well there is. it implements the old fee rules
540 2013-06-03 20:20:55 <sipa> not a problem to the network
541 2013-06-03 20:21:04 <Luke-Jr> Goonie_: I probably need to update the chart
542 2013-06-03 20:21:09 <Luke-Jr> I think last time was 0.8.2rc :P
543 2013-06-03 20:21:15 <Luke-Jr> and 0.8.1 is current until 0.8.2 final
544 2013-06-03 20:21:22 <Goonie_> but a problem to the user who creates a spend that does not confirm
545 2013-06-03 20:21:31 <sipa> ?
546 2013-06-03 20:21:41 <Luke-Jr> was kinda waiting for the May15 hardfork to take effect, sigh
547 2013-06-03 20:21:55 <sipa> i don't see which direction you mean
548 2013-06-03 20:22:18 <sipa> 0.8.1 and earlier already used 0.0001 as a fee/kb for relaying
549 2013-06-03 20:22:47 <sipa> right, old clients could create dust
550 2013-06-03 20:22:57 <Goonie_> well it is my understanding that 0.8.1 can create dust that will not propagate
551 2013-06-03 20:23:00 <Luke-Jr> and their dust will probably still get mined for some time
552 2013-06-03 20:23:54 <Goonie_> and also there are other clients besides bitcoin-qt. for bitcoin-wallet I need to decide on the right time to upgrade the fee rules
553 2013-06-03 20:24:07 <Goonie_> so a chart for this would be nice
554 2013-06-03 20:24:13 <sipa> Goonie_: how so?
555 2013-06-03 20:24:25 <sipa> except for not creating dust, anything should be fine
556 2013-06-03 20:25:03 <sipa> what fee to advise is harder, i suppose
557 2013-06-03 20:25:40 <Goonie_> sipa: well that's already done by BlueMatt
558 2013-06-03 20:25:58 <Goonie_> (needs to be tested though)
559 2013-06-03 20:26:00 <sipa> how?
560 2013-06-03 20:26:23 <Goonie_> sipa: he has a patch for bitcoinj that implements the new rules
561 2013-06-03 20:26:41 <sipa> i don't mean the minimum fee stuff
562 2013-06-03 20:26:53 <sipa> i don't think the minimum that will be relayed is a good suggestion
563 2013-06-03 20:27:14 <Goonie_> why not?
564 2013-06-03 20:27:17 <sipa> as many clients pay much higher fees by default, against which to compete
565 2013-06-03 20:28:08 <Goonie_> how much fee does bitcoin-qt 0.8.2 pay by default?
566 2013-06-03 20:28:24 <Goonie_> (for a standard ~500 bytes tx)
567 2013-06-03 20:28:24 <sipa> 0.0001 BTC/kB i think
568 2013-06-03 20:28:37 <nsh> ACTION nods
569 2013-06-03 20:29:03 <phantomcircuit> sipa, purple
570 2013-06-03 20:29:12 <sipa> ...?
571 2013-06-03 20:29:19 <phantomcircuit> er
572 2013-06-03 20:29:28 <Goonie_> sipa: but that *is* the minimum that will be relayed
573 2013-06-03 20:29:31 <phantomcircuit> sipa, any suggestions for my patch to improve wallet load times
574 2013-06-03 20:29:53 <sipa> Goonie_: 0.0001 BTC per started kB, i think
575 2013-06-03 20:30:18 <sipa> Goonie_: if it doesn't fit the free relay rules
576 2013-06-03 20:30:25 <Goonie_> sipa: that's exactly what BlueMatt implemented
577 2013-06-03 20:30:43 <Goonie_> sipa: I guess he just mirrored the bitcoin-qt rules
578 2013-06-03 20:30:47 <sipa> right ok
579 2013-06-03 20:31:03 <BlueMatt> to be clear: that is a possible use of the new api, and it is what I recommended bitcoin-wallet use
580 2013-06-03 20:31:03 <sipa> i was talking about determining what a good fee was, based on network activity
581 2013-06-03 20:31:14 <BlueMatt> you can specify lower, and it also implements the new min-relay rules separately
582 2013-06-03 20:31:51 <sipa> phantomcircuit: you can pullreq it, otherwise i'll probably do so if i find some time
583 2013-06-03 20:31:53 <BlueMatt> ACTION -> bed
584 2013-06-03 20:32:14 <sipa> afk
585 2013-06-03 20:32:21 <Goonie_> nite
586 2013-06-03 20:34:27 <nsh> ACTION imagines a world where BlueMatt <- bed
587 2013-06-03 20:34:38 <nsh> (maybe one of those beds that hides in a wall)
588 2013-06-03 20:37:20 <oleganza> i'm comparing libbitcoin and bitcoin-qt and see that in Bitcoin-QT uint256 is not reversed when signing/verifying EC signature, but in libbitcoin hash_digest (std::array<uint8_t, 32> ) is reversed
589 2013-06-03 20:37:34 <oleganza> where can i read more about byte order gimmicks in any of those codebases?
590 2013-06-03 20:38:01 <phantomcircuit> lol wat
591 2013-06-03 20:38:04 <phantomcircuit> 3 seconds
592 2013-06-03 20:38:10 <phantomcircuit> that has to be a record for drive by question
593 2013-06-03 20:38:51 <nsh> hehe
594 2013-06-03 20:39:31 <nsh> maybe it was the spooks. one of the downsides to only having a read access to all the world's communications