1 2014-06-18 00:03:19 <CoinFinder> the hashMerkleRoot in the blockheader - this would change if the transactions in the block change, right?
2 2014-06-18 00:05:18 <arubi> the tx's themselves, also the order
3 2014-06-18 00:05:53 <arubi> (afaik, unless they're being sorted before that)
4 2014-06-18 00:07:42 <CoinFinder> but (unrelated directly to #bitcoin-dev) - the stratum mining protocol doesn't send this merkleRoot to the miner does it? It just sends the left side? any clue as to why they do this?
5 2014-06-18 00:08:17 <arubi> I don't know, sorry
6 2014-06-18 00:08:20 <CoinFinder> surely it has to be the entire merkle root, or the blockhash would be invalid?
7 2014-06-18 00:31:43 <Luke-Jr> CoinFinder: the miner has to calculate the entire merkle root
8 2014-06-18 00:32:05 <Luke-Jr> CoinFinder: because the miner chooses what the bottom of the left side is
9 2014-06-18 00:32:52 <CoinFinder> thanks for the clarification :)
10 2014-06-18 00:33:08 <CoinFinder> so my solution would work with stratum then, without modification.
11 2014-06-18 00:33:30 <Luke-Jr> CoinFinder: solution to?
12 2014-06-18 00:35:45 <CoinFinder> >51% control of the blockchain adding in a layer between the block template and the pool, where the block template is genereated by a third party, with a hash to prove the source in the coinbase extra, and a check in the mining software to prevent pools tampering.
13 2014-06-18 00:37:19 <maaku> CoinFinder: not relaly possible with stratum
14 2014-06-18 00:37:23 <maaku> that's what GBT is for though
15 2014-06-18 00:37:42 <CoinFinder> maaku: stratum seems to send all the required information to confirm this. merkle hashes and so forth
16 2014-06-18 00:38:09 <gmaxwell> CoinFinder pulled me into PM two hours ago and I haven't been able to convince him.
17 2014-06-18 00:38:09 <maaku> CoinFinder: stratum tells you what to include in the block. you don't have decentralized control over this
18 2014-06-18 00:39:01 <CoinFinder> maaku: no you don't.. but you have the checks In the data then to not mine the block if it doesn't verify with the third party that generaeted the block.
19 2014-06-18 00:39:21 <maaku> CoinFinder: no, you don't have the data necessary to know what is in the block even
20 2014-06-18 00:39:41 <maaku> and not being able to control that is the whole point -- that's all that is sufficient to carry out bad attacks
21 2014-06-18 00:39:48 <CoinFinder> maaku: you dont need to know what is in the block, merely that the block is unmodified.
22 2014-06-18 00:39:58 <maaku> but why does it matter? GBT solves this, and is already implemented
23 2014-06-18 00:40:18 <maaku> CoinFinder: that makes absolute no sense. you have to know what is in the block, period.
24 2014-06-18 00:41:21 <CoinFinder> maaku: if i give you the block template, and miners then can check the block you send out is the same as the one i sent you.. they need not know.
25 2014-06-18 00:42:23 <CoinFinder> because then they know you haven't got control over the block. and they know that i wont have control over the next block (because your pool will round-robin to another valid source)
26 2014-06-18 00:58:26 <Luke-Jr> CoinFinder: it might be possible to *extend* stratum to do this, but there's no need since we already have GBT
27 2014-06-18 00:59:02 <Luke-Jr> CoinFinder: wait what? that makes no sense
28 2014-06-18 00:59:16 <CoinFinder> What doesn't?
29 2014-06-18 00:59:17 <Luke-Jr> CoinFinder: the end miner *should* have control over the block
30 2014-06-18 00:59:35 <CoinFinder> My solution isn't about giving the miner control over the block. Its about taking it away from the controlling pool.
31 2014-06-18 00:59:56 <Luke-Jr> then it isn't a solution
32 2014-06-18 01:00:49 <CoinFinder> It is a solution. If you can get everyone to use GBT then great... someone was saying thought that its very hard for pools GBT blocks? honestly i have no clue about the pros/cons of GBT. I know its not well utilised currently.
33 2014-06-18 01:01:19 <Luke-Jr> CoinFinder: so help out
34 2014-06-18 01:01:26 <CoinFinder> Anyway, feel free to comment in the thread :)
35 2014-06-18 01:01:31 <Luke-Jr> someone was saying ⦠absolute nonsense?
36 2014-06-18 01:01:35 <Luke-Jr> what thread?
37 2014-06-18 01:02:10 <Luke-Jr> using bitcointroll for anything serious is dumbâ¦
38 2014-06-18 01:02:20 <CoinFinder> ist better than reddit lol
39 2014-06-18 01:04:38 <fanquake> ;;blocks
40 2014-06-18 01:04:39 <gribble> 306411
41 2014-06-18 01:10:55 <CoinFinder> anyway im off to bed :)
42 2014-06-18 01:39:03 <Luke-Jr> wtf, coinfinder's idea is even more insane than I expected
43 2014-06-18 01:40:27 <andytoshi> oh? i just skimmed until i found the part where the pools had to voluntarily act
44 2014-06-18 01:41:26 <gmaxwell> I thought he was redescribing coinbase only mining at first, but no, he expects pools to round robbin other pools as block template sources.
45 2014-06-18 02:16:35 <maaku> that's optimistic
46 2014-06-18 02:44:55 <ubuntuDoubts> Hello
47 2014-06-18 02:44:59 <ubuntuDoubts> Good night.
48 2014-06-18 02:45:28 <ubuntuDoubts> I would like to know if anyone here is able to help me with github.
49 2014-06-18 03:02:09 <fanquake> ubuntuDoubts It's easier if your just ask your question
50 2014-06-18 04:09:01 <G_Qu> Hi there everyone. I've encountered an odd error in bitcoind while creating a raw transaction. Does anyone have any idea what could have caused this or what it means? http://paste.ubuntu.com/7661757/
51 2014-06-18 05:53:33 <Dizzle> sipa: if you don't mind me asking, what feeds the addresses in your DNS record used in Bitcoin Core's discovery process?
52 2014-06-18 05:59:19 <Luke-Jr> Dizzle: github.com/sipa/bitcoin-seeder
53 2014-06-18 05:59:29 <Dizzle> ty, Luke-Jr
54 2014-06-18 06:03:09 <wumpus> Luke-Jr: let's not confuse the guy in #4361, his English understanding is pretty bad, so if you start discusiing he thinks you agree with his change :p
55 2014-06-18 06:04:07 <Luke-Jr> XD
56 2014-06-18 06:37:50 <Dizzle> How does bitcoind determine what unconfirmed transactions from its mempool to put in getwork or getblocktemplate request?
57 2014-06-18 06:40:56 <wumpus> Dizzle: see CreateNewBlock in src/miner.cpp
58 2014-06-18 06:41:14 <Dizzle> Thanks! Code is actually really readable, hah
59 2014-06-18 06:46:20 <Luke-Jr> Dizzle: note this is policy, and intended to be modified by miners
60 2014-06-18 06:48:31 <Dizzle> Luke-Jr: does bitcoind provide a way for a miner to simply grab the node's valid mempool transactions so that the miner can decide for itself how to prioritize them (i.e. its own CreateNewBlock)?
61 2014-06-18 06:48:53 <Luke-Jr> Dizzle: getrawmempool? but then you need to order them too
62 2014-06-18 06:49:11 <Luke-Jr> Dizzle: the usual recommendation at the moment would be to modify the CreateNewBlock function
63 2014-06-18 06:49:48 <Dizzle> Cool. Thanks!
64 2014-06-18 06:53:33 <dsnrk> wow, #4343 is a nasty DOS bug
65 2014-06-18 06:54:19 <wumpus> Dizzle: making it possible to do transaction selection policy outside of the process would be a worthwhile goal, no one is working on that AFAIK
66 2014-06-18 06:54:32 <dsnrk> should be good for when people suggest leaving RPC open to the world is alright :)
67 2014-06-18 06:57:43 <wumpus> dsnrk: but only the nodes that you specify as rpcallowip can attack you, others are disconnected before even getting there
68 2014-06-18 06:58:28 <wumpus> that has turned out to be a very good policy, preventing everything from heartbleed leaks to DoS vulnerabilities
69 2014-06-18 06:58:30 <dsnrk> wumpus: I've seen people post their configs that have rpcallowip=* in them
70 2014-06-18 07:00:30 <dsnrk> http://pastebin.com/t8hvpZmT http://pastebin.com/Y3zbY9nG http://pastebin.com/bX8fJHG9 http://pastebin.com/MgiCRzkh http://pastebin.com/SfXLY6B1
71 2014-06-18 07:00:45 <dsnrk> if there's that many on pastebin, you can assume there's going to be even more of them in real life
72 2014-06-18 07:01:49 <wumpus> dsnrk: well if you have wallet disabled it *should* at most open you up to DoS attacks
73 2014-06-18 07:03:55 <wumpus> though it's absolutely not recommended to allowip everyone, the RPC API has been much less audited than the P2P API, and there may of course be a code execution vulnerability somewhere in there
74 2014-06-18 07:04:29 <dsnrk> ACTION mutters about people running bitcoind as root
75 2014-06-18 07:06:03 <gmaxwell> dsnrk: really local code execution, at least outside of a sandbox, ~= root anyways.
76 2014-06-18 07:07:38 <wumpus> gmaxwell: well in a way a local code execution can always lead to compromising root when combined with another exploit, but I hope you're not using that as an argument for people to run all services as root :)
77 2014-06-18 07:07:43 <dsnrk> gmaxwell: unnecessary though. why throw somebody root when you can make them work for it?
78 2014-06-18 07:09:26 <gmaxwell> no no, indeed, I'm not, but I wouldn't put it on even the same ranking as having rpc open to the internet on a machine that isn't a throwaway. :)
79 2014-06-18 07:12:00 <dsnrk> it's madness! if you need to get to your RPC port that's not local, just tunnel the port through ssh.
80 2014-06-18 07:12:03 <wumpus> it's the combination that makes it extra strong, run bitcoind as root AND have RPC open to the internet
81 2014-06-18 07:12:49 <wumpus> it's about as scary as the combination of people that are clueless about security and bitcoin
82 2014-06-18 07:13:05 <Apocalyptic> oh wait
83 2014-06-18 07:13:09 <Apocalyptic> is that guy back again ?
84 2014-06-18 07:13:17 <dsnrk> no, don't worry :)
85 2014-06-18 07:17:26 <dsnrk> gmaxwell: I do have those orphan blocks for you too, I just need to sort out which ones involve ghash.io.
86 2014-06-18 07:33:22 <wumpus> CodeShark: I've managed to compile CoinVault, but can't find any documentation on running it -- can I run it in testnet/regtest mode?
87 2014-06-18 07:35:05 <wumpus> hearn: thanks for adding the service bit, it's ok with me now
88 2014-06-18 07:35:34 <hearn> cool. i will look at extending the pull tester to unit test the message. also updating it so peter's stack clearing patch works
89 2014-06-18 07:36:09 <hearn> wumpus: would you like it to be NODE_GETUTXOS or NODE_FULL_UTXO?
90 2014-06-18 07:36:53 <wumpus> hearn: well -- in my opinion the focus of service bits should be what they offer to the network, not what the node is
91 2014-06-18 07:37:09 <hearn> ok, then i'll keep it as is
92 2014-06-18 07:39:22 <wumpus> hearn: basically you are adding an API that adds semi-trusted queries, so the name of the node bit should focus around that... NODE_GETUTXOS sounds fine to me, although it is very specific to this call, not sure if the intent is to extend this later
93 2014-06-18 07:40:17 <hearn> yes, not sure either. i don't have any other messages i want to add at the moment. maaku mentioned a getutxo2 message that includes proofs in future, but that could also be just regular NODE_GETUTXO + regular getutxo message + higher version number. not sure.
94 2014-06-18 07:40:40 <wumpus> right
95 2014-06-18 08:03:37 <LowFructose> anyone around?
96 2014-06-18 08:14:57 <maaku> hearn: "that could also be just regular NODE_GETUTXO + regular getutxo message + higher version number" <-- right
97 2014-06-18 08:16:07 <maaku> hearn: wumpus: NODE_NETWORK (ugh on the name) means the node has the full block chain history, e.g. so you can fetch blocks or do bloom filter queries
98 2014-06-18 08:16:09 <uiop> there are two kinds of people on irc; those that insert quoted message before reply, and those that after
99 2014-06-18 08:16:40 <uiop> :)
100 2014-06-18 08:17:01 <maaku> my point is that this is really 100% orthogonal to having the UTXO set, so we should have a separate service bit indicating that the node maintains the UTXO set and can answer UTXO-related queries
101 2014-06-18 08:17:07 <wumpus> maaku: yes, and as I said, I think it makes more sense to define service bits around which services a node provides, not so much what it is
102 2014-06-18 08:18:24 <wumpus> as that is much more useful information to peers; someone could be storing all history but not want to serve it to others
103 2014-06-18 08:18:26 <maaku> right, so we need a new NODE_UTXOSET or somesuch, indicating support for answering UTXO queries (using getutxos now, getutxos2 with proofs later)
104 2014-06-18 08:18:30 <wumpus> but I agree they should have been separate
105 2014-06-18 08:21:00 <uiop> wumpus: good point. lack of capability is indistinguishable from unexposed
106 2014-06-18 08:22:32 <uiop> (from the pov under discussion)
107 2014-06-18 08:23:07 <maaku> actually we don't need to go as far as utxo commitments either -- block chain pruning will result in nodes that can serve utxo queries but not block chain history
108 2014-06-18 08:24:03 <maaku> well, in practice nodes will keep some blocks around if for no other reason than reorg support, and they will support retrieval of those, but the conceptual point stands :P
109 2014-06-18 08:52:59 <gdm85> is there a comprehensive wiki page about notification features of bitcoind? I have seen walletnotify and blocknotify so far
110 2014-06-18 08:54:15 <gdm85> also, I would like to inquiry if patches to support keypool extension notification would be welcome or not
111 2014-06-18 09:21:37 <wumpus> gdm85: no objections, although that would be akin to a notification after each new address generated
112 2014-06-18 09:23:30 <gdm85> wumpus: right. that's because there is currently no way to force generation only in units of X addresses, correct?
113 2014-06-18 09:23:47 <wumpus> wumpus: no, although you could call keypoolrefill manually
114 2014-06-18 09:24:14 <wumpus> there was a patch at some point that added an option to disable automatic keypool refill
115 2014-06-18 09:24:20 <wumpus> I liked it , but no one else did :/
116 2014-06-18 09:24:27 <gdm85> uhm, I think I would like it too now
117 2014-06-18 09:25:14 <wumpus> anyhow, if you're smart you use another wallet instead of the bitcoind one :)
118 2014-06-18 09:25:43 <gdm85> so if automatic keypool refill was there and enabled, one could extend keypoolrefill to send a notify when complete
119 2014-06-18 09:25:46 <gdm85> wumpus: sure :)
120 2014-06-18 09:25:58 <wumpus> it's really falling behind a lot; BIP32 would solve all keypool related issues
121 2014-06-18 09:26:37 <wumpus> many other wallets do implement deterministic key generation, which is probably preferable to hacks-on-hacks on top of keypools
122 2014-06-18 09:26:40 <gdm85> ah, deterministic wallets
123 2014-06-18 09:26:55 <gdm85> makes sense
124 2014-06-18 09:27:09 <warren> gdm85: I assume you want such a notification because you need ot know when it backup the wallet?
125 2014-06-18 09:27:32 <warren> You may be better off not backing up that wallet directly because you technically need to take it down to do so.
126 2014-06-18 09:28:01 <warren> This is for an automated service right?
127 2014-06-18 09:28:22 <gdm85> warren: ideally I would have a wrapper over bitcoind that puts the wallet down during keypool extension, makes a backup and then puts it back online
128 2014-06-18 09:28:28 <gdm85> to preserve atomicity of the operation
129 2014-06-18 09:28:35 <warren> quite messy
130 2014-06-18 09:28:58 <gdm85> ?
131 2014-06-18 09:28:58 <warren> Prior to deterministic wallet, you might do well to use the watchonly wallet that's coming soon.
132 2014-06-18 09:29:33 <warren> Generate addresses and privkeys offline, importaddress without rescan for each new address.
133 2014-06-18 09:29:36 <warren> no need to backup that wallet
134 2014-06-18 09:29:55 <gdm85> with a keypoolrefill notification it'd be doable, and the RPC does not need to change (except for the fact that it would delay certain operations)
135 2014-06-18 09:29:59 <gdm85> warren: I'll look into that
136 2014-06-18 09:30:02 <warren> Go test the watch only PR
137 2014-06-18 09:30:27 <warren> This has the benefit of keeping the private keys entirely offline, and you don't need to take it down to make backups.
138 2014-06-18 09:30:54 <t7> building boost, brb 2 hours
139 2014-06-18 09:31:19 <gdm85> warren: one thing is for sure: if taking down the wallet is the safe way, it's not messy for me. it's the only option available now
140 2014-06-18 09:31:56 <warren> gdm85: seriously, go test the watchonly PR, it's much safer and better for the future.
141 2014-06-18 09:32:10 <warren> gdm85: if that server is hacked they can't steal any money
142 2014-06-18 09:32:23 <gdm85> warren: I am not denying that. I am just looking at currently released bitcoind, the one that I have to use
143 2014-06-18 09:32:56 <gdm85> I will check what that PR does, and keep an eye
144 2014-06-18 09:33:00 <gdm85> this is indeed interesting development
145 2014-06-18 09:35:37 <gdm85> ACTION is reading https://github.com/bitcoin/bitcoin/pull/4045
146 2014-06-18 09:51:24 <wumpus> warren: you don't need to take it down to do a wallet backup, there has been a RPC call for that for a logg time
147 2014-06-18 09:53:17 <warren> wumpus: oops, ok =)
148 2014-06-18 10:23:40 <gdm85> it's more about being sure that a new generated address will not be used until its private key is backed up
149 2014-06-18 10:25:03 <warren> gdm85: what I suggested works, you do importaddress instead of getnewaddress
150 2014-06-18 10:25:09 <warren> so you know exactly which addresses were used
151 2014-06-18 10:25:10 <Jouke> Why do you need to put the wallet down for a backup?
152 2014-06-18 10:25:14 <wumpus> gdm85: that's not supported in bitcoind at the moment - the only way to guarantee that is to disable automatic keypool refill, and refill the keypool manually when you run out and the immediately do a backup before you do any transactions
153 2014-06-18 10:25:24 <wumpus> Jouke: you don't, that was a misunderstanding by warren
154 2014-06-18 10:25:38 <warren> that doesn't make what gdm85 asked for a good way to do it
155 2014-06-18 10:25:54 <gdm85> wumpus: yep, automatic keypool refill would be the obstacle
156 2014-06-18 10:26:25 <wumpus> warren: please don't suggest using importkey -- change addresses will still come from the keypool, for example, it's a very brittle solution
157 2014-06-18 10:27:09 <hearn> a basic HD wallets in bitcoin core wouldn't be very complicated
158 2014-06-18 10:27:09 <wumpus> if you ask me just use a wallet with deterministic key generation and forget about the keypool thing, but if you insist on doing it with keypools, you need to somehow disable the automatic keypool refill... I'll see if I can find the pull for that
159 2014-06-18 10:27:29 <wumpus> hearn: it wouldn't, but no one cares enough to do it
160 2014-06-18 10:27:37 <gdm85> ACTION nods
161 2014-06-18 10:27:43 <wumpus> everyone either uses iron-fisted backup policies or uses another wallet
162 2014-06-18 10:28:25 <wumpus> gdm85: https://github.com/bitcoin/bitcoin/pull/2841
163 2014-06-18 10:28:36 <warren> wumpus: I wasn't suggesting importprivkey
164 2014-06-18 10:29:01 <warren> wumpus: I was suggesting importaddress and watchonly is excellent for receivers
165 2014-06-18 10:29:09 <warren> I did forget to ask if this wallet sends.
166 2014-06-18 10:29:12 <wumpus> gdm85: although it seems very much out of date now, rebasing will take some work
167 2014-06-18 10:29:16 <wumpus> warren: OK, good then
168 2014-06-18 10:29:21 <wumpus> gtg
169 2014-06-18 10:30:57 <gdm85> wumpus: ah, I understand
170 2014-06-18 11:05:18 <dsnrk> is it intentional that the 0.9.2 release doesn't have static builds like 0.9.1?
171 2014-06-18 11:19:39 <terve> :)
172 2014-06-18 11:19:54 <terve> usually forks last max 4 blocks? reorgs
173 2014-06-18 11:23:06 <dsnrk> terve: there's no real limit on the length. more a question for #bitcoin though, lets take it there.
174 2014-06-18 11:23:40 <terve> cool
175 2014-06-18 11:26:19 <longfloat> bitcoin.org is not clear enough on this: which sources version is recommended to use now? the newest tag? so 0.9.2 now?
176 2014-06-18 11:31:27 <SomeoneWeird> 0.9.2 has been tagged, but not officially released, afaik
177 2014-06-18 11:31:53 <SomeoneWeird> wait nevermind, it has
178 2014-06-18 11:31:57 <SomeoneWeird> at least, the website links to it
179 2014-06-18 11:32:03 <SomeoneWeird> longfloat: what is unclear?
180 2014-06-18 11:45:38 <longfloat> SomeoneWeird: the link should be to that tag, not to head
181 2014-06-18 11:45:48 <SomeoneWeird> where?
182 2014-06-18 11:45:56 <SomeoneWeird> https://bitcoin.org/en/download
183 2014-06-18 11:45:57 <longfloat> https://github.com/bitcoin/bitcoin takes people to location of current head, right? from https://bitcoin.org/en/download
184 2014-06-18 11:45:59 <SomeoneWeird> links to 0.9.2
185 2014-06-18 11:46:11 <SomeoneWeird> eh?
186 2014-06-18 11:49:47 <longfloat> SomeoneWeird: using links from bitcoin.org to github, people will checkout by default (or download zip) of current head, instead of current stable tag 0.9.2, right?
187 2014-06-18 11:50:08 <SomeoneWeird> oh, you mean the actual github link
188 2014-06-18 11:50:14 <longfloat> to fix it, the link on https://bitcoin.org/en/download under sources should link to tag 0.9.2
189 2014-06-18 11:50:35 <SomeoneWeird> i see how it may be slightly confusing
190 2014-06-18 11:50:57 <SomeoneWeird> longfloat: the site is open source, make a pull req :)
191 2014-06-18 11:51:01 <longfloat> another concern: also, this link is too deeply burried. the Download should be clearly visible on top of bitcoin.org as one of first things
192 2014-06-18 11:51:25 <SomeoneWeird> how? it's one or two clicks
193 2014-06-18 11:51:33 <longfloat> SomeoneWeird: I don't have github configured; but ok friend should commit later
194 2014-06-18 11:51:46 <SomeoneWeird> and the pages before it should defs be read before people download
195 2014-06-18 11:51:50 <longfloat> SomeoneWeird: 2 clicks > 0 clicks
196 2014-06-18 11:52:07 <SomeoneWeird> informed people > misinformed people
197 2014-06-18 11:53:58 <longfloat> SomeoneWeird: put big warning "This is the CORE WALLET, you might want to check out the easier wallets first". Also, it is in network interest to attract more people to run full node
198 2014-06-18 11:54:16 <SomeoneWeird> not just that
199 2014-06-18 11:54:26 <SomeoneWeird> https://bitcoin.org/en/getting-started
200 2014-06-18 11:54:33 <SomeoneWeird> this page is invaluable
201 2014-06-18 11:54:40 <SomeoneWeird> for noobs, trying to understand how things work
202 2014-06-18 11:54:45 <SomeoneWeird> this is offtopic for in here, now
203 2014-06-18 11:58:46 <longfloat> on debian stable can I just use the system provided libdb or is custome one needed? System provides libdb5.1++
204 2014-06-18 12:03:30 <longfloat> how you actually build bitcoin now?
205 2014-06-18 12:04:00 <longfloat> oh. it's in the other readme.. the main README.md should link to that probbly
206 2014-06-18 12:51:47 <wumpus> dsnrk: yes, the static builds are not necessary anymore
207 2014-06-18 12:54:48 <dsnrk> wumpus: primo.
208 2014-06-18 13:20:23 <lorenzo_> hello
209 2014-06-18 13:21:31 <lorenzoasr> does anyone know if there is a way to sign offline a p2sh transaction with BitcoinJ
210 2014-06-18 13:21:32 <lorenzoasr> ?
211 2014-06-18 13:21:43 <hearn> yes, of course
212 2014-06-18 13:21:47 <hearn> btw there is a #bitcoinj channel
213 2014-06-18 13:22:06 <hearn> this document may answer your question: http://bitcoinj.github.io/working-with-contracts
214 2014-06-18 13:24:09 <wumpus> cfields: people are reporting font issues with the 0.9.2 macosx build :/ https://bitcointalk.org/index.php?topic=655359.msg7380054
215 2014-06-18 13:24:43 <dsnrk> wumpus: one second, I'll see if I can replicate in a VM.
216 2014-06-18 13:29:25 <dsnrk> wumpus: replicated. https://i.imgur.com/bUvZbxh.png
217 2014-06-18 13:31:03 <wumpus> ok so the fixed-width font is broken
218 2014-06-18 13:31:21 <dsnrk> only affects the "pay to" field of that panel, nothing more.
219 2014-06-18 13:31:48 <wumpus> probably it also affects "command line options" in the help menu, it uses the same font
220 2014-06-18 13:32:41 <wumpus> anyhow this pretty much means that the macosx build of 0.9.2 is useless, why didn't anyone see this with the rc?
221 2014-06-18 13:32:47 <dsnrk> wumpus: replicated. https://i.imgur.com/hbJSLat.jpg
222 2014-06-18 13:33:33 <wumpus> squares, lots of squares, this is not just fixed-width this is fixed-character :p
223 2014-06-18 13:34:36 <wumpus> hearn: oh no https://bitcointalk.org/index.php?topic=656704.0
224 2014-06-18 13:34:51 <hearn> wonderful
225 2014-06-18 13:35:01 <hearn> anyway, i think we have a decision by gavin
226 2014-06-18 13:35:09 <dsnrk> wumpus: what is a sending address anyway? https://i.imgur.com/xHNtDz4.jpg
227 2014-06-18 13:35:11 <wumpus> the crazy cook brigade is on the loose again
228 2014-06-18 13:35:22 <wumpus> kook*
229 2014-06-18 13:35:31 <dsnrk> I've never used the GUI before so I'm not sure what a "sending" address is.
230 2014-06-18 13:35:35 <wumpus> dsnrk: something very square
231 2014-06-18 13:35:49 <hearn> it's not crazy to disagree, but trying to rabble-rouse is annoying
232 2014-06-18 13:36:10 <michagogo> gdm85: you can set keypool=1 and then use the rpc "keypoolrefill 1000", for example
233 2014-06-18 13:36:17 <wumpus> no, it's not crazy to disagree, it's about the way that it's done
234 2014-06-18 13:36:42 <gdm85> michagogo: keypool could still enlarge itself automatically by 1 address
235 2014-06-18 13:36:46 <wumpus> I wonder if you couuld set keypool=0
236 2014-06-18 13:36:49 <dsnrk> wumpus: my point was more that transactiond don't have a from address, so what is a "sending" address in the GUI?
237 2014-06-18 13:37:11 <wumpus> dsnrk: it's an address that you send to
238 2014-06-18 13:37:19 <michagogo> gdm85: well, easy -- just tail debug.log
239 2014-06-18 13:37:19 <wumpus> receiving addresses are addresses that you receive with
240 2014-06-18 13:37:25 <gdm85> wumpus: yes but doesn't mean disabled AFAIR
241 2014-06-18 13:37:32 <michagogo> And then alert on the "added key" warning
242 2014-06-18 13:37:46 <dsnrk> wumpus: oh like an address book for external things? that makes more sense.
243 2014-06-18 13:37:47 <gdm85> michagogo: hence -> keypoolrefill notification patch
244 2014-06-18 13:37:48 <michagogo> s/warning/message/
245 2014-06-18 13:38:00 <wumpus> gdm85: I think it would be natural to have keypool=0 mean 'no automatic keypool'
246 2014-06-18 13:38:07 <gdm85> ACTION nods
247 2014-06-18 13:38:12 <michagogo> gdm85: my point is, you don't necessarily need a patch for it, just monitor the log
248 2014-06-18 13:38:14 <wumpus> I don't think it works that way at the moment, but still
249 2014-06-18 13:38:24 <gdm85> yep
250 2014-06-18 13:38:38 <michagogo> Also, there's the fact that it can't generate keys with a locked wallet
251 2014-06-18 13:38:50 <wumpus> a keypool refill notication may be too late, or get lost, it's not an option for reliable backups IMO
252 2014-06-18 13:39:06 <michagogo> So you don't even need to monitor the log 24/7 -- just whenever you unlock the wallet
253 2014-06-18 13:39:22 <gdm85> wumpus: useful in case you have already keypool=0 and you command a refill manually
254 2014-06-18 13:39:27 <wumpus> michagogo: yep, you can also use the wallet encryption to avoid the keypool from being refilled automatically, but you need to unlock it to send a transaction so it's not terribly useful
255 2014-06-18 13:39:32 <gdm85> (keypool=0 meaning disabled)
256 2014-06-18 13:39:37 <wumpus> gdm85: sure but if you refill manually .. .you don't need the notification
257 2014-06-18 13:39:46 <gdm85> wumpus: is it synchronous?
258 2014-06-18 13:39:53 <wumpus> gdm85: yes
259 2014-06-18 13:39:55 <gdm85> ah, cool
260 2014-06-18 13:40:02 <gdm85> one less problem :)
261 2014-06-18 13:40:14 <michagogo> wumpus: right, just watch the log when you do that
262 2014-06-18 13:40:17 <gdm85> Jouke: ^
263 2014-06-18 13:40:18 <michagogo> Also, you can monitor the log for keypool reserve/keep messages
264 2014-06-18 13:41:09 <wumpus> the log should never be used as a critical interface
265 2014-06-18 13:41:33 <michagogo> Oh, also, important to note: at the moment, I think if the keypool runs out, getting a new address doesn't fail
266 2014-06-18 13:41:33 <wumpus> it's fine to tail the log for debugging or troubleshooting, but please don't make services rely on it
267 2014-06-18 13:41:40 <michagogo> It gives you one specific address
268 2014-06-18 13:41:49 <michagogo> I don't remember how it picks it
269 2014-06-18 13:41:51 <wumpus> michagogo: it does fail, *unless* you use the raw change address call
270 2014-06-18 13:41:59 <michagogo> wumpus: aha
271 2014-06-18 13:42:09 <michagogo> Interesting
272 2014-06-18 13:42:18 <wumpus> michagogo: I have a pull to test and fix that
273 2014-06-18 13:42:23 <michagogo> (How come?)
274 2014-06-18 13:42:48 <wumpus> michagogo: https://github.com/bitcoin/bitcoin/pull/4347
275 2014-06-18 13:43:05 <gdm85> wumpus: exactly. michagogo you are underestimating the case where the log is partially flushed
276 2014-06-18 13:43:10 <gdm85> tailing the log is just a very dirty hack
277 2014-06-18 13:43:14 <wumpus> michagogo: well imo it's a bug/inconsistency
278 2014-06-18 13:43:33 <wumpus> getting a new address when the keypool is drained should be an error, period
279 2014-06-18 13:43:42 <gdm85> ACTION agrees
280 2014-06-18 15:04:36 <michagogo> wumpus: right.
281 2014-06-18 15:31:29 <michagogo> Hm, apparently the $j extban is now available on free use
282 2014-06-18 15:31:33 <michagogo> Freenode*
283 2014-06-18 15:32:37 <michagogo> So you can mirror one channel's ban list onto another, AIUI
284 2014-06-18 15:33:08 <michagogo> So if you, for example, set /mode #bitcoin-dev +b $j:#bitcoin
285 2014-06-18 15:33:32 <michagogo> That will mean that anyone banned there will be autobanned here
286 2014-06-18 15:43:51 <phantomcircuit> michagogo, do they count the bans in the other channel against the banlist limit for your channel?
287 2014-06-18 15:44:01 <phantomcircuit> if not then well
288 2014-06-18 15:44:03 <phantomcircuit> unlimited ban list
289 2014-06-18 15:44:22 <michagogo> phantomcircuit: hm, good question. I have no idea.
290 2014-06-18 15:51:44 <michagogo> phantomcircuit: not unlimited
291 2014-06-18 15:51:52 <michagogo> But x^2
292 2014-06-18 15:52:35 <michagogo> #freenode seems to think that it doesn't count the target channel bans against your limit
293 2014-06-18 15:52:41 <michagogo> But it doesn't recurse either
294 2014-06-18 15:56:18 <phantomcircuit> michagogo, isn't the channel limit like 1024 bans or something?
295 2014-06-18 16:00:14 <michagogo> phantomcircuit: idk
296 2014-06-18 16:00:37 <michagogo> If it is, this increases it to a M-ban
297 2014-06-18 16:00:42 <phantomcircuit> it's large enough that n^2 is pretty close to unlimited
298 2014-06-18 16:16:58 <lifty> hi gents. I have a confusion regarding transactions. Is there any difference between multisig transactions and p2sh transactions?
299 2014-06-18 16:21:51 <poutine> bitcoin script question, if the scriptSig in the txin does a OP_1 OP_TOALTSTACK, why would that not work with a txout's scriptPubKey that is "OP_FALSE OP_FROMALTSTACK"?
300 2014-06-18 16:34:29 <gavinandresen> poutine : because the alt stack is cleared between executing the scriptSig and executing the scriptPubKey.
301 2014-06-18 16:41:07 <poutine> Interesting, did not know that, thanks gavinandresen
302 2014-06-18 16:57:21 <hearn> poutine: there's no point putting anything but data into scriptSig as it runs with no input
303 2014-06-18 17:03:04 <ubuntuDoubts> Hi all can somebody just help me out with 1 thing?
304 2014-06-18 17:03:14 <ubuntuDoubts> when compiling without the genesis hash
305 2014-06-18 17:03:19 <ubuntuDoubts> where i look to core dump?
306 2014-06-18 17:03:23 <ubuntuDoubts> Where is it at ubuntu ?
307 2014-06-18 17:03:42 <ubuntuDoubts> ?
308 2014-06-18 17:03:42 <ubuntuDoubts> the folder that dump the debug.log
309 2014-06-18 17:09:48 <ubuntuDoubts> how can i find the file that terminal dumped with the hash merkel and genesis
310 2014-06-18 17:09:50 <ubuntuDoubts> pls..
311 2014-06-18 17:19:38 <ninjashogun> Hi. I was banned by andytosh i from #bitcoin and I'd like this ban removed as it concerned simple disagreement over the nature of low-probability events and does not warranty this reaction. I don't think a crypto network is stronger by banning discussion of its relationship with its design goals.
312 2014-06-18 17:20:12 <ninjashogun> warrant*
313 2014-06-18 17:26:26 <RBecker> ninjashogun: take it up with him directly, this isn't a deliberation channel
314 2014-06-18 17:27:22 <ninjashogun> ok
315 2014-06-18 18:12:28 <gribble> 306531
316 2014-06-18 18:12:28 <michagogo> ;;blocks
317 2014-06-18 18:13:29 <michagogo> Hm, does 2014-06-18 18:02:00 ERROR: AcceptToMemoryPool : inputs already spent
318 2014-06-18 18:13:34 <michagogo> only appear with txindex=1?
319 2014-06-18 18:50:28 <michagogo> Hm, what's the subver /Satoshi:0.8.2.2/ ?
320 2014-06-18 18:50:35 <michagogo> (what's 0.8.2.2?)
321 2014-06-18 19:00:41 <dsnrk> michagogo: don't know, but there's ~60 of them running that version
322 2014-06-18 19:01:29 <dsnrk> there's also 0.8.2.1 (5 nodes)
323 2014-06-18 19:02:19 <dsnrk> 0.8.1.99 (6 nodes)
324 2014-06-18 19:03:10 <dsnrk> https://getaddr.bitnodes.io/nodes/1403118000/?q=/Satoshi:0.8.2.2/ < that's handy
325 2014-06-18 19:05:09 <michagogo> phantomcircuit: MAXLIST=bqeI:100
326 2014-06-18 19:05:43 <michagogo> So the $j:#channel extban increases the ban list from 100 to 10,000 entries
327 2014-06-18 19:07:08 <phantomcircuit> michagogo, i wonder how it's implemented
328 2014-06-18 19:07:21 <michagogo> It's opensource, go and see!
329 2014-06-18 19:09:01 <jcorgan> i never checked before, but the 0.9.2 splashbox says 0.9.2-beta. is that normal?
330 2014-06-18 19:11:52 <chmod755> jcorgan, bitcoin is beta, yes
331 2014-06-18 19:12:11 <phantomcircuit> michagogo, is it?
332 2014-06-18 19:12:14 <phantomcircuit> oh ok then
333 2014-06-18 20:04:14 <econo> hiya
334 2014-06-18 20:09:01 <Forex> :)
335 2014-06-18 20:09:03 <Forex> hi
336 2014-06-18 20:14:19 <Pibs> Any developers here?
337 2014-06-18 20:17:38 <Forex> yes u
338 2014-06-18 21:06:39 <tigereye> So I'm looking for some info and am hoping someone in this channel can assist...
339 2014-06-18 21:07:05 <tigereye> Sipa created a patch last year for watch-only addresses... https://github.com/bitcoin/bitcoin/pull/2861
340 2014-06-18 21:07:41 <tigereye> That pull request has been closed and it seems like the feature wasn't added. THere is talk in the discussion of that PR about making watch-only *wallets* rather than adding watch-only *addresses* to a wallet...
341 2014-06-18 21:08:21 <tigereye> I'm wondering if watch-only wallet functionality was added to Bitcoin core instead? If so, does this feature give the user the ability to tell bitcoind to watch an address?
342 2014-06-18 21:08:58 <tigereye> like... with the latest-greatest bitcoind code, can I set up a keyless bitcoind that will call txnotify whenever a transaction occurrs that involves one or more particular addresses?
343 2014-06-18 21:09:10 <tigereye> Thanks for any insight you can give on this Q :)
344 2014-06-18 23:09:19 <GAit> banks are really changing their mind about btc
345 2014-06-18 23:15:36 <GAit> unrelated: JS is faster than Java for BIP32 ops + signing after profiling (tested on LG L5, 18 secs with java and 10 secs with JS) - then I found this http://www.stefankrause.net/wp/?p=144 that says "Once again: V8 is much faster than Dalvik and easily within a range of 2 to C!"
346 2014-06-18 23:33:22 <people> hey, is there alredy pool soft that grant to the miners controll over if they are not a part of double spending attempt?
347 2014-06-18 23:34:02 <GAit> people: not that i know of and if it exists is not in the wild
348 2014-06-18 23:36:39 <people> you mean internet?
349 2014-06-18 23:36:43 <gmaxwell> If there are no objections I'm going to set this channel to quiet anyone who is currently banned in #bitcoin or in #bitcoin-global-bans (a new freenode feature makes this possible). I intend to use global bans for crapflooding and such.
350 2014-06-18 23:36:55 <gwillen> gmaxwell: +1
351 2014-06-18 23:37:12 <gmaxwell> people: P2pool exists and is used by a non-trivial number of people, and gives miners complete control over their own work.
352 2014-06-18 23:37:14 <xabbix> I'm getting the 'OpenSSL appears to lack support for elliptic curve cryptography.' message after building the bitcoind executable. I'm going to install OpenSSL from the source, but I don't know how to define the bitcoin ./configure file to take the openssl files from the compiled source.. any ideas?
353 2014-06-18 23:40:59 <people> complete seems unlike because they may want to send fail hashes to the pool to participate in common sallary and at the same time send good hashes to the net by them selfs
354 2014-06-18 23:41:35 <gmaxwell> people: no. No mining works in a way where that is possible.
355 2014-06-18 23:41:46 <gmaxwell> This conversation should be in #bitcoin.
356 2014-06-18 23:42:33 <GAit> gmaxwell: can I ask you out of curiosity what you are working on?
357 2014-06-18 23:47:29 <kazcw> xabbix: I think you just need to configure with --libdir and --includedir pointing to the compiled openssl. you on a redhad derivative?
358 2014-06-18 23:48:53 <xabbix> kazcw, Yes, CentOS