| 00:24:30 | AlexWagner: | AlexWagner is now known as StephanKonstanti |
| 00:25:36 | StephanKonstanti: | StephanKonstanti is now known as StephanYanev |
| 01:05:30 | Adohgg: | Adohgg is now known as moriartyisfat |
| 01:06:12 | moriartyisfat: | moriartyisfat is now known as ungrup |
| 01:06:52 | ungrup: | ungrup is now known as Adohgg |
| 02:36:08 | Taek42: | 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:36:09 | Taek42: | minute. |
| 02:37:20 | Taek42: | 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:52 | Dr-G3: | Dr-G3 is now known as Valleygrill |
| 02:53:09 | x48: | google trends for bitcoin starting to curve up again |
| 02:53:17 | x48: | http://www.google.com/trends/explore#q=bitcoin |
| 02:53:24 | x48: | whoops |
| 02:53:28 | x48: | wrong room, sorry |
| 04:03:09 | gmaxwell: | gmaxwell is now known as Guest67746 |
| 05:32:32 | phantomcircuit|w: | darn |
| 05:32:36 | phantomcircuit|w: | laptop memory went bad |
| 05:32:42 | phantomcircuit|w: | :( |
| 05:33:43 | phantomcircuit|w: | oh i know |
| 05:33:50 | phantomcircuit|w: | i knocked capacitors off one of them |
| 05:33:54 | phantomcircuit|w: | thought i fixed that... |
| 07:15:59 | brisque: | 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:23 | fluffypony: | 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:31 | fluffypony: | eugh 5644 lines in a single commit :/ |
| 07:21:13 | brisque: | 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:18 | orwell.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:18 | orwell.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:18 | orwell.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:18 | orwell.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:18 | orwell.freenode.net: | Users on #bitcoin-wizards: throughnothing Guest47516 Alanius abc56889 lechuga_ burcin petertodd @ChanServ phedny |
| 08:46:02 | phantomcircuit: | brisque, seems to yes |
| 08:46:33 | phantomcircuit: | and iirc they masternodes are elected or something so it's probably hyber sybil vulnerable |
| 08:48:55 | brisque: | 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:28 | brisque: | 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:46 | samson2: | samson2 is now known as samson_ |
| 12:12:21 | jgarzik: | jgarzik is now known as home_jg |
| 12:39:25 | crescendo: | @brisque thanks for the heads up on my github repo, btw |
| 12:40:37 | brisque: | crescendo: you're from bitpay? |
| 12:41:58 | crescendo: | yes |
| 12:42:08 | brisque: | absolutely no worries :) |
| 12:47:18 | hearn: | crescendo: do you work on copay by any chance? |
| 12:58:36 | crescendo: | no, not directly, but I am responsible for aggregating feedback about it |
| 12:58:49 | crescendo: | also, we've met |
| 13:22:53 | amiller_: | http://eprint.iacr.org/2014/763 On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin clients |
| 13:23:24 | amiller_: | from the system security group at eth zurich |
| 13:24:35 | hearn: | ah they published it |
| 13:25:08 | brisque: | heh, wonder if they'd like my dataset :) |
| 13:25:48 | amiller_: | seems from the metadata there it's accepted to ACSAC 2014 and will be presented in dcember |
| 13:27:00 | amiller_: | 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:28 | hearn: | not entirely fix. there are lots of things that need to be done to increase privacy of bloom filters |
| 13:27:30 | hearn: | it's a hard PIR problem |
| 13:27:40 | hearn: | those things are necessary but not sufficient for a full solution |
| 13:28:20 | brisque: | 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:27 | hearn: | i think it was discussed in this channel before, i can't remember on which day but the logs should have it |
| 13:29:37 | amiller_: | i grepped my log a few different ways and can't find it if so |
| 13:30:24 | hearn: | amiller_: this was some weeks ago |
| 13:31:24 | brisque: | "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:03 | hearn: | hmm now i can't find the logs either. annoying. |
| 13:33:22 | brisque: | hearn: amiller_: bitcoin.ninja has nice logs and a better interface. |
| 13:34:05 | hearn: | yeah, i guess this discussion predates it |
| 13:34:48 | hearn: | anyway i'll link to the paper from the relevant issue |
| 13:37:56 | hearn: | also interesting: http://eprint.iacr.org/2014/764 |
| 13:38:58 | brisque: | 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:52 | brisque: | 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:52 | hearn: | no |
| 13:41:57 | hearn: | i don't think that's what they suggest |
| 13:42:19 | brisque: | "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:36 | brisque: | oh. bloom filter *including* the junk already there. |
| 13:43:47 | lianj_: | lianj_ is now known as lianj |
| 13:47:58 | brisque: | means you can't really use an HD wallet easily though |
| 13:50:00 | andytoshi: | you can grind on an HD wallet |
| 13:50:13 | andytoshi: | it will make it incompatible with other software that uses "gap limits" tho |
| 13:50:39 | hearn: | brisque: bitcoinj already pre-generates lots of keys and addresses to generate bloom filters |
| 13:51:19 | brisque: | hearn: that's different to making millions of them though, it would make recovering from a seed ~impossible |
| 13:51:50 | andytoshi: | if you stored the filter along with the seed it'd be fine |
| 13:51:53 | andytoshi: | just slow |
| 13:52:27 | brisque: | pretty high cost. can't restore from just the seed anymore. |
| 13:52:43 | hearn: | you don't really need it, as far as i can tell? you just connect to different nodes |
| 13:52:46 | andytoshi: | 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:12 | brisque: | 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:53:19 | andytoshi: | yeah |
| 13:56:17 | andytoshi: | 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:32 | hearn: | andytoshi: what is wizards-wallet? |
| 13:56:34 | andytoshi: | but i've gotta write signing code so i can get my testcoins off the current system first :) |
| 13:56:56 | andytoshi: | hearn: it is my "learn to use rust for bitcoin" toy project |
| 13:57:25 | andytoshi: | 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:39 | hearn: | ah ok. |
| 13:57:46 | hearn: | how do you find rust? |
| 13:57:50 | andytoshi: | with the understanding that it is a sharp tool and you shouldn't store lots of coins with it |
| 13:57:53 | brisque: | 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:54 | andytoshi: | hearn: i really really like it |
| 13:58:51 | andytoshi: | 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:55 | brisque: | 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:39 | brisque: | andytoshi: oh nice, got it. |
| 13:59:56 | hearn: | andytoshi: what do you like about it? |
| 13:59:59 | andytoshi: | 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:13 | hearn: | andytoshi: but is it better than just regular gc? |
| 14:00:16 | andytoshi: | hearn: yes |
| 14:00:19 | hearn: | i mean a wallet is not really system level software, i'd say |
| 14:00:22 | andytoshi: | hearn: gc does not track ownership |
| 14:00:25 | hearn: | you are not writing a kernel |
| 14:00:41 | andytoshi: | hearn: you can still have races, you can still have stuff being mutated from multiple places |
| 14:00:47 | hearn: | yes |
| 14:00:48 | andytoshi: | hearn: rust is way way easier to think about |
| 14:01:03 | hearn: | ok. so you like the data race/immutability controls |
| 14:01:20 | andytoshi: | yeah. the memory safety is nice but you don't really think about it |
| 14:02:11 | hearn: | do you find the lack of libraries an issue? |
| 14:02:11 | andytoshi: | 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:30 | andytoshi: | hearn: not really. it's improving rapidly, a lot of libraries i just contribute to when i'm missing stuff |
| 14:02:41 | andytoshi: | hearn: but all the major C libs have wrappers by now |
| 14:02:47 | andytoshi: | and wrapping C libs is not exactly hard.. |
| 14:03:00 | hearn: | right |
| 14:03:21 | andytoshi: | having said that, the next month will see another round of breaking stdlib and syntax changes, don't learn the language now |
| 14:03:58 | hearn: | no i saw that they keep changing it in quite significant ways |
| 14:04:02 | hearn: | was going to wait a while before looking at that |
| 14:04:06 | andytoshi: | but it should be the last round, we are on track for 1.0rc1 this year.. |
| 14:04:10 | hearn: | my current new language is kotlin anyway. only so many hours in the day :) |
| 14:04:16 | andytoshi: | yeah, fair enough :) |
| 14:06:24 | hearn: | https://transfer.sh/ - looks useful |
| 14:06:31 | andytoshi: | 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:47 | hearn: | sure, i understand that |
| 14:07:24 | andytoshi: | it makes C++ feel like assembler :P |
| 14:07:24 | hearn: | 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:47 | andytoshi: | yeah, that's a big priority for rust, it links with C very cleanly |
| 14:07:48 | hearn: | 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:58 | andytoshi: | tho the package manager (cargo) does not support this well at all yet |
| 14:08:07 | hearn: | 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:45 | hearn: | 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:52 | andytoshi: | i'll check it out if i can, i also have limited hours :) |
| 14:09:21 | hearn: | 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:11 | hearn: | i can imagine migrating lighthouse or even with a bit more work bitcoinj to it |
| 14:10:27 | hearn: | 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:10:28 | hearn: | :) |
| 14:11:51 | brisque: | oh look, more "secure 0conf transactions" bullshit. |
| 14:12:01 | brisque: | that'll work. |
| 14:12:17 | brisque: | er, wrong channel but still sorta on topic. |
| 14:14:31 | fluffypony: | brisque: you talking about Darkcoin "solving" instant transactions or something else? |
| 14:15:51 | brisque: | it's deeply off topic for this channel (meant for #bitcoin), but I was referencing this. https://archive.today/bxtZN |
| 14:16:08 | brisque: | (archive link because of annoying javascript) |
| 14:16:46 | brisque: | fluffypony: did you see that they actually made their "dark send" open source? |
| 14:17:21 | fluffypony: | yeah |
| 14:17:39 | fluffypony: | 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:47 | fluffypony: | and taken his audit as a thumbs up |
| 14:18:06 | brisque: | any audit is a good audit if you shill hard enough :) |
| 14:18:09 | hearn: | 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:47 | hearn: | incidentally the intro doc is really good |
| 14:20:56 | brisque: | 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:28 | fluffypony: | 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:53 | andytoshi: | hearn: roughly. you can define types with more precise access rules than mutex locks |
| 14:23:02 | brisque: | fluffypony: guess it works works until it doesn't. |
| 14:23:13 | andytoshi: | (and even mutexes are library types, there is almost no direct language support for this stuff) |
| 14:23:20 | hearn: | brisque: you could say the same of bitcoin ;) |
| 14:23:30 | hearn: | andytoshi: right. i think these abstractions are implementable in kotlin, but not enforceable. |
| 14:24:00 | hearn: | though automated "movement" would be tricky, probably not catchable at compile time. |
| 14:24:03 | andytoshi: | 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:11 | hearn: | sure |
| 14:24:15 | hearn: | i'm familiar with these |
| 14:24:32 | brisque: | 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:42 | hearn: | huh what? |
| 14:24:44 | fluffypony: | yup |
| 14:24:46 | hearn: | bitcoin is riddled with DoS issues |
| 14:24:55 | fluffypony: | quite incomparable, though, hearn |
| 14:25:01 | brisque: | like division by zero? ;) |
| 14:25:15 | fluffypony: | they have a handful of "masternodes" and every single full node connects to as many masternodes as possible |
| 14:25:37 | brisque: | 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:34 | fluffypony: | I raised that and it got cross-posted, brisque - https://darkcointalk.org/threads/interesting-question-reposted-from-bitcointalk-org.1999/ |
| 14:26:52 | fluffypony: | there's an official response in that thread |
| 14:27:14 | andytoshi: | i'm with hearn, would not be bragging about bitcoin's dos resistance :) |
| 14:27:47 | brisque: | better than connecting to masternodes, that's for sure. |
| 14:28:14 | brisque: | and I know better than most that bitcoin is slightly fragile |
| 14:28:35 | brisque: | I've reported big bugs and got responses from hearn in the same voice |
| 14:28:45 | brisque: | well, a bug to that mailing list. |
| 14:29:54 | brisque: | 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:54 | hearn: | clearing them out will take a lot of work :( + a somewhat professional audit |
| 14:30:39 | brisque: | 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:45 | fluffypony: | brisque: the point was to take them offline by having them null-routed so everything gets routed through masternodes you control |
| 14:30:56 | fluffypony: | the difference is that you have no financial incentive to do so |
| 14:31:01 | brisque: | fluffypony: yep, I got that. |
| 14:31:07 | fluffypony: | a masternode operator has a direct financial incentive to attack the next guy |
| 14:31:56 | fluffypony: | 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:00 | brisque: | 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:32:10 | fluffypony: | yup |
| 14:33:53 | brisque: | 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:11 | brisque: | 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:26 | Guest67746: | Guest67746 is now known as gmaxwell |
| 15:42:43 | gmaxwell: | 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:51 | gmaxwell: | 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:26 | starsoccer: | 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:37 | starsoccer: | then you dont have to keep the whole blockchain and just have a small amount of it |
| 16:02:38 | brisque: | not that exactly, but nodes which only keep a partial block history are totally possible. I'm running one right now. |
| 16:03:37 | starsoccer: | 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:04 | gmaxwell: | 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:22 | gmaxwell: | starsoccer: oh you cannot do that you you can just be fed bullshit when you connect. |
| 16:04:40 | gmaxwell: | The data is still needed for initilization but isn't needed after that. |
| 16:04:55 | starsoccer: | agreed, but why cant you use the typical 51% rule to figure out what is and isnt bs |
| 16:05:22 | starsoccer: | 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:35 | gmaxwell: | 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:12 | gmaxwell: | 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:13 | starsoccer: | im confused, what incentive do they have no not lie |
| 16:06:32 | starsoccer: | what stops such an agreement with all the big mining pools now? |
| 16:06:45 | gmaxwell: | starsoccer: miners are explicitly untrusted in bitcoin. The design of the protocol stops it. |
| 16:07:28 | gmaxwell: | 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:36 | starsoccer: | 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:37 | gmaxwell: | (and it would be precisely equal to not mining at all) |
| 16:07:50 | brisque: | starsoccer: nothing. |
| 16:08:03 | brisque: | this is why pools are particularly dangerous. |
| 16:08:08 | starsoccer: | so basically the nodes need some sort of incentive to not lie |
| 16:08:21 | gmaxwell: | 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:27 | jgarzik: | miners cannot create fake transactions or steal coins |
| 16:08:38 | jgarzik: | they can reorder transaction timeline, potentially removing transactions |
| 16:09:11 | starsoccer: | gotcha, and in theory they could create blocks in such a way as to avoid X coins ever being allowed to move |
| 16:09:21 | gmaxwell: | 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:41 | starsoccer: | Yes I understand that |
| 16:09:49 | starsoccer: | hmm just trying to think of a solution |
| 16:10:17 | gmaxwell: | There isn't a solution. Its the limitations of the system. |
| 16:10:45 | gmaxwell: | (you can come up with random things, they all open new attacks and have different and not clearly better tradeoffs) |
| 16:12:27 | starsoccer: | agreed, another idea I had, is as follows, |
| 16:14:07 | starsoccer: | 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:46 | brisque: | that doesn't work within the scope of outputs at all. |
| 16:15:43 | starsoccer: | 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:13 | andytoshi: | you cannot design cryptosystems "on a high level", the details are crucial |
| 16:16:21 | andytoshi: | and on a detailed level, what you are saying is gibberish |
| 16:16:35 | brisque: | each transaction contains the hash of it's previous. you can't eliminate "loops". |
| 16:16:35 | starsoccer: | lol |
| 16:16:36 | starsoccer: | okay |
| 16:16:57 | starsoccer: | sorry, like I said, just brainstorming |
| 16:17:06 | starsoccer: | well actully |
| 16:17:35 | starsoccer: | 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:43 | brisque: | that doesn't work either, have a read of the whitepaper and you'll find more reasons why not. |
| 16:18:58 | starsoccer: | kk |
| 16:26:13 | amiller_: | 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:46 | andytoshi: | been a busy day in academia, here is one about ringsigs http://eprint.iacr.org/2014/764 |
| 16:27:36 | fluffypony: | oh surae will like that last one |
| 16:28:08 | amiller_: | it's the day after eurocypt submission deadline :) |
| 16:28:15 | fluffypony: | lol |
| 16:28:21 | andytoshi: | ahh |
| 16:28:56 | fluffypony: | 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:20 | andytoshi: | behind cloudflare |
| 16:29:39 | fluffypony: | should be able to wget it |
| 16:29:51 | brisque: | is there a reason monero didn't ditch the horrible backdoor PoW? |
| 16:30:02 | fluffypony: | brisque: no time yet |
| 16:30:30 | fluffypony: | 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:44 | brisque: | right. so not an assertion it's "asic proof", just developer-time proof :) |
| 16:31:13 | jgarzik: | heh |
| 16:31:15 | fluffypony: | ah well it was never meant to be asic "proof", just to lower the performance gap between CPUs / GPUs / ASICs |
| 16:31:24 | fluffypony: | which it has done remarkably well |
| 16:31:45 | brisque: | just before I saw it being called "ASIC proof", which I don't believe in the least |
| 16:31:57 | fluffypony: | the tradeoff is that it makes verification stupidly expensive, so in that aspect it fails |
| 16:32:08 | fluffypony: | brisque: by idiots, yes :-P |
| 16:32:24 | amiller_: | 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:39 | andytoshi: | oh lol, i didn't see the "no crs" bit |
| 16:32:52 | andytoshi: | wow, that's exciting |
| 16:33:04 | fluffypony: | quite so |
| 16:33:08 | andytoshi: | will print and read then |
| 16:34:27 | brisque: | 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:50 | brisque: | I've done the numbers several times and they just come off as insane |
| 16:35:05 | fluffypony: | brisque: I'm certain someone has, although it would only run on exceedingly expensive FPGAs due |
| 16:35:12 | fluffypony: | but if you happened to have those lying around, then definitely |
| 16:36:11 | brisque: | 23MH/s on some moonmagic GPU giving you 1KH/s means there's 23,000 of them mining? |
| 16:36:13 | amiller_: | 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:50 | brisque: | I suppose a small botnet would account for the Monero hashrate entirely |
| 16:37:27 | fluffypony: | Claymore's miner does ~700h/s on a 290X, and an EC2 c3.8xlarge does around 1100h/s |
| 16:38:18 | brisque: | so 32,000 top end AMD graphics cards? no way. |
| 16:38:22 | fluffypony: | yup |
| 16:38:26 | fluffypony: | definitely a botnet or two in there |
| 16:40:30 | andytoshi: | amiller_: oh lol |
| 16:41:12 | amiller_: | 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:21 | brisque: | fluffypony: a big one, no doubt. |
| 16:59:32 | gmaxwell: | hm log in the accumulator size. |
| 17:00:55 | gmaxwell: | but by my figuring a 4e6 setsize would have signatures under 5kb. |
| 17:02:10 | gmaxwell: | 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:55 | gmaxwell: | ah, the catch is that its computationally unfriendly. |
| 17:31:03 | gmaxwell: | (size scales with log() but verification is O(n)) |
| 18:17:11 | andytoshi: | :P i would've said "value commitment (and potentially script commitment)" |
| 20:54:30 | zooko: | : |
| 20:54:40 | phantomcircuit: | gmaxwell, lol |
| 20:54:55 | phantomcircuit: | the memory in my laptop is failing... but inconsistently and apparently at random |
| 20:54:59 | phantomcircuit: | awesome |
| 20:55:14 | pigeons: | mine too :( |
| 20:55:29 | phantomcircuit: | i ran memtest in two separate runs |
| 20:55:35 | phantomcircuit: | immediate failure the first time |
| 20:55:39 | phantomcircuit: | no failures the second time |
| 20:55:45 | phantomcircuit: | :/ |
| 20:56:53 | gmaxwell: | might be crap in the socket. |
| 20:57:24 | phantomcircuit: | entirely plausible |
| 20:57:51 | phantomcircuit: | it's unpossible to remove them |
| 20:58:00 | phantomcircuit: | there's a heat pipe directly over the socket |
| 20:58:07 | phantomcircuit: | (which could also be the issue...) |
| 20:58:17 | fluffypony: | have you re-seated the RAM? |
| 20:58:21 | helo: | disassembling laptops is the best |
| 20:58:43 | helo: | (way to anger techie friends) |
| 20:59:16 | phantomcircuit: | darn |
| 20:59:33 | phantomcircuit: | cant get this python code to read fixed sized records at more than 3.5m/second |
| 21:00:00 | phantomcircuit: | well that is 210 MB/s |
| 21:00:04 | phantomcircuit: | i guess that's not *too* bad |
| 21:26:05 | home_jg: | home_jg is now known as jgarzik |