01:08:24jtimon:gmaxwell isn't it true that memory-hard ASICs are much more power efficient compared to general purpose than sha256d-like functions ASICS?
01:11:03[nsh]:efficient at doing what?
01:12:10gmaxwell:jtimon: I assume you mean the ratio of power efficiency for general purpose vs special purpose hardware. potentially, it's very hard to generalize... and none of the existing memory hard in use POW are actually all that memory hard.
01:12:30gmaxwell:er existing memory hard POW in use (e.g. scrypt with ltc parameters).
01:13:16jtimon:what about the ratios of GPU vs ASIC in SHA256d vs scrypt?
01:14:49gmaxwell:when I'd looked before the first gen scrypt asics looked similar in terms of power to first/second gen sha256d devices.
01:21:45wallet42:wallet42 is now known as Guest43116
01:21:45wallet421:wallet421 is now known as wallet42
02:41:53fanquake_:fanquake_ is now known as fanquake
03:26:36Taek42:"The hardware costs are amortized the longer you run, so big established players have an advantage." Established players I see, but why does it make a difference if they are big or small? If everyone is buying the same $3k base component, where does scale give you an advantage?
03:27:10Taek42:I'm asking specifically with regards to high power costs vs. high upfront cost.
03:27:41jaekwon1:business deals with chip manufacturers,
03:27:56jaekwon1:investments and choice in energy sources,
03:28:30Taek42:Choice in energy sources would seem to favor having a high upfront cost.
03:29:50jaekwon1:seems so.
03:29:52Taek42:Bulk discount would favor high power cost, but I think a perfectly efficient market would minimize bulk discounts.
03:31:45jaekwon1:it's not like high power costs are disjoint from high reward from high upfront costs.
03:32:14Taek42:Can you explain that a bit more?
03:35:28jaekwon1:you posed the question as high power costs vs high upfront costs, but that doesn't seem like a good dichotomy.
03:36:12jaekwon1:anyways...
03:37:15jaekwon1:like, the reason why bulk discounts are possible is because upfront costs are high.
03:38:37jaekwon1:but to address the first question… a large player wouldn't need to pay $3k per component.
03:39:04jaekwon1:he'd buy something expensive that lets him pay say $2.5k per component.
03:39:25jaekwon1:and over time the cost of the expensive something, is amortized the longer he runs it.
03:40:26jaekwon1:Otherwise, yeah, I have no idea what that quote is talking about :)
03:41:29Taek42:Alright thanks. The bulk discounts thing does make sense, and other economy-of-scale factors.
04:01:23brisque:I think cuckoo cycle was presented more as "do the economics make sense" more than anything else. at least, that's how I read John's post.
05:20:16gmaxwell:well the whole argument about memory hard functions orignially came in the scrypt paper for KDF, and at least there I think its broken because of this. How broken the goal is in the context of POW is less obvious to me.
05:25:02justanotheruser:thesis- memory hard PoW will work well when we have at home atomic mechanosythnthesis
05:25:20justanotheruser:*mechanosythesis
05:30:19sipa:justanotheruser: hard as in the mohr scale? :p
05:31:30justanotheruser:sipa: as in lots of distance the electrons or light needs to travel
05:36:22phantomcircuit:Taek42, lets say you have 1000 machines making $2/day
05:36:27phantomcircuit:or 1 machine making $1/day
05:36:29phantomcircuit:er
05:36:33phantomcircuit:1 machine making $3/day
05:36:41phantomcircuit:which do you think is more likely to be maintained?
05:56:18wumpus:when we have at home atomic mechanosythnthesis <- so you're saying you DON'T have that yet? puh
05:57:07sipa:yeah, i thought that that was what wizardry was all about
05:57:18sipa:seems you guys here are really just alchemists
05:57:23wumpus:a home atomic mechansynthesis was the first thing I got after my coffee machine
05:57:27wumpus:indeed
05:57:55gmaxwell:Who could live without beer?
05:57:55sipa:wumpus: before getting a Mr. Fusion? must have taken years to get it charged...
05:58:09justanotheruser:wumpus: wtf
05:58:25justanotheruser:why wouldn't you get the machine first, then print a coffee machine
05:58:58gmaxwell:I only have the models that can print beer and sourdough here.
05:59:25justanotheruser:doesn't sound like mechanosynthesis
05:59:33justanotheruser:more like biologosythesis
05:59:46justanotheruser:need to upgrade
06:00:07gmaxwell:going back on topic, I had a kind of concerning though a while back.
06:00:33gmaxwell:Presume someone made a biocomputer for sha256... potentially you could get some insane hashrates, but the latency would likely be very bad.
06:00:49Luke-Jr:I think I may need to implement heating on my Nest :|
06:00:54gmaxwell:So ... maybe you'd end up with the most efficient miner existing being only useful for attacks. :(
06:01:07Luke-Jr:gmaxwell: :|
06:01:18gmaxwell:Luke-Jr: I thought heating was a BFGMiner feature.
06:01:50Luke-Jr:gmaxwell: good idea, I should take my 65nm BFL stuff home and heat with it
06:01:56Luke-Jr:although it's loud :/
06:02:07gmaxwell:if your heater is just electrical the miners will be strictly better.
06:02:10Luke-Jr:* Luke-Jr ponders
06:02:20Luke-Jr:gmaxwell: well, there's heat pump. not sure how that is on efficiency
06:02:24gmaxwell:can you put them in the ac behind the air filter?
06:02:25sipa:if you write a Nest heater, call it MiNest
06:02:47gmaxwell:ah, heatpump is indeed usually pretty efficient, esp in florida.
06:03:17Luke-Jr:gmaxwell: actually, I think both of my air intakes are in convenient locations for putting miners in front of
06:03:28Luke-Jr:but.. both in places I wouldn't want noise
06:03:28gmaxwell:(they lose efficiency as the outside temp gets colder)
06:04:03Luke-Jr:* Luke-Jr ponders if there's a sane way to underclock miners just right so they don't need cooling
06:04:04wumpus:gmaxwell: why would a biocomputer be efficient at computing sha256?
06:06:43justanotheruser:Luke-Jr: doubt it will be sane while the $/hash is still decreasing like it is
06:07:04sipa:wumpus: massively parralel
06:07:05Luke-Jr:justanotheruser: remember, my primary goal is heating
06:07:28gmaxwell:wumpus: 'efficiency' is not precisely right. But the notion there is that you have self replicating machinery, so there is low marginal hardware costs for the massively parallel machine... and stored energy (chemical) simplifying supply.
06:07:43sipa:wumpus: it's not efficient at anything, but it can do millions of computations in parallel
06:07:51justanotheruser:Luke-Jr: oh, I guess 65nm should have given away that its worthless
06:07:56justanotheruser:worthless for mining I mean
06:08:08[nsh]:<gmaxwell> Presume someone made a biocomputer for sha256... <--- don't say things like that when kanzure is listening
06:08:18justanotheruser:lol
06:08:40justanotheruser:I am also curious how a biocomputer would be faster
06:08:46gmaxwell:(I didn't intend it this way, but I think this also may tie back into questions about gate limited vs energy limited functions)
06:09:15[nsh]:it's not faster; slime is just very parallelizable :)
06:09:56justanotheruser:so my asic might be a blob of slime in an open 100 acre field in the country?
06:09:58wumpus:gmaxwell: oh it's self-replicating and parallel, yes then eventually it may get insanely big and outcompute anything else
06:10:15[nsh]:* [nsh] isn't sure what gate-level DNA computers are at just now. maybe not too far from sha256 really...
06:11:07wumpus:[nsh]: you'd need quite a lot of gates working together to make sha256, though granted it's easy compared to a full CPU
06:11:24[nsh]:* [nsh] nods
06:12:38gmaxwell:wumpus: right, you'd engineer e.coli to spit out proteins or RNA sequences or what have you that do the computation. You build your process from parts we already know how to do massive, cheap, nanoscale fabrication (e.g. proteins)
06:16:23wumpus:gmaxwell: I wonder if the fabrication/assembly process would be precise enough to build enough units that exactly compute such a well-defined function
06:17:47wumpus:unlike biological functions that degrade gracefully, approximate-sha256 would be entirely useless
06:18:01gmaxwell:The error rate on DNA replication is insanely low at least, but that doesn't mean engineering that for everything is acceptably easy.. you can create error robust circuits with some modest blow up in complexity.
06:18:45[nsh]:i guess you'd just culture enough that a significant proportion could fail the calculation and devise a way to efficiently separate the ones that get it right
06:20:08gmaxwell:in any case, I'm mostly speaking from ignorance on the biocomputing front, the -wizards point was that high latency hashrate is only useful for attack... (and bio computers are a example of why you might have high hashpower high latency mining)
06:22:24wumpus:'the blob' attack on bitcoin :)
06:22:29gmaxwell:(wrt DNA replication, once all the error correction is considered: "reported mutation rates as low as 1 mistake per 100 million (10-8) to 1 billion (10-9) nucleotides, mostly in bacteria,")
06:24:17gmaxwell:which I think puts it better than typical commercial asic miners! :P (they're often run at ~1% error rate; and there aren't _that_ many operations in one hash execution...but again thats DNA replication, potentially the most optimized computational process in the universe.. :) )
06:24:38sipa:gmaxwell: probably not
06:24:52sipa:gmaxwell: it doesn't aim for minimizing errors
06:24:59sipa:without errors.. no evolution
06:26:36wumpus:on a small timescale it needs to minimize errors, otherwise it wouldn't be able to grow into a consistent organism
06:26:36[nsh]:(i'd argue that proton-->proton is the most optimized computational process in the universe, or probably something several orders more fundamental)
06:26:46gmaxwell:sure sure, but that doesn't mean engineering your own biological process with an error rate that low is easy at all.. those figures are also 'as low as', because they're specifically referring to low mutation (highly conserved) sequences.
06:27:20gmaxwell:the text continues: "and as high as 1 mistake per 100 (10-2) to 1,000 (10-3) nucleotides, the latter in a group of error-prone polymerase genes in humans"
06:32:00brisque:would suck to solve a block only to find it was not quite sha256
06:33:44sipa:"almost" is not entirely; in fact, "almost" is entirely not
06:34:10[nsh]:* [nsh] smiles
08:05:17cameron.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:17cameron.freenode.net:Users on #bitcoin-wizards: andy-logbot AaronvanW jtimon adam3us cbeams RoboTeddy grandmaster2 waxwing CoinMuncher p15 cym Adlai SDCDev jchp devrandom firepacket dgenr8 TheSeven coinheavy Trugnor justanotheruser fanquake Sangheili Dr-G2 altoz kmels koshii irc88 eristisk napedia tacotime jgarzik arowser wiretapped mortale brisque Starduster jaekwon1 go1111111 arubi zwischenzug zenojis LarsLarsen spinza BigBitz EasyAt Graftec_ samson_ gavinandresen emsid Adohgg Hunger-
08:05:17cameron.freenode.net:Users on #bitcoin-wizards: mkarrer drawingthesun Kretchfoop berndj [d__d] nsh jcorgan copumpkin c0rw1n lysobit yoleaux Transisto Iriez wizkid057 hollandais ebfull Aquent lnovy gribble hguux livegnik rfreeman_w stonecoldpat Dyaheon Fistful_of_coins digitalmagus MRL-Relay artifexd _2539 mappum jbenet [Derek] zibbo_ kanzure Luke-Jr petertodd optimator [\\\] Grishnakh warren puszl pi07r K1773R Eliel HM gmaxwell amiller_ crescendo cfields btc_ kgk bobke iddo comboy Happzz
08:05:17cameron.freenode.net:Users on #bitcoin-wizards: wumpus NikolaiToryzin coryfields michagogo LaptopZZ Meeh poggy_ Emcy_ UukGoblin danneu catcow TD-Linux [Tristan] helo smooth otoburb gwillen ryan-c mmozeiko roasbeef pajarillo sl01 Keefe Gnosis ahmed_ Muis Logicwax nanotube espes__ andytoshi so epscy BlueMatt tromp a5m0 starsoccer midnightmagic Graet kinlo pigeons BrainOverfl0w lianj Apocalyptic mr_burdell fluffypony bbrittain SomeoneWeird forrestv Anduck Nightwolf Krellan Taek42 asoltys
08:05:17cameron.freenode.net:Users on #bitcoin-wizards: @ChanServ phedny burcin lechuga_ abc56889 Alanius Guest47516 throughnothing harrow DoctorBTC phantomcircuit [nsh] sipa
08:08:08Trugnor:Trugnor has left #bitcoin-wizards
11:34:31jgarzik:http://nelenkov.blogspot.it/2014/10/revisiting-android-disk-encryption.html
11:34:46jgarzik:good read. Off-topic except for... scrypt! :)
11:37:12jgarzik:I wonder if I've ever met TierNolan in person?
12:07:28jgarzik:jgarzik is now known as jgarzik_
13:54:51fanquake:fanquake has left #bitcoin-wizards
15:49:05Dr-G2:Dr-G2 is now known as Dr-G
16:53:57spinza:* spinza looks for the tag
16:56:44jgarzik:spinza, I'm sure it's there somewhere, assuming infinite scroll back ;p
16:57:51spinza:was just wondering how long you've been saying random things ;)
16:58:36kanzure:just claim that you aren't standards compliant
16:58:38kanzure:problem solved
17:26:53SDCDev:SDCDev is now known as ^-_-^Rynomster^-
17:30:46jgarzik_:jgarzik_ is now known as jgarzik
19:52:51Disket:Disket has left #bitcoin-wizards
20:05:53Diskett:Diskett has left #bitcoin-wizards
20:33:50Taek42:would merge mined coins be parasitic?
20:34:28Taek42:say I play to have 10 million blockchains merge mined on Bitcoin, each paying their own reward
20:34:32justanotheruser:Taek42: they would be symbiotic
20:34:53Taek42:well the problem is that only the big miners could afford to merge mine all of them
20:35:30Taek42:so little miners could no longer profit, b/c big miners are making money on 10 million blockchains and little miners can only afford the 100 or 10,000 most valuable
20:37:25Luke-Jr:Taek42: outsource the resy
20:37:26Luke-Jr:rest
20:38:58Taek42:oh that's a good point
21:06:27amiller_:Taek42, yeah merge mining doesn't really cost anything, which is weird
21:06:45amiller_:that's because you can save on costs by not validating anything at al
21:06:49amiller_:(or outsourcing that validation)
21:07:19amiller_:this applies to Bitcoin today too, just it's more clear that there's a lot to save by mining a lot of chains
21:14:33jgarzik:amiller_, IMO that's the future, in fact
21:14:42jgarzik:Thousands of chains linked to each bitcoin block
21:15:03amiller_:you can't easily prevent people from doing merge mining and getting payment for it (out of band, i.e. payment in coins on other systems not btc)
21:15:04jgarzik:via merged-mining into coinbase, or pseudo-merged-mining into OP_RETURN embedded data in a tx
21:15:14amiller_:miners are affected just as much by fees in other things as they are for bitcoin fees
21:15:23jgarzik:bitcoin will become the root of thousands of decentralized db's
21:15:39amiller_:jgarzik, so i think that's the case because of how little incentive there is for validation
21:15:49amiller_:er i think that won't be the case
21:16:00amiller_:or maybe it will, but it means all those other coins are getting shit for security
21:16:30amiller_:it's not secure if most of your miners aren't actually validating the data, it's not even proof of publication if most of them aren't receiving/scanning the data
21:16:35kanzure:what are the regular incentives for doing your own validation?
21:16:44amiller_:kanzure, next to none
21:16:57amiller_:kanzure, it's almost always easier to let someone handle that for you, this is something that pools do automatically too
21:17:13amiller_:i think this can be addressed a *little* with the proof of storage based puzzles
21:17:23kanzure:merge mining involves less validation?
21:17:30amiller_:still doesn't give an incentive to validate, but it makes it less relatively expensive... you have to actually touch the data that way to mine
21:17:36amiller_:no merge mining doesn't involve less validation,
21:17:41amiller_:but it makes it more apparent what the missing incentive is
21:18:08Taek42:amiller_, if your miners aren't validating it only affects their chances of finding a block. Consider an exchange like Coinbase, but "Altbase". Altbase will never accept a block that's invalid, they will be validating everything
21:18:35Taek42:and all the clients will be validating everything too, it's just the miners that are outsourcing validation
21:18:37amiller_:Taek42, unless they think 50+% of miners/customers are relying on *their* definition of valid
21:18:57amiller_:clients may or may not be validating everything, mobile clients for sure arne't
21:21:03Taek42:all that matters is that everyone who's got significant stake in the game is doing validating
21:21:10Taek42:exchanges, small businesses, etc.
21:21:31Taek42:not a huge deal if a mobile client is misled, so long as that mobile client isn't receiving payments
21:21:35amiller_:i don't buy that kind of reasoning offhand
21:21:55Taek42:elaborate?
21:22:14amiller_:i feel like small groups of related persons/institutions who appear to be stakeholders tend to be disappointing and actually be susceptible to other incentives
21:22:59amiller_:the same reasoning seems to justify current banking/payment systems working great and we don't need this blockchain stuff
21:23:32amiller_:(in the couple of lines above i'm just fighting a heuristic with a heuristic)
21:24:18amiller_:so what could go wrong..... well if it's just everyone who's got significant stake in the game doing the validating it seems like it would be easy for them to push through code changes?
21:24:29Taek42:the major difference between a centralized solution and stake-only-validation is that *anyone* can perform validation in the second case.
21:25:20amiller_:hm so anyone *can* but hardly anyone *does* because it's expensive and most people have no other incentive to
21:25:36amiller_:why does that seem intuitively undesirable/insecure to me
21:25:57Taek42:if all the stakeholders started collaborating, they could probably pull something off
21:26:10amiller_:there's a difference between all the stakeholders
21:26:14amiller_:and all the largest united stakeholders
21:26:51Taek42:well, what would happen if coinbase, bitstamp, circle, and a handful of the other major players in the Bitcoin economy decided to only accept blocks following a certain different set of rules
21:27:04amiller_:everyone with a bitcoin is a stakeholder, suppose we have a nice economy where there are a million people with 1 bitcoin and say 100 people with 10,000 bitcoin.... those 100 people are the large stakeholders and you're suggesting that it's okay if they're the only ones doing validation
21:27:29kanzure:validation does not always have to happen in real time
21:27:42kanzure:sleeper nodes wake up months or years later and then check their data
21:27:58helo:large stakeholders would find themselves risking devaluing their stake
21:28:22amiller_:they always risk devaluing their stake no matter what choice they make
21:28:24kanzure:there may be some rule changes that you are uninterested in following, but nobody else who is interested in backtracking that far, so you may have to compromise a few times to find enough of a group to bother with a fork that you would be interested in
21:28:38amiller_:they could risk devaluing their stake by *not* pushing through a code change that seems like a good idea and is in "everyones best interest"
21:29:05Taek42:that is true
21:29:29amiller_:right now there's a sort of trifecta right, large mining pools, large companies, and nodes on the network
21:30:05amiller_:if the miners and stakeholdes tried to push through a rule breaking change, but not a bulk of the p2p nodes, then mobile clients would still receive only correct data from the p2p nodes
21:30:15helo:well, creating consensus confusion is a new risk created by modifying consensus rules. i guess there could be some modification of consensus rules to reduce the future chances of consensus confusion -.-
21:30:19amiller_:(this is assuming people iwth mobile clients are on the p2p protocol and not just logging into coinbase)
21:31:18amiller_:so miners don't just follow pools because they love ceding control to someone to do everyhting for them, it's just a) cheaper/easier, and b) the whole lottery pool lower variance thing right
21:31:38amiller_:so we can fix b with different reward rules and i don't want to talk about how/details for that part right now
21:32:38amiller_:i'm arguing that regarding a) it's possible through puzzle design to at least make independent validation cheaper and therefore more miners would do it, which makes it harder for the stakeholders/pool-operators to steer both sides
21:33:29kanzure:ah i thought you were aiming for an increase in not-just-mining p2p validation
21:33:51amiller_:well that would be nice too but i'm suggesting a way to achieve it that relies on mining incentives
21:34:33amiller_:so... well to put it another way, if you're a p2p node that put some investment in validation (i.e., you receive all the blocks and store enough state to check them) then hey that gets you most of the way to mining
21:35:36Taek42:Assuming that the miners sell their coins immediately, do we care that miners validate at all? If a miner releases an invalid block because untrustworthy-upstream fed them something following a hard fork, they'd only be hurting themselves unless you could _also_ get the rest of the ecosystem to accept the block (individual clients, corporate clients, and other miners)
21:36:15Taek42:even if exactly 0 miners on the network do validation, I would think that Bitcoin would be okay, on account of all the other players doing validation
21:36:27Taek42:bad blocks just get ignored
21:36:55Taek42:unless you think that the vast majority of players don't do validation at all
21:37:08amiller_:yes i think we should care because if miners are not validating themselves, they are delegating validation to a tiny number of servers
21:37:18amiller_:they suffer no penalty most of the time because they are optimistic
21:38:13amiller_:but it's eggs in few baskets, because it would be easier for an attacker to get that small number of servers to collude with, say, the small number of largest stakeholders
21:39:45Taek42:hmm. I think that it would be bad no matter what if the largest stakeholders were colluding. But I suppose it would be less bad if the miners weren't also colluding.
22:57:06gavinandresen:gavinandresen has left #bitcoin-wizards