1 2014-07-21 04:21:17 <phantomcircuit> Luke-Jr, it would be so nice if tv_nsec was guaranteed to be < 1m
  2 2014-07-21 04:21:23 <phantomcircuit> in practice it always is
  3 2014-07-21 04:21:30 <Luke-Jr> it's not a guarantee?
  4 2014-07-21 04:21:46 <Luke-Jr> just think, if POSIX were tonal, the guarantee would be inherent in the type!
  5 2014-07-21 04:21:55 <phantomcircuit> heh
  6 2014-07-21 05:04:53 <wumpus> BlueMatt: he is pretty close, so it's best to coordinate with him first if you intend to make changes, to make sure that you don't do overlapping things
  7 2014-07-21 05:06:40 <wumpus> @cfields
  8 2014-07-21 05:47:04 <wumpus> BlueMatt: of course, in the meantime fixing disk space problems will still make sense...
  9 2014-07-21 05:50:12 <BlueMatt> wumpus: afiu, the latest rash of changes were not disk-space-related?
 10 2014-07-21 05:50:22 <BlueMatt> I didnt dig in deep, but the logs mentioned nothing about disk space
 11 2014-07-21 05:51:04 <BlueMatt> I was asking before digging in because it may take some time and simply not be worth it (can we live without pull-tester until cfields finishes up?)
 12 2014-07-21 05:52:41 <wumpus> we can't really live without pulltester, not even for a day
 13 2014-07-21 05:53:27 <BlueMatt> is it still failing atm?
 14 2014-07-21 05:53:41 <wumpus> not sure; I just pushed something so we'll see in a moment
 15 2014-07-21 07:01:51 <wumpus> BlueMatt: it works
 16 2014-07-21 07:02:33 <bombsite> hi
 17 2014-07-21 07:02:49 <bombsite> I'm looking for sipa
 18 2014-07-21 07:02:57 <bombsite> I was reading one of your issues about refactoring
 19 2014-07-21 07:03:02 <bombsite> that was from december
 20 2014-07-21 07:04:19 <bombsite> Also have a question about the legality of writing open-source code while employed as a software engineer
 21 2014-07-21 07:04:26 <bombsite> :/
 22 2014-07-21 07:04:30 <gmaxwell> you can generally trust that if its discussed in here sipa will see it.
 23 2014-07-21 07:05:54 <gmaxwell> bombsite: depends on where you live, and what agreement you have with your employer. Ideally you should have an agreement that permits you to do so— though in many places employers cannot encumber what you do on your own time, with your own equipment— regardless of any contract... this isn't the best place for that kind of advice though, you might want to try #fsf
 24 2014-07-21 07:07:44 <bombsite> hmm, I'm in california
 25 2014-07-21 08:02:37 <gwillen> gmaxwell: unfortunately I think what you say is not _quite_ true; at least in CA, your employer can still encumber your own stuff, if it's within the current or demonstrably anticipated line of business of the company (or something like that)
 26 2014-07-21 08:02:51 <gwillen> i.e. if your employer is google, "software" is something you can't do on your own time without your employer owning it :-P
 27 2014-07-21 08:03:17 <t7> not sure thats true
 28 2014-07-21 08:04:26 <gwillen> t7: the bit about "software" is me being slightly sarcastic
 29 2014-07-21 08:05:16 <gwillen> t7: what california law says is "when the invention was conceived or “reduced to practice” (actually created or a patent application filed) it related to the employer’s business or actual or “demonstrably anticipated” research or development"
 30 2014-07-21 08:05:37 <gwillen> t7: the trick being the google's actual or demonstrably anticipated R&D includes essentially all of software
 31 2014-07-21 08:05:56 <t7> i see i see
 32 2014-07-21 08:05:58 <gwillen> t7: for example, they take the official position that their employees may not write phone apps of any kind for any platform without permission
 33 2014-07-21 08:06:03 <gwillen> or google owns the result
 34 2014-07-21 08:06:03 <wumpus> please move this discussion somewhere else
 35 2014-07-21 08:06:07 <gwillen> sorry
 36 2014-07-21 08:06:15 <wumpus> for something on-topic see https://github.com/bitcoin/bitcoin/pull/4566
 37 2014-07-21 08:07:36 <gwillen> wumpus: 'fairly selected' is rather vague; also DNS TTLs of less than one minute are ignored by some resolvers (e.g. Windows at least at one point in time)
 38 2014-07-21 08:08:01 <gwillen> (The rule of thumb I heard was that if it's under 30 minutes, Windows will ignore it)
 39 2014-07-21 08:08:08 <wumpus> gwillen: agreed; 'fairly selected' should be better defined
 40 2014-07-21 08:08:32 <wumpus> gwillen: as for the DNS TTL, it is forbidden for it to be less than one minute, so if windows ignores it that's even better
 41 2014-07-21 08:08:34 <gwillen> oh, sorry, may NOT be served
 42 2014-07-21 08:08:39 <gwillen> please forgive me, I'm very tired. :-)
 43 2014-07-21 08:10:59 <wumpus> we should also add a link to bitcoin-seeder as a reference implementation that implements 'fair selection'
 44 2014-07-21 08:11:14 <gmaxwell> gwillen: right, it's not super rigid— I think we think some diversity in how dnsseeds work is good, but there are some things which are right out. Since most of this can't be actually checked/enforced there is an assumption of basic honesty in this.
 45 2014-07-21 08:11:23 <gwillen> 
ACTION nods.

 46 2014-07-21 08:12:28 <gmaxwell> and maybe sometimes otherwise honest people do stupid things because they haven't thought through the consequences— which is mostly what this is supposted to be about. Making sure the expectations are clear. "thou shall not use this to spy on users or to attempt to partition the network"
 47 2014-07-21 08:13:01 <gwillen> aha, *nods*.
 48 2014-07-21 08:13:18 <jcorgan> TL;DR: the State of California inserts itself, uninvited, into any agreement you make between employer and employed--consult with a competent attorney before entering into any employment agreement.
 49 2014-07-21 08:13:42 <gwillen> there is no state that fails to do so :-P
 50 2014-07-21 08:13:56 <gwillen> (but wumpus already poked us for being off-topic with this topic.)
 51 2014-07-21 08:14:23 <jcorgan> sorry, unto #bitcoin we go
 52 2014-07-21 08:15:00 <wumpus> it's not about bitcoin either, a US law-specific channel like #fsf, as gmaxwell suggested, would be better
 53 2014-07-21 08:18:03 <gmaxwell> (in particular the #fsf recommendation was becuase the person was asking about contributing to open source software, and I know this is a FAQ in those circles)
 54 2014-07-21 08:19:01 <wumpus> right
 55 2014-07-21 08:58:05 <gmaxwell> Anyone have a UPNP enabled natted host that has never run bitcoin? trying to figure out what I can realisticaly test with the no-whatismyip patch.
 56 2014-07-21 09:06:10 <drizztbsd> you can ask your ip address using UPNP :P
 57 2014-07-21 09:12:54 <wumpus> drizztbsd: indeed; although that doesn't help in the natted non-UPNP cases in which a port was manually forwarded
 58 2014-07-21 09:13:30 <drizztbsd> and what about using ICE or STUN?
 59 2014-07-21 09:13:39 <wumpus> ...wut?
 60 2014-07-21 09:15:15 <gmaxwell> drizztbsd: I'm not asking for how to determine an IP. I'm trying to figure out which test cases I can realistically include on a test plan and get them covered.
 61 2014-07-21 10:00:03 <wumpus> shouldn't -logtoconsole log to stdout *as well as* file, instead of log only to stdout?
 62 2014-07-21 10:00:45 <gmaxwell> hm. I've used it before because I didn't want the logs going to disk. Though logically that could just as well be a second option.
 63 2014-07-21 10:01:12 <wumpus> why wouldn't you want logs going to disk?
 64 2014-07-21 10:01:29 <wumpus> anyhow, not a big issue, I just thought it was weird
 65 2014-07-21 10:02:01 <wumpus> will just keep using tail -f
 66 2014-07-21 10:02:02 <gmaxwell> wumpus: in my case because I was running a bunch of debugging on a host with not much space remaining.
 67 2014-07-21 10:02:49 <gmaxwell> (or not wanting to thrash your SSD with writes I guess,  or generally— because you're using stdout to send it to some other log handling thing)
 68 2014-07-21 10:03:09 <wumpus> yes, never mind
 69 2014-07-21 12:16:31 <buZz> what technical reasons are there to not run multiple wallets with the same private keys imported?
 70 2014-07-21 12:18:48 <jaakkos> buZz: not a question for -dev. fwiw, that *will* get you screwed. thing is, wallets generate *new* private keys for the change BTC amount when you do transactions, and the other wallets will not know about those.
 71 2014-07-21 12:19:18 <buZz> oh sorry .. i wanted to know the technical reason, i understand the change address reason
 72 2014-07-21 12:20:33 <buZz> i just assumed this channel would be more applicable, but forgive me :)
 73 2014-07-21 12:23:46 <wumpus> buZz: if you really need to share a wallet between multiple locations you must use a deterministic wallet with a suitable lookahead
 74 2014-07-21 12:24:14 <buZz> what does that fix?
 75 2014-07-21 12:24:22 <hearn> hello
 76 2014-07-21 12:24:35 <jaakkos> buZz: then the newly generated private keys are the same for all wallets
 77 2014-07-21 12:24:45 <buZz> ahhhh right
 78 2014-07-21 12:25:32 <wumpus> all wallets will generate the same keys, so they don't have to exchange information
 79 2014-07-21 12:26:33 <hearn> buZz: electrum and bitcoinj (git master) are examples of such wallets.
 80 2014-07-21 12:26:35 <wumpus> otherwise an active synchronization process for keys is needed, which is obviously possible too
 81 2014-07-21 12:26:48 <hearn> buZz: (with caveats)
 82 2014-07-21 12:27:16 <buZz> well thats to keep change 'inside' i guess
 83 2014-07-21 12:27:17 <wumpus> but if you get anything wrong it can be dangerous
 84 2014-07-21 12:27:34 <buZz> unless you set change address to the one address thats already inside
 85 2014-07-21 12:28:09 <wumpus> yes, cycling the same N receiving addresses forever is also 'deterministic'
 86 2014-07-21 12:28:25 <buZz> ah of course
 87 2014-07-21 12:28:27 <hearn> buZz: it's not only about change but receiving money
 88 2014-07-21 12:28:43 <hearn> buZz: your wallet needs to know what keys to search for in the stream of transactions.
 89 2014-07-21 12:29:23 <buZz> obviously, but if you 'fix' the change address to a single one, nothing else would make new addresses, right?
 90 2014-07-21 12:29:31 <wumpus> but reusing addresses makes accounting more difficult, is worse for privacy, and is slightly less secure, so you should use a real deterministic wallet
 91 2014-07-21 12:29:54 <buZz> ! how is it less secure?
 92 2014-07-21 12:29:54 <gribble> Error: "how" is not a valid command.
 93 2014-07-21 12:30:00 <buZz> gribble: thanks ...
 94 2014-07-21 12:30:52 <hearn> in theory, if a break in ECDSA was found that worked on pubkeys, the fact that keys are only revealed in hashed form until they're used would be beneficial
 95 2014-07-21 12:30:52 <wumpus> you can find all those answers on the internet
 96 2014-07-21 12:31:04 <wumpus> this is about the 10000th time that has been asked here
 97 2014-07-21 12:31:28 <hearn> in practice it makes little or no difference, because if ECDSA breaks then bitcoin would suffer critical confidence issues anyway. also we use RIPEMD160 which is a very old hash function
 98 2014-07-21 12:31:55 <hearn> i would consider RIPEMD160 to be more likely to be weak than ECDSA. but it's the sort of discussion for academic cryptographers, i think
 99 2014-07-21 12:31:56 <wumpus> it's just better to not reuse addresses, do so at your own peril
100 2014-07-21 12:37:33 <wumpus> hearn: it doesn't have to be ecdsa itself that is broken, but the danger of an implementation problem in ecdsa (such as reusing a nonce) is also amplified
101 2014-07-21 12:38:32 <pigeons> which has happened and people lost money as a result. i know most people know this but for buZz's benefit
102 2014-07-21 12:38:37 <hearn> even with hashing, if an ecdsa implementation is broken you could race real transactions as they propagate across the network to try and steal the coins. i'm not sure bitcoin can survive a break in ecdsa even if all public keys are only used once.
103 2014-07-21 12:38:58 <hearn> pigeons: AFAIK that's incorrect. there have been no cases where nonce reuse was a problem but the underlying keys were OK
104 2014-07-21 12:39:07 <hearn> i might have missed an incident though
105 2014-07-21 12:39:25 <sipa> nonce reuse has happened, and coins have been stolen because of it
106 2014-07-21 12:39:33 <sipa> but only a few cases
107 2014-07-21 12:39:39 <hearn> yes, but in those cases the underlying keys were also weak and hashing wouldn't have helped.
108 2014-07-21 12:39:40 <pigeons> not nonce reuse, but implementation problem such as predictable k and the damage amplified by addres reuse
109 2014-07-21 12:39:54 <hearn> at least for the cases i'm familiar with
110 2014-07-21 12:39:59 <hearn> oh and hi sipa :)
111 2014-07-21 12:40:34 <wumpus> anyhow let's just not try to defend lazy practices by stating they could be worse
112 2014-07-21 12:41:16 <hearn> i think you underestimate the amount of work involved in not reusing keys, ever. i do not anticipate key reuse disappearing any time soon, i'm afraid
113 2014-07-21 12:41:25 <hearn> even with BIP32 wallets becoming more popular.
114 2014-07-21 12:41:43 <Luke-Jr> buZz: https://en.bitcoin.it/wiki/Address_reuse
115 2014-07-21 12:42:13 <hearn> most obviously, wallets i'm aware of or at least are in wide use attempt to store all keys in memory e.g. to display in the UI
116 2014-07-21 12:42:18 <hearn> or to send to the server or calculate bloom filters.
117 2014-07-21 12:42:22 <wumpus> sometimes it is worth to do some work to do things properly
118 2014-07-21 12:42:35 <hearn> but .... memory is finite. on desktop machines with swap you can sort of pretend memory is infinite even though it's not, and just accept terrible performance.
119 2014-07-21 12:42:49 <hearn> on mobiles you don't get that luxury. if you run out of memory you get OOM killed.
120 2014-07-21 12:43:00 <buZz> ty!
121 2014-07-21 12:43:08 <wumpus> keys just take up a few bytes, this is 2014
122 2014-07-21 12:43:11 <drizztbsd> use the swap luke
123 2014-07-21 12:43:11 <hearn> hence the need for key expiry and other things, which in turn means we need wide usage of bip 70
124 2014-07-21 12:43:15 <Luke-Jr> hearn: discard keys once they're used
125 2014-07-21 12:43:31 <hearn> a key never stops being used with today's model. you don't know if a user handed it out and someone else stored it in their address book.
126 2014-07-21 12:43:40 <drizztbsd> some web wallets generates a new address every time
127 2014-07-21 12:43:45 <drizztbsd> to discurage it
128 2014-07-21 12:43:45 <hearn> with BIP70 there's a fix for that but of course it's a slow rollout. not every wallet author implements it yet.
129 2014-07-21 12:43:51 <Luke-Jr> hearn: today's model makes no guarantee you can reuse it.
130 2014-07-21 12:44:10 <hearn> but in practice no wallets today expire keys. so users expectation is that they are reusable.
131 2014-07-21 12:44:15 <Luke-Jr> if a user sends you bitcoins twice using the same address, they've just lost the second one to confirm.
132 2014-07-21 12:44:16 <wumpus> and I'm not sure it's needed to store all keys in memory at all, you could give out keys and tell people to only use them once
133 2014-07-21 12:44:20 <wumpus> then scan the old keys periodically
134 2014-07-21 12:44:29 <wumpus> (for the cases that someone stupidly did send to them twice)
135 2014-07-21 12:44:58 <hearn> "scanning the old keys periodically" still requires you to be able to do that, even if the keys don't all fit in RAM.
136 2014-07-21 12:45:09 <wumpus> or just wait for them to mention that they send to an old address, and only then scan their used address
137 2014-07-21 12:45:27 <hearn> i mean, it's easy to complain and say wallet implementors are all lazy, but these sorts of things are real issues all wallet devs have been hitting
138 2014-07-21 12:46:35 <hearn> yeah, well that's possible if you have a block explorer handy. otherwise you can't just scan an address. you have to scan a segment of the chain forward using filtering. that's slow if it's a large possible period of time. not to mention that "hey I'm still waiting for the work, I sent you money" "huh it never turned up" is a terrible user experience that would just appear broken to people
139 2014-07-21 12:46:35 <wumpus> hearn: sure the worst-case scenario is the most difficult, writing a wallet that needs to handle millions of keys on a memory-constrained device
140 2014-07-21 12:46:48 <Luke-Jr> it's not a real issue if you simply discard an address after it's been used once in a confirmed transaction
141 2014-07-21 12:47:08 <hearn> yeah, sure, which is why BIP70 has an expiry time in it. exactly so we can manage memory in this way.
142 2014-07-21 12:47:17 <Luke-Jr> an expiry time isn't needed in most cases
143 2014-07-21 12:47:45 <drizztbsd> Luke-Jr: and what do you do with mining pools?
144 2014-07-21 12:48:02 <hearn> well, you go ahead and make a wallet that appears to regular users to just randomly break for no reason and see how competitive it is.
145 2014-07-21 12:48:31 <hearn> wumpus: i don't think you need millions of keys to start hitting problems unfortunately, but we haven't tested to see how far we can go yet.
146 2014-07-21 12:48:45 <Luke-Jr> drizztbsd: fix them
147 2014-07-21 12:49:13 <hearn> wumpus: it's also a matter of e.g. startup time, bloom filter calculation time, keys in ram take up more memory than just raw bytes on disk because of the overhead of object representation and so on. plus quite a few cheap/old phones give you 32mb of ram for everything, that includes all app data, code and artwork.
148 2014-07-21 12:49:18 <hearn> so yeah - pretty tricky.
149 2014-07-21 12:49:24 <Luke-Jr> hearn: you could always use a tree of bloom filters if you really have problems
150 2014-07-21 12:49:26 <hearn> i haven't yet implemented wraparound for bitcoinj but probably will have to
151 2014-07-21 12:50:09 <Luke-Jr> have a bloom filter for each year, then within those each month, then each day, etc as needed
152 2014-07-21 12:50:47 <hearn> yes there are usually technical solutions to all these problems. but they tend to be complicated. it's very far from "lazy devs don't care about privacy or security"
153 2014-07-21 12:50:59 <wumpus> hearn: well anyhow, maybe for heavy usage on small embedded devices you have a reason to sometimes reuse addresses... but that's stil not an excuse for the practice in common usage
154 2014-07-21 12:51:01 <hearn> for instance bloom filters have to be size matched, at least to be used on the same connection
155 2014-07-21 12:52:10 <wumpus> I suppose the general cases are either servers with lots of memory and high workloads, or small devices with occasional workloads
156 2014-07-21 12:52:43 <hearn> you have desktops where they have lots of memory and occasional workloads too. i think we can make the most progress there. but you still have the problem of infinite growth fitting into non-infinite resources
157 2014-07-21 12:52:53 <hearn> it just changes the timeframe in which you'd hit problems
158 2014-07-21 12:53:02 <hearn> s/desktops/desktops and laptops/
159 2014-07-21 12:53:06 <wumpus> if you want to use your el cheapo android phone to handle millions of transactions, well then maybe you should just invest in technology...
160 2014-07-21 12:53:29 <hearn> current android phones start running out of RAM after around 30-40,000 outputs, unfortunately
161 2014-07-21 12:53:38 <wumpus> nothing is *infinite*, that's a strawman argument, the block chain is limited too
162 2014-07-21 12:53:44 <hearn> that's just for the transaction data. mostly this only happens because bitcoinj doesn't prune transaction data down, and ideally it would.
163 2014-07-21 12:54:07 <hearn> ok sure. the key stream is not really infinite. so the question is, does your hardware scale faster than your bitcoin usage.
164 2014-07-21 12:54:18 <hearn> not sure where those two graph lines cross, needs measurement and simulation
165 2014-07-21 12:58:54 <wumpus> well sure, watching a growing number of keys forever will run into scaling problems at some point, but the proper solution to that is a key expiration (or: archival) policy, not reuse
166 2014-07-21 13:00:06 <Luke-Jr> funny how hearn is trying to justify reuse with reuse
167 2014-07-21 13:00:41 <hearn> Luke-Jr: how do you mean? i'm explaining it, not "trying to justify it". you can ignore the engineering realities if you like, but that won't change the level of address reuse we see on the real network.
168 2014-07-21 13:01:15 <hearn> wumpus: yes indeed. and for that we need to break the paradigm of people storing addresses in "address books". unfortunately we have no compelling replacement today.
169 2014-07-21 13:01:19 <wumpus> there is no ignoring going on here, just proposing better solutions
170 2014-07-21 13:01:30 <epscy> does somebody measure that? (address reuse on the network)
171 2014-07-21 13:01:39 <hearn> perhaps the diffie-hellman in BIP70 / stealth address proposals can help (if implemented)
172 2014-07-21 13:01:47 <hearn> but we need a lot more infrastructure to make that work
173 2014-07-21 13:01:48 <Luke-Jr> hearn: reuse will stop quite quickly if it stops working, I think.
174 2014-07-21 13:01:52 <jgarzik> I thought it was agreed that Bitcoin Wallet on Android address reuse was bad
175 2014-07-21 13:01:56 <jgarzik> and were moving to HD?
176 2014-07-21 13:02:08 <hearn> it is moving to HD. however it will likely still reuse addresses sometimes (wraparound)
177 2014-07-21 13:02:18 <hearn> as will likely all mobile wallets
178 2014-07-21 13:02:34 <jgarzik> RE storage cap, there is plenty of storage room of keys, and RAM for signing.  Backing up is more of an issue.
179 2014-07-21 13:02:47 <hearn> Luke-Jr: threats are pointless. you can't change the amount of RAM in phones by breaking bitcoin for ordinary users.
180 2014-07-21 13:03:12 <Luke-Jr> hearn: what?
181 2014-07-21 13:03:13 <hearn> jgarzik: well, you'd be surprised .... i've optimised where i can by e.g. rederiving private keys on the fly and only storing public keys in memory.
182 2014-07-21 13:03:35 <hearn> jgarzik: but mobiles don't give you much memory. you can't use all the ram on the device. you get a tiny subset of it
183 2014-07-21 13:03:39 <hearn> that's how they make multitasking fast.
184 2014-07-21 13:03:45 <jgarzik> of course
185 2014-07-21 13:04:19 <hearn> Luke-Jr: you were suggesting mining pools stop address reuse from "working", no?
186 2014-07-21 13:05:23 <hearn> anyway, we need to measure in various profiles and see how many keys can fit. currently we're waiting for the new bouncy castle to release. the current bottleneck is cpu not ram.
187 2014-07-21 13:05:27 <Luke-Jr> hearn: no, I was suggesting wallets stop monitoring addresses after they've been used/confirmed
188 2014-07-21 13:05:33 <hearn> Luke-Jr: oh, i see, sory.
189 2014-07-21 13:05:54 <hearn> Luke-Jr: yes but no wallet dev will do that. it'd break how people use wallets in the real world. the trend is the opposite - wallets are currently competing on their address book implementations
190 2014-07-21 13:05:57 <Luke-Jr> hearn: although Eligius has in the past filtered out reuse, and could do so again if someone takes the effort to address the issues in that patch
191 2014-07-21 13:06:29 <buZz> i would like to see 'want to save' as option on 'getnewaddress'
192 2014-07-21 13:06:30 <hearn> Luke-Jr: with things like linking addresses to phone numbers and so on. people want the ability to send money to a name/face and wallet devs are trying to provide that within the current protocol constraints.
193 2014-07-21 13:06:37 <buZz> so i can use temporary accounts
194 2014-07-21 13:06:48 <Luke-Jr> hearn: well, then we need to ostracate wallets which encourage broken behaviour; I already encourage people not to use such broken wallets.
195 2014-07-21 13:07:04 <hearn> still, i think we're going to impose a two-week lifetime on refund addresses in bip70 or something like that.
196 2014-07-21 13:07:23 <hearn> so there will be slow and steady progress towards optimising address re-use. but it'll always be an optimisation problem i think.
197 2014-07-21 13:08:18 <jgarzik> just talk to miners about requiring a higher fee for dumb, anti-privacy policies like this and the rest will sort itself out
198 2014-07-21 13:08:38 <hearn> ah yes, the whole "lazy devs just need to be given an incentive"
199 2014-07-21 13:08:49 <hearn> why does this keep coming up when - reality check - bitcoin core is not even HD and nobody even started?
200 2014-07-21 13:08:52 <epscy> not sure relying on miners to be civic minded is going to work
201 2014-07-21 13:08:54 <hearn> you don't make progress by punishing users
202 2014-07-21 13:09:01 <Luke-Jr> hearn: Bitcoin Core never reuses addresses, nor encourages it
203 2014-07-21 13:09:39 <jgarzik> hearn, furthermore, sipa has already started, PRs exist
204 2014-07-21 13:09:56 <hearn> no, it just risks users destroying their money instead. i've actually encountered a relatively high profile user of Core who was making nightly wallet backups, but using up more keys per day than the default keypool size. disaster could have struck at any moment.
205 2014-07-21 13:10:13 <Luke-Jr> you don't need HD wallets to avoid address reuse. you need HD wallets to avoid regular backups.
206 2014-07-21 13:10:41 <Luke-Jr> hearn: really? more than 100 txn per day?
207 2014-07-21 13:10:46 <hearn> yep
208 2014-07-21 13:10:54 <Luke-Jr> hearn: sounds like we should increase the default keypool size then
209 2014-07-21 13:10:59 <hearn> quite possibly!
210 2014-07-21 13:11:03 <hearn> i certainly advised them to
211 2014-07-21 13:11:06 <wumpus> bitcoin core is also not where wallet innovation happens
212 2014-07-21 13:11:25 <Luke-Jr> wumpus: dunno, at this point it's better than most others IMO
213 2014-07-21 13:11:45 <Luke-Jr> 
ACTION wonders how to measure a reasonable keypool size

214 2014-07-21 13:12:54 <wumpus> also, I've proposed multiple times to make keypool refill manual instead of automatic, so that a sane backup policy can be enforced
215 2014-07-21 13:13:36 <wumpus> there is even a pull implementing that option somewhere
216 2014-07-21 13:13:42 <Luke-Jr> wumpus: I like the idea, but it's crufty - might end up with idiots reusing addresses just to avoid it :/
217 2014-07-21 13:14:21 <wumpus> Luke-Jr: well it would just fail if the keypool is exhausted; same as now happens in that case if you request a new key with an encrypted wallet
218 2014-07-21 13:14:25 <Luke-Jr> and unnecessary for HD wallets, which hopefully we'll get soon
219 2014-07-21 13:15:07 <wumpus> Luke-Jr: but for the non-HD wallet case it'd be the only way to be safe
220 2014-07-21 13:15:30 <Luke-Jr> hm
221 2014-07-21 13:15:44 <Luke-Jr> unrelated: is EC encryption safe to reuse keys for?
222 2014-07-21 13:15:47 <wumpus> the way it works currently is grossly irresponsible
223 2014-07-21 13:16:04 <Luke-Jr> 
ACTION ponders encrypting metadata and automating backups of it every time it changes

224 2014-07-21 13:17:30 <Luke-Jr> wumpus: I suppose the crufty edges of a manual refill are reasonably acceptable as soon as we can tell end users to upgrade to HD wallets to avoid it
225 2014-07-21 13:18:35 <Luke-Jr> lol reddit "If security wasnt good enough for web-wallets they wouldnt exist."
226 2014-07-21 13:22:45 <hearn> that transition would have to be carefully managed. otherwise a lot of people would upgrade Core and discover their app/exchange/pool had broken.
227 2014-07-21 13:23:00 <hearn> but yes it's probably a good idea/safer than the current arrangement
228 2014-07-21 13:23:58 <wumpus> hearn: it would have been an option anyhow
229 2014-07-21 13:24:18 <wumpus> which defaults to the current way for backwards compatibility
230 2014-07-21 13:24:25 <hearn> yeah
231 2014-07-21 13:24:53 <hearn> or it could just wrap around and start reusing addresses once the keypool is exhausted, until a new backup is made, which grows the pool and makes a backup simultaneously.
232 2014-07-21 13:25:38 <wumpus> no, it won't wrap around
233 2014-07-21 13:26:42 <wumpus> I'm against address reuse and anyhow that would mess up expectations even more; what if you use the receiving address to keep track of payments in some other db!
234 2014-07-21 13:27:01 <hearn> that is true
235 2014-07-21 13:27:05 <wumpus> better to just fail so that some admin gets page
236 2014-07-21 13:27:09 <hearn> reuse would also be an api change
237 2014-07-21 13:27:42 <Luke-Jr> reuse is broken behaviour. it should never happen.
238 2014-07-21 13:27:48 <Luke-Jr> if it happens, something is broken
239 2014-07-21 13:28:52 <hearn> i think i prefer the term suboptimal to broken, but whatever.
240 2014-07-21 13:48:27 <Luke-Jr> wumpus: it might be good to explicitly mention the all-to-often requests for adding a static node to results for "research" in the DNSSeed policy, just so people know up front there's no exception (or if there is, what the rules are)
241 2014-07-21 13:48:35 <Luke-Jr> all-too-often*
242 2014-07-21 13:51:15 <wumpus> Luke-Jr: agreed; that is part of 'unfair' node selection
243 2014-07-21 13:51:33 <hearn> sipa: just wanted to double check that it was indeed a bug and not an issue with how i am using the coins api
244 2014-07-21 15:00:18 <dgenr8> if address reuse is ever going to stop working, sooner would be better because the social patterns are being established.
245 2014-07-21 15:03:11 <dgenr8> when someone gives you an address, you would start to protect it until paying to it.  you don't want someone else mucking it up
246 2014-07-21 15:06:57 <epscy> i don't really see how it's possible to enforce not reusing addresses
247 2014-07-21 15:09:41 <Eliel_> epscy: simple, make a network rule that only one transaction is valid per address.
248 2014-07-21 15:10:23 <Luke-Jr> Eliel_: that can't be a network rule without burdening nodes
249 2014-07-21 15:10:47 <Luke-Jr> miners can deprioritise/filter it, and wallets can skip looking for it..
250 2014-07-21 15:14:55 <Eliel_> if the only goal is to minimize the amount of people who'd even attempt reusing addresses, all you need is to make the network rule apply for n-blocks, where n is sufficiently big that people won't bother keeping addresses they can't send to.
251 2014-07-21 15:18:59 <cfields> BlueMatt: it's going to be at least another week until I can begin deploying my work. I'm going to need a few things from gavin, and he's currently away
252 2014-07-21 15:19:27 <cfields> *deploying for real. I'll be testing/simulating in the meantime
253 2014-07-21 15:30:59 <hearn> BlueMatt: I think cfields is working on making it run on Jenkins. the java side itself isn't changing.
254 2014-07-21 15:31:04 <hearn> though i'm working on it a little bit at the moment
255 2014-07-21 15:31:30 <cfields> yep, just build-side for me. runtime checks are all you guys :)
256 2014-07-21 15:47:33 <dgenr8> Luke-Jr: a list of 34-byte addresses could hold a heck of a lot of them.  I think it would have fit in 1G at the start of this year.
257 2014-07-21 15:48:18 <Luke-Jr> dgenr8: they're only 20 bytes really
258 2014-07-21 15:48:35 <Luke-Jr> in theory one could use a bloom filter too, although then there's a risk of false positives
259 2014-07-21 15:49:04 <dgenr8> probably still fits in 1G them
260 2014-07-21 15:53:29 <Luke-Jr> I think so
261 2014-07-21 17:45:56 <dcousens> Luke-Jr: what's wrong with BIP38?
262 2014-07-21 17:47:53 <Luke-Jr> dcousens: it represents a single EC private key, which is not sufficient for offline storage, and encourages end-user key management which itself has numerous problems
263 2014-07-21 17:48:12 <Luke-Jr> dcousens: it probably wouldn't even be a BIP had the idea followed proper procedures
264 2014-07-21 17:50:36 <dcousens> Luke-Jr: understandable
265 2014-07-21 18:32:13 <AmThatsMe> Hey everyone
266 2014-07-21 18:34:33 <AmThatsMe> I'm having some problems debugging the reference code (Unit tests). I'm using Eclipse on OSX, i configured the build with ./configure --enable-debug=true to add debug flags to the make files. When i mark a row with a breakpoint i get one of 2 things : 1) source not found OR 2) breakpoint cannot be installed.  Anyone has some suggestions or can help ?
267 2014-07-21 18:35:15 <sipa> sorry, i'm not familiar with eclipse for C++ development
268 2014-07-21 18:35:18 <sipa> in gdb it works
269 2014-07-21 18:36:09 <Luke-Jr> AmThatsMe: =true is wrong
270 2014-07-21 18:36:13 <Luke-Jr> just --enable-debug
271 2014-07-21 18:43:40 <AmThatsMe> sipa: do u debug in gdb command line ? or use something like cgdb ?
272 2014-07-21 18:43:48 <sipa> command line
273 2014-07-21 18:44:04 <AmThatsMe> Luke-jr: ok thanks, i will try it !
274 2014-07-21 18:45:26 <AmThatsMe> ok, thanks sipa
275 2014-07-21 18:50:50 <jcorgan> speaking of debugging, i know real men use gdb command-line, but i'd be happy to have some of gdb's commands automated.  there used to be (i guess still is) something called 'ddd' that was a nice graphical shell around gdb.
276 2014-07-21 18:51:14 <jcorgan> any others like that?
277 2014-07-21 18:58:06 <wumpus> well if you want to automate things gdb has a pretty nice python interface
278 2014-07-21 18:59:07 <wumpus> it allows programatically executing almost all of the gdb commands, including nesting into data structures, getting values, stepping, etc
279 2014-07-21 18:59:54 <wumpus> and it even works for remote debugging sessions
280 2014-07-21 19:01:11 <jcorgan> hmm, will look into that.
281 2014-07-21 19:05:32 <wumpus> also the TUI mode is nice in gdb
282 2014-07-21 19:08:42 <jcorgan> TIL
283 2014-07-21 19:09:02 <jcorgan> normally use emacs gdb mode, but this looks better
284 2014-07-21 19:43:48 <cronus> why does importaddress take so long to run?
285 2014-07-21 19:45:32 <cronus> in fact im not sure its even working, just hangs
286 2014-07-21 19:46:55 <sipa> it needs to rescan the entire blockchain for transactions affecting the imported address
287 2014-07-21 19:47:09 <sipa> it may take 20 minutes
288 2014-07-21 19:57:00 <cronus> even with rescan=false?
289 2014-07-21 19:57:32 <cronus> if I know its a brand new address that has 0 transactions
290 2014-07-21 20:02:13 <sipa> with rescan false, it shouldn't take too long
291 2014-07-21 20:03:33 <cronus> hm still seems to take too long to wait synchronously before returning the address to an enduser for payment.  Seems like only solution would be to pre-generate and import a pool of addresses and constantly refill asynchronously
292 2014-07-21 20:03:51 <sipa> define 'too long' ?
293 2014-07-21 20:04:05 <cronus> well its been over 3 minutes and its still going
294 2014-07-21 20:04:16 <cronus> if its triggered by an http request it’s going to time out
295 2014-07-21 20:04:17 <sipa> what's the exact request you're sending?
296 2014-07-21 20:04:33 <sipa> if it's more than ~seconds, there's something wrong
297 2014-07-21 20:04:54 <cronus> oh ok then maybe its scanning, the bitcoin-cli isn’t really clear on how to use it
298 2014-07-21 20:05:21 <cronus> ive tried a couple ways importaddress address mylabel false   and   importaddress mylabel rescan=false
299 2014-07-21 20:05:34 <cronus> er that second one is missing the address
300 2014-07-21 20:05:38 <cronus> but it’s not clear which way to do it
301 2014-07-21 20:05:41 <cronus> neither seem to work then
302 2014-07-21 20:06:43 <sipa> bitcoin-cli importaddress address label false
303 2014-07-21 20:07:08 <cronus> yeah thats the first thing i tried
304 2014-07-21 20:07:43 <sipa> you didn't forget the label?
305 2014-07-21 20:07:51 <cronus> nope
306 2014-07-21 20:07:58 <cronus> ./bitcoin-cli importaddress 16kBbmD6SWXoUmfxWgLxhCyFWS4YARp1Wt label false
307 2014-07-21 20:08:02 <cronus> still running..minutes later
308 2014-07-21 20:09:30 <sipa> oh, importaddress
309 2014-07-21 20:10:01 <cronus> ?
310 2014-07-21 20:10:10 <sipa> i thought you were talking about importprivkey
311 2014-07-21 20:10:16 <sipa> but it should be identical for importaddress
312 2014-07-21 20:10:27 <sipa> if it's not, and you can reproduce it, please file a bug
313 2014-07-21 20:10:52 <sipa> (which is very new, so it may have quirks)
314 2014-07-21 20:11:23 <cronus> yeah maybe the option to not rescan is being ignored or something? or is that too trivial
315 2014-07-21 20:12:32 <sipa> the code looks correct at first glace
316 2014-07-21 20:12:39 <sipa> but i haven't tested it
317 2014-07-21 20:14:18 <gribble> 138980050.639
318 2014-07-21 20:14:18 <sipa> ;;nethash