1 2012-02-29 00:00:40 <sipa> BlueMatt: as it allows parallelization of key generation, it can be considered a scalable enterprise solution
2 2012-02-29 00:01:02 <BlueMatt> there we go, now thats the kind of buzzword thinking we need around here
3 2012-02-29 00:01:15 <BlueMatt> HD Enterprise Wallets
4 2012-02-29 00:01:31 <sipa> furthermore, as single-chain pubkey codes do not reveal any private information, they can safely be uploaded to the Cloud(tm)
5 2012-02-29 00:01:40 <da2ce7> lol
6 2012-02-29 00:01:42 <BlueMatt> great, lets keep it going
7 2012-02-29 00:01:50 <BlueMatt> HD Enterprise Cloud Wallets
8 2012-02-29 00:01:57 <etotheipi_> you know I never noticed that the secp256k1 curve has super-simple coefficients.... in x^3 + ax + b, a=0 and b=7
9 2012-02-29 00:02:11 <etotheipi_> so it's really just y^2 = x^3 + 7
10 2012-02-29 00:02:17 <BlueMatt> really? damn
11 2012-02-29 00:02:39 <sipa> etotheipi_: Hal feared secp256k1 because its simplicity
12 2012-02-29 00:02:55 <etotheipi_> I would've expected full 32-byte coefficients
13 2012-02-29 00:03:22 <sipa> secp256r1 does have such coefficients, and is apparently considered more safe because of it
14 2012-02-29 00:03:24 <etotheipi_> well, I guess modular arithmatic is powerful enough that such complexities are unnecessary
15 2012-02-29 00:03:36 <da2ce7> sipa: why only a 32-byte root seed?
16 2012-02-29 00:03:36 <sipa> https://bitcointalk.org/index.php?topic=2699.0
17 2012-02-29 00:03:41 <sipa> da2ce7: why more?
18 2012-02-29 00:03:54 <sipa> we don't over more than 128-bit security anyway
19 2012-02-29 00:04:09 <graingert> would it not be better to define the key type in the address
20 2012-02-29 00:04:10 <da2ce7> hmm; ok.
21 2012-02-29 00:04:18 <graingert> or pubkey
22 2012-02-29 00:04:35 <sipa> graingert: not sure what you mean; addresses have not yet come into the picture
23 2012-02-29 00:04:48 <graingert> sorry pubkey
24 2012-02-29 00:05:00 <sipa> what would the "key type" be?
25 2012-02-29 00:05:06 <graingert> hash(pubkey + "sep" + enc type)
26 2012-02-29 00:05:06 <sipa> Ah, you mean secp256k1?
27 2012-02-29 00:05:20 <graingert> could extend to rsa
28 2012-02-29 00:05:21 <sipa> No need, there is a version byte for such things.
29 2012-02-29 00:05:23 <graingert> or rot13
30 2012-02-29 00:06:02 <sipa> But adding a new signature scheme would imply a hardfork, so...
31 2012-02-29 00:06:06 <sipa> ... wait, it doesn't
32 2012-02-29 00:06:33 <BlueMatt> sipa: tripple? thats weak quad-rot13 is the way to go
33 2012-02-29 00:07:07 <da2ce7> sipa: we should also define a standard for 'easly human rememberable wallets' aka... Wallet Name: UserName: Passphase: that is all hashed to create a key.
34 2012-02-29 00:07:36 <da2ce7> so the wallet name, username, and password are all hashed together to make the seed.
35 2012-02-29 00:07:38 <etotheipi_> da2ce7, this has been talked about a lot: there's a ton of risk of people sharing wallets when they use overly-simple passphrases
36 2012-02-29 00:07:46 <sipa> da2ce7: I don't like that, I prefer randomly generated masterkeys, which can be written on paper.
37 2012-02-29 00:07:49 <BlueMatt> da2ce7: I still really prefer the printable computer-generated ones
38 2012-02-29 00:08:20 <etotheipi_> if someone knows your wallet name and username... they can too easily guess your password... you *really* need that full 32-bytes of entropy in the master key
39 2012-02-29 00:08:21 <da2ce7> BlueMatt: sure, but if the risks are clearly explained... it would be super handy, for example when traveling.
40 2012-02-29 00:08:45 <BlueMatt> da2ce7: ever heard of a flash drive?
41 2012-02-29 00:08:53 <BlueMatt> I hear you can encrypt those...
42 2012-02-29 00:08:58 <sipa> da2ce7: I don't approve of using the block chain as your wallet (though for simple usage it may be possible).
43 2012-02-29 00:10:10 <da2ce7> hmm... I think that it would be usefull... I would use my credit card number as one of the feilds... there is no problem in carrying a credit card over any boarder; then ill also remember a phase.
44 2012-02-29 00:10:34 <sipa> etotheipi_: well, casascius' first generation coins have only 123 bits of entropy.
45 2012-02-29 00:12:15 <da2ce7> sipa: how dose the HDW handel Encryption? are you going to include that in the standard?
46 2012-02-29 00:12:39 <BlueMatt> da2ce7: get it right, its (at least) HDEC Wallets
47 2012-02-29 00:13:35 <da2ce7> HDEC Wallets... hmm but do we really need to specify that it is EC cypto?
48 2012-02-29 00:13:44 <sipa> da2ce7: actually, no
49 2012-02-29 00:13:45 <BlueMatt> HE-Enterprise-Cloud Wallets
50 2012-02-29 00:14:18 <sipa> da2ce7: you can store [P(s),Encrypt(s),c]
51 2012-02-29 00:16:02 <da2ce7> yep. hmm... well if we can make this into a flat-file.txt format. including an standard way of handeling encyption; then bitcoin-qit, bitcoinj, armory, multibit et'all could all impment the same format.
52 2012-02-29 00:17:28 <da2ce7> bitcoin-walletchain:(P(s)....) io handeler for links.
53 2012-02-29 00:17:53 <da2ce7> so mtgox could give you a private key pair, to sweep coins from, to withdraw.
54 2012-02-29 00:17:58 <da2ce7> *chain
55 2012-02-29 00:18:40 <da2ce7> and send to a differnt address every time you withdraw... no need to load up bitocoin to generate 'yet annother' address.
56 2012-02-29 00:19:51 <etotheipi_> sipa, actually I didn't mean to suggest that they need the full 256-bits of entropy... but they need way more entropy that a user-generated passphrase alone
57 2012-02-29 00:20:06 <sipa> etotheipi_: i completely agree
58 2012-02-29 00:20:29 <etotheipi_> because no matter what warnings you give, people will use their first name as their password, and then post about all their coins getting stolen, creating FUD fodder for opponents of bitcoin
59 2012-02-29 00:20:37 <etotheipi_> and of course they'll never admit they used a weak passphrase
60 2012-02-29 00:21:14 <sipa> How do you mean "bitcoin" is not a good password? I don't think many peope would think of that!
61 2012-02-29 00:22:06 <da2ce7> etotheipi_: yep... maybe have a option for people to include a passphase in the key generation. So we give them a 'write this code down, and optionaly supply a password'
62 2012-02-29 00:22:18 <da2ce7> *seed
63 2012-02-29 00:23:24 <da2ce7> so they print out their qrcode/random base58 string... and also have a phasephase for the seed. :P
64 2012-02-29 00:27:07 <graingert> BlueMatt: why?
65 2012-02-29 00:28:15 <BlueMatt> why what?
66 2012-02-29 00:28:25 <da2ce7> graingert: it was ''Bitcoin'
67 2012-02-29 00:28:39 <BlueMatt> Im not that stupid, it was B1tcoin ;)_
68 2012-02-29 00:28:54 <BlueMatt> (actually, in reality, it was a randomly generated string just like all my passwords)
69 2012-02-29 00:29:48 <da2ce7> gpg -a --gen-random 3 32
70 2012-02-29 00:29:52 <da2ce7> *no
71 2012-02-29 00:30:08 <BlueMatt> actually keepassx
72 2012-02-29 00:30:20 <da2ce7> gpg -a --gen-random 1 32
73 2012-02-29 00:30:21 <da2ce7> :)
74 2012-02-29 00:30:36 <da2ce7> that is what I use... very handy... and gpg is installed everywhere.
75 2012-02-29 00:30:50 <da2ce7> produces something like; f6RHYZ30X0OCysz7s7ADjcAQCNd6V2hizCRF8wX7QBE=
76 2012-02-29 00:30:51 <BlueMatt> but doesnt have a built-in password manager
77 2012-02-29 00:31:10 <BlueMatt> also, I can easily customize for broken websites which wont let you use special character x or y
78 2012-02-29 00:31:39 <da2ce7> BlueMatt that is why you pass it throogh gpg -e -a and email the result to yourself.
79 2012-02-29 00:31:57 <da2ce7> BlueMatt lawl.
80 2012-02-29 00:32:05 <BlueMatt> thats a pita compared to a program built for password management
81 2012-02-29 00:34:28 <BlueMatt> also, I can load my password db on android, or really any computer, and there are good flash-drive versions too
82 2012-02-29 00:34:40 <BlueMatt> so, even if its not as ubiquitous as gpg, its pretty damn good
83 2012-02-29 00:34:56 <graingert> lastpass is cool too
84 2012-02-29 00:35:25 <BlueMatt> /nod, but even if it is awesome, I still prefer a local version
85 2012-02-29 00:35:40 <sipa> you can create a backup yourself
86 2012-02-29 00:35:56 <sipa> though it's quite manual
87 2012-02-29 00:36:11 <BlueMatt> yea, but I sync it to my phone and server in germany anyway, so...
88 2012-02-29 00:36:17 <BlueMatt> (automatically)
89 2012-02-29 00:36:23 <BlueMatt> (in addition to bitcoin wallet, etc)
90 2012-02-29 00:41:38 <graingert> KeePassX or KeePass2 ?
91 2012-02-29 00:41:43 <graingert> BlueMatt ^
92 2012-02-29 00:41:54 <BlueMatt> X, did they finally make a linux version for version2?
93 2012-02-29 00:42:06 <graingert> yup
94 2012-02-29 00:42:10 <graingert> in ubuntu
95 2012-02-29 00:42:12 <BlueMatt> android too?
96 2012-02-29 00:42:23 <graingert> yep
97 2012-02-29 00:42:30 <graingert> keepassdroid
98 2012-02-29 00:42:38 <graingert> http://www.androlib.com/android.application.com-android-keepass-qtw.aspx
99 2012-02-29 00:42:48 <graingert> which should I get?
100 2012-02-29 00:43:25 <BlueMatt> nfc, when I started there was no Keepass version 2 in ubuntu
101 2012-02-29 00:43:28 <BlueMatt> x was the only option
102 2012-02-29 00:43:48 <BlueMatt> might upgrade sometime though
103 2012-02-29 00:45:06 <da2ce7> ok... there is something that I really want to have... a p2sh. where there is two sets of output, 1. output if both key A and B sign. 2. if key C is used you can only send the coins to address X
104 2012-02-29 00:45:47 <luke-jr> da2ce7: I think you mean a multisig :P
105 2012-02-29 00:46:10 <luke-jr> unfortunately, scriptPubKey has no access to information from the spender's scriptPubKey
106 2012-02-29 00:47:11 <da2ce7> if A & B both agree, the coins can be send to any address... however A || B can send the coins to a pre-definded address.
107 2012-02-29 00:47:23 <da2ce7> (say the address of an court)
108 2012-02-29 00:47:28 <da2ce7> *a
109 2012-02-29 00:47:39 <da2ce7> and that address is pre-defined in the script.
110 2012-02-29 00:47:40 <luke-jr> da2ce7: not possible
111 2012-02-29 00:48:02 <da2ce7> what modifications would be needed to the scripting engine to make it possible.
112 2012-02-29 00:48:22 <luke-jr> something like BIP 17, but more flexible
113 2012-02-29 00:48:48 <sipa> I'd add such things as soon as we replace the script language completely :)
114 2012-02-29 00:48:52 <luke-jr> ^
115 2012-02-29 00:49:27 <da2ce7> :(
116 2012-02-29 00:49:44 <da2ce7> it is a really important use-case
117 2012-02-29 00:49:58 <sipa> it's also a very fundament change that is required
118 2012-02-29 00:50:17 <luke-jr> da2ce7: could just as well make it 2-of-A,B,court
119 2012-02-29 00:50:19 <luke-jr> :p
120 2012-02-29 00:52:02 <da2ce7> luke-jr: sure, but then one of the partys need to contact the court first; and the court can steal the coins at anytime. maybe...
121 2012-02-29 00:52:21 <luke-jr> da2ce7: huh? no
122 2012-02-29 00:52:51 <da2ce7> hmm...
123 2012-02-29 00:53:24 <da2ce7> the other thing.. is that we could nest p2sh... so the court address. could define a script.
124 2012-02-29 01:55:40 <da2ce7> etotheipi_: with your client... there is no problem on windows with always using as much ram as you like... just set it to low priority memory, and windows will automcaticly swap it out for you.
125 2012-02-29 01:56:19 <etotheipi_> da2ce7, ehhh... that's not suffiicent
126 2012-02-29 01:56:28 <etotheipi_> I don't want to allocate that much RAM at all
127 2012-02-29 01:56:50 <etotheipi_> I originally wrote it the way I did to prove how freakin' fast it can be to scan the blockchain... didn't realize I'd later use it to build a client
128 2012-02-29 01:56:53 <sipa> you're not allocating RAM, you're allocating virtual memory </pedantic>
129 2012-02-29 01:57:53 <da2ce7> windows itself uses that for superfetch; the fast loading of programs. it is designed for alication of low-priority data
130 2012-02-29 01:58:22 <da2ce7> it will not slow down winodws, and will run on computers with less than 2gb of ram.
131 2012-02-29 01:58:40 <etotheipi_> except I want a better solution, anyway, without using swap
132 2012-02-29 01:59:46 <da2ce7> as 'everything' will take higher preference than it... but you get caching for free. At the kernel level.
133 2012-02-29 02:00:42 <sipa> but you do not want that
134 2012-02-29 02:00:54 <sipa> you want the data to resize in your database file
135 2012-02-29 02:01:03 <sipa> not in swap, however low priority it is
136 2012-02-29 02:01:09 <sipa> *reside
137 2012-02-29 02:01:20 <etotheipi_> well, I will be taking a compromise approach, at least originally: mmap
138 2012-02-29 02:01:25 <etotheipi_> and the equivalent on windows
139 2012-02-29 02:01:46 <sipa> i was about to suggest that :)
140 2012-02-29 02:01:47 <etotheipi_> it looks like much of what I've already done works beautifully with mmap without changing much
141 2012-02-29 02:02:04 <etotheipi_> except for all those operations that used to take a fraction of a second but now take 20s
142 2012-02-29 02:02:10 <etotheipi_> so I have to re-arrange some calculations...
143 2012-02-29 02:02:26 <da2ce7> sipa: isn't that what it is designed for... low prioirty temporary apllication data, that can be sored in ram if the ram is spare?
144 2012-02-29 02:02:49 <sipa> da2ce7: except the block chain is not temporary data :)
145 2012-02-29 02:03:09 <etotheipi_> basically, mmap does exactly what you're saying, but doesn't use swap... it uses the disk space already occupied by the blockchain
146 2012-02-29 02:03:51 <da2ce7> sipa: the block chain 'working set' should be generated from the chain on disk, on load.
147 2012-02-29 02:04:00 <etotheipi_> AND, as you said... if you have the RAM, it will cache it, and work just as well as the full-RAM implementation
148 2012-02-29 02:04:07 <da2ce7> and be built up as needed.
149 2012-02-29 02:04:08 <sipa> da2ce7: which is exactly what mmap does
150 2012-02-29 02:04:33 <da2ce7> :S
151 2012-02-29 02:05:10 <etotheipi_> if the blockchain wasn't on disk already, I'd be with you... but there's no reason for it to get copied to swap (just another part of the disk) and consume the swap space that might be needed by the user
152 2012-02-29 02:06:04 <etotheipi_> speaking of this... is there any push to start expanding blockchain into blk0002.dat, blk0003.dat?
153 2012-02-29 02:06:19 <sipa> etotheipi_: yes, they are limited to 1 GiB
154 2012-02-29 02:06:21 <etotheipi_> I mean, shouldn't we be concerned about blockchain size getting too big?
155 2012-02-29 02:06:31 <etotheipi_> oh shit... so that's automatic?
156 2012-02-29 02:06:34 <sipa> yes
157 2012-02-29 02:06:48 <etotheipi_> that means Armory will stop working shortly...
158 2012-02-29 02:07:02 <sipa> i think you still have time :)
159 2012-02-29 02:07:11 <luke-jr> Armory shares blk* with bitcoind?
160 2012-02-29 02:07:12 <etotheipi_> not much, last I checked we were approaching quickly
161 2012-02-29 02:07:21 <etotheipi_> luke-jr, it's read-only
162 2012-02-29 02:07:27 <luke-jr> hm
163 2012-02-29 02:07:30 <da2ce7> sipa: has sombody made a stupid number of testnet tx to test the splitting yet?
164 2012-02-29 02:07:39 <sipa> ?
165 2012-02-29 02:08:34 <da2ce7> have we tested the code that splits blk000x > blk000xyz
166 2012-02-29 02:09:30 <sipa> da2ce7: transactions won't help for that; orphans/memory pool transactions are not saved to disk
167 2012-02-29 02:10:43 <da2ce7> shure but couldn't somebody fillup 20K testnet blocks at 50kb each?
168 2012-02-29 02:11:07 <luke-jr> & or just reduce their file size to 10 KB :p
169 2012-02-29 02:11:19 <sipa> i assume/hope satoshi tested it that way
170 2012-02-29 02:11:31 <da2ce7> :O
171 2012-02-29 02:13:38 <sipa> seems we still have some time
172 2012-02-29 02:13:46 <sipa> etotheipi_: 0x7F000000 is the max size per block file
173 2012-02-29 02:14:06 <sipa> 2.13 GB
174 2012-02-29 02:14:10 <luke-jr> &
175 2012-02-29 02:14:13 <luke-jr> that should be reduced
176 2012-02-29 02:14:14 <etotheipi_> ooh, then I got quite a bit of time
177 2012-02-29 02:14:21 <luke-jr> FAT32 maxes out at 2 GB
178 2012-02-29 02:14:39 <da2ce7> I thought 4gb
179 2012-02-29 02:14:41 <sipa> luke-jr: no, it maxes out at 2 GiB
180 2012-02-29 02:14:50 <da2ce7> ahh
181 2012-02-29 02:14:57 <luke-jr> GB*
182 2012-02-29 02:15:01 <etotheipi_> but it will be an easy fix for me... I just gotta scan the bitcoin dir for all blkxxxx.dat files
183 2012-02-29 02:16:19 <etotheipi_> is there a C++-platform independent way of doing that?
184 2012-02-29 02:16:39 <etotheipi_> I forgot I always branched it in my code at work ,but it seemed inelegant
185 2012-02-29 02:17:16 <luke-jr> glob!
186 2012-02-29 02:17:24 <luke-jr> <.<
187 2012-02-29 02:30:23 <finway> ;;seen roconnor
188 2012-02-29 02:30:23 <gribble> roconnor was last seen in #bitcoin-dev 1 week, 4 days, 11 hours, 49 minutes, and 8 seconds ago: <roconnor> Dear user n27pHgA6KioCvXUCdijzdFjeaa9kHA7kzi, Due to your violation of bitcoin TOS your asset has been frozen and your private key is being disclosed as 9afaa65b092e4c82ea752080bee6ce53398207dca480f64c82f32bdb7f85b7e5. Have a nice day, and thank you for using bitcoin.
189 2012-02-29 02:31:48 <luke-jr> hi finway
190 2012-02-29 02:31:56 <finway> hi,luke
191 2012-02-29 02:32:53 <finway> What's that mean?
192 2012-02-29 02:33:00 <finway> private key is being disclosed
193 2012-02-29 02:33:04 <finway> a new bug ?
194 2012-02-29 02:33:15 <luke-jr> finway: nah, I think that was a troll
195 2012-02-29 02:33:52 <finway> the address seems BIP16 ?
196 2012-02-29 02:33:54 <luke-jr> n27& is a namecoin addr anyhow
197 2012-02-29 02:34:01 <luke-jr> BIP16/17 begin with 3&
198 2012-02-29 02:34:03 <finway> oh
199 2012-02-29 02:34:28 <finway> so blockexplorer.com/testnet can explore namecoin ?
200 2012-02-29 02:35:11 <luke-jr> finway: no?
201 2012-02-29 02:37:24 <sipa> finway: it's just a testnet address
202 2012-02-29 02:39:18 <finway> http://blockexplorer.com/testnet/address/n27pHgA6KioCvXUCdijzdFjeaa9kHA7kzi
203 2012-02-29 02:39:21 <finway> oh, i see
204 2012-02-29 02:39:49 <finway> Does Nefario live in China ?
205 2012-02-29 03:23:51 <etotheipi_> is there something special about block 47329 on testnet? none of my testnet clients seem to be able to catch up
206 2012-02-29 03:46:06 <etotheipi_> rather... I have 2 testnet clients running, and both are stuck at that block
207 2012-02-29 03:46:19 <etotheipi_> anyone else see this?
208 2012-02-29 04:04:18 <Kiba> howdy howdy
209 2012-02-29 07:46:52 <OneMiner> Hey guys I think I have an error to report.
210 2012-02-29 07:47:54 <OneMiner> Client version 0.5.1-beta prevents Windows 7 64bit from completing a commanded time sync with the internet. When the client is closed time sync works well.
211 2012-02-29 15:48:51 <gribble> New news from bitcoinrss: gavinandresen opened pull request 911 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/911>
212 2012-02-29 17:42:40 <BlueMatt> gavinandresen: are there not better ways to delete a random orphan than just picking a random one?
213 2012-02-29 17:42:47 <BlueMatt> (oldest one, shortest orphan chain, etc)
214 2012-02-29 17:42:59 <BlueMatt> (not sure which can be done quickly, but...)
215 2012-02-29 17:43:22 <gavinandresen> My reasoning for random is: If there is a particular policy, then it is easy for an attacker to try to workaround that policy
216 2012-02-29 17:44:02 <gmaxwell> I thought the random decision was a good one.
217 2012-02-29 17:44:12 <gavinandresen> I don't like oldest, because then an attacker can flood you with orphans and get legitimate orphans out of your pool
218 2012-02-29 17:44:37 <gavinandresen> ... newest is bad because attacker can fill up your pool with orphans that never go away....
219 2012-02-29 17:44:59 <BlueMatt> but with random the orphan pool is half-worthless because you often delete orphans that are in the middle of an orphan chain
220 2012-02-29 17:45:13 <BlueMatt> and then the download from orphan root logic is half-broken
221 2012-02-29 17:45:59 <BlueMatt> maybe highest-work orphan chain
222 2012-02-29 17:46:03 <gavinandresen> Again, if the policy is something more complicated it just makes it easier for an attacker to make sure their orphans are preferred....
223 2012-02-29 17:46:21 <gavinandresen> (there's no work in orphan TRANSACTIONS)
224 2012-02-29 17:47:14 <gmaxwell> BlueMatt: you could write a lot of code to do optimal subgraph dropping. E.g. make the orphans into graphs, then drop a subgraph at random but to me that sounds like a way to create a DOS attack. :)
225 2012-02-29 17:47:58 <BlueMatt> gmaxwell: yea, but I think more thought should be given instead of just drop random...
226 2012-02-29 17:48:23 <BlueMatt> gavinandresen: transactions...uh...oh
227 2012-02-29 17:48:28 <BlueMatt> nevermind
228 2012-02-29 17:48:31 <BlueMatt> Ignore all of that
229 2012-02-29 17:49:14 <gmaxwell> ah, you thought this was about blocks.
230 2012-02-29 17:49:21 <gavinandresen> BlueMatt: :)
231 2012-02-29 17:49:23 <BlueMatt> yea, somehow...
232 2012-02-29 17:50:24 <gmaxwell> The graph code needed to do things like make joint mining decisions (e.g. "I'll mine this txn because there is a dependency with a good fee") could be used to drop orphan txn more smartly but normally txn aren't orphaned by more than one deep.
233 2012-02-29 17:50:55 <BlueMatt> /nod
234 2012-02-29 17:51:26 <BlueMatt> if its orphaned its not a big deal anyway, since it will be rebroadcasted eventually if its dropped anyway
235 2012-02-29 17:51:45 <BlueMatt> if it is valid the owner will make sure it eventually gets in a block
236 2012-02-29 17:53:09 <gavinandresen> yes, for 0.7 turning mapOrphans into a more complicated data structure and evicting old orphans (and maybe dropping peers that send you lots of orphans that never get into blocks) is probably the way to go
237 2012-02-29 17:53:24 <gavinandresen> for 0.6 just fixing the vulnerability is good enough for now
238 2012-02-29 17:54:26 <BlueMatt> meh, there is little reason to make it much more complicated (there are more important issues to address) though dropping peers who send too many orphans might be useful
239 2012-02-29 17:55:07 <jrmithdobbs> that would add the framework to drop peers sending bogus blocks and such too
240 2012-02-29 17:55:12 <jrmithdobbs> so probably worth the effort
241 2012-02-29 17:55:13 <gavinandresen> I keep thinking that maybe DoS prevention code at the send/receive messages/bytes might be worthwhile... disconnect any peer that is sending you an unreasonable number of ANY message
242 2012-02-29 17:55:53 <jrmithdobbs> gavinandresen: just got to keep in mind the problems the last bad dos prevention code caused
243 2012-02-29 17:56:10 <gavinandresen> jrmithdobbs: yup, gotta be very careful...
244 2012-02-29 17:56:32 <gavinandresen> jrmithdobbs: (although which one are you talking about? The latest few DoS patches haven't caused any problems at all)
245 2012-02-29 17:56:51 <jrmithdobbs> gavinandresen: the original one that caused the painful initial download issues
246 2012-02-29 17:57:03 <jrmithdobbs> because of too low a threshold
247 2012-02-29 17:57:24 <gavinandresen> jrmithdobbs: that's what I thought you were talking about...yep, gotta be careful...
248 2012-02-29 17:57:43 <gavinandresen> jrmithdobbs: there's already a framework for dropping peers sending bogus blocks and such
249 2012-02-29 17:57:45 <gmaxwell> jrmithdobbs: we have a general framework for dropping peers that send bogus stuff. But we can't drop for anything an innocent peer might relay.
250 2012-02-29 17:57:58 <gmaxwell> jrmithdobbs: that all was added since you were list digging in the code.
251 2012-02-29 17:58:14 <jrmithdobbs> gmaxwell: right of course (to your "but ...")
252 2012-02-29 19:00:15 <BlueMatt> sipa: are you actually using the term HDW in code?
253 2012-02-29 19:00:46 <BlueMatt> gavinandresen: whats the status on getting an 0.6.0rc2 tag?
254 2012-02-29 19:01:15 <gavinandresen> BlueMatt: I'm gitian-building git head now, if it compiles nicely I'll tag it
255 2012-02-29 19:01:25 <BlueMatt> ok, nice
256 2012-02-29 19:01:56 <BlueMatt> mind double-building to double-check the determinism?
257 2012-02-29 19:02:34 <gavinandresen> BlueMatt: sure, I can do that. Takes a while for my gitian machine to do a build, though
258 2012-02-29 19:12:06 <BlueMatt-mobile> Meh, dont bother then, ill just build whe i get back
259 2012-02-29 19:28:17 <gavinandresen> BlueMatt-mobile: build finished
260 2012-02-29 19:31:20 <gavinandresen> BlueMatt-mobile: how do I get the final gitian-built hash?
261 2012-02-29 19:36:13 <Diablo-D3> woah
262 2012-02-29 19:36:25 <Diablo-D3> soemone sent me a nearly 4 btc donation
263 2012-02-29 19:37:30 <BlueMatt> gavinandresen: there is no such thing, just do the gsign stuff and put it in the gitian.sigs repo
264 2012-02-29 19:37:38 <BlueMatt> (it just finds hashes for individual files)
265 2012-02-29 19:44:13 <superjames> hey, is there a way to get the time of the last received block via json api? or other means
266 2012-02-29 19:45:23 <gavinandresen> BlueMatt: ... but don't I remember pasting a shasum for... the gitian-sigs.zip file? ... to compare different people's builds?
267 2012-02-29 19:46:29 <BlueMatt> gavinandresen: if the output is one single file, sure you can do that
268 2012-02-29 19:46:38 <BlueMatt> but for win32/linux actual bitcoin builds they are many files
269 2012-02-29 20:01:45 <BlueMatt> gavinandresen: my win32 sigs: https://github.com/bitcoin/gitian.sigs/tree/master/0.6.0rc2-win32/bluematt
270 2012-02-29 20:05:56 <gavinandresen> BlueMatt: I built the linux release twice, got the same results. Tagged v0.6.0rc2. And pushed gitian.sigs/0.6rc2/gavinandresen@gmail.com
271 2012-02-29 20:06:06 <gavinandresen> BlueMatt: building win32 now
272 2012-02-29 20:08:43 <BlueMatt> gavinandresen: check that directory matches tag (missing .0) and that signer matches user in contrib/gitian-downloader/win32-download-config (without @gmail.com)
273 2012-02-29 20:08:56 <BlueMatt> the first one isnt a big deal
274 2012-02-29 20:09:09 <gavinandresen> BlueMatt: I'm missing bitcoin-deps-0.0.3.zip
275 2012-02-29 20:09:23 <BlueMatt> but the second one would break gitian-downloader (when someone (ok, probably me) eventually gets around to writing win32 auto-update using gitian)
276 2012-02-29 20:09:49 <BlueMatt> gavinandresen: build contrib/gitian-descriptors/deps-win32.tml and copy build/out/* to inputs (in gitian-builder dir)
277 2012-02-29 20:09:56 <BlueMatt> s/tml/yml/
278 2012-02-29 20:10:21 <BlueMatt> did I forget to add that to release-process?
279 2012-02-29 20:10:28 <gavinandresen> BlueMatt: ok. release-process.txt needs updating, it says cp build/out/bitcoin-deps-0.0.1.tbz2 inputs/
280 2012-02-29 20:10:41 <BlueMatt> yep, ok will do
281 2012-02-29 20:11:49 <gavinandresen> BlueMatt: ... and libpng-1.5.9.tar.gz ....
282 2012-02-29 20:12:08 <gavinandresen> BlueMatt: (never mind, that's ok in release-process.txt)
283 2012-02-29 20:13:12 <BlueMatt> gavinandresen:
284 2012-02-29 20:13:13 <BlueMatt> https://github.com/bitcoin/bitcoin/pull/912
285 2012-02-29 20:13:21 <gavinandresen> BlueMatt: thanks
286 2012-02-29 20:15:07 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 912 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/912>
287 2012-02-29 20:30:27 <gribble> New news from bitcoinrss: gavinandresen opened issue 913 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/913>
288 2012-02-29 20:35:16 <sipa> BlueMatt: re: HDW in code, not sure yet
289 2012-02-29 20:35:35 <BlueMatt> heh, ok
290 2012-02-29 20:35:54 <sipa> BlueMatt: did you see my update to detwallet maybe?
291 2012-02-29 20:36:14 <BlueMatt> I saw a list of commits, one of who's commitmsg's mentioned HDW, I havent had time to actually look yet
292 2012-02-29 20:36:45 <jercos> SSSSSSSSSSSSSSSSSSSS
293 2012-02-29 20:36:47 <jercos> *boom*
294 2012-02-29 20:36:58 <sipa> BlueMatt: just implemented the key derivation + unit tests for it
295 2012-02-29 20:37:10 <BlueMatt> fuck, now I have to walk all the way back out there, damn I hope my stuff is still there
296 2012-02-29 20:37:19 <BlueMatt> sipa: nice
297 2012-02-29 20:38:59 <sipa> i read something about a determinism check; do i need to run a gitian build?
298 2012-02-29 20:39:09 <BlueMatt> gavin tagged 0.6rc2
299 2012-02-29 20:39:15 <BlueMatt> so its always nice to get more sigs ;)
300 2012-02-29 20:39:18 <gavinandresen> BlueMatt: I just pushed gitian.sigs/0.6.0rc2-win32/gavinandresen/
301 2012-02-29 20:40:39 <sipa> no need to rebuild win32-deps, boost or qt?
302 2012-02-29 20:40:45 <BlueMatt> no
303 2012-02-29 20:42:26 <sipa> building
304 2012-02-29 20:45:39 <BlueMatt> gavinandresen: uh, oops the fact that you called gsign with 0.6rc2 for linux and I called gsign with 0.6.0rc2 for win32 (without the -win32) means they dont match...so gsign must be run again (you dont have to build again as long as you havent built anything in between...)
305 2012-02-29 20:45:47 <BlueMatt> so in other words, uh...oops
306 2012-02-29 20:47:04 <gavinandresen> Ok, I saved the linux build directory before building windows, I'll re-sign
307 2012-02-29 20:49:14 <gavinandresen> BlueMatt: re-signed and pushed
308 2012-02-29 20:50:09 <sipa> thanks for putting a '-' between those two syllables
309 2012-02-29 20:51:15 <sipa> dd626ee01ba9574729d521c7d4f6fae5f97f5d2ad09a13afb6f976b94f40c725
310 2012-02-29 20:51:21 <sipa> dd626ee01ba9574729d521c7d4f6fae5f97f5d2ad09a13afb6f976b94f40c725 bitcoin-qt.exe
311 2012-02-29 20:54:12 <gavinandresen> BlueMatt: hang on, I think I screwed up the windows build somehow....
312 2012-02-29 20:55:47 <BlueMatt> gavinandresen: you also have to save var/base-lucid-*.manifest
313 2012-02-29 20:55:56 <BlueMatt> (but that doesnt matter much, since gitian wont complain if you dont)
314 2012-02-29 20:56:41 <gavinandresen> BlueMatt: no, screwed up much more fundamentally: built the deps, but then signed them as if they were the complete windows build....
315 2012-02-29 20:56:48 <BlueMatt> oh...
316 2012-02-29 20:57:12 <gavinandresen> (trying to parallel process, lost my place in what I was building....)
317 2012-02-29 20:57:41 <sipa> my win32 build matches BlueMatt's
318 2012-02-29 20:58:51 <sipa> is there any way for forcing bitcoin-qt to not start up minimized?
319 2012-02-29 20:59:17 <sipa> (at least, that's what i assumed happened, since i see no window, but it's running fine)
320 2012-02-29 20:59:23 <gavinandresen> sipa: that's an option if I remember
321 2012-02-29 20:59:31 <BlueMatt> sipa: mind pushing to the gitian.sigs repo?
322 2012-02-29 20:59:45 <sipa> BlueMatt: yes, as soon as the linux build is done
323 2012-02-29 21:00:25 <BlueMatt> gavinandresen: our linux builds match
324 2012-02-29 21:00:40 <gavinandresen> nifty keen
325 2012-02-29 21:02:04 <luke-jr> does rc2 have the dupe txn fix?
326 2012-02-29 21:02:09 <BlueMatt> no
327 2012-02-29 21:11:49 <sipa> the "Installing additional packages" takes much longer than "Running build script"
328 2012-02-29 21:12:37 <BlueMatt> (or you could use the -i option to gbuild)
329 2012-02-29 21:14:00 <gavinandresen> I got: 059149dfa0d7f706ceb8fc12d528b9b27d004cff991e204043a6fb0b0b48ddee bitcoin-qt.exe
330 2012-02-29 21:14:30 <BlueMatt> can you upload the sigs anyway so we can compare inputs?
331 2012-02-29 21:15:47 <gavinandresen> BlueMatt: done
332 2012-02-29 21:18:32 <sipa> BlueMatt: matches; pushed
333 2012-02-29 21:18:33 <BlueMatt> a. oops I build master instead of 0.6.0rc2 because release-process is 7aa...
334 2012-02-29 21:18:45 <BlueMatt> gavinandresen: we have different qt-win32 and bitcoin-deps
335 2012-02-29 21:19:02 <BlueMatt> gavinandresen: bitcoin-deps I dont understand, can you upload yours, qt-win32 you should grab from skypaint.com/bitcoin
336 2012-02-29 21:21:02 <gavinandresen> bitcoin-deps-0.0.3.zip uploaded to skypaint.com/bitcoin
337 2012-02-29 21:21:04 <BlueMatt> sipa: thanks, Ill get mine to match in a sec
338 2012-02-29 21:22:55 <BlueMatt> gavinandresen: argggg...only the zips differ not the files...wtf???
339 2012-02-29 21:23:39 <gavinandresen> different version of zip?
340 2012-02-29 21:23:46 <gavinandresen> gremlins?
341 2012-02-29 21:23:50 <gavinandresen> cosmic rays?
342 2012-02-29 21:23:51 <sipa> phase of the moon?
343 2012-02-29 21:24:03 <gavinandresen> Ah, I know, it's leap day.
344 2012-02-29 21:24:08 <BlueMatt> oh, that must be it
345 2012-02-29 21:24:52 <sipa> gavinandresen: you built the dependencies right now?
346 2012-02-29 21:25:20 <gavinandresen> bitcoin-deps-0.0.3 yes.
347 2012-02-29 21:25:27 <BlueMatt> gavinandresen: you dont happen to have a zip*.deb in any of your var/*.manifest files in gitiab-builder do you?
348 2012-02-29 21:26:50 <gavinandresen> BlueMatt: http://pastebin.com/WmpzgeE3
349 2012-02-29 21:27:19 <BlueMatt> hmm, sadly not, want to run the deps-win32 build again?
350 2012-02-29 21:27:27 <BlueMatt> also, what -j and -m flags did you build deps-win32 with?
351 2012-02-29 21:27:43 <gavinandresen> I followed release-process.txt....
352 2012-02-29 21:27:58 <sipa> I used -j5 -m2000, and had the same result as BlueMatt
353 2012-02-29 21:28:10 <sipa> at least after he fixed the sorting order input to zip
354 2012-02-29 21:28:23 <BlueMatt> but in theory that shouldnt matter
355 2012-02-29 21:28:33 <BlueMatt> also, it appears the diffs between me and gavin are (again) soring order...
356 2012-02-29 21:29:03 <BlueMatt> at least in qrencode
357 2012-02-29 21:29:38 <BlueMatt> how can sort produce different results???
358 2012-02-29 21:30:13 <sipa> sort is deterministic
359 2012-02-29 21:30:31 <BlueMatt> one would hope so
360 2012-02-29 21:30:53 <BlueMatt> so I guess zip doesnt always add in cli order
361 2012-02-29 21:32:16 <gavinandresen> Rebuilding windows with qt-win32 from skypaint....
362 2012-02-29 21:32:45 <BlueMatt> should result in the same output exe, but gitian wont accept it because it has different inputs...
363 2012-02-29 21:32:52 <BlueMatt> mind rerunning the deps one?
364 2012-02-29 21:34:24 <BlueMatt> sipa: your gsign is 0.6.0rc2-win2 instead of win32
365 2012-02-29 21:34:32 <sipa> dang
366 2012-02-29 21:34:36 <BlueMatt> (just sign again if you havent run a build in between)
367 2012-02-29 21:34:56 <sipa> i did
368 2012-02-29 21:37:00 <gavinandresen> I wonder how long it will take the alterna-chains to apply the 0.6 DoS fixes....
369 2012-02-29 21:37:33 <doublec> gavinandresen: the alt chains I've looked at don't have the DoS code
370 2012-02-29 21:39:55 <BlueMatt> ouch
371 2012-02-29 21:49:41 <gavinandresen> dd626ee01ba9574729d521c7d4f6fae5f97f5d2ad09a13afb6f976b94f40c725 bitcoin-qt.exe
372 2012-02-29 21:49:49 <gavinandresen> yay!
373 2012-02-29 21:50:52 <sipa> BlueMatt: updated
374 2012-02-29 21:50:56 <sipa> gavinandresen: what changed this time?
375 2012-02-29 21:51:19 <gavinandresen> downloaded qt-win32-blah from skypaint
376 2012-02-29 21:51:43 <gavinandresen> gotta run, back in an hour or three
377 2012-02-29 21:53:12 <BlueMatt> sipa: uh, I get an OK for gavin's build, but MISMATCH for yours
378 2012-02-29 21:53:40 <sipa> uh-oh
379 2012-02-29 21:53:41 <sipa> diff?
380 2012-02-29 21:53:53 <BlueMatt> no, still the win2 vs win32 thing
381 2012-02-29 21:54:11 <BlueMatt> did gavin overwrite your push?
382 2012-02-29 21:54:55 <BlueMatt> gavinandresen: nevermind, though our inputs are different, gitian actually doesnt care about inputs on the verification
383 2012-02-29 21:55:13 <BlueMatt> bugs me that the zips are diff, but if gitian doesnt care, neither do i
384 2012-02-29 21:59:51 <sipa> BlueMatt: better now?
385 2012-02-29 21:59:55 <sipa> i don't really understand what happened
386 2012-02-29 22:00:07 <sipa> but my internet connection is quite flaky, maybe my push failed or timed out
387 2012-02-29 22:01:30 <BlueMatt> sipa: looks good now
388 2012-02-29 22:01:31 <BlueMatt> thanks
389 2012-02-29 22:01:43 <BlueMatt> all sigs match
390 2012-02-29 22:02:11 <sipa> who can push them to sf?
391 2012-02-29 22:02:24 <BlueMatt> gavinandresen: jgarzik
392 2012-02-29 22:02:35 <BlueMatt> maybe others
393 2012-02-29 22:04:06 <pentarh> block chain in 3d :) Block tree in DIANNA :) http://dianna-project.org/wiki/DIANNA_Block_Chain
394 2012-02-29 22:09:08 <BlueMatt> dont you mean 2-d (instead of the bitcoin 1-d)
395 2012-02-29 22:10:12 <pentarh> well, yeah )
396 2012-02-29 22:10:32 <BlueMatt> :)
397 2012-02-29 22:10:48 <pentarh> but 3D is fashionable )
398 2012-02-29 22:10:58 <BlueMatt> good point, in that case, make it HD
399 2012-02-29 22:12:46 <pentarh> dianna will make some things to be hd )
400 2012-02-29 22:13:14 <pentarh> i2p surfing for example
401 2012-02-29 23:31:16 <occulta> well that was rude..
402 2012-02-29 23:31:28 <sipa> gmaxwell: concerning hierarchical wallets... i was wondering how much sense it makes to tie the internal chains to external ones
403 2012-02-29 23:32:00 <sipa> gmaxwell: maybe /[internal or external]/[chain number]/[key number] is better as derivation
404 2012-02-29 23:32:32 <sipa> typically one would always use /internal/0/N for change, but that 0 can be configured to be something else
405 2012-02-29 23:32:44 <gmaxwell> So long as it's reasonable easy to find all of the ones in use starting from only knowing the master chain I don't know that it matters.
406 2012-02-29 23:32:47 <sipa> if you want nodes independently capable of spending funds
407 2012-02-29 23:33:17 <gmaxwell> (there are schemes possible which don't tie them which make finding them hard/impossible)
408 2012-02-29 23:33:46 <sipa> the problem with the former scheme (/[chain number]/[internal or external]/[key number]) is that it's not very useful to give someone the /[chain number]/ key
409 2012-02-29 23:33:58 <gavinandresen> RE: uploading to sourceforge: I'm compiling the Mac release now, will start uploading rc2 binaries
410 2012-02-29 23:34:30 <sipa> they can see all incoming payments to that account, but any spends done from the master will most likely be not meaningful, as they combine inputs from severals chains
411 2012-02-29 23:36:08 <BlueMatt> gavinandresen: nice, what is the p2sh switch time coded in rc2?
412 2012-02-29 23:36:10 <BlueMatt> is it never?
413 2012-02-29 23:36:31 <sipa> gmaxwell: you see what i mean?
414 2012-02-29 23:36:47 <gavinandresen> BlueMatt: April 1
415 2012-02-29 23:37:00 <BlueMatt> oh, ok
416 2012-02-29 23:37:05 <BlueMatt> what was the one in rc1?
417 2012-02-29 23:37:13 <gavinandresen> BlueMatt: Feb15 I think?
418 2012-02-29 23:37:27 <BlueMatt> mmm
419 2012-02-29 23:37:48 <gmaxwell> sipa: Yes. But I'm too tired at the moment to think of anything useful to say about that.
420 2012-02-29 23:39:10 <da2ce7> good morning, sipa, gavinandresen, BlueMatt, gmaxwell :)
421 2012-02-29 23:39:26 <BlueMatt> hi da2ce7
422 2012-02-29 23:39:33 <BlueMatt> also, morning? its 7:30
423 2012-02-29 23:39:43 <sipa> morning? it's 1:40am here!
424 2012-02-29 23:39:55 <da2ce7> 11:39 here...
425 2012-02-29 23:39:57 <BlueMatt> da2ce7: in asia?
426 2012-02-29 23:40:08 <sipa> australia
427 2012-02-29 23:40:11 <da2ce7> yep Aus
428 2012-02-29 23:40:20 <BlueMatt> ah
429 2012-02-29 23:41:37 <da2ce7> I think that we should make an alert and release a bitcoin client that fixes this bug asap... I also think that it is worth the extra code to 'unlile' the blocks, before it becomes mandotory; set a changeover time.
430 2012-02-29 23:42:20 <da2ce7> as it minimises the risk of a hard fork.
431 2012-02-29 23:42:28 <BlueMatt> we have to get miner support first
432 2012-02-29 23:42:37 <BlueMatt> also, when we release, we have to do it with a new version
433 2012-02-29 23:43:27 <da2ce7> BlueMatt, just a hard fork?
434 2012-02-29 23:43:39 <BlueMatt> who said anything about a hard fork?
435 2012-02-29 23:43:44 <da2ce7> if sombody puts a block that breaks the rules.
436 2012-02-29 23:43:49 <BlueMatt> if we have miner support for this, we wont have a hard fork
437 2012-02-29 23:44:05 <da2ce7> but you need >> 50%
438 2012-02-29 23:44:27 <BlueMatt> yea, but its a minor change, so (it is hoped) that that shouldnt be hard
439 2012-02-29 23:47:03 <sipa> i hope most pool operators will agree quickly to patch
440 2012-02-29 23:47:34 <sipa> if there is 70% miner support, a 6-block long fork has less than 1/1000 chance
441 2012-02-29 23:49:13 <da2ce7> sipa: do we have standard code for 'unperfer blocks that break the rule, then after x number of blocks, enforce rule'
442 2012-02-29 23:50:01 <gmaxwell> da2ce7: the code to do that is complicated and carries its own risk.
443 2012-02-29 23:50:45 <da2ce7> oh. so we don't have well tested generic code from the testnet :(
444 2012-02-29 23:50:48 <gmaxwell> this fix only has a forking risk _IF_ an attack is carried out. It makes the consequences somewhat worse should one happen and the fix be only partially deployed, but we're already in trouble of the attack happens.
445 2012-02-29 23:51:07 <gmaxwell> da2ce7: as if it would _actually_ be well tested?
446 2012-02-29 23:51:35 <da2ce7> hmm... do a whole heap of test runs... with people trying to subvert it.
447 2012-02-29 23:52:01 <gmaxwell> So, you'll be funding this team of dedicated testers then? :)
448 2012-02-29 23:52:28 <gmaxwell> It's easy to wave your hands, harder to actually do it.
449 2012-02-29 23:54:20 <da2ce7> :( I know; everyone is busy with there own projects.
450 2012-02-29 23:55:23 <gmaxwell> da2ce7: well the code exists. Its a bit scarry though.
451 2012-02-29 23:55:43 <gmaxwell> Gavin created it a while ago. Presumably we'll sometime have it as a generic mechenism.
452 2012-02-29 23:56:03 <da2ce7> kk
453 2012-02-29 23:56:14 <gmaxwell> Luke was generally unhappy with the behavior though, because you're likely to get orphaned if you mine while using it unless everyone also uses it.
454 2012-02-29 23:56:27 <gmaxwell> so basically it just replaces the problem with a meta problem of the same kind. :(