1 2011-10-19 00:21:13 <gjs278> ;;bc,stats
  2 2011-10-19 00:21:16 <gribble> Current Blocks: 149814 | Current Difficulty: 1468195.4272208 | Next Difficulty At Block: 151199 | Next Difficulty In: 1385 blocks | Next Difficulty In About: 1 week, 4 days, 1 hour, 4 minutes, and 25 seconds | Next Difficulty Estimate: 1280646.08059896 | Estimated Percent Change: -12.7741404955
  3 2011-10-19 00:53:52 <min0r> just a question, once all coins are mined, is it possible to change the block speed to 1 minute from 10 minutes?  (i.e. new client)
  4 2011-10-19 00:54:11 <min0r> Just thinking that no real commerce will ever be done with bitcoins if blocks take 10 minutes to confirm
  5 2011-10-19 00:54:25 <min0r> i.e. who wants to wait 10 minutes to pay for dinner? or a pair of jeans? etc
  6 2011-10-19 00:55:18 <min0r> is it possible that new clients in the future can change the block speed?
  7 2011-10-19 01:04:21 <[Tycho]> min0r, there are many other solutions.
  8 2011-10-19 01:04:35 <[Tycho]> And you were told about it.
  9 2011-10-19 01:05:26 <gjs278> once all fo the blocks are mined YOU WILL BE DEAD DONT WORRY ABOUT
 10 2011-10-19 01:05:28 <gjs278> IT
 11 2011-10-19 01:06:18 <phantomcircuit> gjs278, lol
 12 2011-10-19 01:06:40 <gjs278> bitcoin making it to 2140 is the real lol
 13 2011-10-19 01:06:48 <gjs278> but hey we have to plan ahead
 14 2011-10-19 01:27:41 <min0r> What are the other solutions? bit-pay and ripple?
 15 2011-10-19 01:27:58 <min0r> there is no widespread solution to the POS problem
 16 2011-10-19 01:28:22 <min0r> bitcoin will trend toward $0 unless its used in real-world commerce... i think POS is a big part of this
 17 2011-10-19 01:34:07 <gmaxwell> min0r: jesus go read before I ban you from this channel too
 18 2011-10-19 01:34:17 <gmaxwell> Also see the youtube link allinvain gave you
 19 2011-10-19 01:36:50 <phantomcircuit> actually that's an interesting thought
 20 2011-10-19 01:36:59 <phantomcircuit> bitcoins can be used as ripple cash with a final clear
 21 2011-10-19 01:37:01 <phantomcircuit> interesting
 22 2011-10-19 01:39:14 <gmaxwell> phantomcircuit: yea, I pointed it out here: https://bitcointalk.org/index.php?topic=28565.5;wap2
 23 2011-10-19 01:39:31 <gmaxwell> (when someone described something I thought looked like ripple)
 24 2011-10-19 01:59:30 <copumpkin> wtfwtf: what's wrong?
 25 2011-10-19 02:52:39 <min0r> gmaxell, can you repost allinvain's youtube link? i lost the link when you kicked me
 26 2011-10-19 02:52:50 <min0r> isnt allinvain the guy that had 50K BTC stolen?
 27 2011-10-19 02:55:06 <gmaxwell> min0r: 5 million btc!
 28 2011-10-19 02:55:34 <gmaxwell> min0r: 20:07 < allinvain> http://www.youtube.com/watch?v=2Z4m4lnjxkY
 29 2011-10-19 02:56:33 <whiteman> On Ubuntu 11.10 I'm getting an error about missing db_cxx.h, which I believe is related to package libdb4.8++-dev.
 30 2011-10-19 02:56:45 <whiteman> Apparently this package has been deleted. http://www.ubuntuupdates.org/packages/show/335212
 31 2011-10-19 03:22:39 <whiteman> Looks like libdb5.1-dev and libdb5.1++-dev will work fine.
 32 2011-10-19 03:52:17 <devrandom> whiteman: our reference build OS is lucid (10.04)
 33 2011-10-19 03:56:41 <devrandom> whiteman: you are breaking new ground ;)
 34 2011-10-19 04:20:11 <phantomcircuit> ;;bc,blocks
 35 2011-10-19 04:20:12 <gribble> 149837
 36 2011-10-19 04:37:41 <phantomcircuit> ;;bc,blocks
 37 2011-10-19 04:37:42 <gribble> 149841
 38 2011-10-19 05:20:54 <genjix> Diablo-D3: do you want to do a conference talk? not sure if i already invited you, http://conference.bitgroups.org/
 39 2011-10-19 05:21:05 <genjix> nanotube: same?
 40 2011-10-19 05:21:17 <genjix> anyone else i've forgotten to invite
 41 2011-10-19 05:23:06 <genjix> da2ce7: got my email? want to do an OpenTransactions talk?
 42 2011-10-19 05:23:39 <genjix> anyone else, feel free to email us. conference@bitgroups.org
 43 2011-10-19 07:24:26 <Lolcust_Backup> anyone seen jgarzik ?
 44 2011-10-19 07:30:55 <neofutur> !seen jgarzik
 45 2011-10-19 07:30:59 <spaola> jgarzik (~jgarzik@99-43-178-25.lightspeed.rlghnc.sbcglobal.net) was last seen changing nicks to Guest51076 on #bitcoin-dev 1 day, 5 hours, 48 minutes ago.
 46 2011-10-19 07:34:09 <Diablo-D3> [03:20:54] <genjix> Diablo-D3: do you want to do a conference talk? not sure if i already invited you, http://conference.bitgroups.org/
 47 2011-10-19 07:34:14 <Diablo-D3> meh he left
 48 2011-10-19 08:58:21 <shadders> TD: ping
 49 2011-10-19 08:58:31 <shadders> TD[gone]: ping
 50 2011-10-19 09:01:13 <TD> hi
 51 2011-10-19 09:01:17 <TD> i just replied to your mail
 52 2011-10-19 09:01:28 <shadders> ya saw it... that's all I was pinging about
 53 2011-10-19 09:02:06 <shadders> yr past comments seemed to imply you wanted to do it or were already so didn't want to double up.
 54 2011-10-19 09:07:35 <shadders> TD: BTW what's the correct convention for author in new classes?  I notice most of them just have 'google'
 55 2011-10-19 09:08:11 <shadders> and what's this mean: - Remove VersionMessage check in Message serialization roundtrip checks
 56 2011-10-19 11:24:44 <n5> Do we have bitcoin 0.4.0 rpm's for centos 5 or 6 ?
 57 2011-10-19 12:00:26 <terrytibbs> gavinandresen: You never publicized the ClearCoin source code, did you?
 58 2011-10-19 12:00:43 <gavinandresen> terrytibbs: nope
 59 2011-10-19 12:00:55 <terrytibbs> roger
 60 2011-10-19 12:01:14 <gavinandresen> ... it didn't show up on some hacker forum somewhere, did it?  :-)
 61 2011-10-19 12:02:00 <gavinandresen> sipa: ping
 62 2011-10-19 12:02:06 <sipa> gavinandresen: pang
 63 2011-10-19 12:02:31 <terrytibbs> gavinandresen: I wouldn't know anything about such a thing! :)
 64 2011-10-19 12:02:32 <gavinandresen> sipa:  I've been thinking about smaller signatures and op_eval...
 65 2011-10-19 12:02:56 <gavinandresen> I like your proposal, but it feels "too radical"
 66 2011-10-19 12:03:03 <sipa> i understand
 67 2011-10-19 12:03:32 <gavinandresen> I'm thinking:  what if the CHECKSIG opcodes behaved a little differently when 'inside' an OP_EVAL?
 68 2011-10-19 12:03:58 <gavinandresen> The different behavior would be:  if the public key is 21 bytes, then interepret it as a hash+bits
 69 2011-10-19 12:04:11 <sipa> you could just switch to the compact signatures inside OP_EVAL
 70 2011-10-19 12:04:12 <gavinandresen> ... and do the key extraction thing to get the pubkey from the sig
 71 2011-10-19 12:04:34 <gavinandresen> feel like writing some code?
 72 2011-10-19 12:04:48 <sipa> sure
 73 2011-10-19 12:04:57 <gavinandresen> Start here:  https://github.com/gavinandresen/bitcoin-git/tree/op_eval
 74 2011-10-19 12:06:33 <sipa> i'm not sure whether overloading CHECKSIG is the way to go
 75 2011-10-19 12:06:54 <gavinandresen> why not?
 76 2011-10-19 12:07:13 <gavinandresen> (less flexible, I know....)
 77 2011-10-19 12:07:42 <gavinandresen> The semantics seem clear:  either <sig> <pubkey> CHECK   or  <sig> <hash+bits> CHECK ...
 78 2011-10-19 12:07:58 <gavinandresen> (or maybe:  <compatsig> <hash+bits> CHECK)
 79 2011-10-19 12:08:20 <n5> you all developing here, its great, but i can't compile 0.4 version on centos, and it sux, because a lot of users who want to use bitcoin on webservices are waiting for some good toturial :)
 80 2011-10-19 12:08:41 <sipa> what about just adding OP_RECOVER and/or OP_CHECKHASH inside OP_EVAL (and leave the rest untouched) ?
 81 2011-10-19 12:08:45 <sipa> that feels cleaner
 82 2011-10-19 12:09:08 <gmaxwell> n5: you're not providing any details the build instructions for prior versions should mostly work for 0.4 IIRC
 83 2011-10-19 12:09:17 <gavinandresen> That means more complicated for IsStandard() checks
 84 2011-10-19 12:09:43 <gavinandresen> n5: I don't know nuthin about centos
 85 2011-10-19 12:09:44 <sipa> it means adding an extra case to the script solver
 86 2011-10-19 12:09:50 <sipa> but you need an extra case anyway, no?
 87 2011-10-19 12:10:07 <sipa> (haven't looked at your OP_EVAL code yet)
 88 2011-10-19 12:10:12 <gavinandresen> No, CHECKSIG is already a standard case (and I added CHECKMULTISIG as a standard case)
 89 2011-10-19 12:10:43 <gavinandresen> ... and you'd need code that did "If inside an op_eval THEN OP_RECOVER is allowed, otherwise it isn't, etc etc)
 90 2011-10-19 12:11:05 <sipa> ok, just OP_CHECKHASH?
 91 2011-10-19 12:11:10 <gavinandresen> Don't get me wrong, I like OP_RECOVER/OP_CHECKHASH, I just think baby steps is the way to go
 92 2011-10-19 12:11:31 <sipa> which is identical to OP_CHECKSIG except it takes a hash instead of a pubkey
 93 2011-10-19 12:11:55 <n5> gmaxwell, but they not working, firstly, i had to edit makefile.unix, like 10 times, sometimes files in difrent folders, and later on i got error anyway
 94 2011-10-19 12:12:13 <gmaxwell> gavinandresen: won't you still need a check to prevent check from accepting hash+bits without eval?
 95 2011-10-19 12:12:46 <gmaxwell> n5: I don't mean to insult, but it sounds like you need to read this http://catb.org/~esr/faqs/smart-questions.html
 96 2011-10-19 12:12:49 <gavinandresen> gmaxwell: yes, but that's a check on redemption, not an IsStandard check....
 97 2011-10-19 12:13:00 <gmaxwell> gavinandresen: ah point.
 98 2011-10-19 12:13:39 <n5> gmaxwell,  I asked if we have somewhere rpms for centos
 99 2011-10-19 12:13:43 <gmaxwell> n5: I have to go out for a bit, so I'm not ignoring you but really "i had to edit makefile.unix, like 10 times" and "later on I got an error" tells me nothing that could possibly help me make a suggestion for you.
100 2011-10-19 12:13:45 <n5> its not smart question?
101 2011-10-19 12:13:58 <neofutur> n5: centos is the worst place to build bitcoin , their ssl is not supporting things bitcoin need
102 2011-10-19 12:14:00 <gmaxwell> n5: Oh, well, the answer to that is apparently no. :)
103 2011-10-19 12:14:06 <n5> I'm used this script - https://github.com/sneak/bitcoin-el5-rpm
104 2011-10-19 12:14:26 <gmaxwell> neofutur: it's a trivial change to the openssl srpm to fix that.
105 2011-10-19 12:14:49 <neofutur> I tried
106 2011-10-19 12:15:04 <neofutur> if its trivial . . . please provide the working rpm ;)
107 2011-10-19 12:15:18 <gmaxwell> I don't have any centos systems, I can give you a fedora one.
108 2011-10-19 12:15:31 <gavinandresen> sipa:  CHECKHASH probably means 4 new opcodes; do you not want to overload the CHECKSIG opcodes for aesthetic reasons? (ugly to look at number-of-bytes-in-item-on-stack to decide what to do?)
109 2011-10-19 12:15:46 <n5> gmaxwell,  sorry, its just soo huge mess doing it, that its a little hard for me
110 2011-10-19 12:16:25 <gmaxwell> if its any comfort.. 0.5 will be easier to build.
111 2011-10-19 12:16:27 <sipa> gavinandresen: it feels wrong to me to hardcode one form of addresses (the OP_HASH160-based one) inside a standard opcode
112 2011-10-19 12:16:51 <n5> gmaxwell,  fedora is almost like centos, so rpms should work maybe :D i dont know
113 2011-10-19 12:17:53 <gmaxwell> n5: I don't have fedora rpms for bitcoin.. only openssl. (I don't bother building with wx, which is half the trouble of building bitcoin <0.5 on fedora)
114 2011-10-19 12:18:12 <gavinandresen> sipa:  got it.  Well, it seems more likely we'll want/need to upgrade ECDSA than we'll want/need to upgrade the RIPEMD(SHA256()) that is HASH160
115 2011-10-19 12:18:34 <neofutur> gmaxwell: i been able to rebuild on fedora, but not on centos, i can provide a ssh if you re interested in trying
116 2011-10-19 12:18:47 <neofutur> rpmbuild and src rpm already installed
117 2011-10-19 12:19:49 <gavinandresen> sipa:  can you help me with a back-of-the-envelope how many bytes could be saved?  21 bytes for hash+bits versus 65 for full public key...
118 2011-10-19 12:19:58 <n5> http://pastebin.com/GytYagNk
119 2011-10-19 12:20:06 <n5> this is error i'm stuck right now
120 2011-10-19 12:20:20 <sipa> right now, signatures are 72 bytes, pubkeys are 65 bytes
121 2011-10-19 12:20:30 <gavinandresen> ... and how small can signatures get?
122 2011-10-19 12:20:42 <neofutur> n5: yup same problem here on centos, you have to rebuild the openssl rpm from source, and it wont work :p
123 2011-10-19 12:20:43 <sipa> with your proposal, signatures will be 64 bytes, "pubkeys" will be 21 bytes
124 2011-10-19 12:21:12 <sipa> although i'd add the extra bits to the signature, and not to the pubkeyhash
125 2011-10-19 12:21:19 <neofutur> n5: centos openssl dont have support for ecdsa
126 2011-10-19 12:21:21 <n5> neofutur,  yes i did it, but its not working
127 2011-10-19 12:21:26 <sipa> so you'd have 65 byte signatures and 20 byte pubkeys
128 2011-10-19 12:21:28 <neofutur> i know
129 2011-10-19 12:21:41 <n5> so its crazy :D
130 2011-10-19 12:23:17 <n5> how to do it? I have all site ready to integrate bitcoin, tested with remote server on windows and everything went ok, soo I want to let bitcoind run on local webserver and its impossible, because of OS its running :D
131 2011-10-19 12:23:29 <gavinandresen> sipa:  thanks
132 2011-10-19 12:24:09 <sipa> gavinandresen: so, in your proposal, you'd do: txout: "OP_DUP <scriptHash> OP_HASH160 OP_EQUALVERIFY OP_OPEN", txin: "<65-byte sig> < <pubkeyhash> OP_CHECKHASH>", right?
133 2011-10-19 12:24:28 <neofutur> n5: try gentoo ;)
134 2011-10-19 12:24:32 <sipa> (whether OP_CHECKHASH is the same opcode as OP_CHECKSIG or not)
135 2011-10-19 12:24:36 <gavinandresen> ^OP_OPEN^OP_EVAL^
136 2011-10-19 12:24:50 <sipa> eh, right - no idea where that came from
137 2011-10-19 12:25:28 <gavinandresen> Well, in my proposal there would be no OP_CHECKHASH-- OP_CHECKSIG would notice that it is getting 65/20 byte items on the stack and Do the Right Thing
138 2011-10-19 12:25:37 <n5> neofutur,  I can't change OS on server because its running my websites :D I'm stuck on CentOS and its not working
139 2011-10-19 12:25:44 <sipa> yes, yes - so it's just the same opcode as OP_CHECKSIG
140 2011-10-19 12:26:39 <n5> soo, anyone else have ideas?
141 2011-10-19 12:26:53 <sipa> gavinandresen: or, would you consider: txout: <<<pubkeyhash> <OP_CHECKHASH>> OP_EVAL>, txin: < <sig> > ?
142 2011-10-19 12:27:30 <cuqa> hey
143 2011-10-19 12:27:57 <neofutur> n5: I can migrate your websites on a secure gentoo hardened server, query me if interested, https://bitcointalk.org/?topic=1687.0
144 2011-10-19 12:27:58 <cuqa> my bitcoind does not seem to react any more after restart saying: error: couldn't connect to server
145 2011-10-19 12:28:07 <sipa> cuqa: version?
146 2011-10-19 12:28:13 <cuqa> the blockchain is up to date
147 2011-10-19 12:28:17 <cuqa> 0.3.24
148 2011-10-19 12:28:21 <gavinandresen> sipa:  let me think about that ....
149 2011-10-19 12:28:40 <n5> neofutur, i'm just need to run bitcoind on centos :D
150 2011-10-19 12:29:05 <cuqa> how long is normal for bitcoind to start up? oO
151 2011-10-19 12:29:37 <gavinandresen> sipa:  one thing I like about the DUP/HASH/EVAL form is it is semi-secure even with old miners/clients-- if you've never used the pubkey before, then the script hash is unique and un-guessable
152 2011-10-19 12:30:10 <gavinandresen> (hash is unique, what script produces that hash is un-guessable)
153 2011-10-19 12:30:11 <tcatm> n5: have you tried compiling openssl manually?
154 2011-10-19 12:30:26 <sipa> gavinandresen: what's the difference?
155 2011-10-19 12:30:39 <sipa> gavinandresen: right now, if you've never used a pubkey, it is also un guessable?
156 2011-10-19 12:31:12 <neofutur> n5: so contact centos support to know why its impossible to rebuild their openssl source package with ecdsa and ec
157 2011-10-19 12:31:13 <gavinandresen> If an old client gets   <...anything>  OP_EVAL, then any scriptPubKey will validate as true
158 2011-10-19 12:31:22 <sipa> oh, i see
159 2011-10-19 12:31:31 <sipa> yes, that is true
160 2011-10-19 12:31:46 <neofutur> n5: i could build it with ecdsa but after that you have another problem
161 2011-10-19 12:31:47 <n5> tcatm,  yes
162 2011-10-19 12:31:48 <n5> cd %{_builddir}/openssl-1.0.0a
163 2011-10-19 12:32:07 <neofutur> ( bitcoin/src/key.h:169: undefined reference to `EC_KEY_new_by_curve_name' )
164 2011-10-19 12:32:26 <neofutur> ( after you fix the one in your pastebin )
165 2011-10-19 12:32:42 <n5> huh... its hard
166 2011-10-19 12:33:27 <neofutur> n5: and you have to edit the rpm spec file before rebuilding
167 2011-10-19 12:33:55 <neofutur> rpmbuild/SPECS/openssl.spec
168 2011-10-19 12:34:28 <neofutur> ( search for ecdsa in the spec file )
169 2011-10-19 12:34:51 <neofutur> i could add ecdsa support but i  stuck on the next problem
170 2011-10-19 12:35:01 <tcatm> n5: can you paste your patched makefile somewhere?
171 2011-10-19 12:38:05 <cuqa> is 0.3.24 out dated and not recommend to use any more
172 2011-10-19 12:38:06 <cuqa> ?
173 2011-10-19 12:38:30 <gavinandresen> yes, 0.3.24 is outdated and not recommended to use any more
174 2011-10-19 12:38:59 <cuqa> could it be caused by the version that I cant start it any more?
175 2011-10-19 12:39:27 <gavinandresen> no, 0.3.24 should still start and run just fine
176 2011-10-19 12:40:00 <neofutur> n5: the "error: db_cxx.h: No such file or directory" is easyer to fix, just install a recent bdb
177 2011-10-19 12:40:43 <neofutur> ( and add the path in makefile.unix )
178 2011-10-19 12:44:42 <ByteCoin> ping gavin?
179 2011-10-19 12:45:12 <gavinandresen> Hey ByteCoin
180 2011-10-19 12:46:00 <ByteCoin> Am I right in thinking that (A and B) or C transactions are not going to be in the first round of multisignature transactions implemented?
181 2011-10-19 12:46:11 <gavinandresen> yes
182 2011-10-19 12:46:19 <gavinandresen> (yes, you're right)
183 2011-10-19 12:46:34 <gavinandresen> ... although I've been thinking about them....
184 2011-10-19 12:46:44 <ByteCoin> Oh... that's a pity
185 2011-10-19 12:47:01 <ByteCoin> Any reason?
186 2011-10-19 12:47:26 <sipa> gavinandresen: anyway, so you'd have 114 bytes for scriptSig + scriptPubKey
187 2011-10-19 12:47:32 <gavinandresen> Just trying to keep things as simple as possible to start
188 2011-10-19 12:48:23 <ByteCoin> ok. thx
189 2011-10-19 12:48:28 <sipa> where now that is 164 bytes
190 2011-10-19 12:48:38 <gavinandresen> ByteCoin: what use-case are you thinking of for a&b | c ?
191 2011-10-19 12:49:31 <ByteCoin> gavin: A&B is standard "overseen" transaction but what happens if your oversight agency disappears? You need the key in your safe C
192 2011-10-19 12:49:55 <ByteCoin> Otherwise your coins are not available for you to spend
193 2011-10-19 12:50:04 <gavinandresen> Yes, B should send you a copy of the private key in the mail in case they disappear
194 2011-10-19 12:50:30 <gavinandresen> (I agree it would be nifty if you could generate a C and keep it safe just in case, but it adds a fair bit of complexity)
195 2011-10-19 12:51:25 <ByteCoin> Ok. I can see your reasoning. From an oversight agency point of view there's a problem in exposing these keys internally to allow them to be printed out.
196 2011-10-19 12:51:46 <gavinandresen> That IS the use case I was thinking about... but I think it would require a third type of bitcoin address that had 2 20-byte hashes in it...
197 2011-10-19 12:52:04 <gavinandresen> ... and I think it will be hard enough to get people to agree that one more type of bitcoin address is a good idea
198 2011-10-19 12:52:11 <ByteCoin> Printing out or otherwise distributing private keys becomes an impediment to using different keys.
199 2011-10-19 12:52:33 <gavinandresen> hmm?  what do you mean?
200 2011-10-19 12:52:39 <ByteCoin> Oh? Why such long addresses?
201 2011-10-19 12:52:51 <ByteCoin> Surely with OP_EVAL only one kind of address is needed ever
202 2011-10-19 12:52:58 <ByteCoin> Otherwise what's the point?
203 2011-10-19 12:53:10 <ByteCoin> (Ok until we leave Hash160)
204 2011-10-19 12:53:35 <gavinandresen> Well, consider:  you create a transaction that is (a AND b) OR c.   lets say you use a different (a) for every transaction, b and c are fixed keys.
205 2011-10-19 12:53:57 <gavinandresen> You compute the hash of the script for that.... and then you store  that hash in your wallet.
206 2011-10-19 12:54:19 <gavinandresen> Now b goes out of business.  No problem, I can sign with c.
207 2011-10-19 12:54:26 <gavinandresen> But what if I lose my wallet?
208 2011-10-19 12:54:54 <gavinandresen> I'd really like to sign with c, but I can't because I don't have HASH(script of a and b or c) in my wallet....
209 2011-10-19 12:54:59 <ByteCoin> Isn't losing your wallet a coin-losing proposition anyway? Why's this worse?
210 2011-10-19 12:55:10 <gmaxwell> sipa: gavinandresen: one loss resulting from just using checksig  is that you can't express a script needing a AND b AND c  by writing RECOVER RECOVER RECOVER CONCAT CONCAT HASH EQUALS <160bit/256bit number>  you'd have to express three pubkey hashes.
211 2011-10-19 12:55:40 <gavinandresen> If I lose my wallet but I have c's public/private keys someplace safe and offline, then I aught to be able to recover
212 2011-10-19 12:56:11 <gavinandresen> gmaxwell: Huh?  A &B & C  is    3 ... 3 CHECKMULTISIG
213 2011-10-19 12:56:41 <gavinandresen> ByteCoin: If (a&b)
214 2011-10-19 12:56:43 <gavinandresen> ...grr
215 2011-10-19 12:56:55 <ByteCoin> gavin: Yes you are right.
216 2011-10-19 12:57:06 <gavinandresen> If (a&b)|c  is expressed as  two  hash-checks in the scriptPubKey, then I can recover with just c
217 2011-10-19 12:57:34 <gmaxwell> gavinandresen: The improvement I'm describing is that you should only need one hash per possible way of satisfiying a txn. E.g. there is only one way to satisify A&B&C so you should only need one hash.. the hash of the concat of all the public keys.
218 2011-10-19 12:57:36 <gavinandresen> ... which is where I get to a 2-hash bitcoin address form
219 2011-10-19 12:58:11 <gavinandresen> afk a minute
220 2011-10-19 12:58:15 <ByteCoin> gavin: Ok your 2 hash bitcoin address is one way to solve the problem
221 2011-10-19 12:58:42 <gavinandresen> ... nevermind, back
222 2011-10-19 12:59:07 <ByteCoin> gavin: You should have posted your thoughts on the forum as there are other solutions to this problem
223 2011-10-19 13:00:01 <ByteCoin> One solution is the use of a deterministic wallet
224 2011-10-19 13:00:11 <gavinandresen> ByteCoin: conversations on the forums have a tendency to wander off topic....
225 2011-10-19 13:00:37 <gavinandresen> And yeah, a deterministic wallet could let you compute all the possible (a&b)|c variations to find the ones that belong to you
226 2011-10-19 13:00:50 <ByteCoin> (agreed about offtopic - Moderation?) Another solution is to lodge the scripts for a hash with some 3rd party
227 2011-10-19 13:00:53 <gmaxwell> ByteCoin: or just publish A/B far and wide its not exactly private data but not in the blockchain...
228 2011-10-19 13:01:11 <ByteCoin> gmaxwell: Exactly
229 2011-10-19 13:01:38 <ByteCoin> It's just a question of not storing stuff in the block chain that doesn't NEED to be there
230 2011-10-19 13:01:39 <gmaxwell> As a matter of general principle, if your problem is "I need to reliably store some data" the bitcoin blockchain is not a good solution. :)
231 2011-10-19 13:01:44 <gavinandresen> Well, new standard transaction types should be easy...
232 2011-10-19 13:02:23 <ByteCoin> afk
233 2011-10-19 13:02:43 <n5> tcatm,  i'm using default makefile.uni from src/src dir
234 2011-10-19 13:03:36 <gmaxwell> gavinandresen: another possiblitity would be to have an address format which encodes that data tagged onto the end but doesn't actually write the extrabits into the chain.
235 2011-10-19 13:03:46 <gmaxwell> Then its a matter of "remember your old address"
236 2011-10-19 13:04:02 <gavinandresen> gmaxwell: I'm proposing a scriptPubKey that is a generic:  DUP HASH <hash> EQUALVERIFY OP_EVAL...
237 2011-10-19 13:04:22 <gavinandresen> gmaxwell: ... that is satisified by a generic   <signatures>  <serialized-script>
238 2011-10-19 13:04:44 <gavinandresen> e.g. <serialized script> might be   <3 pubkey pubkey pubkey 3 CHECKMULTISIG>
239 2011-10-19 13:05:00 <tcatm> n5: that makefile is probably still using the system's openssl libs. you should add -I and -L flags so it can find your own libs. you might also want to link the resulting binary statically so it doesn't break when you delete or move your openssl libs
240 2011-10-19 13:05:24 <n5> http://pastebin.com/LHgeLHUJ
241 2011-10-19 13:05:48 <gavinandresen> (although I was trying to convince sipa that teaching the CHECKSIG opcodes to do pubkey extraction if given 20-byte hashes instead of pubkeys would be a good idea)
242 2011-10-19 13:07:33 <gmaxwell> gavinandresen: right, above I suggested a script type why making CHECKSIG do recovery alone wouldn't be ideal. Because for a&b&c you'd be better off (smaller data) coding RECOVER RECOVER RECOVER CONCAT CONCAT HASH <hash> EQUALVERIFY
243 2011-10-19 13:07:53 <gmaxwell> (though I guess we have the concat turned off right now)
244 2011-10-19 13:07:56 <ThomasV> gavinandresen: hi gavin, is piotrnar's importexporttx patch going to be merged at some point ?
245 2011-10-19 13:08:15 <gavinandresen> gmaxwell: ah, got it
246 2011-10-19 13:08:40 <gavinandresen> ThomasV: is that a pull request?
247 2011-10-19 13:09:15 <ThomasV> no I don't think it's a pull request, as far as I can tell :https://github.com/piotrnar/bitcoin/commits/importexporttx
248 2011-10-19 13:10:03 <gmaxwell> gavinandresen: for three keys that construction would save about 34 bytes. about 14 bytes for a&b.  It doesn't do anything for e.g. 2 of 3 though.
249 2011-10-19 13:11:07 <gmaxwell> ( (a&b)|(b&c)|(a&c) ... as you'd need three hashes anyplace, plus you'd lose from having a bunch more opcodes to express it. :) )
250 2011-10-19 13:12:15 <ByteCoin> Guys. I can see you're spending a lot of time thinking about how to reduce space. Why don't we just not include signatures in blocks? Just have signed transactions?
251 2011-10-19 13:13:12 <ByteCoin> The transactions hashes shouldn't be affected by the signatures already
252 2011-10-19 13:13:30 <ByteCoin> So going one step further and not including them in blocks makes sesne
253 2011-10-19 13:13:35 <n5> tcatm,  can you help me and tell where to add -I and -L to makefile.unix?
254 2011-10-19 13:13:45 <edcba> what about not including previous hash ? :)
255 2011-10-19 13:13:50 <gmaxwell> ByteCoin: but then the rest of the network must trust that you actually validated the signatures.
256 2011-10-19 13:13:58 <lianj> edcba: neat idea!
257 2011-10-19 13:14:39 <ByteCoin> gmaxwell: If the rest of the network cared then they can see all the transactions anyway
258 2011-10-19 13:14:41 <gmaxwell> ByteCoin: and my space misering is shed painting. I apologize if I'm making it look very important.
259 2011-10-19 13:14:46 <gavinandresen> ByteCoin: interesting.  That seems like a protocol optimization for cases where you already trust (or can verify) that your neighbor is feeding you valid blocks
260 2011-10-19 13:14:48 <edcba> anyway now that bitcoin is low again we will be able to do breaking changes :))
261 2011-10-19 13:15:08 <gavinandresen> ("give me the block, but don't bother giving me the scriptSigs")
262 2011-10-19 13:15:26 <gmaxwell> Yes, it sounds like a useful on the wire optimization- I wouldn't want to make it a default however.
263 2011-10-19 13:15:33 <ByteCoin> gavin: Yes.. If they want the sigs they could ask for the raw transactiosn too
264 2011-10-19 13:15:57 <gmaxwell> Also fun would be making nodes just validate a small random percent of them... so if you start trying to feed a nonsense chain they'll eventually figure out that you're lying.
265 2011-10-19 13:16:14 <gavinandresen> gmaxwell: randomness for the win....
266 2011-10-19 13:16:16 <ByteCoin> gmaxwell: If the rest of the network wanted to verify all the signatures they would have to ask for all the signatures separately
267 2011-10-19 13:16:57 <lianj> ByteCoin: sadly you cant ask for old transactions alone. just for old blocks
268 2011-10-19 13:17:02 <tcatm> n5: add them to CXXFLAGS
269 2011-10-19 13:17:03 <gavinandresen> I like it.  Who wants to write up a BIP extending the protocol?
270 2011-10-19 13:17:15 <ByteCoin> gmaxwell: They'd figure out much sooner as - if they're relayers - they'd see whether the transactions in the blocks matched up to the transactions they'd seen
271 2011-10-19 13:17:29 <sipa> if we're going to change the block format, we should do everything at once (that is agreed upon)
272 2011-10-19 13:17:32 <ByteCoin> lianj: That's the current situatuion
273 2011-10-19 13:17:43 <sipa> i like splitting off the signatures
274 2011-10-19 13:17:52 <gmaxwell> E.g. A node that is going to verify one in a hundred signatures but you can't predict which is almost as good for network security as a full node (assuming it isn't mining).  Because you'll screw yourself doing a high difficulty mining operation only to get caught out by some node.
275 2011-10-19 13:18:22 <sipa> if we do that, also add a merkle of the available txouts to the coinbase
276 2011-10-19 13:18:25 <ByteCoin> gmaxwell: Nodes see all transactions + sigs when they relay anyway
277 2011-10-19 13:18:45 <ByteCoin> sipa: Excellent idea "balance sheets"
278 2011-10-19 13:18:54 <sipa> it was gmaxwell's idea :)
279 2011-10-19 13:18:55 <ThomasV> gavinandresen: does it need to be a pull request before I can get an informal opinion on it ?
280 2011-10-19 13:18:56 <gmaxwell> ByteCoin: not always sometimes you really do learn of a txn first via a block.
281 2011-10-19 13:19:11 <gavinandresen> ThomasV: is the RPC interface for it written up somewhere?
282 2011-10-19 13:19:16 <gmaxwell> It was my idea, but ByteCoin had it too. (he was probably first, I was just unaware of it)
283 2011-10-19 13:19:35 <ThomasV> gavinandresen: I do not know
284 2011-10-19 13:20:10 <gavinandresen> ThomasV: I could go digging through the code, but it'd be nice if there was a little design document written so I didn't have to
285 2011-10-19 13:20:10 <ThomasV> gavinandresen: it is not ready to be merged anyway
286 2011-10-19 13:20:21 <gmaxwell> (Bytecoin also had a more complete vision, I was mostly concerned with the impossiblity of namecoin lite nodes because validating open txn is important in namecoin in a way that it isn't in bitcoin)
287 2011-10-19 13:20:32 <ByteCoin> gavin: Re: BIP for this conversation. First I'll do a forum post - then if there seems to be a consesus that it's desirable then I might invest the necessary work
288 2011-10-19 13:20:46 <gavinandresen> ThomasV: in general, I like the idea of creating transactions and then submitting them to bitcoind to validate and send across the network
289 2011-10-19 13:21:05 <ThomasV> gavinandresen: ok, that's what I wanted to know
290 2011-10-19 13:21:32 <ThomasV> gavinandresen: I don't care if it is through that particular patch or another
291 2011-10-19 13:21:38 <gmaxwell> ThomasV: thats good functionality it means you can have offnet wallets and such.
292 2011-10-19 13:21:49 <edcba> anyway there is plenty ways to improve bitcoin
293 2011-10-19 13:21:57 <ThomasV> gmaxwell: or lightweight wallets
294 2011-10-19 13:22:07 <gavinandresen> edcba: heresy, bitcoin is absolutely perfect the way it is
295 2011-10-19 13:22:15 <ThomasV> lol
296 2011-10-19 13:22:16 <n5> ok tcatm  it helped
297 2011-10-19 13:22:18 <edcba> haha
298 2011-10-19 13:22:45 <gmaxwell> edcba: you'd help your position if you didn't argue crazy things like not including the prev hash! :)
299 2011-10-19 13:23:15 <edcba> it was a semi joke
300 2011-10-19 13:23:34 <gmaxwell> There are so many bad suggestions around (some by me!) that I can't tell anymore!
301 2011-10-19 13:24:02 <gavinandresen> RE: offline transactions:  what SHOULD a partially-signed transaction look like?   serialized bytes like it appears on the bitcoin network... but what if you have a 3-of-6 MULTISIG with 1 signature?  ....
302 2011-10-19 13:24:03 <edcba> there are a lot of tradeoff you can make if you want to sacrifice some security with bitcoin
303 2011-10-19 13:24:30 <gavinandresen> I think groffer's patch had OP_0 placeholders for missing signatures, I'm not sure if that is the right way to go, though
304 2011-10-19 13:24:40 <ThomasV> gavinandresen: no idea, this is over my head
305 2011-10-19 13:25:04 <n5> tcatm,  other error now - http://pastebin.com/FDeyhKB7
306 2011-10-19 13:25:27 <gmaxwell> edcba: yes, I don't think any non-trivial system wide security loss is really tolerable. People that have invested time into bitcoin bought into a system with particular security parameters.
307 2011-10-19 13:25:42 <ByteCoin> gavin: Obviously it's vital that the signatures don't affect the transaction hash
308 2011-10-19 13:25:59 <tcatm> n5: add USE_UPNP= after bitcoind (when calling make)
309 2011-10-19 13:26:09 <gavinandresen> ByteCoin:  that seems like a separate issue
310 2011-10-19 13:26:32 <gmaxwell> edcba: so strict improvements are fine, but changes in the compromises are very touchy.  If its personal, e.g. you can choose to run a weaker node (just another kind of lite node, which was already possible) then its less of an issue.. but overall changes, not so much.
311 2011-10-19 13:26:33 <gavinandresen> (separate to "what does it look like to send a partially signed transaction to somebody else to gather more signatures")
312 2011-10-19 13:26:56 <ByteCoin> Well if you part sign the transaction and the hash changes then the next signature is going to be signing a different hash etc...
313 2011-10-19 13:27:10 <gmaxwell> gavinandresen: I'd probably prefer stubbing out a missing signature with zeros.
314 2011-10-19 13:28:28 <gavinandresen> gmaxwell: I'm wondering if for the JSON-RPC interface something like  "here's the transaction" and "here's a dictionary of <input> : <signature>" might be a better way to do it
315 2011-10-19 13:28:43 <ByteCoin> Gavin: As I mentioned in a forum post a long time ago. Partially signed transactions can't work at the moment because signing the transaction changes the hash
316 2011-10-19 13:29:00 <sipa> not the message hash, does it?
317 2011-10-19 13:29:04 <ByteCoin> Yup
318 2011-10-19 13:29:08 <n5> tcatm,  how to use it? dont understand
319 2011-10-19 13:29:12 <sipa> or does the message hash depend on previous signatures as well?
320 2011-10-19 13:29:14 <gavinandresen> ByteCoin: I don't think so....
321 2011-10-19 13:29:17 <gmaxwell> waa?
322 2011-10-19 13:29:22 <tcatm> n5: make -f makefile..... bitcoind USE_UPNP=
323 2011-10-19 13:29:30 <n5> ok
324 2011-10-19 13:29:44 <ByteCoin> Let me find the forum post...
325 2011-10-19 13:30:25 <gavinandresen> ByteCoin: I hacked a version of bitcoin to spit out what was actually being signed while I was implementing OP_EVAL, and the signatures aren't signed.
326 2011-10-19 13:31:20 <gmaxwell> gavinandresen: well you need to know the exact outputs for your dictonary approach.. and their order... Actually just passing the transaction itself around sounds simpler to me... though I guess you'll need a way of parsing it and displaying it.
327 2011-10-19 13:31:33 <gavinandresen> CHECKSIG does not sign the transaction hash that you see in block explorer....
328 2011-10-19 13:31:36 <ByteCoin> https://bitcointalk.org/index.php?topic=40627.msg494697#msg494697
329 2011-10-19 13:31:51 <ByteCoin> Ok. Sorry. I'm muddled
330 2011-10-19 13:32:11 <ByteCoin> You can't have a transaction that spends an unsigned transaction
331 2011-10-19 13:32:29 <gmaxwell> oh because the signature changes the id on the network.
332 2011-10-19 13:32:30 <n5> tcatm, - http://pastebin.com/3HVLywEK
333 2011-10-19 13:32:43 <gmaxwell> Thats unfortunate, but its not what we were talking about here.
334 2011-10-19 13:32:53 <ByteCoin> Yes. Sorry about that. I misremembered. Yes it's not relevant to the current discussion
335 2011-10-19 13:33:38 <ByteCoin> I vote for inserting zero bytes for the missing signatures. And the code should be changed so that signatures always take a constant number of bytes to encode
336 2011-10-19 13:34:09 <tcatm> n5: you need to install BDB's c++ dev package using the system's package manager
337 2011-10-19 13:34:13 <ByteCoin> The current way of interpreting numbers with the top bit set as negative is a problem
338 2011-10-19 13:34:57 <gavinandresen> gmaxwell: the "you need to know where to put the signatures" is part of why I think maybe just a serialized sig with zero placeholders might not be the right thing to do...  although I'm probably wrong
339 2011-10-19 13:34:57 <gmaxwell> ByteCoin: the proposed signature recovery stuff would make signatures constant size as a side effect I think.
340 2011-10-19 13:36:00 <gavinandresen> gmaxwell: the danger would be people write code that just fill in signatures of 'weird' transactions that they don't understand.  Although I suppose we could just say you're an idiot if you do that, because you might not be signing what you think you're signing
341 2011-10-19 13:36:08 <ByteCoin> gmaxwell: Good. I guess if the 2 hint bits are in the lsbs of top byte of the number then that's ok
342 2011-10-19 13:37:30 <ByteCoin> gavin: If the places to put the signatures was indicated in any other way, broken software could still try to stuff a signature in an inappropriate place anyway
343 2011-10-19 13:38:27 <gavinandresen> The code for filling in a (say) 2-of-6 MULTISIG would be a little trickier, because the order of signatures matters...
344 2011-10-19 13:40:21 <gavinandresen> ... so whoever ends up sending the transaction will probably end up digging out all the signatures and re-ordering them anyway.
345 2011-10-19 13:42:57 <gmaxwell> gavinandresen: yes, but no disagreement over what they're actually signing.
346 2011-10-19 13:43:06 <n5> tcatm,  - http://pastebin.com/MdS683wp huh its hard a bit, i dont get it at all
347 2011-10-19 13:44:45 <tcatm> n5: does it work when compiling without -static?
348 2011-10-19 13:44:57 <gavinandresen> gmaxwell: right.  It just seems to me that if the task is "gather up signatures for this transaction" then a serialized transaction with zero'ed out pubkeys in the signature may not be the right data structure; everybody will end up pulling signatures out anyway to figure out what has already been signed and what hasn't, etc....
349 2011-10-19 13:45:55 <jrmithdobbs> why not just have each signature prefixed with it's position?
350 2011-10-19 13:46:28 <jrmithdobbs> it's not like >256 sigs are going to be common
351 2011-10-19 13:46:45 <gavinandresen> jrmithdobbs: that's what <input> : <signature> would be....
352 2011-10-19 13:46:58 <gmaxwell> gavinandresen: Perhaps. I also like the idea that a completed but unsent txn has the same format as an incomplete one.
353 2011-10-19 13:47:11 <ByteCoin> You could have a dummy-verifier for a transaction where if a signature were all zero then it would be tweaked to evaluate it as correct. This would enable people to verify that their signature was put in the right place
354 2011-10-19 13:47:12 <gmaxwell> But I guess it doesn't actually matter so long as the result works.
355 2011-10-19 13:47:30 <jrmithdobbs> gavinandresen: i didn't read the whole buffer, but yes
356 2011-10-19 13:48:22 <ByteCoin> If they replace the wrong sequence of zero bytes with their signature then the transaction now gets rejected by the dummy-verifier
357 2011-10-19 13:48:57 <jrmithdobbs> how is that more helpful than just rejecting once all sigs are available and combination fails?
358 2011-10-19 13:49:12 <jrmithdobbs> seems overcomplicated for no gain
359 2011-10-19 13:49:18 <gavinandresen> ByteCoin: the problem with ordering is lets say you need 2 of <a,b,c> to sign, but you ask <b> to sign first.  Should <b> put the signature in the first or second slot?
360 2011-10-19 13:49:18 <lianj> there are some right reason to add complexity but so many wrong ones
361 2011-10-19 13:50:19 <ByteCoin> gavin: I'm not familiar with your intended syntax for 2 of 3 multisignatures. Is order important?
362 2011-10-19 13:50:32 <jrmithdobbs> ByteCoin: also, prefixing with the index may be kind of ugly but it allows huge, say, 0x10 of 0xf0ffff sigs without blowing up the blockchain
363 2011-10-19 13:50:41 <gavinandresen> ByteCoin: yes, I'm assuming CHECKMULTISIG where the order of signatures must match order of public keys
364 2011-10-19 13:50:44 <jrmithdobbs> which while not common could definitely be useful transactions
365 2011-10-19 13:51:43 <ByteCoin> gavin: It would be polite to indicate where to place the signature but if that information were not forthcoming, <b> could use my dummy-verifier to ascertain where to put the signature
366 2011-10-19 13:52:21 <gavinandresen> ByteCoin: ... but where to put the signature depends on whether a or c is asked to sign next....  and b can't know that
367 2011-10-19 13:53:09 <ByteCoin> Ah....
368 2011-10-19 13:53:13 <ByteCoin> I see
369 2011-10-19 13:53:44 <ByteCoin> Seems to be a good reason to make checkmultisig not care about the order
370 2011-10-19 13:54:44 <ByteCoin> As the public key can be extracted from the signature, perhaps checmultisig can work it out  correctly...
371 2011-10-19 13:55:03 <gavinandresen> Mmmm... that'd be a blockchain-splitting change unless we 'hid' it inside OP_EVAL changes... and I'm worried about making the OP_EVAL proposals too extensive already
372 2011-10-19 13:56:09 <ByteCoin> gavin: Signatures must be moveable so if <b> signs in the "first" place and the transaction is then sent to <a> then <a> must move the signature?
373 2011-10-19 13:56:31 <ByteCoin> Otherwise <a>'s validation of the transaction will fail
374 2011-10-19 13:57:40 <ByteCoin> <b>s dummy-verification of the 2-of-3 transaction would succeed as the dummy-verifier would assume that the zero signature had been supplied by <c>
375 2011-10-19 13:58:19 <gavinandresen> ByteCoin: sure, that's do-able, it is just more complicated code than "Add my signatures to the dictionary" and then having the txn submission code grab signatures from the dictionary to create the final scriptSigs.
376 2011-10-19 13:58:48 <gavinandresen> I wonder if there is a use case for gathering more signatures than required, and then having some preference for WHICH signatures are used to satisfy...
377 2011-10-19 13:59:16 <gavinandresen> e.g. if you have a 2-of-3 transaction, would you ever want to gather all three and then have some preference on which 2 you use?
378 2011-10-19 13:59:34 <ByteCoin> You couldn't rule such a thing out....
379 2011-10-19 14:00:02 <ByteCoin> The fact that someone can be seen to have signed something conveys information
380 2011-10-19 14:00:57 <ByteCoin> Now that you've discussed it, I think that your solution is better than what I proposed initially. I've changed my mind.
381 2011-10-19 14:01:04 <gavinandresen> That's a problem for the placeholder solution if, for example, you had a.. oh, I dunno, 1-of-6.  And somebody wanted to give you the information "I hold 3 of the keys" (since there's only room for 1 placeholder)
382 2011-10-19 14:02:36 <ByteCoin> Use your method of having a signature dictionary/map/list/whatever
383 2011-10-19 14:04:02 <gmaxwell> gavinandresen: meh, don't do that. Use signmessage to prove ownership.
384 2011-10-19 14:04:22 <gmaxwell> Arguably you shouldn't be permitted to provide too many for x-of-y validations.
385 2011-10-19 14:04:23 <ByteCoin> The equivalent of the "dummy-verifier" code has to be a bit more intelligent with your solution though....
386 2011-10-19 14:05:41 <gavinandresen> gmaxwell: that's why I asked "is there a use case" .... I don't have a clear vision in my head how more complicated m-of-n signature schemes will work
387 2011-10-19 14:09:00 <n5> tcatm,  ok i'm done for today... its not working, will work on it tommorow
388 2011-10-19 14:09:56 <ByteCoin> gmaxwell: Re: you shouldn't be permitted to provide too many for x-y validations. Yes when you submit the transaction it shouldn't have too many signatures but while it's being passed round partly signed then you couldn't rule it out. Such as if m of n signatures are used for voting schemes were the number of votes you hold is represented by how many signatures you can provide
389 2011-10-19 14:11:05 <whiteman> Just in case you guys didn't see last night, I found a problem compiling under Ubuntu 11.10. The package libdb4.8++-dev no longer exists, but libdb5.1++-dev works as a replacement on both 11.04 and 11.10.
390 2011-10-19 14:11:11 <gmaxwell> ByteCoin: well, if I have enough to meet M on my own. ... tada. I win.
391 2011-10-19 14:11:31 <ByteCoin> Obviously.
392 2011-10-19 14:11:52 <whiteman> I got a segmentation fault when trying to run bitcoin-qt on 11.10, but I'm rechecking that now.
393 2011-10-19 14:11:55 <ByteCoin> We're presuming in the voting scenario that one person doesn't have enough signatures to satisfy it
394 2011-10-19 14:12:14 <gmaxwell> ByteCoin: right why not fill with all I can.. then pass it along until its met?
395 2011-10-19 14:13:11 <gmaxwell> so. .. e.g. if it needs 10 votes and you and I have 8 keys and you have 4 ... we just have me prove 8, and you provide two.
396 2011-10-19 14:13:19 <ByteCoin> Ok. Imagine a 4 of 5 scheme in which A holds 2 and B holds 1  and C holds 2. If A and B sign then it still needs C to sign