1 2015-07-27 05:31:57 <wumpus> testnet's block chain is protected by "proof of cheating", sort of
  2 2015-07-27 05:37:14 <phantomcircuit> wumpus, i've been ~100% of testnet for long periods of time
  3 2015-07-27 05:37:28 <wumpus> a new, improved alternative to "proof of work" which has been shown to be a much better match to human psychology
  4 2015-07-27 05:37:33 <wumpus> phantomcircuit: hah
  5 2015-07-27 05:39:40 <phantomcircuit> wumpus, im basically the reason testnet is ~150k blocks ahead of mainnet
  6 2015-07-27 05:41:27 <wumpus> collecting fool's gold?
  7 2015-07-27 05:42:55 <Newyorkadam> what’s the testnet/btc or usd exchange rate
  8 2015-07-27 05:43:07 <Newyorkadam> is that even a thing?
  9 2015-07-27 05:43:22 <wumpus> absolute zero
 10 2015-07-27 05:43:33 <Newyorkadam> every single one is worth $0?
 11 2015-07-27 05:43:38 <Newyorkadam> how do people even obtain them
 12 2015-07-27 05:43:53 <wumpus> by publishing proof of cheating
 13 2015-07-27 05:44:05 <arubi> :)
 14 2015-07-27 05:44:43 <Newyorkadam> Oh, I see
 15 2015-07-27 05:47:50 <phantomcircuit> Newyorkadam, would you like one?
 16 2015-07-27 05:47:55 <phantomcircuit> i can spare a million or so
 17 2015-07-27 05:48:04 <Newyorkadam> are you kidding
 18 2015-07-27 05:48:07 <phantomcircuit> no
 19 2015-07-27 05:48:10 <Newyorkadam> is it still 21mil cap?
 20 2015-07-27 05:48:25 <phantomcircuit> yes
 21 2015-07-27 05:48:41 <phantomcircuit> 1115269.00385679
 22 2015-07-27 05:48:41 <phantomcircuit> bitcoin-cli -testnet getbalance
 23 2015-07-27 05:50:06 <Newyorkadam> how is testnet worth nothing
 24 2015-07-27 05:50:10 <Newyorkadam> not even pennies
 25 2015-07-27 05:50:20 <wumpus> plaease move this to #bitcoin
 26 2015-07-27 05:50:27 <leakypat> Because I value it at 0
 27 2015-07-27 08:39:58 <jonasschnelli> do i understand the correct, that most rpcwallet.cpp locks like LOCK2(cs_main, pwalletMain->cs_wallet); locking cs_main to avoid deadlocks? Most calls further down lock cs_main anyway, but i assume keeping the LOCKORDER is importnatn.
 28 2015-07-27 08:46:08 <wumpus> yes
 29 2015-07-27 08:47:47 <wumpus> most wallet queries and operations require access to the block data structures in main in one way or another, so grabbing the locks at once avoids deadlocks
 30 2015-07-27 08:49:15 <jonasschnelli> What would be a good approach to avoid locking cs_main from the wallet? Process separation together with a async. block data structure API?
 31 2015-07-27 08:49:46 <jonasschnelli> or the wallet could build it's own header chain with the existing signals.
 32 2015-07-27 08:52:52 <wumpus> the second - I think the wallet should avoid, as much as possible, accessing main's data structures, and just store what it needs itself when the signals come in
 33 2015-07-27 08:54:49 <jonasschnelli> Yes. Makes sense. In case of reorgs i assume the relevant SyncTransaction() signals will come in, so the wallet itself really don't need to handle reorg detecting.
 34 2015-07-27 08:55:09 <wumpus> right, the wallet is notified when the tip changes, and should handle it then
 35 2015-07-27 08:56:37 <wumpus> (those are the cases where it does make sense to hold both the main lock and the wallet lock, as it explicitly needs access to both data structures. Though, it may be possible to avoid holding both locks *at once*, I don't know)
 36 2015-07-27 08:56:55 <wumpus> but if you need both locks make sure that you get cs_main first
 37 2015-07-27 08:57:39 <jonasschnelli> Yes. While working on the new wallet, i recognized that cs_main must be locked first.
 38 2015-07-27 08:58:00 <wumpus> the wallet *queries* on the other hand it would be very nice if they could do without cs_main locking
 39 2015-07-27 08:58:54 <jonasschnelli> wumpus: Yes. I try to achieve this... probably by having a header-chain somewhere within the wallet space.
 40 2015-07-27 08:59:15 <wumpus> are you sure you need that at all?
 41 2015-07-27 09:00:45 <wumpus> ok, maybe for 'how deep is this in the chain' queries
 42 2015-07-27 09:01:55 <wumpus> it'd be overkill if you'd have to replicate the entire header chain in the wallet, just to avoid some locking
 43 2015-07-27 09:03:04 <jonasschnelli> Yea. I think mostly AddToWallet (https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L616) requires more than the depth... but need to analyze in depth what the functions really does with the mapBlockIndex
 44 2015-07-27 09:03:13 <jonasschnelli> something with time calculation
 45 2015-07-27 09:03:47 <jonasschnelli> I think the only realevant point is https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L676
 46 2015-07-27 09:07:46 <jonasschnelli> And somehow the depth calculation of a wtx must be different. Currently it locks cs_main https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L2823 which is really bad IMO
 47 2015-07-27 09:12:43 <wumpus> but AddToWallet is invoked by signals coming from main, using main data structures is okay thre
 48 2015-07-27 09:14:56 <wumpus> yes, the "number of confirmations" computation is the most (only?) problematic one
 49 2015-07-27 09:15:00 <jonasschnelli> AddToWallet is called when you syncTransaction() (one that involves you) or when you commit a transaction or when you open/load a wallet.
 50 2015-07-27 09:15:05 <jonasschnelli> IMO it should not lock cs_main
 51 2015-07-27 09:15:37 <wumpus> well let's see it like this: it is quite a rare function to be called
 52 2015-07-27 09:15:57 <jonasschnelli> Yes. "Numer of Confirmations" could be calculated if we keep a height in every wtx and handle disconnectTips() reorgs correctly
 53 2015-07-27 09:16:37 <wumpus> but that'd be a lot of overhead, having to go over every transaction on new block arrival / reorg
 54 2015-07-27 09:18:33 <jonasschnelli> wumpus: would it not be sufficient to check if "new" blocks height is below/equals wallets bestblock height and only re-calculate down the required block height?
 55 2015-07-27 09:18:37 <wumpus> storing the height on the transactions themselves and keeping it updated isn't a scalable solution. It'd, at most, work if you add a threshold between say, 'permanent' >100 deep in the chain transactions and 'live' <100 deep ones, and only update the second set
 56 2015-07-27 09:18:47 <jonasschnelli> wtx confirmation could would then be, bestblockheight-wtxheight?
 57 2015-07-27 09:19:47 <wumpus> sure
 58 2015-07-27 09:20:12 <wumpus> you can do it smarter, e.g. have an index storing the transactions per height, then update only from the height of the reorg on
 59 2015-07-27 09:20:34 <jonasschnelli> Agreed.
 60 2015-07-27 09:21:03 <wumpus> then on the transactions store either their height (not depth), or an invalid value when not in the chain at all
 61 2015-07-27 09:21:58 <jonasschnelli> Yes. And because the wallet have to load all wtx anywhen when the users starts the app, keeping a per height index would be trivial.
 62 2015-07-27 09:21:58 <wumpus> and for transactions that aren't confirmed or at unknown height, you have to recheck if they made it now
 63 2015-07-27 09:22:18 <jonasschnelli> s/anyways
 64 2015-07-27 09:23:03 <wumpus> keeping it up to date correctly is harder :)
 65 2015-07-27 09:24:22 <jonasschnelli> even if you miss a new block/change-tip-signal (but i don't now how), it would recover on the next signal
 66 2015-07-27 09:24:52 <wumpus> yes
 67 2015-07-27 09:54:38 <jonasschnelli> would a in mem height index like std::map<int(height), std::vector<WalletTx*> >  be enough, scalable? IMO theres no need for disk persistence.
 68 2015-07-27 09:55:58 <jonasschnelli> and it would only handle wtx with a height > then bestblochkeight-288
 69 2015-07-27 10:16:39 <wumpus> jonasschnelli: yes
 70 2015-07-27 10:17:57 <wumpus> fair enough; if there is a larger reorg than that, there will be worse issues than keeping # confirmations up to date
 71 2015-07-27 10:20:16 <wumpus> it should probably just fail in that case
 72 2015-07-27 10:51:32 <jonasschnelli> hmm... calculating wallets smartTime requires the wallet keep track/a index of blockhash/block->nTime
 73 2015-07-27 10:52:42 <Luke-Jr> does it?
 74 2015-07-27 10:56:43 <jonasschnelli> Luke-Jr: in case of wallet/core separation. Because it uses the block->nTime for the wtx->nSmartTime
 75 2015-07-27 10:57:12 <jonasschnelli> I try to avoid coupling / locking , even if the new wallet still is compiled into bitcoin-core
 76 2015-07-27 10:57:24 <Luke-Jr> just to assign it initially, right?
 77 2015-07-27 10:57:44 <jonasschnelli> right... initial = receiving a tx = wtx
 78 2015-07-27 10:58:23 <jonasschnelli> because users could have turned off the wallet, he might receive transaction from a older block
 79 2015-07-27 10:58:26 <Luke-Jr> so the wallet doesn't need to keep track of blockhash->nTime, just know the nTime of the block it gets a given wtx in
 80 2015-07-27 10:58:39 <jonasschnelli> right...
 81 2015-07-27 10:58:53 <jonasschnelli> a basic std::map would be sufficient.
 82 2015-07-27 10:59:23 <jonasschnelli> std::map<uint256(hash), uint64_t(time)>
 83 2015-07-27 10:59:53 <Luke-Jr> I see no reason for a map/index of any sort..
 84 2015-07-27 10:59:55 <jonasschnelli> but such structures serialized into a append only db are bad...
 85 2015-07-27 11:00:08 <jonasschnelli> how would you get a blocktime from the wallet?
 86 2015-07-27 11:00:23 <jonasschnelli> s/from the wallet/withing the wallet code
 87 2015-07-27 11:00:49 <Luke-Jr> I'd store it with the wtx; but blocktime != smarttime
 88 2015-07-27 11:01:46 <jonasschnelli> sure. I want to store it in the wtx structure. But initial i need to get it from somewhere...
 89 2015-07-27 11:02:07 <jonasschnelli> hmm... you could be right...
 90 2015-07-27 11:02:08 <Luke-Jr> from your blocknotify :p
 91 2015-07-27 11:02:12 <jonasschnelli> yes. :)
 92 2015-07-27 11:02:50 <jonasschnelli> totally true... AddToWalletIfInvolvingMe (super function of AddToWallet) does know the block
 93 2015-07-27 11:03:24 <jonasschnelli> i need to stop trusting that the current wallet implementation makes sense.
 94 2015-07-27 11:05:01 <s3gfault> http://www.ibtimes.co.uk/bitcoins-smart-sibling-ethereum-only-game-town-banks-build-blockchains-1512726
 95 2015-07-27 11:05:28 <s3gfault> Are we only going to fix script when Ethereum has a bigger market cap then Bitcoin? Is that when we'll take it seriously?
 96 2015-07-27 11:05:59 <s3gfault> (assuming eth doesn't have a critical failure(s)
 97 2015-07-27 11:06:14 <s3gfault> We need sidechains sooner than later
 98 2015-07-27 11:14:40 <wumpus> so, how are you going to contribute to that?
 99 2015-07-27 11:16:02 <wumpus> anyhow -> #bitcoin
100 2015-07-27 11:43:24 <s3gfault> wumpus: i'll move discussion there , but without raising awareness here as well the processess will never happen
101 2015-07-27 11:44:11 <s3gfault> wumpus: can i propose that we fork the ethereum virtual machine and replace script with it?
102 2015-07-27 11:44:36 <s3gfault> i'll make a pull request if the devs will ACK it
103 2015-07-27 11:45:00 <wumpus> you can propose it, sure, but again the place is not here or on github. You should use the mailing list for network-wide issues.
104 2015-07-27 11:45:22 <s3gfault> wumpus: thanks will do
105 2015-07-27 11:47:07 <wumpus> I personally would say that replacing a well-functioning, battle tested script system with a alpha-level 'virtual machine' from another project would be a folly, though. It would need a very through argumentation at least.
106 2015-07-27 11:51:39 <wumpus> you may understand we've sort of had it with 'oh no we need to do something now!??!' panic-driven proposals
107 2015-07-27 12:17:47 <s3gfault> wumpus: agreed.  perhaps we should set a metric for when we can take it seriously? i.e. 6 months and/or $0.5B market cap seem reasonable.   The risk is waiting too long; if we pass a tipping point the network effect takes over and there is no recovery.
108 2015-07-27 17:46:59 <jonasschnelli> would HTTP Long Polling over REST/RPC be an alternative for ZMQ push?
109 2015-07-27 17:47:17 <jonasschnelli> (searching a stable way of informing a remote wallet over new blocks/transactions)
110 2015-07-27 18:00:17 <flyingkiwi> jonasschnelli, not really answering your question, but I'm using a p2p implementation to get notified
111 2015-07-27 18:00:18 <wumpus> jonasschnelli: there's one method that does longpolling, getblocktemplate
112 2015-07-27 18:00:58 <jonasschnelli> wumpus: hmm.. i didn't knew that. Will look at it.
113 2015-07-27 18:01:09 <wumpus> yes, if you just want to be notified of blocks/transactions the P2P protocol seems to be the best way
114 2015-07-27 18:02:29 <jonasschnelli> I don't want to implement the SPV stack now... i'd like to trust/protect the wallet behind a full node
115 2015-07-27 18:02:57 <jonasschnelli> I just search a way to seperate the core / wallet processes
116 2015-07-27 18:09:52 <ajweiss> what are the desirable traits?
117 2015-07-27 18:10:20 <jonasschnelli> But yes. Maybe it makes no sense to separate the processes while not directly upgrade the netlayer to use SPV.
118 2015-07-27 18:10:33 <ajweiss> something that can be used from a variety of environments?  works well specifically for pushing notifications?  perhaps authentication and authorization so you can use your own trusted fullnode remotely?
119 2015-07-27 18:11:06 <jonasschnelli> ajweiss: SPV would work for a such case. You could bind you SPV client to your full node.
120 2015-07-27 18:11:24 <jonasschnelli> I just fear that most people then go over unencrypted channels (just over the net over 8333).
121 2015-07-27 18:11:28 <ajweiss> over some sort of secure tunnel
122 2015-07-27 18:11:32 <ajweiss> yeah...
123 2015-07-27 18:11:50 <ajweiss> it gets a little more complicated because people are actively working to remove openssl from core
124 2015-07-27 18:12:07 <jonasschnelli> But you probably now how this works: "let me set up a IPSec tunnel.. nah.. lets go straight over port 8333" . :)
125 2015-07-27 18:12:12 <ajweiss> and sure there's stuff like stunnel, but that's a little more complicated to setup
126 2015-07-27 18:12:15 <ajweiss> yeah
127 2015-07-27 18:12:36 <ajweiss> and if you go plaintext it defeats the point... why not just use regular spv...
128 2015-07-27 18:12:57 <jonasschnelli> regular spv is fine.. but you lose pricavy
129 2015-07-27 18:13:03 <jonasschnelli> (in case you use BF)
130 2015-07-27 18:13:21 <ajweiss> privacy and things can be hidden from you
131 2015-07-27 18:13:23 <jonasschnelli> and a trustred node could serve you fee estimations.
132 2015-07-27 18:14:26 <ajweiss> there was a thing on the dev list recently where some guy was talking about how he used iptables to redirect all bitcoin p2p traffic at a festival to go through his one node to save bandwidth
133 2015-07-27 18:14:37 <ajweiss> ideally you'd like something that would be resistant to things like that
134 2015-07-27 18:15:16 <jonasschnelli> Yes... and a SPV wallet can not examine the mempool.
135 2015-07-27 18:15:44 <jonasschnelli> but yeah... maybe i should straight aim for SPV
136 2015-07-27 18:16:24 <ajweiss> that might not be bad
137 2015-07-27 18:16:41 <ajweiss> it covers pretty much everything except the auth/encryption
138 2015-07-27 18:17:07 <jonasschnelli> what about fee estimations?
139 2015-07-27 18:17:24 <jonasschnelli> IMO a big problem/risk for current SPV clients
140 2015-07-27 18:17:32 <ajweiss> i haven't thought about that too much...  but maybe that would make sense to be added to the p2p protocol
141 2015-07-27 18:17:45 <ajweiss> although i haven't looked at how dos-able it would be
142 2015-07-27 18:17:55 <jonasschnelli> ajweiss: miner would tell you funny fee estimations probably if it would be on p2p
143 2015-07-27 18:18:14 <jonasschnelli> fee estimation needs a trusted node.
144 2015-07-27 18:18:22 <jonasschnelli> like verification IMO
145 2015-07-27 18:19:33 <ajweiss> yeah .. true
146 2015-07-27 18:35:02 <ajweiss> maybe a clean solution here would be to use the p2p protocol for blocks/transactions
147 2015-07-27 18:35:36 <ajweiss> and then an optional tls upgrade option that would allow p2p clients to request fee estimations
148 2015-07-27 18:36:20 <ajweiss> although that gets into the whole game of what certs do you trust and how do you get that into the wallet
149 2015-07-27 18:37:08 <ajweiss> but maybe a first pass attempt would involve an idea like that but s/authenticated encrypted/localhost/
150 2015-07-27 18:37:59 <jonasschnelli> ajweiss: yeah. Probably localhost for the beginning or RPC over a tunneling (RPC would support SSL but should be depracated IMO)
151 2015-07-27 18:38:00 <ajweiss> then discussions about how this could then be used for remote wallets over untrusted networks could come about... (i suspect said discussions would bring about a lot of ideas and opinions and would probably take some time to reach consensus)
152 2015-07-27 18:38:14 <ajweiss> i lean away from rpc
153 2015-07-27 18:38:32 <jonasschnelli> k
154 2015-07-27 18:38:46 <ajweiss> but a new p2p message that only works for localhost might be a good start (for the fee estimates)
155 2015-07-27 18:39:17 <jonasschnelli> for localhost you can alerady use the RPC call estimatefee
156 2015-07-27 18:39:37 <ajweiss> yes, but wouldn't it be nice to have it all use one interface?
157 2015-07-27 18:40:02 <jonasschnelli> yeah. But chaning p2p is hard and i think fee estimation is not ideal on p2p
158 2015-07-27 18:40:32 <ajweiss> i don't think it would be too bad...  if it only works for localhost, i don't think it would be too controversial
159 2015-07-27 18:41:39 <ajweiss> having to hand out rpc creds to any wallet isn't great...  since there is no granularity in what you can do once you have access to the rpc interface...
160 2015-07-27 18:42:14 <jonasschnelli> fee estimation should probably go over the unauthenticated REST interface
161 2015-07-27 18:42:38 <ajweiss> maybe, but then as a wallet developer you have to support two protocols
162 2015-07-27 18:43:02 <jonasschnelli> RPC or REST, but not both...
163 2015-07-27 18:43:04 <ajweiss> think about wallets like msigna that already can be told about a trusted bitcoind
164 2015-07-27 18:43:11 <ajweiss> that talk to it over rpc
165 2015-07-27 18:43:16 <ajweiss> er, p2p!
166 2015-07-27 18:44:39 <ajweiss> they could add fee estimation support just by adding support for p2p fee estimates using their existing p2p code
167 2015-07-27 18:44:53 <ajweiss> rather than having to stick a whole http/rest downloader in there just for fees
168 2015-07-27 18:45:34 <ajweiss> if it all goes over one protocol, then eventually securing that protocol for clients over untrusted networks becomes much easier
169 2015-07-27 18:49:06 <jonasschnelli> i think fees over p2p make not much sense. It would be a fundamental change. fees are a result of a validated blockchain... the current p2p elements (tx/blocks/addresses) are ment to be verified by a node...
170 2015-07-27 18:49:42 <jonasschnelli> and theres is no SFV (simple fee verification)
171 2015-07-27 18:49:43 <ajweiss> sure.. but bloom filters go over p2p and they only exist to support spv clients
172 2015-07-27 18:50:22 <jonasschnelli> yeah. Bloom filter transaction so a SPV client can verify the transaction (merkle tree check).
173 2015-07-27 18:50:36 <jonasschnelli> estimated fees are not verifiable in any way.
174 2015-07-27 18:50:59 <ajweiss> true.  that's why fee estimates wouldn't be served anywhere other than localhost
175 2015-07-27 18:51:31 <jonasschnelli> but than people might question why to add on a p2p layer when not really serving over p2p (only localhost).
176 2015-07-27 18:51:46 <jonasschnelli> Than it's not p2p, it's centralized.
177 2015-07-27 18:52:07 <ajweiss> sure.  but it's also a simple way for a wallet to talk to a fullnode it trusts
178 2015-07-27 18:52:15 <jonasschnelli> REST would be ideal for a such use case.
179 2015-07-27 18:52:26 <ajweiss> so lets say
180 2015-07-27 18:52:27 <jonasschnelli> yes. it would be simple from the wallet perspective.
181 2015-07-27 18:52:41 <ajweiss> one year down the road, people want to run the wallet remotely
182 2015-07-27 18:52:46 <jonasschnelli> But REST is very simple... open a SOCKET, call HTTP 1.1 GET /fees, ... more or less done. :)
183 2015-07-27 18:52:50 <ajweiss> now they have to secure both p2p and rest traffic
184 2015-07-27 18:54:16 <jonasschnelli> yeah. But this would go hand in hand when tunneling to your node
185 2015-07-27 18:54:49 <jonasschnelli> But i agree that it would be easier for a developer to get fees over p2p... but it's just the design that seems to be unideal.
186 2015-07-27 18:56:15 <ajweiss> i guess its a matter of taste... but i believe that having to support two very different protocols over two different ports is really pretty ugly... regardless of how simple one of them may be...
187 2015-07-27 18:56:46 <ajweiss> but honestly, this would be a good discussion for the dev list
188 2015-07-27 18:57:00 <jonasschnelli> Yeah... need to take it there once...
189 2015-07-27 18:57:03 <ajweiss> there are people who have been involved in this stuff for a long time who have thought about this
190 2015-07-27 18:57:23 <ajweiss> i think hearn would definitely have some ideas, since he's had a wallet focus for so long
191 2015-07-27 18:58:01 <jonasschnelli> The thing with the mailing list is, it might end up in endless loops. But sure, will probably bring in good ideas.
192 2015-07-27 18:58:28 <ajweiss> it would be a pallete cleanser after all the tweddit jibber jabber : )
193 2015-07-27 18:59:38 <jonasschnelli> haha..
194 2015-07-27 19:01:40 <ajweiss> just make sure you give it an accurate, yet boring sounding subject line : )
195 2015-07-27 19:42:25 <waxwing> reading about bip 66, can someone "reinterpret" this for me? "Null bytes at the start of S are not allowed, unless S would otherwise be  nterpreted as a negative number"
196 2015-07-27 19:42:53 <waxwing> or i could just read the code and ignore the words, I guess :)
197 2015-07-27 19:43:33 <waxwing> so is it, if the leading byte is zero and the next byte has the first bit set, it's interpreted as negative, and rejected?
198 2015-07-27 19:46:23 <sdaftuar_> no, if the leading byte is zero, then the next byte must have the first bit set, or else it's rejected.  i think it
199 2015-07-27 19:46:42 <waxwing> sdaftuar_: oh yes, wasn't reading carefully. thanks.
200 2015-07-27 19:46:43 <sdaftuar_> 's easier to just look at the code
201 2015-07-27 20:09:23 <tyho> Is there a decent wordpress plugin that allows you to take bitcoin but doesn't rely on some stupid SAAS provider? i.e. one that runs a bitcoin client and doesn't involve a third party.
202 2015-07-27 20:48:15 <BlueMatt> -rw------- 1 matt matt 436G Jul 27 13:47 /bigraid/docker/seed/.bitcoin/debug.log
203 2015-07-27 20:48:21 <BlueMatt> hmmmmmm....maybe I should prune that
204 2015-07-27 20:52:31 <rodarmor> BlueMatt: in FullBlockTestGenerator.java, what does the comment "// Entirely invalid scriptPubKey to ensure we aren't pre-verifying too much" mean?
205 2015-07-27 20:52:55 <BlueMatt> scriptPubKeys dont have to be valid scripts - they can be unparseable crap
206 2015-07-27 20:53:06 <BlueMatt> it just makes them unspendable, doesnt make the transaction invalid
207 2015-07-27 20:54:30 <BlueMatt> (IIRC)
208 2015-07-27 20:54:50 <rodarmor> Okay, cool, that makes sense.
209 2015-07-27 22:51:39 <Sapex> which server distro do you recommend to run bitcoind?? I am trying to compile on CentOS6.6 from source on git and having too many errors, I tried bitcoin version 0.9, 0.10 and 0.11, they all gave me a different error
210 2015-07-27 22:51:52 <Sapex> for instance here is one of the errors I got: http://bitcoin.stackexchange.com/questions/38837/bitcoin-compile-error-on-centos-6-6-size-max-was-not-declared-in-this-scope
211 2015-07-27 22:53:16 <Luke-Jr> Sapex: #bitcoin
212 2015-07-27 22:57:01 <Sapex> which distro do you guys as developers use for bitcoind? and why?
213 2015-07-27 22:57:21 <Luke-Jr> ask in #bitcoin still please
214 2015-07-27 22:57:59 <Luke-Jr> this is not "talk to bitcoin developers", it is "talk about bitcoin development"
215 2015-07-27 23:47:45 <leakypat> harding: you around?