| 00:13:01 | jcorgan: | heh: https://mjos.fi/doc/gavekort_kale.pdf |
| 00:14:33 | op_mul: | jcorgan: I think there's some previous wizards discussion on that. |
| 00:14:39 | jcorgan: | ah |
| 00:34:34 | nsh: | .wik XSL attack |
| 00:34:35 | yoleaux: | "In cryptography, the eXtended Sparse Linearization (XSL) attack is a method of cryptanalysis for block ciphers. The attack was first published in 2002 by researchers Nicolas Courtois and Josef Pieprzyk." — http://en.wikipedia.org/wiki/XSL_attack |
| 00:34:59 | nsh: | the less-satirical literature around the subject is pretty interesting too |
| 00:38:01 | op_mul: | an interesting side effect of people writing their own wallets is that cryptanalysis of ECDSA is likey less effective than attacking bitcoin through RC4. |
| 00:41:35 | op_mul: | there's something weird about the fact that our total security is resting on top of a stream cipher that's been known to be weak since the 90s. |
| 00:47:59 | nsh: | since the 80s if you work at the NSA |
| 00:49:59 | op_mul: | regardless it's still weird that anybody would knowingly base their new cryptosystem on RC4. |
| 00:51:24 | nsh: | how does wallet security depend on RC4? communication with bitcoind? |
| 00:51:55 | rusty: | * rusty wants to know too... |
| 00:52:24 | op_mul: | no, almost all transactions today are made with a library called "bitcoinjs" which uses RC4 as it's PRNG. even in the situations where the browser has a CS PRNG, it gets fed through RC4 before being used. |
| 00:52:42 | op_mul: | s/almost all/almost all transactions not made with bitcoind/ |
| 00:57:10 | op_mul: | it also makes some other small mistakes, like using a 32 bit initialization vector for AES. hardly end of the world stuff, but it makes you wonder how much review any of this stuff has had. |
| 00:59:23 | rusty: | op_mul: Hmm if browser doesn't provide CSPRNG then crypto in it seems like a bad idea. |
| 01:00:32 | op_mul: | rusty: people have been told this, I promise you. websites like blockchain.info still don't hard fail and simply just use Math.random() silently. |
| 01:01:33 | rusty: | op_mul: they'd be better relying on the server for seed, at least that reduces the opportunity for theft to a smaller subset of the population. |
| 01:01:44 | antgreen: | jgarzik: you may have noticed that I'm going to a local bitcoin dev meetup Feb 19, and volunteered to speak for 10-15min about moxie/moxiebox. I'm really there to learn, and don't claim to completely understand if/how moxie may be used by bitcoin in the future, but if you have anything more to share by the 19th, be sure to let me know! |
| 01:02:35 | op_mul: | rusty: their security model is 0% trust in the service using client side javascript loaded from a remote server. you can't go doing that! |
| 01:02:51 | op_mul: | rusty: (they do, anyway) |
| 01:04:42 | rusty: | op_mul: I agree they should be hard failing, but marketing >> technology I guess. |
| 01:06:16 | op_mul: | rusty: this is the company that edited their RNG software, made a copy and paste error making it's output have 8 bits of entropy, and then pushed the change straight into production. dripping with incompetence, and oddly not the first time they've broken their RC4 PRNG and lost money doing it. |
| 01:07:08 | rusty: | op_mul: Oh, I didn't know about that one.... |
| 01:08:19 | op_mul: | type error, they didn't initialise an array so the "entropy pool" was exactly one integer wide. |
| 01:12:20 | rusty: | op_mul: That's an easy error to make though, and cursory testing won't reveal it. But you'd hope they'd be a bit more paranoid... |
| 01:13:03 | op_mul: | ಠ_ಠ |
| 01:13:21 | op_mul: | solution is not hiring monkeys. |
| 01:13:33 | rusty: | op_mul: but, hey, it's not their money! |
| 01:14:42 | op_mul: | the story is funnier than that. so they lost 900 BTC. and then the person that stole the money returned it. and then to "verify" people were stolen from and return the money, blockchain.info emailed the affected users and asked them to send in their wallet ID and password in cleartext. |
| 01:16:20 | op_mul: | but the point is more that you shouldn't be making cryptographic changes in production and with no oversight. take a leaf out of NASAs book or something, justify every single line. |
| 01:20:03 | nsh: | * nsh takes a leaf out of NASA's book |
| 01:23:35 | fanquake_: | fanquake_ is now known as fanquake |
| 01:25:10 | op_mul: | and also stop using RC4. |
| 01:47:47 | fanquake_: | fanquake_ is now known as fanquake |
| 02:25:07 | phantomcircuit: | gmaxwell, did hashfast every pay creditors anything? |
| 02:49:43 | Pan0ram1x: | Pan0ram1x is now known as Guest16027 |
| 03:01:55 | gmaxwell: | phantomcircuit: I certantly got nothing. |
| 03:03:09 | phantomcircuit: | i wonder what their bom cost is for a board w/o psu |
| 03:03:24 | phantomcircuit: | downclocked without the liquid cooling nonsense |
| 03:03:51 | phantomcircuit: | actually even downclocked it's still a 400W chip |
| 03:04:20 | phantomcircuit: | er no it's a 100W chip |
| 03:04:42 | phantomcircuit: | i bet they actually do have tons of chips and nobody who wants them |
| 03:06:29 | tacotime__: | they dumped most of the rest of their chips, all they had at the end was their IP pretty much |
| 03:07:11 | tacotime__: | there were some aftermarket boards coming out for a bit. i still get mail from their lawyers. worst investment of my life. |
| 03:09:18 | gmaxwell: | cluestick solicitced: https://bitcointalk.org/index.php?topic=937058.0 |
| 03:11:46 | justanotheruser: | Can truthcoin work? It seems that the cost of keeping a price feeder honest is something no one wants to bear. Be it a small or large contract/bet, people will gravitate towards blockchains where the price feeds are subsidized by them the least leading to very little incentive for the feeds to stay honest. |
| 03:18:31 | jcorgan: | gmaxwell: the paranoia runs deep there |
| 03:18:41 | phantomcircuit: | tacotime__, i wonder if they sold all of the chips or if they really did just dump them? |
| 03:19:05 | sipa: | jcorgan: it's a very legitimate concern |
| 03:19:05 | gmaxwell: | jcorgan: it's a reasonable thing to ask, also not hard to answer; juts better if other clueful people respond. |
| 03:19:27 | instagibbs: | justanotheruser: a little rusty on the truthcoins mechanisms. Could you give a pointer? Thought they were doing SVD or something |
| 03:20:44 | jcorgan: | there are ways to ask about the legitimate concern that don't employ words like "enemy", "NSA-type organizations", and "infiltrate" |
| 03:22:03 | justanotheruser: | instagibbs: SVD on the vote matrix |
| 03:22:05 | gmaxwell: | some people were raised by wolves, some raised by conspiracy theorists. |
| 03:22:13 | justanotheruser: | I'm asking about incentives to have a good vote matrix |
| 03:22:18 | instagibbs: | justanotheruser: right |
| 03:22:19 | instagibbs: | ah |
| 03:22:21 | instagibbs: | who knows |
| 03:22:27 | instagibbs: | that's obviously the best question to ask |
| 03:23:16 | instagibbs: | they are attempting a sort of split of responsibilities, but why wouldn't having a really large stake just let them punish people who vote against them |
| 03:23:28 | justanotheruser: | I don't know why I said price feeds |
| 03:23:43 | justanotheruser: | Mixing up bitshares terminology |
| 03:24:12 | instagibbs: | yeah I mean it's an interesting experiment. I really like the composable bet structure |
| 03:24:27 | instagibbs: | something I'd probably lose tons of time and money on :D |
| 03:25:25 | justanotheruser: | another thing is delegates only have so much bandwidth. One set of delegates can only be price feeds for a few things. |
| 03:26:13 | justanotheruser: | I'm guessing that means the incentive can't get massive |
| 03:29:52 | instagibbs: | issue is if some malicious actor gets 100% of any particular bet, they can clean house. I'll have to re-read their stuff; too rusty on specifics |
| 03:30:07 | instagibbs: | err 100% of the staking or whatever |
| 03:37:08 | justanotheruser: | instagibbs: I don't think the matrices will be defined such that you will even need 100% |
| 04:03:17 | Imposter: | Imposter is now known as imposter |
| 05:57:39 | Taek: | instagibbs, justanotheruser: currently you could clean house with 51% I think. There were plans to raise it to 70% or something, but that has it's own tradeoffs (70% to clean house, 30% to stall everything) |
| 05:58:06 | Taek: | But, if you chose to clean house, everyone will know because the votes will obviously be a lie |
| 05:58:18 | Taek: | that means that the entire voting pool's value will drop to 0 and nobody will ever use it again |
| 05:58:25 | Taek: | being a part of a voting pool is profitable |
| 05:58:52 | Taek: | Truthcoin attempts to defend against this attack by making it more profitable to be a long term successful pool than to clean house one time |
| 05:59:17 | Taek: | Even if you could clean house, you wouldn't want to b/c you'd make more money just by sitting on your giant portion and voting honestly for a few months |
| 07:56:28 | fanquake_: | fanquake_ is now known as fanquake |
| 08:05:54 | lclc_bnc: | lclc_bnc is now known as lclc |
| 09:05:16 | weber.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:16 | weber.freenode.net: | Users on #bitcoin-wizards: andy-logbot orik p15 p15__ Starduster hearn RoboTeddy damethos GibsonA justanotheruser fanquake siraj c0rw1n gribble coiner shesek binaryatrocity ryanxcharles Emcy wiz Sub|afk Adlai` hashtag TheSeven e1782d11df4c9914 imposter instagibbs adam3us Guest16027 PRab Dr-G3 dasource K1773R antgreen copumpkin CryptOprah artifexd Muis kumavis jgarzik go1111111 mappum d1ggy nsh MoALTz Tjopper platinuum Oizopower kyletorpey jbenet michagogo devrandom spinza |
| 09:05:16 | weber.freenode.net: | Users on #bitcoin-wizards: waxwing comboy harrow coryfields bepo_ optimator nuke1989 huseby weex nullbyte ebfull catcow btc___ PFate delll_ nick1234abcd__ davout phedny HM2 so Meeh jcorgan brand0 NikolaiToryzin Fistful_of_Coins luny CodeShark Aquent xabbix mortale epscy_ Aesthetic EasyAt jaromil mr_burdell forrestv amiller TD-Linux midnightmagic cfields Dyaheon sdaftuar_ bobke__ Anduck espes___ Eliel_ grubles Luke-Jr morcos le_killer veox nanotube Iriez s1w [d__d] |
| 09:05:16 | weber.freenode.net: | Users on #bitcoin-wizards: stonecoldpat Keefe gavinand1esen sl01_ Cory bbrittain tacotime__ petertod1 PaulCapestany maaku HaltingState mkarrer cryptowest [\\\] bosma Hunger- Graftec BananaLotus gmaxwell tromp__ qwopqwop_ roasbeef_ DoctorBTC jaekwon sipa smooth starsoccer iddo @ChanServ Xzibit17 Alanius null_radix ryan-c ajweiss wizkid057 hollandais warren otoburb ahmed_ phantomcircuit lechuga_ Apocalyptic kinlo andytoshi gwillen gnusha burcin a5m0 btcdrak sneak wumpus |
| 09:05:16 | weber.freenode.net: | Users on #bitcoin-wizards: BrainOverfl0w hguux_ yoleaux lnovy tromp_ deego warptangent d9b4bef9 berndj crescend1 Taek azariah eric BlueMatt livegnik isis asoltys_ LarsLarsen Krellan pigeons catlasshrugged fluffypony kanzure heath poggy lclc dansmith_btc JonTitor yrashk fenn Adrian_G nickler_ throughnothing helo Graet MRL-Relay earlz brad___ |
| 09:36:28 | lclc: | lclc is now known as lclc_bnc |
| 10:13:30 | lclc_bnc: | lclc_bnc is now known as lclc |
| 11:27:45 | fanquake_: | fanquake_ is now known as fanquake |
| 11:37:45 | lclc: | lclc is now known as lclc_bnc |
| 11:42:18 | lclc_bnc: | lclc_bnc is now known as lclc |
| 11:58:17 | lclc: | If I store Gold and issue it as Colored Coins, how could I collect storage fees? |
| 11:59:04 | lclc: | Could I define it in the colore kernel? e.g. that the value of one of those colored coins is first 1g each and then decreases by 1% or so each year? |
| 12:02:28 | lclc: | or in the asset contract actually |
| 12:20:23 | fanquake_: | fanquake_ is now known as fanquake |
| 12:38:03 | Luke-Jr: | lclc: obviously you can define it any way you want. another possibility might be to have a "redemption fee" rather than storage fee |
| 13:11:49 | petertod1: | petertod1 is now known as petertodd |
| 14:23:12 | andytoshi: | http://arxiv.org/pdf/1406.5694v3.pdf <-- PoS paper which cites my work then almost immediately says "we need to introduce trust to avoid this" :) page 11 |
| 14:24:15 | andytoshi: | it's quite refreshing to see that laid out |
| 14:24:54 | andytoshi: | it does then say "bitcoin has checkpoints too" tho :( |
| 14:37:32 | nsh: | is there something you can point the author at that concisely unwrongthinks the checkpoint misunderstanding? |
| 14:38:02 | gmaxwell: | the right thing is to get them out of the reference software and not worry about this anymore. |
| 14:39:22 | gmaxwell: | There isn't a better way, obviously people are going to willfully ignore the difference between something set only in new manually updated software fixed thousands of blocks back vs some crazy block signing scheme. |
| 14:39:52 | nsh: | * nsh nods |
| 14:40:04 | instagibbs: | to be fair they mentioned in the paper that headers-first is a big step going away from checkpoints |
| 14:40:56 | Eliel_: | why not just support a checkpointless mode for those who don't like them? :P |
| 14:41:09 | Eliel_: | that is, a command line option for it |
| 14:41:21 | gmaxwell: | Eliel_: uh we do. but thats stupid and doesn't do anything to address the problem. |
| 14:41:58 | gmaxwell: | The post headers first checkpoints are not really needed for anything important now, all they do is confuse the security model. |
| 14:42:25 | lclc: | lclc is now known as lclc_bnc |
| 14:42:36 | sipa: | nsh: "if checkpoints, as currently used in bitcoin core, fail, the consensus logic hash failed, and the checkpoint won't fix it. They are there because they were needed for a performance optimization, and nothing more." |
| 14:43:01 | gmaxwell: | well performance and DOS attack avoidance. |
| 14:43:05 | hearn: | and also to ensure you don't end up on a bogus chain if you initialise from scratch with a totally sybilled p2p network |
| 14:43:23 | gmaxwell: | hearn: a total work threshold achieves that even better. |
| 14:43:26 | sipa: | hearn: right, that's the DoS avoidance |
| 14:43:35 | hearn: | sure |
| 14:43:38 | nsh: | * nsh nods |
| 14:43:45 | sipa: | as soon as you connect to an honest node, you'll find the correct chain anyway |
| 14:44:00 | sipa: | but yes, checkpoints avoid wasting time and memory on a bogus chain before that time is reached |
| 14:45:32 | instagibbs: | forgive me but what does the checkpoint do exactly then? Just say "download this chain first" |
| 14:47:49 | hearn: | forces hash at a particular height to be equal to a given value |
| 14:47:54 | hearn: | if it's not the block is considered invalid |
| 14:47:57 | hearn: | (this is for Core/full nodes) |
| 14:48:11 | hearn: | (for SPV clients they have their own notion of checkpoints which is used for different purposes) |
| 14:49:12 | lclc_bnc: | lclc_bnc is now known as lclc |
| 14:50:20 | nsh: | it says when this version of the reference client was released, these here points way back in history were uncontroversially canonical and if you get to that point in history and don't see this block's hash, you might want to start asking for more opinions |
| 14:50:34 | nsh: | is that relatively accurate? |
| 14:53:00 | Eliel_: | nsh: that sounds pretty much like what I've read in the past. |
| 14:53:07 | instagibbs: | huh. |
| 14:54:15 | Eliel_: | nsh: although, I'd probably phrase it such that "if you don't see this particular hash, you should assume something is seriously wrong and refrain from transacting until you've figured out what's going on." |
| 14:54:59 | nsh: | right, i mean, you shouldn't really be transacting at this point as you haven't verified back to the genesis block |
| 14:55:21 | nsh: | and by really i mean at all |
| 15:02:49 | Eliel_: | no, I mean, in that case, you should refrain from transacting even if it looks like you've done full verification |
| 15:04:55 | instagibbs: | Ok so the checkpoint rejects blocks as invalid even in the presence of superior length of work. This is only really needed for bootstrapping nodes, as large re-orgs already get alarms |
| 15:05:57 | gmaxwell: | Eliel_: yea, that part of what I was suggesting we change to, gate ecdsa validation by blocks having a work advantage of X over the best exclusive fork; and then total difficulty or particular blocks just as a wallet safe mode feature. |
| 15:08:47 | instagibbs: | gmaxwell: still nagging me. How can you say "even though checkpoints do nothing relative to consensus" when default nodes will reject a longer chain, while possibly other nodes won't and will follow the most work rule? Or does this literally only happen on bootstrap? |
| 15:10:38 | gmaxwell: | instagibbs: I'm confused by your quotation, where did I say that? |
| 15:11:02 | instagibbs: | sorry digging up old bct threads from googling about this question: https://bitcointalk.org/index.php?topic=194078.20 |
| 15:13:37 | gmaxwell: | instagibbs: Thanks. The reason they do nothing in theory is that they can only be added by users updating their software (manually), and are as a matter of policy set thousands of blocks back and not when there is an existing race. So in _practice_ they are not for consensus purposes, they inhibit dos/partitioning attacks and help a performance optimization. If they were setting the consensus I |
| 15:13:43 | gmaxwell: | (and I think anyone working on bitcoin core) would consider that a a complete failure of the system. |
| 15:14:26 | instagibbs: | Got it. |
| 15:14:52 | gmaxwell: | Unfortunately, because they would have additional consensus effects in those failure situations, people justify straight up centeralized approaches on the basis of them. So we should move to using other mechenisms for the things we intend checkpoints to accomplish in order to avoid the confusion. |
| 15:15:15 | gmaxwell: | Doing so just takes work, the hardest part of that was headers first which has just been finished. |
| 15:15:37 | gmaxwell: | andytoshi: nice post, https://bitcointalk.org/index.php?topic=937058.msg10278072#msg10278072 thanks |
| 15:17:48 | NewLiberty: | Some later experimental work on checkpoints advanced this by making them more easily user managable, and providing additional options for authoritative checks. Altcoin Monero implemented these. |
| 15:18:58 | andytoshi: | thx gmaxwell. i maybe should've added some elaboration on the timing attack resistance (e.g. all the code is branchless) but i guess i don't have a super technical audience |
| 15:19:16 | andytoshi: | mainly i wanted to list a ton of stuff to say "there are people thinking about this, and more than briefly" |
| 15:22:27 | gmaxwell: | NewLiberty: I don't think thats interesting or helpful in general. |
| 15:23:32 | NewLiberty: | It defeats the criticism of "this violates the principles of Bitcoin" handidly. decentralizing it |
| 15:24:11 | gmaxwell: | NewLiberty: I don't really agree. There are a lot of things you can do which are just decenteralization theater... making the centeralization you actually get harder to analyize and secure against. |
| 15:25:03 | gmaxwell: | E.g. if you have some plug in some magic value thing, what are people going to do? they're going to go to magicvalue.info and plug in whatever it gives them. You've just obfscuated the trust that would exist _in practice_ with some smoke and mirros that say "well it's not really required". |
| 15:25:07 | NewLiberty: | It does that too. DNSsec validation, and also provides for out-of-band updates if git is comromised for example. No need for full recomplies to update them , etc. |
| 15:25:55 | NewLiberty: | It may look stupid if you dig in to it only a foot, but when you see it all, it is robust |
| 15:26:08 | gmaxwell: | The really honorable citation is |
| 15:26:08 | gmaxwell: | 01:57 <@fluffypony> which goes back to the thing we continually say: Monero is not a decentralised cryptocurrency right now. It has the potential to be in future, but right now it's just an experiment |
| 15:26:34 | NewLiberty: | that is still true ofc |
| 15:27:06 | fluffypony: | MoneroPulse checkpoints aren't enforced by default |
| 15:27:19 | fluffypony: | you'll get notified in big red letters if you're on a fork |
| 15:27:22 | gmaxwell: | In any case, its so that some interesting things are interesting; it's just also easy to fall into the trap of decenteralization theater. |
| 15:27:41 | fluffypony: | you can enable enforcing if you run an unattended node, but it's off by default |
| 15:28:57 | gmaxwell: | Thats kind of bleh, since if its ever enforced it has a lot of power; but there are reasons in that case to do it. (the centeralization is justified considering the state of the maturity of the system) |
| 15:29:19 | fluffypony: | well the use-case is simple |
| 15:29:27 | fluffypony: | the majority won't turn enforcement on |
| 15:29:32 | gmaxwell: | Though on that basis it might well be better if it were default, since then there wouldn't be any decenteralization-theater about it. |
| 15:30:06 | gmaxwell: | fluffypony: if a significant amount of miners are (who have strong economic incentives to not get 'left behind') then it's basically as good as if everyone did. |
| 15:30:30 | NewLiberty: | ^^ |
| 15:30:57 | fluffypony: | yeah, but it doesn't negate hardcoded checkpointing or file checkpointing |
| 15:32:02 | gmaxwell: | at an extreme you can dispense with the blockchain entirely and say "well users can just set which sets of transactions they'll consider valid." :) |
| 15:32:44 | fluffypony: | yeah, and at another extreme we could have the extreme centralisation of Bitcoin's alert system |
| 15:32:45 | NewLiberty: | y |
| 15:33:03 | fluffypony: | which, thankfully, we've foregone |
| 15:33:26 | hearn_: | hearn_ is now known as Guest465 |
| 15:34:43 | gmaxwell: | fluffypony: lol, a thing that displays a message which has no effect and which everyone ignores is "extreme centralisation" but a system where broadcast signatures forces "unattended" (e.g. miners) onto paritcular chains, is not? come on. |
| 15:35:13 | fluffypony: | it was tongue-in-cheek, but I think the point has been made |
| 15:36:18 | fluffypony: | if someone goes and sends an alert and say that X has been compromised and please urgently upgrade to this binary from Y you know that there will be a super-majority that will blindly comply, especially if it's pitched a certain way |
| 16:17:53 | pgokeeffe_: | pgokeeffe_ is now known as pgokeeffe |
| 16:22:08 | Pan0ram1x: | Pan0ram1x is now known as Guest64830 |
| 16:34:18 | krikey: | Hello. Im sure you get asked this question a lot. Im trying to configure and install Alethzero on windows 7 but struggling. Is there a working compiled executable that I can use or so I have to "roll my own"? |
| 16:35:32 | krikey: | the exectuable I have (POC6) will ot connect to the default peer |
| 16:35:43 | krikey: | should I be using another Peer? |
| 16:36:40 | kanzure: | wrong channel |
| 16:55:52 | krikey: | krikey has left #bitcoin-wizards |
| 17:06:21 | Adlai`: | Adlai` is now known as adlai |
| 17:24:04 | lclc: | lclc is now known as lclc_bnc |
| 20:29:21 | nullbyte_: | nullbyte_ is now known as Guest50863 |
| 20:49:22 | roidster: | roidster is now known as Guest71701 |
| 21:54:05 | op_mul: | fluffypony: in the event that the alert key is misused, anybody else who has it can send a maximum sequence alert. this prevents any further use and replaces the message with "alert key compromised". |
| 21:54:45 | fluffypony: | op_mul: too late, those that took action will already be compromised |
| 21:55:24 | op_mul: | I highly doubt anybody pays attention to alerts. I've spoken to many companies who don't even monitor them. |
| 21:56:05 | fluffypony: | so then the same argument can be made for MoneroPulse |
| 21:56:14 | fluffypony: | the discussion was contextual. |
| 21:57:09 | fluffypony: | also is anyone else dealing with the glibc-pocalypse ? |
| 21:57:25 | helo: | op_mul: bitcoin companies that don't monitor alerts? |
| 21:58:01 | helo: | fluffypony: luckily we don't run anything that allows user-input dns |
| 21:58:13 | nsh: | fluffypony, what constitutes 'dealing with'? does casual detatched bemusement count? |
| 21:58:36 | fluffypony: | I'm finding all sorts of interesting bits and pieces in some of my servers that are calling GHOST |
| 21:59:06 | nsh: | calling gethostbyname, you mean? |
| 21:59:39 | fluffypony: | yes - meant GHBN |
| 21:59:43 | fluffypony: | or GHBN2 |
| 21:59:44 | nsh: | (actual code doesn't reference stupid allcaps marketing petnames for vulnerabilities ;) |
| 21:59:54 | op_mul: | helo: I've asked a couple directly. I expected people to be triggering a safe mode of their service from the -alert bitcoind trigger, but nope. one monitors their block heights and goes into a safe mode when they get behind, which is nice. |
| 22:00:12 | helo: | :/ |
| 22:00:41 | fluffypony: | nsh: I forget, are we calling this one GHOST or heartleech? I've heard both :-P |
| 22:00:43 | helo: | seems like a rudimentary step to take |
| 22:00:47 | NewLiberty: | CVE-2015-0235 |
| 22:00:47 | nsh: | * nsh smiles |
| 22:01:10 | nsh: | fluffypony, anyway, we're pretty O/T. better to discuss this in ##security or something |
| 22:01:20 | kanzure: | ##nosecuritys |
| 22:01:40 | fluffypony: | security theatre! |
| 22:02:21 | op_mul: | helo: seeing that blockchain.info now supports searching by BIP32 MPK, and I've now seen 2 companies saying they will add "sending to" MPK if the user gives it up, we shouldn't developers to be doing anything sane :( |
| 22:02:43 | kanzure: | "gives it up"? |
| 22:02:48 | helo: | yeah... |
| 22:03:01 | op_mul: | like, puts their MPK into the "send to bitcoin address" textbox. |
| 22:04:06 | helo: | low hanging data rich core dev fruit, ignored |
| 22:07:15 | gwillen: | op_mul: every day we get more evidence for the proposition "if you don't want people doing something stupid, make sure you make it impossible" |
| 22:08:03 | gwillen: | (i.e. the MPK could have been made into an object that doesn't look like a key you can send to, at the expense of adding totally unnecessary complexity) |
| 22:08:04 | adam3us: | gwillen: another version is if thats not possible (making it impossible) you may actually have to code for them for free otherwise they'll insist on doing the stupid thing because its easier :) |
| 22:08:10 | gwillen: | hah, yeah |
| 22:08:26 | gwillen: | although if the stupid thing really is easier you still lose unless you write the code in every language for every framework |
| 22:08:30 | gwillen: | and even then someone will _still_ reimplement it |
| 22:08:41 | op_mul: | gwillen: that doesn't seem to work. bip38 was proposed but is a totally insane idea. the bip was never finalized as a result. now it's a "standard", where people are writing wallets around these "high security" keys which are nothing of the sort. |
| 22:10:18 | Eliel_: | is there a good article somewhere highlighting what's wrong with bip38? |
| 22:10:39 | gwillen: | op_mul: but BIP32 was not insane and was finalized, so it could have been written differently (purely in retrospect) |
| 22:11:20 | op_mul: | yes. calling the MPK "master public" was a mistake. |
| 22:11:22 | gwillen: | if BIP32 had been written in a way that obfuscated the MPK, even if it was secretly still there but never computed directly, e.g. |
| 22:11:25 | gwillen: | * gwillen nods |
| 22:11:46 | gwillen: | but probably it would have been expecting too much for the authors of BIP32 to forsee this |
| 22:12:00 | Eliel_: | You can't predict every stupid idea people will come up with, unfortunately. |
| 22:12:03 | gwillen: | right |
| 22:12:14 | gwillen: | but it's evidently worth being defensive about them |
| 22:14:09 | Eliel_: | yes, I agree with that |
| 22:33:28 | op_mul: | the fun thing is I suppose. all the more data for me. |
| 22:50:20 | roidster: | roidster is now known as Guest71993 |