| 00:09:34 | midnightmagic: | "Novel" huh. |
| 00:13:59 | BlueMatt: | Taek: bad idea. |
| 00:18:58 | Starduster: | Starduster is now known as benjamintrees |
| 00:20:17 | benjamintrees: | benjamintrees is now known as Starduster |
| 00:24:00 | Taek: | BlueMatt, gavin had earlier expressed that he thought thought that 'it might be genius' (I don't think he was being sarcastic). He told me to ask about it later, as he was busy. |
| 00:26:52 | adam3us: | so did anyone figure anything further on parameters and privacy of the simple & greatly improved idea of computing a bloom filter on the block rather than the query (which seems to lead to bad tradeoffs and probable ongoing privacy breakdown - the anonymity set utxo is varying and the params are not) |
| 00:28:42 | gmaxwell: | Not really, it looks like its a huge win for performance/bandwidth if you're scanning more keys than there are txouts in a block. And a moderate loss in bandwidth. (Obviously its always a privacy win) |
| 00:29:06 | gmaxwell: | just needs implementation now. |
| 00:29:53 | adam3us: | someone should do that :) its a very cool development. its amazing really that no one thought of it before. |
| 00:31:37 | adam3us: | another question is reusable addresses. i dont think bloom on blocks helps the privacy leak from stealth + address prefix. and my IBE address proof of concept adds a dependency on weil-pairing and slower to verify signatures |
| 00:32:19 | adam3us: | it would be ideal to have a reusable address that is scannable via the bloom block or related precomputed committed data structure. |
| 00:32:28 | adam3us: | while preserving privacy. |
| 00:34:54 | sipa: | * sipa needs to write up a proposal for reusable payment requests |
| 01:08:43 | AdrianG: | I have a serious question. |
| 01:08:50 | AdrianG: | how will the problem of custody ever be sold with bitcoin? |
| 01:08:55 | AdrianG: | with physical commodities, ownership = custody |
| 01:09:28 | AdrianG: | you can own a private key, but such ownership does not automatically exclude the possiblity someone else might own the same key, and move your coins any second now. |
| 01:10:51 | gmaxwell: | if you generated the private key, and told no one else, then you know no one else has it. |
| 01:10:57 | gmaxwell: | (with exponential probability) |
| 01:11:20 | gmaxwell: | (and nothing in life is certian, a meteor could hit you on the head 5 seconds from now...) |
| 01:11:29 | lechuga_: | :o |
| 01:11:57 | gmaxwell: | (with WAY greater likelyhood than you generating the same key as someone else, assuming you're using software which is extensively reviewed and tested and free of systematic flaws) |
| 01:12:05 | AdrianG: | gmaxwell: yes, but how do i prove to others? |
| 01:12:10 | AdrianG: | that i never told anyone? |
| 01:12:42 | gmaxwell: | You don't, and doing so isn't that important-- I mean if you're going to _lie_ than you could just steal the funds yourself. |
| 01:13:11 | lechuga_: | potentially dumb question but why would u want a reusable payment request |
| 01:13:21 | AdrianG: | gmaxwell: why do you think its not important? |
| 01:14:01 | gmaxwell: | lechuga_: because people sometimes want to make reoccuring payments to another party, or refunds, without expecting there to constantly be synchrnous realtime communication with the other party. You might even want to pay someone you only have one way communication with (e.g. a donation). |
| 01:14:05 | AdrianG: | we have thousands of years of law decisions about custody, its a socially important concept |
| 01:14:41 | phantomcircuit: | i guess the only real question for bloomfilters per block is what the parameters should be |
| 01:14:47 | gmaxwell: | AdrianG: I just explained to you why it's not important. Your custody is your claim. You can be dishonest with that claim, but you can also take an object you physical have and give it to someone else or drop it in an incenerator. |
| 01:15:01 | phantomcircuit: | possibly they should be variable based on the number of entries/length of those entries |
| 01:15:48 | gmaxwell: | phantomcircuit: well there are some oher interesting considerations. For example, it may be interesting to shard the blocks filtering, e.g. N filters for the block, and sort the txn into the shards based on common filter hits, so as to allow people to check only part of a block. |
| 01:16:15 | lechuga_: | couldn't you set expires sufficiently high and re-use away as-is? |
| 01:16:21 | lechuga_: | re: payreqs |
| 01:16:23 | phantomcircuit: | yeah i was also thinking that maybe a very tiny filter for each txn might also make sense |
| 01:16:29 | phantomcircuit: | but that doesn't seem super practical |
| 01:16:34 | AdrianG: | gmaxwell: if we can establish custody with certainty, a liar cannot assert defense that his keys were compromise |
| 01:16:44 | AdrianG: | we would know they weren't, and he is indeed lying. |
| 01:16:55 | AdrianG: | compromised* |
| 01:17:16 | lechuga_: | guess you would want to sign that it is expected to be reused |
| 01:17:37 | phantomcircuit: | AdrianG, you cannot prove that you did not produce a copy of the private key to a third party |
| 01:17:45 | phantomcircuit: | you maybe can approximate that with hardware DRM |
| 01:17:55 | phantomcircuit: | but that would be imperfect for certain |
| 01:17:59 | AdrianG: | phantomcircuit: i know, i think its a "problem" to an extent. |
| 01:18:08 | gmaxwell: | lechuga_: that forces you to reuse addresses (which has risk of blocking by miners and systemic risk from creating an incentive to demand miners block things), and doesn't let you set parameters around it. Reusing an existing payment request might be dangerous, since the reciever may not retain private keys forever, or could have accounting that can't handle the unexpected payments. So you want |
| 01:18:15 | gmaxwell: | the reciever to set what his rules are. You migth break the rules, but thats potentially equal to just dumping the coins to /dev/null. :) |
| 01:18:18 | AdrianG: | in common law, fiduciary duty is rather important. |
| 01:18:30 | phantomcircuit: | AdrianG, in practice custody of physical things has to do with socially accepted signs of custody and nothing more |
| 01:18:41 | AdrianG: | without even being able to figure out who has custody over things, things become complicated |
| 01:18:45 | phantomcircuit: | the rules are indeed very poorly defined |
| 01:18:52 | AdrianG: | phantomcircuit: rules of custody? |
| 01:19:09 | phantomcircuit: | AdrianG, fiduciary duty is a concept which is entirely unrelated to bitcoin |
| 01:19:21 | phantomcircuit: | that's an abstraction on top of any money system |
| 01:19:36 | lechuga_: | ic so reusable payreqs are going to require some sort of pubkey derivation |
| 01:20:06 | phantomcircuit: | you can utilize multisig to improve the controls in place for fiduciaries but you cannot possibly hope to encapsulate all of the rules of such into any reasonable system |
| 01:20:13 | AdrianG: | phantomcircuit: yes, but physical money are a lot more workable in this case |
| 01:20:21 | AdrianG: | with bitcoin, i cannot even be 100% certain nobody stole my private key |
| 01:20:33 | AdrianG: | so i cant even be 100% certain my coins are really mine. |
| 01:20:33 | gmaxwell: | AdrianG: I think you're imaginging a distinction that doesn't exist. Someone can have a physical object, and yet someone can steal a physical object. ... you can even fail to know that an object is stolen yet. Nothing is different there, except the specific details about how you go about checking things. To be confident of custody of a bitcoin, you move it. (thats why transfers between distrus |
| 01:20:39 | gmaxwell: | ting parties always move the coins). |
| 01:20:41 | sipa: | lechuga_: yup |
| 01:20:49 | phantomcircuit: | AdrianG, counterfeit swaps are a thing that insiders actually do with cash |
| 01:21:00 | sipa: | lechuga_: stealth addresses, but using out of band communication rather than blockchain storage |
| 01:21:16 | AdrianG: | phantomcircuit: what does that have to do with custody and fiduciary duty? |
| 01:21:23 | lechuga_: | interesting |
| 01:21:38 | AdrianG: | gmaxwell: so in order for me, to be 100% certain my coins are still my coins |
| 01:21:43 | AdrianG: | I must move them every now and then? |
| 01:21:45 | phantomcircuit: | AdrianG, you cannot trivially prove control of cash either |
| 01:21:54 | gmaxwell: | lechuga_: yea, the idea is that the payment request basically includes the relevant information to establish a novel HD-wallet chain for that request. |
| 01:22:03 | phantomcircuit: | at least with bitcoin you can continuously move the funds to new addresses which have newly generated private keys |
| 01:22:08 | AdrianG: | phantomcircuit: paper no, electronic cash is very trackable. |
| 01:22:19 | gmaxwell: | AdrianG: yes, thats how you 'observe' ownership with bitcoin. Just like your hope diamond in a box requires you to open a box (thus interacting with it), to be sure you really have it. |
| 01:22:22 | AdrianG: | but paper cash is miniscule vs electronic funds. |
| 01:22:30 | sipa: | lechuga_: and the payment request contains an encryption key, which the signer encrypts the whole payment message too, so if the data is not received, coins don't move |
| 01:22:56 | AdrianG: | gmaxwell: hehe how very quantum |
| 01:23:46 | gmaxwell: | Same model is used for chaum token digital cash: You only know the funds are yours when you ask the server to swap out a new token. |
| 01:24:44 | kanzure: | you don't prove to anyone that you never told others, that's not the point |
| 01:24:56 | kanzure: | just as others don't need to prove to you that others don't know their private key |
| 01:25:50 | lechuga_: | sipa: where does the payment message go if there is no synchronous channel |
| 01:26:00 | sipa: | lechuga_: a mailbox |
| 01:26:03 | gmaxwell: | Well for example, with a hope-diamond-in-a-box you can prove you have it _now_ by opening the box (moving the coins), but you cannot prove that you didn't help someone steal it (or lose it) while the box is closed. You can show them your security practices to increase confidence though. |
| 01:26:29 | sipa: | lechuga_: given that the message is encrypted, the mailserver being compromised doesn't result in theft, and which sufficient precautions, not even loss of privacy |
| 01:26:56 | sipa: | (i say mailbox in an abstract sense; it doesn't have to actually be SMTP) |
| 01:27:27 | lechuga_: | ic |
| 01:27:31 | gmaxwell: | lechuga_: basically the scheme needs some kind of dropbox for encrypted messages. It can have a hiererchy like, "send the request to all of the following places" one of which could be you directly if you're online or email. Part of the design that we haven't considered much is that there may be a snazzy way to use bitcoin e.g. proof of owernship of coins to help make the mailbox DOS attack resis |
| 01:27:37 | gmaxwell: | tant. |
| 01:28:25 | sipa: | one downside is that you can't rely on the sent coins to actually move, so the sender needs a way to recover (by double-spending, or by using a 1-of-2 output to himself) |
| 01:28:51 | sipa: | another is that there is no instant confirmation that the message is received, and thus no means to return a message back |
| 01:28:55 | lechuga_: | there is a public rsa key in a payment request already, can;t that be used? |
| 01:29:33 | sipa: | there is just a certificate, by a certificate authority |
| 01:29:49 | sipa: | eh, signature |
| 01:30:30 | sipa: | i'm confusing things; but no, i'd prefer not to use that - you want to be able to issue payment requests between individuals, without needing a CA |
| 01:30:43 | lechuga_: | makes sense |
| 01:30:47 | sipa: | it's a different layer |
| 01:30:51 | lechuga_: | nod |
| 01:31:08 | sipa: | one is about making sure that (if you trust the payment request) -> (you can safely transact) |
| 01:31:11 | AdrianG: | gmaxwell: the problem is that it costs absolutely nothing to open the diamond box. moving btc thru the network quickly costs money. |
| 01:31:25 | sipa: | the other is about making you trust the payment requestr |
| 01:32:08 | lechuga_: | yeah and presumably u might want very different acls on who has the private key |
| 01:32:27 | lechuga_: | for one use vs. the other |
| 01:33:01 | lechuga_: | sry, sometimes have a bad habit of asking a question b4 thinking enough |
| 01:33:18 | gmaxwell: | AdrianG: oh it absolutely has a cost to open the box: you suffer increased risk of damage or theft, you take the labor to actually go do it, have it observed, and also for the additional security required around the opening. |
| 01:34:48 | Eliel_: | AdrianG: in practise, unless the imagined attacker has a reason to assume you'll be adding coins to the account, it makes no sense not to take the coins immediately if they manage to find a private key with access to bitcoins. |
| 01:35:02 | sipa: | lechuga_: right, you could separate them entirely; the encryption key may be a of a payment processor (which acts on the received money), which can be different from the issuing server (which may be even different from the actual key needed to spend the coins) |
| 01:36:39 | lechuga_: | yup |
| 01:37:50 | AdrianG: | Eliel_: at the moment its a purely theoretical/legalese concern for me, I don't have a very good scenarios where the attacker would wait. |
| 01:37:52 | lechuga_: | so the payer is going to pick a nonce and include that in their encrypted payment i guess |
| 01:38:08 | lechuga_: | maybe it's tweaked contracthashtool-style with their refund address |
| 01:38:41 | Eliel_: | AdrianG: the only scenario where waiting makes sense is if stealthiness is more valuable than the coins in the address. |
| 01:39:16 | lechuga_: | will be interesting to read the writeup |
| 01:40:26 | AdrianG: | Eliel_: i think such scenarios can be plausible. i have to think of good, relevant examples. |
| 02:02:29 | phantomcircuit: | Eliel_, except that actually we have seen in practice very weak keys not being stolen immediately |
| 02:02:58 | phantomcircuit: | indeed there has been some discussion around taking the small amounts at very weak addresses to protect people |
| 02:03:04 | phantomcircuit: | since it would immediately be obvious |
| 02:03:19 | gmaxwell: | phantomcircuit: the brainwallet stuff is a bit different thought since those uses systematically reuse addresses. |
| 02:03:32 | gmaxwell: | And the brainwallet cracker people are all yelling at each other to not steal the small amounts. |
| 02:03:44 | gmaxwell: | (using BC.i messages) |
| 02:03:44 | phantomcircuit: | hmm |
| 02:03:48 | phantomcircuit: | yeah i guess that's fair |
| 02:04:20 | gmaxwell: | hm. I guess this is an argument against HD wallets... less incentive to reveal that your keys are leaked early. |
| 02:04:26 | gmaxwell: | Because they're not forward secure. |
| 02:04:58 | phantomcircuit: | personally i think hd wallets are just too complicated for most people to use correctly |
| 02:05:14 | phantomcircuit: | and building wallet software that makes it even possible is non trivial |
| 02:05:19 | phantomcircuit: | much less being easy |
| 02:08:05 | gmaxwell: | Depends on what you mean. |
| 02:08:18 | gmaxwell: | It's no different to the user than existing wallets, except with a simpler backup scheme. |
| 02:08:42 | gmaxwell: | Sadly there is _nothing_ that does proper key management for them. (e.g. achieving forward security by having an ability to rotate the things.) |
| 02:10:33 | phantomcircuit: | well i think it's not exactly obvious to people that you lose forward secrecy if a single key is compromised |
| 02:10:42 | phantomcircuit: | so that would have to be made obvious |
| 02:10:58 | phantomcircuit: | and tools would have to be added to the wallet to mark a key as compromised |
| 02:11:24 | gmaxwell: | Right. This is actually not that complex. Just ... well no one making wallet software is really ... aware of these concerns it seems. :( |
| 02:11:30 | gmaxwell: | "move fast, break things" |
| 02:12:11 | phantomcircuit: | gmaxwell, it's not that complex, but it's definitely more complex |
| 02:13:12 | gmaxwell: | Yes, well you need to handle multiple master keys, and keep track of when they were backed up, and have a rotation policy. Handling compromise isn't so hard, since you just keep track of which one you're using. |
| 02:17:19 | phantomcircuit: | gmaxwell, sure, but the rest of the wallet can be very simple |
| 02:17:53 | phantomcircuit: | (address, private key) tuples are small |
| 02:18:07 | phantomcircuit: | so generating and saving lots of them in advance shouldn't be that expensive |
| 02:18:23 | phantomcircuit: | bbl |
| 03:32:26 | op_mul: | phantomcircuit: I’ve actually revised my feelings about BIP32 for any purpose other than split-key storage. I don’t think wallet developers are capable of implementing responsible way that won’t lead to people losing money. they either don’t understand, or don’t care how much trouble they are causing. |
| 03:33:36 | op_mul: | a feeling spread by bitcointalk and reddit is that you are able to happily import and export keys from any wallet, and those which don’t allow you to are somehow robbing you of your money (or control of it, whatever). it’s common practise to import keys into random bits of software without expecting a brick to fall on your head. people resent Bread Wallet for not having the “feature”, sadly. |
| 03:35:04 | op_mul: | with services like blockchain.info adding features allowing users to “search” by a particular BIP32 key (how, I don’t know, as there’s no real standard on the paths, maybe they support all of them), there’s a very high risk of users unknowingly compromising either their security or their privacy. |
| 03:35:44 | op_mul: | in a world where websites asking you to export master public keys and past them in is the norm, you can see how two “harmless” actions (export your public key to check your balance, export your old empty private keys for money (this is actually a thing today already)) lead to massive loss of money, maybe delayed by months or years, as pointed out. |
| 03:38:41 | PRab: | op_mul: So is your complaint that wallets should actually advertize that they use bip 44, or that users should never share private keys (bip 32 master keys) between wallets? |
| 03:39:48 | op_mul: | PRab: well there's a few hunks of fruit in that cake. I don't think that wallets should *ever* have *ANY* option to export private keys no matter what users think they want. |
| 03:40:08 | op_mul: | or import them either. that's just as dangerous. |
| 03:40:23 | PRab: | User MUST be able to make a backup. A backup implies that they can export private keys. |
| 03:41:10 | op_mul: | why would you want to export keys to make a backup‽‽ |
| 03:41:32 | phantomcircuit: | op_mul, and i have a convert! |
| 03:41:57 | PRab: | Not directly, but whatever the backup is must be able to derive the private keys. |
| 03:42:13 | op_mul: | no, you let the software do that. |
| 03:43:01 | op_mul: | if you have a user touching a private key, you've just lost. |
| 03:43:34 | PRab: | I guess what I am hinting at is that every wallet MUST be able to make a backup. The fact that multiple wallets can import/export the same backup format is almost inevitable. |
| 03:43:47 | phantomcircuit: | op_mul, importing keys can be done reasonably, but only as automated sweep, doesn't even display the corresponding address |
| 03:44:04 | PRab: | If the formats are close enough to be confused, then they better be 100% compatible. |
| 03:44:34 | phantomcircuit: | which is obviously a special feature that nobody implements today |
| 03:44:41 | op_mul: | phantomcircuit: no, that's still stupidly dangerous. besides, if you're not able to export a private key how would the user find one to import in the first place. |
| 03:45:04 | phantomcircuit: | op_mul, oh yeah it's definitely dangerous |
| 03:45:20 | phantomcircuit: | just google the prefix for openssl genrsa keys |
| 03:45:24 | phantomcircuit: | you'll find TONS |
| 03:45:28 | op_mul: | phantomcircuit: oh that's right, they'll use bitaddress.org to make a "paper wallet" in their browser with Math.Random, that'll go well. |
| 03:46:08 | op_mul: | phantomcircuit: just be sure to use it offline so that you can be sure the page hasn't been maliciously altered. if you're not connected to the internet it can't send them home, right? |
| 03:46:44 | phantomcircuit: | op_mul, ha |
| 03:46:49 | phantomcircuit: | do people really think that ??/ |
| 03:46:55 | phantomcircuit: | sigh i know they do |
| 03:46:56 | op_mul: | phantomcircuit: yes :( |
| 03:46:59 | MRL-Relay_: | MRL-Relay_ is now known as MRL-Relay |
| 03:47:06 | phantomcircuit: | the question alone was answer enough |
| 03:47:12 | phantomcircuit: | i knew it as soon as i hit enter |
| 03:47:18 | op_mul: | the website tells you to disconnect from the internet to be 100% safe. |
| 03:47:24 | gwillen: | speaking of amusing information disclosures, have you guys seen the chrome search-in-page information leak |
| 03:47:35 | PRab: | grr... I hate this debate. Javascript can be (almost) as secure or insecure as any other programing language. |
| 03:47:44 | gwillen: | where a website can detect what you're searching for by synthesizing text and measuring your scroll position |
| 03:47:57 | op_mul: | PRab: I don't think there's much desire for wallet files to be interoperable. different wallets supporting different feature sets just ends up being constricting, and users will do silly things like trying to use the same wallet backup in two clients at once. |
| 03:47:59 | PRab: | Using a modern browser that implements web crypto you can get good random number generators. |
| 03:48:15 | phantomcircuit: | PRab, javascript the language... maybe, real world implementations of javascript interpreters? hahah NOPE |
| 03:48:45 | phantomcircuit: | but even then there are serious issues with javascript the language and cryptography |
| 03:48:54 | op_mul: | PRab: if you think we are talking about JavaScript being the flaw here, well, we're not. |
| 03:49:34 | phantomcircuit: | oh yeah |
| 03:49:37 | PRab: | phantomcircuit: At least with javascript most people at least have the chance to look at the source. I for one have always run the binary version of bitcoin core and trusted that nobody played any games as they compiled. it. |
| 03:49:57 | phantomcircuit: | no the issue is that you cant trust the bitaddress code unless you review it yourself |
| 03:50:00 | op_mul: | PRab: bitaddress.org is 30,000 lines of javascript. nobody has ever read it. |
| 03:50:08 | phantomcircuit: | you have verified the copy was reviewed by someone else |
| 03:50:11 | OneFixt_: | OneFixt_ is now known as OneFixt |
| 03:50:15 | phantomcircuit: | (and that it's really the same copy!) |
| 03:51:09 | PRab: | I have not, but it is theoretically easier than verifying that bitcoin core (or any other wallet) compiled from the source code posted to github. |
| 03:51:29 | op_mul: | who says the person visiting the website got served that copy of the code? |
| 03:51:53 | phantomcircuit: | PRab, ??? |
| 03:52:03 | phantomcircuit: | you can in practice verify that today |
| 03:52:09 | PRab: | Who says that the download of bitcoin core is valid (yes I know about gitian)? |
| 03:52:12 | phantomcircuit: | bitcoin core is built deterministically from source |
| 03:52:32 | phantomcircuit: | signed by multiple parties, but you can verify it yourself too! |
| 03:52:44 | phantomcircuit: | shit you can even trivially compile from a git tag yourself |
| 03:52:50 | moa: | signed src hash |
| 03:52:51 | phantomcircuit: | it's not even close |
| 03:53:11 | PRab: | phantomcircuit: I live in a windows world, so compiling from source is not as trivial. |
| 03:53:24 | Luke-Jr: | PRab: if you run Windows, then you can't be sure of anything ever |
| 03:53:33 | phantomcircuit: | lol yeah that |
| 03:54:16 | phantomcircuit: | that's like someone wearing a firemans uniform standing in the middle of an inferno going "EVERYTHING IS FINE IM IN THE SUIT!" |
| 03:54:28 | PRab: | I trust Microsoft. Some people might laugh at me for that, but I am most comfortable with Windows as an operating system, and have CHOSEN to trust Microsoft. |
| 03:54:48 | Luke-Jr: | lolol |
| 03:55:11 | moa: | heh, torllbait? |
| 03:55:23 | Luke-Jr: | "Sure, he's been caught violating my rights, but … I CHOOSE TO TRUST HIM!" |
| 03:56:03 | PRab: | I also gave Linux a fair chance. I have installed at least 4 different distros, tried to get comfortable with the command line for most operations, compiled my own kernel, etc. |
| 03:57:02 | moa: | microsoft's 'early' move into crypto is intriguing though |
| 03:57:31 | PRab: | In the end I always end up back using Windows knowing full well that hardcore open source advocates will ridicule me for it. |
| 03:58:11 | Luke-Jr: | how did this conversation get into -wizards? |
| 03:58:51 | PRab: | Sorry, I didn't mean to make the drift so far from bitcoin. It started with to use/not use a unified backup strategy such as bip 32. |
| 03:59:03 | moa: | using windows is like watching the 6 o'clock mainstream TV news to see what the masses are being fed, it's educational but unsatisfying |
| 03:59:26 | PRab: | My contention is that something bip32ish is inevitable. |
| 03:59:34 | op_mul: | Luke-Jr: here's where we drifted. https://botbot.me/freenode/bitcoin-wizards/2014-12-14/?msg=27504701&page=2 |
| 03:59:43 | PRab: | Because of that, we should ensure that it is done as correctly as possible. |
| 04:01:02 | Luke-Jr: | PRab: was someone implying there is a problem with BIP32 at some level? |
| 04:01:30 | PRab: | I agree that in practice we should encourage users to create a new backup/wallet for each piece of wallet software that they use. |
| 04:02:39 | PRab: | Luke-Jr: op_mul Was saying (correct me if I'm wrong) that bip32 was a bad idea because people might load 2 pieces of wallet software with the same wallet and get unexpected results. |
| 04:02:59 | Luke-Jr: | so load it in the other one and get expected results? |
| 04:03:45 | op_mul: | Luke-Jr: read the bit of the log I linked to, it explains my problem better than I can paraphrase myself. |
| 04:03:50 | Luke-Jr: | XD |
| 04:04:05 | PRab: | Expected results would be good, but like the consensus code, unexpected results can cause people to lose money. |
| 04:04:44 | PRab: | Bip32/44 are essentially introducing new pieces of consensus code. |
| 04:05:36 | Luke-Jr: | not 32, no |
| 04:06:31 | bitjedi_: | bitjedi_ is now known as bitjedi |
| 04:06:33 | Luke-Jr: | sure, wallets might end up with different balances if they don't implement it identically - but worst case you just go back to the old software to get the "lost" coins |
| 04:06:44 | PRab: | It 2 wallets deviate at all and both claim they implement bip32, the user could be missing money in one wallet or the other. |
| 04:07:05 | PRab: | Thats exactly my point. |
| 04:07:40 | Luke-Jr: | and easily recover it, by using the other again |
| 04:07:50 | Luke-Jr: | and in no case does it affect consensus |
| 04:07:54 | op_mul: | my main problem with BIP32 isn't that though, it's the using it properly bit. |
| 04:09:08 | PRab: | So, op_mul does bip44 solve the using it properly bit, or is there more than that? |
| 04:10:29 | op_mul: | no, it all just comes down to the fact that users are trained to go "search" for their addresses (and master public keys are the same right) and export private keys whenever they feel like it. with HD wallets this is a lot, lot more dangerous, you don't just compromise yourself now but you compromise all future transactions too. |
| 04:11:02 | Luke-Jr: | … |
| 04:11:13 | Luke-Jr: | if users are trained to do that, THAT is the problem, not BIP 32/44 |
| 04:11:22 | Luke-Jr: | users should never be touching ECDSA private keys |
| 04:11:37 | op_mul: | yes, I know. |
| 04:11:48 | PRab: | Ah, I see. In general, I believe that the ONLY way a wallet should allow the user to export private keys is through a full wallet backup. |
| 04:12:12 | PRab: | If the wallet allows them to export an individual private key, I almost consider that a bug. |
| 04:13:06 | op_mul: | it certainly is. yet in that case every wallet I can think of except for Bread is flawed. |
| 04:13:34 | PRab: | I think breadwallet and armory do this correctly. I have never seen an "Export specific private key" option in either and have used both extensively. |
| 04:13:43 | op_mul: | bread does not, Armory does. |
| 04:13:55 | PRab: | Where/how in armory? |
| 04:14:27 | op_mul: | wallet properties > backup this wallet > export key lists |
| 04:15:41 | PRab: | Oh, oops, I missed that. IMO, I would kill that and the "Import Private Keys" option (leave Sweep Private Keys). |
| 04:15:57 | Luke-Jr: | op_mul: Bitcoin Core doesn't export individual keys to users |
| 04:16:37 | op_mul: | Luke-Jr: it's not like end users aren't taught to use the RPC console. https://bitcoin.stackexchange.com/questions/7536/how-do-i-export-my-private-keys-from-my-bitcoin-qt-client |
| 04:16:49 | Luke-Jr: | ………. |
| 04:17:13 | PRab: | Luke-Jr: I agree if you say bitcoin-qt, bitcoind has it pretty exposed over RPC. |
| 04:17:24 | Luke-Jr: | PRab: bitcoind isn't for end users |
| 04:18:03 | PRab: | Define end user and I might agree. |
| 04:19:12 | Luke-Jr: | grandma |
| 04:19:34 | PRab: | grandma = bitcoin-qt = I agree |
| 04:20:11 | Luke-Jr: | (and your average bitcoiner is NOT smarter than grandma..) |
| 04:21:12 | PRab: | That I would disagree with for now, but I hope more of the general public (grandma) starts using bitcoin in the long run. |
| 04:24:55 | phantomcircuit: | Luke-Jr, generally speaking i think HD wallets are useful for sophisticated users |
| 04:25:13 | phantomcircuit: | but for users who cant explain how they work? |
| 04:25:16 | phantomcircuit: | not so much |
| 04:25:41 | phantomcircuit: | the problem is that means you have two sets of wallet code now... which is probably worse than the sophisticated users running non-HD wallets |
| 04:25:58 | op_mul: | phantomcircuit: explaining to people why they shouldn't pase their master public key into the search box of blockchain.info is going to be pretty difficult once peopel writing "tutorials" on the subject find out about that new feature. |
| 04:36:26 | gmaxwell: | the really bad privacy implications are maybe a bit less concerning for me than that facility will make any wallet using the stronger hardened derrivation have a competative disadvantage. (I'm pretty concerned that none of the wallets implementing BIP32 use hardened at all.) |
| 04:37:08 | gmaxwell: | there are cases where non-hardned is very useful, but it's much more fragile, and for plenty of wallet applications hardened works fine. |
| 04:40:14 | op_mul: | gmaxwell: yes, that's similar to the key exporting issue. from the users perspective not being able to "export" or "import" private keys is a deficiency rather than a security enhancement. I suspect they would rather leave it in and have a less secure, more user loved wallet than the other way around. |
| 04:57:43 | PRab: | op_mul: I'm sure this isn't quite as far as you would like to take it, but I just put in an issue for armory. https://github.com/etotheipi/BitcoinArmory/issues/254 |
| 04:58:24 | PRab: | I verified that import/sweep private key is already hidden from the standard user view. |
| 04:59:24 | op_mul: | PRab: sure, why not, good idea. I suppose they could hide it under the "expert" view, there's already modifiers for showing EC related stuff only to certain people. |
| 05:00:32 | gmaxwell: | it's particularly dangerous with any kind of homorphic determinstic wallet. IMO even an expert screen should get an explicit warning that exporting any private key exports all your private keys, effectively. |
| 05:01:28 | PRab: | Thats my though, Armory is designed to be a fairly advanced tool, so if you put it into advanced mode and it gives you a warning, it should allow you to shoot yourself in the foot. |
| 05:02:52 | gmaxwell: | Yea, the thing to distinguish is between what "the user wants" vs "what the user would want if they had perfect knoweldge" |
| 05:04:20 | PRab: | good point. |
| 05:05:43 | gmaxwell: | one way to do that is to educate the user to make them more like the perfect knoweldge version of themselves and then just ask them what they want. There are limits though. :) |
| 05:32:19 | K1773R_: | K1773R_ is now known as K1773R |
| 05:40:17 | mr_burdell: | mr_burdell is now known as Guest99301 |
| 05:55:39 | fluffypony: | fluffypony is now known as 6A4AAQ8FF |
| 09:05:16 | sinisalo.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 | sinisalo.freenode.net: | Users on #bitcoin-wizards: andy-logbot Profreid Guyver2 paveljanik hashtag hollandais DoctorBTC fluffypony jtimon Emcy_ btc__ NikolaiToryzin CryptOprah null_radix HaltingState mappum koshii grandmaster bosma ryanxcharles bitjedi [\\\] BlueMatt Iriez grishnakh__ c0rw1n_ bbrittain kanzure warren Krellan LaptopZZ nanotube Graet fenn otoburb_ LarsLarsen coutts bobke jchp Baz___ nsh_ SubCreative PRab 64MABDITL Guest99301 Hunger- gavinand1esen asoltys_ sl01_ arowser K1773R |
| 09:05:16 | sinisalo.freenode.net: | Users on #bitcoin-wizards: pi07r_ shesek Shiftos todaystomorrow TheSeven nuke__ waxwing atgreen prepost nickler_ a5m0_ Starduster_ jgarzik OneFixt op_mul PaulCapestany Luke-Jr @ChanServ Meeh DougieBot5000 go1111111 Burrito RoboTeddy prodatalab Dr-G phantomcircuit SDCDev wumpus Flyer9933 zwischenzug Transisto epscy Guest21930 dansmith_btc comboy eristisk tacotime Tjopper midnightmagic btcdrak adlai spinza omni_ ahmed_ lnovy mortale espes__ tdlfbx heath eordano luny |
| 09:05:16 | sinisalo.freenode.net: | Users on #bitcoin-wizards: jbenet nsh gribble gwillen Nightwolf gazab Anduck Dyaheon samson_ cfields digitalmagus8 stonecoldpat gmaxwell pigeons isis tromp andytoshi lechuga_ artifexd Muis hguux_ michagogo kumavis warptangent Fistful_of_Coins HM2 paperbot maaku Cory Guest38445 coryfields iddo kinlo azariah yoleaux Logicwax berndj lclc_bnc s1w Eliel_ sneak harrigan sipa Alanius AdrianG livegnik BananaLotus burcin wizkid057 tromp_ poggy mmozeiko Taek optimator_ |
| 09:05:16 | sinisalo.freenode.net: | Users on #bitcoin-wizards: Apocalyptic throughnothing petertodd crescendo so [d__d] BigBitz jaromil helo Keefe phedny BrainOverfl0w harrow roasbeef ryan-c TD-Linux catcow danneu amiller smooth |
| 09:13:58 | SubCreative: | SubCreative is now known as Sub|zzz |
| 09:33:05 | op_mul: | for a while people have been talking about censorship-resistant methods of getting block data to people. pretty sure I’ve got the problem sorted without using satellites and all that nonsense. I’ve come up with an elegant solution that needs no additional infrastructure and is unequivocally foolproof. let me lay it down here. |
| 09:33:28 | op_mul: | you put this URL in. |
| 09:33:30 | op_mul: | https://soundcloud.com/blockchain/00000000000000000f54a1fe88f6a4a2bf98952e60b57376eb15d80e9c753c04 |
| 09:33:41 | op_mul: | and the blocks. |
| 09:33:44 | op_mul: | they come out of the speakers. |
| 09:33:53 | op_mul: | at 8000 baud. |
| 09:36:39 | rusty: | op_mul: cute :) I am more interested in a non-internet distribution method to make sybil attacks harder. |
| 09:37:57 | gmaxwell: | rusty: but but, he's solved it! it's in the cloud! |
| 09:42:31 | rusty: | gmaxwell: ah yes, true. Since cloud does solve every problem, it's a simple lemma that it solves this one. My mistake... |
| 09:44:04 | op_mul: | I was prepared to encode and upload every new block to soundcloud, but you have to pay to upload more than 150 minutes of "music". |
| 11:26:09 | lclc_bnc: | lclc_bnc is now known as lclc |
| 12:14:12 | lclc: | lclc is now known as lclc_bnc |
| 13:27:15 | kanzure: | :) there exist preserved samples of len sassaman brain matter https://groups.google.com/forum/#!topic/diybio/LMfqPUR0OCA |
| 13:46:40 | fluffypo_: | fluffypo_ is now known as fluffypony |
| 14:19:42 | DoctorBTC_: | DoctorBTC_ is now known as DoctorBTC |
| 14:22:32 | lclc_bnc: | lclc_bnc is now known as lclc |
| 15:29:21 | samson2: | samson2 is now known as samson_ |
| 16:01:42 | Guest99301: | Guest99301 is now known as mr_burdell |
| 16:02:12 | mr_burdell: | mr_burdell is now known as Guest42810 |
| 16:46:01 | lclc: | lclc is now known as lclc_bnc |
| 16:58:48 | nuke__: | nuke__ is now known as nuke1989 |
| 17:02:39 | mr_burdell_: | mr_burdell_ is now known as mr_burdell |
| 17:03:08 | mr_burdell: | mr_burdell is now known as Guest84365 |
| 18:14:45 | Guest84365: | Guest84365 is now known as mr_burdell |
| 19:23:18 | Sub|zzz: | Sub|zzz is now known as SubCreative |
| 21:08:50 | Guyver2: | Guyver2 has left #bitcoin-wizards |