| 00:09:45 | justanotheruser: | dsnrk: optomizing profits? |
| 00:10:21 | dsnrk: | maybe. seems oddly timed though. they've had terrible orphan rates for ages, why alter their setup now? |
| 00:11:55 | dsnrk: | I quited liked the description of their setup though. bit banging SPI because cgminer is too slow :) |
| 00:23:20 | maaku: | maaku is now known as Guest50777 |
| 00:23:57 | Guest50777: | Guest50777 is now known as maaku |
| 00:34:59 | sipa: | SPI? |
| 00:36:21 | justanotheruser: | dsnrk: seems weird to set a specific number rather than a specific fee/kb though. |
| 00:41:57 | dsnrk: | 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:25 | dsnrk: | justanotheruser: I think that's the default block size, they've just ditched their old bitcoin.conf for some reason. |
| 00:43:13 | dsnrk: | 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:44:51 | dsnrk: | http://redd.it/27rsv8 |
| 00:45:18 | maaku: | dsnrk: unambigously? |
| 00:45:49 | dsnrk: | yep, the top one in the list is my blockchain.info wallet. |
| 00:45:51 | maaku: | I can random-click on bc.i and have X% chance of ending up on the original input |
| 00:45:54 | maaku: | ok |
| 00:46:13 | dsnrk: | the second in the list is where I split it into two coinjoins, then they follow the whole join |
| 00:46:45 | maaku: | so what's the issue? there's actually no common-size outputs? |
| 00:46:55 | maaku: | or they feed back to same sized outputs? |
| 00:47:01 | maaku: | *differently sized |
| 00:48:14 | dsnrk: | 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:49:01 | maaku: | ah |
| 00:51:17 | dsnrk: | 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:22 | Adohgg: | Adohgg is now known as NOT_DEA |
| 01:23:49 | NOT_DEA: | NOT_DEA is now known as Adohgg |
| 02:12:10 | phantomcircuit: | dsnrk, the rpi is only too slow because they're driving 450+ chips per RPI by bit banging an spi bus |
| 02:12:31 | phantomcircuit: | those suckers will shoot out total fucking nonsense shares for hours |
| 02:14:54 | dsnrk: | phantomcircuit: surely they'd have been better off with something else controlling the chains rather than dumping it on their pool |
| 02:17:21 | phantomcircuit: | dsnrk, yes and no |
| 02:17:54 | phantomcircuit: | dumping it on the pool makes gathering some statistics easier |
| 02:18:02 | phantomcircuit: | it also however makes it much much more expensive |
| 02:18:45 | phantomcircuit: | 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:52 | dsnrk: | 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:57 | phantomcircuit: | dsnrk, the only issue is that you lose a certain amount of the raw data on invalid shares |
| 02:21:11 | phantomcircuit: | but basically that never gets analyzed anyways |
| 02:23:02 | dsnrk: | phantomcircuit: would mean that you wouldn't have central servers being bombed with data though |
| 02:23:16 | phantomcircuit: | well |
| 02:23:22 | phantomcircuit: | bombed with data is a relative term |
| 02:23:33 | phantomcircuit: | on a lan it's trivial |
| 02:23:49 | phantomcircuit: | a completely failing machine with a loose spi cable will generate ~10mbps of invalid shares |
| 02:24:13 | dsnrk: | eesh |
| 02:24:15 | phantomcircuit: | but mostly they dont do that and are either completely dead or just submitting stupidly stale shares |
| 02:24:21 | phantomcircuit: | also |
| 02:24:31 | phantomcircuit: | [00:10:21] maybe. seems oddly timed though. they've had terrible orphan rates for ages, why alter their setup now? |
| 02:24:34 | phantomcircuit: | that isn't why their orphan rate is so bad |
| 02:24:47 | phantomcircuit: | their 6U units have a flush time that can exceed 2 minutes |
| 02:25:22 | phantomcircuit: | mostly it's about 15 seconds though |
| 02:25:34 | phantomcircuit: | but 15 seconds is like 2.5% |
| 02:25:37 | dsnrk: | mm, I was using that as an argument against them changing their setup for that reason |
| 02:26:11 | phantomcircuit: | my first guess would be that they moved hardware to a location that has totally different pool software and nobody noticed |
| 02:26:19 | dsnrk: | they're making smaller blocks now with the default cap, I took that as a sign they moved to a new bitcoind |
| 02:26:47 | dsnrk: | possibly, you'd think if that was the case there'd be a mix of old and new block sizes though |
| 02:27:15 | phantomcircuit: | only if there was still anything at the old location |
| 02:27:33 | dsnrk: | if they moved everything wouldn't the poolservers have gone too? |
| 02:28:06 | dsnrk: | their poolservers are funny by the way, they have "us" and "uk" options but they're in the us/canada |
| 02:28:41 | phantomcircuit: | dsnrk, i doubt it |
| 02:28:53 | dsnrk: | doubt which comment? |
| 02:29:07 | phantomcircuit: | shoe strings, bubblegum, and lead free solder for those guys |
| 02:29:42 | phantomcircuit: | dsnrk, they have more than 2 pool servers for sure |
| 02:29:47 | dsnrk: | actually their uk pool name is returning a UK ip address now. |
| 02:30:13 | dsnrk: | phantomcircuit: well I assume the ones they expose aren't the ones they mine on internally |
| 02:32:29 | phantomcircuit: | if they moved everything wouldn't the poolservers have gone too? |
| 02:32:31 | phantomcircuit: | i doubt it |
| 02:32:54 | phantomcircuit: | dsnrk, the bay area is weird |
| 02:32:58 | phantomcircuit: | in a tunnel |
| 02:32:59 | phantomcircuit: | on a train |
| 02:33:04 | phantomcircuit: | still have LTE |
| 02:34:16 | dsnrk: | phantomcircuit: weird. sorry for badgering you with questions, I find the whole large-scale mining thing very interesting. |
| 05:00:35 | BlueMatt: | sipa/jgarzik: where do you want @bitcoin.ninja emails redirected to? |
| 05:00:56 | BlueMatt: | anyone else want one? |
| 05:01:41 | BlueMatt: | adam3us: you too |
| 05:03:07 | BlueMatt: | (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:40 | BlueMatt: | everyone else who's asked for one, it should be working |
| 05:18:11 | maaku: | phantomcircuit: you're in the bay area? |
| 05:19:00 | maaku: | BlueMatt: thanks! |
| 05:21:45 | Luke-Jr: | BlueMatt: . |
| 05:22:09 | BlueMatt: | E_NOPARSE |
| 05:22:16 | Luke-Jr: | BlueMatt: ! |
| 05:22:53 | Luke-Jr: | BlueMatt: see other chat thing for mine |
| 05:23:09 | BlueMatt: | yours should be set up |
| 05:23:28 | BlueMatt: | (you should test it though, I'm prone to typos) |
| 05:24:57 | Luke-Jr: | k |
| 05:25:00 | Luke-Jr: | thx |
| 05:26:43 | Luke-Jr: | BlueMatt: how hard would it be to setup other alias domains? |
| 05:26:55 | BlueMatt: | you mean a@x.bitcoin.ninja? |
| 05:26:59 | Luke-Jr: | no |
| 05:27:07 | Luke-Jr: | like @bitcoin.rocks once I have that for example |
| 05:27:15 | Luke-Jr: | or @bitcoin.community |
| 05:27:19 | BlueMatt: | 10 minutes, maybe |
| 05:27:26 | BlueMatt: | just like 2 conf files in postfix |
| 05:27:36 | dsnrk: | Luke-Jr: are you planning a forum? :3 |
| 05:27:44 | Luke-Jr: | dsnrk: not really. |
| 05:27:58 | dsnrk: | what's .community for then? just because? |
| 05:28:02 | Luke-Jr: | kinda. |
| 05:28:20 | maaku: | but btw, DNS forwarding x.bitcoin.ninja would be cool too |
| 05:28:25 | Luke-Jr: | maybe if theymos's new BitcoinTalk doesn't prove to fix the troll problem, someone can setup a forum on it |
| 05:28:35 | BlueMatt: | maaku: if you want to run dns servers, I'll give you a ns record |
| 05:28:45 | Luke-Jr: | dsnrk: going for bitcoin.reviews and a bunch other too |
| 05:28:57 | Luke-Jr: | BlueMatt: I suggest just pointing it at HE DNS :P |
| 05:29:10 | maaku: | yeah. i mean i might not get around to setting it up for a few weeks, but i probably will do that |
| 05:29:13 | dsnrk: | 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:20 | BlueMatt: | 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:55 | Luke-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:36 | Luke-Jr: | dsnrk: once upon a time, someone in #eligius tried to start abitcoin.org, but it seems to be dead |
| 05:31:42 | dsnrk: | Luke-Jr: fair enough. it's not something I would want to take on either. |
| 05:32:13 | dsnrk: | unfortunate. between reddit and bitcointalk there's nowhere to have decent conversatio. |
| 05:32:24 | Luke-Jr: | dsnrk: most of these I grabbed were just to avoid someone trying to ransom them |
| 05:32:31 | Luke-Jr: | dsnrk: IRC? :p |
| 05:32:43 | Luke-Jr: | oh. I put in for bitcoin.tools too. that one might be useful |
| 05:32:43 | dsnrk: | Luke-Jr: you're also up for competition with me on some of those TLD. |
| 05:32:51 | dsnrk: | me too. |
| 05:32:56 | Luke-Jr: | dsnrk: fine by me, as long as they go to someone involved :p |
| 05:33:08 | Luke-Jr: | at least my registrar has a full refund for ones I don't get |
| 05:33:14 | dsnrk: | I lost out on bitcoin.watch to someone squatting it |
| 05:33:40 | Luke-Jr: | >_< |
| 05:33:57 | dsnrk: | would have made a nice status website or something |
| 05:35:26 | Luke-Jr: | someone's been spamming me trying to sell dashjr … .com for a few months now |
| 05:35:38 | Luke-Jr: | I can probably just buy it simply in a few more weeks now. |
| 05:35:44 | Luke-Jr: | but … not sure I care. |
| 05:36:48 | dsnrk: | a while back I jokingly suggested you buy bitcoin.католик without knowing what it meant. turns out it means "catholic". awesome coincidence. |
| 05:37:19 | dsnrk: | (who the hell thought unicode TLD was acceptable) |
| 05:37:23 | Luke-Jr: | not sure I care to spend $ on a useless TLD |
| 05:37:36 | Luke-Jr: | Unicode is fine, but nobody can type that outside Asia |
| 05:38:02 | dsnrk: | that's russian, but I get what you mean |
| 05:38:29 | Luke-Jr: | Russia counts as Asia, no? |
| 05:38:48 | BlueMatt: | not the inhabited parts :p |
| 05:38:57 | Luke-Jr: | <.< |
| 05:41:55 | dsnrk: | well at any rate, nobody can type that stuff |
| 05:42:33 | justanotheruser: | католик is a tld? |
| 05:42:40 | dsnrk: | 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:52 | dsnrk: | justanotheruser: yeah, there's a pile of unicode ones now. |
| 05:43:17 | justanotheruser: | 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:31 | dsnrk: | yep. there's hundreds and they're all stupid |
| 05:43:57 | dsnrk: | Luke-Jr: did you pitch for bitcoin.secure too? |
| 05:44:07 | Luke-Jr: | dsnrk: nope, didn't even see that one |
| 05:44:25 | dsnrk: | hm, might not be released yet. it will at some point |
| 05:46:37 | Luke-Jr: | BlueMatt: both work; does your server parse + or similar? |
| 05:47:51 | BlueMatt: | dsnrk: meh, I wasnt planning on using it for website registration or anything, just for business cards and the like |
| 05:47:56 | sipa: | BlueMatt: pieter.wuille@_gmail.com; thanks |
| 05:48:04 | BlueMatt: | Luke-Jr: dont think so, is there a flag in postfix to make it do that? |
| 05:48:16 | Luke-Jr: | BlueMatt: yes |
| 05:48:39 | Luke-Jr: | recipient_delimiter |
| 05:49:09 | Luke-Jr: | IIRC |
| 05:49:20 | dsnrk: | BlueMatt: just thought it needed to be said. had services refuse to send me emails and things like that. |
| 05:49:48 | BlueMatt: | sipa: pieter@ and sipa@ should work |
| 05:50:54 | BlueMatt: | 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:31 | Luke-Jr: | BlueMatt: yep, seems to work |
| 05:53:35 | BlueMatt: | hmm, nice |
| 06:02:40 | andytoshi: | BlueMatt: can i have apoelstra@ and andytoshi@ going to apoelstra@wpsoftware.net |
| 06:02:41 | andytoshi: | ? |
| 06:05:07 | BlueMatt: | andytoshi: done |
| 06:05:13 | andytoshi: | :D thx |
| 07:20:22 | justanotheruser: | justanotheruser is now known as yandere |
| 07:26:56 | yandere: | yandere is now known as justanotheruser |
| 08:50:18 | Guest24131: | Guest24131 is now known as Pan0ram1x |
| 09:04:53 | qwertyoruiop_: | qwertyoruiop_ is now known as qwertyoruiop |
| 10:20:37 | alferzz: | alferzz is now known as alferz |
| 11:00:37 | jgarzik: | BlueMatt, jgarzik@pobox.com |
| 11:17:17 | Quanttek_: | Quanttek_ is now known as Quanttek |
| 11:23:52 | Pasha: | Pasha is now known as Cory |
| 12:29:22 | Quanttek_: | Quanttek_ is now known as Quanttek |
| 12:57:57 | Quanttek_: | Quanttek_ is now known as Quanttek |
| 13:06:32 | irc.freenode.net: | Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 265 seconds)) |
| 13:07:47 | wilhelm.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:47 | wilhelm.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:47 | wilhelm.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:47 | wilhelm.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:47 | wilhelm.freenode.net: | Users on #bitcoin-wizards: kiddouk Pan0ram1x adam3us ewust |
| 14:42:01 | jgarzik_: | 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:26 | jgarzik_: | though I suppose it could just start at code==0x00000, and reference any memory pre-loaded after that |
| 14:44:07 | maaku_: | maaku_ is now known as maaku |
| 14:45:53 | hearn: | how simple is moxie, exactly? |
| 14:46:10 | hearn: | 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:48 | maaku: | hearn: are we talking for consensus code? that sitll sounds enourmously large |
| 14:47:02 | hearn: | this is for oracles |
| 14:47:38 | hearn: | 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:58 | hearn: | 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:12 | hearn: | whereas some other misc VM that nobody ever heard of has not had the same kind of attention |
| 14:48:41 | hearn: | 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:48 | hearn: | sorry, bytecode language |
| 14:49:00 | hearn: | except you don't have to invent your own toolchains and IDEs and things |
| 14:53:03 | jtimon_: | I would implement a custom language using pypy for a script 2.0 |
| 14:53:38 | jtimon_: | then you may want to compile higher level languages to the script lang |
| 14:54:45 | maaku: | ugh still way way too much complexity imho |
| 14:54:53 | jtimon_: | pypy seems relatively simple to use for writing interpreters |
| 14:54:55 | jtimon_: | http://morepypy.blogspot.com.es/2011/04/tutorial-writing-interpreter-with-pypy.html |
| 14:54:56 | maaku: | we need something that fits in a single C file, under 1k lines |
| 14:55:11 | jtimon_: | pyp will produce that for you |
| 14:55:14 | jtimon_: | pypy |
| 14:55:34 | maaku: | but pypy is a massive project |
| 14:55:48 | jtimon_: | you don't need to use all of it |
| 14:55:56 | maaku: | *a single C file with zero dependencies |
| 14:56:21 | jtimon_: | I would say most of the project is specific to the python pypy interpreter, I'm talking about using their tools |
| 14:56:39 | jtimon_: | yes, I think pypy can produce that |
| 14:57:13 | jtimon_: | reduced python can be compilable to C |
| 14:57:23 | andytoshi: | hearn: the actual moxie interpreter is less than 1000 lines of code |
| 14:57:24 | maaku: | 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:05 | maaku: | jtimon_: do you mean write it in python, use pypy to compile to C? |
| 14:58:26 | jtimon_: | 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:39 | hearn: | 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:55 | tromp__: | i once wrote a standalone interpreter for a pure lazy functional language in 650 *bytes* of c-code... |
| 14:58:59 | jtimon_: | 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:11 | andytoshi: | hearn: yeah. if you go download it it's a several gig download because it includes a complete gcc distribution |
| 14:59:32 | andytoshi: | hearn: but the idea for consensus code was that we'd be hand-writing assembler |
| 14:59:42 | andytoshi: | (after adding some opcodes or mmio to do crypto) |
| 14:59:58 | hearn: | again, this came up in the context of oracles, that want complicated external state. entire web pages and things. |
| 15:00:03 | maaku: | tromp__: well you probably didn't have various crypto and serialization primitives, but yes tha's what i'm talking about ;) |
| 15:00:03 | jtimon_: | there's an example with a stupid language as well |
| 15:00:10 | hearn: | so (A) not core consensus and (B) relatively big programs that you don't want to hand write in assembly |
| 15:00:27 | tromp__: | it had no primitives whatsoever:( |
| 15:00:30 | jtimon_: | although I don't think you can write full python to write the interpreter, only reduced python |
| 15:01:22 | jtimon_: | hearn I would consider pypy for the oracles language as well |
| 15:01:54 | hearn: | i don't think the python stack is built with security against malicious code in mind at all |
| 15:02:02 | jtimon_: | although as you say there you have other constraints |
| 15:02:31 | jtimon_: | which python stack? |
| 15:02:34 | petertodd: | amiller: lol, my pay-to-publish scheme paypub is in wired already: http://www.wired.com/2014/06/paypub/ |
| 15:04:19 | jtimon_: | cpython's pypy's jython's? |
| 15:05:25 | jtimon_: | there's also stackless python |
| 15:13:12 | helo: | don't forget twisted stackless writhing python |
| 15:14:33 | maaku: | 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:55 | jtimon_: | do you mean you can't write a secure interpreter using pypy? |
| 15:16:27 | jtimon_: | I don't follow the reasoning |
| 15:23:38 | hearn: | jtimon_: all of them |
| 15:24:29 | hearn: | 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:31 | hearn: | python has none of that |
| 15:24:53 | hearn: | i'd rate the chances of successfully sandboxing malicious python at just above zero |
| 15:35:50 | jtimon_: | I don't see how that necessarily mean that python's security is lower than javascript or java's |
| 15:36:32 | jtimon_: | A has x and it's insecure, B doesn't have x ergo must be even more insecure |
| 15:37:29 | jtimon_: | I don't think a language can be "secure" or "insecure" on its own anyway |
| 15:37:56 | sipa: | well, if it allows pointer arithmetic or system library calls, it's inevitable insecure |
| 15:38:05 | helo: | we're talking about executing untrusted code someone gives you, or writing networking software? |
| 15:38:19 | jtimon_: | 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:01 | sipa: | i wouldn't use either python or java to be honest... neither have a decent way of controlling resource usage :) |
| 15:40:50 | sipa: | for oracles that probably matters less, but you're also talking about some consensus script proposal, no? |
| 15:41:30 | maaku: | jtimon_: the context of an oracle is that you are running random code provided by others on the internet |
| 15:42:31 | maaku: | e.g. "run this code and sign the result" |
| 15:43:42 | jtimon_: | so you can write the interpreter with pypy and the rest (receiving the messages signing them) with whatever you want |
| 15:44:25 | maaku: | i think you're missing the point. there are not many platforms in the world which are safe to run untrusted code |
| 15:44:37 | maaku: | i don't think anyone on the pypy team has even consdiered this security risk |
| 15:44:37 | jtimon_: | for example python with some framework, say flask, what's insecure there? |
| 15:44:38 | helo: | i like the simpler oracles that advertises the code they run (job they perform), and users just provide parameters (like escrow) |
| 15:44:41 | maaku: | it's outside their domain |
| 15:44:51 | maaku: | jtimon_: everything |
| 15:45:10 | jtimon_: | the security risk of what? the interpreter not doing what it's supposed to do? |
| 15:45:11 | maaku: | if you give me the ability to run random python code on your server, you're toast |
| 15:45:15 | helo: | python with flask is fine if you choose the code you execute |
| 15:45:32 | helo: | (can be fine, ofc) |
| 15:45:38 | jtimon_: | at what point I have given you the hability to run python code in my server? |
| 15:45:49 | maaku: | jtimon_: that is the context of this discussion |
| 15:45:51 | helo: | when you're using it in this context of arbitrary oracles |
| 15:45:54 | maaku: | the oracle runs user-provided programs |
| 15:46:11 | sipa: | i think we're having very different mental models of the problem |
| 15:46:18 | sipa: | jtimon_: in your mind, what does the oracle receive? |
| 15:46:24 | jtimon_: | you can only run oraclescript, which is run by an interpreter translated from reduced python to c and then compiled |
| 15:46:47 | sipa: | who runs the compiler? |
| 15:46:51 | jtimon_: | a message with some oraclescript code? |
| 15:47:23 | maaku: | so you are assuming it is impossible for any carefully constructed oraclescript to trigger a vulnerability on the server |
| 15:47:35 | jtimon_: | 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:39 | maaku: | and I'm saying that was never a design criteria of pypy, so we can't assume that |
| 15:47:41 | sipa: | of course |
| 15:48:13 | sipa: | how do you produce oraclescript? |
| 15:48:19 | sipa: | in a typical use case |
| 15:48:36 | jtimon_: | the interpreter doing strictly what you define in your language was a design criteria though |
| 15:49:12 | sipa: | 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:16 | maaku: | yes, but you're trusting pypy to do that for you |
| 15:49:22 | sipa: | but the oracle executing it by first compiling it... no |
| 15:50:24 | jtimon_: | no, the interpreter is compiled, but the oracle doesn't compile the oraclescript it receives, he interprets it with the compiled interpreter |
| 15:51:11 | sipa: | ah |
| 15:51:14 | sipa: | then i misunderstood |
| 15:51:37 | sipa: | you're really just saying to write the oracle interpreter in python, and compile it to C to improve its performance? |
| 15:52:01 | jtimon_: | that's what pypy does |
| 15:52:23 | jtimon_: | as well as giving you other tools for memory management, etc |
| 15:53:07 | sipa: | so you're not at all talking about the toolchain for creating oracle bytecode |
| 15:53:15 | sipa: | only about the interpreter implementation? |
| 15:54:18 | jtimon_: | 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:44 | sipa: | i think you were talking about totally different things |
| 15:55:23 | sipa: | 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:33 | jtimon_: | yep, I was talking about the interpreter although pyp could be probably also useful for the translation to bytecode processes |
| 15:56:57 | jtimon_: | PyPy project, [...] it's two things: |
| 15:56:57 | jtimon_: | A set of tools for implementing interpreters for interpreted languages |
| 15:56:57 | jtimon_: | An implementation of Python using this toolchain |
| 15:58:43 | hearn: | 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:53 | hearn: | language choice would follow from that |
| 15:58:57 | jtimon_: | 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:08 | hearn: | the weak point is usually the place where it interfaces with the outside world |
| 15:59:31 | hearn: | 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:59 | hearn: | 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:09 | hearn: | you'd probably ban multithreading |
| 16:00:14 | hearn: | at least to start with |
| 16:01:43 | jtimon_: | * jtimon_ wonders if there's a java implementation using pypy alreaady... |
| 16:02:00 | hearn: | 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:18 | hearn: | but ultimately it will always be risky to run programs written by a possibly malicious person ... there's no silver bullet |
| 16:02:45 | jtimon_: | so what you're considering is suing java directly as the oraclescript |
| 16:03:01 | sipa: | hell no |
| 16:03:41 | jtimon_: | it may sound stupid but I think it's simpler to implement your own oraclescript interpreter (ehem, specially using pypy) |
| 16:05:14 | sipa: | well, i wouldn't use python, but that's a different question :) |
| 16:05:25 | hearn: | jtimon_: there are about a million better things to do in the world than invent a new language |
| 16:05:36 | hearn: | so yes, i'd suggest that (a heavily restricted version of it) |
| 16:05:55 | hearn: | you realise that smartcards often run java as well, right? again, a very heavily restricted version of it (no new keyword!) |
| 16:06:34 | hearn: | 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:15 | jtimon_: | 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:26 | hearn: | 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:23 | hearn: | anyway, work day is over. out into the sun! |
| 16:09:14 | jtimon_: | too much sun here, still time to hide from it |
| 16:42:10 | maaku: | jtimon_: what I'm saying is that you'd still have to fully audit the source code and everything it relies upon |
| 16:42:36 | maaku: | 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:45 | jtimon_: | again, pypy produces dependency-less C code, the resulting interpreter is compiled from dependency-less C code |
| 16:44:18 | jtimon_: | RPython -> C -> binary |
| 17:02:58 | BlueMatt: | jgarzik: ok, you have jeff@ and jgarzik@ |
| 17:06:31 | jgarzik_: | BlueMatt, word |
| 18:11:32 | michagogo: | BlueMatt: Ooh, can I have michagogo@bitcoin.ninja? |
| 18:11:43 | michagogo: | Maybe micha@ too? |
| 18:12:38 | nshlol: | * nshlol emotes disapproval towards sillyTLDs |
| 18:16:02 | Luke-Jr: | * Luke-Jr wonders who got bitcoin.expert |
| 18:36:38 | maaku: | jtimon: the issue is/was that a reorg would make an arbitrary historical transaction invalid |
| 18:36:54 | maaku: | e.g. I exchange asset for bitcoin, then send bitcoins as payment (separate tx) |
| 18:39:36 | maaku: | the person taking that btc is unknowning assuming risk that a reorg will make the exchange transaction (which had an expiry) invalid |
| 18:47:56 | jtimon: | well, I get it although there's nothing special with btc here, it could happen with any asset |
| 18:48:30 | maaku: | yes |
| 18:48:48 | jtimon: | and the "quieting period op"? how that's better |
| 18:48:49 | jtimon: | ? |
| 18:49:28 | maaku: | queting period doesn't suffer the same problem because the period is presumably COINBASE_MATURITY blocks long |
| 18:49:47 | maaku: | you can't build off an output which is in a quieting period |
| 18:50:27 | maaku: | but it would seriously wreck things if we applied the same constraint to nExpiry bids and asks on an exchange |
| 18:50:29 | jtimon: | ok, I forgot how you were supposed to use them equivalently |
| 18:51:39 | jtimon: | even forgetting the point you just made |
| 18:52:44 | jtimon: | anyway in the example you made |
| 18:54:06 | jtimon: | 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:12 | pigeons: | is this regarding moving from a chain to a sidechain and back? |
| 19:13:51 | jtimon: | pigeons no, it is rewarding an expiry_op or a nExpiryTime field (the opposite of nLockTime) in general |
| 19:14:20 | jtimon: | we have them on freimarkets, but some people are hostile to the idea of expiries in transactions |
| 19:15:20 | jtimon: | 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:32 | jtimon: | 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:38 | jtimon: | 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:13 | jtimon: | I think was gmaxwell who convinced me that I didn't need an expiry for anything |
| 19:51:12 | BlueMatt: | michagogo: redirected to where? |
| 19:51:24 | maaku: | jtimon: i think you can do the options contract with op_maturity, but that doesn't solve the open orders problem |
| 19:51:42 | maaku: | unless you require explicit double-spends to change an order, but that is both costly and slow |
| 19:53:21 | michagogo: | BlueMatt: see notice |
| 19:53:27 | michagogo: | Thanks! |
| 19:54:04 | BlueMatt: | michagogo: hmm? is it possible my bouncer ate it? |
| 19:54:33 | michagogo: | okay, see privmsg |
| 20:33:01 | bobke_: | bobke_ is now known as bobke |
| 20:40:32 | otoburb: | otoburb is now known as Guest28941 |
| 21:31:14 | justanotheruser: | 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:31 | jonpry_: | jonpry_ is now known as jonpry |
| 22:40:03 | qwertyoruiop: | qwertyoruiop is now known as Guest1337 |
| 22:40:14 | Guest1337: | Guest1337 is now known as qwertyoruiop |
| 23:03:06 | OneFixt_: | OneFixt_ is now known as OneFixt |
| 23:27:18 | Luke-Jr: | justanotheruser: what needs elaboration? |
| 23:28:25 | justanotheruser: | Luke-Jr: how a miner proves that the hashpower used to find a block wasn't from another machine |
| 23:29:53 | justanotheruser: | I could rent out 51% of the hash power, but there is nothing locking the blocks those machines produce to someone signature |
| 23:30:40 | Luke-Jr: | justanotheruser: the chips would refuse to hash anything unsigned |
| 23:31:18 | justanotheruser: | Luke-Jr: If I'm purchasing cloud hashing services, how do I verify that their chips refuse to hash anything unsigned? |
| 23:34:24 | Luke-Jr: | justanotheruser: I think the current idea is that the chips would do some kind of remote attest to their control key |
| 23:34:57 | justanotheruser: | Luke-Jr: isn't that easy to forge? |
| 23:35:08 | maaku: | justanotheruser: you would have to get the control key from the vendor that supplied the hardware |
| 23:35:15 | maaku: | how do you forge a digital signature? |
| 23:35:40 | justanotheruser: | maaku: you don't |
| 23:35:46 | maaku: | vendor A sells asic to user B but ships it to data center C |
| 23:35:57 | maaku: | vendor A also mails a private key to user B |
| 23:36:03 | justanotheruser: | you modify the hardware (or have lying hardware to begin with) |
| 23:36:26 | Luke-Jr: | justanotheruser: people will obviously buy it without decentralisation |
| 23:36:32 | justanotheruser: | indeed |
| 23:36:44 | Luke-Jr: | justanotheruser: point is that once this is in place, it's good |
| 23:36:57 | maaku: | 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:57 | Luke-Jr: | trust is upfront only |
| 23:36:59 | justanotheruser: | Luke-Jr: "it's good"? |
| 23:37:28 | Luke-Jr: | you don't need to worry about some hostile entity breaking into the datacenter, social engineering them, etc |
| 23:37:31 | maaku: | justanotheruser: the idea is that modifying the miners is more expensive than it is worth |
| 23:37:44 | justanotheruser: | maaku: good point |
| 23:37:56 | maaku: | it breaks down if you lose that assumption |
| 23:38:16 | maaku: | btw highlighting gmaxwell because this is really his idea |
| 23:40:17 | justanotheruser: | 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:15 | Luke-Jr: | justanotheruser: what's the problem? |
| 23:42:14 | justanotheruser: | 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:37 | Luke-Jr: | that's basically solved IMO |
| 23:42:56 | kanzure: | you can fabricate your own asics |
| 23:43:08 | kanzure: | don't listen to the propaganda from the billion dollar fabs :p |
| 23:43:29 | kanzure: | they are just grumpy that they keep replacing their equipment every few years |
| 23:44:17 | Luke-Jr: | justanotheruser: solved because new chips won't be 30% |
| 23:44:20 | justanotheruser: | Luke-Jr: it is solved because there is so much competition? |
| 23:44:52 | justanotheruser: | I assume the new chips were only 30% because of how unoptomized ASICs were? |
| 23:47:03 | Luke-Jr: | also because the old chips were obsolete technology |
| 23:47:21 | jtimon: | justanotheruser the room for further optimizations only shrinks |
| 23:48:23 | justanotheruser: | Luke-Jr: and they will take much longer to become obsolete because of the shrinking rise in rise in difficulty? |
| 23:48:46 | Luke-Jr: | justanotheruser: because we're basically up-to-date on ASIC tech now |
| 23:48:55 | Luke-Jr: | ASIC tech doesn't shrink *that* fast |
| 23:49:40 | Luke-Jr: | Intel might be able to pull off 30% on a new gen of chips right now, but short of that.. |
| 23:50:10 | Luke-Jr: | (by combining their skills and access to bleeding-edge ASIC tech) |
| 23:51:46 | justanotheruser: | hm, that's reassuring |