1 2014-08-13 03:18:37 <earlz> So, are floating points at all safe to use in protocol level code for the reference wallet?
  2 2014-08-13 03:19:17 <earlz> My impression is that floating points can vary depending on compiler, platform, OS, etc
  3 2014-08-13 03:31:59 <Luke-Jr> earlz: it's never appropriate to memcpy complex memory over the network, even if it's simple >8-bit integers.
  4 2014-08-13 03:32:19 <Luke-Jr> earlz: that's why Bitcoin Core doesn't work on anything but x86 really (and to a limited extent, ARM)
  5 2014-08-13 03:33:59 <jcrubino> can bitcoind be set to just "sit" on the network in spv mode?
  6 2014-08-13 03:38:58 <poutine> What is the reasoning behind restricting the redeemscript to pushdata operations?
  7 2014-08-13 03:39:32 <poutine> or am I reading "Validation fails if there are any operations other than "push data" operations in the scriptSig." from bip-0016 wrong?
  8 2014-08-13 03:42:46 <poutine> nevermind
  9 2014-08-13 03:43:35 <Luke-Jr> jcrubino: bitcoind does not support SPV mode today.
 10 2014-08-13 03:44:19 <jcrubino> Luke-Jr; the wiki indicates it is capable of a "hybrid"
 11 2014-08-13 03:44:29 <Luke-Jr> jcrubino: where?
 12 2014-08-13 03:45:25 <jcrubino> mybad:  "integrated"
 13 2014-08-13 03:45:32 <jcrubino> still nebulous
 14 2014-08-13 03:45:48 <jcrubino> https://en.bitcoin.it/wiki/Clients#For_developers
 15 2014-08-13 03:47:08 <jcrubino> Luke-Jr: integarted as in monolithic implementation is my new interpretation
 16 2014-08-13 04:22:40 <poutine> if a txout was: OP_HASH160 [20-byte-hash of {OP_1} ] OP_EQUAL (P2SH), and a txin scriptSig is OP_1 [serialized {OP_1}], would that work?
 17 2014-08-13 04:23:03 <poutine> I meant if a txout scriptPubKey was
 18 2014-08-13 04:28:32 <andytoshi> hey, wizards-wallet just validated the whole testnet chain :)
 19 2014-08-13 04:28:52 <andytoshi> (it doesn't do P2SH yet so that's not a real accomplishment..)
 20 2014-08-13 04:29:07 <Luke-Jr> andytoshi: is it a wallet or a node? O.o
 21 2014-08-13 04:29:46 <andytoshi> Luke-Jr: a wallet. but i need a working script implementation because i'm bolting a coinjoin client/server onto it and it needs to validate txes
 22 2014-08-13 04:30:03 <andytoshi> and i also wanna do coinswaps, and atomic cross-chain swaps, and whatever else takes my fancy..
 23 2014-08-13 04:30:08 <Luke-Jr> andytoshi: why not a library for that?
 24 2014-08-13 04:30:16 <andytoshi> Luke-Jr: i'm writing the library :)
 25 2014-08-13 04:30:20 <Luke-Jr> ah
 26 2014-08-13 04:30:21 <andytoshi> i'm in rust
 27 2014-08-13 04:35:07 <Luke-Jr> andytoshi: btw, rust can use C libs and vice-versa, right?
 28 2014-08-13 04:36:16 <andytoshi> Luke-Jr: yeah, though it's a bit nasty to use rust libs from C
 29 2014-08-13 04:36:23 <andytoshi> because you need to start the rust runtime from C
 30 2014-08-13 04:37:01 <andytoshi> and it's also nasty to use C libs from rust because you have to read the API docs very carefully (or more likely, study the code <.<) to construct a safe API which follows rust's aliasing and mutability rules
 31 2014-08-13 04:37:27 <Luke-Jr> rust needs a runtime? :<
 32 2014-08-13 04:37:42 <jrick> depends
 33 2014-08-13 04:37:51 <jrick> libgreen needs one
 34 2014-08-13 04:37:56 <andytoshi> otherwise you wind up with unsafe{} blocks everywhere
 35 2014-08-13 04:38:00 <jrick> (which has the M:N threading model)
 36 2014-08-13 04:38:06 <andytoshi> Luke-Jr: a very minimal one
 37 2014-08-13 04:38:12 <andytoshi> for task spawning, as jrick says
 38 2014-08-13 04:38:18 <andytoshi> if you are using libnative (the default
 39 2014-08-13 04:38:22 <andytoshi> ) it's basically just a shim
 40 2014-08-13 04:38:52 <andytoshi> oh, and it supports unwinding in case of task failure
 41 2014-08-13 04:48:46 <davec> poutine: that looks accurate, just be aware that serialied OP_1 -> OP_81
 42 2014-08-13 04:49:08 <poutine> Thanks davec
 43 2014-08-13 04:49:41 <gmaxwell> davec: huh? you mean seralized OP_1 = 0x81
 44 2014-08-13 04:49:43 <davec> err sorry I meant it's just OP_1
 45 2014-08-13 04:50:04 <davec> i.e so it's canonical don't add an OP_DATA_1 in front of it
 46 2014-08-13 04:51:20 <davec> gmaxwell, right I mean 0x81, not OP_81.
 47 2014-08-13 04:56:51 <poutine> It wouldn't be 51?
 48 2014-08-13 04:56:53 <poutine> 0x51
 49 2014-08-13 04:57:49 <gmaxwell> hah indeed. my memory is off-base.
 50 2014-08-13 04:58:08 <davec> here, with scriptbuilder -> scriptPubkey: a914568750a966ff3c89a80cdf13fdb27955bc0a053887, scriptSig: 510151
 51 2014-08-13 05:00:04 <davec> wow, yeah we're both remining 0x81 instead of 81 (0x51). sigh
 52 2014-08-13 05:03:07 <davec> poutine: oh I hashed the whole thing instead of just the OP_1.  This looks right: scriptPubkey: a914da1745e9b549bd0bfa1a569971c77eba30cd5a4b87, scriptSig: 510151
 53 2014-08-13 05:03:32 <davec> been too long since I manually created one
 54 2014-08-13 05:04:42 <poutine> I keep getting a91445296d4fe0a8645c200ce8a846e1d5547f7528fd87
 55 2014-08-13 05:04:45 <poutine> when I do it
 56 2014-08-13 05:04:56 <poutine> I wonder what I'm messing up
 57 2014-08-13 05:05:39 <poutine> Let me try with yours
 58 2014-08-13 05:08:28 <poutine> 5114568750a966ff3c89a80cdf13fdb27955bc0a0538 is the scriptSig I'm generating to redeem that
 59 2014-08-13 05:08:34 <poutine> but it is not working
 60 2014-08-13 05:09:01 <poutine> hmm I think I know what I did wrong, sorry for cluttering the channel
 61 2014-08-13 05:10:09 <davec> poutine: You're probably not using Go, but here is what I used to generate that: http://zer0byte.com/zeropastebin/?c78d293a25ca5fe7#nDEWIsnEmvvM7qMK7NjqPHazgxwcRnxQ9yZuow3yZ0g=
 62 2014-08-13 05:14:49 <jrick> davec: could probably clean that api up by making the constructor a variadic function
 63 2014-08-13 05:15:08 <jrick> ...interface{}, bytes are opcodes, []byte is data
 64 2014-08-13 05:16:49 <davec> yeah, but then you have to return errors
 65 2014-08-13 05:17:04 <davec> when somebody passes something that isn't one of them, runtime versus compile
 66 2014-08-13 05:17:14 <Luke-Jr> wumpus: any magic for 'make src/bitcoind+install'? :P
 67 2014-08-13 05:17:30 <wumpus> Luke-Jr: no :( that's a problem in general with the make-based selective approach
 68 2014-08-13 05:17:56 <wumpus> install is always 'build everything that was selected, install everything that was selected'
 69 2014-08-13 05:17:59 <Luke-Jr> oh well :x
 70 2014-08-13 05:18:17 <jrick> davec: type Opcode interface ? :)
 71 2014-08-13 05:18:26 <jrick> er
 72 2014-08-13 05:18:28 <jrick> Op
 73 2014-08-13 05:18:51 <jrick> I guess it still ugly
 74 2014-08-13 05:20:01 <jrick> btw our const () block is wrong, it needs the 'byte' type for each
 75 2014-08-13 05:20:13 <jrick> everything but OP_FALSE is untyped
 76 2014-08-13 05:22:45 <davec> not wrong, just not explicit and yeah I agree it should be
 77 2014-08-13 05:40:12 <poutine> davec, I hate to ask this, but could you dump the hex string value of hash?
 78 2014-08-13 05:40:24 <poutine> I've struggled getting this go environment up, but will continue trying
 79 2014-08-13 05:41:19 <davec> hash: da1745e9b549bd0bfa1a569971c77eba30cd5a4b
 80 2014-08-13 05:41:55 <poutine> Thanks
 81 2014-08-13 05:47:32 <poutine> Ok got it crafted and spent, thanks a bunch davec
 82 2014-08-13 06:01:50 <jcrubino> andytoshi: how are you handling the rust api changes
 83 2014-08-13 06:01:59 <jcrubino> I cant get examples from two months ago to run
 84 2014-08-13 06:03:03 <andytoshi> jcrubino: i'm always on #rust and #rust-internals on irc.mozilla.org, i generally react to any breaking changes within a day
 85 2014-08-13 06:03:20 <andytoshi> iirc there haven't been any that affected me in the last month or so
 86 2014-08-13 06:03:45 <jcrubino> is there any api subset freezes planned?
 87 2014-08-13 06:03:53 <andytoshi> oh, no, there was one 13 days ago that broke a ton of stuff, but i was responsible for that one
 88 2014-08-13 06:04:15 <andytoshi> jcrubino: yeah, all the docs have a stable/experimental/deprecated tag on every method
 89 2014-08-13 06:04:22 <andytoshi> and there is work toward stabilizing everything in the stdlib
 90 2014-08-13 06:05:14 <jcrubino> ah, i noticed the experimental but overlooked the stable tags
 91 2014-08-13 06:05:49 <andytoshi> as cargo matures the hope is that everything non-crucial to the compiler can be moved into separate libs
 92 2014-08-13 06:06:19 <andytoshi> then with cargo you can set dependencies to specific versions (or even git commits), and the rust community takes semantic versioning MAJOR.minor.bugfix seriously
 93 2014-08-13 06:07:51 <jcrubino> good to know, I am going to have stop into #rust on mozilla to learn more
 94 2014-08-13 06:19:38 <BlueMatt> ;;seen gavinandresen
 95 2014-08-13 06:19:38 <gribble> gavinandresen was last seen in #bitcoin-dev 1 week, 0 days, 15 hours, 2 minutes, and 9 seconds ago: <gavinandresen> Anyway, if you're really and truly paranoid you should be using a multisig wallet so even if you're copy of bitcoin core is unsafe your coins are still safe.
 96 2014-08-13 08:30:45 <wumpus> so now that showmyip.com no longer exists, everyone is trying to replace it with their own whatismyip service
 97 2014-08-13 08:31:42 <wumpus> https://github.com/bitcoin/bitcoin/pull/4686 https://github.com/bitcoin/bitcoin/pull/4691
 98 2014-08-13 08:32:00 <wumpus> .. or just removing it like https://github.com/bitcoin/bitcoin/pull/4682
 99 2014-08-13 08:32:04 <Luke-Jr> lol
100 2014-08-13 08:32:44 <wumpus> it's clear that some decision needs to be made here
101 2014-08-13 08:33:08 <Luke-Jr> it's obvious polling an external site is dumb and useless
102 2014-08-13 08:33:16 <Luke-Jr> just see what some random peer sees you as
103 2014-08-13 08:33:47 <wumpus> agreed; random peers can lie to you, but so can a random external site (especially without authentication)
104 2014-08-13 08:34:38 <Luke-Jr> even if they lie to you, we don't use it for anything important afaik
105 2014-08-13 08:34:53 <wumpus> we use it to determine what address we advertise
106 2014-08-13 08:34:56 <Luke-Jr> worst case you might be stuck with your initial 8 peers
107 2014-08-13 08:34:56 <wumpus> so kinda important
108 2014-08-13 08:35:10 <Luke-Jr> basically has the same effect as not forwarding the port
109 2014-08-13 08:35:21 <wumpus> (well, important if it could be disrupted on a massive scale)
110 2014-08-13 08:35:47 <wumpus> I agree it's pointless to lie to just one peer
111 2014-08-13 08:36:38 <Luke-Jr> if all 8 of your nodes are conspiring to hide your IP, you're probably already screwed ;x
112 2014-08-13 08:37:28 <gmaxwell> it sounds like you guys don't actually understand my solution.
113 2014-08-13 08:37:32 <gmaxwell> thats unfortunate.
114 2014-08-13 08:37:41 <wumpus> we're not talking about your solution ,just the problem
115 2014-08-13 08:38:14 <gmaxwell> wumpus: My solution has no problem with peers lying to you.
116 2014-08-13 08:39:49 <gmaxwell> It gives the peer the address it gave you back to it. If it lies to you it doesn't change your behavior in any respect except what you send to the self-same peer.
117 2014-08-13 08:40:29 <wumpus> gmaxwell: nice!
118 2014-08-13 08:41:03 <wumpus> gmaxwell: sounds like a very sensible solution
119 2014-08-13 08:41:21 <gmaxwell> if anyone has cycles to test, https://github.com/gmaxwell/bitcoin/commits/extip3
120 2014-08-13 08:43:57 <gmaxwell> in case the peer is merely braindamaged and not malicious, it only uses the peer provided one sometimes. Definition of 'sometimes' is about the only thing that prevents this from being completely trivial.
121 2014-08-13 08:45:57 <wumpus> good for privacy too, to only give out information to peers that we received from them
122 2014-08-13 08:46:32 <wumpus> would even work for tor hidden services
123 2014-08-13 08:48:11 <gmaxwell> wumpus: my patch also soft-disables address discovery if using -proxy (I'm not sure why we didn't do that before)
124 2014-08-13 08:49:52 <wumpus> gmaxwell: the reasoning, afaik, is that -proxy disables -listen, no listen disables -discover
125 2014-08-13 08:50:13 <wumpus> (and -upnp)
126 2014-08-13 08:51:50 <gmaxwell> wumpus: right but -proxy -listen is the hidden service configuration.
127 2014-08-13 08:52:07 <wumpus> gmaxwell: agreed
128 2014-08-13 08:53:04 <wumpus> gmaxwell: although a hidden service would provide -externalip
129 2014-08-13 08:53:17 <wumpus> gmaxwell: which also disables -discover
130 2014-08-13 08:53:32 <wumpus> gmaxwell: but I'm OK with a little belt-and-suspenders here so let's add that
131 2014-08-13 09:30:45 <michagogo> 11:51:33 <gmaxwell> wumpus: right but -proxy -listen is the hidden service configuration.
132 2014-08-13 09:30:45 <michagogo> Eh? Isn't that -onion?
133 2014-08-13 09:31:09 <gmaxwell> michagogo: only if you also want to use the ipv4 internet.
134 2014-08-13 09:31:59 <gmaxwell> (without tor)
135 2014-08-13 09:31:59 <wumpus> -onion is useful if you want to be able to connect to hidden services in your ipv4/ipv6 node
136 2014-08-13 09:32:03 <michagogo> gmaxwell: you're still using ipv4 internet with -proxy
137 2014-08-13 09:32:14 <gmaxwell> michagogo: I clarified.
138 2014-08-13 09:32:22 <michagogo> For that you want -onlynet=tor, iirc?
139 2014-08-13 09:32:24 <wumpus> michagogo: -onlynet=tor
140 2014-08-13 09:32:25 <wumpus> yes
141 2014-08-13 09:32:29 <michagogo> gmaxwell: yeah, I saw
142 2014-08-13 09:32:50 <michagogo> Onnention lagging a bit, sorry
143 2014-08-13 09:32:51 <michagogo> Connection*
144 2014-08-13 09:33:04 <wumpus> the point of -proxy is to send all outgoing requests through a proxy
145 2014-08-13 09:33:17 <wumpus> it overrides the ipv4, ipv6 and onion proxy
146 2014-08-13 09:33:24 <michagogo> right
147 2014-08-13 09:36:05 <wumpus> whoa my MRU CCoinsCache based on boost::bimap is actually working
148 2014-08-13 09:37:33 <michagogo> Which is orthogonal to hidden services
149 2014-08-13 09:37:36 <michagogo> To running one, that is
150 2014-08-13 09:38:03 <wumpus> michagogo: yes
151 2014-08-13 09:38:25 <wumpus> a hidden service is just an extra source of incoming connections, it doesn't affect how you handle outgoing ones
152 2014-08-13 09:43:32 <cdecker>  îS#îS/mark
153 2014-08-13 09:48:08 <wumpus> anyhow - I'm going to merge #4682 now so that we don't poll the real-estate broker anymow, hopefully many people will test gmaxwell's tree so that we can get rid of the external IP poll completely
154 2014-08-13 09:49:14 <wumpus> s/anymow/anymore
155 2014-08-13 09:54:14 <cdecker> Will test as soon as I can :-)
156 2014-08-13 12:24:19 <netg_> peter todd left bitcoin dev for viacoin, is that true?
157 2014-08-13 12:25:37 <btcdrak> We hired him to work on tree-chains, I that doesnt affects his contribution to bitcoin.
158 2014-08-13 12:26:08 <btcdrak> *it doesnt affect his contribution to bitcoin.
159 2014-08-13 12:27:11 <btcdrak> if you are wondering where he's been for the last week: https://twitter.com/petertoddbtc/status/499417331173707776
160 2014-08-13 12:27:40 <netg_> ic, thank you
161 2014-08-13 12:28:04 <Luke-Jr> 
ACTION should figure out how petertodd manages his time :p

162 2014-08-13 12:28:32 <netg_> personl assistant :o
163 2014-08-13 12:41:51 <hearn> petertodd: ah you're back? your testnet seed is hosed again, i think
164 2014-08-13 14:24:27 <bsm1175321> Regarding HD wallets, I'm pretty disappointed that any compromised private key compromises all others.  Has anyone suggested an alternate HD algorithm in which this is not the case?
165 2014-08-13 14:25:08 <sipa> it's theoretically impossible to have that property with ecdsa
166 2014-08-13 14:25:45 <jgarzik> bsm1175321, (1) the compromise of a wallet has similar impact, (2) regen the HD seed periodically
167 2014-08-13 14:26:14 <sipa> hardened derivation limits the impact of that, but also hurts convenience
168 2014-08-13 14:26:55 <jgarzik> Have to examine key security not just at the granular level, but also look at wallet practices, and how it trickles down to the user.  Today, a "compromised private key" can mean compromised-all-keys-in-wallet.
169 2014-08-13 14:27:12 <sipa> (you need a child private key + parent extended public key; just a private key isn't enough, but it's sad that this elevates extended public keys to somewhat secret data)
170 2014-08-13 14:27:13 <bsm1175321> As far as remembering a word phrase and the capacity of human memory, regenning the HD seed is kind of a nightmare.
171 2014-08-13 14:27:49 <sipa> on the other hand, the use cases for actually revealing private keys are probably limited
172 2014-08-13 14:28:16 <bsm1175321> I can memorize a 12-word phrase, but I don't want to have to re-memorize one, ever.
173 2014-08-13 14:28:36 <jgarzik> bsm1175321, not refreshing periodically is poor security practice.  (PSA. brain wallets are highly insecure, if you are just thinking up a phrase on your own, rather than generating it programmaticaly)
174 2014-08-13 14:28:39 <bsm1175321> sipa: One can "import a wallet" in several web and offline wallets, by giving it the private key.
175 2014-08-13 14:28:50 <sipa> bsm1175321: i think that's crazy :)
176 2014-08-13 14:29:00 <bsm1175321> sipa: agreed, but it's a valuable use case.
177 2014-08-13 14:29:06 <jgarzik> sipa, the use case for revealing HD seeds is even more limited ;p
178 2014-08-13 14:29:23 <jgarzik> it has similar attack surface as wallet master key
179 2014-08-13 14:29:36 <sipa> bsm1175321: importing a watch-only wallet, sure
180 2014-08-13 14:29:52 <sipa> bsm1175321: if you actually want the webwallet to be able to spend things (and not just watch), i think it should have independent keys
181 2014-08-13 14:30:02 <sipa> dealing with coins thta can be spent from multiple places is a nightmare
182 2014-08-13 14:30:45 <bsm1175321> jgarzik: I'm talking about memorizing a programatically-generated phrase.  A little app which makes you type it over and over to aid in memorization would be helpful.  There are UI issues to work on here.
183 2014-08-13 14:30:56 <sipa> oh, i also think brainwallets are crazy
184 2014-08-13 14:31:23 <jgarzik> Consider funding levels in the security plan, too.  Day to day spending can occur from a lower security wallet, where the compromise risk is monetarily limited.  Periodically refresh from high security, perhaps offline/paper wallet.
185 2014-08-13 14:31:26 <bsm1175321> sipa: why?  No matter what you're going to need to memorize the relevant number of bits in a password.
186 2014-08-13 14:31:42 <sipa> bsm1175321: we have storage devices which much better reliability than human brains
187 2014-08-13 14:32:01 <sipa> one was invented a few thousand years ago even, called paper
188 2014-08-13 14:32:05 <bsm1175321> sipa: but you're going to want to unlock it somehow.  The lowest-bit password in the process is the attack vector.
189 2014-08-13 14:32:27 <sipa> no, there's a huge difference
190 2014-08-13 14:32:33 <bsm1175321> I know it's the 21st century and everything, but once upon a time, thieves would actually come into your house and take paper.
191 2014-08-13 14:32:48 <sipa> a brainwallet was unlimited eternal and unconditional attack surface: the whole world can continually try to break it
192 2014-08-13 14:33:08 <helo> it is certainly impractical for people to remember rotating high-entropy passphrases
193 2014-08-13 14:33:10 <bsm1175321> Let them.  I can calculate how long that would take...
194 2014-08-13 14:33:13 <jgarzik> and does.  brainwallet stealing robots exist.  a reddit post demonstrated common passwords are stolen in < 30 seconds.
195 2014-08-13 14:33:16 <sipa> they don't even need to know about you or you having a wallet
196 2014-08-13 14:33:17 <helo> and unnecessary, luckily
197 2014-08-13 14:33:42 <sipa> bsm1175321: compare that with a password, which can only be attacked by anyone who has access to the encrypted secret
198 2014-08-13 14:34:00 <jgarzik> in fairness, bsm1175321 did say " I'm talking about memorizing a programatically-generated phrase"
199 2014-08-13 14:34:03 <jgarzik> which is a BIP
200 2014-08-13 14:34:12 <jgarzik> human-generated phrase is not
201 2014-08-13 14:34:26 <sipa> oh, i'm not even talking about human generated phrases
202 2014-08-13 14:34:33 <bsm1175321> I'm talking about memorizing a 12-word phrase or so for which I can calculate the entropy.  Then training users to do that...
203 2014-08-13 14:35:45 <sipa> but fair enough, if you set the entropy high enough, you can calculate the duifficulty of even such an unlimited attack succeeding
204 2014-08-13 14:36:01 <sipa> but it does make the amount of entropy to remember higher
205 2014-08-13 14:36:17 <jgarzik> is it... BIP 38 with the canonical word list?
206 2014-08-13 14:36:19 <bsm1175321> sipa: I don't see any other reasonable way to secure a wallet, of any description, than forcing users to memorize the relevant number of bits.
207 2014-08-13 14:36:20 <jgarzik> 
ACTION tries to remember

208 2014-08-13 14:36:33 <jgarzik> https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki
209 2014-08-13 14:36:37 <bsm1175321> But I'd be interested in other proposals...
210 2014-08-13 14:37:45 <helo> you can't force remember... and if something bad happens to you, then it's gone forever
211 2014-08-13 14:37:45 <jgarzik> bsm1175321, there is an existing proposal that presumes a canonical English word list.  You request a random 256 bits, and the algorithm returns a sequence of words from that Well Known List.
212 2014-08-13 14:37:52 <sipa> jgarzik: bip 39
213 2014-08-13 14:38:27 <jgarzik> Ah yes.  Thanks sipa.  https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki  "Mnemonic code for generating deterministic keys"
214 2014-08-13 14:38:27 <sipa> bsm1175321: "the relevant number of bits" depends on whether you still have an external secret that not everyone has access to
215 2014-08-13 14:38:32 <jgarzik> bsm1175321, ^
216 2014-08-13 14:39:31 <bsm1175321> So you keep a long password on your phone/usb key, encrypted with a poor one.  I know how to attack that...
217 2014-08-13 14:39:41 <sipa> not a "poor one"
218 2014-08-13 14:39:42 <helo> and you hide the usb key
219 2014-08-13 14:39:50 <sipa> just a less strong one
220 2014-08-13 14:40:15 <helo> someone has to find it, brute force it likely forever, not even knowing what the payoff is
221 2014-08-13 14:40:15 <sipa> like if the device only allows 3 attempts per second, you've rate limited any attacker
222 2014-08-13 14:41:34 <helo> what kind of device can deny an attacker access to the actual encrypted data for an "offline" attack?
223 2014-08-13 14:42:17 <sipa> something that auto destructs when you try to tamper with it?
224 2014-08-13 14:42:37 <sipa> but yes, sure, there are always scenarios in which particular attackers can do more
225 2014-08-13 14:42:44 <helo> i think i'm all out of those :/
226 2014-08-13 14:43:13 <helo> anyways, it's reasonable to just remember one 12-word passphrase for your local encrypted backups
227 2014-08-13 14:43:29 <jgarzik> It's the normal security scenario.  You can never prevent an attack.  You just use various methods to increase cost ($$, time, ...), decrease chance of success.
228 2014-08-13 14:43:55 <sipa> even remembering a 256-bit entropy key by heart is vulnerable to a $4 wrench attack
229 2014-08-13 14:44:01 <jgarzik> A ridiculously well funded attack can probably find a way.
230 2014-08-13 14:44:20 <jgarzik> sipa, perhaps even encourages it
231 2014-08-13 14:44:28 <sipa> spreading out the requirements an attacker needs helps
232 2014-08-13 14:44:40 <sipa> (access to the secret in some storage form + your passphrase)
233 2014-08-13 14:48:29 <cfields> BlueMatt: great work!
234 2014-08-13 14:49:20 <cfields> i saw that PR and was ready to start feuding. Looks like I'll have to put my pitchforks away
235 2014-08-13 18:54:51 <dgenr8> Luke-Jr: today if a wallet had an "add to fees" function, that generates a child tx, how well would it work?  IOW how much effect will #1647 actually have?
236 2014-08-13 19:00:40 <dgenr8> actually i'm asking anyone who knows