00:24:30AlexWagner:AlexWagner is now known as StephanKonstanti
00:25:36StephanKonstanti:StephanKonstanti is now known as StephanYanev
01:05:30Adohgg:Adohgg is now known as moriartyisfat
01:06:12moriartyisfat:moriartyisfat is now known as ungrup
01:06:52ungrup:ungrup is now known as Adohgg
02:36:08Taek42:justanotheruser if you wanted to estimate a conversion rate between blockchain bloat and utxo bloat, you could look at the number of nodes that store the whole blockchain vs. the number of nodes that store just the utxo set, and then compare the type of memory they store them in and the frequency with which they access the memory. I guess there's also bandwidth to consider, but this would seem to be a lesser detail when bloat is so small per-
02:37:20Taek42:working completely in the dark, I'd say you'd consider utxo data to be 2x (for being accessed more often than the full blockchain), and then you'd have another multiplier which is the inverse of the percentage of full nodes on the network. (IE if 10% of nodes are full nodes, then multiply by 10x in addition to the 2x ==> 20x total)
02:47:52Dr-G3:Dr-G3 is now known as Valleygrill
02:53:09x48:google trends for bitcoin starting to curve up again
02:53:28x48:wrong room, sorry
04:03:09gmaxwell:gmaxwell is now known as Guest67746
05:32:36phantomcircuit|w:laptop memory went bad
05:33:43phantomcircuit|w:oh i know
05:33:50phantomcircuit|w:i knocked capacitors off one of them
05:33:54phantomcircuit|w:thought i fixed that...
07:15:59brisque:because I know it's the source of much amusement, the "darkcoin" developers actually made their system open source after however many months of "polish" it needed. https://github.com/darkcoin/darkcoin/commit/133f4387866ca572c01383a52c9299ab3d9fe692
07:18:23fluffypony:now they just need to add "instant transactions that are entirely dissimilar, but not entirely unlike, green addresses" and clearly they're headed for the moon
07:18:31fluffypony:eugh 5644 lines in a single commit :/
07:21:13brisque:https://github.com/darkcoin/darkcoin/commit/133f4387866ca572c01383a52c9299ab3d9fe692#diff-568a69d65983b416159f2a6f562c84f4R214 < does that mean someone can just make a masternode that just takes all of the "collateral" transactions no matter what?
08:05:18orwell.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:18orwell.freenode.net:Users on #bitcoin-wizards: andy-logbot adam3us OX3_ brisque damethos chris200_ melvster Eliel drawingthesun tromp__ toffoo HM pen p15 Guest67746 amiller_ justanotheruser artifexd TheSeven Adlai fanquake Valleygrill DougieBot5000 x48 digitalmagus crescendo TrollsRoyce vmatekol_ koshii LarsLarsen spinza prepost hashtag cfields btc_ jaekwon ericp4 todaystomorrow kgk SDCDev livegnik jchp kanzure mortale br4n bobke devrandom Graftec iddo HaltingState AaronvanW stonecoldpat
08:05:18orwell.freenode.net:Users on #bitcoin-wizards: samson2 MRL-Relay arowser comboy irc88__ Happzz copumpkin EasyAt wumpus [d__d] StephanYanev emsid jgarzik nsh dgenr8 K1773R coryfields xmj go1111111 michagogo hollandais _2539 altoz zenojis mappum warren jrayhawk jbenet LaptopZZ optimator_ pi07r Meeh Hunger-- poggy_ Luke-Jr Emcy_ UukGoblin danneu catcow TD-Linux Guest50253 helo smooth otoburb gwillen ryan-c nickler_ mmozeiko roasbeef pajarillo sl01 Keefe Dyaheon Grishnakh rs0_ Gnosis nuke1989
08:05:18orwell.freenode.net:Users on #bitcoin-wizards: ahmed_ wiretapped Muis Logicwax puszl nanotube espes__ andytoshi rfreeman_w so zibbo lnovy dansmith_btc epscy tacotime OneFixt Fistful_of_coins BlueMatt tromp wizkid057 a5m0 starsoccer midnightmagic Adohgg berndj gribble Graet kinlo [Derek] pigeons BrainOverfl0w lianj_ Apocalyptic Iriez mr_burdell fluffypony bbrittain SomeoneWeird forrestv Anduck Nightwolf Krellan BigBitz [\\\] Taek42 asoltys sipa nsh- phantomcircuit DoctorBTC harrow CodeShark
08:05:18orwell.freenode.net:Users on #bitcoin-wizards: throughnothing Guest47516 Alanius abc56889 lechuga_ burcin petertodd @ChanServ phedny
08:46:02phantomcircuit:brisque, seems to yes
08:46:33phantomcircuit:and iirc they masternodes are elected or something so it's probably hyber sybil vulnerable
08:48:55brisque:phantomcircuit: sort of. they "lock" a set of outputs for a period and use that as a sort of weak "anti sybil". every single node in the network then connects to the masternodes socket, and chooses betwen the masternodes they can see.
08:49:28brisque:phantomcircuit: it's pretty easy to abuse. if you can partition a person then the "masternode" will always be you, so uh. yeah there's a lot of problems in this system even just from a quick glance.
10:04:46samson2:samson2 is now known as samson_
12:12:21jgarzik:jgarzik is now known as home_jg
12:39:25crescendo:@brisque thanks for the heads up on my github repo, btw
12:40:37brisque:crescendo: you're from bitpay?
12:42:08brisque:absolutely no worries :)
12:47:18hearn:crescendo: do you work on copay by any chance?
12:58:36crescendo:no, not directly, but I am responsible for aggregating feedback about it
12:58:49crescendo:also, we've met
13:22:53amiller_:http://eprint.iacr.org/2014/763 On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin clients
13:23:24amiller_:from the system security group at eth zurich
13:24:35hearn:ah they published it
13:25:08brisque:heh, wonder if they'd like my dataset :)
13:25:48amiller_:seems from the metadata there it's accepted to ACSAC 2014 and will be presented in dcember
13:27:00amiller_:tldr: SPV bloom filters leak info about addresses to the nodes they connnect to... putting less data in the bloom filter (just the pubkey hash, rather than both pubkey and pubkey hash) and keeping state so you don't rebuild a new bloom filter every time you reconnect would fix it
13:27:28hearn:not entirely fix. there are lots of things that need to be done to increase privacy of bloom filters
13:27:30hearn:it's a hard PIR problem
13:27:40hearn:those things are necessary but not sufficient for a full solution
13:28:20brisque:with a large enough collection of bloom filters you can do interesting things too, like follow users cross-network by intersecting their filters.
13:28:27hearn:i think it was discussed in this channel before, i can't remember on which day but the logs should have it
13:29:37amiller_:i grepped my log a few different ways and can't find it if so
13:30:24hearn:amiller_: this was some weeks ago
13:31:24brisque:"If theadversary acquires two Bloom filters of the same user whichare initialized with different seeds, then these filters are likely to exhibit different false positives" < I could probably do this with my small collection of them
13:33:03hearn:hmm now i can't find the logs either. annoying.
13:33:22brisque:hearn: amiller_: bitcoin.ninja has nice logs and a better interface.
13:34:05hearn:yeah, i guess this discussion predates it
13:34:48hearn:anyway i'll link to the paper from the relevant issue
13:37:56hearn:also interesting: http://eprint.iacr.org/2014/764
13:38:58brisque:so they suggest grinding to find addresses that make filters with the same bloom filter pattern? that sounds.. undesrable given the search space.
13:39:52brisque:it means you can just search for addresses in the block chain that have the exact name filter, and make an assumption that they are more likely than not related. that seems worse than a possibly not-logging node exposing them.
13:41:57hearn:i don't think that's what they suggest
13:42:19brisque:"Subsequently, whenever an SPV client needs to generate a new Bitcoin address, it will choose a Bitcoin address which matches its existing Bloom filter
13:42:36brisque:oh. bloom filter *including* the junk already there.
13:43:47lianj_:lianj_ is now known as lianj
13:47:58brisque:means you can't really use an HD wallet easily though
13:50:00andytoshi:you can grind on an HD wallet
13:50:13andytoshi:it will make it incompatible with other software that uses "gap limits" tho
13:50:39hearn:brisque: bitcoinj already pre-generates lots of keys and addresses to generate bloom filters
13:51:19brisque:hearn: that's different to making millions of them though, it would make recovering from a seed ~impossible
13:51:50andytoshi:if you stored the filter along with the seed it'd be fine
13:51:53andytoshi:just slow
13:52:27brisque:pretty high cost. can't restore from just the seed anymore.
13:52:43hearn:you don't really need it, as far as i can tell? you just connect to different nodes
13:52:46andytoshi:wizards-wallet right now uses the master chaincode to seed a filter, on the assumption that the master chaincode will never be publicized ... i haven't decided yet what a safer way to do this is
13:53:12brisque:actually you could if the junk was based on the seed somehow as well. then you'd know how far you had to grind to get the next key, and the next and the next.
13:56:17andytoshi:i guess i should HMAC the cc keyed on the master key, that'd at least not show up in standard HD tools that don't consider the cc to be such a privacy risk
13:56:32hearn:andytoshi: what is wizards-wallet?
13:56:34andytoshi:but i've gotta write signing code so i can get my testcoins off the current system first :)
13:56:56andytoshi:hearn: it is my "learn to use rust for bitcoin" toy project
13:57:25andytoshi:hearn: the goal eventually is that it will support all the weird protocols (eg coinswap) that get posted on bct but nobody knows how to do UI for
13:57:39hearn:ah ok.
13:57:46hearn:how do you find rust?
13:57:50andytoshi:with the understanding that it is a sharp tool and you shouldn't store lots of coins with it
13:57:53brisque:andytoshi: it's still not great, really. the chance of you connecting to one of my nodes is fairly high really, means you can easily be followed cross-network.
13:57:54andytoshi:hearn: i really really like it
13:58:51andytoshi:brisque: well, i'm using my filters for something different (wizards-wallet is a full node, it sees all the utxos ... the filter is so that i can rapidly scan them all and eliminate 255/256 of them without squinting too hard ... lets me load a wallet and index its spendable txos in like 3 seconds)
13:58:55brisque:I don't care enough to run it, but I'm sure somewhere I've captured intersecting filters on more than one network.
13:59:39brisque:andytoshi: oh nice, got it.
13:59:56hearn:andytoshi: what do you like about it?
13:59:59andytoshi:hearn: the usually advertised lifetime/aliasing checks are really helpful, it makes writing code way faster and way more fun, the compiler error messages are very detailed and helpful...
14:00:13hearn:andytoshi: but is it better than just regular gc?
14:00:16andytoshi:hearn: yes
14:00:19hearn:i mean a wallet is not really system level software, i'd say
14:00:22andytoshi:hearn: gc does not track ownership
14:00:25hearn:you are not writing a kernel
14:00:41andytoshi:hearn: you can still have races, you can still have stuff being mutated from multiple places
14:00:48andytoshi:hearn: rust is way way easier to think about
14:01:03hearn:ok. so you like the data race/immutability controls
14:01:20andytoshi:yeah. the memory safety is nice but you don't really think about it
14:02:11hearn:do you find the lack of libraries an issue?
14:02:11andytoshi:also the typing system is very useful, you can do stuff like `struct SecretKey([u8, ..32])` which is a type SecretKey whose interface you can specify, and at compile-time it is just a 32-byte array ... there are tons of these "zero-cost abstractions" in rust
14:02:30andytoshi:hearn: not really. it's improving rapidly, a lot of libraries i just contribute to when i'm missing stuff
14:02:41andytoshi:hearn: but all the major C libs have wrappers by now
14:02:47andytoshi:and wrapping C libs is not exactly hard..
14:03:21andytoshi:having said that, the next month will see another round of breaking stdlib and syntax changes, don't learn the language now
14:03:58hearn:no i saw that they keep changing it in quite significant ways
14:04:02hearn:was going to wait a while before looking at that
14:04:06andytoshi:but it should be the last round, we are on track for 1.0rc1 this year..
14:04:10hearn:my current new language is kotlin anyway. only so many hours in the day :)
14:04:16andytoshi:yeah, fair enough :)
14:06:24hearn:https://transfer.sh/ - looks useful
14:06:31andytoshi:i do want to emphasize tho that rust doesn't -feel- like a low-level language, because it has so many high-level abstractions (most of which are zero-cost, i.e. basically glorified compiler instructions), it supports concurrency really well, the compiler knows how objects' lifetimes are supposed to related to each other, what can be shared safely, etc
14:06:47hearn:sure, i understand that
14:07:24andytoshi:it makes C++ feel like assembler :P
14:07:24hearn:my main issue with such languages these days is that the ecosystem of C libraries is not that great, especially compared to what you get with larger/older ecosystems like python, the jvm etc
14:07:47andytoshi:yeah, that's a big priority for rust, it links with C very cleanly
14:07:48hearn:i'd like to see the good bits of rust brought into a jvm language, as much as technically possible at least (not all of it would be doable)
14:07:58andytoshi:tho the package manager (cargo) does not support this well at all yet
14:08:07hearn:kotlin is pretty sweet in many ways, but it's not got the same notion of ownership in the core type system (it does however have nullability/optionality)
14:08:45hearn:although this is partly in order to achieve zero-cost interop with java libraries. so it strikes a different part of the interop/new-features spectrum
14:08:52andytoshi:i'll check it out if i can, i also have limited hours :)
14:09:21hearn:http://kotlinlang.org/ - it's nothing incredibly new, but has the advantage that it's written by professional IDE designers, so you don't have to sacrifice libraries *or* tools. very convenient.
14:10:11hearn:i can imagine migrating lighthouse or even with a bit more work bitcoinj to it
14:10:27hearn:e.g. there's even a java to kotlin auto translator to get you started. very clean upgrade path for existing codebases written in crappy languages :
14:11:51brisque:oh look, more "secure 0conf transactions" bullshit.
14:12:01brisque:that'll work.
14:12:17brisque:er, wrong channel but still sorta on topic.
14:14:31fluffypony:brisque: you talking about Darkcoin "solving" instant transactions or something else?
14:15:51brisque:it's deeply off topic for this channel (meant for #bitcoin), but I was referencing this. https://archive.today/bxtZN
14:16:08brisque:(archive link because of annoying javascript)
14:16:46brisque:fluffypony: did you see that they actually made their "dark send" open source?
14:17:39fluffypony:they also had a review from Kristov Atlas that listed a bunch of potential attacks, and they seem to have brushed them off
14:17:47fluffypony:and taken his audit as a thumbs up
14:18:06brisque:any audit is a good audit if you shill hard enough :)
14:18:09hearn:andytoshi: it looks like rust solves concurrency by insisting on (a) immutable data and (b) if it's mutable, it can only be accessed via a scoped mutex lock. does that sound right?
14:18:47hearn:incidentally the intro doc is really good
14:20:56brisque:fluffypony: never ceases to amaze me how much they are pushing a broken concept though. even without looking too hard at the code, the whole system is instantly vulnerable to DOS attack.
14:21:28fluffypony:brisque: yeah, I've said as much on several occasions - they'd honestly have been better off dumping the masternode idea. ah well.
14:22:53andytoshi:hearn: roughly. you can define types with more precise access rules than mutex locks
14:23:02brisque:fluffypony: guess it works works until it doesn't.
14:23:13andytoshi:(and even mutexes are library types, there is almost no direct language support for this stuff)
14:23:20hearn:brisque: you could say the same of bitcoin ;)
14:23:30hearn:andytoshi: right. i think these abstractions are implementable in kotlin, but not enforceable.
14:24:00hearn:though automated "movement" would be tricky, probably not catchable at compile time.
14:24:03andytoshi:hearn: e.g. there are RWLocks, which let you have multiple read-only refs, there are Arcs "atomic refcounted pointers" which let you share immutable data, there is Once which lets you write to something once on first use
14:24:15hearn:i'm familiar with these
14:24:32brisque:hearn: bitcoin doesn't have DOS issues we can directly point at though. like, darkcoin wallets make an outgoing connection to every single "masternode" for an example. what.
14:24:42hearn:huh what?
14:24:46hearn:bitcoin is riddled with DoS issues
14:24:55fluffypony:quite incomparable, though, hearn
14:25:01brisque:like division by zero? ;)
14:25:15fluffypony:they have a handful of "masternodes" and every single full node connects to as many masternodes as possible
14:25:37brisque:and no, not on the same scale at all. in this case a single person who wants all the "masternode" fees for themselves can just DOS all the rest. they make bank, easy.
14:26:34fluffypony:I raised that and it got cross-posted, brisque - https://darkcointalk.org/threads/interesting-question-reposted-from-bitcointalk-org.1999/
14:26:52fluffypony:there's an official response in that thread
14:27:14andytoshi:i'm with hearn, would not be bragging about bitcoin's dos resistance :)
14:27:47brisque:better than connecting to masternodes, that's for sure.
14:28:14brisque:and I know better than most that bitcoin is slightly fragile
14:28:35brisque:I've reported big bugs and got responses from hearn in the same voice
14:28:45brisque:well, a bug to that mailing list.
14:29:54brisque:fluffypony: do you really need to SYN flood them? wouldn't the masternodes have the same ~1000 connection limit that bitcoin nodes do?
14:29:54hearn:clearing them out will take a lot of work :( + a somewhat professional audit
14:30:39brisque:fluffypony: same atack you can do on the bitcoin network today, pack 125 conenction to all of the 7000 listening sockets, and you've just taken down the whole network.
14:30:45fluffypony:brisque: the point was to take them offline by having them null-routed so everything gets routed through masternodes you control
14:30:56fluffypony:the difference is that you have no financial incentive to do so
14:31:01brisque:fluffypony: yep, I got that.
14:31:07fluffypony:a masternode operator has a direct financial incentive to attack the next guy
14:31:56fluffypony:the thing that a lot of the altcoin developers don't understand is that anytime you monetise / incentivise something you also create an attack vector
14:32:00brisque:fluffypony: indeed, which is why we haven't seen mass attacks against the bitcoin network so far. I don't think the sort of people who have the power (botnet hearders) have the intellegence to try to partition the network for their own gain.
14:33:53brisque:I'm not sure that would work very well, there's a reasonable amount of private peering in our network already. my nodes peer with each other on a private network (but not with each other over the internet) in an effort to avoid that sort of thing.
14:37:11brisque:I've been meaning to try and get some pools to peer as well, but that might be a bit on the ambitious side :)
15:39:26Guest67746:Guest67746 is now known as gmaxwell
15:42:43gmaxwell:hearn: Did you see the proposed alternaive bloom filter construction? It looks like it would use somewhat more bandwidth in the case where the user had few addresses, but have potentially much better privacy.
15:43:51gmaxwell:the notion is instead of the client sending a bloom filter, the node sends a compressed map of the txouts in the block and the client does the matching itself. Because the data is per block, it needs no additional cpu time on the server and could even be comitted so its authenticated.
16:01:26starsoccer:gmaxwell, just a bit curious, but why cant something as simple as just keeping a log of the previous 5 locations for each satoshi work
16:01:37starsoccer:then you dont have to keep the whole blockchain and just have a small amount of it
16:02:38brisque:not that exactly, but nodes which only keep a partial block history are totally possible. I'm running one right now.
16:03:37starsoccer:intersting, but I am saying to stop the need for full nodes all together and just have node that keep X previous locations for the coins
16:04:04gmaxwell:starsoccer: you don't have to keep anywhere near that much. Bitcoin-qt is already designed this way... there just isn't a handy knob to delete the old data.
16:04:22gmaxwell:starsoccer: oh you cannot do that you you can just be fed bullshit when you connect.
16:04:40gmaxwell:The data is still needed for initilization but isn't needed after that.
16:04:55starsoccer:agreed, but why cant you use the typical 51% rule to figure out what is and isnt bs
16:05:22starsoccer:for example if 1 node is feeding me info saying X coins were sent to guy a but everyone else is saying X coins when to guy B then I know which is correct
16:05:35gmaxwell:Because the "typical 51% rule" is only for order. The large hashpower participants have an economic incentive to not lie that goes away if they can lie freely.
16:06:12gmaxwell:If you allow them to just say "hey, it would be in all of our interests to move the subsidy back to 50 btc" then ... why do you think they wouldn't, if the whole network would just accept it?
16:06:13starsoccer:im confused, what incentive do they have no not lie
16:06:32starsoccer:what stops such an agreement with all the big mining pools now?
16:06:45gmaxwell:starsoccer: miners are explicitly untrusted in bitcoin. The design of the protocol stops it.
16:07:28gmaxwell:The only thing miners influence is 'order', which is powerful indeed, but they cannot produce a blockchain that inflates or steals arbritary coins. If they tried the other nodes would all ignore it.
16:07:36starsoccer:okay, but what stops for example lets say 3 big pools from saying lets go back 10 blocks and then start creating new blocks from there
16:07:37gmaxwell:(and it would be precisely equal to not mining at all)
16:07:50brisque:starsoccer: nothing.
16:08:03brisque:this is why pools are particularly dangerous.
16:08:08starsoccer:so basically the nodes need some sort of incentive to not lie
16:08:21gmaxwell:starsoccer: they can do that, but doing that only allows reordering transactions... which can allow theft in the case someone took an irreversable action with respect to a pool's transactions in that time, but thats it.
16:08:27jgarzik:miners cannot create fake transactions or steal coins
16:08:38jgarzik:they can reorder transaction timeline, potentially removing transactions
16:09:11starsoccer:gotcha, and in theory they could create blocks in such a way as to avoid X coins ever being allowed to move
16:09:21gmaxwell:But they can't, for example, just create more coins for themselves. Or steal arbritary coins (at least not without breaking the whole thing)
16:09:41starsoccer:Yes I understand that
16:09:49starsoccer:hmm just trying to think of a solution
16:10:17gmaxwell:There isn't a solution. Its the limitations of the system.
16:10:45gmaxwell:(you can come up with random things, they all open new attacks and have different and not clearly better tradeoffs)
16:12:27starsoccer:agreed, another idea I had, is as follows,
16:14:07starsoccer:basically the nodes would be paid to find coins that went in a circle. for example went from guy A to guy b to guy C back to Guy A. and then to simplify it but just removing the whole circle
16:14:46brisque:that doesn't work within the scope of outputs at all.
16:15:43starsoccer:im not sure exactly of the fine details of it, but something as simple as just only relaying certians parts of the transaction or something
16:16:13andytoshi:you cannot design cryptosystems "on a high level", the details are crucial
16:16:21andytoshi:and on a detailed level, what you are saying is gibberish
16:16:35brisque:each transaction contains the hash of it's previous. you can't eliminate "loops".
16:16:57starsoccer:sorry, like I said, just brainstorming
16:17:06starsoccer:well actully
16:17:35starsoccer:brisque, why cant you just rather then relay all the transactions of the coins moving from one to another and then back to guy A just not relay any of them at all. and so its like they are still with guy A
16:18:43brisque:that doesn't work either, have a read of the whitepaper and you'll find more reasons why not.
16:26:13amiller_:Here's a new paper about formalizing the Bitcoin consensus protocol http://eprint.iacr.org/2014/765 The Bitcoin Backbone Protocol: Analysis and Applications
16:26:46andytoshi:been a busy day in academia, here is one about ringsigs http://eprint.iacr.org/2014/764
16:27:36fluffypony:oh surae will like that last one
16:28:08amiller_:it's the day after eurocypt submission deadline :)
16:28:56fluffypony:well since we're formally releasing this in a couple of hours, I suppose everyone can take a look at MRL-0003 - http://lab.monero.cc/pubs/MRL-0003.pdf
16:29:20andytoshi:behind cloudflare
16:29:39fluffypony:should be able to wget it
16:29:51brisque:is there a reason monero didn't ditch the horrible backdoor PoW?
16:30:02fluffypony:brisque: no time yet
16:30:30fluffypony:we're not blood-bound to it, though, and there are some alternatives up for consideration, but it's not something we have to hurry
16:30:44brisque:right. so not an assertion it's "asic proof", just developer-time proof :)
16:31:15fluffypony:ah well it was never meant to be asic "proof", just to lower the performance gap between CPUs / GPUs / ASICs
16:31:24fluffypony:which it has done remarkably well
16:31:45brisque:just before I saw it being called "ASIC proof", which I don't believe in the least
16:31:57fluffypony:the tradeoff is that it makes verification stupidly expensive, so in that aspect it fails
16:32:08fluffypony:brisque: by idiots, yes :-P
16:32:24amiller_:andytoshi, this paper isn't just about 'ringsigs' it also claims to have a construction for zerocoin/zerocash that doesn't rely on any trusted setup
16:32:39andytoshi:oh lol, i didn't see the "no crs" bit
16:32:52andytoshi:wow, that's exciting
16:33:04fluffypony:quite so
16:33:08andytoshi:will print and read then
16:34:27brisque:fluffypony: I think, honestly, if there were somebody who has ported the thing to some sort of FPGA or ASIC.. we wouldn't know about it save for the global hashrate. for monero it is ridiculously high even now.
16:34:50brisque:I've done the numbers several times and they just come off as insane
16:35:05fluffypony:brisque: I'm certain someone has, although it would only run on exceedingly expensive FPGAs due
16:35:12fluffypony:but if you happened to have those lying around, then definitely
16:36:11brisque:23MH/s on some moonmagic GPU giving you 1KH/s means there's 23,000 of them mining?
16:36:13amiller_:andytoshi, uh nvm it seems like it's super inefficient, looks like it needs N steps to spend a coin if there are N available coins,
16:36:50brisque:I suppose a small botnet would account for the Monero hashrate entirely
16:37:27fluffypony:Claymore's miner does ~700h/s on a 290X, and an EC2 c3.8xlarge does around 1100h/s
16:38:18brisque:so 32,000 top end AMD graphics cards? no way.
16:38:26fluffypony:definitely a botnet or two in there
16:40:30andytoshi:amiller_: oh lol
16:41:12amiller_:it's pretty close to a naive zk proof that "i'm spending either coin 1, or coin 2, or coin 3, or ... ", just the proof is "smaller" (but not any faster to compute or verify)
16:41:21brisque:fluffypony: a big one, no doubt.
16:59:32gmaxwell:hm log in the accumulator size.
17:00:55gmaxwell:but by my figuring a 4e6 setsize would have signatures under 5kb.
17:02:10gmaxwell:It's a serial reveal scheme, so we can use the script commitment (and potentially value comittement) approach andytoshi and I came up with for BRS.
17:27:55gmaxwell:ah, the catch is that its computationally unfriendly.
17:31:03gmaxwell:(size scales with log() but verification is O(n))
18:17:11andytoshi::P i would've said "value commitment (and potentially script commitment)"
20:54:40phantomcircuit:gmaxwell, lol
20:54:55phantomcircuit:the memory in my laptop is failing... but inconsistently and apparently at random
20:55:14pigeons:mine too :(
20:55:29phantomcircuit:i ran memtest in two separate runs
20:55:35phantomcircuit:immediate failure the first time
20:55:39phantomcircuit:no failures the second time
20:56:53gmaxwell:might be crap in the socket.
20:57:24phantomcircuit:entirely plausible
20:57:51phantomcircuit:it's unpossible to remove them
20:58:00phantomcircuit:there's a heat pipe directly over the socket
20:58:07phantomcircuit:(which could also be the issue...)
20:58:17fluffypony:have you re-seated the RAM?
20:58:21helo:disassembling laptops is the best
20:58:43helo:(way to anger techie friends)
20:59:33phantomcircuit:cant get this python code to read fixed sized records at more than 3.5m/second
21:00:00phantomcircuit:well that is 210 MB/s
21:00:04phantomcircuit:i guess that's not *too* bad
21:26:05home_jg:home_jg is now known as jgarzik