1 2014-09-13 00:10:37 <warren> https://github.com/bitcoin/gitian.sigs something odd is going on with the rc2 directories
2 2014-09-13 00:17:52 <AlSzacrel> Hello! I just discovered issue 1643, and would like to contribute to solving that. So far, I have forked the bitcoin project on Github and then I've written some code that might help alleviate the problem. I've never worked for an open-source project before and I am unsure what I am supposed to be doing next. Could anyone point me in the right direction?
3 2014-09-13 00:19:25 <phantomcircuit> warren, line endings fail
4 2014-09-13 00:23:49 <Guest77961> AlSzacrel, you probably want to start with an easier to solve issue
5 2014-09-13 00:27:13 <AlSzacrel> Guest77961: Why is that? I might well be overlooking something, but I think my code would improve the described issue with the 517 single satoshi inputs.
6 2014-09-13 00:27:52 <AlSzacrel> Probably really low-hanging fruits are hard to come by, somebody would snaffle them up along the way, right? :)
7 2014-09-13 00:30:57 <phantomcircuit_> AlSzacrel, there's a lot of open issues
8 2014-09-13 00:31:05 <phantomcircuit_> im sure one of them is a better candidate
9 2014-09-13 00:31:09 <phantomcircuit_> either way though
10 2014-09-13 00:31:15 <phantomcircuit_> what you need to do is a pull request
11 2014-09-13 00:31:33 <phantomcircuit_> https://help.github.com/articles/using-pull-requests
12 2014-09-13 00:33:55 <AlSzacrel> phantomcircuit_: thanks
13 2014-09-13 00:42:58 <goodbtc> sipa, i have more info about the error: http://pastebin.com/mqc7bUwB
14 2014-09-13 00:43:06 <goodbtc> if this helps
15 2014-09-13 00:46:08 <sipa> goodbtc: i see no error?
16 2014-09-13 00:46:29 <goodbtc> i caanot select the text in the error
17 2014-09-13 00:46:35 <goodbtc> I could try some ss
18 2014-09-13 00:48:40 <sipa> what error are you talking about?
19 2014-09-13 00:52:50 <goodbtc> this error https://pastee.org/57xch
20 2014-09-13 00:53:43 <sipa> AlSzacrel: does this actually remove things from time to time?
21 2014-09-13 00:53:43 <sipa> if so, it seems a cheap but potentially useful improvement to the result
22 2014-09-13 00:59:31 <goodbtc> and some ss: http://i.imgur.com/cC25Bxe.png
23 2014-09-13 00:59:50 <AlSzacrel> @sipa: I would assume that if you have a lot of small inputs you might end up with a non-minimal set of inputs even after 1000 iterations. The issue describes a transaction that added 571 single satoshis to a transaction. From my limited understanding, I think that this patch would have kicked out at least all the single satoshi inputs. It's probably only gonna matter for people with immense numbers of available UTXO
24 2014-09-13 01:00:03 <simoncion> I asked this question in #bitcoin, but Seventoes directed me here.
25 2014-09-13 01:00:12 <simoncion> Is there some reason that bitcoin-qt (0.8.6) shouldn't be able to use a read-only copy of the blockchain that's managed by a bitcoind instance running on another computer?
26 2014-09-13 01:00:17 <simoncion> When I run bitcoin-qt with such a copy netmounted to ~/.bitcoin/blockchain , btc-qt complains that "Error opening block database. Do you want to rebuild the block database now?". Answering "OK" tells me that there was an "Error opening block database".
27 2014-09-13 01:04:04 <simoncion> And, uh, then bitcoin-qt just exits.
28 2014-09-13 01:06:56 <sipa> i seem to have dropped out of the channel for a while and have missed the discusson
29 2014-09-13 01:08:36 <goodbtc> my error: http://pastebin.com/mqc7bUwB + http://i.imgur.com/cC25Bxe.png
30 2014-09-13 01:09:30 <simoncion> sipa: I was wondering if there's a good reason for bitcoin-qt to barf when it has been handed a read-only copy of the blockchain data. I can repeat the details if you're interested.
31 2014-09-13 01:09:45 <simoncion> (The blockchain data is being managed by a running bitcoind instance on another machine.)
32 2014-09-13 01:10:26 <AlSzacrel> ilable UTXO, but it would be very cheap for people with few UTXO to run anyway.
33 2014-09-13 01:10:26 <AlSzacrel> @sipa: I would assume that if you have a very large number of small inputs you might end up with a non-minimal set of inputs even after 1000 iterations. Issue#1643 describes a transaction that had 571 single satoshis added as inputs. From my limited understanding, I think that the patch I suggested would have kicked out at least all the single satoshi inputs. It's probably only gonna matter for people with immense numbers of ava
34 2014-09-13 01:12:52 <sipa_> AlSzacrel: well, thanks for contributing!
35 2014-09-13 01:12:56 <sipa_> the patch looks sane to me
36 2014-09-13 01:15:07 <sipa> i'm not familiar enough with the coin selection code to say whether it will actually help with that particular case
37 2014-09-13 01:16:27 <sipa> as maybe if it accidentally ends up selecting a ton of dust inputs, maybe the target was just reached, and dropping any dust input would not be enough - they would actually need to be replaced with a larger output instead
38 2014-09-13 01:20:39 <phantomc-> >.>
39 2014-09-13 01:20:40 <phantomc-> god damn it freenode
40 2014-09-13 01:21:35 <AlSzacrel> @sipa: Apparently in the described case the other inputs that were selected would have been sufficient, all the 517 satoshis were unnecessary. You are correct though, a "bestSubset" that would just exactly hit the target would oust anything that exceeded the target, and you could still be forced to pay for a lot of dust that way.
41 2014-09-13 01:22:27 <AlSzacrel> @sipa: Will sleep a night on it, perhaps I can improve on it tomorrow. That was fun. :D
42 2014-09-13 01:27:16 <AlSzacrel> @sipa: on the other hand, unless you are trying to make a minuscule payment a bigger UTXO would have a much bigger chance to exceed the target, than the chance that you'd only inputs that inch closer and closer to the target to match it finally without exceeding it. Still think it should work. :)
43 2014-09-13 01:28:26 <sipa> AlSzacrel: your patch wouldn't hurt in any case
44 2014-09-13 01:31:28 <AlSzacrel> sipa: Very glad to hear that, very exciting to me. :)
45 2014-09-13 01:37:02 <phantomcircuit> >.>
46 2014-09-13 01:37:03 <phantomcircuit> <.<
47 2014-09-13 01:40:37 <nickodell> In wallet.cpp:1165, what does adding a CWalletTx to an int64 do?
48 2014-09-13 01:42:29 <nickodell> never mind
49 2014-09-13 01:49:57 <simoncion> Is there some reason that bitcoin-qt (0.8.6) shouldn't be able to use a read-only copy of the blockchain that's managed by a bitcoind instance running on another computer?
50 2014-09-13 01:50:03 <simoncion> When I run bitcoin-qt with such a copy netmounted to ~/.bitcoin/blockchain , btc-qt complains that "Error opening block database. Do you want to rebuild the block database now?". Answering "OK" tells me that there was an "Error opening block database".
51 2014-09-13 01:52:54 <sipa> read only will do weird things
52 2014-09-13 01:53:09 <sipa> you can symlink existing files into your directory, and reindex
53 2014-09-13 01:53:29 <sipa> and then it will share the existing files with the other install, but have separate new ones
54 2014-09-13 01:53:49 <sipa> but it builds its own index files that it needs exclusive access over or things will break
55 2014-09-13 01:55:39 <Luke-Jr> wouldn't "block database" be referring to the LevelDB stuff?
56 2014-09-13 02:00:27 <simoncion> sipa, Luke-Jr blocks and blocks/index are netmounted and read-only. chainstate is local and read-write.
57 2014-09-13 02:00:48 <Luke-Jr> simoncion: well, don't do that.
58 2014-09-13 02:00:57 <sipa> you can't share blicks/index or chainstate
59 2014-09-13 02:01:00 <simoncion> sipa, You're saying that for this to work I should give both bitcoind and bitcoin-qt R/W access to the blockchain data?
60 2014-09-13 02:01:11 <sipa> they are databases that need exclusive readwrite access
61 2014-09-13 02:01:20 <sipa> but yiu can share the individual block files
62 2014-09-13 02:01:28 <simoncion> Oh. So if I also had a local blocks/index, then this would probably work?
63 2014-09-13 02:01:32 <Luke-Jr> simoncion: you can't share the wallet either
64 2014-09-13 02:01:39 <simoncion> Luke-Jr, Yep. I know that.
65 2014-09-13 02:01:57 <Luke-Jr> simoncion: it would "work", but they would append it locally
66 2014-09-13 02:02:04 <simoncion> Luke-Jr, With how often bitcoin-qt corrupts the wallet on shutdown, I wouldn't want to.
67 2014-09-13 02:02:08 <Luke-Jr> at least, I made changes so it "worked" to that extent a year or so ago
68 2014-09-13 02:02:14 <Luke-Jr> simoncion: never? :p
69 2014-09-13 02:02:14 <simoncion> Luke-Jr, you're talking about the wallet?
70 2014-09-13 02:02:22 <Luke-Jr> if your wallet is getting corrupted, you have a bad disk or something
71 2014-09-13 02:02:31 <simoncion> Luke-Jr, I'm sure I don't. :)
72 2014-09-13 02:03:37 <simoncion> Luke-Jr, so to be clear, the notion is that one can netmount blocks read-only, and have a local, read-write blocks/index and chainstate and bitcoin-qt should probably be happy?
73 2014-09-13 02:03:53 <simoncion> Sorry, we got to talking about wallets, too, so I wanna be sure that my understanding of the convo is correct.
74 2014-09-13 02:04:06 <Luke-Jr> just the actual block data, yes
75 2014-09-13 02:04:13 <simoncion> Cool. I'll go off and try that. Thanks!
76 2014-09-13 02:04:16 <Luke-Jr> I don't think we "officially" support it, but it should work
77 2014-09-13 02:04:26 <simoncion> Sure, i'm not looking for a warranty. :)
78 2014-09-13 02:04:43 <Luke-Jr> if you're having problems with the wallet getting corrupt, I suspect you have subtle issues to worry about
79 2014-09-13 02:14:10 <sipa> simoncion: not just local blocks/index; also local _new_ block files
80 2014-09-13 02:14:25 <sipa> bitcoind will write new blocks, and expect them to be where it writes them
81 2014-09-13 02:14:32 <sipa> but you can share preexisting block files
82 2014-09-13 02:15:47 <simoncion> sipa, the idea is for bitcoind to do all of the blockchain handling and for bitcoin-qt to be a remote, graphical frontend that doesn't get to write to the blockchain data, or create *new* blockchain data.
83 2014-09-13 02:18:59 <sipa> simoncion: not possible
84 2014-09-13 02:19:07 <sipa> not with the current design
85 2014-09-13 02:20:37 <gwillen> sipa: could you shut both down periodically, delete the files on one side, and symlink them from the other side?
86 2014-09-13 02:20:58 <gwillen> would this cause massive expense to reindex everything? (or worse, cause it to fail to notice that it needed to?)
87 2014-09-13 02:23:09 <simoncion> sipa, Luke-Jr, Bah. Looks like bitcoin-qt *REQUIRES* that it be able to open blockchain data R/W.
88 2014-09-13 02:23:22 <phantomcircuit> simoncion, you cant do that with readonly files
89 2014-09-13 02:23:22 <simoncion> 2014-09-13 02:20:29 Unable to open file ~/.bitcoin/blocks/blk00000.dat 2014-09-13 02:20:29 Reindexing finished
90 2014-09-13 02:23:44 <simoncion> phantomcircuit, Can't do what?
91 2014-09-13 02:24:16 <phantomcircuit> simoncion, there is movement in the direction of that
92 2014-09-13 02:24:16 <simoncion> Mmm. Would the bitcoin devs support the addition of a set of RPC calls that let a client request blockchain data?
93 2014-09-13 02:24:30 <Luke-Jr> simoncion: â¦
94 2014-09-13 02:24:30 <phantomcircuit> however there is a bunch of groundwok that has to be laid first
95 2014-09-13 02:24:41 <sipa> simoncion: there's no need; the P2P protocol already supports that, and it's much more efficient at it
96 2014-09-13 02:24:43 <simoncion> This would let bitcoind actually act as a blockchain server for local clients, which would be pretty killer.
97 2014-09-13 02:24:54 <Luke-Jr> simoncion: it already does
98 2014-09-13 02:25:18 <sipa> the plan is to split of the wallet node from the blockchain handling part
99 2014-09-13 02:25:30 <sipa> so you'd get what you want for free, i think
100 2014-09-13 02:25:41 <sipa> but it's much more involved than just asking for blockchain data
101 2014-09-13 02:26:00 <sipa> you may not know, but bitcoind hardly _ever_ uses the data in the blockchain itself
102 2014-09-13 02:26:04 <simoncion> sipa, AFAICT, the P2P protocol requires me to either run a "lite" client and trust a digest server, or download the entire blockchain.
103 2014-09-13 02:26:11 <sipa> bingo
104 2014-09-13 02:26:20 <sipa> the wallet would become a lite client to the full node, basically
105 2014-09-13 02:26:41 <sipa> which, if you run it against your own full node (which would happen transparently), you have the same security model as now
106 2014-09-13 02:26:45 <Luke-Jr> simoncion: if you're just requesting blockchain data as needed, you are trusting the server.. inherently
107 2014-09-13 02:26:59 <simoncion> Luke-Jr, Yeah, that's why I would run my own server.
108 2014-09-13 02:27:09 <sipa> yes, it's a very reasonable thing to ask for
109 2014-09-13 02:27:24 <sipa> but the data set that bitcoind manages is much more complex than just block data
110 2014-09-13 02:27:31 <Luke-Jr> simoncion: so you run a full node, then use the p2p protocol to *your* full node, to run the lite client
111 2014-09-13 02:27:31 <sipa> (utxo set, headers, ...)
112 2014-09-13 02:27:55 <simoncion> sipa, but I get the impression that the only thing that bitcoin-qt and bitcoind consult during regular operation is the stuff in chainstate, right?
113 2014-09-13 02:28:06 <simoncion> That's 537MB of data on my bitcoind node.
114 2014-09-13 02:28:09 <sipa> and headers
115 2014-09-13 02:28:27 <simoncion> Where are the headers stored? blocks/index ?
116 2014-09-13 02:28:30 <sipa> yes
117 2014-09-13 02:28:45 <simoncion> That's another 45MB.
118 2014-09-13 02:29:07 <simoncion> So, I would *Very* much rather store 600MB of data on my laptop, than 26GB. :)
119 2014-09-13 02:29:19 <Luke-Jr> simoncion: that's just pruning then
120 2014-09-13 02:29:33 <sipa> which is what you would get if the wallet would be a separate (lite) node
121 2014-09-13 02:29:36 <Luke-Jr> simoncion: and offers nothing over a lite node with a trusted server
122 2014-09-13 02:29:42 <simoncion> Luke-Jr, Does Electrum support talking the lite-protocol to bitcoind? Or is there another client that actually talks to it?
123 2014-09-13 02:29:49 <Luke-Jr> simoncion: no
124 2014-09-13 02:29:52 <simoncion> Or do I have to run electrum-server, too?
125 2014-09-13 02:29:57 <simoncion> No to both?
126 2014-09-13 02:30:13 <Luke-Jr> Bitcoin Wallet for Android does lite-protocol I believe
127 2014-09-13 02:30:14 <sipa> simoncion: multibit or android wallet for android or hive are lite clients that speak the P2P protcol
128 2014-09-13 02:30:18 <simoncion> Luke-Jr, I'm talking about running bitcoind on my LAN. I trust whatever server I'm running. :)
129 2014-09-13 02:32:53 <simoncion> ACTION looks at multibit
130 2014-09-13 02:32:58 <sipa> simoncion: so, with pruning you could have local nodes that have maybe 1GB of local storage only, with the same security model as bitcoind
131 2014-09-13 02:33:11 <sipa> you could connect them to a local node, but there is no real need
132 2014-09-13 02:33:33 <sipa> however, you wouldn't be able to rescan the blockchain in wallets
133 2014-09-13 02:33:52 <simoncion> sipa, but in order to get the pruned data, they need to be bootstrapped with a complete copy of the blockchain, whether they get it from the P2P net or elsewhere, right?
134 2014-09-13 02:34:05 <simoncion> sipa, and you have to rescan every time you add an address?
135 2014-09-13 02:34:09 <sipa> simoncion: yes
136 2014-09-13 02:34:12 <simoncion> to both?
137 2014-09-13 02:34:15 <sipa> yes
138 2014-09-13 02:34:16 <simoncion> k
139 2014-09-13 02:34:34 <sipa> well, if you add an address that was potentially used before
140 2014-09-13 02:34:39 <Luke-Jr> ^
141 2014-09-13 02:34:43 <sipa> if you add a fresh address there is no such need
142 2014-09-13 02:34:44 <Luke-Jr> new addresses don't need a rescan
143 2014-09-13 02:34:56 <phantomcircuit> sipa, getinfo is returning difficulty: 1.0000 but submitting blocks with difficulty=1 results in "Incorrect proof of work"
144 2014-09-13 02:35:04 <Luke-Jr> simoncion: for rescanning, you basically need a non-pruned node
145 2014-09-13 02:35:21 <sipa> phantomcircuit: testnet special 20-minute rule
146 2014-09-13 02:35:25 <Luke-Jr> (for full security)
147 2014-09-13 02:35:32 <sipa> getinfo reports the difficulty of the last block iirc
148 2014-09-13 02:35:38 <phantomcircuit> ah
149 2014-09-13 02:35:50 <phantomcircuit> ok so i'll mangle the timestamps...
150 2014-09-13 02:36:54 <simoncion> Ah, slowly and carefully reading the rpc dox, I see getblockhash(0), and getblock, which I guess could be used to create a BTC client that uses a remote copy of the blockchain?
151 2014-09-13 02:37:37 <sipa> well, but just the blockchain is not what you need
152 2014-09-13 02:38:04 <sipa> but yes i guess
153 2014-09-13 02:38:27 <sipa> you can however do the exact same thing with the p2p protocol, which has getheaders and getdata
154 2014-09-13 02:38:42 <sipa> and you'll even get live announcements of new blocks and transactions
155 2014-09-13 02:38:51 <sipa> so you wouldn't need to poll all the time
156 2014-09-13 02:39:09 <sipa> in fact, the p2p protocol handling is optimized to that
157 2014-09-13 02:41:51 <jgarzik> Indeed. Drives me crazy to see these Poll-RPC solutions...
158 2014-09-13 02:41:53 <simoncion> I assume that the p2p protocol isn't in bitcoin 0.8?
159 2014-09-13 02:41:57 <sipa> ...
160 2014-09-13 02:42:06 <sipa> the p2p protocol is what bitcoin nodes use to talk to eachother
161 2014-09-13 02:42:10 <jgarzik> simoncion, the p2p protocol _is_ bitcoin.
162 2014-09-13 02:42:54 <simoncion> Mm, I thought so.
163 2014-09-13 02:43:52 <Luke-Jr> simoncion: why do you think you want to use 0.8 anyway?
164 2014-09-13 02:44:23 <simoncion> Luke-Jr, because it's what I currently have installed?
165 2014-09-13 02:44:59 <simoncion> So, I guess I should refine my question.
166 2014-09-13 02:45:10 <phantomcircuit> sipa, ffs someone is setting testnet blocks to like 1 hour in the future
167 2014-09-13 02:45:26 <simoncion> (Based on the new info that you guys have very graciously provided to me.) :)
168 2014-09-13 02:45:51 <sipa> simoncion: so part of the problem is that the wallet code very strongly relies on having a local blockchain available to query
169 2014-09-13 02:46:09 <simoncion> sipa, Is that going to be fixed any time soon?
170 2014-09-13 02:46:27 <simoncion> Or would patches to add a "remote blockchain" mode of operation be accepted?
171 2014-09-13 02:46:42 <simoncion> Er, let's call it "Blockchain on the LAN"
172 2014-09-13 02:46:43 <robertjw> Is their any issue with running two instances of bitcoind on the same system provided that they each run out of their own datadir?
173 2014-09-13 02:46:48 <sipa> simoncion: i don't think you understand how much work that would be
174 2014-09-13 02:46:55 <simoncion> sipa, That wasn't my question.
175 2014-09-13 02:46:57 <simoncion> :)
176 2014-09-13 02:47:31 <sipa> simoncion: the current plan is to have a mode at some point (within let's say ~months) that makes it function as a light client
177 2014-09-13 02:47:38 <Luke-Jr> simoncion: people are actively working on patches to add a "remote blockchain" mode of operation
178 2014-09-13 02:47:45 <sipa> no; not really
179 2014-09-13 02:47:51 <simoncion> sipa, "it" is bitcoin-qt?
180 2014-09-13 02:47:59 <sipa> light mode is still using a local chain; just one without the full block data
181 2014-09-13 02:48:11 <sipa> simoncion: yes
182 2014-09-13 02:48:39 <sipa> so you would be running a (bitcoind with full chain) + (bitcoin-qt in light mode)
183 2014-09-13 02:49:13 <simoncion> sipa, Could I configure the bitcoin-qt lite to use my bitcoind full as the sole source of its data?
184 2014-09-13 02:49:19 <sipa> yes
185 2014-09-13 02:49:29 <simoncion> Ah! That's exactly what I was looking for. Cool!
186 2014-09-13 02:49:30 <sipa> all of this hypothetically speaking
187 2014-09-13 02:49:38 <simoncion> ee, that sounds bad.
188 2014-09-13 02:49:45 <sipa> none of this actually exists - though steps towards it are being worked on
189 2014-09-13 02:49:59 <simoncion> So, does any stable version of bitcoind exist that will feed data to a bitcoin lite client?
190 2014-09-13 02:50:11 <sipa> yes, each and every release ever
191 2014-09-13 02:50:18 <sipa> as light mode was part of the design from the start
192 2014-09-13 02:50:33 <sipa> and such lite clients exist too
193 2014-09-13 02:50:49 <simoncion> I looked at electrum, but its user docs are pretty... chatty. :)
194 2014-09-13 02:50:50 <sipa> but bitcoin-qt itself today cannot work as lite client; only as server to lite clients
195 2014-09-13 02:51:03 <simoncion> I'll install it then and take a look at its config file.
196 2014-09-13 02:51:06 <sipa> electrum doesn't use the p2p protocol directly; it speaks to its own specialized servers
197 2014-09-13 02:51:09 <simoncion> Ugh.
198 2014-09-13 02:51:19 <simoncion> Oh, so multibit would be a BTC lite client?
199 2014-09-13 02:51:22 <sipa> yes
200 2014-09-13 02:51:29 <simoncion> Cool!
201 2014-09-13 02:51:34 <sipa> (though i can't vouch for its quality)
202 2014-09-13 02:51:40 <simoncion> BTW, thanks *so much* for your patience, guys. :D
203 2014-09-13 02:51:44 <sipa> yw!
204 2014-09-13 02:51:46 <Luke-Jr> last I checked multibit was pretty bad
205 2014-09-13 02:51:53 <Luke-Jr> but that was a while ago
206 2014-09-13 02:52:06 <sipa> i believe multibit is being rewritten, and i've heard good things about the rewrite
207 2014-09-13 02:52:11 <Luke-Jr> cool
208 2014-09-13 03:20:07 <phantomcircuit> sipa, er... walletpassphrase rpc call causes literally all of the encrypted keys in a wallet to be decrypted
209 2014-09-13 03:20:22 <phantomcircuit> seems like it should just be decrypting the master key
210 2014-09-13 03:26:41 <phantomcircuit> sipa, lol
211 2014-09-13 03:26:45 <phantomcircuit> if (key.GetPubKey() != vchPubKey)
212 2014-09-13 03:27:07 <phantomcircuit> gmaxwell,
213 2014-09-13 03:27:08 <phantomcircuit> 1e21c17d (Gregory Maxwell 2014-04-06 00:18:52 -0700 177) if (key.GetPubKey() != vchPubKey)
214 2014-09-13 03:27:12 <phantomcircuit> why you do dis to me
215 2014-09-13 03:35:24 <phantomcircuit> shrug oh well i'll fix this
216 2014-09-13 04:02:09 <Luke-Jr> is 0.9.3 before or after the simplified %d-for-any-number-type change?
217 2014-09-13 04:06:11 <jgarzik> some Satoshi emails are popping up on reddit
218 2014-09-13 04:07:46 <Luke-Jr> jgarzik: #bitcoin ;p
219 2014-09-13 04:09:33 <jgarzik> Well I think "Mike & Gavin should fork bitcoin.git" is on-topic ;p
220 2014-09-13 04:11:23 <Luke-Jr> jgarzik: shrug, I'd say go for it just so we have multiple codebases
221 2014-09-13 04:31:21 <arioBarzan> which is block height/320385 on main-chain? 00000000000000000c06e54c51c91aa306f1d043c05ef36afff446041243babb or 00000000000000001af016dd744624803372985edda587f0bf5d9689118cdae8 ?
222 2014-09-13 06:51:22 <Luke-Jr> sigh.
223 2014-09-13 06:51:34 <Luke-Jr> someone broke my 1stclassmsg patch, and I don't see how to fix it :|
224 2014-09-13 07:01:05 <Aquent> wow, mike hern wants to fork?
225 2014-09-13 07:01:34 <Aquent> well, considered the idea*
226 2014-09-13 07:13:06 <Luke-Jr> Aquent: it's a good idea
227 2014-09-13 07:13:20 <Luke-Jr> cfields: make src/qt/bitcoin-qt <-- does not rebuild if files changed :/
228 2014-09-13 07:13:56 <Aquent> duno if you read the leaked email from mike hearn
229 2014-09-13 07:14:27 <Aquent> "Forking Bitcoin-Qt/Core has been coming up more and more often lately in conversation (up from zero not that long ago). Gavin even suggested me and him fork it ... I pointed out that maintainers don't normally fork their own software :)"
230 2014-09-13 07:14:49 <Aquent> "I know you won't return and that's wise, but sometimes I wish you'd left a clearer design manifesto before handing the reigns over to Gavin, who is increasingly burned out due to all the arguments (as am I)."
231 2014-09-13 07:15:21 <Aquent> don't think he gets the point of decentralized if he wants satoshi to order people around
232 2014-09-13 07:16:13 <Luke-Jr> Aquent: he probably doesn't, but that's off-topic here
233 2014-09-13 07:16:50 <Aquent> well the forking consideration isn't off topic?
234 2014-09-13 07:17:19 <Luke-Jr> Aquent: borderline topic - it's only on-topic insofar as it relates to development of it
235 2014-09-13 07:24:23 <Aquent> well, Luke-Jr I am not a Bitcoin developer. I just wanted to know if this forking idea is being considered seriously?
236 2014-09-13 07:25:11 <wumpus> everyone is free to fork bitcoin repository, including the maintainer, or even satoshi :p
237 2014-09-13 07:25:14 <Luke-Jr> ^
238 2014-09-13 07:25:35 <Luke-Jr> Aquent: forking would be a good thing; we just don't have sufficient resources period.
239 2014-09-13 07:25:54 <Luke-Jr> wumpus: can you aide in fixing 1stclassmsg plz? :|
240 2014-09-13 07:26:05 <wumpus> Luke-Jr: what's the problem?
241 2014-09-13 07:26:07 <Luke-Jr> wumpus: when I click the tab thing, it pops up the stupid window
242 2014-09-13 07:26:43 <wumpus> which window is 'the stupid window'?
243 2014-09-13 07:26:45 <Luke-Jr> wumpus: I pushed 1stclassmsg-0.9.x branch to my github if you want to see the current code
244 2014-09-13 07:26:49 <Luke-Jr> wumpus: the sign/verify window
245 2014-09-13 07:26:56 <Luke-Jr> which I want embedded as a tab
246 2014-09-13 07:27:22 <wumpus> I had that with the debug window as well at some point
247 2014-09-13 07:28:10 <Luke-Jr> I'm at a complete loss for what is forcing it to be a new window
248 2014-09-13 07:28:25 <wumpus> this was it in the case: rpcConsole = new RPCConsole(enableWallet ? this : 0);
249 2014-09-13 07:28:47 <wumpus> if you pass a current window to the constructor, for some reason it wants to regard it as a separate window
250 2014-09-13 07:29:01 <Luke-Jr> O.o
251 2014-09-13 07:29:02 <wumpus> if you pass 0, then add it as widget later, it works fine as a widget
252 2014-09-13 07:29:08 <Luke-Jr> odd, let me try that..
253 2014-09-13 07:30:13 <wumpus> that was really counter-intuitive to me
254 2014-09-13 07:30:33 <wumpus> you can also try passing Qt::WindowFlags
255 2014-09-13 07:33:03 <Luke-Jr> hah, that was it
256 2014-09-13 07:33:07 <Luke-Jr> thanks
257 2014-09-13 07:37:56 <wumpus> Luke-Jr: I think the problem is that we're using QDialogs, which expect to always be a top-level window
258 2014-09-13 07:39:33 <wumpus> all these GUI units which can both be top-level windows and embedded should just be QWidget, but that's more than a matter of just changing the class names as the code assumes they have dialog-like behavior
259 2014-09-13 07:40:07 <wumpus> (such as call .exec() on them)
260 2014-09-13 07:40:51 <wumpus> could be solved by having a dummy "frame" QDialog and insert the widgets in that if they're used as top level
261 2014-09-13 07:45:15 <Luke-Jr> hmm
262 2014-09-13 08:30:10 <robbak> Bitty gitty question - when you download the source code from github, it extracts into a folder that includes a partial commit hash - bitcoin-bitcoin-d1911c7 for rc2. I can't find that commit on github - where does it come from?
263 2014-09-13 08:36:37 <Luke-Jr> robbak: it's on github
264 2014-09-13 08:36:54 <Luke-Jr> commit cea5e4942070b842cac560803f9ba74271e26cd7 (tag: v0.9.3rc2, origin/0.9.3, 0.9.3)
265 2014-09-13 08:37:07 <Luke-Jr> https://github.com/bitcoin/bitcoin/commit/cea5e4942070b842cac560803f9ba74271e26cd7
266 2014-09-13 08:42:59 <robbak> I saw that, but that is tag cea5e49, not d1911c7. I imagine that it is the commit for the tag itself, I can't see that number.
267 2014-09-13 08:46:30 <wumpus> the tag itself is also an object in git
268 2014-09-13 08:46:45 <wumpus> try "git show d1911c7"
269 2014-09-13 08:53:03 <robbak> That looks like it. Thanks. It's something I wanted to check, to make sure that what I had was what I should have.
270 2014-09-13 12:15:18 <Happzz> what happens to a tx that isnt confirmed for days
271 2014-09-13 12:15:22 <Happzz> is it dropped?
272 2014-09-13 12:15:31 <sipa> maybe
273 2014-09-13 12:23:27 <robertjw_> I just spent a day of time manually extracting priv keys from a corrupt wallet and after finishing this, I have a suggestion. The cause of the wallet corruption was a "disk full" event while bitcoind was active. My best guess is that wallet.dat was still valid at the time of the event but was corrupted by bitcoind's attempts to continue after disk space was freed. I'm thinking that in the event of "disk full", the best stra
274 2014-09-13 12:35:36 <Happzz> sipa what are the other options? could it stay in mempool forever?
275 2014-09-13 12:35:50 <Happzz> if its dropped, i could issue another tx..
276 2014-09-13 12:37:13 <robbak> If you enter another transaction that spends the first transactions inputs, you will force the first transaction to be dropped by any nodes with it still in their queues.
277 2014-09-13 12:45:44 <Happzz> robbak nodes wont take the second one because the first is already in their mempool
278 2014-09-13 12:54:26 <sipa> Happzz: nodes change
279 2014-09-13 12:54:32 <sipa> they get restarted etc
280 2014-09-13 12:55:09 <sipa> what you say is true, but there is no consistency mechanism tgat synchronizes the mempool contents
281 2014-09-13 12:57:24 <Happzz> so theoretically, if all nodes in the world are restarted now, they'd forget about the old tx and i could transmit a different tx?
282 2014-09-13 12:58:26 <Eliel> robertjw_: the wallet is handled the bdb library, so that kind of limits what can be done about it.
283 2014-09-13 12:59:22 <sipa> Happzz: yes
284 2014-09-13 12:59:28 <Happzz> thanks
285 2014-09-13 13:00:21 <robertjw_> Eliel: I was thinking along the lines of removing the automatic invokation of recovery.
286 2014-09-13 13:01:08 <sipa> hmm, was it automatic recovery that corrupted it?
287 2014-09-13 13:01:38 <sipa> robertjw_: your message got cut off, btw
288 2014-09-13 13:01:51 <sipa> (irc max line length of 510 characters)
289 2014-09-13 13:02:31 <robertjw_> I can't say that for certain, what I can say is that db_dump identified a "no records" wallet.dat at conclusion.
290 2014-09-13 16:01:23 <dabura667> wait... do all pubkeys in redeemscripts for multisig required to be uncompressed?
291 2014-09-13 16:03:03 <sipa> no
292 2014-09-13 16:03:14 <sipa> i suggest nobody uses uncompressed pubkeys, ever