1 2014-01-19 00:34:06 <tigereye> for the first time in months my bitcoind node seems to be running out of connections frequently
  2 2014-01-19 00:34:14 <tigereye> it's happened 6 times in the last 2:30
  3 2014-01-19 00:34:21 <brisque> running out of them?
  4 2014-01-19 00:34:31 <brisque> hitting the default limit?
  5 2014-01-19 00:34:46 <tigereye> well, I run p2pool, and p2pool has reported that it's lost connection to bitcoind. Yes, hitting the _raised_ limit that I configured long ago
  6 2014-01-19 00:35:11 <tigereye> sure enough, when I "bitcoind getinfo" I have a tough time connecting to it in order to retrieve info from the commandline
  7 2014-01-19 00:35:34 <brisque> RPC is on a different port and isn't limited though
  8 2014-01-19 00:35:38 <lechuga__> what OS
  9 2014-01-19 00:35:47 <tigereye> slackware/linux
 10 2014-01-19 00:35:52 <brisque> even if you max out your peers RPC will still be chugging along happily.
 11 2014-01-19 00:36:17 <tigereye> well <shrug> p2pool reports bitcoind connectivity problems for the first time in 6 months
 12 2014-01-19 00:36:31 <tigereye> I figured I'd mention it in case others have started seeing it today too
 13 2014-01-19 00:36:43 <tigereye> i realize this may be p2pool, or may be othe rlocalized reasons.
 14 2014-01-19 00:36:56 <tigereye> I just awnted to mention it in case others suddenly saw it too.
 15 2014-01-19 00:38:23 <brisque> raise the number of RPC threads maybe? I'm taking a stab in the dark, not something I've had issues with.
 16 2014-01-19 00:41:20 <tigereye> I'm giving it the ol' Rule#1 in tech support
 17 2014-01-19 00:41:25 <tigereye> "Have you tried turning it off and on?"
 18 2014-01-19 00:42:21 <tigereye> P2Pool shows fancy graphs for various metrics, and the graph for bitcoind latency definitely shows giant spikes of 14s+ on 5 occasions in the last ~3hrs
 19 2014-01-19 00:42:47 <tigereye> Not sure what's making bitcoind lag so suddenly this evening but hopefully a reboot will fix it.
 20 2014-01-19 00:43:28 <sipa> if you restart bitcoind, does the problem go away (temporarily) ?
 21 2014-01-19 00:43:35 <tigereye> just did. Will see.
 22 2014-01-19 00:44:51 <tigereye> I do know that bitcoind/p2pool configuration haven't been altered in the last 5 months this node has been running, and these symptoms have never been seen before tonight. 5 instances in the last 3 hours has peaked my interest.
 23 2014-01-19 00:45:20 <CodeShark> you mean piqued :p
 24 2014-01-19 00:45:34 <tigereye> I do :) thx
 25 2014-01-19 00:46:05 <tigereye> I can share the graphs that show the behaviour upon request.
 26 2014-01-19 00:46:28 <brisque> tigereye: #p2pool or forre`stv could be of more use.
 27 2014-01-19 00:58:44 <lechuga__> anyone know avg txn propagation time?
 28 2014-01-19 00:59:19 <brisque> lechuga__: http://bitcoinstats.com/network/propagation/
 29 2014-01-19 00:59:55 <lechuga__> ty
 30 2014-01-19 01:09:04 <jgarzik> Goonie, I'm happy to entertain BitPay complaints -- please do! -- but not on this channel.  #bitcoin is fine
 31 2014-01-19 01:18:54 <sipa> ;;nethash
 32 2014-01-19 01:18:55 <gribble> 15208047.5479
 33 2014-01-19 01:21:52 <lechuga__> does any1 have any guess what coinbase does for off-the-blockchain txns
 34 2014-01-19 01:22:28 <brisque> a database with balances for each user?
 35 2014-01-19 01:23:02 <brisque> not particularly complex, just a lot of checks and balances to make sure you don't end up with people having the wrong balances when there's networking or database issues.
 36 2014-01-19 01:23:25 <lechuga__> yeah makes sense
 37 2014-01-19 01:23:48 <lechuga__> i wonder how likely an inter-ledger protocol would be
 38 2014-01-19 01:24:11 <lechuga__> so coinbase-like entities can enable cross-domain micropayments
 39 2014-01-19 01:24:22 <brisque> that requires trust.
 40 2014-01-19 01:24:25 <lechuga__> yeah
 41 2014-01-19 01:24:33 <lechuga__> that seems to be the biggest issue
 42 2014-01-19 01:24:58 <brisque> you invariably end up with parties not having a consensus and then the trust is broken. that's what the design of bitcoin is trying to avoid.
 43 2014-01-19 01:25:35 <lechuga__> so then is the real micropayment solution an optimized blockchain?
 44 2014-01-19 01:25:54 <brisque> ;;bc,wiki scalability
 45 2014-01-19 01:25:55 <gribble> http://en.bitcoin.it/wiki/Scalability | Jul 6, 2013 ... 1 Scalability targets; 2 Current bottlenecks; 3 CPU; 4 Network; 5 Storage; 6 Optimizations. 6.1 CPU; 6.2 Simplified payment verification.
 46 2014-01-19 01:26:06 <lechuga__> yeah ive seen that site
 47 2014-01-19 01:26:16 <lechuga__> but no1 even does micropayments right now
 48 2014-01-19 01:26:23 <lechuga__> so u cant compare it to existing load
 49 2014-01-19 01:26:28 <brisque> bitcoin isn't really designed for them.
 50 2014-01-19 01:26:37 <lechuga__> well right but could it be throug optimization
 51 2014-01-19 01:26:45 <lechuga__> through*
 52 2014-01-19 01:27:23 <brisque> this is likely off topic for #bitcoin-dev, but I don't see it being friendly for micropayments any time in the near future. see "dust transactions".
 53 2014-01-19 01:27:38 <lechuga__> tru re: offtopic
 54 2014-01-19 01:27:44 <maaku> sipa: we had a discussion about changing to XBT on the developer list, and IIRC there was some concensus about 1 XBT = 1 uBTC, but no one actually made a pull request
 55 2014-01-19 01:28:02 <sipa> maaku: first thing i heard about it
 56 2014-01-19 01:31:03 <maaku> sipa: 14 Nov "moving the default display to mbtc"
 57 2014-01-19 01:31:56 <sipa> right, i remember that discussion
 58 2014-01-19 01:33:33 <brisque> there's lots of drivel on bitcointalk about wanting to move to "new BTC" by redefining the value. as if Bitcoin wasn't already confusing enough.
 59 2014-01-19 01:34:55 <maaku> brisque: that's essentially the heart of the matter.  "new BTC" / XBT is better than redefining the symbol
 60 2014-01-19 01:35:21 <brisque> why do you even want that?
 61 2014-01-19 01:41:13 <scoofy> actually most of altcoins are 'new BTC' redefining the value, in terms of relative to BTC
 62 2014-01-19 01:42:11 <scoofy> well that's not a fixed ratio, but their value can vary widely
 63 2014-01-19 01:52:22 <Luke-Jr> scoofy: TBC is fixed ratio :P
 64 2014-01-19 01:52:23 <maaku> scoofy: the precient is the history of many fiat currencies
 65 2014-01-19 01:52:40 <maaku> e.g. Taiwan Dollar -> New Taiwan Dollar which dropped some zeros
 66 2014-01-19 01:52:53 <maaku> although in this case deflationary instead of inflationary
 67 2014-01-19 01:53:30 <jcorgan> maaku: hmm, interesting way to think about it
 68 2014-01-19 01:54:21 <brisque> the thing is, if you change the meaning of BTC you needlessly confuse things.
 69 2014-01-19 01:54:53 <brisque> if your excuse is that people don't understand bitcoin is divisible, maybe that needs to be made more apparent in introduction material.
 70 2014-01-19 01:56:43 <jcorgan> I don't think it really the issue that people don't know that bitcoin is divisible (but there are some), its the difficult people seem to have with lots of zeros after the decimal point
 71 2014-01-19 01:57:24 <brisque> so use milibitcoin.
 72 2014-01-19 01:57:24 <jcorgan> so introducing a new currency symbol and making it equate to a small division of BTC would fix that
 73 2014-01-19 01:57:57 <brisque> the only people that care about the currency symbol are traders, who really should be able to handle decimal places. their job revolves around it.
 74 2014-01-19 01:58:52 <jcorgan> someone (don't remember who) proposed going through ISO standardization on XBT, and setting it to a 100 satoshis, which would solve two problems at once
 75 2014-01-19 01:59:16 <jcorgan> http://en.wikipedia.org/wiki/ISO_4217
 76 2014-01-19 01:59:57 <jcorgan> getting an officiall recognized currency symbol, and helping people by putting the zeros to the left of the decimal point
 77 2014-01-19 02:12:55 <scoofy> why would that help
 78 2014-01-19 02:13:19 <sipa> human behavior
 79 2014-01-19 02:15:11 <scoofy> so people would say 1 dollar is worth 8000000000 XBT
 80 2014-01-19 02:15:28 <scoofy> or something like that, right?
 81 2014-01-19 02:17:42 <scoofy> 1 sathoshi is 1e-8 BTC, or so 100 satohshi is 1e-6 BTC, or $0.0008
 82 2014-01-19 02:18:04 <scoofy> so 1 dollar would worth 1250 XTB
 83 2014-01-19 02:18:21 <scoofy> and 1000 dollar = 1250000 XBT
 84 2014-01-19 02:18:44 <scoofy> how is that better than writing: 1000 dollar = 1.25 BTC
 85 2014-01-19 02:19:04 <scoofy> s/XTB/XBT
 86 2014-01-19 02:19:48 <scoofy> you either add 3 zeros, or remove 3 zeros...
 87 2014-01-19 02:22:31 <scoofy> anyways i somewhat like the idea of mBTC, because that roughly equals one dollar
 88 2014-01-19 02:22:40 <sipa> for now
 89 2014-01-19 02:22:58 <scoofy> yep. if BTC goes up to $100,000, then it won't be true
 90 2014-01-19 02:23:11 <sipa> or if it crashes to $1 again
 91 2014-01-19 02:23:21 <scoofy> if it drops to $10, it won't be true either
 92 2014-01-19 02:23:59 <scoofy> so it's impossible to find a value representation that stays constant with wide value fluctiations...
 93 2014-01-19 02:24:13 <scoofy> you can go some orders of magnitude up, or down
 94 2014-01-19 02:24:24 <scoofy> in any case (with XBT too)
 95 2014-01-19 02:29:07 <scoofy> if btc crashes to $1, and XBT = 100 satoshi, then 1 XBT will worth 0.000001 USD
 96 2014-01-19 02:29:24 <scoofy> and 1 USD will worth 1000000 XBT
 97 2014-01-19 03:03:03 <midnightmagic> it would be amusing to officially move the decimal place and see how the market reacts.
 98 2014-01-19 03:03:21 <midnightmagic> watch it climb to $1 parity again. lol
 99 2014-01-19 03:03:41 <jgarzik> heh
100 2014-01-19 03:05:05 <Luke-Jr> midnightmagic: "officially"?
101 2014-01-19 03:05:55 <brisque> moving the decimal place would just confuse everybody and break the conventions we have in place. if the unit can move, why not change the coin cap, make mining easier?
102 2014-01-19 03:05:57 <midnightmagic> yeah just slip it into the reference client. move it 3 spots to the right, so 1 "btc" is now 10e5 satoshis.
103 2014-01-19 03:06:48 <midnightmagic> brisque: Because the decimal place is just a constant. everything is a psychological barrier: what happens when people realise it's been simple human perception right from the start?
104 2014-01-19 03:07:32 <Luke-Jr> midnightmagic: the reference client already supports mBTC
105 2014-01-19 03:08:34 <jcorgan> if we came out with XBT = 100 Satoshis, people could use either XBT or BTC as needed
106 2014-01-19 03:10:21 <midnightmagic> Luke-Jr: You mean by fiddling with COIN and CENT in util.h ?
107 2014-01-19 03:10:37 <midnightmagic> or is there a switch now for mbtc display that I've missed?
108 2014-01-19 03:10:45 <Luke-Jr> midnightmagic: no, I mean Settings->Options
109 2014-01-19 03:10:54 <Luke-Jr> Display->Unit to show amounts in: mBTC
110 2014-01-19 03:11:01 <midnightmagic> ah, you're in the qt client.
111 2014-01-19 03:11:03 <Luke-Jr> been there since 0.5 I'm pretty sure
112 2014-01-19 03:11:10 <Luke-Jr> midnightmagic: yes, the reference client..
113 2014-01-19 03:11:31 <midnightmagic> not the reference client i'm using. :)
114 2014-01-19 03:11:45 <Luke-Jr> midnightmagic: bitcoind is not intended for human use in the first place.
115 2014-01-19 03:11:56 <Luke-Jr> midnightmagic: the only reason it doesn't count amounts in satoshis is for backward compatibility
116 2014-01-19 03:12:18 <midnightmagic> :-P I don't consider the GUI to be human-usable, personally.
117 2014-01-19 03:12:29 <Luke-Jr> midnightmagic: when was the last time you tried it? :P
118 2014-01-19 03:13:15 <brisque> https://github.com/chjj/termcoin this is a nice replacement for the QT GUI.
119 2014-01-19 03:13:37 <midnightmagic> I'm not interested in running X infrastructure on top of everything I already do.
120 2014-01-19 03:13:40 <Luke-Jr> wow, ASCII art QR codes?
121 2014-01-19 03:13:48 <Luke-Jr> midnightmagic: Bitcoin-Qt *should* work without X
122 2014-01-19 03:14:05 <brisque> Luke-Jr: heh, yeah, you can make them with the 'qrencode' package too.
123 2014-01-19 03:14:09 <midnightmagic> wouldn't that defeat the purpose of using it rather than just bitcoind?
124 2014-01-19 03:14:18 <Luke-Jr> midnightmagic: no?
125 2014-01-19 03:14:24 <Luke-Jr> midnightmagic: Bitcoin-Qt is far more functional
126 2014-01-19 03:15:01 <midnightmagic> You trust QT more than I do.
127 2014-01-19 03:15:25 <Luke-Jr> what's to trust? it's just a programming language.
128 2014-01-19 03:15:49 <midnightmagic> My employer has discovered crash bugs in the QT toolkit that took trolltech like 9 months to commit fixes for.
129 2014-01-19 03:16:03 <brisque> crashes aren't security issues though
130 2014-01-19 03:16:11 <brisque> annoying at best
131 2014-01-19 03:16:44 <midnightmagic> mm..  depends on the crash. I'm confident the ones we found could have been security issues depending on how the clients used the broken functions.
132 2014-01-19 03:18:01 <midnightmagic> Luke-Jr: How does one run bitcoin-qt without some kind of X infrastructure as a display server?
133 2014-01-19 03:18:29 <Luke-Jr> Windows
134 2014-01-19 03:18:32 <Luke-Jr> </troll>
135 2014-01-19 03:18:41 <midnightmagic> lol turkey
136 2014-01-19 03:18:44 <Luke-Jr> more seriously, http://qt-project.org/doc/qt-4.8/qt-embedded-linux.html
137 2014-01-19 03:20:01 <Luke-Jr> there's also the Wayland port
138 2014-01-19 03:59:26 <justanotheruser> For programs that involve creating and looking at bitcoin wallets and transactions do developers usually use a library, a modified satoshi client, or a satoshi client with API calls being made from the program?
139 2014-01-19 04:03:53 <scoofy> QT doesn't need X. runs fine on Windows
140 2014-01-19 04:04:10 <brisque> and OSX, which doesn't have X either
141 2014-01-19 06:17:16 <Snowleaksange> i need a job that pays in bitcoins
142 2014-01-19 06:17:31 <Snowleaksange> ah meant for #bitcoin
143 2014-01-19 10:38:05 <wumpus> so is it really time to get rid of the GUI, everyone here seems to be so annoyed by it? or is that just -dev posturing, we don't need a GUI because we're so technical?
144 2014-01-19 10:40:34 <gmaxwell> I don't think we should get rid of the gui.
145 2014-01-19 10:41:24 <wumpus> I think especially for windows it's useful, as people are not used to running services without a GUI
146 2014-01-19 10:41:38 <gmaxwell> absolutely, I agree there.
147 2014-01-19 10:42:23 <gmaxwell> and even for technical users in windows they use the gui plus the gui console. The windows command prompt is foreign and behaves not so great.
148 2014-01-19 10:42:27 <maaku> Not everyone can use the command line
149 2014-01-19 10:42:52 <maaku> I am aware of no other GUI that is a full node
150 2014-01-19 10:43:02 <gmaxwell> well I'm pretty sure everyone _can_ but— not everyone should be or needs to be.
151 2014-01-19 10:44:17 <wumpus> maaku: that's entirely true, but end-users will use some other app or web service, they aren't encouraged to run a full node anymore
152 2014-01-19 10:45:06 <maaku> wumpus: most users will be fine on multbit, yes, but some users will feel they need to run a full node, maybe with good reason
153 2014-01-19 10:45:17 <maaku> and they may be uncomfortable or untrained in using a command line
154 2014-01-19 10:45:39 <gmaxwell> Multibit is glitchy and very feature constrained.
155 2014-01-19 10:45:39 <wumpus> right... I agree with you
156 2014-01-19 10:46:44 <gmaxwell> Multibit should probably be removed from bitcoin.org, I don't mean this to be controversial but as far as I know no one other than its author even can build it.
157 2014-01-19 10:47:02 <gmaxwell> and indeed, being able to run a full node (at the reasonable and relevant costs) is a part of what makes bitcoin bitcoin and not paypal.
158 2014-01-19 10:48:24 <wumpus> right, as long as there is a sizeable amount of users that wants to run a full node and is helped by having a GUI, then it makes sense to continue maintaining it :)
159 2014-01-19 10:49:10 <gmaxwell> now, seperating out the gui in the codebase more, and such, thats all a grand plan.
160 2014-01-19 10:51:55 <wumpus> the GUI already builds seperately, I think the next seperation effort would be the wallet and the rest of the node
161 2014-01-19 10:53:14 <wumpus> as in, seperate processes
162 2014-01-19 14:46:11 <twizt> anyone know if hteres a game dev channel on this network
163 2014-01-19 14:46:12 <twizt> ?
164 2014-01-19 17:16:56 <lopp> I've asked this question on both Bitcointalk and Reddit without a single response. Hopefully someone on here can shed some light...
165 2014-01-19 17:17:07 <lopp> It's fairly straightforward to see the strength of the Bitcoin mining infrastructure growing by viewing the graphs of the relentlessly-increasing hashrate and thus mining difficulty. What I'd like to learn more about is the "health / strength" of the network with respect to the number of full nodes that are broadcasting transactions.
166 2014-01-19 17:17:15 <lopp> I try to keep tabs on the number of full nodes via http://getaddr.bitnodes.io/chart/nodes/ and have been disappointed by the recent decline, but I don't know if it is cause for concern. Does anyone know of a method by which we can determine the optimal number / minimum threshold of operating full nodes that will keep the relaying of transactions robust?
167 2014-01-19 17:19:59 <sipa> lopp: full nodes have distinct functions, and the "optimality" differs between them
168 2014-01-19 17:20:27 <sipa> 1) full nodes provide lookup of historic blocks, which is necessary for new nodes synchronizing
169 2014-01-19 17:20:55 <sipa> 2) full nodes provide filtered transaction lookup for SPV clients, which is necessary for those clients to function
170 2014-01-19 17:21:07 <sipa> 3) full nodes validate blocks and transactions, and relay them
171 2014-01-19 17:21:48 <sipa> 1 and 2 are easy... we just need enough to satisfy reasonable (non-attack) demand
172 2014-01-19 17:22:23 <sipa> 3 is a bit harder, relay of blocks and transactions is important, but technically doesn't require a full node
173 2014-01-19 17:22:33 <sipa> what full nodes however do, is make sure the network is honest
174 2014-01-19 17:22:51 <sipa> and this is not so much as question of how many there are
175 2014-01-19 17:22:58 <sipa> it's more about how hard it is to run one
176 2014-01-19 17:25:48 <lopp> Understood. Is there any worry, however, about the ratio of nodes running the standard 8 connections vs those that maintain 100+ connections? I've seen them referred to as "seeder" and "leecher" nodes but haven't seen any hard proof that it is "bad" to only accept 8 connections.
177 2014-01-19 17:27:26 <sipa> accept?
178 2014-01-19 17:27:44 <sipa> the reference client by default accepts up to 120 connections
179 2014-01-19 17:27:53 <sipa> it never makes more than 8 outgoing connections those
180 2014-01-19 17:28:03 <sipa> in order not to exhaust connectable peer slots
181 2014-01-19 17:28:14 <sipa> s/those/though/
182 2014-01-19 17:31:44 <lopp> I believe it comes down to people running a node behind a router / firewall who don't open / forward the port. So you're saying that when my full node reports 100 connections, those are all incoming and only 8 are outgoing?
183 2014-01-19 17:31:55 <sipa> yes
184 2014-01-19 17:32:31 <lopp> Doesn't make sense to me, because my upstream bandwith usage goes through the roof when I open up my bitcoin port...
185 2014-01-19 17:32:55 <sipa> that makes perfect sense
186 2014-01-19 17:33:08 <sipa> incoming connections are much more likely to be by peers who are still catching up
187 2014-01-19 17:33:18 <sipa> so they tend to request much more data from you
188 2014-01-19 17:33:49 <lopp> oh, ok, they're "incoming" from the viewpoint of the rest of the network
189 2014-01-19 17:34:10 <sipa> incoming connections: from the network to you
190 2014-01-19 17:34:16 <sipa> outgoing connections: from you to the network
191 2014-01-19 17:34:23 <lopp> gotcha
192 2014-01-19 17:37:26 <lopp> then it sounds like any node that is not allowing incoming connection is, in essence, "leeching"
193 2014-01-19 17:38:43 <lopp> would it be helpful if we could determine a seeder:leecher ratio a la bittorrent?
194 2014-01-19 17:38:47 <sipa> if the only resource you're considering is available connection slots, yes
195 2014-01-19 17:39:12 <sipa> but even nodes that only make outgoing connections do verify transactions and blocks, and relay those between their peerds
196 2014-01-19 17:40:15 <lopp> but we can't publicly query a node for those granular statistics, correct?
197 2014-01-19 17:48:10 <lopp> I'm assuming that not all nodes are equal with regard to how many transactions that they verify and relay
198 2014-01-19 17:50:13 <sipa> every node verifies and relies every block (and every transaction in it)
199 2014-01-19 17:50:20 <sipa> *relays
200 2014-01-19 17:53:06 <blazon> propigation, depending on node density in your area is a different story
201 2014-01-19 17:54:12 <CryptDrift> what is the easiest way to generate QR codes for BTC addresses in a webpage?
202 2014-01-19 17:56:04 <justanotheruser> CryptDrift: probably to use a QR code library
203 2014-01-19 17:56:16 <CryptDrift> bitaddress.org qrcode.js ?
204 2014-01-19 17:57:10 <CryptDrift> sweet there is jquery qrcode but wanted to keep the project lightweight
205 2014-01-19 17:57:59 <sipa> lightweight for the server or for the client?
206 2014-01-19 17:58:27 <CryptDrift> for the client
207 2014-01-19 17:59:10 <justanotheruser> CryptDrift: there probably is a library for whatever you are using to generate web pages
208 2014-01-19 17:59:35 <sipa> well then you'll need to geneate the qr code images server-side :)
209 2014-01-19 17:59:39 <CryptDrift> justanotheruser, okay already got a nice jquery plugin
210 2014-01-19 17:59:57 <CryptDrift> was just curious are there any differences for BTC addresses than a normal string
211 2014-01-19 18:00:32 <sipa> as far as the QR code generation is concerns, a bitcoin address is just a string
212 2014-01-19 18:00:44 <sipa> a bitcoin: URI, rather
213 2014-01-19 18:00:56 <CryptDrift> sipa thanks thats what I needed to know
214 2014-01-19 18:01:07 <CryptDrift> bitcoin URI doesn't work with electrum wallet :/
215 2014-01-19 18:03:15 <CryptDrift> sometimes bitcoin URI annoys like email URIs
216 2014-01-19 18:49:39 <niston> I wonder who comes first with hardware crypto support, AMD or nVidia?
217 2014-01-19 18:49:55 <Luke-Jr> niston: Intel
218 2014-01-19 18:50:00 <Luke-Jr> actually, VIA
219 2014-01-19 18:50:02 <niston> heh.
220 2014-01-19 18:50:15 <niston> what chipset?
221 2014-01-19 18:57:04 <sturles> C3 and C7 at least.
222 2014-01-19 18:57:16 <Diablo-D3> heh
223 2014-01-19 18:57:22 <Diablo-D3> it'd probably be intel
224 2014-01-19 18:57:29 <Diablo-D3> that comes first in hw crypto support
225 2014-01-19 18:59:13 <niston> interesting
226 2014-01-19 19:00:04 <sturles> VIA had hw crypto support in their x86 CPUs for ten years now.
227 2014-01-19 19:00:54 <niston> yeah I have an ALIX board with a VIA chip
228 2014-01-19 19:01:06 <niston> but would it be useful for mining? I doubt that.
229 2014-01-19 19:01:31 <niston> its nice for VPN throughput however.
230 2014-01-19 19:04:15 <Luke-Jr> niston: look into VIA PadLock
231 2014-01-19 19:06:10 <lianj> niston: sadly the alix boards have 100mbit nics though :)
232 2014-01-19 19:07:00 <sturles> Looks like both AMD and Intel have had AES specific instructions for a while: https://en.wikipedia.org/wiki/AES_instruction_set#Supporting_CPUs
233 2014-01-19 19:10:10 <niston> lianj: true ;)
234 2014-01-19 19:10:58 <niston> I still think it would be logical for gfx card manufacturers to include support for crypto mining
235 2014-01-19 19:15:18 <lianj> sturles: some/most of them. "Mobile: all Core i7 and Core i5" is not true, you can be unlucky and by a an i5 that doesn't have it
236 2014-01-19 19:15:50 <lianj> *buy an
237 2014-01-19 19:15:58 <Luke-Jr> niston: that makes not much sense. GPUs already do SHA2 very well
238 2014-01-19 19:26:27 <niston> Luke-Jr but theres no dedicated on chip support for it, is there?
239 2014-01-19 19:54:01 <maaku> niston: there'd be no point and a real cost
240 2014-01-19 23:41:56 <sipa> ;;blocks
241 2014-01-19 23:41:57 <gribble> 281389