02:11:00jgarzik:jgarzik is now known as appleapple_jg
02:11:11jgarzik_:jgarzik_ is now known as jgarzik
02:39:53fanquake_:fanquake_ is now known as fanquake
05:53:50dgenr8:[01/17 15:58:44] this is what allows a single point in the system to do a global measurement
05:53:53dgenr8:nsh: a single point in the system calcs a number that is exceedingly unlikely to be greater than the hashrate, and could easily be less, if somebody wanted to toy with you. does it still seem sublime put that way?
06:17:00nsh:sublime is as sublime does, and the shortfall hasn't sublimated the system yet, so i guess it's nothing tragic
06:18:48nsh:but yeah, it's contingent on there not being dark cycles, which was not even a consideration before the economic incentive of bitcoin made the fabrication of the necessary hardware an economic possibility
06:19:34nsh:i don't know if this entwining of the material and the theoretical demeans the latter, it just complicates the task thereafter
06:20:36nsh:satoshi might have bet wrong, and someone could have had the means to grow the global sha256(sha256()) of the universe in a briefer blink than a block
06:20:38nsh:seems he didn't
06:21:30nsh:sometimes like that happens in history, i'm happy to run with it and not check too closely the loops of its shoelaces
06:38:23bramc:doing sha256(sha256()) is generally considered redundant. It's a throwback from doing sha1(sha1()) which is sometimes done because of weaknesses in sha1 which don't apply to sha256
06:40:11phantomcircuit:bramc, it prevents extension attacks which is potentially useful but mostly not
06:40:55phantomcircuit:i assume that's what you're talking about?
06:42:20phantomcircuit:bramc, sha256 is vulnerable to such an attack
08:11:16fanquake_:fanquake_ is now known as fanquake
09:05:13verne.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
09:05:13verne.freenode.net:Users on #bitcoin-wizards: andy-logbot RoboTeddy benten Burrito damethos booly-yam-4795 bramc fanquake MoALTz_ grubles ryanxcharles TheSeven moa coiner sdkfew Adlai Emcy d1ggy__ Dr-G2 jgarzik appleapple_jg nuke1989 Dizzle Guest15720 _Plebington_ GAit atgreen iyoki Cory wallet42 shesek @ChanServ BananaLotus Xzibit17 justanotheruser Alanius artifexd_ kumavis jbenet luny hktud0 epscy imposter HaltingState koshii_ Shiftos grandmaster mkarrer hashtag hashtagg_ Transisto huseby
09:05:13verne.freenode.net:Users on #bitcoin-wizards: qwopqwop starsoccer null_radix Graftec Guest62486 dgenr8 ebfull mappum devrandom Oizopower PRab waxwing bsm117532 zwischenzug nsh coblee DougieBot5000 ryan-c c0rw1n catcow ajweiss DoctorBTC gavinandresen wizkid057 stonecoldpat davout hollandais warren bosma forrestv otoburb ahmed_ PaulCapestany phantomcircuit mortale gribble copumpkin [d__d] lechuga_ nanotube so Apocalyptic michagogo btc___ Muis CryptOprah HM2 bbrittain Hunger- phedny Iriez
09:05:14verne.freenode.net:Users on #bitcoin-wizards: comboy_ MRL-Relay cluckj optimator_ earlz cryptowest weex wiz coryfields_ harrow` tripleslash brad___ thrasher` Graet helo throughnothing nickler_ Adrian_G fenn yrashk sl01 mr_burdell JonTitor roasbeef Keefe espes__ Logicwax petertodd dansmith_btc lclc poggy heath kanzure fluffypony xabbix_ catlasshrugged pigeons Krellan Luke-Jr dasource Guest74833 Eliel_ morcos kinlo andytoshi gwillen gnusha burcin spinza Nightwolf a5m0 Fistful_of_Coins Meeh
09:05:14verne.freenode.net:Users on #bitcoin-wizards: s1w jcorgan Anduck btcdrak sneak wumpus BrainOverfl0w hguux_ yoleaux BigBitz iddo delll midnightmagic lnovy sdaftuar tromp_ SubCreative coryfields deego pi07r_ warptangent TD-Linux NikolaiToryzin bepo_ samson_ nick1234abcd__ d9b4bef9 jaromil Starduster_ EasyAt berndj crescend1 jaekwon_ Taek azariah eric gmaxwell BlueMatt tacotime go1111111 livegnik isis asoltys_ LarsLarsen brand0 amiller tromp Dyaheon _v3Rve K1773R
11:15:00nsh:does leslie lamport ever chime in on any or any things bitcoin/blockchain?
12:59:56Shiftos_:Shiftos_ is now known as Shiftos
13:48:13fanquake_:fanquake_ is now known as fanquake
15:36:24Guest15720:Guest15720 is now known as maaku
19:39:37contrapumpkin:contrapumpkin is now known as copumpkin
20:20:05fanquake_:fanquake_ is now known as fanquake
21:41:44op_mul:op_mul is now known as sponges
21:43:56sponges:sponges is now known as op_mul
21:44:43coryfields:coryfields is now known as cfields
21:45:20maaku:maaku is now known as Guest89043
21:49:26cfields:cfields is now known as cfields_
21:50:41cfields_:cfields_ is now known as cfields
21:57:50andytoshi:nsh: i've never heard him do so, no
21:58:46andytoshi:kanzure: the most meaningful way to measure hashpower is in gigahashes (or some scalar multiple of this, like megahashes or flops) ... converting to energy is an accident of the currently available hardware and might be useful for economic reasoning, but energy consumption does not let you directly derive things like hashrate (which is a "macrovariable" or statistical quantity, analogous to
22:00:46andytoshi:amiller: re output value hiding, adam3us has a proposal on how to do this somewhat efficiently, but it does not result in smaller transactions (since you need to provide a proof that outputs ≤ inputs)
22:01:45andytoshi:amiller: i don't think it's compatible with cryptonote signatures...it is definitely not compatible with the form of output value hiding that gmaxwell and myself proposed in https://download.wpsoftware.net/bitcoin/wizardry/ringsig-blinding.txt
22:03:28phantomcircuit:jgarzik, a thought on ASN.1, the encoding format itself is actually decent, however common implementations are insane
22:04:24kanzure:andytoshi: actually i wasn't that interested in measuring hashpower, but only the dimensional units of the "work" that the hashpower makes proofs of
22:04:26andytoshi:amiller: here is adam3us's proposal https://bitcointalk.org/index.php?topic=305791.0 i do not remember the details of what it requires from the signature scheme
22:04:50andytoshi:kanzure: computations
22:04:59kanzure:you guys are bad at dimensions :P
22:05:15amiller:andytoshi, that system seems like it involves decomposition into bits
22:05:29andytoshi:kanzure: well a computation is a real physical thing, but we're into quantum physics that i don't understand now..
22:05:30kanzure:in other areas of physics, work is measured in joules
22:05:39kanzure:obviously, joules is not appropriate here
22:05:59kanzure:(although the definition might incorporate joules somewhere.....)
22:07:41andytoshi:kanzure: the problem is that you can make little changes to your model of computation that introduce constants or even O(time) factors, this is why computational complexity doesn't get more specific than "polynomial" and "nonpolynomial" unless it really needs to
22:08:07andytoshi:kanzure: if you want to be precise, i'd say "RAM machine ticks"
22:10:35jgarzik:phantomcircuit, agree, and that's the rub
22:10:48jgarzik:phantomcircuit, protobufs had a much better ecosystem for developers
22:11:04phantomcircuit:that's reasonable
22:11:06jgarzik:phantomcircuit, easier to pick your favorite language, and get going more rapidly
22:11:16jgarzik:thus anyone can easily support BIP70 w/ existing code
22:11:19jgarzik:not so w/ ASN
22:11:26phantomcircuit:especially since openssl still doesn't correctly implement DER...
22:11:31jgarzik:lol, yep
22:11:44Pan0ram1x:Pan0ram1x is now known as Guest90099
22:11:47phantomcircuit:i like how their patch doesn't actually fix the underlying issue
22:12:00Alanius:I think in the end it does boil down to Joules; it's just that current mining technology is horribly inefficient and produces a lot of heat in the way, making energy a very unmeaningful measurement. But there is a thermodynamic limit to computation so in the end there is some conversion rate between "computations" and "joules".
22:12:16phantomcircuit:i wonder if there's anybody left that understands the macro ASN.1 stuff well enough to fix it
22:12:40phantomcircuit:Alanius, current miners are INSANELY efficient...
22:12:57phantomcircuit:where in the world would you get the opposite impression from
22:12:59Alanius:well ... compared to what?
22:14:38Alanius:miners today use far less energy to produce one hash than say a year ago; but I posit that they are still using orders of magnitude more energy than what is thermodynamically necessary to produce one hash
22:17:28kanzure:hah, quite right yeah there's definitely an upper limit you can estimate like that
22:18:11phantomcircuit:Alanius, the current systems are within 1 order of magnitude of what is possible on the best currently available process node
22:18:36phantomcircuit:getting to the limit would require clockless designs that are very very expensive to get right and which i cant seriously see anybody doing
22:19:43phantomcircuit:so basically you should expect to see improvements roughly following improvements in the broader semiconductor industry
22:21:11kanzure:"ivan sutherland and i think some berkeley folks are doing clockless designs with reasonable success"
22:21:17kanzure:" http://arc.cecs.pdx.edu/ though they're bad at putting papers here"
22:22:14phantomcircuit:kanzure, it's my understanding that clockless design becomes much more difficult on <90nm process nodes
22:22:21phantomcircuit:something about wire delay becoming unpredictable
22:23:56rusty:phantomcircuit: BTW, thanks for mentioning the length extension attack yesterday; now I finally learned the reason for double sha...
22:24:36bramc:phantomcircuit, His point was that there is in fact a fundamental physics limit on how little energy you can use to do computation. We're nowhere close to that right now.
22:24:37phantomcircuit:rusty, it's obscure but apparently H(k|m) isn't an entirely uncommon MAC scheme
22:24:59op_mul:rusty: if it wasn't double SHA, miners really wouldn't be doing much at all
22:25:23phantomcircuit:bramc, yeah i noticed that now... but really we'll never be so what's the point?
22:25:39bramc:phantomcircuit, It would be interesting to know what the fundamental limit is
22:26:22kanzure:well, it's bounded by some normal computational limits (see "physics of computational superobjects")
22:26:31phantomcircuit:bramc, is it really though?
22:26:40andytoshi:bramc: if you can estimate the number of irreversible operations (i.e. bitflips) required for sha256d you can compute it from landauer's limit https://en.wikipedia.org/wiki/Landauer's_principle
22:26:43rusty:op_mul: ? Less than half the work?
22:26:51phantomcircuit:i guess it would be kind of neat to know how close to the absolute limits we are
22:27:05bramc:phantomcircuit, Yes at its core usable energy is information theory, and you have to use up information to reset your memory
22:27:38andytoshi:fwiw there are irreversible hash functions (e.g. sha256d where you just leave all the "waste bits" in the output) in which case the minimum J/hash is zero, but can only be obtained at 0 hash/sec
22:29:16kanzure:cc andytoshi
22:29:30kanzure:there's probably a more succinct paper i could cite for this but who cares, it's a fun paper
22:29:51kanzure:see page 5 section 3.3 i guess
22:30:04op_mul:rusty: well. look at the how miners currently work. they hash up until the nonce, and then cache that for the next 2^32-1 rounds.
22:30:40op_mul:rusty: they then do just the first round on the result of the first hash, and get a pass/fail based on that
22:30:52phantomcircuit:op_mul, that would make building a near optimal asic pretty trivial actually
22:31:04phantomcircuit:you could do the layout by hand without going insane
22:31:24op_mul:phantomcircuit: autorouter <3
22:31:50phantomcircuit:apparently most of the auto layout stuff is pretty lame
22:31:56op_mul:grinds for an hour and makes a board that's 99% vias
22:32:38rusty:op_mul: ah yeah, it *would* be pretty trivial with the internal SHA state cached, good point :)
22:32:40op_mul:yeah. *never* use the autorouter. not even for "quick" things.
22:33:32bramc:Apparently we're only six orders of magnitude or so off theoretical limits.
22:34:05bramc:So we're likely to smash right into physical limits in 30 years or so
22:34:10phantomcircuit:op_mul, RTL -> phsyical layout stuff is apparently largely supppper suboptimal
22:34:49phantomcircuit:i suspect that they're full of assumptions from larger process nodes that are no longer valid
22:35:12phantomcircuit:and nobody wants to mess with them since that could lead to a failed $5m+ tapeout
22:35:24kanzure:bramc: that's okay we'll just move the computation into a black hole
22:36:03op_mul:probably. main trouble with all PCB autorouters is that they don't do optional stuff very well. if I have a chip with 4 different grounds I could use, I can come up with better solutions than if I have to tell the autorouter "yeah, that one".
22:36:19bramc:When is moore's law supposed to run out of juice? It seems clock speeds have already stopped going up
22:36:25op_mul:they won't do clever stuff at all. if it's stuck, it'll spray vias everywhere.
22:36:38kanzure:( black hole computation: https://www.cs.auckland.ac.nz/research/groups/CDMTCS/researchreports/327cris.pdf#page=211 )
22:36:54kanzure:(page 136)
22:37:11Alanius:kanzure: where are you getting these links from? I can't read fast enough :/
22:37:50kanzure:Alanius: my collection http://diyhpl.us/~bryan/papers2/bitcoin/ http://diyhpl.us/~bryan/papers2/microfluidics/ http://diyhpl.us/~bryan/papers2/security/ http://diyhpl.us/~bryan/papers2/bio/ http://diyhpl.us/~bryan/papers2/neuro/
22:37:56kanzure:Alanius: READ FASTER
22:37:57phantomcircuit:bramc, transistor density is going up roughly following moore's law, but the power improvements are not
22:38:30phantomcircuit:bramc, for example 28nm -> 20nm is a 50% die shrink but only results in a 30% power improvement
22:38:39phantomcircuit:(20^2)/(28^2) ~= 51%
22:38:51kanzure:oh also these are favorites (although off topic) http://diyhpl.us/~bryan/papers2/DNA/ http://diyhpl.us/~bryan/papers2/polymerase/
22:40:41kanzure:haha andytoshi actually beat me to the gun (landauer's principle direct link rather than my indirection through an obscure paper)
22:49:36andytoshi:kanzure: you mean i don't have to read the obscure paper?
22:50:00kanzure:you don't have to, but it aligns with some of your other interests
22:50:37andytoshi:hmm, i'll make some tea and give it a shot
22:50:46bramc:Seems like nobody's prognosticating the end of Moore's law at this point, at least until around 10nm or so, which is in another three or four years, and there are likely to be tricks for getting below that. Carbon nanotubes can make wires which are around 1nm, so that's probably around the limit, which will be in another 12 years or so
22:51:22bramc:So basically Moore's Law is likely to run out of steam in roughly 2030, at which point the game will be in heat dissipation and energy consumption reductions
22:51:22andytoshi:i thought we were already having serious problems with electron leakage
22:51:32andytoshi:but what do i know (nothing)
22:51:44bramc:andytoshi, We are, but people are figuring out ways to handle them
22:52:11andytoshi:ok, sounds good then :)
22:52:26kanzure:bramc: here are some predictions about moore's law https://github.com/kanzure/uncertainfuture/blob/abe41c24a46c689ec0045a04ccb8a4607131b004/web/ufHelp/Q2.html
22:52:51kanzure:sorry for the format, it was for this thing: http://diyhpl.us/~bryan/irc/theuncertainfuture/
22:53:57kanzure:looks like this when rendered http://theuncertainfuture.com/ufHelp/Q2.html
22:54:43bramc:The prediction of 2030 seems to not have moved much over time
22:55:08kanzure:i suspect not many people are regularly being rigorous about updating that number though
22:55:55bramc:The hard limit of 1nm hasn't changed much, and the doubling-every-18-months has been remarkably consistent
22:56:15kanzure:that might be because of industry alignment on roadmaps etc
22:56:31op_mul:problem with all this new stuff is that I can't even use any of today's stuff, let alone tomorrows :(
22:56:48op_mul:here's this new package, it's in QFN and BGA! .. great thanks.
22:56:54bramc:Could be, but there never in history has been such rapid development of any technology ever for a decade, much less 80 years
22:57:50bramc:And there's likely to be a decade or three of reductions in power consumption and improvements in heat dissippation at the end
22:58:26bramc:So the party ends around 2050 or so, and that's around the end of my shift.
22:59:06op_mul:* op_mul kicks around some BGA ICs
22:59:15op_mul:hope 2030 brings easier to solder crap.
22:59:23kanzure:maybe meredith will be kind enough to preserve your brain tissue as well
22:59:49op_mul:core i7 in DIP. that's what we really need.
22:59:51kanzure:wait, that's okay to say, right? sorry, i mean good things by it
23:00:15bramc:kanzure, Maybe by then meredith will have gotten the autopsy report for the already preserved brain tissue :-P
23:00:50op_mul:DIP1366 for the i7. maybe that's not plausible.
23:04:36bramc:Bit of an argument going on on twitter at the moment. Collaborative signatures have space and unlinking advantages, but multisig allows for internal auditing. Of course both should be an option.
23:08:18op_mul:if you're thinking about privacy in bitcoin. just totally forget about it.
23:08:22op_mul:there's is *zero*.
23:08:40bramc:op_mul, bitcoin privacy works better than one would expect
23:08:53bramc:Kind of like how DHTs actually seem to work
23:09:44phantomcircuit:bramc, there is a reasonable amount of privacy against an unsophisticated attacker who is unable to subpoena records
23:10:04phantomcircuit:there is effectively none (currently) against sophisticated attackers who have the ability to subpoena records
23:10:10op_mul:bramc: you're arguing with somebody who has a significant portion of wallets segmented and identified.
23:10:15bramc:As a matter of practice I don't think any major players have had their identities unveiled by research involving the blockchain
23:10:29bramc:At least, that's what I was told about a year ago
23:11:24op_mul:come on. I can even identify the software people are using to sign transactions with some clarity.
23:12:12bramc:op_mul, I'll want to hear more about that from you later, when my kid isn't pestering me to play a game with him
23:12:20kanzure:yes but you're like the only one paying attention, op_mul
23:13:40op_mul:even if privacy services work *today* them being broken in the future would be a problem.
23:15:12rusty:op_mul: I think most people are going for obscurity, rather than real privacy at the moment. But I'm sure you could make a nice living tracking bitcoins for divorce lawyers :)
23:16:43op_mul:rusty: usually there's not even that.
23:17:46op_mul:bramc: it just comes down to people having made no effort to make sure their software makes the same transaction types as everybody else.
23:18:26rusty:op_mul: you need some known transaction to start with, right?
23:19:46op_mul:rusty: I can cluster without any known trandactions, and then tack an identity on later. most people leak in bitcointalk posts, or on reddit. if there's no connections you can force them by forcing them to merge outputs.
23:20:42rusty:op_mul: I hope that most bitcoin users don't actually post on bitcointalk or reddit, otherwise our userbase is much smaller than I thought...
23:21:30op_mul:some of it can't be automated, there's comments that you can manually process to find via a fuzzy reference. "I traded for $184 BTC yesterday" can actually be a unique transaction result if you are willing for some margin of error.
23:21:43rusty:op_mul: for example, you can't tell me how many satoshi my wife holds. Even though my 1RustyR vanity address is transparent...
23:22:15op_mul:users are also terrible at censoring. they'll often black out amounts and not TXID, or TXID and not amounts, or show one or two letters of an address.
23:23:07op_mul:rusty: you're a localbitcoins user :)
23:23:18rusty:op_mul: nice work :)
23:24:29op_mul:what did you buy from bitpay on september the 24th 2013?
23:24:56op_mul:0.28 BTC.
23:25:05rusty:op_mul: best way to meet other bitcoin users in Adelaide, FWIW. And AFAICT, no silk road users....
23:25:20op_mul:I don't want to know. the point is. this shit is painfully easy.
23:25:39op_mul:there is *zero* privacy.
23:28:04op_mul:any privacy that exists is just because nobody is interested in funding people to break it.
23:30:38rusty:op_mul: hmm, maybe that tx was humble bundle? I guess my vanity address reuse does weaken others' privacy.
23:30:42kanzure:eh, you talk a big talk, but merged outputs is easy and gives you the game. you should focus on known-bad prngs and user agent strings from logs.
23:32:07rusty:op_mul: Then what do you suggest we do for anonymity? Would homogonizing different programs' txs help much?
23:32:27op_mul:kanzure: I don't want to steal from people, and user agents have nothing to do with it.
23:32:44kanzure:rusty: carefully keep track of the number of identifying bits you are leaking, set a threshold that you are comfortable with leaking, and never go beyond it
23:32:55kanzure:op_mul: user agent strings often tell you which bad prng they were using at the time
23:33:24op_mul:kanzure: again, I don't want to steal from anybody.
23:33:32kanzure:you don't have to steal from them
23:33:44rusty:kanzure: I was referring to "we" here as the bitcoin community as a whole, not "me". If I cared, I wouldn't use a vanity address...
23:33:59op_mul:kanzure: that's obviously not acceptable behaviour.
23:34:08kanzure:not stealing from them is unacceptable?
23:34:25op_mul:rusty: anonymity is just not something Bitcoin can do.
23:35:34tacotime:yup. if you want anonymity, ideally don't transact on the blockchain. i hear cash is good.
23:36:27op_mul:imagine I have an address cluster
23:36:42kanzure:i don't have to imagine that, we all know you do :P
23:36:47op_mul:well, just looking at the times of the transactions within it I can work out roughly where that person lives
23:37:22tacotime:and even enhanced privacy chains like monero are still vulnerable to temporal snooping issues.
23:37:29kanzure:i like to refer to http://www.gwern.net/Death%20Note%20Anonymity
23:37:31op_mul:which is super neat, it means that given some other fuzzy sources you can do some additional weeding.
23:37:47kanzure:unfortunately there's no particularly better overview of "leaky bits are what detectives use"
23:44:18rusty:op_mul: timezone information would be an example of a leak which becomes less useful if bitcoin usage increases; it's the ones which scale which worry me more.
23:47:20op_mul:well it's all useful as part of fuzzy matches
23:47:35op_mul:if I have a proof address = person then they are taken out of the matching set
23:48:15op_mul:if I have something like, a $100 USD payment on a particular date, then you need to be doing gritty stuff like timezone working out and stuff like that. I haven't even coded that up yet because I see so little value in it.
23:50:26op_mul:* op_mul shrugs
23:51:21op_mul:at any rate. my point is just that if someone with no funding and little motivation can do it, the people who actually have funding will be able to do it a hell of a lot better.
23:51:28rusty:op_mul: sure, if you know the amount you might be able to determine what they bought (and thus who from, even if via bitpay), but that too gets harder with scale.
23:51:41rusty:op_mul: and my point is that we should be whacking these moles in order.
23:53:10op_mul:some are doable. some are not.
23:54:01rusty:op_mul: sure, timezone and amount are hard. But making standard transactions indistinguishable shouldn't be.
23:54:22op_mul:given the number of transactions and wallets which don't use compressed keys (no computational cost, lower fees, smaller transactions), it doesn't make me that hoepful other things will change for the better.
23:55:49op_mul:blockchain.info just only a few weeks ago made the one line change they needed to start using compressed point pubkeys.
23:56:29rusty:op_mul: they'll make an effort once it becomes a well-known issue, I think. Like any security :)
23:57:42op_mul:they still haven't removed their broken RC4 based RNG, so I won't hold my breath.
23:58:03rusty:op_mul: yeah, I was surprised how long it took Armory to support compressed keys... hmm, maybe it still doesn't.
23:58:16op_mul:it doesn't.