00:09:45justanotheruser:dsnrk: optomizing profits?
00:10:21dsnrk:maybe. seems oddly timed though. they've had terrible orphan rates for ages, why alter their setup now?
00:11:55dsnrk:I quited liked the description of their setup though. bit banging SPI because cgminer is too slow :)
00:23:20maaku:maaku is now known as Guest50777
00:23:57Guest50777:Guest50777 is now known as maaku
00:36:21justanotheruser:dsnrk: seems weird to set a specific number rather than a specific fee/kb though.
00:41:57dsnrk:sipa: the bitfury chips talk over SPI, controlled by a raspberry pi. the Pi is too slow, so they just proxy everything to their pool, including invalid nonces.
00:42:25dsnrk:justanotheruser: I think that's the default block size, they've just ditched their old bitcoin.conf for some reason.
00:43:13dsnrk:for what it's worth, given an output of a bc.i Shared Coin transaction a user on reddit was able to unmask the original address with no other given information. no computation, just a block explorer.
00:45:18maaku:dsnrk: unambigously?
00:45:49dsnrk:yep, the top one in the list is my blockchain.info wallet.
00:45:51maaku:I can random-click on bc.i and have X% chance of ending up on the original input
00:46:13dsnrk:the second in the list is where I split it into two coinjoins, then they follow the whole join
00:46:45maaku:so what's the issue? there's actually no common-size outputs?
00:46:55maaku:or they feed back to same sized outputs?
00:47:01maaku:*differently sized
00:48:14dsnrk:there's heaps of issues, that's one of them. another is that all the other outputs are bc.i's, you end up with a chain of spent outputs and all of the fake filler ones are unspent.
00:51:17dsnrk:in the case of one of the examples there was only a single match between the sizes of the outputs at the start and finish of the transaction chain, so it was painfully obvious what was going on.
01:23:22Adohgg:Adohgg is now known as NOT_DEA
01:23:49NOT_DEA:NOT_DEA is now known as Adohgg
02:12:10phantomcircuit:dsnrk, the rpi is only too slow because they're driving 450+ chips per RPI by bit banging an spi bus
02:12:31phantomcircuit:those suckers will shoot out total fucking nonsense shares for hours
02:14:54dsnrk:phantomcircuit: surely they'd have been better off with something else controlling the chains rather than dumping it on their pool
02:17:21phantomcircuit:dsnrk, yes and no
02:17:54phantomcircuit:dumping it on the pool makes gathering some statistics easier
02:18:02phantomcircuit:it also however makes it much much more expensive
02:18:45phantomcircuit:i actually had to write about 500 lines of python to consolidate error counters at the edge of the pool to prevent their hw from ddos'ing the network
02:19:52dsnrk:I think if I was going to be doing it, I'd have low cost micros/fpga controlling the chains, and them talking to local work servers. it would sort of take the central failure thing out of it, meaning each cluster could be tweaked as needed. stats would be collected somewhere else. not that I'm planning on doing anything of the sort, but is there any issue with that approach you can see?
02:20:57phantomcircuit:dsnrk, the only issue is that you lose a certain amount of the raw data on invalid shares
02:21:11phantomcircuit:but basically that never gets analyzed anyways
02:23:02dsnrk:phantomcircuit: would mean that you wouldn't have central servers being bombed with data though
02:23:22phantomcircuit:bombed with data is a relative term
02:23:33phantomcircuit:on a lan it's trivial
02:23:49phantomcircuit:a completely failing machine with a loose spi cable will generate ~10mbps of invalid shares
02:24:15phantomcircuit:but mostly they dont do that and are either completely dead or just submitting stupidly stale shares
02:24:31phantomcircuit: [00:10:21] maybe. seems oddly timed though. they've had terrible orphan rates for ages, why alter their setup now?
02:24:34phantomcircuit:that isn't why their orphan rate is so bad
02:24:47phantomcircuit:their 6U units have a flush time that can exceed 2 minutes
02:25:22phantomcircuit:mostly it's about 15 seconds though
02:25:34phantomcircuit:but 15 seconds is like 2.5%
02:25:37dsnrk:mm, I was using that as an argument against them changing their setup for that reason
02:26:11phantomcircuit:my first guess would be that they moved hardware to a location that has totally different pool software and nobody noticed
02:26:19dsnrk:they're making smaller blocks now with the default cap, I took that as a sign they moved to a new bitcoind
02:26:47dsnrk:possibly, you'd think if that was the case there'd be a mix of old and new block sizes though
02:27:15phantomcircuit:only if there was still anything at the old location
02:27:33dsnrk:if they moved everything wouldn't the poolservers have gone too?
02:28:06dsnrk:their poolservers are funny by the way, they have "us" and "uk" options but they're in the us/canada
02:28:41phantomcircuit:dsnrk, i doubt it
02:28:53dsnrk:doubt which comment?
02:29:07phantomcircuit:shoe strings, bubblegum, and lead free solder for those guys
02:29:42phantomcircuit:dsnrk, they have more than 2 pool servers for sure
02:29:47dsnrk:actually their uk pool name is returning a UK ip address now.
02:30:13dsnrk:phantomcircuit: well I assume the ones they expose aren't the ones they mine on internally
02:32:29phantomcircuit: if they moved everything wouldn't the poolservers have gone too?
02:32:31phantomcircuit:i doubt it
02:32:54phantomcircuit:dsnrk, the bay area is weird
02:32:58phantomcircuit:in a tunnel
02:32:59phantomcircuit:on a train
02:33:04phantomcircuit:still have LTE
02:34:16dsnrk:phantomcircuit: weird. sorry for badgering you with questions, I find the whole large-scale mining thing very interesting.
05:00:35BlueMatt:sipa/jgarzik: where do you want @bitcoin.ninja emails redirected to?
05:00:56BlueMatt:anyone else want one?
05:01:41BlueMatt:adam3us: you too
05:03:07BlueMatt:(Note that standard postfix logs are in place on the server located in the US, so to/from is logged, but that is it.)
05:07:40BlueMatt:everyone else who's asked for one, it should be working
05:18:11maaku:phantomcircuit: you're in the bay area?
05:19:00maaku:BlueMatt: thanks!
05:21:45Luke-Jr:BlueMatt: .
05:22:16Luke-Jr:BlueMatt: !
05:22:53Luke-Jr:BlueMatt: see other chat thing for mine
05:23:09BlueMatt:yours should be set up
05:23:28BlueMatt:(you should test it though, I'm prone to typos)
05:26:43Luke-Jr:BlueMatt: how hard would it be to setup other alias domains?
05:26:55BlueMatt:you mean a@x.bitcoin.ninja?
05:27:07Luke-Jr:like @bitcoin.rocks once I have that for example
05:27:15Luke-Jr:or @bitcoin.community
05:27:19BlueMatt:10 minutes, maybe
05:27:26BlueMatt:just like 2 conf files in postfix
05:27:36dsnrk:Luke-Jr: are you planning a forum? :3
05:27:44Luke-Jr:dsnrk: not really.
05:27:58dsnrk:what's .community for then? just because?
05:28:20maaku:but btw, DNS forwarding x.bitcoin.ninja would be cool too
05:28:25Luke-Jr:maybe if theymos's new BitcoinTalk doesn't prove to fix the troll problem, someone can setup a forum on it
05:28:35BlueMatt:maaku: if you want to run dns servers, I'll give you a ns record
05:28:45Luke-Jr:dsnrk: going for bitcoin.reviews and a bunch other too
05:28:57Luke-Jr:BlueMatt: I suggest just pointing it at HE DNS :P
05:29:10maaku:yeah. i mean i might not get around to setting it up for a few weeks, but i probably will do that
05:29:13dsnrk:Luke-Jr: bitcointalk doesn't need a new forum, it needs aggressive moderation. seriously that place is worse than 4chan's /b/, and that's saying something
05:29:20BlueMatt:Luke-Jr: heh, its already slaved there (as are all my domains), I just dont want to run other people's dns zones :p
05:29:55Luke-Jr:dsnrk: that's my position, but it's far enough down my todo list I don't especially care to try to do anything about it any time soon
05:31:36Luke-Jr:dsnrk: once upon a time, someone in #eligius tried to start abitcoin.org, but it seems to be dead
05:31:42dsnrk:Luke-Jr: fair enough. it's not something I would want to take on either.
05:32:13dsnrk:unfortunate. between reddit and bitcointalk there's nowhere to have decent conversatio.
05:32:24Luke-Jr:dsnrk: most of these I grabbed were just to avoid someone trying to ransom them
05:32:31Luke-Jr:dsnrk: IRC? :p
05:32:43Luke-Jr:oh. I put in for bitcoin.tools too. that one might be useful
05:32:43dsnrk:Luke-Jr: you're also up for competition with me on some of those TLD.
05:32:51dsnrk:me too.
05:32:56Luke-Jr:dsnrk: fine by me, as long as they go to someone involved :p
05:33:08Luke-Jr:at least my registrar has a full refund for ones I don't get
05:33:14dsnrk:I lost out on bitcoin.watch to someone squatting it
05:33:57dsnrk:would have made a nice status website or something
05:35:26Luke-Jr:someone's been spamming me trying to sell dashjr … .com for a few months now
05:35:38Luke-Jr:I can probably just buy it simply in a few more weeks now.
05:35:44Luke-Jr:but … not sure I care.
05:36:48dsnrk:a while back I jokingly suggested you buy bitcoin.католик without knowing what it meant. turns out it means "catholic". awesome coincidence.
05:37:19dsnrk:(who the hell thought unicode TLD was acceptable)
05:37:23Luke-Jr:not sure I care to spend $ on a useless TLD
05:37:36Luke-Jr:Unicode is fine, but nobody can type that outside Asia
05:38:02dsnrk:that's russian, but I get what you mean
05:38:29Luke-Jr:Russia counts as Asia, no?
05:38:48BlueMatt:not the inhabited parts :p
05:41:55dsnrk:well at any rate, nobody can type that stuff
05:42:33justanotheruser:католик is a tld?
05:42:40dsnrk:BlueMatt: just to point out, you'll run into heaps of issues with that domain. I gave up on having my email on a new top level because nobody had added it to their whitelists.
05:42:52dsnrk:justanotheruser: yeah, there's a pile of unicode ones now.
05:43:17justanotheruser:dsnrk: it seems like new tlds have been pumping out like crazy... or at least I assume so based on the emails namecheap sends me
05:43:31dsnrk:yep. there's hundreds and they're all stupid
05:43:57dsnrk:Luke-Jr: did you pitch for bitcoin.secure too?
05:44:07Luke-Jr:dsnrk: nope, didn't even see that one
05:44:25dsnrk:hm, might not be released yet. it will at some point
05:46:37Luke-Jr:BlueMatt: both work; does your server parse + or similar?
05:47:51BlueMatt:dsnrk: meh, I wasnt planning on using it for website registration or anything, just for business cards and the like
05:47:56sipa:BlueMatt: pieter.wuille@_gmail.com; thanks
05:48:04BlueMatt:Luke-Jr: dont think so, is there a flag in postfix to make it do that?
05:48:16Luke-Jr:BlueMatt: yes
05:49:20dsnrk:BlueMatt: just thought it needed to be said. had services refuse to send me emails and things like that.
05:49:48BlueMatt:sipa: pieter@ and sipa@ should work
05:50:54BlueMatt:Luke-Jr: hmm, seems to be set to + already, go try it and see if it works (I never use it, wouldnt know)
05:53:31Luke-Jr:BlueMatt: yep, seems to work
05:53:35BlueMatt:hmm, nice
06:02:40andytoshi:BlueMatt: can i have apoelstra@ and andytoshi@ going to apoelstra@wpsoftware.net
06:05:07BlueMatt:andytoshi: done
06:05:13andytoshi::D thx
07:20:22justanotheruser:justanotheruser is now known as yandere
07:26:56yandere:yandere is now known as justanotheruser
08:50:18Guest24131:Guest24131 is now known as Pan0ram1x
09:04:53qwertyoruiop_:qwertyoruiop_ is now known as qwertyoruiop
10:20:37alferzz:alferzz is now known as alferz
11:00:37jgarzik:BlueMatt, jgarzik@pobox.com
11:17:17Quanttek_:Quanttek_ is now known as Quanttek
11:23:52Pasha:Pasha is now known as Cory
12:29:22Quanttek_:Quanttek_ is now known as Quanttek
12:57:57Quanttek_:Quanttek_ is now known as Quanttek
13:06:32irc.freenode.net:Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 265 seconds))
13:07:47wilhelm.freenode.net:topic is: This channel is not about short-term Bitcoin development | "Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas. This channel is logged at http://download.wpsoftware.net/bitcoin/wizards/. For questions about the logs talk to andytoshi."
13:07:47wilhelm.freenode.net:Users on #bitcoin-wizards: andytoshi-logbot coke0 rdponticelli edulix mr_burdell Vitalik_ moneycat cryptoAI _ingsoc Quanttek spinza michagogo jtimon_ ZZyZX Krellan__ gloriusAgain vfor nanotube Logicwax kanzure Cory maaku_ tjopper2 OneFixt_ [_Tristan_] maraoz Guyver2 Burrito alferz wizkid057 arubi execut3 llllllllll roconnor__ cypherc AaronvanW_ postpre wallet42 Emcy at0mat lnovy px1NbxQzEC tromp_ espes TheSeven jchp pen ebfull quickcoin K1773R eristisk melvster
13:07:47wilhelm.freenode.net:Users on #bitcoin-wizards: dgenr8 danneu c0rw1n [Derek] Armstrong mkarrer bobke_ pajarillo gribble lechuga_ Apocalyptic heakins roasbeef LaptopZZ_ @ChanServ epscy Muis optimator otoburb mhanne lenticulis quackgyver Fistful_of_Coins Mikalv mmozeiko zibbo Dyaheon- Anduck crescendo ageis pigeons Eliel Krellan Kretchfoop lianj ryan-c dsnrk comboy weex Sangheili jcorgan keus petertodd davidlatapie DoctorBTC jaromil_ sl01 burcin nikitab emsid bitz helo LarsLarsen warren
13:07:47wilhelm.freenode.net:Users on #bitcoin-wizards: d34th [\\\] phantomcircuit coyo zenojis Alanius sipa amiller kinlo flammit Graet andytoshi dansmith_btc a5m0 wumpus asoltys so BlueMatt poggy rs0 HM Hunger- UukGoblin iddo tromp__ nkuttler copumpkin nickler tacotime_ harrow gavinandresen Luke-Jr forrestv midnightmagic gmaxwell realazthat altoz stqism justusranvier artifexd Adohgg stephenreed gavinandresen_ qwertyoruiop drawingthesun cajg jgarzik waxwing mortale justanotheruser EasyAt
13:07:47wilhelm.freenode.net:Users on #bitcoin-wizards: kiddouk Pan0ram1x adam3us ewust
14:42:01jgarzik_:gmaxwell, another next step: creating the "machine" definition such that the Moxie sandboxed CPU knows the magic memory addresses for pre-loaded content
14:42:26jgarzik_:though I suppose it could just start at code==0x00000, and reference any memory pre-loaded after that
14:44:07maaku_:maaku_ is now known as maaku
14:45:53hearn:how simple is moxie, exactly?
14:46:10hearn:i'm wondering how it compares to a jvm that's had the JITC switched off/disabled i.e. is a pure interpreter, with a heavily restricted class library
14:46:48maaku:hearn: are we talking for consensus code? that sitll sounds enourmously large
14:47:02hearn:this is for oracles
14:47:38hearn:well, is it? it's large compared to Script for sure, but moxie came up in the context of programs that could do useful computation like signature checking on external inputs
14:47:58hearn:the advantage of the JVM is lots of people, both blackhats and whitehats, spend a lot of time trying to poke holes in it
14:48:12hearn:whereas some other misc VM that nobody ever heard of has not had the same kind of attention
14:48:41hearn:if you tightly restrict the classes available (e.g. no threads), then what you've got is basically an interpreter for a relatively small/simple stack based bytecode interpreter
14:48:48hearn:sorry, bytecode language
14:49:00hearn:except you don't have to invent your own toolchains and IDEs and things
14:53:03jtimon_:I would implement a custom language using pypy for a script 2.0
14:53:38jtimon_:then you may want to compile higher level languages to the script lang
14:54:45maaku:ugh still way way too much complexity imho
14:54:53jtimon_:pypy seems relatively simple to use for writing interpreters
14:54:56maaku:we need something that fits in a single C file, under 1k lines
14:55:11jtimon_:pyp will produce that for you
14:55:34maaku:but pypy is a massive project
14:55:48jtimon_:you don't need to use all of it
14:55:56maaku:*a single C file with zero dependencies
14:56:21jtimon_:I would say most of the project is specific to the python pypy interpreter, I'm talking about using their tools
14:56:39jtimon_:yes, I think pypy can produce that
14:57:13jtimon_:reduced python can be compilable to C
14:57:23andytoshi:hearn: the actual moxie interpreter is less than 1000 lines of code
14:57:24maaku:I don't know. we can later talk about doing JIT compilation of script using pypy code, but I think the reference consensus code should be done first as a stand-alone interpreter
14:58:05maaku:jtimon_: do you mean write it in python, use pypy to compile to C?
14:58:26jtimon_:this would produce a standalone interpreter, it's more maintainable from the beginning, and won't give people excuses to reimplement it on their own
14:58:39hearn:andytoshi: yes, not including any kind of support code i imagine. presumably you have to provide your own libc, your own malloc, etc
14:58:55tromp__:i once wrote a standalone interpreter for a pure lazy functional language in 650 *bytes* of c-code...
14:58:59jtimon_:maaku from the link: "As you may have guessed, PyPy solves this problem. PyPy is a sophisticated toolchain for analyzing and translating your interpreter code to C code (or JVM or CLI)."
14:59:11andytoshi:hearn: yeah. if you go download it it's a several gig download because it includes a complete gcc distribution
14:59:32andytoshi:hearn: but the idea for consensus code was that we'd be hand-writing assembler
14:59:42andytoshi:(after adding some opcodes or mmio to do crypto)
14:59:58hearn:again, this came up in the context of oracles, that want complicated external state. entire web pages and things.
15:00:03maaku:tromp__: well you probably didn't have various crypto and serialization primitives, but yes tha's what i'm talking about ;)
15:00:03jtimon_:there's an example with a stupid language as well
15:00:10hearn:so (A) not core consensus and (B) relatively big programs that you don't want to hand write in assembly
15:00:27tromp__:it had no primitives whatsoever:(
15:00:30jtimon_:although I don't think you can write full python to write the interpreter, only reduced python
15:01:22jtimon_:hearn I would consider pypy for the oracles language as well
15:01:54hearn:i don't think the python stack is built with security against malicious code in mind at all
15:02:02jtimon_:although as you say there you have other constraints
15:02:31jtimon_:which python stack?
15:02:34petertodd:amiller: lol, my pay-to-publish scheme paypub is in wired already: http://www.wired.com/2014/06/paypub/
15:04:19jtimon_:cpython's pypy's jython's?
15:05:25jtimon_:there's also stackless python
15:13:12helo:don't forget twisted stackless writhing python
15:14:33maaku:but in all cases it's a valid point that it hasn't really been an attack surface and is probably not very secure against running random code
15:15:55jtimon_:do you mean you can't write a secure interpreter using pypy?
15:16:27jtimon_:I don't follow the reasoning
15:23:38hearn:jtimon_: all of them
15:24:29hearn:jtimon_: look at it this way. java _was_ designed to be secure against malicious code, as was javascript, and they all failed miserably. they've both collectively had many many man years invested in finding, exploiting and patching security holes, both have entire teams of people devoted just to security
15:24:31hearn:python has none of that
15:24:53hearn:i'd rate the chances of successfully sandboxing malicious python at just above zero
15:35:50jtimon_:I don't see how that necessarily mean that python's security is lower than javascript or java's
15:36:32jtimon_:A has x and it's insecure, B doesn't have x ergo must be even more insecure
15:37:29jtimon_:I don't think a language can be "secure" or "insecure" on its own anyway
15:37:56sipa:well, if it allows pointer arithmetic or system library calls, it's inevitable insecure
15:38:05helo:we're talking about executing untrusted code someone gives you, or writing networking software?
15:38:19jtimon_:you can build a secure server with python or java (with many more languages thanks to mongrel2) or an insecure one with all the languages as well
15:39:01sipa:i wouldn't use either python or java to be honest... neither have a decent way of controlling resource usage :)
15:40:50sipa:for oracles that probably matters less, but you're also talking about some consensus script proposal, no?
15:41:30maaku:jtimon_: the context of an oracle is that you are running random code provided by others on the internet
15:42:31maaku:e.g. "run this code and sign the result"
15:43:42jtimon_:so you can write the interpreter with pypy and the rest (receiving the messages signing them) with whatever you want
15:44:25maaku:i think you're missing the point. there are not many platforms in the world which are safe to run untrusted code
15:44:37maaku:i don't think anyone on the pypy team has even consdiered this security risk
15:44:37jtimon_:for example python with some framework, say flask, what's insecure there?
15:44:38helo:i like the simpler oracles that advertises the code they run (job they perform), and users just provide parameters (like escrow)
15:44:41maaku:it's outside their domain
15:44:51maaku:jtimon_: everything
15:45:10jtimon_:the security risk of what? the interpreter not doing what it's supposed to do?
15:45:11maaku:if you give me the ability to run random python code on your server, you're toast
15:45:15helo:python with flask is fine if you choose the code you execute
15:45:32helo:(can be fine, ofc)
15:45:38jtimon_:at what point I have given you the hability to run python code in my server?
15:45:49maaku:jtimon_: that is the context of this discussion
15:45:51helo:when you're using it in this context of arbitrary oracles
15:45:54maaku:the oracle runs user-provided programs
15:46:11sipa:i think we're having very different mental models of the problem
15:46:18sipa:jtimon_: in your mind, what does the oracle receive?
15:46:24jtimon_:you can only run oraclescript, which is run by an interpreter translated from reduced python to c and then compiled
15:46:47sipa:who runs the compiler?
15:46:51jtimon_:a message with some oraclescript code?
15:47:23maaku:so you are assuming it is impossible for any carefully constructed oraclescript to trigger a vulnerability on the server
15:47:35jtimon_:sipa whoever wants to run it? In this case the oracle, but if users want to run it at home to test scripts...
15:47:39maaku:and I'm saying that was never a design criteria of pypy, so we can't assume that
15:47:41sipa:of course
15:48:13sipa:how do you produce oraclescript?
15:48:19sipa:in a typical use case
15:48:36jtimon_:the interpreter doing strictly what you define in your language was a design criteria though
15:49:12sipa:so, being able to write scripts in a python-like language that gets compiled to a tiny VM bytecode is fine to me, and sounds very appealing
15:49:16maaku:yes, but you're trusting pypy to do that for you
15:49:22sipa:but the oracle executing it by first compiling it... no
15:50:24jtimon_:no, the interpreter is compiled, but the oracle doesn't compile the oraclescript it receives, he interprets it with the compiled interpreter
15:51:14sipa:then i misunderstood
15:51:37sipa:you're really just saying to write the oracle interpreter in python, and compile it to C to improve its performance?
15:52:01jtimon_:that's what pypy does
15:52:23jtimon_:as well as giving you other tools for memory management, etc
15:53:07sipa:so you're not at all talking about the toolchain for creating oracle bytecode
15:53:15sipa:only about the interpreter implementation?
15:54:18jtimon_:so maaku do you trust lex and yacc to do what they're supposeed to do?or not because "they weren't designed with security in mind"
15:54:44sipa:i think you were talking about totally different things
15:55:23sipa:but if you're just talking about the oracle interpreter implementation... i don't see much of a reason why that would be bad
15:55:33jtimon_:yep, I was talking about the interpreter although pyp could be probably also useful for the translation to bytecode processes
15:56:57jtimon_:PyPy project, [...] it's two things:
15:56:57jtimon_:A set of tools for implementing interpreters for interpreted languages
15:56:57jtimon_:An implementation of Python using this toolchain
15:58:43hearn:ultimately, the most important thing is to ensure the code is strongly sandboxed. ideally with multiple sandboxes (i.e. language/interp level, os level, etc)
15:58:53hearn:language choice would follow from that
15:58:57jtimon_:but I think the translation tools (the ones used to translate from Rpython to C) are designed generically so you could probably use some of that to build your high-level-lang-to-oracle-bytecode translator
15:59:08hearn:the weak point is usually the place where it interfaces with the outside world
15:59:31hearn:e.g. almost all java vulnerabilities are in the APIs, usually, vast and complex APIs that do things like movie decoding or 3D acceleration
15:59:59hearn:core VM vulnerabilities are much rarer, though do happen. the last one i recall was to do with multi-threaded access to the array copy intrinsic or something like that.
16:00:09hearn:you'd probably ban multithreading
16:00:14hearn:at least to start with
16:01:43jtimon_:* jtimon_ wonders if there's a java implementation using pypy alreaady...
16:02:00hearn:resource consumption can be limited somewhat effectively by telling the jvm how big the heap is allowed to be, and doing CPU throttling at the kernel level, i think. you can sandbox network access quite easily too, for bandwidth or website specific host control
16:02:18hearn:but ultimately it will always be risky to run programs written by a possibly malicious person ... there's no silver bullet
16:02:45jtimon_:so what you're considering is suing java directly as the oraclescript
16:03:01sipa:hell no
16:03:41jtimon_:it may sound stupid but I think it's simpler to implement your own oraclescript interpreter (ehem, specially using pypy)
16:05:14sipa:well, i wouldn't use python, but that's a different question :)
16:05:25hearn:jtimon_: there are about a million better things to do in the world than invent a new language
16:05:36hearn:so yes, i'd suggest that (a heavily restricted version of it)
16:05:55hearn:you realise that smartcards often run java as well, right? again, a very heavily restricted version of it (no new keyword!)
16:06:34hearn:anyway, the set of language runtimes that are actually battle-tested is very small. basically: java, flash, javascript ..... and that's about it.
16:07:15jtimon_:its design could mimic java, all I'm saying is that even if it sounds hard to believe, reimplement that reduced subset of java from scratch using pypy is probably simpler than getting java's code and starting to cut things out
16:07:26hearn:of those, javascript is pretty minimal, and would be a reasonable other choice, except then your language and runtime are very tightly bound together. there's no genericity at all. whereas there are lots of languages that can run on a simple interpreted jvm (not sure how many require fancy features of it though).
16:08:23hearn:anyway, work day is over. out into the sun!
16:09:14jtimon_:too much sun here, still time to hide from it
16:42:10maaku:jtimon_: what I'm saying is that you'd still have to fully audit the source code and everything it relies upon
16:42:36maaku:it'll probably be easier to just start with something that is already constrained (e.g. dependency-less C code) or audited (micro JVM)
16:43:45jtimon_:again, pypy produces dependency-less C code, the resulting interpreter is compiled from dependency-less C code
16:44:18jtimon_:RPython -> C -> binary
17:02:58BlueMatt:jgarzik: ok, you have jeff@ and jgarzik@
17:06:31jgarzik_:BlueMatt, word
18:11:32michagogo:BlueMatt: Ooh, can I have michagogo@bitcoin.ninja?
18:11:43michagogo:Maybe micha@ too?
18:12:38nshlol:* nshlol emotes disapproval towards sillyTLDs
18:16:02Luke-Jr:* Luke-Jr wonders who got bitcoin.expert
18:36:38maaku:jtimon: the issue is/was that a reorg would make an arbitrary historical transaction invalid
18:36:54maaku:e.g. I exchange asset for bitcoin, then send bitcoins as payment (separate tx)
18:39:36maaku:the person taking that btc is unknowning assuming risk that a reorg will make the exchange transaction (which had an expiry) invalid
18:47:56jtimon:well, I get it although there's nothing special with btc here, it could happen with any asset
18:48:48jtimon:and the "quieting period op"? how that's better
18:49:28maaku:queting period doesn't suffer the same problem because the period is presumably COINBASE_MATURITY blocks long
18:49:47maaku:you can't build off an output which is in a quieting period
18:50:27maaku:but it would seriously wreck things if we applied the same constraint to nExpiry bids and asks on an exchange
18:50:29jtimon:ok, I forgot how you were supposed to use them equivalently
18:51:39jtimon:even forgetting the point you just made
18:52:44jtimon:anyway in the example you made
18:54:06jtimon:how is a trade being trade being replaced by a spend in a reorg any worse than having a trade being replaced by another trade in a reorg?
18:56:12pigeons:is this regarding moving from a chain to a sidechain and back?
19:13:51jtimon:pigeons no, it is rewarding an expiry_op or a nExpiryTime field (the opposite of nLockTime) in general
19:14:20jtimon:we have them on freimarkets, but some people are hostile to the idea of expiries in transactions
19:15:20jtimon:so in the 2-way peg conversations an expiry was used for something but then it was replaced by the quieting period op
19:16:32jtimon:and we're talking about try to use it to replace the expiries on freimarkets too or decide that we really need them for open orders anyway and keep them
19:18:38jtimon:I should have written down my ideas on this, I was convinced that I could implement the option contracts with the op_maturity, but now I'm not so sure, and I don't think it can be used with the regular orders either
19:19:13jtimon:I think was gmaxwell who convinced me that I didn't need an expiry for anything
19:51:12BlueMatt:michagogo: redirected to where?
19:51:24maaku:jtimon: i think you can do the options contract with op_maturity, but that doesn't solve the open orders problem
19:51:42maaku:unless you require explicit double-spends to change an order, but that is both costly and slow
19:53:21michagogo:BlueMatt: see notice
19:54:04BlueMatt:michagogo: hmm? is it possible my bouncer ate it?
19:54:33michagogo:okay, see privmsg
20:33:01bobke_:bobke_ is now known as bobke
20:40:32otoburb:otoburb is now known as Guest28941
21:31:14justanotheruser:maaku: can you elaborate on preventing centralized miners from attacking by having those that bought the cloud mining having to sign the blocks?
22:00:31jonpry_:jonpry_ is now known as jonpry
22:40:03qwertyoruiop:qwertyoruiop is now known as Guest1337
22:40:14Guest1337:Guest1337 is now known as qwertyoruiop
23:03:06OneFixt_:OneFixt_ is now known as OneFixt
23:27:18Luke-Jr:justanotheruser: what needs elaboration?
23:28:25justanotheruser:Luke-Jr: how a miner proves that the hashpower used to find a block wasn't from another machine
23:29:53justanotheruser:I could rent out 51% of the hash power, but there is nothing locking the blocks those machines produce to someone signature
23:30:40Luke-Jr:justanotheruser: the chips would refuse to hash anything unsigned
23:31:18justanotheruser:Luke-Jr: If I'm purchasing cloud hashing services, how do I verify that their chips refuse to hash anything unsigned?
23:34:24Luke-Jr:justanotheruser: I think the current idea is that the chips would do some kind of remote attest to their control key
23:34:57justanotheruser:Luke-Jr: isn't that easy to forge?
23:35:08maaku:justanotheruser: you would have to get the control key from the vendor that supplied the hardware
23:35:15maaku:how do you forge a digital signature?
23:35:40justanotheruser:maaku: you don't
23:35:46maaku:vendor A sells asic to user B but ships it to data center C
23:35:57maaku:vendor A also mails a private key to user B
23:36:03justanotheruser:you modify the hardware (or have lying hardware to begin with)
23:36:26Luke-Jr:justanotheruser: people will obviously buy it without decentralisation
23:36:44Luke-Jr:justanotheruser: point is that once this is in place, it's good
23:36:57maaku:justanotheruser: this assumes that the asic supplier is trustworthy (or you check a few units at random to verify), and that the asic provider and cloud hashing setup are not the same
23:36:57Luke-Jr:trust is upfront only
23:36:59justanotheruser:Luke-Jr: "it's good"?
23:37:28Luke-Jr:you don't need to worry about some hostile entity breaking into the datacenter, social engineering them, etc
23:37:31maaku:justanotheruser: the idea is that modifying the miners is more expensive than it is worth
23:37:44justanotheruser:maaku: good point
23:37:56maaku:it breaks down if you lose that assumption
23:38:16maaku:btw highlighting gmaxwell because this is really his idea
23:40:17justanotheruser:hmm, so that would eliminate the risk of cloud hashing attackers somewhat. Is there any way to stop asic manufacturer centralization? Will that stop on it's own?
23:41:15Luke-Jr:justanotheruser: what's the problem?
23:42:14justanotheruser:Luke-Jr: the fact that people send a ton of money to asic manufacturers and the manufacturer could potentially have 30% of the hashrate on their control for a little bit
23:42:37Luke-Jr:that's basically solved IMO
23:42:56kanzure:you can fabricate your own asics
23:43:08kanzure:don't listen to the propaganda from the billion dollar fabs :p
23:43:29kanzure:they are just grumpy that they keep replacing their equipment every few years
23:44:17Luke-Jr:justanotheruser: solved because new chips won't be 30%
23:44:20justanotheruser:Luke-Jr: it is solved because there is so much competition?
23:44:52justanotheruser:I assume the new chips were only 30% because of how unoptomized ASICs were?
23:47:03Luke-Jr:also because the old chips were obsolete technology
23:47:21jtimon:justanotheruser the room for further optimizations only shrinks
23:48:23justanotheruser:Luke-Jr: and they will take much longer to become obsolete because of the shrinking rise in rise in difficulty?
23:48:46Luke-Jr:justanotheruser: because we're basically up-to-date on ASIC tech now
23:48:55Luke-Jr:ASIC tech doesn't shrink *that* fast
23:49:40Luke-Jr:Intel might be able to pull off 30% on a new gen of chips right now, but short of that..
23:50:10Luke-Jr:(by combining their skills and access to bleeding-edge ASIC tech)
23:51:46justanotheruser:hm, that's reassuring