1 2012-10-27 01:53:10 <amiller> jgarzik, regarding your analysis of the analysis of bitcoin, "seems likely to introduce statistically significant changes in the results."
2 2012-10-27 01:53:57 <amiller> that's a strong statement and i don't have the slightest idea how to fill in the gap, what do you mean by that?
3 2012-10-27 01:55:20 <amiller> do you mean that if we asked for mtgox's data we could contribute an analysis that contradicts their estimates?
4 2012-10-27 01:56:40 <gmaxwell> amiller: that seems really likely to me, even if thats not what Jeff was saying.
5 2012-10-27 01:57:58 <jgarzik> amiller: no I meant that underlying assumptions as stated were invalid, and the lack of analysis related to cold storage and web wallets seemed likely to materially impact results
6 2012-10-27 01:58:39 <gmaxwell> E.g. they would have assumed X btc of mtgox stored funds was inactive, MTGOX data _will_ show that some portion of that coin is actively moving between customers. This will change the results. 30 day mtgox volume is on the order of a million btc these days.
7 2012-10-27 01:59:19 <gmaxwell> (and thats just the exchange volume, no clue on the like currency customer to customer transfer volume)
8 2012-10-27 02:01:49 <amiller> can you elaborate on how an analysis of cold storage would change their results? besides that - web wallets seems like the most practical way to provide a compelling counter example, that would be a measure of the number of transactions conducted nominally in bitcoins, but using a separate transaction mechanism
9 2012-10-27 02:31:39 <kjj_> so... signrawtransaction won't work with multisig until pull #1818 is merged in?
10 2012-10-27 02:32:26 <gmaxwell> kjj_: it works with multisig, if you load the multisig scripts.
11 2012-10-27 02:32:53 <kjj_> where do you do that?
12 2012-10-27 02:32:55 <gmaxwell> I wrote up an example here, https://people.xiph.org/~greg/escrowexample.txt and you can see it working.
13 2012-10-27 02:34:35 <kjj_> I generated my keys offline
14 2012-10-27 02:34:41 <gmaxwell> Yea, so?
15 2012-10-27 02:34:47 <gmaxwell> As you should.
16 2012-10-27 02:35:27 <kjj_> so I did the addmultisigaddressm sent to it
17 2012-10-27 02:36:08 <kjj_> created the raw transaction, but when I sign it, nothing happens
18 2012-10-27 02:36:38 <gmaxwell> you need to have the inputs specified, and the multisign added on the signer too, I do have an offline example but it's not for a multisign:
19 2012-10-27 02:36:41 <gmaxwell> https://people.xiph.org/~greg/signdemo.txt
20 2012-10-27 02:39:23 <kjj_> I'm not sure that I'm following you here
21 2012-10-27 02:39:53 <kjj_> which step is different from the normal raw transaction process?
22 2012-10-27 02:40:45 <gmaxwell> the extra argument to the signature that provides the input being spent.
23 2012-10-27 02:41:25 <kjj_> ahh, ok, I think I see it
24 2012-10-27 02:45:52 <kjj_> no, that doesn't do it
25 2012-10-27 02:49:25 <gmaxwell> hm. I thought it could redeem the darn thing as long as you provided the inputs it needed to sign and had addmultisign it, I thought that aformentioned pull was only required when you didn't addmultisign. Perhaps I am mistaken.
26 2012-10-27 02:50:07 <gmaxwell> If so, if the offline node has a blockchain current enough to see the txn you're trying to spend's inputs you could just 'sendrawtransaction' it to import it. Then it would work like an online node.
27 2012-10-27 02:51:59 <kjj_> This is all on an online node
28 2012-10-27 02:52:21 <kjj_> except for the private keys, I'm just copying and pasting those on the command line
29 2012-10-27 02:52:44 <kjj_> when I do signrawtransaction, it returns the same string that I used for the input
30 2012-10-27 02:54:07 <gmaxwell> Yes, I understood that.
31 2012-10-27 02:54:29 <gmaxwell> It sounds like it's unable to construct the scriptsig because it can't figure out that it owns the input.
32 2012-10-27 02:55:15 <kjj_> odd that it can't figure that out, I created the address using addmultisigaddress
33 2012-10-27 02:55:28 <kjj_> and when I validate it, it shows ismine=true
34 2012-10-27 06:18:37 <Joric> What the hell is Devcoin (here https://bitcointalk.org/index.php?topic=118181) and why they are using the same address scheme?
35 2012-10-27 06:22:43 <Joric> looks like they are totally incompatible with the main blockchain despite similar looking addresses
36 2012-10-27 07:25:44 <ibno> why isn't data compressed when sent over the network?
37 2012-10-27 07:26:23 <ibno> wouldn't this create some improvements?
38 2012-10-27 07:28:59 <ibno> I mean, if I just compress my (not complete) blockchain it takes 1.8 G (bzip2) (1.9 with zip), and uncompressed it takes 2.6 G
39 2012-10-27 07:30:21 <bd_> when most of the data is pseudorandom keys and signatures, compression doesn't make much difference. on-disk, of course, there's index data and stuff too though
40 2012-10-27 07:33:12 <ibno> I understand that, but take the blockchain as an example
41 2012-10-27 08:04:33 <ibno> at least the blockchain torrent could use compression
42 2012-10-27 08:51:52 <robbak> As they are now allocating the blockchain file in chunks, mostof your 'compression' is probably the nulls at the end of the file. Bloclhain data should not compress
43 2012-10-27 08:55:16 <robbak> (then again, maybe not)
44 2012-10-27 08:57:27 <ibno> what nulls are these nulls?
45 2012-10-27 08:57:44 <ibno> I thought the blockchain file is just all the blocks concatenated
46 2012-10-27 08:58:30 <ibno> and 0xf9 0xbe 0xb4 0xd9 appended in the beginning of each block
47 2012-10-27 08:59:09 <robbak> I think I have got something wrong. But the bitcoin files were getting badly fragmented, so they are now allocated in larger chunks to prevent this.
48 2012-10-27 08:59:39 <robbak> However, I am wrong, in that the files do contain compressable data, probably indexes.
49 2012-10-27 09:00:42 <ibno> I'm talking about the blockchain files, like blk00001.dat
50 2012-10-27 09:01:03 <robbak> Whether it is a good idea to compress them is another matter. I'll leave that to those who actually made that decision.
51 2012-10-27 09:11:49 <ibno> I don't think the blockfiles contain any indexes
52 2012-10-27 09:12:41 <ibno> those are stored in blkindex.dat
53 2012-10-27 09:15:32 <sipa> the block files themselves are trivially compressible by 25% or so, simply by using a smarter serialization
54 2012-10-27 09:17:31 <sipa> blkindex.dat indeed contained the index, and that should be very compressible - it uses a very inefficient encoding
55 2012-10-27 09:17:59 <sipa> in 0.8, the block files are indeed allocated in chucks, but the format is the same because of backward compatibility
56 2012-10-27 09:19:07 <ibno> so the block files are basically just the blocks concatenated and 0xf9 0xbe 0xb4 0xd9 appended to each block?
57 2012-10-27 09:19:23 <sipa> prepended
58 2012-10-27 09:19:25 <ibno> and size of the block as a var_int
59 2012-10-27 09:19:35 <sipa> as a uint32, i think
60 2012-10-27 09:19:36 <ibno> yeah right, prepended
61 2012-10-27 09:20:02 <ibno> It can't be a uint32
62 2012-10-27 09:21:02 <sipa> why not?
63 2012-10-27 09:21:13 <ibno> I'm just doing a hexdump of the file
64 2012-10-27 09:21:36 <ibno> oh, I might be wrong
65 2012-10-27 09:21:52 <ibno> yeah, you are right
66 2012-10-27 09:22:00 <ibno> it's a uint32
67 2012-10-27 09:22:04 <kreal> the blockchain iphone wallet, does it not support &label in bitcoin uri?
68 2012-10-27 09:25:03 <robbak> Just for fun, I just compressed bootstrap.dat from bittorrent. 2.3 compressed to 1.7 - about 25%.
69 2012-10-27 09:25:13 <kreal> ;(
70 2012-10-27 09:26:16 <robbak> So, worth doing if it is simple, but not worth doing if it is a lot of work or difficult to maintain.
71 2012-10-27 09:29:49 <ibno> with the bittorrent file, it might take a couple of minutes to compress, but you get them back (and more) by downloading it faster.
72 2012-10-27 09:31:13 <MC1984> any way to store and use the chain in a compressed state
73 2012-10-27 09:31:27 <ibno> I don't think so
74 2012-10-27 09:31:28 <sipa> the 25% i referred to was just using a more compact representation on-disk -- it could be used in the blk000?.dat files as well without problems
75 2012-10-27 09:31:41 <MC1984> some sort of custom segmented compression shit.....?
76 2012-10-27 09:32:01 <robbak> Use a filesystem with a compression layer you can turn on?
77 2012-10-27 09:32:15 <sipa> any zip/bzip2/lzma/... could be done on top of that still
78 2012-10-27 09:32:17 <MC1984> oh yeah
79 2012-10-27 09:32:42 <MC1984> but vast majority dont use FS compression
80 2012-10-27 09:32:48 <MC1984> might be worth it for 25%
81 2012-10-27 09:33:01 <MC1984> spoken like a non-coder
82 2012-10-27 09:33:30 <robbak> Is it? Disk space is dirt cheap. Even SSD disk space is falling fast.
83 2012-10-27 09:33:57 <sipa> robbak: that's part of the reason for not changing the block format
84 2012-10-27 09:34:23 <robbak> )I don't think there are many devs active in -dev, or we'd all have been shot down mintues ago.
85 2012-10-27 09:34:49 <MC1984> greg will be along shortly to smash our dreams
86 2012-10-27 09:34:53 <sipa> robbak: i'm a core dev :)
87 2012-10-27 09:35:11 <robbak> I noticed :{
88 2012-10-27 09:36:35 <sipa> what does :{ mean?
89 2012-10-27 09:37:18 <robbak> wry smile?
90 2012-10-27 09:38:55 <sipa> ok
91 2012-10-27 10:25:13 <SomeoneWeird> anybody know of any disassemblers that support x64 elf apart from IDA?
92 2012-10-27 10:28:57 <wumpus> ...objdump -d?
93 2012-10-27 10:33:15 <SomeoneWeird> objdump: can't disassemble for architecture UNKNOWN!
94 2012-10-27 10:33:17 <SomeoneWeird> :c
95 2012-10-27 10:35:00 <sipa> you are talking about em64t/amd64/x86_64/x64, right?
96 2012-10-27 10:36:00 <SomeoneWeird> powerpc
97 2012-10-27 10:36:10 <SomeoneWeird> sorry, shoulda said that
98 2012-10-27 10:36:21 <SomeoneWeird> readelf can read it fine, but doesn't dissasemble (afaik)
99 2012-10-27 10:38:03 <wumpus> you need a ppc objdump
100 2012-10-27 10:38:19 <wumpus> ie, that comes with a cross compiler
101 2012-10-27 10:42:45 <SomeoneWeird> hm thanks that works
102 2012-10-27 10:59:57 <sipa> enmaku: are you the author of codinginmysleep.com 's articles?
103 2012-10-27 11:39:12 <MC1984> is atlas really gone?
104 2012-10-27 12:52:38 <dusty__> hello, I'm trying to get some testnet3 coins but I get an HTTPS error
105 2012-10-27 12:52:43 <dusty__> is it a known problem?
106 2012-10-27 12:52:53 <dusty__> also, can someone send me some test coin, please?
107 2012-10-27 12:53:30 <dusty__> mvFFPDNGMpXjrgWBG7cAq25rkcDhdXQFkq if someone is around
108 2012-10-27 13:45:14 <jgarzik> gmaxwell: testnet3 support added to picocoin last night
109 2012-10-27 13:45:27 <jgarzik> not that it does anything (yet)
110 2012-10-27 13:45:52 <jgarzik> ACTION just wrote the TCP network engine, up to the point where messages are verified as passing checksum
111 2012-10-27 13:46:01 <jgarzik> now it's time to communicate!
112 2012-10-27 14:37:51 <dusty__> jgarzik: do you have some spare testnet3 coins you can send me?
113 2012-10-27 14:38:01 <dusty__> the faucet is not working
114 2012-10-27 15:06:53 <gmaxwell> dusty__: address?
115 2012-10-27 15:22:37 <D34TH> dusty__, address?
116 2012-10-27 15:30:40 <D34TH> bluematt: you alive?
117 2012-10-27 15:34:13 <D34TH> bluematt: when you get a chance your jenkins mingw is missing windows.h thats why the mingw builds are failing
118 2012-10-27 15:46:23 <yellowhat> does anyone have a quick code example how to send a bitcoin uri intent on android? is it exactly like a regular url http:// except bitcoin: ?
119 2012-10-27 16:19:18 <dusty__> D34TH: mvFFPDNGMpXjrgWBG7cAq25rkcDhdXQFkq
120 2012-10-27 16:19:20 <dusty__> thanks!
121 2012-10-27 16:19:53 <D34TH> sent
122 2012-10-27 16:27:13 <dusty__> D34TH: mmm nothing yet
123 2012-10-27 16:27:33 <D34TH> Transaction ID: 1314b5898be983e8d8c6060edfd53545c6a9ef6cf8e2b44e65769caa06869e10
124 2012-10-27 16:27:47 <D34TH> Status: 1/unconfirmed, broadcast through 3 nodes
125 2012-10-27 16:28:36 <D34TH> try -addnode=178.33.28.54
126 2012-10-27 16:29:35 <gmaxwell> dusty__: what version of bitcoin are you running?
127 2012-10-27 16:30:52 <dusty__> 0.7.1
128 2012-10-27 16:31:45 <dusty__> bitcoin-qt -testnet -addnode=178.33.28.54 ?
129 2012-10-27 16:31:50 <D34TH> yup
130 2012-10-27 16:31:58 <dusty__> it gives me an error
131 2012-10-27 16:32:13 <dusty__> telling me the dir is locked etc (the client is running)
132 2012-10-27 16:32:15 <dusty__> ok
133 2012-10-27 16:32:20 <dusty__> transaction arrived :)
134 2012-10-27 16:32:26 <dusty__> 100 btc
135 2012-10-27 16:32:31 <dusty__> thanks very much
136 2012-10-27 16:42:10 <BlueMatt> D34TH: yes, that much I knew...as to how to fix it...I havent looked into it yet
137 2012-10-27 16:42:27 <D34TH> copying files from windows mingw?
138 2012-10-27 16:42:29 <D34TH> :D
139 2012-10-27 16:43:01 <sipa> well, how does the gitian setup get this windows.h file?
140 2012-10-27 16:43:06 <sipa> it must come from some package
141 2012-10-27 16:43:48 <BlueMatt> ye
142 2012-10-27 16:43:49 <BlueMatt> p
143 2012-10-27 16:47:23 <Luke-Jr> sipa: mingw :p
144 2012-10-27 16:50:49 <sipa> well why doesn't BitcoinPullTester have it then?
145 2012-10-27 16:52:53 <BlueMatt> it does...its just missing from the include path somehow
146 2012-10-27 16:53:32 <sipa> does it patch the makefile?
147 2012-10-27 16:53:40 <BlueMatt> ahh, heres why, your makefile is f'd up
148 2012-10-27 16:53:45 <BlueMatt> its using g++ for the mingw builds
149 2012-10-27 16:53:57 <BlueMatt> (not i586-mingw32msvc-g++)
150 2012-10-27 16:54:53 <BlueMatt> (in makefile.linux-mingw, at the least)
151 2012-10-27 16:55:38 <BlueMatt> oh, and the makefile should use && instead of ;, which is probably why it continues trying to build after leveldb build fails
152 2012-10-27 16:55:58 <BlueMatt> ACTION -> breakfast
153 2012-10-27 16:56:15 <sipa> you can probably try passing CXX=i586-mingw32msvc-g++ to make
154 2012-10-27 16:56:39 <sipa> still... why does it work in gitian then?
155 2012-10-27 17:13:38 <BlueMatt> sipa: I dont know why it works in gitian, but afaics CXX should fix it...re: specify CXX, the makefile.linux-mingw should probably set a default CXX and let the user override (somehow it currently doesnt...)
156 2012-10-27 17:14:17 <sipa> BlueMatt: feel free to send a pullreq
157 2012-10-27 17:14:39 <BlueMatt> will do (a bit later...)
158 2012-10-27 17:21:53 <ThomasV> there used to be a blockchain.info page where forked chains are visible. anyone knows its url?
159 2012-10-27 17:22:49 <sipa> http://blockchain.info/orphaned-blocks ?
160 2012-10-27 17:23:12 <ThomasV> sipa: yes, thanks!
161 2012-10-27 17:24:05 <Luke-Jr> BlueMatt: make defines CXX by default
162 2012-10-27 17:24:46 <sipa> leveldb's build_detect_platform sets it to g++ unless already defined
163 2012-10-27 17:24:56 <BlueMatt> Luke-Jr: is there a way to check if it was manually set or set automatically?
164 2012-10-27 17:25:42 <Luke-Jr> BlueMatt: not afaik
165 2012-10-27 17:25:49 <BlueMatt> well thats no fun...
166 2012-10-27 17:26:00 <Luke-Jr> you can change the default :P
167 2012-10-27 17:26:31 <BlueMatt> sipa: saw that, thats why Im wondering why gitian works
168 2012-10-27 17:55:18 <amiller> are block times guaranteed to be monotonic or anything?
169 2012-10-27 17:55:30 <amiller> i know there's like a two hour window that comes into play but i don't fully understand it
170 2012-10-27 17:55:38 <amiller> timestamps i mean
171 2012-10-27 17:56:51 <amiller> actually...
172 2012-10-27 17:57:09 <runeks> I need some testnet bitcoins to play around with. is there a kind soul somewhere, who's wealthy in BTC play-money, that will send me some at mkDcsGrcRZKqfLaCCbLPTZdtnv8hkYLnp7 ?
173 2012-10-27 17:57:13 <amiller> suppose we decided it would be an awesome idea to change the between blocks interval to 7 minutes instead of 10, but no one wanted to bother with a hardfork
174 2012-10-27 17:57:16 <BlueMatt> afaik the only requirement is that its past the median of last N blocks (and will only be accepted by a node if its not too far by 2 hours)
175 2012-10-27 17:57:25 <amiller> we could just create 'bitcoin time' and decouple the timestamps from the system clocks
176 2012-10-27 17:58:34 <maaku> amiller: block times are not monotonic
177 2012-10-27 17:58:36 <BlueMatt> there was an intent to add an ntp (or similar) client to bitcoin-qt
178 2012-10-27 17:58:43 <maaku> amiller: there are plenty of examples in the chain
179 2012-10-27 17:59:26 <BlueMatt> (plus we already keep track, fairly poorly, of offsets)
180 2012-10-27 18:00:11 <maaku> amiller: it would still be a hard-fork, potentially less disruptive to the ecosystem of bitcoin tools
181 2012-10-27 18:00:36 <maaku> s/potentially/although potentially/
182 2012-10-27 18:08:22 <maaku> BlueMatt Luke-Jr: if you're using GNU make, you could use some shell logic to set it: $(shell ??? )
183 2012-10-27 18:15:40 <runeks> when signing a newly created transaction, what exactly is signed? I understand that the scriptSig is removed, but what about the var_int that precedes the scriptSig, is that included in the hash that is signed?
184 2012-10-27 18:16:07 <sipa> that var_int is set to 0
185 2012-10-27 18:16:32 <runeks> sipa: ok
186 2012-10-27 18:16:54 <maaku> runeks: https://en.bitcoin.it/wiki/OP_CHECKSIG
187 2012-10-27 18:18:08 <runeks> maaku: I've read that, but i was unsure what exactly "empty script" meant, ie. if it included a zero-size var_int preceding it.
188 2012-10-27 18:18:23 <runeks> is there some easy way to verify that the hash I generate of an "scriptless" transaction is the correct one?
189 2012-10-27 18:19:03 <sipa> runeks: check script.cpp's SignatureHash function, it's more complicated
190 2012-10-27 18:19:07 <runeks> ie. some test transaction some place that I can hash a sign to see if I create the sign final signature and intermediate hash
191 2012-10-27 18:19:48 <sipa> all input scripts are set to [], except the that of the input being signed, which is set to the *output* script that is being consumed
192 2012-10-27 18:19:54 <runeks> sipa: uh oh. I was afraid you were going to point me to the official code :)
193 2012-10-27 18:20:59 <sipa> then there are some options to blank out some outputs, and a way to remove other inputs
194 2012-10-27 18:21:10 <Luke-Jr> maaku: huh? I don't see how $(shell ???) is of any use here?
195 2012-10-27 18:21:17 <runeks> sipa: so if I have a transaction with a single input, I would create a transaction where I would just replace the scriptSig in this transaction with the output that I want to redeem?
196 2012-10-27 18:21:29 <sipa> runeks: normally, yes
197 2012-10-27 18:21:52 <runeks> sipa: does that mean "assuming SIGHASH_ALL is used"?
198 2012-10-27 18:22:08 <maaku> Luke-Jr: i misunderstood
199 2012-10-27 18:22:08 <sipa> yes
200 2012-10-27 18:22:34 <runeks> sipa: cool. thanks!
201 2012-10-27 18:52:19 <runeks> so I think I've created a correct "scriptless" transaction. is there a way to verify that I've done it correctly? does anyone have an example transaction with an accompanying "scriptless" hash?
202 2012-10-27 18:54:02 <Luke-Jr> huh? no such thing..
203 2012-10-27 18:54:15 <graingert> runeks: do you mean p2sh?
204 2012-10-27 18:55:34 <sipa> "scriptless" is probably a confusing term; he's just referring to the modified transaction being signed
205 2012-10-27 19:09:40 <runeks> graingert: as sipa said, I'm just trying to assess whether I can create a valid transaction. I need to know if I calculate the correct hash that is to be signed when creating a new tx.
206 2012-10-27 19:09:58 <graingert> uhhh
207 2012-10-27 19:09:59 <graingert> no idea
208 2012-10-27 19:10:02 <graingert> ask Luke-Jr
209 2012-10-27 19:10:35 <Luke-Jr> y me?
210 2012-10-27 19:11:19 <runeks> I just mined 50 BTC on testnes. I guess I will try creating a valid tx and seeing if importrawtx accepts it.
211 2012-10-27 20:51:59 <bcb> is is possible serch the [comment] or [comment-to] colums from the sendtoaddress method in bitcoind?
212 2012-10-27 21:10:27 <runeks> how do I derive the private key from a "Compressed Testnet Private key"? what is a "compressed" private key even?
213 2012-10-27 21:11:11 <runeks> I'd like to just get the integer that is the private key from the output of the "dumpprivkey" command. but I can't figure out how to do it.
214 2012-10-27 21:11:54 <gmaxwell> compressed is just a flag on the private key that says the matching public key should be point compressed.
215 2012-10-27 21:12:04 <sipa> the format is: 0x80 + [32-byte secret parameter in BE] + ([0x01] if compressed, [] otherwise)
216 2012-10-27 21:12:18 <sipa> encoded in base58 with checksum
217 2012-10-27 21:13:50 <runeks> ok... so if strip the first byte and the last five bytes from the base58-decoded byte string, I get an uncompressed private key?
218 2012-10-27 21:14:15 <sipa> there is nothing compressed or uncompressed about the the private key
219 2012-10-27 21:14:17 <kjj_> public keys don't compress. the extra marker is the sign of the public key that was created with it
220 2012-10-27 21:14:18 <runeks> or, rather, just a private key (since they can't be compressed)
221 2012-10-27 21:14:22 <runeks> sipa: right
222 2012-10-27 21:14:35 <sipa> but yes, if you take those bytes, you get the secret parameter
223 2012-10-27 21:14:42 <runeks> super
224 2012-10-27 21:14:49 <gmaxwell> if you ignore the compressed flag you will generate the wrong public key / address for compressed ones however.
225 2012-10-27 21:15:43 <gmaxwell> (well technically the public key will be the right one but bitcoin doesn't know the compressed and non-compressed public keys are the same; and the address actually will be wrong)
226 2012-10-27 21:15:46 <runeks> gmaxwell: are compressed public keys the default in the client?
227 2012-10-27 21:15:48 <kjj_> I still think it is a funny quirk that a private key can correspond to several different public keys
228 2012-10-27 21:16:02 <sipa> kjj_: it doesn't
229 2012-10-27 21:16:08 <gmaxwell> runeks: yes, now.
230 2012-10-27 21:16:11 <sipa> kjj_: but it does correspond to several addresses :)
231 2012-10-27 21:16:19 <sipa> as addresses depend on how the public key is encoded
232 2012-10-27 21:16:20 <runeks> gmaxwell: any way to turn it off?
233 2012-10-27 21:16:56 <gmaxwell> runeks: Old wallets have it off, but you wouldn't want to turn it off... makes transactions a fair bit smaller to have use compressed addresses.
234 2012-10-27 21:17:04 <kjj_> sipa: sure it does. give me any 256 bit number and I can create two different addresses that both work with it
235 2012-10-27 21:17:09 <gmaxwell> runeks: you can use validateaddress to tell if an address in your own wallet is compressed or not.
236 2012-10-27 21:17:14 <runeks> gmaxwell: I mean, it makes sense, since we want as little data in the block chain as possible. but the script I'm writing sort of expects uncompressed pubkeys
237 2012-10-27 21:17:37 <sipa> kjj_: and as i said, with one secret parameter corresponds to several addresses
238 2012-10-27 21:18:05 <gmaxwell> runeks: then fix your script.
239 2012-10-27 21:18:09 <sipa> kjj_: but not to different public keys - but public keys have two encoded forms, and addresses depend on that
240 2012-10-27 21:18:11 <gmaxwell> :P
241 2012-10-27 21:18:13 <runeks> gmaxwell: right :)
242 2012-10-27 21:18:29 <gmaxwell> runeks: what language are you writing this in?
243 2012-10-27 21:18:34 <runeks> Python
244 2012-10-27 21:18:36 <sipa> gmaxwell: ultraprune compressed uncompressed public keys in the txouts, by the way
245 2012-10-27 21:18:47 <sipa> *compresses
246 2012-10-27 21:18:55 <kjj_> ok, you've split the hair finer than I did. two "public key representations", not two "public keys"
247 2012-10-27 21:18:56 <gmaxwell> sipa: I noticed.
248 2012-10-27 21:19:12 <sipa> kjj_: haha :)
249 2012-10-27 21:19:37 <sipa> well, i guess it's disputable anyway, as bitcoin always uses public keys in their encoded form
250 2012-10-27 21:20:23 <sipa> runeks: anyway, undocumented feature: if you start -updragewallet=40000 when a new wallet is created that does not do compressed pubkeys
251 2012-10-27 21:20:29 <sipa> *wuth
252 2012-10-27 21:20:31 <sipa> *wIth
253 2012-10-27 21:20:40 <gmaxwell> sipa: I wonder how much space the txout pubkey compression is doing for deepbit alone?
254 2012-10-27 21:20:57 <runeks> so a compressed public key is either 0x02 or 0x03 plus x-coordinate. does the first byte designate signedness of the y-coordinate?
255 2012-10-27 21:21:10 <sipa> runeks: the lowest order bit
256 2012-10-27 21:21:18 <sipa> (0x03 for odd, 0x02 for even)
257 2012-10-27 21:21:57 <sipa> gmaxwell: there are not many unspent txouts to 1Vaynert, i think
258 2012-10-27 21:22:11 <sipa> or are there?
259 2012-10-27 21:22:26 <gmaxwell> I dunno, there are some, he doesn't pay to a single chain of transactions.
260 2012-10-27 21:22:56 <sipa> 29 unspent txouts to 1VayNert, according to blockinfo
261 2012-10-27 21:23:53 <runeks> sipa: I never quite understood that. if the curve equation is y^2=... and y=sqrt(...) don't we need to know if the y-coordinate is positive and negative, and not even or odd?
262 2012-10-27 21:24:23 <runeks> 's/positive and negative/positive or negative'
263 2012-10-27 21:24:29 <sipa> runeks: it's in the field Zp, which has no signs
264 2012-10-27 21:24:52 <sipa> as -k and p-k are the same
265 2012-10-27 21:25:24 <sipa> you could aritifically divide it in and upper and a lower half, and assign signs to those
266 2012-10-27 21:25:31 <sipa> but checking one bit is easier :)
267 2012-10-27 21:25:45 <runeks> sipa: hmm. so what do we get from checking evenness instead?
268 2012-10-27 21:26:04 <sipa> the sign *ducks*
269 2012-10-27 21:26:22 <runeks> ducks?
270 2012-10-27 21:26:31 <sipa> because i've just told you there are no signs
271 2012-10-27 21:26:35 <kjj_> heh. this isn't regular math. sqrt() still gives two possible answers, but in this case, neither of them are negative
272 2012-10-27 21:26:37 <gmaxwell> runeks: it's accomplishing the same thing you expected, but in the context of the number field it's evenness not the sign you care about.
273 2012-10-27 21:27:04 <runeks> so does sqrt() yield two possibl answers. one being even and the other being odd?
274 2012-10-27 21:27:12 <sipa> anyway, k and p-k (aka -k) have a different evenness
275 2012-10-27 21:27:21 <gmaxwell> it's basically k or p-k and one is even and the other odd.
276 2012-10-27 21:27:30 <sipa> so if you're looking for the two "signs", one will be odd and one will be even
277 2012-10-27 21:27:33 <sipa> (since p is odd)
278 2012-10-27 21:27:42 <gmaxwell> (there aren't too many even primes)
279 2012-10-27 21:27:52 <sipa> there are two
280 2012-10-27 21:28:04 <runeks> not just one?
281 2012-10-27 21:28:09 <gmaxwell> I didn't any for a reason. :P
282 2012-10-27 21:28:13 <sipa> 2 and -2 *ducks again*
283 2012-10-27 21:28:18 <gmaxwell> hahah
284 2012-10-27 21:28:19 <bcb> is is possible search the [comment] or [comment-to] data colums created by the sendtoaddress method in bitcoind?
285 2012-10-27 21:28:23 <kjj_> sqrt() is still giving you two possible numbers that can be squared to give the input. there are actually more than 2, but the field wraps at N, so after the first two, they are all equivalent
286 2012-10-27 21:28:40 <gmaxwell> bcb: No search, er. are they shown on listtransactions? listtransactions | grep
287 2012-10-27 21:28:55 <bcb> thx
288 2012-10-27 21:29:31 <runeks> I think I get it now. if P=29 and k=14 then p-k=15 and k=14. just takes a little getting used to... all these prime fields and what not.
289 2012-10-27 21:30:11 <sipa> the prime fields are quite easy compared to the EC groups :
290 2012-10-27 21:31:37 <runeks> sipa: anyway. I just saw you previous comment. -updragewallet=40000 it is. my script is really just meant to demonstrate how to create a transaction and sign it. whether it uses compressed or non-compressed pubkeys isn't important.
291 2012-10-27 21:32:02 <gmaxwell> runeks: until someone uses your code and is going around telling people do downgrade their wallets to use it. :P
292 2012-10-27 21:32:46 <runeks> gmaxwell: well it's more theoretical. I'm just using Python to describe the theory.
293 2012-10-27 21:33:01 <sipa> well there are functioning wallets written in python...
294 2012-10-27 21:33:27 <kjj_> heh. while we are holding the remedial EC math class, I can make absolutely no sense of this EC multiplication implementation that I've been using.
295 2012-10-27 21:34:12 <sipa> there are two types of EC multiplication routines
296 2012-10-27 21:34:22 <sipa> those that are fast, and those that are readable :)
297 2012-10-27 21:34:52 <runeks> OpenSSL uses the former type
298 2012-10-27 21:34:57 <runeks> I can attest to that
299 2012-10-27 21:35:11 <kjj_> sadly, this one is not fast. I'm just missing the steps between the theoretical notion that you can do the multiplication, and seeing how it is done
300 2012-10-27 21:35:56 <sipa> you know this: http://en.wikipedia.org/wiki/Exponentiation_by_squaring ?
301 2012-10-27 21:36:24 <runeks> kjj_: have you taken a look at Lis' Python ECDSA script? that's pretty readable (fairly)
302 2012-10-27 21:36:39 <kjj_> ahh, that explains why doubling is so important
303 2012-10-27 21:37:04 <kjj_> I'm reading a PHP library. I can follow along with what it is doing, I just don't usually know WHY it is doing it
304 2012-10-27 21:38:39 <kjj_> I should probably sit down with pen and paper and do a contrived example
305 2012-10-27 21:39:56 <runeks> sipa: when starting bitcoin-qt with -updragewallet=40000 and creating a new address, I still get a private key that starts with "c" from running "dumpprivkey" (Wiki says that's "compressed")
306 2012-10-27 21:40:27 <sipa> runeks: did you start without a wallet?
307 2012-10-27 21:40:43 <runeks> no I already had one...
308 2012-10-27 21:40:58 <runeks> that I've painstakingly mined 100 BTC to :)
309 2012-10-27 21:41:00 <sipa> it's a non-documented feature for a reason: it can't downgrade wallets
310 2012-10-27 21:41:05 <runeks> oh
311 2012-10-27 21:41:17 <runeks> anyone have some testnet coins they're willing to send me?
312 2012-10-27 21:41:18 <sipa> it just limits the features for newly created ones
313 2012-10-27 21:41:34 <sipa> runeks: you can dump the address that has your coins, create a new wallet at version 40000, and import
314 2012-10-27 21:42:09 <sipa> doing so may upgrade the wallet, though, unsure
315 2012-10-27 21:42:45 <runeks> are any of you on testnet? I can send you the coins, upgrade my wallet, and you can send it back to an uncompressed wallet...
316 2012-10-27 21:43:03 <sipa> you can do that yourself
317 2012-10-27 21:43:43 <runeks> i'll try
318 2012-10-27 21:46:29 <runeks> still getting compressed keys :\\
319 2012-10-27 21:48:50 <sipa> it should say "Performing wallet upgrade to 40000" in debug.log
320 2012-10-27 21:49:13 <sipa> or "Allowing wallet upgrade to 40000"
321 2012-10-27 21:50:24 <sipa> ACTION zZzZ
322 2012-10-27 21:50:26 <runeks> "Performing wallet upgrade to 60000" it says
323 2012-10-27 21:51:43 <sipa> what's the exact command-line?
324 2012-10-27 21:52:05 <runeks> bitcoin-qt -updragewallet=40000
325 2012-10-27 21:52:20 <sipa> right, you copied my typo :)
326 2012-10-27 21:52:26 <sipa> -upgradewallet=40000 it should be
327 2012-10-27 21:52:28 <runeks> oh. i see now :)
328 2012-10-27 21:52:35 <sipa> i need sleep
329 2012-10-27 21:52:36 <sipa> bye
330 2012-10-27 21:52:45 <runeks> me too!
331 2012-10-27 21:52:55 <runeks> (apparently)
332 2012-10-27 21:55:16 <runeks> later!
333 2012-10-27 21:59:00 <gribble> 205307
334 2012-10-27 21:59:00 <sipa> ;;bc,blocks
335 2012-10-27 22:08:09 <kjj_> wait, why doesn't the WIF need to know if the pubkey was even or odd?
336 2012-10-27 22:08:39 <gmaxwell> WIF?
337 2012-10-27 22:09:06 <sipa> wallet import format; and it does need to know (and does know)
338 2012-10-27 22:10:05 <kjj_> it looks like it has to figure it out
339 2012-10-27 22:10:27 <sipa> there's a marker byte at the end for compressed ones
340 2012-10-27 22:11:14 <kjj_> right, but the WIF only knows compressed or not. it has to do the multiplication itself
341 2012-10-27 22:11:42 <sipa> yes, of course
342 2012-10-27 22:12:14 <sipa> well, not of course, but for reason of compactness the corresponding EC point is not encoded, as it can be reconstructed
343 2012-10-27 22:13:04 <kjj_> right, I get side-tracked soemtimes and forget that while the even/odd flag is needed to solve for Y from X, it isn't needed when starting from K
344 2012-10-27 22:15:03 <kjj_> as in, a given secret could correspond to either 0x02... or 0x03... , but not to both
345 2012-10-27 22:38:38 <helo> ACTION wonders if he should attempt createrawtransaction or bother with copying the blockchain
346 2012-10-27 22:44:57 <helo> anyone agree that it would be nice if, when one sends with an encrypted wallet, the password dialog has a drop-down for "show raw unsigned transaction"?
347 2012-10-27 22:58:13 <helo> createrawunsignedsendtoaddress is probably a little long
348 2012-10-27 23:02:31 <helo> would such a thing be a reasonable way to keep people from shooting themselves in the foot when creating raw transactions for offline signin?
349 2012-10-27 23:03:15 <helo> gmaxwell: any thoughts?
350 2012-10-27 23:05:07 <dparrish> what would be nice is for the bitcoind client to prompt for my wallet passphrase instead of requiring it on the commandline where it's visible to ps and my shell history :(
351 2012-10-27 23:06:16 <helo> you can probably use an rpc client that doesn' keep history
352 2012-10-27 23:06:40 <dparrish> shell history
353 2012-10-27 23:07:19 <gmaxwell> dparrish: https://bitcointalk.org/index.php?topic=54671.0
354 2012-10-27 23:07:32 <gmaxwell> (not that the cli rpc shim couldn't be made smarter...)
355 2012-10-27 23:08:00 <dparrish> gmaxwell: thanks... still shows up in ps though. Not that's there's *currently* anyone else using my machine (that i know of)..
356 2012-10-27 23:09:33 <gmaxwell> helo: I've thought about createrawsend ... meh. Maybe. I'd rather we think more about how to better support offline wallets in a less rocket science way but there are a bunch of things that have to happen.
357 2012-10-27 23:09:50 <gmaxwell> (e.g. we probably need multiple wallet and watch only wallet support first. :( )
358 2012-10-27 23:13:13 <gmaxwell> Perhaps someday we'll have a proper CLI interface. Maybe even a curses mode. :P
359 2012-10-27 23:13:23 <dparrish> ACTION grins in excitement
360 2012-10-27 23:14:02 <gmaxwell> the one we have right now has the strong point that it really is the ~simplest possible client to the RPC. If you know the CLI you know the API for rpc access.
361 2012-10-27 23:14:58 <gmaxwell> so there are probably 10x the number of people who could easily write some api using tool than there would be otherwise.