00:09:34midnightmagic:"Novel" huh.
00:13:59BlueMatt:Taek: bad idea.
00:18:58Starduster:Starduster is now known as benjamintrees
00:20:17benjamintrees:benjamintrees is now known as Starduster
00:24:00Taek: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:52adam3us: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:42gmaxwell: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:06gmaxwell:just needs implementation now.
00:29:53adam3us:someone should do that :) its a very cool development. its amazing really that no one thought of it before.
00:31:37adam3us: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:19adam3us:it would be ideal to have a reusable address that is scannable via the bloom block or related precomputed committed data structure.
00:32:28adam3us:while preserving privacy.
00:34:54sipa:* sipa needs to write up a proposal for reusable payment requests
01:08:43AdrianG:I have a serious question.
01:08:50AdrianG:how will the problem of custody ever be sold with bitcoin?
01:08:55AdrianG:with physical commodities, ownership = custody
01:09:28AdrianG: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:51gmaxwell:if you generated the private key, and told no one else, then you know no one else has it.
01:10:57gmaxwell:(with exponential probability)
01:11:20gmaxwell:(and nothing in life is certian, a meteor could hit you on the head 5 seconds from now...)
01:11:29lechuga_::o
01:11:57gmaxwell:(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:05AdrianG:gmaxwell: yes, but how do i prove to others?
01:12:10AdrianG:that i never told anyone?
01:12:42gmaxwell: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:11lechuga_:potentially dumb question but why would u want a reusable payment request
01:13:21AdrianG:gmaxwell: why do you think its not important?
01:14:01gmaxwell: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:05AdrianG:we have thousands of years of law decisions about custody, its a socially important concept
01:14:41phantomcircuit:i guess the only real question for bloomfilters per block is what the parameters should be
01:14:47gmaxwell: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:01phantomcircuit:possibly they should be variable based on the number of entries/length of those entries
01:15:48gmaxwell: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:15lechuga_:couldn't you set expires sufficiently high and re-use away as-is?
01:16:21lechuga_:re: payreqs
01:16:23phantomcircuit:yeah i was also thinking that maybe a very tiny filter for each txn might also make sense
01:16:29phantomcircuit:but that doesn't seem super practical
01:16:34AdrianG:gmaxwell: if we can establish custody with certainty, a liar cannot assert defense that his keys were compromise
01:16:44AdrianG:we would know they weren't, and he is indeed lying.
01:16:55AdrianG:compromised*
01:17:16lechuga_:guess you would want to sign that it is expected to be reused
01:17:37phantomcircuit:AdrianG, you cannot prove that you did not produce a copy of the private key to a third party
01:17:45phantomcircuit:you maybe can approximate that with hardware DRM
01:17:55phantomcircuit:but that would be imperfect for certain
01:17:59AdrianG:phantomcircuit: i know, i think its a "problem" to an extent.
01:18:08gmaxwell: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:15gmaxwell: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:18AdrianG:in common law, fiduciary duty is rather important.
01:18:30phantomcircuit:AdrianG, in practice custody of physical things has to do with socially accepted signs of custody and nothing more
01:18:41AdrianG:without even being able to figure out who has custody over things, things become complicated
01:18:45phantomcircuit:the rules are indeed very poorly defined
01:18:52AdrianG:phantomcircuit: rules of custody?
01:19:09phantomcircuit:AdrianG, fiduciary duty is a concept which is entirely unrelated to bitcoin
01:19:21phantomcircuit:that's an abstraction on top of any money system
01:19:36lechuga_:ic so reusable payreqs are going to require some sort of pubkey derivation
01:20:06phantomcircuit: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:13AdrianG:phantomcircuit: yes, but physical money are a lot more workable in this case
01:20:21AdrianG:with bitcoin, i cannot even be 100% certain nobody stole my private key
01:20:33AdrianG:so i cant even be 100% certain my coins are really mine.
01:20:33gmaxwell: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:39gmaxwell:ting parties always move the coins).
01:20:41sipa:lechuga_: yup
01:20:49phantomcircuit:AdrianG, counterfeit swaps are a thing that insiders actually do with cash
01:21:00sipa:lechuga_: stealth addresses, but using out of band communication rather than blockchain storage
01:21:16AdrianG:phantomcircuit: what does that have to do with custody and fiduciary duty?
01:21:23lechuga_:interesting
01:21:38AdrianG:gmaxwell: so in order for me, to be 100% certain my coins are still my coins
01:21:43AdrianG:I must move them every now and then?
01:21:45phantomcircuit:AdrianG, you cannot trivially prove control of cash either
01:21:54gmaxwell: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:03phantomcircuit:at least with bitcoin you can continuously move the funds to new addresses which have newly generated private keys
01:22:08AdrianG:phantomcircuit: paper no, electronic cash is very trackable.
01:22:19gmaxwell: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:22AdrianG:but paper cash is miniscule vs electronic funds.
01:22:30sipa: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:56AdrianG:gmaxwell: hehe how very quantum
01:23:46gmaxwell: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:44kanzure:you don't prove to anyone that you never told others, that's not the point
01:24:56kanzure:just as others don't need to prove to you that others don't know their private key
01:25:50lechuga_:sipa: where does the payment message go if there is no synchronous channel
01:26:00sipa:lechuga_: a mailbox
01:26:03gmaxwell: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:29sipa: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:56sipa:(i say mailbox in an abstract sense; it doesn't have to actually be SMTP)
01:27:27lechuga_:ic
01:27:31gmaxwell: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:37gmaxwell:tant.
01:28:25sipa: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:51sipa:another is that there is no instant confirmation that the message is received, and thus no means to return a message back
01:28:55lechuga_:there is a public rsa key in a payment request already, can;t that be used?
01:29:33sipa:there is just a certificate, by a certificate authority
01:29:49sipa:eh, signature
01:30:30sipa: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:43lechuga_:makes sense
01:30:47sipa:it's a different layer
01:30:51lechuga_:nod
01:31:08sipa:one is about making sure that (if you trust the payment request) -> (you can safely transact)
01:31:11AdrianG:gmaxwell: the problem is that it costs absolutely nothing to open the diamond box. moving btc thru the network quickly costs money.
01:31:25sipa:the other is about making you trust the payment requestr
01:32:08lechuga_:yeah and presumably u might want very different acls on who has the private key
01:32:27lechuga_:for one use vs. the other
01:33:01lechuga_:sry, sometimes have a bad habit of asking a question b4 thinking enough
01:33:18gmaxwell: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:48Eliel_: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:02sipa: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:39lechuga_:yup
01:37:50AdrianG: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:52lechuga_:so the payer is going to pick a nonce and include that in their encrypted payment i guess
01:38:08lechuga_:maybe it's tweaked contracthashtool-style with their refund address
01:38:41Eliel_:AdrianG: the only scenario where waiting makes sense is if stealthiness is more valuable than the coins in the address.
01:39:16lechuga_:will be interesting to read the writeup
01:40:26AdrianG:Eliel_: i think such scenarios can be plausible. i have to think of good, relevant examples.
02:02:29phantomcircuit:Eliel_, except that actually we have seen in practice very weak keys not being stolen immediately
02:02:58phantomcircuit:indeed there has been some discussion around taking the small amounts at very weak addresses to protect people
02:03:04phantomcircuit:since it would immediately be obvious
02:03:19gmaxwell:phantomcircuit: the brainwallet stuff is a bit different thought since those uses systematically reuse addresses.
02:03:32gmaxwell:And the brainwallet cracker people are all yelling at each other to not steal the small amounts.
02:03:44gmaxwell:(using BC.i messages)
02:03:44phantomcircuit:hmm
02:03:48phantomcircuit:yeah i guess that's fair
02:04:20gmaxwell:hm. I guess this is an argument against HD wallets... less incentive to reveal that your keys are leaked early.
02:04:26gmaxwell:Because they're not forward secure.
02:04:58phantomcircuit:personally i think hd wallets are just too complicated for most people to use correctly
02:05:14phantomcircuit:and building wallet software that makes it even possible is non trivial
02:05:19phantomcircuit:much less being easy
02:08:05gmaxwell:Depends on what you mean.
02:08:18gmaxwell:It's no different to the user than existing wallets, except with a simpler backup scheme.
02:08:42gmaxwell: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:33phantomcircuit:well i think it's not exactly obvious to people that you lose forward secrecy if a single key is compromised
02:10:42phantomcircuit:so that would have to be made obvious
02:10:58phantomcircuit:and tools would have to be added to the wallet to mark a key as compromised
02:11:24gmaxwell:Right. This is actually not that complex. Just ... well no one making wallet software is really ... aware of these concerns it seems. :(
02:11:30gmaxwell:"move fast, break things"
02:12:11phantomcircuit:gmaxwell, it's not that complex, but it's definitely more complex
02:13:12gmaxwell: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:19phantomcircuit:gmaxwell, sure, but the rest of the wallet can be very simple
02:17:53phantomcircuit:(address, private key) tuples are small
02:18:07phantomcircuit:so generating and saving lots of them in advance shouldn't be that expensive
02:18:23phantomcircuit:bbl
03:32:26op_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:36op_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:04op_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:44op_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:41PRab: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:48op_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:08op_mul:or import them either. that's just as dangerous.
03:40:23PRab:User MUST be able to make a backup. A backup implies that they can export private keys.
03:41:10op_mul:why would you want to export keys to make a backup‽‽
03:41:32phantomcircuit:op_mul, and i have a convert!
03:41:57PRab:Not directly, but whatever the backup is must be able to derive the private keys.
03:42:13op_mul:no, you let the software do that.
03:43:01op_mul:if you have a user touching a private key, you've just lost.
03:43:34PRab: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:47phantomcircuit:op_mul, importing keys can be done reasonably, but only as automated sweep, doesn't even display the corresponding address
03:44:04PRab:If the formats are close enough to be confused, then they better be 100% compatible.
03:44:34phantomcircuit:which is obviously a special feature that nobody implements today
03:44:41op_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:04phantomcircuit:op_mul, oh yeah it's definitely dangerous
03:45:20phantomcircuit:just google the prefix for openssl genrsa keys
03:45:24phantomcircuit:you'll find TONS
03:45:28op_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:08op_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:44phantomcircuit:op_mul, ha
03:46:49phantomcircuit:do people really think that ??/
03:46:55phantomcircuit:sigh i know they do
03:46:56op_mul:phantomcircuit: yes :(
03:46:59MRL-Relay_:MRL-Relay_ is now known as MRL-Relay
03:47:06phantomcircuit:the question alone was answer enough
03:47:12phantomcircuit:i knew it as soon as i hit enter
03:47:18op_mul:the website tells you to disconnect from the internet to be 100% safe.
03:47:24gwillen:speaking of amusing information disclosures, have you guys seen the chrome search-in-page information leak
03:47:35PRab:grr... I hate this debate. Javascript can be (almost) as secure or insecure as any other programing language.
03:47:44gwillen:where a website can detect what you're searching for by synthesizing text and measuring your scroll position
03:47:57op_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:59PRab:Using a modern browser that implements web crypto you can get good random number generators.
03:48:15phantomcircuit:PRab, javascript the language... maybe, real world implementations of javascript interpreters? hahah NOPE
03:48:45phantomcircuit:but even then there are serious issues with javascript the language and cryptography
03:48:54op_mul:PRab: if you think we are talking about JavaScript being the flaw here, well, we're not.
03:49:34phantomcircuit:oh yeah
03:49:37PRab: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:57phantomcircuit:no the issue is that you cant trust the bitaddress code unless you review it yourself
03:50:00op_mul:PRab: bitaddress.org is 30,000 lines of javascript. nobody has ever read it.
03:50:08phantomcircuit:you have verified the copy was reviewed by someone else
03:50:11OneFixt_:OneFixt_ is now known as OneFixt
03:50:15phantomcircuit:(and that it's really the same copy!)
03:51:09PRab: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:29op_mul:who says the person visiting the website got served that copy of the code?
03:51:53phantomcircuit:PRab, ???
03:52:03phantomcircuit:you can in practice verify that today
03:52:09PRab:Who says that the download of bitcoin core is valid (yes I know about gitian)?
03:52:12phantomcircuit:bitcoin core is built deterministically from source
03:52:32phantomcircuit:signed by multiple parties, but you can verify it yourself too!
03:52:44phantomcircuit:shit you can even trivially compile from a git tag yourself
03:52:50moa:signed src hash
03:52:51phantomcircuit:it's not even close
03:53:11PRab:phantomcircuit: I live in a windows world, so compiling from source is not as trivial.
03:53:24Luke-Jr:PRab: if you run Windows, then you can't be sure of anything ever
03:53:33phantomcircuit:lol yeah that
03:54:16phantomcircuit: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:28PRab: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:48Luke-Jr:lolol
03:55:11moa:heh, torllbait?
03:55:23Luke-Jr:"Sure, he's been caught violating my rights, but … I CHOOSE TO TRUST HIM!"
03:56:03PRab: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:02moa:microsoft's 'early' move into crypto is intriguing though
03:57:31PRab: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:11Luke-Jr:how did this conversation get into -wizards?
03:58:51PRab: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:03moa: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:26PRab:My contention is that something bip32ish is inevitable.
03:59:34op_mul:Luke-Jr: here's where we drifted. https://botbot.me/freenode/bitcoin-wizards/2014-12-14/?msg=27504701&page=2
03:59:43PRab:Because of that, we should ensure that it is done as correctly as possible.
04:01:02Luke-Jr:PRab: was someone implying there is a problem with BIP32 at some level?
04:01:30PRab: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:39PRab: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:59Luke-Jr:so load it in the other one and get expected results?
04:03:45op_mul:Luke-Jr: read the bit of the log I linked to, it explains my problem better than I can paraphrase myself.
04:03:50Luke-Jr:XD
04:04:05PRab:Expected results would be good, but like the consensus code, unexpected results can cause people to lose money.
04:04:44PRab:Bip32/44 are essentially introducing new pieces of consensus code.
04:05:36Luke-Jr:not 32, no
04:06:31bitjedi_:bitjedi_ is now known as bitjedi
04:06:33Luke-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:44PRab: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:05PRab:Thats exactly my point.
04:07:40Luke-Jr:and easily recover it, by using the other again
04:07:50Luke-Jr:and in no case does it affect consensus
04:07:54op_mul:my main problem with BIP32 isn't that though, it's the using it properly bit.
04:09:08PRab:So, op_mul does bip44 solve the using it properly bit, or is there more than that?
04:10:29op_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:02Luke-Jr:
04:11:13Luke-Jr:if users are trained to do that, THAT is the problem, not BIP 32/44
04:11:22Luke-Jr:users should never be touching ECDSA private keys
04:11:37op_mul:yes, I know.
04:11:48PRab: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:12PRab:If the wallet allows them to export an individual private key, I almost consider that a bug.
04:13:06op_mul:it certainly is. yet in that case every wallet I can think of except for Bread is flawed.
04:13:34PRab: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:43op_mul:bread does not, Armory does.
04:13:55PRab:Where/how in armory?
04:14:27op_mul:wallet properties > backup this wallet > export key lists
04:15:41PRab:Oh, oops, I missed that. IMO, I would kill that and the "Import Private Keys" option (leave Sweep Private Keys).
04:15:57Luke-Jr:op_mul: Bitcoin Core doesn't export individual keys to users
04:16:37op_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:49Luke-Jr:……….
04:17:13PRab:Luke-Jr: I agree if you say bitcoin-qt, bitcoind has it pretty exposed over RPC.
04:17:24Luke-Jr:PRab: bitcoind isn't for end users
04:18:03PRab:Define end user and I might agree.
04:19:12Luke-Jr:grandma
04:19:34PRab:grandma = bitcoin-qt = I agree
04:20:11Luke-Jr:(and your average bitcoiner is NOT smarter than grandma..)
04:21:12PRab: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:55phantomcircuit:Luke-Jr, generally speaking i think HD wallets are useful for sophisticated users
04:25:13phantomcircuit:but for users who cant explain how they work?
04:25:16phantomcircuit:not so much
04:25:41phantomcircuit: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:58op_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:26gmaxwell: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:08gmaxwell: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:14op_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:43PRab: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:24PRab:I verified that import/sweep private key is already hidden from the standard user view.
04:59:24op_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:32gmaxwell: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:28PRab: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:52gmaxwell:Yea, the thing to distinguish is between what "the user wants" vs "what the user would want if they had perfect knoweldge"
05:04:20PRab:good point.
05:05:43gmaxwell: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:19K1773R_:K1773R_ is now known as K1773R
05:40:17mr_burdell:mr_burdell is now known as Guest99301
05:55:39fluffypony:fluffypony is now known as 6A4AAQ8FF
09:05:16sinisalo.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:16sinisalo.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:16sinisalo.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:16sinisalo.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:16sinisalo.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:58SubCreative:SubCreative is now known as Sub|zzz
09:33:05op_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:28op_mul:you put this URL in.
09:33:30op_mul:https://soundcloud.com/blockchain/00000000000000000f54a1fe88f6a4a2bf98952e60b57376eb15d80e9c753c04
09:33:41op_mul:and the blocks.
09:33:44op_mul:they come out of the speakers.
09:33:53op_mul:at 8000 baud.
09:36:39rusty:op_mul: cute :) I am more interested in a non-internet distribution method to make sybil attacks harder.
09:37:57gmaxwell:rusty: but but, he's solved it! it's in the cloud!
09:42:31rusty:gmaxwell: ah yes, true. Since cloud does solve every problem, it's a simple lemma that it solves this one. My mistake...
09:44:04op_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:09lclc_bnc:lclc_bnc is now known as lclc
12:14:12lclc:lclc is now known as lclc_bnc
13:27:15kanzure::) there exist preserved samples of len sassaman brain matter https://groups.google.com/forum/#!topic/diybio/LMfqPUR0OCA
13:46:40fluffypo_:fluffypo_ is now known as fluffypony
14:19:42DoctorBTC_:DoctorBTC_ is now known as DoctorBTC
14:22:32lclc_bnc:lclc_bnc is now known as lclc
15:29:21samson2:samson2 is now known as samson_
16:01:42Guest99301:Guest99301 is now known as mr_burdell
16:02:12mr_burdell:mr_burdell is now known as Guest42810
16:46:01lclc:lclc is now known as lclc_bnc
16:58:48nuke__:nuke__ is now known as nuke1989
17:02:39mr_burdell_:mr_burdell_ is now known as mr_burdell
17:03:08mr_burdell:mr_burdell is now known as Guest84365
18:14:45Guest84365:Guest84365 is now known as mr_burdell
19:23:18Sub|zzz:Sub|zzz is now known as SubCreative
21:08:50Guyver2:Guyver2 has left #bitcoin-wizards