1 2013-10-19 02:26:15 <coingenuity> who administers bitcoin.org
  2 2013-10-19 02:28:02 <coingenuity> sipa Luke-Jr
  3 2013-10-19 02:29:44 <coingenuity> gavinandresen
  4 2013-10-19 02:34:19 <MC1984_> saivann isnt it?
  5 2013-10-19 02:34:37 <saivann> Mostly, yes
  6 2013-10-19 02:35:25 <saivann> coingenuity: ping
  7 2013-10-19 02:35:51 <coingenuity> ah, hi saivann
  8 2013-10-19 02:36:07 <coingenuity> http://pastebin.com/hC92AFzt here you are
  9 2013-10-19 02:36:28 <coingenuity> someone's either broken into your MTA, or is spoofing emails
 10 2013-10-19 02:36:49 <coingenuity> might wanna take a look and see if your boxes look normal there
 11 2013-10-19 02:37:12 <saivann> coingenuity: Yes I saw that on bitcointalk. I doubt we can do anything about it. The domain name is managed by sirius, but this is probably just plain simple spoofing..
 12 2013-10-19 02:37:13 <MC1984_> wuts an MTA
 13 2013-10-19 02:37:37 <coingenuity> ah, ok- glad you're aware
 14 2013-10-19 02:37:45 <coingenuity> was worried some box got owned :)
 15 2013-10-19 02:38:05 <coingenuity> i havent seen sirius in like... couple years... do we still have dns access?
 16 2013-10-19 02:38:15 <coingenuity> if so, we should add an SPF record
 17 2013-10-19 02:38:28 <saivann> coingenuity: Perhaps I can ping sirius just in case.. But I guess that the attacker just "pretend" to be from @bitcoin.org
 18 2013-10-19 02:39:16 <saivann> coingenuity: SPF would be a good idea, and locking the domain name also.. but last time I asked sirius, I didn't get a reply on this subject. Sometime he answers, sometime he doesn't..
 19 2013-10-19 02:39:45 <saivann> To my knowledge, nobody except sirius have access to bitcoin.org dns..
 20 2013-10-19 02:40:09 <coingenuity> im not expert enough on email-blackhat to tell from the headers if it's a local compromise or not, but looking closely it seems like a russian mailserver spoofing bitcoin.org for a vietnamese SMTP originator
 21 2013-10-19 02:40:29 <coingenuity> however, "(HELO ?192.168.0.100?)" makes me nervous
 22 2013-10-19 02:40:54 <coingenuity> in any case, if sirius could add an SPF record for bitcoin.org that would be great, as i would hate to see noobies scammed this way
 23 2013-10-19 02:41:04 <coingenuity> its at least worth asking about :)
 24 2013-10-19 02:42:38 <saivann> coingenuity: I'll ask him. Definitively worth trying to protect users against this. Thanks!
 25 2013-10-19 02:42:59 <coingenuity> sure thing :) wanted to catch it early on
 26 2013-10-19 02:43:31 <coingenuity> [19:41:38] <Eleuthria> Heh, just got a phishing email from "donation@bitcoin.org" trying to solicit donations for Bitcoin Foundation.   Looked so good until the end where it broke into engrish. <<< oh nose :(
 27 2013-10-19 02:44:04 <coingenuity> think i'll keep an eye on this address
 28 2013-10-19 02:48:32 <MC1984_> https://blockchain.info/address/1PPqWCmzDeBxgtfwNPqekzHBTzxnkXba5i
 29 2013-10-19 02:48:41 <MC1984_> dumbass level so far: 0%
 30 2013-10-19 02:49:13 <saivann> Yes, that's reassuring
 31 2013-10-19 02:50:01 <nanotube> coingenuity: from the headers, it's clearly not being sent from bitcoin.org. yes, spf is only thing we can do about that, and even that's far from perfect.
 32 2013-10-19 02:53:43 <coingenuity> nanotube: being the crypto nerds we are, we should set up DMARC :D
 33 2013-10-19 02:55:08 <nanotube> heh /me googled.
 34 2013-10-19 02:55:37 <coingenuity> the only non-trivial aspect is integration the dkim privkey into an MTA
 35 2013-10-19 02:55:42 <coingenuity> but that's really not even that bad
 36 2013-10-19 02:56:02 <nanotube> well the other thing is, if nobody else is using it, it won't do anything. :P
 37 2013-10-19 02:56:50 <coingenuity> dmarc is standard amongst all major mail providers
 38 2013-10-19 02:57:15 <coingenuity> AOL, Comcast, Gmail, Hotmail, Mail.ru, Netease, XS4ALL, Yahoo! <<< short list of some of the major providers
 39 2013-10-19 02:57:29 <nanotube> ah nice
 40 2013-10-19 02:57:46 <coingenuity> https://dmarcian.com/dmarc_adoption/ bigger list
 41 2013-10-19 02:57:47 <coingenuity> :)
 42 2013-10-19 02:58:17 <coingenuity> Total: 3.382 billion supported email addresses
 43 2013-10-19 02:58:19 <coingenuity> heh
 44 2013-10-19 02:58:46 <nanotube> andreasschulze.de 
 45 2013-10-19 02:59:47 <nanotube> those extra 19 users were really important. >_>
 46 2013-10-19 02:59:54 <coingenuity> lmao
 47 2013-10-19 05:11:58 <warren> contrib/linearize/linearize.py:
 48 2013-10-19 05:12:00 <warren> what is that?
 49 2013-10-19 05:14:10 <Luke-Jr> https://en.bitcoin.it/wiki/Protocol_specification#Message_structure
 50 2013-10-19 05:15:19 <olalonde> how do miners know a transaction was already included in the blockchain?
 51 2013-10-19 05:16:48 <olalonde> like lets say i broadcast transaction A, A gets included in the next block
 52 2013-10-19 05:17:03 <olalonde> how do other miners know they should no longer attempt to include A in the following block
 53 2013-10-19 05:24:11 <olalonde> because it becomes invalid?
 54 2013-10-19 05:26:23 <freewil> well, technically speaking i think when they get the new block, they'll just remove any tx they have in their mempool that are included in the block
 55 2013-10-19 05:27:00 <freewil> so they wont try to do it
 56 2013-10-19 05:53:36 <olalonde> would it be correct to say that every transaction in the blockchain is unique?
 57 2013-10-19 05:54:02 <olalonde> since you can't use the same output twice
 58 2013-10-19 05:57:38 <swulf--> olalonde: yes, but I believe there's been a hash collision once before
 59 2013-10-19 05:58:12 <olalonde> transaction hash collision?
 60 2013-10-19 05:58:22 <olalonde> so 2 different transactions that hash to the same number?
 61 2013-10-19 05:58:26 <swulf--> yeah
 62 2013-10-19 05:58:37 <olalonde> interesting
 63 2013-10-19 05:58:56 <olalonde> would be curious to see what blockchain.info output would be for that eheh
 64 2013-10-19 05:59:41 <olalonde> actually was it included in the blockchain?
 65 2013-10-19 06:01:03 <swulf--> i'm not sure, I don't recall the specifics
 66 2013-10-19 06:04:28 <olalonde> http://villaggioinsicilia.com/wp-content/themes/twentytwelve/inc/commercial-bitcoin-mining/bitcoin-hash-collision.php
 67 2013-10-19 06:05:00 <olalonde> (warning: this page contains malware apparently)
 68 2013-10-19 06:05:18 <olalonde> probably a wallet stealing virus
 69 2013-10-19 06:07:56 <olalonde> lol , looks like the articles were generated with a markov chain
 70 2013-10-19 06:14:41 <swulf--> i've noticed about one of those on every page of google search results for certain bitcoin queries
 71 2013-10-19 06:25:03 <warren> hmm, does linearize.py work for anyone?
 72 2013-10-19 06:25:07 <warren>   File "/home/ltc08/bin/linearize.py", line 68, in getblock
 73 2013-10-19 06:25:09 <warren>     data = hexdata.decode('hex')
 74 2013-10-19 06:25:11 <warren> AttributeError: 'dict' object has no attribute 'decode'
 75 2013-10-19 06:47:27 <warren> https://github.com/bitcoin/bitcoin/issues/3112
 76 2013-10-19 07:34:39 <sipa> swulf--: there have been duplicate transactions with the same hash (those are not possible anymore)
 77 2013-10-19 07:34:53 <sipa> but not different transactions with the same hash
 78 2013-10-19 07:35:17 <sipa> sha256 doesn't have known collisions afaik
 79 2013-10-19 07:38:30 <gmaxwell> if you become aware of a sha256 collision you can recieve 0.15 + 0.1 + 0.1 BTC ( https://bitcointalk.org/index.php?topic=293382.0 )
 80 2013-10-19 08:58:18 <sipa> b.i uses uncompressed pubkeys by default?
 81 2013-10-19 09:01:42 <gmaxwell> Does it support compressed pubkeys at all?
 82 2013-10-19 09:09:38 <petertodd> It does, but it often avoids using them for backwards compatibility reasons.
 83 2013-10-19 09:09:44 <petertodd> probably mainly the iphone...
 84 2013-10-19 15:15:59 <skinnkavaj> New mixing service from blockchain.info creator? https://bitcointalk.org/index.php?topic=40264.msg3367854#msg3367854
 85 2013-10-19 15:16:11 <skinnkavaj> I am a bit confused because i thought blockchain.info survived on that mixing fee :P
 86 2013-10-19 15:17:12 <MagicalTux> anyone knows how one is supposed to get a block and all its detail with recent bitcoind? As I understand it you need to getblockhash/getblock/gettransaction, but gettransaction won't work with unrelated txs
 87 2013-10-19 15:17:32 <sipa> MagicalTux: you need -txindex enabled
 88 2013-10-19 15:17:40 <sipa> and use getrawtransaction
 89 2013-10-19 15:17:47 <sipa> gettransaction only queries the wallet, not the blockchain
 90 2013-10-19 15:19:12 <MagicalTux> sipa: tbqh we're still using the old getblock patch we kept porting to newer bitcoind
 91 2013-10-19 15:19:37 <MagicalTux> worked for us very good so far
 92 2013-10-19 15:20:09 <MagicalTux> (doing one query for each tx will require a lot of queries for large blocks, and has very poor performances)
 93 2013-10-19 15:20:23 <sipa> you can do them in batch, if you're using JSON 2
 94 2013-10-19 15:20:31 <sipa> but yes, there's extra overhead
 95 2013-10-19 15:20:46 <sipa> (send all getrawtransaction queries at once)
 96 2013-10-19 15:42:13 <catAcomb> Hi.
 97 2013-10-19 15:42:20 <catAcomb> Today I noticed that there is no "restore wallet" feature.
 98 2013-10-19 15:42:24 <catAcomb> This *ought* to be implemented.
 99 2013-10-19 15:42:38 <catAcomb> Or, if not, at least a menu item which opens the correct dir in Explorer (on Windows).
100 2013-10-19 15:42:44 <skinnkavaj> catAcomb: Restore wallet?
101 2013-10-19 15:42:48 <catAcomb> I had to hunt and search for the right dir to put the wallet in.
102 2013-10-19 15:42:55 <catAcomb> skinnkavaj: Yes. It allows easy backing up, but not restoring.
103 2013-10-19 17:46:56 <michagogo> cloud|catAcomb: so basically a button to rename wallet.dat to something else, copy a user-provided file to datadir/wallet.dat, and rescan?
104 2013-10-19 17:48:32 <catAcomb> michagogo|cloud: Yeah.
105 2013-10-19 17:48:50 <catAcomb> michagogo|cloud: But the simplest thing would simply be for the menu item to open %APPDATA%\bitcoin or whatever.
106 2013-10-19 17:49:13 <catAcomb> Perhaps with instructions popping up before: "I will now open the dir where you should copy your previously backed up wallet.dat."
107 2013-10-19 17:49:35 <catAcomb> I mean, what's the point of making backups if you can't put them back easily?
108 2013-10-19 17:49:43 <catAcomb> I had to ask/hunt for the location to put my stored wallet.dat.
109 2013-10-19 17:55:39 <Luke-Jr> michagogo|cloud: that exact procedure isn't safe.
110 2013-10-19 18:02:16 <michagogo> cloud|Luke-Jr: yeah, I figured it probably isn't -- didn't think it through at all
111 2013-10-19 18:03:14 <michagogo> cloud|catAcomb: the thing is that anything like this would need to be idiotproofed
112 2013-10-19 18:03:42 <catAcomb> Opening a dir is pretty damn safe and non-ambiguous.
113 2013-10-19 18:04:05 <Luke-Jr> "what's a dir?"
114 2013-10-19 18:05:30 <PK> Yea, why would I need to open a deer?
115 2013-10-19 18:21:45 <catAcomb> :S
116 2013-10-19 19:25:19 <darsie> hi
117 2013-10-19 19:26:12 <darsie> https://en.bitcoin.it/wiki/Private_key says: Nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 (b) is a valid private key.
118 2013-10-19 19:26:46 <darsie> Does that mean 1<key<0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 ?
119 2013-10-19 19:27:42 <darsie> So key must be at least 2 and smaller/not including 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 ?
120 2013-10-19 19:29:22 <swulf--> darsie: why?  specifically, why cna't a privkey = 0 ?
121 2013-10-19 19:29:29 <darsie> Also, "nearly every 256-bit number" ??? The vast majority of 256 bit numbers is larger than 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141.
122 2013-10-19 19:29:38 <darsie> dunno
123 2013-10-19 19:29:51 <darsie> Says so in the wiki.
124 2013-10-19 19:30:04 <CodeShark> the vast majority of 256 numbers are far smaller than that
125 2013-10-19 19:30:28 <darsie> CodeShark: sigh
126 2013-10-19 19:30:39 <darsie> ohh, right :)
127 2013-10-19 19:30:50 <darsie> The Fs aren't 0.
128 2013-10-19 19:31:15 <CodeShark> the public key is computed from the private key by K = k*G where k is the private key (a scalar), G is the generator of the elliptic curve (a point), and K is the public key (another point)
129 2013-10-19 19:31:56 <CodeShark> if k = 0, K will be the point at infinity
130 2013-10-19 19:32:33 <darsie> so k can be 1?
131 2013-10-19 19:32:52 <CodeShark> the mathematics seem to allow it - although the security is highly questionable :)
132 2013-10-19 19:33:12 <CodeShark> however, 0 is not allowed because the number must be invertible
133 2013-10-19 19:33:20 <darsie> Theoretically any valid key should have the same security.
134 2013-10-19 19:33:34 <CodeShark> not necessarily - small numbers can be brute-forced
135 2013-10-19 19:33:45 <darsie> so can big numbers.
136 2013-10-19 19:33:54 <CodeShark> yes, but small numbers are an obvious range to try
137 2013-10-19 19:33:56 <darsie> If you start near them.
138 2013-10-19 19:34:46 <darsie> By this logic, small numbers should be rejected. Then brute forcing would start at bigger numbers. These should be rejected,  too, etc. ;).
139 2013-10-19 19:35:04 <CodeShark> n = 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is the modulus of the curve - this means that n*G = G
140 2013-10-19 19:35:17 <CodeShark> err...
141 2013-10-19 19:35:22 <michagogo> cloud|like that poison puzzle from the princess bride
142 2013-10-19 19:35:24 <CodeShark> I mean n*G = point at infinity
143 2013-10-19 19:35:36 <CodeShark> n*G = 0*G
144 2013-10-19 19:35:44 <CodeShark> n acts like 0
145 2013-10-19 19:36:05 <CodeShark> numbers larger than n effectively act the same as the same number mod n
146 2013-10-19 19:36:12 <CodeShark> so for instance, n + 10 behaves exactly like 10
147 2013-10-19 19:36:21 <CodeShark> so numbers larger than n are really like small numbers
148 2013-10-19 19:36:31 <CodeShark> 0 and n cannot be used because they have no inverse
149 2013-10-19 19:36:31 <darsie> CodeShark: If you made a program that randomly generated private keys, would you reject small keys? Up to which size?
150 2013-10-19 19:37:04 <CodeShark> the probability of generating a small key is tiny
151 2013-10-19 19:37:05 <CodeShark> :)
152 2013-10-19 19:37:05 <michagogo> cloud|If you made a program that randomly generated keys, you'd never get 1
153 2013-10-19 19:37:25 <CodeShark> but you should still test these cases since the test is inexpensive
154 2013-10-19 19:37:31 <darsie> michagogo: 1 is a random number.
155 2013-10-19 19:37:44 <CodeShark> it's possible - just HIGHLY unlikely if you have a good rng
156 2013-10-19 19:37:57 <darsie> so, would you reject small keys?
157 2013-10-19 19:38:12 <michagogo> cloud|no
158 2013-10-19 19:38:16 <darsie> k
159 2013-10-19 19:38:59 <darsie> Is 1 a valid key?
160 2013-10-19 19:39:06 <CodeShark> it's the identity
161 2013-10-19 19:39:11 <darsie> means?
162 2013-10-19 19:39:24 <CodeShark> it results in trivial signing
163 2013-10-19 19:40:04 <darsie> k, so a signature would reveal the private key trivially?
164 2013-10-19 19:40:09 <CodeShark> yes
165 2013-10-19 19:40:25 <darsie> Then the first practically valid key is 2?
166 2013-10-19 19:41:04 <michagogo> cloud|.....
167 2013-10-19 19:41:27 <darsie> I need to know which random numbers to reject.
168 2013-10-19 19:41:32 <CodeShark> a private key of 1 means that the public key is the generator of the curve
169 2013-10-19 19:41:47 <CodeShark> since the generator of the curve is well-known, someone is apt to figure it out
170 2013-10-19 19:41:55 <darsie> I'm sorry I don't understand the ECDSA maths ...
171 2013-10-19 19:42:27 <darsie> Nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 is a valid private key.
172 2013-10-19 19:42:56 <michagogo> You don't need to reject any random numbers
173 2013-10-19 19:43:02 <darsie> So I reject 1 and anything from 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 ?
174 2013-10-19 19:43:24 <CodeShark> anything larger than n is effectively the same as that number minus n
175 2013-10-19 19:43:39 <CodeShark> 0 and n are mathematically impossible to use
176 2013-10-19 19:43:42 <michagogo> Oh, if you're SHA256ing, then just reject anything larger than 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141
177 2013-10-19 19:44:08 <michagogo> (you could wrap around, but then there's a bias towards lower numbers)
178 2013-10-19 19:44:10 <CodeShark> but yes, you probably want to reject the numbers over n rather than taking the mod in order to not skew the distribution
179 2013-10-19 19:44:14 <darsie> michagogo: Yes, I'm gonna sha256 a brain wallet passphrase.
180 2013-10-19 19:44:37 <michagogo> So yes -- just reject anything larger than that
181 2013-10-19 19:44:46 <darsie> And reject 0 and 1, too.
182 2013-10-19 19:45:08 <darsie> 2 would be ok?
183 2013-10-19 19:45:36 <CodeShark> I think we're more likely to get wiped out by a giant asteroid before you get 2 if you're using SHA256
184 2013-10-19 19:45:44 <michagogo> cloud|...I can guarantee you, you will not get 0, 1, or 2
185 2013-10-19 19:46:00 <darsie> michagogo: Thank you, dear god :)
186 2013-10-19 19:46:12 <darsie> michagogo|cloud*
187 2013-10-19 19:46:50 <michagogo> cloud|Also
188 2013-10-19 19:46:53 <michagogo> cloud|You will not get 0b411f74c43d6f68e6fed8cb0d8fd7935dabf1540ba587a96ca8dae66be11be3
189 2013-10-19 19:47:00 <darsie> ok :)
190 2013-10-19 19:47:07 <michagogo> cloud|nor c736d1ed93d9d236dd8c18f76a918915c54f77eeaf14b926a1ec69f737acfe80
191 2013-10-19 19:47:16 <michagogo> cloud|And also not 46f5610b3268dabe9696ab90fe344810c9e6851175eb7746bf82cac6daceac68
192 2013-10-19 19:47:41 <darsie> Wanna bet a few femtoBTC? :)
193 2013-10-19 19:48:35 <swulf--> why are 0 and n mathematically invalid to use?
194 2013-10-19 19:48:53 <swulf--> seems like G=n*G (mod ..something?..) could be true
195 2013-10-19 19:49:06 <swulf--> i'm guessing G is the generator for a field with n elements
196 2013-10-19 19:49:27 <CodeShark> correct, swulf
197 2013-10-19 19:49:54 <CodeShark> well, not a field
198 2013-10-19 19:49:58 <CodeShark> a group
199 2013-10-19 19:49:59 <swulf--> ring?
200 2013-10-19 19:50:01 <swulf--> ah, group
201 2013-10-19 19:50:16 <swulf--> if it were a field, there'd be the 0 element
202 2013-10-19 19:50:38 <swulf--> man, abstract algebra from 8 years ago is quite rusty...
203 2013-10-19 19:50:57 <CodeShark> the group members are points on the curve y^2 = x^3 + 7
204 2013-10-19 19:51:07 <darsie> I'm thinking of computing many sha256 recursively with filling like 1 GB RAM so smaller brainwallet passwords can be used. What you think about that?
205 2013-10-19 19:52:25 <CodeShark> given any two distinct points on that curve, the line containing them will intersect the curve at a third point with the exception of y1 = -y2, in which case we say the line intersects the curve "at infinity". given any single point on the curve, the tangent at that point will intersect the curve at exactly one point
206 2013-10-19 19:52:57 <CodeShark> this is how we define the group operation - and the "point at infinity" is the group identity element
207 2013-10-19 19:52:57 <swulf--> wow
208 2013-10-19 19:53:06 <swulf--> thats pretty damn intuitive
209 2013-10-19 19:54:42 <michagogo> cloud|darsie: That still doesn't help
210 2013-10-19 19:54:53 <michagogo> Because the source doesn't have mush entropy
211 2013-10-19 19:54:56 <michagogo> much*
212 2013-10-19 19:55:07 <darsie> michagogo|cloud: But it slows down bruteforcing.
213 2013-10-19 19:55:50 <olalonde> regarding transactions, how is it possible to verify a signature without the public key? if i understand correctly, addresses are hashes of the public key. is the public key included in the transaction?
214 2013-10-19 19:55:52 <michagogo> darsie: That's called "security through obscurity"
215 2013-10-19 19:55:58 <michagogo> olalonde: Yes, it is
216 2013-10-19 19:56:09 <olalonde> ah ok, thanks
217 2013-10-19 19:56:15 <darsie> Hmm, all possible private keys could eventually be computed ... if a small entropy password were used ...
218 2013-10-19 19:57:42 <swulf--> assuming repeated h(anything) was a generator for the entire domain
219 2013-10-19 19:58:12 <CodeShark> yes - the coordinates of the point's curves are over a prime field
220 2013-10-19 19:58:19 <olalonde> is there a web based tool that could let me inspect a raw transaction with labels? blockchain is great but it doesnt let me see the raw hexadecimal transaction
221 2013-10-19 19:58:22 <swulf--> in things like SHA256?
222 2013-10-19 19:58:38 <olalonde> and the wiki has some info but its not very detailed
223 2013-10-19 19:58:58 <CodeShark> if it were possible to prove that sha256 has a generator for the entire domain I think it would constitute a break in its security
224 2013-10-19 19:59:05 <swulf--> olalonde: actually been thinking of building a site that would do that
225 2013-10-19 19:59:38 <olalonde> swulf--: I will donate a bit if you pull it off :)
226 2013-10-19 19:59:41 <CodeShark> if you want to look at the raw transactions, you can always use bitcoind's decoderawtransaction
227 2013-10-19 19:59:56 <swulf--> code: why? i thought the point of the hash was that the inverse was hard to find
228 2013-10-19 20:00:25 <swulf--> I think it's not the decoding thats the problem, it's the retrieval of an arbitrary tx
229 2013-10-19 20:00:41 <CodeShark> you can do that if you enable tx indexing
230 2013-10-19 20:00:46 <CodeShark> with bitcoind
231 2013-10-19 20:00:49 <swulf--> getrawtransaction won't tell you the hex for just any tx
232 2013-10-19 20:00:56 <CodeShark> it will if you enable tx indexing
233 2013-10-19 20:00:58 <swulf--> ah, tx indexing
234 2013-10-19 20:02:20 <michagogo> [22:58:07] <olalonde> is there a web based tool that could let me inspect a raw transaction with labels? blockchain is great but it doesnt let me see the raw hexadecimal transaction
235 2013-10-19 20:02:20 <michagogo> What do you mean by labels?
236 2013-10-19 20:03:44 <olalonde> well , like what every portion of the transaction is for
237 2013-10-19 20:04:46 <olalonde> like byte X to Y is a signature, etc.
238 2013-10-19 20:05:21 <olalonde> there is some info at https://en.bitcoin.it/wiki/Transaction but it's not complete
239 2013-10-19 20:05:48 <CodeShark> it would be rather straightforward to write a web interface to bitcoind's decoderawtransaction
240 2013-10-19 20:06:15 <michagogo> olalonde: I think coinb.in has a decoder tool
241 2013-10-19 20:06:37 <olalonde> cool
242 2013-10-19 20:06:45 <michagogo> olalonde: Oh, also...
243 2013-10-19 20:06:48 <michagogo> https://en.bitcoin.it/wiki/Transaction is complete.
244 2013-10-19 20:07:06 <michagogo> A week or two ago, I dissected a raw transaction using only https://en.bitcoin.it/wiki/Transaction
245 2013-10-19 20:07:29 <CodeShark> I've manually dissected a few myself :p
246 2013-10-19 20:07:33 <michagogo> Oh, actually -- you also want https://en.bitcoin.it/wiki/Script
247 2013-10-19 20:08:52 <olalonde> yeah was going to ask about that actually
248 2013-10-19 20:09:07 <olalonde> Txin-script and Txout-script for a standard transaction
249 2013-10-19 20:09:32 <olalonde> txin would include your signature right?
250 2013-10-19 20:09:58 <michagogo> olalonde: https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29
251 2013-10-19 20:09:59 <olalonde> and Txout would include your address?
252 2013-10-19 20:10:13 <olalonde> thanks
253 2013-10-19 20:11:50 <olalonde> Txin basically solves the previous Txout
254 2013-10-19 20:11:58 <michagogo> Exactly.
255 2013-10-19 20:12:25 <olalonde> and Txout sets a new challenge to solve
256 2013-10-19 20:12:33 <michagogo> That's right :-)
257 2013-10-19 20:12:38 <olalonde> makes sense :)
258 2013-10-19 20:12:45 <michagogo> Basically, the txin script sets up the stack such that the txout script that it's spending will complete with a non-zero output
259 2013-10-19 20:12:59 <michagogo> erm, non-zero top item on the stack, that is
260 2013-10-19 20:13:22 <michagogo> note that that's 2 separate things
261 2013-10-19 20:13:30 <michagogo> 1. complete
262 2013-10-19 20:13:40 <michagogo> 2. do so with a non-zero top item on the stack
263 2013-10-19 20:14:41 <michagogo> (there are a few cases where the script is aborted and fails before executing the whole thing -- OP_RETURN, and OP_*VERIFY if whatever's being verified fails
264 2013-10-19 20:14:43 <michagogo> )
265 2013-10-19 20:26:03 <dansmithbtc2> HI, is there an easy-to-use tool to send messages (mempool, getdata) to nodes and parse responses?
266 2013-10-19 20:32:28 <CodeShark> dunno about easy-to-use, but this could be modified to do that: https://github.com/CodeShark/CoinClasses/blob/master/examples/ping/ping.cpp
267 2013-10-19 20:33:54 <gmaxwell> 0_o "Bitcoin's core code is written in Typescript, which is compiled into C++"
268 2013-10-19 20:34:07 <CodeShark> gmaxwell: who wrote that?
269 2013-10-19 20:40:59 <gmaxwell> This person, http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html
270 2013-10-19 20:43:39 <dansmithbtc2> Which message does a node send to broadcast their transaction. I'm looking at https://en.bitcoin.it/wiki/Protocol_specification. Is it inv ?
271 2013-10-19 20:44:17 <CodeShark> you can send an inv to alert other nodes that you have it - and you'd use a tx message to actually send it
272 2013-10-19 20:45:11 <gmaxwell> dansmithbtc2: inv offers it, other nodes request it if they don't know it already.
273 2013-10-19 20:45:56 <CodeShark> you send an inv, the other node sends a getdata, you send a tx
274 2013-10-19 20:46:28 <dansmithbtc2> CodeShark, gmaxwell, thanks all clear now
275 2013-10-19 20:49:55 <CodeShark> wondering whether it would make sense to support an ack message to verify the node accepted the transaction as valid and will relay it
276 2013-10-19 20:50:19 <CodeShark> could be useful when it comes to things like fee rules
277 2013-10-19 20:51:06 <CodeShark> or nonstandard transaction rules
278 2013-10-19 20:51:47 <gmaxwell> CodeShark: meh: increases traffic, nodes can lie, tells you nothing about behavior two hops away. The better alternative is to announce only to a small number of peers and see what shows up from your neighbors.
279 2013-10-19 20:51:59 <gmaxwell> Which apparently bitcoinj does (and we also do the fractional broadcast part at least)
280 2013-10-19 22:07:40 <Matt_von_Mises> Does anyone know why HMAC is used for the master key generation in BIP0032? https://en.bitcoin.it/wiki/BIP_0032#Master_key_generation
281 2013-10-19 22:44:13 <jegs> any way to configure the bitcoind server to allow queries about transactions and addresses not in the wallet on that server? i want to verify transactions and such without actually holding money on the server itself
282 2013-10-19 22:46:13 <Luke-Jr> jegs: getrawtransaction
283 2013-10-19 22:46:26 <jegs> Luke-Jr: thanks
284 2013-10-19 22:46:38 <sipa> darsie: keys are at least one, and at most that nukber minus one
285 2013-10-19 22:46:44 <Luke-Jr> jegs: you may need to enable -txindex depending on your use case
286 2013-10-19 22:46:53 <sipa> the largest valid private key in hex ends in4140
287 2013-10-19 22:47:05 <Luke-Jr> jegs: future versions will be adding support for watch-only wallets
288 2013-10-19 22:47:14 <Luke-Jr> jegs: ie, wallets without the ability to spend money
289 2013-10-19 22:47:17 <jegs> nice, thanks
290 2013-10-19 22:47:21 <jegs> yeah that's exactly what i want
291 2013-10-19 22:47:53 <jegs> is that coming around this year you think or no eta?
292 2013-10-19 22:47:57 <Luke-Jr> jegs: a workaround that can be done today, is to create a wallet with infinitely large keypool, make a copy, and encrypt the copy, and then throw away the passphrase
293 2013-10-19 22:48:10 <Luke-Jr> jegs: where infinitely large means "large enough you never use it up"
294 2013-10-19 22:49:03 <Luke-Jr> an encrypted wallet for which no passphrase is known, is effectively watch-only
295 2013-10-19 22:50:08 <olalonde> is ECDSA deterministic?
296 2013-10-19 22:50:14 <olalonde> for transaction signatures
297 2013-10-19 22:50:29 <Luke-Jr> olalonde: with some standards
298 2013-10-19 22:50:43 <Luke-Jr> olalonde: it is not probably deterministic without the private key, however
299 2013-10-19 22:50:43 <olalonde> the one used to sign transactions?
300 2013-10-19 22:51:01 <Luke-Jr> ie, only the person with the private key can prove he did it deterministically
301 2013-10-19 22:51:08 <olalonde> right
302 2013-10-19 22:51:14 <jegs> so an encrypted wallet means, a wallet with only the private keys encrypted?
303 2013-10-19 22:51:14 <sipa> michagogo|cloud: it's an existing construction for such purposes :)
304 2013-10-19 22:51:18 <Luke-Jr> jegs: yes
305 2013-10-19 22:51:31 <olalonde> well i guess my question is which one does bitcoin use?
306 2013-10-19 22:51:37 <olalonde> deterministic ECDSA?
307 2013-10-19 22:51:51 <Luke-Jr> olalonde: as only the private party can tell if it's deterministic, Bitcoin cannot enforce any specific behaviour
308 2013-10-19 22:52:17 <sipa> olalonde: bitcoind and bitcoin-qt do not create deterministic signature
309 2013-10-19 22:52:22 <olalonde> interesting
310 2013-10-19 22:52:23 <sipa> maybe in the near future they will
311 2013-10-19 22:52:31 <sipa> though as luke says, it cannot be enforced
312 2013-10-19 22:53:03 <olalonde> i've just read on wikipedia that ECDSA is vulnerable if the same k is used to sign 2 different messages
313 2013-10-19 22:53:09 <sipa> yes
314 2013-10-19 22:53:11 <jegs> can i run 'getnewaddress' on an encrypted wallet?
315 2013-10-19 22:53:16 <sipa> not an issue if you have a decent rng
316 2013-10-19 22:53:28 <Luke-Jr> olalonde: correct usage of Bitcoin never signs two different messages with the same ECDSA key
317 2013-10-19 22:53:32 <sipa> jegs: yes, it takes an address from its keypool
318 2013-10-19 22:53:34 <Luke-Jr> olalonde: so not really a problem in any case
319 2013-10-19 22:53:52 <jegs> sipa: well can the keypool be replenished without decrypting?
320 2013-10-19 22:53:55 <olalonde> mmm im  a bit confused
321 2013-10-19 22:54:01 <Luke-Jr> jegs: no, that's why you make it infinite ;)
322 2013-10-19 22:54:08 <jegs> ahh
323 2013-10-19 22:54:17 <olalonde> isn't the private key the ECDSA key?
324 2013-10-19 22:54:24 <sipa> yes
325 2013-10-19 22:54:32 <Luke-Jr> olalonde: the private key is used exactly once, when you spend the coin sent to an address
326 2013-10-19 22:54:38 <olalonde> so, the same key is used to sign multiple messages no?
327 2013-10-19 22:54:46 <Luke-Jr> no
328 2013-10-19 22:54:47 <olalonde> oh
329 2013-10-19 22:54:52 <Luke-Jr> since addresses are only used once
330 2013-10-19 22:54:58 <sipa> in correct usage, you never use the same address to receive multiple transactions
331 2013-10-19 22:55:06 <Polyatomic> how do you make the keypool infinite ?
332 2013-10-19 22:55:12 <Luke-Jr> Polyatomic: -keypool=10000000
333 2013-10-19 22:55:14 <Luke-Jr> :P
334 2013-10-19 22:55:15 <olalonde> I didn't get that
335 2013-10-19 22:55:20 <sipa> there are privacy and mild security advanyages to never reusing addresses
336 2013-10-19 22:56:48 <olalonde> so if you have 100 btc on one address and want to send 1 btc to another address, the remaining 99 will be sent to a new address that u control right?
337 2013-10-19 22:57:05 <olalonde> and the original private key will be useless?
338 2013-10-19 22:57:51 <jegs> Luke-Jr: so, let's say I generate this wallet with "infinite" keys, and copy it up to my public server. I'll encrypt it there and use a random and very long passphrase that I'll not record. The original copy on my offline machine will have access to those funds, correct? Sounds obvious just want to be 110% sure I understand.
339 2013-10-19 22:58:25 <Luke-Jr> jegs: I'd advise encrypting it BEFORE uploading
340 2013-10-19 22:58:38 <jegs> Luke-Jr: err, right :) good call
341 2013-10-19 22:58:40 <Luke-Jr> jegs: since the hard drive may have the pre-encrypted copy otherwise
342 2013-10-19 22:58:45 <jegs> indeed
343 2013-10-19 22:58:50 <jegs> lol
344 2013-10-19 22:58:50 <jegs> that's what I uh, meant to say
345 2013-10-19 22:58:54 <sipa> olalonde: not useless, but the reference client will not reuse it
346 2013-10-19 22:59:05 <sipa> olalonde: you can of course keep using it to receive coins
347 2013-10-19 22:59:06 <olalonde> ok
348 2013-10-19 22:59:12 <Luke-Jr> olalonde: right, although coins aren't stored "on addresses", just in a wallet with a given ECDSA private key
349 2013-10-19 22:59:19 <sipa> it's just compromising for your and other's privacy
350 2013-10-19 22:59:26 <Luke-Jr> olalonde: the address form is only used to specify the recipient
351 2013-10-19 22:59:50 <jegs> Luke-Jr: can you estimate the size of a wallet.dat that is encrypted and has 10M keys in it?
352 2013-10-19 22:59:53 <olalonde> well if u keep using the private key, u will be signing 2 ecdsa messages using the same key no?
353 2013-10-19 23:00:07 <sipa> jegs: more than 100k keys is painful
354 2013-10-19 23:00:25 <Luke-Jr> jegs: 10000 is 3 MB
355 2013-10-19 23:00:28 <sipa> olalonde: not the same
356 2013-10-19 23:00:39 <Luke-Jr> olalonde: you're not supposed to
357 2013-10-19 23:00:41 <sipa> oh, the same key yes
358 2013-10-19 23:00:47 <jegs> the entire wallet never has to be loaded into memory at once, correct/
359 2013-10-19 23:00:53 <Luke-Jr> jegs: it always must be
360 2013-10-19 23:00:54 <sipa> but that isn't a problem (though you still shouldnt)
361 2013-10-19 23:01:06 <Luke-Jr> jegs: at least, with the current implementation
362 2013-10-19 23:01:15 <jegs> so this makes a 10M key wallet a bit unfeasible for a small shop :p
363 2013-10-19 23:01:16 <Luke-Jr> it's a problem if your k is not random enough, or if quantum computers get created someday, etc
364 2013-10-19 23:01:21 <olalonde> sipa: yeah, i meant same key, not same message
365 2013-10-19 23:01:38 <olalonde> yeah, that's why I was asking about deterministic ECDSA Luke-Jr
366 2013-10-19 23:01:44 <sipa> jegs: the same of a wallet is mostly determined by the number of transactions, not keus
367 2013-10-19 23:01:49 <Luke-Jr> and even if neither of those are the case, it's still got less privacy than you'd expect from any kind of money store
368 2013-10-19 23:02:49 <sipa> olalonde: we may switch to determibistic signing at some point
369 2013-10-19 23:02:59 <sipa> currenrly with openssl it's a bit hars to do
370 2013-10-19 23:05:21 <jegs> with the advent of machines like http://en.wikipedia.org/wiki/D-Wave_Two is all encryption and everything that depends on it gone to shit?
371 2013-10-19 23:05:24 <olalonde> cool
372 2013-10-19 23:05:48 <sipa> jegs: d-wave is not a general purpose quantum computer
373 2013-10-19 23:06:03 <jegs> it only solves "discrete optimization" problems right?
374 2013-10-19 23:06:12 <sipa> it's computing tehnology based on quantum effects, but it's not a auqntum computer
375 2013-10-19 23:06:16 <jegs> but could they just as easily made it to crack keys?
376 2013-10-19 23:06:24 <sipa> no
377 2013-10-19 23:06:32 <sipa> well, i suppose it can
378 2013-10-19 23:06:47 <sipa> bit it doesn't have the superlinear speedup that quantum computing would bring
379 2013-10-19 23:07:24 <jegs> ok so "we're safe" for now lol
380 2013-10-19 23:07:32 <sipa> yes
381 2013-10-19 23:07:40 <sipa> i don't worry about QC
382 2013-10-19 23:07:55 <Luke-Jr> jegs: as long as you only use addresses once, you're pretty safe against QC in any case
383 2013-10-19 23:08:03 <sipa> by the time they can create 128-bit quantum computers, i'll start worrying
384 2013-10-19 23:08:13 <Luke-Jr> (assuming the QC is known and you stop sending bitcoins when they go online)
385 2013-10-19 23:08:16 <sipa> right now, afaik, the best is a 4-bit one
386 2013-10-19 23:08:35 <jegs> only a matter of time :/
387 2013-10-19 23:08:42 <sipa> i doubt that
388 2013-10-19 23:08:53 <jegs> you think there's physical limits to the number of bits?
389 2013-10-19 23:08:58 <Luke-Jr> qubits*
390 2013-10-19 23:09:06 <sipa> no, but i do think there are engineering limits to it
391 2013-10-19 23:09:21 <sipa> and that addig bits will probably become exponentially harder
392 2013-10-19 23:10:34 <MC1984_> maybe the topic needs a new section
393 2013-10-19 23:10:36 <jegs> just using my intuition and looking at the last 50 years of computing, it seems that whatever barriers there are now would be overcome
394 2013-10-19 23:10:39 <Luke-Jr> sipa: not when jorash finishes his QC simulator!11one <.<
395 2013-10-19 23:10:43 <MC1984_> "dont be scared of D-Wave"
396 2013-10-19 23:11:09 <sipa> haha
397 2013-10-19 23:11:21 <sipa> jegs: maybe
398 2013-10-19 23:11:26 <sipa> but we'll see it coming
399 2013-10-19 23:12:01 <MC1984_> what im scared of is that lots of qubits are possible but only ever under lab conditions
400 2013-10-19 23:12:10 <MC1984_> we are so buggered if thats the case
401 2013-10-19 23:12:34 <Luke-Jr> MC1984_: "lab conditions"?
402 2013-10-19 23:12:43 <Luke-Jr> I think you'd quickly see those conditions leave the lab.
403 2013-10-19 23:13:38 <MC1984_> like 0 kelvin and superconduction and shit?
404 2013-10-19 23:14:01 <MC1984_> cant just slap a waterblock on that bad boy
405 2013-10-19 23:14:12 <Luke-Jr> I think you'd quickly see those conditions leave the lab.
406 2013-10-19 23:14:32 <MC1984_> i dont know
407 2013-10-19 23:14:54 <MC1984_> even if we did, not on the scale a facility could manage
408 2013-10-19 23:15:16 <MC1984_> whereas you could break an average datacenter up and put it in peoples houses instead if you wanted to
409 2013-10-19 23:15:53 <Luke-Jr> normal computers used to take up entire rooms too
410 2013-10-19 23:16:46 <MC1984_> well
411 2013-10-19 23:17:13 <jegs> does bitcoin-qt run bitcoind? i want to interact with a wallet using both a GUI and api commands from the command line
412 2013-10-19 23:17:22 <MC1984_> i look forward to powering my new Quantumstar 3000 computer off the tabletop fusion torus i keep in the shed behind the house
413 2013-10-19 23:17:37 <Luke-Jr> jegs: more or less - use the -server option
414 2013-10-19 23:17:53 <Luke-Jr> jegs: they share the same codebase, and bitcoin-qt is always built with bitcoind's code embedded
415 2013-10-19 23:18:48 <jegs> i see, so if i run bitcoin-qt -server -data-dir=/whatever, i can then run 'bitcoind somecommand'?
416 2013-10-19 23:20:53 <sipa> yes
417 2013-10-19 23:20:57 <sipa> no need for the datadir
418 2013-10-19 23:21:03 <sipa> (it's without -)
419 2013-10-19 23:22:10 <jegs> i have non-standard location
420 2013-10-19 23:22:16 <jegs> i don't want it to startup and create a new one
421 2013-10-19 23:26:20 <sipa> right, sure
422 2013-10-19 23:26:40 <sipa> you may need to pass the datadir to bitcoind as well, if you want it to find your rpcpass automatically
423 2013-10-19 23:27:54 <jegs> yeah that's what i'm doing now
424 2013-10-19 23:28:22 <jegs> ok so it turns out i actualy need an API call that will let me list transactions for an address (not necessarily in my wallet)
425 2013-10-19 23:28:32 <jegs> i only see 'listtransactions' and that takes an account
426 2013-10-19 23:29:47 <sipa> you have lostreceivedbyaddress
427 2013-10-19 23:29:50 <jegs> i'm wondering how blockchain.info does it
428 2013-10-19 23:29:52 <sipa> *list
429 2013-10-19 23:29:59 <jegs> ok let me check that out
430 2013-10-19 23:30:00 <sipa> using a hige index
431 2013-10-19 23:30:04 <oleganza> hey! I wonder if anyone already proposed a way to avoid scanning/indexing UTXO: https://bitcointalk.org/index.php?topic=314467.msg3370937
432 2013-10-19 23:30:04 <sipa> huge
433 2013-10-19 23:30:46 <sipa> oleganza: huh, a full utxo database is 200 MB
434 2013-10-19 23:31:06 <jegs> sipa: listreceivedbyaddress still required that address to be in your wallet
435 2013-10-19 23:31:28 <sipa> yes of course
436 2013-10-19 23:31:31 <sipa> it's a wallet api
437 2013-10-19 23:31:35 <oleganza> really? I heard from some guy that their full UTXO index for all transactions (not only personal wallet ones) is 100 Gb.
438 2013-10-19 23:31:51 <sipa> they're using abe i guess :p
439 2013-10-19 23:31:52 <oleganza> maybe i misunderstood something
440 2013-10-19 23:32:07 <sipa> the reference client maintains an utxo set internally
441 2013-10-19 23:32:14 <sipa> in the chainstate directory
442 2013-10-19 23:32:31 <sipa> 254 MB now
443 2013-10-19 23:32:53 <oleganza> so why the hell people are so obsessed with UTXO growing?
444 2013-10-19 23:32:55 <MC1984_> oh no
445 2013-10-19 23:33:01 <sipa> indexing it by address would add a few hundred MB
446 2013-10-19 23:33:13 <sipa> oleganza: because it will, and every node needs fast access tovit
447 2013-10-19 23:33:31 <sipa> contrary to the blockchain
448 2013-10-19 23:33:43 <oleganza> okay, so what about this solution: no one needs to store full UTXO index. But senders send parent txs with their branches.
449 2013-10-19 23:33:44 <sipa> which is just lots of data, but all you need to do is read it in once
450 2013-10-19 23:33:55 <MC1984_> how fast is fast
451 2013-10-19 23:33:59 <oleganza> so every receiving node immediately can check if the parents are already validated
452 2013-10-19 23:34:05 <sipa> fast enough to validate blocks
453 2013-10-19 23:34:07 <oleganza> without indexing UTXO or scanning blockchain
454 2013-10-19 23:34:09 <MC1984_> what about an SSD?
455 2013-10-19 23:34:14 <sipa> oleganza: that is what the utxo set is for...
456 2013-10-19 23:34:26 <sipa> quickly knowing what is alreadyvalodated
457 2013-10-19 23:34:31 <sipa> already validating
458 2013-10-19 23:34:34 <jegs> listreceivedbyaddress gives me an error anyway: {"code"=>-1, "message"=>"value is type str, expected int"} shouldn't it expect a string which is the address?
459 2013-10-19 23:34:53 <jegs> ah nevermind i see it doesn't take arguments :p
460 2013-10-19 23:34:53 <sipa> check the documentation
461 2013-10-19 23:34:58 <jegs> or not the address
462 2013-10-19 23:35:35 <sipa> MC1984_: even disk is fast enough now, with some cache on top
463 2013-10-19 23:35:39 <jegs> sipa: are there any non-wallet apis?
464 2013-10-19 23:35:48 <sipa> MC1984_: by fast i just mean "readily available"
465 2013-10-19 23:36:21 <sipa> jegs: getrawtransaction can get you any transaction from the chain, if you enable -txindex
466 2013-10-19 23:36:34 <MC1984_> oh thats not so bad
467 2013-10-19 23:36:36 <sipa> (except the genesis tx, if you'd want to try that one)
468 2013-10-19 23:37:00 <sipa> MC1984_: it is bad with todays technology if the chainstate were hundred gb
469 2013-10-19 23:37:22 <MC1984_> well yes
470 2013-10-19 23:37:29 <jegs> sipa: yes i noticed that and it works nicely but i don't think i can use that to look up transactions by receiving address
471 2013-10-19 23:37:52 <MC1984_> it wouldnt have been bad ten years ago to have it 250mb
472 2013-10-19 23:37:58 <MC1984_> would*
473 2013-10-19 23:38:36 <sipa> jegs: no, that requires an additional multi-gb index, which isnt needed for normal operation
474 2013-10-19 23:39:04 <sipa> and the reference client doesn't have that
475 2013-10-19 23:39:19 <sipa> watch-only wallets are likely what you need, but not yet implemented
476 2013-10-19 23:39:29 <sipa> (well, not yet merged)
477 2013-10-19 23:40:18 <jegs> with the yet-to-be-merged watch-only wallets, i wouldn't have to create the massive keypool?
478 2013-10-19 23:40:34 <sipa> you can just add addresses to watch
479 2013-10-19 23:40:39 <jegs> oh nice
480 2013-10-19 23:40:42 <sipa> on the fly
481 2013-10-19 23:40:43 <jegs> can i just build it myself then?
482 2013-10-19 23:41:21 <jegs> you said it's not merged so i suppose i could build from a branch?
483 2013-10-19 23:41:40 <sipa> yes
484 2013-10-19 23:41:47 <sipa> tjere's a pullreq for it
485 2013-10-19 23:41:56 <sipa> but it's a development branch
486 2013-10-19 23:42:05 <sipa> i would advise against using it in production
487 2013-10-19 23:42:32 <gmaxwell> the final version of the watching support may also be interface incompatible with the current implementation.
488 2013-10-19 23:42:56 <jegs> well this is for a personal project
489 2013-10-19 23:43:02 <jegs> only gotta answer to myself
490 2013-10-19 23:43:06 <jegs> so i'm ok with that
491 2013-10-19 23:43:59 <jegs> i don't see the branch on https://github.com/bitcoin/bitcoin/branches is it still private?
492 2013-10-19 23:45:42 <sipa> you're not looking at pull requests
493 2013-10-19 23:45:46 <jegs> yeah sorry :p
494 2013-10-19 23:45:56 <sipa> branches is the branches of the master repository
495 2013-10-19 23:46:11 <sipa> pull requests live in other people's branches, they've only been requested to be merged
496 2013-10-19 23:46:21 <jegs> cool, i get it
497 2013-10-19 23:46:22 <sipa> https://github.com/bitcoin/bitcoin/pulls
498 2013-10-19 23:47:07 <jegs> there are a lot could you just give me the pr # ? :p
499 2013-10-19 23:47:18 <jegs> it seems you don't want me to be running this feature yet lol
500 2013-10-19 23:47:19 <sipa> 2861
501 2013-10-19 23:47:21 <jegs> thanks
502 2013-10-19 23:47:56 <jegs> what a nice smile you have sipa