| 00:36:45 | nsh: | petertodd, did your blockchain run finish? |
| 00:47:05 | nsh: | yo ens |
| 00:47:38 | ens: | hi nsh |
| 00:48:03 | nsh: | (see next door) |
| 01:00:52 | andytoshi: | Luke-Jr: i'll be in austin on the 5 and 6, text me if you're downtown 5124504323. i'm not gonna register for the conference tho |
| 01:01:18 | Luke-Jr: | andytoshi: ⁈ |
| 01:01:20 | Luke-Jr: | why not |
| 01:02:00 | justanotheruser: | is pizzacoin off topic? |
| 01:02:33 | nsh: | not in the context of its notable innovations in cryptocurrency technology... |
| 01:03:12 | nsh: | (so, probably, yes) |
| 01:04:15 | andytoshi: | Luke-Jr: it's a hundred dollars and i have to be at school those days |
| 01:04:19 | justanotheruser: | Okay. So I have a concern with bitcoin 0.9 (and Bitcoin in general). With the new small fees, it will cost about $3k/day to DoS the network. This seems like a good way to dump and pump |
| 01:05:06 | Luke-Jr: | justanotheruser: off-topic here |
| 01:05:07 | justanotheruser: | Or if dump and pump doesn't make sense, just substitute it with manipulate the market |
| 01:05:21 | justanotheruser: | Luke-Jr: sorry, I'll post it in #bitcoin? |
| 01:05:31 | Luke-Jr: | #bitcoin-dev usually, but read ML first |
| 01:05:41 | justanotheruser: | Luke-Jr: ML? |
| 01:05:57 | Luke-Jr: | the mailing list |
| 01:06:19 | justanotheruser: | Luke-Jr: okay, I'll re-sub. |
| 01:14:38 | Luke-Jr: | andytoshi: if it was just $, I could probably get you in :/ |
| 01:21:28 | andytoshi: | Luke-Jr: how much notice would you need? i'm unsure of my schedule those days but there's a decent chance i'll be free after 2-3PM |
| 01:23:03 | Luke-Jr: | andytoshi: I don't know. |
| 01:28:24 | andytoshi: | no worries, i'll let you know when i know and we'll figure something out |
| 01:39:29 | austinhill: | austinhill has left #bitcoin-wizards |
| 02:04:53 | Luke-Jr: | Anyone want to moderate the altcoin panel in Texas? Or at least suggest some reasonable questions for them? |
| 02:14:29 | justanotheruser: | Luke-Jr: "Normally when a program is modified to have a different name or graphics it doesn't take off because of the support. Altcoins are an different because a clone with a changed name can be used as a speculative tool. Is there any thing that separates from being just a speculative tool?" |
| 02:14:56 | justanotheruser: | s/doesn't take off because of the support/doesn't take off because it has little reason to exist |
| 02:15:07 | justanotheruser: | s/are an different/are different |
| 02:19:38 | amiller: | does anyone collect stale blocks |
| 02:19:55 | amiller: | suppose i wanted to collect a set of stale valid blocks for innocent purposes like to have a museum, where could i go |
| 02:24:39 | amiller: | https://blockchain.info/orphaned-blocks i guess this is what i want |
| 02:41:15 | comboy: | MUSEUM OF ORPHANED BLOCKS "this one is from 2010, notice the nonce, very interesting exhibit, one of a kind" |
| 02:51:52 | comboy: | so if I'm checking correctly out of 84M txouts 2.6M have at least one (pkscript,value) duplicate, wow |
| 02:59:17 | andytoshi: | * andytoshi imagines amiller sculpting images of his orphan blocks for his museum |
| 03:00:12 | amiller: | we don't say "wow" here, dogecoin museum is next door |
| 03:00:35 | Luke-Jr: | * Luke-Jr says, "very sculpted" |
| 03:37:02 | c--O-O: | lol |
| 03:37:09 | c--O-O: | ;;ticker --market all |
| 03:37:14 | gribble: | MtGox BTCUSD last: 135.0, vol: 0.00000000 | Bitstamp BTCUSD last: 549.99, vol: 107799.32198253 | BTC-E BTCUSD last: 546.8, vol: 66052.24497 | Bitfinex BTCUSD last: 552.25, vol: 83792.50384978 | BTCChina BTCUSD last: 556.709296, vol: 26107.70000000 | Volume-weighted last average: 550.533044228 |
| 03:37:21 | c--O-O: | nice |
| 03:40:14 | nsh: | dullest armageddon ever |
| 03:45:01 | phantomcircuit: | gmaxwell, out of curiosity what do you suppose the lower bound is on hashes/joule |
| 03:45:33 | maaku: | phantomcircuit: physical lower bound? |
| 03:45:44 | phantomcircuit: | maaku, right |
| 03:45:47 | phantomcircuit: | like |
| 03:45:50 | maaku: | way, way, way lower |
| 03:46:12 | maaku: | i assume you mean reversible drexlarian computation? |
| 03:46:19 | phantomcircuit: | maaku, im thinking millions of time lower |
| 03:46:44 | phantomcircuit: | maaku, i dont even know what that is |
| 03:46:47 | phantomcircuit: | thus questions |
| 03:48:02 | tacotime_: | self-assembling nanoscale circuits? like those self-assembling DNA pieces that do stuff like solve the hamiltonian math problem? |
| 03:48:16 | tacotime_: | er path |
| 03:48:34 | phantomcircuit: | oh |
| 03:48:35 | phantomcircuit: | right |
| 03:48:52 | tacotime_: | That's what I was thinking but maybe maako meant something else |
| 03:49:10 | phantomcircuit: | maaku, i was thinking more like what the finite number of state changes was |
| 03:51:21 | andytoshi: | phantomcircuit: in the limit if you can compute irreversibly you can do infinity hashes/J. but that limit is as your hashtime goes to infinity....if you are talking normal (irreversible) computing then Landauer's principle applies https://en.wikipedia.org/wiki/Landauer%27s_principle |
| 03:51:45 | maaku: | phantomcircuit: what andytoshi said |
| 03:52:00 | maaku: | physical limits of computation are crazy small |
| 03:52:32 | phantomcircuit: | oh right |
| 03:52:46 | phantomcircuit: | yeah obviously im assuming an sha256d circuit is irreversible :) |
| 03:52:52 | phantomcircuit: | otherwise we might have issues |
| 03:53:59 | maaku: | phantomcircuit: different definition of irreversibility |
| 03:54:13 | tacotime_: | Now I'm reading the nature paper cited in that wiki heh |
| 03:54:21 | phantomcircuit: | maaku, ah ok then |
| 03:54:35 | phantomcircuit: | i should probably read more about this |
| 03:54:39 | phantomcircuit: | but who has the time |
| 03:54:48 | phantomcircuit: | * phantomcircuit looks around at everybody who does |
| 03:54:49 | phantomcircuit: | heh |
| 03:55:20 | maaku: | http://en.wikipedia.org/wiki/Reversible_computing |
| 03:55:32 | maaku: | nah, i was a physics major back in the day |
| 03:55:40 | maaku: | otherwise this stuff is pretty useless |
| 03:55:44 | tacotime_: | It's nice to see optical tweezers seeing (somewhat) practical uses |
| 03:56:09 | andytoshi: | if SHA256 takes 10000 bit changes, then by Landauer's principle (the equation on that wiki page) you can get roughly 3.5e16 hashes per joule. at 350W that is 1.2e19 hashes/sec. the BFL monarch is 350W and does 6e11 hashes/sec |
| 03:56:54 | andytoshi: | that's IMO amazingly close, if anyone has a better number than 10000 i'd be interested in it |
| 03:56:54 | maaku: | but most of those state changes could probably be made reversible |
| 03:59:03 | phantomcircuit: | maaku, ah i see, so the idea is that if the state goes from A->B->A then there has been no change in entropy |
| 03:59:26 | phantomcircuit: | interesting |
| 03:59:36 | maaku: | right |
| 03:59:52 | maaku: | only when you destructively change state need you expend energy |
| 03:59:56 | phantomcircuit: | however you're likely doubling the length of the path the electrons are running |
| 03:59:58 | tacotime_: | Is that like a chemical equilibrium? |
| 04:00:06 | phantomcircuit: | which means you're doublign resistive losses |
| 04:00:11 | phantomcircuit: | but i cant imagine that matters much |
| 04:00:13 | maaku: | but still, we're just talking an extra order of magnitude or two, on top of 1.2e19h/s :) |
| 04:00:27 | maaku: | phantomcircuit: superconductors |
| 04:00:39 | phantomcircuit: | maaku, oh right |
| 04:00:45 | maaku: | there's zero resistive losses at the limits of computation :) |
| 04:00:48 | phantomcircuit: | so you could be doing computation essentially for free |
| 04:01:03 | phantomcircuit: | or at least a few orders of magnitude cheaper than otherwise |
| 04:01:15 | phantomcircuit: | maaku, that's neat |
| 04:01:31 | maaku: | yes, only irreversible/destructive computation "counts", everything else is free |
| 04:02:00 | maaku: | modulo slight constant cost due to the fact that you can't actually reach absolute zero |
| 04:02:19 | copumpkin: | clearly just encode sha256 in a logic language and run it backwards >_> |
| 04:02:37 | maaku: | copumpkin: right, except sha256 is not a one-to-one function |
| 04:02:46 | copumpkin: | it doesn't need to be |
| 04:02:54 | maaku: | it does for reversible computation |
| 04:03:01 | copumpkin: | I'm saying something like prolog |
| 04:03:10 | copumpkin: | it'd probably take forever |
| 04:03:16 | [\\\]: | twss |
| 04:06:19 | phantomcircuit: | maaku, sha256 isn't 1:1 but smaller parts of it are right? |
| 04:06:23 | phantomcircuit: | i think so |
| 04:06:51 | copumpkin: | try encoding it in prolog! |
| 04:28:46 | justanotheruser: | justanotheruser is now known as just[dead] |
| 04:34:36 | just[dead]: | just[dead] is now known as justanotheruser |
| 04:38:43 | maaku: | phantomcircuit: yeah, it's been a while but in principle each step should be 1:1 |
| 04:38:53 | maaku: | you just throw away bits equal to the length of the message |
| 04:39:05 | maaku: | (rounded up to the next block size) |
| 04:39:37 | maaku: | irreversible transforms are actually very hard to analyze, so i would be very surprised if sha256 was constructed that way |
| 04:54:06 | phantomcircuit: | maaku, sha256 involves a bunch of xor operations |
| 04:54:19 | phantomcircuit: | im pretty sure that is irreversible without one of the inputs |
| 04:55:36 | copumpkin: | my suggestion doesn't need it to be reversible :P |
| 04:59:13 | maaku: | copumpkin: it is, trust me |
| 04:59:23 | copumpkin: | what? |
| 04:59:51 | justanotheruser: | justanotheruser is now known as just[dead] |
| 05:00:36 | maaku: | copumpkin: your emulation suggestion is orthogonal to the issue of reversibility |
| 05:01:13 | tacotime_: | tacotime_ is now known as tt_away |
| 05:01:22 | copumpkin: | I'm suggesting emulating it? |
| 05:01:24 | maaku: | phantomcircuit: do you throw away both the inputs? |
| 05:01:41 | maaku: | try encoding it in prolog! |
| 05:02:00 | copumpkin: | do you understand what I'm advocating? |
| 05:02:06 | maaku: | copumpkin: aparantly not |
| 05:02:16 | copumpkin: | have you used prolog? |
| 05:02:24 | maaku: | yes |
| 05:02:54 | maaku: | but how does it relate to reversible computation? |
| 05:02:56 | phantomcircuit: | maaku, yes you do |
| 05:03:28 | phantomcircuit: | http://en.wikipedia.org/wiki/SHA-2#Pseudocode |
| 05:04:54 | maaku: | yeah you're right |
| 05:05:12 | maaku: | so figure out how man xor computations, *32bits |
| 05:05:47 | maaku: | for which the input isn't reused |
| 05:06:21 | just[dead]: | just[dead] is now known as justanotheruser |
| 05:08:16 | phantomcircuit: | maaku, it's basically all of the computations |
| 05:11:16 | maaku: | phantomcircuit: not really, notice from the diagram how 6 of the 8 input registers simply shift to a new position |
| 05:11:20 | maaku: | those don't count against you |
| 05:11:23 | copumpkin: | maaku: you specify the relational form of your program and ask it to solve for a given output. You don't need 1:1, and it'll just show you an input that fits. Different logic languages do this differently, and I'm not actually claiming that it'll magically figure out how to invert sha256 in our lifetimes, but in principle I don't see why not |
| 05:11:31 | jcorgan: | jcorgan has left #bitcoin-wizards |
| 05:11:58 | maaku: | copumpkin: it can't and won't - there's information loss |
| 05:12:09 | maaku: | but that's a fundamentally different issue |
| 05:12:20 | maaku: | reversible computation is about using reversible physical processes for computation |
| 05:12:29 | copumpkin: | I know there's information loss :P |
| 05:12:31 | maaku: | very little to do with the actual algorithms |
| 05:12:51 | copumpkin: | I'm just saying it is specifying the entire equivalence class of inputs that produce a given output |
| 05:13:02 | copumpkin: | utterly incomputable, but still conceptually there |
| 05:13:33 | maaku: | no, not conceptually there at all |
| 05:13:50 | maaku: | when you reduce a 512 bit block to a 256 bit hash, you fundamentally eliminate 256 bits |
| 05:14:09 | maaku: | the reverse is a 1 : 2^256 mapping |
| 05:14:17 | copumpkin: | yes |
| 05:14:54 | copumpkin: | are you contradicting me? |
| 05:22:13 | justanotheruser: | justanotheruser is now known as just[dead] |
| 05:27:40 | copumpkin: | anyway, I'll take my impracticality elsewhere and get out of your discussion :P |
| 05:31:24 | just[dead]: | just[dead] is now known as justanotheruser |
| 05:49:36 | justanotheruser: | petertodd: when breaking coinbases consensus, did you just make complex tx and hope it would break it, or did you have a more complex method? |
| 05:55:09 | maaku: | maaku is now known as Guest62160 |
| 05:58:39 | ghtdak: | ghtdak has left #bitcoin-wizards |
| 06:04:03 | jgarzik: | amiller, I would be highly amused if you published the dakami thing on storify.com |
| 06:04:22 | amiller: | * amiller will figure out wtf that means and do it immediately |
| 06:09:42 | copumpkin: | jgarzik: yes please :) |
| 06:09:44 | copumpkin: | I don't have context |
| 06:23:11 | amiller: | it takes fucking 30 minutes to pg-down throuhg dan kaminsky's twitter timeline, i don't know any fatser way |
| 06:23:50 | amiller: | nope, it ends at sep 2013 |
| 06:24:18 | amiller: | bet i can scroll throuhg jeffs easier |
| 06:24:26 | copumpkin: | http://backtweets.com/search/?q=%40dakami |
| 06:24:27 | copumpkin: | perhaps? |
| 06:24:43 | copumpkin: | except it doesn't scroll automatically :) |
| 06:24:51 | copumpkin: | there are probably other third-party sites that archive them though |
| 06:25:40 | amiller: | ok well i'll race you, you try the third parties and i'll try twitter/jef |
| 06:26:37 | copumpkin: | what do I look for? |
| 06:26:50 | amiller: | first instance of the best? |
| 06:26:52 | copumpkin: | http://topsy.com/s?q=from%3Adakami%20%40jgarzik |
| 06:27:10 | amiller: | i basically have https://twitter.com/jgarzik/status/336210942717214720 |
| 06:29:25 | copumpkin: | another option is for jgarzik to request his tweet history archive |
| 06:29:33 | copumpkin: | :) |
| 06:32:19 | copumpkin: | amiller: https://twitter.com/jgarzik/status/335877664030212096 |
| 06:33:09 | amiller: | yeah ok i got all those |
| 06:33:28 | amiller: | this is coming along just fine, i'm making it look nice like a celebrity gossip article with lots of bold phrases and hhyperinlks |
| 06:33:34 | copumpkin: | fun |
| 06:33:44 | amiller: | i drank just enough scotch for this task tonight, i wasn't going to get anything else done anyway |
| 06:34:46 | copumpkin: | * copumpkin goes to sleep :) |
| 06:34:54 | jgarzik: | heh |
| 06:47:06 | austinhill: | playing host to tons of #bitcoin-wizards sounds fund until they are all on your couch tired & screaming about mt. god killing their day |
| 06:48:20 | austinhill: | actually its still fun - just complicated ;) |
| 06:53:52 | Luke-Jr: | austinhill: lol |
| 06:54:33 | amiller: | copumpkin, here you go https://twitter.com/socrates1024/status/438566986835312640 |
| 07:21:18 | justanotheruser: | justanotheruser is now known as just[dead] |
| 09:36:13 | sipa: | austinhill: haha |
| 11:00:33 | qwertyoruiop_: | qwertyoruiop_ is now known as qwertyoruiop |
| 13:28:28 | jgarzik: | jgarzik is now known as home_jg |
| 14:09:55 | stonecoldpat: | guys, was mtgox malleability issue that they were accepted transactions too quickly? (that later became invalid) |
| 14:18:43 | gmaxwell: | No. |
| 14:20:53 | gmaxwell: | stonecoldpat: To the best of my understanding their 'malleability issue', wasn't really one— they were reissuing transactions without conflicting the originals, making it possible for both to go through. This is unsafe— malleabilitys role, apparently, was that they'd check to see if the original had gone through— still unsafe since it could go through at the same time or later— and wouldn't detect mutated versions of the ... |
| 14:21:00 | gmaxwell: | ... transaction. |
| 14:21:58 | gmaxwell: | However, since they've never actually pointed out any of the theft transactions, it's hard to be sure how accurate that is. The claimed losses don't really plausably follow from that pattern. |
| 14:23:27 | gmaxwell: | If they really did lose that much coin then I would think it likely that there were additional vectors. |
| 14:27:45 | stonecoldpat: | i understand, so if mtgox issued t1, then later issued t2 (as t1 has got held up), t2 never invalidated t1, and so both would go through. |
| 14:28:06 | stonecoldpat: | to loose the coins they did, that would need to have happened for a long time :/ so it cant be the sole reason |
| 14:31:03 | wumpus: | if so many coins were stolen it must be abused on a pretty large scale, it's strange that we don't hear anyone gloating who abused this, even anonymously |
| 14:32:04 | gmaxwell: | stonecoldpat: I can't say that it couldn't be the sole reason. E.g. if someone got an account that could make 10k in withdraws per day and they constantly cycled funds through it, they potentially could trigger this hundreds of times over many many months by automating the attack. It's probably possible. |
| 14:32:22 | gmaxwell: | Almost all great disasters involve layered faults. |
| 14:32:50 | gmaxwell: | Though it seems likely to me if the claims are correct there probably are other reasons. |
| 14:34:06 | gmaxwell: | ... and if the situation was really bad enough that they could have huge ongoing losses without noticing, then who knows if they even know all the causative issues. |
| 14:35:05 | wumpus: | so one person/party discovered this and abused it over a long time, syphoning all of mtgox's coins away without being discovered by anyone... somehow it just doesn't add up to me |
| 14:35:57 | wumpus: | if these are due to duplicated transactions: he has to have withdrawn half of mtgox's total coins to get all of them |
| 14:36:45 | comboy: | I did a histogram of number of duplicates of (pkscript,value) pairs over distance in blocks between them |
| 14:36:49 | wumpus: | in volume, at least, of course they can have bounced the same coins from/to mtgox all the time... but come on |
| 14:37:03 | comboy: | and there is a clear bump around 150 blocks, but that's probably some daily payments |
| 14:38:04 | comboy: | if mtgox would be reissuing transactions automagically, I would expect not a smooth bump but some sharp edge at some block diff (presumably associated with if tx not in block after X blocks then...) |
| 14:39:29 | stonecoldpat: | i suppose the bump / sharp edge would only happen if there were a lot of duplicates? did you check the amount of coins being transferred per duplicate? |
| 14:39:52 | stonecoldpat: | in your 150 block bump |
| 14:40:19 | stonecoldpat: | as wumpus mentioned, it would require access to at least half of mtgox's coins at some point |
| 14:40:40 | stonecoldpat: | close to half* |
| 14:42:02 | gmaxwell: | comboy: it's hard to analyize the data, mtgox had daily withdraw limits on accounts... |
| 14:42:24 | comboy: | yeah I have it over value too, but it seems more noisy because probably exchanges cold storage moves and whales, one sec |
| 14:42:30 | gmaxwell: | I can point you to addresses that had recieved >10k btc in repeated payments from mtgox, but it looked like they were just grinding against daily limits. |
| 14:43:30 | comboy: | gmaxwell: agreed, but if it would be automated I would expect some bump at specific value |
| 14:44:18 | comboy: | I just started doing this after waking up not long ago so I don't want to share some bs data which it may be, but this is hist over count of duplicates, not value: http://i.imgur.com/Y3M7OiP.png |
| 14:45:11 | comboy: | (I skipped values under 0.01 btc, total number of dups 2.6M so it would be under 26k anyway) |
| 14:45:36 | gmaxwell: | if the attack had low success rate— which I'd expect it to if it were based on reissues— you'd expect the traffic to mostly reflect the withdraw limits. |
| 14:46:22 | comboy: | yeah that's true, I don't know how it could be approached to filter it better |
| 14:46:32 | epscy: | https://github.com/olalonde/blind-solvency-proof |
| 14:46:32 | gmaxwell: | interesting graph. I wonder if you could plot that graph for tx sent by addresses in my mtgox address list (which I'd guess is at best 1/3rd of their addresses) vs all. |
| 14:46:41 | epscy: | that looks cool |
| 14:47:58 | comboy: | gmaxwell: just give me list of addrs (hash160 prefered) |
| 14:49:16 | stonecoldpat: | also comboy, is that duplicates in the same block? or is it duplicates found within a certain radius of blocks? (so two similar transactions found within the past 10 blocks)? (duplicate criteria is value of transaction i imagine?) |
| 14:49:16 | gmaxwell: | https://people.xiph.org/~greg/goxaddrs.txt.gz (sorry, base58... I had scriptpubkeys at first and everone complained, sadily I overwrote them after converting) |
| 14:49:46 | gmaxwell: | stonecoldpat: the graph is showing the 'radius' effectively, if I understand it. |
| 14:49:59 | comboy: | yes, radius is on x axis |
| 14:50:28 | comboy: | stonecoldpat: duplicate criteria pkscript matches and value matches |
| 14:52:32 | gmaxwell: | comboy: what is the total value duplicated? |
| 14:53:30 | comboy: | didn't even check but between radius 100 and 220 it's 3.7M |
| 14:53:52 | gmaxwell: | yea, figured. |
| 14:54:15 | gmaxwell: | mtgox txn could be filtered futher with fee policy, once they made their high fees mandatory you can exclude other txn... not sure how useful this would be since it wasn't made mandatory all that long ago. |
| 14:54:55 | gmaxwell: | well— I'm relatively confident that all hits on that address list are mtgox, but I don't know how to match more than that beyond fees. |
| 14:56:14 | epscy: | gmaxwell: thoughts on this? www.reddit.com/r/Bitcoin/comments/1yyrkz/well_technically_speaking_its_not_lost_just_yet/ |
| 14:57:39 | gmaxwell: | epscy: very doubtful. |
| 14:58:19 | gmaxwell: | it's a pretty longshot extrapolation from a minor comment. |
| 14:58:37 | epscy: | that was my take too |
| 14:58:51 | epscy: | think people are grasping at straws |
| 14:59:55 | gmaxwell: | I think it makes a nice joke, not a serious theory. The comment was more like 'not lost just temp unavailable' ... 'because I plan on saving the ship and paying everyone back.' |
| 15:01:04 | pigeons: | i wish instead of asking how accurate the document was they asked him how accurate the number was |
| 15:01:30 | gmaxwell: | I suspect he wouldn't have answered that |
| 15:02:05 | pigeons: | likely they dont know how much they lost |
| 15:03:22 | epscy: | pigeons: yup, my read is that the updates are so sparse because tux doesn't know yet what will happen next |
| 15:04:22 | nly: | A lot of angry people are going to persue legal action through whatever means they have at their disposal |
| 15:04:25 | nly: | just a guess |
| 15:05:03 | pigeons: | cant get blood from a turnip |
| 15:18:18 | ens_: | ens_ is now known as ens |
| 15:21:16 | comboy: | I need to go afk for a at least 2h, running query against these gox addrs will take me a moment anyway, if anybody wants to play with just txouts here's the list of (pkscript,value) duplicates with value > 0.01 http://tesuji.pl/dupsmall2.csv.bz2 (~100M, value, block height, hash160) |
| 15:23:22 | gmaxwell: | reddit post: "I have trained my ferret to memorize a 256 character numeric string. On command he'll take a pen and scribble it down on a piece of paper. Is this a safe way to store bitcoins?" |
| 15:23:49 | sipa: | what if your ferret dies? |
| 15:26:28 | nanotube: | obviously you must train multiple ferrets and store them in geographically disparate locations. |
| 15:26:42 | nanotube: | and have them teach the string to their offspring upon reproduction |
| 15:27:07 | sipa: | i think you should apply shamir secret sharing on the ferrets |
| 15:27:35 | gmaxwell: | Mustelidae signature transactions. |
| 15:37:42 | sl01: | so what's the conensus here, did they really lose all but 2k BTC to txmal ? |
| 15:38:04 | sipa: | sl01: not here, please |
| 15:55:48 | shesek: | what services/softwares do you know that uses multi-signature transactions? |
| 15:56:25 | jgarzik: | shesek, few if any of the "big guys" |
| 15:56:42 | jgarzik: | shesek, BitPay does internally. blockchain.info offers (used to offer?) a manual multi-sig builder. |
| 15:56:57 | jgarzik: | A couple startups are just starting to roll over services. |
| 15:57:01 | shesek: | used to, its gone for a while now |
| 15:57:12 | shesek: | anything operational that you know of? |
| 15:57:32 | shesek: | other than using it internally to store funds, something that exposes interesting functionality to users in some way |
| 15:57:39 | jgarzik: | shesek, some operational startups |
| 15:57:50 | jgarzik: | don't know the site addresses off the top of my head |
| 15:57:52 | sl01: | gmaxwell: regarding 10k daily withdrawal limit, at max verification level you could withdraw 100k at a time |
| 15:58:06 | shesek: | jgarzik, do you remember what they're doing with it? |
| 15:58:11 | shesek: | perhaps I could look it up |
| 16:04:16 | pigeons: | shesek: https://www.bitrated.com/ |
| 16:04:35 | shesek: | pigeons, yeah, heh, that one is mine :) |
| 16:04:39 | pigeons: | heh |
| 16:04:43 | shesek: | I'm looking for some other examples |
| 16:05:11 | shesek: | I'm doing a talk on multi-signature, seems odd to only mention my own thing as an example... |
| 16:06:52 | pigeons: | i havent checked out that i2p market that suppoosedly uses multisig |
| 16:07:25 | pigeons: | not the best publicity for your talk |
| 16:09:13 | shesek: | yeah... and it kinda sucks too |
| 16:09:22 | shesek: | they ask you for your private key and sign server-side |
| 16:09:37 | shesek: | which kinda defeats the purpose |
| 16:09:45 | kanzure: | do they realize that they sound like dorks asking for that? |
| 16:09:53 | kanzure: | or is it intentional malice |
| 16:10:13 | stonecoldpat: | gmaxwell: i was looking for your idea about a merkle tree to verify exchange balances, is there a link available? |
| 16:10:52 | kanzure: | stonecoldpat: well, ther'es https://github.com/olalonde/blind-solvency-proof |
| 16:11:03 | kanzure: | stonecoldpat: and https://iwilcox.me.uk/v/nofrac |
| 16:13:29 | stonecoldpat: | ok gonna have a read, but i was thinking, may be possible to use something like commitcoin in the process too, store in the transaction its origion and when the coins are moved, attach commitment to new transaction, in such a way where the real owner could use a 'password' to verify the commitment, but it does not reveal all owners |
| 16:14:17 | stonecoldpat: | so as long as exchange publish all their transactions, a simple script could search over valid outputs and check if its still there |
| 16:23:30 | epscy: | sl01: 100k?, this could explain why gox lost so much in a short amount of time |
| 16:24:20 | gmaxwell: | unless its technical and helps us advance the ecosystem the gox stuff really should move elsewhere (uh, where I don't have a suggestion, mtgox-chat is a wall of noise) |
| 16:28:12 | stonecoldpat: | having just sat in mtgox-chat for 2 minutes, i think the gox stuff fits in there perfectly to add more noise to it |
| 16:30:13 | mus1cb0x: | what is a proper daily withdrawl limit for an exchange to hvae? |
| 16:30:17 | mus1cb0x: | have* |
| 16:32:03 | epscy: | #mtgox-signal is probably the best place |
| 16:32:33 | epscy: | mus1cb0x: perhaps a percentage of your hot wallet? |
| 16:32:49 | epscy: | with your hot wallet being a percentage of your total coins? |
| 16:33:12 | andytoshi: | please, this is a business q, let's keep -wizards to research |
| 16:33:14 | mus1cb0x: | i was thinking a % of the exchange's volume entotale, but your idea is probably better |
| 16:33:20 | sl01: | epscy: yep, required the apostillized stuff and then manually requesting that limit |
| 16:33:24 | mus1cb0x: | it is? |
| 16:33:43 | mus1cb0x: | i mean it is a business question i guess, but... i don't even know how to respond |
| 16:33:58 | mus1cb0x: | well nvm then |
| 16:34:04 | epscy: | yeah this is a bit offtopic, i recommend #mtgox-signal |
| 16:34:07 | shesek: | gmaxwell, any chance you're aware of someone using multi signature in an active service/software? |
| 16:34:13 | mus1cb0x: | mus1cb0x has left #bitcoin-wizards |
| 16:34:19 | shesek: | other than me, that is :P |
| 16:38:57 | gmaxwell: | shesek: there was someone talking about one of those underground markets doing something in that space, but I dunno anything about it. There have been a lot more multisig on the network recently... but for all I know it's all you. |
| 16:41:43 | flotsamuel: | Yea, darknet markets considering it as an alternative to PHP developers trying to secure an escrow service. |
| 16:47:22 | shesek: | gmaxwell, there's one black marketplace that uses it |
| 16:48:00 | shesek: | but it kinda sucks... I saw some screenshots of it, they ask users to provide their private key to release the funds and sign it server-side :-\ |
| 16:48:13 | gmaxwell: | ::sigh:: |
| 16:48:42 | kanzure: | gmaxwell: it would be nice if it was a property of private keys to somehow make users feel uneasy or suspicious when stuff like that is requested of them |
| 16:48:55 | kanzure: | i suppose the word private is not strong enough |
| 16:49:05 | gmaxwell: | kanzure: I was about to point that out... :P |
| 16:49:18 | kanzure: | i will turn off my telepathy helmet |
| 16:49:28 | gmaxwell: | Finally a use for brain wallets, require users to include embarassing personal information in their private keys. |
| 16:49:58 | wumpus: | also very stealthy if a black market is the only one using such transactions :) |
| 16:51:20 | andytoshi: | it would be nice if we had schnorr sigs, split-key signatures are so easy (and innoculous looking) :( |
| 16:51:23 | kanzure: | maybe just annoying messages around all private keys. WARNING. CRITICAL. |
| 16:51:37 | gmaxwell: | I'd hoped that things like trezor would always be used in a multisig capacity so you didn't have to worry about the device leaking your keys in a covert channel, but sadly they didn't see value in going that route. |
| 16:51:42 | andytoshi: | kanzure: that's not a bad idea, if the import/export format had a bunch of required noise in it |
| 16:51:57 | andytoshi: | ***DO-NOT-SHARE***5abcdefg123456789 |
| 16:52:12 | kanzure: | that would be ignored |
| 16:52:31 | gmaxwell: | TOP-SECRET-UMBRA-XRAY-I-LIKE-GAY-PORN-IOWEIRWR*U@#$(@URWORUWOQU |
| 16:52:41 | andytoshi: | kanzure: not if you couldn't import keys without it, and make the casing depend on the private key so that it's hard to recreate |
| 16:52:47 | gmaxwell: | user factors are hard. |
| 16:53:07 | kanzure: | oh, so make the armor mandatory. hrm. |
| 16:53:21 | kanzure: | well, it would still be ignored |
| 16:53:49 | gmaxwell: | a lot of the problem reduces to "If I didn't trust this site, I wouldn't be using it." |
| 16:54:09 | kanzure: | "trust is good for you" is the common response i get |
| 16:54:31 | kanzure: | there are many advantages to not needing trust that don't seem to be easy to communicate |
| 16:55:02 | gmaxwell: | trusting and not needing to trust are also not mutually exclusive. Verification doesn't mean distrust. |
| 16:55:11 | gmaxwell: | But that seems hard to express to people. |
| 16:55:33 | kanzure: | which part is the verification in the "paste your private keys here plz" example? |
| 16:55:33 | sl01: | gmaxwell: what format was the goxaddrs.txt in ? |
| 16:55:36 | gmaxwell: | Also a lot of service operators instantly get offended when you suggest their service should be provable. |
| 16:55:54 | gmaxwell: | sl01: gziped text of base58 encoded bitcoin addresses one per line. |
| 16:56:28 | sl01: | ah weird, i had to double unzip it thx |
| 16:58:01 | nly: | I discovered today I've been using -j and -z with tar for years unnecessarily... if the file extension is right it detects it automatically :( |
| 16:58:08 | nly: | well not today, a few days ago |
| 16:58:58 | nly: | come to think of it, it probably doesn't even depend on the extension |
| 17:01:56 | rastapopuloto: | rastapopuloto has left #bitcoin-wizards |
| 17:10:10 | nly: | nly is now known as HM2 |
| 17:14:00 | sl01: | gmaxwell: what's the provenance of those mtgox addresses? |
| 17:14:26 | flotsamuel: | flotsamuel is now known as Dizzle |
| 17:14:34 | just[dead]: | just[dead] is now known as justanotheruser |
| 17:21:55 | home_jg: | home_jg is now known as jgarzik |
| 17:24:53 | gmaxwell: | sl01: they're extracted from the assumption that if a TX has signatures for addresses A, B, C and B is known as an mtgox address A and C are too, which isn't a safe general assumption but it matches mtgox's operating practices to the best of my knoweldge. |
| 17:25:09 | gmaxwell: | sl01: It was also spot verified by using MTGox's api. |
| 17:25:32 | gmaxwell: | About half the addresses return true as a customer deposit address— which is about what you'd expect, when considering change. |
| 17:27:27 | sl01: | gmaxwell: thx |
| 17:32:31 | phantomcircuit: | gmaxwell, that's a silly thing to get offended about |
| 17:32:33 | phantomcircuit: | sooo |
| 17:32:37 | phantomcircuit: | gmaxwell, id be interested in doing that for intersango |
| 17:32:39 | phantomcircuit: | maybe people would leave me alone afterwards |
| 17:41:22 | justanotheruser: | justanotheruser is now known as just[dead] |
| 17:42:22 | just[dead]: | just[dead] is now known as justanotheruser |
| 17:46:59 | austinhill: | adam3us and I having a breakfast conversation about the incompentence of BTC |
| 17:47:41 | jgarzik: | heh |
| 17:48:29 | jgarzik: | austinhill, It is my opinion that BTC is too easy to use, if you are a programmer. So seductively easy to transfer money, that you do not think about the wider difficulties and attack landscape involved in securing millions in value. |
| 17:48:55 | jgarzik: | The more value you secure, the more bad actors are attracted, the more important security becomes. |
| 17:49:49 | jgarzik: | Also, "first generation" bitcoin attracted [lovingly!!] naive libertarians and crypto-anarchists who like the theoretical, pure idea of anonymous digital money |
| 17:50:33 | jgarzik: | People have to re-learn the basics of money and trust |
| 17:50:35 | jgarzik: | all over again |
| 17:50:50 | jgarzik: | bitcoin community is slowly re-learning lessons known hundreds of years ago |
| 17:54:38 | wumpus: | incompetence of BTC in comparison to what? |
| 17:54:41 | austinhill: | jgarzik: Yeah btc is too easy to use … the incompentence of Mt gox shows us all that |
| 17:54:59 | austinhill: | sorry meant incompentence of Mt Gox not btc |
| 17:55:20 | wumpus: | it's baffling indeed |
| 17:56:16 | gmaxwell: | I'm concerned the details will never be made public, ... which would be sad because we need to learn from their mistakes. |
| 17:56:27 | gmaxwell: | It would be foolish to assume other people couldn't make the same ones. |
| 17:57:20 | jgarzik: | Prediction: details will never be made public |
| 17:57:29 | Persopolis: | do you still hold the belief that gox was incompetence rather than fraudulant? |
| 17:57:40 | jgarzik: | I think Mark tried to do it all himself |
| 17:57:45 | helo: | yeah ^ |
| 17:57:49 | gmaxwell: | I agree with that prediction, though perhaps more will be made public just to defend against claims of outright fraud. |
| 17:57:52 | phantomcircuit: | gmaxwell, im pretty sure i have a complete picture of what went wrong |
| 17:58:17 | phantomcircuit: | i believe their client failed to mark transactions which they had generated as unspendable |
| 17:58:31 | phantomcircuit: | which meant they had what looked like unspent outputs in an amount much larger than they did |
| 17:58:54 | phantomcircuit: | im pretty sure all of their auditing procedures were proper and everything, but their client was simply giving them the wrong balance |
| 17:59:07 | austinhill: | if we solved transaction scalability and had a better a blockchain we could improve the situation |
| 17:59:07 | gmaxwell: | considering the transfer limits, it's not clear to me how the losses could have been so large considering that. Or how they could have simultaniously kept refilling from cold while thinking they had the funds in hot |
| 17:59:32 | phantomcircuit: | gmaxwell, that last part is something i haven't been able to figure out |
| 17:59:44 | phantomcircuit: | and possibly is something we will never know |
| 17:59:55 | phantomcircuit: | because im sure it will be a pointed issue in some form of litigation |
| 17:59:58 | Luke-Jr: | it sounds like the wallet probably semi-automated transfers from the cold wallet, just telling people when it needed access |
| 18:00:14 | gmaxwell: | austinhill: I don't agree with this idea that you've repeated several times that all the exchanges transactions could be in the blockchain. I don't think it's reasonable, because of privacy and scaling— no matter how well you make things scale. Nor does it cover their USD side obligations so it's still incomplete. |
| 18:00:29 | jgarzik: | Yah, hot wallet top-off becomes a routine task, even though human intervention is required |
| 18:00:34 | jgarzik: | no inspection into "why" |
| 18:01:04 | gmaxwell: | Right but why would the system ask if it thought it had coins? ... and then wouldn't the hot balance claim 700k coins? |
| 18:01:16 | gmaxwell: | I propose a theory: there was no cold wallet. |
| 18:01:20 | Luke-Jr: | gmaxwell: hmm, true |
| 18:01:21 | jgarzik: | austinhill: agree w/ gmaxwell. Off-chain transactions systems are to be encouraged, even. |
| 18:01:31 | jgarzik: | perhaps will be numerous, in the future |
| 18:02:08 | Persopolis: | i find it incomprehinsible that something of this scale could have happened in a short period of time, and if it didn't how they could not notice |
| 18:02:09 | jgarzik: | gmaxwell, I'd bet at least there were separate wallets |
| 18:02:19 | jgarzik: | with the one being less hot |
| 18:02:24 | gmaxwell: | austinhill: mtgox's peak transaction rates I think hit many hundreds of transactions per second. Thats not reasonable in a global consensus system. They could have some kind of audiable system, indeed... but I can't see getting that into the one blockchain to rule them all. |
| 18:02:28 | Luke-Jr: | who was it that was promoting off-chain transactions in San Jose again? <.< |
| 18:02:50 | phantomcircuit: | Persopolis, the time period is more likely months to years |
| 18:02:57 | jgarzik: | Persopolis, period of time is years |
| 18:03:10 | jgarzik: | Luke-Jr, :) |
| 18:03:13 | gmaxwell: | well we can give a minumum bound on the time using comboy's data extraction.. |
| 18:03:36 | Persopolis: | so how could it be possible that they don't notice that they were losing money |
| 18:04:05 | helo: | Persopolis: mark was the only one in a position to notice, and he assumed it wasn't possible |
| 18:04:14 | phantomcircuit: | Persopolis, like i said, their client was likely lying to them about it's balance |
| 18:04:25 | adam3us: | gmaxwell: trustless exchange implies atomic swap of colored or tagged usdcoins for bitcoins. order match on server, or direct. scaling is the problem. but for example aside from gox you said u did not trust your coins to exchanges. therefore you already used it in this pattern. deposit, trade, withdraw. all your btc transactions were on blockchain. |
| 18:04:29 | helo: | so didn't implement or use rigorous auditing |
| 18:05:06 | gmaxwell: | adam3us: but I wasn't one of the thousands of parties providing constant liquidity to the market. |
| 18:05:21 | Persopolis: | phantomcircuit - and he never checked his actual wallets in all that period? |
| 18:05:34 | phantomcircuit: | Persopolis, his actual wallet was their client |
| 18:05:52 | phantomcircuit: | a wallet is merely a collection of unspent transaction outputs and private keys |
| 18:06:16 | phantomcircuit: | i believe their client was simply failing to mark unspent transaction outputs as unspendable |
| 18:06:17 | jgarzik: | a wallet is a keyring |
| 18:06:20 | austinhill: | +1 |
| 18:06:20 | austinhill: | adam3usrustless exchange implies atomic swap of colored or tagged usdcoins for bitcoins. order match on server, or direct. scaling is the problem. but for example aside from gox you said u did not trust your coins to exchanges. therefore you already used it in this pattern. deposit, trade, withdraw. all your btc transactions were on blockchain. |
| 18:06:23 | Luke-Jr: | * Luke-Jr wonders if n00bs are starting to flood -wizards :| |
| 18:06:30 | adam3us: | gmaxwell: u do have the counter party risk of the usd.. but the issuing key can be offline |
| 18:06:39 | phantomcircuit: | jgarzik, it's not very useful w/o a list of utxo to spend though :P |
| 18:06:45 | gmaxwell: | adam3us: even there I seldom sold a bunch of coin all in a single transaction, and the trades often went to a half dozen different people (just based on the repeated entries in my sale data at different prices) |
| 18:07:04 | adam3us: | gmaxwell: it seems to me much of that "liquidity' is wash trade and other forms of blatant bot / price manipulation which is illegal in most jurisdictions |
| 18:07:08 | jgarzik: | phantomcircuit, agree, but that data may be obtained/derived as needed |
| 18:07:14 | jgarzik: | phantomcircuit, it's secondary |
| 18:07:27 | phantomcircuit: | austinhill, that's great and all except that there is no real liquidity in such a system, you're effectively arguing for an RFQ system vs CLOB |
| 18:07:30 | adam3us: | gmaxwell: true, but partly because of this ongoing washtrade... just look at the tickers |
| 18:07:44 | phantomcircuit: | localbitcoins.com and friends are RFQ |
| 18:07:54 | phantomcircuit: | there is a reason that there is far more liquidity on the CLOB exchanges |
| 18:07:55 | jgarzik: | CLOB? |
| 18:07:56 | adam3us: | gmaxwell: but overall... yes the scalability issue is a killer. |
| 18:08:03 | phantomcircuit: | jgarzik, central limit order book |
| 18:08:12 | Persopolis: | so would transaction not start failing when his client's view of unspent outputs mismatched that of the network? |
| 18:08:29 | Luke-Jr: | Persopolis: they DID |
| 18:09:11 | phantomcircuit: | jgarzik, most of the us securities markets actually operate on a request for quote system, which is why high frequency trading is so prevalent, they can literally make money with zero meaningful logic simply by front running other participants |
| 18:09:22 | phantomcircuit: | with a CLOB HFT is essentially pointless |
| 18:09:56 | adam3us: | again on the gox incompetence: how could they not just spot check their cold outputs with different clients over different channels. I do that. |
| 18:10:10 | Luke-Jr: | uh, how? |
| 18:10:18 | Luke-Jr: | wallets are completely unportable right now |
| 18:10:56 | phantomcircuit: | Luke-Jr, well.... he could have checked his db against the reference client with getrawtransaction |
| 18:10:56 | jgarzik: | bah. nothing is "completely unportable" ;p |
| 18:11:20 | phantomcircuit: | and then only counted confirmed stuff as spent/spendable |
| 18:11:48 | phantomcircuit: | but to be fair the reference client has a similar but substantially less dangerous issue around reporting for zero confirmations |
| 18:11:55 | Luke-Jr: | phantomcircuit: getrawtransaction doesn't report a spent flag |
| 18:12:11 | phantomcircuit: | the principle difference being that he wasn't marking them as unspendable |
| 18:13:06 | phantomcircuit: | Luke-Jr, no but it does fail when the transaction is no longer spendable because of a conflict |
| 18:13:18 | phantomcircuit: | (yeah yeah relying on unintended behaviour etc etc) |
| 18:13:18 | adam3us: | Luke-Jr: but just like paste a list of wallet addresss though wget bc.i/ | awk |
| 18:13:35 | phantomcircuit: | adam3us, pretttty sure that wouldn't have worked |
| 18:13:38 | adam3us: | Luke-Jr: i mean the Karpeles guy is nominally a programmer |
| 18:13:39 | phantomcircuit: | they had lots of addresses |
| 18:13:45 | adam3us: | phantomcircuit: so? |
| 18:13:50 | phantomcircuit: | which is why they had their own client to begin with |
| 18:14:02 | phantomcircuit: | adam3us, millions of addresses in fact |
| 18:14:12 | phantomcircuit: | something tells me bc.i would have cried foul |
| 18:14:15 | adam3us: | phantomcircuit: so? |
| 18:14:40 | Luke-Jr: | or asked for payment :P |
| 18:15:00 | gmaxwell: | bc.i often has junk data, plus they block you after you pull a few thousand in a short time (apparently) unless you use the api key they leaked in the shared send sourcecode. |
| 18:15:01 | wumpus: | or using a local block chain and an address index |
| 18:15:27 | Luke-Jr: | probably a significant part of the problem was that Mark didn't fix the problem with immature coins when he learned about it |
| 18:15:34 | phantomcircuit: | wumpus, which is probably a more correct way of doing it |
| 18:15:38 | gmaxwell: | A screenshot someone sent me of some of my hijinx: https://people.xiph.org/~greg/21mbtc.png |
| 18:15:39 | Luke-Jr: | instead, he just decided to try to avoid it |
| 18:15:55 | Luke-Jr: | which means when transactions failed occasionally, he just assumed it was that issue |
| 18:16:01 | Luke-Jr: | IMO |
| 18:16:22 | phantomcircuit: | Luke-Jr, if their wallet code handled it correctly |
| 18:16:28 | phantomcircuit: | then those issues were just an annoyance |
| 18:16:38 | gmaxwell: | I think MT thought it was just normal for txn to fail or not go through... thus the reissuing, thus the higher and higher fees. |
| 18:16:48 | phantomcircuit: | the problem is that they gave an attacker a big giant window |
| 18:17:13 | Luke-Jr: | I don't consider transparency part of the problem :x |
| 18:17:22 | adam3us: | surely there were some accidental ones or honest researchers who told them - hey you paid me twice |
| 18:17:33 | gmaxwell: | As I keep pointing out, if you look at the history of industrial disaster there are always layered faults... |
| 18:17:53 | phantomcircuit: | adam3us, there actually were a handful of reports in #mtgox over the past year |
| 18:17:54 | Luke-Jr: | adam3us: yeah, that's one of the things I wonder about.. |
| 18:18:00 | phantomcircuit: | i fielded at least 3 of them |
| 18:18:05 | Persopolis: | I guess we've all heard of fiat based businesses run worse than that, no reason the same couldn't happen on btc |
| 18:18:10 | phantomcircuit: | but none of them seemed particularly credible |
| 18:18:13 | gmaxwell: | adam3us: I heard from someone recently who had been paid twice via USD and reported it and basically had to fight with mtgox to fix it. |
| 18:18:13 | phantomcircuit: | :( |
| 18:18:17 | phantomcircuit: | they do now |
| 18:18:33 | gmaxwell: | people have reported doubled btc payments, not many, not sure if they were correct or whatever... but there were reports. |
| 18:18:48 | phantomcircuit: | however 2-3 people over the course of a year is hardly something that would trigger a panic for me |
| 18:19:00 | adam3us: | gmaxwell: yep i've seen (and found) a few mmulti-fails myself (outside of bitcoin) often they involve like 3 or 4 simultaneous and very stupid failures, with ignored indicators. |
| 18:19:07 | gmaxwell: | esp because users do daft things like withdraw again and forget it. |
| 18:19:16 | Luke-Jr: | unfortunately, there are enough idiots out there that without at least a screenshot, I can see ignoring a few claims |
| 18:19:33 | phantomcircuit: | Luke-Jr, they were all marginally technical |
| 18:19:40 | phantomcircuit: | and without access to the mtgox database |
| 18:19:45 | phantomcircuit: | they seemed wrong |
| 18:19:53 | gmaxwell: | Luke-Jr: people have erroniously claimed eligius bogusly paid them— because they were confused about backpay when they'd stopped mining |
| 18:20:08 | Luke-Jr: | gmaxwell: exactly |
| 18:20:55 | Luke-Jr: | on the other hand, when multiple people were making reports of double-payout a month or so ago, we *did* take note and find it |
| 18:21:02 | Luke-Jr: | so I guess that's comforting |
| 18:21:04 | adam3us: | i just dont buy that anyone remotely competent running an exchange would not get nervous enough to run a batch job using another client and check their balance. you would think the #1 thing on your mind as custodian of that much btc, would be to check your position frequently |
| 18:21:46 | Luke-Jr: | I'd be scared to death to run an exchange. :x |
| 18:21:48 | phantomcircuit: | adam3us, in general the most dangerous part of an exchange is the database of balances |
| 18:22:05 | phantomcircuit: | at the end of the day everything else is reliant on those numbers |
| 18:22:14 | helo: | so if someone was to define best practices for a cold wallet, a naive approach prohibit any inbound data to avoid the chance of attack code infiltrating the machine |
| 18:22:19 | phantomcircuit: | and yet bizarrely i've yet to see any exchange get ruined that way |
| 18:23:27 | adam3us: | well even the usd balance can be edited on the exchange and then cashed out via btc. even happens to banks now and then. probably undisclosed bank insider apart from the $45m prepaid balance hac. |
| 18:25:22 | wumpus: | phantomcircuit: wasn't mtgox hacked that way once? not a database hack, but selling non-existent coins using an admin account, dropping the price to <$1 |
| 18:26:03 | orperelman: | Yes I think I remember that - in the 22 dollar rise |
| 18:26:04 | andytoshi: | adam3us: in 'The unbearable lightness of PIN cracking' the authors explain some easy hacks switch operators can do to steal funds, and suggest this as an explanation for phantom withdrawls |
| 18:26:09 | orperelman: | than they fucked again in the 255 mark |
| 18:26:10 | Luke-Jr: | wumpus: yes, using jed's codebase |
| 18:26:25 | Luke-Jr: | orperelman: what happened at 255? |
| 18:26:32 | orperelman: | They had lagging problems |
| 18:26:35 | orperelman: | if I recall |
| 18:27:02 | orperelman: | and it caused panic |
| 18:27:10 | helo: | *266? |
| 18:27:13 | orperelman: | 266 yes |
| 18:27:16 | orperelman: | sorry, my bad |
| 18:27:33 | Luke-Jr: | … |
| 18:27:44 | Luke-Jr: | "oh noes, lag" |
| 18:28:37 | orperelman: | Luke-Jr, I remember the price couldn't been seen for hrs |
| 18:28:59 | Luke-Jr: | somehow I cannot take it serious that you are comparing this to losing money |
| 18:29:16 | orperelman: | and they stopped the trading back than at one point as well - no that's not my point |
| 18:29:16 | Persopolis: | i worry that any evidence of what actually happened might not get secured |
| 18:29:20 | orperelman: | not comparing both cases ofcourse |
| 18:31:50 | Persopolis: | if it is genuinely a case of negligence, then it would be beneficial to gox if there was no evidence to support that |
| 18:31:54 | phantomcircuit: | wumpus, actually yeah so i guess it's happened once |
| 18:32:38 | ens: | gmaxwell: i had to deal with that kind of fault once |
| 18:33:22 | ens: | gmaxwell: tv station went kaputt, over 50% of it's material couldn't tx and all the stuff on the music channel was stopping after exactly 1 minute of playout. |
| 18:33:39 | ens: | it was layer upon layer of faults triggering faults all under _just_ the right conditions. |
| 18:39:41 | Persopolis: | Persopolis has left #bitcoin-wizards |
| 18:41:47 | gmaxwell: | adam3us: scared only lasts so long before it wears out, and I'm sure mtgox had a lot of other things to be scared of... |
| 18:47:16 | phantomcircuit: | gmaxwell, scared isn't really the right emotion either |
| 18:47:21 | phantomcircuit: | it's not a visceral fear |
| 18:47:34 | phantomcircuit: | it's not like you're going to be eaten by a bear or something |
| 18:47:47 | phantomcircuit: | it's more like you wake up at 3am and check things just because |
| 18:47:58 | adam3us: | any thoughts on this speculation that mtgox may still have some coins just with dodgy key management and some work to recover? |
| 18:48:01 | phantomcircuit: | you literally cannot do it for very long |
| 18:48:56 | adam3us: | i thought Karpeles basically admitted the leaked doc was mostly legit, that being the mos scary stat in it - that they had only 2k btc left out of 744k |
| 18:49:19 | gmaxwell: | he didn't appear to comment on the stats, so who knows. |
| 18:49:43 | phantomcircuit: | adam3us, the doc was probably written before their database had completely finished reindexing |
| 18:50:15 | phantomcircuit: | it appears to be a worst case scenario plan of action with ideas just thrown at the wall |
| 18:50:31 | phantomcircuit: | it's unfortunate that it was leaked because im sure it's not their actual plan |
| 18:50:43 | phantomcircuit: | but contains some things which are |
| 18:50:52 | phantomcircuit: | which will mean people will assume it is all accurate |
| 19:00:31 | jgarzik: | he also seemed to note that the doc was written by a third party |
| 19:01:52 | gmaxwell: | my theory is that it was written by someone who recieved inside information as part of mtgox's effort to find a buyer... either as a genuine proposal, or as truthy disinformation. |
| 19:03:40 | midnightmagic: | might be a disinformation training campaign |
| 19:06:23 | midnightmagic: | https://firstlook.org/theintercept/2014/02/24/jtrig-manipulation/ |
| 19:07:31 | adam3us: | now if we had mtgox chain code, presuming they were using an hd wallet for cold storge, maybe we could do some public analysis |
| 19:08:22 | jgarzik: | I do agree w/ sipa that we should get some HD basics into upstream sooner rather than later |
| 19:11:50 | TD: | i'd love for exchanges to start charging people to hold deposits |
| 19:11:56 | TD: | these huge piles of money need to be dispersed |
| 19:12:42 | Guest62160: | phantomcircuit: mark says the doc was not written by mt gox and the wording of it confirms this |
| 19:13:21 | gmaxwell: | TD: they _want_ to hold them alas. |
| 19:13:23 | Guest62160: | reasonable speculation is that it was a proposed plan by potential buyers / investors looking to bail out and take over, and assuming worst-case |
| 19:13:46 | Guest62160: | Guest62160 is now known as maaku |
| 19:13:56 | TD: | what makes you think that? |
| 19:14:16 | maaku: | maaku is now known as Guest31062 |
| 19:14:35 | Guest31062: | Guest31062 is now known as maaku |
| 19:15:29 | gmaxwell: | makes it easier to trade, they've all generally implemented some amount of wallet functionality. (e.g. look at the mtgox green addresses as a high profile example)... bitstamp has a whole gigantic Bitcoin IOU thing with ripple. |
| 19:15:35 | maaku: | TD: they make money on trades, trades only occur with funds on balance |
| 19:15:48 | gmaxwell: | pigeons: Can you count up how much bitstamp btc exists in ripple? |
| 19:16:41 | TD: | the vast majority of customer funds end up in cold wallets, i.e. they are not being used for trading |
| 19:16:42 | gmaxwell: | several of them charge high fees to take funds out. E.g. I think BTC-E charges 0.001— and this isn't a bitcoin transaction fee, it's a fee to them. |
| 19:16:53 | TD: | these huge cold wallets pose significant risk for the operators and yet earn nothing |
| 19:16:54 | gmaxwell: | cold wallet funds are used for trading. |
| 19:17:22 | gmaxwell: | e.g. speculators churning funds back and forth are just churning database entries, until someone withdraws the funds are sitting in a cold wallet. |
| 19:18:40 | TD: | yeah, i was thinking of "real economy" trading. but sure, if those funds are actually mostly moving then it'd be difficult to disperse for sure |
| 19:18:54 | TD: | if they're being basically held long term on deposit though ... |
| 19:19:04 | TD: | it really depends on the velocity of money inside an exchange, which i do not know |
| 19:19:49 | gmaxwell: | and the distribution of the velocity. I think on average its quite high, (go look at gox historical volume)... but I suspect there is a lot of deadweight funds. |
| 19:20:12 | gmaxwell: | Still, so long as you underestimate the risk of holding those funds, you'd rather have them with you than— say— with the compeition. |
| 19:20:21 | jgarzik: | It does seem like people holding millions should charge for deposit security |
| 19:20:29 | jgarzik: | a management and storage fee |
| 19:20:49 | jgarzik: | That's not a winning business model when everyone else is zero fee, of course |
| 19:20:59 | gmaxwell: | people get spazzy about fees too. |
| 19:21:18 | jgarzik: | bitcoin community seems to prefer "zero fee + high centralization risk" :( |
| 19:21:26 | gmaxwell: | e.g. the right thing to do is charge the fee conditionally on inactivity. But then people will mentally chalk it up as a constant fee. |
| 19:21:42 | gmaxwell: | and then, having no better way to evaluate choices, chose the zero fee comptition. |
| 19:22:07 | orperelman: | It seems people care more about comfortability and zero fees than about security. |
| 19:22:18 | orperelman: | I mean look at how BTC-E is so successful. |
| 19:22:19 | gmaxwell: | plus, having to way an hour to deposit encourages keeping balances if you think you _might_ trade. |
| 19:22:21 | TD: | we don't really know what they prefer, given that no existing exchanges levy storage fees |
| 19:22:46 | gmaxwell: | They've had negative storage fees. |
| 19:22:59 | jgarzik: | I think smart people assume average people reason about their choices far more than they actually do... a lot of times this boils down to (a) it's easy and/or (b) that's what Joe Nerd showed me |
| 19:23:06 | gmaxwell: | orperelman: It's like what I said previously: People wouldn't use a service if they didn't think they trusted it.. so since they trust it… |
| 19:23:16 | TD: | i suspect a lot of it is also driven by a reasonable fear of being your own bankk |
| 19:23:22 | jgarzik: | yes |
| 19:23:25 | TD: | it's easy to assume money in an exchange is safer than money on your laptop |
| 19:23:25 | gmaxwell: | TD: bitcoinica and bitfinex and I think one other place have had negative fees on deposits. |
| 19:23:30 | TD: | and this may or may not be correct, i guess |
| 19:23:37 | TD: | gmaxwell: they gave you money for depositing? |
| 19:23:41 | gmaxwell: | Yes. |
| 19:23:51 | midnightmagic: | Very old people consider money in coffee tins to be safer than in a bank. |
| 19:23:53 | jgarzik: | Bucket Shop. |
| 19:24:00 | TD: | "negative fee", interesting way to phrase it :) |
| 19:24:16 | orperelman: | It's amazing though - how can you trust a service which you don't know who runs it + coins getting disappeared from wallets all the time? |
| 19:24:27 | TD: | calculated risk i guess |
| 19:24:29 | gmaxwell: | orperelman: everyone else uses it |
| 19:24:34 | TD: | people put a bit of money in, value goes up a lot |
| 19:24:41 | midnightmagic: | orperelman: "social proof" |
| 19:24:49 | jgarzik: | TD, that's a big part of it too |
| 19:24:52 | TD: | seems easier to just keep it there rather than learn about running your own wallet |
| 19:24:58 | jgarzik: | 700,000 BTC sounds like a lot today |
| 19:25:03 | TD: | i'd like to see exchanges team up with the trezor guys |
| 19:25:12 | gmaxwell: | I dunno, I use btc-e to sell namecoins and I'm personally convinced they have to be fractional (because they've had some amazing compromises that cost them coins and just kept running) |
| 19:25:15 | TD: | if exchanges sold trezors, this would solve several problems simultaneously (with some tweaks to the trezor itself) |
| 19:25:24 | jgarzik: | I'd like the exchanges to be SPOF-proof, including key men |
| 19:25:50 | TD: | 1) trezors could be given a private key + cert at manufacturing time, allowing them to generate payment protocol requests for themselves that are verified by the exchange. allowing money to move from exchange to trezor inbound, safely, even with a compromised host |
| 19:25:51 | midnightmagic: | gmaxwell: That seems to me to be more a sign of something else to me. |
| 19:25:58 | TD: | 2) it educates users and gets the hardware in front of them |
| 19:26:33 | TD: | 3) if the trezor hardware was secure enough, it could sign the Payment messages submitted to exchanges for outbound sends, and the exchange could use that as a trust signal that double spending was unlikely, so allow faster deposits |
| 19:26:53 | TD: | jgarzik: i don't think it's possible. i was pondering the kidnapping problem lately. |
| 19:27:02 | orperelman: | Gmaxwell - you sold your namecoins and left your bitcoins there? |
| 19:27:07 | jgarzik: | DAMMIT. Someone already got bitcoin.tips and bitcoins.tips (now gTLD) |
| 19:27:09 | orperelman: | or moved your bitcoins back to your wallet? |
| 19:27:09 | jgarzik: | *new |
| 19:27:11 | gmaxwell: | TD: yea, PT had jumped on trezor early on to ask it to be able to display and sign arbritary messages so you could authorize logins and withdraws and stuff, and he got an out-of-scope reponse. .. but V1. |
| 19:27:24 | gmaxwell: | orperelman: no I don't _leave_ anything there of course. |
| 19:27:35 | jgarzik: | TD, you can reduce it with multi-sig, A/B teams |
| 19:27:35 | TD: | jgarzik: currently we get a lot of herd immunity, and it doesn't make sense to kidnap/extort exchange operators for huge amounts because to convert them into dollars and buy all the juicy stuff you'd have to immediately go sell them back on the same exchange |
| 19:27:40 | TD: | jgarzik: no. doesn't work. |
| 19:27:42 | gmaxwell: | orperelman: except maybe for a day or two while a limit order executes. |
| 19:28:06 | TD: | jgarzik: CEO's daughter is kidnapped. kidnapper sends video via Tor saying he'll kill her within 72 hours if there isn't a 10,000 BTC transfer to the given address. people believe him. |
| 19:28:09 | TD: | jgarzik: result: all parties sign |
| 19:28:24 | orperelman: | gmaxwell - that's a good point - so alot of people use BTC-E just to exchange alts immediatly cashout. |
| 19:28:28 | jgarzik: | TD, it's not a binary work/doesn't work. it makes the attack more difficult. |
| 19:28:31 | gmaxwell: | TD: I think you would have no problem showing up someplace and saying "I have a million bitcoin that you can't sell for a decade or so, who wants to buy it for 10cts on the dollar" You'll get buyers. |
| 19:28:33 | TD: | we're hard-wired to value human life above any amount of money. multi-sig is useful in some situations like when someone is compromised and trying to hide it. but not in this case |
| 19:29:04 | jgarzik: | TD, ideally there is a multi-organization or algorithm-driven multi-sig that is even more resistant... but that is accordingly harder to build |
| 19:29:34 | TD: | whilst people are involved, i'm not sure it can work. it's very very hard to get people, even in institutions, to willingly let other people die over money. |
| 19:29:46 | TD: | though i hate to say it, the british government is one such institution that's willing to do that |
| 19:29:59 | TD: | it has a "no paying kidnappers" policy and victims have in fact been killed as a result of it. |
| 19:30:29 | TD: | very difficult ethical dilemmas here. |
| 19:30:58 | gmaxwell: | Paying kidnappers just encourages more kidnapping. Often people believe the person will be killed regardless of the payment anyways— usually safer for the kidnappers. |
| 19:31:07 | TD: | of course |
| 19:31:46 | TD: | it's easy to see why it's done. hard to enforce though. governments can make such a policy for themselves. enforcing a "no pay" law on citizens would be very hard though. people would end up victimised twice. |
| 19:31:57 | midnightmagic: | The chances of retrieving a son, on the other hand, will cause a parent to pay. Also, companies will often pay ransom for their operators, and the process is insured. |
| 19:31:58 | jgarzik: | That's why some real world systems feature gadgets like time locks |
| 19:31:58 | TD: | i think secure hardware might be a part of a solution |
| 19:32:10 | jgarzik: | Time locks are a simple example of proving that humans are out of the loop |
| 19:32:10 | TD: | jgarzik: indeed |
| 19:32:35 | TD: | smartcard chips could enforce a variety of rules that no human can overrule |
| 19:32:44 | TD: | at least not in any reasonable amount of time |
| 19:32:53 | HM2: | | we're hard-wired to value human life above any amount of money. |
| 19:33:04 | HM2: | except the people who take human life for money? |
| 19:33:32 | TD: | er, context matters :) obviously i was talking about the lives of people very close to you |
| 19:33:36 | gmaxwell: | well not just smartcards but N of M smartcards in varrious seperate locations. |
| 19:33:36 | TD: | not random strangers |
| 19:33:42 | zooko: | Not really on-topic, but still maybe relevant: https://www.eff.org/deeplinks/2014/02/open-letter-to-tech-companies |
| 19:33:45 | zooko: | Just came out. |
| 19:34:26 | TD: | i think the rules for such smartcards would be interesting. simple time locks are too inflexible - you still need to be able to spend your money when you want it |
| 19:34:32 | TD: | and kidnappers can hold people for a while |
| 19:35:08 | TD: | possibly, some kind of "can spend if the receiver meets criteria X,Y,Z and can do a 'cash withdrawal' of K coins per month" etc |
| 19:35:13 | TD: | so perhaps emulating bank policies in hardware |
| 19:35:15 | zooko: | Does anyone here have experience buying or operating HSMs? |
| 19:35:44 | TD: | i've never found a crisp definition of what makes something an HSM, actually |
| 19:35:50 | zooko: | By the way, I'm currently looking for someone with experience in real adversarial network-, info-, operational- security. |
| 19:36:21 | zooko: | I.e., if you could tell stories of actual info attacks you've experienced, then you would do well in a job interview. |
| 19:36:37 | zooko: | Or if you know someone like that, please introduce me. |
| 19:36:46 | zooko: | TD: hi there! Nice to see you. |
| 19:36:59 | TD: | hey zooko :) |
| 19:37:03 | zooko: | TD: I know what you mean about the definition of HSM. |
| 19:37:23 | zooko: | So, I'm thinking of buying and operating HSMs for the same reason I'm looking to hire an experienced opsec person. |
| 19:37:28 | TD: | i can tell many interesting attack stories, unfortunately, they're all confidential ..... |
| 19:37:37 | TD: | so by "can" i really mean "can't" |
| 19:37:39 | zooko: | TD: well, you personally just took a new job didn't you? |
| 19:37:56 | TD: | i'm currently an unemployed person |
| 19:38:02 | sipa: | so sad |
| 19:38:13 | jgarzik: | heh |
| 19:38:17 | zooko: | Sometimes known as funemployed! |
| 19:38:34 | TD: | it's been pretty fun so far :) |
| 19:38:50 | sipa: | i was unemployed for a year; i spent some time rewriting bitcoind then :p |
| 19:38:59 | TD: | albeit, because 50% of my unemployment has been spent on holiday :) |
| 19:39:07 | gmaxwell: | the IBM cryptocards show up on ebay pretty cheap from time to time, I plan to get a few sometime after the second or third hour-in-a-day expanders. |
| 19:39:25 | TD: | the IBM cards are great, but my understanding is, also discontinued |
| 19:39:27 | orperelman: | Sipa, core dev is like a rock star nowdays ;) |
| 19:39:36 | GabNet: | In case of you are interested in other invest metode... https://leancy.com/~GabNet .... Promisel 5% daily income. Greetings. |
| 19:39:38 | GabNet: | GabNet has left #bitcoin-wizards |
| 19:39:39 | zooko: | TD: I sent you private messages just now. |
| 19:39:40 | TD: | next gen intel chips will also have hardware security (that might actually work). unfortunately no ship dates have been announced |
| 19:39:48 | TD: | oops, so you did |
| 19:39:51 | TD: | * TD resizes window |
| 19:39:51 | jgarzik: | and better RNG seeding |
| 19:40:15 | jgarzik: | though, amusingly, "better" is defined operationally as "running the same speed, but failing more often" |
| 19:40:51 | TD: | gmaxwell: my understanding is that to get the dev kit, you have to take out an IBM support contract :( |
| 19:41:01 | TD: | so .... not sure if you can locate the stuff needed in other ways. Hal used to have one |
| 19:41:06 | gmaxwell: | I have never been unemployed since I was first employed 18 years ago, unless you count a weekened once where my employment was scheduled to begin on the following monday. |
| 19:41:12 | zooko: | So, there are these products that are used by CA's, I think. |
| 19:41:23 | zooko: | And maybe private-CA's. |
| 19:41:38 | gmaxwell: | TD: yea, I actually tried asking hal if he still had the developer tools and his card some time ago, but I guess it didn't cross the threshold of getting a reply. :( |
| 19:41:44 | jgarzik: | zooko, nice! the EFF mentions reproducible builds! :) |
| 19:41:47 | zooko: | This sort of thing: https://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules |
| 19:41:50 | TD: | i wonder if he's even still alive :( |
| 19:41:50 | zooko: | jgarzik: yeah! |
| 19:42:09 | zooko: | The topic of Hal's illness and probable imminent mortality makes me sad. |
| 19:42:10 | TD: | iirc the ibm cards were made for banks |
| 19:42:23 | TD: | not sure CA's use them. they use other things, i think |
| 19:42:33 | sipa: | it's been a while since i read anything about hal |
| 19:43:02 | zooko: | TD: I know a guy who has done a lot of CA work, and he emphatically insisted that HSMs are de rigeur. |
| 19:43:16 | zooko: | But, I haven't found anybody (else) who has hands-on experience with them. |
| 19:43:25 | zooko: | And that guy isn't available to hire... |
| 19:43:29 | TD: | yes, i think it might actually be a CA/B requirement |
| 19:43:37 | gmaxwell: | zooko: I've seen the HSMs that verisign was using.. uh. if I think for a bit I can remember the brand.. in any case I'd looked them up at the time and thought they were too fixed function to be interesting. |
| 19:43:39 | zooko: | TD: Oh yeah, it is. I remember looking that up, now. |
| 19:43:53 | zooko: | Yeah, me too. |
| 19:44:00 | TD: | i know CA's use things called "HSMs" but i'm not sure they're the same thing as the IBM cards. also, i'm not sure how it helps. "secure hardware" that signs whatever it's asked to seems ...... not secure |
| 19:44:06 | TD: | there has to be a way to run custom business logic on them |
| 19:44:19 | TD: | and then they're just normal computers, perhaps that are tougher to open and attach logic analyzers to |
| 19:44:40 | zooko: | But now I have a |
| 19:44:43 | zooko: | Wow! This is cool: http://antonopoulos.com/2014/02/25/coinbase-review/ |
| 19:45:12 | gmaxwell: | TD: yea... well it would at least potentially rate limit your access. The IBM cards were something special though. still not perfect. But if you combine ibm cards (like devices) with distributed control.. you get the "wait, you want me to drill my signer device .... uhhh lemme get back to you on that" |
| 19:45:16 | zooko: | Okay, well I've gotta get moving to get to a meweting. |
| 19:45:26 | gmaxwell: | zooko: I think it's exactly the opposite of cool. |
| 19:45:46 | gmaxwell: | Thats the same trust me security crap that Roger Ver did for mtgox a few months back with the "mtgox's problems are the banks" video. |
| 19:45:46 | zooko: | If you think of someone who has practical opsec experience and might be available to hire, please email zooko@LeastAuthority.com. |
| 19:45:55 | TD: | yes. i liked the IBM cards too. was sad when i read that they weren't available any more |
| 19:45:56 | zooko: | gmaxwell: I understand your point. |
| 19:46:00 | zooko: | Okay, bye for now folks! |
| 19:46:18 | gmaxwell: | If 1/5th of coinbases coins were unspendable due to corrupted private keys, his test would be overwhelmingly unlikely to uncover that. |
| 19:46:33 | jgarzik: | gmaxwell, yeah, it was a silly, gimmicky test |
| 19:46:43 | TD: | that's true, however, it is better than no audit at all |
| 19:47:26 | TD: | got to start somewhere |
| 19:47:41 | TD: | i think the bar will only be raised from here |
| 19:47:43 | jgarzik: | leveldb code < bitcoind code |
| 19:47:44 | gmaxwell: | There are places offering to pay for statements like that FWIW, if you're looking to make a buck. |
| 19:47:55 | gmaxwell: | But they are not interested in real audits. |
| 19:48:01 | gmaxwell: | So good luck with that. |
| 19:48:01 | sipa: | jgarzik: how so? |
| 19:48:25 | jgarzik: | sipa, subjectively, I think our code is better |
| 19:48:29 | jgarzik: | quality |
| 19:48:33 | sipa: | wut? |
| 19:48:36 | sipa: | ok :) |
| 19:48:59 | TD: | jgarzik: errrrrrrrrrr ... :) ok .... :) if you say so |
| 19:49:14 | sipa: | let me respectfully completely disagree :) |
| 19:49:57 | HM2: | bitcoind code isn't the best C++ code I've ever seen, but I've seen a lot lot worse |
| 19:50:56 | TD: | perhaps i got warped by years of working with google-style c++ but i much prefer the leveldb code to bitcoin's |
| 19:51:23 | sipa: | even regardless of style, it's cleanly separated into modules, classes that hide access to their members, ... |
| 19:51:51 | sipa: | bitcoin has a few places that are like that, but the majority is still very chaotic |
| 19:52:55 | HM2: | but bitcoind isn't a library |
| 19:53:06 | sipa: | not very relevant |
| 19:53:17 | HM2: | it doesn't need to worry about maintaining a stable API internally or binary compatbility, leveldb does |
| 19:53:23 | HM2: | in theory? |
| 19:53:37 | TD: | i don't think leveldb commits to a stable api or abi. it's designed to be statically linked into other apps |
| 19:53:40 | TD: | (specifically, into chrome) |
| 19:53:44 | sipa: | stability of APIs is less important perhaps indeed |
| 19:53:59 | sipa: | but having APIs for the different pieces to communicate with eachother is |
| 19:54:06 | sipa: | separation of concerns etc |
| 19:55:08 | HM2: | I dislike a lot of Google C++ codebases, some of it is just style friction |
| 19:55:11 | HM2: | they're very conservative |
| 19:55:43 | HM2: | I like that Facebook have embraced modern C++ style and practice |
| 19:55:54 | HM2: | much of libraries like folly are well-written imho |
| 19:56:15 | TD: | there's a lot of ex-googlers at facebook these days ... it used to all be PHP over there :) |
| 19:56:39 | TD: | but by the time i left google3 was modernising quite fast. c++11 features were being whitelisted all the time. so i think you'll see more modern c++ in new releases |
| 19:56:48 | HM2: | Andrei is championing modern C++ there and D now |
| 19:56:54 | HM2: | (FB) |
| 19:56:56 | TD: | D! |
| 19:57:01 | sipa: | E! |
| 19:57:29 | BlueMatt: | F! |
| 19:57:32 | TD: | i remember when i cared about D |
| 19:57:36 | BlueMatt: | wait, I thought we were just listing letters |
| 19:57:51 | HM2: | D still has a chance |
| 19:58:03 | sipa: | oh? i think we were listing the first character of android releases |
| 19:58:06 | HM2: | newer C++ standards are going to squeeze that chance out though |
| 19:58:27 | HM2: | there's a lot of blowback on features like traits |
| 20:03:57 | orperelman: | Bluematt - lol |
| 20:18:56 | phantomcircuit_: | phantomcircuit_ is now known as phantomcircuit |
| 20:36:21 | jron: | /lastlog leaked 10 |
| 20:45:50 | pigeons: | gmaxwell: bitstamp (rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B) has issued 3,521.6586376551745 BTC in ripple, 261.47741227315123 BTC of that is held by their "hotwallet" (rrpNnNLKrartuEqfJGpqyDwPj1AFPg9vn1) that sends the ripple payments. |
| 20:47:23 | justanotheruser: | justanotheruser is now known as just[dead] |
| 20:47:48 | mike4: | mike4 is now known as c--O-O |
| 20:48:41 | gmaxwell: | pigeons: thanks. :) |
| 20:49:41 | gmaxwell: | TD: ^ so for example, bitstamp has 3,521.65 in bitcoin they're holding (hopefully) just to back people trading around via the ripple network. This isn't suggestive to me of someone who is trying to avoid holding other people's funds. :) |
| 20:50:37 | phantomcircuit: | pigeons, that is a comically small amount compared to the size of their trading volume |
| 20:50:51 | pigeons: | there isnt a lot of action on ripple |
| 20:50:59 | phantomcircuit: | i know |
| 20:51:05 | phantomcircuit: | and it fills my heart with happyness |
| 20:55:39 | pigeons: | offtopic, but bitstamp disabled their "bitcoin bridge" which is opaquely integrated into the ripple labs client for sending real bitcoins to bitcoin addresses when mtgox disabled their btc withdrawals, and it is still not enabled. you can still make a ripple payment to your bitstamp account and withdraw the btc from the bitstamp site. it is assumed bitstamp is too busy with recent events to re-enable |
| 20:56:11 | michagogo|cloud: | 21:27:10 DAMMIT. Someone already got bitcoin.tips and bitcoins.tips (now gTLD) |
| 20:56:27 | michagogo|cloud: | Someone in Estonia and India, respectively... I wonder what they're planning to use them for |
| 20:56:37 | phantomcircuit: | pigeons, sounds like maybe they had btc on mtgox |
| 20:56:41 | TD: | selling them, i imagine |
| 20:56:45 | phantomcircuit: | although i cant understand why |
| 20:56:48 | michagogo|cloud: | 21:39:09 the IBM cryptocards show up on ebay pretty cheap from time to time, I plan to get a few sometime after the second or third hour-in-a-day expanders. |
| 20:56:48 | michagogo|cloud: | What are hour-in-a-day expanders? |
| 20:57:37 | michagogo|cloud: | bitcoins.tips has an email address from http://msourceone.com/companyoverview.html |
| 20:58:11 | michagogo|cloud: | The other may just be some individual |
| 20:58:43 | michagogo|cloud: | Ah, bitcoin.tips is bought for resale |
| 20:58:57 | michagogo|cloud: | And bitcoins.tips is just parked |
| 20:59:32 | TD: | gmaxwell: do you know why eli et al didn't release any code yet? |
| 21:01:14 | gmaxwell: | TD: No, thought I've talked to them some on various technical things I've not bothered them for a code release because I don't want to do that unless I can say in the message that I'll personally do something with it. ... though maybe I should just code up a blind proof of owning a coin, and then I'll be able to at least tell them that I'll try it. |
| 21:01:49 | gmaxwell: | I think, fundimentally, the problem is that they don't need to publish code to publish papers. :) |
| 21:02:01 | TD: | yeah. i was thinking the same thing. i want to play with such things, but then, i got a threshold RSA implementation from some other researchers and then never used it ..... |
| 21:02:26 | TD: | probably also they want to do big rewrites and/or don't want to do tech support except for other researchers |
| 21:02:49 | gmaxwell: | It's likely that the implemention is crap, bubblegum and duct tape. But you have to start somewhere. |
| 21:03:12 | TD: | well that'd be fitting for anything bitcoin related |
| 21:03:22 | phantomcircuit: | :/ |
| 21:06:01 | gmaxwell: | Mostly I'd want it for technology demos. Actual production use will take years of maturation which needs to start with being aware of the possibilities. |
| 21:11:49 | TD: | i think we can find uses for it already that are purely additive, that is, if it fails completely and turns out to be worthless, we're in no worse position than where we started |
| 21:12:21 | jgarzik: | new wallet, https://test.greenaddress.it/en/ |
| 21:14:46 | gmaxwell: | TD: the various flavors of the cryptographic backend stuff have different tradeoffs between zero-knoweldge and soundness. Some of them (like the CRS GGPR'12 stuff in most of the publications) has information theoretic zero knoweldge— even if the scheme is broken it very likely won't leak data— but only cryptographic soundness,— you can get fake proofs if the crypto turns out to be weak. |
| 21:15:24 | gmaxwell: | Other ones flip that around: the ZK is only computationally sound, but the soundness is without crypto assumptions (if it were unsound it would be due to software bugs). |
| 21:15:47 | gmaxwell: | so if you align the usecase with the weaknesses you can get better purely additive effects. |
| 21:15:48 | TD: | jgarzik: well that's an impressive list of features |
| 21:16:24 | gmaxwell: | Hack proof! |
| 21:16:46 | TD: | jgarzik: i see no mention of their revenue model |
| 21:17:06 | TD: | also where did you find this? it appears to be a half finished website |
| 21:17:34 | gmaxwell: | "GreenAddressIT Ltd takes no responsibility for and will not be liable for any financial loss arising from the use of our wallet service including any of the following." "Financial loss due to server hacks" ... but they said it was hack proof! |
| 21:18:26 | TD: | it's obviously not hack proof against bogus software updates, and i'm sure they know it |
| 21:18:54 | phantomcircuit: | lol |
| 21:18:55 | TD: | i tried creating a wallet and it isn't working |
| 21:19:02 | phantomcircuit: | gmaxwell, if they dont have your private key |
| 21:19:03 | TD: | but then it is a test site, i guess |
| 21:19:08 | phantomcircuit: | then how can they set transaction limits |
| 21:19:09 | gmaxwell: | phantomcircuit: it's a webwallet. |
| 21:19:14 | gmaxwell: | phantomcircuit: multisig. |
| 21:19:33 | phantomcircuit: | great so they lose their half of the key and everybody is boned |
| 21:19:45 | TD: | still, if/when it launches, that could be a very impressive wallet |
| 21:19:51 | phantomcircuit: | at least it's iteratively better than bc.i |
| 21:21:10 | gmaxwell: | The hyperbole needs to go though. Part of the reason that we don't get better solutions is that existing ones mislead people about their security. |
| 21:21:35 | BCB: | BCB is now known as Guest38327 |
| 21:21:46 | gmaxwell: | If they want to claim this stuff, they can give me the server software and start using a wallet I host for their own usage— I get to keep whatever coins I can steal. :P |
| 21:21:58 | TD: | i don't know about that. the costs of wallet development are just going up beyond what volunteers can do. so then people look for ways to fund it. it's much easier to get funding for making a web service than a regular app, i guess |
| 21:22:42 | TD: | investors feel like they "get" web service based business models, whereas pure downloadable software just gets pirated a lot |
| 21:22:49 | phantomcircuit: | TD, building a reasonably secure shared webwallet costs takes approximately 4 hours of competent developer time |
| 21:23:17 | Luke-Jr: | phantomcircuit: I don't agree. |
| 21:23:21 | TD: | i look forward to seeing the competitive phantomcircuit wallet written in 4 hours |
| 21:23:26 | gmaxwell: | I don't begrudge them making a living, or even making a webservice... but they should try to not mislead about what they can offer. |
| 21:23:29 | Luke-Jr: | but I have high standards for "reasonably secure" |
| 21:23:55 | phantomcircuit: | TD, i cant run it since im in the us and that would be money transmitting |
| 21:24:21 | TD: | good excuse. if you don't have access to customer funds then you are not transmitting the money, according to any legal interpretation i'm aware of |
| 21:24:25 | phantomcircuit: | TD, you forget that i've essentially run intersango for 3+ years now with losses less than 0.01% of total value |
| 21:24:57 | phantomcircuit: | TD, that interpretation is misguided and whomever gave it to you should have their head checked |
| 21:25:15 | phantomcircuit: | TD, the vast majority of money transmitters are merely transmitting payment instructions |
| 21:28:36 | TD: | i think it's your interpretation that's misguided, but you could still prove your claim by making a wallet for testnet coins with no real risk |
| 21:29:10 | phantomcircuit: | TD, looking at all of the past failures they all have two things in common |
| 21:29:18 | phantomcircuit: | either the operator stole the funds |
| 21:29:41 | phantomcircuit: | (no existing javascript wallet protects against an active attack here, the bc.i plugin thing is bullshit) |
| 21:29:56 | phantomcircuit: | or their hot wallet server was compromised |
| 21:30:12 | phantomcircuit: | generally speaking if your wallet server is compromised the web server is also |
| 21:30:19 | phantomcircuit: | in which case goto 1 |
| 21:31:05 | phantomcircuit: | realistically what keeps these services actually secure is auditing and correct accounting of records |
| 21:31:15 | phantomcircuit: | but that's actually difficult |
| 21:31:25 | phantomcircuit: | so instead people try to do multisig whatever gizmose |
| 21:32:26 | phantomcircuit: | but you know that's just my opinion... |
| 21:33:43 | iddo_: | iddo_ is now known as iddo |
| 21:37:24 | aksyn: | aksyn is now known as Guest59861 |
| 21:38:01 | imsaguy: | TD, you forget that i've essentially run intersango for 3+ years now with losses less than 0.01% of total value << are you still incrementing that age? I hadn't heard the name intersango in so long, I figured it was shut down. |
| 21:38:39 | phantomcircuit: | imsaguy, intersango still holds a pretty significant amount of btc which is customers |
| 21:38:56 | phantomcircuit: | im actually working on an orderly process for returning it all |
| 21:39:04 | phantomcircuit: | but it's taking a while to get legal stuff sorted for it |
| 21:39:06 | imsaguy: | you've halted the wallet |
| 21:39:27 | imsaguy: | so there's not much security risk at this time. |
| 21:39:28 | phantomcircuit: | imsaguy, for about 2 months |
| 21:39:48 | imsaguy: | so they don't count |
| 21:39:49 | phantomcircuit: | imsaguy, the value of what was being held rose about 100x |
| 21:39:58 | phantomcircuit: | so allowing password resets via email and etc wasn't safe compared to the value anymore |
| 21:40:15 | phantomcircuit: | (especially with effectively zero revenue) |
| 21:40:21 | imsaguy: | phantomcircuit: that all depends on which exchange you compare the price to.. in gox dollars, its like 10% |
| 21:40:34 | imsaguy: | and in today's gox, its 0 |
| 21:40:47 | phantomcircuit: | imsaguy, regardless of that |
| 21:41:11 | phantomcircuit: | this was all written and designed when all bitcoins in existence were worth < 100m usd |
| 21:43:18 | imsaguy: | Do you have provable reserves? |
| 21:43:51 | phantomcircuit: | imsaguy, you mean do we have reserves which have been proven |
| 21:43:55 | phantomcircuit: | or which could be proven |
| 21:43:58 | phantomcircuit: | very different questions |
| 21:46:40 | HM: | is the liquidity still too low for any of the 'real'/established financial institutions to run an exchange? |
| 21:46:42 | imsaguy: | Proving reserves 6 months ago vs proving reserves now are two very different things by your own statement. |
| 21:47:02 | imsaguy: | I asked if you have probable reserves, which I thought was pretty clear to mean present tense. |
| 21:48:32 | phantomcircuit: | imsaguy, the phrasing of the sentence could mean either thing |
| 21:48:58 | phantomcircuit: | which is why i asked :) |
| 21:52:18 | nsh: | |
| 22:04:38 | imsaguy: | phantomcircuit: Do you, at this present time, have total bitcoins stored by the exchange or elsewhere but dedicated only to the exchange, equal to the total number of bitcoins deposited there by all users? |
| 22:04:53 | phantomcircuit: | imsaguy, yes |
| 22:05:07 | phantomcircuit: | and the people for whom it really matters are by and large not mad |
| 22:05:27 | imsaguy: | I'm not looking to start crap, I just figured it was worth asking. |
| 22:06:52 | gmaxwell: | FWIW, phantomcircuit has expressed interest in implementing that obligations/liabilities scheme I've described on several occasions going back a year or so. |
| 22:08:15 | imsaguy: | gmaxwell: Judging by pc's claim that it'd only take 4 hours to write a good web wallet and any "good" web wallet would be able to prove assets and liabilities, I would assume it'd take less than 4 hours. Why hasn't it been implemented yet? |
| 22:09:45 | phantomcircuit: | being able to prove assets/liabilities w/o a trusted auditor is hardly something i would expect a good web wallet to do at this time |
| 22:10:04 | phantomcircuit: | it's simply not something that has been worked through enough |
| 22:10:39 | gmaxwell: | imsaguy: because no one gives a shit, you ask the operators of services about this stuff (as I have, as have others— e.g. iwilcox) you get a long explination about how trustworthy they are. |
| 22:10:57 | imsaguy: | gmaxwell: I know. My question to you was already answered in my head. |
| 22:11:01 | gmaxwell: | and if you press you insult them even if you take care to specify that you're thinking about things like rogue employees are hacks. |
| 22:11:10 | gmaxwell: | and the users do not demand it. |
| 22:11:48 | gmaxwell: | go watch in #bitcoin ... you'll frequently see n00bs telling other n00bs that bc.i is highly secure because only you have your private keys... or mtgox is secure because you can get a yubi. |
| 22:12:11 | imsaguy: | gmaxwell: I idle in there, but I'm usually not actively reading it. |
| 22:12:18 | HM: | it's the same outside of bitcoin |
| 22:12:29 | gmaxwell: | In Bitcoin we can do something about it. |
| 22:12:35 | HM: | companies don't go out of their way to prove they are trustworthy via technical means |
| 22:12:36 | imsaguy: | gmaxwell: see pm |
| 22:12:37 | gmaxwell: | (and we have more need to) |
| 22:12:41 | sipa: | gmaxwell: it's an amazingly prevalent idea |
| 22:13:04 | sipa: | "the key never leaves my computer" - "which code guarantees that?" - "theirs!" |
| 22:13:36 | HM: | that applies to pretty much every program or app anyone uses |
| 22:14:03 | gmaxwell: | sipa: Roger Ver was plugging exactly that like on — I assume facebook— luke commented about that and he deleted his comment. There are real reasons why improving the security model is hard, but it irritates me that people running these services are not frank (if not quite deceptive) about the limitations. |
| 22:14:43 | sipa: | there is an actual difference though: with a client-side in-browser key, they still can't still all accounts at the same time |
| 22:14:47 | imsaguy: | gmaxwell: that's pretty much what keeps getting these exchanges in trouble by the 3 letter agencies. If they'd just be frank about the risks, it'd go a long way towards being 'legit'. |
| 22:15:02 | sipa: | but i've often warned that thinking that the key is theirs is a false sense of security |
| 22:15:31 | gmaxwell: | HM: window of exposure is a bit different... give me a bump in the wire in front of BC.i's servers for a few weeks and I bet I could steal a substantial fraction of their users funds. Hell, I'd put up a sizable bet on that. |
| 22:15:56 | HM: | BC.i? |
| 22:16:03 | HM: | bitcoin.info? |
| 22:16:04 | DBordello: | HM, blockchain.info |
| 22:16:06 | imsaguy: | aye |
| 22:16:09 | gmaxwell: | blockchain.info (very popular web wallet) |
| 22:16:09 | HM: | right |
| 22:16:30 | midnightmagic: | blockchain.info, a really not-friendly network participant that confuses lots of people and gets them in trouble with law enforcement |
| 22:16:44 | gmaxwell: | The fact that strongcoin actually clawed back stolen funds successfully using this capability seems to have no opened anyone's eyes. |
| 22:16:53 | DBordello: | midnightmagic, how does BC.i get people in trouble with law enforcement? |
| 22:17:14 | DBordello: | gmaxwell, I was just thinking that. The ozcoin fiasco should have scared everyone away |
| 22:17:23 | phantomcircuit: | DBordello, they operate a service for the express purpose of money laundering |
| 22:17:36 | gmaxwell: | midnightmagic: still not sure that wasn't trolling... :( but yea. |
| 22:17:40 | phantomcircuit: | they fraudulently claim to delete the records, which they do not |
| 22:17:41 | DBordello: | The mixer? I thought they shut that down |
| 22:17:54 | phantomcircuit: | DBordello, they just changed the name to shared send |
| 22:18:00 | DBordello: | ah |
| 22:18:01 | HM: | the web makes it easy to hide your incompetance on the server side. as long as your frontend is pretty. 300 million stolen passwords leaked again recently from some site yet to to be identified |
| 22:18:05 | midnightmagic: | DBordello: LE supposedly busted down someone's door because bc.i didn't specify in their "tx originated here" geolocation that it's completely inaccurate. |
| 22:18:06 | phantomcircuit: | and got rid of the giant picture of the guy with the v mask |
| 22:18:30 | DBordello: | midnightmagic, yikes |
| 22:18:47 | DBordello: | phantomcircuit, Interesting, thank you. |
| 22:18:49 | imsaguy: | that's also a pretty weak search warrant |
| 22:18:56 | imsaguy: | a good lawyer would tear that apart |
| 22:19:59 | phantomcircuit: | imsaguy, great you can sue the state for busting down your door and maybe get compensation for fixing it |
| 22:20:04 | phantomcircuit: | otoh they might have shot you |
| 22:20:10 | phantomcircuit: | but they didn't |
| 22:20:15 | phantomcircuit: | so no harm no damages right? |
| 22:20:17 | HM: | christ, i'm out of the loop. i thought blockchain.info was reputable |
| 22:20:24 | midnightmagic: | gmaxwell: I don't suppose you could hint at the issue number could you? I can't find it anymore. |
| 22:20:29 | imsaguy: | you're always at risk of being shot by LE |
| 22:20:33 | midnightmagic: | HM: It *never* has been, it's brutal. |
| 22:20:41 | imsaguy: | if you comply with their directives, you greatly reduce that risk. |
| 22:21:00 | gmaxwell: | midnightmagic: https://github.com/bitcoin/bitcoin/issues/2653 |
| 22:21:17 | Luke-Jr: | I'd probably shoot back. |
| 22:21:21 | midnightmagic: | gmaxwell: Thank you. DBordello ^^ |
| 22:21:26 | imsaguy: | lol Luke-Jr |
| 22:21:31 | imsaguy: | you probably would. |
| 22:21:36 | Luke-Jr: | unless they gave me time to call 911 and verify |
| 22:22:05 | imsaguy: | Actually, so long as you aren't destroying what they consider to be evidence, they'll give you time to verify |
| 22:22:26 | gmaxwell: | The US is weird, federally its lawful to use deadly force to stop an unlawful arrest, presuming lesser means have already failed. .. uh.. though ... probably not wise to depend on this. |
| 22:22:39 | Luke-Jr: | imsaguy: it's when they suddenly break in unannounced that I'm concerned about.. |
| 22:22:49 | DBordello: | What if they knocked politely? |
| 22:22:56 | sipa: | policely? |
| 22:23:00 | midnightmagic: | lol |
| 22:23:02 | DBordello: | hah |
| 22:23:21 | Luke-Jr: | my door has a flap I can open to talk through |
| 22:23:35 | gmaxwell: | in any case, this isn't #bitcoin-gunnuts. :P |
| 22:23:43 | Luke-Jr: | I won't open it until I've verified they're legit, and have a right to be there |
| 22:23:47 | Luke-Jr: | open the door* |
| 22:23:57 | gmaxwell: | the take away is that it harm is done by unwelcome attention, no matter how things turn out. |
| 22:24:17 | HM: | I opened the door to a policewoman the other day who 'just called to see everything was OK' |
| 22:24:26 | HM: | I asked if anything was up in the neighbourhood and she said no |
| 22:24:30 | HM: | I am now suspicious |
| 22:25:25 | gmaxwell: | meh, no use being suspicious. |
| 22:25:47 | Luke-Jr: | coulda been a thief checking if you were home |
| 22:26:32 | HM: | Undoubtedly |
| 22:27:10 | HM: | Last year there were some shifty looking windows salesmen selling super secure windows and doors. few nights later there were some attempted breakins and damage to doors and windows |
| 22:27:23 | midnightmagic: | Sounds shifty. |
| 22:27:40 | DBordello: | They should have came a few days later |
| 22:27:51 | Dizzle: | HM: how recently was this? If a friend knew you had goxcoins or something, they might have called the cops to come check on you. |
| 22:28:08 | imsaguy: | See, I didn't lose any coins to gox |
| 22:28:14 | imsaguy: | I keep them all safely at mybitcoin.com |
| 22:28:28 | sipa: | :D |
| 22:28:29 | DBordello: | I have mine in deep storage at bitcoinica. No need to ever check up on them |
| 22:28:41 | HM: | Dizzle, if I had Goxcoins I'd want to be committed. |
| 22:29:04 | Guest38327: | I'm still waiting for coins back from mybitcoin.com |
| 22:29:23 | Guest38327: | Guest38327 is now known as BCB |
| 22:30:07 | imsaguy: | BCB: SASL ftw |
| 22:30:28 | BCB: | imsaguy: ??? |
| 22:30:39 | phantomcircuit: | HM, that is quite possibly the most suspicious thing i have ever heard |
| 22:30:45 | midnightmagic: | Luke-Jr: This might make you happy. http://m.torontosun.com/comment/columnists/alan_shanoff/2010/05/14/13956236.html :) |
| 22:30:54 | BCB: | Simple Authentication and Security Layer |
| 22:30:57 | midnightmagic: | Come to Canada.. it's nice up here. We have lots of trees. |
| 22:30:59 | HM: | phantomcircuit, it seemed more suspicious before i typed it |
| 22:31:03 | imsaguy: | BCB: http://freenode.net/sasl/ |
| 22:31:25 | BCB: | imsaguy: english |
| 22:31:27 | BCB: | please |
| 22:31:33 | HM: | phantomcircuit, i live in a road full of elderly, since i moved here a few years back it's been stunning how many coldcallers there are |
| 22:31:45 | sipa: | coldcallers? |
| 22:31:55 | HM: | door salesmen |
| 22:32:03 | midnightmagic: | BCB: You should connect to freenode *with your account name and password as the server password*. You wouldn't have the issue then where you just revealed your IP address to us all. |
| 22:32:13 | imsaguy: | BCB, it auths you before you completely join freenode so that it doesn't show you was guest and it also applies your cloak before joining channels so you don't leak your info |
| 22:32:15 | BCB: | hmm |
| 22:32:31 | BCB: | I'm using znc on a server |
| 22:32:39 | imsaguy: | so your znc would need to use sasl |
| 22:32:41 | imsaguy: | most support it |
| 22:32:41 | BCB: | with Chatzilla |
| 22:32:50 | BCB: | too fucking complicated |
| 22:32:53 | midnightmagic: | imsaguy: Or it can just use SSL and supply the user:pass as the server pass. |
| 22:33:02 | imsaguy: | midnightmagic: true |
| 22:33:11 | BCB: | I probably rebooted my server and didn't rest the config |
| 22:33:37 | HM: | midnightmagic, might be less secure. not sure if znc encrypts server passwords in its config file |
| 22:34:02 | BCB: | what the the linux cmd to check the size of all the files on your server |
| 22:34:14 | BCB: | (before I join #linux to ask) |
| 22:34:20 | HM: | du -sh |
| 22:34:25 | HM: | or df -h |
| 22:34:27 | midnightmagic: | HM: Doesn't really matter: there's no way his client can verify the connection anyway. |
| 22:34:41 | BCB: | HM I'm looking for individual large files not total |
| 22:35:04 | HM: | BCB. find |
| 22:35:31 | HM: | midnightmagic, you could presumably cache the certificate after you accept it? |
| 22:35:44 | imsaguy: | each freenode server has its own wildcard cert |
| 22:35:47 | imsaguy: | its annoying as hell |
| 22:35:58 | HM: | ah |
| 22:36:00 | BCB: | hm find list all the file in the current dir |
| 22:36:14 | sipa: | this is not #unix101 |
| 22:36:15 | imsaguy: | and they're only good for a year, so you spend the first few weeks each refresh verifying and accepting new cets |
| 22:36:26 | BCB: | sipa sorry |
| 22:36:28 | andytoshi: | guys, please try to keep this channel to research |
| 22:36:42 | HM: | I use ZNC as well, i haven't bothered to check anything except all the links at SSL :S |
| 22:36:48 | HM: | i guess it just autoaccepts anything |
| 22:37:05 | HM: | hurray for false sense of security ^_^ |
| 22:37:15 | midnightmagic: | HM: No, I mean BCB himself has no way to verify the znc is behaving normally, so if someone broke into the server, it wouldn't matter if znc encrypted the password or not. |
| 22:37:42 | HM: | normally how? |
| 22:40:54 | HM: | ah i always connect to the same freenode server |
| 22:41:11 | midnightmagic: | HM: Verifying the SSL cert, not short-circuiting to some localhost socat redirector for ease of sniffing, not recompiled and/or modified to divulge nickserv passwords automatically, etc. |
| 22:46:59 | just[dead]: | just[dead] is now known as justanotheruser |
| 22:53:44 | HM: | midnightmagic, i think that gets back to what we were saying about clientside crypto in web wallets |
| 22:53:59 | HM: | if someone gets in to your irc bouncer you're boned from then on |
| 22:54:10 | HM: | but the conversation we had yesterday about taking over the world is safe |
| 22:54:22 | HM: | and if i'm not connected it's pretty useless |
| 22:54:33 | HM: | but if they obtain my nick password they can impersonate you |
| 22:54:40 | HM: | me* |
| 22:54:41 | HM: | etc |
| 22:55:17 | midnightmagic: | andytoshi: Since the channel itself, and connecting to it, are important parts of participating in the channel, I thought it topical or at least important. |
| 23:00:19 | justanotheruser: | justanotheruser is now known as just[dead] |
| 23:06:58 | roasbeef_: | roasbeef_ is now known as roasbeef |
| 23:30:24 | gmaxwell: | gah, this guy is driving me nuts: http://www.reddit.com/r/Bitcoin/comments/1yzil4/i_implemented_gmaxwells/cfpkthi |
| 23:31:38 | gmaxwell: | he really doesn't get it and he's obsessing over "negative balances" in private messages, and when I told him that I wasn't going to discuss it anymore until he went and read the original IRC log his response was to just go post his somewhat broken scheme in public. ::sigh:: |
| 23:44:03 | HM: | hash trees. hash trees everywhere |