1 2013-04-26 00:33:27 <Styles> Hey guys, can I ask some really stupid questions about bitcoin?
2 2013-04-26 00:33:43 <bwen> so you give us the choice?
3 2013-04-26 00:33:46 <Styles> I know there are clients, but I also see references to servers, what's this about? There isn't much info on "bitcoin servers"
4 2013-04-26 00:33:58 <Styles> Meh good point bwen, I know better than that.
5 2013-04-26 00:34:04 <btcluvr> any people in here looking for work. I want to setup a gaming site. Neever some coders to help
6 2013-04-26 00:34:04 <bwen> but I havent answered the first question :(
7 2013-04-26 00:34:05 <etotheipi_> bwen!
8 2013-04-26 00:34:16 <etotheipi_> I've been waiting for you on bitcoin-armory, I didn't know you were here
9 2013-04-26 00:34:20 <Styles> bwen idc! Answer the second :)
10 2013-04-26 00:34:33 <eklass> clients come in 2 flavors. full client which hosts the blockchain and are nodes/servers in the sense you're
11 2013-04-26 00:34:38 <eklass> meaning
12 2013-04-26 00:34:51 <eklass> engrish hard
13 2013-04-26 00:34:52 <bwen> ethotheipi_: what did you do to my fav client? >_<
14 2013-04-26 00:34:59 <etotheipi_> bwen: did you figure out the (?) thing? I updated the code to make it a little more obvious
15 2013-04-26 00:35:07 <eklass> since it's peer-to-peer, there are no "servers" just nodes
16 2013-04-26 00:35:09 <Styles> eklass ok, so the full client... what's the lite?
17 2013-04-26 00:35:14 <Styles> eklass I understand
18 2013-04-26 00:35:21 <eklass> lite is basically an interface to a full client hosted elsewhere
19 2013-04-26 00:35:21 <etotheipi_> bwen: when you click on the (?) it pops up a little informational window. You click it to make it go away
20 2013-04-26 00:35:24 <Styles> I'm more interested in monitoring the current block chain.
21 2013-04-26 00:35:37 <etotheipi_> bwen: but if you don't realize that, it all looks totally frozen
22 2013-04-26 00:35:38 <Styles> I've seen people setup a "bitcoin server" and use RPC to monitor it, but that doesn't seem to scale to well.
23 2013-04-26 00:35:44 <Styles> And how often does the bitcoin protocol change?
24 2013-04-26 00:36:24 <gmaxwell> What does "scale well" mean in this context?
25 2013-04-26 00:36:37 <eklass> you don't have to use a full client if you're just looking to monitor the blockchain. there are libraries around to do that. depends on what you're trying to accomplish
26 2013-04-26 00:36:43 <Styles> Well from my understanding, the server hosts the "wallet" and interacts with it directly.
27 2013-04-26 00:36:54 <Styles> If you had 500 wallets and you were interacting witht hem often, IO might be an issue.
28 2013-04-26 00:37:27 <Styles> I'm more interested in the protocol and I haven't really seen any docs on it :-/
29 2013-04-26 00:37:40 <gmaxwell> In what protocol? The RPC protocol?
30 2013-04-26 00:38:16 <Styles> Well RPC is the method that the bitcoin client allows you to interact with it. But the protocol the clients are using.
31 2013-04-26 00:38:41 <Styles> Sort of ripping apart the public client :p
32 2013-04-26 00:38:58 <gmaxwell> Styles: Because there are no servers bitcoin doesn't just have a protocol, it's a distributed algorithim that all nodes participate in, part of which gets serialized up and sent over the wire. Impletmenting it exactly consistently with other nodes is incredibly important.
33 2013-04-26 00:38:59 <Styles> er well it's oss but w/e (too much coffee today)
34 2013-04-26 00:39:02 <jgarzik> Styles: https://en.bitcoin.it/wiki/Protocol_specification
35 2013-04-26 00:39:20 <Styles> jgarzik perfect, thank you!
36 2013-04-26 00:39:26 <Styles> What bootstrapping does BC use?
37 2013-04-26 00:39:39 <Styles> This site didn't work yesturday btw :-/
38 2013-04-26 00:39:46 <btcluvr> no coders in here, ?????
39 2013-04-26 00:39:53 <jgarzik> Styles: DNS or hardcoded list to obtain initial P2P node addresses
40 2013-04-26 00:39:59 <jgarzik> Styles: then peer exchange
41 2013-04-26 00:40:10 <eklass> Styles i believ eit piggybacks off IRC
42 2013-04-26 00:40:20 <gmaxwell> Styles: you should note that the wiki page there isn't remotely complete.
43 2013-04-26 00:40:20 <Styles> I was reading it use to use IRC but no longer does?
44 2013-04-26 00:40:32 <Styles> gmaxwell yeah :-/
45 2013-04-26 00:40:38 <jgarzik> eklass: no
46 2013-04-26 00:40:42 <jgarzik> Styles: correct
47 2013-04-26 00:40:50 <Styles> Where missing a lot of functionalliity. This just seems like the basic structure of it.
48 2013-04-26 00:41:03 <kanzure> irc was a rather clever bootstrapper originally
49 2013-04-26 00:41:06 <jgarzik> Styles: If you want the full rules, you must read the source code
50 2013-04-26 00:41:07 <eklass> news to me :-\\
51 2013-04-26 00:41:15 <gmaxwell> kanzure: it was a pretty poor one.
52 2013-04-26 00:41:18 <Styles> jgarzik bah I was avoiding that.
53 2013-04-26 00:41:22 <Styles> How often does this change?
54 2013-04-26 00:41:34 <kanzure> gmaxwell: well, he needed something that he didn't have to support
55 2013-04-26 00:41:52 <gmaxwell> Styles: if you have any hesitance at all at reading the code then you'd have no chance of implementing it correctly in any case.
56 2013-04-26 00:42:09 <kanzure> that doesn't sound good, what about just reading the tests instead
57 2013-04-26 00:42:09 <Styles> gmaxwell I have no problem doing it, just wasn't sure if it's already documented.
58 2013-04-26 00:42:17 <Styles> It seems like something that would have happened by now, that's all.
59 2013-04-26 00:42:20 <Styles> Like an RFC
60 2013-04-26 00:42:21 <gmaxwell> kanzure: it made everything dependant on an unreliable centeralized service which could abuse its position to isolated nodes or monitor who was using bitcoin.
61 2013-04-26 00:43:00 <Styles> Yeah standard bootstrapping is DNS
62 2013-04-26 00:43:12 <Styles> A lot of p2p networks depended on 3rd parties to do this.
63 2013-04-26 00:43:41 <kanzure> i'm not going to stir up a debate about whether or not irc is better than dns, both have been compromised in the past
64 2013-04-26 00:43:53 <Styles> kanzure terrible way
65 2013-04-26 00:43:57 <kanzure> what?
66 2013-04-26 00:44:16 <gmaxwell> Styles: There is no RFC protocol with anywhere near the interlocking complexity of Bitcoin, perhaps the closest would be the Opus RFC (which I worked extensively on) and we resolved exactness of specification by including a normative decoder implementation in C in the RFC.
67 2013-04-26 00:44:40 <gmaxwell> kanzure: there is nothing to compare. IRC created a _single_ point of failure, the dnsseed stuff does not.
68 2013-04-26 00:44:50 <Styles> gmaxwell why is it so complex? Just the math behind it?
69 2013-04-26 00:45:16 <Styles> The idea behind p2p is it has no single point of failure. And if bootstrapping is hard, well shit you have a problem.
70 2013-04-26 00:45:29 <kanzure> gmaxwell: you might know something that i don't about dns, but how would you go about doing actually anonymous dns registration?
71 2013-04-26 00:45:37 <gmaxwell> Styles: the fact that all of non-trivial calculations and operations must be performed exactly, if a node permits something it shouldn't or denies something it should then thats an exploitable vulnerablities that causes consensus failure.
72 2013-04-26 00:46:04 <gmaxwell> kanzure: what does anonymous dns registration have to do with anything?
73 2013-04-26 00:46:11 <Styles> gmaxwell alright, makes sense.
74 2013-04-26 00:46:27 <kanzure> well it seems like the initial choices were constrained by that choice of anonymity
75 2013-04-26 00:47:01 <kanzure> actually, screw it, i bet there's some tor/dns things that i'm not aware of
76 2013-04-26 00:47:04 <Styles> kanzure a lot of large p2p networks survived by clients setting up multiple bootstrapping dns servers. Check Gnutella network.
77 2013-04-26 00:47:17 <Styles> kanzure why does anon matter here?
78 2013-04-26 00:47:28 <Styles> Once you get a list of other nodes, cache them, and you never hit the bootstrapper again.
79 2013-04-26 00:47:29 <kanzure> the initial release of bitcoin was from an individual that was trying to remain anonymous
80 2013-04-26 00:47:39 <kanzure> so his bootstrapping decisions were determined in part by this
81 2013-04-26 00:48:06 <kanzure> s/determined/constrained/
82 2013-04-26 00:48:22 <Styles> gmaxwell so this would be slighly intensive to write a monitor for the block chain in another language?
83 2013-04-26 00:48:31 <Styles> My best bet is to just setup bitcoind and use RPC?
84 2013-04-26 00:48:55 <gmaxwell> what kind of monitor? does it have to be reliable? can people get robbed if its wrong and following a fork?
85 2013-04-26 00:49:22 <Styles> gmaxwell Yeah it needs to be as reliable as bitcoind is.
86 2013-04-26 00:49:36 <gmaxwell> Then you should use the rpc.
87 2013-04-26 00:49:54 <Styles> Well RPC doesn't have events, it so what I'd be checking every 30s for changes?
88 2013-04-26 00:50:17 <gmaxwell> Styles: you can use blocknotify for it to tell you when the bestblock has changed.
89 2013-04-26 00:50:35 <Styles> gmaxwell ah, alright awesome.
90 2013-04-26 00:52:26 <saracen> Are there any plans to come up with some proper documentation and test cases for creating your own bitcoin nodes? Like an RFC?
91 2013-04-26 00:52:39 <Styles> saracen yeah that was my question :(
92 2013-04-26 00:52:48 <Styles> Seems like it's slowly being built by a few members here
93 2013-04-26 00:53:21 <Styles> But it also seems like failure to implement one properly would cause mayhem on the network
94 2013-04-26 00:53:28 <saracen> It seems like it's needed, because this reliance on bitcoind makes it quite centralised in a way
95 2013-04-26 00:53:46 <gmaxwell> saracen: The reference software is the documentation. You must immitate its behavior indistiguishably.
96 2013-04-26 00:54:09 <gmaxwell> indistinguishably*
97 2013-04-26 00:54:43 <gmaxwell> If you do not faithfully apply exactly the same rules it applies, permitting no more and no less, then you risk creating a consensus failure if your software is widely used.
98 2013-04-26 00:54:57 <Styles> Plus changes down the line will lead you to have issues.
99 2013-04-26 00:55:29 <vrs> Styles: if it did cause mayhem it would be useful as a cheap dos
100 2013-04-26 00:55:36 <gmaxwell> vrs: Not so.
101 2013-04-26 00:56:10 <gmaxwell> vrs: it only causes 'mayhem' if honest users use the alternative software which is not completely faithful.
102 2013-04-26 00:56:21 <vrs> yes
103 2013-04-26 00:56:42 <saracen> At what point could bitcoind be considered not faithful?
104 2013-04-26 00:56:45 <gmaxwell> You??? an attacker??? running weird software doesn't cause any mayhem.
105 2013-04-26 00:57:03 <vrs> I figured that if the network was easy to break/scramble, people would've done it by now, while new implementors needed to be on the watch to not introduce new points of failure themselves
106 2013-04-26 00:57:36 <gmaxwell> vrs: there is a material difference between software run by users and software run by an attacker.
107 2013-04-26 00:58:01 <Styles> Right
108 2013-04-26 00:58:01 <vrs> yes, but it rules out accidental breaking, doesn't it?
109 2013-04-26 00:58:10 <Styles> The rest of the clients can filter out the bad requeste ect..
110 2013-04-26 00:58:58 <gmaxwell> Bitcoin is a consensus system. All honest nodes must come to exactly the same determination about the state of the blockchain. If they fail to reach a consensus, then the currency turns into two currencies and all bitcoins can be spent twice. You can startup your own nodes that don't join into the global consensus??? but that harms no one but you.
111 2013-04-26 00:59:15 <vrs> yeah.
112 2013-04-26 00:59:22 <gmaxwell> But if you have a bunch of regular users running different software and someone produces a transaction which they disagree on.. thats a disaster.
113 2013-04-26 00:59:57 <vrs> I see your point
114 2013-04-26 01:00:00 <gmaxwell> We're very careful in the reference client to not introduce incompatiblities with past versions except in the form of adding new restrictions and then making sure the vast majority of mining enforces them first.
115 2013-04-26 01:00:08 <gmaxwell> So that old nodes still believe the new consensus.
116 2013-04-26 01:00:35 <saracen> Doesn't this effectively put the bitcoind core developers in complete control of the network?
117 2013-04-26 01:00:55 <Styles> saracen no
118 2013-04-26 01:00:59 <Styles> Anyone can contribute
119 2013-04-26 01:01:07 <gmaxwell> saracen: Of course not??? me writing some software doesn't do anything to make anyone run it.
120 2013-04-26 01:01:11 <vrs> if they change the implementation, it puts them out of sync with the clients that repruduced earlier versions faithfully
121 2013-04-26 01:01:19 <vrs> reproduced*
122 2013-04-26 01:01:35 <saracen> Hmm.
123 2013-04-26 01:02:03 <saracen> In theory, you could say that nobody would run it
124 2013-04-26 01:02:08 <saracen> But in practice, they most likely would.
125 2013-04-26 01:02:13 <gmaxwell> The rules that must be enforced are insanely subtle.. 0.8 in replacing the database layer introduced a potential for inconsistency with old nodes. Weirdness in the oracle bdb database library used for the transaction indexes in old nodes were effectively undisclosed network rules.
126 2013-04-26 01:02:38 <Diablo-D3> fucking oracle :<
127 2013-04-26 01:02:47 <saracen> For example, now, I'm going to say things here that are complete guesses (so feel free to shoot me down)...
128 2013-04-26 01:02:58 <saracen> The changes that forked the chain with the whole database issue
129 2013-04-26 01:03:02 <Diablo-D3> ORACLE, RUINER OF OPEN SOURCE
130 2013-04-26 01:03:19 <gmaxwell> This caused a short term convergence failure which was fixed by gettting a majority of hashpower to manually reject the blockchain fork that wouldn't be accepted by all nodes.
131 2013-04-26 01:03:22 <saracen> Didn't the pools effectively save you? If pools didnt exist, how long would it have taken you to tell everybody mining to use a specific version?
132 2013-04-26 01:03:38 <gmaxwell> saracen: if pools didn't exist there likely would have been no problem.
133 2013-04-26 01:04:00 <gmaxwell> saracen: because the 'weird and not acceptable to most nodes' chain would have had a hashpower minority.
134 2013-04-26 01:04:04 <vrs> when there's a network split, a slight majority in hashpower is enough for one chain to eventually outrun the other
135 2013-04-26 01:04:08 <gmaxwell> and so it would have just naturally died.
136 2013-04-26 01:04:12 <vrs> and rational miners will join that blockchain
137 2013-04-26 01:04:24 <saracen> But how long would that take?
138 2013-04-26 01:04:28 <saracen> To naturally die?
139 2013-04-26 01:04:34 <vrs> probably longer than with manual intervention
140 2013-04-26 01:04:41 <gmaxwell> saracen: it happens all the time??? once or twice a day that there is a losing fork.
141 2013-04-26 01:05:38 <gmaxwell> saracen: would have depended on how split the hashpower was when it happened, at ~50% it would have taken a long time, at the 25% of the network that 0.8 had at the time... it would have very likely happened by the next block.
142 2013-04-26 01:06:26 <gmaxwell> The issue there wasn't just that 0.8 and before disagreed, but that 0.8 had a super majority of hashpower while also having a minority of actual nodes.
143 2013-04-26 01:06:33 <vrs> theoretically you could fork the existing chain with a client that speaks a slightly different protocol and enough people using it
144 2013-04-26 01:06:52 <vrs> but that wouldn't be very different from an altcoin
145 2013-04-26 01:06:53 <Styles> Yes vrs but try getting enough people
146 2013-04-26 01:07:00 <Styles> And eventually it should correct itself
147 2013-04-26 01:07:06 <vrs> exactly
148 2013-04-26 01:07:11 <Styles> So it doesn't matter
149 2013-04-26 01:07:22 <Styles> If the user wants their bitcoins to be worth something, use the correct protocol
150 2013-04-26 01:08:22 <gmaxwell> hah but while an inconsistency exists all the txn on the losing side of it may potentially be reversed..... kinda high stakes.
151 2013-04-26 01:09:01 <saracen> I just wonder what the landscape will look like when there are other nodes written by others, and the share is much greater
152 2013-04-26 01:09:26 <gmaxwell> and it's not like people know their protocol is incorrect.. there are hundreds of rules and they must be just so. E.g. if there is a rule that a script must be <10000 bytes, and you count differently so that you only permit 9999.. then if someone makes a transaction right on the boundary you're forked.
153 2013-04-26 01:09:55 <Styles> gmaxwell no pun intended?
154 2013-04-26 01:09:58 <gmaxwell> saracen: there are other nodes written by others, and the art of testing for conformance is improving over time.
155 2013-04-26 01:10:09 <gmaxwell> Styles: :P
156 2013-04-26 01:10:14 <Styles> wait wait
157 2013-04-26 01:10:18 <Styles> please don't fire me from my job
158 2013-04-26 01:10:57 <Styles> So the best practice is use the bitcoind
159 2013-04-26 01:12:30 <Styles> gmaxwell using pure speculation, sites like MtGox are just using bitcoind and monitoring changes on the block chain
160 2013-04-26 01:12:33 <gmaxwell> Yes, best practice is to use bitcoind. The second best practice is to put whatever you use behind your own current bitcoind "firewall" nodes... so at worst any rule disagreement just causes you to get stuck.
161 2013-04-26 01:12:44 <vrs> talking of alternative implementations, is supernode any good?
162 2013-04-26 01:13:05 <Styles> vrs what?
163 2013-04-26 01:13:10 <gmaxwell> I don't believe any alternatives are actually correct.
164 2013-04-26 01:13:11 <vrs> https://github.com/bitsofproof/supernode
165 2013-04-26 01:13:13 <saracen> gmaxwell: Thank you for answering my questions :)
166 2013-04-26 01:13:30 <gmaxwell> (but they're improving)
167 2013-04-26 01:13:44 <Styles> vrs ah interesting
168 2013-04-26 01:13:49 <gmaxwell> Bitcoinj's fullnode functionality has done the most work on correctness, but there are known inconsistencies still.
169 2013-04-26 01:13:53 <Styles> This is exactly what I was talking about
170 2013-04-26 01:14:02 <gmaxwell> Styles: what is?
171 2013-04-26 01:14:30 <vrs> weren't there issues with big wallet files and stock bitcoind?
172 2013-04-26 01:15:18 <Styles> https://github.com/bitsofproof/supernode
173 2013-04-26 01:15:19 <Styles> this
174 2013-04-26 01:16:10 <saracen> I imagine it depends on how big the wallet file is. I got my up to 3gb, and then it stopped working when I attempted a rescan.
175 2013-04-26 01:16:36 <gmaxwell> vrs: hm? I test with 100,000 addresses. Large numbers of move transactions can slow it down a lot.
176 2013-04-26 01:16:36 <vrs> a 3gb *wallet*?
177 2013-04-26 01:16:54 <gmaxwell> (large meaning tens or hundreds of thousands)
178 2013-04-26 01:17:14 <vrs> ah
179 2013-04-26 01:17:22 <saracen> gmaxwell: Yeah. I added a *lot* of keys.
180 2013-04-26 01:17:25 <saracen> err
181 2013-04-26 01:17:26 <saracen> vrs*
182 2013-04-26 01:17:47 <gmaxwell> saracen: stopped working or was just making progress VERY VERY slowly?
183 2013-04-26 01:18:16 <vrs> saracen, impressive
184 2013-04-26 01:19:05 <saracen> gmaxwell: I never found out. It took me awhile to add that many keys, and then it was either going slow, or not doing anything. Then I fucked everything up by trying to read the file with a BDB library
185 2013-04-26 01:19:10 <gmaxwell> at one point about two years ago I imported every transaction in the network into a wallet... worked okay. Probably wouldn't now. :)
186 2013-04-26 01:19:16 <saracen> Except, I didnt read it, I accidentally saved a blank database over the top of it
187 2013-04-26 01:19:19 <saracen> So then I gave up.
188 2013-04-26 01:19:29 <Styles> gmaxwell can you request every transaction going backwards?
189 2013-04-26 01:19:32 <Styles> Like every block chain?
190 2013-04-26 01:20:09 <gmaxwell> Styles: if you run with a txindex you can use the getrawtransaction call to fetch all the historical transactions. (I'm not quite sure what you're asking)
191 2013-04-26 01:20:24 <vrs> saracen: that evokes an amusing image, I was imagining a literal wallet swollen to the size of several potato bags and a thief trying to drag it away
192 2013-04-26 01:20:28 <Styles> gmaxwell well if I wanted to get a history of the whole network
193 2013-04-26 01:20:28 <vrs> too big to steal
194 2013-04-26 01:21:04 <gmaxwell> Styles: well you can't find out about orphan blocks, since you don't have all of them.
195 2013-04-26 01:21:13 <gmaxwell> and there is no way over the network to fetch them.
196 2013-04-26 01:21:48 <saracen> vrs: Ha. As far as I know, there was no money in the wallet. All the private keys were generated from the blcokchain's transactions.
197 2013-04-26 01:23:22 <gmaxwell> saracen: what, just assuming K had been zero and recovering the private key from each signature?
198 2013-04-26 01:23:22 <Styles> gmaxwell I don't know enough about how bitcoin works to know what an orphan block is (Assuming it's a block that is bad?)
199 2013-04-26 01:23:29 <vrs> hm kind of makes me wish I hadn't deleted my old relay node when bitcoind became too hungry for that small vps
200 2013-04-26 01:23:36 <Styles> btw gmaxwell thank you for all the information so far.
201 2013-04-26 01:23:45 <vrs> lots of vintage orphan blocks from 2011, probably have collector value by now
202 2013-04-26 01:24:03 <gmaxwell> Styles: it's a block that didn't make it into the consensus. Usually they're not bad??? just late.
203 2013-04-26 01:24:18 <Styles> So what ends up happening to it?
204 2013-04-26 01:24:30 <Styles> It gets added to the next or the transaction is rejected and has to be re-preformed?
205 2013-04-26 01:24:54 <gmaxwell> Styles: it's as if it didn't exist, except all nodes that previously accepted it will reintroduce transactions that were in it and fell out of the chain back to the chain as they are able.
206 2013-04-26 01:25:54 <saracen> gmaxwell: Basically, I was interested to see whether anybody had a brainwallet where they decided they'd remember their private key from say, block height 20000, transaction 3
207 2013-04-26 01:26:25 <saracen> I tested a lot, and nobody had. So needless to say, I've now considered it the best private key to use
208 2013-04-26 01:26:57 <gmaxwell> saracen: ... you can not observe all the people that tried the same thing as you without luck. :P
209 2013-04-26 01:27:33 <saracen> :D
210 2013-04-26 01:27:45 <vrs> saracen: I can imagine how you arrived at that 3G wallet
211 2013-04-26 01:28:00 <saracen> vrs: Yeah, I hit the betting game spams
212 2013-04-26 01:28:01 <saracen> :(
213 2013-04-26 01:29:17 <saracen> The ~3 BTC on private key 00000000000000000000000000000000 bothers me.
214 2013-04-26 01:29:44 <saracen> need more zeros
215 2013-04-26 01:29:46 <saracen> But yeah. 0.
216 2013-04-26 01:30:14 <Belxjander> a "null" private key ?
217 2013-04-26 01:30:23 <saracen> Yeah
218 2013-04-26 01:30:27 <Belxjander> so effectively the private key was "taken out" or was entirely null to start with?
219 2013-04-26 01:30:39 <vrs> it would be interesting to find out how memory corruption can affect the key generation and if it constricts the keys space enough, search that space
220 2013-04-26 01:31:33 <vrs> not that corruption is very likely to show up in in that particular part of memory
221 2013-04-26 01:32:12 <gmaxwell> vrs: you can set any word of the privkey to zero and still have way more than enough entropy to make attacking it infesable.
222 2013-04-26 01:33:49 <lianj> saracen: is that even a valid privkey?
223 2013-04-26 01:35:37 <saracen> lianj: No. But there's a weird bug in that you can get bitcoind to add it to your wallet
224 2013-04-26 01:35:42 <saracen> Even though it returns an error
225 2013-04-26 01:36:06 <saracen> I thought it had more bitcoins on it, but its 1.237
226 2013-04-26 01:36:10 <blakangel> i just sent 1btc to that address
227 2013-04-26 01:36:10 <saracen> http://blockchain.info/address/1F1RK4nEQyLgMhpXy4AdqhQ5BuLkDp9u9B
228 2013-04-26 01:37:06 <lianj> saracen: 'had'
229 2013-04-26 01:37:25 <saracen> oh wait
230 2013-04-26 01:37:26 <saracen> thats not the one
231 2013-04-26 01:37:33 <saracen> That's probably private key: 1 or something
232 2013-04-26 01:37:34 <saracen> hmm
233 2013-04-26 01:40:30 <saracen> http://blockchain.info/address/1FYMZEHnszCHKTBdFZ2DLrUuk3dGwYKQxh
234 2013-04-26 01:40:31 <saracen> here we are
235 2013-04-26 01:40:38 <saracen> thats the null priv key
236 2013-04-26 01:42:04 <saracen> If you're going to destroy bitcoins, it's probably the best place to send them
237 2013-04-26 01:43:14 <lianj> how do you know its privkey is zero?
238 2013-04-26 01:45:20 <saracen> lianj: Test for yourself, here's the private key in WIF format: 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAbuatmU
239 2013-04-26 01:45:30 <saracen> https://www.bitaddress.org/
240 2013-04-26 01:45:38 <saracen> You can paste it into the wallet details
241 2013-04-26 01:45:53 <saracen> it will show you the private key in hexadecimal, and the public key address
242 2013-04-26 01:46:11 <saracen> oh
243 2013-04-26 01:46:16 <saracen> it doesnt show it. Hmm
244 2013-04-26 01:46:43 <saracen> You can see that its zero though. I think their JS cant deal with the null key
245 2013-04-26 01:47:10 <gmaxwell> hm? a string of zeros should have a bunch of 1s in base 58.
246 2013-04-26 01:47:50 <lianj> gmaxwell: privkey version + checksum
247 2013-04-26 01:48:08 <saracen> gmaxwell: thats showing base64
248 2013-04-26 01:48:27 <lianj> saracen: ? no
249 2013-04-26 01:49:01 <saracen> Oh, sorry, I thought you meant the base64 display on bitaddress.org
250 2013-04-26 01:49:17 <saracen> Yeah, it's the 80+00000 etc.
251 2013-04-26 01:49:42 <lianj> so the only secret is the pubkey :D funny
252 2013-04-26 01:50:27 <saracen> hah, well, I guess so. But no, its definately the one I pasted the link to earlier
253 2013-04-26 01:53:14 <saracen> I'm off to bed, nn!
254 2013-04-26 01:53:17 <saracen> ACTION &
255 2013-04-26 02:23:15 <BlueMatt> "2031: Google defends the swiveling roof-mounted scanning electron microscopes on its Street View cars, saying they 'don't reveal anything that couldn't be seen by any pedestrian scanning your house with an electron microscope."
256 2013-04-26 02:46:44 <Luke-Jr> BlueMatt: riiiiiiight??? wouldn't they be arrested for stalking? ;)
257 2013-04-26 02:48:50 <etotheipi_> is there any indication in the tx serialization that a script is P2SH? I see there's a version byte that is only for the Base58 serialization
258 2013-04-26 02:49:18 <Luke-Jr> etotheipi_: no, we only thought of that possibility when it was too late
259 2013-04-26 02:49:34 <etotheipi_> Luke-Jr: I just wanted to make sure it's not actually needed, though
260 2013-04-26 02:49:58 <etotheipi_> nodes just know the P2SH template and apply it if they see it
261 2013-04-26 02:50:03 <Luke-Jr> yes
262 2013-04-26 02:53:02 <etotheipi_> Luke-Jr: so there's a four-byte version number on the transactions... I assume we just use that for major protocol changes and increment it
263 2013-04-26 02:53:24 <BlueMatt> unless someone comes up with a killer application (tm) that needs it
264 2013-04-26 02:53:59 <etotheipi_> what I'm really trying to figure out is if I can "safely" use only 4 *bits* to represent it in my serialization
265 2013-04-26 02:54:13 <etotheipi_> hoping we don't go through 15 more tx versions in the near future
266 2013-04-26 02:54:39 <BlueMatt> use 1 bit if its the current default, and 4 bytes if it isnt
267 2013-04-26 02:54:53 <jspilman> varint to the max
268 2013-04-26 02:55:16 <BlueMatt> also, will bitcoin currently accept txn with a different version?
269 2013-04-26 02:56:51 <jspilman> is it possible to build bitcoind in msvc? doesn't look like anyone has tried in a while, and makefile.vc is gone?
270 2013-04-26 02:57:54 <etotheipi_> sounds like we should've given 3 of the header version bytes to the timestamp
271 2013-04-26 02:58:44 <etotheipi_> I'm pretty sure we're not going to get through 256 versions before 2068 or whenever that thing runs out
272 2013-04-26 02:59:40 <diki> hmm
273 2013-04-26 03:00:29 <diki> I have no idea how to deal with numbers like 12.3456 when entered into a text hield in a webpage
274 2013-04-26 03:00:54 <diki> removing the dot and treating it as a whole number * 100000000 would still equal the same number as 123,456
275 2013-04-26 03:01:36 <diki> So I am not sure how to format this for an exchange
276 2013-04-26 03:02:26 <etotheipi_> diki: https://en.bitcoin.it/wiki/Proper_Money_Handling_(JSON-RPC)
277 2013-04-26 03:02:30 <etotheipi_> maybe some clues
278 2013-04-26 03:03:29 <etotheipi_> generally castToFloat(value) * 1e8 , then round
279 2013-04-26 03:03:50 <diki> I thought we used 64bit integers to avoid using double/floats and rounding
280 2013-04-26 03:04:58 <etotheipi_> heh, in Armory I just split on the decimal place then pad the right side to size 8 with zeros
281 2013-04-26 03:05:08 <etotheipi_> the recombine them
282 2013-04-26 03:05:12 <etotheipi_> but that's stupid easy in python
283 2013-04-26 03:05:27 <diki> nah I'm doing this in PHP and storing the data in MySQL
284 2013-04-26 03:06:13 <diki> But I did think of the same thing
285 2013-04-26 03:06:44 <BetwithBTC> Bet with BTC! https://www.satoshi-karoshi.com/?r=10670
286 2013-04-26 03:06:46 <diki> Like if the user entered 12,3, I'd calculate how much I need to pad, then remove the separator and add the zeroes
287 2013-04-26 03:07:48 <etotheipi_> diki: but on the upside. double-precision values apparently, actually have just barely enough mantissa precision to handle the full range of 0 to 21e14
288 2013-04-26 03:08:27 <etotheipi_> I think that's why rounding is okay... because it's going to be exact anyway... you just want to avoid truncation
289 2013-04-26 03:08:40 <diki> I'm not exactly a math person so when you start talking about numbers that have the letter 'e' and a 'mantissa' I kind of stop listening :P
290 2013-04-26 03:08:47 <etotheipi_> diki: haha
291 2013-04-26 03:08:50 <etotheipi_> it's not important
292 2013-04-26 03:09:10 <etotheipi_> bedtime for me
293 2013-04-26 03:09:18 <diki> morning here
294 2013-04-26 03:13:46 <Luke-Jr> etotheipi_: what happens when I set version=0xdeadbeef?
295 2013-04-26 04:15:58 <fwgw4g4g> ?
296 2013-04-26 04:51:42 <Luke-Jr> sigh
297 2013-04-26 04:57:18 <saivann> Luke-Jr : Let's him calm down I guess..
298 2013-04-26 04:57:33 <saivann> Let's let him calm down*
299 2013-04-26 04:58:02 <Luke-Jr> I've already given up trying to reason with him
300 2013-04-26 04:58:13 <saivann> :(
301 2013-04-26 05:00:59 <Luke-Jr> he's obviously not even really reading it
302 2013-04-26 05:01:03 <saivann> It's amazing to see people trying to force us to do things on github..
303 2013-04-26 05:02:49 <saivann> I mean, I try to stay calm and create a constructive environment despite the insults.. but they don't want to hear anything.
304 2013-04-26 05:03:14 <Luke-Jr> obviously there is nothing to discuss - we just need to concede
305 2013-04-26 05:06:24 <saivann> If I wanted Matonis there, I would be unhappy to see someone polluting the issue like that and delay everything again..
306 2013-04-26 05:06:28 <MWNinja> why not speed up the average time per block and lower the reward to maintain the same award rate?
307 2013-04-26 05:06:46 <MWNinja> Once the hash rate is in place from asic then we could get 30 second blocks
308 2013-04-26 05:09:57 <Luke-Jr> MWNinja: there is no benefit to 30 second blocks and a lot of harm
309 2013-04-26 05:11:07 <saivann> This has probably been discussed many times before, but I also wondered the same thing once. Is it due to the increasing number of blocks?
310 2013-04-26 05:11:23 <saivann> s/increasing/increased/
311 2013-04-26 05:11:50 <MWNinja> then how does bitcoin benefit from all the new hash rate being added? How do we utilize the processing power,
312 2013-04-26 05:11:57 <Luke-Jr> saivann: there are a lot of different angles to it
313 2013-04-26 05:12:16 <Luke-Jr> the most obvious being that's 20x more block headers everyone (even light nodes) needs to store
314 2013-04-26 05:12:25 <Luke-Jr> MWNinja: difficulty increases
315 2013-04-26 05:12:46 <MWNinja> we just make it arbitrarily harder to process transactions
316 2013-04-26 05:12:52 <Luke-Jr> there's also the factor of more frequent blocks resulting in more stale blocks, which wastes hashing
317 2013-04-26 05:12:59 <Luke-Jr> MWNinja: precisely
318 2013-04-26 05:13:07 <saivann> MwNinja : The processing power actually increases the security without any change in the protocol, at the very least. And that is very important because the security must increase at the same time than its adoption.
319 2013-04-26 05:13:08 <Luke-Jr> MWNinja: that's the purpose of mining
320 2013-04-26 05:13:17 <MWNinja> storage shouldn't be a concern, lets put the blockchain on peta-scale storage
321 2013-04-26 05:13:37 <Luke-Jr> MWNinja: every full node must store the blockchain. every light node must store block headers.
322 2013-04-26 05:13:51 <saivann> Luke-Jr : I see
323 2013-04-26 05:14:12 <saivann> Thanks for the summary
324 2013-04-26 05:14:34 <Luke-Jr> MWNinja: and again: there is no real benefit to reducing block time below 10 minutes
325 2013-04-26 05:15:06 <saivann> Well, instant transactions I guess. But then again, double-spend detection can become more used I guess
326 2013-04-26 05:15:12 <MWNinja> global instant point of sale for every brick and mortar company on the planet
327 2013-04-26 05:15:33 <MWNinja> big benefit to 30 second irreverible transactions
328 2013-04-26 05:15:36 <Luke-Jr> saivann: fast blocks don't make transactions any faster
329 2013-04-26 05:15:45 <Luke-Jr> MWNinja: but that's not possible
330 2013-04-26 05:15:53 <Luke-Jr> MWNinja: even with 30 second blocks, you'd still need to wait an hour
331 2013-04-26 05:16:08 <saivann> Exactly :-) More weak confirmation == a few strong confirmation
332 2013-04-26 05:17:28 <Luke-Jr> MWNinja: the reason it's 6 confirms is because that's how many are in an hour on average
333 2013-04-26 05:18:14 <MWNinja> right Luke-Jr but its arbitrary, litecoin goes faster
334 2013-04-26 05:18:26 <Luke-Jr> MWNinja: no, it doesn't.
335 2013-04-26 05:19:47 <MWNinja> with 30 second blocks you would get 6 confirms in 3 minutes right?
336 2013-04-26 05:20:04 <MWNinja> or would that not be enough to trust?
337 2013-04-26 05:20:17 <feral> its still only 3 minutes of hashing security
338 2013-04-26 05:20:32 <Luke-Jr> MWNinja: nope
339 2013-04-26 05:20:57 <Luke-Jr> MWNinja: you'd just need 120 blocks to get the same kind of confirmation that bitcoin gives you with 6
340 2013-04-26 05:21:54 <saivann> 30 seconds blocks would just be much easier to revert. And you need 20x the amount of blocks to get the same security.
341 2013-04-26 05:22:34 <MWNinja> well our networks will be 100x faster
342 2013-04-26 05:22:43 <MWNinja> then 1000x faster
343 2013-04-26 05:22:53 <saivann> Instant transactions wouldn't be faster
344 2013-04-26 05:23:24 <MWNinja> mining operations will be mobile too
345 2013-04-26 05:24:00 <Luke-Jr> MWNinja: no, the network would be slower
346 2013-04-26 05:24:13 <Luke-Jr> because you'd bog it down with extra data for no benefit
347 2013-04-26 05:27:35 <saivann> Then, is it possible with current TX priority system to have decent double-spend detection systems for point of sales who requires instant transactions in the future?
348 2013-04-26 05:27:45 <MWNinja> I want to pay with bitcoins everywhere, for everything, globally, universally, and instantly. I think that should be a realistic goal as technology continues to advance at a rapid pace
349 2013-04-26 05:28:45 <Luke-Jr> saivann: you can't detect double spends really
350 2013-04-26 05:29:44 <Luke-Jr> MWNinja: great, but the blockchain today is not capable of that
351 2013-04-26 05:30:02 <saivann> Luke-Jr : I thought it was possible with clients listening for unconfirmed transactions
352 2013-04-26 05:30:05 <MWNinja> right with the current implementation of bitcoin, a merchant Point of sale system will place the risk on either the merchant, or processing company who would have to hold a hot wallet of large value
353 2013-04-26 05:30:25 <Luke-Jr> saivann: it's entirely possible the double-spend is never broadcasted
354 2013-04-26 05:30:36 <MWNinja> I just want to understand the vision and path forward over the next 10 years
355 2013-04-26 05:31:12 <Luke-Jr> MWNinja: I have a summary writeup/proposal for an extension that would allow instant transactions, but it requires trust between friends
356 2013-04-26 05:31:16 <saivann> Luke-Jr : But then, the miner must participate in the attack, am-I right?
357 2013-04-26 05:31:35 <Luke-Jr> saivann: more or less
358 2013-04-26 05:31:42 <Luke-Jr> saivann: but not necessarily
359 2013-04-26 05:32:04 <Luke-Jr> saivann: today, someone could send Eligius a transaction to mine which nobody else finds out about due to the "non-standard" relay rules
360 2013-04-26 05:32:29 <Luke-Jr> (except that Eligius uses GBT and miners could detect it)
361 2013-04-26 05:32:42 <saivann> Luke-Jr : I see, fascinating
362 2013-04-26 05:33:38 <Luke-Jr> saivann: and there are services like Hashpower.com which allow someone to just buy mining power
363 2013-04-26 05:33:55 <Luke-Jr> so they could easily spend 30 BTC to get a good chance at finding the next block
364 2013-04-26 05:34:01 <Luke-Jr> they get the 25 BTC subsidy + double spend
365 2013-04-26 05:34:22 <saivann> In fact, in a perfect world without mining pool where Bitcoin is extremely decentralized, this attack would have too much chances to fail to be worth
366 2013-04-26 05:34:40 <Luke-Jr> perhaps
367 2013-04-26 05:34:58 <saivann> (Except for very large amounts)
368 2013-04-26 05:39:03 <MWNinja> So far the best I can think of is that the merchant system uses a split key, where the customer only holds half the private key and can only spend with the merchant system (or redeemed to another wallet)
369 2013-04-26 05:39:49 <Luke-Jr> MWNinja: https://gist.github.com/luke-jr/5409899
370 2013-04-26 05:44:45 <MWNinja> I saw this little NFC energy harvesting kit at Design West this week, would make a very interesting hardware wallet
371 2013-04-26 05:44:57 <MWNinja> http://www.st.com/web/en/catalog/tools/FM116/SC1444/PF253360
372 2013-04-26 05:45:04 <MWNinja> its super cheap too
373 2013-04-26 07:38:39 <The_Fly> anyone here who has played with the 0mq fork know if it sends all transactions or just those affecting the wallet?
374 2013-04-26 07:38:47 <The_Fly> asking before i peer at source to determine
375 2013-04-26 07:40:19 <The_Fly> CTxMemPool::accept
376 2013-04-26 07:40:22 <The_Fly> so is all right?
377 2013-04-26 07:46:05 <The_Fly> suppose i could add a 0mq send in CWallet::AddToWallet
378 2013-04-26 07:46:40 <The_Fly> or use Scrat's trick of writing to a file for each tx and removing once processed
379 2013-04-26 07:48:43 <The_Fly> hm
380 2013-04-26 07:51:02 <wumpus> The_Fly: a ghetto queue :p
381 2013-04-26 07:51:45 <wumpus> using 0mq is more flexible and performant
382 2013-04-26 07:53:24 <The_Fly> cool :)
383 2013-04-26 07:53:34 <The_Fly> i need to adapt to send on walletnotify though
384 2013-04-26 07:53:58 <The_Fly> and am unsure how to deal with the case where say my transaction processor is down
385 2013-04-26 07:54:18 <The_Fly> in scrats case at least you have the tx hash on disk
386 2013-04-26 07:54:29 <The_Fly> and can process next startup
387 2013-04-26 07:54:59 <The_Fly> (in the case that bitcoind stays up but tx processor dies)
388 2013-04-26 08:01:11 <The_Fly> USE_ZMQ=1 make -f makefile.unix -e PIE=1
389 2013-04-26 08:01:41 <The_Fly> ive merged the 0mq branch with master on the main bitcoin repo, hope it works / passes tests
390 2013-04-26 08:02:54 <wumpus> I'm not sure if 0mq can handle durable queues, ie reliable messenging when one of the endpoints can go offline... may be that you want to use a more full-blown queue, such as rabbitmq
391 2013-04-26 08:03:16 <wumpus> there are adapters between them
392 2013-04-26 08:03:41 <The_Fly> thanks
393 2013-04-26 08:03:55 <The_Fly> so i can take 0mq from bitcoind and sent to rabbitmq?
394 2013-04-26 08:04:14 <wumpus> yes
395 2013-04-26 08:04:28 <The_Fly> which will persist anything that was not ack'd by my database scripts
396 2013-04-26 08:04:43 <The_Fly> and allow me to fetch later
397 2013-04-26 08:04:48 <wumpus> that would be the official, scalable solution, a ghetto queue may well suffice in your case...
398 2013-04-26 08:04:58 <The_Fly> id like something that scales
399 2013-04-26 08:05:03 <The_Fly> or at least to play with it anyway :)
400 2013-04-26 08:05:27 <The_Fly> i may host multiple projects off the one wallet so who knows what traffic will be like
401 2013-04-26 08:06:07 <The_Fly> well, might be a bad plan, i was asking in here about decoupling the p2p stuff from the wallets
402 2013-04-26 08:06:32 <The_Fly> so i could keep private keys on separate boxes, sign transactions and send to the p2p node for transmittion over the network
403 2013-04-26 08:06:57 <The_Fly> but with only a few day's into the codebase im not really equipped to do that atm
404 2013-04-26 08:08:55 <Luke-Jr> anyone ever heard of this? http://www.bitcoinx.org/
405 2013-04-26 08:09:42 <The_Fly> visited the site yesterday
406 2013-04-26 08:16:31 <The_Fly> hrm, prepending USE_ZMQ=1 before make, not sure if... is actually enabling the define
407 2013-04-26 08:19:35 <The_Fly> that seems to be how you do it, but dont see a -DUSE_ZMQ anywhere... hm
408 2013-04-26 08:20:22 <Arnavion> That is for defining things for make
409 2013-04-26 08:20:26 <Arnavion> Not for defining C flags
410 2013-04-26 08:20:35 <Arnavion> For that you use CFLAGS=-DUSE_ZMQ
411 2013-04-26 08:20:56 <The_Fly> yeah i tried that
412 2013-04-26 08:21:00 <The_Fly> still didn't see :S
413 2013-04-26 08:21:06 <The_Fly> he has a ifneq (${USE_ZMQ}, -)
414 2013-04-26 08:21:08 <Luke-Jr> The_Fly: it's supposed to be at the end..
415 2013-04-26 08:21:09 <The_Fly> in the makefile
416 2013-04-26 08:21:20 <Luke-Jr> make -f makefile.unix USE_ZMQ=1
417 2013-04-26 08:21:22 <The_Fly> Luke-Jr: oh, he has it at beginning in the note he posted
418 2013-04-26 08:21:30 <The_Fly> will try that, thanks
419 2013-04-26 08:21:56 <The_Fly> still no see flag
420 2013-04-26 08:21:57 <Arnavion> `USE_ZMQ=1 make` is short-hand for `env USE_ZMQ=1 make` , no?
421 2013-04-26 08:21:59 <The_Fly> *define
422 2013-04-26 08:22:18 <The_Fly> Arnavion: yeah, i thought ${USE_ZMQ} would check the env
423 2013-04-26 08:22:41 <The_Fly> he has a condition and adds to DEFS
424 2013-04-26 08:22:51 <The_Fly> and libs
425 2013-04-26 08:23:09 <The_Fly> https://github.com/fredan/bitcoin/blob/91dad762c75829f913ed7a96fd3fa38dbdb0ccc7/src/makefile.unix
426 2013-04-26 08:23:20 <The_Fly> line 52
427 2013-04-26 08:23:33 <The_Fly> https://github.com/fredan/bitcoin/blob/91dad762c75829f913ed7a96fd3fa38dbdb0ccc7/src/makefile.unix#L52
428 2013-04-26 08:25:27 <The_Fly> or shoul di just change it in the makefile lol
429 2013-04-26 08:25:31 <The_Fly> and be done with it
430 2013-04-26 08:25:47 <The_Fly> just confused as to why he says this in his pull request
431 2013-04-26 08:26:28 <Arnavion> What you were trying should work
432 2013-04-26 08:26:38 <Arnavion> but what Luke-Jr told you to use will definitely work
433 2013-04-26 08:27:59 <The_Fly> yeah, putting it in front works
434 2013-04-26 08:28:11 <The_Fly> i was in wrong branch loll!
435 2013-04-26 08:28:26 <Arnavion> Keyboard, chair, etc.
436 2013-04-26 08:28:26 <The_Fly> and the merge with master did not work
437 2013-04-26 08:28:28 <The_Fly> conflicts
438 2013-04-26 08:29:32 <The_Fly> so if i want wallet notify...
439 2013-04-26 08:29:43 <The_Fly> i could try cherry-picking the commit
440 2013-04-26 08:29:53 <The_Fly> but is doubtful that will work
441 2013-04-26 08:43:48 <Belxjander> does the "bitcoin" software require any special linking attributes beyond needing the "boost" libraries?
442 2013-04-26 08:45:27 <The_Fly> oh, btw conflict between 0mq and bitcoin/master was trivial
443 2013-04-26 08:45:29 <The_Fly> just init.cpp
444 2013-04-26 08:49:52 <The_Fly> now to try and add walletnotify 0mq
445 2013-04-26 08:50:13 <The_Fly> unless that is unnecessary?
446 2013-04-26 08:50:55 <diki> woah 4 blocks in 2 minutes
447 2013-04-26 08:50:59 <diki> someone turned on asic?
448 2013-04-26 08:51:07 <diki> oh, oops that is TRC
449 2013-04-26 10:02:37 <Skami> Help my Wallet has been stuck like this http://imgur.com/5BeNb9i with 145 blocks for 12 hours now >.> Any one? (Yea It's the lastest version)
450 2013-04-26 10:03:25 <fanquake> Skami Can you check your debug.log ?
451 2013-04-26 10:04:05 <Skami> fanquake, what should I find in there?
452 2013-04-26 10:04:36 <nsh> more "information"
453 2013-04-26 10:05:12 <nsh> often when things stop working the way they're intended to, the last few things they sputter out can give some indication of why
454 2013-04-26 10:05:18 <Skami> Where there doesn't seem to be anything weird in there :S
455 2013-04-26 10:06:00 <sipa> Skami: can you put the last 1000 lines or so in some paste site?
456 2013-04-26 10:06:09 <Skami> Oh
457 2013-04-26 10:06:24 <Skami> Yea sure I think I see the issue though
458 2013-04-26 10:06:36 <sipa> please share :)
459 2013-04-26 10:06:53 <Skami> http://pastebin.com/3qWb91Pr
460 2013-04-26 10:06:57 <sipa> staying stuck for 12 hours is not intended behaviour in any case
461 2013-04-26 10:07:26 <sipa> Skami: that's far too little to say anything
462 2013-04-26 10:07:41 <Skami> Ah I thought cause the last line started with () that would have been the issue
463 2013-04-26 10:07:42 <fanquake> Skami what OS?
464 2013-04-26 10:07:48 <Skami> Win 7 x64
465 2013-04-26 10:08:06 <sipa> Skami: that's just truncating
466 2013-04-26 10:08:37 <Skami> http://pastebin.com/gQWKBPAf
467 2013-04-26 10:08:41 <Skami> 1000 Lines >.>
468 2013-04-26 10:09:19 <sipa> InvalidChainFound: invalid block=00000000000000452c2f082ba882796ef6f89024f9d6439067014022fc0c4302 height=233233 work=1080506124902978417718 date=2013-04-26 10:35:41
469 2013-04-26 10:09:47 <sipa> Skami: my guess is your database got corrupted
470 2013-04-26 10:09:51 <fanquake> quite a few of those warning in there
471 2013-04-26 10:10:10 <Skami> >.<, how would I fix that?
472 2013-04-26 10:10:18 <sipa> i can't say more without seeing the initial error that occurred... probably when accepting block 233097
473 2013-04-26 10:10:31 <sipa> Skami: start with the -reindex command line flag
474 2013-04-26 10:10:39 <sipa> it will rebuild the database, which may take a while
475 2013-04-26 10:10:52 <sipa> you can stop and start the client in between (don't pass -reindex when starting again)
476 2013-04-26 10:11:36 <Skami> It will resync everything? ..>
477 2013-04-26 10:11:46 <Skami> Oh just indexing
478 2013-04-26 10:11:47 <Skami> I see
479 2013-04-26 10:12:48 <sipa> it will not download everything again
480 2013-04-26 10:13:42 <bwen> does bitcoin has a roadmap of some sort for version 1.0.0 ? Features that will get in, what will not
481 2013-04-26 10:14:32 <Skami> Thank you sipa, I will let you know if it works out :)
482 2013-04-26 10:14:54 <sipa> Skami: i'm wondering why it happened, and why the client didn't detect it by itself, though
483 2013-04-26 10:15:32 <Skami> Is HDD corruption a possiblity? >.>
484 2013-04-26 10:15:36 <sipa> Skami: yes
485 2013-04-26 10:15:42 <Skami> >.<
486 2013-04-26 10:15:53 <sipa> but i'd expect the client to detect that by itself
487 2013-04-26 10:15:58 <sipa> there are several checksums
488 2013-04-26 10:16:13 <sipa> seeing the actual error would be useful, but i assume it's not in your log anymore
489 2013-04-26 10:16:29 <sipa> it should be around a day ago
490 2013-04-26 10:17:04 <Skami> how can I see when stuff was written in the log?
491 2013-04-26 10:17:10 <sipa> you can't
492 2013-04-26 10:17:22 <sipa> it deliberately doesn't contain timestamps for privacy reasons
493 2013-04-26 10:17:26 <Skami> Ah
494 2013-04-26 10:17:31 <Skami> Was about to say huge design flaw :p
495 2013-04-26 10:17:42 <sipa> but just look for a line InvalidChainFound, with height=233097
496 2013-04-26 10:22:40 <TD> Skami: you can enable timestamps with a flag.
497 2013-04-26 10:22:50 <TD> ACTION thinks the privacy issue of having timestamps is perhaps a bit overblown
498 2013-04-26 10:23:05 <nsh> and with two flags you can enable semaphore
499 2013-04-26 10:23:21 <Skami> I'll keep that in mind, thank you sir.
500 2013-04-26 10:45:58 <Plarkplark_> Hi guys.
501 2013-04-26 10:46:06 <Plarkplark_> got bitcoind running
502 2013-04-26 10:46:07 <Plarkplark_> ThreadRPCServer incorrect password attempt from ::ffff:127.0.0.1
503 2013-04-26 10:46:17 <Plarkplark_> But wont accept password. (user / pass)
504 2013-04-26 10:47:39 <Plarkplark_> (compiled from source)
505 2013-04-26 10:48:44 <Plarkplark_> When browsing there with browser I get NO error in debug - an this in browser: {"result":null,"error":{"code":-32700,"message":"Parse error"},"id":null}
506 2013-04-26 10:52:01 <Plarkplark_> ? :(
507 2013-04-26 10:57:06 <Plarkplark_> ..
508 2013-04-26 11:00:01 <Plarkplark_> [2013-04-26 14:51:50] HTTP request failed: The requested URL returned error: 401
509 2013-04-26 11:00:29 <bwen> Hullo Plarkplark :)
510 2013-04-26 11:05:16 <bwen> plarkplark_: can you start the ./bitcoind started as a daemon ? then try to ./bitcoind help
511 2013-04-26 11:14:26 <Plarkplark_> it's a deamon, yes
512 2013-04-26 11:14:35 <Plarkplark_> nogo, 401 error
513 2013-04-26 11:16:23 <bwen> i'm sorry I wish I could help more, kind of learning all this myself. I didnt have that problem when I installed the .deb. Everything just seemed to work.
514 2013-04-26 11:17:22 <bwen> did you modify the bitcoin.conf?
515 2013-04-26 11:18:34 <Plarkplark_> i compiled it all from source.
516 2013-04-26 11:18:41 <Plarkplark_> as a learning experience
517 2013-04-26 11:18:57 <Plarkplark_> on windows even ;)
518 2013-04-26 11:19:02 <Plarkplark_> mingwg + q
519 2013-04-26 11:19:03 <Plarkplark_> qt
520 2013-04-26 11:19:10 <bwen> did you modify the bitcoin.conf?
521 2013-04-26 11:19:27 <Plarkplark_> in %appdata% (on linux its in .bitcoin) ? no
522 2013-04-26 11:19:35 <bwen> https://en.bitcoin.it/wiki/Running_Bitcoin
523 2013-04-26 11:19:48 <bwen> you need to enable the jsonrpc server... its not on by default
524 2013-04-26 11:20:16 <Plarkplark_> rpcallowip=*
525 2013-04-26 11:20:16 <Plarkplark_> rpcallowip=127.0.0.1
526 2013-04-26 11:20:16 <Plarkplark_> rpcpassword=password
527 2013-04-26 11:20:16 <Plarkplark_> rpcport=9332
528 2013-04-26 11:20:16 <Plarkplark_> rpcuser=user
529 2013-04-26 11:20:17 <Plarkplark_> rpcallowip=*
530 2013-04-26 11:20:17 <Plarkplark_> server=1
531 2013-04-26 11:20:30 <bwen> looks good to me
532 2013-04-26 11:20:54 <Plarkplark_> removed the double rpcallowip - nogo
533 2013-04-26 11:24:12 <bwen> try to remove all rpcallowip
534 2013-04-26 11:24:34 <bwen> I only have rpcport, rpcpassword and rpcuser in my .conf
535 2013-04-26 11:25:13 <Plarkplark_> k
536 2013-04-26 11:25:24 <Plarkplark_> rpcpassword=p
537 2013-04-26 11:25:24 <Plarkplark_> rpcport=9332
538 2013-04-26 11:25:24 <Plarkplark_> rpcuser=u
539 2013-04-26 11:25:24 <Plarkplark_> server=1
540 2013-04-26 11:25:24 <Plarkplark_> THis is it now
541 2013-04-26 11:25:35 <bwen> hey weird, I dont even have server=1
542 2013-04-26 11:25:36 <bwen> :p
543 2013-04-26 11:25:44 <bwen> and it works...
544 2013-04-26 11:25:54 <Plarkplark_> [2013-04-26 15:19:19] HTTP request failed: The requested URL returned error: 401
545 2013-04-26 11:26:20 <Plarkplark_> The debug is not really debug. More verbose +1
546 2013-04-26 11:27:46 <bwen> did you try to just query bitcoind directly on the prompt?
547 2013-04-26 11:28:36 <Plarkplark_> data
548 2013-04-26 11:28:36 <Plarkplark_> i get json daa
549 2013-04-26 11:28:36 <Plarkplark_> on getinfo
550 2013-04-26 11:29:24 <bwen> i'm out of ideas :(
551 2013-04-26 11:29:29 <Plarkplark_> np
552 2013-04-26 11:29:30 <SomeoneWeird> yeah
553 2013-04-26 11:29:32 <SomeoneWeird> and?
554 2013-04-26 11:29:54 <Plarkplark_> I got json data when I run bitcoind.exe getinfo
555 2013-04-26 11:30:05 <SomeoneWeird> what's the problem?
556 2013-04-26 11:30:09 <Plarkplark_> well
557 2013-04-26 11:30:16 <Plarkplark_> Oh sorry
558 2013-04-26 11:30:22 <Plarkplark_> I can't connect on the RPC
559 2013-04-26 11:30:38 <Plarkplark_> ThreadRPCServer incorrect password attempt from 127.0.0.1
560 2013-04-26 11:30:43 <Plarkplark_> ^debug
561 2013-04-26 11:31:20 <Plarkplark_> config is
562 2013-04-26 11:31:21 <Plarkplark_> rpcpassword=p
563 2013-04-26 11:31:21 <Plarkplark_> rpcport=9332
564 2013-04-26 11:31:21 <Plarkplark_> rpcuser=u
565 2013-04-26 11:31:21 <Plarkplark_> server=1
566 2013-04-26 11:35:10 <bwen> plarkplark_: you have a webserver setup right?
567 2013-04-26 11:35:14 <Plarkplark_> no
568 2013-04-26 11:35:24 <Plarkplark_> litecoind does an RPC
569 2013-04-26 11:35:26 <Plarkplark_> api / http
570 2013-04-26 11:35:46 <bwen> because I just tried to access it directly in the browser
571 2013-04-26 11:36:00 <bwen> and I get the same error you do {"result":null,"error":{"code":-32700,"message":"Parse error"},"id":null}
572 2013-04-26 11:36:31 <bwen> but if I use the lil php API I made with curl to post JSON it works as expected
573 2013-04-26 11:37:02 <Plarkplark_> bwen same here
574 2013-04-26 11:37:05 <Plarkplark_> ok
575 2013-04-26 11:37:08 <Plarkplark_> so that output is normal
576 2013-04-26 11:37:14 <Plarkplark_> But my miner won't connect.... weird is that.
577 2013-04-26 11:37:17 <bwen> I believe so
578 2013-04-26 11:37:41 <Plarkplark_> {"result":null,"error":{"code":-32700,"message":"Parse error"},"id":null}
579 2013-04-26 11:37:43 <Plarkplark_> same :)
580 2013-04-26 11:37:49 <bwen> how are you trying to connect to it?
581 2013-04-26 11:37:56 <Plarkplark_> with cgminer
582 2013-04-26 11:39:03 <bwen> maybe you'll have more chance in #bitcoin-mining I have no idea how cgminer connects to bitcoin.. i'm guessing its... properly... so maybe just an error (typo) in username / password
583 2013-04-26 11:39:08 <bwen> or port
584 2013-04-26 11:40:36 <Plarkplark_> Ill check it all again
585 2013-04-26 11:40:38 <Plarkplark_> thanks :)
586 2013-04-26 11:57:12 <Plarkplark_> For fun i'm trying to start a blockchain for some testing. How di I let the genesis mine?
587 2013-04-26 11:57:29 <Plarkplark_> Just point a miner to the only running bitcoind - and a block will be solved on genesis?
588 2013-04-26 12:00:36 <SomeoneWeird> uh, no
589 2013-04-26 12:00:42 <SomeoneWeird> unless you're running a new chain
590 2013-04-26 12:20:53 <alaricsp> I'm interested in men *and* women, but I only like havin sex with the latter.
591 2013-04-26 12:21:11 <nsh> ACTION takes notes
592 2013-04-26 12:21:25 <alaricsp> Whoa, that was for #bitcoin, dammit
593 2013-04-26 12:21:29 <alaricsp> Stoopid laggy ssh connection
594 2013-04-26 12:21:59 <TD> yes, much more on topic there
595 2013-04-26 12:22:00 <TD> :)
596 2013-04-26 12:22:07 <alaricsp> And now it's TOO LATE for it to be FUNNY there! :-(
597 2013-04-26 12:23:13 <SomeoneWeird> lol
598 2013-04-26 12:40:37 <HM2> ACTION sighs