1 2011-12-17 00:01:20 <BlueMatt> TD[gone]: ping
  2 2011-12-17 00:05:36 <[Tycho]> As theymos said, "It could certainly be better than AES encryption if there was a script op that output a hash of the non-Script parts of transactions"
  3 2011-12-17 00:05:58 <[Tycho]> So I would like to use such OPs.
  4 2011-12-17 00:06:13 <[Tycho]> May be as "constants".
  5 2011-12-17 00:07:36 <BlueMatt> ok mobile internet sucks...
  6 2011-12-17 00:08:20 <[Tycho]> As theymos said, "It could certainly be better than AES encryption if there was a script op that output a hash of the non-Script parts of transactions"
  7 2011-12-17 00:10:53 <BlueMatt> heh, that would be useful
  8 2011-12-17 00:10:59 <[Tycho]> So I would like to use such OPs.
  9 2011-12-17 00:11:01 <[Tycho]> May be as "constants".
 10 2011-12-17 00:11:26 <BlueMatt> in any case, though many of the script ops allow cool stuff to be done, almost all of them have no practical real-world applications...
 11 2011-12-17 00:13:54 <[Tycho]> I like cool stuff.
 12 2011-12-17 00:15:12 <CIA-100> libbitcoin: genjix * rff1b96d2d4e5 / (5 files in 2 dirs): bdb size_t -> uint32_t for depth to be consistent. http://tinyurl.com/brmp3b5
 13 2011-12-17 00:15:14 <CIA-100> libbitcoin: genjix * r3f48a8dfc3a8 /src/blockchain/postgresql/pq_blockchain.cpp: Remove inlining for function which can exist across multiple TUs by means of a declaration alone. http://tinyurl.com/c4p733z
 14 2011-12-17 00:19:28 <luke-jr> [Tycho]: such things cannot be added without a blockchain fork
 15 2011-12-17 00:19:41 <luke-jr> [Tycho]: maybe make a wiki page of things to add when we do that
 16 2011-12-17 00:19:44 <[Tycho]> Why do you think so ?
 17 2011-12-17 00:27:57 <sipa> BlueMatt: pong?
 18 2011-12-17 00:28:15 <BlueMatt> sipa: see gribble
 19 2011-12-17 00:43:25 <[Tycho]> Sorry for asking again, but... what was wrong with Gavin's "hidden address" script ?
 20 2011-12-17 00:52:36 <[Tycho]> Oh, I remember, because of crippled OP_ADD again.
 21 2011-12-17 00:55:14 <[Tycho]> Another reason to fix it.
 22 2011-12-17 00:59:56 <eueueue> newbie question: bitcoin plataform could be used to serving aerial images like google satellite?
 23 2011-12-17 01:00:35 <eueueue> to a project like: http://www.openaerialmap.org/Main_Page
 24 2011-12-17 01:25:18 <CIA-100> libbitcoin: genjix * r08a32dda1b71 / (7 files in 4 dirs): cast_chunk is little endian encoding by default. http://tinyurl.com/6s5e3a6
 25 2011-12-17 01:25:19 <CIA-100> libbitcoin: genjix * r6edcee4e5df6 / (7 files in 4 dirs): Merge branch 'lil' http://tinyurl.com/7s26tjd
 26 2011-12-17 01:25:21 <CIA-100> libbitcoin: genjix * r8b2b6b8763f3 /development-makefile: Updated Dev Makefile unit tests for base58 and big-number http://tinyurl.com/6su62vy
 27 2011-12-17 01:30:30 <EvanR> help i need tech support
 28 2011-12-17 01:31:38 <EvanR> http://codepad.org/p42dnbyk
 29 2011-12-17 01:32:01 <EvanR> background, my computer froze up when it ran out of memory, hdd thrashing
 30 2011-12-17 01:32:12 <EvanR> had to kill bitcoin after it refused to close after about 3 hours of waiting
 31 2011-12-17 01:32:18 <EvanR> now i can restart bitcoin
 32 2011-12-17 01:32:20 <EvanR> cannot
 33 2011-12-17 01:32:57 <denisx> throw the db away but keep your wallet
 34 2011-12-17 01:32:59 <gmaxwell> make a backup copy of your .bitcoin directory. If you runout of room you can omit the blk0001.dat /blkindex.dat
 35 2011-12-17 01:33:14 <gmaxwell> after making a backup (especially of wallet.dat)
 36 2011-12-17 01:33:38 <gmaxwell> delete everything in the database subdirectory (all the .log files)
 37 2011-12-17 01:33:56 <gmaxwell> if that doesn't make it happy, delete everything except wallet.dat and bitcoin.conf (if you have one)
 38 2011-12-17 01:34:37 <gmaxwell> once you're up and happy again you can delete the backup I told you to make above (though you should make periodic backups of your wallet.dat file)
 39 2011-12-17 01:34:59 <EvanR> i have backups
 40 2011-12-17 01:35:11 <EvanR> im not sure if they are recent enough though
 41 2011-12-17 01:35:23 <EvanR> but i made a backup of this wallet after the fiasco
 42 2011-12-17 01:35:25 <gmaxwell> thats okay, its unlikely that you'll need them here.
 43 2011-12-17 01:35:51 <EvanR> alright carrying out surgery
 44 2011-12-17 01:35:58 <gmaxwell> to be maximally cautious you should backup more than just the wallet while doing a recovery. There can be wallet data in the database log files.
 45 2011-12-17 01:36:09 <EvanR> oh
 46 2011-12-17 01:36:15 <EvanR> good to know (tm)
 47 2011-12-17 01:37:08 <EvanR> cp is running, hope my hdd will survive
 48 2011-12-17 01:42:49 <EvanR> uh oh
 49 2011-12-17 01:42:52 <EvanR> cp: reading `.bitcoin/addr.dat': Input/output error
 50 2011-12-17 01:45:01 <EvanR> cp: reading `.bitcoin/database/log.0000000290': Input/output error
 51 2011-12-17 01:45:29 <gmaxwell> oh dear.
 52 2011-12-17 01:45:37 <gmaxwell> well. at least those files aren't terribly important.
 53 2011-12-17 01:46:04 <gmaxwell> get a copy of wallet.dat off that disk _now_ though. sounds like you may be suffering from a disk failure.
 54 2011-12-17 01:50:52 <EvanR> yeah
 55 2011-12-17 01:50:53 <EvanR> me too
 56 2011-12-17 01:50:59 <EvanR> i send a copy to gmail
 57 2011-12-17 01:51:09 <luke-jr> scary.
 58 2011-12-17 01:53:14 <EvanR> three log files total threw input output error
 59 2011-12-17 01:53:17 <EvanR> so far
 60 2011-12-17 02:41:19 <EvanR> well i finished the backup
 61 2011-12-17 02:41:38 <EvanR> now bitcoin is taking its sweet time booting up
 62 2011-12-17 02:41:52 <EvanR> no errors yet
 63 2011-12-17 03:02:13 <diki> EvanR:redownloading the chain?
 64 2011-12-17 03:02:16 <diki> that is boring
 65 2011-12-17 03:02:52 <EvanR> no
 66 2011-12-17 03:03:04 <EvanR> i have the block chain
 67 2011-12-17 03:03:08 <EvanR> i dont have a working hard disk
 68 2011-12-17 03:03:28 <diki> I havent fired up bitcoin in weeks
 69 2011-12-17 03:16:41 <CIA-100> libbitcoin: genjix * r42ff138a0d42 / (8 files in 4 dirs): cast_chunk is little endian encoding by default. http://tinyurl.com/6wrsxoj
 70 2011-12-17 03:16:45 <CIA-100> libbitcoin: genjix * r7457075ffa59 / (development-makefile tests/merkle.cpp): Updated Dev Makefile unit tests for base58 and big-number http://tinyurl.com/8xuhlo4
 71 2011-12-17 03:25:11 <CIA-100> libbitcoin: genjix * r0692a52c03a8 / (9 files in 5 dirs): cast_chunk is little endian encoding by default. http://tinyurl.com/77svx3s
 72 2011-12-17 03:25:12 <CIA-100> libbitcoin: genjix * r3d0465f57dbc / (development-makefile tests/merkle.cpp): Updated Dev Makefile unit tests for base58 and big-number http://tinyurl.com/7g7qjja
 73 2011-12-17 05:11:50 <onelineproof> anyone played with libdb? I'm trying to use it to read/write the wallet.dat, but I keep getting "undefined reference to `db_create'" on ubuntu
 74 2011-12-17 05:13:12 <Diablo-D3> learn how to link libraries, dude
 75 2011-12-17 05:13:49 <onelineproof> ya I used the "I" and "L" options together with -ldb
 76 2011-12-17 05:18:23 <Diablo-D3> onelineproof: are you sure you used the right ones, however?
 77 2011-12-17 05:20:15 <onelineproof> I downloaded the most recent libdb-5.2 from the oracle site, compiled it, and set the include and lib directories as options...so I don't know. I see similar problems on google, but no solution. Just thought maybe some people have this thing working here.
 78 2011-12-17 05:20:51 <Diablo-D3> woah woah woah
 79 2011-12-17 05:20:56 <Diablo-D3> onelineproof: dont use that libdb
 80 2011-12-17 05:20:59 <Diablo-D3> use 4.8
 81 2011-12-17 05:21:01 <onelineproof> I'm trying to make a qr coder eventually
 82 2011-12-17 05:21:13 <Diablo-D3> libdb upgrades databases one way, even when opened as read only
 83 2011-12-17 05:21:27 <Diablo-D3> so if you open it in 5.x, you wont be able to open it in 4.8 ever again
 84 2011-12-17 05:21:34 <Diablo-D3> which means it'll no longer work in bitcoin
 85 2011-12-17 05:22:00 <onelineproof> ok ill try 4.8...
 86 2011-12-17 05:29:33 <luke-jr> onelineproof: we already have a QR Coder
 87 2011-12-17 05:30:49 <onelineproof> I just want an easy way to export my private keys as qr codes offline, and also import them back into a wallet.dat
 88 2011-12-17 05:30:58 <luke-jr> oh, private keys
 89 2011-12-17 05:31:58 <onelineproof> i heard of a pywallet, but not sure if it's good, so ill see if I can do something easily with c
 90 2011-12-17 05:34:02 <luke-jr> I  use vanitygen
 91 2011-12-17 05:35:07 <onelineproof> is that the javascript one?
 92 2011-12-17 05:35:58 <gmaxwell> onelineproof: use google.
 93 2011-12-17 05:35:58 <onelineproof> o nevermind, something else
 94 2011-12-17 05:38:28 <onelineproof> i may try it but I think it's good to understand how it works, when theres potentially lots of money on the line.
 95 2011-12-17 05:44:46 <luke-jr> practice.
 96 2011-12-17 05:44:50 <luke-jr> use 0.01 BTC or testnet
 97 2011-12-17 08:23:02 <onelineproof> So I got the libdb working. I'm printing out the key, data pairs from the database, and it's mostly giberrish. Sometimes I see addresses as the part of the keys. But is there any specification that someone can direct me to?
 98 2011-12-17 08:26:55 <PK> I can't compile bitcoind because of: net.cpp:1476: error: 'INT64_MIN' was not declared in this scope
 99 2011-12-17 08:29:16 <PK> I have errors about missing INT64_MAX and UINT64_MAX too. I compile it on 32bit linux
100 2011-12-17 08:30:32 <cjdelisle> perhaps try adding
101 2011-12-17 08:30:38 <cjdelisle> #include <stdint.h>
102 2011-12-17 08:30:42 <cjdelisle> to the top of net.cpp
103 2011-12-17 08:30:48 <cjdelisle> but it's a longshot...
104 2011-12-17 08:43:16 <PK> cjdelisle: I tried that but it didn't help it :(
105 2011-12-17 09:20:22 <PK> bitcoin 4.0 compiles fine and it uses INT64_MIN too
106 2011-12-17 09:38:17 <sipa> onelineproof: what do you need to know?
107 2011-12-17 09:38:56 <sipa> both keys and values are serialized data structures from the bitcoin program
108 2011-12-17 09:39:12 <sipa> looking in db.cpp in LoadWallet() will probably tell you a lot
109 2011-12-17 10:24:05 <sausage2> Hi. Why does the new version of bitcoin want to change something in my windows registry: /controlset001/services/BITS ?
110 2011-12-17 13:30:25 <sacarlson> so what have I missed?
111 2011-12-17 14:18:40 <sausage2> zone-alarm: "bitcoin-qt-somethigsneomtom.exe" wants to access/edit/write/something a registery entry: /that which I said/
112 2011-12-17 15:36:39 <jrmithdobbs> luke-jr: serious (derogatory) question
113 2011-12-17 15:36:51 <jrmithdobbs> luke-jr: what the hell are you smoking thinking pubkeys would fit better into qr codes than addresses?
114 2011-12-17 16:15:38 <sausage2> does anyone want a bit of fish?
115 2011-12-17 16:16:24 <Mqrius> No thanks.
116 2011-12-17 16:34:18 <sausage2> So... are you single?
117 2011-12-17 16:36:37 <Mqrius> Nope.
118 2011-12-17 16:36:46 <Mqrius> Not sure how that's related though
119 2011-12-17 16:49:06 <sausage2> I'm a sausage.
120 2011-12-17 16:49:14 <sausage2> And you're not.
121 2011-12-17 16:49:32 <Mqrius> Quite the marmelade, eh chap?
122 2011-12-17 16:52:08 <sausage2> yes :)
123 2011-12-17 16:55:15 <Mqrius> It pains me to say I am summoned to depart this pear-factory post-haste.
124 2011-12-17 16:55:54 <Mqrius> Thanks for the blue ribbon!
125 2011-12-17 16:55:54 <rjk2> haste makes waste
126 2011-12-17 17:37:34 <luke-jr> jrmithdobbs: get a clue
127 2011-12-17 17:38:03 <copumpkin> lol
128 2011-12-17 18:43:48 <sipa> jrmithdobbs: obviously an address takes less space than a full pubkey, but in a QR code is more than enough space for full pubkeys
129 2011-12-17 18:45:12 <luke-jr> sipa: overall, an pubkey-hash address takes more space than a full pubkey
130 2011-12-17 18:45:37 <sipa> because of base58 encoding, you mean?
131 2011-12-17 18:46:27 <luke-jr> no
132 2011-12-17 18:46:43 <sipa> pubkeys are 33 or 65 bytes
133 2011-12-17 18:46:52 <sipa> pubkey hashes are 20+1 bytes
134 2011-12-17 18:47:00 <luke-jr> because a pubkeyhash address adds to the block chain: hash, pubkey, signature
135 2011-12-17 18:47:06 <luke-jr> a pubkey adds: pubkey, signature
136 2011-12-17 18:47:10 <sipa> oh in the blockchain
137 2011-12-17 18:47:12 <sipa> yes of course
138 2011-12-17 18:47:18 <sipa> that's why you'd want to use a pubkey
139 2011-12-17 18:48:27 <sipa> using key recovery, that wouldn't necessarily be the case
140 2011-12-17 18:48:42 <sipa> but the current script language doesn't allow that
141 2011-12-17 18:48:58 <luke-jr> key recovery is a Bitcoin 2.0 feature ;)
142 2011-12-17 18:49:16 <sipa> yeah :p
143 2011-12-17 18:49:17 <luke-jr> pubkeys are 33 or 65, not 33 to 65, right?
144 2011-12-17 18:49:23 <sipa> or, indeed
145 2011-12-17 18:49:54 <sipa> 512 or 257 bits, actually
146 2011-12-17 18:50:06 <sipa> without the marker byte
147 2011-12-17 18:50:19 <luke-jr> o.o
148 2011-12-17 18:53:36 <luke-jr> sipa: is the base58 prefix '4' taken?
149 2011-12-17 18:54:06 <sipa> not used so far, afaik
150 2011-12-17 18:55:51 <luke-jr> I propose version 118 then
151 2011-12-17 18:56:05 <sipa> for?
152 2011-12-17 18:56:11 <luke-jr> for public keys
153 2011-12-17 18:56:12 <luke-jr> starts with '4' at length 33 and 65
154 2011-12-17 18:56:50 <luke-jr> actually, 116 would be slightly better
155 2011-12-17 18:56:59 <luke-jr> 116 also starts with '4'
156 2011-12-17 18:57:16 <luke-jr> but unlikely to ever be needed for 20-byte data
157 2011-12-17 19:14:09 <luke-jr> oops
158 2011-12-17 19:14:12 <luke-jr> figured that wrong
159 2011-12-17 19:40:33 <md2k7> can someone point me to an URL (or give me some search terms) on bitcoin addresses starting with a 3?
160 2011-12-17 19:41:00 <md2k7> (https://en.bitcoin.it/wiki/Address says they can start with 1 or 3)
161 2011-12-17 19:42:30 <Apexseals> yeah
162 2011-12-17 19:42:33 <Apexseals> still happening
163 2011-12-17 19:42:35 <Apexseals> my 5850 wont clock up
164 2011-12-17 19:43:15 <sipa> md2k7: OP_EVAL addresses may start with a '3'
165 2011-12-17 19:43:20 <sipa> but they aren't in use yet
166 2011-12-17 19:44:42 <md2k7> sipa: I see, thanks
167 2011-12-17 20:33:13 <onelineproof> Ill ask again: Is there more info on the encoding format / specification of wallet.dat? I'm using libdb to iterate through the database, but most of it doesn't print out in readable format.
168 2011-12-17 20:34:52 <gmaxwell> onelineproof: look at the source of bitcoin or the python wallet tools.
169 2011-12-17 20:35:10 <gmaxwell> There isn't much of anything 'printable' because there isn't much human-readable data in it.
170 2011-12-17 20:35:31 <onelineproof> I just want the private keys associated to each address. I can see the addresses.
171 2011-12-17 20:36:10 <onelineproof> I don't care about other things like transaction history
172 2011-12-17 20:37:01 <rjk2> pywallet does that right
173 2011-12-17 20:37:11 <onelineproof> But if it comes down to it, sure I can look at the source code
174 2011-12-17 20:37:26 <gmaxwell> if thats all you want just use https://github.com/gavinandresen/bitcointools to dump it.
175 2011-12-17 20:45:02 <luke-jr> sipa: any reason not to require pubkey addresses to be compact?
176 2011-12-17 20:45:07 <luke-jr> ie, forbid 65 bytes
177 2011-12-17 21:34:28 <Eliel> luke-jr: no need to require public key addresses to be compact, just require more fee to relay transactions with long ones :P
178 2011-12-17 21:34:50 <luke-jr> Eliel: the purpose of that was to ensure they begin with '4' ;)
179 2011-12-17 21:36:52 <Eliel> ... I don't think I'm awake enough to get this :)
180 2011-12-17 21:37:12 <luke-jr> Eliel: the only way to get a fixed base58 starting character, is for fixed-width data
181 2011-12-17 21:37:34 <Eliel> ah, makes sense now
182 2011-12-17 21:39:41 <Eliel> I see absolutely no reason to have non-compact pubkeys used in addresses. You can always calculate the full pubkey from it anyway.
183 2011-12-17 21:44:23 <sipa> onelineproof: keys and values are both serialized data structures from the bitcoin program
184 2011-12-17 21:44:32 <sipa> onelineproof: look in db.cpp at LoadWallet
185 2011-12-17 21:45:09 <sipa> there are ('key' + pubkey) keys whose values are OpenSSL serialized private keys
186 2011-12-17 21:45:45 <sipa> luke-jr: i hope we can move to compressed pubkeys soon
187 2011-12-17 21:46:27 <sipa> i don't think they're remain any reason to use non-compressed ones, except for spending outputs that spend to a hash of an uncompressed one of course
188 2011-12-17 21:46:39 <sipa> except maybe legal issues...
189 2011-12-17 21:48:05 <sipa> s/they're/there will/
190 2011-12-17 21:51:18 <gmaxwell> Why would you want to use pubkey addresses?
191 2011-12-17 21:51:39 <luke-jr> gmaxwell: to save block chain space, when long addresses aren't a problem
192 2011-12-17 21:51:44 <luke-jr> ie, QR codes
193 2011-12-17 21:51:52 <gmaxwell> sipa: sadly I don't know of any good early citations for the point compressed form even though its pretty trivial.
194 2011-12-17 21:52:39 <gmaxwell> luke-jr: the input scripts are super prunable, space in input scripts isn't so exciting... and they aren't smaller in output scripts which matter more.
195 2011-12-17 21:53:13 <sipa> gmaxwell: read this: http://cr.yp.to/patents/us/6141420.html
196 2011-12-17 21:53:21 <gmaxwell> They also have different security properties: if people start to become able to break ecdsa they can't even begin to attack a never-spent-from-address.
197 2011-12-17 21:53:27 <luke-jr> gmaxwell: they're not?
198 2011-12-17 21:53:58 <sipa> gmaxwell: but pruning isn't available right now, and it's not entirely clear to me how it will become available
199 2011-12-17 21:54:02 <gmaxwell> sipa: (dunno if you know about it but the classic reference for safe ecc is  https://tools.ietf.org/html/rfc6090 )
200 2011-12-17 21:54:32 <gmaxwell> sipa: then we should be pushing for key recovery, which is smaller than payments to pubkeys.
201 2011-12-17 21:55:18 <gmaxwell> luke-jr: pay to pubkey is only smaller if you consider output+input equally, and only smaller if the input can't use key recovery.
202 2011-12-17 21:56:16 <gmaxwell> The argument against doing key recovery w/ op-eval was IIRC that the input script size didn't really matter that much because of its superprunablity.
203 2011-12-17 21:56:20 <sipa> still, using a pubkey's hash instead of the full key when you have it anyway, seems wasteful to me
204 2011-12-17 21:56:46 <luke-jr> the only reason not to do key recovery, is if it breaks compatibility
205 2011-12-17 21:57:09 <gmaxwell> sipa: it conceals the pubkey, which slows down attacking it. ::shrugs:: I don't know if anyone really cares.
206 2011-12-17 21:57:24 <gmaxwell> It could be done without breaking compatiblity by using it inside op-eval.
207 2011-12-17 21:57:28 <sipa> i know, that is an advantage, but not one we should depend on
208 2011-12-17 21:57:42 <sipa> if ECDSA is broken, bitcoin should be considered broken
209 2011-12-17 21:57:49 <gmaxwell> sipa: not depend on, sure. Not have? ::shrugs::
210 2011-12-17 21:58:34 <gmaxwell> Of course ECDSA probably doesn't go from unbroken to broken over night. I can break RSA512 but it takes me a day (or two, longer if you don't let me use EC2 :) )).
211 2011-12-17 21:58:45 <sipa> haha
212 2011-12-17 21:59:47 <gmaxwell> (well, not just can, I _have_ in two days using about 160 bucks of ec2 time back before they got the cheaper spot pricing, </tangent>)
213 2011-12-17 22:00:18 <gmaxwell> sipa: in any case, really if you care about input script size key recovery is much better than send to pubkey.
214 2011-12-17 22:00:28 <sipa> of course it is
215 2011-12-17 22:01:14 <sipa> but send-to-base58-string-representing-a-full-pubkey is almost trivial to implement right now
216 2011-12-17 22:01:24 <sipa> while rolling out a new script language takes time
217 2011-12-17 22:02:18 <gmaxwell> Rolling out client that can pay to that also takes time. ::shrugs:: and we're going to end up with more fatter never-in-all-history-prunable outputs. ::shrugs:: I'm not impressed.
218 2011-12-17 22:03:38 <sipa> hmm, true, didn't consider that
219 2011-12-17 22:04:07 <gmaxwell> The size difference between normal and send to pubkey isn't all that great either. If all txn became that tomorrow, how much could we expect to save in the  say  year it took to roll out support for op_eval+key_recovery? And of course the vast majority wouldn't be switched even in a year.
220 2011-12-17 22:04:52 <luke-jr> gmaxwell: the goal right now is to ONLY add support for paying to it
221 2011-12-17 22:05:20 <luke-jr> gmaxwell: the receiving end can be done later
222 2011-12-17 22:05:36 <sipa> somehow i still consider pruning a theoretical thing, and all data in the block chain semi-permanent
223 2011-12-17 22:07:27 <sipa> that's far from optimal, but if nodes that prune are not able to function as full nodes anymore (as they can't give a cryptographic proof that a missing input was in fact already redeemed), i don't see it becoming supporting quickly
224 2011-12-17 22:10:20 <sipa> luke-jr: but if you can't assume your payer's software supports the address format, it's quite useless too
225 2011-12-17 22:10:22 <CIA-100> libbitcoin: genjix * rb5c8c6e74991 /src/blockchain/ (6 files in 2 dirs): bdb: Ability to reorganise. http://tinyurl.com/ctycz8o
226 2011-12-17 22:10:52 <sipa> so it's true that rolling out support for send-to-pubkey-addresses takes time as well
227 2011-12-17 22:23:13 <luke-jr> sipa: that's why we should add it now, so in 2013 we can start using it
228 2011-12-17 22:23:31 <luke-jr> the paying side, not the receiving side
229 2011-12-17 22:23:46 <sipa> the receiving side already exists...
230 2011-12-17 22:26:47 <luke-jr> sipa: not for compact sigs
231 2011-12-17 22:26:57 <luke-jr> sipa: and not generating addresses
232 2011-12-17 22:27:20 <sipa> oh, you were talking about compact sigs, not pay-to-pubkey?
233 2011-12-17 22:29:23 <luke-jr> pay-to-pubkey's receving end only needs compact afaik
234 2011-12-17 22:30:43 <sipa> there are three separate possible improvements: compressed pubkeys, compact signature, and key recovery
235 2011-12-17 22:30:49 <sipa> which are you talking about?
236 2011-12-17 22:33:16 <gmaxwell> certantly pay to compressed pubkey doesn't make any sense. It doesn't have any grand theoretical legal improvement, it requires upgraded software to accept and it produces larger transactions than key recovery.
237 2011-12-17 22:40:15 <luke-jr> sipa: compressed pubkeys I guess
238 2011-12-17 22:40:27 <luke-jr> sipa: and how it relates to pubkey addresses
239 2011-12-17 22:40:46 <luke-jr> gmaxwell: except key recovery is impossible
240 2011-12-17 22:40:57 <luke-jr> unless OP_EVAL enables it
241 2011-12-17 22:41:12 <sipa> it won't, but OP_EVAL2 may ;)
242 2011-12-17 22:41:41 <luke-jr> if it can, why not?
243 2011-12-17 22:41:57 <luke-jr> in any case, pubkey addresses CAN be done
244 2011-12-17 22:42:22 <sipa> luke-jr: compressed pubkeys doesn't require any change at all beyond pull #649
245 2011-12-17 22:43:51 <luke-jr> sipa: great
246 2011-12-17 22:44:11 <luke-jr> sipa: in any case, that's unrelated to SENDING TO them :P
247 2011-12-17 22:44:24 <luke-jr> ie, without a hash
248 2011-12-17 22:44:33 <sipa> right
249 2011-12-17 22:45:01 <sipa> gmaxwell has a point though, that if we want to roll out something, key recovery is a better bet than send-to-pubkey
250 2011-12-17 22:45:59 <sipa> send-to-pubkey is a lot easier, but leaves us with more legacy that may be superceded
251 2011-12-17 22:46:18 <luke-jr> except we *can't* just roll out key recovery
252 2011-12-17 22:46:31 <gmaxwell> We can, and could have.
253 2011-12-17 22:47:33 <gmaxwell> It was originally part of the OP_EVAL discussion but got dropped because of 'input script size doesn't matter'. It could be shoved back in. (or has code with op_eval validation actually been released yet)
254 2011-12-17 22:53:46 <luke-jr> well that's a bogus reason to drop it
255 2011-12-17 22:53:59 <luke-jr> even if it were true, minimizing input script size is OK
256 2011-12-17 22:54:22 <luke-jr> gmaxwell: Eligius is doing OP_EVAL validation, but not rejecting invalid ones yet
257 2011-12-17 22:55:29 <gmaxwell> I've been clued in that my memory was incorrect and that it was mostly dropped in order to get OP_EVAL out quicker.
258 2011-12-17 22:56:25 <gmaxwell> But, in any case, pay to address (or pay to script hash) has the smallest output size. Key recovery has the smallest input size.
259 2011-12-17 22:57:10 <gmaxwell> Pay to pubkey bloats the output size (a lot for the non-compressed case) in exchange for reducing the input script size some. (assuming no recovery)
260 2011-12-17 22:57:46 <sipa> and for the total: send-to-recovered-pubkey-with-hash < send-to-compressed-pubkeys-hash < send-to-pubkey < send-to-pubkeys-hash
261 2011-12-17 22:58:08 <luke-jr> gmaxwell: my proposal for pay to pubkey would require compression
262 2011-12-17 22:58:45 <gmaxwell> We should make a matrix of these things with all the sizes and which software changes are required.
263 2011-12-17 22:59:06 <gmaxwell> (by we, I mean me I guess)
264 2011-12-17 22:59:18 <luke-jr> anyhow, defining an address format, and supporting it as a destination, doesn't mean anyone has to use it
265 2011-12-17 22:59:27 <luke-jr> it just makes the option available in the future
266 2011-12-17 22:59:51 <sipa> it does require client software to support it before it is useful
267 2011-12-17 22:59:59 <luke-jr> send-to-recovered-pubkey-with-hash < send-to-compressed-pubkey < send-to-compressed-pubkeys-hash < send-to-pubkey < send-to-pubkeys-hash
268 2011-12-17 23:00:10 <luke-jr> sipa: exactly
269 2011-12-17 23:00:25 <gmaxwell> but it also makes pruning less useful forever.
270 2011-12-17 23:00:35 <gmaxwell> (if its widely used, at least)
271 2011-12-17 23:02:05 <sipa> pay-to-pubkeys-hash: 25 + 139 bytes
272 2011-12-17 23:02:18 <sipa> pay-to-recovered-pubkey: 24 + 66 bytes
273 2011-12-17 23:02:38 <sipa> (using my own proposal for op_eval script extension)
274 2011-12-17 23:03:10 <gmaxwell> Have numbers on pay to pubkey/ pay to compressed pubkey? (I'm making a table now)
275 2011-12-17 23:03:50 <sipa> pay-to-pubkey: 67 + 73
276 2011-12-17 23:04:03 <sipa> pay-to-compressed-pubkey: 35 + 73
277 2011-12-17 23:04:46 <sipa> pay-to-compressed-pubkeys-hash: 25 + 107
278 2011-12-17 23:05:33 <sipa> that's not entirely a fair comparison, because if we'd roll out my script extensions, the other pay-to-hash sizes would shrink a bit too
279 2011-12-17 23:07:18 <sipa> onne byte
280 2011-12-17 23:16:28 <sipa> hmm, i may have forgotten the hash type into the calculations
281 2011-12-17 23:16:36 <luke-jr> IMO, if we can squeeze pubkey recovery into OP_EVAL we should
282 2011-12-17 23:16:49 <sipa> luke-jr: https://gist.github.com/gists/1262449
283 2011-12-17 23:17:08 <luke-jr> sipa: THAT is not practical
284 2011-12-17 23:17:27 <sipa> to be enabled only within OP_EVAL
285 2011-12-17 23:17:30 <luke-jr> oh
286 2011-12-17 23:17:32 <luke-jr> hmmmmmmm
287 2011-12-17 23:17:37 <luke-jr> k
288 2011-12-17 23:18:16 <luke-jr> I'm willing to do my part to delay OP_EVAL for it ;)
289 2011-12-17 23:18:22 <gmaxwell> http://people.xiph.org/~greg/addr.compare.html
290 2011-12-17 23:19:42 <luke-jr> gmaxwell: use the Bitcoin wiki so we can sort -.-
291 2011-12-17 23:20:18 <gmaxwell> oops I have some numbers swapped.
292 2011-12-17 23:20:50 <sipa> gmaxwell: pay-to-recovered-pubkey is 24 + 67
293 2011-12-17 23:20:57 <sipa> i forgot one byte :)
294 2011-12-17 23:21:22 <luke-jr> send-to-hash, send-to-hash w/ recovery, send-to-pubkey, send-to-compressed-pubkey, send-to-compressed-pubkey-hash, send-to-compressed-pubkey-hash w/ recovery
295 2011-12-17 23:23:23 <luke-jr> last one?
296 2011-12-17 23:24:17 <gmaxwell> With recovery you never actually send the pubkey (its recovered) so compressed or not is moot.
297 2011-12-17 23:24:28 <sipa> gmaxwell: what is "upgrade tx" ?
298 2011-12-17 23:24:30 <luke-jr> true
299 2011-12-17 23:24:47 <gmaxwell> sipa: new sender software
300 2011-12-17 23:25:03 <gmaxwell> I think you don't need new sender software for send-to-compressed-pubkey-hash.
301 2011-12-17 23:25:09 <gmaxwell> (or pay to address, of course)
302 2011-12-17 23:25:12 <sipa> what is the difference between "upgrade sender" and "upgrade tx" ?
303 2011-12-17 23:25:21 <gmaxwell> sipa: reloader.
304 2011-12-17 23:25:21 <sipa> *upgrade send
305 2011-12-17 23:25:50 <gmaxwell> upgrade tx is upgrading the send side software, upgrade rx is upgrading the recieve side software.
306 2011-12-17 23:26:07 <sipa> got it
307 2011-12-17 23:26:12 <sipa> seems correct
308 2011-12-17 23:26:44 <gmaxwell> I'll put it on the wiki in a bit.
309 2011-12-17 23:26:56 <sipa> send-to-pubkey as luke-jr proposes it does require an upgrade rx, as the receiver needs to create a base58 representation of the pubkey
310 2011-12-17 23:27:33 <sipa> although the actual receice code is obviously already there
311 2011-12-17 23:28:41 <gmaxwell> True, noted.
312 2011-12-17 23:31:11 <sipa> hmm, so send-to-compressed-pubkey-hash is unambiguously better than send-to-pubkey
313 2011-12-17 23:31:38 <luke-jr> yes
314 2011-12-17 23:31:43 <luke-jr> wait
315 2011-12-17 23:32:11 <luke-jr> yes
316 2011-12-17 23:32:14 <sipa> oh, right - but you're proposing send-to-compressed-pubkey of course
317 2011-12-17 23:32:16 <luke-jr> but nobody was talking about send-to-pubkey
318 2011-12-17 23:32:20 <luke-jr> yep
319 2011-12-17 23:34:31 <luke-jr> send-to-compressed-pubkey incurs a tiny hit on pruned nodes (10 bytes), in exchange for major savings on full nodes (56 bytes)
320 2011-12-17 23:34:59 <luke-jr> send-to-key-hash w/ recovery is undeniably the best solution, though'
321 2011-12-17 23:35:16 <luke-jr> and most of the work is already being done for OP_EVAL anyway
322 2011-12-17 23:35:33 <sipa> well, as secp256k1 only has 128 bits of security, we could use 128-bit hashes as well ;)
323 2011-12-17 23:36:23 <sipa> (though one step of the 2^128 to break secp256k1's ECDSA is significantly harder than one step of a 128-bit hash function_
324 2011-12-17 23:36:51 <luke-jr> hmm
325 2011-12-17 23:37:05 <luke-jr> maybe we should defer OP_EVAL long enough to consider what other opcodes we can enable in it ;)
326 2011-12-17 23:37:41 <sipa> or put it in OP_EVAL2 ;)
327 2011-12-17 23:37:52 <luke-jr> why make a new one?
328 2011-12-17 23:38:00 <luke-jr> it's not like there's any real rush for OP_EVAL (1)