1 2014-05-13 00:11:27 <andytoshi> Jacques_: check out the wikipedia page on ElGamal encryption
2 2014-05-13 00:12:37 <andytoshi> that is bare-bones "encrypt against a diffie-hellman secret". it also has different security properties depending if your group is DDH-hard or just CDH-hard, which are easy to show (and good practice for working with these group properties)
3 2014-05-13 00:13:01 <andytoshi> and unlike ECDSA, that wiki page is readable
4 2014-05-13 00:15:17 <Jacques_> andytoshi: hmm, my point was more like, is there any risk of private key leakage if have two points Q=dG, Q'=(d+1)G = QG
5 2014-05-13 00:16:08 <Jacques_> Jacques_: I understand the implications of a DH
6 2014-05-13 00:16:34 <andytoshi> i'm not sure what you mean by QG. but no, exposing (d+1)G does not affect the security of dG. (given dG, anyone can compute dG + G, after all)
7 2014-05-13 00:18:06 <Jacques_> andytoshi: right, that much is clear, what wasn't clear was if I say used the same k value for both (a bad idea, but a curiosity anyway)
8 2014-05-13 00:18:16 <Jacques_> (in 2 signatures)
9 2014-05-13 00:18:59 <andytoshi> ah, if you sign two messages with same k, that'll expose your secret key. but that's a weakness put into ECDSA, it isn't related to DH at all
10 2014-05-13 00:19:33 <Jacques_> andytoshi: which is what I was aiming to talk about :)
11 2014-05-13 00:19:49 <Jacques_> (other than the use of DH in Stealth, not sure how that came up)
12 2014-05-13 00:19:50 <andytoshi> cool. but this is more appropriate in ##crypto or #bitcoin. (it's not ontopic in #bitcoin but i like having crypto discussions in there because it encourages people to think of cryptography less magically)
13 2014-05-13 00:19:53 <andytoshi> i'm in both channels
14 2014-05-13 00:20:18 <Jacques_> sure, i'll move it there
15 2014-05-13 00:58:59 <super_bit_A> hello, I need some help installing an insight server on testnet. anyone know how?
16 2014-05-13 00:59:45 <Luke-Jr> super_bit_A: maybe try #bitcore
17 2014-05-13 01:00:19 <super_bit_A> trying...
18 2014-05-13 01:00:21 <super_bit_A> 10x
19 2014-05-13 01:05:11 <super_bit_A> another try
20 2014-05-13 01:05:14 <super_bit_A> hello, I need some help installing an insight server on testnet. anyone know how?
21 2014-05-13 01:05:36 <survic> this really isn't the right channel for that. ask on #bitcoin and I'll see if I can help you out.
22 2014-05-13 01:55:54 <warren> what was the first version of bitcoin that switched from wx to qt?
23 2014-05-13 01:56:46 <andytoshi> iirc 0.7 was the first version i could run, and i was never able to get wx installed
24 2014-05-13 01:57:52 <warren> thanks
25 2014-05-13 02:02:50 <Luke-Jr> warren: 0.5
26 2014-05-13 02:14:25 <[\\\]> bitcoin.sipa.be seems broken
27 2014-05-13 02:14:31 <[\\\]> its about a day behind
28 2014-05-13 02:39:02 <warren> btw, I can't remember, were there any objections to changing regtest address versions?
29 2014-05-13 03:44:38 <warren> oh shit, I remember
30 2014-05-13 03:44:43 <warren> pull tester uses regtest
31 2014-05-13 03:45:24 <gmaxwell> thats what regtest is for.
32 2014-05-13 03:59:33 <warren> I'll have to figure out how to redo the tests with different versions then.
33 2014-05-13 04:07:03 <Luke-Jr> ACTION still doesn't get why pulltester (aka regtest) should use a different version
34 2014-05-13 04:08:00 <Luke-Jr> is there a reason GCC doesn't have a -frandom-seed=HASH-OF-PREPROCESSED?
35 2014-05-13 04:20:07 <sabfer> Hi, I'm having trouble getting Bitcoin Core to compile on OS X 10.9. I keep getting this error: http://pastebin.com/hgTSSX6d
36 2014-05-13 04:20:52 <sabfer> any help would be greatly appreciated!
37 2014-05-13 04:25:07 <gwillen> sabfer: some googling and reading of tea leaves suggests that's an error that results from failure to #include <string>; I conjecture that perhaps it works on some systems / with some compilers, and just happens not to work with yours without that include
38 2014-05-13 04:25:23 <gwillen> sabfer: (meaning I'm conjecturing it's an actual bug)
39 2014-05-13 04:25:49 <gwillen> sabfer: if you're comfortable with it, try adding #include <string> to the top of the file with the error
40 2014-05-13 04:26:19 <gwillen> sabfer: here is an example of the same issue I found in an unrelated package: http://savannah.nongnu.org/bugs/?39543
41 2014-05-13 04:26:21 <sabfer> gwillen: done! compiling again to see if it works
42 2014-05-13 04:26:25 <gwillen> kk!
43 2014-05-13 04:27:19 <gwillen> oh, in fact I can think of a good reason you might run into this on 10.9 when other people don't it it -- they replaced gcc with a symlink to clang starting in 10.9 or thereabouts
44 2014-05-13 04:27:22 <gwillen> don't hit it*
45 2014-05-13 04:29:17 <sabfer> gwillen: it compiled fine with the additional include.
46 2014-05-13 04:29:34 <gwillen> Awesome. Want to file a bug against bitcoin/bitcoin on github?
47 2014-05-13 04:29:45 <gwillen> Include exact OS and compiler version, and exactly what fixed it.
48 2014-05-13 04:29:55 <sabfer> gwillen: right! the gcc symlink threw me off the wrong path too initially
49 2014-05-13 04:30:01 <gwillen> ACTION nods
50 2014-05-13 04:30:54 <sabfer> gwillen: thanks for the help
51 2014-05-13 04:31:05 <gwillen> sabfer: no problem! Thanks for spotting and reporting the bug. :-)
52 2014-05-13 04:31:35 <gwillen> please do officially file it, since this probably means bitcoin-core doesn't build for anybody on 10.9
53 2014-05-13 04:31:38 <gwillen> and you're just the first to notice
54 2014-05-13 04:33:40 <sabfer> gwillen: i'll do it as soon as possible
55 2014-05-13 04:34:10 <gwillen> sabfer: awesome, thanks. Or if you can't do it immediately, paste your OS version and the output of gcc --version and I'll file it for you :-)
56 2014-05-13 04:43:35 <sabfer> gwillen: https://github.com/bitcoin/bitcoin/pull/4181
57 2014-05-13 04:43:49 <gwillen> Yay! Thanks sabfer! :-)
58 2014-05-13 04:44:37 <sabfer> gwillen: let me know if you need anything else
59 2014-05-13 04:45:24 <gwillen> sabfer: whoever looks at your pullreq will comment on it if they need anything. (I'm not actually a dev, just a hanger-on, which is why I didn't just do the fix myself.)
60 2014-05-13 04:47:59 <sabfer> gwillen: ok, thanks for your help again
61 2014-05-13 07:39:05 <warren> https://github.com/slickage/insight/tree/regtesthack If you want regtest insight I will maintain this hack branch until something better can go upstream.
62 2014-05-13 08:47:38 <warren> #define COPYRIGHT_STR "2009-" STRINGIZE(COPYRIGHT_YEAR) " The Bitcoin developers"
63 2014-05-13 08:47:46 <warren> is technically is not correct to programmatically add the copyright year
64 2014-05-13 08:52:57 <wumpus> sigh, it's set manually, not automatically from the current year
65 2014-05-13 08:55:42 <wumpus> and it beats having to update the copyright of the program it in all different user-facing places, 'technically correct' or not I couldn't care less really, can we worry about the hundreds of issues that actually affect anything
66 2014-05-13 09:08:39 <warren> wumpus: ok
67 2014-05-13 09:08:52 <warren> wumpus: btw, are we OK with changing address versions of regtest if pulltester is updated to use it?
68 2014-05-13 09:11:09 <Luke-Jr> pulltester = regtest
69 2014-05-13 09:12:02 <warren> just verifying that it would be accepted if it were done
70 2014-05-13 09:31:25 <wumpus> warren: i don't know, I don't really have an opinion on that, last time I suggested proposing it on the mailing list
71 2014-05-13 09:33:13 <wumpus> depends, for example, how much infrastructure (beyond pulltester) people have already built that assumes that regtest addresses are testnet
72 2014-05-13 09:34:22 <Luke-Jr> I thought they were mainnet :o
73 2014-05-13 09:35:12 <wumpus> Luke-Jr: eh? in that case it'd be good to change them
74 2014-05-13 09:35:46 <warren> they're equal to testnet
75 2014-05-13 09:37:33 <warren> wumpus: I looked around and found literally nothing that uses regtest yet
76 2014-05-13 09:37:45 <warren> writing to list
77 2014-05-13 09:40:22 <wumpus> maybe bitcoinj
78 2014-05-13 09:41:26 <warren> oh mm
79 2014-05-13 09:49:18 <Luke-Jr> warren: to elaborate on my comment earlier, regtest essentially exists *for* pulltester *only* <.<
80 2014-05-13 09:49:36 <Luke-Jr> so, it's no surprise nothing else uses it..
81 2014-05-13 09:50:35 <wumpus> nah, other people use it as well for testing their systems
82 2014-05-13 09:51:06 <wumpus> it has been introduced for pulltester, but that's no longer the only application
83 2014-05-13 09:52:14 <Luke-Jr> commenting on why warren isn't finding anything using it. it isn't a network..
84 2014-05-13 09:55:33 <warren> src/qt/locale/bitcoin_af_ZA.ts: <translation>Die adres waarheen die betaling gestuur moet word (b.v. 1H7wyVL5HCNoVFyyBJSDojwyxcCChU7TPA)</translation>
85 2014-05-13 09:55:45 <warren> unclear why this is the only instance of a different example address in source
86 2014-05-13 09:55:51 <warren> everything else is 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L
87 2014-05-13 09:55:51 <wumpus> zuid afrikaans is almost dutch :)
88 2014-05-13 09:56:14 <warren> I'm changing it in transifex
89 2014-05-13 09:56:56 <wumpus> makes sense
90 2014-05-13 09:57:25 <warren> does anyone own 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJDE9L =)
91 2014-05-13 09:57:50 <warren> apparently not
92 2014-05-13 09:57:56 <Luke-Jr> warren: did you check your own wallet? ;)
93 2014-05-13 09:58:25 <Luke-Jr> hm
94 2014-05-13 09:58:26 <warren> sure, for consistency I'll replace it all with a better example
95 2014-05-13 09:58:33 <Luke-Jr> my B-Qt says that isn't a valid address at all :P
96 2014-05-13 09:58:46 <Luke-Jr> IMO we should use the example on the wiki
97 2014-05-13 09:59:05 <michagogo> cloud|Or CHBS :P
98 2014-05-13 09:59:09 <warren> maybe it was included in source invalid on purpose so nobody uses it?
99 2014-05-13 09:59:14 <Luke-Jr> 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy <!-- anyone-can-spend, null script -->
100 2014-05-13 09:59:38 <Luke-Jr> using P2SH gives it more exposure to people who never see it right now
101 2014-05-13 09:59:45 <jouke> warren, wumpus, we made some in house regtest software, but is really basic and changing the address version is not a problem at all.
102 2014-05-13 10:00:14 <warren> jouke: want to help pick suitable address versions and adapt pull tester?
103 2014-05-13 10:01:03 <jouke> I really have no experience with pull tester and I really don't care what the version will be :)
104 2014-05-13 10:01:13 <michagogo> cloud|Luke-Jr: is it really anyone-can-spend? o_O
105 2014-05-13 10:01:20 <Luke-Jr> michagogo|cloud: yes
106 2014-05-13 10:01:34 <Luke-Jr> null scriptPubKey means you just provide an OP_1 to spend it
107 2014-05-13 10:06:14 <warren> I get to choose the bike shed color if nobody else cares.
108 2014-05-13 10:06:16 <michagogo> cloud|Oh, I see
109 2014-05-13 10:06:31 <michagogo> cloud|That address seems to be buggy with the various explorer-type sites
110 2014-05-13 10:17:58 <wumpus> warren: yes, it's invalid on purpose
111 2014-05-13 11:07:37 <warren> perhaps my status names should be that fine grained too
112 2014-05-13 11:14:37 <warren> I recruited a professional tech translator for Japanese. She has an entire network of tech translators in many other languages.
113 2014-05-13 11:14:51 <warren> I asked them to target the languages that are poorly covered now.
114 2014-05-13 11:15:26 <warren> I plan on spending some of my own funds to tip them. It would be helpful if others can chip in.
115 2014-05-13 11:20:02 <warren> None of them are Bitcoin users.... but perhaps they will be after they do this. =)
116 2014-05-13 11:20:15 <wumpus> I don't know, wouldn't it be better to encourage the community to be more active on transifex? I'm not sure paying translators is currently a good use of our funds, also because things are so much in flux and bitcoin core is moving toward more of a background role
117 2014-05-13 11:21:08 <warren> We've been asking for translators for a LONG time and many languages are barely improved. Japanese supposedly has 10 contributors but it's quite low in coverage.
118 2014-05-13 11:21:27 <warren> boosting a few key languages to 100% once might just help adoption in that country? I dunno
119 2014-05-13 11:21:54 <warren> you're right about core taking a background role
120 2014-05-13 11:22:13 <warren> hopefully these recruited translators can be helpful for bitcoin.org, electrum and other projects
121 2014-05-13 11:22:37 <warren> I happen to know these translators and trust their skills in tech translations.
122 2014-05-13 11:24:11 <wumpus> well I'm certainly not against that
123 2014-05-13 11:29:27 <hearn> translating the website seems more profitable than translating Core
124 2014-05-13 11:30:21 <warren> My recent announcements have recruited people to bitcoin-translators list for the purpose of all bitcoin software/websites
125 2014-05-13 11:45:41 <wumpus> warren: great!
126 2014-05-13 12:08:42 <wumpus> I think it makes sense to move the 0.9.2rc1 release past bitcoin 2014
127 2014-05-13 12:09:19 <wumpus> i.e., to next week
128 2014-05-13 12:10:59 <warren> ah, because too many people will be traveling
129 2014-05-13 12:11:12 <warren> what new date do you want?
130 2014-05-13 12:11:54 <wumpus> and the macosx gitian stuff isn't finished yet, the release has to wait for that anyway
131 2014-05-13 12:12:15 <warren> right
132 2014-05-13 12:17:10 <warren> just add 7 days then?
133 2014-05-13 13:07:26 <warren> wumpus: oh, 0.9.2 is now branched off?
134 2014-05-13 13:08:29 <warren> should I begin building both branches?
135 2014-05-13 13:09:39 <warren> wumpus: sleeping now. please let me know if I should announce a 7 day delay in the schedule
136 2014-05-13 13:09:49 <warren> and if you want the "string freeze" to happen now or next week
137 2014-05-13 15:00:20 <wumpus> warren: yes, building both branches makes sense
138 2014-05-13 15:00:37 <wumpus> warren: I notified you on IRC when the split-off happened
139 2014-05-13 15:02:11 <wumpus> warren: string-freeze is fine, we've sort of been in that for a whlie already
140 2014-05-13 15:09:06 <wumpus> last update was before the fork, and I need to have some solution in place before I can update the English translations from anything but the 0.9.2 branch, otherwise messages will get lost
141 2014-05-13 15:51:58 <coryfields> wumpus: you see my ping from last night?
142 2014-05-13 15:52:18 <coryfields> still working furiously to have dmg builds for .9.2. Am I too late?
143 2014-05-13 15:54:21 <wumpus> coryfields: no, not too late, I've postponed the rc1 till after bitcoin 2014
144 2014-05-13 15:56:23 <coryfields> ok
145 2014-05-13 15:56:46 <wumpus> coryfields: I don't see anything from last night, browsing back the log now
146 2014-05-13 15:56:53 <coryfields> keep bumping into small issues. But it's coming
147 2014-05-13 15:57:32 <wumpus> I know, the small issues are always what costs the most time with gitian
148 2014-05-13 15:57:43 <coryfields> wumpus: no worries. I just said that I'm still working on it constantly, just little things
149 2014-05-13 15:57:55 <coryfields> yea, and they take forever to recreate. It's nothing hard, just incredibly time consuming
150 2014-05-13 15:58:10 <coryfields> i'll be really happy to have this done and move onto more interesting things :)
151 2014-05-13 15:58:11 <coryfields> back in a bit
152 2014-05-13 15:58:27 <wumpus> yes indeed, it's a drag, but we need it :)
153 2014-05-13 15:58:32 <wumpus> ok later
154 2014-05-13 18:17:24 <michagogo> cloud|Is there a way to suppress the "Bitcoin server starting"?
155 2014-05-13 18:17:37 <michagogo> cloud|er, wrong channel I guess
156 2014-05-13 18:22:52 <elichai2> yes it is :)
157 2014-05-13 18:23:04 <elichai2> any news in the development?
158 2014-05-13 18:48:14 <lechuga_> with bip32 would i be able to: create a private key, derive infinite key/pairs from it, give someone else the public key to the original private key and they would be able to tell any of derivations came from the same original private key?
159 2014-05-13 18:48:35 <lechuga_> any of the derivations*
160 2014-05-13 18:50:44 <kdomanski> so...CPartialMerkleTree::ExtractMatches is only used within unit tests]
161 2014-05-13 19:51:11 <dhill> sipa?
162 2014-05-13 19:52:33 <dhill> in checkpoints.cpp, i see 16341 as the number of txs from genesis to block 546. my test shows only 1488 txs.
163 2014-05-13 20:14:41 <michagogo> cloud|2014-05-13 20:13:27 UpdateTip: new best=000000005a4ded781e667e06ceefafb71410b511fe0d5adc3e5a27ecbec34ae6 height=546 log2_work=41.095419 tx=560 date=2009-01-15 06:08:20 progress=0.000008
164 2014-05-13 20:15:13 <michagogo> cloud|Oh, testnet
165 2014-05-13 20:15:15 <gmaxwell> michagogo|cloud: he's asking about testnet.
166 2014-05-13 20:17:47 <michagogo> cloud|Hmm.
167 2014-05-13 20:17:59 <michagogo> cloud|Looks like that here too: 2014-05-13 20:16:54 UpdateTip: new best=000000002a936ca763904c3c35fce2f3556c559c0214345d31b1bcebf76acb70 height=546 log2_work=41.095419 tx=1488 date=2012-05-25 17:14:29 progress=0.001365
168 2014-05-13 20:19:07 <michagogo> cloud|And the timestamp differs too: 1338180505 translates to 4:48:25 am UTC Monday, May 28, 2012
169 2014-05-13 20:20:10 <michagogo> cloud|It does appear sipa is to blame.
170 2014-05-13 20:37:22 <andytoshi> shouldn't something fail if the checkpoints don't match reality?
171 2014-05-13 20:38:58 <jrick> checkpoints are assumed to be reality
172 2014-05-13 20:39:06 <jrick> the point is to not have to check them
173 2014-05-13 20:45:09 <gmaxwell> andytoshi: this is not a checkpoint. geesh
174 2014-05-13 20:45:21 <gmaxwell> all it is is some numbers for estimating the synchronization progress.
175 2014-05-13 20:46:00 <gmaxwell> jrick: and no, thats not the case.
176 2014-05-13 20:51:00 <jrick> it prevents nodes from advertising chains that are obviously wrong
177 2014-05-13 20:51:12 <jrick> and tx signatures are not checked until after the final cp
178 2014-05-13 20:51:33 <jrick> (not disagreeing with you, obviously you know yuor stuff, but just saying what I understand about them)
179 2014-05-13 20:55:49 <gmaxwell> Yes, as a regretable performance optimization which has better alternatives that will be used in the future. Everything else, however, is still checked which is why I commented disagreeing.
180 2014-05-13 20:56:55 <jrick> if a bitcoind node was running with the wrong checkpoints would they ignore every other node on the network or finish the IBD anyways?
181 2014-05-13 20:57:23 <gmaxwell> wrong how?
182 2014-05-13 20:57:43 <jrick> wrong block hashes for example
183 2014-05-13 20:57:55 <jrick> wrong == not matching the rest of the nodes on the network
184 2014-05-13 20:58:54 <gmaxwell> they'll just reject the mismatching thing and continue as normal (e.g. following another chain if there is one.)
185 2014-05-13 20:59:45 <gmaxwell> Generally you'd do best to not think about them much, since their role should be greatly reduced after headers first is implemented, since they won't be needed for anti-dos anymore.
186 2014-05-13 20:59:46 <jrick> yeah that's what I had thought, hence "checkpoints are assumed to be reality"
187 2014-05-13 21:00:31 <gmaxwell> jrick: what you said is "checkpoints are assumed to be reality the point is to not have to check them" which is absolutely not correct.
188 2014-05-13 21:01:09 <gmaxwell> As it does check, deciding that one side or another _wins_ is not the same as not checking.
189 2014-05-13 21:03:29 <jrick> ok
190 2014-05-13 21:03:41 <jrick> i haven't dug too deep in the chain verification rules but that's good to know
191 2014-05-13 21:04:03 <jrick> so other chains are rejected but the assumed valid chain is still checked to be valid
192 2014-05-13 21:05:05 <jrick> and now that I think about it that has to be the case, or else a node can send you blatently wrong blocks
193 2014-05-13 21:31:25 <warren> http://nightly.bitcoin.it/0.9.2/
194 2014-05-13 22:00:48 <Emcy> bccore has nightly builds now?
195 2014-05-13 22:03:19 <michagogo> cloud|Emcy: apparently.
196 2014-05-13 22:07:50 <warren> Emcy: https://bitcointalk.org/index.php?topic=571414.0
197 2014-05-13 22:11:08 <Emcy> so theyre auto build deterministly from daily git tags?
198 2014-05-13 22:11:29 <Emcy> where/who actually builds though
199 2014-05-13 22:12:35 <Emcy> oh its a forked repo
200 2014-05-13 22:12:37 <warren> it's built in an undisclosed bat cave
201 2014-05-13 22:13:04 <warren> and if people actually verify the gitian builds it doesn't matter where its built
202 2014-05-13 22:14:13 <KuDeTa> off hand, does someone know any upper limit to the number of addresses a (custom) single client could realistically manage theoretically, just in terms of maximum computer specs etc? I know its a random question, but someone is suggesting mtgox created and managed 20mil bitcoin addresses. As far as i know, there are only about 35-40mil addresses ever used, so the number seems high for the network and high just out of
203 2014-05-13 22:15:16 <warren> KuDeTa: to handle a huge number of addresses and transactions you currently need to implement your own wallet
204 2014-05-13 22:15:22 <warren> that can be hazardous
205 2014-05-13 22:16:12 <KuDeTa> i know and understand. We know Mark Kerpeles did that too. I just wondered what was technically possible. 20mil is just massive
206 2014-05-13 22:18:27 <Emcy> depends how long you want to wait for operations?
207 2014-05-13 22:18:59 <KuDeTa> Managable..
208 2014-05-13 22:23:04 <droark> gmaxwell & sipa - I'm looking into ECDSA deterministic signing. What are the current best practices? Is RFC 6979 a good choice for such things? It looks good to me but I know some people think it's too complicated.
209 2014-05-13 22:33:39 <sipa> droark: i believe it is unnecessarily complicated indeed
210 2014-05-13 22:34:46 <sipa> KuDeTa: addresses is not a problem, apart from loading time i thibk bitcoind scales to millions. but the number of transactions can be problmatic
211 2014-05-13 22:35:21 <KuDeTa> sipa: is it likely that gox were really using 20mil addresses?
212 2014-05-13 22:37:54 <wallet42> http://btc.ondn.net/search there are only 2,9mil addr with some coins
213 2014-05-13 22:38:18 <Luke-Jr> KuDeTa: quite possible, but off-topic here
214 2014-05-13 22:38:38 <KuDeTa> sorry, seemed sensible to ask the devs ;)
215 2014-05-13 22:38:40 <KuDeTa> thanks
216 2014-05-13 22:41:21 <droark> sipa: I can understand RFC 6979 being considered to be complicated. I figured it might have to do with security concerns or other issues. Are there any recommended alternatives?
217 2014-05-13 22:43:20 <sipa> i'm not a cryptographer
218 2014-05-13 22:43:45 <droark> Okay. Thanks.
219 2014-05-13 22:44:02 <sipa> but as far as i can see it really just defines a way to generate pseudorandom sequence generated from the message andbthe private key, and use the output of that as secret nonce
220 2014-05-13 22:44:53 <sipa> and you can use just as well any other such function
221 2014-05-13 22:45:21 <droark> Yeah, that was my read. Seemed a little twisted but I figured there was a reason for it. You're right, in theory, anything else could be used.
222 2014-05-13 22:51:00 <sipa> i'd use something hmac-sha512(key=secret, msg=someprefix + message)
223 2014-05-13 22:52:00 <droark> Thanks. It's certainly easy enough to implement.
224 2014-05-13 22:58:57 <gmaxwell> sipa: well it did take some care to avoid extension attacks when the underlying hashfunction is non-ideal.
225 2014-05-13 23:04:51 <droark> gmaxwell: So you're basically saying 6979 is, if not perfect, at least a decent attempt at mitigating certain attacks? Is there anything else you'd recommend?
226 2014-05-13 23:05:59 <gmaxwell> what sipa says above is fine too, but "other random thing someome came up with" is not.. e.g. constructions that don't use hmac.
227 2014-05-13 23:06:42 <droark> Yeah, I figured HMAC would be almost mandatory.
228 2014-05-13 23:51:01 <robwhiz22> hi guys
229 2014-05-13 23:51:47 <robwhiz22> Is it true there is a universal maximum on number of transactions per second on the bitcoin network? (around 700/second is what I read), worldwide?
230 2014-05-13 23:51:58 <robwhiz22> i.e. by protocol
231 2014-05-13 23:53:19 <gmaxwell> robwhiz22: Lets take this discussion to #bitcoin.
232 2014-05-13 23:53:37 <robwhiz22> k