1 2015-07-01 00:01:18 <CodeShark> settlement costs aren't entirely predictable, though
  2 2015-07-01 00:01:19 <leakypat> petertodd: so I can assume when any of the transaction set is included in a block, the rest of the transactions in the set are no longer out there in anyone's mem pool
  3 2015-07-01 00:01:39 <petertodd> leakypat: er... assume for what purpose? :P
  4 2015-07-01 00:01:40 <CodeShark> you need to have a settlement strategy that protects you from uncooperative counterparties...but there are many ways to allocate the risk
  5 2015-07-01 00:02:39 <leakypat> Because I am tracking all the transactions broadcast from my wallet related to the outputs being sent
  6 2015-07-01 00:03:06 <leakypat> So that could be 10 RBF attempts on the same txins
  7 2015-07-01 00:03:41 <leakypat> Once anyone of those 10 gets included in a block, I can consider the other 9 toast
  8 2015-07-01 00:03:57 <leakypat> But before that point any one of the 10 could be included in a block
  9 2015-07-01 00:04:20 <leakypat> As I don't 100% know what miners have what tx in their mem pools
 10 2015-07-01 00:04:40 <petertodd> leakypat: ah, yeah, I think that's fine
 11 2015-07-01 00:05:02 <petertodd> leakypat: main thing is don't 100% rely on it, e.g. in certain reorg scenarios one of the other txs could end up in the blockchain again
 12 2015-07-01 00:05:40 <phantomcircuit> leakypat, for a wallet you should keep conflicting transactions for like say 100 confirmations
 13 2015-07-01 00:05:47 <phantomcircuit> then it's safe to throw them away
 14 2015-07-01 00:06:42 <petertodd> phantomcircuit: nah, wait until the devs create an Official Checkpoint™
 15 2015-07-01 00:09:03 <phantomcircuit> petertodd, lolin
 16 2015-07-01 00:10:16 <leakypat> phantomcircuit: are you running RBF on your testnet miners now?
 17 2015-07-01 00:11:13 <phantomcircuit> leakypat, maybe? i've restarted that a bunch of times
 18 2015-07-01 00:11:15 <phantomcircuit> let me check
 19 2015-07-01 00:11:30 <leakypat> I ordered an S5 yesterday so I can join in :0
 20 2015-07-01 00:11:41 <leakypat> Assuming my transactions ever confirm :(
 21 2015-07-01 00:11:56 <phantomcircuit> i think so
 22 2015-07-01 00:12:21 <leakypat> phantomcircuit: cool
 23 2015-07-01 01:42:27 <leakypat> Does antpool support  CPFP?
 24 2015-07-01 02:00:20 <Luke-Jr> leakypat: OT, ask them
 25 2015-07-01 04:54:21 <wiz> is there a channel for bitcoin.org discussion?
 26 2015-07-01 04:57:25 <wiz> i forked bitcoin.org for bitcoin.com and bitcoin.jp - would be nice to discuss with the other maintainers on site development
 27 2015-07-01 05:01:01 <wiz> we added some promoted listings for wallets and exchanges, also added a news section bitcoin.com/news
 28 2015-07-01 05:15:53 <Luke-Jr> wiz: here is fine
 29 2015-07-01 05:16:50 <Luke-Jr> "added" means you removed all the real wallets? O.o
 30 2015-07-01 05:17:05 <wiz> you have to click "view all wallets" at the bottom
 31 2015-07-01 05:17:06 <Luke-Jr> actually, for content, #bitcoin is probably better
 32 2015-07-01 05:17:37 <wiz> wallets can donate to the site to become the promoted listing
 33 2015-07-01 05:17:56 <Luke-Jr> yeah, or people will just continue to use bitcoin.org <.<
 34 2015-07-01 05:18:17 <wiz> or maybe bitcoin.com will become the new supreme bitcoin portal? :P
 35 2015-07-01 05:18:44 <Luke-Jr> unlikely if it's just a for-pay-only clone
 36 2015-07-01 05:18:51 <wumpus> move the discussion out of -dev please
 37 2015-07-01 06:33:39 <jonasschnelli> wumpus: May have a look at: https://github.com/jonasschnelli/bitcoin/commit/53a42df076e73c92c49ad579821f126d0a41ff68
 38 2015-07-01 06:33:58 <jonasschnelli> wumpus: i struggle with the base class / abstract class memory management
 39 2015-07-01 06:34:25 <jonasschnelli> i couldn't find a better way than GetScriptForMining(CReserveScript **script).
 40 2015-07-01 06:48:00 <wumpus> jonasschnelli: the idea is ok, please use RAII though, e.g. scoped_ptr for scoped pointers instead of manual deletion
 41 2015-07-01 06:48:41 <wumpus> jonasschnelli: that also saves a lot of noise in catch(...) etc
 42 2015-07-01 06:48:51 <jonasschnelli> wumpus: hmm... the problem is that i can't use RAII (IIRC) because we spin of a boost::thread
 43 2015-07-01 06:49:50 <wumpus> the other alternative is return a boost::shared_ptr<CReserveScript>
 44 2015-07-01 06:50:20 <CodeShark> when are we going to start using std::thread and std::shared_ptr? :)
 45 2015-07-01 06:50:39 <wumpus> jonasschnelli: shared_ptrs are thread safe
 46 2015-07-01 06:50:56 <wumpus> CodeShark: irrelevant here
 47 2015-07-01 06:51:15 <CodeShark> is it?
 48 2015-07-01 06:51:26 <jonasschnelli> wumpus: okay. Let me try it with shared_ptr
 49 2015-07-01 06:51:43 <CodeShark> I think it's a pretty relevant development question...but perhaps orthogonal to jonas' issue :)
 50 2015-07-01 06:51:46 <wumpus> yes. Using the std:: instead of boost:: names wouldn't change the design level problems here anything
 51 2015-07-01 06:51:55 <wumpus> you're just adding noise :P
 52 2015-07-01 06:51:59 <CodeShark> right, that's what I meant to say :p
 53 2015-07-01 06:52:37 <wumpus> there is an issue about moving to C++11, please comment there if that's your interest
 54 2015-07-01 06:53:23 <Luke-Jr> would be nice if GCC would stabilise C++11 support already..
 55 2015-07-01 06:53:46 <wumpus> CodeShark: here:  https://github.com/bitcoin/bitcoin/issues/6211  the fact that I opened it should be enough proof that I don't consider the issue irrelevant for development
 56 2015-07-01 06:54:05 <CodeShark> no, I get it - it wasn't relevant to jonas' problem
 57 2015-07-01 06:54:10 <CodeShark> :)
 58 2015-07-01 06:54:25 <CodeShark> where "here" = jonas' problem
 59 2015-07-01 06:54:47 <wumpus> sorry, the heat is getting to my head, things boiling over
 60 2015-07-01 06:58:19 <CodeShark> GCC should finish stabilizing C++11 right around the time that C++23 is released :p
 61 2015-07-01 06:59:44 <midnightmagic> lol
 62 2015-07-01 06:59:51 <wumpus> well it's open source, feel free to help them :)
 63 2015-07-01 07:00:19 <wumpus> arguably we already get a lot more than we pay for
 64 2015-07-01 07:02:12 <CodeShark> oh, I'm not really complaining - I use what I can copiously in other projects :)
 65 2015-07-01 07:03:09 <CodeShark> supporting old compilers is a bitch - for some projects I just say tough :p
 66 2015-07-01 07:03:13 <wumpus> I agree, instead of discussing full c++11 versus no c++11 it would be more constructive to agree on a list of c++11 features
 67 2015-07-01 07:03:27 <wumpus> compilers have broken up the standard, so why not we
 68 2015-07-01 07:04:05 <Luke-Jr> wumpus: https://gcc.gnu.org/wiki/Cxx11AbiCompatibility suggests compiling with C++11 basically means we can't use any C++ libraries with std::map etc..
 69 2015-07-01 07:04:21 <CodeShark> you need to use compatible stdlibs
 70 2015-07-01 07:04:34 <CodeShark> but as long as you do you can use all your favorite containers
 71 2015-07-01 07:05:08 <Luke-Jr> CodeShark: you need all the libraries compiled with C++11 or avoiding those containers
 72 2015-07-01 07:05:27 <wumpus> Luke-Jr: are you sure about that? just compiling them with the same compiler isn't enough?
 73 2015-07-01 07:05:41 <wumpus> Luke-Jr: I know there are 5.0 versus 4.x ABI issues, but never heard that
 74 2015-07-01 07:06:02 <Luke-Jr> wumpus: the internal data structure is different :<
 75 2015-07-01 07:06:13 <CodeShark> on many platforms the stdlibs are completely reimplemented for C++11
 76 2015-07-01 07:06:27 <Luke-Jr> CodeShark: if it was just the stdlibs, things would be easy
 77 2015-07-01 07:06:45 <wumpus> anyhow, this seems like something we can never decide it, even if c++11 was to be finalized it will take years for that version of g++ to be in common use
 78 2015-07-01 07:07:08 <CodeShark> I think as you were saying we could pull out a few widely supported features and use those
 79 2015-07-01 07:07:09 <Luke-Jr> but is Debian going to ship a C++11 ABI boost, if they have other software that won't compile as C++11 that needs boost? probably not :|
 80 2015-07-01 07:07:45 <Luke-Jr> CodeShark: as soon as we compile with C++11, we get these ABI problems
 81 2015-07-01 07:07:50 <wumpus> Luke-Jr: so you are saying that on Debian/Ubuntu a c++11 program cannot use boost/Qt?
 82 2015-07-01 07:08:01 <wumpus> Luke-Jr: that's weird.I'm fairly sure I have seen some
 83 2015-07-01 07:08:11 <CodeShark> you can use boost/Qt...but
 84 2015-07-01 07:08:11 <Luke-Jr> wumpus: I suspect Qt is fine, since it doesn't use C++ stdlib much
 85 2015-07-01 07:08:22 <CodeShark> they need to be built using the correct stdlib
 86 2015-07-01 07:08:29 <CodeShark> if you use any features in them that use the stdlib
 87 2015-07-01 07:08:30 <wumpus> CodeShark: but Luke-Jr claims that they aren't
 88 2015-07-01 07:08:57 <wumpus> I find that strange. Would be easy to experimentally check this, I think I"m going to do  that later
 89 2015-07-01 07:09:02 <CodeShark> I believe the packages installed depend on your gcc version
 90 2015-07-01 07:09:06 <wumpus> e.g. build bitcoin on my 14.04 with -std=c++11
 91 2015-07-01 07:09:20 <CodeShark> I haven't had a problem on ubuntu 14.04 using gcc4.8
 92 2015-07-01 07:09:27 <Luke-Jr> wumpus: that's a bad test IMO, at least if you want to show success
 93 2015-07-01 07:09:32 <CodeShark> gcc4.6 might have a few issues
 94 2015-07-01 07:09:39 <Luke-Jr> seems likely to get a repeat of that 0.4.0 bug
 95 2015-07-01 07:09:45 <wumpus> Luke-Jr: how is it a bad test? its *the* test, if the tests pass
 96 2015-07-01 07:10:34 <Luke-Jr> wumpus: it could be we just lack the test needed to find the problem
 97 2015-07-01 07:11:14 <wumpus> that's always possible.
 98 2015-07-01 07:11:48 <wumpus> ... building
 99 2015-07-01 07:16:14 <Luke-Jr> it looks like LLVM's libc++ may not have this problem FWIW
100 2015-07-01 07:16:25 <wumpus> "This makes it dangerous to link C++98 objects with C++11 objects", nothing about the other way around
101 2015-07-01 07:19:16 <wumpus> (unless that is somehow implied; it's also not updated for 4.8+)
102 2015-07-01 07:19:45 <wumpus> build gets: libbitcoin_wallet.a(libbitcoin_wallet_a-walletdb.o): In function `BackupWallet(CWallet const&, std::string const&)':  walletdb.cpp:(.text+0x402a): undefined reference to `boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option, boost::system::error_code*)'
103 2015-07-01 07:20:09 <Luke-Jr> well, at least it's a link error
104 2015-07-01 07:21:08 <Luke-Jr> I wonder if we can depend on GCC catching all such problems at compile/link time.. it'd make avoiding them easier at least
105 2015-07-01 07:21:53 <wumpus> so this could indeed be caused by ABI mismatch
106 2015-07-01 07:22:33 <wumpus> for releases this doesn't have  to be a problem, we statically link libstdc++ as well as boost and qt
107 2015-07-01 07:22:42 <wumpus> but for people manually compiling it's a nightmare
108 2015-07-01 07:23:05 <CodeShark> right, wumpus - and that makes it a pretty good argument not to go all out on this right now
109 2015-07-01 07:23:15 <wumpus> it makes a good argument to ignore c++11 completely
110 2015-07-01 07:23:26 <Luke-Jr> I wonder if there's a way to ask GCC/LLVM to give us everything C++11 it can without changing ABI :x
111 2015-07-01 07:23:34 <wumpus> (there is no -std=abitofc++11)
112 2015-07-01 07:23:48 <wumpus> right that' what I mean Luke-Jr
113 2015-07-01 07:23:52 <CodeShark> well, the flipside is that C++11 does provide at least a few nice features that are worth the compiler support issues for certain applications :)
114 2015-07-01 07:24:07 <CodeShark> but perhaps not this one
115 2015-07-01 07:24:26 <wumpus> it would only work if we can, at the same time, get rid of boost completely, but then we're still stuck with Qt (but maybe that one's less of an issue)
116 2015-07-01 07:24:50 <wumpus> e.g. Qt doesn't generally pass std:: types on the ABI
117 2015-07-01 07:24:53 <CodeShark> asio isn't part of std yet, is it? :)
118 2015-07-01 07:25:10 <wumpus> no, but we want to switch to e.g. libevent
119 2015-07-01 07:25:11 <Luke-Jr> CodeShark: asio isn't working very nicely anyway <.<
120 2015-07-01 07:25:24 <wumpus> I have code that switches over RPC
121 2015-07-01 07:25:36 <CodeShark> it works pretty well when used properly - I'm not sure we're using it properly
122 2015-07-01 07:25:36 <wumpus> and the P2P uses our own-wrapped network functions not asio
123 2015-07-01 07:27:05 <wumpus> here: eventually using libevent for the P2P networking would make sense too, it is much more optimized and has built-in bandwidth controls and such, but
124 2015-07-01 07:27:11 <jonasschnelli> request for assistance: https://github.com/jonasschnelli/bitcoin/commit/1ccd7f0920117b7693035f78f235aeb4f3f48af7
125 2015-07-01 07:27:16 <wumpus> eh https://github.com/bitcoin/bitcoin/pull/5677
126 2015-07-01 07:27:29 <jonasschnelli> i have changed it to boost::shared_ptr, but now i have a mem leak...
127 2015-07-01 07:27:51 <jonasschnelli> and if i pass the boost::shared_ptr to boost::thread, it never get deconstructed.
128 2015-07-01 07:27:54 <wumpus> the code looks much better now, at least
129 2015-07-01 07:28:33 <wumpus> strange that you get a memory leak, wonder where it happens, maybe a thread doesn't get joined properly so it has no chance to unroll the stack?
130 2015-07-01 07:28:34 <jonasschnelli> yeah. Code looks better. But somehow i miss a part. I have to admit i don't have exp. with shared pointers.
131 2015-07-01 07:28:52 <wumpus> in any case I don't see any apparent problems at first glance
132 2015-07-01 07:28:56 <CodeShark> as long as you didn't make any copies it should be deallocated by destructor
133 2015-07-01 07:29:03 <jonasschnelli> I even get a memory leak over "generate" (where no threads gets kicked off)
134 2015-07-01 07:29:16 <CodeShark> but you might want to look into the make_shared method
135 2015-07-01 07:29:24 <CodeShark> although I don't think that's the problem here
136 2015-07-01 07:29:30 <jonasschnelli> i think the problematic part is this: https://github.com/jonasschnelli/bitcoin/commit/1ccd7f0920117b7693035f78f235aeb4f3f48af7#diff-b2bb174788c7409b671c46ccc86034bdR2593
137 2015-07-01 07:30:11 <jonasschnelli> i pass a shared pointer by ref, than re-pointing to a new shared pointer. Maybe this is wrong...
138 2015-07-01 07:30:15 <wumpus> uhm
139 2015-07-01 07:30:31 <wumpus> should be fine
140 2015-07-01 07:30:52 <CodeShark> passing by reference is fine as long as we're in the same thread
141 2015-07-01 07:30:56 <wumpus> that's what shared pointers are supposed to be able to do, you can copy them around, as long as you copy the pointer
142 2015-07-01 07:31:18 <wumpus> so script=rKey will increase the refcount by one
143 2015-07-01 07:31:34 <wumpus> then the destructor of rKey at the end of the function will decrease it by one again
144 2015-07-01 07:32:03 <wumpus> when refcount reaches zero, the underlying object is deallocated
145 2015-07-01 07:32:25 <jonasschnelli> wumpus: are you sure that it decreases at the end of the function? I have initialized it with boost::shared_ptr<CReserveKey> rKey(new CReserveKey(this));
146 2015-07-01 07:32:26 <wumpus> jonasschnelli: OH I see the problem
147 2015-07-01 07:32:33 <jonasschnelli> that sounds good
148 2015-07-01 07:32:38 <wumpus> jonasschnelli: void static BitcoinMiner(const CChainParams& chainparams, const boost::shared_ptr<CReserveScript> &coinbaseScript)
149 2015-07-01 07:32:48 <wumpus> that should be boost::shared_ptr<CReserveScript> coinbaseScript
150 2015-07-01 07:32:50 <wumpus> not a reference
151 2015-07-01 07:32:58 <jonasschnelli> hmm... let me try
152 2015-07-01 07:33:01 <wumpus> don't use a reference to a shared pointer for the thread function
153 2015-07-01 07:33:14 <wumpus> (or in general when passing thread barriers, as CodeShark says already)
154 2015-07-01 07:33:24 <wumpus> it's a pointer, just use it as a pointer
155 2015-07-01 07:34:16 <wumpus> normally you wouldn't make references to pointers either, unless you intend to change the value in eg. an out parameter
156 2015-07-01 07:34:34 <jonasschnelli> wumpus: That makes sense. But when passing it through the signal, i need to pass it by ref. because the signal listener needs the ability to re-point to a new shared pointer?
157 2015-07-01 07:35:06 <wumpus> jonasschnelli: that's what I mean with 'out parameters', yes. There is no thread barrier there so no issue.
158 2015-07-01 07:39:07 <Luke-Jr> jonasschnelli: https://github.com/bitcoin/bitcoin/pull/5314 new icon yet? :P
159 2015-07-01 07:39:21 <jonasschnelli> still detecting leaks, no deconstructor call over the thread.
160 2015-07-01 07:39:59 <wumpus> jonasschnelli: what is the new code?
161 2015-07-01 07:40:31 <jonasschnelli> wumpus: https://github.com/jonasschnelli/bitcoin/commit/c2d1c630f057fe02c608d6e1e0dee1e5e108928d
162 2015-07-01 07:41:24 <jonasschnelli> Luke-Jr: right. It requires a new icon. But it seems to be a controversial PR
163 2015-07-01 07:41:35 <wumpus> looks perfectly ok to me now
164 2015-07-01 07:42:14 <jonasschnelli> Yeah. It should be fine. But somehow the deconstrutor is not getting called. This seems to be wrong.
165 2015-07-01 07:42:28 <Luke-Jr> jonasschnelli: eh, I don't see anyone objecting to it, just suggesting how to improve it
166 2015-07-01 07:43:11 <jonasschnelli> Luke-Jr: gmaxwell commented with : "The "toggle" rpc is a bad interface."
167 2015-07-01 07:43:52 <Luke-Jr> jonasschnelli: yes, it should be a "set" interface..
168 2015-07-01 07:44:20 <Luke-Jr> jonasschnelli: eg, networkonline(true/false)
169 2015-07-01 07:44:23 <wumpus> we need bandwidth limiting, not chopping it off completely, although an option to disable serving blocks may be nice
170 2015-07-01 07:44:41 <CodeShark> yes, that would be a great feature
171 2015-07-01 07:44:41 <jonasschnelli> Luke-Jr: Yes. A set is much better. Agreed. But i think there are concerns that disabling net. activity can do harm to the network.
172 2015-07-01 07:45:04 <wumpus> (although pruning effectively does that, now)
173 2015-07-01 07:45:07 <Luke-Jr> … the user can disable it by exiting already; this is just friendlier
174 2015-07-01 07:45:17 <jonasschnelli> Yes. I thought reopening the PR with a option to disable block relaying.
175 2015-07-01 07:45:30 <CodeShark> a better solution would be to just throttle the bandwidth
176 2015-07-01 07:45:33 <CodeShark> IMO
177 2015-07-01 07:45:33 <wumpus> jonasschnelli: relaying recent blocks would be ok
178 2015-07-01 07:45:45 <Luke-Jr> when I am using 3G for my connection, I'd want to turn off all network activity
179 2015-07-01 07:45:46 <wumpus> jonasschnelli:  just stop serving historical blocks
180 2015-07-01 07:46:02 <wumpus> CodeShark: yes, that's sepearetely useful
181 2015-07-01 07:46:04 <jonasschnelli> wumpus: Ah. Right. So you mean >288 = don't relay.
182 2015-07-01 07:46:25 <jonasschnelli> s/>288/older then 288
183 2015-07-01 07:46:30 <wumpus> jonasschnelli: I don't know. Maybe right now, completely disabling block relay is better, as there is no feature bit between NODE_NETWORK and nothing
184 2015-07-01 07:46:50 <jonasschnelli> Agreed.
185 2015-07-01 07:47:05 <Luke-Jr> so maybe it should be networkcontrol(disabled/relay/server)
186 2015-07-01 07:47:20 <CodeShark> you can set a filter :)
187 2015-07-01 07:47:21 <wumpus> with NODE_NETWORK, nodes expect to be able to request any block
188 2015-07-01 07:47:43 <jonasschnelli> how do we deal with that problem for pruned nodes?
189 2015-07-01 07:47:43 <wumpus> without it, nodes won't request any, and it wouldn't make sense either
190 2015-07-01 07:47:52 <wumpus> pruned nodes don't realy blocks at all
191 2015-07-01 07:47:59 <wumpus> so they're already in disabled mode
192 2015-07-01 07:48:11 <CodeShark> indeed
193 2015-07-01 07:48:12 <jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/6148
194 2015-07-01 07:48:27 <Luke-Jr> ideally disabled/client/relay/server would at least be options
195 2015-07-01 07:48:50 <wumpus> jonasschnelli: I think there is no point merging that right now, without change to the P2P protocol
196 2015-07-01 07:49:17 <Luke-Jr> isn't 6148 just about relaying new blocks?
197 2015-07-01 07:49:26 <Luke-Jr> service bits are ignored if you inv a block, right?
198 2015-07-01 07:49:38 <wumpus> ok, in that case it's a different issue, yes
199 2015-07-01 07:52:37 <wumpus> jonasschnelli: are the miner threads ever joined?
200 2015-07-01 07:54:40 <wumpus> also; now we're passing the same CReserveScript to all miner threads. Is CReserveScript thread safe internally?
201 2015-07-01 07:55:34 <jonasschnelli> No... i don't see a joining. Right. Let me investigate...
202 2015-07-01 07:55:38 <CodeShark> shouldn't that structure be made immutable?
203 2015-07-01 07:56:04 <wumpus> you know what, maybe this was the wrong turn in the first place, I thought the miner requested a coinbase script for each new block
204 2015-07-01 07:56:23 <wumpus> it seems you are requesting one key at the beginning of mining, and using that for every block after that
205 2015-07-01 07:56:29 <jonasschnelli> thought the same. :)
206 2015-07-01 07:56:55 <jonasschnelli> Okay. Will change it that way.
207 2015-07-01 07:56:58 <wumpus> eh
208 2015-07-01 07:57:14 <wumpus> that depends: is this new behavior or was this already the case?
209 2015-07-01 07:57:36 <jonasschnelli> At the moment i use one key for all threads...
210 2015-07-01 07:57:36 <wumpus> I'm thoroughly confused
211 2015-07-01 07:57:48 <wumpus> but did you decide to do that? or was that already the case before your pull?
212 2015-07-01 07:57:54 <jonasschnelli> i think we should change it that it requests a script per thread...
213 2015-07-01 07:58:45 <jonasschnelli> Before this PR it was done over CreateNewBlockWithKey(), so every thread did got his own CReserveKey
214 2015-07-01 07:58:45 <wumpus> no: old behavior was to request a CReservScripty per thread
215 2015-07-01 07:58:52 <wumpus> let's keep that
216 2015-07-01 07:59:06 <wumpus> Luke-Jr: yeah....
217 2015-07-01 07:59:39 <wumpus> it's a waste of effort, really, the internal miner is useless for anything besides regtest mining, which doesn't use a therad
218 2015-07-01 07:59:53 <Luke-Jr> jonasschnelli: throw a few lines of libcurl around libblkmaker's example.c?
219 2015-07-01 08:00:00 <wumpus> regtest doesn't use the miner as such, it has a much simplified path in `generate`
220 2015-07-01 08:00:25 <jonasschnelli> wumpus: what about removing the mining thread (setgenerate and -gen) in this PR? to much?
221 2015-07-01 08:00:28 <wumpus> in any case, generating blocks for regtest from pyton would also be easy
222 2015-07-01 08:00:36 <wumpus> jonasschnelli: nah
223 2015-07-01 08:00:56 <wumpus> jonasschnelli: let's not swing ideas too wildly, let's just fix up this PR
224 2015-07-01 08:01:00 <CodeShark> yeah, seriously - for tests you can generate the data however you want
225 2015-07-01 08:01:13 <jonasschnelli> ok
226 2015-07-01 08:01:13 <wumpus> jonasschnelli: we can remove it later, otherwise the pull will be again in limbo for >3 months
227 2015-07-01 08:01:19 <jonasschnelli> haha
228 2015-07-01 08:03:32 <wumpus> so a) every thread should get its own reserve key, like before. This avoids all thread issues as long as GetScriptForMining is thread-safe (which it must be, anyhow). b)  we need to make sure miner threads are actually joined at shutdown
229 2015-07-01 08:03:57 <wumpus> should be a relatively easy change then we can wrap this up
230 2015-07-01 08:04:38 <CodeShark> if the data doesn't change once the thread is spawned make it an immutable structure
231 2015-07-01 08:04:51 <CodeShark> then you can be sure you'll never have contention or memory access issues
232 2015-07-01 08:04:52 <CodeShark> :)
233 2015-07-01 08:06:15 <CodeShark> using a shared ptr is a completely unnecessary synchronization overhead
234 2015-07-01 08:06:17 <wumpus> it will change, e.g. at the least the 'used' bit will be set
235 2015-07-01 08:06:26 <wumpus> or the key will be returned
236 2015-07-01 08:06:29 <jonasschnelli> Okay. Looks good now: https://github.com/jonasschnelli/bitcoin/commit/cc304ec8fe69bd8520213db5d6673884670822f1
237 2015-07-01 08:06:32 <wumpus> please don't derail this
238 2015-07-01 08:08:49 <jonasschnelli> However my leaks detector still tells me that i leak a CWalletTx (probably the coinsbase transaction)
239 2015-07-01 08:09:20 <jonasschnelli> But i have to admit i'm using the "Steve Jobs" under the leaks detector. The UI looks good, but somehow it does detect strange non-leaks sometimes.
240 2015-07-01 08:10:34 <jonasschnelli> if there was a such leak, it was also there before this PR (bad excuse i know).
241 2015-07-01 08:11:03 <wumpus> yes, I wouldn't be too worried about it
242 2015-07-01 08:12:27 <jonasschnelli> Luke-Jr: regarding https://github.com/bitcoin/bitcoin/pull/5314 , i don't thing it's worth investigating more into this direction,... or at least i don't know in which direction it should go.
243 2015-07-01 08:14:54 <wumpus> cumulative memory leaks are serious problems, and none of that can occur in this case
244 2015-07-01 08:15:29 <wumpus> (as only one per thread is allocated in the first place)
245 2015-07-01 08:21:44 <ocb> anyone had such problems when compiling boost? http://pastebin.com/7R6qQngL
246 2015-07-01 08:21:52 <ocb> I am getting same error for the last 3 hours
247 2015-07-01 08:22:51 <CodeShark> offtopic, looks like you're missing the python library
248 2015-07-01 08:22:57 <CodeShark> try #boost or something
249 2015-07-01 08:23:13 <ocb> thanks CodeShark for pointing me
250 2015-07-01 08:36:43 <ocb> Installing bitcoin 0.10 on debian = 10 minutes, on centos 6 hours...
251 2015-07-01 08:39:35 <Luke-Jr> ocb: #bitcoin
252 2015-07-01 08:39:52 <ocb> Luke-Jr fixed it: yum install python-devel zlib2-devel
253 2015-07-01 08:40:11 <Luke-Jr> ocb: again, #bitcoin
254 2015-07-01 08:40:18 <ocb> I am there :)
255 2015-07-01 08:40:19 <ocb> ok
256 2015-07-01 08:50:04 <wangchun> We finally did it with block 363270!
257 2015-07-01 08:50:17 <wangchun> 1000000 bytes, 4509 transactions.
258 2015-07-01 08:51:03 <Luke-Jr> wangchun: #bitcoin
259 2015-07-01 08:52:37 <wangchun> Luke-Jr: I was wondering how eligius did it in 2013
260 2015-07-01 09:03:07 <Diablo-D3> wangchun: nice
261 2015-07-01 09:22:45 <ocb> qt/test/../paymentrequestplus.h:8:31: fatal error: paymentrequest.pb.h: No such file or directory
262 2015-07-01 09:23:07 <ocb> v0.10.0 compiling without qt, no protobuf installed
263 2015-07-01 09:23:37 <ocb> centos 6.6
264 2015-07-01 09:25:13 <phantomcircuit> ocb, you mean --without-gui and you still got that error?
265 2015-07-01 09:25:30 <ocb> phantomcircuit: yes Sir
266 2015-07-01 09:25:45 <ocb> tried with and without gui, installed protobuf from source still getting it
267 2015-07-01 09:26:22 <ocb> I will try to configure everything again
268 2015-07-01 09:27:11 <michagogo> ocb: can you pastebin your configure command and output?
269 2015-07-01 09:27:49 <ocb> sure 2min
270 2015-07-01 09:32:18 <ocb> let it just compile until error it's a slow machine
271 2015-07-01 09:52:11 <ocb> looks like it went through now after doing ./configure again. There are a few warning though if somebody wants to check, here is the complete log: http://pastebin.com/fYyd5Sad
272 2015-07-01 10:23:32 <Luke-Jr> wumpus: ⁇? 0.11.0rc3-osx-signed/laanwj/bitcoin-win-signer-build.assert
273 2015-07-01 10:42:05 <wumpus> Luke-Jr: lol did I name it wrong?
274 2015-07-01 10:42:53 <wumpus> probably copy/paste error, will look at it later
275 2015-07-01 10:43:42 <Luke-Jr> wumpus: your signed dirs have two assert files in each :|
276 2015-07-01 10:44:39 <wumpus> at least the gverify script didn't bark, so I got something right
277 2015-07-01 10:52:21 <AmazonStuff> I devs... I made a transaction from my unsynced Bitcoin Core wallet and I changed my mind. As fast as possible I shutdown my wallet. Transaction was not broadcasted. How could I cancel this transaction? Thank you
278 2015-07-01 10:59:45 <wumpus> -zapwallettxes should get rid of any unconfirmed transactions, but make sure you disconnect network etc just to be sure
279 2015-07-01 10:59:47 <AmazonStuff> 0.10.0
280 2015-07-01 11:00:10 <AmazonStuff> Ok, I will try
281 2015-07-01 11:00:13 <kinlo> should have been a question for #bitcoin tough
282 2015-07-01 11:00:34 <wumpus> in 0.11.0rcX you can use -walletbroadcast=0 to prevent wallet broadcasts
283 2015-07-01 11:00:42 <wumpus> kinlo: right
284 2015-07-01 11:01:13 <AmazonStuff> I asked there, but no one replied
285 2015-07-01 11:01:18 <AmazonStuff> sorry guys
286 2015-07-01 11:33:14 <wumpus> wangchun: congrats :)
287 2015-07-01 11:47:24 <jonasschnelli> anybody interested to think about a good way of optimizing the send*/raw* rpc commands?
288 2015-07-01 11:48:31 <jonasschnelli> https://github.com/jonasschnelli/bitcoin/blob/2015/05/corewallet/src/corewallet/corewallet_rpc.cpp#L709
289 2015-07-01 11:48:31 <jonasschnelli> In the new wallet if have started a command called "createtx"
290 2015-07-01 11:49:02 <jonasschnelli> The idea is to aggregate all send commands in one RPC cmd.
291 2015-07-01 11:49:28 <jonasschnelli> because the new wallet allows flexible parameter ordering with key=value notation, this could be possible.
292 2015-07-01 11:50:09 <jonasschnelli> Examples: ./src/bitcoin-cli --regtest corewallet/createtx sendto='{"mw41T1vKHUuaAbvVy7jJXee2msvZvEAgcG":1}' send=1
293 2015-07-01 11:50:29 <jonasschnelli> if send=1 is not there, it will response a hex string (along to the fee)
294 2015-07-01 11:51:09 <jonasschnelli> It could also be extended to allow preexisting vins if one likes to include a certain coin.
295 2015-07-01 11:51:27 <jonasschnelli> But im not sure if one command for all purposes is the best way.
296 2015-07-01 12:09:01 <Belxjander> jonasschnelli: how about using a "queue" and "createbatch" system? where you queue up a group of "N" transactions and send them together as a single TX block?
297 2015-07-01 12:59:35 <jonasschnelli> Belxjander: what about using the RPC batch feature? Not fast enought?
298 2015-07-01 13:04:32 <wumpus> also: sendmany?
299 2015-07-01 13:04:47 <wumpus> instead of generating multiple transactions it's better to generate one with multiple outputs
300 2015-07-01 13:18:17 <Belxjander> jonasschnelli: not really that familiar with the commandset over RPC
301 2015-07-01 13:18:56 <Belxjander> wumpus: I was more thinking...queue a bunch...and then merge them into a single mass-transaction at set intervals over the time of a day
302 2015-07-01 13:53:17 <jonasschnelli> wumpus: Are you sure that g_signals.UpdateRequestCount() is not required? i was adding this signal because of this (https://github.com/bitcoin/bitcoin/pull/5994/files#diff-4a59b408ad3778278c3aeffa7da33c3cL432).
303 2015-07-01 14:00:10 <wumpus> jonasschnelli: look at Inventory. It does exactly the same.
304 2015-07-01 14:00:46 <jonasschnelli> wumpus: okay... will have a look at it
305 2015-07-01 14:02:01 <wumpus> jonasschnelli: well not exactly - Inventory only increases the request count *if* the hash is already in mapRequestCount, UpdateRequestCount always increases it (and adds if necessary) - but if you need that difference in behavior, why not add a flag...
306 2015-07-01 14:02:21 <wumpus> jonasschnelli: but why does the wallet keep track of the request count of block hashes?
307 2015-07-01 14:02:27 <wumpus> jonasschnelli: doesn't it only count about transactions?
308 2015-07-01 14:02:38 <wumpus> s/count/care
309 2015-07-01 14:03:09 <jonasschnelli> wumpus: i didn't follow the request count logic in the GUI... i just wanted to not change it's behaviour
310 2015-07-01 14:03:58 <wumpus> jonasschnelli: oh - you are already changing it!
311 2015-07-01 14:04:17 <wumpus> jonasschnelli: oh wait, no, I see the difference now!
312 2015-07-01 14:04:26 <wumpus> jonasschnelli: UpdateRequestCount *resets* the request count
313 2015-07-01 14:05:05 <jonasschnelli> Ah. Right... so the method name should be changed....
314 2015-07-01 14:05:07 <wumpus> jonasschnelli: I agree we need it, but call it differently please, e.g. ResetRequestCount()
315 2015-07-01 14:05:08 <wumpus> yes
316 2015-07-01 14:05:27 <wumpus> it's the announcement that there is a new block, after which Inventory() will increase it
317 2015-07-01 14:05:45 <wumpus> please also make the argument an uint256 to make it consistent with Inventory
318 2015-07-01 14:07:36 <wumpus> what it means is "wallet, this block is interesting, please keep track of requests for it" - although I wonder where in the UI or other application logic we actually ask the wallet how many times a block is requested
319 2015-07-01 14:08:02 <wumpus> (we do it for transactions in transactiondesc.cpp)
320 2015-07-01 14:10:54 <jonasschnelli> I also think the request count doesn't make that much sense from a end user perspective. But for now we probably should keep it.
321 2015-07-01 14:10:58 <jonasschnelli> Fixed and pushed.
322 2015-07-01 14:28:20 <wumpus> yes, removing it doesn't belong in a refactor
323 2015-07-01 14:30:40 <jonasschnelli> wumpus: but do i understand this correctly: mapRequestCount does keep account of how many nodes did request a certain wtx? This could be used to show how a wtx has been broadcastet?
324 2015-07-01 14:30:45 <jonasschnelli> *broadcasted
325 2015-07-01 14:31:52 <wumpus> jonasschnelli: yes - mapRequestCount keeps track of how many nodes have requested a transaction broadcasted by the wallet. It makes perfect sense to see how widely a transaction was spread, just how it belongs in the miner (expecting it to track blocks) was a surprise to me.
326 2015-07-01 14:32:33 <jonasschnelli> yeah. I don't see how storing/couning block hashed makes sense....
327 2015-07-01 14:32:39 <wumpus> jonasschnelli: but if you look at GetRequestCount() in wallet.cpp it makes sense
328 2015-07-01 14:32:56 <wumpus> jonasschnelli: (it also looks at the request count of the block, for coinbases)
329 2015-07-01 14:33:28 <wumpus> jonasschnelli: yes, the wallet code still holds surprises for me too after all those years
330 2015-07-01 14:33:45 <jonasschnelli> Ah. So if you have mined a block you can see how many nodes did request the coinbase transaction...
331 2015-07-01 14:34:15 <wumpus> * you can see how many nodes have requested the block, by looking at the "transaction details" of the coinbase transaction
332 2015-07-01 14:34:39 <jonasschnelli> Ah. Right....
333 2015-07-01 14:39:23 <coderwill> hello all, would appreciate it if anyone has time, to help out on this issue with bitcoin.org: https://github.com/bitcoin-dot-org/bitcoin.org/issues/928  - basically, roger ver is allowing bitcoin.com to be used to duplicate bitcoin.org and phish people into luxstack and blockchain.info (omitting no doubt hundreds of audit hours our awesome contributor craig
334 2015-07-01 14:39:23 <coderwill> watkins has put into the site)
335 2015-07-01 14:40:03 <coderwill> ...probably would take 2-3 minutes max to help out.
336 2015-07-01 14:40:11 <coderwill> cheers and hope you all have nice days/evenings.
337 2015-07-01 14:45:10 <jonasschnelli> coderwill: did you twitter R. Ver?
338 2015-07-01 14:48:10 <coderwill> jonasschnelli: I messaged him on Skype.
339 2015-07-01 14:53:54 <wumpus> coderwill: yes, it's awful that he's just copying bitcoin.org with a few changes :s
340 2015-07-01 14:54:09 <coderwill> jonasschnelli: He's well aware of what the site looks like. He owns the domain and other than replicating almost all of the Bitcoin.org content, he has removed every web and mobile wallet on the Choose Your Wallets page except for those he is invested in.
341 2015-07-01 14:54:38 <coderwill> wumpus: yeah can't believe it
342 2015-07-01 14:54:40 <wumpus> I don't think anything can be done legally - MIT license allows it - but it's awfully fishy
343 2015-07-01 14:56:30 <wumpus> oops this discussion belongs in #bitcoin not -dev
344 2015-07-01 14:56:57 <coderwill> ok
345 2015-07-01 15:03:55 <btcdrak> 95.4% version 3 blocks in the last 288 blocks!
346 2015-07-01 18:42:09 <C-Otto> bip66?
347 2015-07-01 19:14:31 <jonasschnelli> C-Otto: Yes. bip66 = version3 blocks.
348 2015-07-01 19:15:01 <denisx> did the change happen already?
349 2015-07-01 19:18:07 <gmaxwell> denisx: by change you mean what precisely?
350 2015-07-01 19:18:53 <denisx> block version 2 will not be accepted anymore
351 2015-07-01 19:19:11 <gmaxwell> denisx: no, not yet.
352 2015-07-01 19:19:36 <gmaxwell> minimum of 150 more v3 blocks are required to make v2 orphaned.
353 2015-07-01 19:53:07 <cfields> jgarzik: around, by chance?
354 2015-07-01 19:53:19 <jgarzik> cfields, da
355 2015-07-01 19:53:32 <cfields> jgarzik: off-topic question, mind if i pm?
356 2015-07-01 19:53:55 <jgarzik> cfields, I suppose
357 2015-07-01 21:36:02 <TD-Linux> anyone have opinions on lazy initialization of libsecp256k1 context?
358 2015-07-01 21:36:31 <TD-Linux> it seems like a bad idea but I'm not sure how much of a bad idea