1 2012-06-08 01:53:16 <amtran> I don't think that broken cryptography could ever be the end of BitCoin if it becomes popular. Since the block chain can be forked without losing too much data, modifications to all aspects of BitCoin are possible. If SHA-256 was broken, a new version of BitCoin would be released that would switch to a stronger hash function for addresses. I don't think that broken cryptography could ever be the end of BitCoin if it becomes p
  2 2012-06-08 01:53:17 <amtran> 6 blocks after a certain point in time, but most old transactions would survive.Changing the hash function used for blocks might not be necessary if the weakness still required some non-trivial amount of computation. The new version would ignore SHA-256 blocks after a certain point in time, but most old transactions would survive.
  3 2012-06-08 01:53:26 <amtran> -theymos
  4 2012-06-08 02:00:54 <amtran> So lets say I can create SHA-256 collisions fairly easily, and I want to replace an old transaction somewhere in the block chain.
  5 2012-06-08 02:01:05 <amtran> I create an alternate version of the transaction with the same hash... and then?  Whenever clients happen to connect to my node to get old transactions I feed them the bogus version?
  6 2012-06-08 02:01:16 <amtran> How do I get a majority of the network to accept the bogus version as valid, when the majority of the network probably already has already downloaded the old, valid version?
  7 2012-06-08 02:01:20 <amtran> -gavin
  8 2012-06-08 02:24:05 <amtran> ...disk blocks are stored in a B+tree indexed by file position,
  9 2012-06-08 07:30:27 <chmod755> hi nanotube
 10 2012-06-08 11:07:35 <Diapolo> Comments? http://i48.tinypic.com/2iw3yfb.jpg
 11 2012-06-08 11:08:16 <sipa> Diapolo: looks good; something like that will be needed
 12 2012-06-08 11:09:00 <Diapolo> The code and UI is there I just need to create a pull.
 13 2012-06-08 11:09:20 <Diapolo> It's tabbed as you see and much easier to expand, because it has an UI-file.
 14 2012-06-08 11:10:26 <Diapolo> sipa: If I push it to my remote repo can you try if it compiles and take a quick look at the code, before I open a pull?
 15 2012-06-08 11:11:12 <diki> Any new stuff going on?
 16 2012-06-08 11:11:45 <diki> New stolen coins or stuff like that?
 17 2012-06-08 11:13:33 <sipa> Diapolo: to be honest, i'd wait a little bit
 18 2012-06-08 11:13:57 <sipa> Diapolo: i hope to get the onion routing stuff merged as well
 19 2012-06-08 11:15:06 <Diapolo> sipa: as I said it will be real easy to extend the available options and if you tell me what you need I have no problem in assisting you
 20 2012-06-08 11:15:14 <sipa> Diapolo: when that is done, i think we need something in the gui like "[X] proxy server: [...]" "IPv6 proxy: [X] Same [ ] None [ ] Other server: [...]" "Tor proxy: [X] Same [ ] Other server [...]"
 21 2012-06-08 11:17:06 <sipa> but sure, i'll have a look if you want
 22 2012-06-08 11:23:27 <Diapolo> sipa: take a look here, perhaps you can try to build it, so that I can fix possible compilation errors before opening a pull
 23 2012-06-08 11:24:18 <Diapolo> sipa: I extended the optionsmodel with the SOCKS version I guess that's the main part where you can look for glitches
 24 2012-06-08 11:24:22 <Diapolo> https://github.com/Diapolo/bitcoin/tree/tabbed_optionsdialog
 25 2012-06-08 11:46:45 <Diapolo> re
 26 2012-06-08 11:55:40 <bulletbill> hello,  if i want to build a 'production-ready' bitcoin client, should i go off the 0.6.2 branch or the 0.6.2 tag in master? what is the procedure for maintaining the current stable version? is the latest stable version going to be branched now? (has it always been..i don't think so)
 27 2012-06-08 11:56:06 <sipa> 0.6.2 is 0.6.2
 28 2012-06-08 11:57:04 <bulletbill> sipa: however, 0.6.2 branch has further commits...i guess i worded it badly: to follow the latest 'stable' version, should i track the branch?
 29 2012-06-08 12:00:16 <Diapolo> sipa: I'm out for now, if you have got the time and have things, comment directly in my branch, ok :)? Thanks!
 30 2012-06-08 12:57:09 <Ukto> luke-jr is it possible for an LP response from a pool to respond, but without data, so the miner would immediately process a normal getwork ?
 31 2012-06-08 12:57:46 <luke-jr> possible, but bad idea
 32 2012-06-08 12:58:42 <Ukto> LP (at lease gminers implementation) breaks things a bit if a miner has diff threads passing through the same proxy but getting work from diff pools
 33 2012-06-08 13:05:28 <epscy> i was thinking about the variance problem
 34 2012-06-08 13:06:17 <epscy> as well as accepting a hash equal to the difficulty
 35 2012-06-08 13:06:57 <epscy> could it not also accept two hashes each equal to half the difficult
 36 2012-06-08 13:07:03 <epscy> y
 37 2012-06-08 13:10:31 <sipa> what problem would that solve?
 38 2012-06-08 13:14:42 <helo> 'variance problem' is that some blocks can take a lot longer than others?
 39 2012-06-08 13:16:56 <epscy> yeah
 40 2012-06-08 13:17:51 <epscy> basically if we let it accept two hashes that take an average of 5 minutes each to calc as well as one that takes an average of 10 mins
 41 2012-06-08 13:18:20 <epscy> that should give us more chances of solving a block every 10 mins
 42 2012-06-08 13:18:26 <epscy> i think
 43 2012-06-08 13:19:25 <epscy> and of course we could take it further, 4 hashes each taking 2 minutes and 30 seconds on average to caulculate, and so on
 44 2012-06-08 13:19:48 <epscy> is it a dumb idea?
 45 2012-06-08 13:21:16 <sipa> you'd just move the problem, i think
 46 2012-06-08 13:21:28 <epscy> how?
 47 2012-06-08 13:21:42 <sipa> pools will want to let miners announce their half-blocks
 48 2012-06-08 13:27:07 <epscy> why?
 49 2012-06-08 13:27:18 <epscy> i don't see what the difference would be
 50 2012-06-08 13:27:42 <epscy> the protocol would say that you need 0..n hashes that add up to the current difficulty
 51 2012-06-08 13:27:50 <epscy> sorry 1..n
 52 2012-06-08 13:28:28 <epscy> the pools and lone miners would hold on to hashes that are greater than half the difficulty
 53 2012-06-08 13:28:56 <epscy> but why would they announce them?
 54 2012-06-08 13:29:09 <epscy> until they actually have enough hashes?
 55 2012-06-08 13:31:37 <sipa> waiting for one miner to find two good hashes takes longer than waiting for one miner to find one hash, broadcasting it, and waiting for another miner to find the second
 56 2012-06-08 13:32:43 <epscy> sipa: why?
 57 2012-06-08 13:32:55 <epscy> you are talking about a pool?
 58 2012-06-08 13:32:59 <sipa> yes
 59 2012-06-08 13:33:18 <epscy> don't miners have to send all their hashes to the pool anyway?
 60 2012-06-08 13:33:23 <sipa> well, or a solo miner with many mining nodes
 61 2012-06-08 13:33:48 <epscy> the only downsides i can see, is that the block would larger
 62 2012-06-08 13:34:07 <sipa> i don't even see what problem it solves
 63 2012-06-08 13:34:09 <helo> right now the average is every 10 minutes... if you start accepting more ways to solve a block, the average will be less than every 10 minutes
 64 2012-06-08 13:34:23 <helo> i think we want the average to stay every 10
 65 2012-06-08 13:34:29 <epscy> and the bitcoin node (either in a pool or solo) would need to remember some hashes
 66 2012-06-08 13:34:31 <sipa> yes, there is variance, and yes your idea would decrease variance
 67 2012-06-08 13:35:00 <sipa> but there are ways to do this that do not make the core bitcoin system more complicated
 68 2012-06-08 13:35:09 <epscy> helo: huh, two 5 minute hashes should take 10 minutes on average as well
 69 2012-06-08 13:35:19 <epscy> sipa: fair enough
 70 2012-06-08 13:35:27 <helo> oh, you mean isntead of accepting 10 minute hash, accept 2 5-minute hashes
 71 2012-06-08 13:35:30 <epscy> this doesn't actually seem that complicated to me though
 72 2012-06-08 13:35:34 <helo> not in addition to
 73 2012-06-08 13:35:40 <sipa> well, it would require a hard fork
 74 2012-06-08 13:35:49 <epscy> sipa: oh yes obviously
 75 2012-06-08 13:35:54 <sipa> which may one day indeed be necessary
 76 2012-06-08 13:36:10 <epscy> i was just asking to see if anyone could see a technical flaw in the idea
 77 2012-06-08 13:36:16 <sipa> but it would also require an extraordinary degree of consensus on any changes included
 78 2012-06-08 13:36:36 <helo> how do the two submitters of the hashes agree on the transactions that are included in the block?
 79 2012-06-08 13:36:38 <epscy> sipa: i am not suggesting we put this into the bitcoin client today
 80 2012-06-08 13:36:43 <sipa> sure
 81 2012-06-08 13:36:52 <sipa> it's interesting to think about
 82 2012-06-08 13:36:56 <epscy> helo: two submitters?
 83 2012-06-08 13:37:03 <epscy> the pool gives the work
 84 2012-06-08 13:37:11 <epscy> they should be hashing the same thing
 85 2012-06-08 13:37:17 <helo> oh, missed that part too... so you accept two 5-min hashes from the same person
 86 2012-06-08 13:37:24 <epscy> yeah
 87 2012-06-08 13:37:53 <sipa> it would increase transaction confirmation time by a few minutes on average
 88 2012-06-08 13:38:12 <epscy> why?
 89 2012-06-08 13:38:15 <sipa> as miners cannot simply switch to new work without discarding earlier found hashes
 90 2012-06-08 13:38:47 <epscy> i don't see why that is so, when new work is issued you discard hashes for the old work
 91 2012-06-08 13:39:00 <epscy> i think that's how it works now
 92 2012-06-08 13:39:00 <sipa> that would be stupid!
 93 2012-06-08 13:39:08 <epscy> why?
 94 2012-06-08 13:39:27 <sipa> miners will not start working on new work when there is a hash for old work found already
 95 2012-06-08 13:39:37 <epscy> errm, why not?
 96 2012-06-08 13:39:37 <sipa> on a new block, sure
 97 2012-06-08 13:39:48 <epscy> the old hash becomes useless...
 98 2012-06-08 13:39:59 <sipa> no it does not
 99 2012-06-08 13:40:17 <sipa> i'm just talking about new transactions added to the mempool
100 2012-06-08 13:40:22 <epscy> hmmm i thought new work was issued for new blocks only
101 2012-06-08 13:40:38 <sipa> no new work is generated anytime a miner asks for it
102 2012-06-08 13:41:00 <sipa> anyone with 4GH/s needs one getwork per second
103 2012-06-08 13:41:02 <epscy> sipa: right but when do transactions get added to the potential block?
104 2012-06-08 13:41:16 <sipa> when new work is requested by a miner
105 2012-06-08 13:41:24 <epscy> aah
106 2012-06-08 13:41:47 <epscy> i thought the miners froze the potential block when a new round starts
107 2012-06-08 13:41:56 <sipa> not at all
108 2012-06-08 13:42:05 <epscy> of course miners can pick and choose which transactions they include
109 2012-06-08 13:42:15 <epscy> so this could still work
110 2012-06-08 13:42:22 <epscy> but yeah
111 2012-06-08 13:42:31 <epscy> it would increase confirmation time
112 2012-06-08 13:42:41 <epscy> hmmm
113 2012-06-08 13:42:42 <epscy> thanks
114 2012-06-08 13:43:05 <sipa> also, it incentivizes larger pools
115 2012-06-08 13:43:22 <sipa> i think
116 2012-06-08 13:46:48 <epscy> well i think it should be neutral in the regard
117 2012-06-08 13:47:14 <epscy> or at least it shouldn't give pools more of an advantage than they do at the moment
118 2012-06-08 13:51:24 <luke-jr> epscy: did you see my anti-blockwithholding algo?
119 2012-06-08 13:51:43 <epscy> luke-jr: nope
120 2012-06-08 13:52:34 <luke-jr> it's aimed at a different problem, but maybe would have your idea as a side effect?
121 2012-06-08 13:52:46 <epscy> what is it all about?
122 2012-06-08 13:52:50 <luke-jr> http://sourceforge.net/mailarchive/message.php?msg_id=29353920
123 2012-06-08 13:53:36 <jgarzik> so
124 2012-06-08 13:53:40 <jgarzik> what have I missed?
125 2012-06-08 13:53:55 <jgarzik> we chose to hardfork and added a ton of new, incompatible features yes?
126 2012-06-08 13:53:58 <luke-jr> jgarzik: not much, I think
127 2012-06-08 13:54:02 <epscy> jgarzik: me and luke-jr are going to create a new alt coin
128 2012-06-08 13:54:05 <luke-jr> hah
129 2012-06-08 13:54:13 <sipa> jgarzik: satoshi returned, sold 1M btc on mtgox
130 2012-06-08 13:54:14 <jgarzik> tonalcoin
131 2012-06-08 13:54:54 <sipa> oh, and we dropped IPv4 support
132 2012-06-08 13:54:58 <luke-jr> ^ win
133 2012-06-08 13:55:13 <luke-jr> can we drop Windows support now?
134 2012-06-08 13:55:44 <jgarzik> let's drop windows and linux support
135 2012-06-08 13:55:50 <jgarzik> OSX is the only relevant OS these days
136 2012-06-08 13:56:00 <luke-jr> &
137 2012-06-08 13:56:00 <sipa> and OS/2!
138 2012-06-08 13:56:03 <epscy> i'm too poor to afford a mac
139 2012-06-08 13:56:10 <amtran> lets go full pen/paper
140 2012-06-08 13:56:24 <jgarzik> go go HPFS
141 2012-06-08 13:56:30 <amtran> how fast can you do sha256 with an abacus
142 2012-06-08 13:56:33 <epscy> this is bitcoins future, a niche for rich people with more money than sense
143 2012-06-08 13:57:02 <jgarzik> more seriously, sounds like 'sendrawtx' has a bug...  it adds the new tx to relay inventory, but does not force immediate broadcast.  sounds like it should force immediate broadcast too.
144 2012-06-08 13:57:16 <luke-jr> wizkidO57: ^
145 2012-06-08 13:57:55 <sipa> jgarzik: indeed
146 2012-06-08 13:58:03 <amtran> GetNextWorkRequired has a bug too. it really sucks.
147 2012-06-08 13:58:32 <sipa> furthermore, gavin (who is in vienna right now) is working on a more lowlevel rpc interface for transactions
148 2012-06-08 13:58:44 <sipa> maybe sendrawtx should be adapted a bit
149 2012-06-08 13:59:13 <sipa> amtran: no it has no bug; it has odd semantics, but that is something we can't just change
150 2012-06-08 13:59:16 <[Tycho]> sendrawtx... Cool :)
151 2012-06-08 13:59:48 <luke-jr> jgarzik: did you miss the new x32 ABI?
152 2012-06-08 14:00:00 <sipa> ?
153 2012-06-08 14:00:01 <amtran> no really why is the difficulty retargeted once every 2016 blocks
154 2012-06-08 14:00:07 <amtran> why not retarget continuously
155 2012-06-08 14:00:13 <sipa> amtran: because that is what satoshi chose
156 2012-06-08 14:00:25 <sipa> it was easy to implement i guess
157 2012-06-08 14:00:37 <sipa> i wouldn't do it that way if i redesigned it
158 2012-06-08 14:00:41 <[Tycho]> amtran: otherwise it will be heavily affected by randomness
159 2012-06-08 14:00:57 <amtran> its heavily affected by randomness as it is
160 2012-06-08 14:01:06 <[Tycho]> Or you were talking about moving window ?
161 2012-06-08 14:01:08 <amtran> from what i can see it only uses 2 values
162 2012-06-08 14:01:14 <sipa> nah, you have to be careful, but there are certainly much better retargeting algorithms than the one implwmented
163 2012-06-08 14:01:15 <luke-jr> &
164 2012-06-08 14:01:26 <amtran> time value of current block and the time value of the block 2016 blocks ago
165 2012-06-08 14:02:00 <sipa> well, the actual new difficulty is just based on the average hash rate the past 2016 blocks
166 2012-06-08 14:02:17 <amtran> yes but this is a stupid way to calculate a rate
167 2012-06-08 14:02:17 <luke-jr> oh right
168 2012-06-08 14:02:28 <sipa> unless it is more than 4x or less than 1/4x the previous difficulty
169 2012-06-08 14:02:35 <luke-jr> amtran is the guy who was suggesting we use non-cryptographic hashes for block hashing algorithm, and use DHT
170 2012-06-08 14:02:57 <sipa> yes it is far from perfect as a retargeting
171 2012-06-08 14:03:07 <sipa> but it is stable and simple to implement
172 2012-06-08 14:03:13 <amtran> a better way to calculate a rate is a type 3 or 4 FIR filter
173 2012-06-08 14:03:19 <sipa> and we cannot change it
174 2012-06-08 14:04:09 <amtran> the problem with bitcoin and control theory is that the values of time between block completion are not discrete
175 2012-06-08 14:04:34 <sipa> who are you trying to convince?
176 2012-06-08 14:04:43 <amtran> nobody
177 2012-06-08 14:04:59 <sipa> yes, i agree with you
178 2012-06-08 14:05:07 <luke-jr> sipa: you know, the trolls who would complain at a hardfork (the ones without good reasoning), would probably get behind it if it was me forking the project to continue the current blockchain as-is ;)
179 2012-06-08 14:05:23 <amtran> i just recently started taking a hard look at bitcoin and reading old posts on the forum
180 2012-06-08 14:06:05 <amtran> im just trying to understand the software and strip it down to the bare essentials sorry ill shut up
181 2012-06-08 14:06:41 <amtran> like a lot of people seem to worry about sha-256 being broken but i dont think thats a big deal
182 2012-06-08 14:06:55 <jgarzik> sipa: oh?  what are the goals for the lowlevel rpc tx interface?
183 2012-06-08 14:06:57 <amtran> trying to figure out what actually matters
184 2012-06-08 14:07:10 <jgarzik> sipa: I'm happy to change sendrawtx as needed.  I see gavin already changed the return value
185 2012-06-08 14:07:34 <jgarzik> I am also curious about opinions on filter{clear,add} RPCs
186 2012-06-08 14:07:40 <jgarzik> or a better method of filtering
187 2012-06-08 14:08:00 <jgarzik> sendraw + filter seem to fit the needs of a large enterprise site that manages its own keys
188 2012-06-08 14:08:11 <luke-jr> jgarzik: how about longpolling filters?
189 2012-06-08 14:08:35 <luke-jr> (so it can be network-friendly)
190 2012-06-08 14:09:12 <amtran> i cnat find any open resources on the web to display what im talking about
191 2012-06-08 14:09:19 <amtran> you'd need to find a signals and system text
192 2012-06-08 14:09:25 <amtran> heres a paper,,, http://eeweb.poly.edu/iselesni/lowdiff/lowdiff.pdf
193 2012-06-08 14:09:26 <gribble> Error: "," is not a valid command.
194 2012-06-08 14:09:35 <amtran> but its too complicated
195 2012-06-08 14:11:21 <sipa> jgarzik: https://gist.github.com/2839617
196 2012-06-08 14:12:29 <amtran> i think you could achieve better results in 1/10 of the blocks delay if you put an actual filter
197 2012-06-08 14:13:02 <epscy> amtran: a moving window would decrease variance?
198 2012-06-08 14:13:11 <amtran> no moving window
199 2012-06-08 14:13:40 <sipa> amtran: i think one easy improvement would be doing looing at the past 2016-blocks-window at every block, and multiply difficulty by the 2016th root of the time factor
200 2012-06-08 14:13:47 <amtran> look up an fir filter
201 2012-06-08 14:14:41 <epscy> i like the idea of a moving window
202 2012-06-08 14:14:41 <sipa> well if you have 2016-inputs FIR with contant weights, you have in practice a moving window
203 2012-06-08 14:15:34 <amtran> i dont know what you mean when you say moving window
204 2012-06-08 14:15:53 <amtran> the number of taps to the filter would not change
205 2012-06-08 14:15:59 <amtran> the coefficients would nto change
206 2012-06-08 14:16:18 <amtran> http://en.wikipedia.org/wiki/Finite_difference
207 2012-06-08 14:16:30 <amtran> See section "higher order differences"
208 2012-06-08 14:16:46 <amtran> but imagine this for order=128
209 2012-06-08 14:16:51 <amtran> or some similar high value
210 2012-06-08 14:17:14 <jgarzik> sipa: looks good
211 2012-06-08 14:17:58 <amtran> wait i said that wrong
212 2012-06-08 14:18:59 <amtran> wrong wikipedia page in my notes
213 2012-06-08 14:19:02 <amtran> http://en.wikipedia.org/wiki/Finite_difference_coefficients
214 2012-06-08 14:36:28 <SteveBell> hi all. should URI links be working on mac platform?
215 2012-06-08 14:36:40 <SteveBell> I see some closed but also several open tickets in that regard. not sure how platforms matter in that regard
216 2012-06-08 14:36:55 <sipa> i don't think they are currently functional
217 2012-06-08 14:38:09 <SteveBell> hey sipa. ok, that'd be my experience. I think this is very important. it would easen up the process for new users a lot
218 2012-06-08 14:38:18 <SteveBell> and streamline bitcoin payment.
219 2012-06-08 14:39:55 <SteveBell> do you have URI on your radar or is it way down the priority list?
220 2012-06-08 14:40:38 <sipa> i hope it'll be fixed before 0.7
221 2012-06-08 14:43:50 <SteveBell> that's good news. thx for your work and hope to see this live soon. let it bring further adoption of bitcoin
222 2012-06-08 14:43:56 <SteveBell> enjoy your day :)
223 2012-06-08 14:43:59 <SteveBell> ^/
224 2012-06-08 14:47:25 <luke-jr> sipa: lol at your non-answer :P
225 2012-06-08 14:47:41 <luke-jr> (btw, Mac support isn't broken, it just isn't implemented at all ;)
226 2012-06-08 14:48:26 <gribble> New news from bitcoinrss: luke-jr opened pull request 1431 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1431>
227 2012-06-08 16:07:42 <gribble> New news from bitcoinrss: Dr-Nix opened issue 1432 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1432>
228 2012-06-08 16:35:13 <[Tycho]> Can anyone remember when default fee was changed to 0.0005 ?
229 2012-06-08 16:41:34 <freewil> [Tycho], 0.3.23 i think
230 2012-06-08 16:41:41 <freewil> https://en.bitcoin.it/wiki/Transaction_Fee
231 2012-06-08 16:46:48 <[Tycho]> Thanks.
232 2012-06-08 19:02:43 <sipa> hmm, i just rebased ipparse against upstream/master
233 2012-06-08 19:02:53 <sipa> but github says it cannot be merged automatically
234 2012-06-08 19:40:24 <BlueMatt> sipa: no, I dont think uri for osx is on the roadmap for anyone, windows is another story, and I hope win32 is fixed for 0.7
235 2012-06-08 19:41:48 <BlueMatt> speaking of which...I should go do that
236 2012-06-08 19:42:53 <diki> 0.7 eh?
237 2012-06-08 19:44:12 <Diablo-D3> lol
238 2012-06-08 20:02:04 <luke-jr> BlueMatt: is your prune branch sane enough to put in next-test?
239 2012-06-08 20:02:28 <BlueMatt> luke-jr: afaik, sure
240 2012-06-08 20:02:40 <luke-jr> then again, it permanently affects the user's data& ?
241 2012-06-08 20:02:58 <BlueMatt> blkindex.dat, yea...but it only prunes up to checkpoints
242 2012-06-08 20:05:08 <luke-jr> so can't hurt anything?
243 2012-06-08 20:05:19 <BlueMatt> in theory, yea
244 2012-06-08 20:05:27 <sipa> it should be safe enough to put in an experimental branch
245 2012-06-08 20:05:29 <BlueMatt> if I wrote it wrong, sure
246 2012-06-08 22:18:00 <bennysx> hi
247 2012-06-08 22:18:10 <bennysx> i need help for my bussiness
248 2012-06-08 22:18:24 <bennysx> i want to sell my ebaooks via bitcoin
249 2012-06-08 22:18:30 <bennysx> ebooks*
250 2012-06-08 22:19:01 <bennysx> but im just too lazy to keep creating addresses for each costumer
251 2012-06-08 22:19:16 <bennysx> is there a easier way to do this?
252 2012-06-08 22:20:23 <MagicalTux> bennysx: you can use some of the existing checkout solutions
253 2012-06-08 22:21:25 <bennysx> im selling my ebook at a forum, people PM me asking for the address,
254 2012-06-08 22:21:37 <bennysx> i know there is processing solutions
255 2012-06-08 22:21:49 <luke-jr> bennysx: http://coindl.com
256 2012-06-08 22:22:32 <bennysx> i know but i got more traffic on that forum that im selling
257 2012-06-08 22:22:41 <luke-jr> so link to coindl
258 2012-06-08 22:30:33 <weex> bennysx: i run coindl, let me know if you need any help
259 2012-06-08 22:49:36 <amtran> https://bitcointalk.org/index.php?topic=86400.0
260 2012-06-08 22:55:54 <MagicalTux> amtran: what's your goal ?
261 2012-06-08 22:56:30 <MagicalTux> I see that could work with HOTP, but not TOTP nor yubikey
262 2012-06-08 22:56:42 <amtran> iit is hotp
263 2012-06-08 22:56:46 <amtran> yubikey has hotp
264 2012-06-08 22:57:07 <MagicalTux> problem is if by accident you use your OTP generator and go over the bound of pre-generated values
265 2012-06-08 22:57:29 <MagicalTux> plus, I'm not sure about the concatenate part
266 2012-06-08 22:57:39 <MagicalTux> you need many otp input to decode ?
267 2012-06-08 22:57:41 <amtran> this is all implemented in the plugin i attribute it to
268 2012-06-08 22:57:47 <amtran> i use it every day
269 2012-06-08 22:57:52 <amtran> for password storage
270 2012-06-08 22:58:29 <MagicalTux> you'll need to store the OTP secret together with the bitcoin wallet
271 2012-06-08 22:58:31 <amtran> dominik has implemented a look ahead window for accidental generation
272 2012-06-08 22:58:37 <MagicalTux> or you won't be able to re-encrypt it with the new HOTP key
273 2012-06-08 22:58:41 <amtran> yes i agree
274 2012-06-08 22:58:53 <phantomcircuit> HOTP is only useful if replacement of the token isn't costly and time consuming
275 2012-06-08 22:59:12 <amtran> but you seee this is better than typing the same password (Against keyloggers)
276 2012-06-08 22:59:34 <phantomcircuit> if there is a keylogger you're already fucked
277 2012-06-08 22:59:44 <MagicalTux> amtran: true, however to produce enough protection you need to input a lot of characters
278 2012-06-08 22:59:55 <MagicalTux> standard HOTP is good because you cannot do fast bruteforce over network
279 2012-06-08 23:00:05 <phantomcircuit> the only protection against a compromised terminal is challenge response tokens where the challenge incorporates transaction details in a simple to verify manner
280 2012-06-08 23:00:07 <MagicalTux> however if it's a locally encrypted file, you need more input
281 2012-06-08 23:00:13 <amtran> thats why you use multiple HOTP and hash it
282 2012-06-08 23:00:35 <amtran> so the problem is protecting your memory when the wallet+secret are decrypted
283 2012-06-08 23:00:35 <MagicalTux> amtran: inputting multiple HOTP makes this whole thing less practical
284 2012-06-08 23:01:22 <phantomcircuit> amtran, if the computer is compromised the only protection is to sign the bitcoin transaction on the hardware token itself
285 2012-06-08 23:01:46 <phantomcircuit> these bitcoin card people seem to have the right idea
286 2012-06-08 23:01:52 <phantomcircuit> although i haven't looked into it much
287 2012-06-08 23:02:01 <amtran> phantomcircuit: my intention is to be "good enough" if you understand
288 2012-06-08 23:02:33 <amtran> id imagine most bitcoin wallets are compromised through keyloggers
289 2012-06-08 23:02:43 <amtran> or similar crude methods
290 2012-06-08 23:03:32 <MagicalTux> on our servers, we use the YubiHSM for an extra bit of security (if server is stolen or rebooted, private keys are not available)
291 2012-06-08 23:03:59 <phantomcircuit> amtran, actually no i would bet that most of them are compromised simply by copying the wallet.dat since most aren't encrypted
292 2012-06-08 23:04:12 <MagicalTux> for more mainstream protection you idea, amtran, is not bad, but the resulting hassle (inputting many HOTP) and risk (desync means lose it all) will probably not be seen as worth it
293 2012-06-08 23:04:13 <amtran> yeah that too
294 2012-06-08 23:04:20 <phantomcircuit> the vast majority of bitcoin malware either simply copies wallet.dat or replaces bitcoin addresses in the clipboard
295 2012-06-08 23:04:33 <amtran> i use it every day my girlfriend does too magicaltux
296 2012-06-08 23:04:36 <wizkid057> MagicalTux: what if I splice in power from a grid tie inverter and steal the server without ever cutting power?
297 2012-06-08 23:04:38 <wizkid057> :P
298 2012-06-08 23:04:41 <phantomcircuit> MagicalTux, yubiHSM doesn't support the right ecc sign mechanism though
299 2012-06-08 23:04:55 <phantomcircuit> so the private key still ends up in the hosts memory at somepoint
300 2012-06-08 23:05:10 <amtran> the solution to desync is writing your secret key on a piece of paper
301 2012-06-08 23:05:11 <MagicalTux> phantomcircuit: yep, but it's still better than keeping all the stuff required to decrypt these on disk
302 2012-06-08 23:05:30 <phantomcircuit> MagicalTux, i guess in practical terms that's probably a step up
303 2012-06-08 23:05:33 <amtran> and pressing a button a few times doesn't end up being a very big hassle
304 2012-06-08 23:05:43 <MagicalTux> as I said, it's not perfect security, it's slightly better
305 2012-06-08 23:05:44 <phantomcircuit> but realistically any compromise of the system instructing payments is effectively a total loss
306 2012-06-08 23:06:02 <phantomcircuit> which is something all the people talking about multisig seem to simply not understand
307 2012-06-08 23:07:32 <amtran> well that system would not be exposed to the internet, and it would be less vuln because it would run simpler services
308 2012-06-08 23:07:49 <amtran> than lets say your user auth server or accounting server
309 2012-06-08 23:08:30 <phantomcircuit> amtran, it really doesn't matter
310 2012-06-08 23:08:43 <phantomcircuit> auth/accounting/bitcoin transfer node
311 2012-06-08 23:08:47 <phantomcircuit> are all equally important
312 2012-06-08 23:09:02 <phantomcircuit> lose auth? attacker logs in as everybody game over
313 2012-06-08 23:09:11 <phantomcircuit> lose accounting? attacker gives himself infinity money
314 2012-06-08 23:09:19 <phantomcircuit> bitcoin transfer node is obvious :)
315 2012-06-08 23:10:05 <amtran> true i guess
316 2012-06-08 23:10:36 <phantomcircuit> and actually realistically a compromise of even the www server nodes is a significant breach
317 2012-06-08 23:10:45 <phantomcircuit> passwords in plaintext and session cookies
318 2012-06-08 23:10:52 <amtran> if i were running a commercial service i would also include a sig from the webserver to say  "i did this"
319 2012-06-08 23:12:40 <amtran> hm
320 2012-06-08 23:13:26 <phantomcircuit> amtran, essentially a creative attacker could leverage a compromise of just about any piece of infrastructure into a near total compromise
321 2012-06-08 23:13:36 <phantomcircuit> it's mostly dependent on how patient they are
322 2012-06-08 23:13:38 <dw> $25 raspberry pi + 100 line python script + google authenticator + network cable = secure wallet
323 2012-06-08 23:14:13 <dw> and i'd sooner trust that than a half baked smart card implementation
324 2012-06-08 23:14:21 <phantomcircuit> yup i agree
325 2012-06-08 23:15:03 <amtran> computer + code + periphrials = nasa mission control
326 2012-06-08 23:15:20 <dw> i have some basic cards here i wanted to play with, but they don't support hardware ecdsa
327 2012-06-08 23:16:33 <dw> hey actually there's a business opp in there for someone. all the raspberry pi needs is a physical switch to put it into "i lost my authenticator secrets" mode, and a $5 plastic case :)
328 2012-06-08 23:19:27 <MagicalTux> dw: we could do that, I guess
329 2012-06-08 23:19:42 <MagicalTux> actually we could dev a full bitcoin client using blockexplorer or us as blockchain provider
330 2012-06-08 23:19:43 <dw> i'll write the software bit if you'll give me 10% :P
331 2012-06-08 23:20:09 <dw> ooh, phantomcircuit / MagicalTux confusion
332 2012-06-08 23:20:09 <MagicalTux> and have the raspberry pi only expose a shell and/or web interface to use that bitcoin client
333 2012-06-08 23:20:16 <phantomcircuit> wat
334 2012-06-08 23:20:21 <phantomcircuit> dw, lol
335 2012-06-08 23:20:32 <phantomcircuit> MagicalTux, serial line
336 2012-06-08 23:20:37 <dw> MagicalTux: actually there are those arm usb sticks that have built in wifi on aliexpress.com, like 30 bucks
337 2012-06-08 23:20:37 <MagicalTux> dw: been replying to [10:13:38] <dw> $25 raspberry pi + 100 line python script + google authenticator + network cable = secure wallet
338 2012-06-08 23:20:37 <phantomcircuit> they're ornery as fuck
339 2012-06-08 23:21:00 <phantomcircuit> all the high security https certificate places have a serial connection to the signing box with crazy custom protocols
340 2012-06-08 23:21:14 <phantomcircuit> an attacker will almost certainly fuckup the protocol and trip the box
341 2012-06-08 23:21:15 <phantomcircuit> lol
342 2012-06-08 23:21:20 <phantomcircuit> security through complexity
343 2012-06-08 23:21:55 <MagicalTux> phantomcircuit: the CA I know do it manually, 12 times a day (every 2 hours)
344 2012-06-08 23:22:06 <dw> MagicalTux: there are various pci cards with network interface that have an on board processor, but they're a bit more expensive
345 2012-06-08 23:22:09 <MagicalTux> some guy copy the req to tape, go to the CA room, get the signatures on a new tape, etc
346 2012-06-08 23:22:18 <phantomcircuit> MagicalTux, verisign and startssl both use the serial line stuff
347 2012-06-08 23:22:24 <dw> appears to the pc as rtl8139, runs linux on a separate cpu/bus/ram/etc
348 2012-06-08 23:22:33 <luke-jr> dw: Google != trustworhty
349 2012-06-08 23:22:44 <dw> luke-jr: authenticator is open source IIRC
350 2012-06-08 23:22:49 <dw> its just an algorithm
351 2012-06-08 23:22:52 <MagicalTux> google auth is HOTP
352 2012-06-08 23:23:01 <amtran> hahah yeah i didnt want to say
353 2012-06-08 23:23:01 <luke-jr> dw: in any case, a secure wallet requires a dedicated display
354 2012-06-08 23:23:14 <phantomcircuit> and some buttons
355 2012-06-08 23:23:15 <MagicalTux> phantomcircuit: I was talking about a japanese one
356 2012-06-08 23:23:20 <luke-jr> phantomcircuit: yes
357 2012-06-08 23:23:22 <phantomcircuit> MagicalTux, that's hilarious :)
358 2012-06-08 23:24:26 <MagicalTux> in Japan, manpower is cheap
359 2012-06-08 23:27:14 <phantomcircuit> manpower is cheap everywhere
360 2012-06-08 23:27:21 <phantomcircuit> except at scale
361 2012-06-08 23:27:23 <phantomcircuit> then it's expensive
362 2012-06-08 23:29:49 <phantomcircuit> although
363 2012-06-08 23:29:54 <phantomcircuit> trustworthy manpower is expensive :)
364 2012-06-08 23:32:18 <MagicalTux> and/or just a dream
365 2012-06-08 23:33:43 <phantomcircuit> heh
366 2012-06-08 23:34:08 <phantomcircuit> im lucky there are some people around here i trust completely
367 2012-06-08 23:34:21 <phantomcircuit> now to make enough money that i can afford to hire someone
368 2012-06-08 23:34:22 <phantomcircuit> lol
369 2012-06-08 23:52:48 <dw> bitcoin is insanely ram hungry though isn't it