00:17:34 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
00:32:02 | hanncx: | hanncx has left #bitcoin-wizards |
01:34:28 | MOONPLS: | MOONPLS is now known as emsid |
03:07:55 | amincd: | I'm intrigued by the SPV side-chain idea, but wouldn't the reanimation transactions require extremely long chains of block-headers? |
03:09:40 | amincd: | or am I getting it wrong? Is there anywhere that explains the concept in more detail? |
03:11:43 | gmaxwell: | amincd: No— for two reasons: we can construct compact proofs of chain work (e.g. one covering 50k blocks in 15.5kb), and the security is controlled by the sidechain, so it could pick the tradeoff required. |
03:13:34 | amincd: | gmaxwell: That's great. Is the compact proof of chain work experimental' cryptography or well tested? |
03:14:15 | gmaxwell: | it's not expiremental cryptography. It's just a merkel tree with special structure. |
03:14:36 | amincd: | gmaxwell: thanks for the info |
03:15:49 | gmaxwell: | Basically you add backpointers to far back blocks in the chain instead of just the previous block, 'merged mined', and the back pointers are conditionally valid based on the low low the target of the block turns out to be... such that a back pointer spanning X work is only valid if the block has a target matching an equal X amount of apparent work. |
03:16:20 | gmaxwell: | So you can't successfully produce blocks with fake back references skipping over blocks that didn't exist, without the same expected work as creating those blocks actually. |
03:17:03 | gmaxwell: | (this has higher variance than the hop at a time approach, so you do need to have an additional constraint that the proof has to at least show a minimum number of hops and not just the total amount of work) |
03:17:51 | gmaxwell: | amincd: and dude! why did you post that in the economic forum. That was a sure way to make sure no one technical saw it. :P |
03:20:16 | amincd: | gmaxwell: I posted it in the Dev and Technical Discussion forum too: https://bitcointalk.org/index.php?topic=365392.msg3900881#msg3900881 :) |
03:20:55 | gmaxwell: | weird. |
03:21:18 | gmaxwell: | So it's good news that this idea seems to have been independantly invented at least five times now. |
03:21:36 | gmaxwell: | (or at least this general class of ideas) |
03:22:10 | gmaxwell: | maybe it's actually a good one. :) |
03:23:04 | amincd: | I think it is a good idea. I just hope it's secure, with it relying on merge-mining and all |
03:23:10 | amincd: | without a lot of economic incentives |
03:23:26 | gmaxwell: | You can create economic incentives in the side chain, if further ones are required. |
03:23:57 | gmaxwell: | Though I challenge anyone saying it isn't to explain wtf is going to happen to bitcoin when the subsidy becomes negligible. :) Might as well solve the problem. :) |
03:24:05 | amincd: | true |
03:24:50 | gmaxwell: | amincd: for example, I think you could do something like have a small cut of coins moved in be set aside into a pool that provides transaction fees even when there are no transactions. |
03:25:22 | gmaxwell: | part of the idea of doing this is not having to answer every future question in advance though— build something sufficiently flexible and the details can be worked out in the side chains. |
03:27:12 | amincd: | gmaxwell: I agree. It opens up a huge number of possibilities |
03:27:54 | amincd: | and counter-acts some of the inflationary effect of altcoin experimentation |
03:28:46 | amincd: | I should say fragmentation effect, rather than inflationary. |
03:31:04 | gmaxwell: | right, ... it avoids the tying. Want to try a new kind of digital signature, transaction form, etc.. you have to start a new currency. It would be like needing to build another internet for every application or a new road network for every kind of car. |
03:31:59 | gmaxwell: | There are some neat hybrid things that can be done to improve the security too. |
03:34:20 | gmaxwell: | at least in the future… First— potentially speculative crypto stuff (see the CoinWitness thread), secondly you could do something like having remote-attesting full nodes verify the blocks and require their signatures, third— you could have a semi-federated model, kind of like in between the federated open transactions model where there are some preestablished servers that sign, and an anonymous blockchain.. where you could ... |
03:34:26 | gmaxwell: | ... have prior miners sign future blocks. so there there are a bunch of intermediate tradeoffs possible too. |
03:35:43 | amincd: | interesting.. |
03:42:04 | austinhill: | I've got some ideas on how the incentives on merged mining can be bootstrapped & deployed but the long term transaction fee model that allows for a large variance in business model types operating in different side chains with various types of transaction fees adapting to the proper use case is complex and needs some more work. For instance, a virtual world that wants a side chain for asset tracking of virtual objects & |
03:42:39 | kanzure: | austinhill: you are getting cut off (at "virtual objects &") |
03:43:00 | austinhill: | & an internal virtual world currency that might have billions of transactions as objects move from person to person, coins & objects are transferred in that world but has little interface with FIAT currencies aside from wanting to have blockchain type smart contracts & |
03:43:13 | austinhill: | open interoperability of their digital assets & currencies with other worlds would need a lower transaction fee then say a Wall Street Futures contract exchange where billions of dollars are traded back & forth in smart contracts and paying $1-$50-$500 is still a huge cost savings….. allowing for merged mining to account for these different types of transaction fees simultaneously is a hard problem….but fun & worthw |
03:43:24 | kanzure: | cutoff at "but fun & worthw" |
03:43:45 | austinhill: | kanzure: 'hile' - fun & worthwhile :) |
03:45:56 | kanzure: | isn't there a glaringly big attack vector even with merged mining. hm i'll fish out the name. |
03:48:54 | kanzure: | "Merge-mining looks like a nice way to achieve that, but in reality just leaves you vulnerable to zero-marginal-cost attacks until you get the support of a large % of the total hashing power." |
03:49:01 | kanzure: | nevermind, i thought petertodd had given that a more specific name |
03:49:42 | austinhill: | Getting support of a large % of the total hashing power is actually the easy part imho |
03:50:13 | kanzure: | that's easy in merge-mining? |
03:50:48 | kanzure: | couldn't the incentive to attack be greater than the incentive to merge-mine honestly for a large pool operator? |
03:51:44 | austinhill: | Namecoin is merged mined with something like 80% of the global bitcoin hashrate. Very little incentive to be honest there (I've seen reported it accounts for an extra 3% revenue for miners who merge mine it) |
03:52:43 | kanzure: | well, of course, i should limit my comments to the introduction of a new thing to be merge-mined, where there's a bootstrapping phase (because anything new to merge mine is always going to be easily attackable in the same way most of the altcoins are vulnerable to large pools or hugs of death) |
03:53:58 | austinhill: | A properly bootstrapped merged mined system that generates 5-30% of extra revenue for BTC miners with 75%+ of hashrate should be reasonably secure with proper economic incentives but that doesn't happen over night so the early days of aligning proper incentives & launching with a large distributed has rate is important |
03:54:10 | kanzure: | 75% of total hashrate? |
03:54:13 | mr_burdell_japan: | mr_burdell_japan is now known as mr_burdell |
03:54:17 | gmaxwell: | kanzure: worked out fine for namecoin which is generally seen as complementary to bitcoin. AFAIR it only did not work out fine for a single coin, but it's sort of become urban legend now. |
03:54:58 | kanzure: | many of the altcoins are getting "attacked" almost immediately by eager early miners |
03:55:01 | gmaxwell: | austinhill: currently namecoin is +1.39% though it used to be somewhat morei n the past. |
03:55:42 | gmaxwell: | kanzure: sure though thats not merged mined stuff. |
03:55:43 | austinhill: | gmaxwell: thanks - namecoin hasn't taken off due to other reasons, but still a great case study in merged mining |
03:56:26 | kanzure: | merge mining prevents early chainforks? i forget the right term |
04:04:01 | gmaxwell: | amiller: so that bloom-tree paper (which is neat!) has amused me with its layering of different structures. I want to add something like paillier encryption or an oblivious transfer to it in order to complete the orgy of different techniques. |
04:57:40 | ebfull: | 2-way-pegging: requires the sidechain use the same proof-of-work as bitcoin? |
05:01:43 | Luke-Jr: | ebfull: no |
05:02:11 | Luke-Jr: | but it does require a sane proof-of-work (IFF it uses a PoW at all) |
05:02:20 | Luke-Jr: | so, eg, no scrypt |
05:03:12 | Luke-Jr: | but, SHA256d POW is pretty much ideal right now and going forward |
05:03:29 | Luke-Jr: | well, right now maybe not so much ideal as "least bad" |
05:23:43 | vetch: | Luke-Jr: what's your criteria for calling it "least bad"? |
05:25:00 | gmaxwell: | I dunno about luke— No ambigious security assumptions, cheap to verify. Generally well understood; Manufactured by a diverse set of hardware makers, etc. |
05:25:05 | Luke-Jr: | vetch: 1) easy to verify; 2) hard to generate; 3) equally hard to generate for everyone (ASICs) |
05:25:47 | vetch: | alright, I thought "least bad" implied there was something tangibly wrong with it |
05:26:09 | Luke-Jr: | vetch: well, right now there are a handful of hw vendors which can do it dirt cheap compared to everyone else |
05:26:15 | gmaxwell: | vetch: computational POW is not a perfect model of what we wish we had. |
05:27:23 | Luke-Jr: | vetch: some of whom *cough*KnC Bitfury*cough* are in fact abusing that position |
05:28:51 | Luke-Jr: | gmaxwell: ever think of doing a writeup about smart property mining chips? seems like something we could get the community to push for, and maybe get manufs onboard committing to |
05:29:09 | vetch: | KNC looks to have bitten themselves in the ass by deciding to make an scrypt(1024,1,1) ASIC |
05:29:21 | Luke-Jr: | vetch: ? |
05:29:33 | Luke-Jr: | did they even say it was (1024,1,1)? |
05:29:43 | vetch: | it's for litecoin mining presumably |
05:30:13 | gmaxwell: | sure but why make it less general than you must. :P |
05:30:18 | vetch: | they have litecoin logos on their front page, so it's a fairly safe assumption |
05:30:21 | Luke-Jr: | I've forgotten the scrypt details already. Is a chip that can do different N factors really much slower? |
05:30:36 | phantomcircuit: | Luke-Jr, knc's cost is actually insanely high |
05:30:40 | gmaxwell: | Surely not so for some designs, probably so for others. |
05:30:44 | Luke-Jr: | phantomcircuit: ? |
05:30:47 | gmaxwell: | s/cost/price/ |
05:30:54 | phantomcircuit: | gmaxwell, no cost |
05:31:02 | vetch: | wouldn't it be a complete waste to have bigger scratch pads on chip if all you ever want to do is mine litecoin? |
05:31:18 | vetch: | they'll already be whales in a very small litecoin pool. all the other altcoins are even smaller. |
05:31:19 | Luke-Jr: | vetch: that isn't likely. litecoin is doomed. |
05:31:25 | gmaxwell: | vetch: on 28nm die area isn't all that costly, esp if you need space to sink heat. |
05:31:37 | phantomcircuit: | their bin/failure rate is high enough that their true cost is about 3-4x what other manufacturers are at |
05:32:04 | Luke-Jr: | phantomcircuit: that's still pretty low, I think |
05:32:13 | vetch: | phantomcircuit: doesn't the bin not matter? the chip is largely individual cores for sha256d, you can just disable the bad bits and carry on |
05:32:22 | phantomcircuit: | Luke-Jr, it's really not |
05:33:02 | gmaxwell: | vetch: if your design is good and builds the parts you can't tolerate failing very robustly... |
05:33:30 | gmaxwell: | Luke-Jr: I don't really have the bandwidth to do it... there are a lot of interesting things that need to be thought through to do it well. |
05:33:46 | vetch: | gmaxwell: not sure what you mean |
05:34:33 | phantomcircuit: | vetch, you still have to pay for the dead chips |
05:34:36 | gmaxwell: | vetch: binning doesn't help you when your logic failure results in your clock whole clock network being grounded, or a failure in the serial interface. |
05:34:42 | phantomcircuit: | 20% bin rate? chips are 20% more expensive |
05:34:46 | gmaxwell: | phantomcircuit: he's pointing out that there should be _no_ dead chips. |
05:35:01 | phantomcircuit: | gmaxwell, oh |
05:35:31 | phantomcircuit: | vetch, the chips are sectors in sectors, they tend to fail as whole sectors not individual hashing cores |
05:35:35 | Luke-Jr: | phantomcircuit: 25% more expensive* |
05:35:53 | vetch: | gmaxwell: right, so some failures in the cores lead to catastrophic failure. got it. |
05:35:57 | phantomcircuit: | and they're unrolled pipelines, so if even a tiny portion of the chip is screwed the entire pipeline is broken |
05:36:21 | vetch: | gmaxwell: doesn't it make more sense to do what everybody else is doing then? many small chips rather than mammoth dies? |
05:36:54 | vetch: | presumably bitfury, ant miner et al have failure rates too but they don't care because the chips are small and cheap anyway |
05:37:14 | phantomcircuit: | vetch, yes and no, theoretically mammoth chips should be cheaper since the assembly is easier |
05:37:51 | phantomcircuit: | but in practice the components are more expensive, and you need water cooling |
05:37:57 | phantomcircuit: | maybe some day... |
05:38:02 | gmaxwell: | my preference generally is for small chips, there are non-linearities in package costs that make the optimum not the largest possible, at least from the information I've seen... not just for defect handling, but I think the wave of the big chip makers had some non-techie business people engaging in a bragging game wrt fastest chip. ... or they just have better assembly deals than I'm aware of. |
05:38:19 | vetch: | phantomcircuit: their boards must be very expensive to produce. their copper layers must be a mile thick to provide the current at such a low voltage. |
05:38:45 | phantomcircuit: | vetch, yeah you're talking like 4oz copper boards |
05:39:02 | phantomcircuit: | lets do the math |
05:39:13 | phantomcircuit: | the chips run at about 0.8v |
05:39:26 | phantomcircuit: | ct chips are pulling ~450w each |
05:39:34 | phantomcircuit: | 562.5 amps |
05:39:41 | phantomcircuit: | lol |
05:39:49 | phantomcircuit: | i had never done that before |
05:39:51 | phantomcircuit: | that's hilarious |
05:39:55 | vetch: | that's ridiculous |
05:40:19 | vetch: | they must be dissipating half their power just into the power rails from the DC-DC to the chip |
05:40:30 | gmaxwell: | phantomcircuit: you hadn't? perhaps now my past remarks of ... surprise ... at their density decisions make more sense to you. :) |
05:41:14 | phantomcircuit: | gmaxwell, i had done the 12v calculation for that giant fat rail |
05:41:33 | phantomcircuit: | actually i was trying to figure out what the fire risk was... |
05:41:41 | phantomcircuit: | hint significant |
05:41:42 | vetch: | gmaxwell: looks like they aren't doing the mammoth chip thing for the scrypt miner, looks like antminer with lots of little chips on long heatsinks https://www.kncminer.com/pictures/product/big/5453_big.png |
05:41:44 | gmaxwell: | in any case, considering how poorly all the big chip places have run their businesses, I don't feel like I'm making bad assumptions in concluding that — no, it's probably not that they know something I don't— their design is probably just stupid. :) |
05:42:17 | gmaxwell: | vetch: or they're not making the chips at all and they just contracted with the gridseed folks |
05:42:22 | gmaxwell: | (same engineers that did the avalon) |
05:42:26 | phantomcircuit: | that |
05:42:29 | phantomcircuit: | definitely that |
05:42:40 | phantomcircuit: | there's also no way they're delivering neptunes |
05:42:43 | vetch: | gmaxwell: why the hell is it so expensive then? |
05:42:49 | phantomcircuit: | or jupiters or whatever the hell they're claling them |
05:42:53 | gmaxwell: | vetch: charge what the market will pay, of course. |
05:43:10 | vetch: | phantomcircuit: go do the calculations on the neptune, they don't look pretty |
05:43:12 | phantomcircuit: | they've put several Ph of capacity online very recently for their plan b nonsense |
05:43:34 | phantomcircuit: | vetch, im about 85% sure they wont be able to *ever* deliver the neptunes |
05:43:37 | Luke-Jr: | vetch: you realise KnC didn't make their first chips either, right? |
05:43:42 | Luke-Jr: | KnC has *always* outsourced that |
05:43:43 | vetch: | 30% more efficient than the previous one, 5 times the speed, in the same size box |
05:44:38 | gmaxwell: | phantomcircuit: hey at least they have lots of rapidly depricating assets to liquidate when the lawsuits start. |
05:44:43 | vetch: | Luke-Jr: I sort of assumed that. all of the companies like has fast, BFL, etc just seem to be subcontracting fronts. that's why they're so delayed because they have absolutely no idea what the actual people developing them are doing. |
05:45:09 | vetch: | phantomcircuit: it doesn't look physically possible with the specification they have given. |
05:45:13 | Luke-Jr: | vetch: actually, I think BFL does really design their own chips |
05:45:31 | Luke-Jr: | of course, that isn't the marketting people :p |
05:46:53 | vetch: | ASICminers new design sounds interesting at least. |
05:47:45 | vetch: | if they actually meet their design specifications they'll be under half a watt per gigahash per second. |
05:47:52 | Luke-Jr: | if. |
05:48:03 | Luke-Jr: | I think that's what everyone's been trying for, since forever. |
05:49:18 | phantomcircuit: | Luke-Jr, iirc bfl effectively purchased the company that designed their original chips |
05:49:25 | phantomcircuit: | im not sure that really counts |
05:50:03 | vetch: | Luke-Jr: if they manage it, it could be interesting |
05:50:26 | Luke-Jr: | phantomcircuit: lol |
05:50:56 | vetch: | Luke-Jr: I expected Bitfury 2 to be something incredible given his first design, but it looks to be just a bug fixed version that still doesn't meet the original design specs (5GH/s as laser etched on the package) |
05:51:10 | Luke-Jr: | >_< |
05:52:05 | phantomcircuit: | vetch, there's a certain amount of luck involved with chip design |
05:52:13 | phantomcircuit: | especially at smaller process nodes |
05:52:40 | vetch: | not like he doesn't have all the money in the world to throw at it though |
05:53:14 | phantomcircuit: | vetch, for 20nm you're talking about 10m usd |
05:53:25 | phantomcircuit: | i dont think anybody has the kind of money to just throw at things |
05:54:55 | vetch: | phantomcircuit: I bet he does. between the chips being sold for like 10 euro each and cex.io drawing in every gullible bitcoiner in the land |
05:55:31 | vetch: | phantomcircuit: I'm certain there's whole DCs of these things sitting around http://www.bitfurystrikesback.com/product/bitfury-razz-used/ |
05:56:05 | phantomcircuit: | vetch, ~12Ph/s |
05:56:15 | phantomcircuit: | which is more like 12 rooms |
05:56:17 | gmaxwell: | vetch: depends on how much of his funds were stolen by cheap subcontractors. :P |
05:56:18 | phantomcircuit: | but ok |
05:57:06 | vetch: | phantomcircuit: that's ridiculous if true |
05:57:41 | vetch: | 4800 Razz, 3kW each, 14MW total? |
05:57:58 | vetch: | (to make up 12PH with those units) |
05:58:35 | phantomcircuit: | vetch, i can put 15Th/s in a single rack with those units |
05:58:45 | phantomcircuit: | actually the biggest problem is they're stupid heavy |
05:59:04 | vetch: | bigger problem is that they're 7250 euros plus shipping. |
05:59:20 | phantomcircuit: | vetch, sure if you buy one... |
05:59:39 | vetch: | oh yeah, bet they're a few hundred bucks each |
06:00:26 | vetch: | looks like mainly off the shelf parts. 4 PC power supplies, 2 raspberry pi (why?) |
06:00:43 | phantomcircuit: | uh |
06:00:51 | phantomcircuit: | they're mainly custom boards |
06:01:25 | vetch: | those are definitely raspberry pi controlling them though, which seems like a weird cost add |
06:01:45 | phantomcircuit: | vetch, an rpi is like $45 |
06:01:49 | gmaxwell: | vetch: rpi is unreliable and super slow... but derp derp. thery're trendy and a frequent pick by people who've done no research. |
06:02:17 | vetch: | yeah, so $90 to control some boards with SPI. surely if they're already making custom boards there's a better SoC |
06:02:44 | phantomcircuit: | gmaxwell, the other options usually suck in other ways, or require broadcom to give you docs |
06:02:50 | phantomcircuit: | which some russian dudes cant get |
06:03:54 | gmaxwell: | phantomcircuit: the mips microcontrollers the chinese folks are using are pretty good, the spoondooles device appears to be an omap3 (maybe it's actually a beaglebone, either way, some soc)... both much better choices. |
06:04:18 | gmaxwell: | rpi also draws a lot of power considering, way more than both the omap boards I have here. |
06:04:38 | phantomcircuit: | a lot of power in a device pulling 3kW :P |
06:04:54 | vetch: | if you're running 4800 of them then it all adds up |
06:05:19 | phantomcircuit: | gmaxwell, the main thing is they're super easy to source |
06:05:24 | gmaxwell: | it's not just that, more heat on the controller board.. contributes to them being unreliable I expect. |
06:05:36 | vetch: | that's like 38KW just in raspberry pi boards |
06:06:00 | vetch: | two raspberry pi per box, drawing 4W each, 4800 boxes |
06:06:26 | phantomcircuit: | gmaxwell, huh? the rpi isn't near the heat source in the 6U units |
06:07:00 | vetch: | it's behind the heat source, looks like the fans blow in from the front and out over the raspberry pi |
06:07:26 | vetch: | http://www.bitfurystrikesback.com/wp-content/uploads/2014/03/bajanback.png |
06:07:51 | gmaxwell: | phantomcircuit: it's a heat source for _itself_ |
06:07:52 | phantomcircuit: | lol that's funny |
06:07:53 | vetch: | if you were pulling through the back you would be going against the fans in the PC power supplies, which draw in from their side and out the back |
06:08:00 | phantomcircuit: | they're in the front on other units |
06:08:47 | phantomcircuit: | gmaxwell, yeah but there's a lot of air flow there i cant imagine they would overheat |
06:09:02 | phantomcircuit: | their max TDW is like 5W |
06:09:42 | vetch: | there's a shroud over the pi if you look carefully. it plugs into the pi's header and breaks out into two cable headers |
06:10:28 | vetch: | it's actually numbered too. 587. |
06:12:00 | gmaxwell: | so instead of mining how about an altcoiny idea. |
06:12:51 | phantomcircuit: | gmaxwell, ooh fun |
06:13:40 | gmaxwell: | I was thinking today about closed membership mining: mining where there is some set of allowed keys and you have to be a member of the set in order to produce a block. You can imagine 'blockchain' things where the blocks are signed by the prior miners. ... but then, of course, why would they let anyone else in |
06:13:51 | gmaxwell: | ...eg. admit a block from a new party? |
06:14:07 | gmaxwell: | so I came up with an idea that I thought might be neat. |
06:15:03 | gmaxwell: | imagine there is a pow blockchain where a member of the set of prior (or recent or whatever) miners must also sign the block. But the block subsidy is split between the signer and the miner. |
06:15:13 | gmaxwell: | Obviously if you're a signer you'll sign your own. |
06:15:33 | gmaxwell: | but now there is an incentive to admit more people to the set. |
06:16:45 | gmaxwell: | you can further improve things by setting up the signatures as single show, and having the existance of some conflicting signatures forfeit held coins or whatever... but the main notion was that you could potentially have an incentive to admit new players. |
06:17:12 | phantomcircuit: | gmaxwell, dat oligopoly |
06:17:59 | gmaxwell: | yea absolutely. |
06:19:19 | gmaxwell: | well its interesting, basically all consensus research in the past has been on consensuses where the participants are enumerated in advance... which is inherently an oligopoly. POS is this too, just with a bigger collection and some succession rules. The non-anonymousness of it is ugly, so I wondered if there were in-between solutions. |
06:19:23 | kanzure: | gmaxwell: why wouldn't the private set of miners just strike deals with outside amounts of hashpower? |
06:19:55 | kanzure: | oops, i didn't wait to read your block subsidy split. |
06:21:01 | kanzure: | for a small enough number of participants in a closed membership mining scenario, why bother with pow? |
06:21:52 | gmaxwell: | kanzure: because without it replacement histories are costlessly simulatable by any of the prior set of approved signers. |
06:22:06 | gmaxwell: | and because it gives a new participant something to bring to the table to get themsevles admitted. |
06:38:12 | phantomcircuit: | gmaxwell, blargh firefox ui locks up randomly |
06:42:58 | phantomcircuit: | bwahaha |
06:43:07 | phantomcircuit: | turned the fan to full blast |
06:43:10 | phantomcircuit: | laptop is cold |
07:19:38 | wump: | wump is now known as wumpus |
08:23:47 | wallet42: | wallet42 is now known as Guest25245 |
08:23:47 | wallet421: | wallet421 is now known as wallet42 |
11:59:17 | c0rw|sleep: | c0rw|sleep is now known as c0rw1n |
12:23:56 | HobGoblin: | HobGoblin is now known as Guest51740 |
12:41:47 | nsh__: | nsh__ is now known as nsh |
12:51:35 | mike4: | mike4 is now known as money |
15:19:37 | stonecoldpat: | is there any examples of blind signatures being used in any fancy bitcoin contracts / protocols being used? |
15:19:46 | stonecoldpat: | (working ontop of bitcoin blockchain) |
15:25:00 | gmaxwell: | stonecoldpat: Unfortunately the most likely example I can give to you for that results in indistinguishable transactions: https://www.realitykeys.com/ |
15:25:56 | gmaxwell: | (not a traditional blind signature— well, since we use ECDSA there can't be any overly-traditional blind signatures. :)) |
15:31:08 | stonecoldpat: | gmaxwell: that's true, cheers i'll have a look into it |
15:32:58 | maaku: | maaku is now known as Guest93689 |
15:39:06 | aynstein: | aynstein has left #bitcoin-wizards |
16:25:33 | dansmith: | dansmith is now known as dansmith_btc |
17:28:25 | nsh_: | nsh_ is now known as nsh |
17:58:07 | BurritoBazooka: | BurritoBazooka is now known as Burrito |
18:08:35 | zzyzx: | zzyzx is now known as roidster |
18:09:17 | roidster: | roidster is now known as Guest54654 |
19:20:05 | adam3us: | gmaxwell: "small chips, there are non-linearities in package costs that make the optimum not the largest possible, at least from the information I've seen.." i believe you are right. spondoolies has like 192 chips on their SP10 which is 40nm TSMC but more energy efficient, cooler (and hence air coolable) and denser (1.4TH/1.25u rackmount) than other peoples 28nm |
19:21:03 | nsh_: | nsh_ is now known as nsh |
19:25:28 | adam3us: | gmaxwell: you said that i recall that you had a demo scrypt asic? and it was more speed advantage over GPU than sha256? i was checking that claim just now and i am not sure it adds up, at least so far with eg knc titan scrypt $10k for 250MH vs say 20x $500 amd 7970 at 400KH/s is 250000/(400*20)=31x advantage ASIC to GPU. and yet SHA256 is far higher right? |
19:26:25 | vetch: | adam3us: the scrypt ASIC are vastly more efficient than GPUS, but the sha256 side of them is uselessly inefficient. |
19:28:18 | vetch: | KNC are using the same gridseed chips as the other group are apparently, just boxed up without the ridiculous heatsinks. |
19:28:54 | adam3us: | vetch: no i mean dedicated SHA256 vs GPU (ignoring the token SHA256 in the scrypt ASICs). eg SHA256 spondoolies $9k 5.4TH/s vs 18x $500 amd 7970 666MH/s 5400000/(18*666)=450x.. so SHA256 seems something like 15x more ASIC amenable? |
19:30:21 | vetch: | without doing the maths, it seems like the scrypt ASIC are far more power efficient than the equivalent sha256d ones were |
19:30:40 | vetch: | http://i.imgur.com/95xph4m.jpg < this PCB layout is obscene though, whatever idiot came up with that? |
19:33:24 | tromp_: | normalized on hash performance, scrypt ASIC/GPU dollar advantage does seem way higher than SHA256 |
19:33:45 | tromp_: | power efficiency advantage is a separate issue |
19:34:32 | vetch: | it's fairly significant really, the scrypt ASICs really draw nothing in comparison with their hulking SHA256 counterparts |
19:35:00 | vetch: | the step in power efficiency from GPU > ASIC for scrypt is a lot higher |
19:35:50 | vetch: | wait, maybe that's false. let me work it out. |
19:36:09 | tromp_: | yes, run the numbers like adam did for dollars |
19:36:20 | gmaxwell: | adam3us: I do, I was talking about power efficiency, though it was also purchase price, but gridseed basically increased their prices by a factor of 5x. KNC, likewise, is charging what people will pay. |
19:37:05 | gmaxwell: | adam3us: purchase prices are unrelated to anything buy how many suckers there are out there right now. :) |
19:37:28 | adam3us: | gmaxwell: oh gotcha. its early days so the manufacturer can put a bigger mark up. |
19:37:48 | vetch: | adam3us: the timeframe has nothing to do with it. the producer will charger what the market will pay |
19:38:24 | vetch: | look at the USB block eruptors, they sold for a ridiculous cost given what they were.. but they charged that because people would pay it. |
19:42:39 | vetch: | it really works well on this sort of thing because there's very limited suppliers and not many people have any idea what the real cost or return from these things is. it's completely speculative. |
19:42:58 | adam3us: | gmaxwell: so this knc scrypt pre-order has no power predictions "use std atx powersupply" so i cant calc anything. recall your sample scrypt asic hashrate and power draw? (i do recall your argument now that you mention it about the scrypt asic being denser as the sha256 are power-density limited) |
19:43:22 | vetch: | adam3us: they use the same grid seed chips, they have known attributes |
19:44:00 | vetch: | 5 chips is 350kh/s and draws 8W doing so. easy enough to work from there. |
19:44:02 | adam3us: | vetch: which are advertised at unit levels somewhere? or the non-knc scrypt box? |
19:44:20 | adam3us: | vetch: ok that'll do as a crude approx (whole system better as includes fans, etc) |
19:44:56 | vetch: | adam3us: https://github.com/gridseed/gc3355-doc/raw/master/GC3355_DataSheet.pdf |
19:45:47 | vetch: | the official documentation doesn't include the power for the SCRYPT side, so I'm said real-world usage |
19:46:29 | vetch: | adam3us: oh yes it does, page 10 |
19:47:35 | adam3us: | vetch: so 44kh/W for gridseed ASIC vs 2kh/W for amd 7970 GPU |
19:47:49 | adam3us: | vetch: does the datasheet say 350kh/w by 8W? |
19:48:15 | vetch: | no, the data sheet says 60kh per chip at 0.44W, which is probably optimistic |
19:48:17 | tromp_: | it says 60Kh per chip |
19:48:32 | vetch: | 350kh/s at 8W is the power usage of the assembled miner that uses 5 chips |
19:49:05 | tromp_: | so KnC uses 4K of these chips to get 250Mh? |
19:49:24 | vetch: | looks like it. their diagrams mesh with that. |
19:49:49 | gmaxwell: | vetch: not optimistic, but just measured at the chip without psu inefficiencies. |
19:50:15 | vetch: | tromp_: https://www.kncminer.com/pictures/product/big/5453_big.png < not the big monolithic chip, lots of little ones on big heatsinks like antminer does with theirs |
19:50:53 | vetch: | gmaxwell: 1.2W > 0.44W with PSU inefficiencies? |
19:51:09 | tromp_: | amazing they can fit 1024 chips on each od those circuit boards... |
19:51:44 | vetch: | gmaxwell: they're dropping 12v to ~1v with 36% efficiency? |
19:52:21 | adam3us: | ok so then SHA256 amd gpu 3.33MH/W vs 1120MH/W for spondoolie SP10 (1.4TH 1.25kW) |
19:53:09 | vetch: | http://cryptomining-blog.com/wp-content/uploads/2014/04/gridseed-blade-miner-2.jpg < is it just me, or does this "grid seed miner blade" look incredibly like what KNCminer would be putting in their scrypt miner? |
19:53:51 | vetch: | that's apparently 11MH/s, tromp_'s doubts about being to pack that many in there seems well founded |
19:54:16 | vetch: | http://cryptomining-blog.com/wp-content/uploads/2014/04/gridseed-blade-miner-1.jpg |
19:54:27 | adam3us: | gmaxwell: ? 336x power efficiency SHA256 ASIC vs GPU, compared with 22x efficiency Scrypt ASIC vs GPU same result 15x power amenability and 15x cost amenability to ASIC for Scrypt favor. did i screw up calc? 44kh/W for gridseed ASIC vs 2kh/W for amd 7970 GPU |
19:56:29 | vetch: | tromp_: http://i.imgur.com/nwzwiSH.jpg < interesting packing efficiency |
19:56:52 | vetch: | low heat output must mean they can really those things onto a board |
19:57:15 | adam3us: | (assuming approx 400kh/200W for scrypt from scrypt mining hw guide and 666MH/200W from bitcoin mining guide wiki) |
19:58:10 | vetch: | actually according to the seller these things only pump out 6MH total? that doesn't sound right. |
19:59:18 | vetch: | at any rate, I don't think it's possible for KNCminer to cram 100MH into a box the size that they are showing. |
20:02:21 | adam3us: | tromp_: the question for someone is to survey PoWs and work with a hw expert to estimate basic hw optimization to see the ratio of GPU to ASIC advantage. i think its the only way to know actual ASIC resistance. software people are not good at predicting hw optimization. know any ASIC experts? |
20:02:43 | vetch: | that would be gmaxwell. |
20:02:58 | gmaxwell: | not really. |
20:06:14 | gmaxwell: | adam3us: The numbers I had for gridseed were something like 140KH/w and by comparison the avalon batch 1 was about 110MH/w. |
20:07:48 | adam3us: | vetch: these ASIC guys are wizards. it looks like a fun area but we sw geeks or dabblers dont know it well enuf. it'd take a decade to get to one of these guys state. just rent their brain as co-author, much easier. |
20:07:50 | vetch: | gmaxwell: completely unrelated to the current conversation, I'm *still* unable to come up with a proper number for how long Armory takes to load. their new version just took 25 hours to "prepare databases" and then tried to open hundreds of sockets to talk to bitcoind, and crashed. |
20:08:33 | adam3us: | gmaxwell: looks like gridseed sucks then relative to avalon... 110MH/w is 3-orders magnitude better |
20:09:08 | adam3us: | gmaxwell: or wait are u saying avalon SHA256? |
20:09:18 | vetch: | avalon is SHA256 only |
20:09:26 | gmaxwell: | adam3us: yes, sha256. |
20:09:31 | vetch: | gridseed is the *only* scrypt ASIC |
20:10:50 | gmaxwell: | the gridseed is a weird chip because it's also a sha256d miner. |
20:11:12 | vetch: | does anybody use that though? |
20:11:27 | vetch: | I've never heard of anybody using it, it's unstable |
20:12:33 | gmaxwell: | vetch: yea, it's unstable because the power is underprovisioned for it. |
20:12:46 | gmaxwell: | on all the existing boards. |
20:12:50 | gmaxwell: | (and maybe other reasons) |
20:16:38 | tromp_: | adam3us: no; i don't know any ASIC experts unfortunately. my background is theoretical computer science |
20:16:43 | adam3us: | gmaxwell: ok correcting for gridseed 140kH/w vs 44kH/w its 70x more power efficient ASIC vs GPU. and again SHA256 w. spondoolies SP10 is 336x power efficient so still SHA256 is ~5x more ASIC amenable? |
20:17:11 | vetch: | adam3us: are you comparing the hash rates directly? 1MH on scrypt is nothing like 1MH on SHA256 |
20:17:14 | adam3us: | tromp_: time for interdisciplinary collab. unfortunately the asic clever guys are busy churning out gen3 asics so i am not sure they have time to play |
20:17:17 | tromp_: | adam3us: it's not just GPU vs ASIC. it's CPU vs GPU vs FPGA vs ASIC |
20:17:36 | gmaxwell: | adam3us: I don't know why you're using the SP10 as a reference point. |
20:17:45 | gmaxwell: | I wouldn't have done that (considering it didn't exist) |
20:17:47 | adam3us: | gmaxwell: ok avalon? |
20:17:54 | gmaxwell: | I used the avalon miners as a reference point. |
20:18:04 | adam3us: | gmaxwell: exist? people are running them i think (just) |
20:19:36 | gmaxwell: | adam3us: yea, I have one now. :) a problem there is that it's comparing unequal technology (e.g. I couldn't have used those numbers before because they didn't exist). one thing to do would be to compare the gridseed in sha256d mode against gridseed in scrypt mode. |
20:19:40 | adam3us: | gmaxwell: aim is apple to apple. as scrypt is newish? i guess thts difficult to say. latest only? scrypt vs latest sha256. or scrypt vs gen1 sha256 asic. latter pbably fairer as scrypt no doubt can improve analogously. ok fair. |
20:20:14 | adam3us: | gmaxwell: yeah but the gridseed sha256 is maybe not trying (after thougt) |
20:20:25 | gmaxwell: | yea, I would have been comparing 1MH/j to avalon batch1 which is 110MH/j. |
20:20:26 | adam3us: | gmaxwell: lets use avalon gen1. i' down with that |
20:21:12 | gmaxwell: | adam3us: my understanding is that it was the other way around: the gridseed chips were originally intended to be sha256d chips that had scrypt as an expirement. When it worked thats what they were mostly used for. |
20:21:52 | adam3us: | gmaxwell: oh interesting. so that scrypt maybe its weak area. even more interesting :) |
20:22:25 | vetch: | I doubt there's much money in making a dedicated chip just for scrypt |
20:23:13 | gmaxwell: | vetch: right, well that was their hedge, but I think that the scrypt part has been successful enough that no one would use gridseeds for sha256d mining. |
20:23:16 | adam3us: | vetch: miners are not fussy. if they can dominate the scrypt alt market and litecoin has a usable price & depth... they'll take it. question is if they react |
20:23:45 | adam3us: | vetch: and change the hash. that is a debate warren is having (he's on the no side from what i saw) on the litecoin forum |
20:23:53 | vetch: | the only reason litecoin exists is because butthurt CPU/GPU miners needed something to do with their expensive hardware. |
20:23:59 | vetch: | adam3us: exactly. |
20:25:09 | tromp_: | vetch: the gridseed specsheet didnt show (unless i missed it) how much memory is on there for scrypt. do you know? |
20:25:16 | vetch: | gmaxwell: yes, but at this point I doubt there's enough funds moving into litecoin and the other alt coins to cover the costs of making a dedicated scrypt chip. if what you've heard is true, we only have one now because of a surprisingly successful experiment. |
20:25:54 | vetch: | tromp_: I've no idea. I think litecoin uses 128kB scratch pads though doesn't it? four cores each with their own scratch pad. |
20:25:58 | gmaxwell: | vetch: there are several companies that claim to be doing it, but gridseed beat them to market. |
20:26:21 | vetch: | tromp_: yeah, 128kB per core, four cores. |
20:26:31 | tromp_: | where does it show 4 cores? |
20:26:46 | vetch: | think it's somewhere in that document, one second |
20:26:55 | vetch: | "4 LTC Units" |
20:26:58 | vetch: | "160 BTC Units" |
20:27:07 | tromp_: | ah, ok |
20:27:19 | tromp_: | is it safe to assume the memory is SRAM? |
20:27:33 | vetch: | your guess is as good as mine. |
20:27:53 | tromp_: | the KnC machine would have a total of 2GB SRAM then |
20:28:44 | tromp_: | it's rare to find that much SRAM in one place! |
20:28:59 | vetch: | wonder if one of those guys who do chip decapping would be willing to do a gridseed chip |
20:29:29 | gmaxwell: | it's not safe to assume the memory is sram at all. |
20:29:42 | gmaxwell: | no need, you pipeline the memory. |
20:31:09 | tromp_: | yes, it would be rather overkill, seeing as you only access memory in 1KB blocks |
20:31:27 | tromp_: | sorry 128B blocks |
20:31:30 | vetch: | wonder if anybody has some broken grid seed units around to spare |
20:33:50 | vetch: | Armory apparently takes screenshots of you using it and uses that as an RNG. that's an odd one. |
20:38:21 | gmaxwell: | vetch: bitcoin-qt does that on windows too. |
20:39:59 | sipa: | we still do? |
20:40:09 | vetch: | nothing more reassuring than a commit named "Fixed problem with entropy generator" regardless. |
20:41:22 | gmaxwell: | sipa: yes. util.cpp like 125 or so. |
20:41:24 | gmaxwell: | er line. |
22:45:49 | [\\\]: | [\\\] is now known as imsaguy |
22:46:14 | imsaguy: | imsaguy is now known as [\\\] |
22:54:16 | maaku: | maaku is now known as Guest62012 |
23:51:53 | Guest62012: | Guest62012 is now known as maaku |